From wintert@acm.org Sun Nov 1 15:21:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F5E3A686B for ; Sun, 1 Nov 2009 15:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jda2hEZoxVz for ; Sun, 1 Nov 2009 15:21:35 -0800 (PST) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id 1108E3A67FD for ; Sun, 1 Nov 2009 15:21:34 -0800 (PST) Received: (qmail 77969 invoked from network); 1 Nov 2009 23:21:48 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 01 Nov 2009 15:21:48 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: dFuu4eMVM1k.nRxi4iLyXIxu1Pkj.WOZCBdCWC0kEIif_EraJH1Kk2Z6gU3ma5zqHm53Z9aqTfE7JsXOFccVo7OyC_89p4UDointKft7CO9l23jO050PNtVR.WT0IbLRFvx20NHxvDCETdPHBZohW4OoRtK.jxhhVP8Y4Lp96198buLhzI5F4ghIyuualDdxmcdIrYhoayJIU2gaAjFuUmIDr8xan7MSN6oI625hnvtCySAmMnBvSRm_2Ct26uA.ln.Pcbm9Q6jhX8DF6_HhWhRdTGc3xz8g82.ry5kq3Fzn0pGcRaxKBeKfKpV7nojXkWLmlq_JIB7fbMfapPxsWpfQI9wEwN3bOdLGJ3mhwV12ujehhG8D6HtJGnJzvAmYu0Dkf1LMtT7s.ehwhYxPMdbxMZ6OVz0kd9T6fUN7jm4E9gsIq98X7yexcip2NSUsXo84FNZreHxwVoJ0AA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AEE180B.8040805@acm.org> Date: Sun, 01 Nov 2009 18:21:47 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Julien Abeille \(jabeille\)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 23:21:36 -0000 Hi Julien, WG, Yes, the draft-ietf-roll-routing-metrics-03 suggests that the metrics may exceed 255 bytes, and so the DIO suboption for DAG Metric Container drives the overall requirements for suboption length. If we use 16bits for length, maybe 1 byte is `wasted' to specify a short ( < 255 bytes) option. If we use 8bits for length in units of 8bytes, only one byte is used for suboption length in all cases, so the second byte is saved. But the suboption itself must pad for [0-7] bytes to meet the 8 byte boundary. In the first case, 0 byte of padding is required, one byte is saved from encoding the suboption length, and one byte is saved overall. In the second case, 1 byte of padding is used and one byte is saved from the suboption length, breaking even. In the 6 other cases, more bytes are used for padding than are saved in encoding the suboption length. We don't know anything yet about a typical distribution of lengths for suboptions, in particular the DAG Metric Container. So perhaps this discussion could be premature. But, given that in the 8byte encoding case we use more bytes in 6/8 of the possible cases, my opinion is that it is better to stick with a 16-bit suboption length in units of bytes. Thoughts? Did you have another architectural driver in mind? -Tim Julien Abeille (jabeille) wrote: > Hi all, > > do we expect DIO suboptions to be longer than 255 bytes? if yes would it > be ok to spell the length in multiple of 8bytes instead of bytes (value > of 1 means 8 bytes, like in ND). The target is to use 8 bits instead of 16. > > Thank you, > Julien > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Mon Nov 2 01:29:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CD128C197 for ; Mon, 2 Nov 2009 01:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.973 X-Spam-Level: X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 bKkSXnr4h5-P for ; Mon, 2 Nov 2009 01:29:38 -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 D290428C194 for ; Mon, 2 Nov 2009 01:29:16 -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: AjYAAPQ07kqQ/uCWe2dsb2JhbACbUwEBCwskBqc+lkGEOQQ X-IronPort-AV: E=Sophos;i="4.44,665,1249257600"; d="scan'208";a="53347979" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2009 09:29:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA29TYZj029071; Mon, 2 Nov 2009 09:29:34 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:29:34 +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, 2 Nov 2009 10:29:33 +0100 Message-ID: In-Reply-To: <4AEE180B.8040805@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [roll] #8: DIO Option Length Thread-Index: AcpbSh8gYpopar3YSgSJlR+6JBRIgQAU0Mmw References: <4AEE180B.8040805@acm.org> From: "Julien Abeille (jabeille)" To: "Tim Winter" X-OriginalArrivalTime: 02 Nov 2009 09:29:34.0388 (UTC) FILETIME=[FD2AC740:01CA5B9E] Cc: ROLL WG Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 09:29:39 -0000 Hi Tim, Thanks for answering. I am not sure I get your point about padding. Removing one byte does not necessarily mean that it will have to be padded, e.g. if the option is padding 7 bytes with 2 bytes length, it will not pad anything with one byte length.=20 But I think you are correct that it may be a bit early to discuss all this ;-) Some suboptions should be moved to options (separate thread, DIO base option is not optional hence should not be an option. Makes sense?). General related question: for the cases where we need suboptions (metric container), do we want suboptions to be 8 bytes aligned? Or only options should be 8 bytes aligned? Best, Julien > -----Original Message----- > From: Tim Winter [mailto:wintert@acm.org]=20 > Sent: lundi 2 novembre 2009 00:22 > To: Julien Abeille (jabeille) > Cc: ROLL WG > Subject: Re: [roll] #8: DIO Option Length >=20 > Hi Julien, WG, >=20 > Yes, the draft-ietf-roll-routing-metrics-03 suggests that the=20 > metrics may exceed 255 bytes, and so the DIO suboption for=20 > DAG Metric Container drives the overall requirements for=20 > suboption length. >=20 > If we use 16bits for length, maybe 1 byte is `wasted' to=20 > specify a short ( < > 255 bytes) option. >=20 > If we use 8bits for length in units of 8bytes, only one byte=20 > is used for suboption length in all cases, so the second byte=20 > is saved. But the suboption itself must pad for [0-7] bytes=20 > to meet the 8 byte boundary. In the first case, 0 byte of=20 > padding is required, one byte is saved from encoding the=20 > suboption length, and one byte is saved overall. In the=20 > second case, 1 byte of padding is used and one byte is saved=20 > from the suboption length, breaking even. In the 6 other=20 > cases, more bytes are used for padding than are saved in=20 > encoding the suboption length. >=20 > We don't know anything yet about a typical distribution of=20 > lengths for suboptions, in particular the DAG Metric=20 > Container. So perhaps this discussion could be premature. =20 > But, given that in the 8byte encoding case we use more bytes=20 > in 6/8 of the possible cases, my opinion is that it is better=20 > to stick with a 16-bit suboption length in units of bytes. >=20 > Thoughts? >=20 > Did you have another architectural driver in mind? >=20 > -Tim >=20 > Julien Abeille (jabeille) wrote: > > Hi all, > > =20 > > do we expect DIO suboptions to be longer than 255 bytes? if=20 > yes would=20 > > it be ok to spell the length in multiple of 8bytes instead=20 > of bytes=20 > > (value of 1 means 8 bytes, like in ND). The target is to=20 > use 8 bits instead of 16. > > =20 > > Thank you, > > Julien > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From jabeille@cisco.com Mon Nov 2 02:04:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8148628C1AD for ; Mon, 2 Nov 2009 02:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPQvmB6apwS5 for ; Mon, 2 Nov 2009 02:04:43 -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 64B5D28C1A2 for ; Mon, 2 Nov 2009 02:04:43 -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: Aj8AAC097kqQ/uCWe2dsb2JhbACCKCuZAAEBCwskBj2nHJZEhDkE X-IronPort-AV: E=Sophos;i="4.44,665,1249257600"; d="scan'208,217";a="53352613" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2009 10:05:02 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA2A51TP011356 for ; Mon, 2 Nov 2009 10:05:02 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 11:05:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BA3.F0B41EC0" Date: Mon, 2 Nov 2009 11:05:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL detail: DEFAULT_DIO_REDUNDANCY_CONSTANT Thread-Index: Acpbo/BAycHT0vbDR5qXYjx27Faj8w== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 02 Nov 2009 10:05:01.0633 (UTC) FILETIME=[F11A9B10:01CA5BA3] Subject: [Roll] RPL detail: DEFAULT_DIO_REDUNDANCY_CONSTANT X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Nov 2009 10:04:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BA3.F0B41EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 detail: DEFAULT_DIO_REDUNDANCY_CONSTANT is not specified or mentionned in section 6. =20 Best, Julien ------_=_NextPart_001_01CA5BA3.F0B41EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
detail:=20 DEFAULT_DIO_REDUNDANCY_CONSTANT is not specified or mentionned in = section=20 6.
 
Best,
Julien
------_=_NextPart_001_01CA5BA3.F0B41EC0-- From jabeille@cisco.com Mon Nov 2 02:51:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8057F3A67E5 for ; Mon, 2 Nov 2009 02:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.015 X-Spam-Level: X-Spam-Status: No, score=-10.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bn4ykjbvQW3 for ; Mon, 2 Nov 2009 02:51:23 -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 5EC8B3A67E1 for ; Mon, 2 Nov 2009 02:51:23 -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: AjwAANtI7kqQ/uCWe2dsb2JhbACCJyyZAAEBCwskBqdSlk2EOQQ X-IronPort-AV: E=Sophos;i="4.44,666,1249257600"; d="scan'208,217";a="53359047" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2009 10:51:39 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA2ApdeM005027 for ; Mon, 2 Nov 2009 10:51:39 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 11:51:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BAA.749991BA" Date: Mon, 2 Nov 2009 11:51:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL clarification needed: 5.10.1.3 Thread-Index: AcpbqnQs8P+ySLDQR3WoncMSDaO2PQ== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 02 Nov 2009 10:51:39.0528 (UTC) FILETIME=[74C78080:01CA5BAA] Subject: [Roll] RPL clarification needed: 5.10.1.3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Nov 2009 10:51:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BAA.749991BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 in section 5.10.1.3: "When a node receives a DIO message over an LLN interface from a DA parent, the DelayDAO is armed to force a full update." =20 should I read "when a node receives a DIO message with the D flag set..." =20 At the next line, broadcast should be multicast. =20 Best, Julien ------_=_NextPart_001_01CA5BAA.749991BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
in = section=20 5.10.1.3:
"When = a node=20 receives a DIO message over an LLN interface from a DA
   = parent,=20 the DelayDAO is armed to force a full update."
 
should = I read "when=20 a node receives a DIO message with the D flag = set..."
 
At the = next line,=20 broadcast should be multicast.
 
Best,
Julien
------_=_NextPart_001_01CA5BAA.749991BA-- From trac@tools.ietf.org Mon Nov 2 05:12:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981203A6A0D for ; Mon, 2 Nov 2009 05:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 xC+IxdloMone for ; Mon, 2 Nov 2009 05:12:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 0ADC83A6923 for ; Mon, 2 Nov 2009 05:12:52 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N4wib-0005R8-0F; Mon, 02 Nov 2009 05:13:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 02 Nov 2009 13:13:08 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/9 Message-ID: <055.6453f7e4084a474e1bfade94efbfbfeb@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #9: DEFAULT_DIO_REDUNDANCY_CONSTANT X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:12:52 -0000 #9: DEFAULT_DIO_REDUNDANCY_CONSTANT --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- detail: DEFAULT_DIO_REDUNDANCY_CONSTANT is not specified or mentionned in section 6. -- Ticket URL: roll From jvasseur@cisco.com Mon Nov 2 05:12:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D81B28C0E7 for ; Mon, 2 Nov 2009 05:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.735 X-Spam-Level: X-Spam-Status: No, score=-7.735 tagged_above=-999 required=5 tests=[AWL=-1.136, 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 cy82rJ8J2JQe for ; Mon, 2 Nov 2009 05:12:57 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8619228C0DC for ; Mon, 2 Nov 2009 05:12:57 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG9p7kqrRN+J/2dsb2JhbADEJpZPhDkE X-IronPort-AV: E=Sophos;i="4.44,666,1249257600"; d="scan'208";a="200521139" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 02 Nov 2009 13:13:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nA2DDGT5011137; Mon, 2 Nov 2009 13:13:17 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 14:13:16 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 14:13:15 +0100 Message-Id: From: JP Vasseur To: Tim Winter In-Reply-To: <4AEE180B.8040805@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 14:13:15 +0100 References: <4AEE180B.8040805@acm.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Nov 2009 13:13:15.0587 (UTC) FILETIME=[3CD33930:01CA5BBE] Cc: ROLL WG Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:12:58 -0000 On Nov 2, 2009, at 12:21 AM, Tim Winter wrote: > Hi Julien, WG, > > Yes, the draft-ietf-roll-routing-metrics-03 suggests that the > metrics may > exceed 255 bytes, and so the DIO suboption for DAG Metric Container > drives > the overall requirements for suboption length. > > If we use 16bits for length, maybe 1 byte is `wasted' to specify a > short ( < > 255 bytes) option. > > If we use 8bits for length in units of 8bytes, only one byte is used > for > suboption length in all cases, so the second byte is saved. But the > suboption itself must pad for [0-7] bytes to meet the 8 byte > boundary. In > the first case, 0 byte of padding is required, one byte is saved from > encoding the suboption length, and one byte is saved overall. In > the second > case, 1 byte of padding is used and one byte is saved from the > suboption > length, breaking even. In the 6 other cases, more bytes are used for > padding than are saved in encoding the suboption length. > > We don't know anything yet about a typical distribution of lengths for > suboptions, in particular the DAG Metric Container. So perhaps this > discussion could be premature. But, given that in the 8byte > encoding case > we use more bytes in 6/8 of the possible cases, my opinion is that > it is > better to stick with a 16-bit suboption length in units of bytes. > +1 > Thoughts? > > Did you have another architectural driver in mind? > > -Tim > > Julien Abeille (jabeille) wrote: >> Hi all, >> >> do we expect DIO suboptions to be longer than 255 bytes? if yes >> would it >> be ok to spell the length in multiple of 8bytes instead of bytes >> (value >> of 1 means 8 bytes, like in ND). The target is to use 8 bits >> instead of 16. >> >> Thank you, >> Julien >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 trac@tools.ietf.org Mon Nov 2 05:24:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C05E3A6885 for ; Mon, 2 Nov 2009 05:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo3B4n604g5X for ; Mon, 2 Nov 2009 05:24:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C1E893A6852 for ; Mon, 2 Nov 2009 05:24:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N4wto-0000Kh-Il; Mon, 02 Nov 2009 05:24:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 02 Nov 2009 13:24:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/10 Message-ID: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:24:27 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email from JP: (chair hat off) We'd like to get your input on the following issue. Referring the following text: We had that text is -03: "RPL is designed to survive and still operate, though in a somewhat degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector of metrics that it sources in the DAG, derived in part from the metrics sourced from its preferred parent. As a result, the DAG is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect. The default operation specified in OCP 0 clarifies this point." We changed the text but still some confusion remains so let's try to clarify. Question 1: should we rely on default OCP/Metric ? Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP Option 2: the OCP/metric must always be explicitly mentioned in the DIO. Question 2: OCP/metric not understood/supported. Consider the following DAG: A / \ B C X X is a new node receiving DIO messages from B and C. The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?" 1) Option 1 X logs the problem and does not join the DAG at all. 2) Option 2 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind). 3) Option 3 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes. I personally favor 2). Opinions ? Thanks. JP. CONCLUSION The WG seems to convergence of both option 2 above. RPL -05 text to be adjusted: => The DAG metric Container MUST include an OF => The document specify one OCP (OCP0), let's no longer call it the "default" OCP => Add if a node receives a OF that it does not understand/support, it SHOULD log the problem (add it to the manageability section). It SHOULD join the DAG selecting a parent as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that the node should not start advertising a DIO with inconsistent metric (that could confuse many other nodes behind). -- Ticket URL: roll From trac@tools.ietf.org Mon Nov 2 06:03:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E4C3A6944 for ; Mon, 2 Nov 2009 06:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yiq4b6dAAIGw for ; Mon, 2 Nov 2009 06:03:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 3B3273A6963 for ; Mon, 2 Nov 2009 06:03:56 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N4xW4-00043M-Cg; Mon, 02 Nov 2009 06:04:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 02 Nov 2009 14:04:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/11 Message-ID: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #11: Decision on prefix packing in DIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:03:57 -0000 #11: Decision on prefix packing in DIO messages --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Currently RPL requires one DAO per message. JP's proposal below: Hi Jonathan, What I was referring to was to pack prefix in DAO, a very light change in the spec (just make use of TLV) and factor the common fields. This allows to reduce the number of packets very significantly as we get closer to the root. There two benefits here: 1) You send one DAO between C and D instead of 3 2) You can also pack the Reverse Route Stack whenever possible for all prefix sharing the same routes. Let's suppose that: 1) X advertises two prefixes X1 and X2 2) Y advertises two prefixes Y1, Y2 and Y3 3) Z advertised one prefix: Z1 Instead of sending 6 DAO, C would send one DAO to D would look like this: X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] Note that you could when possible also aggregates prefixes at the same time if they share a common path. BAck to you timing question Richard, it depends of the sequence of events but there is no need to wait. C could start with one DAO and then start to pack at it receives more, the same reasoning applies to other nodes. Others, thoughts ? Thanks. JP. -- Ticket URL: roll From pal@cs.stanford.edu Mon Nov 2 08:04:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555F93A6A1B for ; Mon, 2 Nov 2009 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 wUBnl1rxpgG0 for ; Mon, 2 Nov 2009 08:04:45 -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 94DC73A689F for ; Mon, 2 Nov 2009 08:04:45 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N4zOy-0007z1-OC; Mon, 02 Nov 2009 08:05:05 -0800 Message-Id: <2C784EE0-FC0F-45EE-9AE6-47A9947E8FB6@cs.stanford.edu> From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 08:05:19 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll ROLL Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Nov 2009 16:04:46 -0000 On Oct 30, 2009, at 11:39 AM, Jerald.P.Martocci@jci.com wrote: > > HiPhil, > > Leaving Neighbor Cache building and maintenance to the discretion of > the implementer seems to open the door toward non-interoperable > implementations on multi-vendor systems. How one builds and > maintains its neighbor cache seems to me to be a very important > primitive operation of a mesh system. > > If all implementations must all support the full suite of messages > and the implementation is just deciding which message it will use to > build its cache, that's ok. However, if implementer A picks message > X to build its neighbor cache while implementer B picks message Y > and elects not to support message X; that would not be a good thing. > > The point of all this babble is to please keep in mind > nonhomogeneous networks composed of many vendors' implementations. I think we agree? There needs to be a specified set of operations which a node can use to discover other nodes, in that a RPL implementation MUST implement them. As it's a MUST, I'm of the opinion that such a set should be as simple and minimal as possible. Implementations can use other mechanisms as desired, but have to be able to use the standardized ones, such that they place a MUST on what other nodes do. Phil From jabeille@cisco.com Mon Nov 2 09:00:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D693A68D0 for ; Mon, 2 Nov 2009 09:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.035 X-Spam-Level: X-Spam-Status: No, score=-8.035 tagged_above=-999 required=5 tests=[AWL=-1.437, BAYES_00=-2.599, 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 fkGgTUIgaXQi for ; Mon, 2 Nov 2009 09:00:23 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4623428C14A for ; Mon, 2 Nov 2009 09:00:23 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAKOe7kqrR7Ht/2dsb2JhbACCJyzDSpZohDwE X-IronPort-AV: E=Sophos;i="4.44,668,1249257600"; d="scan'208,217";a="422991308" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 02 Nov 2009 17:00:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA2H0aXv015243 for ; Mon, 2 Nov 2009 17:00:43 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 18:00:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5BDE.027B8CE4" Date: Mon, 2 Nov 2009 18:00:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification: DIS processing Thread-Index: Acpb3gHKg5inE4o1QSGH0K3LaI8Zcw== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 02 Nov 2009 17:00:41.0631 (UTC) FILETIME=[02804AF0:01CA5BDE] Subject: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Nov 2009 17:00:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BDE.027B8CE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 one question: when a router receives a DIS, should it answer right away? I guess this is a good source of collision, so a random timer would help. Could we set T to a random value between I_min /2 and I_Min, without resetting I (receiving a DIS does not mean inconsistency)? =20 Best, Julien ------_=_NextPart_001_01CA5BDE.027B8CE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
one=20 question:
when a = router=20 receives a DIS, should it answer right away? I guess this is a good = source of=20 collision, so a random timer would help. Could we set T to a random = value=20 between I_min /2 and I_Min, without resetting I (receiving a DIS = does not=20 mean inconsistency)?
 
Best,
Julien
------_=_NextPart_001_01CA5BDE.027B8CE4-- From jvasseur@cisco.com Mon Nov 2 13:04:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2B13A6A84 for ; Mon, 2 Nov 2009 13:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.712 X-Spam-Level: X-Spam-Status: No, score=-7.712 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, 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 Uf4i0EByfCYS for ; Mon, 2 Nov 2009 13:04:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 14AFA3A697E for ; Mon, 2 Nov 2009 13:04:11 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAJbX7kqtJV2Z/2dsb2JhbACCJi3DTZZ/hDwE X-IronPort-AV: E=Sophos;i="4.44,670,1249257600"; d="scan'208,217";a="66038838" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2009 21:04:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id nA2L3Ugk005835 for ; Mon, 2 Nov 2009 21:04:30 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:03:38 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:03:38 +0100 Message-Id: From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-37--284256505 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 22:03:37 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Nov 2009 21:03:38.0460 (UTC) FILETIME=[F2F7E1C0:01CA5BFF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16984.005 X-TM-AS-Result: No--14.233900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Nov 2009 21:04:12 -0000 --Apple-Mail-37--284256505 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Nov 2, 2009, at 6:00 PM, Julien Abeille (jabeille) wrote: > Hi all, > > one question: > when a router receives a DIS, should it answer right away? I guess > this is a good source of collision, so a random timer would help. > Could we set T to a random value between I_min /2 and I_Min, without > resetting I (receiving a DIS does not mean inconsistency)? I do not see either why we should reset the trickle timer. JP. > > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-37--284256505 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Nov 2, = 2009, at 6:00 PM, Julien Abeille (jabeille) wrote:

=
Hi= all,
 
one = question:
when a = router receives a DIS, should it answer right away? I guess this is a = good source of collision, so a random timer would help. Could we set T = to a random value between I_min /2 and I_Min, without resetting I = (receiving a DIS does not mean inconsistency)?
=

I = do not see either why we should reset the trickle = timer.

JP.

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

= --Apple-Mail-37--284256505-- From sung.lee@us.fujitsu.com Mon Nov 2 15:03:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6724A3A684A for ; Mon, 2 Nov 2009 15:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, 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 Fi1+mBkx1hto for ; Mon, 2 Nov 2009 15:03:03 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 8C2773A67DB for ; Mon, 2 Nov 2009 15:03:03 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id nA2N4Lbe008551 for ; Mon, 2 Nov 2009 15:04:21 -0800 (PST) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id nA2N4Lst008548 for ; Mon, 2 Nov 2009 15:04:21 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id nA2N3Mwa008657 for ; Mon, 2 Nov 2009 15:03:23 -0800 (PST) Received: from [10.157.253.52] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id nA2N3Me00670 for ; Mon, 2 Nov 2009 15:03:22 -0800 (PST) Message-ID: <4AEF6538.5020207@us.fujitsu.com> Date: Mon, 02 Nov 2009 18:03:20 -0500 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-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, 02 Nov 2009 23:03:04 -0000 > You're quite right that the results were for a limited topology size. > I would vote for making it > configurable 3-bit flag that could be adjusted according to the > network topology. JP, Does this mean that one can have up to 2^3 sibling transmissions (configurable parameter)? Did I understand you correctly? This might work and I am willing to take this as an initial point although we would evaluate this value further to make sure that this is adequate number. Thanks. Sung roll-request@ietf.org wrote: > Message: 1 > Date: Thu, 29 Oct 2009 17:18:26 +0100 > From: JP Vasseur > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt > To: Sung Lee > Cc: roll@ietf.org > Message-ID: <45049DAF-552D-4D3D-9846-CBA60B77BFF8@cisco.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Oct 29, 2009, at 5:08 PM, Sung Lee wrote: > > >> Tim and WG members, >> >> I was reviewing v04 and have some concerns about current proposal. >> In particular, the restriction on 2 sibling hops in a row. >> >> >>> 5.11.4. Sibling Loop Avoidance >>> >>> When a packet is forwarded along siblings, it cannot be checked for >>> forward progress and may loop between siblings. Experimental >>> evidence has shown that one sibling hop can be very useful but is >>> generally sufficient to avoid loops. Based on that evidence, this >>> specification enforces the simple rule that a packet may not make 2 >>> sibling hops in a row. >>> >> I recall that the experiment result was presented at the interim >> meeting. >> However, it was also pointed out that if the selected sibling is not >> the >> right one, then you risk a packet loss. >> If the network topology is simple enough, this may be sufficient >> restriction to avoid sibling loops. >> Without much coordinated effort of trying to figure out the "right" >> next >> hop sibling, this simple restriction will cause many packet drops if >> the >> network topology is complicated. >> >> My understanding is that ROLL is targeting for a large scale network. >> And I have concerns about this. >> I would like to hear about what others think about this. >> > > You're quite right that the results were for a limited topology size. > I would vote for making it > configurable 3-bit flag that could be adjusted according to the > network topology. > > Thoughts ? > > JP. > > >> Regards, >> Sung >> >> From jvasseur@cisco.com Mon Nov 2 23:15:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C7E28C145 for ; Mon, 2 Nov 2009 23:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.391 X-Spam-Level: X-Spam-Status: No, score=-7.391 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 g88KewTvCOTQ for ; Mon, 2 Nov 2009 23:15:55 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1A32F3A68B0 for ; Mon, 2 Nov 2009 23:15:55 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdn70qrR7H+/2dsb2JhbADFE5dBhD0E X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="scan'208";a="265261714" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2009 07:16:14 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA37G6lO025792; Tue, 3 Nov 2009 07:16:12 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:16:08 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:16:07 +0100 Message-Id: From: JP Vasseur To: Sung Lee In-Reply-To: <4AEF6538.5020207@us.fujitsu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 08:16:06 +0100 References: <4AEF6538.5020207@us.fujitsu.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 07:16:07.0550 (UTC) FILETIME=[832201E0:01CA5C55] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-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: Tue, 03 Nov 2009 07:15:56 -0000 Hi Sung, On Nov 3, 2009, at 12:03 AM, Sung Lee wrote: > >> You're quite right that the results were for a limited topology size. >> I would vote for making it >> configurable 3-bit flag that could be adjusted according to the >> network topology. > > JP, > > Does this mean that one can have up to 2^3 sibling transmissions > (configurable parameter)? > Did I understand you correctly? > > This might work and I am willing to take this as an initial point > although we would evaluate this value further to make sure that this > is > adequate number. > The idea would be to make it n bits so indeed you would get 2^n mac number of sibling hops. Then you could configure the value of n for each network, possibly advertise it from the DAG root, .... Thanks. JP. > Thanks. > Sung > > roll-request@ietf.org wrote: >> Message: 1 >> Date: Thu, 29 Oct 2009 17:18:26 +0100 >> From: JP Vasseur >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> To: Sung Lee >> Cc: roll@ietf.org >> Message-ID: <45049DAF-552D-4D3D-9846-CBA60B77BFF8@cisco.com> >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Oct 29, 2009, at 5:08 PM, Sung Lee wrote: >> >> >>> Tim and WG members, >>> >>> I was reviewing v04 and have some concerns about current proposal. >>> In particular, the restriction on 2 sibling hops in a row. >>> >>> >>>> 5.11.4. Sibling Loop Avoidance >>>> >>>> When a packet is forwarded along siblings, it cannot be checked for >>>> forward progress and may loop between siblings. Experimental >>>> evidence has shown that one sibling hop can be very useful but is >>>> generally sufficient to avoid loops. Based on that evidence, this >>>> specification enforces the simple rule that a packet may not make 2 >>>> sibling hops in a row. >>>> >>> I recall that the experiment result was presented at the interim >>> meeting. >>> However, it was also pointed out that if the selected sibling is not >>> the >>> right one, then you risk a packet loss. >>> If the network topology is simple enough, this may be sufficient >>> restriction to avoid sibling loops. >>> Without much coordinated effort of trying to figure out the "right" >>> next >>> hop sibling, this simple restriction will cause many packet drops if >>> the >>> network topology is complicated. >>> >>> My understanding is that ROLL is targeting for a large scale >>> network. >>> And I have concerns about this. >>> I would like to hear about what others think about this. >>> >> >> You're quite right that the results were for a limited topology size. >> I would vote for making it >> configurable 3-bit flag that could be adjusted according to the >> network topology. >> >> Thoughts ? >> >> JP. >> >> >>> Regards, >>> Sung >>> >>> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Tue Nov 3 01:23:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1020A28C196 for ; Tue, 3 Nov 2009 01:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwbgVFjamkoy for ; Tue, 3 Nov 2009 01:23:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7117F3A69A2 for ; Tue, 3 Nov 2009 01:23:56 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N5Fcc-0002di-VL; Tue, 03 Nov 2009 01:24:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 03 Nov 2009 09:24:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/12 Message-ID: <055.c2df21e47095fbec7400989f77132d30@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #12: DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:23:57 -0000 #12: DIS --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: trivial | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Indicate in RPL that responses to DIS SHOULD be randomized to avoid message collision. -- Ticket URL: roll From mdurvy@cisco.com Tue Nov 3 02:28:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221EB3A69F0 for ; Tue, 3 Nov 2009 02:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.266 X-Spam-Level: X-Spam-Status: No, score=-8.266 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEM-zwnrUz-R for ; Tue, 3 Nov 2009 02:28:27 -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 7FDE83A69EB for ; Tue, 3 Nov 2009 02:28:26 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4AAH6U70qQ/uCWe2dsb2JhbACCJywhmGEBAQsLJAapMJdYAoQ7BA X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="gif'147?scan'147,208,217,147";a="53475643" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 10:28:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3ASiZ0024739 for ; Tue, 3 Nov 2009 10:28:44 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 11:28:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5C70.6B705DC4" Date: Tue, 3 Nov 2009 11:28:43 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on the objective function Thread-Index: AcpccGrHTjPvM/TMT3+OlbWoqmd+GQ== From: "Mathilde Durvy (mdurvy)" To: "roll" X-OriginalArrivalTime: 03 Nov 2009 10:28:44.0347 (UTC) FILETIME=[6B8548B0:01CA5C70] Subject: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:28:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C70.6B705DC4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5C70.6B705DC4" ------_=_NextPart_002_01CA5C70.6B705DC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 Section 5.9.1 says "When the scan is complete, the preferred parent is elected and self's rank is computed as the preferred parent rank plus the step in rank with that parent." Does this mean that the rank of a node is only based on the rank of its = most preferred parent? Shouldn't the rank of the node also depend on the non-preferred parents? Or is it assumed that the node always forward traffic via its most = preferred parent?=20 =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA5C70.6B705DC4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 All,

 

Section 5.9.1=20 says

    =20 "When the scan is complete, the preferred parent is elected = and
      self's = rank is=20 computed as the preferred parent rank plus the step
      in = rank with=20 that parent."
Does this mean that the = rank of a node=20 is only based on the rank of its most preferred = parent?

Shouldn't the rank of the node also = depend on the=20 non-preferred parents?

Or is it assumed that the node = always forward=20 traffic via its most preferred parent? 

 

Best,

Mathilde

 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA5C70.6B705DC4-- ------_=_NextPart_001_01CA5C70.6B705DC4 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA5C70.6B705DC4 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA5C70.6B705DC4-- From mdurvy@cisco.com Tue Nov 3 02:48:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEA93A6A04 for ; Tue, 3 Nov 2009 02:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 SEUXruq5siNw for ; Tue, 3 Nov 2009 02:48:09 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6F1493A69AC for ; Tue, 3 Nov 2009 02:48:09 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAC+Z70qrR7H+/2dsb2JhbACCJi0hwnSXXQKEOwQ X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="gif'147?scan'147,208,217,147";a="265335928" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2009 10:48:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA3AmDOJ021786 for ; Tue, 3 Nov 2009 10:48:29 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 11:48:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5C73.2BD107A8" Date: Tue, 3 Nov 2009 11:48:25 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEA161AF@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on parent / destination prefix / route removal Thread-Index: AcpccytsV946n2qGRMOOvMRn+icMYQ== From: "Mathilde Durvy (mdurvy)" To: "roll" X-OriginalArrivalTime: 03 Nov 2009 10:48:26.0104 (UTC) FILETIME=[2BE71780:01CA5C73] Subject: [Roll] Clarification on parent / destination prefix / route removal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Nov 2009 10:48:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C73.2BD107A8 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5C73.2BD107A8" ------_=_NextPart_002_01CA5C73.2BD107A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 This is my current understanding: =20 - Parents are removed based on OF selection (decision to move within the = DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer = procedure described in section 5.10.1.1.1. This is essentially a keep = alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding = destination prefix is removed?=20 - When are routes corresponding to parents removed? Do they also have a = lifetime? - What happens when a neighbor disappears, are the corresponding = parents/destination/routes removed? =20 The current behavior seems quite asymmetric... There is some kind of = keep alive mechanism for destination prefixes, but not for parents. = There is a lifetime associated with routes corresponding to destination = prefixes but not for routes corresponding to parents. Is that a design = choice? I would appreciate some clarifications. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA5C73.2BD107A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
This = is my current=20 understanding:
 
- = Parents are=20 removed based on OF selection (decision to move within the DAG, change = DAG,=20 etc)
- = Destination=20 prefixes are removed after the retry / RemoveTimer procedure described = in=20 section 5.10.1.1.1. This is essentially a keep alive mechanism based on=20 DIO (D bit set) - DAO exchanges.
- = Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires? Are they also removed when the corresponding destination prefix = is=20 removed?
- When = are routes=20 corresponding to parents removed? Do they also have a=20 lifetime?
- What = happens when=20 a neighbor disappears, are the corresponding parents/destination/routes=20 removed?
 
The = current behavior=20 seems quite asymmetric... There is some kind of keep alive mechanism for = destination prefixes, but not for parents. There is a lifetime = associated with=20 routes corresponding to destination prefixes but not for routes = corresponding to=20 parents. Is that a design choice? I would appreciate some=20 clarifications.
 
Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA5C73.2BD107A8-- ------_=_NextPart_001_01CA5C73.2BD107A8 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA5C73.2BD107A8 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA5C73.2BD107A8-- From jvasseur@cisco.com Tue Nov 3 03:29:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDEE3A67DA for ; Tue, 3 Nov 2009 03:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.664 X-Spam-Level: X-Spam-Status: No, score=-9.664 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPDhWuG2K2mt for ; Tue, 3 Nov 2009 03:29:54 -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 E861C3A68D1 for ; Tue, 3 Nov 2009 03:29:53 -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: Aj4AAI6i70qQ/uCWe2dsb2JhbACCJywhmGEBAQsLJAapc5dgAoQ7BA X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="scan'208,217";a="53485273" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 11:30:12 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3BU6iY017881 for ; Tue, 3 Nov 2009 11:30:12 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:30:08 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:30:07 +0100 Message-Id: From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-58--232271173 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 12:30:02 +0100 References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 11:30:07.0460 (UTC) FILETIME=[FED3BA40:01CA5C78] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:29:55 -0000 --Apple-Mail-58--232271173 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On Nov 3, 2009, at 11:28 AM, Mathilde Durvy (mdurvy) wrote: > Hi All, > > Section 5.9.1 says > "When the scan is complete, the preferred parent is elected and > self's rank is computed as the preferred parent rank plus the =20= > step > in rank with that parent." > Does this mean that the rank of a node is only based on the rank of =20= > its most preferred parent? > Shouldn't the rank of the node also depend on the non-preferred =20 > parents? > Or is it assumed that the node always forward traffic via its most =20 > preferred parent? A node may indeed choose to send traffic to an alternate parent and =20 not the most preferred. But do you think that this should change the way its computes its rank ? JP. > > Best, > Mathilde > > > Durvy Mathilde > Software Engineer > Technology center > > mdurvy@cisco.com > Phone: +41 21 822 1725 > Mobile: +41 76 396 8116 > > Cisco Systems International S=E0rl > Av. des Uttins, 5 > CH-1180 Rolle > > Cisco home page > > > > Think before you print. > This e-mail may contain confidential and privileged material for the =20= > sole use of the intended recipient. Any review, use, distribution or =20= > disclosure by others is strictly prohibited. If you are not the =20 > intended recipient (or authorized to receive for the recipient), =20 > please contact the sender by reply e-mail and delete all copies of =20 > this message. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-58--232271173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Nov 3, = 2009, at 11:28 AM, Mathilde Durvy (mdurvy) wrote:

=
Hi = All,

 

Section 5.9.1 = says
     "When the = scan is complete, the preferred parent is elected and
      self's = rank is computed as the preferred parent rank plus the step
      in = rank with that parent."
Does this mean that = the rank of a node is only based on the rank of its most preferred = parent?
Shouldn't the rank of the node also = depend on the non-preferred parents?
Or= is it assumed that the node always forward traffic via its most = preferred parent? 


= A node may indeed choose to send traffic to an alternate parent and not = the most preferred.
But do you think that this should change = the way its computes its rank = ?

JP.

 

Best,
Mathilde
 
=
= =

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: = +41 21 822 1725
Mobile: +41 76 396 = 8116

Cisco = Systems International S=E0rl
Av. des Uttins, 5
CH-1180 = Rolle

Cisco home page

 
=
3D"Think Think before you print.
This e-mail may contain = confidential and privileged material for the sole use of the = intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the = intended recipient (or authorized to receive for the recipient), = please contact the sender by reply e-mail and delete all copies = of this = message.

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

= --Apple-Mail-58--232271173-- From mdurvy@cisco.com Tue Nov 3 04:29:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BB83A68E5 for ; Tue, 3 Nov 2009 04:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.361 X-Spam-Level: X-Spam-Status: No, score=-9.361 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkrrUhpj01aw for ; Tue, 3 Nov 2009 04:29:52 -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 569A33A6819 for ; Tue, 3 Nov 2009 04:29:51 -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: Aj4AAKyw70qQ/uCWe2dsb2JhbACCJywhmGEBARYkBqoUl3MChDsE X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208,217";a="53491501" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 12:30:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3CUAul005417 for ; Tue, 3 Nov 2009 12:30:10 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:30:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5C81.62479568" Date: Tue, 3 Nov 2009 13:30:09 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEA162AA@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcpceP83kWm8s9ojSUOYpdaU8Jt1BgABh9Wg References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 03 Nov 2009 12:30:10.0534 (UTC) FILETIME=[626D3060:01CA5C81] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 12:29:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C81.62479568 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 I guess it is ok as long as you ensure that all your parents have rank = lower than yours by other means. This is currently done by reevaluating = all parents when you change your rank. Parents with rank larger than the = node's rank are removed. I don't know why but I add the impression that = at some point we considered all parents in the rank computation, my = mistake probably. =20 Best, Mathilde ________________________________ From: JP Vasseur (jvasseur)=20 Sent: mardi, 3. novembre 2009 12:30 To: Mathilde Durvy (mdurvy) Cc: roll Subject: Re: [Roll] Clarification on the objective function Hi,=20 On Nov 3, 2009, at 11:28 AM, Mathilde Durvy (mdurvy) wrote: =09 Hi All, =20 Section 5.9.1 says "When the scan is complete, the preferred parent is elected and self's rank is computed as the preferred parent rank plus the = step in rank with that parent." Does this mean that the rank of a node is only based on the rank of its = most preferred parent? Shouldn't the rank of the node also depend on the non-preferred = parents? Or is it assumed that the node always forward traffic via its most = preferred parent?=20 =09 A node may indeed choose to send traffic to an alternate parent and not = the most preferred. But do you think that this should change the way its computes its rank ? JP. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you = print. Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CA5C81.62479568 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP,
 
I guess it is ok as long as you ensure that = all your=20 parents have rank lower than yours by other means. This is currently = done by=20 reevaluating all parents when you change your rank. Parents with rank = larger=20 than the node's rank are removed. I don't know why but I add the = impression that=20 at some point we considered all parents in the rank computation, my = mistake=20 probably.
 
Best,
Mathilde

From: JP Vasseur (jvasseur) =
Sent:=20 mardi, 3. novembre 2009 12:30
To: Mathilde Durvy=20 (mdurvy)
Cc: roll
Subject: Re: [Roll] Clarification = on the=20 objective function

Hi,

On Nov 3, 2009, at 11:28 AM, Mathilde Durvy (mdurvy) = wrote:
Hi All,

 

Section 5.9.1 = says
     "When the = scan is=20 complete, the preferred parent is elected and
      = self's rank is=20 computed as the preferred parent rank plus the step
      in = rank with=20 that parent."
Does this mean that the = rank of a=20 node is only based on the rank of its most preferred=20 parent?
Shouldn't the rank of the node also = depend on=20 the non-preferred parents?
Or is it assumed that the node = always forward=20 traffic via its most preferred parent? 


A node may indeed choose to send traffic to an alternate parent and = not the=20 most preferred.
But do you think that this should change the way its computes its = rank=20 ?

JP.

 

Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins,=20 5
CH-1180 Rolle

Cisco home = page

  
Think before you print.This=20 e-mail may contain confidential and privileged material = for the=20 sole use of the intended recipient. Any review, use, = distribution=20 or disclosure by others is strictly prohibited. If you are = not the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
=
 
_______________________________________________Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------_=_NextPart_001_01CA5C81.62479568-- From jabeille@cisco.com Tue Nov 3 08:08:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAE43A659C for ; Tue, 3 Nov 2009 08:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.989 X-Spam-Level: X-Spam-Status: No, score=-7.989 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, 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 nmZrcTm8iUfu for ; Tue, 3 Nov 2009 08:08:21 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BF4C33A69F2 for ; Tue, 3 Nov 2009 08:08:21 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAHvk70qrR7Hu/2dsb2JhbACCJi3ETpgHhD0E X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208,217";a="423823866" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2009 16:08:42 +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 nA3G8J4c015560 for ; Tue, 3 Nov 2009 16:08:42 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:08:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5C9F.E8B04332" Date: Tue, 3 Nov 2009 17:08:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL clarification needed: moving down the DAG Thread-Index: Acpcn+fgsT/e5Ng6SKeByfqwZbLU0w== From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 03 Nov 2009 16:08:40.0802 (UTC) FILETIME=[E8C15420:01CA5C9F] Subject: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Nov 2009 16:08:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C9F.E8B04332 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 when does a node move down a DAG? 5.4.1.4 says a node must not, but if it does it must poison down. so when does it move down? example 1; if node A has two parents, B and C, rank 1 and 2. A rank is 5 (let's say OCP 0 is used) for some reason B is not available anymore, A new rank if it goes with C would be 6. Is A allowed to move to C? =20 Julien ------_=_NextPart_001_01CA5C9F.E8B04332 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
when = does a node=20 move down a DAG? 5.4.1.4 says a node must not, but if it does it must = poison=20 down. so when does it move down?
example 1; if=20 node A has two parents, B and C, rank 1 and 2. A rank is 5 = (let's say=20 OCP 0 is used) for some reason B is not available anymore, A new rank if = it goes=20 with C would be 6. Is A allowed to move to C?
 
Julien
------_=_NextPart_001_01CA5C9F.E8B04332-- From pthubert@cisco.com Tue Nov 3 08:33:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1189E3A6A2C for ; Tue, 3 Nov 2009 08:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.694 X-Spam-Level: X-Spam-Status: No, score=-9.694 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrIzzR72QR9B for ; Tue, 3 Nov 2009 08:33:46 -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 B3E973A6A15 for ; Tue, 3 Nov 2009 08:33:45 -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: AjoAAAvq70qQ/uCWe2dsb2JhbACCJyyZAgEBFiQGqyKYCoQ9BA X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208,217";a="53521755" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 16:34:05 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3GY5gi028810 for ; Tue, 3 Nov 2009 16:34:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:34:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5CA3.753A4995" Date: Tue, 3 Nov 2009 17:34:01 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E0178@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL clarification needed: moving down the DAG Thread-Index: Acpcn+fgsT/e5Ng6SKeByfqwZbLU0wAArPcg References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , X-OriginalArrivalTime: 03 Nov 2009 16:34:05.0559 (UTC) FILETIME=[7594C870:01CA5CA3] Subject: Re: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Nov 2009 16:33:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5CA3.753A4995 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien: =20 The response used to be in early versions, start a small timer that's an order of magnitude longer than RA propagation, and when it elapses, loose memory and do what you like.=20 =20 The Dag Hop Timer being gone down the simplifier sink, we are in a sad situation where the node cannot move down anymore. It has to wait for a new sequence. =20 Maybe this timer was removed a bit too enthusiastically? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: mardi 3 novembre 2009 17:09 To: roll@ietf.org Subject: [Roll] RPL clarification needed: moving down the DAG =20 Hi all, =20 when does a node move down a DAG? 5.4.1.4 says a node must not, but if it does it must poison down. so when does it move down? example 1; if node A has two parents, B and C, rank 1 and 2. A rank is 5 (let's say OCP 0 is used) for some reason B is not available anymore, A new rank if it goes with C would be 6. Is A allowed to move to C? =20 Julien ------_=_NextPart_001_01CA5CA3.753A4995 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien:

 

The response used to be in early versions, start a small = timer that’s an order of magnitude longer than RA propagation, and when it elapses, = loose memory and do what you like.

 

The Dag Hop Timer being gone down the simplifier sink, we = are in a sad situation where the node cannot move down anymore. It has to wait = for a new sequence.

 

Maybe this timer was removed a bit too = enthusiastically?

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: mardi 3 novembre 2009 17:09
To: roll@ietf.org
Subject: [Roll] RPL clarification needed: moving down the = DAG

 

Hi all,

 

when does a node move down a DAG? 5.4.1.4 says a node must not, but if it = does it must poison down. so when does it move down?

example 1; if node A has two parents, B and C, rank 1 and 2. A = rank is 5 (let's say OCP 0 is used) for some reason B is not available anymore, A = new rank if it goes with C would be 6. Is A allowed to move to = C?

 

Julien=

------_=_NextPart_001_01CA5CA3.753A4995-- From pal@cs.stanford.edu Tue Nov 3 11:20:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916833A68A0 for ; Tue, 3 Nov 2009 11:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 bui0UV6BpI00 for ; Tue, 3 Nov 2009 11:20:34 -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 CE5D33A681A for ; Tue, 3 Nov 2009 11:20:34 -0800 (PST) Received: from dnab42209d.stanford.edu ([171.66.32.157]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N5Ow2-0002AH-A9; Tue, 03 Nov 2009 11:20:55 -0800 Message-Id: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 11:20:54 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: roll ROLL Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:20:35 -0000 On Oct 30, 2009, at 6:18 AM, Julien Abeille (jabeille) wrote: > Hi all, > > I am getting headackes with up the tree, to a lower rank, inward vs > down the tree, to a higher rank, outwards. > Could the text only use up and down (direction), higher node, lower > node (nodes/parents), and mention rank only when needed. > This seems like an excellent simplification to me. The one weird thing that occurs is that people often talk about going "up" the tree as towards the root, which is the opposite of a real world tree. E.g., depth first search. So I'd suggest we say Up: towards the root, decreasing rank Down: towards the leaves, increasing rank Higher node: lower rank Lower node: higher rank I think it's important to define higher and lower in terms of Rank since Rank is what's actually used. Otherwise you get into a weird situation comparing disjoint subtrees. Parent -> higher node. Child -> lower node. Thoughts? Phil From pal@cs.stanford.edu Tue Nov 3 11:25:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA2F3A68C8 for ; Tue, 3 Nov 2009 11:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 FhyfFfaQ6VM0 for ; Tue, 3 Nov 2009 11:25:26 -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 13E303A68A0 for ; Tue, 3 Nov 2009 11:25:26 -0800 (PST) Received: from dnab42209d.stanford.edu ([171.66.32.157]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N5P0l-0002PM-2L; Tue, 03 Nov 2009 11:25:47 -0800 Message-Id: <39183443-7F17-4ECE-9DB3-2DE51E78E85A@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 11:25:46 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Nov 2009 19:25:26 -0000 On Nov 2, 2009, at 1:03 PM, JP Vasseur wrote: > Hi, > > On Nov 2, 2009, at 6:00 PM, Julien Abeille (jabeille) wrote: > >> Hi all, >> >> one question: >> when a router receives a DIS, should it answer right away? I guess >> this is a good source of collision, so a random timer would help. >> Could we set T to a random value between I_min /2 and I_Min, >> without resetting I (receiving a DIS does not mean inconsistency)? > > I do not see either why we should reset the trickle timer. The CTP analogy to DIS is the "pull" bit, which allows a node to solicit beacons (the equivalent of DIOs) from neighbors. Hearing a message with the pull bit set resets a node's trickle timer. This causes nearby nodes to send beacons very soon, speeding discovery. I think it makes sense to just reset the trickle timer, rather than trying to introduce special edge cases. Phil From jhui@archrock.com Tue Nov 3 11:49:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F033E3A6896 for ; Tue, 3 Nov 2009 11:49: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=[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 kLdR7Y1khKYn for ; Tue, 3 Nov 2009 11:49:53 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 2967D3A67F0 for ; Tue, 3 Nov 2009 11:49:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 0F40DAF92A; Tue, 3 Nov 2009 11:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqhENVB9PqzB; Tue, 3 Nov 2009 11:50:09 -0800 (PST) Received: from citris-wlan-177-007.AirBears.Berkeley.EDU (eva2ew-136-152-176-0.Net.Berkeley.EDU [136.152.177.253]) by mail.sf.archrock.com (Postfix) with ESMTP id 0B5A9AF83B; Tue, 3 Nov 2009 11:50:09 -0800 (PST) Message-Id: <272863CA-DE23-446D-898B-DC21D34EFD8F@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: <39183443-7F17-4ECE-9DB3-2DE51E78E85A@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 11:50:03 -0800 References: <39183443-7F17-4ECE-9DB3-2DE51E78E85A@cs.stanford.edu> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Nov 2009 19:49:54 -0000 On Nov 3, 2009, at 11:25 AM, Philip Levis wrote: >>> one question: >>> when a router receives a DIS, should it answer right away? I guess >>> this is a good source of collision, so a random timer would help. >>> Could we set T to a random value between I_min /2 and I_Min, >>> without resetting I (receiving a DIS does not mean inconsistency)? >> >> I do not see either why we should reset the trickle timer. > > The CTP analogy to DIS is the "pull" bit, which allows a node to > solicit beacons (the equivalent of DIOs) from neighbors. Hearing a > message with the pull bit set resets a node's trickle timer. This > causes nearby nodes to send beacons very soon, speeding discovery. I > think it makes sense to just reset the trickle timer, rather than > trying to introduce special edge cases. Agreed. Though is the spec clear on whether the DIO is sent unicast or multicast in response to a unicast DIS? Is there a good use case to unicast the DIO response back to the requester? If unicasting a response, setting the Trickle timer is probably not the right approach. But I personally don't think unicast responses are particularly helpful. -- Jonathan Hui From jhui@archrock.com Tue Nov 3 11:57:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F9C3A6892 for ; Tue, 3 Nov 2009 11:57:35 -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 yZwNup7hwo9d for ; Tue, 3 Nov 2009 11:57:32 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id ED0323A6870 for ; Tue, 3 Nov 2009 11:57:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 34DAAAF83B; Tue, 3 Nov 2009 11:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VyI3UnZC5fV; Tue, 3 Nov 2009 11:57:49 -0800 (PST) Received: from citris-wlan-177-007.AirBears.Berkeley.EDU (eva2ew-136-152-176-0.Net.Berkeley.EDU [136.152.177.253]) by mail.sf.archrock.com (Postfix) with ESMTP id 5A111AF926; Tue, 3 Nov 2009 11:57:49 -0800 (PST) Message-Id: <2329EFAA-6392-40BD-B79F-F40F5C3510F7@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 11:57:47 -0800 References: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:57:35 -0000 On Nov 3, 2009, at 11:20 AM, Philip Levis wrote: > This seems like an excellent simplification to me. > > The one weird thing that occurs is that people often talk about > going "up" the tree as towards the root, which is the opposite of a > real world tree. E.g., depth first search. So I'd suggest we say > > Up: towards the root, decreasing rank > Down: towards the leaves, increasing rank > Higher node: lower rank > Lower node: higher rank > > I think it's important to define higher and lower in terms of Rank > since Rank is what's actually used. Otherwise you get into a weird > situation comparing disjoint subtrees. If we want to be precise about the terms, then "sequence number" needs to appear somewhere. For example, A may be "higher" than B because it has a newer sequence number - which trumps any difference in rank. -- Jonathan Hui From sung.lee@us.fujitsu.com Tue Nov 3 12:30:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F19E3A6833 for ; Tue, 3 Nov 2009 12:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, 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 cIi-6SYc8OMG for ; Tue, 3 Nov 2009 12:30:55 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 37EF53A67D3 for ; Tue, 3 Nov 2009 12:30:55 -0800 (PST) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id nA3KVtcU022895; Tue, 3 Nov 2009 12:31:55 -0800 (PST) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id nA3KVtMx022892; Tue, 3 Nov 2009 12:31:55 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.8/8.13.8) with ESMTP id nA3KUtQB015257; Tue, 3 Nov 2009 12:30:55 -0800 (PST) Received: from [10.157.253.51] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id nA3KUsK10170; Tue, 3 Nov 2009 12:30:54 -0800 (PST) Message-ID: <4AF092FE.8070109@us.fujitsu.com> Date: Tue, 03 Nov 2009 15:30:54 -0500 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4AEF6538.5020207@us.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-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: Tue, 03 Nov 2009 20:30:56 -0000 Hi JP, I like the idea of flexible n-bit magic number. Thank you, Sung JP Vasseur wrote: > Hi Sung, > > On Nov 3, 2009, at 12:03 AM, Sung Lee wrote: > >> >>> You're quite right that the results were for a limited topology size. >>> I would vote for making it >>> configurable 3-bit flag that could be adjusted according to the >>> network topology. >> >> JP, >> >> Does this mean that one can have up to 2^3 sibling transmissions >> (configurable parameter)? >> Did I understand you correctly? >> >> This might work and I am willing to take this as an initial point >> although we would evaluate this value further to make sure that this >> is >> adequate number. >> > > The idea would be to make it n bits so indeed you would get 2^n mac > number of sibling hops. > Then you could configure the value of n for each network, possibly > advertise it from the DAG root, .... > > Thanks. > > JP. > >> Thanks. >> Sung >> >> roll-request@ietf.org wrote: >>> Message: 1 >>> Date: Thu, 29 Oct 2009 17:18:26 +0100 >>> From: JP Vasseur >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >>> To: Sung Lee >>> Cc: roll@ietf.org >>> Message-ID: <45049DAF-552D-4D3D-9846-CBA60B77BFF8@cisco.com> >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >>> >>> On Oct 29, 2009, at 5:08 PM, Sung Lee wrote: >>> >>> >>>> Tim and WG members, >>>> >>>> I was reviewing v04 and have some concerns about current proposal. >>>> In particular, the restriction on 2 sibling hops in a row. >>>> >>>> >>>>> 5.11.4. Sibling Loop Avoidance >>>>> >>>>> When a packet is forwarded along siblings, it cannot be checked for >>>>> forward progress and may loop between siblings. Experimental >>>>> evidence has shown that one sibling hop can be very useful but is >>>>> generally sufficient to avoid loops. Based on that evidence, this >>>>> specification enforces the simple rule that a packet may not make 2 >>>>> sibling hops in a row. >>>>> >>>> I recall that the experiment result was presented at the interim >>>> meeting. >>>> However, it was also pointed out that if the selected sibling is not >>>> the >>>> right one, then you risk a packet loss. >>>> If the network topology is simple enough, this may be sufficient >>>> restriction to avoid sibling loops. >>>> Without much coordinated effort of trying to figure out the "right" >>>> next >>>> hop sibling, this simple restriction will cause many packet drops if >>>> the >>>> network topology is complicated. >>>> >>>> My understanding is that ROLL is targeting for a large scale >>>> network. >>>> And I have concerns about this. >>>> I would like to hear about what others think about this. >>>> >>> >>> You're quite right that the results were for a limited topology size. >>> I would vote for making it >>> configurable 3-bit flag that could be adjusted according to the >>> network topology. >>> >>> Thoughts ? >>> >>> JP. >>> >>> >>>> Regards, >>>> Sung >>>> >>>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From Ted.Humpal@jci.com Wed Nov 4 07:26:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B773A67D4; Wed, 4 Nov 2009 07:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[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 yEy5c3JPsBNZ; Wed, 4 Nov 2009 07:26:13 -0800 (PST) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by core3.amsl.com (Postfix) with ESMTP id B66FC3A67B1; Wed, 4 Nov 2009 07:26:12 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKSvGdKKRElKMWY5mM2FK+1ZsbGx4i3hJN@postini.com; Wed, 04 Nov 2009 07:26:35 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009110409270889-3391171 ; Wed, 4 Nov 2009 09:27:08 -0600 In-Reply-To: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> References: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> To: Philip Levis MIME-Version: 1.0 X-KeepSent: 87C7B02D:2CE35099-86257664:0047EEF5; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Ted.Humpal@jci.com Message-ID: Date: Wed, 4 Nov 2009 09:26:10 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/04/2009 09:26:28 AM, Serialize complete at 11/04/2009 09:26:28 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/04/2009 09:27:08 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/04/2009 09:27:15 AM, Serialize complete at 11/04/2009 09:27:15 AM Content-Type: text/html; charset="US-ASCII" Cc: roll ROLL , roll-bounces@ietf.org Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:26:14 -0000
The misunderstanding appears to be created due to the conversion from a physical position to a numeric position.  The LBR is
the reference point for all relative positions.

The higher numeric rank being a relative  position farther from the LBR
the lower the numeric rank being a relative position closer to the LBR

Is a higher rank (numerically or position as physically drawn)  closer to the top?  This depends how in your mind you draw the DAG

For example many people draw a DAG with the LBR  at the top (typical example shown in the rpl-04 document)


                A      (ROOT)   (rank 0)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        B                C     (rank 1)
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
D                E                F     (rank 2)

but when you consider a normal physical tree - the roots  (LBR) of the tree are at the bottom and the leaves are at the top
Should the RPL DAG samples  be drawn with the LBR at the bottom versus the top to avoid this confusion ?

If you use the terms closer to (lower rank)  or further away (higher rank)  from the LBR - the up and down, inward / outward of the DAG is less confusing

Use  the term further from the LBR ( to a relative higher rank device)
Use the term closer to the LBR (to a relative lower rank device)

Outward means further from the LBR  ( to a relative higher rank device)
Inward means closer to the LBR  (to a relative lower rank device)


Ted







From: Philip Levis <pal@cs.stanford.edu>
To: Julien Abeille (jabeille) <jabeille@cisco.com>
Cc: roll ROLL <roll@ietf.org>
Date: 11/03/2009 01:21 PM
Subject: Re: [Roll] terminology





On Oct 30, 2009, at 6:18 AM, Julien Abeille (jabeille) wrote:

> Hi all,
>
> I am getting headackes with up the tree, to a lower rank, inward vs  
> down the tree, to a higher rank, outwards.
> Could the text only use up and down (direction), higher node, lower  
> node (nodes/parents),  and mention rank only when needed.
>

This seems like an excellent simplification to me.

The one weird thing that occurs is that people often talk about going  
"up" the tree as towards the root, which is the opposite of a real  
world tree. E.g., depth first search. So I'd suggest we say

Up: towards the root, decreasing rank
Down: towards the leaves, increasing rank
Higher node: lower rank
Lower node: higher rank

I think it's important to define higher and lower in terms of Rank  
since Rank is what's actually used. Otherwise you get into a weird  
situation comparing disjoint subtrees.

Parent -> higher node.
Child -> lower node.

Thoughts?

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

From jabeille@cisco.com Wed Nov 4 08:35:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFBE3A697D for ; Wed, 4 Nov 2009 08:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.946 X-Spam-Level: X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[AWL=0.653, 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 n+9MuY92z9Sb for ; Wed, 4 Nov 2009 08:35:40 -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 493293A6923 for ; Wed, 4 Nov 2009 08:35:40 -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: AkUAALc88UqQ/uCWe2dsb2JhbACbXQEBFiQGqheYGYQ9BItu X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="53629569" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2009 16:36:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4Ga06c023411; Wed, 4 Nov 2009 16:36:00 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 17:36:00 +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: Wed, 4 Nov 2009 17:35:59 +0100 Message-ID: In-Reply-To: <2329EFAA-6392-40BD-B79F-F40F5C3510F7@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] terminology Thread-Index: AcpcwCR3wfHz9yZKSkeoj0Sw3LhHAwArIMpg References: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu> <2329EFAA-6392-40BD-B79F-F40F5C3510F7@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Philip Levis" X-OriginalArrivalTime: 04 Nov 2009 16:36:00.0618 (UTC) FILETIME=[E49324A0:01CA5D6C] Cc: roll ROLL Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:35:41 -0000 Hi all, I am inline with Philip. Thanks for the precisions by the way.=20 Regarding sequence numbers, for me 2 nodes with 2 different seq numbers are in different DAGs, hence we do not need to compare them as far as height is concerned. Best, Julien > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com]=20 > Sent: mardi 3 novembre 2009 20:58 > To: Philip Levis > Cc: Julien Abeille (jabeille); roll ROLL > Subject: Re: [Roll] terminology >=20 >=20 > On Nov 3, 2009, at 11:20 AM, Philip Levis wrote: >=20 > > This seems like an excellent simplification to me. > > > > The one weird thing that occurs is that people often talk=20 > about going=20 > > "up" the tree as towards the root, which is the opposite of a real=20 > > world tree. E.g., depth first search. So I'd suggest we say > > > > Up: towards the root, decreasing rank > > Down: towards the leaves, increasing rank Higher node: lower rank=20 > > Lower node: higher rank > > > > I think it's important to define higher and lower in terms of Rank=20 > > since Rank is what's actually used. Otherwise you get into a weird=20 > > situation comparing disjoint subtrees. >=20 >=20 > If we want to be precise about the terms, then "sequence=20 > number" needs to appear somewhere. For example, A may be=20 > "higher" than B because it has a newer sequence number -=20 > which trumps any difference in rank. >=20 > -- > Jonathan Hui >=20 >=20 From prvs=5520a81f1=mukul@uwm.edu Wed Nov 4 15:31:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246C93A6A3B for ; Wed, 4 Nov 2009 15:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.561, 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 fe-Exbyn7fa5 for ; Wed, 4 Nov 2009 15:31:45 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 027EF3A6A41 for ; Wed, 4 Nov 2009 15:31:44 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 04 Nov 2009 17:32:06 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6A932C085C8; Wed, 4 Nov 2009 17:32:06 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0b5WM5h3ftx; Wed, 4 Nov 2009 17:32:05 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5CD1AC085A0; Wed, 4 Nov 2009 17:32:05 -0600 (CST) Date: Wed, 4 Nov 2009 17:32:05 -0600 (CST) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <712157059.4176771257377525296.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <714524734.4174721257377138485.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Nov 2009 23:32:04 -0000 Hi Pascal, Julien, Two points: 1. Regarding the scenario Julien listed, A can safely choose C as the most = preferred parent and increase its rank to 6 immediately. The rank increase = can not lead to routing loops if: a) no new parent is selected (as in case of scenario Julien listed; C was a= lready a parent for A) b) a new parent is selected but has a smaller rank (than the node's current= rank; hence it can not be in the node's sub-DAG) 2. Now, lets suppose that new parent (B) has a higher rank than the node's = current rank and is infact in the node's sub-DAG. The node (A) chooses it a= s a parent and consequently increases its rank. Now, we have a routing loop= . But this loop should be quickly resolved if nodes in the loop have altern= ate parents. e.g. in our example, when A increases its rank, its children w= ill kick it out of the parent set if they have alternate parents. It may ca= use an increase in B's rank and hence a further increase in A's rank but we= wont have "count to infinity" situation. We will have "count to infinity" = situation only when nodes in the loop are isolated from rest of the network= . In that case, they will do "count to infinity" and produce lot of DIOs bu= t we should not really care about these nodes (and their DIOs) since they a= re isolated any way. So, perhaps, we should allow a node to freely move down a DAG? Any resultin= g routing loops will be quickly resolved (in order of I_min*(length of loop= ) time). If that is not fast enough, DAG hop timers may be used. Am I missing some thing? Thanks Mukul =20 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , roll@ietf.org Sent: Tuesday, November 3, 2009 10:34:01 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL clarification needed: moving down the DAG Hi Julien:=20 =C2=A0=20 The response used to be in early versions, start a small timer that=E2=80= =99s an order of magnitude longer than RA propagation, and when it elapses,= loose memory and do what you like.=20 =C2=A0=20 The Dag Hop Timer being gone down the simplifier sink, we are in a sad situ= ation where the node cannot move down anymore. It has to wait for a new seq= uence.=20 =C2=A0=20 Maybe this timer was removed a bit too enthusiastically?=20 =C2=A0=20 Pascal=20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jul= ien Abeille (jabeille)=20 Sent: mardi 3 novembre 2009 17:09=20 To: roll@ietf.org=20 Subject: [Roll] RPL clarification needed: moving down the DAG=20 =C2=A0=20 Hi all,=20 =C2=A0=20 when does a node move down a DAG? 5.4.1.4 says a node must not, but if it d= oes it must poison down. so when does it move down?=20 example 1;=C2=A0if node A has=C2=A0two parents, B and C, rank 1 and 2.=C2= =A0A rank is 5 (let's say OCP 0 is used) for some reason B is not available= anymore, A new rank if it goes with C would be 6. Is A allowed to move to = C?=20 =C2=A0=20 Julien=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 5 01:17:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2796628C1AC for ; Thu, 5 Nov 2009 01:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.682 X-Spam-Level: X-Spam-Status: No, score=-9.682 tagged_above=-999 required=5 tests=[AWL=0.917, 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 eqbKv7c9RlIt for ; Thu, 5 Nov 2009 01:17:24 -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 DA6B528C1AB for ; Thu, 5 Nov 2009 01:17:23 -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: AicAABwn8kqQ/uCWe2dsb2JhbACbYAEBFiQGqj6XZoQ9BA X-IronPort-AV: E=Sophos;i="4.44,685,1249257600"; d="scan'208";a="53678200" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2009 09:17:43 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA59Hhcm008426 for ; Thu, 5 Nov 2009 09:17:43 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 10:17:44 +0100 Received: from dhcp-hlb2-vl250-144-254-42-146.cisco.com ([144.254.42.146]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 10:17:43 +0100 Message-Id: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 08:24:52 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Nov 2009 09:17:43.0358 (UTC) FILETIME=[D49975E0:01CA5DF8] Subject: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 09:17:25 -0000 Dear all, /co-chair hat off/ We would welcome your opinion on the following issue: Suppose that a DAG is formed that support OFx. A new node willing to join the DAG does not support OFx but OFy. Note that by OF we actually mean the Objective function and the metric. We have two options here. Option 1: The node simply joins the DAG as a leaf. In order words, the node has connectivity since it joins the DAG but will not act as a router for others since it does not understand the OF. Parent selection could be a simply a "random". Option 2: The node joins the DAG and falls back to the "default" OCP. From there is prolongs the DAG but with OF0 (of course inconsistent metrics are not added). This also means that everynode MUST implement OF0 and that the network may compromise nodes with different OF at some point. Several options even more complex have been discussed where one could use common denominator to get as close as possible to the desired OF, allow a node not to be so "altruistic", ... My personal view is that OF management can quick get fairly complex and hard to manage. Option 1 is extremely simple and easy to manage. If a node is mis-configured (does not support the OF of the DAG) it can join it as a leaf in order to have connectivity and send an alarm to fix its configuration. We now just need to specify OF in some document and this is it. Several of you mentioned that they were leaning toward option 1, but could you please express your opinion, we would like to have it solved for the next revision next week. Thanks. JP. From jabeille@cisco.com Thu Nov 5 01:21:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C92328C1B8 for ; Thu, 5 Nov 2009 01:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=0.634, 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 jYHpTlNX9gAE for ; Thu, 5 Nov 2009 01:21:00 -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 13AA128C1B1 for ; Thu, 5 Nov 2009 01:20:59 -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: AicAAFAo8kqQ/uCWe2dsb2JhbACbYAEBFiQGqlKXaIQ9BA X-IronPort-AV: E=Sophos;i="4.44,685,1249257600"; d="scan'208";a="53678575" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2009 09:21:21 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA59LLno009491 for ; Thu, 5 Nov 2009 09:21:21 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 10:21:21 +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: Thu, 5 Nov 2009 10:21:19 +0100 Message-ID: In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Opinion please Thread-Index: Acpd+NqS7KeydDTlRcuJNTDLcCUPIwAACxzg References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> From: "Julien Abeille (jabeille)" To: "JP Vasseur (jvasseur)" , "roll WG" X-OriginalArrivalTime: 05 Nov 2009 09:21:21.0625 (UTC) FILETIME=[56B25C90:01CA5DF9] Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 09:21:01 -0000 Hi JP, I am for option 1. As you say OF mismatch is a configuration problem, joining as a leaf works fine. I am also not too keen having extra code on a sensor just because the admin did not do a rather simple task properly. Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of JP Vasseur (jvasseur) > Sent: jeudi 5 novembre 2009 08:25 > To: roll WG > Subject: [Roll] Opinion please >=20 > Dear all, >=20 > /co-chair hat off/ >=20 > We would welcome your opinion on the following issue: >=20 > Suppose that a DAG is formed that support OFx. A new node=20 > willing to join the DAG does not support OFx but OFy. Note=20 > that by OF we actually mean the Objective function and the metric. >=20 > We have two options here. >=20 > Option 1: The node simply joins the DAG as a leaf. In order=20 > words, the node has connectivity since it joins the DAG but=20 > will not act as a router for others since it does not=20 > understand the OF. Parent selection could be a simply a "random". >=20 > Option 2: The node joins the DAG and falls back to the=20 > "default" OCP. =20 > From there is prolongs the DAG but with OF0 (of course=20 > inconsistent metrics are not added). This also means that=20 > everynode MUST implement OF0 and that the network may=20 > compromise nodes with different OF at some point. Several=20 > options even more complex have been discussed where one could=20 > use common denominator to get as close as possible to the=20 > desired OF, allow a node not to be so "altruistic", ... >=20 > My personal view is that OF management can quick get fairly=20 > complex and hard to manage. Option 1 is extremely simple and=20 > easy to manage. =20 > If a node is mis-configured (does not support the OF of the=20 > DAG) it can join it as a leaf in order to have connectivity=20 > and send an alarm to fix its configuration. We now just need=20 > to specify OF in some document and this is it. >=20 > Several of you mentioned that they were leaning toward option=20 > 1, but could you please express your opinion, we would like=20 > to have it solved for the next revision next week. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From zach@sensinode.com Thu Nov 5 01:29:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D273A692F for ; Thu, 5 Nov 2009 01:29:38 -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 VClfNuJwnaYN for ; Thu, 5 Nov 2009 01:29:37 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DE3863A68AA for ; Thu, 5 Nov 2009 01:29:36 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA59Tl2s024265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Nov 2009 11:29:47 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> Date: Thu, 5 Nov 2009 11:29:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1076) Cc: roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 09:29:38 -0000 I would prefer Option 1. For all scenarios I have RPL in mind for, =20 there is not a problem in setting the OF. So for exceptions, falling =20 back as a leaf node works fine. Zach On Nov 5, 2009, at 9:24 , JP Vasseur wrote: > Dear all, > > /co-chair hat off/ > > We would welcome your opinion on the following issue: > > Suppose that a DAG is formed that support OFx. A new node willing to =20= > join the DAG does not support OFx but OFy. Note that by OF we =20 > actually mean the Objective function and the metric. > > We have two options here. > > Option 1: The node simply joins the DAG as a leaf. In order words, =20 > the node has connectivity since it joins the DAG but will not act as =20= > a router for others since it does not understand the OF. Parent =20 > selection could be a simply a "random". > > Option 2: The node joins the DAG and falls back to the "default" =20 > OCP. =46rom there is prolongs the DAG but with OF0 (of course =20 > inconsistent metrics are not added). This also means that everynode =20= > MUST implement OF0 and that the network may compromise nodes with =20 > different OF at some point. Several options even more complex have =20 > been discussed where one could use common denominator to get as =20 > close as possible to the desired OF, allow a node not to be so =20 > "altruistic", ... > > My personal view is that OF management can quick get fairly complex =20= > and hard to manage. Option 1 is extremely simple and easy to manage. =20= > If a node is mis-configured (does not support the OF of the DAG) it =20= > can join it as a leaf in order to have connectivity and send an =20 > alarm to fix its configuration. We now just need to specify OF in =20 > some document and this is it. > > Several of you mentioned that they were leaning toward option 1, but =20= > could you please express your opinion, we would like to have it =20 > solved for the next revision next week. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From richard.kelsey@ember.com Thu Nov 5 03:33:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8232828C1B9 for ; Thu, 5 Nov 2009 03:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 aOzqE+Mgi0ZL for ; Thu, 5 Nov 2009 03:33:50 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4FD3B28C0E7 for ; Thu, 5 Nov 2009 03:33:50 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 06:35:34 -0500 Date: Thu, 05 Nov 2009 06:31:16 -0500 Message-Id: <87aaz15htn.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <712157059.4176771257377525296.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 4 Nov 2009 17:32:05 -0600 (CST)) From: Richard Kelsey References: <712157059.4176771257377525296.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 05 Nov 2009 11:35:34.0378 (UTC) FILETIME=[1682F4A0:01CA5E0C] Cc: roll@ietf.org Subject: Re: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 11:33:51 -0000 Date: Wed, 4 Nov 2009 17:32:05 -0600 (CST) From: Mukul Goyal 2. Now, lets suppose that new parent (B) has a higher rank than the node's current rank and is infact in the node's sub-DAG. The node (A) chooses it as a parent and consequently increases its rank. Now, we have a routing loop. [...] We will have "count to infinity" situation only when nodes in the loop are isolated from rest of the network. In that case, they will do "count to infinity" and produce lot of DIOs but we should not really care about these nodes (and their DIOs) since they are isolated any way. Hi Mukul, Remember that there may be multiple DAG instances. Being isolated from one DAG root does not mean that a node has nothing useful to do. It may just mean that it will use a different DAG for the moment. -Richard Kelsey From prvs=5539aefd1=mukul@uwm.edu Thu Nov 5 04:05:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCE03A672E for ; Thu, 5 Nov 2009 04:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, 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 yZ9DwO4B2hIb for ; Thu, 5 Nov 2009 04:05:01 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id E0C173A63C9 for ; Thu, 5 Nov 2009 04:05:00 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 05 Nov 2009 06:05:22 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5AE9BC085A0; Thu, 5 Nov 2009 06:05:22 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIuI5vdnctn8; Thu, 5 Nov 2009 06:05:22 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 31B2EC085C8; Thu, 5 Nov 2009 06:05:22 -0600 (CST) Date: Thu, 5 Nov 2009 06:05:22 -0600 (CST) From: Mukul Goyal To: Richard Kelsey Message-ID: <1806878229.4287551257422722111.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <71100634.4287141257422120695.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 12:05:30 -0000 Hi Richard If the node is in a "count to infinity" situation in DAG1 and is a part of DAG2 as well (or can join DAG2 quickly if it wants to): 1) it will start using DAG2 for packet forwarding once DAG2 becomes more attractive than DAG1. 2) But how does the "count to infinity" the node is doing in DAG1 affect DAG2 otherwise? I can see that frequent generation of DAG1 DIOs by the in-loop DAG1 nodes will cause extra contention for the radio channel, but what else may happen? Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: "Mukul Goyal" Cc: pthubert@cisco.com, roll@ietf.org Sent: Thursday, November 5, 2009 5:31:16 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL clarification needed: moving down the DAG Date: Wed, 4 Nov 2009 17:32:05 -0600 (CST) From: Mukul Goyal 2. Now, lets suppose that new parent (B) has a higher rank than the node's current rank and is infact in the node's sub-DAG. The node (A) chooses it as a parent and consequently increases its rank. Now, we have a routing loop. [...] We will have "count to infinity" situation only when nodes in the loop are isolated from rest of the network. In that case, they will do "count to infinity" and produce lot of DIOs but we should not really care about these nodes (and their DIOs) since they are isolated any way. Hi Mukul, Remember that there may be multiple DAG instances. Being isolated from one DAG root does not mean that a node has nothing useful to do. It may just mean that it will use a different DAG for the moment. -Richard Kelsey From richard.kelsey@ember.com Thu Nov 5 05:59:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047893A69B2 for ; Thu, 5 Nov 2009 05:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 x1lfUwJeGvLv for ; Thu, 5 Nov 2009 05:59:12 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 001143A68DF for ; Thu, 5 Nov 2009 05:59:11 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 09:00:55 -0500 Date: Thu, 05 Nov 2009 08:56:37 -0500 Message-Id: <87639p5b3e.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-OriginalArrivalTime: 05 Nov 2009 14:00:55.0894 (UTC) FILETIME=[64F0AF60:01CA5E20] Cc: roll@ietf.org Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 13:59:13 -0000 Date: Thu, 5 Nov 2009 10:21:19 +0100 From: "Julien Abeille (jabeille)" Hi JP, I am for option 1. As you say OF mismatch is a configuration problem, joining as a leaf works fine. I am also not too keen having extra code on a sensor just because the admin did not do a rather simple task properly. +1 -Richard Kelsey -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: jeudi 5 novembre 2009 08:25 To: roll WG Subject: [Roll] Opinion please Dear all, /co-chair hat off/ We would welcome your opinion on the following issue: Suppose that a DAG is formed that support OFx. A new node willing to join the DAG does not support OFx but OFy. Note that by OF we actually mean the Objective function and the metric. We have two options here. Option 1: The node simply joins the DAG as a leaf. In order words, the node has connectivity since it joins the DAG but will not act as a router for others since it does not understand the OF. Parent selection could be a simply a "random". Option 2: The node joins the DAG and falls back to the "default" OCP. From there is prolongs the DAG but with OF0 (of course inconsistent metrics are not added). This also means that everynode MUST implement OF0 and that the network may compromise nodes with different OF at some point. Several options even more complex have been discussed where one could use common denominator to get as close as possible to the desired OF, allow a node not to be so "altruistic", ... My personal view is that OF management can quick get fairly complex and hard to manage. Option 1 is extremely simple and easy to manage. If a node is mis-configured (does not support the OF of the DAG) it can join it as a leaf in order to have connectivity and send an alarm to fix its configuration. We now just need to specify OF in some document and this is it. Several of you mentioned that they were leaning toward option 1, but could you please express your opinion, we would like to have it solved for the next revision next week. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Thu Nov 5 06:14:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6471D28C1C8 for ; Thu, 5 Nov 2009 06:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6Q71D23-2dE for ; Thu, 5 Nov 2009 06:14:57 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 2BF223A68EE for ; Thu, 5 Nov 2009 06:14:57 -0800 (PST) Received: by yxe30 with SMTP id 30so14236yxe.29 for ; Thu, 05 Nov 2009 06:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=xWiv+LjKW97V9aGv50X5UVEYWjdnSzdbuPsfCu7NBN0=; b=KqRsyx34rzk1IWASHd/Y1zM/jYbVqirusqGmwD1lUadr8aZTpFfzaNlYjb74ZID48e YCLbkyQAEh5Ru+2G6qqPzJEnHlWGuG6TI20vEjtTFhBwcAZvKkQ9E6s6+/OFBfj/+v2I fx5wHEiyWt0O7kYJYdTrZzTw5oRnm0lfdOWE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=wfNra47jAjQP5EMAg5luA43kq7/YpKlf2Lh+pr317OahcNqJOBgTcPa4W7R/BGnGIR /o4PvVto03It7H1TV765WqMCKG+Ceu2PpbXCmK71UIiDuWnzzXGhSO+3QDqGlvkU47oi n1J65S6Dq3eehAHydm7tqwh0IZkXk/HhoQY5k= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.19.4 with SMTP id w4mr6072624agi.0.1257430514121; Thu, 05 Nov 2009 06:15:14 -0800 (PST) In-Reply-To: <87639p5b3e.fsf@kelsey-ws.hq.ember.com> References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <87639p5b3e.fsf@kelsey-ws.hq.ember.com> From: Emmanuel Baccelli Date: Thu, 5 Nov 2009 15:14:54 +0100 X-Google-Sender-Auth: 3c97d24391ab1e2e Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=001485f547901fc23d0477a05b97 Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 14:14:58 -0000 --001485f547901fc23d0477a05b97 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, I also root for option 1. It will indeed make the draft simpler. Actually I already mentionned this subject in my previous email to the list, giving feedback on the overview section (section 3). Emmanuel On Thu, Nov 5, 2009 at 2:56 PM, Richard Kelsey wrote: > Date: Thu, 5 Nov 2009 10:21:19 +0100 > From: "Julien Abeille (jabeille)" > > Hi JP, > > I am for option 1. As you say OF mismatch is a configuration problem, > joining as a leaf works fine. I am also not too keen having extra code > on a sensor just because the admin did not do a rather simple task > properly. > > +1 > -Richard Kelsey > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of JP Vasseur (jvasseur) > Sent: jeudi 5 novembre 2009 08:25 > To: roll WG > Subject: [Roll] Opinion please > > Dear all, > > /co-chair hat off/ > > We would welcome your opinion on the following issue: > > Suppose that a DAG is formed that support OFx. A new node > willing to join the DAG does not support OFx but OFy. Note > that by OF we actually mean the Objective function and the metric. > > We have two options here. > > Option 1: The node simply joins the DAG as a leaf. In order > words, the node has connectivity since it joins the DAG but > will not act as a router for others since it does not > understand the OF. Parent selection could be a simply a "random". > > Option 2: The node joins the DAG and falls back to the > "default" OCP. > From there is prolongs the DAG but with OF0 (of course > inconsistent metrics are not added). This also means that > everynode MUST implement OF0 and that the network may > compromise nodes with different OF at some point. Several > options even more complex have been discussed where one could > use common denominator to get as close as possible to the > desired OF, allow a node not to be so "altruistic", ... > > My personal view is that OF management can quick get fairly > complex and hard to manage. Option 1 is extremely simple and > easy to manage. > If a node is mis-configured (does not support the OF of the > DAG) it can join it as a leaf in order to have connectivity > and send an alarm to fix its configuration. We now just need > to specify OF in some document and this is it. > > Several of you mentioned that they were leaning toward option > 1, but could you please express your opinion, we would like > to have it solved for the next revision next week. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001485f547901fc23d0477a05b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,

I also root for option 1. It will indeed make the draft simpl= er. Actually I already mentionned this subject in my previous email to the = list, giving feedback on the overview section (section 3).

Emmanuel<= br>

On Thu, Nov 5, 2009 at 2:56 PM, Richard = Kelsey <ri= chard.kelsey@ember.com> wrote:
=A0 Date: Thu, 5 Nov 2009 10:21:19 +0100
=A0 From: "Julien Abeille (jabeille)" <jabeille@cisco.com>

=A0 Hi JP,

=A0 I am for option 1. As you say OF mismatch is a configuration problem,<= br> =A0 joining as a leaf works fine. I am also not too keen having extra code=
=A0 on a sensor just because the admin did not do a rather simple task
=A0 properly.

+1
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -Richard Kelsey

-----Original Message-----
From: roll-bounces@ietf.org [m= ailto:roll-bounces@ietf.org] O= n
Behalf Of JP Vasseur (jvasseur)
Sent: jeudi 5 novembre 2009 08:25
To: roll WG
Subject: [Roll] Opinion please

Dear all,

/co-chair hat off/

We would welcome your opinion on the following issue:

Suppose that a DAG is formed that support OFx. A new node
willing to join the DAG does not support OFx but OFy. Note
that by OF we actually mean the Objective function and the metric.

We have two options here.

Option 1: The node simply joins the DAG as a leaf. In order
words, the node has connectivity since it joins the DAG but
will not act as a router for others since it does not
understand the OF. Parent selection could be a simply a "random".=

Option 2: The node joins the DAG and falls back to the
"default" OCP.
=A0From there is prolongs the DAG but with OF0 (of course
inconsistent metrics are not added). This also means that
everynode MUST implement OF0 and that the network may
compromise nodes with different OF at some point. Several
options even more complex have been discussed where one could
use common denominator to get as close as possible to the
desired OF, allow a node not to be so "altruistic", ...

My personal view is that OF management can quick get fairly
complex and hard to manage. Option 1 is extremely simple and
easy to manage.
If a node is mis-configured (does not support the OF of the
DAG) it can join it as a leaf in order to have connectivity
and send an alarm to fix its configuration. We now just need
to specify OF in some document and this is it.

Several of you mentioned that they were leaning toward option
1, but could you please express your opinion, we would like
to have it solved for the next revision next week.

Thanks.

JP.

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--001485f547901fc23d0477a05b97-- From trac@tools.ietf.org Thu Nov 5 08:39:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C0A3A6851 for ; Thu, 5 Nov 2009 08:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwDptmioZtoZ for ; Thu, 5 Nov 2009 08:39:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C61DE3A67E4 for ; Thu, 5 Nov 2009 08:39:48 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N65NX-0007iS-QM; Thu, 05 Nov 2009 08:40:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Nov 2009 16:40:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/6#comment:1 Message-ID: <064.cecd0fa8e94be1422ea8dfc6d6108b71@tools.ietf.org> References: <055.82953fb7ca07ae4f993dd45d9f020003@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.82953fb7ca07ae4f993dd45d9f020003@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #6: Multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:39:49 -0000 #6: Multicast DAO --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * owner: wintert@… => pal@… -- Ticket URL: roll From trac@tools.ietf.org Thu Nov 5 08:41:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CBB3A6851 for ; Thu, 5 Nov 2009 08:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH1ynmoMT7mN for ; Thu, 5 Nov 2009 08:41:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E63CF3A67E4 for ; Thu, 5 Nov 2009 08:41:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N65Ot-0000Dn-US; Thu, 05 Nov 2009 08:41:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Nov 2009 16:41:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/10#comment:1 Message-ID: <064.009135438222ddf17c0646a90b2e9314@tools.ietf.org> References: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:41:09 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * owner: wintert@… => jpv@… -- Ticket URL: roll From trac@tools.ietf.org Thu Nov 5 08:41:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE4A3A6AEA for ; Thu, 5 Nov 2009 08:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uahAnx+r2BCv for ; Thu, 5 Nov 2009 08:41:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id AA3283A6851 for ; Thu, 5 Nov 2009 08:41:44 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N65PT-0001E7-Dq; Thu, 05 Nov 2009 08:42:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Nov 2009 16:42:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/7#comment:1 Message-ID: <064.4a86de8109aa1f73127f7f00a859bb9d@tools.ietf.org> References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:41:45 -0000 #7: RPL bootstrap question: neighbor cache and DIOs dependency --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * owner: wintert@… => pal@… -- Ticket URL: roll From trac@tools.ietf.org Thu Nov 5 08:54:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6C63A6B30 for ; Thu, 5 Nov 2009 08:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEt3zO6K9w1W for ; Thu, 5 Nov 2009 08:54:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4E97D3A6B2B for ; Thu, 5 Nov 2009 08:54:00 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N65bL-0005Pp-B3; Thu, 05 Nov 2009 08:54:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Nov 2009 16:54:23 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/13 Message-ID: <055.bff47a20859521b2716856f3268f0b1d@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #13: Terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:54:01 -0000 #13: Terminology --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Update the document to use a consistent terminology - today the terminology inward becomes UP (towards to root) outward becomes DOWN -- Ticket URL: roll From pal@cs.stanford.edu Thu Nov 5 09:56:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AD43A6B4A for ; Thu, 5 Nov 2009 09:56:14 -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 NaZ0p4C1Im1z for ; Thu, 5 Nov 2009 09:56:14 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2719D3A6B4B for ; Thu, 5 Nov 2009 09:56:14 -0800 (PST) Received: from evans-wlan-180-66.airbears.berkeley.edu ([136.152.180.66]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N66ZY-00040K-Qt; Thu, 05 Nov 2009 09:56:37 -0800 Message-Id: From: Philip Levis To: roll@ietf.org In-Reply-To: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 09:56:31 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 17:56:14 -0000 On Oct 29, 2009, at 5:02 AM, roll issue tracker wrote: > #7: RPL bootstrap question: neighbor cache and DIOs dependency > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=85 | Owner: wintert@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > Email =46rom Julien > > Hi all, > > as explained in section 5.4.2 of RPL, a DIO must not be processed if =20= > the > source is not in the neighbor cache. The question is how do we =20 > expect the > neighbor cache to be filled? The current proposal is to change the direction of specification. Rather than state a node MUST NOT process a DIO if the SRC is not a =20 candidate neighbor, the document will state that a node MUST process a =20= DIO if the SRC is a candidate neighbor. This rewording also removes =20 the problem of a node ignoring DIOs. Does anyone think this is not a good fix? What are people's opinions? Phil= From ietf-roll@mulligan.org Thu Nov 5 10:14:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EB428C220 for ; Thu, 5 Nov 2009 10:14:13 -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 f0GXjF5M6GuM for ; Thu, 5 Nov 2009 10:14:12 -0800 (PST) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id A5F0F28C21B for ; Thu, 5 Nov 2009 10:14:12 -0800 (PST) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id CF8B5A109E; Thu, 5 Nov 2009 11:14:41 -0700 (MST) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiScIRRAGAYy; Thu, 5 Nov 2009 11:14:40 -0700 (MST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 161B9A10B0; Thu, 5 Nov 2009 11:14:40 -0700 (MST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id nA5IEXsB017720; Thu, 5 Nov 2009 11:14:33 -0700 (MST) From: Geoff Mulligan To: JP Vasseur In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> Content-Type: text/plain Date: Thu, 05 Nov 2009 11:14:26 -0700 Message-Id: <1257444866.3637.7634.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 18:14:13 -0000 I support option 1. The node has connectivity and we don't have to complicate the code on all of the nodes. geoff On Thu, 2009-11-05 at 08:24 +0100, JP Vasseur wrote: > Dear all, > > /co-chair hat off/ > > We would welcome your opinion on the following issue: > > Suppose that a DAG is formed that support OFx. A new node willing to > join the DAG does not support OFx but OFy. Note that by OF we actually > mean the Objective function and the metric. > > We have two options here. > > Option 1: The node simply joins the DAG as a leaf. In order words, the > node has connectivity since it joins the DAG but will not act as a > router for others since it does not understand the OF. Parent > selection could be a simply a "random". > > Option 2: The node joins the DAG and falls back to the "default" OCP. > From there is prolongs the DAG but with OF0 (of course inconsistent > metrics are not added). This also means that everynode MUST implement > OF0 and that the network may compromise nodes with different OF at > some point. Several options even more complex have been discussed > where one could use common denominator to get as close as possible to > the desired OF, allow a node not to be so "altruistic", ... > > My personal view is that OF management can quick get fairly complex > and hard to manage. Option 1 is extremely simple and easy to manage. > If a node is mis-configured (does not support the OF of the DAG) it > can join it as a leaf in order to have connectivity and send an alarm > to fix its configuration. We now just need to specify OF in some > document and this is it. > > Several of you mentioned that they were leaning toward option 1, but > could you please express your opinion, we would like to have it solved > for the next revision next week. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@marajade.sandelman.ca Thu Nov 5 10:24:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BEE3A69EC for ; Thu, 5 Nov 2009 10:24:48 -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 0Uw6EeHX5GXx for ; Thu, 5 Nov 2009 10:24:47 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 76E5E3A67B1 for ; Thu, 5 Nov 2009 10:24:47 -0800 (PST) Received: from sandelman.ottawa.on.ca (ottawa-hs-64-26-148-238.d-ip.magma.ca [64.26.148.238]) by relay.sandelman.ca (Postfix) with ESMTPS id 0AEA2342CF; Thu, 5 Nov 2009 13:15:50 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 6CAFC4E78C; Thu, 5 Nov 2009 13:25:07 -0500 (EST) From: Michael Richardson To: Geoff Mulligan In-Reply-To: <1257444866.3637.7634.camel@dellx1> References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <1257444866.3637.7634.camel@dellx1> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 05 Nov 2009 13:25:07 -0500 Message-ID: <21961.1257445507@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 18:24:48 -0000 >>>>> "Geoff" == Geoff Mulligan writes: Geoff> I support option 1. The node has connectivity and we don't Geoff> have to complicate the code on all of the nodes. I think I agree. It's a MUST --- node connects. If it doesn't connect, operator can not ask it why it isn't acting as a router! Option 2, could be a MAY. Connectivity for downstreams nodes is only affected if the node is only way to get connected. The downstream nodes can compromise on OF0, or get no connectivity --- that's their local decision. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Pete.Stpierre@Sun.COM Thu Nov 5 10:28:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BFF3A6B4E for ; Thu, 5 Nov 2009 10:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GOXNPbBWS2Zz for ; Thu, 5 Nov 2009 10:28:58 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 3A7313A69EC for ; Thu, 5 Nov 2009 10:28:55 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA5ITHCt023370 for ; Thu, 5 Nov 2009 10:29:18 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_d8nF/YGgKV6BeuUUp6LD+g)" Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSN00200ETDQW00@fe-sfbay-10.sun.com> for roll@ietf.org; Thu, 05 Nov 2009 10:29:17 -0800 (PST) Received: from dhcp-069-053.sfbay.sunlabs.com (dyn53.sunlabs.com [204.153.12.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSN00KR1FCLQL40@fe-sfbay-10.sun.com>; Thu, 05 Nov 2009 10:29:09 -0800 (PST) Date: Thu, 05 Nov 2009 10:29:09 -0800 From: "Pete St. Pierre" In-reply-to: <1257444866.3637.7634.camel@dellx1> Sender: Pete.Stpierre@Sun.COM To: JP Vasseur Message-id: <3A2D7798-CBA7-4C9A-9813-9B6029C1D5FA@Sun.COM> X-Mailer: Apple Mail (2.935.3) References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <1257444866.3637.7634.camel@dellx1> Cc: ROLL WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 18:28:59 -0000 --Boundary_(ID_d8nF/YGgKV6BeuUUp6LD+g) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT Option 1 looks appropriate to me. At this point I think simple is good. ...Pete > > On Thu, 2009-11-05 at 08:24 +0100, JP Vasseur wrote: >> Dear all, >> >> /co-chair hat off/ >> >> We would welcome your opinion on the following issue: >> >> Suppose that a DAG is formed that support OFx. A new node willing to >> join the DAG does not support OFx but OFy. Note that by OF we >> actually >> mean the Objective function and the metric. >> >> We have two options here. >> >> Option 1: The node simply joins the DAG as a leaf. In order words, >> the >> node has connectivity since it joins the DAG but will not act as a >> router for others since it does not understand the OF. Parent >> selection could be a simply a "random". >> >> Option 2: The node joins the DAG and falls back to the "default" OCP. >> From there is prolongs the DAG but with OF0 (of course inconsistent >> metrics are not added). This also means that everynode MUST implement >> OF0 and that the network may compromise nodes with different OF at >> some point. Several options even more complex have been discussed >> where one could use common denominator to get as close as possible to >> the desired OF, allow a node not to be so "altruistic", ... >> >> My personal view is that OF management can quick get fairly complex >> and hard to manage. Option 1 is extremely simple and easy to manage. >> If a node is mis-configured (does not support the OF of the DAG) it >> can join it as a leaf in order to have connectivity and send an alarm >> to fix its configuration. We now just need to specify OF in some >> document and this is it. >> >> Several of you mentioned that they were leaning toward option 1, but >> could you please express your opinion, we would like to have it >> solved >> for the next revision next week. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Boundary_(ID_d8nF/YGgKV6BeuUUp6LD+g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE
Option 1 looks appropr= iate to me.  At this point I think simple is good.
...Pete
 

On Thu, 2009-11-05 at 08:24 +0100, JP Vasseur wrote:
Dear all,

/co-chair hat off/
=

We would welcome your opinion on the following issue:

Suppose that a DAG is formed that support OFx. A new no= de willing to  
join t= he DAG does not support OFx but OFy. Note that by OF we actually &nbs= p;
mean the Objective funct= ion and the metric.

We have two options here.

Option 1: The node simply joins the DAG as a leaf. In order= words, the  
node has= connectivity since it joins the DAG but will not act as a  
=
router for others since it doe= s not understand the OF. Parent  
selection could be a simply a "random".
<= blockquote type=3D"cite">
O= ption 2: The node joins the DAG and falls back to the "default" OCP. =  
From there is prolo= ngs the DAG but with OF0 (of course inconsistent  
metrics are not added). This also means = that everynode MUST implement  
OF0 and that the network may compromise nodes with differen= t OF at  
some point. = Several options even more complex have been discussed  
where one could use common denomina= tor to get as close as possible to  
the desired OF, allow a node not to be so "altruistic"= , ...

My personal view is that OF management can quic= k get fairly complex  
and hard to manage. Option 1 is extremely simple and easy to manage.=  
If a node is mis-co= nfigured (does not support the OF of the DAG) it  
can join it as a leaf in order to have c= onnectivity and send an alarm  
to fix its configuration. We now just need to specify OF in= some  
document and t= his is it.

Several of you mentioned that they were le= aning toward option 1, but  
could you please express your opinion, we would like to hav= e it solved  
for the = next revision next week.
Thanks.

JP.<= br>

_______________________________________________
Roll mailing list
Roll@iet= f.org
https://www.ietf.org/mailman/li= stinfo/roll

_________________________________= ______________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Boundary_(ID_d8nF/YGgKV6BeuUUp6LD+g)-- From jhui@archrock.com Thu Nov 5 10:33:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E352028C23C for ; Thu, 5 Nov 2009 10:33:56 -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 4lppKJSLFGF5 for ; Thu, 5 Nov 2009 10:33:56 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E4FCC28C223 for ; Thu, 5 Nov 2009 10:32:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A70BA4C4D21; Thu, 5 Nov 2009 10:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiSZF+uSCE0x; Thu, 5 Nov 2009 10:32:24 -0800 (PST) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 54505AF93A; Thu, 5 Nov 2009 10:32:24 -0800 (PST) Message-Id: <11044C25-35A6-4F43-BDDA-F552E31A33AF@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 10:32:22 -0800 References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 18:33:57 -0000 I prefer option 1. -- Jonathan Hui On Nov 4, 2009, at 11:24 PM, JP Vasseur wrote: > Dear all, > > /co-chair hat off/ > > We would welcome your opinion on the following issue: > > Suppose that a DAG is formed that support OFx. A new node willing to > join the DAG does not support OFx but OFy. Note that by OF we > actually mean the Objective function and the metric. > > We have two options here. > > Option 1: The node simply joins the DAG as a leaf. In order words, > the node has connectivity since it joins the DAG but will not act as > a router for others since it does not understand the OF. Parent > selection could be a simply a "random". > > Option 2: The node joins the DAG and falls back to the "default" > OCP. From there is prolongs the DAG but with OF0 (of course > inconsistent metrics are not added). This also means that everynode > MUST implement OF0 and that the network may compromise nodes with > different OF at some point. Several options even more complex have > been discussed where one could use common denominator to get as > close as possible to the desired OF, allow a node not to be so > "altruistic", ... > > My personal view is that OF management can quick get fairly complex > and hard to manage. Option 1 is extremely simple and easy to manage. > If a node is mis-configured (does not support the OF of the DAG) it > can join it as a leaf in order to have connectivity and send an > alarm to fix its configuration. We now just need to specify OF in > some document and this is it. > > Several of you mentioned that they were leaning toward option 1, but > could you please express your opinion, we would like to have it > solved for the next revision next week. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@marajade.sandelman.ca Thu Nov 5 10:36:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E539728C0E1 for ; Thu, 5 Nov 2009 10:36:54 -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 j0vTugLhw2tU for ; Thu, 5 Nov 2009 10:36:54 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DB60B28C220 for ; Thu, 5 Nov 2009 10:36:34 -0800 (PST) Received: from sandelman.ottawa.on.ca (ottawa-hs-64-26-148-238.d-ip.magma.ca [64.26.148.238]) by relay.sandelman.ca (Postfix) with ESMTPS id 84199342CF for ; Thu, 5 Nov 2009 13:27:38 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 92C254E78C for ; Thu, 5 Nov 2009 13:36:56 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: <4AEE180B.8040805@acm.org> References: <4AEE180B.8040805@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 05 Nov 2009 13:36:56 -0500 Message-ID: <22763.1257446216@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:36:55 -0000 >>>>> "Tim" == Tim Winter writes: Tim> Yes, the draft-ietf-roll-routing-metrics-03 suggests that the Tim> metrics may exceed 255 bytes, and so the DIO suboption for DAG Tim> Metric Container drives the overall requirements for suboption Tim> length. Tim> If we use 16bits for length, maybe 1 byte is `wasted' to Tim> specify a short ( < 255 bytes) option. Tim> If we use 8bits for length in units of 8bytes, only one byte is Tim> used for suboption length in all cases, so the second byte is Tim> saved. But the suboption itself must pad for [0-7] bytes to Tim> meet the 8 byte boundary. In the first case, 0 byte of padding Tim> is required, one byte is saved from encoding the suboption Tim> length, and one byte is saved overall. In the second case, 1 Tim> byte of padding is used and one byte is saved from the Tim> suboption length, breaking even. In the 6 other cases, more Tim> bytes are used for padding than are saved in encoding the Tim> suboption length. Tim> We don't know anything yet about a typical distribution of Tim> lengths for suboptions, in particular the DAG Metric Container. Tim> So perhaps this discussion could be premature. But, given that Tim> in the 8byte encoding case we use more bytes in 6/8 of the Tim> possible cases, my opinion is that it is better to stick with a Tim> 16-bit suboption length in units of bytes. I say either 8bits in units of 8bytes, or 16 bits in byte units. I somewhat favour the second one (16-bits). If the second, then one of the options that we should consider is the "compress" option, which would contain many options. Otherwise, we may want to consider use of the IPCOMP header in constrained situations. This may well simply solve the problem. I propose that this is premature optimization. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Thu Nov 5 10:39:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BF63A68E0 for ; Thu, 5 Nov 2009 10:39:47 -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 8kwQCA-6OTAQ for ; Thu, 5 Nov 2009 10:39:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0005528C0F2 for ; Thu, 5 Nov 2009 10:39:44 -0800 (PST) Received: from sandelman.ottawa.on.ca (ottawa-hs-64-26-148-238.d-ip.magma.ca [64.26.148.238]) by relay.sandelman.ca (Postfix) with ESMTPS id AFC2F342CF for ; Thu, 5 Nov 2009 13:30:48 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 56A804E78C for ; Thu, 5 Nov 2009 13:40:06 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: References: <4AEE180B.8040805@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 05 Nov 2009 13:40:06 -0500 Message-ID: <22981.1257446406@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:39:47 -0000 >>>>> "Julien" == Julien Abeille <(jabeille)" > writes: Julien> Some suboptions should be moved to options (separate thread, Julien> DIO base option is not optional hence should not be an Julien> option. Makes sense?). Julien> General related question: for the cases where we need Julien> suboptions (metric container), do we want suboptions to be 8 Julien> bytes aligned? Or only options should be 8 bytes aligned? Our options and suboptions should be identical. We should also not re-invent the wheel. It should either replicate the IPv6 extension header (if that's what we want), or should replicate another protocol, e.g. radius(RFC2865): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- .... A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jhui@archrock.com Thu Nov 5 10:48:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B9F28C10F for ; Thu, 5 Nov 2009 10:48:26 -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 On1TV0SAfoQY for ; Thu, 5 Nov 2009 10:48:26 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id EDC453A63EB for ; Thu, 5 Nov 2009 10:48:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C425DAF974; Thu, 5 Nov 2009 10:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhwUfWDhEGCH; Thu, 5 Nov 2009 10:48:44 -0800 (PST) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id A0FE4AF93A; Thu, 5 Nov 2009 10:48:43 -0800 (PST) Message-Id: <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 10:48:42 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 18:48:26 -0000 On Nov 5, 2009, at 9:56 AM, Philip Levis wrote: > On Oct 29, 2009, at 5:02 AM, roll issue tracker wrote: > >> #7: RPL bootstrap question: neighbor cache and DIOs dependency >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> Email =46rom Julien >> >> Hi all, >> >> as explained in section 5.4.2 of RPL, a DIO must not be processed =20 >> if the >> source is not in the neighbor cache. The question is how do we =20 >> expect the >> neighbor cache to be filled? > > The current proposal is to change the direction of specification. > > Rather than state a node MUST NOT process a DIO if the SRC is not a =20= > candidate neighbor, the document will state that a node MUST process =20= > a DIO if the SRC is a candidate neighbor. This rewording also =20 > removes the problem of a node ignoring DIOs. > > Does anyone think this is not a good fix? What are people's opinions? I agree that Rule 2 of 5.4.2 is problematic. Though, after your =20 proposed fix, I'm not sure Rule 2 provides any value. I would propose =20= to simply strike Rule 2 from 5.4.2. I think the real issue is with the "candidate neighbor" abstraction. =20= Currently, as specified, candidate neighbor and DAG parent selection =20 are independent processes. These processes should be more coupled. =20 For example, it is useful to also consider routing information =20 contained within the DIO to determine if a neighbor should be a =20 candidate neighbor. -- Jonathan Hui From Jerald.P.Martocci@jci.com Thu Nov 5 11:22:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CA23A69DE; Thu, 5 Nov 2009 11:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LksdVYJW0Zrs; Thu, 5 Nov 2009 11:22:55 -0800 (PST) Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by core3.amsl.com (Postfix) with ESMTP id 601373A69A4; Thu, 5 Nov 2009 11:22:54 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKSvMmJMQIS2B2dyvbrkVMqDAdHt1qsUzh@postini.com; Thu, 05 Nov 2009 11:23:17 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009110513250585-2257512 ; Thu, 5 Nov 2009 13:25:05 -0600 In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 5 Nov 2009 13:23:07 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/05/2009 01:23:12 PM, Serialize complete at 11/05/2009 01:23:12 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2009 01:25:05 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2009 01:25:10 PM, Serialize complete at 11/05/2009 01:25:10 PM Content-Type: multipart/alternative; boundary="=_alternative 006A7CD186257665_=" Cc: roll WG , roll-bounces@ietf.org Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 19:22:56 -0000 This is a multipart message in MIME format. --=_alternative 006A7CD186257665_= Content-Type: text/plain; charset="US-ASCII" I pick Option 1 under duress. I certainly favor the simplicity of Option 1 over Option 2; however last week we also had an Option 3 which was my favorite - that being that the node simply does not join the DAG. Option 1 as described, indicates that the node joins the DAG as a leaf node. My question is - how does a node even know it's a leaf node? My understanding is that DAG children know their parents, but DAG parents do not know who their children are or even if they have children. If there is a way to know that a node is a leaf node, then what does it do to maintain its status of a leaf node; that is not allowing other nodes to attach to it in the future as children? If someone can help me understand these mechanics, I will change my vote. Thanks, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 11/05/2009 03:17 AM To roll WG cc Subject [Roll] Opinion please Dear all, /co-chair hat off/ We would welcome your opinion on the following issue: Suppose that a DAG is formed that support OFx. A new node willing to join the DAG does not support OFx but OFy. Note that by OF we actually mean the Objective function and the metric. We have two options here. Option 1: The node simply joins the DAG as a leaf. In order words, the node has connectivity since it joins the DAG but will not act as a router for others since it does not understand the OF. Parent selection could be a simply a "random". Option 2: The node joins the DAG and falls back to the "default" OCP. From there is prolongs the DAG but with OF0 (of course inconsistent metrics are not added). This also means that everynode MUST implement OF0 and that the network may compromise nodes with different OF at some point. Several options even more complex have been discussed where one could use common denominator to get as close as possible to the desired OF, allow a node not to be so "altruistic", ... My personal view is that OF management can quick get fairly complex and hard to manage. Option 1 is extremely simple and easy to manage. If a node is mis-configured (does not support the OF of the DAG) it can join it as a leaf in order to have connectivity and send an alarm to fix its configuration. We now just need to specify OF in some document and this is it. Several of you mentioned that they were leaning toward option 1, but could you please express your opinion, we would like to have it solved for the next revision next week. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006A7CD186257665_= Content-Type: text/html; charset="US-ASCII"
I pick Option 1 under duress.

I certainly favor the simplicity of Option 1 over Option 2; however last week we also had an Option 3 which was my favorite - that being that the node simply does not join the DAG.  Option 1 as described, indicates that the node joins the DAG as a leaf node.  My question is - how does a node even know it's a leaf node?  My understanding is that DAG children know their parents, but DAG parents do not know who their children are or even if they have children.  If there is a way to know that a node is a leaf node, then what does it do to maintain its status of a leaf node; that is not allowing other nodes to attach to it in the future as children?  

If someone can help me understand these mechanics, I will change my vote.

Thanks,

Jerry






JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

11/05/2009 03:17 AM

To
roll WG <roll@ietf.org>
cc
Subject
[Roll] Opinion please





Dear all,

/co-chair hat off/

We would welcome your opinion on the following issue:

Suppose that a DAG is formed that support OFx. A new node willing to  
join the DAG does not support OFx but OFy. Note that by OF we actually  
mean the Objective function and the metric.

We have two options here.

Option 1: The node simply joins the DAG as a leaf. In order words, the  
node has connectivity since it joins the DAG but will not act as a  
router for others since it does not understand the OF. Parent  
selection could be a simply a "random".

Option 2: The node joins the DAG and falls back to the "default" OCP.  
From there is prolongs the DAG but with OF0 (of course inconsistent  
metrics are not added). This also means that everynode MUST implement  
OF0 and that the network may compromise nodes with different OF at  
some point. Several options even more complex have been discussed  
where one could use common denominator to get as close as possible to  
the desired OF, allow a node not to be so "altruistic", ...

My personal view is that OF management can quick get fairly complex  
and hard to manage. Option 1 is extremely simple and easy to manage.  
If a node is mis-configured (does not support the OF of the DAG) it  
can join it as a leaf in order to have connectivity and send an alarm  
to fix its configuration. We now just need to specify OF in some  
document and this is it.

Several of you mentioned that they were leaning toward option 1, but  
could you please express your opinion, we would like to have it solved  
for the next revision next week.

Thanks.

JP.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006A7CD186257665_=-- From pal@cs.stanford.edu Thu Nov 5 11:24:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CACC28C0E1 for ; Thu, 5 Nov 2009 11:24:39 -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 GkKq894pRqV9 for ; Thu, 5 Nov 2009 11:24:38 -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 262CB3A6994 for ; Thu, 5 Nov 2009 11:24:38 -0800 (PST) Received: from ne-campus-wlan-168-127.airbears.berkeley.edu ([136.152.168.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N67x5-0005Wh-5p; Thu, 05 Nov 2009 11:24:59 -0800 Message-Id: From: Philip Levis To: Jonathan Hui In-Reply-To: <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 11:24:58 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: bf2d39bfc2650c7e8471b46ddb5f48c6 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 19:24:39 -0000 On Nov 5, 2009, at 10:48 AM, Jonathan Hui wrote: >> > > > I agree that Rule 2 of 5.4.2 is problematic. Though, after your > proposed fix, I'm not sure Rule 2 provides any value. I would > propose to simply strike Rule 2 from 5.4.2. > > I think the real issue is with the "candidate neighbor" > abstraction. Currently, as specified, candidate neighbor and DAG > parent selection are independent processes. These processes should > be more coupled. For example, it is useful to also consider routing > information contained within the DIO to determine if a neighbor > should be a candidate neighbor. I agree. Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to know if implementers feel this makes things clearer. In this text, the neighbor set is an unconstrained set of L2 neighbors, the parent set is a subset of the neighbor set and is the set of candidate parents, and the parent is the element of the parent set that is the current next hop towards the DAG root. Note that this text discards the sibling notion for the simpler notion of limited local repair. 5.2 Neighbors, Parents, and Rank If Neighbor Unreachability Detection (NUD) determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node a neighbor when calculating and advertising routes until the node determines it is reachable again. Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless it has neighbors who have advertised that DAG ID. A RPL node that has issued a DIO for a DAGID I, DAG Instance N, and sequence number S MUST NOT consider neighbors for I,N whose last heard DIO for I,N had a sequence number < S. 5.2.1 Parents By definition, DAG Roots do not have any DAG parents. RPL nodes that are not roots MAY maintain multiple candidate DAG parents for a single DAG Instance. The set of candidate DAG parents MUST be a subset of the set of neighbors. At any given moment, a node has a single DAG Parent, selected from the set of candidate DAG parents. 5.2.2 DAG Rank DAG Rank is not a cost metric, although its value is derived from and influenced by route cost metrics. Rank is used to avoid and detect loops. A node's Rank MUST be higher than the Rank of its DAG Parent. The exact calculation of the Rank may depend on the set of candidate DAG parents, link metrics, node configuration, and the DAG Instance OF. 5.3. DAG Discovery and Maintenance DAG discovery forms a Directed Acyclic Graph towards a DAG Root by identifying a set of candidate DAG parents and selecting a member of the set as its DAG parent. DAG discovery also discovers neighbors, which may be used to provide additional path diversity when a node needs to move downward in the DAG. DAG discovery avoids loops by constraining when and how nodes can increase their Rank. RPL uses an IPv6 optional header in data packets to detect loops. 5.3.1. DAGs 1. A node MAY belong to multiple DAG Instances. 2. A DAGID, InstanceID, and DAGSequence number uniquely defines a DAG iteration. All of a node's candidate parents within a DAG instance MUST belong to the same DAG iteration: the last heard DIO from candidate parents must be for the same DAG iteration. 3. Within a given DAG instance, a node that is a not a root MUST NOT advertise a DAGSequenceNumber higher than the highest DAGSequenceNumber it has heard. 4. The DAGSequenceNumbers a node advertises for a DAG instance MUST monotonically increase, barring wrap-around as covered in X. 5. DAG Roots MAY increment the sequence number they advertise. 6. A node MUST advertise the same DAGSequenceNumber as its DAG Parent. 5.3.2. DAG Roots 1. A DAG Root that does not have Internet connectivity to nodes outside the DAG MUST NOT set the Grounded bit. 2. A DAG Root MUST advertise a rank of ROOT_RANK. 5.3.3. Rank and DAG Movement 1. A node MUST NOT advertise a Rank less than or equal to its DAG parent. 2. A node MAY advertise a Rank lower than its prior advertisement. 3. A node MAY advertise a Rank higher than its prior advertisement. If the lowest prior Rank advertised for a DAG iteration is L, a node MUST NOT advertise a Rank > L + DAGMaxRankIncrease. 4. A node MAY, at any time, choose to join a different DAG within a DAG Instance. Such a join has no Rank restrictions. Until a node transmits a DIO indicating its new position, it MUST forward packets along the previous DAG. 5. Joining different DAGs does not preclude rule 3. A node that leaves a DAG iteration and rejoins it later must still obey rule 3 for that DAG iteration. 5.3.4 Parent Set Depletion 1. If a node has no candidate parents, it MAY leave the DAG iteration and advertise itself as the root of a floating DAG. Such a DIO MUST have the same DAG InstanceID as the DAG iteration and a cleared Grounded flag. 2. If a node does not form a floating DAG, then the node MUST advertise a rank of INFINITE_RANK within the DAG iteration. 3. If a node that receives a DIO from one of its DAG parents indicating that the parent has left the DAG, it may either follow that parent or stay in its current DAG through an alternate DAG parent if that is possible. 5.4. DIO Message Communication When an DIO message is received from a source device named SRC, the receiving node must first determine whether or not the DIO message should be accepted for further processing, and subsequently present the DIO message for further processing if eligible. 5.4.1. Determination of Eligibility for DIO Processing If the DIO source is a member of the candidate neighbor set, the node MUST process it. 5.4.2. DIO Message Processing When a node processes a DIO from a member of its candidate neighbor set, it MUST update all relevant state maintained on that neighbor. For example, if a node receives a DIO advertising a different Rank, it must update its state to denote the neighbor's new Rank. 5.4.3. DIO Transmission Each node maintains a timer that governs when to multicast DIO messages. This timer is a trickle timer, as detailed in Section 5.X. The DIO Configuration Option describes the configuration of a DAG Instance's trickle timer. o When a node chooses a DAG parent that changes its DAG iteration, it MUST reset the trickle timer to its minimum value. o When a node receives a packet to forward from a node with a lower or equal rank, it has detected an inconsistency in the DAG. In this case, the node MUST reset the trickle timer to its minimum value. Section Y describes how a node can detect this. o When a node receives a DIS, it MUST reset the trickle timer to the minimum value. o If a node is not a member of a DAG, it MAY suppress transmitting DIO messages. From sdhags@gmail.com Thu Nov 5 12:17:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03A73A69E5 for ; Thu, 5 Nov 2009 12:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVjSdhgq17kd for ; Thu, 5 Nov 2009 12:17:31 -0800 (PST) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 08BDD3A69CF for ; Thu, 5 Nov 2009 12:17:30 -0800 (PST) Received: by vws14 with SMTP id 14so155929vws.32 for ; Thu, 05 Nov 2009 12:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=stfBc+t1OPhKx9s8Co6s1mLHTCpT515ULSKrqJESm5E=; b=OMDF4NfdT7sbpC4kSC27J7ykfLKSs+w8KdC7etW2QpgRDXXzAIq0g/B3iVUwIiwVUw pi2xManQD5vIe+2+kha/5acu71p9uq07uJmVkOOcA//GeLyKUsDjk7tfnFWLF4244Av+ i+Ig69JJFisXHECZqVr/osVMJIcNkKCIO/OTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oifmR/NyJd5rDfts4XEE9Sw9XypmABmaYd01n9gLMUw5zyzBrQSqEn8pvx5pLDyxtn Q8Nygs8RGXeKiGY7L5RUh9H5UVdBRjH14TySclz2aHPZcWTMEegoawSFdIlyuKp9uPlX R24MHs1bF6PWA2Pi55WAB2WR7TrBEz5r44peQ= MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.220.126.165 with SMTP id c37mr4048481vcs.76.1257452270301; Thu, 05 Nov 2009 12:17:50 -0800 (PST) In-Reply-To: References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> Date: Thu, 5 Nov 2009 12:17:50 -0800 X-Google-Sender-Auth: 48ba442bc41f4987 Message-ID: <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> From: Stephen Dawson-Haggerty To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 20:17:32 -0000 In general it's a lot shorter and easier to understand, which is great. Was is this a replacement or an addition? A lot of mechanical text was removed and I don't know if it's intentional (like in 5.4.2, when it enumerated when you would discard a message)-- the new one seems a little more vague about who I'm supposed to store in my candidate parent sets (5.2) Also, we lost some of the text explaining why you might want to increment the dag sequence number (it's split between 5.4.3, 5.3.3, and 5.3.1). I would have appreciated a sentence towards the beginning something like "The effect of incrementing the DAG sequence number is to trigger additional DIO transmissions. This serves as an implementation-controlled mechanism to rebuild forwarding tables among members of a DAG instance". Neither document does a great job of explaining the role of the neighbor set in forwarding, in particular I couldn't find a place where it said that you might try multiple parents for the same packet. Thanks, Steve On Thu, Nov 5, 2009 at 11:24 AM, Philip Levis wrote: > On Nov 5, 2009, at 10:48 AM, Jonathan Hui wrote: > >>> >> >> >> I agree that Rule 2 of 5.4.2 is problematic. =A0Though, after your propo= sed >> fix, I'm not sure Rule 2 provides any value. =A0I would propose to simpl= y >> strike Rule 2 from 5.4.2. >> >> I think the real issue is with the "candidate neighbor" abstraction. >> =A0Currently, as specified, candidate neighbor and DAG parent selection = are >> independent processes. =A0These processes should be more coupled. =A0For >> example, it is useful to also consider routing information contained wit= hin >> the DIO to determine if a neighbor should be a candidate neighbor. > > I agree. > > Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to know if > implementers feel this makes things clearer. In this text, the neighbor s= et > is an unconstrained set of L2 neighbors, the parent set is a subset of th= e > neighbor set and is the set of candidate parents, and the parent is the > element of the parent set that is the current next hop towards the DAG ro= ot. > Note that this text discards the sibling notion for the simpler notion of > limited local repair. > > 5.2 Neighbors, Parents, and Rank > > =A0If Neighbor Unreachability Detection (NUD) determines that a > =A0neighbor is no longer reachable, then a RPL node > =A0MUST NOT consider this node a neighbor when calculating and > =A0advertising routes until the node determines it is reachable again. > > =A0Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless > =A0it has =A0neighbors who have advertised that DAG ID. > > =A0A RPL node that has issued a DIO for a DAGID I, DAG Instance N, > =A0and sequence number S MUST NOT consider neighbors for I,N whose > =A0last heard DIO for I,N had a sequence number < S. > > =A05.2.1 Parents > > =A0By definition, DAG Roots do not have any DAG parents. > > =A0RPL nodes that are not roots MAY maintain multiple candidate > =A0DAG parents for a single DAG Instance. The set of candidate DAG > =A0parents MUST be a subset of the set of neighbors. At any given > =A0moment, a node has a single DAG Parent, selected from the set > =A0of candidate DAG parents. > > =A05.2.2 =A0DAG Rank > > =A0DAG Rank is not a cost metric, although its value is derived from > =A0and influenced by route cost metrics. Rank is used to avoid and > =A0detect loops. A node's Rank MUST be higher than the Rank of its DAG > =A0Parent. The exact calculation of the Rank may depend on the set of > =A0candidate DAG parents, link metrics, node configuration, and the DAG > =A0Instance OF. > > 5.3. =A0DAG Discovery and Maintenance > > =A0DAG discovery forms a Directed Acyclic Graph towards a DAG Root > =A0by identifying a set of candidate DAG parents and selecting a member > =A0of the set as its DAG parent. DAG discovery also discovers neighbors, > =A0which may be used to provide additional path diversity when a node > =A0needs to move downward in the DAG. DAG discovery avoids > =A0loops by constraining when and how nodes can increase their Rank. > =A0RPL uses an IPv6 optional header in data packets to detect loops. > > 5.3.1. =A0DAGs > > =A01. =A0A node MAY belong to multiple DAG Instances. > > =A02. =A0A DAGID, InstanceID, and DAGSequence number uniquely defines > =A0 =A0 a DAG iteration. All of a node's candidate parents within a DAG > =A0 =A0 instance MUST belong to the same DAG iteration: the last heard > =A0 =A0 DIO from candidate parents must be for the same DAG iteration. > > =A03. =A0Within a given DAG instance, a node that is a not a root MUST NO= T > =A0 =A0 advertise a DAGSequenceNumber higher than the highest > =A0 =A0 DAGSequenceNumber it has heard. > > =A04. =A0The DAGSequenceNumbers a node advertises for a DAG instance MUST > =A0 =A0 monotonically increase, barring wrap-around as covered in X. > > =A05. =A0DAG Roots MAY increment the sequence number they advertise. > > =A06. =A0A node MUST advertise the same DAGSequenceNumber as its > =A0 =A0 DAG Parent. > > 5.3.2. =A0DAG Roots > > =A01. =A0A DAG Root that does not have Internet connectivity to nodes > =A0 =A0 outside the DAG MUST NOT set the Grounded bit. > > =A02. =A0A DAG Root MUST advertise a rank of ROOT_RANK. > > 5.3.3. =A0Rank and DAG Movement > > =A01. =A0A node MUST NOT advertise a Rank less than or equal to > =A0 =A0 its DAG parent. > > =A02. =A0A node MAY advertise a Rank lower than its prior advertisement. > > =A03. =A0A node MAY advertise a Rank higher than its prior advertisement. > =A0 =A0 If the lowest prior Rank advertised for a DAG iteration is L, a > =A0 =A0 node MUST NOT advertise a Rank > L + DAGMaxRankIncrease. > > =A04. =A0A node MAY, at any time, choose to join a different DAG within > =A0 =A0 a DAG Instance. Such a join has no Rank restrictions. Until a > =A0 =A0 node transmits a DIO indicating its new position, it MUST forward > =A0 =A0 packets along the previous DAG. > > =A05. =A0Joining different DAGs does not preclude rule 3. A node that lea= ves > =A0 =A0 a DAG iteration and rejoins it later must still obey rule 3 for t= hat > =A0 =A0 DAG iteration. > > 5.3.4 Parent Set Depletion > > =A01. =A0If a node has no candidate parents, it MAY leave the DAG iterati= on and > =A0 =A0 advertise itself as the root of a floating DAG. Such a DIO > =A0 =A0 MUST have the same DAG InstanceID as the DAG iteration and a clea= red > =A0 =A0 Grounded flag. > > =A02. =A0If a node does not form a floating DAG, then the node MUST adver= tise > =A0 =A0 a rank of INFINITE_RANK within the DAG iteration. > > =A03. =A0If a node that receives a DIO from one of its DAG parents > =A0 =A0 indicating that the parent has left the DAG, it may either follow > =A0 =A0 that parent or stay in its current DAG through an alternate DAG > =A0 =A0 parent if that is possible. > > > 5.4. =A0DIO Message Communication > > =A0When an DIO message is received from a source device named SRC, the > =A0receiving node must first determine whether or not the DIO message > =A0should be accepted for further processing, and subsequently present > =A0the DIO message for further processing if eligible. > > 5.4.1. =A0Determination of Eligibility for DIO Processing > > =A0If the DIO source is a member of the candidate neighbor set, > =A0the node MUST process it. > > 5.4.2. =A0DIO Message Processing > > =A0When a node processes a DIO from a member of its candidate neighbor > =A0set, it MUST update all relevant state maintained on that neighbor. > =A0For example, if a node receives a DIO advertising a different Rank, > =A0it must update its state to denote the neighbor's new Rank. > > 5.4.3. =A0DIO Transmission > > =A0Each node maintains a timer that governs when to multicast DIO > =A0messages. =A0This timer is a trickle timer, as detailed in Section 5.X= . > =A0The DIO Configuration Option describes the configuration of a DAG > Instance's > =A0trickle timer. > > =A0o =A0When a node chooses a DAG parent that changes its DAG iteration, > =A0 =A0it MUST reset the trickle timer to its minimum value. > > =A0o =A0When a node receives a packet to forward from a node with a lower= or > =A0 =A0equal rank, it has detected an inconsistency in the DAG. In this > =A0 =A0case, the node MUST reset the trickle timer to its minimum value. > =A0 =A0Section Y describes how a node can detect this. > > =A0o =A0When a node receives a DIS, it MUST reset the trickle timer to > =A0 =A0the minimum value. > > =A0o =A0If a node is not a member of a DAG, it MAY suppress transmitting > =A0 =A0DIO messages. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From jhui@archrock.com Thu Nov 5 12:30:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758893A69BA for ; Thu, 5 Nov 2009 12:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 IWVj2wdTosFf for ; Thu, 5 Nov 2009 12:30:51 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 219733A6970 for ; Thu, 5 Nov 2009 12:30:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 054FFAF978; Thu, 5 Nov 2009 12:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxkmPnrQK3jk; Thu, 5 Nov 2009 12:31:09 -0800 (PST) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id D6456AF974; Thu, 5 Nov 2009 12:31:08 -0800 (PST) Message-Id: From: Jonathan Hui To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 12:31:07 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 20:30:52 -0000 On Nov 5, 2009, at 11:24 AM, Philip Levis wrote: > Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to > know if implementers feel this makes things clearer. In this text, > the neighbor set is an unconstrained set of L2 neighbors, the parent > set is a subset of the neighbor set and is the set of candidate > parents, and the parent is the element of the parent set that is the > current next hop towards the DAG root. Note that this text discards > the sibling notion for the simpler notion of limited local repair. This text is definitely moving in the right direction. > 5.2 Neighbors, Parents, and Rank > > If Neighbor Unreachability Detection (NUD) determines that a > neighbor is no longer reachable, then a RPL node > MUST NOT consider this node a neighbor when calculating and > advertising routes until the node determines it is reachable again. > > Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless > it has neighbors who have advertised that DAG ID. > > A RPL node that has issued a DIO for a DAGID I, DAG Instance N, > and sequence number S MUST NOT consider neighbors for I,N whose > last heard DIO for I,N had a sequence number < S. I'd change "MUST NOT consider neighbors" to "MUST NOT consider nodes as neighbors", or some other wording that cannot be misinterpreted as "MUST NOT process messages from neighbors". > 5.2.1 Parents > > By definition, DAG Roots do not have any DAG parents. > > RPL nodes that are not roots MAY maintain multiple candidate > DAG parents for a single DAG Instance. The set of candidate DAG > parents MUST be a subset of the set of neighbors. At any given > moment, a node has a single DAG Parent, selected from the set > of candidate DAG parents. Not sure why we have to single out THE DAG parent. The DAG is a DAG because a node can maintain more than one candidate parent. Choosing a candidate parent is what defines the forwarding (not routing) topology. More related to this subject below. > 5.2.2 DAG Rank > > DAG Rank is not a cost metric, although its value is derived from > and influenced by route cost metrics. Rank is used to avoid and > detect loops. A node's Rank MUST be higher than the Rank of its DAG > Parent. The exact calculation of the Rank may depend on the set of > candidate DAG parents, link metrics, node configuration, and the DAG > Instance OF. I'd say that the advertised Rank MUST be higher than the Rank of its candidate DAG parents, not just the a chosen DAG parent. We use the DAG to identify assign nodes relative position within the network. It doesn't make sense to have a candidate DAG parent that has a higher Rank. > 5.3. DAG Discovery and Maintenance > > DAG discovery forms a Directed Acyclic Graph towards a DAG Root > by identifying a set of candidate DAG parents and selecting a member > of the set as its DAG parent. DAG discovery also discovers neighbors, > which may be used to provide additional path diversity when a node > needs to move downward in the DAG. DAG discovery avoids > loops by constraining when and how nodes can increase their Rank. > RPL uses an IPv6 optional header in data packets to detect loops. > > 5.3.1. DAGs > > 1. A node MAY belong to multiple DAG Instances. > > 2. A DAGID, InstanceID, and DAGSequence number uniquely defines > a DAG iteration. All of a node's candidate parents within a DAG > instance MUST belong to the same DAG iteration: the last heard > DIO from candidate parents must be for the same DAG iteration. Why not allow a node advertising DAG sequence N forward to a node with DAG sequence N+1? Communication delays means that we can't guarantee that this won't happen. So why restrict it even when we know this is true? > 3. Within a given DAG instance, a node that is a not a root MUST NOT > advertise a DAGSequenceNumber higher than the highest > DAGSequenceNumber it has heard. > > 4. The DAGSequenceNumbers a node advertises for a DAG instance MUST > monotonically increase, barring wrap-around as covered in X. > > 5. DAG Roots MAY increment the sequence number they advertise. > > 6. A node MUST advertise the same DAGSequenceNumber as its > DAG Parent. Or at least what it thinks the DAGSequenceNumber is for its DAG Parent. This comes back to my previous point - when a new sequence number is propagating, nodes will (temporarily) have parents in one iteration, and others in another iteration. I don't think we should restrict implementations from waiting for some time to wait for its DAG parents to catch up to the current iteration - but I don't think we should recommend it either. The rest looks good to me. -- Jonathan Hui > 5.3.2. DAG Roots > > 1. A DAG Root that does not have Internet connectivity to nodes > outside the DAG MUST NOT set the Grounded bit. > > 2. A DAG Root MUST advertise a rank of ROOT_RANK. > > 5.3.3. Rank and DAG Movement > > 1. A node MUST NOT advertise a Rank less than or equal to > its DAG parent. > > 2. A node MAY advertise a Rank lower than its prior advertisement. > > 3. A node MAY advertise a Rank higher than its prior advertisement. > If the lowest prior Rank advertised for a DAG iteration is L, a > node MUST NOT advertise a Rank > L + DAGMaxRankIncrease. > > 4. A node MAY, at any time, choose to join a different DAG within > a DAG Instance. Such a join has no Rank restrictions. Until a > node transmits a DIO indicating its new position, it MUST forward > packets along the previous DAG. > > 5. Joining different DAGs does not preclude rule 3. A node that > leaves > a DAG iteration and rejoins it later must still obey rule 3 for > that > DAG iteration. > > 5.3.4 Parent Set Depletion > > 1. If a node has no candidate parents, it MAY leave the DAG > iteration and > advertise itself as the root of a floating DAG. Such a DIO > MUST have the same DAG InstanceID as the DAG iteration and a > cleared > Grounded flag. > > 2. If a node does not form a floating DAG, then the node MUST > advertise > a rank of INFINITE_RANK within the DAG iteration. > > 3. If a node that receives a DIO from one of its DAG parents > indicating that the parent has left the DAG, it may either follow > that parent or stay in its current DAG through an alternate DAG > parent if that is possible. > > > 5.4. DIO Message Communication > > When an DIO message is received from a source device named SRC, the > receiving node must first determine whether or not the DIO message > should be accepted for further processing, and subsequently present > the DIO message for further processing if eligible. > > 5.4.1. Determination of Eligibility for DIO Processing > > If the DIO source is a member of the candidate neighbor set, > the node MUST process it. > > 5.4.2. DIO Message Processing > > When a node processes a DIO from a member of its candidate neighbor > set, it MUST update all relevant state maintained on that neighbor. > For example, if a node receives a DIO advertising a different Rank, > it must update its state to denote the neighbor's new Rank. > > 5.4.3. DIO Transmission > > Each node maintains a timer that governs when to multicast DIO > messages. This timer is a trickle timer, as detailed in Section 5.X. > The DIO Configuration Option describes the configuration of a DAG > Instance's > trickle timer. > > o When a node chooses a DAG parent that changes its DAG iteration, > it MUST reset the trickle timer to its minimum value. > > o When a node receives a packet to forward from a node with a lower > or > equal rank, it has detected an inconsistency in the DAG. In this > case, the node MUST reset the trickle timer to its minimum value. > Section Y describes how a node can detect this. > > o When a node receives a DIS, it MUST reset the trickle timer to > the minimum value. > > o If a node is not a member of a DAG, it MAY suppress transmitting > DIO messages. > From mcr@marajade.sandelman.ca Thu Nov 5 12:32:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B1A3A6A06 for ; Thu, 5 Nov 2009 12:32:22 -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 xGoo+FC54fa6 for ; Thu, 5 Nov 2009 12:32:21 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 58FB03A6A05 for ; Thu, 5 Nov 2009 12:32:21 -0800 (PST) Received: from sandelman.ottawa.on.ca (ottawa-hs-64-26-148-238.d-ip.magma.ca [64.26.148.238]) by relay.sandelman.ca (Postfix) with ESMTPS id 37E56342CC for ; Thu, 5 Nov 2009 15:23:25 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E14104E78C for ; Thu, 5 Nov 2009 15:32:42 -0500 (EST) From: Michael Richardson To: roll WG In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 05 Nov 2009 15:32:42 -0500 Message-ID: <7412.1257453162@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 20:32:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 {again, you emailed roll-bounces@ietf.org. Fix your MUA} >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I pick Option 1 under duress. Jerald> I certainly favor the simplicity of Option 1 over Option 2; Jerald> however last week we also had an Option 3 which was my Jerald> favorite - that being that the node simply does not join the Jerald> DAG. Option 1 as described, indicates that the node joins Jerald> the DAG as a leaf node. My question is - how does a node Jerald> even know it's a leaf node? My understanding is that DAG It knows it's a left node because it knows that it failed to find a compatible OFy. When it's a leaf node, it does not process the DIOs that it receives, and does not forward that information (list of prefixes, etc.) to it's parent. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvM2Z4CLcPvd0N1lAQKEdwgAhbOWEoqizWQgrdHrf/D/coMkbI04bSyb NYm+8ETMmT0SjLRh4tFdmE8aRuRaMLQZCjGTdEY0bDJ8u4/PlYfCUBpzZCkQOBjF XM4QsItdNOpY5YkxjBgmHCflL4uy8awQ1h528x+ZXnwr+1upJ7iAfE0eLzoYhBLE mnOZ9WqTuGSyzaPS7r8a1QTuwtIdvHtbZWQ7r1yJ8O6RyjKHSxPk06sCYfPlGUgu TF4DHqz9SANsvBiP8XH5yoQsb4tKS1v7QlXAzFqlLxE9Fk9/Cd8LzrA7H/3jryVb wEZSBnYrWSu4yFuda4jQhqrWmSdWpK1ikvdMIDH3hW3Hl+kA4FCRAg== =H9R2 -----END PGP SIGNATURE----- From jhui@archrock.com Thu Nov 5 12:37:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC573A68C8 for ; Thu, 5 Nov 2009 12:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 3xe2676WhTsD for ; Thu, 5 Nov 2009 12:37:42 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 569813A6889 for ; Thu, 5 Nov 2009 12:37:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 3DC4BAF989; Thu, 5 Nov 2009 12:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tgbVm6guPRX; Thu, 5 Nov 2009 12:38:01 -0800 (PST) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 74CD6AF97A; Thu, 5 Nov 2009 12:38:00 -0800 (PST) Message-Id: From: Jonathan Hui To: Stephen Dawson-Haggerty In-Reply-To: <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 12:37:58 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 20:37:43 -0000 Hi Stephen, Your observations reflect a current debate on how much to specify. On one hand, we want to specify a minimial architecture that will provide the flexibility to incorporate and evaluate new mechanisms. On the other hand, we want something that will work "well" out of the box. The issues permeate the entire document (use of hold-up/hold-down timers, backtracking on DA errors, utilization of sibling links, selecting neighbors, selecting candidates, etc.). The issue of "what is enough" is fairly deep and I hope we can come to some common ground on this issue in Hiroshima. -- Jonathan Hui On Nov 5, 2009, at 12:17 PM, Stephen Dawson-Haggerty wrote: > In general it's a lot shorter and easier to understand, which is > great. Was is this a replacement or an addition? A lot of mechanical > text was removed and I don't know if it's intentional (like in 5.4.2, > when it enumerated when you would discard a message)-- the new one > seems a little more vague about who I'm supposed to store in my > candidate parent sets (5.2) > > Also, we lost some of the text explaining why you might want to > increment the dag sequence number (it's split between 5.4.3, 5.3.3, > and 5.3.1). I would have appreciated a sentence towards the beginning > something like "The effect of incrementing the DAG sequence number is > to trigger additional DIO transmissions. This serves as an > implementation-controlled mechanism to rebuild forwarding tables among > members of a DAG instance". > > Neither document does a great job of explaining the role of the > neighbor set in forwarding, in particular I couldn't find a place > where it said that you might try multiple parents for the same packet. > > Thanks, > Steve > > On Thu, Nov 5, 2009 at 11:24 AM, Philip Levis > wrote: >> On Nov 5, 2009, at 10:48 AM, Jonathan Hui wrote: >> >>>> >>> >>> >>> I agree that Rule 2 of 5.4.2 is problematic. Though, after your >>> proposed >>> fix, I'm not sure Rule 2 provides any value. I would propose to >>> simply >>> strike Rule 2 from 5.4.2. >>> >>> I think the real issue is with the "candidate neighbor" abstraction. >>> Currently, as specified, candidate neighbor and DAG parent >>> selection are >>> independent processes. These processes should be more coupled. For >>> example, it is useful to also consider routing information >>> contained within >>> the DIO to determine if a neighbor should be a candidate neighbor. >> >> I agree. >> >> Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to >> know if >> implementers feel this makes things clearer. In this text, the >> neighbor set >> is an unconstrained set of L2 neighbors, the parent set is a subset >> of the >> neighbor set and is the set of candidate parents, and the parent is >> the >> element of the parent set that is the current next hop towards the >> DAG root. >> Note that this text discards the sibling notion for the simpler >> notion of >> limited local repair. >> >> 5.2 Neighbors, Parents, and Rank >> >> If Neighbor Unreachability Detection (NUD) determines that a >> neighbor is no longer reachable, then a RPL node >> MUST NOT consider this node a neighbor when calculating and >> advertising routes until the node determines it is reachable again. >> >> Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless >> it has neighbors who have advertised that DAG ID. >> >> A RPL node that has issued a DIO for a DAGID I, DAG Instance N, >> and sequence number S MUST NOT consider neighbors for I,N whose >> last heard DIO for I,N had a sequence number < S. >> >> 5.2.1 Parents >> >> By definition, DAG Roots do not have any DAG parents. >> >> RPL nodes that are not roots MAY maintain multiple candidate >> DAG parents for a single DAG Instance. The set of candidate DAG >> parents MUST be a subset of the set of neighbors. At any given >> moment, a node has a single DAG Parent, selected from the set >> of candidate DAG parents. >> >> 5.2.2 DAG Rank >> >> DAG Rank is not a cost metric, although its value is derived from >> and influenced by route cost metrics. Rank is used to avoid and >> detect loops. A node's Rank MUST be higher than the Rank of its DAG >> Parent. The exact calculation of the Rank may depend on the set of >> candidate DAG parents, link metrics, node configuration, and the DAG >> Instance OF. >> >> 5.3. DAG Discovery and Maintenance >> >> DAG discovery forms a Directed Acyclic Graph towards a DAG Root >> by identifying a set of candidate DAG parents and selecting a member >> of the set as its DAG parent. DAG discovery also discovers >> neighbors, >> which may be used to provide additional path diversity when a node >> needs to move downward in the DAG. DAG discovery avoids >> loops by constraining when and how nodes can increase their Rank. >> RPL uses an IPv6 optional header in data packets to detect loops. >> >> 5.3.1. DAGs >> >> 1. A node MAY belong to multiple DAG Instances. >> >> 2. A DAGID, InstanceID, and DAGSequence number uniquely defines >> a DAG iteration. All of a node's candidate parents within a DAG >> instance MUST belong to the same DAG iteration: the last heard >> DIO from candidate parents must be for the same DAG iteration. >> >> 3. Within a given DAG instance, a node that is a not a root MUST >> NOT >> advertise a DAGSequenceNumber higher than the highest >> DAGSequenceNumber it has heard. >> >> 4. The DAGSequenceNumbers a node advertises for a DAG instance MUST >> monotonically increase, barring wrap-around as covered in X. >> >> 5. DAG Roots MAY increment the sequence number they advertise. >> >> 6. A node MUST advertise the same DAGSequenceNumber as its >> DAG Parent. >> >> 5.3.2. DAG Roots >> >> 1. A DAG Root that does not have Internet connectivity to nodes >> outside the DAG MUST NOT set the Grounded bit. >> >> 2. A DAG Root MUST advertise a rank of ROOT_RANK. >> >> 5.3.3. Rank and DAG Movement >> >> 1. A node MUST NOT advertise a Rank less than or equal to >> its DAG parent. >> >> 2. A node MAY advertise a Rank lower than its prior advertisement. >> >> 3. A node MAY advertise a Rank higher than its prior advertisement. >> If the lowest prior Rank advertised for a DAG iteration is L, a >> node MUST NOT advertise a Rank > L + DAGMaxRankIncrease. >> >> 4. A node MAY, at any time, choose to join a different DAG within >> a DAG Instance. Such a join has no Rank restrictions. Until a >> node transmits a DIO indicating its new position, it MUST forward >> packets along the previous DAG. >> >> 5. Joining different DAGs does not preclude rule 3. A node that >> leaves >> a DAG iteration and rejoins it later must still obey rule 3 for >> that >> DAG iteration. >> >> 5.3.4 Parent Set Depletion >> >> 1. If a node has no candidate parents, it MAY leave the DAG >> iteration and >> advertise itself as the root of a floating DAG. Such a DIO >> MUST have the same DAG InstanceID as the DAG iteration and a >> cleared >> Grounded flag. >> >> 2. If a node does not form a floating DAG, then the node MUST >> advertise >> a rank of INFINITE_RANK within the DAG iteration. >> >> 3. If a node that receives a DIO from one of its DAG parents >> indicating that the parent has left the DAG, it may either follow >> that parent or stay in its current DAG through an alternate DAG >> parent if that is possible. >> >> >> 5.4. DIO Message Communication >> >> When an DIO message is received from a source device named SRC, the >> receiving node must first determine whether or not the DIO message >> should be accepted for further processing, and subsequently present >> the DIO message for further processing if eligible. >> >> 5.4.1. Determination of Eligibility for DIO Processing >> >> If the DIO source is a member of the candidate neighbor set, >> the node MUST process it. >> >> 5.4.2. DIO Message Processing >> >> When a node processes a DIO from a member of its candidate neighbor >> set, it MUST update all relevant state maintained on that neighbor. >> For example, if a node receives a DIO advertising a different Rank, >> it must update its state to denote the neighbor's new Rank. >> >> 5.4.3. DIO Transmission >> >> Each node maintains a timer that governs when to multicast DIO >> messages. This timer is a trickle timer, as detailed in Section >> 5.X. >> The DIO Configuration Option describes the configuration of a DAG >> Instance's >> trickle timer. >> >> o When a node chooses a DAG parent that changes its DAG iteration, >> it MUST reset the trickle timer to its minimum value. >> >> o When a node receives a packet to forward from a node with a >> lower or >> equal rank, it has detected an inconsistency in the DAG. In this >> case, the node MUST reset the trickle timer to its minimum value. >> Section Y describes how a node can detect this. >> >> o When a node receives a DIS, it MUST reset the trickle timer to >> the minimum value. >> >> o If a node is not a member of a DAG, it MAY suppress transmitting >> DIO messages. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > > -- > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 From pierre.colle@fr.schneider-electric.com Thu Nov 5 13:07:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0D93A682E for ; Thu, 5 Nov 2009 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_60=1, 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 5l58mBdjYO-K for ; Thu, 5 Nov 2009 13:07:30 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id EF2333A677E for ; Thu, 5 Nov 2009 13:07:29 -0800 (PST) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2009110522075123-62498 ; Thu, 5 Nov 2009 22:07:51 +0100 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Thu, 5 Nov 2009 22:07:44 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 05/11/2009 22:07:50, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2009 10:07:51 PM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2009 10:07:54 PM, Serialize complete at 11/05/2009 10:07:54 PM Content-type: multipart/alternative; Boundary="0__=4EBBFCF6DFE796EF8f9e8a93df938690918c4EBBFCF6DFE796EF" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:07:30 -0000 --0__=4EBBFCF6DFE796EF8f9e8a93df938690918c4EBBFCF6DFE796EF Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 04/11/2009 de retour le 06/11/2009. I am currently out of the office. You might contact my manager Didier Pellegrin regarding HOMES project. Best regards, Pierre = --0__=4EBBFCF6DFE796EF8f9e8a93df938690918c4EBBFCF6DFE796EF Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 04/11/2009 de retour le 06/11/200= 9.

I am currently out of the office. You might contact my manager Didier P= ellegrin regarding HOMES project.

Best regards,

Pierre

= --0__=4EBBFCF6DFE796EF8f9e8a93df938690918c4EBBFCF6DFE796EF-- From nicolas.riou@fr.schneider-electric.com Thu Nov 5 14:45:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D963A68F9 for ; Thu, 5 Nov 2009 14:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 k+6v4YFmcnlp for ; Thu, 5 Nov 2009 14:45:09 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 684AB28C139 for ; Thu, 5 Nov 2009 14:45:02 -0800 (PST) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2009110523452488-63238 ; Thu, 5 Nov 2009 23:45:24 +0100 To: roll WG MIME-Version: 1.0 X-KeepSent: 42B36072:59E9739A-C1257665:007BFCEC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Thu, 5 Nov 2009 23:34:40 +0100 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 05/11/2009 23:45:24, Serialize complete at 05/11/2009 23:45:24, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2009 11:45:24 PM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2009 11:45:26 PM, Serialize complete at 11/05/2009 11:45:26 PM Content-Type: multipart/alternative; boundary="=_alternative 007D002BC1257665_=" Subject: [Roll] RE Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 22:45:10 -0000 Message en plusieurs parties au format MIME --=_alternative 007D002BC1257665_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hi JP, I vote for option 1 also to avoid complexity and confusion. Nicolas JP Vasseur =20 Envoy=E9 par : roll-bounces@ietf.org 05/11/2009 08:24 A roll WG cc Objet [Roll] Opinion please Dear all, /co-chair hat off/ We would welcome your opinion on the following issue: Suppose that a DAG is formed that support OFx. A new node willing to=20 join the DAG does not support OFx but OFy. Note that by OF we actually=20 mean the Objective function and the metric. We have two options here. Option 1: The node simply joins the DAG as a leaf. In order words, the=20 node has connectivity since it joins the DAG but will not act as a=20 router for others since it does not understand the OF. Parent=20 selection could be a simply a "random". Option 2: The node joins the DAG and falls back to the "default" OCP.=20 From there is prolongs the DAG but with OF0 (of course inconsistent=20 metrics are not added). This also means that everynode MUST implement=20 OF0 and that the network may compromise nodes with different OF at=20 some point. Several options even more complex have been discussed=20 where one could use common denominator to get as close as possible to=20 the desired OF, allow a node not to be so "altruistic", ... My personal view is that OF management can quick get fairly complex=20 and hard to manage. Option 1 is extremely simple and easy to manage.=20 If a node is mis-configured (does not support the OF of the DAG) it=20 can join it as a leaf in order to have connectivity and send an alarm=20 to fix its configuration. We now just need to specify OF in some=20 document and this is it. Several of you mentioned that they were leaning toward option 1, but=20 could you please express your opinion, we would like to have it solved=20 for the next revision next week. Thanks. JP. =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 =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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F --=_alternative 007D002BC1257665_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi JP,
I vote for option 1 also to avoid complexity and confusi= on.
Nicolas




JP Vasseur <jvasse= ur@cisco.com>
Envoy=E9 par : roll-bounces@ietf.org=

05/11/2009 08:24

A
roll WG <roll@ietf.org>
cc
Objet
[Roll] Opinion please





Dear all,

/co-chair hat off/

We would welcome your opinion on the following issue:

Suppose that a DAG is formed that support OFx. A new node willing to  =
join the DAG does not support OFx but OFy. Note that by OF we actually  
mean the Objective function and the metric.

We have two options here.

Option 1: The node simply joins the DAG as a leaf. In order words, the  
node has connectivity since it joins the DAG but will not act as a   router for others since it does not understand the OF. Parent  
selection could be a simply a "random".

Option 2: The node joins the DAG and falls back to the "default" OCP.  
From there is prolongs the DAG but with OF0 (of course inconsistent  =
metrics are not added). This also means that everynode MUST implement  = ;
OF0 and that the network may compromise nodes with different OF at   some point. Several options even more complex have been discussed  
where one could use common denominator to get as close as possible to  = ;
the desired OF, allow a node not to be so "altruistic", ...

My personal view is that OF management can quick get fairly complex  <= br> and hard to manage. Option 1 is extremely simple and easy to manage.  =
If a node is mis-configured (does not support the OF of the DAG) it  <= br> can join it as a leaf in order to have connectivity and send an alarm  = ;
to fix its configuration. We now just need to specify OF in some  
document and this is it.

Several of you mentioned that they were leaning toward option 1, but  =
could you please express your opinion, we would like to have it solved  
for the next revision next week.

Thanks.

JP.

=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

=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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
This email has been scanned by the MessageLabs Email Security System.
=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=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
--=_alternative 007D002BC1257665_=-- From Jerald.P.Martocci@jci.com Thu Nov 5 15:00:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1643A67E2; Thu, 5 Nov 2009 15:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 LEfc+dgh410K; Thu, 5 Nov 2009 15:00:21 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id E60A13A67D3; Thu, 5 Nov 2009 15:00:20 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSvNZG3JmJXCTp8NDyaLzAUmFwibQhqET@postini.com; Thu, 05 Nov 2009 15:00:44 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009110517023387-2278969 ; Thu, 5 Nov 2009 17:02:33 -0600 In-Reply-To: <7412.1257453162@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 5 Nov 2009 17:00:33 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/05/2009 05:00:39 PM, Serialize complete at 11/05/2009 05:00:39 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2009 05:02:33 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2009 05:02:37 PM, Serialize complete at 11/05/2009 05:02:37 PM Content-Type: multipart/alternative; boundary="=_alternative 007E651D86257665_=" Cc: roll WG , roll-bounces@ietf.org Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Nov 2009 23:00:22 -0000 This is a multipart message in MIME format. --=_alternative 007E651D86257665_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Comments below ... Michael Richardson Sent by: roll-bounces@ietf.org 11/05/2009 02:32 PM To roll WG cc Subject Re: [Roll] Opinion please -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 {again, you emailed roll-bounces@ietf.org. Fix your MUA} >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I pick Option 1 under duress. Jerald> I certainly favor the simplicity of Option 1 over Option 2; Jerald> however last week we also had an Option 3 which was my Jerald> favorite - that being that the node simply does not join the Jerald> DAG. Option 1 as described, indicates that the node joins Jerald> the DAG as a leaf node. My question is - how does a node Jerald> even know it's a leaf node? My understanding is that DAG It knows it's a left node because it knows that it failed to find a compatible OFy. Why is this a discriminator? The node could have other child nodes already attached to itself prior to the node attaching onto the DAG. This set of nodes could all ascribe to the same OFy, yet be different that the OFx of the main DAG. When it's a leaf node, it does not process the DIOs that it receives, and does not forward that information (list of prefixes, etc.) to it's parent. Ok. I assumed that to eliminate newly found children the node would stop sending DIOs. However, I wasn't sure if DIOs are needed to be sent out periodically for other reasons. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvM2Z4CLcPvd0N1lAQKEdwgAhbOWEoqizWQgrdHrf/D/coMkbI04bSyb NYm+8ETMmT0SjLRh4tFdmE8aRuRaMLQZCjGTdEY0bDJ8u4/PlYfCUBpzZCkQOBjF XM4QsItdNOpY5YkxjBgmHCflL4uy8awQ1h528x+ZXnwr+1upJ7iAfE0eLzoYhBLE mnOZ9WqTuGSyzaPS7r8a1QTuwtIdvHtbZWQ7r1yJ8O6RyjKHSxPk06sCYfPlGUgu TF4DHqz9SANsvBiP8XH5yoQsb4tKS1v7QlXAzFqlLxE9Fk9/Cd8LzrA7H/3jryVb wEZSBnYrWSu4yFuda4jQhqrWmSdWpK1ikvdMIDH3hW3Hl+kA4FCRAg== =H9R2 -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007E651D86257665_= Content-Type: text/html; charset="US-ASCII"
Hi Michael,

Comments below ...




Michael Richardson <mcr@sandelman.ca>
Sent by: roll-bounces@ietf.org

11/05/2009 02:32 PM

To
roll WG <roll@ietf.org>
cc
Subject
Re: [Roll] Opinion please





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


{again, you emailed roll-bounces@ietf.org. Fix your MUA}

>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
   Jerald> I pick Option 1 under duress.

   Jerald> I certainly favor the simplicity of Option 1 over Option 2;
   Jerald> however last week we also had an Option 3 which was my
   Jerald> favorite - that being that the node simply does not join the
   Jerald> DAG.  Option 1 as described, indicates that the node joins
   Jerald> the DAG as a leaf node.  My question is - how does a node
   Jerald> even know it's a leaf node?  My understanding is that DAG

 It knows it's a left node because it knows that it failed to find a
compatible OFy.  
Why is this a discriminator?  The node could have other child nodes already attached to itself prior to the node attaching onto the DAG.  This set of nodes could all ascribe to the same OFy, yet be different that the OFx of the main DAG.


 When it's a leaf node, it does not process the DIOs that it receives,
and does not forward that information (list of prefixes, etc.) to it's parent.

Ok.  I assumed that to eliminate newly found children the node would stop sending DIOs.  However, I wasn't sure if DIOs are needed to be sent out periodically for other reasons.


- --
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSvM2Z4CLcPvd0N1lAQKEdwgAhbOWEoqizWQgrdHrf/D/coMkbI04bSyb
NYm+8ETMmT0SjLRh4tFdmE8aRuRaMLQZCjGTdEY0bDJ8u4/PlYfCUBpzZCkQOBjF
XM4QsItdNOpY5YkxjBgmHCflL4uy8awQ1h528x+ZXnwr+1upJ7iAfE0eLzoYhBLE
mnOZ9WqTuGSyzaPS7r8a1QTuwtIdvHtbZWQ7r1yJ8O6RyjKHSxPk06sCYfPlGUgu
TF4DHqz9SANsvBiP8XH5yoQsb4tKS1v7QlXAzFqlLxE9Fk9/Cd8LzrA7H/3jryVb
wEZSBnYrWSu4yFuda4jQhqrWmSdWpK1ikvdMIDH3hW3Hl+kA4FCRAg==
=H9R2
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007E651D86257665_=-- From mcr@marajade.sandelman.ca Thu Nov 5 20:41:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDF93A6A5E for ; Thu, 5 Nov 2009 20:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 bxFeL+kychxm for ; Thu, 5 Nov 2009 20:41:33 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 59A513A6A5D for ; Thu, 5 Nov 2009 20:41:32 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id CC855342CE for ; Thu, 5 Nov 2009 23:32:38 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E75B54E793 for ; Thu, 5 Nov 2009 20:18:10 -0500 (EST) From: Michael Richardson To: roll WG In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 05 Nov 2009 20:18:10 -0500 Message-ID: <7567.1257470290@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 04:41:34 -0000 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I certainly favor the simplicity of Option 1 over Option 2; Jerald> however last week we also had an Option 3 which was my Jerald> favorite - that being that the node simply does not join the Jerald> DAG. Option 1 as described, indicates that the node joins Jerald> the DAG as a leaf node. My question is - how does a node Jerald> even know it's a leaf node? My understanding is that DAG mcr> It knows it's a left node because it knows that it failed mcr> to find a compatible OFy. Jerald> Why is this a discriminator? The node could have other Jerald> child nodes already attached to itself prior to the node Jerald> attaching onto the DAG. This set of nodes could all ascribe Jerald> to the same OFy, yet be different that the OFx of the main Jerald> DAG. okay, so if a node (AA) that implements OFy picks a new parent that has only OF0, it could then tell all it's children that it now has OF0, and those children, expecting OFy, would be in the same situation as AA. It can't forward OFx, because it really doesn't understand OFx. mcr> When it's a leaf node, it does not process the DIOs that mcr> it receives, and does not forward that information (list of mcr> prefixes, etc.) to it's parent. Jerald> Ok. I assumed that to eliminate newly found children the Jerald> node would stop sending DIOs. However, I wasn't sure if Jerald> DIOs are needed to be sent out periodically for other Jerald> reasons. I'm a bit vague on this myself. I think that it has to unicast DIOs to it's parent. It should not be multicasting DIOs if it doesn't want to be a parent. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Thu Nov 5 20:47:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECEE3A6A5D for ; Thu, 5 Nov 2009 20:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 CGgKL8Z4nfDb for ; Thu, 5 Nov 2009 20:47:14 -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 D86903A6925 for ; Thu, 5 Nov 2009 20:47:14 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N6GjV-0006I6-Nh for roll@ietf.org; Thu, 05 Nov 2009 20:47:36 -0800 Message-Id: <746F9743-0B67-49C2-87ED-7BB420CD0CEE@cs.stanford.edu> From: Philip Levis To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 19:52:36 -0800 X-Mailer: Apple Mail (2.936) X-Scan-Signature: 420de4625109dc32c948ff5a924d5714 Subject: [Roll] editing of section 3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 04:47:16 -0000 Feedback/comments appreciated. Mostly, do people feel this makes things clearer? Please note some terminology is in flux (e.g. this text still uses inward/outward rather than up/down). Phil 3. Protocol Model The aim of this section is to describe RPL in the spirit of [RFC4101]. Protocol details can be found in further sections. 3.1 Overview Each RPL instance constructs a routing topology optimized for a certain Objective Function (OF). An instance may provide routes to certain destination prefixes. A single RPL instance consists of one or more DAG roots. These roots may operate independently, or may coordinate over a non-RPL backchannel. Each root has a unique identifier, such that nodes can identify the root of a route. 3.1.1: Multipoint-to-Point Traffic Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN applications ([I-D.ietf-roll-building-routing-reqs], [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]). The destinations of MP2P flows are designated nodes that have some application significance, such as providing connectivity to the larger Internet or core private IP network. RPL supports MP2P traffic by allowing MP2P destinations to be DAG roots. 3.1.2 Point-to-Multipoint Traffic Flows Point-to-multipoint (P2MP) is a traffic pattern required by several LLN applications[cite]. RPL supports P2MP traffic by using a destination advertisement mechanism that sets up routes toward destination prefixes and away from roots. Destination advertisements can update routing tables as the underlying DAG topology changes. 3.1.3 Point-to-Point Traffic Flows RPL DAGs provide a basic structure for point-to-point (P2P) traffic. For a RPL network to support P2P traffic, a root must be able to route packets to a destination. Nodes within the network may also have routing tables to destinations. A packet flows towards a root until it reaches a node that has a known route to the destination. RPL supports the case where a P2P destination is a `one-hop' neighbor. RPL neither specifies nor precludes additional mechanisms for computing and installing more optimal routes to support arbitrary P2P traffic. 3.2. DAG Construction and the DAG Information Object (DIO) RPL creates minimum cost routes to DAG roots. RPL nodes construct these DAGs through DAG Information Object (DIO) messages. A DIO identifies the DAG root, the Objection Function (OF) of the DAG, the position of the transmitter within the DAG, and other routing information. RPL uses DIOs to establish and maintain routes. RPL adapts the rate at which nodes send DIOs. When a DAG is inconsistent or needs repair, RPL sends DIOs more frequently. As the DAG stabilizes, the DIO rate tapers off, reducing the maintenance cost of a steady and well-working DAG. 3.2.1 Grounded and Floating DAGs DAGs can be grounded or floating. A grounded DAG that offers connectivity to to an external routed infrastructure. A floating DAG offers no such external connectivity, and provides routes only to nodes within the DAG. 3.2.2 Objective Function (OF) The Objective Function (OF) conveys and controls the optimization objectives of route selection within a DAG. The Objective Function defines the cost function a RPL instance uses to compute minimum cost routes. Examples of simple optimization functions include minimizing latency, maximizing throughput, or minimizing energy spent. An Objective Code Poiint (OCP) specifies the Objective Function of the DAG. Further details can be found in [I-D.ietf-roll-routing-metrics]. This document describes a default OF, OF0 (designated by OCP value of 0x0000). OF0 may be used to d code efine RPL behaviors in the case where a node encounters a DIO message containing a point that it does not support, if allowed by policy. [I-D.ietf-roll-routing-metrics] contains additional OFs. 3.2.3 Administrative Preference An DAG instance may specify that some DAG roots should be used over others through an administrative preference. Administrative preference offers a way to control traffic and engineer DAG formation in order to better support application requirements or needs. 3.2.4 Distributed Algorithm Operation A high level overview of the distributed algorithm which constructs the DAG is as follows: o Some nodes are DAG roots, with associated administrative preferences. o Nodes advertise their presence, DAG instance, and routing cost with DIO messages sent to the link-local multicast address. o Nodes listen for DIOs and use their information to join a new DAG, maintain their position within an existing DAG, or improve their position within an existing DAG as according to the DAG's Objective Function. o The nodes provision routing table entries for the destinations specified by the DIO towards their DAG Parents. Nodes may provision a DAG Parent as a default gateway. o RPL supports both global and local DAG repair. Each DAG root maintains a sequence number. Incrementing this sequence number institutes a global repair, allowing nodes to choose an arbitrary new position within a DAG. o Nodes may locally repair or change the topology, moving within the DAG without requiring a global repair event. The OCP specifies the limits of this local repair. o Using both DIOs and possibly information in data packets, RPL nodes detect possible routing loops. When a RPL node detects a possible routing loop, it adapts its DIO transmission rate to quickly apply these local repair to the topology. This process and its limitations is discussed in greater detail in 3.4. 3.3 Outward Routes and the Destination Advertisement Object (DAO) RPL uses DIO messages to establish Inward routes from nodes within the LLN to DAG roots. It uses Destination Advertisement Object (DAO) messages to establish Outward routes from DAG roots to nodes within the DAG. DAO messages and Outward traffic are an optional feature for applications that require P2MP traffic. DIO messages advertise whether a DAG instance supports DAOs. 3.3.1 Destination Advertisement Object (DAO) A Destination Advertisement Object conveys destination information so that a root (and other nodes within the network) can establish Outward routes. A DAO message includes prefix information to identify destinations, reverse route information to record routes, and information to determine the freshness of a particular advertisement. Nodes send DAOs Inward towards DAG Roots. Nodes that can maintain routing state may aggregate routes they received in the DAOs they transmit. Nodes that cannot maintain routing state forward DAOs toward the DAG Root and adds the next-hop address to a Reverse Route Stack carried within the DAO message. 3.3.2. `One-Hop' Neighbors In addition to sending DAOs toward DAG roots, RPL nodes may periodically emit a link-local multicast DAO message advertising available destination prefixes. This mechanism allow provisioning a trivial `one-hop' route to local neighbors. 3.4. Loop Detection and Limiting Local Repair RPL nodes maintains route cost information within a DAG. Because links may fail or change over time, nodes can move within a DAG. If routers only move Inward, the DAG remains consistent. However, if a router moves Outward, it can create a routing loop. RPL embeds information in data packets that enable it to quickly detect potential loops and locally repair the DAG. A data packet includes the route cost metric of the transmitter: if a router receives a packet from a router that advertises a cost lower than its own, there may be a routing loop. Allowing nodes to move Outward can, in the case of a Floating DAG, lead to the count-to-infinity problem, where nodes continuously move Outward as they search for a route to a DAG Root. RPL allows a DAG Instance to specify the amount of local repair a router may apply. If a router is unable to find a valid route after this amount of repair, it marks itself as Floating until the DAG Root applies a global repair by incrementing its sequence number. If the local repair limit is zero, then a router cannot move Outward without a global repair. If the local repair limit is infinity, then routers may locally repair freely and can suffer from the count-to-infinity problem. From pal@cs.stanford.edu Thu Nov 5 21:02:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED1C28C0EB for ; Thu, 5 Nov 2009 21:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 N902bo+qg5fM for ; Thu, 5 Nov 2009 21:02:06 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 49F323A67D7 for ; Thu, 5 Nov 2009 21:02:06 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N6Gxt-0005CL-Ml; Thu, 05 Nov 2009 21:02:29 -0800 Message-Id: <7E7DBC18-EED1-4995-A3F0-51A536BDDF44@cs.stanford.edu> From: Philip Levis To: Jonathan Hui In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 21:02:24 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 12c9b5123dfd8f1150b5925870d2fded Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 05:02:07 -0000 On Nov 5, 2009, at 12:31 PM, Jonathan Hui wrote: > > On Nov 5, 2009, at 11:24 AM, Philip Levis wrote: > >> Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to >> know if implementers feel this makes things clearer. In this text, >> the neighbor set is an unconstrained set of L2 neighbors, the >> parent set is a subset of the neighbor set and is the set of >> candidate parents, and the parent is the element of the parent set >> that is the current next hop towards the DAG root. Note that this >> text discards the sibling notion for the simpler notion of limited >> local repair. > > This text is definitely moving in the right direction. > >> 5.2 Neighbors, Parents, and Rank >> >> If Neighbor Unreachability Detection (NUD) determines that a >> neighbor is no longer reachable, then a RPL node >> MUST NOT consider this node a neighbor when calculating and >> advertising routes until the node determines it is reachable again. >> >> Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless >> it has neighbors who have advertised that DAG ID. >> >> A RPL node that has issued a DIO for a DAGID I, DAG Instance N, >> and sequence number S MUST NOT consider neighbors for I,N whose >> last heard DIO for I,N had a sequence number < S. > > I'd change "MUST NOT consider neighbors" to "MUST NOT consider nodes > as neighbors", or some other wording that cannot be misinterpreted > as "MUST NOT process messages from neighbors". I agree. > >> 5.2.1 Parents >> >> By definition, DAG Roots do not have any DAG parents. >> >> RPL nodes that are not roots MAY maintain multiple candidate >> DAG parents for a single DAG Instance. The set of candidate DAG >> parents MUST be a subset of the set of neighbors. At any given >> moment, a node has a single DAG Parent, selected from the set >> of candidate DAG parents. > > Not sure why we have to single out THE DAG parent. The DAG is a DAG > because a node can maintain more than one candidate parent. > Choosing a candidate parent is what defines the forwarding (not > routing) topology. More related to this subject below. I agree. I was trying to distinguish the parent of the moment from the set of candidate parents. Does that make sense? Do you have a suggestion on how to reword this? > >> 5.2.2 DAG Rank >> >> DAG Rank is not a cost metric, although its value is derived from >> and influenced by route cost metrics. Rank is used to avoid and >> detect loops. A node's Rank MUST be higher than the Rank of its DAG >> Parent. The exact calculation of the Rank may depend on the set of >> candidate DAG parents, link metrics, node configuration, and the DAG >> Instance OF. > > I'd say that the advertised Rank MUST be higher than the Rank of its > candidate DAG parents, not just the a chosen DAG parent. We use the > DAG to identify assign nodes relative position within the network. > It doesn't make sense to have a candidate DAG parent that has a > higher Rank. Makes sense. > >> 5.3. DAG Discovery and Maintenance >> >> DAG discovery forms a Directed Acyclic Graph towards a DAG Root >> by identifying a set of candidate DAG parents and selecting a member >> of the set as its DAG parent. DAG discovery also discovers neighbors, >> which may be used to provide additional path diversity when a node >> needs to move downward in the DAG. DAG discovery avoids >> loops by constraining when and how nodes can increase their Rank. >> RPL uses an IPv6 optional header in data packets to detect loops. >> >> 5.3.1. DAGs >> >> 1. A node MAY belong to multiple DAG Instances. >> >> 2. A DAGID, InstanceID, and DAGSequence number uniquely defines >> a DAG iteration. All of a node's candidate parents within a DAG >> instance MUST belong to the same DAG iteration: the last heard >> DIO from candidate parents must be for the same DAG iteration. > > Why not allow a node advertising DAG sequence N forward to a node > with DAG sequence N+1? Communication delays means that we can't > guarantee that this won't happen. So why restrict it even when we > know this is true? I don't think rule 2 restricts this -- rule 6 does. Let me explain where this rule was going -- it's trying to enforce that a node can't perpetually avoid incrementing its sequence number. The rule you suggested -- a node MUST NOT advertise a sequence number lower than all of its candidate parents -- can have issues when DIOs are lost. The goal of this rule is that a node can observe candidate parents increasing their sequence numbers, but continue to use ones that haven't. Then, at some point, it makes the decision to switch to the subset with the newer sequence number, and increments its own. > >> 3. Within a given DAG instance, a node that is a not a root MUST NOT >> advertise a DAGSequenceNumber higher than the highest >> DAGSequenceNumber it has heard. >> >> 4. The DAGSequenceNumbers a node advertises for a DAG instance MUST >> monotonically increase, barring wrap-around as covered in X. >> >> 5. DAG Roots MAY increment the sequence number they advertise. >> >> 6. A node MUST advertise the same DAGSequenceNumber as its >> DAG Parent. > > Or at least what it thinks the DAGSequenceNumber is for its DAG > Parent. This comes back to my previous point - when a new sequence > number is propagating, nodes will (temporarily) have parents in one > iteration, and others in another iteration. I don't think we should > restrict implementations from waiting for some time to wait for its > DAG parents to catch up to the current iteration - but I don't think > we should recommend it either. Yeah -- I think this text needs to distinguish "the last sequence number it heard from its a candidate parent" and "the candidate parent's sequence number." Phil From pal@cs.stanford.edu Thu Nov 5 21:52:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29213A6AF5 for ; Thu, 5 Nov 2009 21:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 jGGegPRASBy1 for ; Thu, 5 Nov 2009 21:52:54 -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 088003A6AEA for ; Thu, 5 Nov 2009 21:52:54 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N6Hl4-0000tD-VI; Thu, 05 Nov 2009 21:53:15 -0800 Message-Id: From: Philip Levis To: Stephen Dawson-Haggerty In-Reply-To: <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Nov 2009 21:53:14 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 05:52:54 -0000 On Nov 5, 2009, at 12:17 PM, Stephen Dawson-Haggerty wrote: > In general it's a lot shorter and easier to understand, which is > great. Was is this a replacement or an addition? A lot of mechanical > text was removed and I don't know if it's intentional (like in 5.4.2, > when it enumerated when you would discard a message)-- the new one > seems a little more vague about who I'm supposed to store in my > candidate parent sets (5.2) Ah -- I think the intention is to keep that as an implementation detail, to leave flexibility. The enumeration of discard cases were, I thought, a bit backwards. Of course you discard malformed messages. Following the response I had to one of the open tickets, it seems to make more sense to state when RPL MUST process a message rather than when it MUST NOT, in part because the MUST NOT introduces bootstrapping problems. > > Also, we lost some of the text explaining why you might want to > increment the dag sequence number (it's split between 5.4.3, 5.3.3, > and 5.3.1). I would have appreciated a sentence towards the beginning > something like "The effect of incrementing the DAG sequence number is > to trigger additional DIO transmissions. This serves as an > implementation-controlled mechanism to rebuild forwarding tables among > members of a DAG instance". The term used is "global repair." I might be OK saying "this can serve as an implementation-controlled mechanism," but stating the total purpose of a mechanism is problematic. If someone later down the line starts using it for something else... does that make sense. > Neither document does a great job of explaining the role of the > neighbor set in forwarding, in particular I couldn't find a place > where it said that you might try multiple parents for the same packet. Agreed. I didn't get to forwarding yet. Clearly it needs to be there. The text would be simple: you forward packets to your parent, which MUST be a member of the candidate parent set. A node MAY change which element of its candidate parent set is its parent at any time. A given implementation might apply certain heuristics (e.g., for stability), but we don't want to constrain the parent selection process. We do want to constrain the set of nodes that can be candidate parents. Phil From jabeille@cisco.com Thu Nov 5 23:45:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E1E3A687F for ; Thu, 5 Nov 2009 23:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.984 X-Spam-Level: X-Spam-Status: No, score=-9.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 ZsKZu1VuN96b for ; Thu, 5 Nov 2009 23:45:07 -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 3D6523A6818 for ; Thu, 5 Nov 2009 23:45:07 -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: AjUAAFNi80qQ/uCWe2dsb2JhbACbbwEBFiQGqEiJQI5ShD0E X-IronPort-AV: E=Sophos;i="4.44,691,1249257600"; d="scan'208";a="53770309" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2009 07:45:29 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA67jTPd016550; Fri, 6 Nov 2009 07:45:29 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 08:45:29 +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, 6 Nov 2009 08:45:28 +0100 Message-ID: In-Reply-To: <7567.1257470290@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Opinion please Thread-Index: Acpem383tIxCag2cRiGwSjDMYWcZ6QAGWvTg References: <7567.1257470290@marajade.sandelman.ca> From: "Julien Abeille (jabeille)" To: "Michael Richardson" , "roll WG" X-OriginalArrivalTime: 06 Nov 2009 07:45:29.0483 (UTC) FILETIME=[1C90E5B0:01CA5EB5] Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 07:45:08 -0000 Hi all, To eliminate children the parent can send DIO with infinite rank right away? Or just resetting trickle, and starting T, which would expire quickly. Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Michael Richardson > Sent: vendredi 6 novembre 2009 02:18 > To: roll WG > Subject: Re: [Roll] Opinion please >=20 >=20 > >>>>> "Jerald" =3D=3D Jerald P Martocci=20 > writes: > Jerald> I certainly favor the simplicity of Option 1 over=20 > Option 2; > Jerald> however last week we also had an Option 3 which was my > Jerald> favorite - that being that the node simply does=20 > not join the > Jerald> DAG. Option 1 as described, indicates that the node joins > Jerald> the DAG as a leaf node. My question is - how does a node > Jerald> even know it's a leaf node? My understanding is that DAG >=20 > mcr> It knows it's a left node because it knows that it failed > mcr> to find a compatible OFy. >=20 > Jerald> Why is this a discriminator? The node could have other > Jerald> child nodes already attached to itself prior to the node > Jerald> attaching onto the DAG. This set of nodes could=20 > all ascribe > Jerald> to the same OFy, yet be different that the OFx of the main > Jerald> DAG. >=20 > okay, so if a node (AA) that implements OFy picks a new=20 > parent that has only OF0, it could then tell all it's=20 > children that it now has OF0, and those children, expecting=20 > OFy, would be in the same situation as AA. > It can't forward OFx, because it really doesn't understand OFx. >=20 > mcr> When it's a leaf node, it does not process the DIOs that > mcr> it receives, and does not forward that information (list of > mcr> prefixes, etc.) to it's parent. >=20 > Jerald> Ok. I assumed that to eliminate newly found children the > Jerald> node would stop sending DIOs. However, I wasn't sure if > Jerald> DIOs are needed to be sent out periodically for other > Jerald> reasons. >=20 > I'm a bit vague on this myself. I think that it has to=20 > unicast DIOs to it's parent. It should not be multicasting=20 > DIOs if it doesn't want to be a parent. >=20 > --=20 > ] He who is tired of Weird Al is tired of life! =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video=20 > > then sign the petition.=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From sdhags@gmail.com Fri Nov 6 01:49:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D953A6877 for ; Fri, 6 Nov 2009 01:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4dXPZl1flWg for ; Fri, 6 Nov 2009 01:49:46 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id AAA2128C161 for ; Fri, 6 Nov 2009 01:49:19 -0800 (PST) Received: by vws31 with SMTP id 31so312867vws.29 for ; Fri, 06 Nov 2009 01:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=b7BbSjDU/Y6CdlUZVFFHT56gjsh16m2Yk6deRuso3fw=; b=B/9h1S2o2Rhrmzx6s6wRz1pFzkdg6pVVFv+rweNjA4Iuzg8p/GQ4w7ou1rVc+8IHZ0 ICe9HhGXmwUPyUPV6EcWxSCGrZ+J8vWMWCSL+AUBKXVnipPv8kuw8wHL7yAzDhLL6R8Z WqNNSFRh0jQ6TxQOdJSFQpVrGAWGVKhAYdmPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qmjGZWIRb6Kcq7c6I1LUZIRfNtxqgqbgV27+4eQ1g9aEDpWhXkInGNHdQp4547V73Y wacmhmCb/jEcArYJ21kMjWqbDWNwVsQLxI907sSw3tznxYDu4LVwl2jVvrzm3FiUqbXt OESvBxqtpPba9ywvIlcCPbi1q11ut+/hRGDZ0= MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.220.126.165 with SMTP id c37mr4415191vcs.76.1257500982835; Fri, 06 Nov 2009 01:49:42 -0800 (PST) In-Reply-To: References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> <44680fe70911051217s7e72836bld1eddd0729d261e@mail.gmail.com> Date: Fri, 6 Nov 2009 01:49:42 -0800 X-Google-Sender-Auth: 39fe03916abd05bb Message-ID: <44680fe70911060149q101dc52at6d64ffe4b244c61f@mail.gmail.com> From: Stephen Dawson-Haggerty To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 09:49:47 -0000 On Thu, Nov 5, 2009 at 9:53 PM, Philip Levis wrote: > > On Nov 5, 2009, at 12:17 PM, Stephen Dawson-Haggerty wrote: > >> >> Also, we lost some of the text explaining why you might want to >> increment the dag sequence number (it's split between 5.4.3, 5.3.3, >> and 5.3.1). =A0I would have appreciated a sentence towards the beginning >> something like "The effect of incrementing the DAG sequence number is >> to trigger additional DIO transmissions. =A0This serves as an >> implementation-controlled mechanism to rebuild forwarding tables among >> members of a DAG instance". > > The term used is "global repair." I might be OK saying "this can serve as= an > implementation-controlled mechanism," but stating the total purpose of a > mechanism is problematic. If someone later down the line starts using it = for > something else... does that make sense. Point taken, although your text is fairly clear here. If I hear a DIO with a new sequence number from a neighbor, I MUST update his information in my table. Furthermore, I MUST only keep parents with the same instance ID in my feasible parents set, so I must either remove the guy with the new sequence number from the set or else remove everyone else (at least until they too update their sequence number). At some point, I switch over to the new sequence number; when I do, I will have heard a updated DIO message from each of the guys in the new candidate parent set. For this reason, I think it would be fair to say that the effect of incrementing the sequence number at the root is to force a refresh of all candidate parent sets within the dag-- doesn't seem up for interpretation. Also, in 5.3.1, #3 and #6 seem more-or-less redundant-- if I must advertise my parent's sequence number, it will not be higher then any number I have heard. Thanks. Steve > >> Neither document does a great job of explaining the role of the >> neighbor set in forwarding, in particular I couldn't find a place >> where it said that you might try multiple parents for the same packet. > > Agreed. I didn't get to forwarding yet. Clearly it needs to be there. The > text would be simple: you forward packets to your parent, which MUST be a > member of the candidate parent set. A node MAY change which element of it= s > candidate parent set is its parent at any time. A given implementation mi= ght > apply certain heuristics (e.g., for stability), but we don't want to > constrain the parent selection process. We do want to constrain the set o= f > nodes that can be candidate parents. > > Phil > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From jvasseur@cisco.com Fri Nov 6 04:15:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91693A6A3D for ; Fri, 6 Nov 2009 04:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 OxRs4Pu4JQzc for ; Fri, 6 Nov 2009 04:15:28 -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 32B773A6999 for ; Fri, 6 Nov 2009 04:15:28 -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: Ak0AAJuh80qQ/uCWe2dsb2JhbACbbwEBFiQGqG6JQI5BhD0E X-IronPort-AV: E=Sophos;i="4.44,692,1249257600"; d="scan'208";a="53800423" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2009 12:15:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6CFovi010108; Fri, 6 Nov 2009 12:15:50 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:15:50 +0100 Received: from dhcp-hlb2-vl250-144-254-42-146.cisco.com ([144.254.42.146]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:15:49 +0100 Message-Id: <95A26CC1-3794-45DC-9A6D-BAB1506B40DA@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Nov 2009 13:15:47 +0100 References: <7567.1257470290@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Nov 2009 12:15:50.0005 (UTC) FILETIME=[E0C02250:01CA5EDA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16992.006 X-TM-AS-Result: No--34.015800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 12:15:29 -0000 On Nov 6, 2009, at 8:45 AM, Julien Abeille (jabeille) wrote: > Hi all, > > To eliminate children the parent can send DIO with infinite rank right > away? Or just resetting trickle, and starting T, which would expire > quickly. I think that the agreement is simply to join as a leaf if you do not understand the OF (simply do not send DIO). Cheers. JP. > > Julien > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Michael Richardson >> Sent: vendredi 6 novembre 2009 02:18 >> To: roll WG >> Subject: Re: [Roll] Opinion please >> >> >>>>>>> "Jerald" == Jerald P Martocci >> writes: >> Jerald> I certainly favor the simplicity of Option 1 over >> Option 2; >> Jerald> however last week we also had an Option 3 which was my >> Jerald> favorite - that being that the node simply does >> not join the >> Jerald> DAG. Option 1 as described, indicates that the node joins >> Jerald> the DAG as a leaf node. My question is - how does a node >> Jerald> even know it's a leaf node? My understanding is that DAG >> >> mcr> It knows it's a left node because it knows that it failed >> mcr> to find a compatible OFy. >> >> Jerald> Why is this a discriminator? The node could have other >> Jerald> child nodes already attached to itself prior to the node >> Jerald> attaching onto the DAG. This set of nodes could >> all ascribe >> Jerald> to the same OFy, yet be different that the OFx of the main >> Jerald> DAG. >> >> okay, so if a node (AA) that implements OFy picks a new >> parent that has only OF0, it could then tell all it's >> children that it now has OF0, and those children, expecting >> OFy, would be in the same situation as AA. >> It can't forward OFx, because it really doesn't understand OFx. >> >> mcr> When it's a leaf node, it does not process the DIOs that >> mcr> it receives, and does not forward that information (list of >> mcr> prefixes, etc.) to it's parent. >> >> Jerald> Ok. I assumed that to eliminate newly found children the >> Jerald> node would stop sending DIOs. However, I wasn't sure if >> Jerald> DIOs are needed to be sent out periodically for other >> Jerald> reasons. >> >> I'm a bit vague on this myself. I think that it has to >> unicast DIOs to it's parent. It should not be multicasting >> DIOs if it doesn't want to be a parent. >> >> -- >> ] He who is tired of Weird Al is tired of life! >> | firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON >> |net architect[ >> ] mcr@sandelman.ottawa.on.ca >> http://www.sandelman.ottawa.on.ca/ |device driver[ >> Kyoto Plus: watch the video >> >> then sign the petition. >> _______________________________________________ >> 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 Jerald.P.Martocci@jci.com Fri Nov 6 06:35:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CBC3A69AF; Fri, 6 Nov 2009 06:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iTmr8Q7eT7cq; Fri, 6 Nov 2009 06:35:32 -0800 (PST) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by core3.amsl.com (Postfix) with ESMTP id 625E53A68DA; Fri, 6 Nov 2009 06:35:31 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKSvQ0R/dF3MUqX400jZEyqciwgQKTsXLu@postini.com; Fri, 06 Nov 2009 06:35:55 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009110608373622-2335747 ; Fri, 6 Nov 2009 08:37:36 -0600 In-Reply-To: MIME-Version: 1.0 To: "Julien Abeille (jabeille)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 6 Nov 2009 08:35:32 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/06/2009 08:35:40 AM, Serialize complete at 11/06/2009 08:35:40 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/06/2009 08:37:36 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/06/2009 08:37:51 AM, Serialize complete at 11/06/2009 08:37:51 AM Content-Type: multipart/alternative; boundary="=_alternative 005028CB86257666_=" Cc: roll-bounces@ietf.org, roll WG Subject: Re: [Roll] Opinion please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 14:35:33 -0000 This is a multipart message in MIME format. --=_alternative 005028CB86257666_= Content-Type: text/plain; charset="US-ASCII" Julien, Michael, Yeah, I guess so. Presumably, the kids will find a new parent if the parent advertises infinite rank. The only special case we need to consider is if some of the children have no other possible connection point to the DAG from a physical radio point-of-view. Thanks for the clarification Jerry "Julien Abeille (jabeille)" Sent by: roll-bounces@ietf.org 11/06/2009 01:45 AM To "Michael Richardson" , "roll WG" cc Subject Re: [Roll] Opinion please Hi all, To eliminate children the parent can send DIO with infinite rank right away? Or just resetting trickle, and starting T, which would expire quickly. Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: vendredi 6 novembre 2009 02:18 > To: roll WG > Subject: Re: [Roll] Opinion please > > > >>>>> "Jerald" == Jerald P Martocci > writes: > Jerald> I certainly favor the simplicity of Option 1 over > Option 2; > Jerald> however last week we also had an Option 3 which was my > Jerald> favorite - that being that the node simply does > not join the > Jerald> DAG. Option 1 as described, indicates that the node joins > Jerald> the DAG as a leaf node. My question is - how does a node > Jerald> even know it's a leaf node? My understanding is that DAG > > mcr> It knows it's a left node because it knows that it failed > mcr> to find a compatible OFy. > > Jerald> Why is this a discriminator? The node could have other > Jerald> child nodes already attached to itself prior to the node > Jerald> attaching onto the DAG. This set of nodes could > all ascribe > Jerald> to the same OFy, yet be different that the OFx of the main > Jerald> DAG. > > okay, so if a node (AA) that implements OFy picks a new > parent that has only OF0, it could then tell all it's > children that it now has OF0, and those children, expecting > OFy, would be in the same situation as AA. > It can't forward OFx, because it really doesn't understand OFx. > > mcr> When it's a leaf node, it does not process the DIOs that > mcr> it receives, and does not forward that information (list of > mcr> prefixes, etc.) to it's parent. > > Jerald> Ok. I assumed that to eliminate newly found children the > Jerald> node would stop sending DIOs. However, I wasn't sure if > Jerald> DIOs are needed to be sent out periodically for other > Jerald> reasons. > > I'm a bit vague on this myself. I think that it has to > unicast DIOs to it's parent. It should not be multicasting > DIOs if it doesn't want to be a parent. > > -- > ] He who is tired of Weird Al is tired of life! > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > > then sign the petition. > _______________________________________________ > 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 --=_alternative 005028CB86257666_= Content-Type: text/html; charset="US-ASCII"
Julien, Michael,

Yeah, I guess so.  Presumably, the kids will find a new parent if the parent advertises infinite rank.  The only special case we need to consider is if some of the children have no other possible connection point to the DAG from a physical radio point-of-view.

Thanks for the clarification

Jerry





"Julien Abeille (jabeille)" <jabeille@cisco.com>
Sent by: roll-bounces@ietf.org

11/06/2009 01:45 AM

To
"Michael Richardson" <mcr@sandelman.ca>, "roll WG" <roll@ietf.org>
cc
Subject
Re: [Roll] Opinion please





Hi all,

To eliminate children the parent can send DIO with infinite rank right
away? Or just resetting trickle, and starting T, which would expire
quickly.

Julien

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> Behalf Of Michael Richardson
> Sent: vendredi 6 novembre 2009 02:18
> To: roll WG
> Subject: Re: [Roll] Opinion please
>
>
> >>>>> "Jerald" == Jerald P Martocci
> <Jerald.P.Martocci@jci.com> writes:
>     Jerald> I certainly favor the simplicity of Option 1 over
> Option 2;
>     Jerald> however last week we also had an Option 3 which was my
>     Jerald> favorite - that being that the node simply does
> not join the
>     Jerald> DAG.  Option 1 as described, indicates that the node joins
>     Jerald> the DAG as a leaf node.  My question is - how does a node
>     Jerald> even know it's a leaf node?  My understanding is that DAG
>
>     mcr>   It knows it's a left node because it knows that it failed
>     mcr> to find a compatible OFy.
>
>     Jerald> Why is this a discriminator?  The node could have other
>     Jerald> child nodes already attached to itself prior to the node
>     Jerald> attaching onto the DAG.  This set of nodes could
> all ascribe
>     Jerald> to the same OFy, yet be different that the OFx of the main
>     Jerald> DAG.
>
> okay, so if a node (AA) that implements OFy picks a new
> parent that has only OF0, it could then tell all it's
> children that it now has OF0, and those children, expecting
> OFy, would be in the same situation as AA.
> It can't forward OFx, because it really doesn't understand OFx.
>
>     mcr>   When it's a leaf node, it does not process the DIOs that
>     mcr> it receives, and does not forward that information (list of
>     mcr> prefixes, etc.) to it's parent.
>
>     Jerald> Ok.  I assumed that to eliminate newly found children the
>     Jerald> node would stop sending DIOs.  However, I wasn't sure if
>     Jerald> DIOs are needed to be sent out periodically for other
>     Jerald> reasons.
>
> I'm a bit vague on this myself. I think that it has to
> unicast DIOs to it's parent.  It should not be multicasting
> DIOs if it doesn't want to be a parent.
>
> --
> ]       He who is tired of Weird Al is tired of life!        
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca
> http://www.sandelman.ottawa.on.ca/ |device driver[
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                                 then sign the petition.
> _______________________________________________
> 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
--=_alternative 005028CB86257666_=-- From jabeille@cisco.com Fri Nov 6 06:36:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB4028C1A4 for ; Fri, 6 Nov 2009 06:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.001 X-Spam-Level: X-Spam-Status: No, score=-8.001 tagged_above=-999 required=5 tests=[AWL=-1.403, BAYES_00=-2.599, 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 jzXUjZYDCcqC for ; Fri, 6 Nov 2009 06:36:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F1AED28C1A1 for ; Fri, 6 Nov 2009 06:36:27 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAO3C80qrR7Ht/2dsb2JhbACCUcMpl36EPQQ X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208,217";a="426403853" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2009 14:36:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6Eaawl009656 for ; Fri, 6 Nov 2009 14:36:49 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 15:36:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EEE.853C27F2" Date: Fri, 6 Nov 2009 15:36:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAG sequence in DAO Thread-Index: Acpe7oT0pR4k8th8QauYsvau9q9DjQ== From: "Julien Abeille (jabeille)" To: "roll WG" X-OriginalArrivalTime: 06 Nov 2009 14:36:26.0535 (UTC) FILETIME=[85507370:01CA5EEE] Subject: [Roll] DAG sequence in DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 14:36:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5EEE.853C27F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 for now the DAO does not contain the DAG sequence. Because a DAG with a different dag sequence is a different DAG, does it make sense for a parent to process a DAO from a child which is in another DAG? =20 Best, Julien ------_=_NextPart_001_01CA5EEE.853C27F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 all,
 
for = now the DAO does=20 not contain the DAG sequence. Because a DAG with a different dag = sequence is a=20 different DAG, does it make sense for a parent to process a DAO from a = child=20 which is in another DAG?
 
Best,
Julien
------_=_NextPart_001_01CA5EEE.853C27F2-- From jabeille@cisco.com Fri Nov 6 06:37:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91B73A6403 for ; Fri, 6 Nov 2009 06:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.962 X-Spam-Level: X-Spam-Status: No, score=-9.962 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFhVdIYC8dm9 for ; Fri, 6 Nov 2009 06:37:19 -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 9841C28C174 for ; Fri, 6 Nov 2009 06:37:18 -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: Ak0AAJzD80qQ/uCWe2dsb2JhbACCUZkfAQEWJAapRJd+hD0E X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208,217";a="53814734" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2009 14:37:41 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6EbfqH019680 for ; Fri, 6 Nov 2009 14:37:41 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 15:37:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EEE.B184F5A0" Date: Fri, 6 Nov 2009 15:37:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAG sequence in DAO Thread-Index: Acpe7oT0pR4k8th8QauYsvau9q9DjQAACF6A References: From: "Julien Abeille (jabeille)" To: "Julien Abeille (jabeille)" , "roll WG" X-OriginalArrivalTime: 06 Nov 2009 14:37:41.0007 (UTC) FILETIME=[B1B3F9F0:01CA5EEE] Subject: Re: [Roll] DAG sequence in DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Nov 2009 14:37:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5EEE.B184F5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable forgot to mention that the DAGID is not there either. Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 6 novembre 2009 15:36 To: roll WG Subject: [Roll] DAG sequence in DAO =09 =09 Hi all, =20 for now the DAO does not contain the DAG sequence. Because a DAG with a different dag sequence is a different DAG, does it make sense for a parent to process a DAO from a child which is in another DAG? =20 Best, Julien ------_=_NextPart_001_01CA5EEE.B184F5A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
forgot to mention that the DAGID is not there=20 either.
Best,
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille=20 (jabeille)
Sent: vendredi 6 novembre 2009 = 15:36
To: roll=20 WG
Subject: [Roll] DAG sequence in DAO

Hi=20 all,
 
for = now the DAO=20 does not contain the DAG sequence. Because a DAG with a different dag = sequence=20 is a different DAG, does it make sense for a parent to process a DAO = from a=20 child which is in another DAG?
 
Best,
Julien
------_=_NextPart_001_01CA5EEE.B184F5A0-- From wintert@acm.org Sat Nov 7 10:54:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B958D28C0D0 for ; Sat, 7 Nov 2009 10:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTk2xRVZda5K for ; Sat, 7 Nov 2009 10:54:25 -0800 (PST) Received: from smtp109.prem.mail.ac4.yahoo.com (smtp109.prem.mail.ac4.yahoo.com [76.13.13.92]) by core3.amsl.com (Postfix) with SMTP id 794903A68E4 for ; Sat, 7 Nov 2009 10:54:25 -0800 (PST) Received: (qmail 36123 invoked from network); 7 Nov 2009 18:54:42 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp109.prem.mail.ac4.yahoo.com with SMTP; 07 Nov 2009 10:54:42 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: A2ZNkFMVM1kolWyQQ6BV1YNlhD9g30tidRfXdXD35iJLCoF6uBvZuQXxfWgo2DKKWZbjfg4J7KAteOkFnVr44avwOkcpYaUwxtrrlFM3tbu94h.c_h5Kr.EpxPXSNo2QuMbaIZuw2Ugwr.cAFKSegvCXWY.Fwklw.du.GRnLhYCKfJEKQJb6Y6FaemjYTqrwhyWWzf5pg9lLGi7AtnhGD98IsKDQxTF_tocBOuq_75p3M5Yxxx_P6siSWevd9qb7or2UGDlLttLUslCq4R91Qzqd13D8amoAy2vzU_cV_WFZ1mRZYaj03EE8EsGtBz5O9VjCm.fj5OrAHfS.M7PMMCJC8H3hBcCST.L75WoyhcVDbVJG7e7JuuDEWMMk1XexEBaRdCpDe2r_fcUJezuu7jE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF5C26A.30408@acm.org> Date: Sat, 07 Nov 2009 13:54:34 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Nov 2009 18:54:26 -0000 Hi Julien, WG, roll issue tracker wrote: > #5: DODAG > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: wintert@… > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------+------------------------------------------- > * This is currently being discussed by the RPL Author team * > > Email from Julien > > Is there a distinction between DAG and destination oriented DAG. From what > I read I feel all DAGs are destination oriented. If this is correct I > propose to remove the destination oriented DAG concept. > The intent for -05 will be to make the unqualifed use of `DAG' in the text consistent with `DODAG Iteration', as outlined below. So in this use, a `DAG' is a `DODAG' snapshotted by a single sequence number -- a `DODAG Iteration'. There may be cases in -04 where the text reads `DAG' and is in fact referring to `DODAG'- we will be sure to clean these up. Here below is some additional explanation prepared by the author team- Does this help to clarify? Regards, -Tim Instance +----------------------------------------------------------------+ | | | (R1) (R2) (Rn) | | / \ /| \ / | \ | | / \ / | \ / | \ | | (A) (B) (M) | (N) ... (X) (Y) (Z) | | /|\ |\ / | |\ | | | | | : : : : : : (O) : : : : : | | / \ | | : : | | | | Instance ID | | | +----------------------------------------------------------------+ Instance An Instance is a routing topology over an LLN, optimized for a particular objective/application. Discrete Instances may also be set up to offer optimized connectivity to different destinations when appropriate, for example to differentiate a Home Network LLN from a Utility Network LLN in a smart metering application where a meter may be configured to join both Instances. It consists of one or more Destination Oriented DAGs (DODAGs). It is uniquely identified by an InstanceID. Each instance is operated independently of other instances, and RPL defines operation over only one instance. Operation among multiple instances is to be expanded upon in a future revision or companion specification. Destination Oriented DAG (DODAG) +----------------+ | | | (R1) | (R2) (Rn) | / \ | /| \ / | \ | / \ | / | \ / | \ | (A) (B) | (M) | (N) ... (X) (Y) (Z) | /|\ |\ | / | |\ | | | | : : : : : | : (O) : : : : : | | / \ | DAGID | : : | | +----------------+ DODAG A Destination Oriented DAG is a DAG rooted at a single root node, which is a node with no outgoing edges. In the case where multiple nodes in the LLN coordinate over a backbone and expose the same DAGID (to support the same DODAG), it is conceptually as if there is a single virtual root over the backbone (not illustrated). In some applications/implementations this may be a desired architecture; in other applications each DODAG may operate with indpendent uncoordinated roots exposing different DAGIDs. A DODAG is uniquely identified over the LLN by the tuple (InstanceID, DAGID). In RPL a node may belong to only one DODAG per Instance at a time. DODAG Iteration +----------------+ +-----------------+ | | | | | (R1) | | (R1) | | / \ | \ | / | \ | | / \ | ------\ | / | \ | | (A) (B) | \ | (A) (C) (B) | | /|\ |\ | / | /|\ |\ | | : : : : : | ------/ | : : : : : | | | / | | | Sequence N | | Sequence N+1 | | | | | +----------------+ +-----------------+ DODAG Iteration A DODAG Iteration is the DODAG that results from the iterative process that reshapes the DODAG as stimulated by the root. It is a DAG as constrained by operation of RPL over a fixed Sequence Number. As the root node increments the Sequence Number, different types of node movement are allowed (e.g. moving `down') and a new DODAG Iteration is formed. A DODAG Iteration is uniquely identified over the LLN by the tuple (InstanceID, DAGID, SequenceNumber). Scope o The scope of an InstanceID is the whole network and it defines an instance o The scope of a DAGID is an instance and it defines a DODAG within that instance o The scope of a Sequence Number is a DODAG and it defines an iteration of that DODAG (DODAG Iteration) o The scope of a rank is a DODAG Iteration and it defines a position of a node within that iteration. From wintert@acm.org Sat Nov 7 11:40:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BEA3A6832 for ; Sat, 7 Nov 2009 11:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGqHyg2qU3ib for ; Sat, 7 Nov 2009 11:40:28 -0800 (PST) Received: from smtp104.prem.mail.ac4.yahoo.com (smtp104.prem.mail.ac4.yahoo.com [76.13.13.43]) by core3.amsl.com (Postfix) with SMTP id C44C33A63EB for ; Sat, 7 Nov 2009 11:40:27 -0800 (PST) Received: (qmail 60974 invoked from network); 7 Nov 2009 19:40:47 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp104.prem.mail.ac4.yahoo.com with SMTP; 07 Nov 2009 11:40:47 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 0zpe02IVM1niS3n0XCaJbVFhNQrvDf0xlMgQnknukBUlukB_Yl2o01zgb_ZnryQeFqw2__Lf8klKzYM5ZCdaOPmoS6BVo6_qLcxKzjU8RxUDrrHOlSXI25VwZ8_4c9z3gZ_BEsBmP5omsZ5miQN7WIrCd7yuAUZsVmL_.KZdHabXIh_TzbugUpJGQ0SWQMbTpmlfJ8KlxGb7l0iXN9SHjYSw9YsA7hMTQqZsPtG51B_Py2fBxBnhGXlkB0AXCWbFuFTV0NTKqKYUADm_70UtGFa2BXoqSDJ1ELsY3OnJpv9Xfx624I1.En6m2agiw90RTFKw4cGqH1vgqNwjrXDgQ1N5d3cCEI2BXwrz3cbsNYcRme5rThOEYW3WK3cVFb1OvjuTc18PwmxkJWCwmBzMHMPsRlGUdeWZFSkEf79ldYkLVigACtI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF5CD37.2080607@acm.org> Date: Sat, 07 Nov 2009 14:40:39 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: roll@ietf.org References: <055.6453f7e4084a474e1bfade94efbfbfeb@tools.ietf.org> In-Reply-To: <055.6453f7e4084a474e1bfade94efbfbfeb@tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #9: DEFAULT_DIO_REDUNDANCY_CONSTANT X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Nov 2009 19:40:28 -0000 This will be fixed in -05. Regards, -Tim roll issue tracker wrote: > #9: DEFAULT_DIO_REDUNDANCY_CONSTANT > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: wintert@… > Type: defect | Status: new > Priority: minor | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------+------------------------------------------- > detail: DEFAULT_DIO_REDUNDANCY_CONSTANT is not specified or mentionned in > section 6. > From william.polk@nist.gov Sun Nov 8 16:03:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912903A6908; Sun, 8 Nov 2009 16:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 E4teNOpR6OCu; Sun, 8 Nov 2009 16:03:29 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 5008F3A68B0; Sun, 8 Nov 2009 16:03:29 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA903Sgk012011; Sun, 8 Nov 2009 19:03:28 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Sun, 8 Nov 2009 19:03:28 -0500 From: "Polk, William T." To: Fred Baker , David R Oran , Richard Shockey , Russ Housley , Leslie Daigle , Sean Turner , Paul Hoffman , Henning Schulzrinne , Phil Roberts , "peter@peter-dambier.de" , "dcrocker@bbiw.net" , Hiroshi Esaki , Michael Dillon , Brian E Carpenter , Ralph Droms , IESG IESG , IAB IAB , "recipe@ietf.org" , Peny Yang , "roll@ietf.org" , "ietf@ietf.org" , "76all@ietf.org" <76all@ietf.org> Date: Sun, 8 Nov 2009 19:03:21 -0500 Thread-Topic: Room for Smart Grid Bar BOF on Wednesday night at IETF 76 Thread-Index: AQHKYMw2E3U2pcLmR0GDycUuI6a4wQ== Message-ID: 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Sun, 08 Nov 2009 16:52:38 -0800 Cc: "St. Pierre, James A." , "Dodson, Donna F." , "Su, David H." , "Golmie, Nada T." Subject: [Roll] Room for Smart Grid Bar BOF on Wednesday night at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 00:03:29 -0000 [Sorry about the shotgun nature of this email; in the absence of a dedicate= d email list, I am a bit concerned about missing interested folks!] Folks, We have been assigned Acacia 1 for the Smart Grid Bar BOF. We will start a= round 8:30PM so that folks attending the plenary will have an opportunity t= o eat before the session. I expect to windup around 11:00 PM, but that dep= ends largely upon the participants' energy and enthusiasm... Given the scale of this bar BOF (64 IETFers have indicated they wish to att= end already!), we will need to be a bit more formal than the usual bar BOF.= Here is a draft agenda, subject to usual in meeting agenda bashing: Bar BOF Agenda I. Agenda Bashing Tim Polk II. Smart Grid Overview Jim St. Pierre/Tim Polk II. Introduction to the IP Priority Action Plan Tim Polk III. Discussion of draft-baker-ietf-core Fred Baker IV. Is the IETF the right place to do this work? Russ Housley V. How should the work be organized? (contingent on IV.) Ralph Droms Thanks, Tim Polk From dcrocker@bbiw.net Sun Nov 8 16:16:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8843A6A45; Sun, 8 Nov 2009 16:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 ofylnwZJkVdE; Sun, 8 Nov 2009 16:16:58 -0800 (PST) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:20e:2eff:fec8:eb01]) by core3.amsl.com (Postfix) with ESMTP id 8520A3A6A42; Sun, 8 Nov 2009 16:16:58 -0800 (PST) Received: from [133.93.17.143] (host-17-143.meeting.ietf.org [133.93.17.143]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id nA90Bno2016438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 16:11:56 -0800 Message-ID: <4AF75E3A.2050808@bbiw.net> Date: Mon, 09 Nov 2009 09:11:38 +0900 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Polk, William T." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10000/Sat Nov 7 19:28:38 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Nov 2009 16:12:01 -0800 (PST) X-Mailman-Approved-At: Sun, 08 Nov 2009 16:52:38 -0800 Cc: "ietf@ietf.org" , "Golmie, Nada T." , "peter@peter-dambier.de" , Phil Roberts , IESG IESG , Hiroshi Esaki , Henning Schulzrinne , "recipe@ietf.org" , "Dodson, Donna F." , "roll@ietf.org" , Russ Housley , Peny Yang , David R Oran , Richard Shockey , IAB IAB , Michael Dillon , Ralph Droms , "76all@ietf.org" <76all@ietf.org>, Paul Hoffman , "Su, David H." , "St. Pierre, James A." , Leslie Daigle , Sean Turner , Brian E Carpenter , Fred Baker Subject: Re: [Roll] Room for Smart Grid Bar BOF on Wednesday night at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 00:16:59 -0000 Polk, William T. wrote: > Given the scale of this bar BOF (64 IETFers have indicated they wish to > attend already!), we will need to be a bit more formal than the usual bar > BOF. Here is a draft agenda, subject to usual in meeting agenda bashing: I presume this extends to the provision of an actual and stocked and functioning /bar/, at the back of the room? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From william.polk@nist.gov Sun Nov 8 16:38:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A313A6A35; Sun, 8 Nov 2009 16:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 whns3hCX8TWI; Sun, 8 Nov 2009 16:38:06 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 269C53A68C2; Sun, 8 Nov 2009 16:38:06 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA90c4Ei002016; Sun, 8 Nov 2009 19:38:04 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Sun, 8 Nov 2009 19:37:57 -0500 From: "Polk, William T." To: Dave CROCKER Date: Sun, 8 Nov 2009 19:33:22 -0500 Thread-Topic: Room for Smart Grid Bar BOF on Wednesday night at IETF 76 Thread-Index: Acpg0hGAb5V6N0GXTKmiLOOSlJJ75wAAiypG Message-ID: References: , <4AF75E3A.2050808@bbiw.net> In-Reply-To: <4AF75E3A.2050808@bbiw.net> 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Sun, 08 Nov 2009 16:52:38 -0800 Cc: "ietf@ietf.org" , "Golmie, Nada T." , "peter@peter-dambier.de" , Phil Roberts , IESG IESG , Hiroshi Esaki , Henning Schulzrinne , "recipe@ietf.org" , "Dodson, Donna F." , "roll@ietf.org" , Russ Housley , Sean, Peny Yang , David R Oran , Ralph Droms , IAB IAB , Michael Dillon , Richard Shockey , "76all@ietf.org" <76all@ietf.org>, Paul Hoffman , Brian E Carpenter , "St. Pierre, James A." , Leslie Daigle , Turner , "Su, David H." , Fred Baker Subject: Re: [Roll] Room for Smart Grid Bar BOF on Wednesday night at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 00:38:06 -0000 That would be lovely, but I just couldn't sort the government paperwork to = make that happen. Billing it as "meeting materials" didn't work out... Tim ________________________________________ From: iesg-bounces@ietf.org [iesg-bounces@ietf.org] On Behalf Of Dave CROCK= ER [dcrocker@bbiw.net] Sent: Sunday, November 08, 2009 7:11 PM To: Polk, William T. Cc: ietf@ietf.org; Golmie, Nada T.; peter@peter-dambier.de; Phil Roberts; I= ESG IESG; Hiroshi Esaki; Henning Schulzrinne; recipe@ietf.org; Dodson, Donn= a F.; roll@ietf.org; Russ Housley; Peny Yang; David R Oran; Richard Shockey= ; IAB IAB; Michael Dillon; Ralph Droms; 76all@ietf.org; Paul Hoffman; Su, D= avid H.; St. Pierre, James A.; Leslie Daigle; Sean Turner; Brian E Carpente= r; Fred Baker Subject: Re: Room for Smart Grid Bar BOF on Wednesday night at IETF 76 Polk, William T. wrote: > Given the scale of this bar BOF (64 IETFers have indicated they wish to > attend already!), we will need to be a bit more formal than the usual bar > BOF. Here is a draft agenda, subject to usual in meeting agenda bashing: I presume this extends to the provision of an actual and stocked and functi= oning /bar/, at the back of the room? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From trac@tools.ietf.org Mon Nov 9 02:04:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B22E3A693E for ; Mon, 9 Nov 2009 02:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNfyiQlNs6If for ; Mon, 9 Nov 2009 02:04:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 91FEC3A6B2B for ; Mon, 9 Nov 2009 02:04:04 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7R6t-0004p0-1W; Mon, 09 Nov 2009 02:04:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 10:04:30 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/10#comment:2 Message-ID: <064.83b73237b624a5d99aa125d99ab2f505@tools.ietf.org> References: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:04:05 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: This closes the ticket #5 and will be reflected in rev-05. Thus the OCP0 will no longer will the "default" OCP and nodes will no longer have to support that OCP. If a node receives a DIO specifying an OCP that it does not support or understand, it may join the DAG but only as a leaf and log the issue. -- Ticket URL: roll From trac@tools.ietf.org Mon Nov 9 02:04:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236A33A685D for ; Mon, 9 Nov 2009 02:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S78S7GUQFoVe for ; Mon, 9 Nov 2009 02:04:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 721B03A67FB for ; Mon, 9 Nov 2009 02:04:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7R7Z-0004xR-Tg; Mon, 09 Nov 2009 02:05:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 10:05:13 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/10#comment:3 Message-ID: <064.fec4f9c7a08c63d0c791027e38c281e6@tools.ietf.org> References: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:04:48 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Comment(by jpv@…): Replying to [comment:2 jpv@…]: > This closes the ticket #10 and will be reflected in rev-05. Thus the OCP0 will no longer will the "default" OCP and nodes will no longer have to support that OCP. If a node receives a DIO specifying an OCP that it does not support or understand, it may join the DAG but only as a leaf and log the issue. -- Ticket URL: roll From jvasseur@cisco.com Mon Nov 9 02:06:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15703A685D for ; Mon, 9 Nov 2009 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.73 X-Spam-Level: X-Spam-Status: No, score=-7.73 tagged_above=-999 required=5 tests=[AWL=-1.131, 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 BvC6rBY8IPE2 for ; Mon, 9 Nov 2009 02:06:06 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 29AB33A67FB for ; Mon, 9 Nov 2009 02:06:06 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN9390qQ/uCW/2dsb2JhbADEQZZHgjOCCwQ X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="222317154" Received: from ams-core-1.cisco.com ([144.254.224.150]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2009 10:06:31 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9A6SGn020759 for ; Mon, 9 Nov 2009 10:06:31 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:06:00 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:06:00 +0100 Message-Id: From: JP Vasseur To: roll WG In-Reply-To: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 11:05:59 +0100 References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 10:06:00.0312 (UTC) FILETIME=[3CF88F80:01CA6124] Subject: [Roll] Ticket #5: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 10:06:10 -0000 Strong consensus towards Option 1. This closes the ticket #10 and will be reflected in rev-05. Thanks. JP. On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: > Dear all, > > /co-chair hat off/ > > We would welcome your opinion on the following issue: > > Suppose that a DAG is formed that support OFx. A new node willing to > join the DAG does not support OFx but OFy. Note that by OF we > actually mean the Objective function and the metric. > > We have two options here. > > Option 1: The node simply joins the DAG as a leaf. In order words, > the node has connectivity since it joins the DAG but will not act as > a router for others since it does not understand the OF. Parent > selection could be a simply a "random". > > Option 2: The node joins the DAG and falls back to the "default" > OCP. From there is prolongs the DAG but with OF0 (of course > inconsistent metrics are not added). This also means that everynode > MUST implement OF0 and that the network may compromise nodes with > different OF at some point. Several options even more complex have > been discussed where one could use common denominator to get as > close as possible to the desired OF, allow a node not to be so > "altruistic", ... > > My personal view is that OF management can quick get fairly complex > and hard to manage. Option 1 is extremely simple and easy to manage. > If a node is mis-configured (does not support the OF of the DAG) it > can join it as a leaf in order to have connectivity and send an > alarm to fix its configuration. We now just need to specify OF in > some document and this is it. > > Several of you mentioned that they were leaning toward option 1, but > could you please express your opinion, we would like to have it > solved for the next revision next week. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 9 02:08:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7859D3A696D for ; Mon, 9 Nov 2009 02:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.71 X-Spam-Level: X-Spam-Status: No, score=-7.71 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, 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 iQL0bTKRP98M for ; Mon, 9 Nov 2009 02:08:02 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 78EAC3A67FB for ; Mon, 9 Nov 2009 02:08:02 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGAAp590qQ/uCW/2dsb2JhbACCIDDBaZZGgjOCCwQ X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208,217";a="222317621" Received: from ams-core-1.cisco.com ([144.254.224.150]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2009 10:08:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9A8R5R021593 for ; Mon, 9 Nov 2009 10:08:27 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:08:27 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:08:26 +0100 Message-Id: <2D7CB642-7EFB-4F3E-919B-39B7F747FA0D@cisco.com> From: JP Vasseur To: JP Vasseur In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-79-281232216 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 11:08:26 +0100 References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 10:08:26.0849 (UTC) FILETIME=[94505510:01CA6124] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-16998.006 X-TM-AS-Result: No--26.868600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll WG Subject: Re: [Roll] Ticket #5: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 10:08:03 -0000 --Apple-Mail-79-281232216 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sorry the tile of the previous email should read "Ticket #10" closed. On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: > Strong consensus towards Option 1. > > This closes the ticket #10 and will be reflected in rev-05. > > Thanks. > > JP. > > On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: > >> Dear all, >> >> /co-chair hat off/ >> >> We would welcome your opinion on the following issue: >> >> Suppose that a DAG is formed that support OFx. A new node willing >> to join the DAG does not support OFx but OFy. Note that by OF we >> actually mean the Objective function and the metric. >> >> We have two options here. >> >> Option 1: The node simply joins the DAG as a leaf. In order words, >> the node has connectivity since it joins the DAG but will not act >> as a router for others since it does not understand the OF. Parent >> selection could be a simply a "random". >> >> Option 2: The node joins the DAG and falls back to the "default" >> OCP. From there is prolongs the DAG but with OF0 (of course >> inconsistent metrics are not added). This also means that everynode >> MUST implement OF0 and that the network may compromise nodes with >> different OF at some point. Several options even more complex have >> been discussed where one could use common denominator to get as >> close as possible to the desired OF, allow a node not to be so >> "altruistic", ... >> >> My personal view is that OF management can quick get fairly complex >> and hard to manage. Option 1 is extremely simple and easy to >> manage. If a node is mis-configured (does not support the OF of the >> DAG) it can join it as a leaf in order to have connectivity and >> send an alarm to fix its configuration. We now just need to specify >> OF in some document and this is it. >> >> Several of you mentioned that they were leaning toward option 1, >> but could you please express your opinion, we would like to have it >> solved for the next revision next week. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-79-281232216 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sorry the tile of the previous = email should read "Ticket #10" closed.

On Nov = 9, 2009, at 11:05 AM, JP Vasseur wrote:

Strong = consensus towards Option 1.

This closes the ticket #10 and will = be reflected in rev-05.

Thanks.

JP.

On Nov 5, 2009, = at 8:24 AM, JP Vasseur wrote:

Dear = all,

/co-chair hat = off/

We would = welcome your opinion on the following issue:

Suppose that a = DAG is formed that support OFx. A new node willing to join the DAG does = not support OFx but OFy. Note that by OF we actually mean the Objective = function and the metric.

We have two = options here.

Option 1: The = node simply joins the DAG as a leaf. In order words, the node has = connectivity since it joins the DAG but will not act as a router for = others since it does not understand the OF. Parent selection could be a = simply a "random".

Option 2: The = node joins the DAG and falls back to the "default" OCP. =46rom there is = prolongs the DAG but with OF0 (of course inconsistent metrics are not = added). This also means that everynode MUST implement OF0 and that the = network may compromise nodes with different OF at some point. Several = options even more complex have been discussed where one could use common = denominator to get as close as possible to the desired OF, allow a node = not to be so "altruistic", ...

My personal = view is that OF management can quick get fairly complex and hard to = manage. Option 1 is extremely simple and easy to manage. If a node is = mis-configured (does not support the OF of the DAG) it can join it as a = leaf in order to have connectivity and send an alarm to fix its = configuration. We now just need to specify OF in some document and this = is it.

Several of you = mentioned that they were leaning toward option 1, but could you please = express your opinion, we would like to have it solved for the next = revision next week.

Thanks.

JP.

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

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

= --Apple-Mail-79-281232216-- From jabeille@cisco.com Mon Nov 9 02:11:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B178A3A67E3 for ; Mon, 9 Nov 2009 02:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.98 X-Spam-Level: X-Spam-Status: No, score=-7.98 tagged_above=-999 required=5 tests=[AWL=-1.381, 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 iwOu0NcoDTKv for ; Mon, 9 Nov 2009 02:11:30 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CC3F33A67A5 for ; Mon, 9 Nov 2009 02:11:29 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADd690qQ/uCW/2dsb2JhbADESJZGhD4E X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="268123837" Received: from ams-core-1.cisco.com ([144.254.224.150]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 10:11:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9ABrN2022927; Mon, 9 Nov 2009 10:11:54 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:11:46 +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, 9 Nov 2009 11:11:45 +0100 Message-ID: In-Reply-To: <4AF5C26A.30408@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #5: DODAG Thread-Index: Acpf29+gSuPDmQxxQziDIkvqKDUczgBSOTZA References: <4AF5C26A.30408@acm.org> From: "Julien Abeille (jabeille)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 09 Nov 2009 10:11:46.0678 (UTC) FILETIME=[0B6BD160:01CA6125] Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 10:11:32 -0000 Hi Tim, My question is: are there DAGs that are not DODAGs in RPL? My feeling is no. Hence I would suppress the DODAG instead of turning all "DAG" into "DODAG". Best, Julien=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Tim Winter > Sent: samedi 7 novembre 2009 19:55 > To: ROLL WG > Subject: [Roll] [roll] #5: DODAG >=20 > Hi Julien, WG, >=20 >=20 > roll issue tracker wrote: > > #5: DODAG > >=20 > --------------------------------+------------------------------------- > > --------------------------------+------ > > Reporter: jpv@... | Owner: wintert@... =20 > > Type: defect | Status: new =20 > > Priority: major | Milestone: =20 > > Component: rpl | Version: =20 > > Severity: Active WG Document | Keywords: =20 > >=20 > --------------------------------+------------------------------------- > > --------------------------------+------ > > * This is currently being discussed by the RPL Author team * > >=20 > > Email from Julien > >=20 > > Is there a distinction between DAG and destination=20 > oriented DAG. From=20 > > what I read I feel all DAGs are destination oriented. If this is=20 > > correct I propose to remove the destination oriented DAG concept. > >=20 >=20 >=20 > The intent for -05 will be to make the unqualifed use of=20 > `DAG' in the text consistent with `DODAG Iteration', as=20 > outlined below. So in this use, a `DAG' is a `DODAG'=20 > snapshotted by a single sequence number -- a `DODAG=20 > Iteration'. There may be cases in -04 where the text reads=20 > `DAG' and is in fact referring to `DODAG'- we will be sure to=20 > clean these up. Here below is some additional explanation=20 > prepared by the author team- >=20 > Does this help to clarify? >=20 > Regards, >=20 > -Tim >=20 >=20 >=20 > Instance >=20 >=20 > =20 > +----------------------------------------------------------------+ > | =20 > | > | (R1) (R2) =20 > (Rn) | > | / \ /| \ / | =20 > \ | > | / \ / | \ / | =20 > \ | > | (A) (B) (M) | (N) ... (X) (Y)=20 > (Z) | > | /|\ |\ / | |\ | | =20 > | | > | : : : : : : (O) : : : : =20 > : | > | / \ =20 > | > | : : =20 > | > | =20 > | > | Instance ID =20 > | > | =20 > | > =20 > +----------------------------------------------------------------+ >=20 > Instance >=20 >=20 > An Instance is a routing topology over an LLN, optimized for a > particular objective/application. Discrete Instances may=20 > also be set > up to offer optimized connectivity to different destinations when > appropriate, for example to differentiate a Home Network LLN from a > Utility Network LLN in a smart metering application where=20 > a meter may > be configured to join both Instances. >=20 > It consists of one or more Destination Oriented DAGs (DODAGs). >=20 > It is uniquely identified by an InstanceID. >=20 > Each instance is operated independently of other instances, and RPL > defines operation over only one instance. Operation among multiple > instances is to be expanded upon in a future revision or companion > specification. >=20 >=20 >=20 > Destination Oriented DAG (DODAG) >=20 >=20 > +----------------+ > | | > | (R1) | (R2) (Rn) > | / \ | /| \ / | \ > | / \ | / | \ / | \ > | (A) (B) | (M) | (N) ... (X) (Y) (Z) > | /|\ |\ | / | |\ | | | > | : : : : : | : (O) : : : : : > | | / \ > | DAGID | : : > | | > +----------------+ >=20 > DODAG >=20 >=20 > A Destination Oriented DAG is a DAG rooted at a single root node, > which is a node with no outgoing edges. >=20 > In the case where multiple nodes in the LLN coordinate over a > backbone and expose the same DAGID (to support the same=20 > DODAG), it is > conceptually as if there is a single virtual root over the backbone > (not illustrated). In some applications/implementations=20 > this may be > a desired architecture; in other applications each DODAG=20 > may operate > with indpendent uncoordinated roots exposing different DAGIDs. >=20 > A DODAG is uniquely identified over the LLN by the tuple=20 > (InstanceID, > DAGID). >=20 > In RPL a node may belong to only one DODAG per Instance at a time. >=20 >=20 >=20 > DODAG Iteration >=20 >=20 > +----------------+ +-----------------+ > | | | | > | (R1) | | (R1) | > | / \ | \ | / | \ | > | / \ | ------\ | / | \ | > | (A) (B) | \ | (A) (C) (B) | > | /|\ |\ | / | /|\ |\ | > | : : : : : | ------/ | : : : : : | > | | / | | > | Sequence N | | Sequence N+1 | > | | | | > +----------------+ +-----------------+ >=20 > DODAG Iteration >=20 >=20 > A DODAG Iteration is the DODAG that results from the iterative > process that reshapes the DODAG as stimulated by the root. It is a > DAG as constrained by operation of RPL over a fixed=20 > Sequence Number. >=20 > As the root node increments the Sequence Number, different types of > node movement are allowed (e.g. moving `down') and a new DODAG > Iteration is formed. >=20 > A DODAG Iteration is uniquely identified over the LLN by the tuple > (InstanceID, DAGID, SequenceNumber). >=20 >=20 >=20 > Scope >=20 > o The scope of an InstanceID is the whole network and it=20 > defines an > instance >=20 > o The scope of a DAGID is an instance and it defines a=20 > DODAG within > that instance >=20 > o The scope of a Sequence Number is a DODAG and it defines an > iteration of that DODAG (DODAG Iteration) >=20 > o The scope of a rank is a DODAG Iteration and it defines=20 > a position > of a node within that iteration. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Mon Nov 9 02:58:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D9E3A68A5 for ; Mon, 9 Nov 2009 02:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.692 X-Spam-Level: X-Spam-Status: No, score=-7.692 tagged_above=-999 required=5 tests=[AWL=-1.093, 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 94nLFyCbGp2v for ; Mon, 9 Nov 2009 02:58:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B45BA3A686A for ; Mon, 9 Nov 2009 02:58:35 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM2E90qrR7Ht/2dsb2JhbADFG5ZKgjOCCwSBaA X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="428057073" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2009 10:59:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9AwvSq019061 for ; Mon, 9 Nov 2009 10:59:01 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:58:55 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:58:55 +0100 Message-Id: <1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com> From: JP Vasseur To: roll WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 11:58:54 +0100 References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 10:58:55.0634 (UTC) FILETIME=[A19C3F20:01CA612B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-16998.006 X-TM-AS-Result: No--22.859100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 10:58:36 -0000 So here is the plan for rev-5. First OCP0 will be removed from the core specification. There will no longer be any requirement for a node to support OCP0. Various OCPs will be defined in separate drafts and each node will be provisioned to support one or more OCPs If a node receives a DIO referring to an OCP that it does not support/ understand, it may join the DAG as a leaf and log the issue. In the absence of comments, we will update rev-05 accordingly. Thanks. JP. On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: > Strong consensus towards Option 1. > > This closes the ticket #10 and will be reflected in rev-05. > > Thanks. > > JP. > > On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: > >> Dear all, >> >> /co-chair hat off/ >> >> We would welcome your opinion on the following issue: >> >> Suppose that a DAG is formed that support OFx. A new node willing >> to join the DAG does not support OFx but OFy. Note that by OF we >> actually mean the Objective function and the metric. >> >> We have two options here. >> >> Option 1: The node simply joins the DAG as a leaf. In order words, >> the node has connectivity since it joins the DAG but will not act >> as a router for others since it does not understand the OF. Parent >> selection could be a simply a "random". >> >> Option 2: The node joins the DAG and falls back to the "default" >> OCP. From there is prolongs the DAG but with OF0 (of course >> inconsistent metrics are not added). This also means that everynode >> MUST implement OF0 and that the network may compromise nodes with >> different OF at some point. Several options even more complex have >> been discussed where one could use common denominator to get as >> close as possible to the desired OF, allow a node not to be so >> "altruistic", ... >> >> My personal view is that OF management can quick get fairly complex >> and hard to manage. Option 1 is extremely simple and easy to >> manage. If a node is mis-configured (does not support the OF of the >> DAG) it can join it as a leaf in order to have connectivity and >> send an alarm to fix its configuration. We now just need to specify >> OF in some document and this is it. >> >> Several of you mentioned that they were leaning toward option 1, >> but could you please express your opinion, we would like to have it >> solved for the next revision next week. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 9 03:02:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047AB3A680D for ; Mon, 9 Nov 2009 03:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.556 X-Spam-Level: X-Spam-Status: No, score=-8.556 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, MANGLED_GOOD=2.3, 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 UiwXVktbZxka for ; Mon, 9 Nov 2009 03:02:27 -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 E29EE28C20D for ; Mon, 9 Nov 2009 03:02:26 -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: Ak0AAO+F90qQ/uCWe2dsb2JhbACbegEBFiQGqGyWToI4ggYEjAs X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="53942955" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 11:02:51 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9B2pDH010074; Mon, 9 Nov 2009 11:02:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:02:51 +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, 9 Nov 2009 12:02:47 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FDE5@XMB-AMS-107.cisco.com> In-Reply-To: <7E7DBC18-EED1-4995-A3F0-51A536BDDF44@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency Thread-Index: AcpenlwBG/MhmID/QPGN1C/NnyXg7gCjS/vQ References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org><6221491B-0837-4BEF-8E48-970AEBDB3972@archrock.com> <7E7DBC18-EED1-4995-A3F0-51A536BDDF44@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Jonathan Hui" X-OriginalArrivalTime: 09 Nov 2009 11:02:51.0732 (UTC) FILETIME=[2E55F140:01CA612C] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:02:32 -0000 > > >> >>> 5.2.1 Parents >>> >>> By definition, DAG Roots do not have any DAG parents. >>> >>> RPL nodes that are not roots MAY maintain multiple candidate >>> DAG parents for a single DAG Instance. The set of candidate DAG >>> parents MUST be a subset of the set of neighbors. At any given >>> moment, a node has a single DAG Parent, selected from the set >>> of candidate DAG parents. >> >> Not sure why we have to single out THE DAG parent. The DAG is a DAG >> because a node can maintain more than one candidate parent. >> Choosing a candidate parent is what defines the forwarding (not >> routing) topology. More related to this subject below. > >I agree. I was trying to distinguish the parent of the moment from the >set of candidate parents. Does that make sense? Do you have a >suggestion on how to reword this? We need the concept of 'preferred' parent to inherit a number of metrics from, and to compute self's rank. So we have a set of current parents and sibling and in that set, there's the preferred one. >> >>> 5.2.2 DAG Rank >>> >>> DAG Rank is not a cost metric, although its value is derived from >>> and influenced by route cost metrics. Rank is used to avoid and >>> detect loops. A node's Rank MUST be higher than the Rank of its DAG >>> Parent. The exact calculation of the Rank may depend on the set of >>> candidate DAG parents, link metrics, node configuration, and the DAG >>> Instance OF. >> >> I'd say that the advertised Rank MUST be higher than the Rank of its >> candidate DAG parents, not just the a chosen DAG parent. We use the >> DAG to identify assign nodes relative position within the network. >> It doesn't make sense to have a candidate DAG parent that has a >> higher Rank. > >Makes sense. We took great care in the current wording. Can be simplified and Phil is very goo d at it. But I suggest we do not make too many changes in one thread. Can we take it rule by rule? >> Why not allow a node advertising DAG sequence N forward to a node >> with DAG sequence N+1? Communication delays means that we can't >> guarantee that this won't happen. So why restrict it even when we >> know this is true? > >I don't think rule 2 restricts this -- rule 6 does. Let me explain >where this rule was going -- it's trying to enforce that a node can't >perpetually avoid incrementing its sequence number. The rule you >suggested -- a node MUST NOT advertise a sequence number lower than >all of its candidate parents -- can have issues when DIOs are lost. >The goal of this rule is that a node can observe candidate parents >increasing their sequence numbers, but continue to use ones that >haven't. Then, at some point, it makes the decision to switch to the >subset with the newer sequence number, and increments its own. We have the concept of future parent; same DODAG, future instance; the text says that you can forward to a future parent but you must set the rank to infinite to avoid false positives in loop detection. Pascal From trac@tools.ietf.org Mon Nov 9 03:04:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242F33A684F for ; Mon, 9 Nov 2009 03:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scjweamW+NIR for ; Mon, 9 Nov 2009 03:04:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 83A363A680D for ; Mon, 9 Nov 2009 03:04:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7S3I-0007rv-T4; Mon, 09 Nov 2009 03:04:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 11:04:52 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/13#comment:1 Message-ID: <064.df3c6284d9c9d7a1abf5cd29a2be5ed3@tools.ietf.org> References: <055.bff47a20859521b2716856f3268f0b1d@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <055.bff47a20859521b2716856f3268f0b1d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #13: Terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:04:27 -0000 #13: Terminology --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Terminology updated in the Revision -05 of the RPL specification. -- Ticket URL: roll From pthubert@cisco.com Mon Nov 9 03:05:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A473A684F for ; Mon, 9 Nov 2009 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[AWL=-1.101, 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 u0RK+HWqZD-v for ; Mon, 9 Nov 2009 03:05:18 -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 4C5243A680D for ; Mon, 9 Nov 2009 03:05:18 -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: ApwEAN+G90qrRN+J/2dsb2JhbACEcpVEqnCHFY85gTKCOFQEgWiKIw X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="48577501" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2009 11:05:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nA9B5RI2006757; Mon, 9 Nov 2009 11:05:44 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:05:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 9 Nov 2009 12:05:35 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FDEC@XMB-AMS-107.cisco.com> In-Reply-To: <1806878229.4287551257422722111.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL clarification needed: moving down the DAG Thread-Index: AcpeEEOIMRuaxhtcQgqm7fsNQnWbrQDHAthA References: <71100634.4287141257422120695.JavaMail.root@mail02.pantherlink.uwm.edu> <1806878229.4287551257422722111.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" X-OriginalArrivalTime: 09 Nov 2009 11:05:39.0824 (UTC) FILETIME=[9286BF00:01CA612C] Cc: roll@ietf.org Subject: Re: [Roll] RPL clarification needed: moving down the DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:05:19 -0000 SGkgTXVrdWw6DQoNCldlIGN1cnJlbnRseSBoYXZlIGEgcnVsZSBOT1QgVE8gZm9sbG93IGEgcGFy ZW50IHRoYXQgZmFsbHMgZG93biBhIGN1cnJlbnQgRE9EQUcgaXRlcmF0aW9uLiBUaGlzIHdhcyBh ZGRlZCB0byBhdm9pZCBjb3VudCB0byBpbmZpbml0eSB2ZXJ5IGVhcmx5IGluIFJQTC4gQSBub2Rl IHN0aWxsIGNhbiBhbmQgc2hvdWxkIElNSE8gZm9sbG93IGEgcGFyZW50IHRoYXQganVtcHMgaWYg dGhhdCBub2RlIGxvb3NlcyBhbGwgcGFyZW50cyBpbiBpdHMgY3VycmVudCBpdGVyYXRpb24uDQoN ClBhc2NhbA0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNdWt1bCBHb3lh bCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdDQo+U2VudDogamV1ZGkgNSBub3ZlbWJyZSAyMDA5IDEz OjA1DQo+VG86IFJpY2hhcmQgS2Vsc2V5DQo+Q2M6IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7 IHJvbGxAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW1JvbGxdIFJQTCBjbGFyaWZpY2F0aW9uIG5l ZWRlZDogbW92aW5nIGRvd24gdGhlIERBRw0KPg0KPkhpIFJpY2hhcmQNCj4NCj5JZiB0aGUgbm9k ZSBpcyBpbiBhICJjb3VudCB0byBpbmZpbml0eSIgc2l0dWF0aW9uIGluIERBRzEgYW5kIGlzIGEg cGFydCBvZiBEQUcyIGFzIHdlbGwgKG9yIGNhbiBqb2luIERBRzINCj5xdWlja2x5IGlmIGl0IHdh bnRzIHRvKToNCj4NCj4xKSBpdCB3aWxsIHN0YXJ0IHVzaW5nIERBRzIgZm9yIHBhY2tldCBmb3J3 YXJkaW5nIG9uY2UgREFHMiBiZWNvbWVzIG1vcmUgYXR0cmFjdGl2ZSB0aGFuIERBRzEuDQo+DQo+ MikgQnV0IGhvdyBkb2VzIHRoZSAiY291bnQgdG8gaW5maW5pdHkiIHRoZSBub2RlIGlzIGRvaW5n IGluIERBRzEgYWZmZWN0IERBRzIgb3RoZXJ3aXNlPyBJIGNhbiBzZWUgdGhhdA0KPmZyZXF1ZW50 IGdlbmVyYXRpb24gb2YgREFHMSBESU9zIGJ5IHRoZSBpbi1sb29wIERBRzEgbm9kZXMgd2lsbCBj YXVzZSBleHRyYSBjb250ZW50aW9uIGZvciB0aGUgcmFkaW8gY2hhbm5lbCwNCj5idXQgd2hhdCBl bHNlIG1heSBoYXBwZW4/DQo+DQo+VGhhbmtzDQo+TXVrdWwNCj4NCj4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+RnJvbTogIlJpY2hhcmQgS2Vsc2V5IiA8cmljaGFyZC5rZWxzZXlAZW1i ZXIuY29tPg0KPlRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KPkNjOiBwdGh1YmVy dEBjaXNjby5jb20sIHJvbGxAaWV0Zi5vcmcNCj5TZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgNSwg MjAwOSA1OjMxOjE2IEFNIEdNVCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwNCj5TdWJqZWN0OiBS ZTogW1JvbGxdIFJQTCBjbGFyaWZpY2F0aW9uIG5lZWRlZDogbW92aW5nIGRvd24gdGhlIERBRw0K Pg0KPiAgIERhdGU6IFdlZCwgNCBOb3YgMjAwOSAxNzozMjowNSAtMDYwMCAoQ1NUKQ0KPiAgIEZy b206IE11a3VsIEdveWFsIDxtdWt1bEB1d20uZWR1Pg0KPg0KPiAgIDIuIE5vdywgbGV0cyBzdXBw b3NlIHRoYXQgbmV3IHBhcmVudCAoQikgaGFzIGEgaGlnaGVyIHJhbmsgdGhhbiB0aGUNCj4gICBu b2RlJ3MgY3VycmVudCByYW5rIGFuZCBpcyBpbmZhY3QgaW4gdGhlIG5vZGUncyBzdWItREFHLiBU aGUgbm9kZSAoQSkNCj4gICBjaG9vc2VzIGl0IGFzIGEgcGFyZW50IGFuZCBjb25zZXF1ZW50bHkg aW5jcmVhc2VzIGl0cyByYW5rLiBOb3csIHdlDQo+ICAgaGF2ZSBhIHJvdXRpbmcgbG9vcC4gWy4u Ll0gV2Ugd2lsbCBoYXZlICJjb3VudCB0byBpbmZpbml0eSIgc2l0dWF0aW9uIG9ubHkNCj4gICB3 aGVuIG5vZGVzIGluIHRoZSBsb29wIGFyZSBpc29sYXRlZCBmcm9tIHJlc3Qgb2YgdGhlIG5ldHdv cmsuIEluIHRoYXQNCj4gICBjYXNlLCB0aGV5IHdpbGwgZG8gImNvdW50IHRvIGluZmluaXR5IiBh bmQgcHJvZHVjZSBsb3Qgb2YgRElPcyBidXQgd2UNCj4gICBzaG91bGQgbm90IHJlYWxseSBjYXJl IGFib3V0IHRoZXNlIG5vZGVzIChhbmQgdGhlaXIgRElPcykgc2luY2UgdGhleQ0KPiAgIGFyZSBp c29sYXRlZCBhbnkgd2F5Lg0KPg0KPkhpIE11a3VsLA0KPg0KPlJlbWVtYmVyIHRoYXQgdGhlcmUg bWF5IGJlIG11bHRpcGxlIERBRyBpbnN0YW5jZXMuICBCZWluZw0KPmlzb2xhdGVkIGZyb20gb25l IERBRyByb290IGRvZXMgbm90IG1lYW4gdGhhdCBhIG5vZGUgaGFzDQo+bm90aGluZyB1c2VmdWwg dG8gZG8uICBJdCBtYXkganVzdCBtZWFuIHRoYXQgaXQgd2lsbCB1c2UNCj5hIGRpZmZlcmVudCBE QUcgZm9yIHRoZSBtb21lbnQuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC1SaWNoYXJkIEtlbHNleQ0K From pthubert@cisco.com Mon Nov 9 03:11:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C720B28C223 for ; Mon, 9 Nov 2009 03:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.677 X-Spam-Level: X-Spam-Status: No, score=-9.677 tagged_above=-999 required=5 tests=[AWL=0.922, 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 tJpW5lE3njks for ; Mon, 9 Nov 2009 03:11:42 -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 3BD0A28C21F for ; Mon, 9 Nov 2009 03:11:42 -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: Ak0AAAyI90qQ/uCWe2dsb2JhbACbegEBFiQGqG+WToIzggsEgWg X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="53944189" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 11:12:07 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9BC6tI012976 for ; Mon, 9 Nov 2009 11:12:07 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:12:06 +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, 9 Nov 2009 12:11:59 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> In-Reply-To: <1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphK6qFZ1tJ5g/JT92hXj2VTrNMgwAAXyyA References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "roll WG" X-OriginalArrivalTime: 09 Nov 2009 11:12:06.0999 (UTC) FILETIME=[794CF670:01CA612D] Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:11:43 -0000 Hi JP: I'm anxious that the term of the resolution that you propose (remove OCP 0) opens the way to: - 2 implementation that could never interop (no ocp in common) - mandatory config (no working 'out of the box' default behavior) Is that really what this group wants? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) >Sent: lundi 9 novembre 2009 11:59 >To: roll WG >Subject: Re: [Roll] Ticket #10: Closed > >So here is the plan for rev-5. > >First OCP0 will be removed from the core specification. There will no >longer be any requirement >for a node to support OCP0. Various OCPs will be defined in separate >drafts and each node will >be provisioned to support one or more OCPs > >If a node receives a DIO referring to an OCP that it does not support/ >understand, it may join the >DAG as a leaf and log the issue. > >In the absence of comments, we will update rev-05 accordingly. > >Thanks. > >JP. > >On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: > >> Strong consensus towards Option 1. >> >> This closes the ticket #10 and will be reflected in rev-05. >> >> Thanks. >> >> JP. >> >> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: >> >>> Dear all, >>> >>> /co-chair hat off/ >>> >>> We would welcome your opinion on the following issue: >>> >>> Suppose that a DAG is formed that support OFx. A new node willing >>> to join the DAG does not support OFx but OFy. Note that by OF we >>> actually mean the Objective function and the metric. >>> >>> We have two options here. >>> >>> Option 1: The node simply joins the DAG as a leaf. In order words, >>> the node has connectivity since it joins the DAG but will not act >>> as a router for others since it does not understand the OF. Parent >>> selection could be a simply a "random". >>> >>> Option 2: The node joins the DAG and falls back to the "default" >>> OCP. From there is prolongs the DAG but with OF0 (of course >>> inconsistent metrics are not added). This also means that everynode >>> MUST implement OF0 and that the network may compromise nodes with >>> different OF at some point. Several options even more complex have >>> been discussed where one could use common denominator to get as >>> close as possible to the desired OF, allow a node not to be so >>> "altruistic", ... >>> >>> My personal view is that OF management can quick get fairly complex >>> and hard to manage. Option 1 is extremely simple and easy to >>> manage. If a node is mis-configured (does not support the OF of the >>> DAG) it can join it as a leaf in order to have connectivity and >>> send an alarm to fix its configuration. We now just need to specify >>> OF in some document and this is it. >>> >>> Several of you mentioned that they were leaning toward option 1, >>> but could you please express your opinion, we would like to have it >>> solved for the next revision next week. >>> >>> Thanks. >>> >>> JP. >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 9 03:16:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A2228C240 for ; Mon, 9 Nov 2009 03:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.674 X-Spam-Level: X-Spam-Status: No, score=-9.674 tagged_above=-999 required=5 tests=[AWL=0.925, 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 9aSdQ4EBAeHN for ; Mon, 9 Nov 2009 03:16:11 -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 5C27028C23B for ; Mon, 9 Nov 2009 03:16:10 -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: Ak0AAH2J90qQ/uCWe2dsb2JhbACbegEBFiQGqG+WT4IzggsEgWg X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="53944772" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 11:16:22 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9BGL6L014621 for ; Mon, 9 Nov 2009 11:16:21 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:16:21 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:16:20 +0100 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 12:16:19 +0100 References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 11:16:20.0699 (UTC) FILETIME=[108482B0:01CA612E] Cc: roll WG Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:16:12 -0000 Hi Pascal, On Nov 9, 2009, at 12:11 PM, Pascal Thubert (pthubert) wrote: > Hi JP: > > I'm anxious that the term of the resolution that you propose (remove > OCP > 0) opens the way to: > > - 2 implementation that could never interop (no ocp in common) > - mandatory config (no working 'out of the box' default behavior) > Here is another way to look at it. You simply configure an OCP and all nodes willing to participate to a DAG have to implement that same OCP. If you mandate the use of an OCP like the OCP0, that also means that ALL nodes MUST implement OCP0, even if they do not want to implement that OCP. In other words, this is a trivial implementation issue easy to fix: specify the OCP to use on the node. > Is that really what this group wants? > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > JP Vasseur (jvasseur) >> Sent: lundi 9 novembre 2009 11:59 >> To: roll WG >> Subject: Re: [Roll] Ticket #10: Closed >> >> So here is the plan for rev-5. >> >> First OCP0 will be removed from the core specification. There will no >> longer be any requirement >> for a node to support OCP0. Various OCPs will be defined in separate >> drafts and each node will >> be provisioned to support one or more OCPs >> >> If a node receives a DIO referring to an OCP that it does not >> support/ >> understand, it may join the >> DAG as a leaf and log the issue. >> >> In the absence of comments, we will update rev-05 accordingly. >> >> Thanks. >> >> JP. >> >> On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: >> >>> Strong consensus towards Option 1. >>> >>> This closes the ticket #10 and will be reflected in rev-05. >>> >>> Thanks. >>> >>> JP. >>> >>> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: >>> >>>> Dear all, >>>> >>>> /co-chair hat off/ >>>> >>>> We would welcome your opinion on the following issue: >>>> >>>> Suppose that a DAG is formed that support OFx. A new node willing >>>> to join the DAG does not support OFx but OFy. Note that by OF we >>>> actually mean the Objective function and the metric. >>>> >>>> We have two options here. >>>> >>>> Option 1: The node simply joins the DAG as a leaf. In order words, >>>> the node has connectivity since it joins the DAG but will not act >>>> as a router for others since it does not understand the OF. Parent >>>> selection could be a simply a "random". >>>> >>>> Option 2: The node joins the DAG and falls back to the "default" >>>> OCP. From there is prolongs the DAG but with OF0 (of course >>>> inconsistent metrics are not added). This also means that everynode >>>> MUST implement OF0 and that the network may compromise nodes with >>>> different OF at some point. Several options even more complex have >>>> been discussed where one could use common denominator to get as >>>> close as possible to the desired OF, allow a node not to be so >>>> "altruistic", ... >>>> >>>> My personal view is that OF management can quick get fairly complex >>>> and hard to manage. Option 1 is extremely simple and easy to >>>> manage. If a node is mis-configured (does not support the OF of the >>>> DAG) it can join it as a leaf in order to have connectivity and >>>> send an alarm to fix its configuration. We now just need to specify >>>> OF in some document and this is it. >>>> >>>> Several of you mentioned that they were leaning toward option 1, >>>> but could you please express your opinion, we would like to have it >>>> solved for the next revision next week. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 9 03:17:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D580A28C235 for ; Mon, 9 Nov 2009 03:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.696 X-Spam-Level: X-Spam-Status: No, score=-9.696 tagged_above=-999 required=5 tests=[AWL=0.903, 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 ZeC2qztnwLH5 for ; Mon, 9 Nov 2009 03:17:30 -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 39BCF28C223 for ; Mon, 9 Nov 2009 03:17:30 -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: Ak0AAH2J90qQ/uCWe2dsb2JhbACbegEBFiQGqG+WT4Q+BA X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208";a="53945025" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 11:17:55 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9BHttJ015400; Mon, 9 Nov 2009 11:17:55 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:17:55 +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, 9 Nov 2009 12:17:50 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FE03@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #5: DODAG Thread-Index: Acpf29+gSuPDmQxxQziDIkvqKDUczgBSOTZAAAIwJUA= References: <4AF5C26A.30408@acm.org> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 09 Nov 2009 11:17:55.0022 (UTC) FILETIME=[48BD0EE0:01CA612E] Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:17:31 -0000 Hi Julien: In classical terms, an instance really defines a DAG. So if you have multiple roots then RPL partitions that DAG into a set of Destination-Oriented DAGs, also called DAG Rooted at a Destination in the art. All those terms exist with a specific load and the wisdom we hear from Phil and Dave is not to overload / redefine / restrict those terms.=20 The most useful object is the DODAG iteration. A node moves within one and jump between 2. This is the object for which we should find cool name. DODAGI is certainly pronounceable by many of us, but it looks a lot like a WG name in mobility. Any idea? Cheers, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) >Sent: lundi 9 novembre 2009 11:12 >To: Tim Winter; ROLL WG >Subject: Re: [Roll] [roll] #5: DODAG > >Hi Tim, > >My question is: are there DAGs that are not DODAGs in RPL? My feeling is >no. Hence I would suppress the DODAG instead of turning all "DAG" into >"DODAG". >Best, >Julien > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Tim Winter >> Sent: samedi 7 novembre 2009 19:55 >> To: ROLL WG >> Subject: [Roll] [roll] #5: DODAG >> >> Hi Julien, WG, >> >> >> roll issue tracker wrote: >> > #5: DODAG >> > >> --------------------------------+------------------------------------- >> > --------------------------------+------ >> > Reporter: jpv@... | Owner: wintert@... >> > Type: defect | Status: new >> > Priority: major | Milestone: >> > Component: rpl | Version: >> > Severity: Active WG Document | Keywords: >> > >> --------------------------------+------------------------------------- >> > --------------------------------+------ >> > * This is currently being discussed by the RPL Author team * >> > >> > Email from Julien >> > >> > Is there a distinction between DAG and destination >> oriented DAG. From >> > what I read I feel all DAGs are destination oriented. If this is >> > correct I propose to remove the destination oriented DAG concept. >> > >> >> >> The intent for -05 will be to make the unqualifed use of >> `DAG' in the text consistent with `DODAG Iteration', as >> outlined below. So in this use, a `DAG' is a `DODAG' >> snapshotted by a single sequence number -- a `DODAG >> Iteration'. There may be cases in -04 where the text reads >> `DAG' and is in fact referring to `DODAG'- we will be sure to >> clean these up. Here below is some additional explanation >> prepared by the author team- >> >> Does this help to clarify? >> >> Regards, >> >> -Tim >> >> >> >> Instance >> >> >> >> +----------------------------------------------------------------+ >> | >> | >> | (R1) (R2) >> (Rn) | >> | / \ /| \ / | >> \ | >> | / \ / | \ / | >> \ | >> | (A) (B) (M) | (N) ... (X) (Y) >> (Z) | >> | /|\ |\ / | |\ | | >> | | >> | : : : : : : (O) : : : : >> : | >> | / \ >> | >> | : : >> | >> | >> | >> | Instance ID >> | >> | >> | >> >> +----------------------------------------------------------------+ >> >> Instance >> >> >> An Instance is a routing topology over an LLN, optimized for a >> particular objective/application. Discrete Instances may >> also be set >> up to offer optimized connectivity to different destinations when >> appropriate, for example to differentiate a Home Network LLN from a >> Utility Network LLN in a smart metering application where >> a meter may >> be configured to join both Instances. >> >> It consists of one or more Destination Oriented DAGs (DODAGs). >> >> It is uniquely identified by an InstanceID. >> >> Each instance is operated independently of other instances, and RPL >> defines operation over only one instance. Operation among multiple >> instances is to be expanded upon in a future revision or companion >> specification. >> >> >> >> Destination Oriented DAG (DODAG) >> >> >> +----------------+ >> | | >> | (R1) | (R2) (Rn) >> | / \ | /| \ / | \ >> | / \ | / | \ / | \ >> | (A) (B) | (M) | (N) ... (X) (Y) (Z) >> | /|\ |\ | / | |\ | | | >> | : : : : : | : (O) : : : : : >> | | / \ >> | DAGID | : : >> | | >> +----------------+ >> >> DODAG >> >> >> A Destination Oriented DAG is a DAG rooted at a single root node, >> which is a node with no outgoing edges. >> >> In the case where multiple nodes in the LLN coordinate over a >> backbone and expose the same DAGID (to support the same >> DODAG), it is >> conceptually as if there is a single virtual root over the backbone >> (not illustrated). In some applications/implementations >> this may be >> a desired architecture; in other applications each DODAG >> may operate >> with indpendent uncoordinated roots exposing different DAGIDs. >> >> A DODAG is uniquely identified over the LLN by the tuple >> (InstanceID, >> DAGID). >> >> In RPL a node may belong to only one DODAG per Instance at a time. >> >> >> >> DODAG Iteration >> >> >> +----------------+ +-----------------+ >> | | | | >> | (R1) | | (R1) | >> | / \ | \ | / | \ | >> | / \ | ------\ | / | \ | >> | (A) (B) | \ | (A) (C) (B) | >> | /|\ |\ | / | /|\ |\ | >> | : : : : : | ------/ | : : : : : | >> | | / | | >> | Sequence N | | Sequence N+1 | >> | | | | >> +----------------+ +-----------------+ >> >> DODAG Iteration >> >> >> A DODAG Iteration is the DODAG that results from the iterative >> process that reshapes the DODAG as stimulated by the root. It is a >> DAG as constrained by operation of RPL over a fixed >> Sequence Number. >> >> As the root node increments the Sequence Number, different types of >> node movement are allowed (e.g. moving `down') and a new DODAG >> Iteration is formed. >> >> A DODAG Iteration is uniquely identified over the LLN by the tuple >> (InstanceID, DAGID, SequenceNumber). >> >> >> >> Scope >> >> o The scope of an InstanceID is the whole network and it >> defines an >> instance >> >> o The scope of a DAGID is an instance and it defines a >> DODAG within >> that instance >> >> o The scope of a Sequence Number is a DODAG and it defines an >> iteration of that DODAG (DODAG Iteration) >> >> o The scope of a rank is a DODAG Iteration and it defines >> a position >> of a node within that iteration. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 9 03:25:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E200728C222 for ; Mon, 9 Nov 2009 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.714 X-Spam-Level: X-Spam-Status: No, score=-7.714 tagged_above=-999 required=5 tests=[AWL=-1.115, 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 4Mxn-lNTm+on for ; Mon, 9 Nov 2009 03:25:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E010E28C224 for ; Mon, 9 Nov 2009 03:25:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANuK90qrR7Hu/2dsb2JhbADFO5ZPgjOCCwSBaA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="428075659" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2009 11:25:33 +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 nA9BPRju010686 for ; Mon, 9 Nov 2009 11:25:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:25:32 +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, 9 Nov 2009 12:25:27 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphLhFk8yC/YGPRRcufCNg1SDjVOgAAEkAQ References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com> <1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Nov 2009 11:25:32.0004 (UTC) FILETIME=[591EFA40:01CA612F] Cc: roll WG Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:25:08 -0000 >Here is another way to look at it. You simply configure an OCP and all >nodes willing >to participate to a DAG have to implement that same OCP. > Simply configure...=20 In industrial, tools for doing that will certainly exist. What about game boys and McDo toys? Can't they do RPL? >If you mandate the use of an OCP like the OCP0, that also means that >ALL nodes MUST >implement OCP0, even if they do not want to implement that OCP. Yes, that was the goal. Making it fairly simple but implemented in every node so if I buy something from brand A and something from brand B, I'm sure there's at least one OCP that both implement. Doesn't that scare you that we allow for 2 RPL-compliant nodes to be by design unable to talk together whatever the way we configure them?=20 > >In other words, this is a trivial implementation issue easy to fix: >specify the OCP to use >on the node. The OCP must be implemented in the node first. There's code associated to it. It makes sense that an implementation should have a mechanism to add more OCPs over time, and that's what I indicated by calling OCPs plug-ins. Pascal > >> Is that really what this group wants? >> >> Pascal >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of >> JP Vasseur (jvasseur) >>> Sent: lundi 9 novembre 2009 11:59 >>> To: roll WG >>> Subject: Re: [Roll] Ticket #10: Closed >>> >>> So here is the plan for rev-5. >>> >>> First OCP0 will be removed from the core specification. There will no >>> longer be any requirement >>> for a node to support OCP0. Various OCPs will be defined in separate >>> drafts and each node will >>> be provisioned to support one or more OCPs >>> >>> If a node receives a DIO referring to an OCP that it does not >>> support/ >>> understand, it may join the >>> DAG as a leaf and log the issue. >>> >>> In the absence of comments, we will update rev-05 accordingly. >>> >>> Thanks. >>> >>> JP. >>> >>> On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: >>> >>>> Strong consensus towards Option 1. >>>> >>>> This closes the ticket #10 and will be reflected in rev-05. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: >>>> >>>>> Dear all, >>>>> >>>>> /co-chair hat off/ >>>>> >>>>> We would welcome your opinion on the following issue: >>>>> >>>>> Suppose that a DAG is formed that support OFx. A new node willing >>>>> to join the DAG does not support OFx but OFy. Note that by OF we >>>>> actually mean the Objective function and the metric. >>>>> >>>>> We have two options here. >>>>> >>>>> Option 1: The node simply joins the DAG as a leaf. In order words, >>>>> the node has connectivity since it joins the DAG but will not act >>>>> as a router for others since it does not understand the OF. Parent >>>>> selection could be a simply a "random". >>>>> >>>>> Option 2: The node joins the DAG and falls back to the "default" >>>>> OCP. From there is prolongs the DAG but with OF0 (of course >>>>> inconsistent metrics are not added). This also means that everynode >>>>> MUST implement OF0 and that the network may compromise nodes with >>>>> different OF at some point. Several options even more complex have >>>>> been discussed where one could use common denominator to get as >>>>> close as possible to the desired OF, allow a node not to be so >>>>> "altruistic", ... >>>>> >>>>> My personal view is that OF management can quick get fairly complex >>>>> and hard to manage. Option 1 is extremely simple and easy to >>>>> manage. If a node is mis-configured (does not support the OF of the >>>>> DAG) it can join it as a leaf in order to have connectivity and >>>>> send an alarm to fix its configuration. We now just need to specify >>>>> OF in some document and this is it. >>>>> >>>>> Several of you mentioned that they were leaning toward option 1, >>>>> but could you please express your opinion, we would like to have it >>>>> solved for the next revision next week. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Mon Nov 9 03:28:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F0128C1EA for ; Mon, 9 Nov 2009 03:28:52 -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.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq4AspSjFFkj for ; Mon, 9 Nov 2009 03:28:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 9EBEF3A6857 for ; Mon, 9 Nov 2009 03:28:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7SQv-0005YS-RM; Mon, 09 Nov 2009 03:29:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 11:29:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/14 Message-ID: <055.c5c47346603d477241129dd6450f54d1@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #14: Local Repair Mechanism for RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:28:52 -0000 #14: Local Repair Mechanism for RPL --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: Local Repair --------------------------------+------------------------------------------- Dear all, This is one of the important design choice that we need to make. How do we repair a DAG. With the current revision of RPL, repair is purely global and a node having lost connectivity has to wait until the new DagSequenceNumber controller by the DAG root before re-joining the DAG at any rank. This is because, one of the rules states that a node cannot join the DAG at a higher rank without risking a loop. Thus if a node loosing its most preferred parent does not have an alternate, it has to wait for the new DagSequenceNumber if it cannot join a node at a lowest rank. There is I think a good agreement for enhancing this mechanism with local repair. Several approaches have been discussed and we need to choose one. Thanks. JP. -- Ticket URL: roll From jvasseur@cisco.com Mon Nov 9 03:34:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265D43A68B7 for ; Mon, 9 Nov 2009 03:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.688 X-Spam-Level: X-Spam-Status: No, score=-9.688 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE3ThLtYmbrA for ; Mon, 9 Nov 2009 03:34:03 -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 3766E3A69FE for ; Mon, 9 Nov 2009 03:34:02 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208,217";a="53947148" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 11:34:27 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9BYRpx021443; Mon, 9 Nov 2009 11:34:27 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:34:27 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:34:26 +0100 Message-Id: <1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> From: JP Vasseur To: roll@ietf.org In-Reply-To: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> Content-Type: multipart/alternative; boundary=Apple-Mail-92-286391385 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 12:34:25 +0100 References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 11:34:26.0335 (UTC) FILETIME=[979B6AF0:01CA6130] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-16998.006 X-TM-AS-Result: No--29.267400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Roll] [roll] #11: Decision on prefix packing in DIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:34:04 -0000 --Apple-Mail-92-286391385 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Dear all, Here is a proposed resolution. Issue: as of today: there is exactly one prefix per DAO. Thanks to the =20= DelayDAO timer, we may have a chance to perform data aggregation (when possible) but =20 we would still end up with an increasing number of DAO as we get closer to the =20= sink, with the worst case being one DAO per leaf ... As a reminder, here is the format of the DAO message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | DAO Sequence | InstanceID | DAO =20 Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | DAO =20 Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Route =20 Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Prefix Length | RRCount =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 + | | Prefix (Variable =20 Length) | . = . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Reverse Route Stack (Variable =20 Length) | . = . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ We have three options: 1) Option 1 (Trivial packing): we change the DAO message structure to =20= carry more than one prefix in a DAO message. This is of course only possible for prefixes sharing =20= the same route tag, rank. 2) Option 2: we also try to factorize common element. By adopting a =20 flexible encoding, we avoid repeating fields that are identical for a set of prefixes. Back to the =20= example provided below, this would avoid repeating the value of the Reverse Route Stack for each prefix =20 that uses the same recorded path. Thoughts ? Thanks. JP. On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote: > #11: Decision on prefix packing in DIO messages > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=85 | Owner: jpv@=85 > Type: enhancement | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > Currently RPL requires one DAO per message. > > JP's proposal below: > > Hi Jonathan, > > What I was referring to was to pack prefix in DAO, a very light =20 > change in > the spec (just make use of TLV) and factor the common fields. This =20 > allows > to reduce the number of packets very significantly as we get closer =20= > to the > root. > > There two benefits here: > 1) You send one DAO between C and D instead of 3 > 2) You can also pack the Reverse Route Stack whenever possible for all > prefix sharing the same routes. > > Let's suppose that: > 1) X advertises two prefixes X1 and X2 > 2) Y advertises two prefixes Y1, Y2 and Y3 > 3) Z advertised one prefix: Z1 > > Instead of sending 6 DAO, C would send one DAO to D would look like =20= > this: > X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] > > Note that you could when possible also aggregates prefixes at the same > time if they share a common path. > > BAck to you timing question Richard, it depends of the sequence of =20 > events > but there is no need to wait. > C could start with one DAO and then start to pack at it receives =20 > more, the > same reasoning applies to other > nodes. > > Others, thoughts ? > > Thanks. > > JP. > > --=20 > Ticket URL: > roll > --Apple-Mail-92-286391385 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Dear = all, 

Here is a proposed = resolution.

Issue: as of today: there is = exactly one prefix per DAO. Thanks to the DelayDAO timer,
we = may have a chance to perform data aggregation (when possible) but we = would 
still end up with an increasing number of DAO as = we get closer to the sink, with the 
worst case being one = DAO per leaf ...

As a reminder, here is the = format of the DAO message:

        0       =
            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We = have three options:

1) Option 1 (Trivial = packing): we change the DAO message structure to carry more than one = prefix
in a DAO message. This is of course only possible for = prefixes sharing the same route tag, rank.
2) Option 2: we = also try to factorize common element. By adopting a flexible encoding, = we avoid  
repeating fields that are identical for a set = of prefixes. Back to the example provided below, this = would
avoid repeating the value of the Reverse Route Stack for = each prefix that uses the same = recorded
path.

Thoughts = ?

Thanks.

JP.
=
On Nov 2, 2009, at 3:04 PM, roll issue tracker = wrote:

#11: Decision on prefix packing in DIO = messages
--------------------------------+-----------------------------= --------------
Reporter:  jpv@=85 =             &n= bsp; |       Owner:  jpv@=85 =        
=     Type:  enhancement =         | =      Status:  new =          
Priority: =  major =             &n= bsp; |   Milestone: =             &n= bsp; 
Component:  rpl =             &n= bsp;   |     Version: =             &n= bsp; 
Severity:  Active WG Document  | =    Keywords: =             &n= bsp; 
--------------------------------+---------------------------= ----------------
Currently RPL requires one DAO per message.

= JP's proposal below:

Hi Jonathan,

What I was referring = to was to pack prefix in DAO, a very light change in
the spec (just = make use of TLV) and factor the common fields. This allows
to reduce = the number of packets very significantly as we get closer to the
= root.

There two benefits here:
1) You send one DAO between C = and D instead of 3
2) You can also pack the Reverse Route Stack = whenever possible for all
prefix sharing the same routes.

= Let's suppose that:
1) X advertises two prefixes X1 and X2
2) Y = advertises two prefixes Y1, Y2 and Y3
3) Z advertised one prefix: = Z1

Instead of sending 6 DAO, C would send one DAO to D would = look like this:
X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC]

Note that = you could when possible also aggregates prefixes at the same
time if = they share a common path.

BAck to you timing question Richard, = it depends of the sequence of events
but there is no need to = wait.
C could start with one DAO and then start to pack at it = receives more, the
same reasoning applies to other
= nodes.

Others, thoughts ?

Thanks.

JP.

-- =
Ticket URL: <https://svn.too= ls.ietf.org/wg/roll/trac/ticket/11>
roll <http://tools.ietf.org/wg/roll/= >


= --Apple-Mail-92-286391385-- From trac@tools.ietf.org Mon Nov 9 03:37:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B193A69FE for ; Mon, 9 Nov 2009 03:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJNuQo1Fq+dO for ; Mon, 9 Nov 2009 03:37:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 096AD3A68B7 for ; Mon, 9 Nov 2009 03:37:14 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7SZ2-0000iE-9E; Mon, 09 Nov 2009 03:37:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 11:37:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/9#comment:1 Message-ID: <064.29161638b7b52ad308b25c95fd62fa1d@tools.ietf.org> References: <055.6453f7e4084a474e1bfade94efbfbfeb@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <055.6453f7e4084a474e1bfade94efbfbfeb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #9: DEFAULT_DIO_REDUNDANCY_CONSTANT X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:37:14 -0000 #9: DEFAULT_DIO_REDUNDANCY_CONSTANT --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Fixed in RPL Revision -05 -- Ticket URL: roll From alexandru.petrescu@gmail.com Mon Nov 9 03:48:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD863A6A0C for ; Mon, 9 Nov 2009 03:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk-dSh7dzjJz for ; Mon, 9 Nov 2009 03:48:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id B52433A68B7 for ; Mon, 9 Nov 2009 03:48:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA9Bn50O003704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 12:49:05 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA9Bn5fK013465; Mon, 9 Nov 2009 12:49:05 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nA9Bn4Kh011177; Mon, 9 Nov 2009 12:49:05 +0100 Message-ID: <4AF801B0.6070607@gmail.com> Date: Mon, 09 Nov 2009 12:49:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <746F9743-0B67-49C2-87ED-7BB420CD0CEE@cs.stanford.edu> In-Reply-To: <746F9743-0B67-49C2-87ED-7BB420CD0CEE@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] editing of section 3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 11:48:48 -0000 Philip Levis a écrit : > Feedback/comments appreciated. Mostly, do people feel this makes things > clearer? Please note some terminology is in flux (e.g. this text still > uses inward/outward rather than up/down). When trying to make the description clearer... As a side note. I like rfc4101 too, especially because each example it gives is using (1) a topology and (2) a message exchange. I think it would be helpful if section 3 of RPL did so too. A simple and meaningful topology is very important. Meaningful i.e. one can easiliy put addresses on it and have a clear idea about its subnet structure. I.e. I can go to the lab now and do it. This topology is missing from RPL document current. It draws topologies in the appendix but they are not understandable (to me), because I don't see where and how could I put addresses, how many interfaces, etc. The (2) message exchange is completely missing from the current RPL document. Something like this, quote from rfc4101: > Client Server > ------ ------ > <-- Change L(CCID, 3 2) > Confirm R(CCID, 3, 3 2) --> > * agreement that CCID/Server = 3 * Alex > > Phil > > > 3. Protocol Model > > The aim of this section is to describe RPL in the spirit of > [RFC4101]. Protocol details can be found in further sections. > > 3.1 Overview > > Each RPL instance constructs a routing topology optimized for a certain > Objective > Function (OF). An instance may provide routes to certain destination > prefixes. > A single RPL instance consists of one or more DAG roots. These roots may > operate independently, or may coordinate over a non-RPL backchannel. > Each root > has a unique identifier, such that nodes can identify the root of a route. > > 3.1.1: Multipoint-to-Point Traffic > > Multipoint-to-Point (MP2P) is a dominant traffic flow in many > LLN applications ([I-D.ietf-roll-building-routing-reqs], > [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]). The > destinations of MP2P flows are designated nodes that have some application > significance, such as providing connectivity to the larger Internet or > core private IP network. RPL supports MP2P traffic by allowing MP2P > destinations to be DAG roots. > > 3.1.2 Point-to-Multipoint Traffic Flows > > Point-to-multipoint (P2MP) is a traffic pattern required by several > LLN applications[cite]. RPL supports P2MP traffic by using a destination > advertisement mechanism that sets up routes toward destination prefixes > and > away from roots. Destination advertisements can update routing tables as > the underlying DAG topology changes. > > 3.1.3 Point-to-Point Traffic Flows > > RPL DAGs provide a basic structure for point-to-point (P2P) traffic. > For a RPL network to support P2P traffic, a root must be able to > route packets to a destination. Nodes within the network may also > have routing tables to destinations. A packet flows towards a root > until it reaches a node that has a known route to the destination. > RPL supports the case where a P2P destination is a `one-hop' neighbor. > > RPL neither specifies nor precludes additional mechanisms for > computing and installing more optimal routes to support arbitrary P2P > traffic. > > 3.2. DAG Construction and the DAG Information Object (DIO) > > RPL creates minimum cost routes to DAG roots. RPL nodes construct these > DAGs through DAG Information Object (DIO) messages. > A DIO identifies the DAG root, the Objection Function (OF) of the DAG, > the position of the transmitter within the DAG, and other routing > information. RPL uses DIOs to establish and maintain routes. RPL > adapts the rate at which nodes send DIOs. When a DAG is inconsistent > or needs repair, RPL sends DIOs more frequently. As the DAG > stabilizes, the DIO rate tapers off, reducing the maintenance cost > of a steady and well-working DAG. > > 3.2.1 Grounded and Floating DAGs > > DAGs can be grounded or floating. A grounded DAG that offers > connectivity to > to an external routed infrastructure. A floating DAG offers no such > external connectivity, and provides routes only to nodes within the DAG. > > 3.2.2 Objective Function (OF) > > The Objective Function (OF) conveys and controls the optimization > objectives of route selection within a DAG. The Objective Function > defines the cost function a RPL instance uses to compute minimum > cost routes. Examples of simple optimization > functions include minimizing latency, maximizing throughput, or > minimizing energy spent. An Objective Code Poiint (OCP) specifies > the Objective Function of the DAG. Further details can be found in > [I-D.ietf-roll-routing-metrics]. > > This document describes a default OF, OF0 (designated by OCP value of > 0x0000). > OF0 may be used to d code efine RPL behaviors in the case where a node > encounters a > DIO message containing a point that it does not support, if allowed by > policy. [I-D.ietf-roll-routing-metrics] contains additional OFs. > > 3.2.3 Administrative Preference > > An DAG instance may specify that some DAG roots should be used over others > through an administrative preference. Administrative preference offers a > way to control traffic and engineer DAG formation in order to better > support application requirements or needs. > > 3.2.4 Distributed Algorithm Operation > > A high level overview of the distributed algorithm which constructs > the DAG is as follows: > > o Some nodes are DAG roots, with associated administrative preferences. > > o Nodes advertise their presence, DAG instance, and routing cost > with DIO messages sent to the link-local multicast address. > > o Nodes listen for DIOs and use their information to join a new DAG, > maintain their position within an existing DAG, or improve their > position within an existing DAG as according to the DAG's Objective > Function. > > o The nodes provision routing table entries for the destinations > specified by the DIO towards their DAG Parents. Nodes may > provision a DAG Parent as a default gateway. > > o RPL supports both global and local DAG repair. Each DAG root > maintains a sequence number. Incrementing this sequence number > institutes a global repair, allowing nodes to choose an arbitrary > new position within a DAG. > > o Nodes may locally repair or change the topology, moving within > the DAG without requiring a global repair event. The OCP > specifies the limits of this local repair. > > o Using both DIOs and possibly information in data packets, > RPL nodes detect possible routing loops. When a RPL node detects a > possible routing loop, it adapts its DIO transmission rate to > quickly apply these local repair to the topology. This process > and its limitations is discussed in greater detail in 3.4. > > 3.3 Outward Routes and the Destination Advertisement Object (DAO) > > RPL uses DIO messages to establish Inward routes from nodes within the LLN > to DAG roots. It uses Destination Advertisement Object (DAO) messages > to establish Outward routes from DAG roots to nodes within the DAG. DAO > messages and Outward traffic are an optional feature for applications > that require P2MP traffic. DIO messages advertise whether a DAG > instance supports DAOs. > > 3.3.1 Destination Advertisement Object (DAO) > > A Destination Advertisement Object conveys destination information > so that a root (and other nodes within the network) can establish Outward > routes. A DAO message includes prefix information to identify > destinations, > reverse route information to record routes, and information to > determine the > freshness of a particular advertisement. Nodes send DAOs Inward towards > DAG Roots. > > Nodes that can maintain routing state may aggregate routes they > received in the DAOs they transmit. Nodes that cannot maintain > routing state forward DAOs toward the DAG Root and adds > the next-hop address to a Reverse Route Stack carried within > the DAO message. > > 3.3.2. `One-Hop' Neighbors > > In addition to sending DAOs toward DAG roots, RPL nodes may periodically > emit a link-local multicast DAO message advertising available > destination prefixes. This mechanism allow provisioning a trivial > `one-hop' route to local neighbors. > > 3.4. Loop Detection and Limiting Local Repair > > RPL nodes maintains route cost information within a DAG. Because links > may fail or change over time, nodes can move within a DAG. If routers > only move Inward, the DAG remains consistent. However, if a router moves > Outward, it can create a routing loop. RPL embeds information in data > packets that enable it to quickly detect potential loops and locally > repair > the DAG. A data packet includes the route cost metric of the transmitter: > if a router receives a packet from a router that advertises a cost lower > than its own, there may be a routing loop. > > Allowing nodes to move Outward can, in the case of a Floating DAG, > lead to the count-to-infinity problem, where nodes continuously move > Outward as they search for a route to a DAG Root. > RPL allows a DAG Instance to specify the amount of local repair a > router may > apply. If a router is unable to find a valid route after this amount of > repair, > it marks itself as Floating until the DAG Root applies a global repair by > incrementing its sequence number. If the local repair limit is zero, then > a router cannot move Outward without a global repair. If the local repair > limit is infinity, then routers may locally repair freely and can suffer > from the count-to-infinity problem. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Mon Nov 9 03:54:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CFA3A6A0A for ; Mon, 9 Nov 2009 03:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8snHAlil8etE for ; Mon, 9 Nov 2009 03:54:42 -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 579843A68B7 for ; Mon, 9 Nov 2009 03:54:42 -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 nA9Bt5av002149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 12:55:05 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA9Bt4UU014474; Mon, 9 Nov 2009 12:55:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nA9Bt4bI012702; Mon, 9 Nov 2009 12:55:04 +0100 Message-ID: <4AF80318.9060009@gmail.com> Date: Mon, 09 Nov 2009 12:55:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tzeta Tsao References: <4AB6C0A2.1010109@ekasystems.com> In-Reply-To: <4AB6C0A2.1010109@ekasystems.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] [Fwd: New Version Notification for draft-tsao-roll-security-framework-01] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:54:43 -0000 Thanks for posting this draft. My comment now is that since we know now that RPL Control Message is probably going to be an ICMP message - could we use IPsec on it? Should we recommend the use of IPsec for RPL? AH/ESP? Alex Tzeta Tsao a écrit : > WG, > > We have posted draft-tsao-roll-security-framework-01, which should be > available from the repository shortly. > > The one major change is the addition of Section 6.5 for design guideline > purposes, while some words were added to the beginning of Section 6 for > context.There is a minor change at the end of Section 3.1 to address the > concern raised in IETF75 about the discussion of physical security. > Another minor change is at the beginning of Section 3.3 to update cited > drafts. > > We appreciate your input and please comment to the list. > > Thanks, > Tzeta > > ------------------------------------------------------------------------ > > Sujet: > New Version Notification for draft-tsao-roll-security-framework-01 > Expéditeur: > IETF I-D Submission Tool > Date: > Sun, 20 Sep 2009 16:43:55 -0700 (PDT) > Destinataire: > tzeta.tsao@ekasystems.com > > Destinataire: > tzeta.tsao@ekasystems.com > Copie à: > roger.alexander@ekasystems.com,mischa.dohler@cttc.es,vanesa.daza@upf.edu,angel.lozano@upf.edu > > > A new version of I-D, draft-tsao-roll-security-framework-01.txt has been successfuly submitted by Tzeta Tsao and posted to the IETF repository. > > Filename: draft-tsao-roll-security-framework > Revision: 01 > Title: A Security Framework for Routing over Low Power and Lossy Networks > Creation_date: 2009-09-20 > WG ID: Independent Submission > Number_of_pages: 34 > > Abstract: > This document presents a security framework for routing over low > power and lossy networks. The development of the framework builds > upon previous work on routing security and adapts the security > assessments to the issues and constraints specific to low power and > lossy networks. A systematic approach is used in defining and > assessing 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. > > > > The IETF Secretariat. > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 9 04:08:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C356B3A6A0E for ; Mon, 9 Nov 2009 04:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8lANFCK1Ppk for ; Mon, 9 Nov 2009 04:08:10 -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 4E7BD3A6A19 for ; Mon, 9 Nov 2009 04:08:10 -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: AlMAADmV90qQ/uCWe2dsb2JhbACCJiuZKQEBFiQGqH+WVIQ+BA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="53950702" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:08:35 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9C8Zsd002262 for ; Mon, 9 Nov 2009 12:08:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:08:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6135.5CD058A4" Date: Mon, 9 Nov 2009 13:08:32 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FE60@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAG sequence in DAO Thread-Index: Acpe7oT0pR4k8th8QauYsvau9q9DjQCRAKlw References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "roll WG" X-OriginalArrivalTime: 09 Nov 2009 12:08:35.0491 (UTC) FILETIME=[5CFFCF30:01CA6135] Subject: Re: [Roll] DAG sequence in DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:08:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6135.5CD058A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien; =20 The sequence in the DAO is not the DAG sequence but the DAO sequence. At the moment we do not check that the child is on the same DODAGI as the parent though we certainly assume that it is... =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 6 novembre 2009 15:36 To: roll WG Subject: [Roll] DAG sequence in DAO =20 Hi all, =20 for now the DAO does not contain the DAG sequence. Because a DAG with a different dag sequence is a different DAG, does it make sense for a parent to process a DAO from a child which is in another DAG? =20 Best, Julien ------_=_NextPart_001_01CA6135.5CD058A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien;

 

The sequence in the DAO is not the DAG sequence but the = DAO sequence. At the moment we do not check that the child is on the same = DODAGI as the parent though we certainly assume that it = is…

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: vendredi 6 novembre 2009 15:36
To: roll WG
Subject: [Roll] DAG sequence in DAO

 

Hi all,

 

for now the DAO does not contain the DAG sequence. Because a DAG with a = different dag sequence is a different DAG, does it make sense for a parent to = process a DAO from a child which is in another DAG?

 

Best,<= o:p>

Julien=

------_=_NextPart_001_01CA6135.5CD058A4-- From pthubert@cisco.com Mon Nov 9 04:12:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28AC3A6A19 for ; Mon, 9 Nov 2009 04:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.209 X-Spam-Level: X-Spam-Status: No, score=-9.209 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCbKK1091y2k for ; Mon, 9 Nov 2009 04:12: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 0806F3A68B7 for ; Mon, 9 Nov 2009 04:12:27 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.emz, image002.png, oledata.mso : 7680, 9650, 48052 X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="mso'?scan'208,217,50,150?png'208,217,50,150,150?emz'208,217,50,150,150,50"; a="53951157" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:12:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CCrEv003547; Mon, 9 Nov 2009 12:12:53 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:12:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA6135.F642F210" Date: Mon, 9 Nov 2009 13:12:46 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FE68@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency Thread-Index: AcpYj7JQFyo/Efk5TGCsU8TR9EHlJgAFM81gAACbBYACIN3qsA== References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , , X-OriginalArrivalTime: 09 Nov 2009 12:12:52.0975 (UTC) FILETIME=[F678BFF0:01CA6135] Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:12:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6135.F642F210 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6135.F642F210" ------_=_NextPart_002_01CA6135.F642F210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien: =20 For me a validation is at least a bidir. NUD is a revalidation. =20 =20 What do you think? =20 Pascal =20 >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: jeudi 29 octobre 2009 15:55 >To: Pascal Thubert (pthubert); wintert@acm.org; jpv@cisco.com >Cc: roll >Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency >=20 >Hi Pascal, >=20 >What I was trying to achieve is the validation. I was trying to see if standard ND (let's not diverge) can >achieve this. With a LLAO, the entry would be created (STALE), then the first time you want to route a packet >through the router that originated the DIO, you would send the packet, arm a delay timer... do NUD as usual. >=20 >Comment on this: >- depends on 6lowpan discussions... >=20 >questions: >- do we think this is enough? >- otherwise do we need to specify a custom mechanism inside RPL? >=20 >Best, >Julien >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Pascal Thubert (pthubert) >> Sent: jeudi 29 octobre 2009 15:46 >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll >> Subject: Re: [Roll] [roll] #7: RPL bootstrap question: >> neighbor cache andDIOs dependency >>=20 >> Hi: >>=20 >> In fact a stale entry is not sufficient. We need an entry >> that is reachable. >>=20 >> That is the minimum validation process that comes with the >> fact that the draft as it stands today depends on NS/NA flows >> to ensure bidir connectivity with the neighbor. The way I see >> it, the node should at least unicast NS to the candidate to >> assert that. In the same fashion as NUD allows the node to >> remove the parent. But if a stronger validation mechanism is >> in place, then that should supersede the NS/NA. >>=20 >> Soon enough we might need to elaborate a bit on the >> validation process. In some environments, it can be done as >> part of metrics computation, like using srcr results for >> instance. Things like that cannot be in the base spec but >> then, do that belong to metrics, a new draft, or should >> validation above and beyond NS/NA be left to implementation? >>=20 >> Pascal >>=20 >> >-----Original Message----- >> >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] >> On Behalf Of >> >roll issue tracker >> >Sent: jeudi 29 octobre 2009 13:02 >> >To: wintert@acm.org; jpv@cisco.com >> >Cc: roll@ietf.org >> >Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor >> cache and >> >DIOs dependency >> > >> >#7: RPL bootstrap question: neighbor cache and DIOs dependency >> >--------------------------------+---------------------------- >> ---------- >> >--------------------------------+----- >> > Reporter: jpv@... | Owner: wintert@... >> > Type: defect | Status: new >> > Priority: major | Milestone: >> >Component: rpl | Version: >> > Severity: Active WG Document | Keywords: >> >--------------------------------+---------------------------- >> ---------- >> >--------------------------------+----- >> > Email From Julien >> > >> > Hi all, >> > >> > as explained in section 5.4.2 of RPL, a DIO must not be >> processed if >> > the source is not in the neighbor cache. The question is how do we >> > expect the neighbor cache to be filled? >> > topology: >> > A >> > | >> > B >> > B receives a DIO from A, A is not in B's neighbor cache: >> > >> > NS/NA exchanges will probably not occur, as B has no good reason to >> > send packets to A (A is not a router for B, B has most of >> the time no >> > data to send to A) RS/RA exchanges: do we expect to send RAs in RPL >> > environments? Would this be enough? >> > If there are no frequent RAs, or unsolicited NAs, then A >> will likely >> > never be in B's neighbor cache. >> > >> > One way to solve this would be to allow SLLAO option in DIOs. >> > Processing this option in ICMP messages (NS, RS, RA) is a >> well known >> > process, and would create an entry in the neighbor cache, >> state STALE. >> > >> > what do you think? >> > >> > Julien >> > __________ >> > >> >-- >> >Ticket URL: >> >roll >> > >> >_______________________________________________ >> >Roll mailing list >> >Roll@ietf.org >> >https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 ------_=_NextPart_002_01CA6135.F642F210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien:

 

For me a validation is at least a bidir. NUD is = a revalidation.

 

What do you think?

 

Pascal

 

>-----Original Message-----

>From: Julien Abeille = (jabeille)

>Sent: jeudi 29 octobre 2009 = 15:55

>To: Pascal Thubert (pthubert); = wintert@acm.org; jpv@cisco.com

>Cc: roll

>Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency

> 

>Hi Pascal,

> 

>What I was trying to achieve is the = validation. I was trying to see if standard ND (let's not diverge) can

>achieve this. With a LLAO, the entry would = be created (STALE), then the first time you want to route a packet

>through the router that originated the DIO, = you would send the packet, arm a delay timer... do NUD as usual.

> 

>Comment on this:

>- depends on 6lowpan = discussions...

> 

>questions:

>- do we think this is enough?

>- otherwise do we need to specify a custom = mechanism inside RPL?

> 

>Best,

>Julien

> 

>> -----Original = Message-----

>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On

>> Behalf Of Pascal Thubert = (pthubert)

>> Sent: jeudi 29 octobre 2009 = 15:46

>> To: wintert@acm.org; = jpv@cisco.com

>> Cc: roll

>> Subject: Re: [Roll] [roll] #7: RPL = bootstrap question:

>> neighbor cache andDIOs = dependency

>> 

>> Hi:

>> 

>> In fact a stale entry is not = sufficient. We need an entry

>> that is reachable.

>> 

>> That is the minimum validation process = that comes with the

>> fact that the draft as it stands today = depends on NS/NA flows

>> to ensure bidir connectivity with the = neighbor. The way I see

>> it, the node should at least unicast NS = to the candidate to

>> assert that. In the same fashion as NUD = allows the node to

>> remove the parent. But if a stronger = validation mechanism is

>> in place, then that should supersede = the NS/NA.

>> 

>> Soon enough we might need to elaborate = a bit on the

>> validation process. In some = environments, it can be done as

>> part of metrics computation, like using = srcr results for

>> instance. Things like that cannot be in = the base spec but

>> then, do that belong to metrics, a new = draft, or should

>> validation above and beyond NS/NA be = left to implementation?

>> 

>> Pascal

>> 

>> >-----Original = Message-----

>> >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]

>> On Behalf Of

>> >roll issue tracker

>> >Sent: jeudi 29 octobre 2009 = 13:02

>> >To: wintert@acm.org; = jpv@cisco.com

>> >Cc: roll@ietf.org

>> >Subject: [Roll] [roll] #7: RPL = bootstrap question: neighbor

>> cache and

>> >DIOs dependency

>> >

>> >#7: RPL bootstrap question: = neighbor cache and DIOs dependency

>> >--------------------------------+----------------------------

>> ----------

>> = >--------------------------------+-----

>> > Reporter:  = jpv@…          &n= bsp;    |       Owner:  = wintert@…

>> >     = Type:  defect           &= nbsp;  |      Status:  new

>> > Priority:  major           &n= bsp;   |   Milestone:

>> >Component:  rpl           &nbs= p;     |     Version:

>> > Severity:  Active WG = Document  |    Keywords:

>> >--------------------------------+----------------------------

>> ----------

>> = >--------------------------------+-----

>> > Email From Julien

>> >

>> > Hi all,

>> >

>> > as explained in section 5.4.2 of = RPL, a DIO must not be

>> processed if

>> > the source is not in the neighbor = cache. The question is how do we

>> > expect the neighbor cache to be = filled?

>> > topology:

>> > A

>> > |

>> > B

>> > B receives a DIO from A, A is not = in B's neighbor cache:

>> >

>> > NS/NA exchanges will probably not = occur, as B has no good reason to

>> > send packets to A (A is not a = router for B, B has most of

>> the time no

>> > data to send to A) RS/RA = exchanges: do we expect to send RAs in RPL

>> > environments? Would this be = enough?

>> > If there are no frequent RAs, or unsolicited NAs, then A

>> will likely

>> > never be in B's neighbor = cache.

>> >

>> > One way to solve this would be to = allow SLLAO option in DIOs.

>> > Processing this option in ICMP = messages (NS, RS, RA) is a

>> well known

>> > process, and would create an entry = in the neighbor cache,

>> state STALE.

>> >

>> > what do you think?

>> >

>> > Julien

>> > __________

>> >

>> >--

>> >Ticket URL: <http://rsync.tools.ietf.org/wg/roll/trac/ticket/7>

>> >roll = <http://tools.ietf.org/wg/roll/>

>> >

>> >_______________________________________________

>> >Roll mailing list

>> >Roll@ietf.org

>> = >https://www.ietf.org/mailman/listinfo/roll

>> = _______________________________________________

>> Roll mailing list

>> Roll@ietf.org

>> = https://www.ietf.org/mailman/listinfo/roll

>> 

------_=_NextPart_002_01CA6135.F642F210-- ------_=_NextPart_001_01CA6135.F642F210 Content-Type: application/octet-stream; name="image001.emz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.emz Content-Location: image001.emz H4sIAAAAAAACC+1dC3hU1Z0/CQkM4eEQCIYQ0kkaSEiQL8UkJvLIjSSBhEcCRApKEREt8ioGbHhY HCt2dWvdYMVHpZpa/VSku1ZRWGFbpOpSl1oVLb72kxZdX60LroL2U9nf7977v3MyzjPMZKbdPfrj /M+5533+r3vvmZsUpdQK4JQddvdT6lkXMuxwzTeUqh2plKd+RoNSKWrpz5X6MlWpXlLAjvsNVipr uFLPIT0qpevFolG91D9sSFNoQI0BPACaK00xUlQuaDeQ6t73OiI1D20TLOsF1gIsm2ekq/6gGb5m 9HLoMiPVrJ9mXvHW5Bt9nGsFRppDlxhKFaJMtl3OjPzoNEM55fNxjcvAPt2AhAIQzONycYzPY65P ARxjqeGrn2f09rWljV2fRyRj0ucTSfvjMAZZUwzPCt7x9aqzf/3p9K2P9eHUHdXStE7Hqow+z1i1 mWEor+w/9w5b5oR9P+g3zdP0QpPs+WJc4R6zDOsQCJOsqCsNVlUQD9lrr9AusO9c5JcB7I9BZCsd eZ+f4n/TG/Z+i7BSUrcP6gqNoua47THUIi3BoTkGf75sQWYdQL6MZA3jsebJ0C+Wr0YWjPRrU86b rNSd5+ljS7YyukzpdE+OOZAuFPmgfnEB0wADKAPI0x4gxYYbsQThe//015HhMTMD75FP9gJfT0Nd yqnbbMP6J8MvPRvp1RgUx9UIGbRKWf92MBMhTaUV1Ko2dbm62LSFV2cOVuW/HawOPH1ovDFoQy/v qCEUSUOpBfvVkWH1ynsDeAh6/5bHUll2Acoq9XL6kn+10PnjAelXAZC+3uziwDODVdqNL4x/CzHT byBeiuukb0Q85J2Xx6/74RnpN975WCrnNPUfz+Byik4xbe3Oxbeptaj3RvsL43nN9fv+6ev+8OJ4 ximHD5l5dy463v6U94ur1TFAC7Tn96Lukfbj7VAJakpd4+S9SC+84H/aGa8u/Khdqc50I+UuE7zu +vfB6syzP2qnDtnxpjUejpdzfnTn8fayoo/a9f6WfNdkCUcXsuxQgPuTDWTaNPOZZj5Caiv++Rwo x4UFiD/pq1QRaI5TQhuIR4ARwHTJtGNTseKf65Fuwf61qUvVKngNHpS8XF2G1CVqPbAClEcVqzXI XalWI82rlyN3iRqN8htQ/zJgoh2TPtsG6dEazXFeCDBmPq+PA1hX8m6383ld6kpZ6Ud0/EAwVzHK 9Qcw9S66vMDO5zwbQB9DgbcAf70eKx2m6xudLjGC+09/LzpVn69Ol2Lu3BsGfR30MjodSZkMw+eP HD2yx/RHFr3666aDI+9uOnJyW2PnqzWN+ejPBSwGhDd8OjG4P1KE8tkAeYlhz5GjZiz8xnyh0b7j pwxE4p97K7Wzr1K/hMajErrCWFtxhXHtxM4ZBOm1FVKXSlFoFI3ITyEPbwM6APKwy1CpBuhyQO4B rqcSZFj9TEOqRWn6wFsj5e6/94ZTLiOl1wSUKQOYL1VlLeed+Y65poxV/q4m5jNWKSnXZBkp2r2D gnaIbp0vQvkqgOvJmEFilZrirP8N995vXbT/lTVjPdkrmaeUlTLMp3Xh/pOmoncBwwE30GzgHqkC 90ygiwEJohd7IaPZWFyx0JhTsRqoRNoNdM5Qak6Yeo/MmFPx5IzFwFqn3pOody0UXaj+npyxdeIj M+4Fv9w7UfpbbcAGham30Lh3YrOxFbh2Iop2mefNqM9+5yO/CpAg8wQvqtXGxejz4ombwKubMObO GVsx560VN4NnpT3yigugU5hNGokHwfNPgOcfRyOy1rqMoJjD5ygSEZ8XoxL3jO0U2LTo8FeQeRDw 1+G6DtHpeOifEiO4Pl/+H6n1oy88UpfMZfT10emeHHMa1pB7zJAPuLQ4105PQ2wAZUA64AGw9Sbc iCVE6yPLHvnsQVcfWa5TH3KMbukIcSgf+TEwqVZUdXCwCOF85Kqx+6Fq9hlKPfwkrMhkpY6cx3pd fWTmRBYaahunj8lt8bB0GXzULzEuYvDw/KXTHx6QDnF1gnvrY6nMT5SPTFmOl4+MKZs+8jrMdhEY rC8U0MWY/IWIU50VsHzVRqSRHdRHXoBrU+HxroDP61FXwgtuU9TPJcAgO6b+Y5oQGxQP/1T4M1p5 1WVdp6NtB2qcJsAO3prujidW7ehz0Wl9Xnq+TsfDPmQYX/VPj3yS29iReoHjnxZj9ahbyIf5gAtY DDAPImE+N6N+whrR/NrBR7NeEZANCC/7+6rMFz5E+46v+iLyfwzlth4FboVipW4tGlDZWDSgdf51 RQTpykapC7lwbDiKajbcW4u0HXw0+20AtgEdgOWrpqYaoMsB8UGj81V7BfRVZV2fb/vAXF/GV32+ uYn5jC1ftZfjq3Js+tpzjcOts/iqrFsFMEgcia/KerJX3FsGf1+V+eI/sby/r/o2GKMSSmoernH8 EqDjzAADot7un9nYa8DHU4sA6iY3cB06/nhq6Hrbiz6eeqAos/EA9l3qHUC9OfND1ztQtG7+9qJb wS+3zpd6RQPAU2Hq9Rpw6/y3+68D5swX31J88mWoz37xv2+NQcs8wYvg1UHoc9D8yUVzgMrG64rW g1/XNy4Dz0p7E1DOBYiv+jvQN4HnN2Fx7wTDy1pz3YXPQTp8jn4i4nPuBWWWe1Zg0xwr+T/ZfdUF X79icsZn20L6qokuo+tqnS4xgvvgsR5zGvriHjPkA+QriXPtdLx8VZmLpqe62F65DtY2x+hGLCGY r0pe7a6v+tLBlyE9hftNX9X7n5Nj5KtSdBTn8Pfoq3K9hwLkoWwg06ape5hmPlSG6atuBv0J8CEW 43xUNLDarC+Ba9QI9AWmS6Ydi45chLTPV12ivqPa8VwX9gMI5q9W2NdGIuZ4dL+V/RfY+exDp6nn jmEikTxXFV6NVnZ1udfpaNuBSg8oO4lqR5+LTuvj0fN1utSw9gnLryIpH0mZDOOrfmuZZ1dj5xN/ apTnqsXoj/xB3hUduFjLKwRNYK1piu3go8lLcC1MvmcbDP5+K/OFD11oaC7SZcAHuLAIDdwMZ+cS AKKh9uQNHLUnr7RyWDVBeuAoqUsbLjSKRmTPyc/bgA7A8lvTUg3Q5UD3/Nb0gH6rrKurf0kT15fx 7jn5TcxnbPmt6Y7fmob+9bXnGhOh1ln8Vq5nlVnWF0fit7Ke7BX3jcHfb2W++FKk/f3W9XnQJaNC +5Hr894feVvewZF7gEq04QaGVeM5HzZvHmjOW4LoOGy/mlR9cOSC6veBgaOk3gLUK0UiVL0F1S2V k6pXgV9WVUq9PRjnqjD1bstbVbk+rwUorRQ/U/zWL1Gf/c7HuGStOWYZL3gRvPpexbDq9yoOV5VW Hq4aOGpY9Szw66xRX4Jnpb0JKOcCxG/9L2zChVjY2zDhpYCsNfdG522hyfMab9SimB263p9xTUWO C2yaY20AvRT9LQCS9Rnrz+9IrXtpUEFIvzUpy2ypCj/mWJXxWx/dduh0iRHcj471GqahL/IcQz5A Ppc4107Hy4+WuWiy0cUXkOtpGAfH6AYkBPOjKYPd9aNzn6Mf/cCT1jPfQ5Nj5EebJoFzSGY/mrol 3s98N2MNCtDPTcBK6M0jiPG/E7JBNQJ9gelOrkWIzl6E5Ew8823HyUsPPOjvAB7kQc2bfvQ3EGfZ oF8toI4Wfaz70SnILwDIX+xDp6l3dwCdgL/ehUoPyKsxkd0I9U3CZRfjJHObDB5oPXCdfN8jsvvo i5BdVWvdA+8IIrvH22ffd7yd71ZceAczCBU8xidmurN8W/ocpH0hRQ1BgvzB9zUMu9WWq5bedFf6 50jXgp7aZ6j6FuIPh2ecWI38RL2v6cTY/GX3z8/1T+dZqtM90wSRMO+Br0IfNRDWd4GJvZQ6FwDp hApQlF3aj+lOrkWI7C5A8lK1DqeU1uCE0uWQ3G+b8kn+4V6MArJsWuR2JNLkn2hkdieY7gEgIpmN RNaS0G7HRM/4zSugTotkfWJVxm88uk+k0/rc9XydLjUsvgHrxOxePBn69d+joSfPqB/S9kRIHzYp yzzydPgxx6qM3/rofKLT+v7Ge50TabuFH6h3iWBzhQrtEdvt3XEItrt8v+V375oc2O+Ozna7MfYI bffJRNpu2ql42W4sgXPW4pRLqdewypm4cRrTu6vtRjnTdvN5SCjbXWeetbgY5495ytjnc9N2017T Vp+O3d6B+p1AOLst/BsTeY1QxyRcXjFOyioRUF5xHazUM/I6kPfJtrx6D/S0vH6aSHntxBrHW143 ow/KaznktALy+oMg8hruPnmOKa/8xQC9bd4pW+f6KaMis6NAZ2lpkeNofe5CMF82EJHsRiJzSWiz Y6Jv/OYVTJbD9hXJGkZSxm88uj+k0/p49Hyd/r/ic79/UUfdi5dUh/RfE11G3xed1vfRn/diPeZE 2kyZSyF0GxFsrlBZPWIzqx7n8ynxcW+Jic0cgrFH6ON+lkibSbsQb5u5DmtxLfr5Mx5KtWClJ/k9 n8LliHzcy/Cbu8txovhK85d3lm0Ueyk2cxja6q6dPIYNi+RchvBvtPKqy7pOR9tOMHlJVDv6XHRa H4+er9PxsEsZxlfPZSw6mdvl927F4BP6UXxOmg+4gMUA8yi3hTaw1mHPZbANBv9zGcwfCbBNtO+c y5gG/udv3z6CTPwSN3YQCbWz/N1lO8vTN2Y2E6TfXSZ1+Y5aaBT1amOrRdoOXd9XNyB3G9AB0O9z Gb1TDdDlQPfOZfQJeC5D1rVlzXJzfRmbv33Devt++9bHOZeBaTvnMrg+2lyCrrOcy2D5KoBB4kjO ZbBeEZANcG8Z/M9lMH8wIDzhfy6jDQv37rLQ5yTayn+zrKP8Puzdfcsq0ZYbyGxW6r4w9c5pvm/Z +c2/Ad516p2PeukbQ/d3fvPojec0TwG/TNko/e3EOKeEqddRPmVjW/loIH2jnKMYbo/3JOqz3/lI O2sMWt4T8DnEzvL9GzKb9294fmb6xudnvrsss7lk+c7ykuUnwbPS3gSUcwF8Ecd1bwDP87dvJ9O6 89s3H2+D/R2e574WA7JnBTbNsTaATvbzxJ7vXVAX7rdviS6j62qdLjEs2eXeYk+4zXbw1sR6zGmG tcfsIB9waXGunZ6G2ADKAOpTD0CZJtyAhGh/+yZzKUQDRLC5gq1NPnSziB0yELslgXg2sBoDIt92 9xzEtl30VTtqrXep90wO/DxW6zQMaf/2jS6T4hyS4xzEPQG/D9Hd375xvYcC1BPk10ybJm8wzXyo DOd57IPQVfztG3/z4//bNzJ6I0A9OB3Qg+jIBci8xPRS5QsR1vtTLjL9U4I0kQWIbdffo3LMBYA9 tq+cfbgFY7weCPdMR/i3xIhOXnVZ1+lo2wkmL4lqR5+LTuvj0fN1uhRryP1giKR8rMrEu1//PXrv ih/V3bj7jpDPUBJdRt8XndbXPN7zSqRdkvWnTSKCzZU6nTzrBiRkgHBLAvFs4HTt0ktP6+8dPg9i l07/PeG6E9kqwBmfz73Ij/8Zn8B2iXq4O89QqOPD2SUUMe3SLSBWYDNfAjJ6w57AC2B9PTQiwb2e rmeCFru0BPRsvHf4rvntqcvxnvBi5+1DJa7RHtEWMR5kgzRBO8U8SXfHZkX6HkJ4O1pZ1vWATkfb TjBZSlQ7+lx0Wh+Pnq/T8bYdel86He9+/feo/12v1oU7a5OUZcK8BzLHHKsy3XifFO91TqQNFX4o hF4jgs0VKrdHbOjuJ3UbGuy3otHZ0GyMnfc5+jnZIDb0i0Ta0O6+h4jGhm7GOvwOtpNnbc5yBT9r 0xflgtnQRbjWiK/6rTTP2fArjmtBWfaR94aE2Eixl7SdzOuOzdyBep1AuPs84WXdJgTj57BlItQ3 CZddjDOk7OJ6T8nutp8dSnfeIcbo3M0Q7HuEsvtlImWX/Blv/1dkl+duekF2k+HcDXVPAUCfmz62 TjcgL1J/N2Ibn4T2O6wu8RtzvHVS2PFEotv8xqz7tTqt96Xn63S8/WC9L52Od7/++zjw/r9M/qTu 2yGfGSW6jL4+Oq3vY7znlUibKesfzGbK9Z6ymV7d31XPxuSZURQ281QibWZP+buvw4H4OZ5PDQE+ AWiz9NCIRDh/txWnbujvtikPTqpeCY/X8mfp34q/Oww01158X/q83fF3I32vIbwarezqcq/T0bYT bz0R7Xj0uei03o6er9PxthV6Xzod73799+jkv22vGzP2v0PaqESX0ddHp/V9jPe8EmmjZP0LoT+I YHNNwxX63W5AQgYItyQQzwZO971GbmJtlEqkjeqJ9xqbsUdzced8NV6o/xPu7V5AnOw2KhsD7A+E eyYjvByt7Opyr9PRthNMdhLVjj4XndbHo+frdDxshctwBTzTuALfQd028mtNU/tvbzp29PPGwtzf O2nj1RrzW1NDDJfXDd6lHuLfVChGTH3E5zX5gAtYDEgedRmBMMmKutLk+SIgG2AbDP7nSZk/GJA2 xb9CX+bZ0jG4thWydD8aexSZfTA4jm/7mN05I6rPzdpSz7jSI/Ugat5A7aGKVxtvLdISHJrj5TOO RUArYJ0x7ZtqgC4HunPGNMtwmfqbY+4LFAMyV208QdfvIpSvArhOjBkkjuScKOvJHnB+DP7nRJkv a0Z6POAC5PzkT7EJh3Osc5tcBwnyDhYqTnWMeSHnhjFPA7uBh3I6xtyd89MxP8mpxDU3UY32skKf /RxWnZ1VAJRWD8+SenfVK/WTMH0/VH93ziP1DwG7gadzHqp/Ieeu+sNO36Xo+3xP6L4Lqud7hgHu 6vM9ct5T5s/62ag/H/Nw1h60zB88h/llezbX/yRnM/p1V8/DHOZl7RpzOGcX1kDam4ByXFfeX2QD HeDrn2HBdyNzABhE9oB7JvwM0is0eVvjGYdvUcahuX/FgPBYgU1zrOTtZD8/Omjx7+v++NOmkP5s osvoOlynSwxLH3JvsVXcZjt4a2I95jTD2mN2kA+AhZw4107H6/yozMXHi4HnCpY2+dCNWEIwf5Y8 3+3zo/v4jtG93zo/enByjM6PfkPG/Pd4fpTrPRSgniC/Zto085lmPlSGeU7netCbe+N9ay+l9kMJ fR8x9YyEviAaAe7tdMm0Y9GRi5D2P6PD7/FQt5UAg2yQJrL80qID9fOkHKuu33Sauu4pDHI3EM6n FX4uMaKTX132dTraduKtK6Idjz4Xndbb0fN1uhRrSN5hiKR8JGVcRkbqDrTXCYgPduMQJBju+UXD KUTYZjNIzDVdwnz77+KSV3ht1euVBiIteGq7rr91qRgR64LVlfKAj1a+XrN75YX7mGRA+tdmOuWa JunjzTcex9/T6hfS//bA16YfzvipL65o4t8qYKxSUlKyjH6Or0hZ4hi4lhx3PuACFgPM43wKbWD8 dDHs4KNZT/xH0lV2CYl1//HxN960r1qRyBvrif/IPhmkrJRh/mBAxurvP/Jb/tsrLP+Jc5IguoFr vMLYXnG/sRqonzUP6WDl7jcunfUj4+pZKwA0a/42wr+9dGQcKr561qHifijXb9Y4tDkObYdqd5zR UjHdqKxYAVSivhvguCsxbvHfxB/MGg1/bbY1H+6BBJkP1+y6ovpZWaO/1yJ1JyDPBdApyAb4hyRn Y+K3YbAFgKwf13IkwLVECOL7eWuty2YRh2a/XDfZB+pALxpcC/jrQF1mdbrUcPqOofz2T2b5dXSE Jb8DAsqv+7lU8xvNjI+8+Ewj76Ml5v20Jb8DHPnlHvSUfAq/YJsdPiIv+Mvhw6XWd5iFv5lemB/6 vujh0kn5z5YW5r8PSL1z2zC3MPUubCvMv7JtErAwn3JaBUgQOeF905Vto0YrEwvzz227A/3ckT9y zELA9z1kkbvUNXguAQZne8Hk7ty2NSVtVxwtDiZ3T2BhBgHj0PmDiOMld+uwGSuAxMrdwL8huTuj Vzn2lfrLsbug3zqxrfFm/M0kxj+Y17epHN9GZ2zJ2xmOvMEvTDp5y82B/Wi0vlvlxviYHjE2tLzl 5nxxVmXO0bPmAuTzMkCCyA3MhVo14uhZq0Z8c+zcnG+O3ZIzAvD93RuRl9IReO5xVmh52ZM3Ymzp iLfHBpOXTvDwS5CTvyDemhY/eUkOO+VOZnnxdvUzBwW0U/Jcd/qgD00/k/FlX3+oiX+/lbElN4Mc uXGDl3x2Kvhz3Fj4kZHaqS31+PtMlB2MjeP7tNlKzwNN/SBB5AFulHK13JmT1fIAsNt57pfVotTG 6tDyltXyw2pXy+3VnzbfXk15q5LGEUv7tFMNM2+vbpi5EOUWVr/WvBHYnfNp88s5W+pfdp7vidwt nanUm+iX7QWzU50zNlYvnXlmdTC5+6XL8g/TcCMwEQOIzk75ngdiCLWAGSDG5vrp/mFy2KnMvyG5 GxzQTvGbEUshX0dgpyTeZP3tOdzXDXbkLRN74JM3372afg/HfepJeeP3FcrgW4m8zYXsMR1K3ipz ytbk5gwFTrSRz8sACSI3tFO5OT+7YIuJE21zc/a27Szf2yY8L/Jy0zDY+QtCy8vcnNb5ecPfukDq TkDbEBHnfuo22Kdb0OEMKIPyqOUlsvupAvRH2eH8GhC3YKPqgET6eCWGxU/ZGI9+H6fTpSjDcTNE Uj7aMuBd3tbawVtz7MxtdRd957XJejvJVkZfH53uyTGnGb59ycfquQCJc+30NMQGUAZQnjwAWN2E G7GEaL8BIXuk6aKAe5iGDsg7bukIMUxSl/RspFdjUBCF7j/DH6D9TkidNzkWz/A/HN5C051Ef/84 8G9tqUP8f2vw6M7j7WVFH7WH+p4+13sowP3JBjJtmvzBtC3z5jP8RUj/EZu5BxengpEGoDLr66ER CajPoM/wW3GtFScm1yMuAaC2zWdVIxGzL/3ZPNsusPOpL3WaujPSZ/PCp9HKpS7TOh1tO3+Lekuf r07Hww64jCHBfbfVz0T1bB7azQBraMFT23X9rUvFiJxnBB7m7YPuMvaRssK+X5vplGvMcsyznu1l Bbxn6th0qOlgzq4mxnuH/KppX22dE5cX7bLvmbIcH24I2ssHXMBigLxPmSu0gWgSIMGhU5FzEVAF kGbMIHGkz+NF3tjnYID9s73xAMckflXpFKweHKZK5LkBpl/BSs0DXQxIoHwyUPZLp3xQM2LKX2sy AKn3sUepv4ap9yfPX2sOeT4AXqmZj3acOYG2Wj91isr4kKd0UlY+8UrNx55d6GdXzXsNrwDeieLb yfg70O8MrB7b49pKkPY45489102clz9jktSdgDyuAYZr6kB3Gr5Lh47fQWYKIOvFtZN1BBnkObvv 3gllagEzsN9iQNad+iw57qOGJrMspnd9fnFmwPuo455dTX/wnNPE+FLcT83Gt/cY47nFNVnGmY4M DsWa++QtOe6j+I26TZq8MX2iLbS8Tdk4fM3ojdVr0gHyeRkgQfg8HRmLWqrXLGp5tC1946Nt+zec ADZ9RV7uaVHqV2tCy0tm84m2e1rGOvdg/vJyDPLyByiCxyEz0T93iOw+ivLihQAm/r1UdnB5Sfx7 ZT/bNSyg7ZpXUWd+o5Jx+eMbmvaOvNuJn4ccWc/7hjlyk421Tza5eRCald+hFHvD9NmtoeXmwdrB rb+p/WzOUSCU3Lyz7LM5v1h2dusvlh2cVLCcOLt1HtaA+luCyBntX8HyOa2u5Stb31m2spXtBit3 tHZla955ZwO+70OK3foa5jIQBiiU3Xpn2aaJ/7J8YE0wuzXMlsO9vXFfD0RntyKTwwLMjzaM86dM tsCw/f/zDCyE3/OMG3+YWvfApMMhzyQmuozu5+t0iWHJezanFed5paEv8hNDPuDS4lw7PQ2xAZQB tGseIMWGG7GEaJ9nyPpruo0uoB28NXIdYmWO0S2XEMfjeUaVeSYx3PfXtUGEIe1vWp7DYvzuSTKf SeyJ5xnrsA4Z0Ff7oBsPI86Ev4KoS2hECtlBn2cswLXT/f46+ywARI/qNHXqEBRwAf7PiGMli7qs 63RPyn08+tLnotN6X3q+TpcaPj2k03lGb59+MtId2mXkpGXbeyj3KPAF3OVGjlMmTyuvj8F/H9GM GfKNPk7dQHqR/OK2ipr/+vPNp8j9M0C+iWQOpzO+SNofZ+BdDsbjBpzgHV+vOvvXn07fkaxNHjrk /kgQ2+C/hrQtbrsQbYv/9US347/HV2GMq4FI9zhW/Ci2ebG9RrS/04ElgIRd/ZT6rUtSOO+K9LNI j1bbfZl+/oR2ISDpP/9clHIDnH+q4ZPZgcgbAjC4AdL/C5sb/ZtoowAA ------_=_NextPart_001_01CA6135.F642F210 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACUySURBVHja 7Z1dkx3FeYC3ChsJnB+Vi/yAVMU/IL8hV7nMrRMnZZfBZUMSbMCAkVEAgZCQQNYHCgjLgMBSoQit PhDSAlpJIIMErCb7nsNAb6u7p2emZ/rtmeep6to958zX6em3n9MzPd0rVVX97Wb6FxKJRCKRSKOl v1/59h8AAAAYj0cQMAAAwPggYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAA gAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwg YAAAgAxMS8ArKytR6Yc/+EG17d5t1f3b76MIDJD3qdf/0f33L87XPffc890y9/7wh+R1x7xOjcSR HIuco6l9t1TH3rV8584P3/7leOU96tDubGxszFPAZpKCLgEwd+7bvn1RAQxR+fRZ/0f33e88b9vu vXe250qTpOrz06fsaP1uKY+9a/nWKmCh/sEg3wHag4BpTW0JpD5BPpSA5dzU72/ftk1Vvmko5zn5 m/t/lLwSnpuAm8q3ZgGbP76kLEA7Ji3gpopDWnzm8nO+lJIiyIeqKEqukDWfrxRIK23uVyP6nhft 5bvp+CgD3ZmtgGtMCXNJEwHP6Xz1pb7vK4nWT/fzUrqA5dzTiOnG7AVsFp45V/AIeH7nqy/SkTFV x6s5n5fSBSzUHbKkTEA8sxdw7Dryy05ayOa9Uvlf3gv96rO3Lfd4Qvd75AeBvF9XbnWhlvdC99js /ciydVDU27hv2/bgenYaI+9D63c5tq75VyPL2OvLPTrJO7uVZy7j68Rn/sDzVU5t9hmb133zoQmz 9evb3jJmtvbsjXn6oM19VLv3sPyV72jmmysW7GVCcWTeo12cl+3bkxx7bPkeo9zL+TC/p+RXXaZj 9m92JKMVHA8tYKOCdPXilEJoViBtO3Ft7dW4bctrW8BmpeZLLona+wltx/6OUxJwn/wTzB9Hvrwz RSvbaqp0zGNy7bvtPmPyum8+xFBX9L6ez2Zl7ku+Wz6xEosp56H8dXUcit1+TLynKt9Dl3vfuZL8 sbcdoq4naQXHM3sBmwFqX0oze3jWhdEu+KacXb+M7UJdb0N+MZoVq1nQF49FGb9a7V/hMS1Z8xe+ rL/lOBvWHyvvY9ePvULRJ/9Mmdrrm/0EzEpbzl9ThWzu1xZpl3025UnffIjB/N6uqzjm9zJbUs5j 2N6uLN4t8e/Lufw1t12XeTsWQr2O7xLX9u3e7bt+QHTpBd1UvmN/bHU533UHqvr7mN/V9eMlti7l sc44Zitg+7KUqxVjViS+yzjmpRfXL7+YX6ExlymbKnO7UupznEPnfdv123QC6ZJ/plB865tCNM+j ecnPlmTouPrs05cnKcpRDOZxuVr+TY+0NR1nrMRcArSfqW0bC03r2ufcrhfGFHDvcn9fcxk0Bd0U 11uu9mzvd4VlLvAccCCYzUDrIg77M5/EY0RvB0zol7tvG11H6emS9ynXb9pu3/yLuZTsq+xC64Yu P/fZpy9PUpSjGMxK2bWfLWWxg+D7xlOfWIhZ1zyvoThMVb59n/c932aLNeYWSkyjhidK2oGAEwzC 0VdsZoUWuy/7mGP2M1UB982/Pi1CsyVrt5hC2+3bCnXlSYpyFEPTD1PzypK0hkUUbTp+9S2nfZYx 3/d1gAvdehhTwGOU+7ZPicS0yOF7ZitgKXzyC7Btj73FvdvNJJdY7F6HKSqMNillxVSygPvmX9/j dgmpz2XWrnmVohylOs+ujj3LpwaWMRd6bliLgFOX1dQCHqvcdxEwjwzGwWNIEYhsbdHGVmYIuP/6 2gXsuhTY1Pt56gKu8yDUG1pacE2XsPvGU+qy1md9BAw2CLgBuwKpn/0VKdeVxxgVRorvPQcB5zhu 12Xopst7QwtYU4xJa1dkLFeMXI/0pejIlGqZUgU85HlEwMOBgANsfUTp3k6DIrS9XNd1kIQ5C7hv /sXejw09L273jG26F9Z3n648SVGOYojtnOhj+QTCva06mKUq523KWsw9YLuz0ZgCHqPccw94WBBw z23Zjz102YYp+tCzmaFehnMWcN/8i+kNunXd8LOvMcfTd5+uPElRjmJo6gUdejSr7/keU8BdBlcZ U8B9z3fbgWToBZ0eBNxzW/Yl6i7bsEfj8v0aNSs+O2DmLOC++df2eUiXdHxzuvqOpe8+m54D7lqO Ymh6DniLGDzPg4aeg9YiYN95Cf3AyPUccKdyH/EselMnUxOeA24PAg5gPk4horXHl3V1MGkTkFsq tW1bRz6yA8UesSZ1xWTem5P9dZndZqiOZDHfrW/+mdJYjCj0bWVmjwgUmnjAvr/ZdBmuzz5jng3t kg8xhB69qo/fHiHOjh2zYk/xLG2qZVxPS5gjn7UZka7LPtt+n77n2zcamz3qV0wdZtaXjIQVBwJu qGiaxoGWAt91ZJxQMIR6jqaudOzgSdE7dmwB980/oWlc5iZh2evHDPXYdZ+xlXLX79JE01jQ9vCn bZ7B1yJge75wM/kGMBlbwCnOtyv2zTIcG3+MBd0eBNxAaJYRc3zZPvdmXfuzx7TtM4NM7DL2AAp9 8j6HgPvkX009RKkpj6YZr8x1Yy4/p9hnzGX5PvnQhHm5MTSSl1Tg9nCG9TP4Q43YlrIX9N2tyHaz kqUo37G3sfqcb/uRMbM1HLP/mPIAdzM5AQPkZE69QL+fD3g6HW54jKYb9Y8UWr/tQMAAiTBbwH2n +yuBmDmBSwMB9yv3tH7bgYABEmHeL+vSia1E6pbPVFrBCJgyMCYIGCABZs/fOVVE5veeQisYAbej bv265qyGZhAwQE9in/2dKnUlPIX7fwi4HXU/gKncghgbBAzQk7oSkr9zrYjq+8Fd5hfWBAKOp36E jvu+3UHAAAAAeUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAA GUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDA AAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAD5WVla8CQCgDxsbGwgY IAakCwApQcAAkbgEXL/nahUjbAAIgYABIvEJ2JRw0/IAADUIGCCSUAvYfo18AaAJBAwQCQIGgJQg YIBIEDAApAQBA0QSI2DfewAANggYIBIEDAApQcAAiUHAABADAgZICPIFgFgQMAAAQB4QMAAAQAYQ cOlc/Ozz6o1Ll0mkSaSTn14lqGEuIODSkUrr+OW16vTVayRS0Unku/vMKkENcwEBl44IWFrBAKXz xddfI2CYEwi4dBAwTAUEDDMDAZcOAoapgIBhZiDg0kHAMBUQMMwMBFw6CBimAgKGmYGASwcBw1RA wDAzEHDpIGCYCggYZgYCLh0EDFMBAcPMQMClg4BhKiBgmBkIuHQQMEwFBAwzAwF35frNm9UT+1+t Htu7L2vaefyt6qnDr2U/jr3H/kShgF4gYJgZCLgrJz44W/16995q5zvvkTbTTx5/kkIBvUDAMDMQ cFdEwL955UC179xF0mZCwNAXBAwzAwF3BQEjYEgLAoaZgYC7goARMKQFAcPMQMBdQcAIGNKCgGFm IOCuIGAEDGlBwDAzEHBXEDAChrQgYJgZCLgrCBgBQzqu3PzrQr51ktcAEwcBdyVWwEKb9xEwzJUj Fy8t5Ct/AabOxsYGAu5KGwELCBggTN0KpvULcwAB96BtC7j+6xOwSWiZWImb+3Ut59pfzHoIGIbi 1u3b1ZHVc4u/AFMHAfcgpYB9n4XWiRGwbx9NxxJaFgFDamRc9ZffPF49sPPZ6r/27l/8ldfyPsBU QcA96HIPOOZ/32e+v7H3ntvuDwHD0Fz65NNq56Ej1S82hfvE0TeqPWdWF2VJ/spreV8+l+UApgYC 7kHXTlj1a/N9FwgYphw7j+zeU/1q1+7q92/+OViu5HNZTpaX9QCmAgLuWYmkFHDsJWzX+ggYtCP3 dY+++1718z/sXMTNs++ebNXJT5aX9WR92Q73iaF0EHAP+jyGVNO1s5VrmwgYNCL3cV96/Vj18x07 q8cOvlbtPn22V297WV+2I9uT7XKfGEoFAfcg9XPAJl1a0W0EHNMLGgFDH85fWauePnBwcR/3yU1R 7j17Puljb7I92a5sX/Yj+wMoCQTcAw0jYQk8Bwxa+PqbbxZx8atnd1UPvbin2nH87VHKnuxH9if7 lf3LcQBoBwG3xBwgAAEjYFhy84svq0Nvn1g8PiQxsevU+1nKoOxX9i/HIccjxwWgFQRs8dXGRnV1 M2h96ZXVC9WB8xeri599zljQCHj2fHrjRrXrtaOLy8CPHz7a+/5uqiTHIccjxyXHJ8cJoBAEbPLW lY+3DAgfSgc/WEXACHiWnL5wsXpi/6vVg//zfPXUsePJ7++mvE8sxyfHKccrxw2gCARs8saly9Xp q9e8n0vrV5aR1jAtYAQ8J+S+6lun/696cOdzi9GqnnnrRFHlU45XjluOX74H94lBAQjYpEnAN259 /+whAkbAc0Duox7489vL53dfPVi9+P6ZosupHL98D/k+8r24TwwZQcAmTQI2GVPAQp/nfhHwkpWV lUVqWsb8O1fW1tcX909/tuOZ6vEj//vdMJFTSfJ95HvJ95PvKd8XYEzohGWhVcAl9IjWLuC2Qp2r gE+unlsM+/jL515Y3D+dw9Ub+Z7yfeV7y/cHGAMEbDGmgE3aDrhhrxvalr1MaFQu1+dTEHDd8jWl 6nqvft/8a//v+yxm21qRYR2PnTy1uD/63/tebT1M5FSSfG/5/pIPkh8MdwlDgoAtxhKw4Htd/+96 r62kXeIN/W9vY6ot4C5CDS0fu6w2zGkAH/3j4eLv76a8Tyz5wbSIMCQI2KJEAXcVc+r7xiVfgu4r 4NB+NArYNw0g6e77xEyLCEOBgC3GFLBNmw5VrvV864S21bSfKQvYvEycWsC+bedGyuzDu3ZHTQNI 2prqaREl/5gWEVKAgC1ytYCbxNl2eQR8N0NegvZ9pgF7GsDn/3IKofZIkn9MiwgpQMAWU70HHCPg mrkJeIgWcOj1WKSeBpC0NTEtIvQFAVuU2gs61NnKt8059YIWfJeK7c98zwE3XbL2LTs2Zy99NOg0 gKStyZ4WUfIfIAYEbFHyc8C5nyVmJKx8mNMAPvzSy6NNA0jamiTfJf+ZFhFiQMAWcxOwTZ9tIeDx 0TINIGlrYlpEiAEBW8y9BYyAy0DrNIBNV1XM/7tcfYndlqb7xEyLCD4QsAUCRsCaken0Htu7T/00 gF1ua8QsF7stjfeJ62kR5fwxLSIICNgCASNgbdjTAO585z0VInW9rolttZrL28vZ27Lfc23Xtf+U HQ1TJDl/TIsIAgK2QMAIWAvapgEU2oi17f/1667b6rJczsS0iICALRBwfgFv3LlTnVm/vjgPc0yn 1j5ROw2gT5Kx92pjpZ1yW7H7yZXsaRHl/E+tTF/lxwUCRsBlCPjiZ59X+86eX5yLOabDq+fVzkoU ErBNX2mm3Jb2+8jmLExy/qdUng9d+LA6cJ573gh4AAE/8Oyu6tFDr5E2U0oBy3mYO/W8vJrGbfYJ OFaAMWJMuS3tAq7Hl57yPMQSzwjYDQK2aCNgGQP2yDvvkr5NqQaoR8Bb0TZzkdB0mdh+3VXAfbel 8R7w3GZYQsB+ELBFGwHDcAGLgO/GnLs3Z6cswfd+/Zm5jO//pkvNvm017aNNb+scna7mNscwAvaD gC0QsI6ARcB+5MqLhseSSk1CzseO5jZ7EgL2g4AtELCOgEXAcdQDc/zyuRcWAz0g2IvRncOGTnI+ 5LzMfeANBOwHAVsgYB0Bi4Dbsba+vuXRJaYezJMWQ08ajxTJeSGeEXAABGyCgHUELALuRj14B5Mz jJvMyRcYVOPueEbAXhCwCQLWEbAIuB/29ITPvHUCUQ6QJF+ZfrA5nhGwFwRsgoB1BCwCTodMEP/E /leLmsBBczInVpB8lfyFcDwjYC8I2AQB6whYBJwecwrDxw6+xn3iDvd3Jd+YWrB9PCNgLwjYBAHr CFgEPBxyf/Lou+8tJ3l45UD1/F9OIdhAkvyRfJL8knzj/m77eEbAXhCwCQLWEbAIeBzkvuXDu3ZX D724p9px/G2EayTJD8kXyZ9Uo7zNNZ4RsBcEbBIj4JWVFW+qP9eM9uNDwONz/spa9fSBg4vLq0++ fmy294nle8v3l3yQ/JB8gf7xjIDd8BywRdsWsHaZlXjMCDgfMjziS5sC+vmOndWjfzycfQ7iMYeJ lO8r31u+/1yGiRwrnhGwGwRskULAdkvYbB27Xpvvud737SdmPdd2XMtrC1gEnBcZLvHYyVNqp0VM lcxpAOX7zm2YyLHiGQG7QcAWqQUcEq9Prk2y9u3bte2YzzQGLALWg8ZpEfumOUwDqCmeEbAbBGwx RAvYt2ysgGP3jYBhSLRNi9g2zW0aQE3xjIDdIGCLXAJ2debybb9pe20/0xiwCFgv9bSIi8eYMk6L 2Ob+rhynHO+cpgHUFM8I2A0CttDQAm7aftP22n6mMWARsH5k2EXN0yLa0wAyTGS+eEbAbhCwBZeg dQQsAi6LU4qmRfRNA3jj1u3q89tfcbIyxDMCdoOALXIIuP4/pjeza1++jlqhy9r0goaUHL+8thDc lmkRDx8dbbjLxTSAh48GpwGUMnXi4084WRniGQG7QcCOIGUkrPwBi4DLQcS7+8zqQsI1MlzjobdP DD4tojkNoOwvNEwkAs4XzwjYCwK2gxQB5w9YBFwOIl4RsCSRsclQ0yJ2mQYQAeeLZwTsBQHbQYqA 8wcsAi6DW5vik3O154Nz1aELH1Zn1q97l+07LWLfaQARcL54RsBeELAdpAg4f8Ai4LKQClbOWwz1 tIgy7GPMtIj1NICyfJ9pABFwvnhGwF4QsB2kCDh/wCLgsmgj4BoZ9jE0LaI9DWDfYSIRcL54RsBe ELAdpAg4f8Ai4LLoImATc1rE3x19fZBpABFwvnhGwF4QsB2kCDh/wCLgsugr4BqZ/m/fm8cHmQYQ AeeLZwTsBQHbQYqA8wcsAi6LVAIeOrYRcJ54RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcs Ai4LBAyheEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLg skDAEIpnBOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4L BAyheEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLgskDA EIpnBOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4LBAyh eEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLgskDAEIpn BOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4LBAyheEbA XnQI+NInn1Y/ffLp6iePP5k1/Xrv/urB51/Mfhz/ueulWQcsAi4LBAyheEbAXnQI+MQHZ6vfvHKg 2nfuImkziYTnHLAIuCwQMITiGQF7QcAIWF/AIuCyQMAQimcE7AUBI2B9AYuAywIBQyieEbAXBIyA 9QUsAi4LBAyheEbAXhAwAtYXsAi4LBAwhOIZAXtBwAhYX8Ai4LJAwBCKZwTsBQEjYH0Bi4DLAgFD KJ4RsBcEjID1BSwCLgsEDKF4RsBeEDAC1hewCLgsEDCE4hkBe0HACFhfwCLgskDAEIpnBOwFASNg fQGLgMsCAUMonhGwFwSMgPUFbAoBr6ysONNQ1NsO7SN2/+ZyQx5zKhAwhOIZAbvZ2NhAwAhYX8Cm EnCb94faX5d9lyBdEwQMoXhGwG4QMAJWGbBjCdjVMrbXc712taZ9LWBz2Zht2e/FrmPva0wQMITi GQG7QcAIWGXAjiHgNgL1bdMnQd/nbbcVu/+mbQ8NAoZQPCNgN0UIWGjzfuwyMeu3WQ4BpwvYMe4B t5Wpbx+hdZpa003bit1em/0MAQKGUDwjYDcIGAGrDNghWsChS7mhS7qu7cau0/YYXMsh4DQg4Hzx jIDdTErAJk3LxMjZt5y9H9fnrtfm39C+EfBwl6BjL9PGiq2PgFNfgm767kOCgCEUzwjYzWQEbC9T v/YtUxOz3ab9+PbtOpbQtnwCvvrFl9WVm3+dVcDmEHCMxGLu6XaVLAIeFgScL54RsJtiBOyjq4Db tqzbtG777r8WsIhXKo3dZ1YXf09fvTaLdPzyWtZe0DHrh2Qbe5m5aVtdekE3HftQIGDwgYD9TKoF bFOygP/96T8sRCTylSQFWCqQuaTVazeIzoJAwOADAfuZ7CXoNvLU2gIWbty6vRCxtAwBtIKAwQcC 9jPbe8CpBdymM1bbe8CLE3XnDqUV1IKAwQcC9jPbXtD2ck33nZv2M7SAATSDgMEHAvbDSFiMhAXQ GwQMPhBwEASMgAH6gYDBBwIOgoARMEA/EDD4QMBBEDAC1o08klQ/jkXSm7QPFoOA84CAgyBgBKwb qTQlycAkJJ3p2pe31JcjBJwHBBwEASNg3UilyXPQ0BcEnAcEHAQBI2DdIGBIAQLOAwIOgoARsG4Q MKQAAecBAQdBwAhYNwgYUoCA84CAgyBgBKwbBAwpQMB5QMBBEDAC1g0ChhQg4Dwg4CAIGAHrBgFD ChBwHhBwEASMgHWDgCEFCDgPCDgIAkbAukHAkAIEnAcEHAQBI2DdIGBIAQLOAwIOgoARsG4QMKQA AecBAQfRIeCTq+eqn+14pnroxT2kzYSAvwcBQwoQcB4QcBAdAhbOX1nLnv584VL1/mag5j6OtfV1 iua3IGBIAQLOAwIOokfAudm4c6d6ZfVCdfzyGpmhCAQMKUDAeUDAQRBwjTnv7I1bt8kQJSBgSAEC zgMCDoKAa9668nG17+z5RWE5s36dDFECAoYUIOA8IOAgCNgOUip7XSBgSBXbCHh8EHAQBGwHKZW9 LhAwpIptBDw+CDgIAraDlMpeFwgYUsU2Ah4fBBwEAdtBSmWvCwQMqWIbAY8PAg6CgO0gpbLXBQKG VLGNgMcHAQdBwHaQUtnrAgFDqthGwOODgIMgYDtIqex1gYAhVWwj4PFBwEEQsB2kVPa6QMCQKrYR 8Pgg4CAI2A5SKntdIOByWVlZUXMctYBjjknLcbf5fnbSco5qAZeWp2OwsbGBgE0QsD4QcLloFHBJ x90nn2O/AwLOBwK2QMD6QMDlYla69f92C83VYmu7bOj9+n9fC9hev2l7GkXiO6aY79B1mdhz8Hf/ 8GME7AEBWyBgfSDgcgnJM1TJxy4bEre9rkvAMevHvNaUz6H8j8mrtvnRtI60gB85eBgBO0DAFghY Hwi4XNq2otou2+b9mHvAcxdwzPptzw2XoP0gYAsErA8EXC5jCNjV+aiNgGPX79rJaex8DuVpl+/q yvOYvEHAzSBgCwSsDwRcLmO3gEPLp7wErTmfY/O0bb63zRsE3AwCtkDA+kDA5aL9ErTvPvMULkF3 ycPYznFttouA/SBgCwSsDwRcLkMLuP6/qddyzCVoc7sl9oKOuUTephd0zHmIOQfSC5pOWG4QsAUC 1gcChlSxzUhY/egiUUbC8oOAHUFKZa8LBAypYhsBd6drCxYB+0HAjiClstcFAoZUsY2AxwcBB0HA dpBS2esCAUOq2EbA44OAgyBgO0ip7HWBgCFVbCPg8UHAQRCwHaRU9rpAwGWTY5ae0GNI5PMw+ezb DgL2wz1gCwSsDwRcLrlm6XGtO2UBa8pnGwTsBwE7gpTKXhcIuFxiB26IGfQhZtYj33L2c8BtZmCa Uz6HWtBN+ezbXz0b0hTyOTUI2AIB6wMBl0tTBRs7GEeXUZzs5SW2/+lf/y24v5hLqlPN5y7nIub/ ejakKeRzahCwBQLWBwIum9C9yZQCbtpujIBD25h6PrcZmazN+XIJuOR8TgkCtkDA+kDA0yJmhp7Y 5RBwunyOPRcx+YeA40DAFghYHwi4XJruTbadizZm+673py7gFPkcey5i9oGA40DAFghYHwi4XNqK Ifc94KZjn3I+j3kPuNR8Tg0CtkDA+kDAZdP0fGrqXtCu99r0gva9nkM+t+kFbb/Xthd0qfmcEgRs gYD1gYAhVWwzEtb48BxwEARsBymVvS4QMKSKbQQ8Pgg4CAK2g5TKXhcIGFLFNgIeHwQcBAHbQUpl rwsEDKliGwGPDwIOgoDtIKWy1wUChlSxjYDHBwEHQcB2kFLZ6wIBQ6rYRsDjg4CDIGA7SKnsdYGA IVVsI+DxQcBBELAdpFT2ukDAkCq2EfD4IOAgCNgOUip7XSBgSBXbCHh8EHAQBGwHKZX9kus3b1aP 791fPbZ3X9a0440/VU8ffSP/cRw4WH39zTcUjIJju6uA/3J2NXv505QOvX0iOu8QcBAEbAcpAl5y /spa9eBzL1Q733mPtJl+tuOZxY8SKDe2uwp412tHq9/+8QhxsJl+d/T1hYRjQcBBELAdpAh4iQj4 oRf3VPvOXSRtpl/sfBYBFx7bfQT81LHjxMFmEgkj4GQgYDtIEfASBIyApxbbCBgBKwMB20GKgJcg YAQ8tdhGwAhYGQjYDtIUAvZN6WUv4/pfCwgYAU8tthEwAtYE0xE6grSvgLvIFAEjYBg+thEwAtYE AnYEaR8BN00a7mv1hlrDrs9iJ9HuAwJGwFOLbQSMgDWBgB1BmroF7HvdVcCxy/YFASPgqcU2AkbA mkDAjiAd+hJ0XwGH9oWAETD4YxsBI2BNIGBHkA4hYPMycWoBu7adAgSMgKcW2wgYAWsCATuCVPsl 6NC2U4KAEfDUYhsBI2BNIGBHkA4p4CFawKHXfUDACHhqsY2AEbAmELAjSIe8BG1+3ubScsy26QWN gCEc2wgYAWsCATuClJGwliBgBDy12EbACFgZCNgOUgS8BAEj4KnFNgJGwMpAwHaQIuAlUxKwgICJ 7bEF7Ct3seWx7/oIWDdcgnYEKQJegoAR8NRiGwEjYE0gYEeQIuAlqQRcE6pA6tdNf83thbYRszwC nl9saxVwU5m2y3Wb7TbFBwLOBwJ2BCkCXpJCwK4KoEnAvkonpoKJ3V9fAd+4dXtRsUBZsa1RwE1l uqmctxFwipiwBSxxIPHgAwH7QcCeIL36xZezT6c28+LhPS8PcunXV1GEKpDYympIAV+6dr06fnmt 2n1mtTpy8dLixxqpjCQSyCFgH10F3LcFnErAtVglFlav3fDWI+9fXUfACDiOM+vXFxImXa4Orp6v Htl/QJ2A+1RkfdKDz+2qXv/wo0WFQyozSXyPLeCYFnBTmdYm4KcOHflOvvWP0VBd0vWHDwKG2ZL6 EvQQLeCulU+fS9ByuU1awVQq82HMS9Bd4iJHC1ioW8HS0oX2IGDwkusesOZL0GYnrK82NigkM0HT PeA+Ak4RE65OWMRCNxAweBmyF7Tr0ltsRWOv06XyoRc0tEFTL+imsuxbzoyxPrHQthc0+EHA4IWR sBAwLJnCSFhCjueAwQ8CBi8IGAHDEgSMgIcAAYMXBIyAYQljQSPggUDA4AYBI2BYgoAR8EAgYHCD gBEwLEHACHggEDC4QcAIGJYgYAQ8EAgY3CBgBAxLEDACHggEDG4QMAKGJQgYAQ8EAgY3CBgBwxIE jIAHAgGDGwSMgGEJAkbAA4GAwQ0CTivglZUVb6o/14z24xsSBIyAh4CBOMALAh6uBVyizBAwAkbA aUHA4AUBjytg8z2zVWy/b69rt6Tt9UPH4FvPdxxzlTACRsBDgIDBCwLOK+Cm167t+MTdtP+m7fmO eS4gYAQ8BAgYvCDg/C3gptex7zftHwGHQcAIeAgQMHhBwGUIuEuHLgTcDgSMgIcAAYMXEfB//P4P CwmT9lQ/ffLp6uYXXybJ26FawKHtd9keAl7y0uvHqgd2Pp+9DP72wKHq4T0vZz2GB597oXp8734q yAQgYAgiEs6d3v3wo0XKfRxr6+vJ8pVL0GVx6/ZtFbGw+8xqderS5ezHwfPwaUDAoJ4jFy8t0pRI JeD6/6bezL5jaOpV3dQDG8ZFBHw10VUYyA8CBtVcufnXRaUjSf4HmDMIeHIgYNDLyU+vVvvOnq9e Wb2w+B9gziDgyYGAQTdvXLpcnfj4EzICZg8CnhwIGHSDgAGWIODJgYBBNwgYYAkCnhwIGHSDgAGW IODJgYBBNwgYYAkCnhwIGHSDgAGWIODJgYBBNwgYYAkCnhwIGHTz5kdXvhuMg0Sae0LAkwIBg24+ v/1VdfrqNRJp9unM+vVq484dKoXpgIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAy gIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIAB AAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAy gIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAysBDwP26mAyQSiUQikUZL//z/jsaj DIB8M2MAAAAASUVORK5CYII= ------_=_NextPart_001_01CA6135.F642F210 Content-Type: application/octet-stream; name="oledata.mso" Content-Transfer-Encoding: base64 Content-ID: Content-Description: oledata.mso Content-Location: oledata.mso AMAAAHic7NRlUF3RmibggyS4u3vQYAd3ggcI7hZcgzsEl+AEtxDcTnALcJDg7hrc3d17357uqlvz p/tWz4+Zqnl3PbV9rdr1rf2Nj2Gt5VYTr4P+t4iA4EAvr0igt/90DeY//HswQcD919d/HP7n/h95 /f/5fyrPgH/UDw6oHTzgDeAfNUcAIAKQAMgAFAAqAA2ADsD4X0sAhAXABuAAcAF4AHwAAYAQQAQg BpAASAFkAHIABYASQAWgBtAAaAF0gHcAegADgBHABGAGsADeA1gBbAB2AAeAEwAGcAG4ATwAXgAf gB8gABAECAGE/31tg0CiADGAOOADQAIgCZACSANkALIAOcBHgDxAAaAI+ARQAigDVACqADWAOkAD oAnQAmgDdAC6AD2APsAAYPgf/8z/DVEFOQCbK1ALKZA9sHcGeYH+leADK+Y/x4L5L57NWS694DYe hPnnfmEEVBAM4AeqyAts3MAZ+F+YnxAEC/PP3/PfeQcWcPv7X5jkv8i/Ov//6fyP5oeFAXlmHS2a q5PqNbOv9RoEt9gGtUg4hq/Zx9hunrCKS4xTIoWIUcrGr52cVIjDwge9w1zDH0hPHx5Of/zR9NqW Xjvnral1WnZw8GwPMeAyzde2vU+WPMzxl6WmJBw/JsNGfEkVKll9kk2jxLxyOHU4PTl5Sfh6a/nw yrQMgvWHdPk4dtx8/UEDwoSRBZkBvQYv4K0YwucnO1hKFhDPGgwIIQClA24NDhEUAjQKjgB4MWRK uHg4BlAS0Be4gWdRcuDG4QhB0UDbAK9RrWEFvOlA/gxXBccHygI6BW8AQgfKGtwZHDwoCEQVcBbX gAYbAdsN2gAhdZgG0AKDocXD9MNugS5AbwKoxZByUJVhSmCnQQcB9CC0gHfA6GjjMHuwV6AHEFwA VQfiZ1R2mDTYYdAO0BEJPyNVwWrD2YEaQIIBwh0wa4iOsHxw+iDMAOYOtDX0M5AnLBS0AqIIYOvA WMNABD2Xt80EKjnDjhaAPp4gQj/4ZZ334ZAjnlR+ffETwiyVC5gp/Jwsqzd1xcaxDrm7nm+IysKx n4JhSHvkbUejVRajPfZPenhNiRcfV25v2BX1Jh91qCwTQ0uDm+B+Q/3if4+f1nF9GuVsVCTq/VU7 4GVh7AtDzjY/TP0BavefIxnFVx+kx8aLrheSufbXtpf2L6svmg7+1hj+Ra8V8NcuxK8tW29CEWAX oxgW0iSy9H+wLG+RLndgylRlJqXWtuLAo65jm1zjxgfweTUHUSmLDQWKvyzcvFSfrsYd+j9jIuPJ y5O4sIeWJdIT5h2Ybe5Jn3ev9MI+mb5T8c5DhmkJIltWWLbLIvV3HW0n67vY5MN3Rx8n8k8eqjTC TQ/aaNvNDVQ4Pi6kKtrBRYclL7rpVP+UkqL+i9qqwx6ZCgEGhUTLUq5qe5XzKFmBSpMn1p8/4zjV lOrVO/XNvOpLpRY7wmqf5NuNrZOnIapsTDVLfhmUz6tGsaa7Gw/X4IBJhr98T+bFkJaFxHbB1Qnc jechPw8ZFDyMfofHUG0yeFKF5V8aVNS363PuQdqyAuktgiACuBuUam/++ShElYNgsvd2LGgUwthY NZaBAcenxW/iKRKp6rhk4QeRuJBuid9ibG1jB8PiNPTE9NJ8zC8DwUXBDd/dugjTfdt1HvMissKe LLkFC1DXvZjS52TF2vcSr4x+1pLAX6PGfVM1jur1umT1ovBqYC3bYtSUiFab/oAirdpjmyruuhi4 Fmfgqrz1boDHffQmuMlTKzVyoP6iELtl8por3uxUDZ2eSpPEtJ36XVD8VMRyyS2ZK4NJq6scxRnz lEeNN6FKSLwL5h/9hJuqpjB78myU/GkGaq/Z8GkwJ7fgwtw1IV3ffbKXz2DtNTFuHOrPA9P63gSy Ve1skdPkooYG3ggrAj7JHN3aAHs21xsTDYo9X+ZrorkqpNQMteF5BkEWO1ozzIxR0szlqy/OhWkY Yf3qonJm3dkIhNwCxIFY0S/40ua7jwQxZ1oJbSH6vU2JPEMLP7vM3jEZiZbWuSP6Y9uV6OjPnrtK Fs+8fR4gxhEqz5gJJ9sd4Lu3Ko+ztyR8Kqjt4jFHIac42CYyKvuDEpECUZZMQd2bx7eAZ9Hak+kU vmsO+2PJUBETCSf62AnLpl+n4+HhOS/aVcPjxV1ZkJ5Hf9edTDb37XlDkTrZdq+6fSTGDExqDFKi qmHIX/NU+SVmhe6MJGxrvuDtxTwcIB2g9jxrJ1FQ2/y8HjYfjYqNlvHhPYtAed60Ij9RMFbFeLOd T5wEkZ0LXqLP64DZD3triXKb/SZo3fuuZn4w/34i98gtbCGdQmIBXzdicMXYpgD5Q13jL38w/qJ4 E8WAsZi/KJO2v9tQOJx0KNreoxuIuu78uaPzwdTz3oXrDrxcXLMl5UXoPvyN5rfGIJX/itS7MiQf +oHlrDbmeH4ZmnPOCLsJSXmXl4zS/fz4nSM5lc1ElZ82Yx8qN9TDTbcsM6yoFPeEtaSPK+ZOD9YT EDMXF1qnf1wq1zYoDdvTllKFwOWeN/P9ZnNUCW9jwEiiEstONbkpHtqkF7XgeIZPgUZgnsxx6R8L +sAmEhlwycBbmmqxauKUdrnQ57N97p3pW2PVw9FIkNV7PFcRv52Gs+BxmrC0pyYnXpfU+2D6M6M7 BD3FxBxe5uKpaHV4cIUvAq2hMyRVy9IP3WBdFIsTY+DmbPPoZDOHBEShbZQa74+Z2yc0bJXnarAW +ZhADRlWfUa78mmVXte/y8Gb3wh9aJp0c3c3dWttT3Qyf14I9IMat/9U83ctrCo+7iezS0uQofJI I4g96FSpUdIuxXShk1LcsiFbYZQ76166a05R8TRPtMdgfvQRRrtWBXc5RHoavUvpX2StslFrL9P/ GMlX84jYKkxHnQH6SphnYTdlQVk9Pa+Vw2TWeJix9mhzEh1lg1lL0U44UjTUsZEYtmWt16k+kalb ZNzJIXpz4qWnA5H2TGUBZy6quIZ/VZ9UPg0pnyruX86dsT+O/lBxbPGT8AibCkYQzeUrPXVlVF20 QS27X+NZN8sSIkZAUNyfJbZrrNwTlNfa6dH2pb3n+qMOdtg3qDTKr/Ioj5Wy5ozHFwZ2YrzI/J1L 7lksr5jmrzAUh0HUZaRwLhNh2hx0HM3Tq3P6i6Nqt1OQqyrBaAfBHdJmB6nrcGH3bddSRtxpxV/f r9OzczxHKgnZApEZkwhXXcBbwuhOGIgl1989r37LcZJPmuNLIBWG3N2nM+N8F35/rODH9fXvvZ56 PURBfLnIL89B/eO+vBI/o+QjS810sKba1KKNi8nUibQttxEVr4bHY++kObhut/8ua6Qkt6j+SjkN Kp8i9TI6Y14UzXdeJM/Vj/hYMkqezhTlKqFvwML+K5KXfa8TdTH2pyFzddBez+bGyK4Vkz5pj1ZF 53DNgu3m9Pqn57kTjZC/FaQIfDC0Hx/f8QpRba0Ktr+eqHO5CltSIAzzJFiJpp7dHh9Q6E2LN1dP wZJYLDI95+aYicXWs1ArClGf1Egjue+n1VuNt8H0ZCoO6E5xJGvOoZHjC3vTeFdOEcQUD+XvB2mK zOBdu7HTwXnjc11LzhNWFRYfmGfRWxpCa1R69H8/Uawi9Hz/Rmc+MlbzaZJ/nP2zxV+brLieUk70 W7nTqR+PHpclZU22F6p8WtC38k7M/vqEha0RqxYvpAtNKxrGI4TcPwyhgsyFveca5X+poHNqGTue bzeFac6btvVeThQ27NOvCN2KdtDYBXqpcbjNw/a1h2OtBuB7JqzvQlBrVaRzYSwaiWWKCn45f6cj JbQwrdtLeVHzGnDDoZeB3V9v0cGocn+zkDeTIqb+R+CdLSwjQrh+XNaaJ61vKKwgttQfxZ+x9c0Z P8pmc9e7D3e8DrUww5YtHzldHq2pR8eS7UyO3hrN4BIzHzXNO3e4ly8oPB51kyaaYBbuPPYMudWa YriExa+3Ughe3yX8oU3pK4yYJVz5fqYwoeVoHNAvW3SOK/B7lJW9sNnptn4Ia2nID5Lr8VMtIrYt yYHbKVOMvO736C60WV9kGM4WY7yAPP8mxFH2onjKHTIq1d/1PiS0RmENWiTyNQotsRH1VTJM+1zI 4VemjKRxQE7XtICSWnAonOCK7yWxvQF71eWGuLZkCu4qPQuGn/9504apigK1jNAUo426NUFDWOrh RK+GsmYIUgGW85jilm7D7Da0fNGVRtVZEWkvW6ZKyM/z4Wr48clmpwuPKJqkcFMGF9qBSWfW8pAV hOJpBMXPtXw4Pg3CbJYd1RxT+dBSbSpLp/+7YmdeehJncSTeKpRRAktzW1qoVbdT+RzXnYChCdFn QN6hzdhlj2UNRfX8PsfeuWJpXqg98KF1FmXKAw8f1s5v8/k+5yqVcd0h8U/gC3QzjytW9FCbsmcB t24yXjSF6IMvd4Xdx8y+ZMRC1Lg2mn3J41t5YyWhe2KUZ7MlrT+VmDVV5dRltfdsqb40OjFJCIIi driop/7OK9hliX8gaZiELMLHpEqVFSTLshk3DCTjKlMvJ0ezTXwi2nfU45ZC9t/LdOsnGm47Fr4s fb071M3Ghmi9dsb60F+qzqoHvrGWH7Yu2RBsIRYWCnEOl4X/+2eywFmzHNsUT+AUZnNB2NG/lJM3 WaulQ0fNxWhWYURhIYS8XutXYU+upzes3oyO4qr9mgnPZP9KJobIVXri4kyEW570i6duU9H7Sd3l i8jgFhOI6bJebf/yKOtooRYaz8R5D8Z0f4bi8GYYeAB7vu08e714RFgLy2wW930ZT3a0hgohQ6eH dwpTZxhVmBMe/7k3EzKbM9hF+DHf+DHf5IKrCGbmso+/MdE745wVp2+qD0epPmo+gq9JC801JfkD +MYQTMzEVpydgT4tnpRsVgHGPCZgawumry5Imts5LFTludOlToRA6dfB9ZtePGSVK9F8ui519t+a +3rAUT/00VN27b83IyzZxPjgsjHX+wuBlbKn0v9M8yMSYWhnVli8L7IgT8qbO6khe9JvD2Ni6Crb 9UoJrONxTC7Z2E40CSOwctHt8aTmVf0C3f2xedsrIpHJXiQgFS80Rl+2JDmTgLbRN3Oso4Io8ccq 3ic60U2uhgWFgoQsMKl3n/4iluUnHydh75gZo+crJAs8CIE3gU+tcf0be4vBXte5GdEnHAtFvV7S v6vy2M1v+EnyoPcTIlocxKVjsn9oDN63Gn8M5ZNErsQwe7fo75bLYjpLLTc+wLX4zm0VA4ZkiaHM mfJk4dqJPq8Uo4iLQ3+muUtWt1sgqTPGn8XY2zhhal5122EJcl5N14lhwjecNLo6q4yPasCXm3ft RNxAKxBcM2VGvjje06FPDJ9/jfzzkfmWisWjqgLm2ypNpWAvd0l28s51itLXtRJGAfkUKnO1c5LO WNKPplMZX8/pxhBQfE2A9jFIu95AVkIoo83ixoxhBq2LricRPDh84LlQyDsm1bdoOTTmWxJQl0jJ k3hUtg95ZG2S3IuR+nSjxRibZqLxyVYiRrN6J6Qde1DLHEGQREmUKDpUqzyx1VawVp4nxbrAaUks XguaARfR0nom1kwkGGO71qb7QUEOIl5NVKbWkz7UVqe5OGeauNyqrSF2RDR2UrwJkUrMLNNLfm8V keZ2+MueIt6TdXVZ25nyCWsUbSpHFeqqYKHhvhmZlzC51xIRNEcgamh+pHUSNjuU0+TeikUVu4KI aqXA/8SahJDPaC4f8+DeMOTRKe2KoaOzplmMUPD+jybOXiEv/Iwgdv4xOHzkzu5AJhyhi3nhEvmX I1p4EJWhS+u5UzJD5RZtw1bBtJencP/TWSn5ybXsLLYHlFqhtz0+/hptJUcLyUZ1ByXwvCj4nGBa 7xyb4kg3a23t9/xnw1/p29+83fJvFKyUUxuldbjAaidMDOGcw1E5JhwkifBgyfVxaLXKlyj37lW6 bEPUicEWUf2pO5dhcWR9jcpjZevesyMF2qKERZfckpjuIrvBexWis0KDzaa0HN5JUKTHJzcNfoSP pY62xxEYGeeulTQZ98xoXZwyQX4NkFz53eujCvCP6MVq+G592WXGpL6hpZcHnO9EMuiSKo015mHD MpyaODwn/R5syA0+y8TYGMufP7N6tVhW4sMPyn+PgaUQPlIkyQur5e31iJDgbWD4WPh55SgU/mYG gVt2YdwbA78NTVEywdXw2BgFp/VXSh+D133Q7Cx1smSVLJyE0725kSZzcFiBbGe/XqCVSbrVEbmM LVG32vRb2a/Xgqjr8iXNeha530BbRV53nRv6EAXYHyiG0w2pGDjW3qJ72SccXPF++utheT75xRxd X8beY9sZkXl/hRPVcNT9kBxLO1xZnpsvdLpqFBpVzttvPUjqvp0eXGck2dcDEcQN2w4jdidj1m7C 9blpuwgIKu9MxnYFEeOSe+ORIT4ecchd2G/f6kEtR1BP43Vn6KsvDA/MXEyGepGR1/p0bdOTWX3m esaobuISEN0HOn4LvSmmGo/QWQTTsS7MT0sHtXxsIhjKDqJoHGcsC2J0HZPF5l+ouyYbiRlvZysj Hohzmzk/G/cz/SWJ83x31C1lhT+wziKAl5/PdDTP64vLdV0KUXwu+ju4VlgkUyWgx3mTY2CsWF3k dR3LVHNKRqFcrVtd9TU8Dal0/JBUzoupvnIOURHdmuZEZGgjL2Km/bs7fiaFLGxgXN5YZfVHPRKz uERvqFlc+hPJPDPbB6GJRSXVbfEDROcLTVI5nmQiIXjaHVb5HDKGKKulkxv99Jf9ZO7phcD0RX2X VxE7W097NaQH/vKjam3sicQ6MeIbWDe7uQZaiExyUlMNiW2k/M1Sb18EJwmKy2kEgRn8wd5DIX+8 5dH7ga8DvlY7SI5ePk3BciRZuY4W4gXSNwlsUhvos2ZGtzlbzFvQWaWa2TJFW7nw1no3yWheYdX2 aK70F55U/FZ69L/wXx4DotfozdeCf9Yr5rI0TjDnFB/xxNezoMFf80N6R0ZQNSB+9ltaDk6j4LHH gh7y45bQ7a0+6JtdfmXTi2Fm/XZ16svpOtHUpKyqoGeDjyd60wvhu6ydtAXY/X83bKQhSPKmK9OY HMRZbokPSsaLY1v6A13o6kWwA0Q03JlGX6zP9g3Euz6hF4dk6d7/kezB/La5ga9ojfWWgv5DJUT2 RmDphzmyYuqvHHxqTfg9Ed/p67yjTJIv0ysczeJsWd9VW5AzLu6KK7I5u5NDRVi0Xkx43xy7cQVh zMIrhC5nFYj/KJzcN8yexiOlfi5UDK14Q/spUxY/SAHJjSAHNlARoqRaSM829Aapmp5iu8Wv6p79 vM7R7LLq5iVO5tV3ilM4+6nwzZUL2ePZXCa+lJoDvUdju97Iy/DGM4HtXySK4QJqmoFN7lJwmiV+ 1FkUF35oC0Rnx/E4E8HuE3k6r7vkMuN8jO2Smsb4BnPVox/eIXnndj2ub6ib7xmTJLPBadakaSNd SWM179/Cs05eV0Ecg1TClveX8a40Znp3qOYUdmrCpTmDuFBP/vx7wxEL2j3qFBWdw+oOIZU5/tJO 65y+ioAZ1p14/pkoMbS3NVlaWfHUMR5jX99+M7So9K6dP6igVLj0rXGBvixnNvqLovu+njt5XoVv dIzeWFL6vd0wEj6+H0PqpjgkevLvXbcMvgOji9bwvUR3xbGMim6e0UQdjvE99W+8xEUHKwZy0BFV FROsU2zkmB0cvA17MiD1s3j+knWUYdhwXNAhztdmb4RF0cQhX7EssWb/DvWYIbUN3hjybQ8X11PI FdtcssdCNt5qCDly4f4l2WvxMHJ8l7atTyI7n40IwUlMRDcdQSNkJkIj3qQ3dAISFBb8GZrfzSZG 2WHGZTljoqLjn6/uzj5mkJ613mrBomBwBd8V87SY20B6MYyoR/PKdsbTJOW4lChZRtMwMPPuHQ1Z arkTSnZjeb3DzZBgHTcalqooc/68IXMlUoKSkj9Ed+MvXc6+h56KtNWRAJqhnL8tT44U/5iamVIW 6kvKcL2aOF+QX+flvPX1esqng9TlRrg4yNFjcP/kGl/6yFsTBRYD8nzcGWlLlnHhMdSlVVw/iLz6 9ayvSZizYUH/S2xblffM/uKpCIuSY0mzfBBM4CcVv5fei59/F0WXMxSsYwRZL9buEttRCkqqM8q5 caJ77VzfVZu4URI/QPNIyHCKXlS9qRsX1FnGTwQEcyhaPySsSHn2S2P0iSI97dOecy4SdD2ibEXo vzccA7fedS5q51ewe3mU88awWpKvDD1Vjy2jdbxtqBPe1HVpoWj0HtARcUMjXavw+wh2UNvWWfU9 1q94+sOOUvl5kxoqBM0fpWSWPhNs3L0YP7epMm7fnPR7QtDXHCnFWlnJ1XHIz0O731D1ClughB0M G9VDqCfKhu6vQK2tfzRUBxt+7aee8EUUX+4izaK3jvOsRm4t85mE+52zdkPLgtdO2VWnOsPAo70W 3YC119dNULNf22v6NmRvecE/4aKxto2wLcOrz8nmWdZvULyu90ohEzvZrclrDIcpQ8RWjuYNHe+3 uhTlt1Pmrz2XFQg3VJVhir6S4POs8ZbI5vaopnMRVGrhDpR2NyUitpXDvGEszXYboaEteqoSxxbd dc/kK3v69p+1OgTim1KJThxRn4yvSuMKTPBvQLw3jwcKM7C9ubpyt00tIVCnt1gX4LzhmIGb5XI4 9y8E9Gz3GsaXozZTYrComQU57Ix5BjCpLKGkCOsD+aa4Tq/nfAfurzh1NcR917rXkpyJnt46tKja oWPdHytl8Ne/rXzgI7r/xlQsk8QCwdXijwI/bPnE6N92KdDl4lfhnHP4XHpdmV1Crsjaax5utm12 MgIw4DEmZ+LC7Q+x94x8/75fnhKY6JiozUoUXUsqCPtCoKKspTP4vko6vcafrCldOrLM5EF5k5Uz +urJpu/gxhuf5BRqKX8KjjWa0K7Y7IYi3iD8ws2yPwh3vum8r/dUnzolJLKk7c9Rn5bKhXVVa2wd VY3kwmm4vWbaSMPRbKtMJg2GY5eDqyi4Oua4RjeBb4dWxH5cOh//a2iKrG86v+HZHC+/LZnux0M9 FumU5tvzqp8QQ6Jqb9I2WdLsBc4fS5/el8QVjNNkECf/XrNb2UKGtfT5tiFdpTtG87nZeH8TcW5W 8fitEPjo+IuDDcpLuauj7Z3EqLtM+b60MbRVxChl3lt3jzmSFiVsBlZhrjD09PRWRom+1VM3Ez62 eZLerXw+w1lYJxLlyy/s2XadqK0rhaI6fH27NGQIJW88IlfKtzjj7OOp71F+7elHPb/1bMy83XnS W2CPi/oFmadcQz/8VOOdqPua3SOspNfWwf7xG4+Bg2M5XdMhxUxUmt/K6kOLvFPNAMHGhVi435mM wFWc1Fx8Su4ULEnsa1SGIM6Z1cEePMoVSYRhPpFQHUY2lDW9Mrl2d/9DsmrFgY2RArFWOs5caA3N +342JspYrlvDnQdyjYfJPovi7v5CKYJ4F2NM8fSPE3ZJM6dUVlotpBcq/UqqeERrSd9Fh8U0wyrZ RSiUny/wetmLAitixCVudJ9iBNeHRRKhFReu7MH2VWqu1K9XWhbFSslsMcHOn75+7POw1Ac7LSJE izpUvZvqHjWX/HIJnuug7RGOeC1LT+dRTptNS00Zni9ycc321KTTkacSjkTQ2FeZoRqTE3OyF/5c ISIdpFq+x/Q+7B7N/dJY/GY8K0SkeAcxxkvp5TBZ/Fv2xdBlypzrAH7yxsN91e7Ud2si3ocvJb92 rVK7legEC0s+9fyUTgsRhQZFlm6qrpP04Sod+dA+16mPFOdmyvjN5NY8EaPVttbu1Z+S9+FZjoKT VwqQ2tsCUa8fQMPnjerrJk2uL/vS9jYrdowzf34p8Wxdjuumv2HrU5rFcLpf0Ttyg7gzFvhuo/MV fLBN85yEcoeQXYy+ndCRVaj7XaKmVc5RmzOl4Ukziqpra1spPGjzNOHZL9g2UG5XZJwx6I7DOS4U TanSWOGJp1FRllVCIzXrcVhC+iujOA0PiawcY4eNdmjMiTMrgok7FunCNvoDKrltZCha9Z8Uts6s CYsbK72E2+6+wM4Z8mlJQexVjrXKzbeq+uZZtYz86Dtjvrq7kMO/+pWQ74Kk4X5B4VzdX0JbGOcb CF1AdGUdC5R7tf0vgVPzWcIGn9NfD2WHqu3xWPfDp4KSqtkYRyeXHrop33Snuri3MqrVgeEb8XwV UJn8Hh9kT0uGjU6oFzJQGuwZOIyce/Y/HAoMIYx4op+U1TDdsix8Qnf2PLHAzE+bPfLx8+Il69gg embJtZ5OLuV03f3mlFuDeIpONe7oyj0T+YP49apFyerW9NOoCrsmWXAazjH8hRjEjcCOrBpy1kj0 YbKYKeZHqHcPqxrdiXcmebgRWSTam4gJklTFw537UFk4jrq9VRfE9Rs3Jf4f0q3hl1XeY2M+rrjj 0+Pez8fXmU0RDxIqeyistwvhiunVRA7fJz1sMgYHUXnSTFhld4yMiyGOvVX3LtU4S86IfqGPrdmy aK/4JAT48AlSj/dsqK96Sk9OaqLJbWlVVDFETpLP39UdQgRn/2CYWXbGJFSb76wHmspla6XPtDmK exFSaVL6lM+1e8XXaKhkzhD1YuIrXmOJjJ5Ju8zyJYTPlbIuBfGJ1kaU8q7X9D3zd9FOra192t5P bXU25P3x4RSVYJmrNhhuYKSItD3TupCUNbb3h/RiYwj8WtLm4EEExqAWr2vYBBX0k8OVaqvNENff JriVI3jcrxocfyoFbFyzTK45sbVvnE7ba74QencaCqx/Ymxn+Z5h9dmPd1hd/JfyYIbo+7GZG99m bf+871ZZ4Qe9e579dTIzf7zGk1k/8lmys5aXvm8Tb/j588HpZdxMJaBZMs+4i3d7f4q5HpUxmiX9 JJEv0rx2Q2N9OTdXxW7oYVnzh54Pf64XvuJNmFsBY2LP4HhqeAuGSWuJDdiIDP0n/yXxw2W6ZXIj YibbXG47yhe/mpk92a/bg3NBDV18kNEdyQprXmWvWWq2QQPNMDmKNuLvrCav7KPRo5ULR8c6RTax 69fzFftUTsYDFxUqV0t0nR/1KPB/0RB08yG3NCb4xsT+LZLzhUz0COghCLZYaH32nVCrTdFFf4Vc NWhJ8ydKy2FVKKv6nvjFmlXIu/wbAAMg/N8SmUdXvZ80sZwGlApH5XeouswXvegGHTsdNCIfVYMU 5hsOtaiWiyWjhh/IhmCI0RQH4ICPNkludHZLcEgSPuyeWTCdnj2YxH2gWz7vu2Kd/zwJczlWGNuQ mByeceAgiVl5UZDuiZYX9Khqu7QTbP7Qd/erfM9FZBUN36fJxWaaclwwp4yybrHDp5ppYp8ErYmn ah5llyJ3kDeoxW2w9VcbQvQw8/d9OusHFRct0nG6CsC5zFEhpb6Ted4ZphNjtB/dKgPa+LgF+Zke xEmmqDGF1+b14aWLTGvFIncQWI5tQufyCm1jvdxEQ29KipRuSMUnPUWc+BICM0rcRZZhWCsOWdYi LaCRR0B9GvQ4UNbFAArYjkMXWyU3C9WGip6A2qQ2IUFlGe2X65PcC+qESbROp/8IK5uKzicALW3q B1aPggTwYZHpLqpQbl5emUqR2lhqunKUlRPKBpPKcpZ394txLN8tBKfaDJkonuOmKwg+X+AoerDY J4XvWmjgm/uc3VrmjbCq4vULQqLUVg+mA/1Q9PRT3a+eMt7WaY2lTAISCZHeYjlXeofP9N5v3NRv I5OVBQRyzt+xXklptTYMcbaTzXRvhMdsu2++Z9qYJt6tlsikxo+cCTSKUmjCmmw8ZA0gifB0YfuE tjmfhx82+e7ys4fHYmzB/FAzaXzB4vyZdrHvsJ1sMXal6ngrCVmRuOq3bX2VFr/bwyzWF4GicQj1 L8F3TXBD+SsthZvJRttKYIXz3FlyHsvE9TuUAVdbx+mvvSHCiXvtYQQX5GNbv/+bKeWQye8Pgdl9 Cfn/Pab8eGAy9GzVEZjce47oD0nLDjLVGQ51YDUe1TTukXPtwtRHT1q4HwzxENpnTs0ukBWrVI0q K84+k1NlcuAN5uv9H8K9KigOLdgWt8HdLWgGdye4S3C34O4QZCA4gQCB4AQI7jC4u7u7uw3u+nJP 3fdz61Sdr9W1+3N396q1eu8sf5DI2+n6ltBBnrm8ldpN8Py446eUCPOMyHSQM7ewgztsDhoe+55a FajKRICPtNV/Big+tsPZHMcpkU3l/pfcbRWxeNIF/pL7bQxTSmeDZEkGcWtJumXZobb1QevS+pqw 9T4XjtiacfmMMZ0cPvhntCU/TgH252j14McTLmCtNnD+MxB3Js6ljUJliAnFHFgpitgLX4xdWW4S 2JqLHBuZzU9ckLoVHYhOJG+avQvjzq4ZvaT6GaTRl0cIXDjPIQXG92kVnlFwnWB4pPjiIfVk7Sec 8RpFhl1L7gWTo0EHjz5Dz9ubZh1KSvDw0pQQ54bPM7QZYJHk0wNz0kFQoyb8DEktRRw+mcorhepb 1sw1JeKMzZlDh1o4VD8LlTrkWZsZ2lLGloYJGIsHSRTqY0pFBMhFjIKLgy32BziMFnsrL0+IbQbr UlPgrdCRCpQkInagXzKWuy1zXLjFTA8sB4mkthYuRk0Gaw6TCOV0MohcletMvzcOmZB8qkYUQIhS V+DAii3OycpkWPlL6z/ZbUQlXsox38h2MxF1tXGI3P7S+hVhgrVTOHfUZ9zMFyBmHwym0RVtMzPy SrVH4O2HbjypcGwM0TyFL8FSv6tkzWJdtTjaw1o/tH174RqbfTr29STjVRVN5LSYrqPfWNIQUdAq 6ZEzqqsXbK+Xma2SCYUEdmq1kbQOspoFQ17QMlW+YneaO4BblCD2PWkjgJeeChzb1j3UjDB2haqp 0rY2e+lQnxbw1riDUfJqO73Xx3yPXFGlrvK7+lPs3I/expYapnATTnYND6IPZN4gnMy+aIPRqxN6 3PuGmvnj3m4PpGmgmIDEI0FoymaBGSvpRsvzb9MGXwFb95gV79oYFeK1KetFa4jHegAh+ooM/Vou hZj/ne2IHCXBgfpELM9B73jv6Obb2UHLc4sxRsV3KoeGsYZAQYrSKJy3ZYWkFhIXD+WokWky1kb1 HKHwiuJO5mlHqRCREB20ACDZC8K/tVpLKLzE6N9Wu0H971Zj/1/6dlzh+0vfBIeCmMd1dr/zkcBR /Q53dErBHk9Q0ZID4sUScst1XuBPxnb3Lk80gj0Su3lGXEBC+Lv+pPwtmat3/tzLxxPDnqEkZF0v yCjA6JHc1GFJ08NX9Fpk3UjZNVZWauX7VYUFp9NE3r3P23bydXtca3POs2MuEpue7mRqg1YJa4G6 boWuxF5phRWzkL5Hzh8U0PdnG9pDAhNeP+InkICD9ZqPZ6v3+INjXYnCXT2QF80u8RtSf3HQ7YjH moLMSZbECXxC4FQuBascxHexvATPinzK1AzAC+OELsia3ErN7LDZzywdR1sJLKAYetNiCxOD3GlP sT6T/JExcHKCKwbSLP5cnxWpMn2yApg6s/tzvKz/tAbrR1qClAGYQaeW5A91AyqEkoB69Twu3pEt x6Y3Z5p6gw5BbGEPnE4Ucjr4Ut+a3PMGnGYIIVVQuGGqKopEZfNVAo0D4nMvJB2SuKCP2CP8od0Y J9enOKRgSfXaQGE7TJa5VP8kmNAmc7f9Mw0qtSh6wkCzuS5+P2HgMZzL/jPdtvMCwhqBrdeUpq/G LXp7HbB2U415LpOznMdaHKDD7xfYkGHWX+V55YJMNFMEb4XLMSyQuw8wSs6KOEYqtZVaVy9OoZTP Io8cdNMJgTlgjq+bQ8O7aaA3x43FZ+Mc3NJCSu7PCvBidGVh5vWyHL/AlR4a+82OosxDKngAuUYD 5DDJln/5nFmoikMumBRkuKwG0UkKIXSQZIvM5nUaj53ZKfpijbNxBYWOblPUOJ2q3oBn3tGe90K+ GpSAqIsaOMatIQhx7dMyCUqdhmECkuq4xG9NDyFRqjGxEQdaiZVhHP8TkwdiyMdSUvdjJ8Cake8v p2FJ9uqYCWD2sCH6DgxFECqMokfokv7gRmBPSsGQ7P3h8Tfw9vykmKB40IlEhpULDAIqRoiKGQb1 vunmM3rmHzFrRq8661V7DAAZYqYY5TXys4nf0dug9oCDKoYFivBd2mVaGKxJerJMeQIL4dtPuWZB QRTMWKoFHZx7tVLCLsOGnmTtiuh1USp/1lBK/uCfX4ehpHQd3QcLYNRdBfwxPr6ZWSNpWufyUtGY hcDW+lZoE82NfUpHPcwVP06ucrQHXYkZiL1/Hzuk6Er3snKJN1au3lTiiWTFJ0gQUsiNzHr8Wo/0 yhe5LSq8kix36qq/CCB/KhSOBemmnXZJ768sdBiBnp/uJ+c6f/GddhQGgnrSC4hZwLfz/pwE5zbv pqWAjy8LgTtNkw0+D17fnOyQyMTjtt7KR9//1YxcPI6YuUaEgkLk+T+j4P+bkf/XhjzV13fdacR7 VdG86zQTUSdWwJUTLtkrrl8RPvroNcB9p9FOhV1NKEEJKw5S/KjZFn5q4sk+ZJw0DRxqgpL9zBq7 6qIi+OFVh8b5KzTp6kAX7evxynPqhWPTxxqDmJdxXoeNHY6hGUWj2BeKivX6p3ZtWzp1OtchmTdY 1len2ID3Fu2+KtwjXy3bCqHDuL24Hy/F830Xh0WKBX79w05XQQo3Sq7cX4gbjp8YNE/Rm622Gawb dnKJRvLOM7VbhLJU6HS7N3aH/Prz6+VxCRS/vO1xAYfl9cFR9eKX2LajMwrqAv1P8Qo/p88flt/a VAcqF6tGpZLax0LYeGtVQR9/eY30DlIYe73k7mjLANX8OLYiRVi5b3+KTJuzyLroGjCOH8mvgwq/ jwT5sD+FrwD2LBh5+u5p0qF9px0EMlKaEjFrfJLJOyq4wFuvkmPW1YHjLRSPi1uIT1Hhi3Ebdqzg H0M53KlvX4PtOYRXKH/0LUNXZfuo6iUaToXt1QY36k3dd4YO2XW1ZRtl+MNg4h98dVX34RhwZUZ5 PMKdfqlTe1z7VVObZ9ni3amJJhUxudk3O4MB7zyTir86tKQ8qjl/RYt53+91fo1bbV/hlhWnK8Yc 7cOmA2s4CdhxDCDqAGGimh3T4wr+rlrpRxuz/1Okmv8Wc8AZyyLd3j099ul0XheBRIuaq310aHCU Dvlo7ceLGK7k/jfpCaYP9zhL9rv37DlkCWjI6ZypaeHcIyFt/QYhXOnt9rG1oG6FjazdI1jk6EuA IiY+25RNBeimTbCvCnlvY1/RZQPnnKaKwr0bU2F+vx9q17dkidPxbvDxlCs8oTMjVTHbY5deT5O3 kPg+xFgEmCKSnCwlnsNFIr53/MaqiIcugFb6GmesrNvFS2VtgXbnSZUn+etJTRTJke2bgzizFoMj O9UBSmcgGh53d7+0SHI5BQvWs+WThnPY4mHvzWXxYDyJygG5CiekCdPaHvUntsRkgR2nkMY2cW7X +kd3Fxv/nc8YR+W+ssmnQ43v175IW7sfFimxNdBvUWOmv8nEzRCOlsrW7DJS2ftgpieSCVnsClIs bzI+8e7QmyP2Kw2jgcwy8rfS+gm3Elua92lVXFN9gjZcwcE+Ce6Z2W+2acVrdSQ1oKC7hkeDo6Px BIxyY0j02Ir9VcQdvQzDhfiIPD7/6ughQKoIl1z1LcK+t7dX6mONb8o9p2QJ3ycacR/D7xpihSvl bj6LUcGHcdNtxvJHHT7ZHEOvWu6okaY9v1TaZdDp1Y9CuBElMhtger+R4rCRBr45pxqx9R2CLY/D mf0sr8jLWsLYy1l3iXHMPteaUFttBo8L22u9+t0fegZV5bSmv+aKRqC/XUoOP3O/9nzZJpZM0uFd egU4J7IQvtviR3ZQTkgNbff41Q/pK549UcTLkUqtDbTtxSk5B729XydN3CVGyio97p+LTUI6kLdr 5nXfaRxDIWe6JzTft7WeuZDWQ16RerfHRJ2jeeq+Y8/RxsAGXk7OzRT9oZd139emCHh6uKYQ8X9Z CDo0G5xQsN5XtR1RbSxDMY5UPdfd+lPCfRXa32S4sfOxrWvuQSC7PnDZOXF98zstsq1NnDOBJuDJ QYF5plyvOVFRpy5EU0GjTlJTwaAu248LL7UVmiSPYiN9d1ul/k9zNTvcGWic/KoJlJzTL154IB21 lJGNc9cN4kX/WTMXV+JwbGirTLZiIQZLUF3hWKfkBFdm23YG16GJ/zBbHaPglAjvWlf2gUDf4psN 80nOiZZutuHI3byqQTdTt8hsdQH5HZIlg/VsdbDxZFSuFPMKe8YzVp8CiTYeK/GIG0nludJjIVco Swlimv4V/gAaydCU+vKvUBNttQ4efrdReX27j1G7ISqH/AaGNMv4oNLgLrXzE2RFx9KMEwcaU9yZ 5X4IBZC9Zw1JmG2GlvFjoAKOOB2TGNF1bE1HfQid3IV+/XRXKkR2ODEmz70ZUjbKxu3BIwuvwa0/ GbEBpVap2Q93HKNeIB/jalWXOII52fwb7H6PC6PXEEy5qo5kvYYeZK1Cle0hiGQWZNI/2wQ0oGY+ MzWnxCWlbIOn3J8bBMGIM/B9egJ8Elgjb0NfVMChIiSlDkagfs2OTfb0jUTqMtn4zl1EuB69wz1L zFqDVUCCAAsDTOAjp1JqKEEgcY3rylJcdjYIl5YpSKt1pN/mydyxqOVoNd39e/kJ+RpoAlbD0LUQ BckxP2LwgxkUfYktwtg5yvxRxqr0gbkd4HdCOdlRBnwjYuCRuTos6U0uOXcrZuB7E4Lzp/XrU6hg XVHlVyaDOcE3BCOxDqxNo2wxhJbfrJnWcXbe5VeS4QRV7LfgUP82plaeRYLQcFYn49K86W282lxy yAKgrvL9xXeNLICskQdnkvI4pP/ZqOCrv3Ajz8yMyeQJ4ZlLoB3/ohNdZZIdaYYL87yTZf0aSBTU BX474f+i5Esi2UC47zOsqeRrGktw17jZuPskeBQqq9lSy58rN0/p1tef7A00IJMCgkaXmoQ+M2Tm cjl4F7T0zdx40IqMt6WMwOGugPwPLE2NitLjXHrw/BkVSV5Oh1zKdR4NTuuf/GroanyjJmxpZ9KU LWgQ/eonF/au4Bdf14knLduXdSssTzk/6ROW8J+RinOpzeMrLwMgBLjhhLWhodR7aR+2oLOZWzlj fEZoU9rQprln7OMV/JbB3mjKWX4a750eL8b/qtO1DscCt/+Khwqs/xYP/yyyT3VWXJfZMP3PFd/F dkTUUVPS6SeH4J/iAeqDiAz1pC2JtNrYcMtHigGlrxkgOe34RMxtXOvp8PFdePPHQ1nf2ha9x801 jkJrsZBRPhLvHw3t4UhR3hngk29e/CQLPuTxKDWE6uODnfpYR20k7SAP1ZD4/kLvvgMUaMQEKnLv YjUpncoRBlr+JKevYoStCo2D4CAZF8NY+Hbos4z59PaN4gO+L0b8RqccmfRy+D9xyMfcun/RYoWY wZ8k22jJDmiddmshUX/rj27voKn72Knn0cNaIeIzuNkL40O8jqkYW8AljXowyd6ydZjCCc+1n8hk GYSJZhZ1n5OCj2MqncFKB2MBtmSQ8bm9kkLmjEU1mSxyQu3wVOQzoKOmIN/E/PVp5BsiSf10BxtS uHmxqrlgbss6Q1tRp/RREYyh11/h4Egf2sZSJoUxZiPgZpmaA8ftWF6tiiqh8vVGjrq/S9mhnZtV wJiPw6GmgFVNY7iiWD7D3+bG2Rs5jRg8exUxAHR4wHtJVyZVKy6wlYrEgkv6IUEZThGXZQaZC5lj KdycaxIogAteSN4u3mIfy1GRdZHcVvzDyYSHJUvUklcgBOWBa68sJ6cj1AUTsGgyf7eFaRkm1YIn PiP/0BjHTG9+pGQt7iKppvxFR/LapnqYFRMthY7cm7IxfCVYpnbO1cFbd/JMvJVY287dz7jhR/v4 FkzHXDAIw6YBsDzm2THDQXKYEg3lmf6bLrGl4KAAsMxmGtyTQqNn1PZmOaGMslwBnb1U1olwooMI ZV8Kc1L5hQyqqkvCfmedmBSqCuLwP8dWJPPQUCtrYR5QnXf1pn/zrw46gEm95K083n5JnGjJTmcS HpVoFogYXeNu22E1Vi1/vsuqMIyPPPW4meRQ0CTZodIviJioAidYsAU5QnhxwI9Fo/l6G5bkp6DT AJ/Cx6Ut3K/zrfgvjJVESptCHuFdmQN90kacz1YxKL9tFL+8jhYN2/3Ovo9f3JT0lrPfUjBrYQ4x wl5Bh9dfoa3HKRtssx3L2+6YsK1HisGbLSLxSF/KHsBZvctprG6thgdmHNUflwjcZN3LHvLt9Wec YPu2TTuIlk/XLdPK61yKTIADiQzWWvIvXo1vTgReC7iikAWyDrRJPnpmSkg1bsJ65MfpKy8H0JvD EDj5R735LNoi5oJK9UmyopVtxbxmi25bfiiXcwuQxr62b4gIEQdcDwPyZwXYq6Se3/eVMPEBHpZf fTV6jDcCWh9vXw8Mm5DUbXvfqExcI16JoZRexzoNHor5evr6unFtLxLhVq8X3fEuDCXDqT+dU6b1 +FsRvf2ru6BRzmMgAA8F5U/y3wPinxcep7qG8ds8mCAVzbNN10xdNsIVVVh9IsvBkbNRDRMMSnt2 z/l6Un22qmINSF38zqnc9Fp15wvEJ0VurqAbQHh9pO6l8FpMa9hmSAsG737FinQ30XPSK+hSN4b7 /MTHJqo4gDbBhTI0HdhHvQfrNga4hlwMUFRUg7AQzxf1mPKgSW2mrGA5f3Gc8KaHUlyF4DlJ9qs/ OLFchcg9pIryBGcIQ3th866UJ80o6vxKs3huVfZlz5IR6cB6o94q1qDhj02Fe45iG0YZS5ozHXE1 gkKrW+eWq+C80BKJPLJ9ojmz6khF+HZN21o/SvVwrrLdKasLwypNPaRDjkedH/DdPs0tJsX9USFT qTo8g3iVmcL1A0pctr01z4ioPOGrIjQCxljbfmxa5K32tRCREVhEskcHTZGwlhsk/mH+AGjzcJzf 4X8Sfi9TBfL2hVubJQuET1c2beXcm/oj6AAZ54pn5y37oY0ynH0kuBXAFK0RmHXY7jrRoW/LcUN0 VDPJIBGrQav8Knc5+QBjJt8VX2qHVTZ1SeQ3ozAfC+D/eUIYBpWZDJaC7XyCznovEdf/irautbVJ cxLMeAEdjMc5CpvJI6JIiYHN/50/WIhRgjk8l+9KlFiNUCgi7zITL/4gLI8B17oTr0qBcDg+vrAL doSIENwTPWXif0hkMPvWmYvycFTlxWM6wB4QkTohgYVoIvbMLQ21Y9PtHtqUh3ja+8mk9q4gb82D qsvGSG9NeaFawHra03OZucXiKyULn8xv5QmPQUukYGrq+7lfk1hTH+yrZjHgi/oUP2vJVJLafzB9 FByOYkCj7LrE8s1iPvvUN4jJTRC9PdNpv2J9pNiim0pysxi2pI5tW2kLrkfX/YkCgeIU1J/PtEiA 99BhPo/DK5bX8h2x9TAYEXNm1hM/C4Nqkl92DJ238zXvaaod1JwW0F/2XIHFMTJhdk2s/ZuoE+TC mKjDb5LXc1KIyrgNP5W1/1maB9G0/l3xnEMlwTIdb6scl2NKz3bCMy3VllXpzMBH49wX0/0716xe C/xTlnb3OCbup22nWinBdysW2pQ1qqiD/GjGyC6LxO4QjLlbOMTd2ug65oW71TNt87KZE7040oii 3C80EnPfBHSK64/zGIBQ3rNmapocin/QtGChSmlzgmhpl0y4oaoEzkt1MhJJyhCgtOiv5f4HrA7/ gcK1f+Bg+h+gjaiAY2iniSfZaI9FzTGDEnGfnn56jq427/b/iSA9miwkEp/9fPOLYCI7K+yzUVab waMdcFyHyZVonmddi0g3SySNwiJ8eVeztKZivu4I5CGNn8VqWyKiNUeEsnoOSJJY0rUllUqX31sm Plhc0yIZDZU/1Si3bMr2S9ZzMDGy5S5KZq1b7jx9obDjlrFbBuv9kM+9toCoDsvSTyRVq98uaw2z 3BL3+zW8Nc3a0Y+7tzfvLLEW/T0i/1O8tgmyb1/wGZtb9uyh2VgKEdAxzWS1LzEC0JBSnjnKMNcV CjRR5Bvdq3Rs7p19oz21zfRvf2xOZMnYLv5yAcb0ftMVjnQ3/uDphjwH2Xoy8d/RuerA7siM2aCJ gXFcZY5fMsI9UtzK58Q8swt8sqbscGG7Ood3Rddm8Ka6CudsJ9vwTppx9l3IRcgI1/txUgHhdvT9 Uujm4LuW5VT5zjXS8g1m51cQawrgOVznF2WVW4ET/8vVY2VWu9+bbwsgjAW8dK0eGJM314cutA3B KBbP6LBaeo2/y3I+gkdmy9EmMnD7hoa0Jh4nYZyO9u9ezsXAXUgbzN8M4n8PXp5/NiiJG8or/7tB YTpvzmNkripiNlP17MmyDUXk60WPdD4d9awJs8GurBNGV6n+Qo/QLxD5R35FKZ3vwO/u/vry0jtA E0XNzQGFlp5r/Vi926JEh6qS/uZqu7FBJhJMSYRE+xjCszr5erTCu/ORPej3p9ykpOwwLmRFa0eH RMmfcm5GQUtqeMkPzOrNcFGVTwJmxO3Znow5Yh0dOImqsst7J8m7pUxANVDetMVQvoMUF4GJyysd 60ec2ZLkIs00kl+XSx0sQzx4zXWheC8G38OwKUrsSKOPcNcKAV0RIdiILAa4l6ZnUcUsXAdncvMU HnVF+8v0GXNuSij7cM2SxB4UzWzvH9lRKXKsjhbEkOM1C0aOCLHNxbRwvuvPNxorBoVUMsmtdN24 cI1NLPQWPNoruePSdeIJKR4b1MWAGjiRPPXQL4NLeXDZbiXzecNkQ0V+v84b+Wghsh8sDWnzf4Vp j7IT9SGnWqdUxxipEGGY59vRfjhHpMLqZ7H/0IgYNBIG13eJeAlw9hizOHf95mG4LNEFfdIebFUY niPrFKEZUtMdr86WZLddCqUCLR/zM6Zv7Iimydxt8uIotfoaEXk8Ogod2DuAv5Ul5ogYJ2PCnwqQ /VoB14OHytP1S7fWL2oARlIajAmWN3NazfUguUDpRy8rkjqNIsXu5wyZegoglMY3VTBo3Pg5Fk+C 4Dog30TmO+zoi3PKUarvnZWc7RLWyTp7VWp3877Ji/KCn2OSkcE8UmqFG56eHcGLIF8JfwR8McY1 C3NY5d6rvCwLYCNB9fJ99eY6QcMIE2y7r5kqIhi4PHN2cvJs5eR7kG55MyeljzSa506qP3cfG1Q+ P2/vaOl4vlwUcJZPvruX6byPu3PtkvGCfXyWOFQvGrfb2L1Y7rsSupHAM6o9YzA7/BIxg0Rwf0P/ r6rE3qP3yftv7Zcj/Hft//NBZzZxy/GvKhnoUFkW1Fm3Isa2lvqQrWd6qiAzZU2xKUuKPQcWXjGv slUztvPNEBkaV56uTpKb01BaJnBm8bJ6D2hvQZ2op6XHmymIM5PsyWWhVaThYO71kaystPwNTdsf JPtNoUvafQBVmKTDn1MDvHUEf7rbjz1KpYj6IU2/dJuSTW5cnk1Gjf3bOUexQtVD0YJYyRZwn+Ur pkcLvRhyaLZSK0iudbSa2lQ91V6ezv63JCc6/oTTlXgqT7qPHE9+aheXyNP9h6Xf4nVA9O0w7PMC IFeIe/RwAq1KZCA22sF6D9GP5unopsQiEds6DQDE/2BOPIHaA6yEipZG8CM9APcwLGpT7qF5DO6S Z2bPG4mdmnIFqy99uckYNSjFgVnO9suVtdLVCGy73NtWoNekYyC99+JscQmecDJOnWuBCZGus6wO y9dhLmQKuPnPgbos5q5fIuIYln4WJdJdl4yd7Lb81lC2vSnu634OS0YSyh3E6As1KqPfzXjN+cEb seJWu+KWekaagPfm+6F3dTF/zaWVzEBb6MYL1mW4eoL7VpgzaNFL5jVCOw8wGTgOd04iGBw5fjtd GkgofMEAaW8sS31NNaik5U2Ypq7095yyqxopq9jyXwrsJ9MDMd8T3wWMVG5c6V9RW5i3M2qrMNwZ BVOP8yr6Y+Z10E6cUxCYhQUPjMWvDDGl3RUMJCifc6V5Pr0uZXMibdwLtl3wHY8XFCasPw55Ld/E u2TA2brUlWURsM87zzB4+gXc76y9rk1Q1X/r6w4jbHhpwb/4rTohadCcejRAvpD1yVBrsRNzRwZm xG1bCUUUMKbj7e7CvwALIPTfPDH6QPCvZasZQ73TCAcFhYT932X7z3+qWZ0112VpwrZzxQ1TmTY6 yhtY62hObp42F1IVKowq2ah8y1t1G6o4ZasrPcjOrpyPp3YUPJ3Y4pmib7DF0enS+b0f0LB1LS+j TFeX9itP/SmvcFQV02gujS+hPsX+zPgkdWK2ruTXTDC4ziLx9u5qgILle/b2FPPaPlCs86cmNJk+ GFNqEqJlOqqm1zYESNpa4mBV/3jh9Dj5Q/4JeZXx/M5XuCN9mqbm+NYi/fbRNTXkVABDm3EkhI6R qBDmTttFTSOs3LpH61cZzA+9Nqf4RfwLHuMXng0dya5hbsfFeVohDCshaiIlly/xVjCou+rUZhx/ QmslTEvMjDjoppaekqtT8O7z9Xwa2lnlsOVK0rqP5zFsU554YVEJ1oL3MMIiEdItUo2MJqGwqNLB ob0Oe6z4U4EOcMi3YxeXjoQdokFoO+kfDiuWoPBPeaTGAZApda+n/t9fqfk+3I0D0fJ1fNLDKYDx exfqzZVrgPP5MMUnpqOolMMLgJzmzt9BhBFcqaH440+LbOM6VF1+9xQFn/A5JZ1yJa+7/QA1B0c9 5N5OcubLmAGcmVuijD7RFPwbtQsXYIc0tHnSZT8xJZJZJs2mc2E1TCzkCtEdWwZrktJsxNil9Emo 3gTbXo9wwMt7l3ABjVwyBSECFlT1S30pgunEL+UPljr7VnRQ+52cgbI3NoiGmp5JHu6rDLBLPmc7 rD7UIt6wSBiXdiTHV0/NRiNBtyAIYZHokltkR83qeYVfBvO+ZTNzJq6PP9ZE8t0CL06yyFidBpJw 7g2rQqfB0wM+9a13gP1Tc44mPCDNaH3vIcHY4EGWJptyWjpvW1Ci/ChWQKbrn1YN3WnRUbFgqYma rgMLNc8f5PEPCgclztXXdEEF3iqbokHpvOPOQwWSZXQTQ1X1qP/Ne7qjlEIP+CABkQk9x666M+PT SvRKlk8Y13hLvl58qdcI9ZUmmdBJscLash/zBvjM6VtNTuzk2U9UEG+j3tm0f2R/XSY+H+4WChfR JbcYSPHV5Hb7kTZmUZKuVgATBHaSnqsJS82gjHOODkq5+n/cfWdUE9+7bgCRKkV6jaCAdJFeI/0H SK9SBaSXgIAGiInSe0SagoB0ka4gqPRQFAvSe0lCkSaJCIyQhBP/55577ofz4ax77qc7a81e76zZ a6959rzvs589a/Z+qxIVQecsxGwuKEuqb3tVS7mnNXUedm35fsjy29FBCv6JxX09NL43imzpzc7N b99Oyb7DbqH5y6bwrdMSxurl67nvSrGWNWs3c50iy3PbC0e+/HCAx8bEvMhWXvl4b72xkmulREX4 h/9XP02aBaiZ2knWNH+3J/JqVXfeo1g4XYzrweGp/tNjwW6arypwGsfMhoM9ze+HhZZP2iw+lvTQ zUMBOBTfCSeqbtBoLDwXn6TSF47oedD4K+Oim23fUe4/AZtmeVcvWkZ+nK6h/fM23C7lOw4l3Aph 3bO45EybZb41MxW2YhBauPnryqJduOW34oKhUElToc4Vx9YBlrasBQmLV2cFwIWbRF+tVN53LlXp 8VdPmtgN4Rqgw7EbJU9TztwvFcBqCvbXkTeNG1ULMxo1copqV8KXduq+jc5krbzj/y0xw7ZU1Od/ UmPfU+5w3YIPbm1cWNNkv32TvmLdZXZGHkn6ffh5BbWpGSxZ+nyF2lT/9zGt68go+6vX0X+yuPdn Apexp0wjEeWhXACWWuDKb3ZR9S88zz8j/0va4zZtFUdQaO/+f+Mb4r8Wy00+dctaUGEbXmH6zZJw sjv7+tDHcw9E+Hnk80YhcBPUatCUYAWu8h8Otb40E4jKyYlMEpUNwoUIGsp+53HJT4bcTVJEZkUe nDwOf+1XbpoO951rooifaLuBALLSm+WmfbpHhlImB09/ifop7nyU2jkkDoNDR5qxBBptbk2Th9mO IsW3UnN91AQdrPuvO3dJmeajkQt6d+z6LQlKGbQk+t0M1uGKbNUv/oUuMZ0dvvCWpWr2D7LlbkN3 b+mfw9n1n9RdkZXWl24qy4uzf2hdsWD2ZPhip+yE/4PmlOscsR2eLhF4LWfC0zWleIHPSk80+z4O 24nf0TVzTX5dO9J2m7nhgDRa7ppnVpak87MgrlKhXKmffxvS+uzkWTyfK3PpBeT1K/zCb0WLVr6z ieqxKDKp/EwpvZaStHvJxG4lo/CD9a+fcSG5i27NwoUMt2lrTDxHP89XyC/xCdyfrl3LmJVoCrRl 1Aen/dA3/EVNNDgOOi4f7npUNpoiz2GT7CFqujCFfAXjPTUdnJT5zcmwUJo1TLUmC/t57rFPhZ91 eHFvxKp432xHyaYltXKqSN8V5ffM6xhzdrBCpQCQVFwRncv5uFZAUFff/VOe1t1Zv47lCAEHg6vI OBvsY1qljLkjng57ksqbSyueI5kE4h3WosWNGykB9I8esvKOSDqIfqbbd7RKfeYaZkTV5PbkgNay gtWAO2Gw9go0QOzZJakwq/bm65Vmysl6r7XcbXTDrTfvLDLx939Z/UC4lUh1jFs3L31qrurTvKbk ZdLn7TTAq39u0Eulw5bxBq2zldzjz+Ke78Xi/FAPVhpUv9oZS7MKLgzdeafC7r5Iykijs88MEI5v XRULXfc9pj+pNSpeHzj3RG/05Ru6EMzdjFS7CsEZY+m7F6CLsBcihaoBMNsF609ILlbZnUWQsJ7S aADsaKC9ZaDR5RJ3H0MK54XI0YdUdlDVSzZK34Mevjjf3GshbZB2/sTvxoq15kyfT6X/7e+g7Huk 6lYvSuXnJVTaM/sdkv+8qzchBSZ7t3pnHsLkBDm+PN7nYpkMYrvJtpzwq2GaTcxkm9laB4t5b/OT f1DVuHcQPVDca21dyvWVfeFi9u1zxmbaqSIktGf55Oo4wy9zfq/2QE7LS8UsQsoDoQEX9ZSaKpJm GyL3dPWrtc3+SZ+Jj2uFadP/NRAU46Nx+vHrmBui7GoGFg3ppnU/hVjSkgLDXjkkT1Slh2deXLL5 5Gy69rvMoIWol7x7wmZAenfVwPTsJtg3ZrRgjfrzm5+SvdSxn96zkuSVFhWzP8gz7mqO2rsqu6zU YV0kt1dJ7yuofa91rToW9p2ZEeEcPVyW3kbC9+c2bnF26VxnK5mkeqDw2EOd/azrRiiGnR8cj+zp OiYOFtVq4rtWEasy1PevFWcYxd8OV23ThkbuzN9HOp2kNverra8yiZMiCFa01NcruteJBzUQ5Alx q8lI+Lap4NFeSIYGemc4umOgBjlVGkbIz98/Mv24GkVXuam3JIWhpaunMhfguPOUR/yg5//ROjaV /y/XsTX1vtAfppj1qv+5GVmkv0+Iz7+X//G3CKpi6CICFUmmwWrzyZ1H+3exO66LWJcXa2uMaqu8 /eQVTBV7ely7XRSAC8CzmN5tfVulEMozNWV/aG/vqAhFkO++zLA0nMgfjvGZh9yqtp7cwVXX35c+ 6Nk/ANNM+GvaQP+Jqk/P+9Pm/7V0hbyZrLrWssCT3P/wdOcou/7Lg5liYbDwvDJzzlENrvYlpn2v Rf0xS7fKh2RzfR2aFf3DVaf8s7BLPiH8yuqghdbZJyh7v0pDl5+BBw23S+2vGS+1qTU3FkrccXft Gm7ecitiVRl/+/Wnei0/jqPWodrQYwO9oMq6ls1ht/RYrkbeYphBBfxcAZH7Yjsp8lEi9BPq4uND /mnF55pZitIR6iGoFDeW6A94Rv3E7uEVoY/19ZkKVQa7dxVeOEZOX/YqWH6ok/la6TNX9FX2imO6 3xbblbqV323LH9hPg89P5nP1p9uaPdlrOVmXiuYVTxXjRFZT75iB+yXfDr+fgOWmKtH92mz59Iit x65SOqjiNIYa6hY/Y2RuIpWbpsVdqfotaXpvkO1LU7Nm7mF95+ju7eoD7A8b1m1T5Ero5yhdxw7Z uu3aU2eunreR2XstUqrqzNgHnF8TDcYDWAsWmRmXGkV+C1eo3zuT/kCaKHl+Q5c550P+m+W2oa1Z 6ktbA47RuMoXa1kiM/qqd+aDTY4XwtFJSzovxAQY94UucHmJ8vDdLP7i1h16vcjksHx+smrOTmlb c2R87UlfErqq78WkeEe37rWbCzoDtrlL/jOVUiov73PvJtwKCwzXTk+d157jXDTq+FmWGRx4BSOt FBq/79pifcNwJrBB1SUl2ENhgfPyYY1L57Xi5uWg+iuiuc3M9t/EBOves357paLT9OV7hNaEU87E yKLezbjPaIb65WnNiUtTLBf/vA96uoCKeyZFDv5qJcPc2ZSstnARF08rHb462epmOq8dceGE4/6j V0PPnhKz6AKLg6i+TPToMqqC/IDhSpD2q2rZtwteS4eZSwK6Sy1NWrnCkHuGB60rcJWSOtRXTeoN Y8fEw+CRty7PlERXC3x9yt9uWQaGbTwimFYlvMnebpXQWhQ1oH3Cpx5lL0lDmuZgnb5nf+99x0KB nghkwuYklFgsS3tgYs3z87xsc9LrDyLnsVE+wkWhyISrkfMFO52PvJKHWPDcNOVM1UE0aciTOc5S fI5nFuFGqP27hfv7I8VjuY9R7x/YciJvOJUvq/Z/2XiX3sKZ8dL4cCDE8ubuJtbWumuY94d3qGqm dodGprgWs9V7szPbnohz2vvNH7dw5qki14+vMxOX8lhpFGVMM9GtL9hPCkRtQmrzWD+ULsvdhSJF APS7L870dr13uuzY7s4iK+hVq525W85L39MSEXQK7/DizaUdS42MpTm7QZYuiopqhK6AV3SDlW/L p3zpDemtQ95JTH5E9eSCjj5m4PwzRRHpamf3pfJpg9clVRkaRTe+xZYF5wandUHt3sp8m9zilPlW G9zoaTgTvGtoH+8jL8Ko79KSXZZUJpuCQK0CRAnewvsczts3BwsaRaxidKwFw/B18f4zbS867vM4 bHR9eCjwYyaKp7cMcVkCF+3XdNNfXPfLH2rH74jrnl/6FOiGVxljblq1vxn6PrLG43UO4Xf5yRDX 5cYXt1KyE3kJA/S7HDAmowzgsVJLELWQJvHahRar2Zt4sQOizrlPYXfOqbA0XCGbm7/7Ptw+m9vc KOSo/jWfdFcNNbH4oUyyYNPzB9PyYuDHXDcyyfyd1tcnTnkeC7mf83XXxFxVF0OsEHPhtvOvTLB6 /JjJJwbA9xvPXvKbIKrjnso9oN9/h/Z1FPjZw6LS/vt1C6mwruv2PP6nCLY/+/zvbxCGoisjz5n+ tDWnotW+5Nt6xr9TZr8kkGyee2om+UVIZf7yi8E6Txo/XoTc+xpFQaql3JCTYUtmaefZcwFYs9Ef nuluLG/M89esG99v1RvfcMx62tp8a6NFU0glzOvHCkjgc9pts0GF6ORMbpXlOs/4asvBP4vMzbfG edqFIc57InqfhCf37Nqn+89XNEVWMjTrkp85ubC67P46lKixQxxesWMSkBiEKyovrL2ja4i10C4J aY7rQp8vUVituhrE7wplAPhnYdk8YVWjv3p193WpyQb9bXQs3/PWFP7QB18qkYMbh1+WDSZOjnJw +c6LyqZdlGbPUqVSCUiAGgqnyd6TNkygPr2aFu+UZ8wksELgIehhmh6sgqI+1Q57et+KRlwO/lFd +vacf8TD/yxkhQrPE/WC1896XKg/83jixI5upSv2Jh3ZJTIF3s7ZqOVIC/lFH5xrLt/+ObpJj72s I+C5rL7Hx94fbc0m9fTuaUWB6a0unjnqD6/n9XCrWGNrSubHv/caMdzANZssfWwxlCpyqHzQ3szg npDp865xV+MrSEAr/PEtAxqBxdbPvOrUArn48h/jvpSeHd0U5rgd/8LErr2ES8Wan+5ZoWxbM9WF En2+HA8agcnMyTW14BfCbs4qKPb7s/7HKpj0Zt2C3XfqUcbdUdaiahrvlL4xxxZ9+Yp1Ty8ruPCS fmSRPkQSlxD8Bh/vzy49VzGMnL14Y9b1Tny0J4fhFq1MW3P4gc97tmewe7NOfILqy562N2cXZncx l0rMOUvtjjYUKwUgeG/5dd+xyqJJiz0D4Oif9wwN3xknwxrMVR9x+WbPNpv/o9pMg/JqkyrkUk1l hbJjnmk5L8osXWK1/6O8JT6aY8DNjNsSZ5owUBH8uWVUFLpbcMbUl9grzzqz0ZvZtCbPv6kuw9np vtbkrsO7IbDyq7+qdzYBTiMKXFe16DNno+P5c9thcYDN1KslpPShgDzhyZas/7prkKDqS9izzv2O MdzGOh3tKsRQZiHnD2YqqnCz49llr3a5lbVUrpROpSfQuDt88oYBClSquj/Xs7ZrtF1ZdlpnM3/9 85zvOvkNVpxqckDqZ9sf8WbtUet2l0J4zhUFrayPsmpZRZce3ZH52COx2FvBtk2j8ttTmbcK9a6L 9H8sLGf8X5vUioD07HFNoIcU8+G/J/q5A/W2ugsNi6DonqgQr1DPgGC5wDAfv7PZs1UQm6mRiRGI iooKdPtvwpuzBZD+36v/0fG3kf9pG1RnvSB2elAvFYiGShREzU5Fw051NvA3LxEV7b9X+I9Neamo ac7RnqejZ2BkolRo+5vxhYaG+hwNLe05ygye6gHlPugcO+1FEQXd8xzWnnSi4ZzXH2WX0V/Wa+nj shnDX1H0uhvHwMjNw8vHLyYucVVSSklZRVVNXUPfwNDI+B8TU1s7ewdHp1vO3nd8fP38AwIjIqPu 3YdFx8QnJCYlp6SmPcnJzcsvePqssLyisqq65mXtq9dvWtvetne8e9+PHhgcGv74aWR8YnJqemZ2 bh6Dxa2tb2z+2Nom/Dr4fXh0DPw5+YvrL87/OP5LXOwUXNTnztGco/uLi4r6/t8K7OdoRRTOX9S1 pvMM5xC9/oieUy+7rKWP4bKiDZ7L6+4YI/cVJYwY4S+0fyH77wGL+79C9r+B/SeueRAzDRXl5dGw gyAgMvlqeRroanmPSCeyljwOFuhZrS7lPgP59tCT5zyEenybEpDMEG/LuTMQTrjgBZEFL7+b2uC+ g9ACcggRuP0EuEktLNmNVIH0OQPN0zjFeuxaJpMF4tA3x+SVNAVuhfwM5eer+pCXEbHCEd9vdD3P NZLwuHJGKgFRkbuh/jXa7m6uM2rqeqdpsujzKme7spEKSQv+WMhRcKicTUbA7YDVbXvLZ9+QHl9/ LeYnBFwdMvm886ya33YzLMN/qP7P8wpey8ONNOJdUvEZCIriBHhW94ekoaj7y0qkKrgPfuEIDySe spBHhcWBoNUzUPJ7y4GeBQm373v1ykhW3eoAlRgUGvzoCMLWec0Y1clDCBpMj8UjV5dR9XABwnEq VAQvnukZ5RfwgyxxBoprgbMC0XiOo3wAQ/DAsO7x4HscSY+7xeDygMvpDfh5Al1itwCsAOcXH7WS UViADoImx+QXQfFo7DCKzAXso8miY91SgMvgvYIV1m4pWPXW76ip1slmJO/WOMx+SbK/86od2nJH iaAmUwPWs/O0QUxnRSV+CocxWqFEn7c8qRiI5qxbtXNXpD8I7tlRkpTxFZp6OvGSwES/NcJb8NT7 +qBRKHvpdNitJJ+8qZADteELWvcsCz3xwKcRNVfDm+flOIMsYDFjNSeZhoh7QUi8VXox2A6fjK6D zvYcdRLAexJYJF0QhFMZOmeJjiB/Uj0D8egIwcHjh6f7jHNwByATx3cGCmKCzDXp4jfTtUzuzMvH aakGEE7tgVLs56nJIdQqUwqcIpTgCl93kHj70rk/BUfOrYD9KiuqtJU19QwU/IAHV7zfewaihUvi 5ZMjz0Acy7Cio/BJLc0qoisQgQO65QEcxgKFRw0tX+yZjkq/4Im4GiR8Ed+Y+goADxbypBBty3c2 0fyOqUGwIWubl6/Mx6t2K6TGm2wg7rZJ/Eq566l5Gu98vRNfvZTKytekyui1XxvC1FnFpW08iWv1 uFwrYf3Kuoo2qSbTtknjeTN6qJq6QWYovUkqsNvFId/buJTWhmv9BGqIEEHMlOLtLQVhqkfXgQOC x6rH7j6hrn+lFdI7On95Fbm7RfBeHR50k1j1IEqAzytD0ktUABehptTD1GAExAMuRMgvxu4nQy52 QsLxHzwAKEEfey+t+xphNO6nVlDFPOBtAGQt85zEkxkvn+oS3QH5U2HAG3sGQqtOd7MSDabJGojB Ze7J36UXA0pZtWyxYOYfEF5IwGg8ggpIXS2+Ry+HEIVDSp1y+t1lKa7XJuuI5h9NCa6HihfZ4ZFp YoUrZjPU6ZtZwuFvkiQUP/16r2gTn7Dj93gk6LYC53zBfnMEetOJ2fCmIWtg7Xgt/v2TKouqu2a+ hYjha/UTGftc+e9bBm3q/Hu83SwycBaZUD+bV21OErqn9ieahvCK02B4GP54d+tUE0Bhe9LglgSP vnm5HBwyblmw1AOQKCfKEVgHzGKbUpD8ZGGi5vju7z1pnHhOI4zajcNpSsvepwKYxllNVE5TnIDW A0i2wkceuSu0fYc2nIEgcL9TT3hwGyXoGohWAASnbYwr7YPM7hw5kLLh4FMD2P7AiXn7rheCBfZ2 wrUbGFNN07kMD54hhtTBDo6yWgC3oBoY4wLanX4CcWEWrkZYLsWVMgBvbIHUsiZ0pj4aITF9YL8V G8hZY8Pp6dDtZ1Qt3mUaGdbxzzofl4XIsOOgQ63aEOeWz+TilEZgo7j5QT1kqsyR3YLc5OzkaiRV rJFHiu/TU4vh3HThSm146vuUuZRB/4IRe06xacfi8AWmb3ZbcqHGtgt2Zabte4lcf07xEWRGEfwZ CFuDIvPAeAbOQOd6/JvmThaOksaj9pBHroSeYRQTUfM7XOzUxJ8s8D0U7veyJ062k51ghqXLJAsB iWTh3h52Sm8lI1uR8YjzRMtJIphUc99ztS7TuN9dbZyokLoKBa6SUwkaHsywHMzoLurUH9hcVR3Q DnLHH/f3zEf091zo5g9CMiDEAp0NUSk+E1EXFPunIXzipDIixyqYN3CZd7ITgoFkrPDq0BKVAbEH ERGYMxDbCtF4QosWO8oEQzuNt+GJK06JphcTNQ6l9BqkcrfHYYGH16bCDmstpKoEodO19v0TvfYZ ClMtdpvJFcm1znLn2QIrtRvUjarkAhmVa0eUr37jLbSXHhuYaDi/ZddnxmrULep0EpHPmC+cCDd0 xlfo1WP+OhkYwwpcRfVCBYmypDSyJCzCHEiMZt1bwe6B+yB0WmyR5lRasWU74zDI4LI6YQ1yUWkU MC0ywi9CzkeCQcAombu1EJqidWNevAaz0yWhjxooTBwqhcbG44fJjGAKrozC0UdNZDD58xmo7WcT ng7bnhYlT0e8RmqSQQjAOFwAHuzCwj9Rky0EgxJu/MygduzRc7xl/9J9W/zPmmp/D75ucfK3bgaA 8qgGBCbYPJgWeNPvLj7jxwGpk/FrzaiSuXDTnh8fH38G8u+3Rk+X8BcbX/1e694a7hQDUzOqc5o/ FGK+3OBQ7GSr/qSG8aup0isKXXd8naiFvsK+8uXcwl7Jda0wkpf64pdSe/Ulxn+1bmbgvdLtbXDZ pCN2fzeaEjr8BK7hXfbTc8AxJboIikclpMaeIHmaIOfkRAQ3nBc/3N8AxloOPtDvm5lpL2XTugWF Yi3ZiRcBDoo39utQ4xcL3c5AaVpmOAg/XBNfr+juXyI03thGYb46tI7gDNKIIgf25717Ia2bCVpm WHn6rRI5PDKF4pGbLoAjIRbjMfBA3nJM5wpRCKjFFJnLW82QwbBttOG0ljHmWZuZtrzrmHKX6oAw M8ExnUiL3b+wEyORRmSlUB0HzMNpQrmoOy3Xx+Lt9USc+qpfSpZIX7e9JUNKWcIA9nZlhTrmqlcL 7KZy8E3vXX+vcJircvTEgGOVqaODXHr1KzmPEDFGmzdrz9cP2y1Ktd95O7eG8W7n+n8daghUk3EL tCqWUY5G/4iR/iWN2Sdy6vwEJ2u074lgly4P93BpqZ6akqcRV0iFSE/5uc+ryzn4LqIHrkEak1+D 66FH9ptXw9qxdGkIPsCkzSNNFt+ObRoq9vMAygje/To0+GG0LLhvmQdPvAbr15wji8SspJyBQtzE D4xI+Yel/DC6IzSpoNOEAD0ae0t6Otxfyk3UBMT8sEUrAi4wM2xWG3cmQdN2KsoyDUE7gwABFSb4 4BLJCbIk+QuEvdO4PrC9FmPGygpM0+cMz1+otgvx2N7OsYVlWNjGWQGBNkN+TBKRYXkBlvmvBjA+ pT5Kbxg5MTbVjN2aTMl14JBUtG39K3kf/ola/6EssMrggaSk0Vse8ZrnUwPYHxYsVrXxDSzgr+tx QwcywnK8gubOaqnWZc5VkLFX0oQz0EAp/tboIwTPa6AdJ7A/N3M01AVInELIE/NnoN1swiiOnIxH Y47e4U8xw4OZHNikAnz+il+i0mh6O1gIcRUGdSeopmgpixfUEpkBTYLF0cjMgLMPKvV3EwuQFwVm nY3lKiVyNmHIz8rJk4pwV4Du1BgOIszsVpxqmp86wkYxdIOykFVEGYFuqIeqwJxwuN6USeZfgl8B dghmmOV6qDIkqUQa31kiTFBFES9jH9ANOJw8aE9XgrI6BZ6EVkQUvK06VH2q/nJ1mt+pJ+TKaomw eojg+mTGnTwTiRyspO9Yxu1NrdeW1xJ8EhJ2jH0SB8z4ZM4FWDh14CryR56YLAjJfIuWn1oyIBVo KabIVL/ZXCt75tC/GmRaIs2XUOXyOyaNuApQZCGtDBBFqBhCntcSewlnJFWRaQPArcePiLo45BwU 6zgMpSOq44fjEDouABStUqI8pQRmdIJ5Y5syu0UBiSHv3mOebo0x4mXCBwoh9TcEDbqzUAIzFa6L MTO/bzkmf8eyEHnbYyF9CMJFZj8D9clWAjgCB/Y4vVuLPNXzpn1PiCBh9RpPGRGof6wwUYgdQt+o xT8/dTwwXICOYU0lSmBlhSmsYQBh3kVwLAFm/THFG2VYW4KowIcgt/MubusWVRp5tXY1NsWm3LZV V02mbe0O5qYrfxiadgABIP7fBmFKWTYoejR6PDHG/rJJrCqfXZ4OXDFJjr02uZYxd5NfWXJyY73K IUs0N8hqwKbhysup/qkapS2sp7pVji2qdaPG2vhoOo0ccQbyHl3YxKEGzD0R4uSJ7iukNh2eW3Bn ygD/An6DlEVmgYu14WuIHNX7q91PSuhnIP7psoqY6YaXMDnWlB7Bvd9udLqA61sIWMujlmg1rfyB 0kUnfsniAB020wzTWIZN/4D6jqKj9I8VmQk27IbnruLp30fFsFJkGhIb1dSHiut5ez8Fro7/tXIU CrQTIA7TVfj2JLgm5unv/TT+muEGGiPCcIZMmwc9UQcoIFBk3SMdduDU/fUEBo9EHRZB+InqXYRc T2h62aMGE/dbCdc3jdJypewygxfkPkVo9dBq5Po5Msnck0tm84ls7nDmTZtSgNUbhAGG7ndrRmFP O8WCffhHrJ34vLkCG7lE6Myonm7O+Upz8NpnahmE5UrjpyMc3oo2MNo1A8FcMUCqdSb/dsGWIReA On1AgWUvAbidqiKWEGKkYh1O8lgMQCokchGgGNIZaC99tYmaCCY49noklLY2JXWKRQslJzURNXHg FCgBOozr7dbuwQ8na8ViUbTkUY+LZFZAYoCnfRrMBrev2lpmAzIhCd0tgB8l8LGsyT3BLqxzOCwq lWOAzEcqg/gWqx7lAbR17gFk8NghmCWolHkTr/oQ4g9JeFkiPKaU0pZ5kYEYgv+MHU04FLoXYjbo EULoGVgSORRAMcL80Br3HsFgpKC59xY77BbK1xpqXbj4fKKTYvlsAmWNim/myAxuzMIN7xtfyOgl OVQzvhWHES9omQ4MYi4z2C9NDX1voI+dutZ2jS/LPNdLJCXuuKtS8eYx3aMGvbSGlL7pqqx8TzM6 Y1r3eojuj/K0bFpO6xv/OhH6sDMQmWEBP3OUTPGzQrgLsH9qTf60Qo3QITJ1kDIhfmegJA+mTn3C MGa/bz992tmDIsuYKPOQU6x8Cr9HcqckLtaDHUhHq5pgmrgBKcqI5eZGYzYe9bIxpD4kyk1vx7Sz rYUUXV4xh95R07I1te0d5bPJuJJbOwJbrFH4tK2RHbg3jt6I2rEKzxVUsPthl/NcRMNe6SjHKTiU W3aIdxumEVXDPfUPmrZo/d1XZQuTOamOjMZE/m3rwhLuqphwq1o1+5o/8ad34fRAVQ2Rl1TUzUf+ BGFBiG6dgai6+Yle+NfEYFIx0ms0tZuNlK0jAys9ihmD8+A0zXl6PWgQovoEgSP4mI5AQCHrIANl dooadGZN0rkGF+km8KC7mAbInOOdJu12BTeme8Qo8OIQ5JmCUibkajWCFU8h43/j0zyjmtrCdZ1t Q1QIIL1FQVpAmhQpki0ICEiQ3slWRJpIE2mR7K0UqTlKyZYWqaEjHSmJkIKK0mtQIAmgNElAcAkh nJx7ft077jk/5p811ppjzO975/s97xiLgQKtLrRubfJxcXUF2GRq3ARSD27HKDGiSU88iajTCRfY QkegpO5y5H2AS9iZCUYs3S0K9nQA4mwbQhKYWncHUlg8/fktwS54Ma6+HOm3upwJRYeO9q5m+cly lUrFzkGTlDHK58nAHessVbkB04zlk/CogDp/8F8s3qkia1bRgweBU0lqli2J8LG8M/aJKk8swZZg Cx2aLNz6aiFR8PMH3avjtS4Gmbd0g3JEJJz6R/rG4mi0K1wP3SMdZiGfwDbHww88Vgm8sOBGqhEN QxqeJbxbOI50/K83dA872L4H0tz5E8JAJM4bAakMyFmga1tKg7q1p80Ek2HJ89qjeKXgLov6YDok 1WMgHXmSXsRjhWcSuIlLnuKjjB/BMs32oACaubWXyK3gA+R1ZsfGMqwPlgLh7RHhDgihaRO9GF/7 Q1zUAjWYhACzYw8cYlJoiPQeTY4e0MTy98qmu3KV9xwm0OatSpbcIkktgGEk8FnAhuLvNfoA+YSO OkekLUjEYPb20mIeM0fLzoRQE3d4zTZ2LK+446YCp5x68xtPGlN7PeDNRdaRZUnWD4vE4A/rlj26 SbbzEW4+AYQ4rB5YtSybtmZ6fmVPV2VRucZrJtqmaIIED7I7j6CiYKjWXxtGB7eQ5q3cQxC8Y1xp rfvdnBGE7BFoEbsgzgGtThWrAZGhVWzPMdh9MF/CkOQwuvWa/EE8hSqKock83PIAXOl2p7+n0B/W LoaorzsHXzPfFWcbGa7zbDQCKvpEQuZCK2pDq2KGrQxIMJ4E07vZHofoBK0vyFMEll1fyHm6bhaW SdxDA9e5poUHv2XJVrM85hYTi7WZv5KRGg1UwgxeYz7GzGnqgclgCUBwau1qJnQeGpY2JSnAs4QS FZQHTqa9D++MjW8IIy0JR3SJx2WxwvPJYx+aZxh3lDv1k1f6LU+v35XxTmjSv7Qsbg3NU8yoblM4 8x/k21myyB/azueTdGH3V4dEc63eVlPzccD0QRA3kNslfEE0w8iQZ7Jih4mEAG598DoQgSOQH1oM eGKizzY9fD5tw0ouWoRRyxaPQOiekJASBFvssBF/5TCN+70PL7O4m25UxXYHJ4e0qcbrjiOvRdet /9LrujHKGYe8wZKxVLu9TO6+zz00s99hzxyBgoYBhWniwqx+H0TMd0rHKJeLhQMMGPXhN+/2Tubn rIZ5rbRBYn4oCc2zRk1a2r+W/Kp2Zk1f8nF6nW21J0IBvUEW0dWcqOkXCCRbtIf7wLWjqx2NaDVs 1bTIlRUrx8Hgt7RJXf5bXhddGttxwxbRKRTX/v7yQGuTQ2SHoARcMLvCuNboww5bu7KulKb22CbZ OTdgMrLE8zxcXShXYoR94rAA5os9vz5vAPAEsqL3IIdvjHnphGddSqmNxs6slv9znCZkwGEZ/niM GV0ae9bYklnNdj+AskUmjkAPIFSXX3TngdRxMkeuecRuAPEM0qKDPw/41Qfl1/3S41xpbwXiq54I HpxV2sw+0GKLHGKOQHcIggkUQ0oTZOMIRBs+zT7Pct10WZBKOBGD2gtmifWjUgyd8mUxrCvvukxS 6I0inPF8HInr4AhbJpvArEV6H+gA4D/RAx3zF0ajYBmaMb633gDpdNi0oenxY3XHVY9J3DwhYHH6 AvO6tECMXDcurVGFrpgfTp4gTpNpodCYWz7yPK4yjjwOFVdRXV2Cn3bOGe6nTJZAxd/GB0XVjPQ7 EX/X8sF1wn7e/Sb2rJQ5o2YW1KDEm1T4Vy1tdbKhpmtifaIsmeS0TyXBr2bo+Fs8ypOXknbdWT2Q SvhALScwb2/Noc2f2BDz0Rt9B8oxaDouBeV3cE2StivVmAIRRy2+5kgCTw7+TJjgQCbUflTknQUL AKcO7D2xfFIWmWrGIqyVX39m0qyipJQTsg9TSg6budkN9Q+hRX9Diw6eIbpNuS6KJfWoMs3IkDZH ZAgApm3NNpJQZxJkvu8EeLiSCMe+73OzmfOB7RpKEGlFe2JE3OZSaQMLtTG5qAEmM+a2BAKoOIq4 sUYFd2azIKu4fgI33fKanARMpmnf+jSSCPwJ/MAxyoHTpFoPmNnYJysBxC8eXLPzxBc4TrVJIc4B NrfGdDzjNxEOndjbk+r0ZptM0/3Yhh9L+bE+Fj89GE6+0u1ZTjj7xSm7PD+3Ltta7lxq8X0Fz/Ro qxhOzWHu7nzaFg9qJhmO9zN+a2WTpoi0oJEFgdwHcCOhQq5A81cMctVMQybK1ChXPdzeOpY5T/aP xmL2HntnDYwmSdgn+5pG9MWf0w36GYzS4PD+l2UnjOKPHxYRFnM4mqyOfgjaR4+F2chmajAQ70Kp PHvB3IT4wNZs7x4w34WgYAViYKQu/wy8FPIel8msEobnj7Gitp6yzZjfTJ+R5/9g2W3+8RqAkfCC LIWVNpzXmokm0yfp9drCm4U3Gu9qEYnFx4GmOsLGFguyFzaVoMV2nkCG1H6HSKGCUZCEmSOQLNIz tBKw7Mf/MWLsz8LSxTJN5JD+Yz1aDJtMnv7HhtdwxCMQl2mkOFqAvhkzK5OWXsUOP+yoXjeRZH5b cHK1tS6eEt93lhez1MzyhdeL7zhkKK+8LYwsDDkJ1ca59Eq+za5Ps6dMkK/Ce8sUpBU9pfmmc5pE ql0L84v0reFTOf6Gwqp3Ap2CaqpWrcWDcr5r1BryjhPHQwymKMNibCabB4BUBh+BmLfAZzlkAtcK 7/ESHhygZw72nrHQGweseJoomqVPRJzkXI0JQGqxfj3f5WICQppzkksg88pAaNkq7LwuLIWjAtiw /Punm5HRh9g2ZY4ssOXM0khMuGhVY14eI09+ASjtXTvsaAtGzeJusyxSWV2/aB3EBUA1JfkIFIhI QZwhBBKo4D6sDCqgcbZjz3bcBMS2Z95/68tyZJhPk0NTA1mygSaaAFd7PWDaZR6GxgBBFPClEdKN 5St9gI7bveNIsxIAtn/sDROT9IggGPOMTPVPRsJwMS3k9i4ZTFqP3Z2ywPYEOZYuNtl3Qo75Ffdc tzY+YPfy/WniaBC1PE4GXxYZKZotW1Gl8NSzfvl99uvqMg2/9OQ7l2p9K1I/XDlnG9hgHdUiXQYh viVbjxLHHi1W0XceQjLd1MzIvky3c0SZvDs7ChZh1Twe5bWjJNpSjspdzVnOHzrLLm3Gp+IxrFP2 UJP5Dp3eSjF1+pm08zhJp2DfMDfj+9Ck2Lob4ZBhXAbXGo9A1BSXw78JIaincSgiuBUJB95y4eMW C7Epw/xFhDHz2cbpHCHwM0MMW/g4DUuZ05BAPfhMn2HDyn8vnDOG1QIFHMHNSJdxpDNkFtZ0f4TB 4iM3ZOtf5+4iB0BYFuNkLNMplGrKIMoi+p5Ec07fYckvVuYyYJuNYBgVrwj4uhxWIsMbYvw5ghOT BeSwJyn9HOhIlN1mQdEZCPjLIWHDJa6eUhYcHxh6MO3mo8wkJPeE0hoFYq5QimVGehDc2Sn6PR+X 3ONMsxMOlEwg0BrPx0R6NWFvTf0ECwR41PfOY+q+51MKoiJxa/kuZcGRvlVuX+wCo0+M2FwKWfHV hLc722mU6PLeiajzcX9W7WxgMZN1LCWlqTr19nJk+MdAR7LNbLzqivGuw35LFr9JAyL/0PVKY1aj TXEeLDWAJWtSpPG4tF726mDnj7Zz0jgViyKlV8sTzIlJPw/7d0OPKhzcUqSdYAJ4HgCxV39YT6DN RCOEYPczXfdigNgDyKqh3QBMhm07hb+EvMCCJCfoA3McCQyZC894SEz0XuSIiQjblAXOqkcebwCn SRJIGkJrCzLsP5iObiM/ZaTMmEm4f3ZD7Dwny5kLKgeCCSQEF8b6pdCA3Bz7BuB7BDq9zfmAagFv Ypk7e0+5LUVemyTQQCw0GQPcTIB8B0bY7tVYEVQo+lxwyoFZnzwp3yd3DwIU+awSAlsOLLfacysC 40Qxld/zFQvulAV06SYV55YHSjoX4bEVqx4+2FCZiuSCyhkPS76KzKTMci2P2VkqWaS3rceeeC5Q Epq+u3W3yb7+X0bTxF3G7pcBsX8n9tJkx9qQcCmjd1AgyULn+0EU5hvCObsEnqkk3a3xEvf5nFMT CoZxrH32bjGMi1rZfctXpSul8eOz9v2LuXEvSlL2XuYG2u+vXIGkO5KdSHe9b/ndhPdUjZdYo3cG yhP6CK0bBP4jkH8j7xqWX/3RHJbr2H2hsEA0dZiC9megU1DBXJLfmGOpkhBtvQNJHEXqlwF69eaW euiGiTKg+AN8JpDrHVNY9ebqasBlyvuKa9rAZ4IfGlCCZZmIxMD2wg/zTDQ4lCNQ2zB5nfA3QoAj 5b4GaYWkERZrj0DSOoSZKyQTAUCJoQoWQ8KAURp6Fj+3R2R9yyhhkTMbk5FKjd8RLe24A2EgmAbH su4OIc4qoZFGTDqFSBfGjl8WIeZx2+itdk36CvLfuFcyfirdLtWuKdpeaLmPQT3mEL/nJY7gZ+8Z zoM8rmeWMz5pdeb9rvazUdv4FDR8pd6j93GJQ2ukMuweIfr0/dktQRa/nmCZ55x9YZAvgBE8uUlz Hzj79+B3pQZf44HfY8Aq8/geEwg/kET1ca/uX6iniOb7Faxtxt4LFmQznQH7B9HKh6UgnhYLAra+ NDB1mJxgDLyqj9GgH6JJ2LRiaWC0lO3LfFjN0BABzPqnOPyALyM0SfZyMSKZintuosSGje2GynBt uOkhUqkGac6doMWcD3qPwwZFGjfMDgTZPlMc6DxRoqtlnB154BjMjUG8zPF32UEumyb5UTZYMBIM VNPX1682mMz54wLnpXoDlsd7rPzCUB6qRaPGF2ka59ZkoZNsAxqKH0A5s6a6xdKMQ6q5mn1VESSr xdKR5E+nBRib02vnzgbHYwXW3wC+xAQZ5pIHvvHySonss9cBXYZe6tgKt7m+StmHGW+yEL1uxjrK KnavJkmWfMRZDN9ioGtYrrIy7c1vvJJWnpxAVC2D2RkXk+QJ9qipbNJVSo2CRsZLjlPuzyxD7dGX tKSvF/oZ4KOdTZEshBfnQ/Ip4dIyG74kyl0/U521ceJHrLm5sJOAsL056P9ebl0NBN9yu8DgcNGS 8KgnfF/Jve0FlYggR93ejLxwb/iq3wmKcinmdktGT8H1wAn1PyPaxD9G2Cd6lW/dy51PbT8Usu0Y VZwVgZrmeK3BNZ+Gwx0CzQ2sLKBbNh8d7G1qAy+7t5lHLDDzZo9AI0pk7/AjkFx79wQDss14vxSh zWMgz8PDVmhH/eRluXqh3tc37F4dYHduG0hn/DN0s498IEnY+fHE0KT9CLSEYczOQRruoL7LYTin sirTlgm0yy1HoNd2aV0MjnlIdDUFtjzw4v3SPf4IC34wYPPgCPT9PL2h8wj0wtN7LRz9O3wpwkDi eOGLZ89mJo9A2MjV0d2OI9AlguzQwLQm4aegzRHouKWjjw0diyYcQ/KxNN5hT7JDWLU0jWccLaTD 071vNEw/SphtyYxO4SiwzdvHXbjciz4Wc95lKsTYkf5dTWhoc8uPycmtsgxq7+AzsriQ08j1RN4Q 7OExpPM0ZFs1uBeudQRSN86ylL8Q+VIznEEQNYEAEIZMNxUonaObl2ss2qUegcAyjxDgr33dN4AW 2nooX0xWhC6YPyiNmlmR1BoRsCOi5/LLVn5NNC4D1nlrzYGsIOFQtintmVP1+SOmwwudlxN+RtdF 4mN5tb6PG9IhUXh68ptioQ4u/d1HaxGtR6sWDwX21iZdZKzLhdetn+Ya3HU2RG47yXuCoS+XrVtF tn56i2xbvoMkygoBJ6NYYO7MhQbo2Amte1zG/s3WoNklxmGfPgInLZw11irxoMYE0xLSK2e/BD3G GD5JSWsDywIr8ZsmC8R9x2CYgG6w7RWioXqBb3AowhLV7+l/BPoTKxI1wE6jbjlmoAbR8i/ev5de ypAOgQrBZYd0FSTGyux3HJeKDCYr4OXfJ9JyGJvK8LIy5/Fqh4wa04gyl3p1j5crFVkVyvoej1Rs 4eWxvj66dxm8HzWrcIM8gy4qTmk5vlcpVnCt/Bz5iVGvjv9ZXX3/a2tMKI3sAywcXU/4rQDsPZ5e /xexf7riCPRPWXXp29D/TV7phqhUNV2p5XEHPpcx1qa6xt10x9Hdyzq2IYG6hWIOZgrLrVqDSzao +81Qg/BvJaC/D1ybarIThlysPnRfE7JqPzxvyz4w0k0nWlVRepVUdMUboqJVjC61TbaP2Tym2ji+ Lk1TvfL6v/+L+f8v1aUtCc5owuURZDQDwQNE0wgpunOwk2txLi8ia9cRgrt2/F4LPkE+Asxv6bMl Y3UJkjGlyvWbmz1WoQHNJnXbny/37OgIkK7uRzpPP/Lm18G4T7ZuQg1uJJ+v8pmjSnyCSjp3uC9Z FI26W2WJRP8eCRlUhhXhLxGaJ03UkEETj9Y7Qx887Amhvap/uPnKL2kEKQ54ShlrK19csrr7UsUx otXBlPWh+abXXNxbuFCxksBknEMuxE9JLLZfPSjMxTGj5HF27lho/RQGoUE2aHvQcZx3MVynms5p sT6fVDVZVfUx111v1ckhMBIaWoBp7nJ4sBt5cAtpKzHcDznGfp19BBLLJsE2mVeYN+6xU+STfaJP zmpgXulv8rAUve8OeoYm+fC4P/qq4TIuOoL0mp5VQrt1jakvd+r7L/YbawRRT9hfbp6zVj+59NJG t7opYKUet8Y5KYjQ66CtzxVgm7+qF+edVNss7RIkyuR+Sp5fGXN+fPOe2M0TLDJU6kWoWvbHdunN jWKIvl7zzJy3WbDw6JMGqnOo3k1fteYvlspv/dwbfBOtmfLmS1624ZI20qIjuh1v7dTf7Wz3yLjF t0dGQa0LvsG1rWqG4iN94IUODvBVNkzQ8/lOtT2Xo9ve5LoaB8WLmGaomo8WQvsdHIgWxdlpQdC6 wkIFKZ3ZBQjVlx4wlCAAiC2fwAI9xRePQKH/YJ/KKy0ZSGvvdKp/QL6t42aTBWnFJlr3tUgaIknt 0edI8jw/s+LzHoZl5zbZWIegmKiM9aiExJ96FcssMOvAi0bHtepfoeLr726dcIR+bC6D7pS5Mi90 7ED63/nwpH6uQ82p+osbeGJsWuiE1pulWvKe1Cd5EoyumytY+2CneKlQtYn+TMd33X86Q8TxvCIn nkzCxHuE/4Bc+JQBckXQ+n5bYtqpCnmLMtBtN+vWCnhOhYRTtZGBMuJrW6xKRO+Ptz7V+v6D4zap V9rS+sbzAhNJpni5DCVJYRVv0yh5sU/fksoZnwpzsx3T0yNudwX/5KQpN76AuZxRLv37v1dlN1TV qLlULi86QsTZSejTp5tnav649BIEehn+J3+DyV6M2ABeOqky8da8MCt5JuO5gsn92kXcn1UJkSsK 9YMNp7+0j2u6Crz33caKcMYSTowuvx1HKsj8ImVGzC4/dTNWXepI2Xgod072miNF3xaSUqL5Hi3y tRgTVbfu0pDVHLBU9sfO8hGIrJGej059wPZfAcDWE49q42tt9YnpJUEeU7n8BUjfeK5eSFd8ViWn KqpEO7Soa3l6cSfbSnUqvY+FX17yHe/3m+n66CyiYiE7VJNeVPJZxfR2Zs4Gtact0GO6ZeR33cJz 7R6llhI1Z8NcF9Wz0DcVn53HcZbnretdlaysVKr6ra7j/RXu5xYgSnRcPyVIHeKQ2psyGNIT2V+0 yXUBAnV7UJGw6O7VcgxFU2tpbnsieckpUAFL3oclh9gn3Pzhn6twY9/6496gQ2sHYbxhM3Qj9KJN us2c6vOGevXXuWaW13o/gS9dIcr9x4dL8Pdr113kOoNG6k292qrhBaufRbN/xttM6sW73XoMlrGj LrJ0mgTWN5YKy5avGsELOBsMsSUPrrXJ1/1PtrbUyLBCBr+2VAu8FBFjQ3nx/qXyo0dPPN+lsbqa m5sNl7SbiPxn3hwQTsW0K9dzNJFhT0+PiV9gEZLGlEtSfbPmdQElZvmFpzp/Pgu4fUx90un29T/0 5w7XY49A8gMpcNiKEwsD80a8K/QPXEdvnWP8aNfGG9CHZ1vMWXbpbFuGMl4OeZM5+S1d4+emndO4 znHmtreKRusCf0CxaBr9U0w27dvzqJvnqIiUnwxDvWo1i+VL+cKJ2qVxvx+rF/O3GeYWTshKhlvz fnhrfCt/9Gp96W7IRl7WZ2QeKpce+UBdFZzo9DVgJQfa4eCVPjugXiahHqzPgmvkUan7OuU9Zqbd zBB8dg2xcdUwc/7NjplibnTA5l5wgGNsp2VqaOtmi21bzvtR7983ytOF5Ubp9SpRsGOXcwJPpT/W GFuzzF+avdkkJSigdUnzA131+djS8FlMRLIbPUyhODJU2eSfI9A5XOUeMMBC/pUnnr74vc/ggxfy wuLOxF8Z6qdnCuwAv2v6HRRYOuPEGxKCx4J3yJpB4+EpLjtxJ8yCNLdmo/vO2gHTRlEPVLlau02m aKYtpReV9pK+OOcUFrzsKcIHSWsU9xeqHHoqv8TxXoeHV67Z5NfWDhum5eesmbeJ2+IDHBPviAlj NIp8vADtdYvJS61vWsfalMO6kIowgc+xYSZUPa+591FGRVBqaFNsfVXFYlSgvNvGhRbNV77bmzd8 HZji78QBIvMGQ1o9QRNQ9kswH8TrdS2GDHyV9ZkLrSDQcn7OL4hzNDKEiIJIGXElA1V0orRsXIZg Up/U+Qd7iOb2pNCaAI/cLdIRKC3ukwdPKlKf/q9OvSVHBCn5ZKWMFhJvx5LFiKx/59ZKp95uw99x /LLkmtFli4+Br83OfLEoF7HT64M6r1IqFeHl90prlBROrVLOaD1EfuQbKKpcmqjcDNimiPCLDvml 97tWm6mXv9mthpcRrRyi5M98LMspEVc2oOglxjqdz5Bbevul8omVucgKR5i5W1lLQ/GtRe+npCni J1r5ZDl7dxh24n8qdPeM1zeo3xPoq+87cXHlxYz5OQGyuJF8ms6Z9B3NRC8/g4/29jnyP/psOxT0 p8KsFHgmex9/OZSr93hRC8+FhhXWONbad+X6WWtlqtinu2ZC69vXVVUvvYzbQKcQQrmpjAvH6Ech nmQU026LCu5f4DHRPgLdZ0OZCymudOzzBhjNaTYm0gZIaozBMNQ65s90A6qsgf5fxaqs6aS5fhPJ USQCtRjiSZqXSbfs7GBOtS0ewm6zjE20do5AfGxxbixrcPuOl2Zent7kY8bfaBoLQbrSMxH0Q2xq JetXlrEZg8/GthtLRPDvglMQAii/9V5FWBLVP71uQ1cmkrTvSuZTomDmz7Ngz42laCGqfQ4xiP7i i5jd4xyBQyVOAtvxCJQ0nEn4/brs/31QV5FCHDxrDJnSCq8w9lEVxcF/1o7lQfNktUvMBO0EJSfC HrGuRv073u9YGGADQci49Kg6ftJqDX47QR4+v9tYs1jmOuNQoiB9YxJaPHDujX2jw7M+Q2ctu9NF 4Ho4f6trSy08rDGF6Fyyg9pQXdyaE3sHa14gQs4kLMBEE2SQYYe1Op3IGwRhE0Wkyshr5tZTYzOF 4bS2AAcg+N9awrlMDbtWpisxXg9jyyzcV8RU+XjEHO/X9F6Y/WLddf3ur2mC/XrcXgqtXvubB0u0 qeK74bWXKd2TuukH3vp27Q5h535hXhJDRVcuuiL/bhGozbvg4s++uG/HPgRwR6CzWCnUznUfCEt/ 7+EbVnujH71Xihw3VEQPkRsNeTSIErWJYiycpaRtW4+Z4dYxOI9RXd5XH/WqaZso20vC8QcyTp4e RHCUFY3l9sq5WjclMygrMvOcgqFOoHmvr3UmtEEzzcMCqufZ3b3AjTEBd8KydDRHyJM43nhdV81q w7b7cxiCS7sk79rX7MK7L2+jLzksD7I0No1CwhTbAF9a+rDQVf5nZFlFm+GzAFyR9OxzS3tnW+h5 IOWDygrUY9XwYXbCvzYooRulsZt4JEthK60nzh0vBxT/IuUNnYUlX5YzVPrnL+kXkjF3J7EHQToB g6UA0Z6lO8E/1hqtCS1/rGdsVxozRzsC/cu5xiyaKqg0dcOKxYQvs/SfOeg6+PxYv93e1DbZY5ya e3CDozSqE6INyble4wWVuBzk6TXn4zkQ7R9+crLuvd/TlbGbPy5/Bb9KrV9JvRWRNxPZ9Ld3yo9Y 1HeC/T99fiMZQbeXSFbuB+6dQ1Z477JH1d24PV+FWMWfv1DqQy2FnHpuCYfaT/GzYoLCcs9EoAs5 hqPBtdXKVkblmD410VUh85DgY6QXSWnz81SBaqG/VyXnzKVvHqeZnra/feF2TdPvvzyG/np185SE 0ytJ3WNK73P8VQW2c9oGVPAX27JVX8iO7j0k3mDNN72+Hh4aGIIblN5/kP+IS31Zu4M3flh/4az8 mPX5cfWv9lZz6BvLQH9pi5OwgHtTKdxrHULPV2gdd7Pxjbxz8aVthFPWPI241d4e4uU+B08+3Sfa PrV+0fIlSzG38qXsgKNQ+YTmT67JIzqW8QcNdlEK4h5fhhfaMPLh2yojg8unuzr3W9d0vpTtGthe P2i3tm7+1h3qafqxsB2ZGltLeW/dJXxBFHr7aU3f+xd/ZEZsnHJPuH3sCASy++khqSOJe7alOIE8 3riGP9WdZ9HZ0z7K11MsM+EXQl6eRCpVeXwBHu+vhItn0TnXTIa9bvaQ2yY3ENoeccUYlpRDU7FW NB+p69Hp02/GdUPsrP1eXOqM6szaivpSbVyzMr/7wrd4ZUorVO39U5TGUOUL16F80zelsdk3l5Ju OsU2jCXfuy1hmq1I/+eYEJKgcSgyO7WCe04kzm6TGwIppZgrraUMnFppaWFHugNarcDRadpY82ER 8pRhc135uD3O2Hh1m3LZytaWEpb9kDe+uddgZzzRSWIzQfKwoq1IyQ9H2uJt3Rutcjf2XTwb/9V6 +vinz0PVi68+DzxvnSDd04k7uZWxLKQZe6f1H3W+jvEEERYmCRleyefbb8jB0PlgsWnuP+eqvgV7 Jg2/8kc9PP12vLHkQgU56afer7xtVUtjwa5m9NDhH7pHIOlbUwv8Pboo+uF/UvOdQU1tb7+xoqAg SAfJUZqAgIWIYkxUBASESO9EmhAQEBEJEsgRpbcj9UgVIQQIAelFipQEgYMIoUhAIEF6S2huIeVy ztx7573/d+Z8ujN37oe9Pzx79pq91n7Wr6xW2S2cMdxgpN6WdllP7o0BBWjZFaaoFUZYXHKwBkIC +mypFnwKb085jOTeAnh23JLvMyGRiU1e9CAxkqifvrQksmOunvElU1hMtN/3ZkQFPSq8NRZjddBn CnQa7WJwQbCQsdnr63UBrvn24QZV+kt2kBkRv/Zbc8nUZGPr2uSOWbFIYcx4aGxHQ7mgi7BsdJue YDjKTsKKnWTpyUwdkpdk1iTvPAtaW1fS/Ct/myjSi20HF3BB/VMxWEYDc5+LNIT/W0RkxjaSxSLs E4kTF9TbXz5PxvbHaXJEhrmgOdl/bLr2Vu6vPSaCIwa7uh8LI6B9DrkQ0flGCcum9VU16XpJYxBV M7PhH79PLM7OC9ov1WkGqkgnqc1IfmGqrKnUxJ5rMfC5kqJ4lSaigDO+ZHS9XRJi6fMz43lt95K8 bZOnabitRr5kVSpEOWDepFjZQnlZwmlRzbK428FgsSbfyqtyX8+eLvqvGnZWHf4DzVjsYvXkXJ5f JgCn41Zv+rFpWSEjZKvp/uipSqvVg5yrAH7Gd2xvJwHIZFQ5ADVMd1pOeYnn7nyXenTr6a3+gxiV QZYiAQUWetwiyJICVnEsf3YO7Ay6ZQ85jIiCXin0gPP+xgjZHk74E6MH/la9FyIfutnEBb2Z6cCD N5XRvbll5dPGV6q3u35G+P20k3Asy35hkuXRsxmOIAwXEEyzFkbjlYcLCWZ4x+RwW7+SvCMmd7ze 6moGxgUFMTYwv1Kv5isHeNX3nI7z1M4IcuO9WJoHOR/8grd6yamkvuFBab7lSQNFOn/F3mVsmzeR I8/5clVGdP83xbGgHwGx96hARuiQZF1cizhGKHemPy7gpk9/W7KjIwbSwBhdeZnHulDFBb22M0fK 2LBuak4KMfqaCxOg1/2YAgggtdhTrPUb2AjjyYCzhMnwxBZlZu7KL6YKTZTAMF5us9RCRoSKYiyA 2PfAFcM6ps5avEx4kZeKQATWKTE699TWTZcOyeqfWMF3zKM45ihdLBz2m9TNKzQvDBhAotTymFeR gwZKxXZLqKL66fmoZCP1nXq6p3OJcc5lg2GVO7kjWRc3zMLtIVri1l+Ljb7GQp5R0hQ8zeIqNBhb w3hFafgwO7zEqbi7J1Ur1UHm8d0sBUKwLTPjSXFPU910bmQTlgYPD+Vl9JPApwREgJ/ag8aZdPhp rLdmFNKxoeZjQ8K4ZaYllhdQWlPz3WKi/AJOA8+HV8pc00jrkMJarcn8JXOTB6lJhq5JVt7NN+qe s+0+Ll3rSrsUP6tmXbSpv2lgqe9o+qLhhkNL2YpKCkNRhofhQb5EQ/AzKWDm+aoZKSvwzx4uqFGL v6wBcdBvGns0zkVGmLF+5hIXJBQLu1TjxwVhyvfy341hj+LZITguqMBygx2KwEO5oKknXNAOXxwX RPl2mvC3VfsntVXamhz2tFhQ5pm+L+Xv7RzQhzrrTmwaEoEL1MWvkxOfx3/k2jJWdkYdJUbm6h8W +2ODC7J9u488romVeG0lGNwngtOqOd9tnKpPSar9kBw78N2x3yI0YaFDMLzDebHROkOYQME6l8pq 5Ab8lXshXV930LhPY+BXRzFwhS4Wub69fHcwDwgvRPv8ulC+XX7Q1r6wxmPDFtc+4QgIra5BJDQl JMc5Sg52JE0hBzv7Q3jr2ydMdfbNOeC1Ehi4TlysraViyCdvl63JVqQbfIR57Kmya+h29ou7OS5u IbAdKa/6yau6YQpRschBMD8X9BnZhd2BjO10sT5zTnJBru7LaVsTl2oeOwA32jV32ekx5U0qtI/9 wqgKDa3AaLWtm5dnkBTaY5+YXuuM4W0p60zPtQS+P4dWJXgONi+41xS12FYPu60sXuvNTMIM4o7D 3MU3qn+sEcWrq70/Qhg111T4YmIJEZ29vJyq6NfFe5qWSXhDEcsUC4hyTIFrcTtcRL9YH/W5IQjG x+gPC5VH/3TNEWMUZMgknv3MRCaea2JsR7R3XFmUkQq2YFpWKEW/HpDKFBBYFPM4vUJd+mDivYYV aHXHHnZc2BWLxviprnc6aJtSqtlOGlzQqQ5f72k2zG7Zw1f0hvoRm3nDemu+8mTN6DkmDOf7m6+s acK5N3rb8k9zDs984pwUJ0OVaJNaLhx5UYyL5wznF/Kn3m1S9F9M65IAqdzKsGJjZeHxmNkUz6s4 VTeFX7IfDY3OpU2SkR1Bj+yi88QHrDPKBaKKlb+lSibN48yO5Z2/05N9I1jfLg3aq/PXoB7ixMXx DpHmJpM238OoE6e0JUknLnbmnYs5/4eynrRHSbTkefMHIrdAvEkxKj2wgn8SM3mAC/rhwYx8XPv7 Cxc484JT1or9Ftlf8b6v+AaltAyht4+I+eQzldQDi/tJ3VkR4V/hT5H4K/tSk0uvUTFLPHF3E8yG a/ez2FplnlwQqQ377T4XtC0gGpBiouP8LPx/ruQEK6L7d2KZPq9mWiUBeEfrSdb1sjFA3WywOjYb aQsklqCfzu1umjIiI6GOffypLgwKSVDH19ebbhis82bbPQ3lPf/2XcRZ8gF2IUwhbp4m8DL0gT4X FNtNB+8AEsC5y6HabzrUb4StpPduJoqSKSxP4DvvRQHFxCYVybTDxzIQYVwQr4X9qThD9yMVny0m BLpb+CPgkTnnc46XEYkXyoiqDTlLHZaDvkTijyAfp3jL4BtvXZJmf7w+fi48c+X9PckFqopSzW4T DJkWYnXSTFCcbIEyS05Z/sJrlhQ+yF5xCVSy0bH5jnOlGm6sPMd2Yqk2CVKHTANQtIp9tyv84ZmK 1jOaaUniFXN3FV3hHxMFHHFjU5RSPapv7zZLP926cmScZvVyxEHTcLiaVA0Wg+zoz4yoVcc2+Jwc Ay4m8lFrXwobPq4djH0ZJJfU5/nY9np1/+olpoY7/BiGbyMMwXJEnOKC6j71twkmb0gnSARNiLm2 IEE50kNyQ1P6+hr91dpC9kZaS9SHFG96qnm0bpG7EUz/kKH0/T/sG1DMwwdwFnbBem2Tv52ISXu+ 4SunQl16YdTpB6eKDqfOhi3m1zUmoJztMr0iwrzMBS4wx0m+KmPPoB+VMW9SnBi4w8t9mhL63XY/ i3tW+4jjVrWx3zdpnVDjbFR7gMOSpk3pEYnzQ6+VKEnpa6o8x3Sz3MR6HzX/wCnZfaxi4zFPMroi Vrb7w0OFKyiQfjH0jfZ0TSqSdNPFsqUCKw7gDRi4mhVJt/l2b/5JwOb70teJfs/dmtgmwfsE5Z44 wo5FqAuQNuggZsVwtY21tWMn0kfbVAjR+U1VjZUR4xzR0bAy2wUkVV81uVO1LSnI1F/4WILr2I/L VE44aWb9UJ/k5xx1xlfL7y/V6vC3f6OSjBfw9QkWP4Q+/uFjf3nWRp/pf19EC6IUYpySfX3QNPlV tnXteNXcXHZZWkbBCnXZt5KWNS8YmxfDGekcjH9hneh+zML8CcXkQWzSs8GCqQu4RxM+mVWoPQLx b7VljDnNBWlHhrcy3g1if6kl/megqdUJycHsq7M2fy5IdrHl4ysu6F2TJkdgn2W6s43+BUdurf9n Wcmf3pWHQSULvFVoSIGDBQ+LJXX+/C2sSFdAnFq/WP1MmHbNJBcqzzeE8/GonxwgBjt4eRHGtpEX Uj0hFdUhqbYBQU/qW3zdTa/MzhHC6jRVnjdnlzdn17pb6ITyc4awjAe+gJL7Sh0TPAOO0oADivjO cur4dGEm3RqqyEB8yuWBnfTiSDK5oJi3LD+aAP+SDAQbyzkJTO3dn/Tk/L13KXJb4NSyZBNYCOua O5awbDE0NyBG2698Jxi00KIFpL77CZZsncYhaxEvQ+UxqoDfNAJQQJDXRRe5IEHMdea5PTsgG1XI cmPCIzgS6DqaESktsxStR9LyjeQcsPO4Yg2sd77Axmv4hjte/ghk0r7DyS0SFCiECe9ofNSch+7v yFDD9UUmkZwY9TEGliQ9iV6DAnmDGuX6Ey1BZSonbUXMhS+d6qVtxzyJw0sbpjwBbEZImrdfnH69 SL90LYiEDy8WN67GBkVmucWlHYSgLPH9EhR0Y8Cizcbwgw5nP7Xc4fM9DXv7LXZsgQtiWMDH07gg +noHMiIj8e9l13RcZGSoLDqT/LxxnmSk2T5V+yifph4mqfl7K40/uFmdrs6Sa/3ABf1OY2pGQ62O zO+D8Iem29NGtj9pWbtpySg86yYTS/Y6UjXaZLgOE2M3tz5eP432okPT4AyEkQd66hO1/DVxq/lQ 56QSuyBUetFRbqAGfBT9k5yj3NzA5InGOnsRpYGEL71tVyUDX2PgDF8z9rsm+WJ0blcoP0OvEx49 xdvkFRj0zvZUUrG0XF7giecyhSonYTbne08aXkqw0Bp2HbT29JIyzRKugHVlhBugP0/xXBtFUwi8 OcN6mRlxHo1/+KU8ysbAZEWMT8VaEc2+0S6pPVvY06cU6z7z1IWkV2HLqs2vDlbvMIwH9A8ZnTCt FgqrbB881xCj85tI0mWS9KljD28fLCSgSPXNFNTKtnG/Rf4vDy3/eOs7BVJPio99OUk28bliYOJz 2cDEG4LuVlLNQGinMNZZ4axALsjFIfcx9q/E6akd3dAGX6MOKStCmVlH64YYc4od/zykggu6DH+F HZPYnW3WPOHtWFZNYJbvbu/T3n3KJnZUpyJCALiy3+algZxC+sF/l4NLy/8mJg/8n2IxD/5zAs4O m4Fv7RxeWngf83npn0mYH1vYX5JQp3HVdzJ/9rMMxd1viN28lNVNkSJDq5f/na09sUdlOU1dXBDi 6yYXBDcmZLQynyB3TsPZ2qRsN2ET6+yzOsIPDuxfPPPqcTbpM5pdilZuHqxAWqDlA+07HdPl7YVC dz+59vC+6lA6oH1UCvpZ6AzSsrouZ3DcbMjb273D3s5u0p7kq9CVczcw4oq0/72yQdgo8nvDcxmb E94t8Uz3lbH3AJ7EUWCmIAVhcmjPTVL67nN8CSrjABCklpJO9Y3UQPDp+D2C6jM2O7UKjnqrd+z6 ZUuZp8k+TTLivSNhcvHfx6B9h502H5+EXpVJtTA1xRukuO2VueKOdT2aHzQZWCRm1Ga1/vlIWinb +Yr0cxX+Bd0cWZEoghHb+UEm3tK/MsnE21HILyWo1kdLIQVzb/nF1yG54daabZ1hCRvXoTTO+p62 y10GeKuv9+nK13fhMyiQoGLaHTl0jfzIdoOBBrWlWPb2iSedjpw17cOn5IeeyB35U8Q6P4OuEf5c TunC51ihdFFOcsDeVT2emGrvo+oxcLHZiiGNbC+zXJOTDOer1clG9ZTfLBIOMeJuFHsbnJ+ltjgF Z+r9/ueq2v2biqzLOZnjM2ASM8zaWf1V/uF5eT/Gq1f9JmEX62Wdvb/PjWHMpV4Tlb2Sht6zP/c8 MBkMXTK+YqA2gnDF4Q9fs4IVKzPjbQPxNiWjncPxywbZkmWBTxwH6o2TA0TW6OmQ6RTY4+HsuSHW 0UcuZ8FiLTz4df0nRbCLaAWIhdoruZKovzDHhp8I3g32bjVWXSWW0gyDDdGq3jPfZ9t8hZ9oy/xE gV1NlN+vPXf3LtG8cUU6Sf9XRO+O5VfithGfaTOQy0TYxN5iqkewzI6mFnFB7eWvEE1DGNVyFEd2 kN4cAqZFpBaz45ZeuOU76LkVjRlpHHOyixoKazW1isyYOT+jbJrKA7unnWZg4vezIdNIpXrrxU0u SH5nQj3FeSMLppADMd2p8SpuN59fvdnvfqx61nXkg5VllYG6a4rB+fdN+UsH6zs/MmH4EnTElNGQ hqpWv86wanX94N6toQDDt3818seWdj/5eQqdfC9al23z7p7pcG3pAao7SkJ2ZflfkMLWuKeUKDpj BOkT71NYolgZoAhjNcGaj3a+P3VOTmGk/MKLD3X2XNkJUDQwjWmne8r3G5tk2DPiSgvK6OUB79Yr 0eOcCAE+LA1MwG76641BvffpmWefnhOHW381lBXG3KzeM92nemH4LxukOY4F5LJUydiNzbQ9xfjW hYeMOo7gbh0XpKkRkkye2rqItuOCjrH3b5kZSx7544gadZagNheUGjmshIUpckF8frmsptmW7hnf XXGoKhf0OpTIBfX1gV2ZdewTfw8utMMtuaC5ucaM8zuUVUMu6PADLmjWadsA2R+9/3DCnQtSv6ih qrB539t55kFLTWvzSI350JpcJeUHRdX5EkrSOFH64rhRkWfyw9sFJJVu+R/hs2m3CNKeUZoL79+b +qdrlI7re6RYJJnony9I0pdL0reRpOB5HzwozIh5mlaZMp4yr/TF2OxpShZeSb9B/+OHMrNPWWhw W754Vzj0Rtd9bOf7/jhve+yUCmdhQatxFnq86yVL8lIc2qyj6VkXy+ACQB7uYm+0riWEjTI8saNU 5K6Or/roj12X/4dY+g+eKv3LBGmzw9P03A0o+tkMxw0h4b89zDpOfp5Tz2F8gS27qAyP1MB44dv7 emZxqQU5vzzwlMYFxSfsM04Rdkn0xPn/XZlZ6A0u6Cz2DBf0bdR9HLwpC2iy3+SW2VGekIeX/jWJ sUd8d7dat7bV4ZtbSw1+YPKn/TLM900an3jAMxMd14D/td1ORmrvFlqPPh+HkXB3ZyDIzx2PMMnZ BMelNNsRXEgwCi8mc4rpmFlAKrKzXWg5WzNygcgyKUYHWzYObMdLPRhYe0eRS1rr2Z4O65mZzgXc BPbl4TcidL8nC0CAUg0mvXg7c+oMtv3Q3mls+2fvwyxEGFnguJ1NLqDYDfix/2g9ODJjHfwWKgk1 CL2upcMFHb+C0QCP6W9FsoSlpnPJ61S+HVemXgd2bIokWfcaduE7OrLtxXpETbb6TibwcU/uVh8t V8jaK/2FVRTnIuY4EMSUpZfK8I16r+TqMPGvmyQKARckMz1CvcaITwd4wxi1aaQ0eb8PtQTWd+y5 oFexZWswDXvWZXYr3CWRRycwhJFB2Xky6As9Se/D3geCaVLHWPsKmy/2HtOiP54jhLk1yrIKKW0J L+2gtQpiDEdCIcDS0uTGrgcmcHq/f4kiv3tcexBZnQaLjfd0pJxJ77bIttFNGaqQUOUxjZs1Fepo TynRrYU8wGsFbEzwe1ZAZj0e+gmIwPTSRwwgZ6RlLvNrOO31yr81j79wX/a49ilqsd1SZbnp6fyY 8pc7wllJnSbL28ixZA7fOBFjDLyFte49w/C0ArIEIPNTOpi3SXb6yn46veJoMMoScWjTLo5QbK40 UB9KAp8OKBdDBTpqVKQFt0a2iI1ywF4yFxPNtUit5KkIjhhljcOPjkko3oPuw1MQBBEOlyoA9PdQ oX2hgsyfsZwr1GVwlWgDPf5qV6eMCOC/p9DGFEUIoq1oozFQIbhrJ2UGyMg9AUkEdCD9wvaGTDHT Biy/7SIFTTFvHX3cFDjt64Mc2+Pwrmq+wmjLr6/q0bSZd0Js6YYnvRBAxTQfmL+vANVBFkB5TfdJ 738DxJ3R1V6EMVGMqv5WvYeI4hxkEyG54TsvjmblnGfmrioGubmHCFCnKut+x6IEjk8CU0ign9kA U0SLkWsbLYsZhE9MD8ejAyswgYWv6OQuWV0G+SU8IlQUUCRJ4sL725dzw/M7A6cEoSimum0uXSZ7 RiVbwHQAqu6HWxwMpKng7qSEpF4tMlQnU3IUYpvdXsU92fowPJdEvE4f4S9TlwonFQWj6Uw/0l59 iXjAnPOvHNU7KqdXCIOdm+TUe46p9o8UebTKsq8PpVicaHmP4/XPV6524hW3Nz5jUKo8hHS0IVJt qDjW1wmkfDVfsJ8337hd//OK8/UZk5P6ZTKTEo/4mXc2vzBllTUGU9VGPN5/SH6aUjBobFSbLyJe +H1VnHSe9DzOVN8jSS/v2Pk7p4xNH8Q9xF038PdUkpu/rqnUTd1IyUzJHveuxeTtubHUgHxm4PRW qDBgiGKX08VZTrRVFxPGFAsSuLrfPffZAEHbO4CpoyJYGr4rbTSEJMaNofcm0A+/jHVlzEeWrUJN 2G/26Yj8Ub4snuA4oQfME0O7cxl+sGRvpunoftaxhAV2nJNGeuZp/Ml7V+2AhHb2Okt1Ol5I/UgX 098IwNPhIpzeKVF1TDBdXdgWwFpRtlol0C29dHC8D8TBeJm0k6PKuOOV0fqqaxn8/zECXH9oF6Fy GiJB6rrYs6QLmQjNi6p16fAeIuia4o2bUI3K4sWWebE/Pud1/unhXKQtYXYoBj2SdfGpJ8T8iXXJ 0x1BLxGDizY19wYsZMW0fKrKr0+myfJpAfU/SogX7rTRCE4h2BnFdnVAzb0TKclSYyI/lVOTaTyf psJHbDVJ31Xo8+3wKJg0gBAgwQWXbC2LoBBGrD0jsTNEcSeQXdh0cnp5/cyCjMwr+lEccdIj59pg qCg6souKq8UzMuk7b/JROaABrEXLgQUZDUZ52Bb4BEtvxI0J7gQLAHy0tPiZxFNG5WARwzL0x/uM gNT0qBoU5gEGzNjjCOkHnLTl+/gWMjCN5FErGZQaZtRFijq9tw59XL7C5oKOPM9sazmb9HMnn5EH 5MGIfvIRNXiWNeNIYuSjQQ3aDE91DeNRAnY6owpwoZnDzid32j62DcF3Yg+EjmT0t+/dPGSMEEb3 7yQ3VVa1RK74fttsA9dohlVzQYLjnGG4WLVvrAz0I6VacbisWgXO25G/KFn6Ij06Prs2NoSW+Kr1 qHHVY4yU+uvVAKKLGaMvehhq4UJc0tJ9STOSXKPcqVls0/gQsECyzegwI/LWx/aeGqqSdrM2C/Ds pn+3/aN0xjLtnGZeRPtsytKeclnuCPQv85AczUMWIT64ksGODV3DMcegFx1DKYu6jm29x6FwKNN8 /jq9pSqms5geNFcUQtARttQr+q+rzf9NKZBYjwAKrf/lLjiSpU0POU3ancwsA7IxN1XQ8LuJdpm3 KmsZ81EsFzpYdPlDd4gzE+3bPinESI+C9BlprK/ChTz73bxpU0eBQJLMxZFnYH7P7IjqxtTyqC0j 536dlhFvYjVScDH90iJlgTFxG4YLoQUTrNxGIDfVNMNnBtWGqRI/nv1xV/Jc2ZnLUB1fPNBqnK7H dG837BdGne4KEqZaRZVyzni9eDbgqeXGiS3SUU3A0WMzUbKtAzVGCP0mvSjiyNuiqW/GMiNrdCUZ hRwFtAdUmkEQ5A0sqDBL/BBw1tHfnHkx3NbiO2/JV+KKp2nZorFxuCfkurJ2soBl+AVdrWtFLubK xng5xrcXlVlu0Np4ZciiOfrFkNwCXfjRzLWh19lKZlmSPoqkqaPwaQL2w/q+fjsCZNID26diMr40 Mzo6ZPg+MLe7En1CJTEGA89W9ToCM7IT4v38C4FAGwYuMbGFUuj5ojbWO8itGA03aqiXbMaNJMoB 6hoV5RS7ieb5uy1jqxJXZ/aUQkdC4UA/gzCtSLrKTOzMHaNjeWwxngxY8TQiGinAQjA29royHCaJ tO83HAZhcsCNdrFcqveRcHZOQ6GNTiCWpvq8fa8Dplo7ANVz98fp9C9OVWiuWOUvyEgzCvcx9fAm O1ujlQ99wxEpDOh12Aau7O1pWC/IiDC19Irbc2QZc4mPz1GqbwadHan5M92KokoMOJJoOTQjdsB3 7XXL6N+H5OWe5MigCV0cLQbPyuw7tBSZCxJZ34q3oqfHYcA09dehEkyrTiLiVkWI+u0hDJZ+Rsy+ cpjlgn2PquzGo8RyzjUN+WiMS8gMfrnn/T3/5uV8xDJ67HZr0TWrBAcD6zgV8h18Xd6Fm/Y+Z/VN CEY0XDTOTkCbT9eEeCcc7ex+wshA3D5HGV/5PimzfHWoQkTmkExRk6ac8+LX/BXctdH51yXBnn/G /OEluDJ8rFQ5R33Ca5OnjQs6DdNEJ7bDxJgi6+R+CTtHrxbpAcjH3mB1Poy06PPNpQxXTYr2ozow n5r7xrk0y3v5OUtBg3Kdo/x0m3NskX2/82rf3uRJkeCA2HQu57HKphgty0usAxvJLIhW1plO5A3P EEnvdXM42mdJF9A69kjh1sv2XunL71/OyalL2CGQcu2DxRf06vB3SgzS1a/g7NLWAqmms411FsFB jvCzZJs0hddP58M6Zy6WmZKCjXWi2/03Sm+E/8o3pD6dtNPsKVh3Uym/B7sM9FzJTXC8Id4NZ97H iF1D5or3t+tMTKn/FYmSsvNDTgaJ0JmaJIKNukIdMDwTG1S+dmQtXxntP70VHxhwpvSq4ERjH6N4 Rt+0A1FRdZGKK4U5ZPTK3Vky7H05ZAc4kudGEdkQNoyn4eWar+jc/J1aw8MIjXtO+hDSkMLH+E6/ bpR/4WJVz6RrmuDEuF1mbIgU8jjgONdl2uIrddtDYzbsbmU95fHMkE9ne5D9N7uTvq6jgp/eEDqr fk+PhVSvuguL/tT79qT3Ye4eROq68tMH7dc/Nr4JL8gzakGicFQTI8dFXeYvcedrEVXhFUDtUEiz ptnleEjvyhm9awZl5473ftOvff/r16PpQf9Zez9mOtkki/WU+Y2szwXFuEw3tLMAcqiQ2tyvUNcb 96jjMZzNz1vYMMfrwJtg5tPx9pbzwKsydNfdoVBpYLTzKMVuAHP84eMapACQT/uSiZ+wdUAbtrWI Nt5YYRmVkPx9g1SHTkwalvoZCfLNN36PT8gN+oH62epbe6qU8Ex0zJj+yMothuqFi7EnpYXp331z oO2SnFmXCy0C75+PeTywTtTw1rPPhgmx7kehqKbtPlf7ZrCvzpZdunGrUOObqJN4kuvzuGOHVa5X dUmFt/cesX32ZEhWU6Rb3iBbScmffKNbp8OSMjdbW0ydXPcxypjz+3LxWcXbiMtEEZPGoUmFWgWh yIoUjuTTkhKC3Oi5bKp3gB+b/+9pgHsQ313BJjMu6GXo8X1L3p743yItet/6m9VZ4H2DnwYmsH3S N5yxjFgJLqiH/5+NPb8Nty7oMhGcI38fYJTJC//PwM24vcF93bwF//Uw5P/ey/8+ABrIkpOsYx+b VOKCPrUe5oI2nSybFJ38cYBdh63birNU342OXUj4hDLzc4U9FTUyskmuvHvf9HCa5gNmstSBhuOm SvX1pknJr54WG+EkU+ZWxYeN9pJSk54mrDruIv9HO2ceD+X69/FbhOxkX1IHIfuuyJAiCVlC1tDE pMHYl0EpS9ZOC6Uy9i1L2cYSsoc0p2SNGI69GEuMTOa5O3WeJPXr9Pye1/P8Xq/5zOu672vuua73 fX2v5Xstf0wmIvF+VIbyoaJo6d5bbSdFTNPYRLvqlQWnO0PguR7eMYOpcw6Ll/6HbmQSE10jGz0x mhDbLGtAMObf/oxjolkO97uPUvvinn6t7gGzlSTt2wRJTjwUNxdThdyB3Tvs6EgwXrY9wFcrH+76 VIm+yuNG3x3bZHkMra+usWWq6ulKy95XGIS4RUZGTC5GVXcHe7/VVM5RSdr4cn5nX7tbq2JjsFOR GrDl4oZhUWPjnNAUKA+aV/7sUiS8lLrCK5C9oF9hdl1FWwaDUIDqx8KixseLYo43mxhXwQSnu7M4 cNPXn1tX7V1VLh6Vik7bjx8bfRh9nQiwttR5hK7ORxMErTsWCE+8fy9Fs32YuMrPhYRyYVqk+KLP oPCZarR3pTDRjtjfZl0TxjVLYvLLC+dUYwJ1Dz0oe3leXP6DBW1GVcli/wJsKSDAycW6oFF3vC7X 2vLU/VXp+/f0Z+unB2QSZ9vqHEzKXCNUIZRX2O5oB7mMlS8mqpctR52/CEDLOwvypebi14UHDMd9 39zQYV5TjmfdaREZZjXA0fWgJ3uMUzg8xB1Rqxgret+9teztmcLU0isO+BCaYr/Ygy0MafuKzKfa ZIyWkYW3TUtmJ7bPvp41cA24XoQXGkVd4ajlkHgkNhIXcWAi2lNPG4uJQarDFao5HsdTtp/Ege5G jXeqMrApo+fyIx6sc1oNprE/z0xx5dqgeseflS2sz5lqTZyIwIK8b0OZpfpBGRQ+XvqZt6S/w/7r mUrRfjDcRAO90cQRfF/akIVTf2yFLFIIn8DUWZIRWvDZTRy9l0wpL3JfOUJHVkU7gmKHyqkPTdjJ d1wKtszTPv1HxuPY0yRvSJyuRekkjhwpfiitJ0AvcOJl8pFF6VzBctmiC24c1LUHbz8P5dUS7mu+ uc895ZjMZT5lm6AXl9PT9HR0Xf1K2dH+pxbAlTK9g5j9AqH2VVejPYKpaUTYKN+85367Qe+oaB2G WaQcaRqinzHn1KeYWtkvkvrI+M22SJHkb0LtXjUOOqQs3qd5sIYCd91NrnhddE3qHsNQoiZ6nCds sKLtfEfhzEFfcO8m1/P4N/cgKiS/cM86W1bIIsZ2NcQsJ36c+fGBZyZjxv25MPdWrYFYvcG5QtnS Kp9iW7lGP3qreTs21SOqkK573gNY0cUAqFb3GAItVeTTk1uWozB/mxPD4z1WY7gC6UZOrZU+BUdL reRg7QKmnQgcoW72fYWWWIirWC+eMBgsOKMSBF31fgv6viDb91J9KBwGAgRPhiP5iUCD43DtupHZ XXMkL5483fm1dNk8R73r5TDmvH4+lq4aRryVNjyrJjz9eIcrgip8QifZ+c5tiQHKx1VF1RVCxxca 4G86MQLGqAR6wzZmoxPG7jc+TB7Jzm6aYR2493a2qfTF0B7bkFzsIL/zLewoTZe1FGyfC1Nm175S 4zv3zKekoK27TIZU01JNEauT0Y4xVe5DImuoGTXPD/3jYCXaJrgMrTqOEYHU5SGKMDWI0yXOlrqP /8xIFso1j65DoCpr5eCrYZQv7riVL6QuF+JNIUU9/POO60xL/ItHCarSDEO2dIiVMI21KlvlhSFX HSx857DBxbnxLiTbcCG5L8SkojhQbdQIV3tB/BEkWA0l342WNe/wy3Ay9WE51YpwhamWFR21k7No EmupeSnva7+479bdgxa05BGXcnad3Jv+AtY0XRFcuT4n5PKmMGwKuhrGwSM+Smaq7B/rchfKWSG8 Q6u1Ml94Tri0Eja70PUhNUjhdRBmiM51XaiPwI9PmX889R4T7umHpMeFLGL5EqLTdwl2S3iKWetz BSkQTPFKw5eyTk2bdUsP5SXJRxmZVOrkLc08GalwUnPuCh7OIgJFHGFIRB5BeT4hokYMr91kw1E1 Dw2PnvVi7GtYDu1R4/XdtfIYHV8ZHJX/CDo/UQehe3RyTQ3vt0TbYaCBfmlDBEbS3eogkUg+8jbh +fAw+66g1i6kxjCff7OelJUln6Nekq5OZmcpnHLmxMN4S7Eq5zVRaMmjzky03/m55LJHZT7R1aWD JT7Mt8bLhviphC9BHPdndhcI4eG47lMEnexz72sjshKw8dcWnfsLIwofqeQ69yeVCuA9a3KyZ/xR oUix7Bkl9NuDz9ICsTE0s+91CuTFuCTU7DN5pA1z3tj56bUh3jfvKqm+HkNF45lTKZt2zijv5rkX +bxHzGCdGQcQNwJRk2J88e19HiPZTc35CoYvGv8oPa5ychB2TIH3VWOOLi03w93J5yajZv31GTpa zhNzF1E449rewuVb+D0jc/1Kw4yNc5xIS7zKcPwf8FIUK154mOotV57Na2cboS6GqHRf7XobpnCs 9Dw6jhC8N3PZtKeWgUCFxbD4Thxd78P92V8bngcn6GGnvCCOeNc1CyQLvjofT66Jd83HxzW+IBzF BUeqIlLAiq7fPhpIidF/jhQY4SII39cceTmvdTFlWo2hu6cxnrs7IpHqirj8oD2fsUaXuNSbNwXd bTz93Ix1Ur2L9URghwLmghoXnhYn1YDapmro4JXpmzCcGYrTrreA1BswTVVeZrIYgr2fa4hi3AEa Y/qwujTydf9C54nnBbuTqNm5Rp3etjVjwmvJax1Ql5MEUM0QmiAyJDXeYWSm5IXRTBOEsYYKr1kX JFAep4lrw4tp6sZ4NCQxdyrsN9PCOTPugDlLdNIrNexZ4jGkvMkbH9Vlxigc0bTGzZlt56ozHJiv ZMwMNcrNN+Bo5zaZnVwTNc4/ElC6x/Ru9jG5GAvk1eY6wxRMdHtGhJfwuwSaNlYHnUpJ1AP9DJ1n qTb9csuxzC4m57RvanlOvJNgawWrCoGNe78D4lIZlHng7cwdSZlyR4gP410/dzgEq4xr+UCBQltD jPm833UkcA7IoarCn6lWKLZ0zRABTOQQXjIoeHAh2EPp/SzjegiuFm+oSwSuL9r6dRtaoQjCuziJ QPL15ZmsaYeC1xVFozxhHituqy0JezvXd8bRBf+hs+bV+U6mx9WqDxHTsH+tHDnafh32zh9cfI2g 12lRqBUkaqBhphzynhZsFuwRqXWDjsCJceF6bFyYLQP+FfpxEosLpXdwEwS6mPJq8ag3ocHtFXq/ 3u3S2Sc/cskv+XF5tdBUDyJAcwnLrs9gUA9hdLxX7YGNVcMNJt0K7F34sz+4/uGH+HIiEAXBhScT gURtLPaC93u8Q9wjWcbB/tWW+LWge447daSy7T114EKllSJTuNqqF0O3a5guwYmAC7S/bMXauodQ bd3dvYCual9Y/eUJ5KUNJ54Px2OGauzRHG6pr8rfrzBp91yvpwFCKygNm8EWMuioHkAq+dOdpTV4 6+elcyaS1Tw2RWIp3W/BwNqMIId5zP9+zxAVEcD14aWIwI2bcpgUfauiBpPKE/ADV+QH7ITZ8z1H ZhO9fSwl0jJ2URXaoErCHDRvPsuz7+IqFdLPm8ppyulrPkeDcNZmTwymr4HhBWXm1w5zNqsxEgyH 6UQwMTW00R+6Vu+4PpVWvPEqtOUmx+uuOrwt1rGBn3yoIxcvhsVcIPDnWp1qzbI6Z8OBCw8nfPT/ 4t0rsr0dfulT3Qksfa0ImLNqPEbg0KKlZdsTG86+gDacDD57VIalkFNZVIt5DK541wHeVRgQrKs5 u6Ba5qdva7D9wMN8EZP7EBh1eWauXqukmXdiNdpZT7zkCKuhlWPBt3+H8M9DMLEPIIkkkkgiiSSS SCKJJJJIIokkkkgiiSSSSCKJJJJIIokkkkj6T9QJXXIKVoASoAbjewDzO1frc8EYPxkAMIN3NzdP KTd3qMcJd1c3D0lf+PnoOBWGemk6dR/BWSZoligd9ckP4hG3yRiYMlx4RBG/qRBcDBq1Q/LToNUT E5VVAcIF6ufJFd2tbxgBiX9Y8vL4qfGZqogqw96U0lLHIIH2AmvJafMj2yiPH4AuHf0t6qrY4BPR DHPRprPbCiuomaXnwtRtslRfZPu/QCMfq5SKtucv9KcScPLhjA2n6d9cqsDz4uKZys12GCgu9LBP 9AYR8bpGb3cCAJFIvsmw3g8xcXlgrAwMOz8b5mlnfx5q7Ol3HvqXaXRPdRhCpDnVsdVXfJzWAyU0 DQVZ63eL+UyT7buxZ0rdKY1ldBC6unBNqgNyLDXB/M0ZeXLiMBlLpcJgOhVlXMAlB/VuxCACVnL6 AQ2tX9lQhirCwM/jPqvZzB+ZTnfcKNM8PA5FwLVTyg/eOjX59t1ZwwF4BV26JT6g86bgxQm+KyPX KV9eSapTyg3ZnVryOKt9LAJ2lNzKX74ZYdLdVZHzYZ94kHoRBNjKOCsxyKF2MKa3odW8YVCfL612 tf1cgzrdkZXQ9YbkQDl9ch2ZXY7GlQwlHwCZ+LdkGHJYYsuQdgl9SZW4VEKAshEa0tLEe0Xozz9P V597fGLBjxrmjludX17aprUvkyzh7pO6UIrlD6OaZv0OyZ0XY7ZdK5k8XVBa0h2JEk3Nc09JH7y1 377ryXU+TgOa2KhAl8T8GE4WwuxqUuCuluEphbXCoznr6rfY8/ZJeYi4p90McArVYV2sXs96OYPY GY6tTjazHsUweN8ZPHu/+zRhzKAo0NEVNVm4peXzBi6nHEGrq7Z9tJya7Iyrw19GSzm4ukM/Wr47 lYJMJBkg+z8ZW/+PdNdIw7lhN2c14zJ/SNbbq7dKpLuvpj+ISbIQEXdwUMqytbzNbfhKnhiUWHZK 14fb9/lKzUSAQdSUTaQTVfOC1k0RXSPWi6n0o+esU9H+7JDUJwdSOZljQli8Tj8vqawWzX4GczgN 46ZvRjz43cxIMavyMM+EZ+zDDJ6rjXuTUlTLz0ULPnPt4HY+VNvKjRPR439Aoc2JoKCqM2eMnBRp ndydg9Za2hZtz7RbY39UsWBDrRWVVj+Eyv/PaNGKmRKMZ0lAQcckGW9vQDuV/asyHZVZuC+Ra938 qe1atoxZihhN9j7ODj6fbblCMq+h8hNiyXxsTIOnJEuHxRje1Dwmlzp+grxRoRljfuywiWuZbc1A kmfIofkQczTOlVUwqVJsWUGAjqt3Htd20nR4Mb8WLTXutv/BE+0Oxqa7V1fmF3UPat40ULlSLK4v 7KXY1uBPoBuXHNdcarioakFAj+gkT/PZBqGnqbbqnQH2vztygj3TgwIAmDb2Tjs3N1Ln/KJ0Ez3X V9J01Yy9wUzIaYYr18Unw9QNZQRF3J26AURV8d7nD6VPyR5WgC/PaFt6qZXZh3cIB6lCfo+7ge/Q hfft2sY9N97nq9zGqTxWiqjyWz4xwKDmSJfmaWExdzqJDyjmmV/nG6IYUo+gvMoc2uBn2tT7dIH3 5PbSxj0ZfNBj/Oe4WumrBhIyDB8sTedQciy2Onnea9ClyNJgTBSwi+d0XMMXpvffL1NDijPQs4n7 YtNKQnM0on2D3PFK/PKRrcJJwlHBMG7nG9GC4eY8bKrvZYvWCtzK5jFMiq/Lnyx67L5CdpTPq3bQ mz4qQEmdDeB9Zbp+21rPkR+CI9DvHnqy20dDkS1yXkFDX3LIIu1ivWpwKd6MX1RdT/BSYXT3sE0x aw1u1b/6QeYUrroVfczC/OqB1BvsF7PjyGq29ekHCeip160gyqjYAk87Bb14k8W1JslsoTfRZ0Mp YC0ItzR3P/BKkfOSiNOOiDvurXNPPXor4JnwqMtCo4WPG7u82ml2SgwT+Z8n3elPL5baflR7IEH+ Gj5s13WPg5UvrnHntAndWGjVKqOQV/GxmTBkHcnIt/PJpPA6wd7Llpi4XCifDDsVW56uo0STO4/O Za9xSVeJCNUY83tdRXhWzo//gzVIVGCpuIZuAX6EzanyauA667AYt8cDidbUay5UlS2E206uHQ7+ mo2+srzPe6yvqnXPBhItImyBv0cT2TYJ4Mt4UlyZchsER4sW3adJ/GtZarq6eEJdPG1N/NygHtYf B9hmgBPeM2U7CBgBByXtV5nZwSFq6w497yEl+fG6OaPuu4NvasGYEph591cZj1N9mm89zsPOQD2k PjH++iLzsQRb0ngkFah2gqQ/yMGV1lc0HepPtE+Yjysv0CA7T5iry3dhT9d6z0eD9hymB8CnG5VC 82UBtxGzmUD+5P3lEDC6qgQAbF8RbOm/Mu6LWZsRXc+vzdd8rh/xrxCs7BsQx+38XL08v6qlT4+U vmve98m8HD9DVv4pssRXZEHOnyHLSP8CWoLrp9Df7zvfrw9F7p9B7/8FshrPTxX6F8havD9Dlv0F sj7fz5DlfoFsuutnyPK/QLbh/xmywnfJsFTbPbtAagvVZvLZ3RvIenYenlD3r8ifHn2/BWPhRcTf QW+1CHrN374iP9uzRZm/6cqbebs6URrHQN7Ob3gooX/Bk96KJ0CZz8IGuvCj9B+/bZSo6I95clvh 9EM6CeJg8QZoNuMCJX6Mk90KVxW6XfMpiFui24yblP4X1m6F652O6FwEm5hKcTNuUX6LZt7cwJtx ppMdF0bA0hUwb8YJHfxx6eS3wpnkK1od2A7WFM9mnJbGj3EKW+FwLcuXq8HpjUi1GVer9WOc4la4 816N731BXD7lZlyVzo9xSlvhTsb+NloO9jtqls049+M/xilvhWM/VrI3CMT5fNMUMMMf4/b/s1l5 r+nPeBrF7/qDwsfJmi1gNE9p86JD0uzz4YoTFA79dN3Q62g+p9oDHDo5WghcAKNg4PiKIHwaAP57 p+Tp5AW3d7GDnZc85wZ13FyMzcdVX2Q1vMXh1TcDadOh0BcpYLc8ItoM2Hzw8kUsI1scw2zO/vXp xUbRjW6og7/PMjZn/3p7uVG5Yxuyf95sntDdTvnxNyHwowe6XfzkX0k5/7pegHzJfAGyUp17WFxy 7vA+dXAt9G9O82Bb3v6/U2yM/2+863tpKMA0dJ+ffhxm1BvuvJ/vumAAkwHSYAC92V+rfrLPgWlD VZeDVdlG/e13AeDvncLWZfhYRsFNv5MDBoA9cA7QAVyAs4Ar8K+e/6xYgG3gfuqLfiYPOCEAlP/4 Td/XP33/v1v/ye//LxPNATUbQWg05YJEsrjTbOPUbsTCeVzYWw1vZNcRwJGrxLOAl4s1tO1nFBb3 R9hwy2Cf+zUbOSpyUMI5u7qRhaShTb5faaXaUU1e6Ubx+RhiOIazhbH4ttR9vTdTMo01y+wdRzhK riIJy9hJtqL5+Wbg0nPlXHHxl8ZRnPxy8djGSf8AimPgucL8+MZ+Ei7m+X5kO0ja24r+88j0f4Je OfiRe/Fy28K+KPiDrnjHRNR+HPjXxAbTW9F8CWBstV8P+KPhzpun3FpdeEvBvha6O+z8TarFc295 LdQM3kuscU0RC+e63Y2On3nkafe/b7YQrKt0FtlO4mZXZYraa6WKXMWWgklEkQHBMSRTx2PhD8bA BQ== ------_=_NextPart_001_01CA6135.F642F210-- From wintert@acm.org Mon Nov 9 04:24:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800E43A6B34 for ; Mon, 9 Nov 2009 04:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.516 X-Spam-Level: X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=1.084, 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 Y1Ie7TjvGzsr for ; Mon, 9 Nov 2009 04:24:41 -0800 (PST) Received: from smtp107.prem.mail.sp1.yahoo.com (smtp107.prem.mail.sp1.yahoo.com [98.136.44.62]) by core3.amsl.com (Postfix) with SMTP id C7E6A28C114 for ; Mon, 9 Nov 2009 04:24:41 -0800 (PST) Received: (qmail 22487 invoked from network); 9 Nov 2009 12:25:06 -0000 Received: from (wintert@12.70.80.151 with plain) by smtp107.prem.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 04:25:06 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: jPRv0DoVM1mqxLDwjqo7qfXt._o_sL9TF1KqkbjSWgth0fJ9vtE5KoiLNhHUV.d_JV7w9tEXFaQfdoyldRf8t358CIBLBj0kqc3ycvo0NtxmMIL5l.uTvXRrwfrK_X0Kywwf2Xvf_OC0zlYTJvKJz80c3PH9XbfYbm2Z1oJuQ.YxDht60nRbd5ulvq58yINRtVTCQTNrglU.2UiAsV5MGcQwF3u7j0mKSeRMA5vNmYEzBMRVRY8PZrPWOc5qhmJUnMwwDGATH0VcvGn.zeqTKU4LHLRYMvOYmVTKn1aKZ5sBjV_hJTwrhb444SVzeJRy0OeHfTOO2a8csKbHGtDK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF80A1C.50100@acm.org> Date: Mon, 09 Nov 2009 07:25:00 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <4AEE180B.8040805@acm.org> <22763.1257446216@marajade.sandelman.ca> In-Reply-To: <22763.1257446216@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] [roll] #8: DIO Option Length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:24:42 -0000 Hi Michael, WG, Michael Richardson wrote: >>>>>> "Tim" == Tim Winter writes: > Tim> Yes, the draft-ietf-roll-routing-metrics-03 suggests that the > Tim> metrics may exceed 255 bytes, and so the DIO suboption for DAG > Tim> Metric Container drives the overall requirements for suboption > Tim> length. > > Tim> If we use 16bits for length, maybe 1 byte is `wasted' to > Tim> specify a short ( < 255 bytes) option. > > Tim> If we use 8bits for length in units of 8bytes, only one byte is > Tim> used for suboption length in all cases, so the second byte is > Tim> saved. But the suboption itself must pad for [0-7] bytes to > Tim> meet the 8 byte boundary. In the first case, 0 byte of padding > Tim> is required, one byte is saved from encoding the suboption > Tim> length, and one byte is saved overall. In the second case, 1 > Tim> byte of padding is used and one byte is saved from the > Tim> suboption length, breaking even. In the 6 other cases, more > Tim> bytes are used for padding than are saved in encoding the > Tim> suboption length. > > Tim> We don't know anything yet about a typical distribution of > Tim> lengths for suboptions, in particular the DAG Metric Container. > Tim> So perhaps this discussion could be premature. But, given that > Tim> in the 8byte encoding case we use more bytes in 6/8 of the > Tim> possible cases, my opinion is that it is better to stick with a > Tim> 16-bit suboption length in units of bytes. > > I say either 8bits in units of 8bytes, or 16 bits in byte units. > > I somewhat favour the second one (16-bits). > If the second, then one of the options that we should consider is the > "compress" option, which would contain many options. > Otherwise, we may want to consider use of the IPCOMP header in > constrained situations. > > This may well simply solve the problem. I propose that this is > premature optimization. > For now then we should leave the text unchanged for -05. Perhaps we may revisit this later when we have more basis to optimize. Thanks, -Tim From jabeille@cisco.com Mon Nov 9 04:25:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B69A3A68B7 for ; Mon, 9 Nov 2009 04:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.943 X-Spam-Level: X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=0.656, 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 G0wt0zoYEPIo for ; Mon, 9 Nov 2009 04:25:49 -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 D11783A684E for ; Mon, 9 Nov 2009 04:25:48 -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: Ak0AAK+Y90qQ/uCWe2dsb2JhbACbegEBFiQGqQiWVYQ+BA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53952683" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:26:13 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CQDBi008138; Mon, 9 Nov 2009 12:26:13 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:26:13 +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, 9 Nov 2009 13:26:11 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FE03@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #5: DODAG Thread-Index: Acpf29+gSuPDmQxxQziDIkvqKDUczgBSOTZAAAIwJUAAAjwSEA== References: <4AF5C26A.30408@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D95FE03@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 09 Nov 2009 12:26:13.0932 (UTC) FILETIME=[D3E116C0:01CA6137] Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:25:50 -0000 Hi Pascal, all, > -----Original Message----- > From: Pascal Thubert (pthubert)=20 > Sent: lundi 9 novembre 2009 12:18 > To: Julien Abeille (jabeille); Tim Winter; ROLL WG > Subject: RE: [Roll] [roll] #5: DODAG >=20 > Hi Julien: >=20 > In classical terms, an instance really defines a DAG.=20 If you have several roots with several DAG IDs, the DAGs are totally disconnected. This is not one DAG, but several. The differences we are talking about is "one vs several", not one kind versus another DAG.=20 > So if=20 > you have multiple roots then RPL partitions that DAG into a=20 > set of Destination-Oriented DAGs, also called DAG Rooted at a=20 > Destination in the art. All those terms exist with a specific=20 > load and the wisdom we hear from Phil and Dave is not to=20 > overload / redefine / restrict those terms.=20 All DAGs in RPL are destination oriented. I don't see the point of adding as many adjectives as possible to the DAG term, especially since we've been talking about DAGs since two years. >=20 > The most useful object is the DODAG iteration. A node moves=20 > within one and jump between 2. This is the object for which=20 > we should find cool name. DODAGI is certainly pronounceable=20 > by many of us, but it looks a lot like a WG name in mobility.=20 > Any idea? DAG ;-) Best, Julien >=20 > Cheers, >=20 > Pascal >=20 > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf Of=20 > >Julien Abeille (jabeille) > >Sent: lundi 9 novembre 2009 11:12 > >To: Tim Winter; ROLL WG > >Subject: Re: [Roll] [roll] #5: DODAG > > > >Hi Tim, > > > >My question is: are there DAGs that are not DODAGs in RPL?=20 > My feeling=20 > >is no. Hence I would suppress the DODAG instead of turning all "DAG"=20 > >into "DODAG". > >Best, > >Julien > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf=20 > >> Of Tim Winter > >> Sent: samedi 7 novembre 2009 19:55 > >> To: ROLL WG > >> Subject: [Roll] [roll] #5: DODAG > >> > >> Hi Julien, WG, > >> > >> > >> roll issue tracker wrote: > >> > #5: DODAG > >> > > >>=20 > --------------------------------+------------------------------------ > >> --------------------------------+- > >> > --------------------------------+------ > >> > Reporter: jpv@... | Owner: wintert@... > >> > Type: defect | Status: new > >> > Priority: major | Milestone: > >> > Component: rpl | Version: > >> > Severity: Active WG Document | Keywords: > >> > > >>=20 > --------------------------------+------------------------------------ > >> --------------------------------+- > >> > --------------------------------+------ > >> > * This is currently being discussed by the RPL Author team * > >> > > >> > Email from Julien > >> > > >> > Is there a distinction between DAG and destination > >> oriented DAG. From > >> > what I read I feel all DAGs are destination oriented.=20 > If this is=20 > >> > correct I propose to remove the destination oriented=20 > DAG concept. > >> > > >> > >> > >> The intent for -05 will be to make the unqualifed use of=20 > `DAG' in the=20 > >> text consistent with `DODAG Iteration', as outlined below. So in=20 > >> this use, a `DAG' is a `DODAG' > >> snapshotted by a single sequence number -- a `DODAG Iteration'. =20 > >> There may be cases in -04 where the text reads `DAG' and=20 > is in fact=20 > >> referring to `DODAG'- we will be sure to clean these up. =20 > Here below=20 > >> is some additional explanation prepared by the author team- > >> > >> Does this help to clarify? > >> > >> Regards, > >> > >> -Tim > >> > >> > >> > >> Instance > >> > >> > >> > >> +----------------------------------------------------------------+ > >> | > >> | > >> | (R1) (R2) > >> (Rn) | > >> | / \ /| \ / | > >> \ | > >> | / \ / | \ / | > >> \ | > >> | (A) (B) (M) | (N) ... (X) (Y) > >> (Z) | > >> | /|\ |\ / | |\ | | > >> | | > >> | : : : : : : (O) : : : : > >> : | > >> | / \ > >> | > >> | : : > >> | > >> | > >> | > >> | Instance ID > >> | > >> | > >> | > >> > >> +----------------------------------------------------------------+ > >> > >> Instance > >> > >> > >> An Instance is a routing topology over an LLN, optimized for a > >> particular objective/application. Discrete Instances=20 > may also be=20 > >> set > >> up to offer optimized connectivity to different=20 > destinations when > >> appropriate, for example to differentiate a Home=20 > Network LLN from a > >> Utility Network LLN in a smart metering application=20 > where a meter=20 > >> may > >> be configured to join both Instances. > >> > >> It consists of one or more Destination Oriented DAGs (DODAGs). > >> > >> It is uniquely identified by an InstanceID. > >> > >> Each instance is operated independently of other=20 > instances, and RPL > >> defines operation over only one instance. Operation=20 > among multiple > >> instances is to be expanded upon in a future revision=20 > or companion > >> specification. > >> > >> > >> > >> Destination Oriented DAG (DODAG) > >> > >> > >> +----------------+ > >> | | > >> | (R1) | (R2) (Rn) > >> | / \ | /| \ / | \ > >> | / \ | / | \ / | \ > >> | (A) (B) | (M) | (N) ... (X) (Y) (Z) > >> | /|\ |\ | / | |\ | | | > >> | : : : : : | : (O) : : : : : > >> | | / \ > >> | DAGID | : : > >> | | > >> +----------------+ > >> > >> DODAG > >> > >> > >> A Destination Oriented DAG is a DAG rooted at a single=20 > root node, > >> which is a node with no outgoing edges. > >> > >> In the case where multiple nodes in the LLN coordinate over a > >> backbone and expose the same DAGID (to support the same=20 > DODAG), it=20 > >> is > >> conceptually as if there is a single virtual root over=20 > the backbone > >> (not illustrated). In some=20 > applications/implementations this may=20 > >> be > >> a desired architecture; in other applications each DODAG may=20 > >> operate > >> with indpendent uncoordinated roots exposing different DAGIDs. > >> > >> A DODAG is uniquely identified over the LLN by the tuple=20 > >> (InstanceID, > >> DAGID). > >> > >> In RPL a node may belong to only one DODAG per Instance=20 > at a time. > >> > >> > >> > >> DODAG Iteration > >> > >> > >> +----------------+ +-----------------+ > >> | | | | > >> | (R1) | | (R1) | > >> | / \ | \ | / | \ | > >> | / \ | ------\ | / | \ | > >> | (A) (B) | \ | (A) (C) (B) | > >> | /|\ |\ | / | /|\ |\ | > >> | : : : : : | ------/ | : : : : : | > >> | | / | | > >> | Sequence N | | Sequence N+1 | > >> | | | | > >> +----------------+ +-----------------+ > >> > >> DODAG Iteration > >> > >> > >> A DODAG Iteration is the DODAG that results from the iterative > >> process that reshapes the DODAG as stimulated by the=20 > root. It is a > >> DAG as constrained by operation of RPL over a fixed Sequence=20 > >> Number. > >> > >> As the root node increments the Sequence Number,=20 > different types of > >> node movement are allowed (e.g. moving `down') and a new DODAG > >> Iteration is formed. > >> > >> A DODAG Iteration is uniquely identified over the LLN=20 > by the tuple > >> (InstanceID, DAGID, SequenceNumber). > >> > >> > >> > >> Scope > >> > >> o The scope of an InstanceID is the whole network and=20 > it defines=20 > >> an > >> instance > >> > >> o The scope of a DAGID is an instance and it defines a DODAG=20 > >> within > >> that instance > >> > >> o The scope of a Sequence Number is a DODAG and it defines an > >> iteration of that DODAG (DODAG Iteration) > >> > >> o The scope of a rank is a DODAG Iteration and it defines a=20 > >> position > >> of a node within that iteration. > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll >=20 From jabeille@cisco.com Mon Nov 9 04:33:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E633A68B7 for ; Mon, 9 Nov 2009 04:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.639, 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 WKvfq7x9hCXd for ; Mon, 9 Nov 2009 04:33:38 -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 13DAF3A684E for ; Mon, 9 Nov 2009 04:33:37 -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: Ak0AAAeb90qQ/uCWe2dsb2JhbACbegEBFiQGqRGWUYIzggsEgWg X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53953900" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:34:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CY38r011432 for ; Mon, 9 Nov 2009 12:34:03 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:34:02 +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, 9 Nov 2009 13:34:00 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphLhFk8yC/YGPRRcufCNg1SDjVOgAAEkAQAAJsJCA= References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Nov 2009 12:34:02.0967 (UTC) FILETIME=[EB722670:01CA6138] Cc: roll WG Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:33:39 -0000 Hi Pascal, JP,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: lundi 9 novembre 2009 12:25 > To: JP Vasseur (jvasseur) > Cc: roll WG > Subject: Re: [Roll] Ticket #10: Closed >=20 >=20 > >Here is another way to look at it. You simply configure an=20 > OCP and all=20 > >nodes willing to participate to a DAG have to implement that=20 > same OCP. > > > Simply configure...=20 >=20 > In industrial, tools for doing that will certainly exist.=20 > What about game boys and McDo toys? Can't they do RPL? >=20 >=20 > >If you mandate the use of an OCP like the OCP0, that also means that=20 > >ALL nodes MUST implement OCP0, even if they do not want to implement=20 > >that OCP. >=20 > Yes, that was the goal. Making it fairly simple but=20 > implemented in every node so if I buy something from brand A=20 > and something from brand B, I'm sure there's at least one OCP=20 > that both implement. >=20 The root has to be configured. If it sends OCPx in the DIO, the game boy will join as a leaf anyway Again, I do not think this is worth extra code on a node. > Doesn't that scare you that we allow for 2 RPL-compliant=20 > nodes to be by design unable to talk together whatever the=20 > way we configure them?=20 >=20 > > > >In other words, this is a trivial implementation issue easy to fix: > >specify the OCP to use > >on the node. >=20 > The OCP must be implemented in the node first. There's code=20 > associated to it. >=20 > It makes sense that an implementation should have a mechanism=20 > to add more OCPs over time, and that's what I indicated by=20 > calling OCPs plug-ins. >=20 > Pascal >=20 >=20 > > > >> Is that really what this group wants? > >> > >> Pascal > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org=20 > [mailto:roll-bounces@ietf.org] On Behalf=20 > >>> Of > >> JP Vasseur (jvasseur) > >>> Sent: lundi 9 novembre 2009 11:59 > >>> To: roll WG > >>> Subject: Re: [Roll] Ticket #10: Closed > >>> > >>> So here is the plan for rev-5. > >>> > >>> First OCP0 will be removed from the core specification. There will > no > >>> longer be any requirement > >>> for a node to support OCP0. Various OCPs will be defined=20 > in separate=20 > >>> drafts and each node will be provisioned to support one=20 > or more OCPs > >>> > >>> If a node receives a DIO referring to an OCP that it does not=20 > >>> support/ understand, it may join the DAG as a leaf and log the=20 > >>> issue. > >>> > >>> In the absence of comments, we will update rev-05 accordingly. > >>> > >>> Thanks. > >>> > >>> JP. > >>> > >>> On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: > >>> > >>>> Strong consensus towards Option 1. > >>>> > >>>> This closes the ticket #10 and will be reflected in rev-05. > >>>> > >>>> Thanks. > >>>> > >>>> JP. > >>>> > >>>> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: > >>>> > >>>>> Dear all, > >>>>> > >>>>> /co-chair hat off/ > >>>>> > >>>>> We would welcome your opinion on the following issue: > >>>>> > >>>>> Suppose that a DAG is formed that support OFx. A new=20 > node willing=20 > >>>>> to join the DAG does not support OFx but OFy. Note that=20 > by OF we=20 > >>>>> actually mean the Objective function and the metric. > >>>>> > >>>>> We have two options here. > >>>>> > >>>>> Option 1: The node simply joins the DAG as a leaf. In=20 > order words,=20 > >>>>> the node has connectivity since it joins the DAG but=20 > will not act=20 > >>>>> as a router for others since it does not understand the=20 > OF. Parent=20 > >>>>> selection could be a simply a "random". > >>>>> > >>>>> Option 2: The node joins the DAG and falls back to the "default" > >>>>> OCP. From there is prolongs the DAG but with OF0 (of course=20 > >>>>> inconsistent metrics are not added). This also means that > everynode > >>>>> MUST implement OF0 and that the network may compromise=20 > nodes with=20 > >>>>> different OF at some point. Several options even more=20 > complex have=20 > >>>>> been discussed where one could use common denominator to get as=20 > >>>>> close as possible to the desired OF, allow a node not to be so=20 > >>>>> "altruistic", ... > >>>>> > >>>>> My personal view is that OF management can quick get fairly > complex > >>>>> and hard to manage. Option 1 is extremely simple and easy to=20 > >>>>> manage. If a node is mis-configured (does not support the OF of > the > >>>>> DAG) it can join it as a leaf in order to have connectivity and=20 > >>>>> send an alarm to fix its configuration. We now just need to > specify > >>>>> OF in some document and this is it. > >>>>> > >>>>> Several of you mentioned that they were leaning toward=20 > option 1,=20 > >>>>> but could you please express your opinion, we would like to have > it > >>>>> solved for the next revision next week. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> JP. > >>>>> > >>>>> _______________________________________________ > >>>>> Roll mailing list > >>>>> Roll@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/roll > >>>> > >>>> _______________________________________________ > >>>> Roll mailing list > >>>> Roll@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/roll > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Mon Nov 9 04:34:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31523A68B7 for ; Mon, 9 Nov 2009 04:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.717 X-Spam-Level: X-Spam-Status: No, score=-9.717 tagged_above=-999 required=5 tests=[AWL=0.882, 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 BhBhTceA1Sg2 for ; Mon, 9 Nov 2009 04:34:16 -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 9A17C3A684E for ; Mon, 9 Nov 2009 04:34:15 -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: Ak0AAAeb90qQ/uCWe2dsb2JhbACbegEBFiQGqRGWUYQ+BIwL X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53953958" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:34:40 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CYeBU011602; Mon, 9 Nov 2009 12:34:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:34:40 +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, 9 Nov 2009 13:34:35 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FE9F@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] terminology Thread-Index: AcpcwCR3wfHz9yZKSkeoj0Sw3LhHAwArIMpgAPLgI/A= References: <0DC26C55-B0F1-454D-9587-B9D1D0686E9D@cs.stanford.edu><2329EFAA-6392-40BD-B79F-F40F5C3510F7@archrock.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" , "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 12:34:40.0810 (UTC) FILETIME=[020088A0:01CA6139] Cc: roll ROLL Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:34:17 -0000 Agreed.=20 Rank is scoped within a sequence. A node cannot use a passed parent (a parent that exposed a passed sequence).=20 A node may use a future parent (a parent with a future sequence) but it has to appear as a leaf to that parent in that DODAG instance by setting the rank to infinite. This is done to avoid a false positive detection if the rank relationship changes with the sequence. Cheers, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) >Sent: mercredi 4 novembre 2009 17:36 >To: Jonathan Hui; Philip Levis >Cc: roll ROLL >Subject: Re: [Roll] terminology > >Hi all, > >I am inline with Philip. Thanks for the precisions by the way. >Regarding sequence numbers, for me 2 nodes with 2 different seq numbers >are in different DAGs, hence we do not need to compare them as far as >height is concerned. > >Best, >Julien > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 3 novembre 2009 20:58 >> To: Philip Levis >> Cc: Julien Abeille (jabeille); roll ROLL >> Subject: Re: [Roll] terminology >> >> >> On Nov 3, 2009, at 11:20 AM, Philip Levis wrote: >> >> > This seems like an excellent simplification to me. >> > >> > The one weird thing that occurs is that people often talk >> about going >> > "up" the tree as towards the root, which is the opposite of a real >> > world tree. E.g., depth first search. So I'd suggest we say >> > >> > Up: towards the root, decreasing rank >> > Down: towards the leaves, increasing rank Higher node: lower rank >> > Lower node: higher rank >> > >> > I think it's important to define higher and lower in terms of Rank >> > since Rank is what's actually used. Otherwise you get into a weird >> > situation comparing disjoint subtrees. >> >> >> If we want to be precise about the terms, then "sequence >> number" needs to appear somewhere. For example, A may be >> "higher" than B because it has a newer sequence number - >> which trumps any difference in rank. >> >> -- >> Jonathan Hui >> >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Mon Nov 9 04:38:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB8D3A6805 for ; Mon, 9 Nov 2009 04:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.976 X-Spam-Level: X-Spam-Status: No, score=-7.976 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, 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 OsVIJCroikAY for ; Mon, 9 Nov 2009 04:38:22 -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 846173A672F for ; Mon, 9 Nov 2009 04:38:22 -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: AuYEAPab90qrR7H+/2dsb2JhbACCJivCdZZRhD4E X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="48589664" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2009 12:38:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CclKO010007 for ; Mon, 9 Nov 2009 12:38:48 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:38:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6139.902330D2" Date: Mon, 9 Nov 2009 13:38:37 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FE60@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAG sequence in DAO Thread-Index: Acpe7oT0pR4k8th8QauYsvau9q9DjQCRAKlwAAG01cA= References: <6A2A459175DABE4BB11DE2026AA50A5D95FE60@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "roll WG" X-OriginalArrivalTime: 09 Nov 2009 12:38:39.0375 (UTC) FILETIME=[9032A9F0:01CA6139] Subject: Re: [Roll] DAG sequence in DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:38:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6139.902330D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok. works for me for unicast DAO. for multicast DAO it does not work. it will end up with paths going though multiple dag IDs Julien ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 9 novembre 2009 13:09 To: Julien Abeille (jabeille); roll WG Subject: RE: [Roll] DAG sequence in DAO =09 =09 Hi Julien; =20 The sequence in the DAO is not the DAG sequence but the DAO sequence. At the moment we do not check that the child is on the same DODAGI as the parent though we certainly assume that it is... =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 6 novembre 2009 15:36 To: roll WG Subject: [Roll] DAG sequence in DAO =20 Hi all, =20 for now the DAO does not contain the DAG sequence. Because a DAG with a different dag sequence is a different DAG, does it make sense for a parent to process a DAO from a child which is in another DAG? =20 Best, Julien ------_=_NextPart_001_01CA6139.902330D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ok. works for me for unicast DAO. for multicast = DAO it does=20 not work. it will end up with paths going though multiple dag=20 IDs
Julien

From: Pascal Thubert (pthubert)=20
Sent: lundi 9 novembre 2009 13:09
To: Julien = Abeille=20 (jabeille); roll WG
Subject: RE: [Roll] DAG sequence in=20 DAO

Hi=20 Julien;

 

The=20 sequence in the DAO is not the DAG sequence but the DAO sequence. At = the=20 moment we do not check that the child is on the same DODAGI as the = parent=20 though we certainly assume that it is…

 

Pascal

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Julien Abeille (jabeille)
Sent: vendredi 6 novembre 2009 = 15:36
To: roll WG
Subject: [Roll] DAG sequence in=20 DAO

 

Hi=20 all,

 

for now = the DAO=20 does not contain the DAG sequence. Because a DAG with a different dag = sequence=20 is a different DAG, does it make sense for a parent to process a DAO = from a=20 child which is in another DAG?

 

Best,

Julien

------_=_NextPart_001_01CA6139.902330D2-- From pthubert@cisco.com Mon Nov 9 04:38:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCD03A672F for ; Mon, 9 Nov 2009 04:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.733 X-Spam-Level: X-Spam-Status: No, score=-9.733 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGIm62i3vHvq for ; Mon, 9 Nov 2009 04:38:40 -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 74DF33A6B3D for ; Mon, 9 Nov 2009 04:38:39 -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: AlMAADOc90qQ/uCWe2dsb2JhbACCJiuZKQEBFiQGqQaWUQKEPAQ X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="53954326" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:39:04 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9Cd4IP012659 for ; Mon, 9 Nov 2009 12:39:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:39:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6139.9EA1965C" Date: Mon, 9 Nov 2009 13:39:00 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcpceQdszzwwqAwyQCeb8RdlCV5REwEwBGBw References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 09 Nov 2009 12:39:04.0069 (UTC) FILETIME=[9EEAAB50:01CA6139] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:38:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6139.9EA1965C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde, =20 If that parent is preferred, it is probably because that's where most of = the traffic should land. This is why rank and metrics are expected to be propagated from that of = that preferred parent. =20 Allowing other parents to impact the rank is opening the door to = greediness. So we picked the simple path of accepting parents that are = upwards once the rank is selected from the honest-to-God preferred = parent. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur (jvasseur) Sent: mardi 3 novembre 2009 12:30 To: Mathilde Durvy (mdurvy) Cc: roll Subject: Re: [Roll] Clarification on the objective function =20 Hi, =20 On Nov 3, 2009, at 11:28 AM, Mathilde Durvy (mdurvy) wrote: Hi All, =20 Section 5.9.1 says "When the scan is complete, the preferred parent is elected and self's rank is computed as the preferred parent rank plus the step in rank with that parent." Does this mean that the rank of a node is only based on the rank of its = most preferred parent? Shouldn't the rank of the node also depend on the non-preferred parents? Or is it assumed that the node always forward traffic via its most = preferred parent?=20 =20 A node may indeed choose to send traffic to an alternate parent and not = the most preferred. But do you think that this should change the way its computes its rank ? =20 JP. =20 Best, Mathilde =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you = print. Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA6139.9EA1965C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mathilde,

 

If that parent is preferred, it is probably because = that’s where most of the traffic should land.

This is why rank and metrics are expected to be = propagated from that of that preferred parent.

 

Allowing other parents to impact the rank is opening the = door to greediness. So we picked the simple path of accepting parents that are = upwards once the rank is selected from the honest-to-God preferred = parent.

 

Pascal

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur = (jvasseur)
Sent: mardi 3 novembre 2009 12:30
To: Mathilde Durvy (mdurvy)
Cc: roll
Subject: Re: [Roll] Clarification on the objective = function

 

Hi,

 

On Nov 3, 2009, at 11:28 AM, Mathilde Durvy = (mdurvy) wrote:



Hi All,

 

Section 5.9.1 says

     "When the scan is complete, the preferred parent is elected and
=A0=A0=A0=A0=A0 self's rank is computed as the preferred parent rank = plus the step
=A0=A0=A0=A0=A0 in rank with that parent."
Does this mean that the rank of a node is only based on the rank of its = most preferred parent?

Shouldn't the rank of the node also depend on the non-preferred = parents?

Or is it assumed that the node always forward traffic via its most = preferred parent? 

 

A node may indeed choose to send traffic to an = alternate parent and not the most preferred.

But do you think that this should change the way = its computes its rank ?

 

JP.



 

Best,<= span style=3D'font-family:"Arial","sans-serif"'>

Mathilde

 

Durvy = Mathilde=
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

= Cisco Systems International S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain = confidential and privileged material for the sole use of the intended recipient. = Any review, use, distribution or disclosure by others is strictly = prohibited. If you are not the intended recipient (or authorized to receive for = the recipient), please contact the sender by reply e-mail and delete all = copies of this message.


 

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

 

------_=_NextPart_001_01CA6139.9EA1965C-- From pthubert@cisco.com Mon Nov 9 04:48:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B613A6B3E for ; Mon, 9 Nov 2009 04:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.539 X-Spam-Level: X-Spam-Status: No, score=-8.539 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhB1ijmLRxif for ; Mon, 9 Nov 2009 04:48:26 -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 CFE023A6B3C for ; Mon, 9 Nov 2009 04:48:25 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAIqe90qQ/uCWe2dsb2JhbACCJSyZKQEBFiQGqQ6WUwKEPAQ X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="gif'147?scan'147,208,217,147";a="53955574" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:48:50 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CmoJt016137 for ; Mon, 9 Nov 2009 12:48:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:48:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA613A.FC8203BF" Date: Mon, 9 Nov 2009 13:48:45 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FEBC@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEA161AF@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on parent / destination prefix / route removal Thread-Index: AcpccytsV946n2qGRMOOvMRn+icMYQExpwhg References: <8A977BDC5A7B0E429B0F521E8D6F91EEA161AF@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "roll" X-OriginalArrivalTime: 09 Nov 2009 12:48:50.0945 (UTC) FILETIME=[FCB8D710:01CA613A] Subject: Re: [Roll] Clarification on parent / destination prefix / route removal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:48:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA613A.FC8203BF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA613A.FC8203BF" ------_=_NextPart_002_01CA613A.FC8203BF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde: =20 In a general manner, when you lose a next-hop/link you clean all routes = via that next-hop/link. =20 A one hop loss can be detected by NUD. So the retry/remove thing only = applies to a destination, since you cannot NUD it hops away. =20 Parents used to be removed after missing periodic RAs in a row, like = MIP does, but that's harder with trickle. I think that's gone from the = spec now. =20 Cheers, =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: mardi 3 novembre 2009 11:48 To: roll Subject: [Roll] Clarification on parent / destination prefix / route = removal =20 Hi All, =20 This is my current understanding: =20 - Parents are removed based on OF selection (decision to move within the = DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer = procedure described in section 5.10.1.1.1. This is essentially a keep = alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding = destination prefix is removed?=20 - When are routes corresponding to parents removed? Do they also have a = lifetime? - What happens when a neighbor disappears, are the corresponding = parents/destination/routes removed? =20 The current behavior seems quite asymmetric... There is some kind of = keep alive mechanism for destination prefixes, but not for parents. = There is a lifetime associated with routes corresponding to destination = prefixes but not for routes corresponding to parents. Is that a design = choice? I would appreciate some clarifications. =20 Best, Mathilde =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 ------_=_NextPart_002_01CA613A.FC8203BF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mathilde:

 

In a general manner, when you lose a next-hop/link you = clean all routes via that next-hop/link.

 

A one hop loss can be detected by NUD. So the = retry/remove thing =A0only applies to a destination, since you cannot NUD it hops = away.

 

Parents used to be removed after missing periodic RAs = in=A0 a row, like MIP does, but that’s harder with trickle. I think = that’s gone from the spec now.

 

Cheers,

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: mardi 3 novembre 2009 11:48
To: roll
Subject: [Roll] Clarification on parent / destination prefix / = route removal

 

Hi All,

 

This is my current understanding:

 

- Parents are removed based on OF selection (decision to move within the = DAG, change DAG, etc)

- Destination prefixes are removed after the retry / RemoveTimer procedure described in section 5.10.1.1.1. This is essentially a keep alive = mechanism based on DIO (D bit set) - DAO exchanges.

- Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed?

- When are routes corresponding to parents removed? Do they also have a = lifetime?

- What happens when a neighbor disappears, are the corresponding parents/destination/routes removed?

 

The current behavior seems quite asymmetric... There is some kind of keep = alive mechanism for destination prefixes, but not for parents. There is a = lifetime associated with routes corresponding to destination prefixes but not for = routes corresponding to parents. Is that a design choice? I would appreciate = some clarifications.

 

Best,<= o:p>

Mathilde

 

Durvy = Mathilde=
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

= Cisco Systems International S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page

 

 

3D"ThinkThink before you print.

This e-mail may contain = confidential and privileged material for the sole use of the intended recipient. = Any review, use, distribution or disclosure by others is strictly = prohibited. If you are not the intended recipient (or authorized to receive for = the recipient), please contact the sender by reply e-mail and delete all = copies of this message.


 

------_=_NextPart_002_01CA613A.FC8203BF-- ------_=_NextPart_001_01CA613A.FC8203BF Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA613A.FC8203BF Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA613A.FC8203BF-- From mdurvy@cisco.com Mon Nov 9 04:48:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7763A6B3C for ; Mon, 9 Nov 2009 04:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 251xj0oFKyw6 for ; Mon, 9 Nov 2009 04:48:51 -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 07F233A672F for ; Mon, 9 Nov 2009 04:48:50 -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: Ak8AAIqe90qQ/uCWe2dsb2JhbACCIy6ZKQEBFiQGqQ6WU4Q+BA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="53955649" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:49:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CnGI8016337 for ; Mon, 9 Nov 2009 12:49:16 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:49:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA613B.0B844FD0" Date: Mon, 9 Nov 2009 13:49:15 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEB0112D@XMB-AMS-103.cisco.com> In-Reply-To: <1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #11: Decision on prefix packing in DIO messages Thread-Index: AcphMJ0LcnkleUXtTfK56c4ONxdCkAACQNQg References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> <1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Nov 2009 12:49:15.0911 (UTC) FILETIME=[0B9A5970:01CA613B] Cc: ROLL WG Subject: Re: [Roll] [roll] #11: Decision on prefix packing in DIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:48:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA613B.0B844FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, =20 Quick questions to help make my choice: - Is it correct to say that all the fields except the Instance ID, the RRcount and the Reverse Route Stack are per prefix? - Why do you need the instance ID? Either you assume that DAO are sent in unicast to preferred parents and hence you only receive DAO from childs belonging to your DAG iteration or you would need to specify the InstanceID, DAGID, DAG sequence triplet no? - The route tag (32bits!) usage is undefined for now, shall we drop it? Best, Mathilde ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: lundi, 9. novembre 2009 12:34 To: roll@ietf.org Subject: Re: [Roll] [roll] #11: Decision on prefix packing in DIO messages Dear all, =20 Here is a proposed resolution. Issue: as of today: there is exactly one prefix per DAO. Thanks to the DelayDAO timer, we may have a chance to perform data aggregation (when possible) but we would=20 still end up with an increasing number of DAO as we get closer to the sink, with the=20 worst case being one DAO per leaf ... As a reminder, here is the format of the DAO message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Sequence | InstanceID | DAO Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | RRCount | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Route Stack (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We have three options: 1) Option 1 (Trivial packing): we change the DAO message structure to carry more than one prefix in a DAO message. This is of course only possible for prefixes sharing the same route tag, rank. 2) Option 2: we also try to factorize common element. By adopting a flexible encoding, we avoid =20 repeating fields that are identical for a set of prefixes. Back to the example provided below, this would avoid repeating the value of the Reverse Route Stack for each prefix that uses the same recorded path. Thoughts ? Thanks. JP. On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote: #11: Decision on prefix packing in DIO messages =09 --------------------------------+--------------------------------------- ---- Reporter: jpv@... | Owner: jpv@... =20 Type: enhancement | Status: new =20 Priority: major | Milestone: =20 Component: rpl | Version: =20 Severity: Active WG Document | Keywords: =20 =09 --------------------------------+--------------------------------------- ---- Currently RPL requires one DAO per message. =09 JP's proposal below: =09 Hi Jonathan, =09 What I was referring to was to pack prefix in DAO, a very light change in the spec (just make use of TLV) and factor the common fields. This allows to reduce the number of packets very significantly as we get closer to the root. =09 There two benefits here: 1) You send one DAO between C and D instead of 3 2) You can also pack the Reverse Route Stack whenever possible for all prefix sharing the same routes. =09 Let's suppose that: 1) X advertises two prefixes X1 and X2 2) Y advertises two prefixes Y1, Y2 and Y3 3) Z advertised one prefix: Z1 =09 Instead of sending 6 DAO, C would send one DAO to D would look like this: X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] =09 Note that you could when possible also aggregates prefixes at the same time if they share a common path. =09 BAck to you timing question Richard, it depends of the sequence of events but there is no need to wait. C could start with one DAO and then start to pack at it receives more, the same reasoning applies to other nodes. =09 Others, thoughts ? =09 Thanks. =09 JP. =09 --=20 Ticket URL: roll =09 =09 ------_=_NextPart_001_01CA613B.0B844FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP,
 
Quick=20 questions to help make my=20 choice:
- Is it correct to say that = all the fields=20 except the Instance ID, the RRcount and the Reverse Route Stack are per=20 prefix?
- Why do you need the instance ID? Either you = assume=20 that DAO are sent in unicast to preferred parents and hence you only = receive DAO=20 from childs belonging to your DAG iteration or you would need to specify = the=20 InstanceID, DAGID, DAG sequence triplet no?
- The route tag (32bits!) usage is undefined = for now,=20 shall we drop it?
Best,
Mathilde
From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur=20 (jvasseur)
Sent: lundi, 9. novembre 2009 12:34
To:=20 roll@ietf.org
Subject: Re: [Roll] [roll] #11: Decision on = prefix=20 packing in DIO messages

Dear all, 

Here is a proposed resolution.

Issue: as of today: there is exactly one prefix per DAO. Thanks to = the=20 DelayDAO timer,
we may have a chance to perform data aggregation (when possible) = but we=20 would 
still end up with an increasing number of DAO as we get closer to = the sink,=20 with the 
worst case being one DAO per leaf ...

As a reminder, here is the format of the DAO message:

        0                   1            =
       2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We have three options:

1) Option 1 (Trivial packing): we change the DAO message structure = to carry=20 more than one prefix
in a DAO message. This is of course only possible for prefixes = sharing the=20 same route tag, rank.
2) Option 2: we also try to factorize common element. By adopting a = flexible encoding, we avoid  
repeating fields that are identical for a set of prefixes. Back to = the=20 example provided below, this would
avoid repeating the value of the Reverse Route Stack for each = prefix that=20 uses the same recorded
path.

Thoughts ?

Thanks.

JP.

On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote:
#11: Decision on prefix packing in DIO=20 = messages
--------------------------------+----------------------------= ---------------
Reporter:=20  jpv@…=20 =             &= nbsp; |=20       Owner:  jpv@…=20 =        
    Typ= e:=20  enhancement         |=20      Status:  new=20          
Priority:=20  major=20 =             &= nbsp; |=20   Milestone:=20 =             &= nbsp; 
Component:=20  rpl=20 =             &= nbsp;   |=20     Version:=20 =             &= nbsp; 
Severity:=20  Active WG Document  |    Keywords:=20 =             &= nbsp; 
--------------------------------+-------------------------= ------------------
Currently=20 RPL requires one DAO per message.

JP's proposal = below:

Hi=20 Jonathan,

What I was referring to was to pack prefix in DAO, a = very=20 light change in
the spec (just make use of TLV) and factor the = common=20 fields. This allows
to reduce the number of packets very = significantly as=20 we get closer to the
root.

There two benefits here:
1) = You send=20 one DAO between C and D instead of 3
2) You can also pack the = Reverse Route=20 Stack whenever possible for all
prefix sharing the same=20 routes.

Let's suppose that:
1) X advertises two prefixes X1 = and=20 X2
2) Y advertises two prefixes Y1, Y2 and Y3
3) Z advertised = one=20 prefix: Z1

Instead of sending 6 DAO, C would send one DAO to D = would=20 look like this:
X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC]

Note that = you=20 could when possible also aggregates prefixes at the same
time if = they share=20 a common path.

BAck to you timing question Richard, it depends = of the=20 sequence of events
but there is no need to wait.
C could start = with one=20 DAO and then start to pack at it receives more, the
same reasoning = applies=20 to other
nodes.

Others, thoughts=20 ?

Thanks.

JP.

--
Ticket URL: <https://svn.to= ols.ietf.org/wg/roll/trac/ticket/11>
roll=20 <http://tools.ietf.org/wg/roll/>


------_=_NextPart_001_01CA613B.0B844FD0-- From jabeille@cisco.com Mon Nov 9 04:50:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0708E3A67D2 for ; Mon, 9 Nov 2009 04:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.442 X-Spam-Level: X-Spam-Status: No, score=-7.442 tagged_above=-999 required=5 tests=[AWL=-1.844, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 neVXwd-d1s0C for ; Mon, 9 Nov 2009 04:50:30 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8AFFB3A672F for ; Mon, 9 Nov 2009 04:50:30 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image002.png : 9650 X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="png'150?scan'150,208,217,150";a="268178615" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:50:56 +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 nA9CoJFx018391; Mon, 9 Nov 2009 12:50:55 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:50:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CA613B.4596C810"; type="multipart/alternative" Date: Mon, 9 Nov 2009 13:50:51 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FE68@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency Thread-Index: AcpYj7JQFyo/Efk5TGCsU8TR9EHlJgAFM81gAACbBYACIN3qsAAD38xA References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE68@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , , X-OriginalArrivalTime: 09 Nov 2009 12:50:53.0505 (UTC) FILETIME=[45C60310:01CA613B] Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:50:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA613B.4596C810 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA613B.4596C810" ------_=_NextPart_002_01CA613B.4596C810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 NUD is not always done after validation. It is also done when there is a certain probability of validity. this is what the LLAO option in RS/RA/NS do, e.g.: - node A has no entry for node B - node B sends RS/RA/NS with SLLAO -> node A creates entry in stale (reachability is not confirmed) - node A has a packet to send to B, sends the packet then does NUD after 5s. In this case node B was never in reachable state before NUD. This is what is being dond in every IPv6 implementation since a decade with RS/RA/NS. =20 questions: - are we ok to accept a parent if it is just STALE (because the LLAO option was there) but bidirectionality is not sure? - if no, what is the proposed way to populate the neighbor cache? In real life this will not happen by magic:=20 if i do not have a packet to send to a neighbor, i do NOT do address resolution. But if i do not have a parent entry for this node, there is in many cases NO reason to send a packet to this node (chicken egg), because this node is just a router for me. E.g in a MP2P application, all nodes want to send to the sink. Only nodes that are within reach of the sink will try to send a packet to the sink, which will be their parent. They will try to send data, it will trigger creation of the neighbor entry, DIOs will be accepted. All other nodes will never have an entry for their neighbors/potential parents. =20 Best, Julien=20 ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 9 novembre 2009 13:13 To: Julien Abeille (jabeille); 'wintert@acm.org'; 'jpv@cisco.com' Cc: 'roll' Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency =09 =09 Hi Julien: =20 For me a validation is at least a bidir. NUD is a revalidation. =20 =20 What do you think? =20 Pascal =20 >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: jeudi 29 octobre 2009 15:55 >To: Pascal Thubert (pthubert); wintert@acm.org; jpv@cisco.com >Cc: roll >Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency >=20 >Hi Pascal, >=20 >What I was trying to achieve is the validation. I was trying to see if standard ND (let's not diverge) can >achieve this. With a LLAO, the entry would be created (STALE), then the first time you want to route a packet >through the router that originated the DIO, you would send the packet, arm a delay timer... do NUD as usual. >=20 >Comment on this: >- depends on 6lowpan discussions... >=20 >questions: >- do we think this is enough? >- otherwise do we need to specify a custom mechanism inside RPL? >=20 >Best, >Julien >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Pascal Thubert (pthubert) >> Sent: jeudi 29 octobre 2009 15:46 >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll >> Subject: Re: [Roll] [roll] #7: RPL bootstrap question: >> neighbor cache andDIOs dependency >>=20 >> Hi: >>=20 >> In fact a stale entry is not sufficient. We need an entry >> that is reachable. >>=20 >> That is the minimum validation process that comes with the >> fact that the draft as it stands today depends on NS/NA flows >> to ensure bidir connectivity with the neighbor. The way I see >> it, the node should at least unicast NS to the candidate to >> assert that. In the same fashion as NUD allows the node to >> remove the parent. But if a stronger validation mechanism is >> in place, then that should supersede the NS/NA. >>=20 >> Soon enough we might need to elaborate a bit on the >> validation process. In some environments, it can be done as >> part of metrics computation, like using srcr results for >> instance. Things like that cannot be in the base spec but >> then, do that belong to metrics, a new draft, or should >> validation above and beyond NS/NA be left to implementation? >>=20 >> Pascal >>=20 >> >-----Original Message----- >> >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] >> On Behalf Of >> >roll issue tracker >> >Sent: jeudi 29 octobre 2009 13:02 >> >To: wintert@acm.org; jpv@cisco.com >> >Cc: roll@ietf.org >> >Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor >> cache and >> >DIOs dependency >> > >> >#7: RPL bootstrap question: neighbor cache and DIOs dependency >> >--------------------------------+---------------------------- >> ---------- >> >--------------------------------+----- >> > Reporter: jpv@... | Owner: wintert@... >> > Type: defect | Status: new >> > Priority: major | Milestone: >> >Component: rpl | Version: >> > Severity: Active WG Document | Keywords: >> >--------------------------------+---------------------------- >> ---------- >> >--------------------------------+----- >> > Email From Julien >> > >> > Hi all, >> > >> > as explained in section 5.4.2 of RPL, a DIO must not be >> processed if >> > the source is not in the neighbor cache. The question is how do we >> > expect the neighbor cache to be filled? >> > topology: >> > A >> > | >> > B >> > B receives a DIO from A, A is not in B's neighbor cache: >> > >> > NS/NA exchanges will probably not occur, as B has no good reason to >> > send packets to A (A is not a router for B, B has most of >> the time no >> > data to send to A) RS/RA exchanges: do we expect to send RAs in RPL >> > environments? Would this be enough? >> > If there are no frequent RAs, or unsolicited NAs, then A >> will likely >> > never be in B's neighbor cache. >> > >> > One way to solve this would be to allow SLLAO option in DIOs. >> > Processing this option in ICMP messages (NS, RS, RA) is a >> well known >> > process, and would create an entry in the neighbor cache, >> state STALE. >> > >> > what do you think? >> > >> > Julien >> > __________ >> > >> >-- >> >Ticket URL: >> >roll >> > >> >_______________________________________________ >> >Roll mailing list >> >Roll@ietf.org >> >https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 ------_=_NextPart_002_01CA613B.4596C810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
NUD is not always done after validation. It is = also done=20 when there is a certain probability of validity. this is what the = LLAO=20 option in RS/RA/NS do, e.g.:
- node A has no entry for node = B
- node B sends RS/RA/NS with SLLAO -> node A = creates=20 entry in stale (reachability is not confirmed)
- node A has a packet to send to B, sends the = packet then=20 does NUD after 5s.
In this case node B was never in reachable = state before=20 NUD. This is what is being dond in every IPv6 implementation since a = decade with=20 RS/RA/NS.
 
questions:
- are we ok to accept a parent if it is = just STALE=20 (because the LLAO option was there) but bidirectionality is not=20 sure?
- if no, what is the proposed way to populate = the neighbor=20 cache? In real life this will not happen by magic:
if i do not have a packet to send to a = neighbor, i do NOT=20 do address resolution. But if i do not have a parent entry for this = node, there=20 is in many cases NO reason to send a packet to this node (chicken egg), = because=20 this node is just a router for me. E.g in a MP2P application, all = nodes=20 want to send to the sink. Only nodes that are within reach of the sink = will try=20 to send a packet to the sink, which will be their parent. They will try = to send=20 data, it will trigger creation of the neighbor entry, DIOs will be = accepted. All=20 other nodes will never have an entry for their neighbors/potential=20 parents.
 
Best,
Julien 

From: Pascal Thubert (pthubert)=20
Sent: lundi 9 novembre 2009 13:13
To: Julien = Abeille=20 (jabeille); 'wintert@acm.org'; 'jpv@cisco.com'
Cc:=20 'roll'
Subject: RE: [Roll] [roll] #7: RPL bootstrap = question:=20 neighbor cache andDIOs dependency

Hi Julien:

 

For me a validation is at least a bidir. NUD = is a=20 revalidation.

 

What do you think?

 

Pascal

 

>-----Original Message-----

>From: Julien Abeille = (jabeille)

>Sent: jeudi 29 octobre 2009 = 15:55

>To: Pascal Thubert (pthubert); = wintert@acm.org;=20 jpv@cisco.com

>Cc: roll

>Subject: RE: [Roll] [roll] #7: RPL = bootstrap=20 question: neighbor cache andDIOs dependency

> 

>Hi Pascal,

> 

>What I was trying to achieve is the = validation. I=20 was trying to see if standard ND (let's not diverge) = can

>achieve this. With a LLAO, the entry would = be=20 created (STALE), then the first time you want to route a = packet

>through the router that originated the = DIO, you=20 would send the packet, arm a delay timer... do NUD as = usual.

> 

>Comment on this:

>- depends on 6lowpan = discussions...

> 

>questions:

>- do we think this is = enough?

>- otherwise do we need to specify a custom = mechanism=20 inside RPL?

> 

>Best,

>Julien

> 

>> -----Original = Message-----

>> From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On

>> Behalf Of Pascal Thubert=20 (pthubert)

>> Sent: jeudi 29 octobre 2009=20 15:46

>> To: wintert@acm.org;=20 jpv@cisco.com

>> Cc: roll

>> Subject: Re: [Roll] [roll] #7: RPL = bootstrap=20 question:

>> neighbor cache andDIOs=20 dependency

>> 

>> Hi:

>> 

>> In fact a stale entry is not = sufficient. We=20 need an entry

>> that is reachable.

>> 

>> That is the minimum validation = process that=20 comes with the

>> fact that the draft as it stands = today depends=20 on NS/NA flows

>> to ensure bidir connectivity with the = neighbor.=20 The way I see

>> it, the node should at least unicast = NS to the=20 candidate to

>> assert that. In the same fashion as = NUD allows=20 the node to

>> remove the parent. But if a stronger = validation=20 mechanism is

>> in place, then that should supersede = the=20 NS/NA.

>> 

>> Soon enough we might need to = elaborate a bit on=20 the

>> validation process. In some = environments, it=20 can be done as

>> part of metrics computation, like = using srcr=20 results for

>> instance. Things like that cannot be = in the=20 base spec but

>> then, do that belong to metrics, a = new draft,=20 or should

>> validation above and beyond NS/NA be = left to=20 implementation?

>> 

>> Pascal

>> 

>> >-----Original = Message-----

>> >From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org]

>> On Behalf Of

>> >roll issue tracker

>> >Sent: jeudi 29 octobre 2009=20 13:02

>> >To: wintert@acm.org;=20 jpv@cisco.com

>> >Cc: roll@ietf.org

>> >Subject: [Roll] [roll] #7: RPL = bootstrap=20 question: neighbor

>> cache and

>> >DIOs dependency

>> >

>> >#7: RPL bootstrap question: = neighbor cache=20 and DIOs dependency

>>=20 = >--------------------------------+----------------------------

>> ----------

>>=20 >--------------------------------+-----

>> > Reporter: =20 = jpv@…          &n= bsp;   =20 |       Owner:  = wintert@…

>> >     = Type: =20 = defect           &= nbsp; =20 |      Status:  new

>> > Priority: =20 = major           &n= bsp;  =20 |   Milestone:

>> >Component: =20 = rpl           &nbs= p;    =20 |     Version:

>> > Severity:  Active WG = Document =20 |    Keywords:

>>=20 = >--------------------------------+----------------------------

>> ----------

>>=20 >--------------------------------+-----

>> > Email From Julien

>> >

>> > Hi all,

>> >

>> > as explained in section 5.4.2 of = RPL, a=20 DIO must not be

>> processed if

>> > the source is not in the = neighbor cache.=20 The question is how do we

>> > expect the neighbor cache to be=20 filled?

>> > topology:

>> > A

>> > |

>> > B

>> > B receives a DIO from A, A is = not in B's=20 neighbor cache:

>> >

>> > NS/NA exchanges will probably = not occur,=20 as B has no good reason to

>> > send packets to A (A is not a = router for=20 B, B has most of

>> the time no

>> > data to send to A) RS/RA = exchanges: do we=20 expect to send RAs in RPL

>> > environments? Would this be=20 enough?

>> > If there are no frequent RAs, or = unsolicited NAs, then A

>> will likely

>> > never be in B's neighbor=20 cache.

>> >

>> > One way to solve this would be = to allow=20 SLLAO option in DIOs.

>> > Processing this option in ICMP = messages=20 (NS, RS, RA) is a

>> well known

>> > process, and would create an = entry in the=20 neighbor cache,

>> state STALE.

>> >

>> > what do you = think?

>> >

>> > Julien

>> > __________

>> >

>> >--

>> >Ticket URL:=20 = <http://rsync.tools.ietf.org/wg/roll/trac/ticket/7>

>> >roll=20 <http://tools.ietf.org/wg/roll/>

>> >

>>=20 >_______________________________________________

>> >Roll mailing list

>> >Roll@ietf.org

>>=20 >https://www.ietf.org/mailman/listinfo/roll

>>=20 _______________________________________________

>> Roll mailing list

>> Roll@ietf.org

>>=20 https://www.ietf.org/mailman/listinfo/roll

>> 

------_=_NextPart_002_01CA613B.4596C810-- ------_=_NextPart_001_01CA613B.4596C810 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: <765004112@09112009-24CE> Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACUySURBVHja 7Z1dkx3FeYC3ChsJnB+Vi/yAVMU/IL8hV7nMrRMnZZfBZUMSbMCAkVEAgZCQQNYHCgjLgMBSoQit PhDSAlpJIIMErCb7nsNAb6u7p2emZ/rtmeep6to958zX6em3n9MzPd0rVVX97Wb6FxKJRCKRSKOl v1/59h8AAAAYj0cQMAAAwPggYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAA gAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwgYAAAgAwg YAAAgAxMS8ArKytR6Yc/+EG17d5t1f3b76MIDJD3qdf/0f33L87XPffc890y9/7wh+R1x7xOjcSR HIuco6l9t1TH3rV8584P3/7leOU96tDubGxszFPAZpKCLgEwd+7bvn1RAQxR+fRZ/0f33e88b9vu vXe250qTpOrz06fsaP1uKY+9a/nWKmCh/sEg3wHag4BpTW0JpD5BPpSA5dzU72/ftk1Vvmko5zn5 m/t/lLwSnpuAm8q3ZgGbP76kLEA7Ji3gpopDWnzm8nO+lJIiyIeqKEqukDWfrxRIK23uVyP6nhft 5bvp+CgD3ZmtgGtMCXNJEwHP6Xz1pb7vK4nWT/fzUrqA5dzTiOnG7AVsFp45V/AIeH7nqy/SkTFV x6s5n5fSBSzUHbKkTEA8sxdw7Dryy05ayOa9Uvlf3gv96rO3Lfd4Qvd75AeBvF9XbnWhlvdC99js /ciydVDU27hv2/bgenYaI+9D63c5tq75VyPL2OvLPTrJO7uVZy7j68Rn/sDzVU5t9hmb133zoQmz 9evb3jJmtvbsjXn6oM19VLv3sPyV72jmmysW7GVCcWTeo12cl+3bkxx7bPkeo9zL+TC/p+RXXaZj 9m92JKMVHA8tYKOCdPXilEJoViBtO3Ft7dW4bctrW8BmpeZLLona+wltx/6OUxJwn/wTzB9Hvrwz RSvbaqp0zGNy7bvtPmPyum8+xFBX9L6ez2Zl7ku+Wz6xEosp56H8dXUcit1+TLynKt9Dl3vfuZL8 sbcdoq4naQXHM3sBmwFqX0oze3jWhdEu+KacXb+M7UJdb0N+MZoVq1nQF49FGb9a7V/hMS1Z8xe+ rL/lOBvWHyvvY9ePvULRJ/9Mmdrrm/0EzEpbzl9ThWzu1xZpl3025UnffIjB/N6uqzjm9zJbUs5j 2N6uLN4t8e/Lufw1t12XeTsWQr2O7xLX9u3e7bt+QHTpBd1UvmN/bHU533UHqvr7mN/V9eMlti7l sc44Zitg+7KUqxVjViS+yzjmpRfXL7+YX6ExlymbKnO7UupznEPnfdv123QC6ZJ/plB865tCNM+j ecnPlmTouPrs05cnKcpRDOZxuVr+TY+0NR1nrMRcArSfqW0bC03r2ufcrhfGFHDvcn9fcxk0Bd0U 11uu9mzvd4VlLvAccCCYzUDrIg77M5/EY0RvB0zol7tvG11H6emS9ynXb9pu3/yLuZTsq+xC64Yu P/fZpy9PUpSjGMxK2bWfLWWxg+D7xlOfWIhZ1zyvoThMVb59n/c932aLNeYWSkyjhidK2oGAEwzC 0VdsZoUWuy/7mGP2M1UB982/Pi1CsyVrt5hC2+3bCnXlSYpyFEPTD1PzypK0hkUUbTp+9S2nfZYx 3/d1gAvdehhTwGOU+7ZPicS0yOF7ZitgKXzyC7Btj73FvdvNJJdY7F6HKSqMNillxVSygPvmX9/j dgmpz2XWrnmVohylOs+ujj3LpwaWMRd6bliLgFOX1dQCHqvcdxEwjwzGwWNIEYhsbdHGVmYIuP/6 2gXsuhTY1Pt56gKu8yDUG1pacE2XsPvGU+qy1md9BAw2CLgBuwKpn/0VKdeVxxgVRorvPQcB5zhu 12Xopst7QwtYU4xJa1dkLFeMXI/0pejIlGqZUgU85HlEwMOBgANsfUTp3k6DIrS9XNd1kIQ5C7hv /sXejw09L273jG26F9Z3n648SVGOYojtnOhj+QTCva06mKUq523KWsw9YLuz0ZgCHqPccw94WBBw z23Zjz102YYp+tCzmaFehnMWcN/8i+kNunXd8LOvMcfTd5+uPElRjmJo6gUdejSr7/keU8BdBlcZ U8B9z3fbgWToBZ0eBNxzW/Yl6i7bsEfj8v0aNSs+O2DmLOC++df2eUiXdHxzuvqOpe8+m54D7lqO Ymh6DniLGDzPg4aeg9YiYN95Cf3AyPUccKdyH/EselMnUxOeA24PAg5gPk4horXHl3V1MGkTkFsq tW1bRz6yA8UesSZ1xWTem5P9dZndZqiOZDHfrW/+mdJYjCj0bWVmjwgUmnjAvr/ZdBmuzz5jng3t kg8xhB69qo/fHiHOjh2zYk/xLG2qZVxPS5gjn7UZka7LPtt+n77n2zcamz3qV0wdZtaXjIQVBwJu qGiaxoGWAt91ZJxQMIR6jqaudOzgSdE7dmwB980/oWlc5iZh2evHDPXYdZ+xlXLX79JE01jQ9vCn bZ7B1yJge75wM/kGMBlbwCnOtyv2zTIcG3+MBd0eBNxAaJYRc3zZPvdmXfuzx7TtM4NM7DL2AAp9 8j6HgPvkX009RKkpj6YZr8x1Yy4/p9hnzGX5PvnQhHm5MTSSl1Tg9nCG9TP4Q43YlrIX9N2tyHaz kqUo37G3sfqcb/uRMbM1HLP/mPIAdzM5AQPkZE69QL+fD3g6HW54jKYb9Y8UWr/tQMAAiTBbwH2n +yuBmDmBSwMB9yv3tH7bgYABEmHeL+vSia1E6pbPVFrBCJgyMCYIGCABZs/fOVVE5veeQisYAbej bv265qyGZhAwQE9in/2dKnUlPIX7fwi4HXU/gKncghgbBAzQk7oSkr9zrYjq+8Fd5hfWBAKOp36E jvu+3UHAAAAAeUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAA GUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDA AAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAAAAGUDAAD5WVla8CQCgDxsbGwgY IAakCwApQcAAkbgEXL/nahUjbAAIgYABIvEJ2JRw0/IAADUIGCCSUAvYfo18AaAJBAwQCQIGgJQg YIBIEDAApAQBA0QSI2DfewAANggYIBIEDAApQcAAiUHAABADAgZICPIFgFgQMAAAQB4QMAAAQAYQ cOlc/Ozz6o1Ll0mkSaSTn14lqGEuIODSkUrr+OW16vTVayRS0Unku/vMKkENcwEBl44IWFrBAKXz xddfI2CYEwi4dBAwTAUEDDMDAZcOAoapgIBhZiDg0kHAMBUQMMwMBFw6CBimAgKGmYGASwcBw1RA wDAzEHDpIGCYCggYZgYCLh0EDFMBAcPMQMClg4BhKiBgmBkIuHQQMEwFBAwzAwF35frNm9UT+1+t Htu7L2vaefyt6qnDr2U/jr3H/kShgF4gYJgZCLgrJz44W/16995q5zvvkTbTTx5/kkIBvUDAMDMQ cFdEwL955UC179xF0mZCwNAXBAwzAwF3BQEjYEgLAoaZgYC7goARMKQFAcPMQMBdQcAIGNKCgGFm IOCuIGAEDGlBwDAzEHBXEDAChrQgYJgZCLgrCBgBQzqu3PzrQr51ktcAEwcBdyVWwEKb9xEwzJUj Fy8t5Ct/AabOxsYGAu5KGwELCBggTN0KpvULcwAB96BtC7j+6xOwSWiZWImb+3Ut59pfzHoIGIbi 1u3b1ZHVc4u/AFMHAfcgpYB9n4XWiRGwbx9NxxJaFgFDamRc9ZffPF49sPPZ6r/27l/8ldfyPsBU QcA96HIPOOZ/32e+v7H3ntvuDwHD0Fz65NNq56Ej1S82hfvE0TeqPWdWF2VJ/spreV8+l+UApgYC 7kHXTlj1a/N9FwgYphw7j+zeU/1q1+7q92/+OViu5HNZTpaX9QCmAgLuWYmkFHDsJWzX+ggYtCP3 dY+++1718z/sXMTNs++ebNXJT5aX9WR92Q73iaF0EHAP+jyGVNO1s5VrmwgYNCL3cV96/Vj18x07 q8cOvlbtPn22V297WV+2I9uT7XKfGEoFAfcg9XPAJl1a0W0EHNMLGgFDH85fWauePnBwcR/3yU1R 7j17Puljb7I92a5sX/Yj+wMoCQTcAw0jYQk8Bwxa+PqbbxZx8atnd1UPvbin2nH87VHKnuxH9if7 lf3LcQBoBwG3xBwgAAEjYFhy84svq0Nvn1g8PiQxsevU+1nKoOxX9i/HIccjxwWgFQRs8dXGRnV1 M2h96ZXVC9WB8xeri599zljQCHj2fHrjRrXrtaOLy8CPHz7a+/5uqiTHIccjxyXHJ8cJoBAEbPLW lY+3DAgfSgc/WEXACHiWnL5wsXpi/6vVg//zfPXUsePJ7++mvE8sxyfHKccrxw2gCARs8saly9Xp q9e8n0vrV5aR1jAtYAQ8J+S+6lun/696cOdzi9GqnnnrRFHlU45XjluOX74H94lBAQjYpEnAN259 /+whAkbAc0Duox7489vL53dfPVi9+P6ZosupHL98D/k+8r24TwwZQcAmTQI2GVPAQp/nfhHwkpWV lUVqWsb8O1fW1tcX909/tuOZ6vEj//vdMJFTSfJ95HvJ95PvKd8XYEzohGWhVcAl9IjWLuC2Qp2r gE+unlsM+/jL515Y3D+dw9Ub+Z7yfeV7y/cHGAMEbDGmgE3aDrhhrxvalr1MaFQu1+dTEHDd8jWl 6nqvft/8a//v+yxm21qRYR2PnTy1uD/63/tebT1M5FSSfG/5/pIPkh8MdwlDgoAtxhKw4Htd/+96 r62kXeIN/W9vY6ot4C5CDS0fu6w2zGkAH/3j4eLv76a8Tyz5wbSIMCQI2KJEAXcVc+r7xiVfgu4r 4NB+NArYNw0g6e77xEyLCEOBgC3GFLBNmw5VrvV864S21bSfKQvYvEycWsC+bedGyuzDu3ZHTQNI 2prqaREl/5gWEVKAgC1ytYCbxNl2eQR8N0NegvZ9pgF7GsDn/3IKofZIkn9MiwgpQMAWU70HHCPg mrkJeIgWcOj1WKSeBpC0NTEtIvQFAVuU2gs61NnKt8059YIWfJeK7c98zwE3XbL2LTs2Zy99NOg0 gKStyZ4WUfIfIAYEbFHyc8C5nyVmJKx8mNMAPvzSy6NNA0jamiTfJf+ZFhFiQMAWcxOwTZ9tIeDx 0TINIGlrYlpEiAEBW8y9BYyAy0DrNIBNV1XM/7tcfYndlqb7xEyLCD4QsAUCRsCaken0Htu7T/00 gF1ua8QsF7stjfeJ62kR5fwxLSIICNgCASNgbdjTAO585z0VInW9rolttZrL28vZ27Lfc23Xtf+U HQ1TJDl/TIsIAgK2QMAIWAvapgEU2oi17f/1667b6rJczsS0iICALRBwfgFv3LlTnVm/vjgPc0yn 1j5ROw2gT5Kx92pjpZ1yW7H7yZXsaRHl/E+tTF/lxwUCRsBlCPjiZ59X+86eX5yLOabDq+fVzkoU ErBNX2mm3Jb2+8jmLExy/qdUng9d+LA6cJ573gh4AAE/8Oyu6tFDr5E2U0oBy3mYO/W8vJrGbfYJ OFaAMWJMuS3tAq7Hl57yPMQSzwjYDQK2aCNgGQP2yDvvkr5NqQaoR8Bb0TZzkdB0mdh+3VXAfbel 8R7w3GZYQsB+ELBFGwHDcAGLgO/GnLs3Z6cswfd+/Zm5jO//pkvNvm017aNNb+scna7mNscwAvaD gC0QsI6ARcB+5MqLhseSSk1CzseO5jZ7EgL2g4AtELCOgEXAcdQDc/zyuRcWAz0g2IvRncOGTnI+ 5LzMfeANBOwHAVsgYB0Bi4Dbsba+vuXRJaYezJMWQ08ajxTJeSGeEXAABGyCgHUELALuRj14B5Mz jJvMyRcYVOPueEbAXhCwCQLWEbAIuB/29ITPvHUCUQ6QJF+ZfrA5nhGwFwRsgoB1BCwCTodMEP/E /leLmsBBczInVpB8lfyFcDwjYC8I2AQB6whYBJwecwrDxw6+xn3iDvd3Jd+YWrB9PCNgLwjYBAHr CFgEPBxyf/Lou+8tJ3l45UD1/F9OIdhAkvyRfJL8knzj/m77eEbAXhCwCQLWEbAIeBzkvuXDu3ZX D724p9px/G2EayTJD8kXyZ9Uo7zNNZ4RsBcEbBIj4JWVFW+qP9eM9uNDwONz/spa9fSBg4vLq0++ fmy294nle8v3l3yQ/JB8gf7xjIDd8BywRdsWsHaZlXjMCDgfMjziS5sC+vmOndWjfzycfQ7iMYeJ lO8r31u+/1yGiRwrnhGwGwRskULAdkvYbB27Xpvvud737SdmPdd2XMtrC1gEnBcZLvHYyVNqp0VM lcxpAOX7zm2YyLHiGQG7QcAWqQUcEq9Prk2y9u3bte2YzzQGLALWg8ZpEfumOUwDqCmeEbAbBGwx RAvYt2ysgGP3jYBhSLRNi9g2zW0aQE3xjIDdIGCLXAJ2debybb9pe20/0xiwCFgv9bSIi8eYMk6L 2Ob+rhynHO+cpgHUFM8I2A0CttDQAm7aftP22n6mMWARsH5k2EXN0yLa0wAyTGS+eEbAbhCwBZeg dQQsAi6LU4qmRfRNA3jj1u3q89tfcbIyxDMCdoOALXIIuP4/pjeza1++jlqhy9r0goaUHL+8thDc lmkRDx8dbbjLxTSAh48GpwGUMnXi4084WRniGQG7QcCOIGUkrPwBi4DLQcS7+8zqQsI1MlzjobdP DD4tojkNoOwvNEwkAs4XzwjYCwK2gxQB5w9YBFwOIl4RsCSRsclQ0yJ2mQYQAeeLZwTsBQHbQYqA 8wcsAi6DW5vik3O154Nz1aELH1Zn1q97l+07LWLfaQARcL54RsBeELAdpAg4f8Ai4LKQClbOWwz1 tIgy7GPMtIj1NICyfJ9pABFwvnhGwF4QsB2kCDh/wCLgsmgj4BoZ9jE0LaI9DWDfYSIRcL54RsBe ELAdpAg4f8Ai4LLoImATc1rE3x19fZBpABFwvnhGwF4QsB2kCDh/wCLgsugr4BqZ/m/fm8cHmQYQ AeeLZwTsBQHbQYqA8wcsAi6LVAIeOrYRcJ54RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcs Ai4LBAyheEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLg skDAEIpnBOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4L BAyheEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLgskDA EIpnBOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4LBAyh eEbAXhCwHaQIOH/AIuCyQMAQimcE7AUB20GKgPMHLAIuCwQMoXhGwF4QsB2kCDh/wCLgskDAEIpn BOwFAdtBioDzBywCLgsEDKF4RsBeELAdpAg4f8Ai4LJAwBCKZwTsBQHbQYqA8wcsAi4LBAyheEbA XnQI+NInn1Y/ffLp6iePP5k1/Xrv/urB51/Mfhz/ueulWQcsAi4LBAyheEbAXnQI+MQHZ6vfvHKg 2nfuImkziYTnHLAIuCwQMITiGQF7QcAIWF/AIuCyQMAQimcE7AUBI2B9AYuAywIBQyieEbAXBIyA 9QUsAi4LBAyheEbAXhAwAtYXsAi4LBAwhOIZAXtBwAhYX8Ai4LJAwBCKZwTsBQEjYH0Bi4DLAgFD KJ4RsBcEjID1BSwCLgsEDKF4RsBeEDAC1hewCLgsEDCE4hkBe0HACFhfwCLgskDAEIpnBOwFASNg fQGLgMsCAUMonhGwFwSMgPUFbAoBr6ysONNQ1NsO7SN2/+ZyQx5zKhAwhOIZAbvZ2NhAwAhYX8Cm EnCb94faX5d9lyBdEwQMoXhGwG4QMAJWGbBjCdjVMrbXc712taZ9LWBz2Zht2e/FrmPva0wQMITi GQG7QcAIWGXAjiHgNgL1bdMnQd/nbbcVu/+mbQ8NAoZQPCNgN0UIWGjzfuwyMeu3WQ4BpwvYMe4B t5Wpbx+hdZpa003bit1em/0MAQKGUDwjYDcIGAGrDNghWsChS7mhS7qu7cau0/YYXMsh4DQg4Hzx jIDdTErAJk3LxMjZt5y9H9fnrtfm39C+EfBwl6BjL9PGiq2PgFNfgm767kOCgCEUzwjYzWQEbC9T v/YtUxOz3ab9+PbtOpbQtnwCvvrFl9WVm3+dVcDmEHCMxGLu6XaVLAIeFgScL54RsJtiBOyjq4Db tqzbtG777r8WsIhXKo3dZ1YXf09fvTaLdPzyWtZe0DHrh2Qbe5m5aVtdekE3HftQIGDwgYD9TKoF bFOygP/96T8sRCTylSQFWCqQuaTVazeIzoJAwOADAfuZ7CXoNvLU2gIWbty6vRCxtAwBtIKAwQcC 9jPbe8CpBdymM1bbe8CLE3XnDqUV1IKAwQcC9jPbXtD2ck33nZv2M7SAATSDgMEHAvbDSFiMhAXQ GwQMPhBwEASMgAH6gYDBBwIOgoARMEA/EDD4QMBBEDAC1o08klQ/jkXSm7QPFoOA84CAgyBgBKwb qTQlycAkJJ3p2pe31JcjBJwHBBwEASNg3UilyXPQ0BcEnAcEHAQBI2DdIGBIAQLOAwIOgoARsG4Q MKQAAecBAQdBwAhYNwgYUoCA84CAgyBgBKwbBAwpQMB5QMBBEDAC1g0ChhQg4Dwg4CAIGAHrBgFD ChBwHhBwEASMgHWDgCEFCDgPCDgIAkbAukHAkAIEnAcEHAQBI2DdIGBIAQLOAwIOgoARsG4QMKQA AecBAQfRIeCTq+eqn+14pnroxT2kzYSAvwcBQwoQcB4QcBAdAhbOX1nLnv584VL1/mag5j6OtfV1 iua3IGBIAQLOAwIOokfAudm4c6d6ZfVCdfzyGpmhCAQMKUDAeUDAQRBwjTnv7I1bt8kQJSBgSAEC zgMCDoKAa9668nG17+z5RWE5s36dDFECAoYUIOA8IOAgCNgOUip7XSBgSBXbCHh8EHAQBGwHKZW9 LhAwpIptBDw+CDgIAraDlMpeFwgYUsU2Ah4fBBwEAdtBSmWvCwQMqWIbAY8PAg6CgO0gpbLXBQKG VLGNgMcHAQdBwHaQUtnrAgFDqthGwOODgIMgYDtIqex1gYAhVWwj4PFBwEEQsB2kVPa6QMCQKrYR 8Pgg4CAI2A5SKntdIOByWVlZUXMctYBjjknLcbf5fnbSco5qAZeWp2OwsbGBgE0QsD4QcLloFHBJ x90nn2O/AwLOBwK2QMD6QMDlYla69f92C83VYmu7bOj9+n9fC9hev2l7GkXiO6aY79B1mdhz8Hf/ 8GME7AEBWyBgfSDgcgnJM1TJxy4bEre9rkvAMevHvNaUz6H8j8mrtvnRtI60gB85eBgBO0DAFghY Hwi4XNq2otou2+b9mHvAcxdwzPptzw2XoP0gYAsErA8EXC5jCNjV+aiNgGPX79rJaex8DuVpl+/q yvOYvEHAzSBgCwSsDwRcLmO3gEPLp7wErTmfY/O0bb63zRsE3AwCtkDA+kDA5aL9ErTvPvMULkF3 ycPYznFttouA/SBgCwSsDwRcLkMLuP6/qddyzCVoc7sl9oKOuUTephd0zHmIOQfSC5pOWG4QsAUC 1gcChlSxzUhY/egiUUbC8oOAHUFKZa8LBAypYhsBd6drCxYB+0HAjiClstcFAoZUsY2AxwcBB0HA dpBS2esCAUOq2EbA44OAgyBgO0ip7HWBgCFVbCPg8UHAQRCwHaRU9rpAwGWTY5ae0GNI5PMw+ezb DgL2wz1gCwSsDwRcLrlm6XGtO2UBa8pnGwTsBwE7gpTKXhcIuFxiB26IGfQhZtYj33L2c8BtZmCa Uz6HWtBN+ezbXz0b0hTyOTUI2AIB6wMBl0tTBRs7GEeXUZzs5SW2/+lf/y24v5hLqlPN5y7nIub/ ejakKeRzahCwBQLWBwIum9C9yZQCbtpujIBD25h6PrcZmazN+XIJuOR8TgkCtkDA+kDA0yJmhp7Y 5RBwunyOPRcx+YeA40DAFghYHwi4XJruTbadizZm+673py7gFPkcey5i9oGA40DAFghYHwi4XNqK Ifc94KZjn3I+j3kPuNR8Tg0CtkDA+kDAZdP0fGrqXtCu99r0gva9nkM+t+kFbb/Xthd0qfmcEgRs gYD1gYAhVWwzEtb48BxwEARsBymVvS4QMKSKbQQ8Pgg4CAK2g5TKXhcIGFLFNgIeHwQcBAHbQUpl rwsEDKliGwGPDwIOgoDtIKWy1wUChlSxjYDHBwEHQcB2kFLZ6wIBQ6rYRsDjg4CDIGA7SKnsdYGA IVVsI+DxQcBBELAdpFT2ukDAkCq2EfD4IOAgCNgOUip7XSBgSBXbCHh8EHAQBGwHKZX9kus3b1aP 791fPbZ3X9a0440/VU8ffSP/cRw4WH39zTcUjIJju6uA/3J2NXv505QOvX0iOu8QcBAEbAcpAl5y /spa9eBzL1Q733mPtJl+tuOZxY8SKDe2uwp412tHq9/+8QhxsJl+d/T1hYRjQcBBELAdpAh4iQj4 oRf3VPvOXSRtpl/sfBYBFx7bfQT81LHjxMFmEgkj4GQgYDtIEfASBIyApxbbCBgBKwMB20GKgJcg YAQ8tdhGwAhYGQjYDtIUAvZN6WUv4/pfCwgYAU8tthEwAtYE0xE6grSvgLvIFAEjYBg+thEwAtYE AnYEaR8BN00a7mv1hlrDrs9iJ9HuAwJGwFOLbQSMgDWBgB1BmroF7HvdVcCxy/YFASPgqcU2AkbA mkDAjiAd+hJ0XwGH9oWAETD4YxsBI2BNIGBHkA4hYPMycWoBu7adAgSMgKcW2wgYAWsCATuCVPsl 6NC2U4KAEfDUYhsBI2BNIGBHkA4p4CFawKHXfUDACHhqsY2AEbAmELAjSIe8BG1+3ubScsy26QWN gCEc2wgYAWsCATuClJGwliBgBDy12EbACFgZCNgOUgS8BAEj4KnFNgJGwMpAwHaQIuAlUxKwgICJ 7bEF7Ct3seWx7/oIWDdcgnYEKQJegoAR8NRiGwEjYE0gYEeQIuAlqQRcE6pA6tdNf83thbYRszwC nl9saxVwU5m2y3Wb7TbFBwLOBwJ2BCkCXpJCwK4KoEnAvkonpoKJ3V9fAd+4dXtRsUBZsa1RwE1l uqmctxFwipiwBSxxIPHgAwH7QcCeIL36xZezT6c28+LhPS8PcunXV1GEKpDYympIAV+6dr06fnmt 2n1mtTpy8dLixxqpjCQSyCFgH10F3LcFnErAtVglFlav3fDWI+9fXUfACDiOM+vXFxImXa4Orp6v Htl/QJ2A+1RkfdKDz+2qXv/wo0WFQyozSXyPLeCYFnBTmdYm4KcOHflOvvWP0VBd0vWHDwKG2ZL6 EvQQLeCulU+fS9ByuU1awVQq82HMS9Bd4iJHC1ioW8HS0oX2IGDwkusesOZL0GYnrK82NigkM0HT PeA+Ak4RE65OWMRCNxAweBmyF7Tr0ltsRWOv06XyoRc0tEFTL+imsuxbzoyxPrHQthc0+EHA4IWR sBAwLJnCSFhCjueAwQ8CBi8IGAHDEgSMgIcAAYMXBIyAYQljQSPggUDA4AYBI2BYgoAR8EAgYHCD gBEwLEHACHggEDC4QcAIGJYgYAQ8EAgY3CBgBAxLEDACHggEDG4QMAKGJQgYAQ8EAgY3CBgBwxIE jIAHAgGDGwSMgGEJAkbAA4GAwQ0CTivglZUVb6o/14z24xsSBIyAh4CBOMALAh6uBVyizBAwAkbA aUHA4AUBjytg8z2zVWy/b69rt6Tt9UPH4FvPdxxzlTACRsBDgIDBCwLOK+Cm167t+MTdtP+m7fmO eS4gYAQ8BAgYvCDg/C3gptex7zftHwGHQcAIeAgQMHhBwGUIuEuHLgTcDgSMgIcAAYMXEfB//P4P CwmT9lQ/ffLp6uYXXybJ26FawKHtd9keAl7y0uvHqgd2Pp+9DP72wKHq4T0vZz2GB597oXp8734q yAQgYAgiEs6d3v3wo0XKfRxr6+vJ8pVL0GVx6/ZtFbGw+8xqderS5ezHwfPwaUDAoJ4jFy8t0pRI JeD6/6bezL5jaOpV3dQDG8ZFBHw10VUYyA8CBtVcufnXRaUjSf4HmDMIeHIgYNDLyU+vVvvOnq9e Wb2w+B9gziDgyYGAQTdvXLpcnfj4EzICZg8CnhwIGHSDgAGWIODJgYBBNwgYYAkCnhwIGHSDgAGW IODJgYBBNwgYYAkCnhwIGHSDgAGWIODJgYBBNwgYYAkCnhwIGHTz5kdXvhuMg0Sae0LAkwIBg24+ v/1VdfrqNRJp9unM+vVq484dKoXpgIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAy gIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIAB AAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAy gIABAAAygIABAAAygIABAAAygIABAAAygIABAAAygIABAAAysBDwP26mAyQSiUQikUZL//z/jsaj DIB8M2MAAAAASUVORK5CYII= ------_=_NextPart_001_01CA613B.4596C810-- From pthubert@cisco.com Mon Nov 9 04:52:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5549A3A6AF6 for ; Mon, 9 Nov 2009 04:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, 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 ypZVVsqO-Ahs for ; Mon, 9 Nov 2009 04:52:17 -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 1A9E03A6A78 for ; Mon, 9 Nov 2009 04:52:17 -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: ArUEAHuf90qrR7Ht/2dsb2JhbACCJSzCdZZThD4EjAs X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="48596204" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2009 12:52:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CqgFd000984; Mon, 9 Nov 2009 12:52:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:52:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA613B.85D58254" Date: Mon, 9 Nov 2009 13:52:35 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] need clarification: DIS processing Thread-Index: Acpb3gHKg5inE4o1QSGH0K3LaI8ZcwFXRHGQ References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 12:52:41.0256 (UTC) FILETIME=[85FF8280:01CA613B] Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:52:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA613B.85D58254 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the moment, I cannot figure when an immediate response would be needed.=20 =20 I think Phil mentions that somewhere else as well. The idea would be to arm trickle and let it time out. =20 Also let us keep in mind that in networking at large, most timers are jittered to avoid network synchronizations. In wireless, it is even worse since as you point out, synchronization also means collisions. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: lundi 2 novembre 2009 18:01 To: ROLL WG Subject: [Roll] need clarification: DIS processing =20 Hi all, =20 one question: when a router receives a DIS, should it answer right away? I guess this is a good source of collision, so a random timer would help. Could we set T to a random value between I_min /2 and I_Min, without resetting I (receiving a DIS does not mean inconsistency)? =20 Best, Julien ------_=_NextPart_001_01CA613B.85D58254 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the moment, I cannot figure when an immediate response = would be needed.

 

I think Phil mentions that somewhere else as well. The = idea would be to arm trickle and let it time out.

 

Also let us keep in mind that in networking at large, = most timers are jittered to avoid network synchronizations. In wireless, it = is even worse since as you point out, synchronization also means = collisions.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: lundi 2 novembre 2009 18:01
To: ROLL WG
Subject: [Roll] need clarification: DIS = processing

 

Hi all,

 

one question:

when a router receives a DIS, should it answer right away? I guess this is a = good source of collision, so a random timer would help. Could we set T to a = random value between I_min /2 and I_Min, without resetting I (receiving a = DIS does not mean inconsistency)?

 

Best,<= o:p>

Julien=

------_=_NextPart_001_01CA613B.85D58254-- From pthubert@cisco.com Mon Nov 9 04:56:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE793A6A0D for ; Mon, 9 Nov 2009 04:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.723 X-Spam-Level: X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=0.876, 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 1-gWD4WdDyy9 for ; Mon, 9 Nov 2009 04:56:13 -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 35B003A6998 for ; Mon, 9 Nov 2009 04:56:13 -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: Ak0AAOKg90qQ/uCWe2dsb2JhbACbegEBFiQGqRCWU4IzggsEgWg X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53956262" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:56:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CuQMe018165 for ; Mon, 9 Nov 2009 12:56:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:56:26 +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, 9 Nov 2009 13:56:23 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphLhFk8yC/YGPRRcufCNg1SDjVOgAAEkAQAAJsJCAAAPu/AA== References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Nov 2009 12:56:26.0132 (UTC) FILETIME=[0C08DD40:01CA613C] Cc: roll WG Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 12:56:14 -0000 Hi Julien: How do I form a network of game boys is my question.=20 Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 9 novembre 2009 13:34 >To: Pascal Thubert (pthubert); JP Vasseur (jvasseur) >Cc: roll WG >Subject: RE: [Roll] Ticket #10: Closed > >Hi Pascal, JP, > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Pascal Thubert (pthubert) >> Sent: lundi 9 novembre 2009 12:25 >> To: JP Vasseur (jvasseur) >> Cc: roll WG >> Subject: Re: [Roll] Ticket #10: Closed >> >> >> >Here is another way to look at it. You simply configure an >> OCP and all >> >nodes willing to participate to a DAG have to implement that >> same OCP. >> > >> Simply configure... >> >> In industrial, tools for doing that will certainly exist. >> What about game boys and McDo toys? Can't they do RPL? >> >> >> >If you mandate the use of an OCP like the OCP0, that also means that >> >ALL nodes MUST implement OCP0, even if they do not want to implement >> >that OCP. >> >> Yes, that was the goal. Making it fairly simple but >> implemented in every node so if I buy something from brand A >> and something from brand B, I'm sure there's at least one OCP >> that both implement. >> >The root has to be configured. If it sends OCPx in the DIO, the game boy will join as a leaf anyway > >Again, I do not think this is worth extra code on a node. > >> Doesn't that scare you that we allow for 2 RPL-compliant >> nodes to be by design unable to talk together whatever the >> way we configure them? >> >> > >> >In other words, this is a trivial implementation issue easy to fix: >> >specify the OCP to use >> >on the node. >> >> The OCP must be implemented in the node first. There's code >> associated to it. >> >> It makes sense that an implementation should have a mechanism >> to add more OCPs over time, and that's what I indicated by >> calling OCPs plug-ins. >> >> Pascal >> >> >> > >> >> Is that really what this group wants? >> >> >> >> Pascal >> >> >> >>> -----Original Message----- >> >>> From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf >> >>> Of >> >> JP Vasseur (jvasseur) >> >>> Sent: lundi 9 novembre 2009 11:59 >> >>> To: roll WG >> >>> Subject: Re: [Roll] Ticket #10: Closed >> >>> >> >>> So here is the plan for rev-5. >> >>> >> >>> First OCP0 will be removed from the core specification. There will >> no >> >>> longer be any requirement >> >>> for a node to support OCP0. Various OCPs will be defined >> in separate >> >>> drafts and each node will be provisioned to support one >> or more OCPs >> >>> >> >>> If a node receives a DIO referring to an OCP that it does not >> >>> support/ understand, it may join the DAG as a leaf and log the >> >>> issue. >> >>> >> >>> In the absence of comments, we will update rev-05 accordingly. >> >>> >> >>> Thanks. >> >>> >> >>> JP. >> >>> >> >>> On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: >> >>> >> >>>> Strong consensus towards Option 1. >> >>>> >> >>>> This closes the ticket #10 and will be reflected in rev-05. >> >>>> >> >>>> Thanks. >> >>>> >> >>>> JP. >> >>>> >> >>>> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: >> >>>> >> >>>>> Dear all, >> >>>>> >> >>>>> /co-chair hat off/ >> >>>>> >> >>>>> We would welcome your opinion on the following issue: >> >>>>> >> >>>>> Suppose that a DAG is formed that support OFx. A new >> node willing >> >>>>> to join the DAG does not support OFx but OFy. Note that >> by OF we >> >>>>> actually mean the Objective function and the metric. >> >>>>> >> >>>>> We have two options here. >> >>>>> >> >>>>> Option 1: The node simply joins the DAG as a leaf. In >> order words, >> >>>>> the node has connectivity since it joins the DAG but >> will not act >> >>>>> as a router for others since it does not understand the >> OF. Parent >> >>>>> selection could be a simply a "random". >> >>>>> >> >>>>> Option 2: The node joins the DAG and falls back to the "default" >> >>>>> OCP. From there is prolongs the DAG but with OF0 (of course >> >>>>> inconsistent metrics are not added). This also means that >> everynode >> >>>>> MUST implement OF0 and that the network may compromise >> nodes with >> >>>>> different OF at some point. Several options even more >> complex have >> >>>>> been discussed where one could use common denominator to get as >> >>>>> close as possible to the desired OF, allow a node not to be so >> >>>>> "altruistic", ... >> >>>>> >> >>>>> My personal view is that OF management can quick get fairly >> complex >> >>>>> and hard to manage. Option 1 is extremely simple and easy to >> >>>>> manage. If a node is mis-configured (does not support the OF of >> the >> >>>>> DAG) it can join it as a leaf in order to have connectivity and >> >>>>> send an alarm to fix its configuration. We now just need to >> specify >> >>>>> OF in some document and this is it. >> >>>>> >> >>>>> Several of you mentioned that they were leaning toward >> option 1, >> >>>>> but could you please express your opinion, we would like to have >> it >> >>>>> solved for the next revision next week. >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> JP. >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Roll mailing list >> >>>>> Roll@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/roll >> >>>> >> >>>> _______________________________________________ >> >>>> Roll mailing list >> >>>> Roll@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/roll >> >>> >> >>> _______________________________________________ >> >>> 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 jabeille@cisco.com Mon Nov 9 04:57:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C09228C111 for ; Mon, 9 Nov 2009 04:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwA9llX8rp0X for ; Mon, 9 Nov 2009 04:57:05 -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 85C4D28C10E for ; Mon, 9 Nov 2009 04:57:04 -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: AlkAAOKg90qQ/uCWe2dsb2JhbACCJishmQgBARYkBqkQllMChDwE X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208,217";a="53956433" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 12:57:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9CvT4U018633 for ; Mon, 9 Nov 2009 12:57:29 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:57:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA613C.31A45AC4" Date: Mon, 9 Nov 2009 13:57:27 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcpceQdszzwwqAwyQCeb8RdlCV5REwEwBGBwAACXDRA= References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "JP Vasseur (jvasseur)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 09 Nov 2009 12:57:29.0305 (UTC) FILETIME=[31B04C90:01CA613C] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:57:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA613C.31A45AC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 just to be sure I understand:=20 - I have a preferred parent at rank 1, my rank is 5, I receive a DIO for = a parent rank 2, must i ignore it? I would say no as this node is useful = as backup parent, but if i lose my preferred parent, choosing the backup = as preferred will make my rank increase (this is ok because if i compute = rank based on all parents, I would have to increase rank at reception of = the second DIO anyway) - At boot time, I receive two DIOs (rank 1 and 2) before computing OCP. = If I calculate rank based on preferred only, if at some point I would = like to switch to the other parent, I will have to move down. =20 Still I think it is preferable to calculate rank based on preferred = only, but what do other think? Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: lundi 9 novembre 2009 13:39 To: JP Vasseur (jvasseur); Mathilde Durvy (mdurvy) Cc: roll Subject: Re: [Roll] Clarification on the objective function =09 =09 Hi Mathilde, =20 If that parent is preferred, it is probably because that's where most = of the traffic should land. This is why rank and metrics are expected to be propagated from that of = that preferred parent. =20 Allowing other parents to impact the rank is opening the door to = greediness. So we picked the simple path of accepting parents that are = upwards once the rank is selected from the honest-to-God preferred = parent. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur (jvasseur) Sent: mardi 3 novembre 2009 12:30 To: Mathilde Durvy (mdurvy) Cc: roll Subject: Re: [Roll] Clarification on the objective function =20 Hi, =20 On Nov 3, 2009, at 11:28 AM, Mathilde Durvy (mdurvy) wrote: =09 =09 =09 Hi All, =20 Section 5.9.1 says "When the scan is complete, the preferred parent is elected and self's rank is computed as the preferred parent rank plus the = step in rank with that parent." Does this mean that the rank of a node is only based on the rank of its = most preferred parent? Shouldn't the rank of the node also depend on the non-preferred = parents? Or is it assumed that the node always forward traffic via its most = preferred parent?=20 =20 A node may indeed choose to send traffic to an alternate parent and not = the most preferred. But do you think that this should change the way its computes its rank = ? =20 JP. =09 =09 =09 =20 Best, Mathilde =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you = print. Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =09 =09 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA613C.31A45AC4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
just to be sure I = understand: 
- I have a preferred parent at rank 1, my rank = is 5, I=20 receive a DIO for a parent rank 2, must i ignore it? I would say no as = this node=20 is useful as backup parent, but if i lose my preferred parent, choosing = the=20 backup as preferred will make my rank increase (this is ok because if i = compute=20 rank based on all parents, I would have to increase rank at reception of = the=20 second DIO anyway)
- At boot time, I receive two DIOs (rank 1 and = 2) before=20 computing OCP. If I calculate rank based on preferred only, if at some=20 point I would like to switch to the other parent, I will have to = move=20 down.
 
Still I think it is preferable to calculate = rank based=20 on preferred only, but what do other think?
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert=20 (pthubert)
Sent: lundi 9 novembre 2009 13:39
To: = JP=20 Vasseur (jvasseur); Mathilde Durvy (mdurvy)
Cc:=20 roll
Subject: Re: [Roll] Clarification on the objective=20 function

Hi=20 Mathilde,

 

If=20 that parent is preferred, it is probably because that=92s where most = of the=20 traffic should land.

This=20 is why rank and metrics are expected to be propagated from that of = that=20 preferred parent.

 

Allowing=20 other parents to impact the rank is opening the door to greediness. So = we=20 picked the simple path of accepting parents that are upwards once the = rank is=20 selected from the honest-to-God preferred = parent.

 

Pascal

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP=20 Vasseur (jvasseur)
Sent: mardi 3 novembre 2009 = 12:30
To:=20 Mathilde Durvy (mdurvy)
Cc: roll
Subject: Re: = [Roll]=20 Clarification on the objective = function

 

Hi,

 

On Nov 3, 2009, at 11:28 AM, Mathilde Durvy = (mdurvy)=20 wrote:



Hi = All,

 

Section 5.9.1=20 says

    =20 "When the scan is complete, the preferred parent is elected=20 and
      self's rank is computed as the = preferred=20 parent rank plus the step
      in rank = with that=20 parent."
Does = this mean=20 that the rank of a node is only based on the rank of its most = preferred=20 parent?

Shouldn't = the rank=20 of the node also depend on the non-preferred parents?

Or is it = assumed=20 that the node always forward traffic via its most preferred=20 parent? 

 

A node may indeed choose to send traffic to an = alternate=20 parent and not the most preferred.

But do you think that this should change the way = its=20 computes its rank ?

 

JP.



 

Best,

Mathilde

 

 Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822=20 1725
Mobile: +41 76 396=20 8116

Cisco=20 Systems International S=E0rl
Av.=20 des Uttins, 5
CH-1180 Rolle

Cisco=20 home page

 

 

Think before you=20 print.

This=20 e-mail may contain confidential and privileged material = for the=20 sole use of the intended recipient. Any review, use, = distribution=20 or disclosure by others is strictly prohibited. If you are = not the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this=20 = message.


 

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

 

------_=_NextPart_001_01CA613C.31A45AC4-- From jabeille@cisco.com Mon Nov 9 05:01:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68A23A67FC for ; Mon, 9 Nov 2009 05:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.915 X-Spam-Level: X-Spam-Status: No, score=-9.915 tagged_above=-999 required=5 tests=[AWL=0.684, 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 zmIVBSElEdJ3 for ; Mon, 9 Nov 2009 05:01:17 -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 DACDD3A67E9 for ; Mon, 9 Nov 2009 05:01:16 -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: Ak0AAA+i90qQ/uCWe2dsb2JhbACbegEBFiQGqSKWU4IzggsEgWg X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53957037" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 13:01:30 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9D1TlL020282 for ; Mon, 9 Nov 2009 13:01:29 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:01:30 +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, 9 Nov 2009 14:01:27 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphLhFk8yC/YGPRRcufCNg1SDjVOgAAEkAQAAJsJCAAAPu/AAAAFcUA References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 09 Nov 2009 13:01:30.0050 (UTC) FILETIME=[C12F1220:01CA613C] Cc: roll WG Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 13:01:18 -0000 Just game boys would all support the same OCP. Game boy + PSP may indeed not support the same one.=20 For me this is interop, and does not happen by magic. People that want their device to interoperate have to check they implement the same things. Otherwise IETF ends up mandating that all device implement the same OCP, same instance, as well as the same transport, the same application layer protocol, the same application, same security, the same data structures.... For me this is the role of an application specific SDO/Forum. Best, Julien > -----Original Message----- > From: Pascal Thubert (pthubert)=20 > Sent: lundi 9 novembre 2009 13:56 > To: Julien Abeille (jabeille); JP Vasseur (jvasseur) > Cc: 'roll WG' > Subject: RE: [Roll] Ticket #10: Closed >=20 > Hi Julien: >=20 > How do I form a network of game boys is my question.=20 >=20 > Pascal >=20 > >-----Original Message----- > >From: Julien Abeille (jabeille) > >Sent: lundi 9 novembre 2009 13:34 > >To: Pascal Thubert (pthubert); JP Vasseur (jvasseur) > >Cc: roll WG > >Subject: RE: [Roll] Ticket #10: Closed > > > >Hi Pascal, JP, > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf=20 > >> Of Pascal Thubert (pthubert) > >> Sent: lundi 9 novembre 2009 12:25 > >> To: JP Vasseur (jvasseur) > >> Cc: roll WG > >> Subject: Re: [Roll] Ticket #10: Closed > >> > >> > >> >Here is another way to look at it. You simply configure an > >> OCP and all > >> >nodes willing to participate to a DAG have to implement that > >> same OCP. > >> > > >> Simply configure... > >> > >> In industrial, tools for doing that will certainly exist. > >> What about game boys and McDo toys? Can't they do RPL? > >> > >> > >> >If you mandate the use of an OCP like the OCP0, that also=20 > means that=20 > >> >ALL nodes MUST implement OCP0, even if they do not want=20 > to implement=20 > >> >that OCP. > >> > >> Yes, that was the goal. Making it fairly simple but implemented in=20 > >> every node so if I buy something from brand A and something from=20 > >> brand B, I'm sure there's at least one OCP that both implement. > >> > >The root has to be configured. If it sends OCPx in the DIO, the game=20 > >boy will join as a leaf anyway > > > >Again, I do not think this is worth extra code on a node. > > > >> Doesn't that scare you that we allow for 2 RPL-compliant=20 > nodes to be=20 > >> by design unable to talk together whatever the way we=20 > configure them? > >> > >> > > >> >In other words, this is a trivial implementation issue=20 > easy to fix: > >> >specify the OCP to use > >> >on the node. > >> > >> The OCP must be implemented in the node first. There's code=20 > >> associated to it. > >> > >> It makes sense that an implementation should have a=20 > mechanism to add=20 > >> more OCPs over time, and that's what I indicated by calling OCPs=20 > >> plug-ins. > >> > >> Pascal > >> > >> > >> > > >> >> Is that really what this group wants? > >> >> > >> >> Pascal > >> >> > >> >>> -----Original Message----- > >> >>> From: roll-bounces@ietf.org > >> [mailto:roll-bounces@ietf.org] On Behalf > >> >>> Of > >> >> JP Vasseur (jvasseur) > >> >>> Sent: lundi 9 novembre 2009 11:59 > >> >>> To: roll WG > >> >>> Subject: Re: [Roll] Ticket #10: Closed > >> >>> > >> >>> So here is the plan for rev-5. > >> >>> > >> >>> First OCP0 will be removed from the core specification. There=20 > >> >>> will > >> no > >> >>> longer be any requirement > >> >>> for a node to support OCP0. Various OCPs will be defined > >> in separate > >> >>> drafts and each node will be provisioned to support one > >> or more OCPs > >> >>> > >> >>> If a node receives a DIO referring to an OCP that it does not=20 > >> >>> support/ understand, it may join the DAG as a leaf and log the=20 > >> >>> issue. > >> >>> > >> >>> In the absence of comments, we will update rev-05 accordingly. > >> >>> > >> >>> Thanks. > >> >>> > >> >>> JP. > >> >>> > >> >>> On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote: > >> >>> > >> >>>> Strong consensus towards Option 1. > >> >>>> > >> >>>> This closes the ticket #10 and will be reflected in rev-05. > >> >>>> > >> >>>> Thanks. > >> >>>> > >> >>>> JP. > >> >>>> > >> >>>> On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote: > >> >>>> > >> >>>>> Dear all, > >> >>>>> > >> >>>>> /co-chair hat off/ > >> >>>>> > >> >>>>> We would welcome your opinion on the following issue: > >> >>>>> > >> >>>>> Suppose that a DAG is formed that support OFx. A new > >> node willing > >> >>>>> to join the DAG does not support OFx but OFy. Note that > >> by OF we > >> >>>>> actually mean the Objective function and the metric. > >> >>>>> > >> >>>>> We have two options here. > >> >>>>> > >> >>>>> Option 1: The node simply joins the DAG as a leaf. In > >> order words, > >> >>>>> the node has connectivity since it joins the DAG but > >> will not act > >> >>>>> as a router for others since it does not understand the > >> OF. Parent > >> >>>>> selection could be a simply a "random". > >> >>>>> > >> >>>>> Option 2: The node joins the DAG and falls back to=20 > the "default" > >> >>>>> OCP. From there is prolongs the DAG but with OF0 (of course=20 > >> >>>>> inconsistent metrics are not added). This also means that > >> everynode > >> >>>>> MUST implement OF0 and that the network may compromise > >> nodes with > >> >>>>> different OF at some point. Several options even more > >> complex have > >> >>>>> been discussed where one could use common=20 > denominator to get as=20 > >> >>>>> close as possible to the desired OF, allow a node=20 > not to be so=20 > >> >>>>> "altruistic", ... > >> >>>>> > >> >>>>> My personal view is that OF management can quick get fairly > >> complex > >> >>>>> and hard to manage. Option 1 is extremely simple and easy to=20 > >> >>>>> manage. If a node is mis-configured (does not=20 > support the OF of > >> the > >> >>>>> DAG) it can join it as a leaf in order to have=20 > connectivity and=20 > >> >>>>> send an alarm to fix its configuration. We now just need to > >> specify > >> >>>>> OF in some document and this is it. > >> >>>>> > >> >>>>> Several of you mentioned that they were leaning toward > >> option 1, > >> >>>>> but could you please express your opinion, we would like to=20 > >> >>>>> have > >> it > >> >>>>> solved for the next revision next week. > >> >>>>> > >> >>>>> Thanks. > >> >>>>> > >> >>>>> JP. > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> Roll mailing list > >> >>>>> Roll@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/roll > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Roll mailing list > >> >>>> Roll@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/roll > >> >>> > >> >>> _______________________________________________ > >> >>> Roll mailing list > >> >>> Roll@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/roll > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> >=20 From mcr@marajade.sandelman.ca Mon Nov 9 06:42:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623DA3A692E for ; Mon, 9 Nov 2009 06:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.900, 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 EcTq1B658UKN for ; Mon, 9 Nov 2009 06:42:07 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8EA6A3A63C9 for ; Mon, 9 Nov 2009 06:42:07 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id A5CF9342DA for ; Mon, 9 Nov 2009 09:33:30 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 8D7A34E791 for ; Mon, 9 Nov 2009 09:42:31 -0500 (EST) From: Michael Richardson To: roll WG In-Reply-To: References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 09 Nov 2009 09:42:31 -0500 Message-ID: <6635.1257777751@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 14:42:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Julien" == Julien Abeille <(jabeille)" > writes: Julien> Just game boys would all support the same OCP. Game boy + Julien> PSP may indeed not support the same one. For me this is Julien> interop, and does not happen by magic. People that want Julien> their device to interoperate have to check they implement Julien> the same things. Otherwise IETF ends up mandating that all Julien> device implement the same OCP, same instance, as well as the Julien> same transport, the same application layer protocol, the Julien> same application, same security, the same data Julien> structures.... Yes, that's certainly true. It is a good, not a bad. And if done correctly, interop does happen by magic. You are reading this email, because email was standardized. It did not need to be standardized for technical discussion seperately from being standardized for use with close relatives. The precise profile of what is MUST, and what is MAY, is sometimes delegated to other documents, but the base specification should not have dozens of options if we expect to get anywhere. >> How do I form a network of game boys is my question. You have to use OCP0. We have to specify that. The document will likely want to say SHOULD for it. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvgqVYCLcPvd0N1lAQL9xgf7BR/WMiVbwCZTwMBfRC66LSNEcMac4WfM LzBCkupWl7HCiyf9oJ0kOIqUaYbTIK5tRItEuaW1LiqKEZksWr4Gxsel3EyTgodL aMwbzoBmxheUdmvQiqMTJnoIYB9A2uZfAb2D36z8JLjWV/IGy9Ijze7sVdExe1s2 1Yl5ZHGKbPwcYOU5meAWaLNmVjPNTNjd+mtyS1SGUkEYTWgDK4ydCdJ9anqd2gfF 5M0Vkr2zgaYVbn0l6t6Ni3KC6eQ0wcoSP9hB8LaT26lEx3Vo/Hr/eucbR8QoGhxb g/wS1kxTVO9pINjMklEeD5sGg0lRnztsl8MCBN0D8wtF4VkLGS6xuw== =aI9Q -----END PGP SIGNATURE----- From trac@tools.ietf.org Mon Nov 9 07:49:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786593A697B for ; Mon, 9 Nov 2009 07:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSsMzR-AUguR for ; Mon, 9 Nov 2009 07:49:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id CDC9A3A6863 for ; Mon, 9 Nov 2009 07:49:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7WUn-0005j1-4N; Mon, 09 Nov 2009 07:49:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 09 Nov 2009 15:49:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/8#comment:1 Message-ID: <064.77855f1c69a5cd04653a385feb5dd242@tools.ietf.org> References: <055.589c0f057f2d5ff596a835659492169c@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <055.589c0f057f2d5ff596a835659492169c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #8: DIO Option Lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:49:09 -0000 #8: DIO Option Lenght --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Email From Tim Winter For now then we should leave the text unchanged for -05. Perhaps we may revisit this later when we have more basis to optimize. Thanks, -Tim -- Ticket URL: roll From jabeille@cisco.com Mon Nov 9 09:21:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006383A687D for ; Mon, 9 Nov 2009 09:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.78 X-Spam-Level: X-Spam-Status: No, score=-8.78 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_YOUR=2.3, 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 iFvdg+0d40HB for ; Mon, 9 Nov 2009 09:21:18 -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 5CDDD3A6403 for ; Mon, 9 Nov 2009 09:21:17 -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: Ak8AAMTe90qQ/uCWe2dsb2JhbACCJSyZKgEBFiQGqm2Wc4Q+BIwL X-IronPort-AV: E=Sophos;i="4.44,709,1249257600"; d="scan'208,217";a="53987542" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 17:21:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9HLUB7014230; Mon, 9 Nov 2009 17:21:30 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 18:21:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6161.136D723C" Date: Mon, 9 Nov 2009 18:21:27 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] need clarification: DIS processing Thread-Index: Acpb3gHKg5inE4o1QSGH0K3LaI8ZcwFXRHGQAAlFvjA= References: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 17:21:30.0378 (UTC) FILETIME=[13B436A0:01CA6161] Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 17:21:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6161.136D723C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable of course it needs jitter. Now trickle is armed anyway at all times right (T timer). If we do not do anything specific, the DIO will not come earlier with DIS than without... So if no immediate response is needed, then DIS is not needed. I still think it is, for instance anytime you lose you r last parent, and do not want to wait possibly hours to get a DIO. This is the same as with RS/RA (jittered !) =20 Resetting trickle (I to Imin, and T to random ) does not make sense I guess, as sending a DIS does not always mean global instability. Thoughts on how to arm a small jittered timer? =20 Best, Julien ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 9 novembre 2009 13:53 To: Julien Abeille (jabeille); Philip Levis Cc: ROLL WG Subject: RE: [Roll] need clarification: DIS processing =09 =09 At the moment, I cannot figure when an immediate response would be needed.=20 =20 I think Phil mentions that somewhere else as well. The idea would be to arm trickle and let it time out. =20 Also let us keep in mind that in networking at large, most timers are jittered to avoid network synchronizations. In wireless, it is even worse since as you point out, synchronization also means collisions. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: lundi 2 novembre 2009 18:01 To: ROLL WG Subject: [Roll] need clarification: DIS processing =20 Hi all, =20 one question: when a router receives a DIS, should it answer right away? I guess this is a good source of collision, so a random timer would help. Could we set T to a random value between I_min /2 and I_Min, without resetting I (receiving a DIS does not mean inconsistency)? =20 Best, Julien ------_=_NextPart_001_01CA6161.136D723C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
of course it needs jitter. Now trickle is armed = anyway at=20 all times right (T timer). If we do not do anything specific, the DIO = will not=20 come earlier with DIS than without...
So if no immediate response is needed, then DIS = is not=20 needed. I still think it is, for instance anytime you lose you r last = parent,=20 and do not want to wait possibly hours to get a DIO. This is the same as = with=20 RS/RA (jittered !)
 
Resetting trickle (I to Imin, and T to random ) = does not=20 make sense I guess, as sending a DIS does not always mean global = instability.=20 Thoughts on how to arm a small jittered timer?
 
Best,
Julien

From: Pascal Thubert (pthubert)=20
Sent: lundi 9 novembre 2009 13:53
To: Julien = Abeille=20 (jabeille); Philip Levis
Cc: ROLL WG
Subject: RE: = [Roll]=20 need clarification: DIS processing

At=20 the moment, I cannot figure when an immediate response would be = needed.=20

 

I=20 think Phil mentions that somewhere else as well. The idea would be to = arm=20 trickle and let it time out.

 

Also=20 let us keep in mind that in networking at large, most timers are = jittered to=20 avoid network synchronizations. In wireless, it is even worse since as = you=20 point out, synchronization also means = collisions.

 

Pascal

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Julien Abeille (jabeille)
Sent: lundi 2 novembre 2009=20 18:01
To: ROLL WG
Subject: [Roll] need = clarification: DIS=20 processing

 

Hi=20 all,

 

one=20 question:

when a = router=20 receives a DIS, should it answer right away? I guess this is a good = source of=20 collision, so a random timer would help. Could we set T to a random = value=20 between I_min /2 and I_Min, without resetting I (receiving a DIS = does not=20 mean inconsistency)?

 

Best,

Julien

------_=_NextPart_001_01CA6161.136D723C-- From jabeille@cisco.com Mon Nov 9 09:27:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A513A6847 for ; Mon, 9 Nov 2009 09:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.92 X-Spam-Level: X-Spam-Status: No, score=-9.92 tagged_above=-999 required=5 tests=[AWL=0.679, 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 VfxeXq0A8MlB for ; Mon, 9 Nov 2009 09:27:56 -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 4D8413A67B2 for ; Mon, 9 Nov 2009 09:27:56 -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: Ak0AACrg90qQ/uCWe2dsb2JhbACbewEBFiQGqnyJQo03gjOCCwSBaA X-IronPort-AV: E=Sophos;i="4.44,710,1249257600"; d="scan'208";a="53988108" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 17:28:21 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9HSLxR015940; Mon, 9 Nov 2009 17:28:21 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 18:28:21 +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, 9 Nov 2009 18:28:19 +0100 Message-ID: In-Reply-To: <6635.1257777751@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #10: Closed Thread-Index: AcphSuQXfeRoPbMCTjqSFVIk5TKaTQAFlamA References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> <6635.1257777751@marajade.sandelman.ca> From: "Julien Abeille (jabeille)" To: "Michael Richardson" , "roll WG" X-OriginalArrivalTime: 09 Nov 2009 17:28:21.0765 (UTC) FILETIME=[08E8E350:01CA6162] Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 17:27:57 -0000 Hi Michael,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Michael Richardson > Sent: lundi 9 novembre 2009 15:43 > To: roll WG > Subject: Re: [Roll] Ticket #10: Closed >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > >>>>> "Julien" =3D=3D Julien Abeille <(jabeille)"=20 > > writes: > Julien> Just game boys would all support the same OCP. Game boy + > Julien> PSP may indeed not support the same one. For me this is > Julien> interop, and does not happen by magic. People that want > Julien> their device to interoperate have to check they implement > Julien> the same things. Otherwise IETF ends up mandating that all > Julien> device implement the same OCP, same instance, as=20 > well as the > Julien> same transport, the same application layer protocol, the > Julien> same application, same security, the same data > Julien> structures....=20 >=20 > Yes, that's certainly true. It is a good, not a bad. >=20 > And if done correctly, interop does happen by magic. > You are reading this email, because email was standardized. =20 Well I am reading this email because I have a laptop that supports a bunch of RFCs, and bunch of email standards.=20 So I guess we disagree on benefits vs costs. And again if the root does not send OCP0, the game boy having OCP0 is useless. Are we trying to solve an adhoc network problem? Do the requirements drafts and RFCs require this kind of scenario? Best, Julien=20 > It did not need to be standardized for technical discussion=20 > seperately from being standardized for use with close relatives. >=20 > The precise profile of what is MUST, and what is MAY, is=20 > sometimes delegated to other documents, but the base=20 > specification should not have dozens of options if we expect=20 > to get anywhere. >=20 > >> How do I form a network of game boys is my question. >=20 > You have to use OCP0. We have to specify that. > The document will likely want to say SHOULD for it. >=20 > - --=20 > ] He who is tired of Weird Al is tired of life! =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video=20 > > then sign the petition.=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys >=20 > iQEVAwUBSvgqVYCLcPvd0N1lAQL9xgf7BR/WMiVbwCZTwMBfRC66LSNEcMac4WfM > LzBCkupWl7HCiyf9oJ0kOIqUaYbTIK5tRItEuaW1LiqKEZksWr4Gxsel3EyTgodL > aMwbzoBmxheUdmvQiqMTJnoIYB9A2uZfAb2D36z8JLjWV/IGy9Ijze7sVdExe1s2 > 1Yl5ZHGKbPwcYOU5meAWaLNmVjPNTNjd+mtyS1SGUkEYTWgDK4ydCdJ9anqd2gfF > 5M0Vkr2zgaYVbn0l6t6Ni3KC6eQ0wcoSP9hB8LaT26lEx3Vo/Hr/eucbR8QoGhxb > g/wS1kxTVO9pINjMklEeD5sGg0lRnztsl8MCBN0D8wtF4VkLGS6xuw=3D=3D > =3DaI9Q > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pal@cs.stanford.edu Mon Nov 9 09:47:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B366628C1BB for ; Mon, 9 Nov 2009 09:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, 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 umfPHR2hHjJQ for ; Mon, 9 Nov 2009 09:47:47 -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 10A1E28C0DF for ; Mon, 9 Nov 2009 09:47:47 -0800 (PST) Received: from dnab42207f.stanford.edu ([171.66.32.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N7YLd-0002e6-Dk; Mon, 09 Nov 2009 09:48:13 -0800 Message-Id: From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 09:00:05 -0800 References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:47:47 -0000 On Nov 9, 2009, at 4:57 AM, Julien Abeille (jabeille) wrote: > Hi Pascal, > > just to be sure I understand: > - I have a preferred parent at rank 1, my rank is 5, I receive a DIO > for a parent rank 2, must i ignore it? I would say no as this node > is useful as backup parent, but if i lose my preferred parent, > choosing the backup as preferred will make my rank increase (this is > ok because if i compute rank based on all parents, I would have to > increase rank at reception of the second DIO anyway) > - At boot time, I receive two DIOs (rank 1 and 2) before computing > OCP. If I calculate rank based on preferred only, if at some point I > would like to switch to the other parent, I will have to move down. > > Still I think it is preferable to calculate rank based on preferred > only, but what do other think? > Julien Julien, Question 1: In -04, you MUST process the DIO. Section 5.4.2.1: If the rank of SRC as reported in the DIO message is lesser than that of the node within the DAG, then the DIO message MUST be considered for further processing Question 2: The draft is unclear. Phil From pal@cs.stanford.edu Mon Nov 9 09:47:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206A028C0DF for ; Mon, 9 Nov 2009 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 62LAC+sGbtdy for ; Mon, 9 Nov 2009 09:47:50 -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 6102228C1D5 for ; Mon, 9 Nov 2009 09:47:50 -0800 (PST) Received: from dnab42207f.stanford.edu ([171.66.32.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N7YLg-0002e6-TV; Mon, 09 Nov 2009 09:48:17 -0800 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D95FE68@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 09:01:55 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FE68@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 58355bea2820b4cf9b9c8322cdf0b49d Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 17:47:51 -0000 On Nov 9, 2009, at 4:12 AM, Pascal Thubert (pthubert) wrote: > Hi Julien: > > For me a validation is at least a bidir. NUD is a revalidation. There are no Held-up or Held-down states in -04. So this figure is incorrect. Phil From pal@cs.stanford.edu Mon Nov 9 09:47:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7F128C1E5 for ; Mon, 9 Nov 2009 09:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 OyMyXmnD7mQT for ; Mon, 9 Nov 2009 09:47:54 -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 2D61028C1D0 for ; Mon, 9 Nov 2009 09:47:54 -0800 (PST) Received: from dnab42207f.stanford.edu ([171.66.32.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N7YLk-0002e6-O7; Mon, 09 Nov 2009 09:48:20 -0800 Message-Id: <9E09DD5C-45C5-4EC9-9299-16046A9D57A9@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 09:12:26 -0800 References: <4AF5C26A.30408@acm.org> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: ROLL WG Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 17:47:55 -0000 On Nov 9, 2009, at 2:11 AM, Julien Abeille (jabeille) wrote: > Hi Tim, > > My question is: are there DAGs that are not DODAGs in RPL? My > feeling is > no. Hence I would suppress the DODAG instead of turning all "DAG" into > "DODAG". > Best, > Julien I disagree -- Directed Acyclic Graph is a very well defined term in graph theory. We shouldn't redefine it. A DODAG is a particular kind of DAG, where there is one and only one node which has only incoming edges. We could maybe come up with a better term than DODAG, but DAG definitely isn't it. It will confuse readers tremendously. Phil From jabeille@cisco.com Mon Nov 9 10:29:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0060B3A6934 for ; Mon, 9 Nov 2009 10:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 zq80Ay2G9rcB for ; Mon, 9 Nov 2009 10:29:41 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 396843A6923 for ; Mon, 9 Nov 2009 10:29:41 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADvu90qrR7H+/2dsb2JhbADHcpcChD4EjAs X-IronPort-AV: E=Sophos;i="4.44,710,1249257600"; d="scan'208";a="103170109" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2009 18:30:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9ITxKB019283; Mon, 9 Nov 2009 18:30:07 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:30:05 +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, 9 Nov 2009 19:30:04 +0100 Message-ID: In-Reply-To: <9E09DD5C-45C5-4EC9-9299-16046A9D57A9@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #5: DODAG Thread-Index: AcphZNuJSF7Z8lDGQAaRA5KILQIUKwAA4Gbw References: <4AF5C26A.30408@acm.org> <9E09DD5C-45C5-4EC9-9299-16046A9D57A9@cs.stanford.edu> From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 18:30:05.0779 (UTC) FILETIME=[A8AC9230:01CA616A] Cc: ROLL WG Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 18:29:42 -0000 Hi Phil, > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: lundi 9 novembre 2009 18:12 > To: Julien Abeille (jabeille) > Cc: Tim Winter; ROLL WG > Subject: Re: [Roll] [roll] #5: DODAG >=20 >=20 > On Nov 9, 2009, at 2:11 AM, Julien Abeille (jabeille) wrote: >=20 > > Hi Tim, > > > > My question is: are there DAGs that are not DODAGs in RPL?=20 > My feeling=20 > > is no. Hence I would suppress the DODAG instead of turning=20 > all "DAG"=20 > > into "DODAG". > > Best, > > Julien >=20 > I disagree -- Directed Acyclic Graph is a very well defined=20 > term in graph theory. We shouldn't redefine it. A DODAG is a=20 > particular kind of DAG, where there is one and only one node=20 > which has only incoming edges. We could maybe come up with a=20 > better term than DODAG, but DAG definitely isn't it. It will=20 > confuse readers tremendously. Sorry, did not want to hurt graph theory specialists among IETF draft readers.=20 Seriously, what is confusing is to have DAGs and DODAGs everywhere in the draft. An instance is not as far as I understand a DAG. An instance is multiple DODAGs. Hence either we use only DAG everywhere, or DODAG everywhere, no mention of DAG. Thoughts? Best, Julien >=20 > Phil >=20 From jabeille@cisco.com Mon Nov 9 10:32:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302CB3A6945 for ; Mon, 9 Nov 2009 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.921 X-Spam-Level: X-Spam-Status: No, score=-7.921 tagged_above=-999 required=5 tests=[AWL=-1.322, 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 xlhBGUGzFNSL for ; Mon, 9 Nov 2009 10:32:41 -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 5A1CA3A6774 for ; Mon, 9 Nov 2009 10:32:41 -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: ApoEACvv90qrR7Hu/2dsb2JhbADHW5cChD4EjAs X-IronPort-AV: E=Sophos;i="4.44,710,1249257600"; d="scan'208";a="48665669" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2009 18:33:07 +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 nA9IWrN3014609; Mon, 9 Nov 2009 18:33:07 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:32:55 +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, 9 Nov 2009 19:32:54 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcphZNQY/WRFX4aGTCeC38gVatwK/QABgsDA References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 18:32:55.0218 (UTC) FILETIME=[0DAAE920:01CA616B] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:32:42 -0000 Phil,=20 Are you in favor of computing rank based on all parents, or only preferred? Julien > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: lundi 9 novembre 2009 18:00 > To: Julien Abeille (jabeille) > Cc: Pascal Thubert (pthubert); JP Vasseur (jvasseur);=20 > Mathilde Durvy (mdurvy); roll > Subject: Re: [Roll] Clarification on the objective function >=20 >=20 > On Nov 9, 2009, at 4:57 AM, Julien Abeille (jabeille) wrote: >=20 > > Hi Pascal, > > > > just to be sure I understand: > > - I have a preferred parent at rank 1, my rank is 5, I=20 > receive a DIO=20 > > for a parent rank 2, must i ignore it? I would say no as=20 > this node is=20 > > useful as backup parent, but if i lose my preferred parent,=20 > choosing=20 > > the backup as preferred will make my rank increase (this is=20 > ok because=20 > > if i compute rank based on all parents, I would have to=20 > increase rank=20 > > at reception of the second DIO anyway) > > - At boot time, I receive two DIOs (rank 1 and 2) before computing=20 > > OCP. If I calculate rank based on preferred only, if at=20 > some point I=20 > > would like to switch to the other parent, I will have to move down. > > > > Still I think it is preferable to calculate rank based on preferred=20 > > only, but what do other think? > > Julien >=20 > Julien, >=20 > Question 1: In -04, you MUST process the DIO. Section 5.4.2.1: >=20 > If the rank of SRC as reported in the DIO message is lesser > than that of the node within the DAG, then the DIO=20 > message MUST > be considered for further processing >=20 > Question 2: The draft is unclear. >=20 > Phil >=20 From pal@cs.stanford.edu Mon Nov 9 10:50:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1363C3A69BF for ; Mon, 9 Nov 2009 10:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 u5veAofdFDbC for ; Mon, 9 Nov 2009 10:50:11 -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 67DF93A68A3 for ; Mon, 9 Nov 2009 10:50:11 -0800 (PST) Received: from dnab42207f.stanford.edu ([171.66.32.127]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N7ZK1-0001yz-4w; Mon, 09 Nov 2009 10:50:37 -0800 Message-Id: <677B41CF-4124-422C-B62E-0EAC2145CCB2@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:50:36 -0800 References: <4AF5C26A.30408@acm.org> <9E09DD5C-45C5-4EC9-9299-16046A9D57A9@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: ROLL WG Subject: Re: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 18:50:12 -0000 On Nov 9, 2009, at 10:30 AM, Julien Abeille (jabeille) wrote: > Hi Phil, > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: lundi 9 novembre 2009 18:12 >> To: Julien Abeille (jabeille) >> Cc: Tim Winter; ROLL WG >> Subject: Re: [Roll] [roll] #5: DODAG >> >> >> On Nov 9, 2009, at 2:11 AM, Julien Abeille (jabeille) wrote: >> >>> Hi Tim, >>> >>> My question is: are there DAGs that are not DODAGs in RPL? >> My feeling >>> is no. Hence I would suppress the DODAG instead of turning >> all "DAG" >>> into "DODAG". >>> Best, >>> Julien >> >> I disagree -- Directed Acyclic Graph is a very well defined >> term in graph theory. We shouldn't redefine it. A DODAG is a >> particular kind of DAG, where there is one and only one node >> which has only incoming edges. We could maybe come up with a >> better term than DODAG, but DAG definitely isn't it. It will >> confuse readers tremendously. > Sorry, did not want to hurt graph theory specialists among IETF draft > readers. > > Seriously, what is confusing is to have DAGs and DODAGs everywhere in > the draft. > An instance is not as far as I understand a DAG. An instance is > multiple > DODAGs. Hence either we use only DAG everywhere, or DODAG > everywhere, no > mention of DAG. Thoughts? I totally agree - the mixed use of DODAG and DAG is confusing. I think we should use DODAG. Phil From pal@cs.stanford.edu Mon Nov 9 10:57:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463883A6359 for ; Mon, 9 Nov 2009 10:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 2MdOEE8ddVV9 for ; Mon, 9 Nov 2009 10:57:35 -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 9A66D3A6774 for ; Mon, 9 Nov 2009 10:57:35 -0800 (PST) Received: from dnab42207f.stanford.edu ([171.66.32.127]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N7ZRA-0002IR-T8; Mon, 09 Nov 2009 10:58:01 -0800 Message-Id: <3C3AA015-BF91-443E-AF96-FAE093BD7C17@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:58:00 -0800 References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:57:36 -0000 On Nov 9, 2009, at 10:32 AM, Julien Abeille (jabeille) wrote: > Phil, > > Are you in favor of computing rank based on all parents, or only > preferred? It's not clear to me what a "preferred" parent is. Is it the exact parent at time T? A node may wish to change which next hop it uses very quickly (albeit under constraints that keep the topology consistent). Jonathan Hui's IP layer does this: it chooses an alternate parent after three consecutive link delivery failures (no acks). The way I see it, a node has a neighbor set, which is an unconstrained set of link-local neighboring nodes. Its parent set is a subset of its neighbor set, and these parents can be used arbitrarily (an implementation could just cycle through them for each transmission, if it wanted). The only time when a node has *a* parent is the instant it transmits a packet to a particular next hop. Given this, Rank should be computed based on the parent set. I'd say that A node MUST NOT advertise a Rank that is less than or equal to any member of its parent set. Phil From jabeille@cisco.com Mon Nov 9 11:39:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6F23A6947 for ; Mon, 9 Nov 2009 11:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.894 X-Spam-Level: X-Spam-Status: No, score=-9.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 JbCT4vPwRqqt for ; Mon, 9 Nov 2009 11:39:46 -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 C91FF3A68C1 for ; Mon, 9 Nov 2009 11:39:20 -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: Ak0AAKz+90qQ/uCWe2dsb2JhbACbfAEBFiQGqzyXD4Q+BIwL X-IronPort-AV: E=Sophos;i="4.44,711,1249257600"; d="scan'208";a="53995975" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 19:39:46 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9Jdkja011408; Mon, 9 Nov 2009 19:39:46 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 20:39:46 +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, 9 Nov 2009 20:39:45 +0100 Message-ID: In-Reply-To: <3C3AA015-BF91-443E-AF96-FAE093BD7C17@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcphbpX8vr+mQaC/R5KMmXCtNxngCwABGO5g References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> <3C3AA015-BF91-443E-AF96-FAE093BD7C17@cs.stanford.edu> From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 09 Nov 2009 19:39:46.0101 (UTC) FILETIME=[64571650:01CA6174] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:39:47 -0000 Hi Phil, > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: lundi 9 novembre 2009 19:58 > To: Julien Abeille (jabeille) > Cc: Pascal Thubert (pthubert); JP Vasseur (jvasseur);=20 > Mathilde Durvy (mdurvy); roll > Subject: Re: [Roll] Clarification on the objective function >=20 >=20 > On Nov 9, 2009, at 10:32 AM, Julien Abeille (jabeille) wrote: >=20 > > Phil, > > > > Are you in favor of computing rank based on all parents, or only=20 > > preferred? >=20 > It's not clear to me what a "preferred" parent is. Is it the=20 For me the preferred parent is the one you send DAOs to.=20 > exact parent at time T? A node may wish to change which next=20 > hop it uses very quickly (albeit under constraints that keep=20 > the topology consistent). Jonathan Hui's IP layer does this:=20 > it chooses an alternate parent after three consecutive link=20 > delivery failures (no acks). agree >=20 > The way I see it, a node has a neighbor set, which is an=20 > unconstrained set of link-local neighboring nodes. Its parent=20 > set is a subset of its neighbor set, and these parents can be=20 > used arbitrarily (an implementation could just cycle through=20 > them for each transmission, if it wanted).=20 agree > The only time when=20 > a node has *a* parent is the instant it transmits a packet to=20 > a particular next hop. >=20 > Given this, Rank should be computed based on the parent set.=20 > I'd say that >=20 > A node MUST NOT advertise a Rank that is less than or equal=20 > to any member of its parent set. >=20 Agree.=20 The issue is when you lose your prefererred parent, you may want to choose a backup one to send DAOs to. The fact that its rank is lower than yours does not guarantee that your new rank will not change. e.g. if OF says my rank is preffered parent's + 2, and I have parents at rank 1 and 2, mine is 3. if my parent at rank 1 dies, and I choose the other parent as preferred, my rank would become 4, which implies moving lower. Does anybody want to avoid this by computing continuesly rank based on the parent set instead of just the preferred one (this is not optimal but helps if you compute your rank when you get several DIOs)?=20 Julien > Phil >=20 From mcr@marajade.sandelman.ca Mon Nov 9 16:21:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E97728C28A for ; Mon, 9 Nov 2009 16:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.455, 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 F5Nrm7dIMerp for ; Mon, 9 Nov 2009 16:21:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E8C7728C289 for ; Mon, 9 Nov 2009 16:21:38 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 74687342BA for ; Mon, 9 Nov 2009 19:13:04 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D61554E792 for ; Mon, 9 Nov 2009 19:22:03 -0500 (EST) From: Michael Richardson To: "roll WG" In-Reply-To: References: <116E87EB-8C18-40CD-B967-044156B43883@cisco.com><1AE5194F-65E9-4E7A-AA8D-14CCCF75627F@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FDF9@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FE13@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D95FECA@XMB-AMS-107.cisco.com> <6635.1257777751@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 09 Nov 2009 19:22:03 -0500 Message-ID: <10755.1257812523@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Ticket #10: Closed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 00:21:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Julien" == Julien Abeille <(jabeille)" > writes: >> And if done correctly, interop does happen by magic. You are >> reading this email, because email was standardized. Julien> Well I am reading this email because I have a laptop that Julien> supports a bunch of RFCs, and bunch of email standards. Right. When you purchased the laptop, did you have to tell the salesperson that you would be using the laptop for *IETF* emails? Did you load an *IETF* *WG* profile into your email system? You can, ad-hoc, send email to any other email system in the world, for a variety of purposes. You can even send voice mail between systems using SMTP, but it turned out that a restricted profile (a subset) of SMTP (vpim) is useful. Julien> So I guess we disagree on benefits vs costs. And again if Julien> the root does not send OCP0, the game boy having OCP0 is Julien> useless. Are we trying to solve an adhoc network problem? Do Julien> the requirements drafts and RFCs require this kind of Julien> scenario? If the root node your game boy can see right now does not send OCP0, then the DAG anchored by that root node is not useful to your game boy. Being a game boy, it's mobile, and it might see another root node that is more to its liking. Also, being mobile, it may well *BECOME* a root node (an ungrounded one), and maybe I'll play head to head with some other guy in the next train car. If that original root node has been configured not to send the OCP0, that's a configuration decision. If it can not be configured to send OCP0, then it's not interoperable. That might be okay -- you might write a subset profile of RPL that mandates a different OCPx, and permits OCP0 to be eliminated -- but you'd claim compliance to that RFC, not the RPL STD. Almost all WGs (and other SDOs) that build general protocols where there is not a minimal subset that is MUST, have wound up having to multiple "profile" documents, and in the end, regularly fail to interop in the field. (X.500->X509->X509.v3->PKIX->PKI4IPSEC comes to mind) So the answer is: if a device claims that it supports RPL, then it yes, it should be possible to configure it to work in an adhoc network. If all light switches in a home automation application need to support OCP4 (as specified in RFCXYZQ), and you order them from the factory with that as the default, then great. If the device supports RPL, I expect to be able to pull the units out of my home (after that kitchen fire which writes my house off, maybe), and use them at my cottage, where OCP0 is going to be used. Maybe I gotta tweak some config options. (my last email on this) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSviyKoCLcPvd0N1lAQI8kgf+IdfKj3o9+BqQhgWLPb8rZPgo8qCuK/lv B5jUyTXHu/eQmqV5SZXe/FswcAbLu8IE5qc8Hst44H2ZBRcnV2/v2+UnuhxT1WJW WrBMIzMzeblvq9T+mOajc80fpiq5Ccgjjr/jhE0pbQsKFopjaPCHaOmQd7h6Jksi SG/1PgFHYVGhULPr+oZQIs7W26cVUTwDcA7DdxqG7B/JiaOPs4p3/R0hfIRnFda4 krxhBDyKblA9k9qkazF/k0B2C2nZuUjX9HZ6d6fN9fAMgKjYsskIUfkTCv6+LO80 4P3ca2u4InaNTFdDu5cDALcW2jTs7dT6ZoVLgXZhF4dFXH3xid+LHg== =eAVn -----END PGP SIGNATURE----- From Adrian.Farrel@huawei.com Mon Nov 9 17:35:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B8A3A6A42 for ; Mon, 9 Nov 2009 17:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxDlXQfpP38S for ; Mon, 9 Nov 2009 17:35:32 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id AA17E3A6A32 for ; Mon, 9 Nov 2009 17:35:32 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV00NAEDRZ26@usaga03-in.huawei.com> for roll@ietf.org; Mon, 09 Nov 2009 19:35:59 -0600 (CST) Received: from your029b8cecfe (host-16-167.meeting.ietf.org [133.93.16.167]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV0008ZDRW11@usaga03-in.huawei.com> for roll@ietf.org; Mon, 09 Nov 2009 19:35:58 -0600 (CST) Date: Tue, 10 Nov 2009 01:34:45 +0000 From: Adrian Farrel To: roll@ietf.org Message-id: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: draft-ietf-roll-routing-metrics@tools.ietf.org Subject: [Roll] draft-ietf-roll-routing-metrics-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:35:33 -0000 Hi, Thanks for presenting today. Something jumped out. In the common header you have... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Routing Metric/Constraint common header format Are you worried that you have only two more unused bits? Is there a risk that you will run out very soon? On the other hand, do you really need 16 bits for the length in bytes of the object? Are you tied to this format by the RPL spec, or could you create yourself 8 more flag bits by reducing the Object Length to 8 bits? Cheers, Adrian From pthubert@cisco.com Mon Nov 9 17:45:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694833A6898 for ; Mon, 9 Nov 2009 17:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.738 X-Spam-Level: X-Spam-Status: No, score=-9.738 tagged_above=-999 required=5 tests=[AWL=0.861, 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 z9MTyLO1oPno for ; Mon, 9 Nov 2009 17:45:04 -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 278CD3A67AF for ; Mon, 9 Nov 2009 17:45:04 -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: AjYAAC5U+EqQ/uCWe2dsb2JhbACbfQEBFiQGqQ+XV4Q+BIwL X-IronPort-AV: E=Sophos;i="4.44,712,1249257600"; d="scan'208";a="54010464" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 01:45:29 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA1jTSn002730; Tue, 10 Nov 2009 01:45:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 02:45:30 +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: Tue, 10 Nov 2009 02:45:29 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D960212@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcphZNP5TYNRd/oCTpur+Z0AtXnfvgAP3YKA References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 10 Nov 2009 01:45:30.0039 (UTC) FILETIME=[7BF24C70:01CA61A7] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:45:05 -0000 Hi Phil and Julien: For 1) agreed with Phil. Any node with rank less than self in the DODAG iteration can be a parent. For 2) RPL has the concept of preferred parent to deal with this. The preferred parent determines the node rank whether the second (not as good) parent is already seen or not. The second (not as good) parent does not influence the rank.=20 This is done to avoid greedy behaviors and to simplify the metrics inheritance. Pascal >-----Original Message----- >From: Philip Levis [mailto:pal@cs.stanford.edu] >Sent: lundi 9 novembre 2009 18:00 >To: Julien Abeille (jabeille) >Cc: Pascal Thubert (pthubert); JP Vasseur (jvasseur); Mathilde Durvy (mdurvy); roll >Subject: Re: [Roll] Clarification on the objective function > > >On Nov 9, 2009, at 4:57 AM, Julien Abeille (jabeille) wrote: > >> Hi Pascal, >> >> just to be sure I understand: >> - I have a preferred parent at rank 1, my rank is 5, I receive a DIO >> for a parent rank 2, must i ignore it? I would say no as this node >> is useful as backup parent, but if i lose my preferred parent, >> choosing the backup as preferred will make my rank increase (this is >> ok because if i compute rank based on all parents, I would have to >> increase rank at reception of the second DIO anyway) >> - At boot time, I receive two DIOs (rank 1 and 2) before computing >> OCP. If I calculate rank based on preferred only, if at some point I >> would like to switch to the other parent, I will have to move down. >> >> Still I think it is preferable to calculate rank based on preferred >> only, but what do other think? >> Julien > >Julien, > >Question 1: In -04, you MUST process the DIO. Section 5.4.2.1: > > If the rank of SRC as reported in the DIO message is lesser > than that of the node within the DAG, then the DIO message MUST > be considered for further processing > >Question 2: The draft is unclear. > >Phil From Adrian.Farrel@huawei.com Mon Nov 9 18:15:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2B83A67AF for ; Mon, 9 Nov 2009 18:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr6hucJtpEja for ; Mon, 9 Nov 2009 18:15:36 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A913D3A67F3 for ; Mon, 9 Nov 2009 18:15:36 -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 <0KSV00L39FMP99@usaga01-in.huawei.com> for roll@ietf.org; Mon, 09 Nov 2009 18:16:01 -0800 (PST) Received: from your029b8cecfe (host-16-167.meeting.ietf.org [133.93.16.167]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV00MVEFMMP8@usaga01-in.huawei.com> for roll@ietf.org; Mon, 09 Nov 2009 18:16:01 -0800 (PST) Date: Tue, 10 Nov 2009 02:15:21 +0000 From: Adrian Farrel To: roll@ietf.org Message-id: <27FEC99A2D374A7FA2C2F9879C2BE894@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: draft-tsao-roll-security-framework@tools.ietf.org Subject: [Roll] draft-tsao-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:15:37 -0000 Thanks to Rene for his presentation today. I'd like you to have a look at RFC 4107, and use this to drive some more thoughts about key management. Cheers, Adrian From jvasseur@cisco.com Mon Nov 9 23:44:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2042B3A697F for ; Mon, 9 Nov 2009 23:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.745 X-Spam-Level: X-Spam-Status: No, score=-7.745 tagged_above=-999 required=5 tests=[AWL=-1.146, 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 WHb3gSuoKwKw for ; Mon, 9 Nov 2009 23:44:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2E35428C118 for ; Mon, 9 Nov 2009 23:44:37 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMuo+EqrR7H+/2dsb2JhbADEUJgDhD4E X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208";a="428864155" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2009 07:45:04 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAA7j3Ou008434; Tue, 10 Nov 2009 07:45:04 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 08:45:03 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 08:45:02 +0100 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D960212@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 08:45:01 +0100 References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D960212@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 07:45:02.0412 (UTC) FILETIME=[B61530C0:01CA61D9] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:44:48 -0000 On Nov 10, 2009, at 2:45 AM, Pascal Thubert (pthubert) wrote: > Hi Phil and Julien: > > For 1) agreed with Phil. Any node with rank less than self in the > DODAG > iteration can be a parent. > > For 2) RPL has the concept of preferred parent to deal with this. > > > The preferred parent determines the node rank whether the second > (not as > good) parent is already seen or not. > The second (not as good) parent does not influence the rank. => used as a back up (similarly to siblings) > This is done to avoid greedy behaviors and to simplify the metrics > inheritance. > > > Pascal > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: lundi 9 novembre 2009 18:00 >> To: Julien Abeille (jabeille) >> Cc: Pascal Thubert (pthubert); JP Vasseur (jvasseur); Mathilde Durvy > (mdurvy); roll >> Subject: Re: [Roll] Clarification on the objective function >> >> >> On Nov 9, 2009, at 4:57 AM, Julien Abeille (jabeille) wrote: >> >>> Hi Pascal, >>> >>> just to be sure I understand: >>> - I have a preferred parent at rank 1, my rank is 5, I receive a DIO >>> for a parent rank 2, must i ignore it? I would say no as this node >>> is useful as backup parent, but if i lose my preferred parent, >>> choosing the backup as preferred will make my rank increase (this is >>> ok because if i compute rank based on all parents, I would have to >>> increase rank at reception of the second DIO anyway) >>> - At boot time, I receive two DIOs (rank 1 and 2) before computing >>> OCP. If I calculate rank based on preferred only, if at some point I >>> would like to switch to the other parent, I will have to move down. >>> >>> Still I think it is preferable to calculate rank based on preferred >>> only, but what do other think? >>> Julien >> >> Julien, >> >> Question 1: In -04, you MUST process the DIO. Section 5.4.2.1: >> >> If the rank of SRC as reported in the DIO message is lesser >> than that of the node within the DAG, then the DIO message > MUST >> be considered for further processing >> >> Question 2: The draft is unclear. >> >> Phil From jabeille@cisco.com Tue Nov 10 00:39:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1363A69B0 for ; Tue, 10 Nov 2009 00:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.908 X-Spam-Level: X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWa0IcXJ8eps for ; Tue, 10 Nov 2009 00:39:47 -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 B6DF43A6A45 for ; Tue, 10 Nov 2009 00:39:37 -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: AjYAAIG1+EqQ/uCWe2dsb2JhbACbfAEBFiQGqD2YB4Q+BIwL X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208";a="54026559" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 08:40:03 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA8e3mI002826; Tue, 10 Nov 2009 08:40:03 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:40:03 +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: Tue, 10 Nov 2009 09:40:01 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D960212@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on the objective function Thread-Index: AcphZNP5TYNRd/oCTpur+Z0AtXnfvgAP3YKAAA83+eA= References: <8A977BDC5A7B0E429B0F521E8D6F91EEA1616F@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D95FEA6@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D960212@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Philip Levis" X-OriginalArrivalTime: 10 Nov 2009 08:40:03.0766 (UTC) FILETIME=[65D7D560:01CA61E1] Cc: roll Subject: Re: [Roll] Clarification on the objective function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:39:48 -0000 Hi Pascal=20 > -----Original Message----- > From: Pascal Thubert (pthubert)=20 > Sent: mardi 10 novembre 2009 02:45 > To: Philip Levis; Julien Abeille (jabeille) > Cc: JP Vasseur (jvasseur); Mathilde Durvy (mdurvy); roll > Subject: RE: [Roll] Clarification on the objective function >=20 > Hi Phil and Julien: >=20 > For 1) agreed with Phil. Any node with rank less than self in=20 > the DODAG iteration can be a parent. >=20 > For 2) RPL has the concept of preferred parent to deal with this. >=20 >=20 > The preferred parent determines the node rank whether the=20 > second (not as good) parent is already seen or not. > The second (not as good) parent does not influence the rank.=20 > This is done to avoid greedy behaviors and to simplify the=20 > metrics inheritance. >=20 I got this some time ago. This is what I am questionning, because of the behavior I detailed twice.=20 Julien >=20 > Pascal >=20 > >-----Original Message----- > >From: Philip Levis [mailto:pal@cs.stanford.edu] > >Sent: lundi 9 novembre 2009 18:00 > >To: Julien Abeille (jabeille) > >Cc: Pascal Thubert (pthubert); JP Vasseur (jvasseur); Mathilde Durvy=20 > >(mdurvy); roll > >Subject: Re: [Roll] Clarification on the objective function > > > > > >On Nov 9, 2009, at 4:57 AM, Julien Abeille (jabeille) wrote: > > > >> Hi Pascal, > >> > >> just to be sure I understand: > >> - I have a preferred parent at rank 1, my rank is 5, I=20 > receive a DIO=20 > >> for a parent rank 2, must i ignore it? I would say no as=20 > this node is=20 > >> useful as backup parent, but if i lose my preferred=20 > parent, choosing=20 > >> the backup as preferred will make my rank increase (this is ok=20 > >> because if i compute rank based on all parents, I would have to=20 > >> increase rank at reception of the second DIO anyway) > >> - At boot time, I receive two DIOs (rank 1 and 2) before computing=20 > >> OCP. If I calculate rank based on preferred only, if at=20 > some point I=20 > >> would like to switch to the other parent, I will have to move down. > >> > >> Still I think it is preferable to calculate rank based on=20 > preferred=20 > >> only, but what do other think? > >> Julien > > > >Julien, > > > >Question 1: In -04, you MUST process the DIO. Section 5.4.2.1: > > > > If the rank of SRC as reported in the DIO message is lesser > > than that of the node within the DAG, then the DIO=20 > message MUST > > be considered for further processing > > > >Question 2: The draft is unclear. > > > >Phil >=20 From jvasseur@cisco.com Tue Nov 10 03:43:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7536B28C181 for ; Tue, 10 Nov 2009 03:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.727 X-Spam-Level: X-Spam-Status: No, score=-9.727 tagged_above=-999 required=5 tests=[AWL=0.872, 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 AQZN0I65zIIF for ; Tue, 10 Nov 2009 03:43:12 -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 65D483A6AA4 for ; Tue, 10 Nov 2009 03:43:12 -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: AjYAAM/g+EqQ/uCWe2dsb2JhbACcAQEBFiQGqG2YD4Q+BA X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208";a="54047308" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 11:43:38 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAABhcaQ029771 for ; Tue, 10 Nov 2009 11:43:38 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:43:38 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:43:37 +0100 Message-Id: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 12:43:37 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 11:43:37.0957 (UTC) FILETIME=[0AD00150:01CA61FB] Subject: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 11:43:16 -0000 We need to clarify that when a node jumps to a better parent (higher rank), it can of course jump at any time since there is no risk of loops, but it must also poison up (send a no-DIO) to the previous parent. Thanks. JP. From jvasseur@cisco.com Tue Nov 10 06:41:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C503A6AEC for ; Tue, 10 Nov 2009 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxfbbnHhu11y for ; Tue, 10 Nov 2009 06:41:36 -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 109B828C131 for ; Tue, 10 Nov 2009 06:41:35 -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: AjoAAAQL+UqQ/uCWe2dsb2JhbACCIi+ZMAEBFiQGqX2YGYQ+BA X-IronPort-AV: E=Sophos;i="4.44,716,1249257600"; d="scan'208,217";a="54070263" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 14:42:02 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAEg2xj002284 for ; Tue, 10 Nov 2009 14:42:02 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:42:01 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:42:00 +0100 Message-Id: <13ACE418-7BEF-4818-A9E0-36C823A5B3A9@cisco.com> From: JP Vasseur To: roll WG In-Reply-To: <1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-202-384046344 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 15:42:00 +0100 References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org> <1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 14:42:00.0990 (UTC) FILETIME=[F6513BE0:01CA6213] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17000.005 X-TM-AS-Result: No--31.087900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix packing in DIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 14:41:38 -0000 --Apple-Mail-202-384046344 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 9, 2009, at 12:34 PM, JP Vasseur wrote: > Dear all, > > Here is a proposed resolution. > > Issue: as of today: there is exactly one prefix per DAO. Thanks to =20 > the DelayDAO timer, > we may have a chance to perform data aggregation (when possible) but =20= > we would > still end up with an increasing number of DAO as we get closer to =20 > the sink, with the > worst case being one DAO per leaf ... > > As a reminder, here is the format of the DAO message: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =20= > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | DAO Sequence | InstanceID | DAO =20 > Rank | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | DAO =20 > Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Route =20 > Tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Prefix Length | RRCount =20 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 > + | > | Prefix (Variable =20 > Length) | > . = . > . = . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Reverse Route Stack (Variable =20 > Length) | > . = . > . = . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > > > We have three options: > > 1) Option 1 (Trivial packing): we change the DAO message structure =20 > to carry more than one prefix > in a DAO message. This is of course only possible for prefixes =20 > sharing the same route tag, rank. > 2) Option 2: we also try to factorize common element. By adopting a =20= > flexible encoding, we avoid > repeating fields that are identical for a set of prefixes. Back to =20 > the example provided below, this would > avoid repeating the value of the Reverse Route Stack for each prefix =20= > that uses the same recorded > path. > > Thoughts ? > > Thanks. > > JP. > > On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote: > >> #11: Decision on prefix packing in DIO messages >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: jpv@=85 >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> Currently RPL requires one DAO per message. >> >> JP's proposal below: >> >> Hi Jonathan, >> >> What I was referring to was to pack prefix in DAO, a very light =20 >> change in >> the spec (just make use of TLV) and factor the common fields. This =20= >> allows >> to reduce the number of packets very significantly as we get closer =20= >> to the >> root. >> >> There two benefits here: >> 1) You send one DAO between C and D instead of 3 >> 2) You can also pack the Reverse Route Stack whenever possible for =20= >> all >> prefix sharing the same routes. >> >> Let's suppose that: >> 1) X advertises two prefixes X1 and X2 >> 2) Y advertises two prefixes Y1, Y2 and Y3 >> 3) Z advertised one prefix: Z1 >> >> Instead of sending 6 DAO, C would send one DAO to D would look like =20= >> this: >> X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] >> >> Note that you could when possible also aggregates prefixes at the =20 >> same >> time if they share a common path. >> >> BAck to you timing question Richard, it depends of the sequence of =20= >> events >> but there is no need to wait. >> C could start with one DAO and then start to pack at it receives =20 >> more, the >> same reasoning applies to other >> nodes. >> >> Others, thoughts ? >> >> Thanks. >> >> JP. >> >> --=20 >> Ticket URL: >> roll >> > --Apple-Mail-202-384046344 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Nov 9, 2009, = at 12:34 PM, JP Vasseur wrote:

Dear = all, 

Here is a proposed = resolution.

Issue: as of today: there is = exactly one prefix per DAO. Thanks to the DelayDAO timer,
we = may have a chance to perform data aggregation (when possible) but we = would 
still end up with an increasing number of DAO as = we get closer to the sink, with the 
worst case being one = DAO per leaf ...

As a reminder, here is the = format of the DAO message:

        0       =
            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We = have three options:

1) Option 1 (Trivial = packing): we change the DAO message structure to carry more than one = prefix
in a DAO message. This is of course only possible for = prefixes sharing the same route tag, rank.
2) Option 2: we = also try to factorize common element. By adopting a flexible encoding, = we avoid  
repeating fields that are identical for a set = of prefixes. Back to the example provided below, this = would
avoid repeating the value of the Reverse Route Stack for = each prefix that uses the same = recorded
path.

Thoughts = ?

Thanks.

JP.
=
On Nov 2, 2009, at 3:04 PM, roll issue tracker = wrote:

#11: Decision on prefix packing in DIO = messages
--------------------------------+-----------------------------= --------------
Reporter:  jpv@=85 =             &n= bsp; |       Owner:  jpv@=85 =        
=     Type:  enhancement =         | =      Status:  new =          
Priority: =  major =             &n= bsp; |   Milestone: =             &n= bsp; 
Component:  rpl =             &n= bsp;   |     Version: =             &n= bsp; 
Severity:  Active WG Document  | =    Keywords: =             &n= bsp; 
--------------------------------+---------------------------= ----------------
Currently RPL requires one DAO per message.

= JP's proposal below:

Hi Jonathan,

What I was referring = to was to pack prefix in DAO, a very light change in
the spec (just = make use of TLV) and factor the common fields. This allows
to reduce = the number of packets very significantly as we get closer to the
= root.

There two benefits here:
1) You send one DAO between C = and D instead of 3
2) You can also pack the Reverse Route Stack = whenever possible for all
prefix sharing the same routes.

= Let's suppose that:
1) X advertises two prefixes X1 and X2
2) Y = advertises two prefixes Y1, Y2 and Y3
3) Z advertised one prefix: = Z1

Instead of sending 6 DAO, C would send one DAO to D would = look like this:
X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC]

Note that = you could when possible also aggregates prefixes at the same
time if = they share a common path.

BAck to you timing question Richard, = it depends of the sequence of events
but there is no need to = wait.
C could start with one DAO and then start to pack at it = receives more, the
same reasoning applies to other
= nodes.

Others, thoughts ?

Thanks.

JP.

-- =
Ticket URL: <https://svn.too= ls.ietf.org/wg/roll/trac/ticket/11>
roll <http://tools.ietf.org/wg/roll/= >


= --Apple-Mail-202-384046344-- From edward.j.beroset@us.elster.com Tue Nov 10 07:19:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318343A67F1 for ; Tue, 10 Nov 2009 07:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6hYqDzKNIJOc for ; Tue, 10 Nov 2009 07:19:56 -0800 (PST) Received: from mail196.messagelabs.com (mail196.messagelabs.com [216.82.254.67]) by core3.amsl.com (Postfix) with SMTP id 392F93A67E6 for ; Tue, 10 Nov 2009 07:19:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: edward.j.beroset@us.elster.com X-Msg-Ref: server-4.tower-196.messagelabs.com!1257866332!60093694!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 26268 invoked from network); 10 Nov 2009 15:18:54 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-4.tower-196.messagelabs.com with SMTP; 10 Nov 2009 15:18:54 -0000 In-Reply-To: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> References: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> MIME-Version: 1.0 To: draft-ietf-roll-routing-metrics@tools.ietf.org, roll@ietf.org X-KeepSent: 3332525F:A3179F2B-8525766A:004B44B2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008 Message-ID: From: edward.j.beroset@us.elster.com Date: Tue, 10 Nov 2009 10:20:02 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 11/10/2009 10:17:59 AM, Serialize complete at 11/10/2009 10:17:59 AM Content-Type: multipart/alternative; boundary="=_alternative 00543B558525766A_=" Subject: [Roll] numeric ranges in routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 15:19:57 -0000 This is a multipart message in MIME format. --=_alternative 00543B558525766A_= Content-Type: text/plain; charset="US-ASCII" I mentioned it during the roll meeting Tuesday, but I think it's probably worth documenting the thought in a little more technical detail. The routing metrics right now include 32-bit floating point numbers for latency and throughput. Since these numbers are much more likely to be added or compared rather than multiplied, fixed point rather than floating point is likely to be a better choice of representation. For example, for normalized positive 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and the minimum is about 1.2e-38. For reference, the age of universe in milliseconds (taking the high end of NASA's most recent estimate) is only 4.4e20 and the time it takes to travel the distance across an electron (Lorentz diameter for you physics heads) is about 1.9e-20 ms. A negative latency would seem to imply that packets appear before they're sent which is probably not practical. If instead, latency were a 32-bit unsigned integer in units of milliseconds, we'd still be able to go from 0 or 1 milliseconds up to almost 1200 hours if my math is right. That should be plenty for any practical network. I haven't done so but I suspect that we could do the same thing with throughput. Ed Beroset --=_alternative 00543B558525766A_= Content-Type: text/html; charset="US-ASCII"
I mentioned it during the roll meeting Tuesday, but I think it's probably worth documenting the thought in a little more technical detail.  The routing metrics right now include 32-bit floating point numbers for latency and throughput.  Since these numbers are much more likely to be added or compared rather than multiplied, fixed point rather than floating point is likely to be a better choice of representation.  For example, for normalized positive 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and the minimum is about 1.2e-38.  For reference, the age of universe in milliseconds (taking the high end of NASA's most recent estimate) is only 4.4e20 and the time it takes to travel the distance across an electron (Lorentz diameter for you physics heads) is about 1.9e-20 ms.  A negative latency would seem to imply that packets appear before they're sent which is probably not practical.  If instead, latency were a 32-bit unsigned integer in units of milliseconds, we'd still be able to go from 0 or 1 milliseconds up to almost 1200 hours if my math is right.  That should be plenty for any practical network.  I haven't done so but I suspect that we could do the same thing with throughput.

Ed Beroset --=_alternative 00543B558525766A_=-- From jvasseur@cisco.com Tue Nov 10 07:54:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CF828C0FC for ; Tue, 10 Nov 2009 07:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.744 X-Spam-Level: X-Spam-Status: No, score=-9.744 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUkyWIna7lYW for ; Tue, 10 Nov 2009 07:54:52 -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 5CF793A6973 for ; Tue, 10 Nov 2009 07:54:52 -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: AjYAAGcb+UqQ/uCWe2dsb2JhbACCUZkwAQEWJAaqHpgdhD4E X-IronPort-AV: E=Sophos;i="4.44,716,1249257600"; d="scan'208,217";a="54079469" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 15:55:18 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAFtI84028165; Tue, 10 Nov 2009 15:55:18 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 16:55:18 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 16:55:17 +0100 Message-Id: <691A0A47-024C-44D2-9136-D37D0097E7E4@cisco.com> From: JP Vasseur To: edward.j.beroset@us.elster.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-206-388442580 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 16:55:16 +0100 References: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 15:55:17.0788 (UTC) FILETIME=[33035DC0:01CA621E] Cc: draft-ietf-roll-routing-metrics@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] numeric ranges in routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 15:54:53 -0000 --Apple-Mail-206-388442580 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Edward, On Nov 10, 2009, at 4:20 PM, edward.j.beroset@us.elster.com wrote: > > I mentioned it during the roll meeting Tuesday, but I think it's > probably worth documenting the thought in a little more technical > detail. The routing metrics right now include 32-bit floating point > numbers for latency and throughput. Since these numbers are much > more likely to be added or compared rather than multiplied, fixed > point rather than floating point is likely to be a better choice of > representation. For example, for normalized positive 32-bit IEEE > 754 numbers, the maximum number is about 3.4e38 and the minimum is > about 1.2e-38. For reference, the age of universe in milliseconds > (taking the high end of NASA's most recent estimate) is only 4.4e20 > and the time it takes to travel the distance across an electron > (Lorentz diameter for you physics heads) is about 1.9e-20 ms. A > negative latency would seem to imply that packets appear before > they're sent which is probably not practical. Indeed ;-) > If instead, latency were a 32-bit unsigned integer in units of > milliseconds, we'd still be able to go from 0 or 1 milliseconds up > to almost 1200 hours if my math is right. That should be plenty for > any practical network. I haven't done so but I suspect that we > could do the same thing with throughput. > Absolutely. It will be reflected in the next revision. Another question is whether we want to make the metrics inversely proportional to the throughput in order to compute least cost path. Opinion ? Thanks. JP. > Ed Beroset_______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-206-388442580 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Edward,

On = Nov 10, 2009, at 4:20 PM, edward.j.beroset@us.elster.= com wrote:


I mentioned it = during the roll meeting Tuesday, but I think it's probably worth = documenting the thought in a little more technical detail.  The = routing metrics right now include 32-bit floating point numbers for = latency and throughput.  Since these numbers are much more likely = to be added or compared rather than multiplied, fixed point rather than = floating point is likely to be a better choice of representation. =  For example, for normalized positive 32-bit IEEE 754 numbers, the = maximum number is about 3.4e38 and the minimum is about 1.2e-38. =  For reference, the age of universe in milliseconds (taking the = high end of NASA's most recent estimate) is only 4.4e20 and the time it = takes to travel the distance across an electron (Lorentz diameter for = you physics heads) is about 1.9e-20 ms.  A negative latency would = seem to imply that packets appear before they're sent which is probably = not practical.  

Indeed = ;-)

If instead, latency were a 32-bit unsigned integer = in units of milliseconds, we'd still be able to go from 0 or 1 = milliseconds up to almost 1200 hours if my math is right.  That = should be plenty for any practical network.  I haven't done so but = I suspect that we could do the same thing with throughput.
=

Absolutely. It will be reflected in = the next revision.

Another question is whether = we want to make the metrics inversely proportional to the throughput in = order to compute least cost path. Opinion = ?

Thanks.

JP.

<= blockquote type=3D"cite">Ed = Beroset_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-206-388442580-- From dcrocker@bbiw.net Sun Nov 8 16:52:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4819C3A6A36; Sun, 8 Nov 2009 16:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 zCaiE68nASdb; Sun, 8 Nov 2009 16:52:56 -0800 (PST) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:20e:2eff:fec8:eb01]) by core3.amsl.com (Postfix) with ESMTP id D4CFA3A68E7; Sun, 8 Nov 2009 16:52:55 -0800 (PST) Received: from [133.93.17.143] (host-17-143.meeting.ietf.org [133.93.17.143]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id nA90qImG018064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 16:52:26 -0800 Message-ID: <4AF767B9.5020506@bbiw.net> Date: Mon, 09 Nov 2009 09:52:09 +0900 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Polk, William T." References: , <4AF75E3A.2050808@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10000/Sat Nov 7 19:28:38 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Nov 2009 16:53:11 -0800 (PST) X-Mailman-Approved-At: Tue, 10 Nov 2009 08:01:46 -0800 Cc: "ietf@ietf.org" , "Golmie, Nada T." , "peter@peter-dambier.de" , Phil Roberts , IESG IESG , Hiroshi Esaki , Henning Schulzrinne , "recipe@ietf.org" , "Dodson, Donna F." , "roll@ietf.org" , Russ Housley , Peny Yang , David R Oran , Ralph Droms , IAB IAB , Michael Dillon , Richard Shockey , "76all@ietf.org" <76all@ietf.org>, Paul Hoffman , Brian E Carpenter , "St. Pierre, James A." , Leslie Daigle , Sean Turner , "Su, David H." , Fred Baker Subject: Re: [Roll] Room for Smart Grid Bar BOF on Wednesday night at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Nov 2009 00:52:56 -0000 Polk, William T. wrote: > That would be lovely, but I just couldn't sort the government paperwork to > make that happen. Billing it as "meeting materials" didn't work out... Too bad. Cultural mismatch. Choose the right government and it's not only acceptable, it's assumed... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ole@cisco.com Mon Nov 9 14:00:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94BD28C255; Mon, 9 Nov 2009 14:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 sukOEo0oWFkh; Mon, 9 Nov 2009 14:00:30 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C771E28C246; Mon, 9 Nov 2009 14:00:30 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,711,1249257600"; d="scan'208";a="268476028" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 22:00:57 +0000 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9M0vZG005673; Mon, 9 Nov 2009 22:00:57 GMT Date: Mon, 9 Nov 2009 14:00:15 -0800 (PST) From: Ole Jacobsen To: Dave CROCKER In-Reply-To: <4AF767B9.5020506@bbiw.net> Message-ID: References: , <4AF75E3A.2050808@bbiw.net> <4AF767B9.5020506@bbiw.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 10 Nov 2009 08:01:46 -0800 Cc: "recipe@ietf.org" , "Dodson, Donna F." , "Polk, William T." , "ietf@ietf.org" , "roll@ietf.org" , "Su, David H." , David R Oran , Paul Hoffman , Richard Shockey , "St. Pierre, James A." , IAB IAB , IESG IESG , "Golmie, Nada T." , Hiroshi Esaki , "76all@ietf.org" <76all@ietf.org>, Leslie Daigle Subject: Re: [Roll] Room for Smart Grid Bar BOF on Wednesday night at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ole Jacobsen List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:00:32 -0000 If you really want a bar in the room I have some suggestions: 1. Run to the nearest 7-11 and stock up on beer etc. Figure out an easy pay-per-drink value that will recover your costs more or less and ask for donations for the remainder or someone willing to submit an "umbrella" charge. 2. As Marcia if the hotel can operate a cash bar for you and at what cost. The drinks won't be cheap and the overhead charge might require "small vehichle" instead of "umbrella", but it's worth asking. 3. Partially dig into the draft material intended for another session this week, supplemented by local variants obtained from the usual sources. Surely you can create a smart grid of options here, no? Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj From jabeille@cisco.com Tue Nov 10 08:06:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B7F3A6B1D for ; Tue, 10 Nov 2009 08:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C0VkirFSnD5 for ; Tue, 10 Nov 2009 08:06:29 -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 6A2073A6A4A for ; Tue, 10 Nov 2009 08:06:27 -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: AjwAAMUe+UqQ/uCWe2dsb2JhbACCIy6ZMgEBFiQGqiCYH4Q+BA X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208,217";a="54081046" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 16:06:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAG6XPX002404 for ; Tue, 10 Nov 2009 16:06:33 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 17:06:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA621F.C568A1DC" Date: Tue, 10 Nov 2009 17:06:24 +0100 Message-ID: In-Reply-To: <13ACE418-7BEF-4818-A9E0-36C823A5B3A9@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix packing inDIO messages Thread-Index: AcpiE/ze25J981L/QM+1aY73Om8jOQACjwXw References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org><1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> <13ACE418-7BEF-4818-A9E0-36C823A5B3A9@cisco.com> From: "Julien Abeille (jabeille)" To: "JP Vasseur (jvasseur)" , "roll WG" X-OriginalArrivalTime: 10 Nov 2009 16:06:32.0949 (UTC) FILETIME=[C570C250:01CA621F] Subject: Re: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix packing inDIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 16:06:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA621F.C568A1DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 many prefixes will not share the same rank, but packing is still good for these different prefixes, hence i do not think we can leave rank prefix independant. same for route tag. rr stack is more tricky. we could use: =20 common header: dao sequence, lifetime and instance =20 option: type | length | NB prefixes |=20 rank | route tag | rr count | rr stack | prefix 1 len | prefix 1 | prefix 2 len | prefix 2 =20 A DAO would look like: header | option 1, includes 2 prefixes | option 2, includes 3 prefixes... =20 thoughts? Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: mardi 10 novembre 2009 15:42 To: roll WG Subject: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix packing inDIO messages =09 =09 On Nov 9, 2009, at 12:34 PM, JP Vasseur wrote: Dear all, =20 Here is a proposed resolution. Issue: as of today: there is exactly one prefix per DAO. Thanks to the DelayDAO timer, we may have a chance to perform data aggregation (when possible) but we would=20 still end up with an increasing number of DAO as we get closer to the sink, with the=20 worst case being one DAO per leaf ... As a reminder, here is the format of the DAO message: =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Sequence | InstanceID | DAO Rank | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Lifetime | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Tag | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | RRCount | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix (Variable Length) | . . . . =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Route Stack (Variable Length) | . . . . =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 =09 =09 We have three options: 1) Option 1 (Trivial packing): we change the DAO message structure to carry more than one prefix in a DAO message. This is of course only possible for prefixes sharing the same route tag, rank. 2) Option 2: we also try to factorize common element. By adopting a flexible encoding, we avoid =20 repeating fields that are identical for a set of prefixes. Back to the example provided below, this would avoid repeating the value of the Reverse Route Stack for each prefix that uses the same recorded path. Thoughts ? Thanks. JP. On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote: #11: Decision on prefix packing in DIO messages =09 --------------------------------+--------------------------------------- ---- Reporter: jpv@... | Owner: jpv@... =20 Type: enhancement | Status: new =20 Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: =09 --------------------------------+--------------------------------------- ---- Currently RPL requires one DAO per message. =09 JP's proposal below: =09 Hi Jonathan, =09 What I was referring to was to pack prefix in DAO, a very light change in the spec (just make use of TLV) and factor the common fields. This allows to reduce the number of packets very significantly as we get closer to the root. =09 There two benefits here: 1) You send one DAO between C and D instead of 3 2) You can also pack the Reverse Route Stack whenever possible for all prefix sharing the same routes. =09 Let's suppose that: 1) X advertises two prefixes X1 and X2 2) Y advertises two prefixes Y1, Y2 and Y3 3) Z advertised one prefix: Z1 =09 Instead of sending 6 DAO, C would send one DAO to D would look like this: X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] =09 Note that you could when possible also aggregates prefixes at the same time if they share a common path. =09 BAck to you timing question Richard, it depends of the sequence of events but there is no need to wait. C could start with one DAO and then start to pack at it receives more, the same reasoning applies to other nodes. =09 Others, thoughts ? =09 Thanks. =09 JP. =09 --=20 Ticket URL: roll =09 =09 ------_=_NextPart_001_01CA621F.C568A1DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
many prefixes will not share the same rank, but = packing is=20 still good for these different prefixes, hence i do not think we can = leave rank=20 prefix independant. same for route tag. rr stack is more tricky. we = could=20 use:
 
common header:
dao sequence, lifetime and = instance
 
option:
type | length | NB prefixes | =
rank | route tag | rr count | rr stack | prefix = 1 len |=20 prefix 1 | prefix 2 len | prefix 2
 
A DAO would look like:
header | option 1, includes 2 prefixes | = option 2,=20 includes 3 prefixes...
 
thoughts?
Julien
From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur=20 (jvasseur)
Sent: mardi 10 novembre 2009 15:42
To: = roll=20 WG
Subject: [Roll] OPINION TO CLOSE TICKET 11: Decision on = prefix=20 packing inDIO messages


On Nov 9, 2009, at 12:34 PM, JP Vasseur wrote:
Dear=20 all, 

Here is a proposed resolution.

Issue: as of today: there is exactly one prefix per DAO. Thanks = to the=20 DelayDAO timer,
we may have a chance to perform data aggregation (when = possible) but we=20 would 
still end up with an increasing number of DAO as we get closer = to the=20 sink, with the 
worst case being one DAO per leaf ...

As a reminder, here is the format of the DAO message:

        0                   =
1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We have three options:

1) Option 1 (Trivial packing): we change the DAO message = structure to=20 carry more than one prefix
in a DAO message. This is of course only possible for prefixes = sharing=20 the same route tag, rank.
2) Option 2: we also try to factorize common element. By = adopting a=20 flexible encoding, we avoid  
repeating fields that are identical for a set of prefixes. Back = to the=20 example provided below, this would
avoid repeating the value of the Reverse Route Stack for each = prefix=20 that uses the same recorded
path.

Thoughts ?

Thanks.

JP.

On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote:
#11: Decision on prefix packing in DIO=20 = messages
--------------------------------+----------------------------= ---------------
Reporter:=20  jpv@…=20 =             &= nbsp; |=20       Owner:  jpv@…=20 =        
    Typ= e:=20  enhancement =         |=20      Status:  new=20 =          
Priority:=20  major=20 =             &= nbsp; |=20   Milestone:=20 =             &= nbsp; 
Component:=20  rpl=20 =             &= nbsp;   |=20     Version:=20 =             &= nbsp; 
Severity:=20  Active WG Document  |    Keywords:=20 =             &= nbsp; 
--------------------------------+-------------------------= ------------------
Currently=20 RPL requires one DAO per message.

JP's proposal = below:

Hi=20 Jonathan,

What I was referring to was to pack prefix in = DAO, a very=20 light change in
the spec (just make use of TLV) and factor the = common=20 fields. This allows
to reduce the number of packets very = significantly=20 as we get closer to the
root.

There two benefits = here:
1) You=20 send one DAO between C and D instead of 3
2) You can also pack = the=20 Reverse Route Stack whenever possible for all
prefix sharing = the same=20 routes.

Let's suppose that:
1) X advertises two prefixes = X1 and=20 X2
2) Y advertises two prefixes Y1, Y2 and Y3
3) Z = advertised one=20 prefix: Z1

Instead of sending 6 DAO, C would send one DAO = to D=20 would look like this:
X1,X2[XBC], Y1,Y2,Y3[YBC], = Z1[ZBC]

Note=20 that you could when possible also aggregates prefixes at the = same
time=20 if they share a common path.

BAck to you timing question = Richard,=20 it depends of the sequence of events
but there is no need to = wait.
C=20 could start with one DAO and then start to pack at it receives = more,=20 the
same reasoning applies to other
nodes.

Others, = thoughts=20 ?

Thanks.

JP.

--
Ticket URL: <https://svn.to= ols.ietf.org/wg/roll/trac/ticket/11>
roll=20 <http://tools.ietf.org/wg/roll/>


=
------_=_NextPart_001_01CA621F.C568A1DC-- From jvasseur@cisco.com Tue Nov 10 08:12:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607BC3A6B2E for ; Tue, 10 Nov 2009 08:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLse7uOUKwO1 for ; Tue, 10 Nov 2009 08:12:33 -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 7FD903A6B2A for ; Tue, 10 Nov 2009 08:12:31 -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: AjwAABcg+UqQ/uCWe2dsb2JhbACCIy6ZMgEBFiQGqiWYH4Q+BA X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208,217";a="54082016" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 16:12:57 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAGCvGF005061 for ; Tue, 10 Nov 2009 16:12:57 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 17:12:57 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 17:12:56 +0100 Message-Id: <52D65402-6A27-48B0-BC78-7D75945EDD8D@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-207-389501782 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 17:12:55 +0100 References: <055.e0fd4786b2b49cea04ccc878201f7329@tools.ietf.org><1F7CE2D4-E88F-4EF9-A30F-7640E4489482@cisco.com> <13ACE418-7BEF-4818-A9E0-36C823A5B3A9@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 16:12:56.0447 (UTC) FILETIME=[AA05E8F0:01CA6220] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17000.005 X-TM-AS-Result: No--39.075500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll WG Subject: Re: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix packing inDIO messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 16:12:35 -0000 --Apple-Mail-207-389501782 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable HI Julien, So I guess that your preference is to pack (option 2), thanks. We can =20= propose a BNF for that. JP. On Nov 10, 2009, at 5:06 PM, Julien Abeille (jabeille) wrote: > Hi all, > > many prefixes will not share the same rank, but packing is still =20 > good for these different prefixes, hence i do not think we can leave =20= > rank prefix independant. same for route tag. rr stack is more =20 > tricky. we could use: > > common header: > dao sequence, lifetime and instance > > option: > type | length | NB prefixes | > rank | route tag | rr count | rr stack | prefix 1 len | prefix 1 | =20 > prefix 2 len | prefix 2 > > A DAO would look like: > header | option 1, includes 2 prefixes | option 2, includes 3 =20 > prefixes... > > thoughts? > Julien > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of JP Vasseur (jvasseur) > Sent: mardi 10 novembre 2009 15:42 > To: roll WG > Subject: [Roll] OPINION TO CLOSE TICKET 11: Decision on prefix =20 > packing inDIO messages > > > On Nov 9, 2009, at 12:34 PM, JP Vasseur wrote: > >> Dear all, >> >> Here is a proposed resolution. >> >> Issue: as of today: there is exactly one prefix per DAO. Thanks to =20= >> the DelayDAO timer, >> we may have a chance to perform data aggregation (when possible) =20 >> but we would >> still end up with an increasing number of DAO as we get closer to =20 >> the sink, with the >> worst case being one DAO per leaf ... >> >> As a reminder, here is the format of the DAO message: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =20= >> 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> | DAO Sequence | InstanceID | DAO =20 >> Rank | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> | DAO =20 >> Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> | Route =20 >> Tag | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> | Prefix Length | RRCount =20 >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 >> + | >> | Prefix (Variable =20 >> Length) | >> . = . >> . = . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> | Reverse Route Stack (Variable =20 >> Length) | >> . = . >> . = . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+-+ >> >> >> We have three options: >> >> 1) Option 1 (Trivial packing): we change the DAO message structure =20= >> to carry more than one prefix >> in a DAO message. This is of course only possible for prefixes =20 >> sharing the same route tag, rank. >> 2) Option 2: we also try to factorize common element. By adopting a =20= >> flexible encoding, we avoid >> repeating fields that are identical for a set of prefixes. Back to =20= >> the example provided below, this would >> avoid repeating the value of the Reverse Route Stack for each =20 >> prefix that uses the same recorded >> path. >> >> Thoughts ? >> >> Thanks. >> >> JP. >> >> On Nov 2, 2009, at 3:04 PM, roll issue tracker wrote: >> >>> #11: Decision on prefix packing in DIO messages >>> --------------------------------=20 >>> +------------------------------------------- >>> Reporter: jpv@=85 | Owner: jpv@=85 >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: rpl | Version: >>> Severity: Active WG Document | Keywords: >>> --------------------------------=20 >>> +------------------------------------------- >>> Currently RPL requires one DAO per message. >>> >>> JP's proposal below: >>> >>> Hi Jonathan, >>> >>> What I was referring to was to pack prefix in DAO, a very light =20 >>> change in >>> the spec (just make use of TLV) and factor the common fields. This =20= >>> allows >>> to reduce the number of packets very significantly as we get =20 >>> closer to the >>> root. >>> >>> There two benefits here: >>> 1) You send one DAO between C and D instead of 3 >>> 2) You can also pack the Reverse Route Stack whenever possible for =20= >>> all >>> prefix sharing the same routes. >>> >>> Let's suppose that: >>> 1) X advertises two prefixes X1 and X2 >>> 2) Y advertises two prefixes Y1, Y2 and Y3 >>> 3) Z advertised one prefix: Z1 >>> >>> Instead of sending 6 DAO, C would send one DAO to D would look =20 >>> like this: >>> X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] >>> >>> Note that you could when possible also aggregates prefixes at the =20= >>> same >>> time if they share a common path. >>> >>> BAck to you timing question Richard, it depends of the sequence of =20= >>> events >>> but there is no need to wait. >>> C could start with one DAO and then start to pack at it receives =20 >>> more, the >>> same reasoning applies to other >>> nodes. >>> >>> Others, thoughts ? >>> >>> Thanks. >>> >>> JP. >>> >>> --=20 >>> Ticket URL: >>> roll >>> >> > --Apple-Mail-207-389501782 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable HI = Julien,

So I guess that your preference is to pack = (option 2), thanks. We can propose a BNF for = that. 

JP.

On Nov = 10, 2009, at 5:06 PM, Julien Abeille (jabeille) wrote:

Hi all,
 
many prefixes will not share the same rank, = but packing is still good for these different prefixes, hence i do not = think we can leave rank prefix independant. same for route tag. rr stack = is more tricky. we could use:
 
common header:
dao sequence, lifetime and = instance
 
option:
type | length | NB prefixes | =
rank | route tag | rr count | rr stack | prefix 1 len | = prefix 1 | prefix 2 len | prefix 2
 
A DAO would look like:
=
header | option 1, includes = 2 prefixes | option 2, includes 3 prefixes...
=
 
=
thoughts?
=
Julien
=
=
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of JP Vasseur (jvasseur)
Sent: mardi 10 = novembre 2009 15:42
To: roll WG
Subject: [Roll] = OPINION TO CLOSE TICKET 11: Decision on prefix packing inDIO = messages


On Nov 9, = 2009, at 12:34 PM, JP Vasseur wrote:

Dear all,  =

Here is a proposed resolution.
=

Issue: as of today: there is exactly one prefix = per DAO. Thanks to the DelayDAO timer,
we may have a = chance to perform data aggregation (when possible) but we = would 
still end up with an increasing number of DAO = as we get closer to the sink, with the 
worst = case being one DAO per leaf ...

As a = reminder, here is the format of the DAO message:
= 

       =
 0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=

We have three options:

=
1) Option 1 (Trivial packing): we change the DAO message = structure to carry more than one prefix
in a DAO = message. This is of course only possible for prefixes sharing the = same route tag, rank.
2) Option 2: we also try to = factorize common element. By adopting a flexible encoding, we avoid =  
repeating fields that are identical for a set of = prefixes. Back to the example provided below, this would
=
avoid repeating the value of the Reverse Route Stack for each = prefix that uses the same recorded
path.
=

Thoughts ?

=
Thanks.

JP.

=
On Nov 2, 2009, at 3:04 PM, roll issue tracker = wrote:

#11: Decision on prefix packing in DIO = messages
--------------------------------+-----------------------------= --------------
Reporter:  jpv@=85 =             &n= bsp; |       Owner:  jpv@=85= =        
    Type= :  enhancement =         | =      Status:  new =          
Priority: =  major =             &n= bsp; |   Milestone: =             &n= bsp; 
Component:  rpl =             &n= bsp;   |     Version: =             &n= bsp; 
Severity:  Active WG Document  | =    Keywords: =             &n= bsp; 
--------------------------------+---------------------------= ----------------
Currently RPL requires one DAO per = message.

JP's proposal below:

Hi = Jonathan,

What I was referring to was to pack prefix in DAO, a = very light change in
the spec (just make use of TLV) and factor = the common fields. This allows
to reduce the number of packets = very significantly as we get closer to the
root.

There = two benefits here:
1) You send one DAO between C and D instead = of 3
2) You can also pack the Reverse Route Stack whenever = possible for all
prefix sharing the same routes.

Let's = suppose that:
1) X advertises two prefixes X1 and X2
2) Y = advertises two prefixes Y1, Y2 and Y3
3) Z advertised one = prefix: Z1

Instead of sending 6 DAO, C would send one DAO to D = would look like this:
X1,X2[XBC], Y1,Y2,Y3[YBC], = Z1[ZBC]

Note that you could when possible also aggregates = prefixes at the same
time if they share a common = path.

BAck to you timing question Richard, it depends of = the sequence of events
but there is no need to wait.
C could = start with one DAO and then start to pack at it receives more, = the
same reasoning applies to other
nodes.

Others, thoughts = ?

Thanks.

JP.

--
Ticket URL: <https://svn.too= ls.ietf.org/wg/roll/trac/ticket/11>
roll <http://tools.ietf.org/wg/roll/= >



= --Apple-Mail-207-389501782-- From mcr@marajade.sandelman.ca Tue Nov 10 08:25:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC373A6B2B for ; Tue, 10 Nov 2009 08:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=0.810, 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 fuhLlYoRHBXh for ; Tue, 10 Nov 2009 08:25:15 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3C5133A6B20 for ; Tue, 10 Nov 2009 08:25:14 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E4746342BA; Tue, 10 Nov 2009 11:16:43 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 904294E792; Tue, 10 Nov 2009 11:25:40 -0500 (EST) From: Michael Richardson To: draft-ietf-roll-routing-metrics@tools.ietf.org, roll@ietf.org In-Reply-To: References: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Nov 2009 11:25:40 -0500 Message-ID: <7815.1257870340@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] numeric ranges in routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 16:25:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "edward" == edward j beroset writes: edward> I mentioned it during the roll meeting Tuesday, but I think edward> it's probably worth documenting the thought in a little more edward> technical detail. The routing metrics right now include edward> 32-bit floating point numbers for latency and throughput. edward> Since these numbers are much more likely to be added or edward> compared rather than multiplied, fixed point rather than edward> floating point is likely to be a better choice of I mostly agree, but gotta point out this is a bike shed. If we can agree that, should we need sub-milisecond latencies in the future (when RPL is used by dust-mote nanites..) that we would simply create a new metric with different units. edward> which is probably not practical. If instead, latency were a edward> 32-bit unsigned integer in units of milliseconds, we'd still edward> be able to go from 0 or 1 milliseconds up to almost 1200 edward> hours if my math is right. That should be plenty for any edward> practical network. I haven't done so but I suspect that we edward> could do the same thing with throughput. If we express throughput as a power of 2, then likely 8 bits works! That gives us values from 2^0=1 bits/second to 2^(256)=10^77 bits/second. If we use 32-bits as integer, in units of kilobits, we get 1kbit/second up to 4 terabits/second, also acceptable. But, this is NOT the interesting question. We also need to think about the error bar/stddev on the numbers!!! The question is: what metrics do we need, how many can be determined at runtime (without explicit configuration), what are the errors on the numbers, and what are the formulae that put them together. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvmUA4CLcPvd0N1lAQKXKgf+O6qwWeQoy3GoWTdtoLNhxULhgGNZC2MT /rrCrmgqpNgNjTQjNsjN7HHem/HL5/smtVVr57QvXRXoxyxI6yZARuMNcX6Wktg0 iioSWBGCd5gcnHibBGCV5r8DddvG2ERdPmKwasQpg+CdMS3wHiiMGE8bnfpJxzOz wThx10BouQZiTeEhkyKPnX+jlEMlNBpzOEGyxx0x3ezfKxy+RRTPT91zzLwEXf9M 62awStsqtWO207gWC5y7Z0a0zXzyxpNjk6rddt28+7zLSQ/jRm6fdZ5lUKeeCG/A ilimAVAF9X1kgtl3okamrSjOdaj4huCn+QHbpYb27tihav1RPsO0MQ== =cc43 -----END PGP SIGNATURE----- From Ted.Humpal@jci.com Tue Nov 10 09:25:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF1328C1FD; Tue, 10 Nov 2009 09:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[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 3X9ANiqDtNJj; Tue, 10 Nov 2009 09:25:34 -0800 (PST) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with ESMTP id 2F1A428C1ED; Tue, 10 Nov 2009 09:25:34 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKSvmiJLM9PkuwjA3WsIPtd/fnLJsa0HSt@postini.com; Tue, 10 Nov 2009 09:26:02 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111011280046-2612264 ; Tue, 10 Nov 2009 11:28:00 -0600 In-Reply-To: References: <2688C8B62E034D24A04877BF564B96C1@your029b8cecfe> To: edward.j.beroset@us.elster.com MIME-Version: 1.0 X-KeepSent: 9F745D1C:31B69689-8625766A:005F834F; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 CCH3 December 30, 2008 From: Ted.Humpal@jci.com Message-ID: Date: Tue, 10 Nov 2009 11:25:43 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/10/2009 11:25:51 AM, Serialize complete at 11/10/2009 11:25:51 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/10/2009 11:28:00 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/10/2009 11:28:10 AM, Serialize complete at 11/10/2009 11:28:10 AM Content-Type: text/html; charset="US-ASCII" Cc: roll-bounces@ietf.org, draft-ietf-roll-routing-metrics@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] floating point in low end devices X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 17:25:35 -0000
Not to mention that some of the base hardware platforms that may be used  - -  do not support 32 bit floating point in certain markets.


Ted


From: edward.j.beroset@us.elster.com
To: draft-ietf-roll-routing-metrics@tools.ietf.org, roll@ietf.org
Date: 11/10/2009 09:20 AM
Subject: [Roll] numeric ranges in routing metrics





I mentioned it during the roll meeting Tuesday, but I think it's probably worth documenting the thought in a little more technical detail.  The routing metrics right now include 32-bit floating point numbers for latency and throughput.  Since these numbers are much more likely to be added or compared rather than multiplied, fixed point rather than floating point is likely to be a better choice of representation.  For example, for normalized positive 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and the minimum is about 1.2e-38.  For reference, the age of universe in milliseconds (taking the high end of NASA's most recent estimate) is only 4.4e20 and the time it takes to travel the distance across an electron (Lorentz diameter for you physics heads) is about 1.9e-20 ms.  A negative latency would seem to imply that packets appear before they're sent which is probably not practical.  If instead, latency were a 32-bit unsigned integer in units of milliseconds, we'd still be able to go from 0 or 1 milliseconds up to almost 1200 hours if my math is right.  That should be plenty for any practical network.  I haven't done so but I suspect that we could do the same thing with throughput.

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

From richard.kelsey@ember.com Tue Nov 10 09:39:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40D23A698D for ; Tue, 10 Nov 2009 09:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 LzGg1KgZihWR for ; Tue, 10 Nov 2009 09:39:47 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 307583A6B5E for ; Tue, 10 Nov 2009 09:39:46 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:41:39 -0500 Date: Tue, 10 Nov 2009 12:37:01 -0500 Message-Id: <874op2l1s2.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> (message from JP Vasseur on Tue, 10 Nov 2009 12:43:37 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> X-OriginalArrivalTime: 10 Nov 2009 17:41:39.0179 (UTC) FILETIME=[0E9E5BB0:01CA622D] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 17:39:47 -0000 From: JP Vasseur Date: Tue, 10 Nov 2009 12:43:37 +0100 We need to clarify that when a node jumps to a better parent (higher rank), it can of course jump at any time since there is no risk of loops, but it must also poison up (send a no-DIO) to the previous parent. JP, Unfortunately, it isn't that simple. The problem is that some nodes may be caching DIO data while others are not. If a node jumps to a new parent, whether up or down, the issue is whether or not this causes the moving node's DIO to be cached by a different ancestor. - If the DIO is still cached by the same ancestor, then the moving node just has to send a new DIO to its new parent and all will be well. - If the DIO is now cached by a different ancestor, then the moving node needs to send a no-DIO before moving and it and all its descendants must send new DIOs after the move. Not only is the second case potentially quite costly, but there is currently no way for a node to know which case applies to a given move. -Richard Kelsey From jabeille@cisco.com Tue Nov 10 13:29:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5E03A682D for ; Tue, 10 Nov 2009 13:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.934 X-Spam-Level: X-Spam-Status: No, score=-7.934 tagged_above=-999 required=5 tests=[AWL=-1.335, 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 yl4EST4TMY8J for ; Tue, 10 Nov 2009 13:29:24 -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 91A073A67C2 for ; Tue, 10 Nov 2009 13:29:23 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from syd-iport-2.cisco.com ([64.104.193.197]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 21:29:50 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK9p+UqQ/uCW/2dsb2JhbADGU5hBhD4E X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="59704220" Received: from ams-core-1.cisco.com ([144.254.224.150]) by syd-iport-2.cisco.com with ESMTP; 10 Nov 2009 21:29:49 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAALTliA007820; Tue, 10 Nov 2009 21:29:47 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:29:47 +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: Tue, 10 Nov 2009 22:27:15 +0100 Message-ID: In-Reply-To: <874op2l1s2.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Something to ADD Thread-Index: AcpiLN/6DAEdxabcR0GbeR+ndioBcQAH3qxw References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Richard Kelsey" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 10 Nov 2009 21:29:47.0892 (UTC) FILETIME=[EDBA3340:01CA624C] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 21:29:25 -0000 Hi all, We are talking about DAOs I guess, not DIOs. I am not sure I understand the issue Richard. To me the no-DAO should travel up following the prefered parents path, removing all DAO states if any. Julien =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: mardi 10 novembre 2009 18:37 > To: JP Vasseur (jvasseur) > Cc: roll@ietf.org > Subject: Re: [Roll] Something to ADD >=20 >=20 > From: JP Vasseur > Date: Tue, 10 Nov 2009 12:43:37 +0100 >=20 > We need to clarify that when a node jumps to a better=20 > parent (higher =20 > rank), it can of course jump at any time since there is no=20 > risk of =20 > loops, but it must also poison up (send a no-DIO) to the previous =20 > parent. >=20 > JP, >=20 > Unfortunately, it isn't that simple. The problem is that=20 > some nodes may be caching DIO data while others are not. > If a node jumps to a new parent, whether up or down, the=20 > issue is whether or not this causes the moving node's DIO to=20 > be cached by a different ancestor. >=20 > - If the DIO is still cached by the same ancestor, > then the moving node just has to send a new DIO > to its new parent and all will be well. >=20 > - If the DIO is now cached by a different ancestor, > then the moving node needs to send a no-DIO before > moving and it and all its descendants must send > new DIOs after the move. >=20 > Not only is the second case potentially quite costly, but=20 > there is currently no way for a node to know which case=20 > applies to a given move. >=20 > -Richard Kelsey=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Tue Nov 10 14:01:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823E03A693B for ; Tue, 10 Nov 2009 14:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.768 X-Spam-Level: X-Spam-Status: No, score=-7.768 tagged_above=-999 required=5 tests=[AWL=-1.169, 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 QZ-Yk2wlC7QG for ; Tue, 10 Nov 2009 14:01:51 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B58C53A67F1 for ; Tue, 10 Nov 2009 14:01:51 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB5y+UqrRN+J/2dsb2JhbADGM5g/hD4E X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="269132740" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2009 22:02:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAAM2IFo018319; Tue, 10 Nov 2009 22:02:19 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 23:02:18 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 23:02:17 +0100 Message-Id: <2F2A0FC0-2F20-480C-A567-5D8C6343B410@cisco.com> From: JP Vasseur To: "Julien Abeille (jabeille)" , Richard Kelsey In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 23:02:17 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 22:02:17.0794 (UTC) FILETIME=[77F5A220:01CA6251] Cc: roll WG Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 22:01:52 -0000 rrr ... yes my bad, second time I make that typo, I meant DAO of course. On Nov 10, 2009, at 10:27 PM, Julien Abeille (jabeille) wrote: > Hi all, > > We are talking about DAOs I guess, not DIOs. I am not sure I > understand > the issue Richard. To me the no-DAO should travel up following the > prefered parents path, removing all DAO states if any. > > Julien > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Richard Kelsey >> Sent: mardi 10 novembre 2009 18:37 >> To: JP Vasseur (jvasseur) >> Cc: roll@ietf.org >> Subject: Re: [Roll] Something to ADD >> >> >> From: JP Vasseur >> Date: Tue, 10 Nov 2009 12:43:37 +0100 >> >> We need to clarify that when a node jumps to a better >> parent (higher >> rank), it can of course jump at any time since there is no >> risk of >> loops, but it must also poison up (send a no-DIO) to the previous >> parent. >> >> JP, >> >> Unfortunately, it isn't that simple. The problem is that >> some nodes may be caching DIO data while others are not. >> If a node jumps to a new parent, whether up or down, the >> issue is whether or not this causes the moving node's DIO to >> be cached by a different ancestor. >> >> - If the DIO is still cached by the same ancestor, >> then the moving node just has to send a new DIO >> to its new parent and all will be well. >> >> - If the DIO is now cached by a different ancestor, >> then the moving node needs to send a no-DIO before >> moving and it and all its descendants must send >> new DIOs after the move. >> >> Not only is the second case potentially quite costly, but >> there is currently no way for a node to know which case >> applies to a given move. >> >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> From trac@tools.ietf.org Tue Nov 10 14:14:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AD23A6B65 for ; Tue, 10 Nov 2009 14:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, MANGLED_STOP=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZbsrkjyRotm for ; Tue, 10 Nov 2009 14:14:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 09E0E3A6A3E for ; Tue, 10 Nov 2009 14:14:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7yyx-000121-Se; Tue, 10 Nov 2009 14:14:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: joakime@sics.se X-Trac-Project: roll Date: Tue, 10 Nov 2009 22:14:35 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/15 Message-ID: <057.91a0dc0643969b3a1f112b3cac4096e0@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: joakime@sics.se, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #15: Inconsistent prefix-length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:14:08 -0000 #15: Inconsistent prefix-length --------------------------------+------------------------------------------- Reporter: joakime@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: destination prefix length --------------------------------+------------------------------------------- The prefix length for a DAG Destination Prefix is specified as 8-bits long in the figure (7) and as 16-bits in the text (5.1.3.1.1.5 / top of page 26). The value should be changed to 8-bits in the text section. -- Ticket URL: roll From richard.kelsey@ember.com Tue Nov 10 15:00:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABD23A6960 for ; Tue, 10 Nov 2009 15:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 CjbQpm+VKKe0 for ; Tue, 10 Nov 2009 15:00:33 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 739C13A691F for ; Tue, 10 Nov 2009 15:00:33 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 18:02:26 -0500 Date: Tue, 10 Nov 2009 17:57:47 -0500 Message-Id: <87hbt22djo.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 10 Nov 2009 23:02:26.0506 (UTC) FILETIME=[DEEB62A0:01CA6259] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Nov 2009 23:00:34 -0000 Date: Tue, 10 Nov 2009 22:27:15 +0100 From: "Julien Abeille (jabeille)" We are talking about DAOs I guess, not DIOs. Yes. I am not sure I understand the issue Richard. To me the no-DAO should travel up following the prefered parents path, removing all DAO states if any. Yes, and then after the move the new DAO follows the new prefered parents' path. Neither has any affect on nodes that do not cache DAO information. If the set of nodes that do cache DAO information does not change, then there is no need for the no-DAO. Here is an example. We start with this, where A is the root: A / \ B C | D | E Now D moves to C as its parent: A / \ B C | D | E If only A caches DAO data, then all D needs to do is send a DAO after the move. A receives it and changes its next hop for D and E to be C. If B and C both cache DAO data, then D needs to send a no-DAO before the move, to update B, and both D and E need to send DAOs after the move, so that C knows that it has downward paths to both of them. -Richard Kelsey From pierre.colle@fr.schneider-electric.com Tue Nov 10 22:15:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8886728C29B for ; Tue, 10 Nov 2009 22:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gclfvBjy4VcM for ; Tue, 10 Nov 2009 22:15:45 -0800 (PST) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 7F6AC28C2BE for ; Tue, 10 Nov 2009 22:15:45 -0800 (PST) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2009111107161312-2737 ; Wed, 11 Nov 2009 07:16:13 +0100 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Wed, 11 Nov 2009 07:16:05 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 11/11/2009 07:16:12, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/11/2009 07:16:13 AM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/11/2009 07:16:14 AM, Serialize complete at 11/11/2009 07:16:14 AM Content-type: multipart/alternative; Boundary="0__=4EBBFCF8DFB1E8E48f9e8a93df938690918c4EBBFCF8DFB1E8E4" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:15:50 -0000 --0__=4EBBFCF8DFB1E8E48f9e8a93df938690918c4EBBFCF8DFB1E8E4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 10/11/2009 de retour le 16/11/2009. I am currently out of the office. You might contact my manager Didier Pellegrin regarding HOMES project. Best regards, Pierre = --0__=4EBBFCF8DFB1E8E48f9e8a93df938690918c4EBBFCF8DFB1E8E4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 10/11/2009 de retour le 16/11/200= 9.

I am currently out of the office. You might contact my manager Didier P= ellegrin regarding HOMES project.

Best regards,

Pierre

= --0__=4EBBFCF8DFB1E8E48f9e8a93df938690918c4EBBFCF8DFB1E8E4-- From jabeille@cisco.com Wed Nov 11 00:42:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEEF3A695C for ; Wed, 11 Nov 2009 00:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.909 X-Spam-Level: X-Spam-Status: No, score=-7.909 tagged_above=-999 required=5 tests=[AWL=-1.310, 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 iGRspQ-XN-yw for ; Wed, 11 Nov 2009 00:42:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 767173A6822 for ; Wed, 11 Nov 2009 00:42:51 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFsI+kqrR7Ht/2dsb2JhbADDd5g2hDwE X-IronPort-AV: E=Sophos;i="4.44,722,1249257600"; d="scan'208";a="429811086" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 08:43:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB8gcQJ015991; Wed, 11 Nov 2009 08:43:07 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:42:54 +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: Wed, 11 Nov 2009 09:42:45 +0100 Message-ID: In-Reply-To: <87hbt22djo.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Something to ADD Thread-Index: AcpiWg+9kARijvEOTMmiyilLh1FTFwAUIJeg References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Richard Kelsey" X-OriginalArrivalTime: 11 Nov 2009 08:42:54.0034 (UTC) FILETIME=[F5BE6B20:01CA62AA] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 08:42:52 -0000 Hi Richard, I get your point. There may be cases where no DAO is not needed. However in the example D cannot know this. Hence I guess we have to do it anyway? Best, Julien=20 > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com]=20 > Sent: mardi 10 novembre 2009 23:58 > To: Julien Abeille (jabeille) > Cc: JP Vasseur (jvasseur); roll@ietf.org > Subject: Re: [Roll] Something to ADD >=20 >=20 > Date: Tue, 10 Nov 2009 22:27:15 +0100 > From: "Julien Abeille (jabeille)" >=20 > We are talking about DAOs I guess, not DIOs. >=20 > Yes. >=20 > I am not sure I understand > the issue Richard. To me the no-DAO should travel up following the > prefered parents path, removing all DAO states if any. >=20 > Yes, and then after the move the new DAO follows the new=20 > prefered parents' path. Neither has any affect on nodes that=20 > do not cache DAO information. If the set of nodes that do=20 > cache DAO information does not change, then there is no need=20 > for the no-DAO. >=20 > Here is an example. We start with this, where A is the root: >=20 > A > / \ > B C > | > D > | > E >=20 > Now D moves to C as its parent: >=20 > A > / \ > B C > | > D > | > E >=20 > If only A caches DAO data, then all D needs to do is send a=20 > DAO after the move. A receives it and changes its next hop=20 > for D and E to be C. >=20 > If B and C both cache DAO data, then D needs to send a no-DAO=20 > before the move, to update B, and both D and E need to send=20 > DAOs after the move, so that C knows that it has downward=20 > paths to both of them. >=20 > -Richard Kelsey >=20 From richard.kelsey@ember.com Wed Nov 11 01:28:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487513A6C06 for ; Wed, 11 Nov 2009 01:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ZvvfJ+A0fe+T for ; Wed, 11 Nov 2009 01:28:56 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8AEF03A68B3 for ; Wed, 11 Nov 2009 01:28:49 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 04:30:43 -0500 Date: Wed, 11 Nov 2009 04:26:02 -0500 Message-Id: <87ljidpg45.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 11 Nov 2009 09:30:43.0255 (UTC) FILETIME=[A3EECC70:01CA62B1] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 09:28:57 -0000 Date: Wed, 11 Nov 2009 09:42:45 +0100 From: "Julien Abeille (jabeille)" I get your point. There may be cases where no DAO is not needed. However in the example D cannot know this. Hence I guess we have to do it anyway? Julien, If it were just one DAO it wouldn't matter much. The problem is that the entire sub-DAG under the moving node may need to send new DAOs. Or they may not. That is too much traffic to send after every move, just in case it is needed. The easy situation is when only the root stores DAOs, because then one new DAO is always enough. -Richard Kelsey From jabeille@cisco.com Wed Nov 11 06:26:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2803A6840 for ; Wed, 11 Nov 2009 06:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.884 X-Spam-Level: X-Spam-Status: No, score=-7.884 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, 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 pg9XR4ePAqkM for ; Wed, 11 Nov 2009 06:26:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D7A723A67DA for ; Wed, 11 Nov 2009 06:26:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAEdY+kqrR7H+/2dsb2JhbACCJyvCNZgdhDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208,217";a="430004916" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 14:26:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABEQeVp029384 for ; Wed, 11 Nov 2009 14:26:45 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:26:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62DA.FE233684" Date: Wed, 11 Nov 2009 15:26:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: trickle question Thread-Index: Acpi2vjanPhqwcklReuy0grf7DloCw== From: "Julien Abeille (jabeille)" To: "roll" X-OriginalArrivalTime: 11 Nov 2009 14:26:44.0218 (UTC) FILETIME=[FE4AADA0:01CA62DA] Subject: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 14:26:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62DA.FE233684 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 what happens if I expires when T is still running ------_=_NextPart_001_01CA62DA.FE233684 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 all,
 
what = happens if I=20 expires when T is still running
------_=_NextPart_001_01CA62DA.FE233684-- From jabeille@cisco.com Wed Nov 11 06:27:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F6E3A6860 for ; Wed, 11 Nov 2009 06:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8gOykWg3vk6 for ; Wed, 11 Nov 2009 06:27:56 -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 73F1F3A69EA for ; Wed, 11 Nov 2009 06:27:56 -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: AjoAAPtY+kqQ/uCWe2dsb2JhbACCJiyZQAEBFiQGqDyYHYQ8BA X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208,217";a="54162448" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 11 Nov 2009 14:28:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABESNpV008353 for ; Wed, 11 Nov 2009 14:28:23 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:28:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62DB.393155C6" Date: Wed, 11 Nov 2009 15:28:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: trickle question Thread-Index: Acpi2vjanPhqwcklReuy0grf7DloCwAAA1Aw From: "Julien Abeille (jabeille)" To: "Julien Abeille (jabeille)" , "roll" X-OriginalArrivalTime: 11 Nov 2009 14:28:23.0328 (UTC) FILETIME=[395DAA00:01CA62DB] Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 14:27:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62DB.393155C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 sorry, pressed send button to early: what happens if I expires when T is still running. the text says to reset T. I would let T expire and next time set it according to the potentially doubled value of I. =20 Julien ________________________________ From: Julien Abeille (jabeille)=20 Sent: mercredi 11 novembre 2009 15:27 To: roll Subject: trickle question =09 =09 Hi all, =20 what happens if I expires when T is still running ------_=_NextPart_001_01CA62DB.393155C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
sorry, pressed send button to = early:
what happens if I expires when T is still = running. the text=20 says to reset T. I would let T expire and next time set it according to = the=20 potentially doubled value of I.
 
Julien

From: Julien Abeille (jabeille)=20
Sent: mercredi 11 novembre 2009 15:27
To:=20 roll
Subject: trickle question

Hi=20 all,
 
what = happens if I=20 expires when T is still = running
------_=_NextPart_001_01CA62DB.393155C6-- From mcr@marajade.sandelman.ca Wed Nov 11 07:05:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247F23A67E5 for ; Wed, 11 Nov 2009 07:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_SBL=1.551] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9aDpLjfOOMM for ; Wed, 11 Nov 2009 07:05:18 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 277823A67DA for ; Wed, 11 Nov 2009 07:05:17 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id CCA76342D0; Wed, 11 Nov 2009 09:56:50 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 569E94E792; Wed, 11 Nov 2009 10:05:43 -0500 (EST) From: Michael Richardson To: Richard Kelsey In-Reply-To: <87ljidpg45.fsf@kelsey-ws.hq.ember.com> References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 11 Nov 2009 10:05:43 -0500 Message-ID: <10442.1257951943@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 15:05:19 -0000 {Richard, I wonder if you could use > or julien> when you quote, rather than three spaces?} >>>>> "Richard" == Richard Kelsey writes: Julien> I get your point. There may be cases where no DAO is not Julien> needed. However in the example D cannot know this. Hence I Julien> guess we have to do it anyway? Richard> Julien, Richard> If it were just one DAO it wouldn't matter much. The Richard> problem is that the entire sub-DAG under the moving node Richard> may need to send new DAOs. Or they may not. That is too Richard> much traffic to send after every move, just in case it is Richard> needed. Richard> The easy situation is when only the root stores DAOs, Richard> because then one new DAO is always enough. And, I think that lower-down nodes do not know who is storing DAOs, correct? Is this something that we should be adding to the protocol? Maybe it's enough for every node to increment a counter in the DIO if it stores DAOs? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Wed Nov 11 08:18:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F933A697F for ; Wed, 11 Nov 2009 08:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 xxgNzQDGWZDC for ; Wed, 11 Nov 2009 08:18:01 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 62BD43A6912 for ; Wed, 11 Nov 2009 08:18:01 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N8Ftt-0000tH-IL; Wed, 11 Nov 2009 08:18:29 -0800 Message-Id: From: Philip Levis To: "Julien Abeille (jabeille)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 08:18:30 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 16:18:02 -0000 On Nov 11, 2009, at 6:28 AM, Julien Abeille (jabeille) wrote: > Hi, > > sorry, pressed send button to early: > what happens if I expires when T is still running. the text says to > reset T. I would let T expire and next time set it according to the > potentially doubled value of I. The interval I can't expire while timer T is still running, as T is in the range of [I/2, I). (There's a typo in the draft). The one exception is when an event causes Trickle to reset I to I_min. But resetting I also resets T. Phil From pal@cs.stanford.edu Wed Nov 11 08:32:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E973A68A8 for ; Wed, 11 Nov 2009 08:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 BnCjIdwm2jZz for ; Wed, 11 Nov 2009 08:32:02 -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 0D4443A6897 for ; Wed, 11 Nov 2009 08:32:02 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N8G7S-0006HK-AP; Wed, 11 Nov 2009 08:32:30 -0800 Message-Id: <83693A31-E353-465A-84DD-D3373BCF9644@cs.stanford.edu> From: Philip Levis To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 08:32:30 -0800 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 16:32:02 -0000 On Nov 5, 2009, at 9:56 AM, Philip Levis wrote: > > On Oct 29, 2009, at 5:02 AM, roll issue tracker wrote: > >> #7: RPL bootstrap question: neighbor cache and DIOs dependency >> --------------------------------=20 >> +------------------------------------------- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +------------------------------------------- >> Email =46rom Julien >> >> Hi all, >> >> as explained in section 5.4.2 of RPL, a DIO must not be processed =20 >> if the >> source is not in the neighbor cache. The question is how do we =20 >> expect the >> neighbor cache to be filled? > > The current proposal is to change the direction of specification. > > Rather than state a node MUST NOT process a DIO if the SRC is not a =20= > candidate neighbor, the document will state that a node MUST process =20= > a DIO if the SRC is a candidate neighbor. This rewording also =20 > removes the problem of a node ignoring DIOs. > > Does anyone think this is not a good fix? What are people's opinions? Are there any objections to this fix for -05? If not, we'll apply it. Phil= From jabeille@cisco.com Wed Nov 11 10:10:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E6A3A680A for ; Wed, 11 Nov 2009 10:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.875 X-Spam-Level: X-Spam-Status: No, score=-9.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIvVk86YUoRS for ; Wed, 11 Nov 2009 10:10:00 -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 33DE528C133 for ; Wed, 11 Nov 2009 10:10:00 -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: AjgAAIuM+kqQ/uCWe2dsb2JhbACcEgEBFiQGqSqYGYQ8BIwZ X-IronPort-AV: E=Sophos;i="4.44,724,1249257600"; d="scan'208";a="54182173" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 11 Nov 2009 18:10:26 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABIAQis013391; Wed, 11 Nov 2009 18:10:26 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 19:10:26 +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: Wed, 11 Nov 2009 19:10:16 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] trickle question Thread-Index: Acpi6q0DH31ItSavR4OeVHc68CLdBQADytJQ References: From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 11 Nov 2009 18:10:26.0346 (UTC) FILETIME=[3E80E0A0:01CA62FA] Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 18:10:04 -0000 Hi Phil, I thought that when T expires, you restart T (without restarting I). Hence if e.g I compute T=3D 3/4I, start both I and T, after 3/4I, I restart T to e.g. 5/6I. After 1/4 I more, I expires, T is still running. Did I misunderstand? Best, Julien > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: mercredi 11 novembre 2009 17:19 > To: Julien Abeille (jabeille) > Cc: roll > Subject: Re: [Roll] trickle question >=20 >=20 > On Nov 11, 2009, at 6:28 AM, Julien Abeille (jabeille) wrote: >=20 > > Hi, > > > > sorry, pressed send button to early: > > what happens if I expires when T is still running. the text says to=20 > > reset T. I would let T expire and next time set it according to the=20 > > potentially doubled value of I. >=20 > The interval I can't expire while timer T is still running,=20 > as T is in the range of [I/2, I). (There's a typo in the draft). >=20 > The one exception is when an event causes Trickle to reset I=20 > to I_min. =20 > But resetting I also resets T. >=20 > Phil >=20 >=20 From pal@cs.stanford.edu Wed Nov 11 10:17:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C72B3A687D for ; Wed, 11 Nov 2009 10:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 G5Rf10l6IXCs for ; Wed, 11 Nov 2009 10:17:02 -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 779613A680A for ; Wed, 11 Nov 2009 10:17:02 -0800 (PST) Received: from dnab422037.stanford.edu ([171.66.32.55]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N8Hl4-0003Z5-Nt; Wed, 11 Nov 2009 10:17:30 -0800 Message-Id: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 10:17:30 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 18:17:03 -0000 On Nov 11, 2009, at 10:10 AM, Julien Abeille (jabeille) wrote: > Hi Phil, > > I thought that when T expires, you restart T (without restarting I). > Hence if e.g I compute T= 3/4I, start both I and T, after 3/4I, I > restart T to e.g. 5/6I. After 1/4 I more, I expires, T is still > running. > Did I misunderstand? Once T has fired, you don't restart it until a new interval begins (I expires or the trickle timer is reset). Phil From jabeille@cisco.com Wed Nov 11 13:13:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2FB3A69B8 for ; Wed, 11 Nov 2009 13:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.887 X-Spam-Level: X-Spam-Status: No, score=-7.887 tagged_above=-999 required=5 tests=[AWL=-1.288, 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 ONPNN7+eP5-x for ; Wed, 11 Nov 2009 13:13:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DC9EC3A6B38 for ; Wed, 11 Nov 2009 13:13:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACi4+kpAZnwN/2dsb2JhbADFR5gThDwEjBs X-IronPort-AV: E=Sophos;i="4.44,725,1249257600"; d="scan'208";a="67558257" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 21:13:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABLDvWO021785; Wed, 11 Nov 2009 21:13:57 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 22:13:55 +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: Wed, 11 Nov 2009 22:13:53 +0100 Message-ID: In-Reply-To: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] trickle question Thread-Index: Acpi+1Pt53HBVZLKQ5CB3WtMqdrSMgAGGwZg References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 11 Nov 2009 21:13:55.0502 (UTC) FILETIME=[E078C4E0:01CA6313] Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 21:13:32 -0000 Ok, thanks.=20 Julien=20 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: mercredi 11 novembre 2009 19:18 > To: Julien Abeille (jabeille) > Cc: roll > Subject: Re: [Roll] trickle question >=20 >=20 > On Nov 11, 2009, at 10:10 AM, Julien Abeille (jabeille) wrote: >=20 > > Hi Phil, > > > > I thought that when T expires, you restart T (without restarting I). > > Hence if e.g I compute T=3D 3/4I, start both I and T, after 3/4I, I=20 > > restart T to e.g. 5/6I. After 1/4 I more, I expires, T is still=20 > > running. > > Did I misunderstand? >=20 > Once T has fired, you don't restart it until a new interval=20 > begins (I expires or the trickle timer is reset). >=20 > Phil >=20 From wintert@acm.org Wed Nov 11 15:42:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3453A6B6B for ; Wed, 11 Nov 2009 15:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.181 X-Spam-Level: X-Spam-Status: No, score=-101.181 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, MANGLED_STOP=2.3, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDaYN3OwgrpN for ; Wed, 11 Nov 2009 15:42:25 -0800 (PST) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id 92B7F3A6B68 for ; Wed, 11 Nov 2009 15:42:25 -0800 (PST) Received: (qmail 22687 invoked from network); 11 Nov 2009 23:42:47 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 11 Nov 2009 15:42:46 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: giZqAkkVM1kXvwI7J9knS8zf_yXEfX_7KInYG.j_LRdZfH8.gDf1qrOqbbGI_6fbyFNt.59AdjDrg.0bYEjgyRc8Svt9JPZ8WxVyOnal.5cde2CF87R_kHOSvwZ9ZFZGx0PAiL7Y8TAGMUXRzdT1tMdZuCDru1ssabiV6zfj2uRdJpkidU92Ts7jTnyLRezAgPxzhF8HamNAiYGu9dN_37xRcg778v6Ada19Imyxd4OJ6eaXdQtawBbQGiUnfCsmpcLts6PWOTreTd9rXnHszXpVyA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFB4BF0.3050006@acm.org> Date: Wed, 11 Nov 2009 18:42:40 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: roll@ietf.org References: <057.91a0dc0643969b3a1f112b3cac4096e0@tools.ietf.org> In-Reply-To: <057.91a0dc0643969b3a1f112b3cac4096e0@tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #15: Inconsistent prefix-length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:42:26 -0000 This will be fixed in -05. -Tim roll issue tracker wrote: > #15: Inconsistent prefix-length > --------------------------------+------------------------------------------- > Reporter: joakime@… | Owner: > Type: defect | Status: new > Priority: minor | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: destination prefix length > --------------------------------+------------------------------------------- > The prefix length for a DAG Destination Prefix is specified as 8-bits long > in the figure (7) and as 16-bits in the text (5.1.3.1.1.5 / top of page > 26). The value should be changed to 8-bits in the text section. > From wintert@acm.org Wed Nov 11 16:04:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE6B3A69A3 for ; Wed, 11 Nov 2009 16:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.108 X-Spam-Level: X-Spam-Status: No, score=-101.108 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, MANGLED_YOUR=2.3, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-mA8tSUE+cJ for ; Wed, 11 Nov 2009 16:04:03 -0800 (PST) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id 04BF13A6B6C for ; Wed, 11 Nov 2009 16:03:52 -0800 (PST) Received: (qmail 80152 invoked from network); 12 Nov 2009 00:04:18 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 11 Nov 2009 16:04:18 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 52S5b2EVM1nVeA6bYODmn3sYHY8paVKHtBSaKkcVODRNIaq6tBKp0cfK1CjCffvTxLKuT7ojrusIZpZyPp5.GkSt55BnpBsxzIfDcT0PIWWJUIfPzhpzpCJPYlGN0azOB47jA8aw0pBEVekH6VwNCxzQ9.D7de8eFSvP_4l4_2R8AxZiEJFeWuvzmIsGMWdUwYu8Wo.OnzNBf_aGFAjkUmQQ8cszvNC6hPB.D07rWmH9.7qGIUxtaQVALHxeTaxkCESG8YvA21OWjRopF3q1_F2TGOuP0kRzJmG79vV1kyKpVkMJMypdCWnK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFB50FC.7050405@acm.org> Date: Wed, 11 Nov 2009 19:04:12 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Julien Abeille \(jabeille\)" References: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 00:04:04 -0000 Hi Julien, Julien Abeille (jabeille) wrote: > of course it needs jitter. Now trickle is armed anyway at all times > right (T timer). If we do not do anything specific, the DIO will not > come earlier with DIS than without... > So if no immediate response is needed, then DIS is not needed. I still > think it is, for instance anytime you lose you r last parent, and do not > want to wait possibly hours to get a DIO. This is the same as with RS/RA > (jittered !) > Yes, I agree DIS is needed also- and this is exactly how we got to DIS. It started by first allowing nodes to actively probe the neighborhood by using `RS' to solicit `RA-DIO'. from their neighborhood in previous RPL versions. This was thought to be useful, e.g., for battery powered nodes that do not want to wait. Now that RPL does not use RS/RA/NA we have introduced DIS for this exact purpose. > Resetting trickle (I to Imin, and T to random ) does not make sense I > guess, as sending a DIS does not always mean global instability. > Thoughts on how to arm a small jittered timer? It doesn't mean global instability- but it does mean that something has changed in the local neighborhood at least. So fair enough I think to reset trickle, to let trickle do it's job. I agree with prior comments- lets not make a special case here for DIS handling. The DIS should then also be multicast, and it should trigger multicast DIO responses. Regards, -Tim > > Best, > Julien > > ------------------------------------------------------------------------ > *From:* Pascal Thubert (pthubert) > *Sent:* lundi 9 novembre 2009 13:53 > *To:* Julien Abeille (jabeille); Philip Levis > *Cc:* ROLL WG > *Subject:* RE: [Roll] need clarification: DIS processing > > At the moment, I cannot figure when an immediate response would be > needed. > > > > I think Phil mentions that somewhere else as well. The idea would be > to arm trickle and let it time out. > > > > Also let us keep in mind that in networking at large, most timers > are jittered to avoid network synchronizations. In wireless, it is > even worse since as you point out, synchronization also means > collisions. > > > > Pascal > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Julien Abeille (jabeille) > *Sent:* lundi 2 novembre 2009 18:01 > *To:* ROLL WG > *Subject:* [Roll] need clarification: DIS processing > > > > Hi all, > > > > one question: > > when a router receives a DIS, should it answer right away? I guess > this is a good source of collision, so a random timer would help. > Could we set T to a random value between I_min /2 and I_Min, without > resetting I (receiving a DIS does not mean inconsistency)? > > > > Best, > > Julien > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Thu Nov 12 04:54:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B0028C15D for ; Thu, 12 Nov 2009 04:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.769 X-Spam-Level: X-Spam-Status: No, score=-6.769 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 LkN8DmNc3TXH for ; Thu, 12 Nov 2009 04:54:49 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9A27A3A68D5 for ; Thu, 12 Nov 2009 04:54:48 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: ATT1372924.txt : 127 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAEGU+0pAZnwN/2dsb2JhbACCJC0hwTiYAwKEOgQ X-IronPort-AV: E=Sophos;i="4.44,727,1249257600"; d="gif'147?txt'147?scan'147,208,217,147";a="67671731" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Nov 2009 12:55:16 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nACCt9ff016866 for ; Thu, 12 Nov 2009 12:55:16 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 13:55:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA6397.5EE2E164" Date: Thu, 12 Nov 2009 13:55:10 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEB6D8E2@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on parent / destination prefix / route removal Thread-Index: AcpccytsV946n2qGRMOOvMRn+icMYQHI8gsA From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 12 Nov 2009 12:55:11.0759 (UTC) FILETIME=[5EF1B1F0:01CA6397] Cc: ROLL WG Subject: [Roll] FW: Clarification on parent / destination prefix / route removal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 12:54:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6397.5EE2E164 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01CA6397.5EE2E164" ------_=_NextPart_002_01CA6397.5EE2E164 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CA6397.5EE2E164" ------_=_NextPart_003_01CA6397.5EE2E164 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 Are you already tracking this issue? I would appreciate some = clarification on how lifetimes are used / or not used... Best, Mathilde ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: mardi, 3. novembre 2009 11:48 To: roll Subject: [Roll] Clarification on parent / destination prefix / route = removal Hi All, =20 This is my current understanding: =20 - Parents are removed based on OF selection (decision to move within the = DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer = procedure described in section 5.10.1.1.1. This is essentially a keep = alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding = destination prefix is removed?=20 - When are routes corresponding to parents removed? Do they also have a = lifetime? - What happens when a neighbor disappears, are the corresponding = parents/destination/routes removed? =20 The current behavior seems quite asymmetric... There is some kind of = keep alive mechanism for destination prefixes, but not for parents. = There is a lifetime associated with routes corresponding to destination = prefixes but not for routes corresponding to parents. Is that a design = choice? I would appreciate some clarifications. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_003_01CA6397.5EE2E164 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP,
 
Are you already tracking this issue? I would = appreciate=20 some clarification on how lifetimes are used / or not=20 used...
Best,
Mathilde

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy=20 (mdurvy)
Sent: mardi, 3. novembre 2009 11:48
To:=20 roll
Subject: [Roll] Clarification on parent / destination = prefix /=20 route removal

Hi=20 All,
 
This = is my current=20 understanding:
 
- = Parents are=20 removed based on OF selection (decision to move within the DAG, change = DAG,=20 etc)
- = Destination=20 prefixes are removed after the retry / RemoveTimer procedure described = in=20 section 5.10.1.1.1. This is essentially a keep alive mechanism based on=20 DIO (D bit set) - DAO exchanges.
- = Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires? Are they also removed when the corresponding destination prefix = is=20 removed?
- When = are routes=20 corresponding to parents removed? Do they also have a=20 lifetime?
- What = happens when=20 a neighbor disappears, are the corresponding parents/destination/routes=20 removed?
 
The = current behavior=20 seems quite asymmetric... There is some kind of keep alive mechanism for = destination prefixes, but not for parents. There is a lifetime = associated with=20 routes corresponding to destination prefixes but not for routes = corresponding to=20 parents. Is that a design choice? I would appreciate some=20 clarifications.
 
Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_003_01CA6397.5EE2E164-- ------_=_NextPart_002_01CA6397.5EE2E164 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_002_01CA6397.5EE2E164 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_002_01CA6397.5EE2E164-- ------_=_NextPart_001_01CA6397.5EE2E164 Content-Type: text/plain; name="ATT1372924.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1372924.txt Content-Disposition: inline; filename="ATT1372924.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== ------_=_NextPart_001_01CA6397.5EE2E164-- From pal@cs.stanford.edu Thu Nov 12 08:11:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCA03A6C03 for ; Thu, 12 Nov 2009 08:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, MANGLED_YOUR=2.3, 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 EIxkZ2Amx0hQ for ; Thu, 12 Nov 2009 08:11:45 -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 ECC653A6BFB for ; Thu, 12 Nov 2009 08:11:45 -0800 (PST) Received: from dnab422172.stanford.edu ([171.66.33.114]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N8cHO-00011n-Vw; Thu, 12 Nov 2009 08:12:15 -0800 Message-Id: <70C68CFA-0C6C-42CA-88DB-14095D850096@cs.stanford.edu> From: Philip Levis To: Tim Winter In-Reply-To: <4AFB50FC.7050405@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 07:31:29 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> <4AFB50FC.7050405@acm.org> X-Mailer: Apple Mail (2.936) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 16:11:47 -0000 On Nov 11, 2009, at 4:04 PM, Tim Winter wrote: > Hi Julien, > > Julien Abeille (jabeille) wrote: >> of course it needs jitter. Now trickle is armed anyway at all times >> right (T timer). If we do not do anything specific, the DIO will not >> come earlier with DIS than without... >> So if no immediate response is needed, then DIS is not needed. I >> still >> think it is, for instance anytime you lose you r last parent, and >> do not >> want to wait possibly hours to get a DIO. This is the same as with >> RS/RA >> (jittered !) >> > > Yes, I agree DIS is needed also- and this is exactly how we got to > DIS. It > started by first allowing nodes to actively probe the neighborhood > by using > `RS' to solicit `RA-DIO'. from their neighborhood in previous RPL > versions. > This was thought to be useful, e.g., for battery powered nodes that > do not > want to wait. Now that RPL does not use RS/RA/NA we have introduced > DIS for > this exact purpose. > >> Resetting trickle (I to Imin, and T to random ) does not make sense I >> guess, as sending a DIS does not always mean global instability. >> Thoughts on how to arm a small jittered timer? > > It doesn't mean global instability- but it does mean that something > has > changed in the local neighborhood at least. So fair enough I think > to reset > trickle, to let trickle do it's job. I agree with prior comments- > lets not > make a special case here for DIS handling. I think that the Trickle text in the draft presents it in a narrower light than which it's been used for routing protocols. A CTP node, for example, resets the Trickle timer on three conditions: 1. It receives a packet to forward whose transmitter's routing cost <= the receiver's routing cost. 2. It receives a packet with the "P" bit set (the equivalent of a DIS). 3. Its cost decreases significantly. We've all been discussing 1. But let's no forget conditions 2 and 3. For 2, a node does not have entries in its neighbor table, then one could say its logical topology is inconsistent with its physical topology. 3 is very much a performance optimization. It handles the case when a node might suddenly offer a much less expensive route than before, and its neighbors view of its cost is out-of-date enough that it might lead to sub-optimal behavior. My experience is that conditions 1 and 2 are both important, 3 is just a small optimization. Using an exponentially increasing timer (rather than just a jittered one) is critical. The reason is that, under sufficient density, a given jittered interval can be too small and lead to many collisions (don't forget we're LLNs, and so can be using low-power link layers that don't work that well under broadcast storms). If you go back to the Trickle paper, you'll note there were several experimental cases where propagation took more than one timer interval per hop due to collisions. Having an exponentially increasing timer solves this problem: if the optimal interval length is L, then nodes will find it in 2L, with a logarithmic message cost. This is part of what allows Trickle to adapt to thousand-fold changes in network density. > The DIS should then also be multicast, and it should trigger > multicast DIO > responses. Agreed. From trac@tools.ietf.org Thu Nov 12 08:21:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0026C28C1BA for ; Thu, 12 Nov 2009 08:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O-y6pU1KK3t for ; Thu, 12 Nov 2009 08:21:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4532228C12C for ; Thu, 12 Nov 2009 08:21:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8cRG-0003BX-7d; Thu, 12 Nov 2009 08:22:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 12 Nov 2009 16:22:26 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/16 Message-ID: <055.185662882dad797a3ef7925716daf473@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #16: Clarification on parent / destination prefix / route removal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:21:58 -0000 #16: Clarification on parent / destination prefix / route removal --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: mardi, 3. novembre 2009 11:48 To: roll Subject: [Roll] Clarification on parent / destination prefix / route removal Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO lifetime expires? Are they also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is that a design choice? I would appreciate some clarifications. Best, Mathilde -- Ticket URL: roll From trac@tools.ietf.org Thu Nov 12 11:48:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C66C3A6778 for ; Thu, 12 Nov 2009 11:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7XbX1cxABii for ; Thu, 12 Nov 2009 11:48:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7F58D3A67AC for ; Thu, 12 Nov 2009 11:48:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8ffZ-0006yN-JE; Thu, 12 Nov 2009 11:49:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 12 Nov 2009 19:49:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/10#comment:4 Message-ID: <064.d27a537e3f0e3d3a2a2bc7f3861dd2b2@tools.ietf.org> References: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:48:58 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: reopened Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: closed => reopened * resolution: fixed => -- Ticket URL: roll From jvasseur@cisco.com Thu Nov 12 11:50:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBCA3A6952 for ; Thu, 12 Nov 2009 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.752 X-Spam-Level: X-Spam-Status: No, score=-7.752 tagged_above=-999 required=5 tests=[AWL=-1.153, 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 ix-9dNgCq-zr for ; Thu, 12 Nov 2009 11:50:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BB36F3A691F for ; Thu, 12 Nov 2009 11:50:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPP1+0qrR7Hu/2dsb2JhbADFZJgZhDwE X-IronPort-AV: E=Sophos;i="4.44,730,1249257600"; d="scan'208";a="431171925" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2009 19:50:36 +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 nACJoWBD021762 for ; Thu, 12 Nov 2009 19:50:35 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 20:50:33 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 20:50:32 +0100 Message-Id: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 20:50:32 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Nov 2009 19:50:33.0050 (UTC) FILETIME=[6530EBA0:01CA63D1] Subject: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 19:50:07 -0000 Dear all, As a reminder Ticket #10 is related to a node behavior when receiving a DIO with an OF that it does not understand / support. There was a strong consensus for the following option: >> Option 1: The node simply joins the DAG as a leaf. In order words, >> the node has connectivity since it joins the DAG but will not act >> as a router for others since it does not understand the OF. Parent >> selection could be a simply a "random". Now the question is whether or not RPL mandates the support of OF0. Again two options: 1) We remove OF0 from the core spec. And nodes are free to implement the OF that they want 2) We do mandate for each node to support OF0 Pros/Cons: If the support of OF0 in no longer mandatory, nodes operating in an environment requiring a specific OF just have to implement that OF. On the other hand, when mixing nodes that do not support the same OF, they do not interoperate. An alternative if we decide to make OF0 non mandatory is to indicate in some applicability statement the applications that would require the support of OF0. Opinion ? Thanks. JP. From trac@tools.ietf.org Thu Nov 12 11:56:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C30D3A6778 for ; Thu, 12 Nov 2009 11:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRZ0V5VyKdvx for ; Thu, 12 Nov 2009 11:56:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id EEF8E3A67DD for ; Thu, 12 Nov 2009 11:56:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8fmg-00005C-9U; Thu, 12 Nov 2009 11:56:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 12 Nov 2009 19:56:46 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/7#comment:2 Message-ID: <064.71572c0068763634568ff8e6f61aeb2d@tools.ietf.org> References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:56:17 -0000 #7: RPL bootstrap question: neighbor cache and DIOs dependency --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by pal@…): * status: new => closed * resolution: => fixed Comment: The text in -05 will change from "If SRC is not a member of the candidate neighbor set, then the DIO is not eligible for further processing. (Further evaluation/ confidence of this neighbor is necessary)" to "If SRC is a member of the candidate neighbor set, then the node MUST process the DIO." -- Ticket URL: roll From richard.kelsey@ember.com Thu Nov 12 13:21:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653953A694F for ; Thu, 12 Nov 2009 13:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 mDf0aR-a2OiN for ; Thu, 12 Nov 2009 13:21:13 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 794BA3A6948 for ; Thu, 12 Nov 2009 13:21:13 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 16:23:09 -0500 Date: Thu, 12 Nov 2009 16:18:22 -0500 Message-Id: <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> To: Michael Richardson In-reply-to: <10442.1257951943@marajade.sandelman.ca> (message from Michael Richardson on Wed, 11 Nov 2009 10:05:43 -0500) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> X-OriginalArrivalTime: 12 Nov 2009 21:23:09.0365 (UTC) FILETIME=[55034E50:01CA63DE] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 21:21:14 -0000 > From: Michael Richardson > Date: Wed, 11 Nov 2009 10:05:43 -0500 > > Richard> The > Richard> problem is that the entire sub-DAG under the moving node > Richard> may need to send new DAOs. Or they may not. That is too > Richard> much traffic to send after every move, just in case it is > Richard> needed. > > Richard> The easy situation is when only the root stores DAOs, > Richard> because then one new DAO is always enough. > > And, I think that lower-down nodes do not know who is storing DAOs, correct? Correct. > Is this something that we should be adding to the protocol? At a minimum there should be a method for indicating when: - only the root stores DAOs - no node stores DAOs > Maybe it's enough for every node to increment a counter in the DIO if it > stores DAOs? The big issue is that having intermediate nodes store DAOs can have a big impact on the cost of switching parents. Given a choice between two new parents, you definitely want to pick the one that does not require that your entire sub-DAG send new DAOs. This has an impact for local repair, because the 'local' repair can become much less local in its effects. I think that we need to reexamine whether or not having intermediate nodes store DAOs is something that we need to support in the base protocol. -Richard Kelsey From mcr@marajade.sandelman.ca Thu Nov 12 13:35:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B973A694F for ; Thu, 12 Nov 2009 13:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcPJ1MvQQLDb for ; Thu, 12 Nov 2009 13:35:37 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C7BCC3A692B for ; Thu, 12 Nov 2009 13:35:37 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 2F1C6342E5 for ; Thu, 12 Nov 2009 16:27:18 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 3B8A14E794 for ; Thu, 12 Nov 2009 16:36:05 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 12 Nov 2009 16:36:05 -0500 Message-ID: <31012.1258061765@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Nov 2009 21:35:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" == Richard Kelsey writes: >> And, I think that lower-down nodes do not know who is storing >> DAOs, correct? Richard> Correct. >> Is this something that we should be adding to the protocol? Richard> At a minimum there should be a method for indicating when: Richard> - only the root stores DAOs Richard> - no node stores DAOs >> Maybe it's enough for every node to increment a counter in the >> DIO if it stores DAOs? I guess it might be enough to have a bit that gets turned by the first non-root node that stores DAOs. Richard> I think that we need to reexamine whether or not having Richard> intermediate nodes store DAOs is something that we need to Richard> support in the base protocol. If I understand correctly, if the intermediate nodes do not store DAOs, then they won't have a routing table to other peers, so p2p traffic will have to travel all the way up to the root and out again. It seemed to me like a compromise that the root had to be able to create source routes so that weaker intermediate nodes could avoid storing the DAOs. That this wasn't the ideal situation, but was a compromise. What happens if we insist all nodes store DAOs? (is it simpler?) What happens if we insist that no nodes store DAOs? (is it simpler?) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvx/xICLcPvd0N1lAQIq9gf/UkeqDJPANbSRKh+sgYmw1YP6DQRxwxyQ sc2kS2EawKLNCBoDhYrMxMEkM9HfnN8nS0Zz7tbeKN5jkqNmLhBOiDDk+oyTwhDh TsaHQ//QA+NFqkeGzBTo1TRgJhEAkw8VNtyy5Es2eGl3WQIaD2H8VxkFbhqpZRA+ ML5LjLSuqkOS5vPgxJem5jBQt1ESQVvgK9lvnXtbOYuHbKGWuX3qSCZgrGH2G6zf V54ttN6ryq2Qm2btWBafycfiDiruyYpYR+Wn0ApWxROir9G8rR0w1L8tkyF9ApdI mwEv9CKc/8zaGxgrGOLRBK81t+0OJwv2+0/zy2bWOjQJai9W8MlXRQ== =VSNn -----END PGP SIGNATURE----- From mcr@marajade.sandelman.ca Thu Nov 12 18:10:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8918C3A67B6 for ; Thu, 12 Nov 2009 18:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkKcpJWvFRQh for ; Thu, 12 Nov 2009 18:10:16 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 5C6783A697D for ; Thu, 12 Nov 2009 18:10:16 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id A4187342DF for ; Thu, 12 Nov 2009 21:01:58 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4476E4E793 for ; Thu, 12 Nov 2009 21:10:44 -0500 (EST) From: Michael Richardson To: roll WG In-Reply-To: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 12 Nov 2009 21:10:43 -0500 Message-ID: <5896.1258078243@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 02:10:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "JP" == JP Vasseur writes: JP> Now the question is whether or not RPL mandates the support of JP> OF0. JP> Again two options: JP> 1) We remove OF0 from the core spec. And nodes are free to JP> implement the OF that they want JP> 2) We do mandate for each node to support OF0 ... JP> If the support of OF0 in no longer mandatory, nodes operating in JP> an environment requiring a specific OF just have to implement JP> that OF. On the other hand, when mixing nodes that do not JP> support the same OF, they do not interoperate. What is the real code complexity of an OF? My impression is that it is not a lot of code. My opinion is that without a mandatory to implement set of options in the core specification, it is not a standard. There is ample experience within the IETF (and even more outside the IETF) with what happens when you do not have a mandatory to implement subset to guarantee interoperability. There will be many implementations which are created and sold as libraries and as part of commodity operating systems which will implement only the minimal subset. If OF0 is not required, it won't be there. If there is a subset of RPL use cases that do not need OF0, and for whom having that code present is make or break, then that group should write a standards track document which says what they need to implement. Those products will not declare themselves as "RFC1234"(RPL) compliant, but instead as "RFC2345"(pool-shed-light-switch-only). - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvzAIYCLcPvd0N1lAQJ6XAf/bwBVAnKJYc+U4IRAdIfqve9H8NAYwM// 248uvPfPb+IbBGblUO7EXOqw40RIj8nksJ0kEWKeZ6aH8OgAoew82KGxpRDEz8wD iOmjILPu1Vn+TUOw3hksoQB1ueIiZLAHJxOKhPudWGqOSjM5+ixiefVZ28bRAcgZ OI8mZtjnBa3+HUeBjXkALFvWRL9ifhzo3CebZs/YlyngtkJEIQLNxu3o2waCeANl VLyD+FFtJeal9P4et6J8200Q9BZ0D+uRDd1h5vRkXVogFLwq6OV7Yn0PwaZg4w2X dM9/u7lzCb3XL5KpBPp+k4Z+KogrN9T6nlIl39GycTABneUXIf/CWQ== =ddwI -----END PGP SIGNATURE----- From trac@tools.ietf.org Fri Nov 13 02:09:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B9B3A690F for ; Fri, 13 Nov 2009 02:09:15 -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.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3dRFi2qRtaf for ; Fri, 13 Nov 2009 02:09:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 910D73A67FF for ; Fri, 13 Nov 2009 02:09:14 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8t68-0007ju-Hp; Fri, 13 Nov 2009 02:09:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 13 Nov 2009 10:09:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/17 Message-ID: <055.17284056a1873989dfcef0e53c684a63@tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #17: Path Digest X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 10:09:15 -0000 #17: Path Digest --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- RPL allows source routing down the DAG. Typically, the source will be the root, and the destination a node somewhere down. The source route path might be strict or loose, depending on whether intermediate nodes can actually store states. a) We can choose between 2 models: keep intermediate SRP in the nodes down the DAG or only do LSRR from the root b) A source route path must be recomputed from the destination up when the path between the source and the destination changes. But there is no way for the destination to know that. That is what the digest was for -- Ticket URL: roll From pthubert@cisco.com Fri Nov 13 02:33:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010973A6959 for ; Fri, 13 Nov 2009 02:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.78 X-Spam-Level: X-Spam-Status: No, score=-7.78 tagged_above=-999 required=5 tests=[AWL=-1.181, 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 nRIjVwm8Ws-u for ; Fri, 13 Nov 2009 02:33:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9502C3A6979 for ; Fri, 13 Nov 2009 02:33:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAObE/EpAZnwN/2dsb2JhbAC8c4k7jm2EPASBbQ X-IronPort-AV: E=Sophos;i="4.44,735,1249257600"; d="scan'208";a="67851240" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Nov 2009 10:33:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nADAXUhA013136; Fri, 13 Nov 2009 10:33:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 11:33:32 +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, 13 Nov 2009 11:33:28 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DA361C4@XMB-AMS-107.cisco.com> In-Reply-To: <5896.1258078243@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on Ticket #10 Thread-Index: AcpkBp0s5RUHZfo2SFaZrUsyemfSwgAQ7RYQ References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <5896.1258078243@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "roll WG" X-OriginalArrivalTime: 13 Nov 2009 10:33:32.0653 (UTC) FILETIME=[BF7EC9D0:01CA644C] Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 10:33:06 -0000 Complete agreement with Michael.=20 RPL abstracts the OCP and enables a lot of freedom in supporting many of them. Consequently, a reasonable implementation will enable the additions/deletion of OCPs unless that's really impossible for that platform. Like a plugin in a web browser if you wish. So adding and removing OCP code should be similar to reconfiguring the device. If OCP0 (and/or whatever OCPs we place in the minimum Interop set) is not needed in a given deployment, it could be uninstalled by conscious choice. If devices are delivered partially preconfigured without OCP0 for a given application that does not require OCP0, I'd be fine, but: * the possibility to reinstall it on the device must exist. * standard devices with no configuration must work and interoperate out of the box (right now that means that OCP0 is the default OCP) Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson >Sent: vendredi 13 novembre 2009 03:11 >To: roll WG >Subject: Re: [Roll] Closing on Ticket #10 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "JP" =3D=3D JP Vasseur writes: > JP> Now the question is whether or not RPL mandates the support of > JP> OF0. > > JP> Again two options: > > JP> 1) We remove OF0 from the core spec. And nodes are free to > JP> implement the OF that they want > > JP> 2) We do mandate for each node to support OF0 > >... > > JP> If the support of OF0 in no longer mandatory, nodes operating in > JP> an environment requiring a specific OF just have to implement > JP> that OF. On the other hand, when mixing nodes that do not > JP> support the same OF, they do not interoperate. > >What is the real code complexity of an OF? >My impression is that it is not a lot of code. > >My opinion is that without a mandatory to implement set of options in >the core specification, it is not a standard. There is ample experience >within the IETF (and even more outside the IETF) with what happens when >you do not have a mandatory to implement subset to guarantee >interoperability. > >There will be many implementations which are created and sold as >libraries and as part of commodity operating systems which will >implement only the minimal subset. If OF0 is not required, it won't be >there. > >If there is a subset of RPL use cases that do not need OF0, and for whom >having that code present is make or break, then that group should write >a standards track document which says what they need to implement. Those >products will not declare themselves as "RFC1234"(RPL) compliant, but >instead as "RFC2345"(pool-shed-light-switch-only). > >- -- >] He who is tired of Weird Al is tired of life! | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Finger me for keys > >iQEVAwUBSvzAIYCLcPvd0N1lAQJ6XAf/bwBVAnKJYc+U4IRAdIfqve9H8NAYwM// >248uvPfPb+IbBGblUO7EXOqw40RIj8nksJ0kEWKeZ6aH8OgAoew82KGxpRDEz8wD >iOmjILPu1Vn+TUOw3hksoQB1ueIiZLAHJxOKhPudWGqOSjM5+ixiefVZ28bRAcgZ >OI8mZtjnBa3+HUeBjXkALFvWRL9ifhzo3CebZs/YlyngtkJEIQLNxu3o2waCeANl >VLyD+FFtJeal9P4et6J8200Q9BZ0D+uRDd1h5vRkXVogFLwq6OV7Yn0PwaZg4w2X >dM9/u7lzCb3XL5KpBPp+k4Z+KogrN9T6nlIl39GycTABneUXIf/CWQ=3D=3D >=3DddwI >-----END PGP SIGNATURE----- >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Fri Nov 13 07:25:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223793A686A for ; Fri, 13 Nov 2009 07:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 aaF296PdLuRi for ; Fri, 13 Nov 2009 07:25:02 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2F1D33A6933 for ; Fri, 13 Nov 2009 07:25:02 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 10:26:59 -0500 Date: Fri, 13 Nov 2009 10:22:10 -0500 Message-Id: <87r5s24fh9.fsf@kelsey-ws.hq.ember.com> To: Michael Richardson In-reply-to: <5896.1258078243@marajade.sandelman.ca> (message from Michael Richardson on Thu, 12 Nov 2009 21:10:43 -0500) From: Richard Kelsey References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <5896.1258078243@marajade.sandelman.ca> X-OriginalArrivalTime: 13 Nov 2009 15:26:59.0430 (UTC) FILETIME=[BDF3C060:01CA6475] Cc: roll@ietf.org Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 15:25:03 -0000 > From: Michael Richardson > Date: Thu, 12 Nov 2009 21:10:43 -0500 > What is the real code complexity of an OF? > My impression is that it is not a lot of code. If RPL turns out to be too complex for small devices, it will be because of lots of little requirements, no one of which necessitates a lot of code. > My opinion is that without a mandatory to implement set > of options in the core specification, it is not a > standard. There is ample experience within the IETF (and > even more outside the IETF) with what happens when you do > not have a mandatory to implement subset to guarantee > interoperability. Yes, but RPL isn't the end of the process. I can't see a consumer peering at a label to see if a wireless thermostat implements a particular RFC. By the time a thermostat gets to a shelf in a store a whole mess of protocols and settings will have been boiled down into one or two logos. We don't need to start that process here. > There will be many implementations which are created and > sold as libraries and as part of commodity operating > systems which will implement only the minimal subset. If > OF0 is not required, it won't be there. > > If there is a subset of RPL use cases that do not need > OF0, and for whom having that code present is make or > break, then that group should write a standards track > document which says what they need to implement. Given ROLL's charter, I think you have this the wrong way around. ROLL is intended for use in small devices with limited resources. If there is a subset of RPL use cases that need a generic, configurable implemenation of RPL, and for whom having that code present is acceptable, then that group should write a standards track document which says what they need to implement. -Richard Kelsey From mcr@marajade.sandelman.ca Fri Nov 13 07:57:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FB53A6AA2 for ; Fri, 13 Nov 2009 07:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm4oG7QWVIii for ; Fri, 13 Nov 2009 07:57:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4B1CF3A6A4F for ; Fri, 13 Nov 2009 07:57:03 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 7AE00342E1 for ; Fri, 13 Nov 2009 10:48:49 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4ED144E793 for ; Fri, 13 Nov 2009 10:57:33 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <87r5s24fh9.fsf@kelsey-ws.hq.ember.com> References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <5896.1258078243@marajade.sandelman.ca> <87r5s24fh9.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 13 Nov 2009 10:57:33 -0500 Message-ID: <9328.1258127853@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 15:57:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" == Richard Kelsey writes: >> There will be many implementations which are created and sold as >> libraries and as part of commodity operating systems which will >> implement only the minimal subset. If OF0 is not required, it >> won't be there. >> >> If there is a subset of RPL use cases that do not need OF0, and >> for whom having that code present is make or break, then that >> group should write a standards track document which says what >> they need to implement. Richard> Given ROLL's charter, I think you have this the wrong way Richard> around. ROLL is intended for use in small devices with Richard> limited resources. If there is a subset of RPL use cases Richard> that need a generic, configurable implemenation of RPL, and Richard> for whom having that code present is acceptable, then that Richard> group should write a standards track document which says Richard> what they need to implement. I hear you. The generic configurable implementation of RPL that I speak of will be sold by operating system vendors. I'm talking QNX, WindRiver, MonteVista, and a dozen other smaller vendors that sell toolkits. So, which requirement does this document satisfy? Is it: - building routing requirements ... - home routing requirements ... - indus routing requirements RFC 5673 - urban routing requirements RFC 5548 I also understand the comment about death by a thousand needle pricks. Will these four stated things be satisfied by a single OFx? Will there be four OFx? Or will many different ones be required for different situations? If there is no MUST for OF0, then we do not have anything we can interoperate with, and so we do not have an IETF standard. We might have four standards, and if so, that's fine, then let's be explicit about this. We have not discussed security very much yet. If there is not space for two OFx (OF0 and OFx) in the code space, then I wonder if there will be space for any security. As far as I can tell, RPL will suffer from all the constraints that SNMP* experienced with security. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSv2B6ICLcPvd0N1lAQKqHwgAhxq0jke2itgQ8QfaKQ4c4POlkWpLxR6t EfU+qdH4Ccjak16JtthNrnHc8xLgML/bFhdCp7su95SCbdHwj9b9jzAQsVV/0pLr mGj0onL/No6NHUONlcEjPDNoLPM4LEZjDde9BgcqaaKTkMKW9VWjaK2lK2OCfjol CnU8D2+tpNSiATj3HkUhsb2Gj70yagWmWI2OPxdPqP05huc6+UGYwPVKbnPcoGKm y01NHhRUY2/GkaoD8gV4JibBNU9dtXWZfnmMsXEkORuJGdSPh5xIXTSdERPJ2Sdm I2MjRESnKiebq4DWC3b7mInP99/wxbh586V7lIxT7nJX96V7orpmIw== =Q/U4 -----END PGP SIGNATURE----- From william.polk@nist.gov Tue Nov 10 20:29:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6F43A6930; Tue, 10 Nov 2009 20:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 INiRP1zMwRjR; Tue, 10 Nov 2009 20:29:49 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7288D3A6B8A; Tue, 10 Nov 2009 20:29:35 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nAB4TZoI026478; Tue, 10 Nov 2009 23:29:35 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 10 Nov 2009 23:29:27 -0500 From: "Polk, William T." To: Fred Baker , David R Oran , Richard Shockey , Russ Housley , Leslie Daigle , Sean Turner , Paul Hoffman , Henning Schulzrinne , Phil Roberts , "peter@peter-dambier.de" , "dcrocker@bbiw.net" , Hiroshi Esaki , Michael Dillon , Brian E Carpenter , Ralph Droms , IESG IESG , IAB IAB , "recipe@ietf.org" , Peny Yang , "roll@ietf.org" , "ietf@ietf.org" , "76attendees@ietf.org" <76attendees@ietf.org> Date: Tue, 10 Nov 2009 23:29:27 -0500 Thread-Topic: Updated logistics and agenda for Smart Grid Bar BOF at IETF 76 Thread-Index: AQHKYoeN3scbGz30kUqhMBqnssfDXw== Message-ID: 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Fri, 13 Nov 2009 08:26:51 -0800 Cc: "St. Pierre, James A." , "Dodson, Donna F." , "Su, David H." , "Golmie, Nada T." Subject: [Roll] Updated logistics and agenda for Smart Grid Bar BOF at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 04:29:50 -0000 [As before, my apologies for the shotgun nature of this email.] Folks, I would like to provide an update to the logistics and agenda for tonight's= Smart Grid Bar BOF. =20 The Bar BOF will begin at 8:30 so that folks attending the plenary have a c= hance to grab dinner. Note that the meeting room will be Acacia West (prio= r announcements indicated Acacia 1). Here is the current agenda.. Smart Grid Bar BOF Agenda 8:30PM - ?, Acacia West November 11, 2009 I. Agenda Bashing (5 minutes) Tim Polk II. Smart Grid Overview (15 minutes) Jim St. Pierre/Tim Polk III. Japanese Interest in Smart Grid (15 minutes) Hiroshi Esaki IV. Introduction to the IP Priority Action Plan (15 minutes) Tim Polk V. Discussion of draft-baker-ietf-core (15 minutes) Fred Baker see http://www.ietf.org/id/draft-baker-ietf-core-04.txt VI. Is the IETF the right place to do this work? Russ Housley VII. How should the work be organized? (contingent on V.) Ralph Droms Slides will be available via webex for remote participants, but we will be = using the IETF streaming audio feed for sound. The URLs for webex access h= ave been appended to this message. The audio feed for this session will be streamed at the following URL: http://videolab.uoregon.edu/events/ietf/ietf762.m3u Remote participants will not be able to speak, but can send comments and qu= estions in the webex chat room. Thanks, Tim Polk ----- webex access details ----- Frederick Baker invites you to attend this online meeting. Topic: Smart Grid Bar BOF in Hiroshima Date: Thursday, November 12, 2009 Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 205 017 176 Meeting Password: smartgrid ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D128776942&UID= =3D1209736217&PW=3DNYTMxMDcxYzMw&RT=3DMiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: smartgrid 4. Click "Join Now". To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=3D128776942&UID=3D12097362= 17&PW=3DNYTMxMDcxYzMw&ORT=3DMiM0OQ%3D%3D From fred@cisco.com Wed Nov 11 00:44:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818263A69DC; Wed, 11 Nov 2009 00:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KNP3eqNcfXB4; Wed, 11 Nov 2009 00:44:28 -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 840013A67F6; Wed, 11 Nov 2009 00:44:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,722,1249257600"; d="scan'208";a="48939407" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 08:44:51 +0000 Received: from host-24-88.meeting.ietf.org (tky-vpn-client-230-69.cisco.com [10.70.230.69]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB8if3n014228; Wed, 11 Nov 2009 08:44:48 GMT Message-Id: <10950D73-A043-479F-A3B6-228E9F842257@cisco.com> From: Fred Baker To: "Polk, William T." In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 17:44:47 +0900 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 13 Nov 2009 08:26:51 -0800 Cc: IETF-Discussion list , "Golmie, Nada T." , peter@peter-dambier.de, Phil Roberts , IESG IESG , ietf-smart-grid@googlegroups.com, Hiroshi Esaki , Henning Schulzrinne , recipe@ietf.org, "Dodson, Donna F." , roll@ietf.org, Russ Housley , Peny Yang , David R Oran , Richard Shockey , IAB IAB , Michael Dillon , Ralph Droms , Paul Hoffman , "Su, David H." , "St. Pierre, James A." , Leslie Daigle , Sean Turner , 76attendees@ietf.org, Brian E Carpenter , Dave CROCKER Subject: [Roll] Smart Grid "Bar BOF" Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 08:44:29 -0000 FYI - the slide decks in use for the Smart Grid "Bar BOF" are available at: ftp://ftpeng.cisco.com/fred/IETF-SG/ We will be running webex tonight, and slides are of course visible there as well. On Nov 11, 2009, at 1:29 PM, Polk, William T. wrote: > [As before, my apologies for the shotgun nature of this email.] > > Folks, > > I would like to provide an update to the logistics and agenda for > tonight's Smart Grid Bar BOF. > > The Bar BOF will begin at 8:30 so that folks attending the plenary > have a chance to grab dinner. Note that the meeting room will be > Acacia West (prior announcements indicated Acacia 1). > > Here is the current agenda.. > > Smart Grid Bar BOF Agenda > 8:30PM - ?, Acacia West > November 11, 2009 > > I. Agenda Bashing (5 minutes) > Tim Polk > II. Smart Grid Overview (15 minutes) > Jim St. Pierre/Tim Polk > III. Japanese Interest in Smart Grid (15 minutes) > Hiroshi Esaki > IV. Introduction to the IP Priority Action Plan (15 minutes) > Tim Polk > V. Discussion of draft-baker-ietf-core (15 minutes) > Fred Baker > see http://www.ietf.org/id/draft-baker-ietf-core-04.txt > VI. Is the IETF the right place to do this work? > Russ Housley > VII. How should the work be organized? (contingent on V.) > Ralph Droms > > Slides will be available via webex for remote participants, but we > will be using the IETF streaming audio feed for sound. The URLs for > webex access have been appended to this message. > > The audio feed for this session will be streamed at the following URL: > http://videolab.uoregon.edu/events/ietf/ietf762.m3u > Remote participants will not be able to speak, but can send comments > and questions in the webex chat room. > > Thanks, > > Tim Polk > > ----- webex access details ----- > > Frederick Baker invites you to attend this online meeting. > > Topic: Smart Grid Bar BOF in Hiroshima > Date: Thursday, November 12, 2009 > Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) > Meeting Number: 205 017 176 > Meeting Password: smartgrid > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&RT=MiM0OQ%3D%3D > 2. Enter your name and email address. > 3. Enter the meeting password: smartgrid > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&ORT=MiM0OQ%3D%3D > From fred@cisco.com Wed Nov 11 01:56:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5642D28C135; Wed, 11 Nov 2009 01:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.429 X-Spam-Level: X-Spam-Status: No, score=-107.429 tagged_above=-999 required=5 tests=[AWL=1.169, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 W-opP06x7YWo; Wed, 11 Nov 2009 01:56:09 -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 2391328C14F; Wed, 11 Nov 2009 01:56:09 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,722,1249257600"; d="scan'208,217";a="48943232" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 09:56:32 +0000 Received: from host-24-88.meeting.ietf.org (tky-vpn-client-230-1.cisco.com [10.70.230.1]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB9uSYf002250; Wed, 11 Nov 2009 09:56:28 GMT Message-Id: From: Fred Baker To: ietf-smart-grid@googlegroups.com, 76attendees@ietf.org In-Reply-To: <16C3F8D9-D90E-410F-9561-4D808FA418C9@standardstrack.com> Content-Type: multipart/alternative; boundary=Apple-Mail-140-453312703 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 18:56:26 +0900 References: <16C3F8D9-D90E-410F-9561-4D808FA418C9@standardstrack.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 13 Nov 2009 08:26:51 -0800 Cc: recipe@ietf.org, IETF-Discussion list , roll@ietf.org, IAB IAB , IESG IESG , "Golmie, Nada T." , "Su, David H." Subject: Re: [Roll] Updated logistics and agenda for Smart Grid Bar BOF at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 09:56:10 -0000 --Apple-Mail-140-453312703 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit There was an error in the reservation announcement. When I first set it up, I managed to hit the wrong date, and so I set up a correct one. The error was sent to the list earlier; it's still an error. oops Here is the correct data. Begin forwarded message: > From: Frederick Baker > Date: November 8, 2009 1:03:32 PM JST > To: fred@cisco.com > Subject: (Forward to attendees) Meeting invitation: Smart Grid IETF > "Bar" BOF > Reply-To: fred@cisco.com > > **** You can forward this email invitation to attendees **** > > Hello , > > Frederick Baker invites you to attend this online meeting. > > Topic: Smart Grid IETF "Bar" BOF > Date: Wednesday, November 11, 2009 > Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) > Meeting Number: 201 328 939 > Meeting Password: smartgrid > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&PW=NZTViNTIwYzFh&RT=MiM0OQ%3D%3D > 2. Enter your name and email address. > 3. Enter the meeting password: smartgrid > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&PW=NZTViNTIwYzFh&ORT=MiM0OQ%3D%3D > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San Jose/ > Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ciscosales.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > fred@cisco.com > 1-408-526 4257 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=OPRSuEQjxcIW1i8IRtMp/EUOrwEVTnOuxF2HObLGnx4=&RT=MiM0OQ%3D%3D > > The playback of UCF (Universal Communications Format) rich media > files requires appropriate players. To view this type of rich media > files in the meeting, please check whether you have the players > installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed > during the session to be recorded. By joining this session, you > automatically consent to such recordings. If you do not consent to > the recording, do not join the session. --Apple-Mail-140-453312703 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable There was an error in the = reservation announcement. When I first set it up, I managed to hit the = wrong date, and so I set up a correct one. The error was sent to the = list earlier; it's still an = error.

oops

Here is the = correct data.

Begin forwarded message:

From: Frederick = Baker <messenger@webex.com>
Date: November 8, = 2009 1:03:32 PM JST
Subject: (Forward = to attendees) Meeting invitation: Smart Grid IETF "Bar" = BOF

**** = You can forward this email invitation to attendees = **** 

Hello , 

Frederick Baker invites you to = attend this online meeting. 

Topic: Smart Grid IETF "Bar" = BOF 
Date: Wednesday, November 11, 2009 
Time: 8:00 pm, = Japan Time (Tokyo, GMT+09:00) 
Meeting Number: 201 328 = 939 
Meeting Password: = smartgrid 


-----------------------------------------------= -------- 
To join the online meeting (Now from iPhones = too!) 
-------------------------------------------------------&nbs= p;
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D12877= 6627&UID=3D0&PW=3DNZTViNTIwYzFh&RT=3DMiM0OQ%3D%3D 2. Enter your name and email address. 
3. Enter the meeting = password: smartgrid 
4. Click "Join Now". 

To view = in other time zones or languages, please click the link: 
https://ciscosales.webex.com/ciscosales/j.php?ED=3D12877= 6627&UID=3D0&PW=3DNZTViNTIwYzFh&ORT=3DMiM0OQ%3D%3D 
----------------------------------------------------------------&nbs= p;
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area = Codes 
-----------------------------------------------------------= ----- 

The affected toll free numbers are: (866) 432-9903 = for the San Jose/Milpitas area and (866) 349-3520 for the RTP = area. 

Please dial the local access number for your area = from the list below: 
- San Jose/Milpitas (408) area: = 525-6800 
- RTP (919) area: = 392-3330 

----------------------------------------------------= --- 
To join the teleconference = only 
------------------------------------------------------- = ;
1. Dial into Cisco WebEx (view all Global Access Numbers = at 
http://cisco.com/en/US/about/doing_business/conferencing= /index.html 
2. Follow the prompts to enter the Meeting = Number (listed above) or Access Code followed by the # = sign. 

San Jose, CA: +1.408.525.6800 RTP: = +1.919.392.3330 

US/Canada: +1.866.432.9903 United Kingdom: = +44.20.8824.0117 

India: +91.80.4350.1111 Germany: = +49.619.6773.9002 

Japan: +81.3.5763.9394 China: = +86.10.8515.5666 

--------------------------------------------= ----------- 
For = assistance 
------------------------------------------------------= - 
1. Go to https://ciscosales.webex.com/ciscosales/mc 
= 2. On the left navigation bar, click "Support". 

You can = contact me at: 
fred@cisco.com 
1-408-526 = 4257 

To add this meeting to your calendar program (for = example Microsoft Outlook), click this link: 
https://ciscosales.webex.com/ciscosales/j.php?ED=3D12877= 6627&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= OPRSuEQjxcIW1i8IRtMp/EUOrwEVTnOuxF2HObLGnx4=3D&RT=3DMiM0OQ%3D%3D&n= bsp;

The playback of UCF (Universal Communications Format) rich = media files requires appropriate players. To view this type of rich = media files in the meeting, please check whether you have the players = installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.= php 

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

<= a href=3D"http://www.webex.com/" = target=3D"_blank">http://www.webex.com 



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

= --Apple-Mail-140-453312703-- From stpeter@stpeter.im Wed Nov 11 03:54:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A8228C0FF; Wed, 11 Nov 2009 03:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 sbScOpKBar7m; Wed, 11 Nov 2009 03:54:41 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1B6AE3A6952; Wed, 11 Nov 2009 03:54:41 -0800 (PST) Received: from host-18-99.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E6AA940D09; Wed, 11 Nov 2009 04:45:08 -0700 (MST) Message-ID: <4AFAA3C3.8010208@stpeter.im> Date: Wed, 11 Nov 2009 20:45:07 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Fred Baker References: <10950D73-A043-479F-A3B6-228E9F842257@cisco.com> In-Reply-To: <10950D73-A043-479F-A3B6-228E9F842257@cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080203060408060201090303" X-Mailman-Approved-At: Fri, 13 Nov 2009 08:26:51 -0800 Cc: Dave CROCKER , recipe@ietf.org, "Dodson, Donna F." , Leslie Daigle , "Polk, William T." , IETF-Discussion list , Russ Housley , roll@ietf.org, ietf-smart-grid@googlegroups.com, peter@peter-dambier.de, Phil Roberts , "St. Pierre, James A." , IAB IAB , IESG IESG , Michael Dillon , "Golmie, Nada T." , Richard Shockey , 76attendees@ietf.org, "Su, David H." , Henning Schulzrinne Subject: Re: [Roll] [76attendees] Smart Grid "Bar BOF" Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Nov 2009 11:54:41 -0000 This is a cryptographically signed message in MIME format. --------------ms080203060408060201090303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Tim had some troubles setting up the WebEx conference, so we are using audio streaming, along with a Jabber chatroom here: xmpp:smartgrid@conference.jabber.org?join On 11/11/09 5:44 PM, Fred Baker wrote: > FYI - the slide decks in use for the Smart Grid "Bar BOF" are available at: > ftp://ftpeng.cisco.com/fred/IETF-SG/ > > We will be running webex tonight, and slides are of course visible there > as well. > > On Nov 11, 2009, at 1:29 PM, Polk, William T. wrote: > >> [As before, my apologies for the shotgun nature of this email.] >> >> Folks, >> >> I would like to provide an update to the logistics and agenda for >> tonight's Smart Grid Bar BOF. >> >> The Bar BOF will begin at 8:30 so that folks attending the plenary >> have a chance to grab dinner. Note that the meeting room will be >> Acacia West (prior announcements indicated Acacia 1). >> >> Here is the current agenda.. >> >> Smart Grid Bar BOF Agenda >> 8:30PM - ?, Acacia West >> November 11, 2009 >> >> I. Agenda Bashing (5 minutes) >> Tim Polk >> II. Smart Grid Overview (15 minutes) >> Jim St. Pierre/Tim Polk >> III. Japanese Interest in Smart Grid (15 minutes) >> Hiroshi Esaki >> IV. Introduction to the IP Priority Action Plan (15 minutes) >> Tim Polk >> V. Discussion of draft-baker-ietf-core (15 minutes) >> Fred Baker >> see http://www.ietf.org/id/draft-baker-ietf-core-04.txt >> VI. Is the IETF the right place to do this work? >> Russ Housley >> VII. How should the work be organized? (contingent on V.) >> Ralph Droms >> >> Slides will be available via webex for remote participants, but we >> will be using the IETF streaming audio feed for sound. The URLs for >> webex access have been appended to this message. >> >> The audio feed for this session will be streamed at the following URL: >> http://videolab.uoregon.edu/events/ietf/ietf762.m3u >> Remote participants will not be able to speak, but can send comments >> and questions in the webex chat room. >> >> Thanks, >> >> Tim Polk >> >> ----- webex access details ----- >> >> Frederick Baker invites you to attend this online meeting. >> >> Topic: Smart Grid Bar BOF in Hiroshima >> Date: Thursday, November 12, 2009 >> Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) >> Meeting Number: 205 017 176 >> Meeting Password: smartgrid >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from iPhones too!) >> ------------------------------------------------------- >> 1. Go to >> https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&RT=MiM0OQ%3D%3D >> >> 2. Enter your name and email address. >> 3. Enter the meeting password: smartgrid >> 4. Click "Join Now". >> >> To view in other time zones or languages, please click the link: >> https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&ORT=MiM0OQ%3D%3D >> >> > > _______________________________________________ > 76attendees mailing list > 76attendees@ietf.org > https://www.ietf.org/mailman/listinfo/76attendees --------------ms080203060408060201090303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMTExNDUwN1owIwYJKoZIhvcNAQkEMRYEFD4Te6b5HvgcNAFlVXCZ xnnIz2ooMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIVhCQqI9kYzBJhiLQiEC++kGlRUEYdNJawclH7xJ nfFlqNSZ0bQ+osBOkpBTGpzIGWqiOyIjUmgfgKy/GPN2UdMjoqr+IXEj1jSIn+rI47RuF1Rn +DD8pt3xsGq8O6ZjNvyCKlcCOrVWh3xDzXnCd5volY4MyZbDBhRLX+X7SO+XNBfRrCX1hY9m YWgQJpbgKokXMTB98JUPgev9Lcje3b7Ph9d+zl82Fbb5eZK6+zT3LCeeYvQEMT5dJjhK01rH CF3SNlWNVLzqPCca3EhEzJ2BgF/BlEUnCBqZCYiBFeqJJ60lCx5aICFpMJLCoWiDO3xHbmt6 i8f/z3zladl+PwAAAAAAAA== --------------ms080203060408060201090303-- From richard.kelsey@ember.com Fri Nov 13 10:16:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C98D3A699D for ; Fri, 13 Nov 2009 10:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 hYro-Oyq8TdJ for ; Fri, 13 Nov 2009 10:16:25 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id E803E3A696A for ; Fri, 13 Nov 2009 10:16:24 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 13:18:22 -0500 Date: Fri, 13 Nov 2009 13:13:32 -0500 Message-Id: <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> To: Michael Richardson In-reply-to: <9328.1258127853@marajade.sandelman.ca> (message from Michael Richardson on Fri, 13 Nov 2009 10:57:33 -0500) From: Richard Kelsey References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <5896.1258078243@marajade.sandelman.ca> <87r5s24fh9.fsf@kelsey-ws.hq.ember.com> <9328.1258127853@marajade.sandelman.ca> X-OriginalArrivalTime: 13 Nov 2009 18:18:22.0056 (UTC) FILETIME=[AEDFF680:01CA648D] Cc: roll@ietf.org Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 18:16:26 -0000 > From: Michael Richardson > Date: Fri, 13 Nov 2009 10:57:33 -0500 > > So, which requirement does this document satisfy? > Is it: - building routing requirements ... > - home routing requirements ... > - indus routing requirements RFC 5673 > - urban routing requirements RFC 5548 > > I also understand the comment about death by a thousand needle pricks. > Will these four stated things be satisfied by a single OFx? Will there > be four OFx? Or will many different ones be required for different > situations? My hope is that we will need no more than one or two OFxs. The reason we need to be flexible now is not that we are likely to need many of them, but that we don't know which ones are the right ones. > If there is no MUST for OF0, then we do not have anything we can > interoperate with, and so we do not have an IETF standard. We might > have four standards, and if so, that's fine, then let's be explicit > about this. Is there a problem with treating RPL and the metrics document as a single standard for the purposes of interoperation? RPL can state that there must be a single metric in use without saying which metric it is. > We have not discussed security very much yet. > > If there is not space for two OFx (OF0 and OFx) in the code space, There is space for two OFx if they are needed. There is no space for anything that is not needed, big or small. In the case of something like a consumer thermostat, I do not see any need for having both OF0 and a more nuanced metric. -Richard Kelsey From richard.kelsey@ember.com Fri Nov 13 11:40:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4521B3A6A67 for ; Fri, 13 Nov 2009 11:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 qckBFnHSFGvm for ; Fri, 13 Nov 2009 11:40:53 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5B18F3A693E for ; Fri, 13 Nov 2009 11:40:53 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 14:42:51 -0500 Date: Fri, 13 Nov 2009 14:38:00 -0500 Message-Id: <87my2q43mv.fsf@kelsey-ws.hq.ember.com> To: Michael Richardson In-reply-to: <31012.1258061765@marajade.sandelman.ca> (message from Michael Richardson on Thu, 12 Nov 2009 16:36:05 -0500) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> X-OriginalArrivalTime: 13 Nov 2009 19:42:51.0133 (UTC) FILETIME=[7C47BAD0:01CA6499] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 19:40:54 -0000 > From: Michael Richardson > Date: Thu, 12 Nov 2009 16:36:05 -0500 > > I guess it might be enough to have a bit that gets turned by the first > non-root node that stores DAOs. I think you need two bits. One is turned on by the root if it stores DAOs and the other is turned on by any intermediate node that stores them. > Richard> I think that we need to reexamine whether or not having > Richard> intermediate nodes store DAOs is something that we need to > Richard> support in the base protocol. > > If I understand correctly, if the intermediate nodes do not store DAOs, > then they won't have a routing table to other peers, so p2p traffic will > have to travel all the way up to the root and out again. Yes. On the other hand, the DAG formation mechanism works to maximize downward fanout, which in turn maximizes the number of P2P routes that go through the root even if all nodes store DAOs. For example, if the root has N children with roughly equal subgraphs, then each node can reach only 1/N of the network without through the root. > It seemed to me like a compromise that the root had to be able to create > source routes so that weaker intermediate nodes could avoid storing the > DAOs. That this wasn't the ideal situation, but was a compromise. > > What happens if we insist all nodes store DAOs? (is it simpler?) That uses too much RAM for us to require it. > What happens if we insist that no nodes store DAOs? (is it simpler?) Do you mean no nodes at all, or no nodes other than the root? If only the root stores DAOs, then most of the P2P traffic will go through the root. As I said above, this is often the case even if all node's store DAOs. I think this would be OK. Even without intermediate DAO storage, routing packets directly to neighbors will reduce the P2P messages traveling through the root. Devices that require more bandwidth (in or out) can become roots of their own DAGs, as long as the number of such devices is limited. -Richard Kelsey From jvasseur@cisco.com Fri Nov 13 13:27:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC8E3A68B7 for ; Fri, 13 Nov 2009 13:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.737 X-Spam-Level: X-Spam-Status: No, score=-9.737 tagged_above=-999 required=5 tests=[AWL=0.862, 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 bxqxhf7lwDII for ; Fri, 13 Nov 2009 13:27:04 -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 3AF173A6965 for ; Fri, 13 Nov 2009 13:27:04 -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: AkAAAGpe/UqQ/uCWe2dsb2JhbACcEwEBCwskBqFImBuEPAQ X-IronPort-AV: E=Sophos;i="4.44,739,1249257600"; d="scan'208";a="54366781" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2009 21:27:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nADLRXab021285; Fri, 13 Nov 2009 21:27:33 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 22:27:32 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 22:27:32 +0100 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87my2q43mv.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 13 Nov 2009 22:27:31 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Nov 2009 21:27:32.0449 (UTC) FILETIME=[1C3C7D10:01CA64A8] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 21:27:05 -0000 On Nov 13, 2009, at 8:38 PM, Richard Kelsey wrote: >> From: Michael Richardson >> Date: Thu, 12 Nov 2009 16:36:05 -0500 >> >> I guess it might be enough to have a bit that gets turned by the >> first >> non-root node that stores DAOs. > > I think you need two bits. One is turned on by the > root if it stores DAOs and the other is turned on by > any intermediate node that stores them. > >> Richard> I think that we need to reexamine whether or not having >> Richard> intermediate nodes store DAOs is something that we need >> to >> Richard> support in the base protocol. >> >> If I understand correctly, if the intermediate nodes do not store >> DAOs, >> then they won't have a routing table to other peers, so p2p traffic >> will >> have to travel all the way up to the root and out again. > > Yes. On the other hand, the DAG formation mechanism works > to maximize downward fanout, which in turn maximizes the > number of P2P routes that go through the root even if all > nodes store DAOs. For example, if the root has N children > with roughly equal subgraphs, then each node can reach only > 1/N of the network without through the root. > >> It seemed to me like a compromise that the root had to be able to >> create >> source routes so that weaker intermediate nodes could avoid storing >> the >> DAOs. That this wasn't the ideal situation, but was a compromise. >> >> What happens if we insist all nodes store DAOs? (is it simpler?) > > That uses too much RAM for us to require it. Yes I heard this for several chipsets too. > >> What happens if we insist that no nodes store DAOs? (is it simpler?) > > Do you mean no nodes at all, or no nodes other than the > root? > > If only the root stores DAOs, then most of the P2P traffic > will go through the root. As I said above, this is often > the case even if all node's store DAOs. I think this would > be OK. Even without intermediate DAO storage, routing > packets directly to neighbors will reduce the P2P messages > traveling through the root. Devices that require more > bandwidth (in or out) can become roots of their own DAGs, > as long as the number of such devices is limited. Right. That said, there are other deployment models where installing some nodes with more memory in the network significantly improves routes quality for P2P. Cheers. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Fri Nov 13 13:59:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5303A659C for ; Fri, 13 Nov 2009 13:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 t+Vxq3q17iie for ; Fri, 13 Nov 2009 13:59:32 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B0BCB3A67DA for ; Fri, 13 Nov 2009 13:59:32 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 17:01:30 -0500 Date: Fri, 13 Nov 2009 16:56:39 -0500 Message-Id: <87iqde3x7s.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Fri, 13 Nov 2009 22:27:31 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 13 Nov 2009 22:01:30.0525 (UTC) FILETIME=[DB0634D0:01CA64AC] Cc: roll@ietf.org Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Nov 2009 21:59:33 -0000 > From: JP Vasseur > Date: Fri, 13 Nov 2009 22:27:31 +0100 > > On Nov 13, 2009, at 8:38 PM, Richard Kelsey wrote: > > > If only the root stores DAOs, then most of the P2P traffic > > will go through the root. As I said above, this is often > > the case even if all node's store DAOs. I think this would > > be OK. Even without intermediate DAO storage, routing > > packets directly to neighbors will reduce the P2P messages > > traveling through the root. Devices that require more > > bandwidth (in or out) can become roots of their own DAGs, > > as long as the number of such devices is limited. > > Right. That said, there are other deployment models where > installing some nodes with more memory in the network > significantly improves routes quality for P2P. Has this actually been tried? I have to admit that I am skeptical that the P2P routes would be very good even if much of the network is storing DAOs, for several reasons: - There is nothing in the DAG rules working to improve the quality of the P2P routes. Only the up and down DAG costs are considered. P2P routes are likely to be long. - Having intermediate nodes store DAOs can greatly increase the cost of changing parents. - Even if all nodes store DAOs, much if not most of the P2P traffic is likely to go through the root. -Richard Kelsey From wintert@acm.org Fri Nov 13 17:47:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0323A693B for ; Fri, 13 Nov 2009 17:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, MANGLED_YOUR=2.3, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rJK41urDnZ2 for ; Fri, 13 Nov 2009 17:47:13 -0800 (PST) Received: from smtp104.prem.mail.ac4.yahoo.com (smtp104.prem.mail.ac4.yahoo.com [76.13.13.43]) by core3.amsl.com (Postfix) with SMTP id 8FB713A683B for ; Fri, 13 Nov 2009 17:47:13 -0800 (PST) Received: (qmail 62965 invoked from network); 14 Nov 2009 01:47:35 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp104.prem.mail.ac4.yahoo.com with SMTP; 13 Nov 2009 17:47:35 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: U0bXP8gVM1lK6EqqiTyQg2iNqYPCqJ9NYc8f6ZoF8UdjDf1xvhAzpPElfnJLFEIBa3JLl.FGh.heKsFDT2ix8UrSyDBIJZwC95Ny1_Y.gEdW1HVyRBxaQ5PIfziPKG3W4dOKCG5TxevV4e05a2nkBqKgNUoAJRHVccaezBH2DutrXKS4XbFmLYRg2Z0ORu8KO6GR.FN3SPoctR65yFNzGb.VrXmGPowX2KBS208HJtfmH3e7dFTCMOFfZ2lQhWFQIgTPLJ2ogT8MCponJUVRVfInzOqEfKW4amr6ofELDfE2YIec2Vtt9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFE0C2E.70600@acm.org> Date: Fri, 13 Nov 2009 20:47:26 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <6A2A459175DABE4BB11DE2026AA50A5D95FEC2@XMB-AMS-107.cisco.com> <4AFB50FC.7050405@acm.org> <70C68CFA-0C6C-42CA-88DB-14095D850096@cs.stanford.edu> In-Reply-To: <70C68CFA-0C6C-42CA-88DB-14095D850096@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 01:47:15 -0000 WG, Upon further discussion we propose for -05 : - A multicast DIS will trigger multicast DIO (by resetting the trickle timer) as in support of case `2' below, where a node wants to poll the neighborhood - A unicast DIS will trigger a unicast DIO response. This is in consideration of the fact that DIO Configuration Options may not be included in every DIO- in the case where a node has, e.g., added a new parent and is uncertain about the DAG configuration, it may use a unicast DIS. In every unicast DIO response then the DAG Configuration MUST be included. Sounds good? - RPL Authors Philip Levis wrote: > > On Nov 11, 2009, at 4:04 PM, Tim Winter wrote: > >> Hi Julien, >> >> Julien Abeille (jabeille) wrote: >>> of course it needs jitter. Now trickle is armed anyway at all times >>> right (T timer). If we do not do anything specific, the DIO will not >>> come earlier with DIS than without... >>> So if no immediate response is needed, then DIS is not needed. I still >>> think it is, for instance anytime you lose you r last parent, and do not >>> want to wait possibly hours to get a DIO. This is the same as with RS/RA >>> (jittered !) >>> >> >> Yes, I agree DIS is needed also- and this is exactly how we got to >> DIS. It >> started by first allowing nodes to actively probe the neighborhood by >> using >> `RS' to solicit `RA-DIO'. from their neighborhood in previous RPL >> versions. >> This was thought to be useful, e.g., for battery powered nodes that do >> not >> want to wait. Now that RPL does not use RS/RA/NA we have introduced >> DIS for >> this exact purpose. >> >>> Resetting trickle (I to Imin, and T to random ) does not make sense I >>> guess, as sending a DIS does not always mean global instability. >>> Thoughts on how to arm a small jittered timer? >> >> It doesn't mean global instability- but it does mean that something has >> changed in the local neighborhood at least. So fair enough I think to >> reset >> trickle, to let trickle do it's job. I agree with prior comments- >> lets not >> make a special case here for DIS handling. > > I think that the Trickle text in the draft presents it in a narrower > light than which it's been used for routing protocols. A CTP node, for > example, resets the Trickle timer on three conditions: > > 1. It receives a packet to forward whose transmitter's routing cost <= > the receiver's routing cost. > 2. It receives a packet with the "P" bit set (the equivalent of a DIS). > 3. Its cost decreases significantly. > > We've all been discussing 1. But let's no forget conditions 2 and 3. For > 2, a node does not have entries in its neighbor table, then one could > say its logical topology is inconsistent with its physical topology. 3 > is very much a performance optimization. It handles the case when a node > might suddenly offer a much less expensive route than before, and its > neighbors view of its cost is out-of-date enough that it might lead to > sub-optimal behavior. > > My experience is that conditions 1 and 2 are both important, 3 is just a > small optimization. Using an exponentially increasing timer (rather than > just a jittered one) is critical. The reason is that, under sufficient > density, a given jittered interval can be too small and lead to many > collisions (don't forget we're LLNs, and so can be using low-power link > layers that don't work that well under broadcast storms). If you go back > to the Trickle paper, you'll note there were several experimental cases > where propagation took more than one timer interval per hop due to > collisions. Having an exponentially increasing timer solves this > problem: if the optimal interval length is L, then nodes will find it in > 2L, with a logarithmic message cost. This is part of what allows Trickle > to adapt to thousand-fold changes in network density. > >> The DIS should then also be multicast, and it should trigger multicast >> DIO >> responses. > > Agreed. > From wintert@acm.org Fri Nov 13 17:59:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C8B3A6931 for ; Fri, 13 Nov 2009 17:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzRcrFisfeeP for ; Fri, 13 Nov 2009 17:59:39 -0800 (PST) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id 5380B3A68BF for ; Fri, 13 Nov 2009 17:59:39 -0800 (PST) Received: (qmail 33917 invoked from network); 14 Nov 2009 02:00:06 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 13 Nov 2009 18:00:06 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: goLCVhMVM1nkjAjiR9b.4K3J24D6N8S_yG18xzOzxc0APH82OGP2RZCBYhvALhfAn9tj7HD_Apvj_B1_HIwzuorBORNMM1YnuJTqrOLuw.SnMS9Swe0nE8J96WH1uBMElix79mbcJ0HRoICpZc3fkgCLRxH87MlC6xkjEhC4OuCvPjXgdsQKyQpH3sCgbhX.zbZotupwrevrBnA8WTAimYX2dZObTWoK2pSTWSJIfVP.ToYAcpO4UkRQ.xkHX7Mfr30Bbi0iG4hegNrne9Z.7z7VsSKWTLqlMrhy44V1ZAIagBfyfmtnw2hwDTI4XDd0jQP7sNSIDHzwiOsBPKXV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AFE0F21.6080304@acm.org> Date: Fri, 13 Nov 2009 21:00:01 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> In-Reply-To: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 01:59:40 -0000 My opinion is for Option 1. I think that the applicability statements are the right place to start pinning down interoperability w.r.t. OFs - as appropriate to each application space. This may also include interoperability between application spaces. -Tim JP Vasseur wrote: > Dear all, > > As a reminder Ticket #10 is related to a node behavior when receiving a > DIO with an OF that it does not understand / support. > > There was a strong consensus for the following option: >>> Option 1: The node simply joins the DAG as a leaf. In order words, >>> the node has connectivity since it joins the DAG but will not act as >>> a router for others since it does not understand the OF. Parent >>> selection could be a simply a "random". > > Now the question is whether or not RPL mandates the support of OF0. > > Again two options: > > 1) We remove OF0 from the core spec. And nodes are free to implement the > OF that they want > > 2) We do mandate for each node to support OF0 > > Pros/Cons: > > If the support of OF0 in no longer mandatory, nodes operating in an > environment requiring a specific OF just have to implement that OF. > On the other hand, when mixing nodes that do not support the same OF, > they do not interoperate. > > An alternative if we decide to make OF0 non mandatory is to indicate in > some applicability statement the applications that would require the > support of OF0. > > Opinion ? > > Thanks. > > JP. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mcr@marajade.sandelman.ca Fri Nov 13 18:43:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A273A68BF for ; Fri, 13 Nov 2009 18:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37hbZ4W3R035 for ; Fri, 13 Nov 2009 18:43:44 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7CAB23A67EF for ; Fri, 13 Nov 2009 18:43:43 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id C4E71342DF for ; Fri, 13 Nov 2009 21:35:31 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D73A64E793 for ; Fri, 13 Nov 2009 21:44:12 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <87my2q43mv.fsf@kelsey-ws.hq.ember.com> References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 13 Nov 2009 21:44:12 -0500 Message-ID: <13293.1258166652@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 02:43:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" == Richard Kelsey writes: mcr> I guess it might be enough to have a bit that gets turned by the mcr> first non-root node that stores DAOs. Richard> I think you need two bits. One is turned on by the root if Richard> it stores DAOs and the other is turned on by any Richard> intermediate node that stores them. I didn't realize that the root could *not* store DAOs...! I'm trying to imagine how that works. I can perhaps see how this might be the case with an ungrounded DAG, where some random DAO-incapable node decides to become the new root. mcr> If I understand correctly, if the intermediate nodes do not store mcr> DAOs, then they won't have a routing table to other peers, so p2p mcr> traffic will have to travel all the way up to the root and out mcr> again. Richard> Yes. On the other hand, the DAG formation mechanism works Richard> to maximize downward fanout, which in turn maximizes the Richard> number of P2P routes that go through the root even if all Richard> nodes store DAOs. For example, if the root has N children Richard> with roughly equal subgraphs, then each node can reach only Richard> 1/N of the network without through the root. Yeah, I can see how a relatively uniformly distributed DAG would have this property. I can also see where this would not be the case, such as a long linear network, such as a series of lampposts or utility poles along a rural road... where the grounded node is at one of the road. >> It seemed to me like a compromise that the root had to be able to >> create source routes so that weaker intermediate nodes could >> avoid storing the DAOs. That this wasn't the ideal situation, but >> was a compromise. >> >> What happens if we insist all nodes store DAOs? (is it simpler?) Richard> That uses too much RAM for us to require it. Yes, I understand why we can not do it. You see, I'm asking what the real tradeoff is about this. If ram and CPU was free, but network bandwidth was not, would we decide to force all nodes to store DAOs? JP has suggested that it helps. I can see with a linear network where there is traffic up and down the line, that without DAO storing nodes in the middle, traffic has to go all the way to the end and back. >> What happens if we insist that no nodes store DAOs? (is it >> simpler?) Richard> Do you mean no nodes at all, or no nodes other than the Richard> root? No nodes other than the root.... Nothing would work if nobody knew the routes, right. Richard> If only the root stores DAOs, then most of the P2P traffic Richard> will go through the root. As I said above, this is often Richard> the case even if all node's store DAOs. I think this would Richard> be OK. Even without intermediate DAO storage, routing Richard> packets directly to neighbors will reduce the P2P messages Richard> traveling through the root. Devices that require more Richard> bandwidth (in or out) can become roots of their own DAGs, Richard> as long as the number of such devices is limited. To summarize, forbidding intermediate nodes to store DAOs: - causes a loss in quality for p2p traffic for some topologies, but for many topologies has a neglible effect - causes no change for m2p - massively reduces traffic when there is a new parent chosen - simplifies the protocol (no need to record who records DAOs) - removes the need for code to do different things depending upon whether there are DAO storing nodes above, when changing parents. Or to be it another way, capable nodes that have the ram to store DAOs are causing load on less capable nodes. They aren't being very helpful. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg== =slpm -----END PGP SIGNATURE----- From mcr@marajade.sandelman.ca Fri Nov 13 19:08:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B88E3A698C for ; Fri, 13 Nov 2009 19:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcojVcecmE9P for ; Fri, 13 Nov 2009 19:08:30 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 79FEC3A699F for ; Fri, 13 Nov 2009 19:08:30 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 6465E342EA for ; Fri, 13 Nov 2009 22:00:18 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id DCCE24E793 for ; Fri, 13 Nov 2009 22:08:59 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: <4AFE0F21.6080304@acm.org> References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <4AFE0F21.6080304@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 13 Nov 2009 22:08:59 -0500 Message-ID: <14800.1258168139@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 03:08:31 -0000 >>>>> "Tim" == Tim Winter writes: Tim> My opinion is for Option 1. I think that the applicability Tim> statements are the right place to start pinning down Tim> interoperability w.r.t. OFs - as appropriate to each Tim> application space. This may also include interoperability Tim> between application spaces. I'm fine with that. The applicability statements will be the main anchor into the standard, that's fine. My concern is that it appeared that some wanted to leave to do other industry "fora" to declare. As long as there is an IETF standards track document that says what is what, then I'm happy. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jabeille@cisco.com Sat Nov 14 02:35:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511DA3A68C4 for ; Sat, 14 Nov 2009 02:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.844 X-Spam-Level: X-Spam-Status: No, score=-7.844 tagged_above=-999 required=5 tests=[AWL=-1.245, 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 BLFvzhXT2eK8 for ; Sat, 14 Nov 2009 02:35:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 830823A681E for ; Sat, 14 Nov 2009 02:35:55 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN8W/kqrR7Hu/2dsb2JhbAC8RZdyhDwE X-IronPort-AV: E=Sophos;i="4.44,741,1249257600"; d="scan'208";a="432549564" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 14 Nov 2009 10:36:26 +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 nAEAaPdR022129; Sat, 14 Nov 2009 10:36:26 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Nov 2009 11:36:25 +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: Sat, 14 Nov 2009 11:36:24 +0100 Message-ID: In-Reply-To: <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on Ticket #10 Thread-Index: AcpkjZXOM4chb6TnS+iIZUS7h4JRBQAiDvgQ References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com><5896.1258078243@marajade.sandelman.ca><87r5s24fh9.fsf@kelsey-ws.hq.ember.com><9328.1258127853@marajade.sandelman.ca> <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Richard Kelsey" , "Michael Richardson" X-OriginalArrivalTime: 14 Nov 2009 10:36:25.0033 (UTC) FILETIME=[50A7A390:01CA6516] Cc: roll@ietf.org Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 10:35:56 -0000 Hi Richard,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: vendredi 13 novembre 2009 19:14 > To: Michael Richardson > Cc: roll@ietf.org > Subject: Re: [Roll] Closing on Ticket #10 >=20 >=20 > > From: Michael Richardson > > Date: Fri, 13 Nov 2009 10:57:33 -0500 > > > > So, which requirement does this document satisfy? > > Is it: - building routing requirements ... > > - home routing requirements ... > > - indus routing requirements RFC 5673 > > - urban routing requirements RFC 5548 > > > > I also understand the comment about death by a thousand=20 > needle pricks. > > Will these four stated things be satisfied by a single OFx? Will=20 > > there be four OFx? Or will many different ones be required for=20 > > different situations? >=20 > My hope is that we will need no more than one or two OFxs. > The reason we need to be flexible now is not that we are=20 > likely to need many of them, but that we don't know which=20 > ones are the right ones. >=20 > > If there is no MUST for OF0, then we do not have anything we can > > interoperate with, and so we do not have an IETF standard. =20 > We might > > have four standards, and if so, that's fine, then let's be explicit=20 > > about this. >=20 > Is there a problem with treating RPL and the metrics document=20 > as a single standard for the purposes of interoperation? RPL=20 > can state that there must be a single metric in use without=20 > saying which metric it is. >=20 100% agree, RPL+metric+OF should be treated as a single standard. This is nothing new. What is the point of SNMP if you do not implement MIBs RFCs? None. A standard does not need to be one RFC. Interoperability was never met between two device simply because they implement one RFC, rather that they implement a set of L1/2 standards, L3, L4, L5.=20 Julien > > We have not discussed security very much yet. > >=20 > > If there is not space for two OFx (OF0 and OFx) in the code space, >=20 > There is space for two OFx if they are needed. There is no=20 > space for anything that is not needed, big or small. In the=20 > case of something like a consumer thermostat, I do not see=20 > any need for having both OF0 and a more nuanced metric. >=20 > -Richard Kelsey=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jabeille@cisco.com Sat Nov 14 02:38:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF393A6954 for ; Sat, 14 Nov 2009 02:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.823 X-Spam-Level: X-Spam-Status: No, score=-7.823 tagged_above=-999 required=5 tests=[AWL=-1.224, 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 hztzq7hEjoDR for ; Sat, 14 Nov 2009 02:38:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4F2413A681E for ; Sat, 14 Nov 2009 02:38:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM8X/kpAZnwN/2dsb2JhbAC8RZduhDwE X-IronPort-AV: E=Sophos;i="4.44,741,1249257600"; d="scan'208";a="68087105" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Nov 2009 10:38:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAEAchKu004412; Sat, 14 Nov 2009 10:38:43 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Nov 2009 11:38:42 +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: Sat, 14 Nov 2009 11:38:41 +0100 Message-ID: In-Reply-To: <4AFE0F21.6080304@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on Ticket #10 Thread-Index: AcpkzjYdOFD8wIl/T1eQxxROdtWatwASGaGA References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <4AFE0F21.6080304@acm.org> From: "Julien Abeille (jabeille)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 14 Nov 2009 10:38:42.0667 (UTC) FILETIME=[A2B0EBB0:01CA6516] Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 10:38:14 -0000 +1. Julien=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Tim Winter > Sent: samedi 14 novembre 2009 03:00 > To: ROLL WG > Subject: Re: [Roll] Closing on Ticket #10 >=20 > My opinion is for Option 1. I think that the applicability=20 > statements are the right place to start pinning down=20 > interoperability w.r.t. OFs - as appropriate to each=20 > application space. This may also include interoperability=20 > between application spaces. >=20 >=20 > -Tim >=20 >=20 > JP Vasseur wrote: > > Dear all, > >=20 > > As a reminder Ticket #10 is related to a node behavior when=20 > receiving=20 > > a DIO with an OF that it does not understand / support. > >=20 > > There was a strong consensus for the following option: > >>> Option 1: The node simply joins the DAG as a leaf. In=20 > order words,=20 > >>> the node has connectivity since it joins the DAG but will=20 > not act as=20 > >>> a router for others since it does not understand the OF. Parent=20 > >>> selection could be a simply a "random". > >=20 > > Now the question is whether or not RPL mandates the support of OF0. > >=20 > > Again two options: > >=20 > > 1) We remove OF0 from the core spec. And nodes are free to=20 > implement=20 > > the OF that they want > >=20 > > 2) We do mandate for each node to support OF0 > >=20 > > Pros/Cons: > >=20 > > If the support of OF0 in no longer mandatory, nodes operating in an=20 > > environment requiring a specific OF just have to implement that OF. > > On the other hand, when mixing nodes that do not support=20 > the same OF,=20 > > they do not interoperate. > >=20 > > An alternative if we decide to make OF0 non mandatory is to=20 > indicate=20 > > in some applicability statement the applications that would require=20 > > the support of OF0. > >=20 > > Opinion ? > >=20 > > Thanks. > >=20 > > JP. > >=20 > >=20 > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From joakime@sics.se Sat Nov 14 07:15:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1443A6839 for ; Sat, 14 Nov 2009 07:15:29 -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 VrUTgvPHEJCD for ; Sat, 14 Nov 2009 07:15:28 -0800 (PST) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by core3.amsl.com (Postfix) with ESMTP id 9FB613A6774 for ; Sat, 14 Nov 2009 07:15:27 -0800 (PST) Received: from ipb2.telenor.se (195.54.127.165) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA00DD9C08 for roll@ietf.org; Sat, 14 Nov 2009 16:15:57 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlASAPdY/kpV5BHmPGdsb2JhbAAInAsBAQEBN7cShDwE X-IronPort-AV: E=Sophos;i="4.44,742,1249250400"; d="scan'208";a="3489446" Received: from c-e611e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.17.230]) by ipb2.telenor.se with ESMTP; 14 Nov 2009 16:15:57 +0100 Message-ID: <4AFEC9B8.1080102@sics.se> Date: Sat, 14 Nov 2009 16:16:08 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 15:15:29 -0000 Hello Phil and Julien, Is it really necessary to wait until the complete I interval has passed before doubling I and restarting T (with the new interval)? It feels that we get basically the same behavior with less complex code if we skip the wait for the complete interval to pass. Best regards, -- Joakim Eriksson, SICS Julien Abeille (jabeille) skrev: > Ok, thanks. > Julien > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: mercredi 11 novembre 2009 19:18 >> To: Julien Abeille (jabeille) >> Cc: roll >> Subject: Re: [Roll] trickle question >> >> >> On Nov 11, 2009, at 10:10 AM, Julien Abeille (jabeille) wrote: >> >>> Hi Phil, >>> >>> I thought that when T expires, you restart T (without restarting I). >>> Hence if e.g I compute T= 3/4I, start both I and T, after 3/4I, I >>> restart T to e.g. 5/6I. After 1/4 I more, I expires, T is still >>> running. >>> Did I misunderstand? >> Once T has fired, you don't restart it until a new interval >> begins (I expires or the trickle timer is reset). >> >> Phil >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Sat Nov 14 09:23:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1AD33A68E4 for ; Sat, 14 Nov 2009 09:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh5WsJCXaErO for ; Sat, 14 Nov 2009 09:23:52 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 275643A6860 for ; Sat, 14 Nov 2009 09:23:52 -0800 (PST) Received: from mail-qy0-f191.google.com ([209.85.221.191]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1N9MMJ-0002QY-5R for roll@ietf.org; Sat, 14 Nov 2009 09:24:23 -0800 Received: by qyk29 with SMTP id 29so1976881qyk.32 for ; Sat, 14 Nov 2009 09:24:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.105.229 with SMTP id u37mr3729375qao.221.1258219462393; Sat, 14 Nov 2009 09:24:22 -0800 (PST) In-Reply-To: <4AFEC9B8.1080102@sics.se> References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> <4AFEC9B8.1080102@sics.se> Date: Sat, 14 Nov 2009 09:24:22 -0800 Message-ID: From: Omprakash Gnawali To: Joakim Eriksson Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 17:23:52 -0000 On Sat, Nov 14, 2009 at 7:16 AM, Joakim Eriksson wrote: > Hello Phil and Julien, > > Is it really necessary to wait until the complete I interval has > passed before doubling I and restarting T (with the new interval)? > > It feels that we get basically the same behavior with less complex > code if we skip the wait for the complete interval to pass. What would the less complex code look like? Do you have some high level pseudocode for what you had in mind? - om_p From joakime@sics.se Sat Nov 14 09:41:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94CB3A681C for ; Sat, 14 Nov 2009 09:41:59 -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 i51p0oJ-FG0s for ; Sat, 14 Nov 2009 09:41:59 -0800 (PST) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by core3.amsl.com (Postfix) with ESMTP id E39FF3A67E3 for ; Sat, 14 Nov 2009 09:41:58 -0800 (PST) Received: from ipb2.telenor.se (195.54.127.165) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA00DE1484 for roll@ietf.org; Sat, 14 Nov 2009 18:42:29 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsESAPN6/kpV5BHmPGdsb2JhbAAIiU2SPwEBAQE3tmqEPASMOA X-IronPort-AV: E=Sophos;i="4.44,742,1249250400"; d="scan'208";a="3518321" Received: from c-e611e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.17.230]) by ipb2.telenor.se with ESMTP; 14 Nov 2009 18:42:29 +0100 Message-ID: <4AFEEC0D.80002@sics.se> Date: Sat, 14 Nov 2009 18:42:37 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Omprakash Gnawali References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> <4AFEC9B8.1080102@sics.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 17:42:00 -0000 Hi, Well the difference is that you do not need to treat the I (interval) as a timer, so it would be: Some pseudo code: When T triggers: -- if (C > REDUNDANCY_CONSTANT) sendDIO(); C = 0; if (doublings++ < max_doublings) I = I * 2; T.start(I/2 + rand() * I/2); -- The only timer that is needed is T in this case. Based on specification it needs to be: When T triggers: -- if (C > REDUNDANCY_CONSTANT) sendDIO(); -- and When I_timer triggers: -- C = 0; if (doublings++ < max_doublings) I = I * 2; T.start(I/2 + rand() * I/2); I_timer.start(I); -- So there is a need for a second timers (or accounting of the rand() result) if we need to wait before restarting T. Skipping the interval timer will give slightly less complex code (well, not much) and less resource need (timers/RAM). Best regards, -- Joakim Eriksson, SICS Omprakash Gnawali skrev: > On Sat, Nov 14, 2009 at 7:16 AM, Joakim Eriksson wrote: >> Hello Phil and Julien, >> >> Is it really necessary to wait until the complete I interval has >> passed before doubling I and restarting T (with the new interval)? >> >> It feels that we get basically the same behavior with less complex >> code if we skip the wait for the complete interval to pass. > > What would the less complex code look like? Do you have some high > level pseudocode for what you had in mind? > > - om_p From pal@cs.stanford.edu Sat Nov 14 11:12:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8B33A680D for ; Sat, 14 Nov 2009 11:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 VEy4ejWOn1KX for ; Sat, 14 Nov 2009 11:12:31 -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 02FC23A67B0 for ; Sat, 14 Nov 2009 11:12:31 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N9O3P-00046Y-Gf; Sat, 14 Nov 2009 11:13:02 -0800 In-Reply-To: <4AFEC9B8.1080102@sics.se> References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> <4AFEC9B8.1080102@sics.se> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Sat, 14 Nov 2009 11:12:58 -0800 To: Joakim Eriksson X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 19:12:32 -0000 On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: > Hello Phil and Julien, > > Is it really necessary to wait until the complete I interval has > passed before doubling I and restarting T (with the new interval)? > > It feels that we get basically the same behavior with less complex > code if we skip the wait for the complete interval to pass. Hm -- I can't recall if I tried this variant. I'm searching around for the analytical simulator source code, if I find it, I'll let you know. One thing is that trickle is more efficient when intervals are synchronized (it sends half as many messages). Let's say you reset the interval after T. First, the average interval length is 0.75I, leading to 33% more messages. Second, it will inherently desynchronize intervals, leading to twice as many messages compared to the best case. This is a total overhead of sending approximately 2.5 times as many messages if you don't. Of course, the 33% also results in a lower detection latency. Given how the interval length changes, if you want to implement it this way, *all* nodes need to do so, or you break load balancing. But this is just off the top of my head. The behavior of protocols like these can often be not something you'd expect (e.g., "basically the same behavior"). I would definitely run some tests to see how it behaves under very high density. It could be that nodes which pick small T values end up shouldering more of the load due to a variant of the short listen problem. My intuition is that this is a shortcut which probably isn't worth it as it might bite you later, but that intuition could be wrong. Usually, it's just easier to keep track of the rand() result, rather than keep two timers. Phil From joakime@sics.se Sat Nov 14 14:07:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4432D3A679C for ; Sat, 14 Nov 2009 14:07:26 -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 ZivddzzncEr8 for ; Sat, 14 Nov 2009 14:07:25 -0800 (PST) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by core3.amsl.com (Postfix) with ESMTP id 52D7F3A6359 for ; Sat, 14 Nov 2009 14:07:24 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C000DF13EE for roll@ietf.org; Sat, 14 Nov 2009 23:07:54 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsESAJe4/kpV5BHmPGdsb2JhbAAIiUySPwEBAQE3tjmEPASMOA X-IronPort-AV: E=Sophos;i="4.44,743,1249250400"; d="scan'208";a="3562601" Received: from c-e611e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.17.230]) by ipb1.telenor.se with ESMTP; 14 Nov 2009 23:07:54 +0100 Message-ID: <4AFF2A43.7080204@sics.se> Date: Sat, 14 Nov 2009 23:08:03 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> <4AFEC9B8.1080102@sics.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Nov 2009 22:07:26 -0000 Philip Levis wrote: > > On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: > >> Hello Phil and Julien, >> >> Is it really necessary to wait until the complete I interval has >> passed before doubling I and restarting T (with the new interval)? >> >> It feels that we get basically the same behavior with less complex >> code if we skip the wait for the complete interval to pass. > > Hm -- I can't recall if I tried this variant. I'm searching around for > the analytical simulator source code, if I find it, I'll let you know. That would be great! > One thing is that trickle is more efficient when intervals are > synchronized (it sends half as many messages). Let's say you reset the > interval after T. First, the average interval length is 0.75I, leading > to 33% more messages. Second, it will inherently desynchronize > intervals, leading to twice as many messages compared to the best case. Is it really the same as unsynchronized trickle (according to the spec)? If we skip waiting for the interval we will reset and restart the counting of sent messages, and count received DIOs immediately. In the version in the specification all nodes will ignore any other nodes DIO messages that happen to come after their own transmission but before the the interval ends. > This is a total overhead of sending approximately 2.5 times as many > messages if you don't. Of course, the 33% also results in a lower > detection latency. > > Given how the interval length changes, if you want to implement it this > way, *all* nodes need to do so, or you break load balancing. Yes, if a single node would run this it will have a higher likelihood to send than the other nodes. But the interval I length is still doubled in each cycle, so it is not as bad as if it would just double the interval that it feeds to T (e.g. I/2 + rand()*I/2). > But this is just off the top of my head. The behavior of protocols like > these can often be not something you'd expect (e.g., "basically the same > behavior"). I would definitely run some tests to see how it behaves > under very high density. It could be that nodes which pick small T > values end up shouldering more of the load due to a variant of the short > listen problem. My intuition is that this is a shortcut which probably > isn't worth it as it might bite you later, but that intuition could be > wrong. It should not be the short listening problem, I think, but there might be other "emergent behaviors" that is more or less impossible to see without a proper round of simulations. > Usually, it's just easier to keep track of the rand() result, rather > than keep two timers. Yes, I agree on that! Best regards, -- Joakim Eriksson, SICS > Phil From trac@tools.ietf.org Sun Nov 15 02:30:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACB93A684D for ; Sun, 15 Nov 2009 02:30:27 -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.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOPiw55SFT6C for ; Sun, 15 Nov 2009 02:30:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id AD38C3A67DF for ; Sun, 15 Nov 2009 02:30:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N9cNm-0004vl-LL; Sun, 15 Nov 2009 02:30:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Sun, 15 Nov 2009 10:30:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/18 Message-ID: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 10:30:27 -0000 #18: Numeric Ranges in Routing Metric --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: minor | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- This ticket is related to the Numeric Ranges in Routing Metric. Here is the original thread: I mentioned it during the roll meeting Tuesday, but I think it's probably worth documenting the thought in a little more technical detail. The routing metrics right now include 32-bit floating point numbers for latency and throughput. Since these numbers are much more likely to be added or compared rather than multiplied, fixed point rather than floating point is likely to be a better choice of representation. For example, for normalized positive 32-bit IEEE 754 numbers, the maximum number is about 3.4e38 and the minimum is about 1.2e-38. For reference, the age of universe in milliseconds (taking the high end of NASA's most recent estimate) is only 4.4e20 and the time it takes to travel the distance across an electron (Lorentz diameter for you physics heads) is about 1.9e-20 ms. A negative latency would seem to imply that packets appear before they're sent which is probably not practical. If instead, latency were a 32-bit unsigned integer in units of milliseconds, we'd still be able to go from 0 or 1 milliseconds up to almost 1200 hours if my math is right. That should be plenty for any practical network. I haven't done so but I suspect that we could do the same thing with throughput. -- Ticket URL: roll From pthubert@cisco.com Mon Nov 16 00:03:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDB23A68FC for ; Mon, 16 Nov 2009 00:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2cUTuBPZkXf for ; Mon, 16 Nov 2009 00:03:13 -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 55DCE3A67E6 for ; Mon, 16 Nov 2009 00:03:13 -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: AiIAAD6WAEuQ/uCWe2dsb2JhbACcHgEBCwskBqEjiTuMZIQ8BIFt X-IronPort-AV: E=Sophos;i="4.44,750,1249257600"; d="scan'208";a="54442378" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2009 08:03:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAG83BSr014432; Mon, 16 Nov 2009 08:03:11 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 09:03:11 +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, 16 Nov 2009 09:03:06 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DA36781@XMB-AMS-107.cisco.com> In-Reply-To: <13293.1258166652@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Something to ADD Thread-Index: Acpk1GHqrlwz32kyQqOUm8LEtPpHjgBviaVg References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , X-OriginalArrivalTime: 16 Nov 2009 08:03:11.0361 (UTC) FILETIME=[3DA01F10:01CA6693] Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 08:03:15 -0000 Hi Richard: Note that LSRR is still workable even if the root does not store DAO itself. An example of that is found here: http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header Note that in the RRH case, the 'multihop' DAO was carried with the traffic as a routing header. The reason being that the other end of the connection has to echo the LSRR header. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson >Sent: samedi 14 novembre 2009 03:44 >To: roll@ietf.org >Subject: Re: [Roll] Something to ADD > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Richard" =3D=3D Richard Kelsey = writes: > mcr> I guess it might be enough to have a bit that gets turned by the > mcr> first non-root node that stores DAOs. > > Richard> I think you need two bits. One is turned on by the root if > Richard> it stores DAOs and the other is turned on by any > Richard> intermediate node that stores them. > > I didn't realize that the root could *not* store DAOs...! > I'm trying to imagine how that works. > I can perhaps see how this might be the case with an ungrounded DAG, >where some random DAO-incapable node decides to become the new root. > > mcr> If I understand correctly, if the intermediate nodes do not store > mcr> DAOs, then they won't have a routing table to other peers, so p2p > mcr> traffic will have to travel all the way up to the root and out > mcr> again. > > Richard> Yes. On the other hand, the DAG formation mechanism works > Richard> to maximize downward fanout, which in turn maximizes the > Richard> number of P2P routes that go through the root even if all > Richard> nodes store DAOs. For example, if the root has N children > Richard> with roughly equal subgraphs, then each node can reach only > Richard> 1/N of the network without through the root. > > Yeah, I can see how a relatively uniformly distributed DAG would have >this property. I can also see where this would not be the case, such >as a long linear network, such as a series of lampposts or utility poles >along a rural road... where the grounded node is at one of the road. > > >> It seemed to me like a compromise that the root had to be able to > >> create source routes so that weaker intermediate nodes could > >> avoid storing the DAOs. That this wasn't the ideal situation, but > >> was a compromise. > >> > >> What happens if we insist all nodes store DAOs? (is it simpler?) > > Richard> That uses too much RAM for us to require it. > > Yes, I understand why we can not do it. > > You see, I'm asking what the real tradeoff is about this. > If ram and CPU was free, but network bandwidth was not, would we >decide to force all nodes to store DAOs? > JP has suggested that it helps. > > I can see with a linear network where there is traffic up and down the >line, that without DAO storing nodes in the middle, traffic has to go >all the way to the end and back. > > >> What happens if we insist that no nodes store DAOs? (is it > >> simpler?) > > Richard> Do you mean no nodes at all, or no nodes other than the > Richard> root? > > No nodes other than the root.... > Nothing would work if nobody knew the routes, right. > > Richard> If only the root stores DAOs, then most of the P2P traffic > Richard> will go through the root. As I said above, this is often > Richard> the case even if all node's store DAOs. I think this would > Richard> be OK. Even without intermediate DAO storage, routing > Richard> packets directly to neighbors will reduce the P2P messages > Richard> traveling through the root. Devices that require more > Richard> bandwidth (in or out) can become roots of their own DAGs, > Richard> as long as the number of such devices is limited. > > To summarize, forbidding intermediate nodes to store DAOs: > - causes a loss in quality for p2p traffic for some topologies, > but for many topologies has a neglible effect > - causes no change for m2p > - massively reduces traffic when there is a new parent chosen > - simplifies the protocol (no need to record who records DAOs) > - removes the need for code to do different things depending > upon whether there are DAO storing nodes above, when changing > parents. > > Or to be it another way, capable nodes that have the ram to store DAOs >are causing load on less capable nodes. They aren't being very >helpful. > >- -- >] He who is tired of Weird Al is tired of life! | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Finger me for keys > >iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF >AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl >p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 >WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko >xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF >YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg=3D=3D >=3Dslpm >-----END PGP SIGNATURE----- >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 16 05:49:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6763A695C for ; Mon, 16 Nov 2009 05:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.486 X-Spam-Level: X-Spam-Status: No, score=-8.486 tagged_above=-999 required=5 tests=[AWL=-1.886, 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 6VM+iiQi6VGA for ; Mon, 16 Nov 2009 05:49:38 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 28A8B3A6950 for ; Mon, 16 Nov 2009 05:49:38 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABvnAEtAZnwM/2dsb2JhbAC+a5ZQgjGCCwQ X-IronPort-AV: E=Sophos;i="4.44,751,1249257600"; d="scan'208";a="68289547" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2009 13:49:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAGDn67U025806 for ; Mon, 16 Nov 2009 13:49:36 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 14:49:34 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 14:49:34 +0100 Message-Id: <87B43DC9-7784-4051-B908-73510E10EB58@cisco.com> From: JP Vasseur To: roll WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 14:49:34 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Nov 2009 13:49:34.0863 (UTC) FILETIME=[A18ED9F0:01CA66C3] Subject: [Roll] Ticket #10 - Decision about OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 13:49:39 -0000 Dear all, Ticker #10 can now be closed: there was a strong consensus on the behavior of a node acting as a leaf when receiving a DIO with a non supported/recognized OF. On the second question (do we need to mandate OF0 ?) we now have a (softer- consensus. We will proceed as follows: * OF0 will be removed for the core spec of RPL (in -05) * OF0 will be moved to a separate ID * OF0 will be referred as appropriate it in some applicability statement. That will make rev-05 even lighter :-) Thanks. JP. From trac@tools.ietf.org Mon Nov 16 05:50:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825FB3A6AA9 for ; Mon, 16 Nov 2009 05:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.186 X-Spam-Level: X-Spam-Status: No, score=-100.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg2ko8uf6PKA for ; Mon, 16 Nov 2009 05:50:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id A53653A6950 for ; Mon, 16 Nov 2009 05:50:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NA1yL-0002iI-Nu; Mon, 16 Nov 2009 05:50:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 16 Nov 2009 13:50:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/10#comment:5 Message-ID: <064.0976cabee15863fe7612b16d5fc9faf0@tools.ietf.org> References: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.5387e12bebdcd55621198e9950e29a1e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #10: Non supported OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:50:27 -0000 #10: Non supported OF --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: reopened => closed * resolution: => fixed Comment: Dear all, Ticker #10 can now be closed: there was a strong consensus on the behavior of a node acting as a leaf when receiving a DIO with a non supported/recognized OF. On the second question (do we need to mandate OF0 ?) we now have a (softer- consensus. We will proceed as follows: * OF0 will be removed for the core spec of RPL (in -05) * OF0 will be moved to a separate ID * OF0 will be referred as appropriate it in some applicability statement. That will make rev-05 even lighter :-) Thanks. JP. -- Ticket URL: roll From mcr@marajade.sandelman.ca Mon Nov 16 10:35:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0389628C1D4 for ; Mon, 16 Nov 2009 10:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwEsus2KszhG for ; Mon, 16 Nov 2009 10:35:35 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EA5D43A69E2 for ; Mon, 16 Nov 2009 10:35:34 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 9D0AD34300 for ; Mon, 16 Nov 2009 13:27:02 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id CC8A64E794 for ; Mon, 16 Nov 2009 13:35:32 -0500 (EST) X-Message-Flag: You should stop using Outlook. Switch to Thunderbird. From: Michael Richardson To: IETF ROLL X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 16 Nov 2009 13:35:32 -0500 Message-ID: <15726.1258396532@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: [Roll] question about rpl-04.txt, destination prefix PRF field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 18:35:36 -0000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is there some reason the PRF field is shifted three bits? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Mon Nov 16 10:52:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762C028C198 for ; Mon, 16 Nov 2009 10:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R13kc+hbruSu for ; Mon, 16 Nov 2009 10:52:28 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3575C3A68E2 for ; Mon, 16 Nov 2009 10:52:28 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 3BD0F342F9 for ; Mon, 16 Nov 2009 13:43:56 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 158454E794 for ; Mon, 16 Nov 2009 13:52:26 -0500 (EST) X-Message-Flag: You should stop using Outlook. Switch to Thunderbird. From: Michael Richardson To: IETF ROLL X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 16 Nov 2009 13:52:25 -0500 Message-ID: <16805.1258397545@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: [Roll] question about rpl-04.txt prefix length X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:52:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 5.1.3.1.1.5. Destination Prefix The Destination Prefix suboption does not have any alignment requirements. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ | | Destination Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... The Prefix Length is an 16-bit unsigned integer that indicates the number of leading bits in the destination prefix. It's shown as an 8-bit value in the picture, and 8 bits is enough for 128 bits of prefix length. I take it the text is wrong, and the picture is right? Change to: The Prefix Length is an 8-bit unsigned integer that indicates the number of (leading) bits in the destination prefix which are part of the network part of the address. === The Destination Prefix contains Prefix Length significant bits of the destination prefix. The remaining bits of the Destination Prefix, as required to complete the trailing octet, are set to 0. I'd like to change this to read: Up to 128 bits of destination prefix MAY be present in normal IPv6 most significant bit first format. The number of bytes present is determined by the suboption length. The receiving node MUST assume any bits not present are zero. The receiving node SHOULD ignore any bits present but not required, setting them to zero. Note that this is a subtle change, I think. If not the original text ambiguously permitted this. If your prefix is, for instance, 2001:4830:16ca::/64, you need to transmit only the first 6 bytes. You do not need to transmit the 2 bytes of zeros between bits 48 and 64. Obviously, you do not need to transmit 8 bytes of zeros from 64 to 128. Also note that this also implies an implementation can just send all 128 bits if it likes --- it's dumb and wasteful, but it's legal. As all implementaitons will have to validate that there are in fact "Prefix Length" of data available before using the data, this won't in fact change any well written code. (If you did not check, buffer overflow...) A downside is that this introduces a possible covert channel, but I don't think it's relevant. Also this opens up a possibility that the prefix length can be derived from the option length, plus 3 bits of the reserved field. Maybe that's what was written in a previous draft... (I notice that rpl-04 removed the alignment requirement. I agree with that) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwGfZ4CLcPvd0N1lAQLrmQf+O8xlggvoBhBFL3mtxnJzKXeRtWfBi39h Fv29t8kVnkg5AcPpwuVFK+TT75TqjzNqvQLQgZV32ijb1UVkmxH6yfdgJuER4jSF 7mwdbHa4a9OqQp4HonTGVpf0nYFvIKJykRI7A06C7VRyZIwBpH4Af+HOD18z9emf UnlIOIbMrmpozaFdUByKqdVIotBaFD8jegAoSc41Jo2oLbIgvvIMQkDP972ylpk7 6lGln/ApE0fcSnSpvLCgcVKjEA6yqgyEd+ClqEgBINv8YhFrXyGMI2fKpJrfy63X S+UdPO8wSgs/mRt6BQCkMtJehPBiCEJMVx2BI27uAgcW/1R/yJr80Q== =jIKh -----END PGP SIGNATURE----- From Jerald.P.Martocci@jci.com Mon Nov 16 11:32:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46693A69AE; Mon, 16 Nov 2009 11:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MANGLED_YOUR=2.3, 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 K71iqPC-rT9P; Mon, 16 Nov 2009 11:32:47 -0800 (PST) Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by core3.amsl.com (Postfix) with ESMTP id CF4863A6989; Mon, 16 Nov 2009 11:32:46 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKSwGo2SY4w53AeYmEeG8jS1threR1AfiK@postini.com; Mon, 16 Nov 2009 11:32:46 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111613351095-3093786 ; Mon, 16 Nov 2009 13:35:10 -0600 In-Reply-To: <4AFE0C2E.70600@acm.org> MIME-Version: 1.0 To: Tim Winter X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 16 Nov 2009 13:32:28 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/16/2009 01:32:38 PM, Serialize complete at 11/16/2009 01:32:38 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/16/2009 01:35:10 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/16/2009 01:35:18 PM, Serialize complete at 11/16/2009 01:35:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006B592C86257670_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 19:32:49 -0000 This is a multipart message in MIME format. --=_alternative 006B592C86257670_= Content-Type: text/plain; charset="US-ASCII" Hi TIm, Can you clarify the use cases for DIS again? I am trying to piece together your response to Julien's email, but am not sure I'm getting it. I agree with Julien that we need a DIO solicitation message (i.e. DIS) since as he says a packet can't wait around for hours waiting for a new DAG parent. I buy that and agree with it. However, I am a bit confused why a multicast DIS should trigger a multicast DIO. This seems to simply add unnecessary packets onto the network. Why wouldn't a multicast DIS be responded to by a unicast DIO from each of the node's neighbors rather than a series of multicast DIOs from each of its neighbors. Jerry Tim Winter Sent by: roll-bounces@ietf.org 11/13/2009 07:47 PM To ROLL WG cc Subject Re: [Roll] need clarification: DIS processing WG, Upon further discussion we propose for -05 : - A multicast DIS will trigger multicast DIO (by resetting the trickle timer) as in support of case `2' below, where a node wants to poll the neighborhood - A unicast DIS will trigger a unicast DIO response. This is in consideration of the fact that DIO Configuration Options may not be included in every DIO- in the case where a node has, e.g., added a new parent and is uncertain about the DAG configuration, it may use a unicast DIS. In every unicast DIO response then the DAG Configuration MUST be included. Sounds good? - RPL Authors Philip Levis wrote: > > On Nov 11, 2009, at 4:04 PM, Tim Winter wrote: > >> Hi Julien, >> >> Julien Abeille (jabeille) wrote: >>> of course it needs jitter. Now trickle is armed anyway at all times >>> right (T timer). If we do not do anything specific, the DIO will not >>> come earlier with DIS than without... >>> So if no immediate response is needed, then DIS is not needed. I still >>> think it is, for instance anytime you lose you r last parent, and do not >>> want to wait possibly hours to get a DIO. This is the same as with RS/RA >>> (jittered !) >>> >> >> Yes, I agree DIS is needed also- and this is exactly how we got to >> DIS. It >> started by first allowing nodes to actively probe the neighborhood by >> using >> `RS' to solicit `RA-DIO'. from their neighborhood in previous RPL >> versions. >> This was thought to be useful, e.g., for battery powered nodes that do >> not >> want to wait. Now that RPL does not use RS/RA/NA we have introduced >> DIS for >> this exact purpose. >> >>> Resetting trickle (I to Imin, and T to random ) does not make sense I >>> guess, as sending a DIS does not always mean global instability. >>> Thoughts on how to arm a small jittered timer? >> >> It doesn't mean global instability- but it does mean that something has >> changed in the local neighborhood at least. So fair enough I think to >> reset >> trickle, to let trickle do it's job. I agree with prior comments- >> lets not >> make a special case here for DIS handling. > > I think that the Trickle text in the draft presents it in a narrower > light than which it's been used for routing protocols. A CTP node, for > example, resets the Trickle timer on three conditions: > > 1. It receives a packet to forward whose transmitter's routing cost <= > the receiver's routing cost. > 2. It receives a packet with the "P" bit set (the equivalent of a DIS). > 3. Its cost decreases significantly. > > We've all been discussing 1. But let's no forget conditions 2 and 3. For > 2, a node does not have entries in its neighbor table, then one could > say its logical topology is inconsistent with its physical topology. 3 > is very much a performance optimization. It handles the case when a node > might suddenly offer a much less expensive route than before, and its > neighbors view of its cost is out-of-date enough that it might lead to > sub-optimal behavior. > > My experience is that conditions 1 and 2 are both important, 3 is just a > small optimization. Using an exponentially increasing timer (rather than > just a jittered one) is critical. The reason is that, under sufficient > density, a given jittered interval can be too small and lead to many > collisions (don't forget we're LLNs, and so can be using low-power link > layers that don't work that well under broadcast storms). If you go back > to the Trickle paper, you'll note there were several experimental cases > where propagation took more than one timer interval per hop due to > collisions. Having an exponentially increasing timer solves this > problem: if the optimal interval length is L, then nodes will find it in > 2L, with a logarithmic message cost. This is part of what allows Trickle > to adapt to thousand-fold changes in network density. > >> The DIS should then also be multicast, and it should trigger multicast >> DIO >> responses. > > Agreed. > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006B592C86257670_= Content-Type: text/html; charset="US-ASCII"

Hi TIm,

Can you clarify the use cases for DIS again?  I am trying to piece together your response to Julien's email, but am not sure I'm getting it.

I agree with Julien that we need a DIO solicitation message (i.e. DIS) since as he says a packet can't wait around for hours waiting for a new DAG parent.  I buy that and agree with it.  However, I am a bit confused why a multicast DIS should trigger a multicast DIO.  This seems to simply add unnecessary packets onto the network.  Why wouldn't a multicast DIS be responded to by a unicast DIO from each of the node's neighbors rather than a series of multicast DIOs from each of its neighbors.

Jerry




Tim Winter <wintert@acm.org>
Sent by: roll-bounces@ietf.org

11/13/2009 07:47 PM

To
ROLL WG <roll@ietf.org>
cc
Subject
Re: [Roll] need clarification: DIS processing





WG,

Upon further discussion we propose for -05 :

                - A multicast DIS will trigger multicast DIO (by resetting the trickle
timer) as in support of case `2' below, where a node wants to poll the
neighborhood

                - A unicast DIS will trigger a unicast DIO response.  This is in
consideration of the fact that DIO Configuration Options may not be included
in every DIO- in the case where a node has, e.g., added a new parent and is
uncertain about the DAG configuration, it may use a unicast DIS.  In every
unicast DIO response then the DAG Configuration MUST be included.

Sounds good?

- RPL Authors


Philip Levis wrote:
>
> On Nov 11, 2009, at 4:04 PM, Tim Winter wrote:
>
>> Hi Julien,
>>
>> Julien Abeille (jabeille) wrote:
>>> of course it needs jitter. Now trickle is armed anyway at all times
>>> right (T timer). If we do not do anything specific, the DIO will not
>>> come earlier with DIS than without...
>>> So if no immediate response is needed, then DIS is not needed. I still
>>> think it is, for instance anytime you lose you r last parent, and do not
>>> want to wait possibly hours to get a DIO. This is the same as with RS/RA
>>> (jittered !)
>>>
>>
>> Yes, I agree DIS is needed also- and this is exactly how we got to
>> DIS.  It
>> started by first allowing nodes to actively probe the neighborhood by
>> using
>> `RS' to solicit `RA-DIO'. from their neighborhood in previous RPL
>> versions.
>> This was thought to be useful, e.g., for battery powered nodes that do
>> not
>> want to wait.  Now that RPL does not use RS/RA/NA we have introduced
>> DIS for
>> this exact purpose.
>>
>>> Resetting trickle (I to Imin, and T to random ) does not make sense I
>>> guess, as sending a DIS does not always mean global instability.
>>> Thoughts on how to arm a small jittered timer?
>>
>> It doesn't mean global instability- but it does mean that something has
>> changed in the local neighborhood at least.  So fair enough I think to
>> reset
>> trickle, to let trickle do it's job.  I agree with prior comments-
>> lets not
>> make a special case here for DIS handling.
>
> I think that the Trickle text in the draft presents it in a narrower
> light than which it's been used for routing protocols. A CTP node, for
> example, resets the Trickle timer on three conditions:
>
> 1. It receives a packet to forward whose transmitter's routing cost <=
> the receiver's routing cost.
> 2. It receives a packet with the "P" bit set (the equivalent of a DIS).
> 3. Its cost decreases significantly.
>
> We've all been discussing 1. But let's no forget conditions 2 and 3. For
> 2, a node does not have entries in its neighbor table, then one could
> say its logical topology is inconsistent with its physical topology. 3
> is very much a performance optimization. It handles the case when a node
> might suddenly offer a much less expensive route than before, and its
> neighbors view of its cost is out-of-date enough that it might lead to
> sub-optimal behavior.
>
> My experience is that conditions 1 and 2 are both important, 3 is just a
> small optimization. Using an exponentially increasing timer (rather than
> just a jittered one) is critical. The reason is that, under sufficient
> density, a given jittered interval can be too small and lead to many
> collisions (don't forget we're LLNs, and so can be using low-power link
> layers that don't work that well under broadcast storms). If you go back
> to the Trickle paper, you'll note there were several experimental cases
> where propagation took more than one timer interval per hop due to
> collisions. Having an exponentially increasing timer solves this
> problem: if the optimal interval length is L, then nodes will find it in
> 2L, with a logarithmic message cost. This is part of what allows Trickle
> to adapt to thousand-fold changes in network density.
>
>> The DIS should then also be multicast, and it should trigger multicast
>> DIO
>> responses.
>
> Agreed.
>
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006B592C86257670_=-- From mcr@marajade.sandelman.ca Mon Nov 16 11:50:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA793A6AD7 for ; Mon, 16 Nov 2009 11:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYZbuVIBRulm for ; Mon, 16 Nov 2009 11:50:05 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2FD343A69FE for ; Mon, 16 Nov 2009 11:50:05 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id B13DD34300 for ; Mon, 16 Nov 2009 14:41:32 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 95A3B4E794 for ; Mon, 16 Nov 2009 14:50:02 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 16 Nov 2009 14:50:02 -0500 Message-ID: <20924.1258401002@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 19:50:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I agree with Julien that we need a DIO solicitation message Jerald> (i.e. DIS) since as he says a packet can't wait around for Jerald> hours waiting for a new DAG parent. I buy that and agree Jerald> with it. However, I am a bit confused why a multicast DIS Jerald> should trigger a multicast DIO. This seems to simply add Jerald> unnecessary packets onto the network. I am reacting to the last sentence. I'd have thought that multicast avoids unncesary packets!!!! So perhaps we are not talking about the same thing? Maybe we need better terminology. I think that there are three kinds of transmission: a) unicast b) link-level multicast c) subnet-level multicast On ethernet, (b) and (c) are the same thing. On 6lowpan-type networks, I think (b) is what happens when you transmit to the nodes that can hear you, and (c) is what you do via a whiteboard or multicast relay. (Maybe there are accepted terms for this, of which I am ignorant) Only transmissions of type (c) cause more packets on the wire. Transmissions of type (b) would save packets, because one message arrives at many receivers at the same time. Maybe (b) causes receivers that would otherwise have been happy to sleep (doze?) to wake up. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg== =MCIA -----END PGP SIGNATURE----- From roger.alexander@ekasystems.com Mon Nov 16 15:33:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23F03A6A01 for ; Mon, 16 Nov 2009 15:33:49 -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, 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 RW3I+sWktabg for ; Mon, 16 Nov 2009 15:33:48 -0800 (PST) Received: from n21.bullet.mail.mud.yahoo.com (n21.bullet.mail.mud.yahoo.com [68.142.206.160]) by core3.amsl.com (Postfix) with SMTP id 323E73A6B3F for ; Mon, 16 Nov 2009 15:33:48 -0800 (PST) Received: from [68.142.200.227] by n21.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2009 23:33:45 -0000 Received: from [68.142.201.69] by t8.bullet.mud.yahoo.com with NNFMP; 16 Nov 2009 23:33:45 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 16 Nov 2009 23:33:45 -0000 X-Yahoo-Newman-Id: 265707.72673.bm@omp421.mail.mud.yahoo.com Received: (qmail 97569 invoked from network); 16 Nov 2009 23:33:44 -0000 Received: from 166-205-133-088.mobile.mymmode.com (roger.alexander@166.205.133.88 with plain) by smtp109.biz.mail.sp1.yahoo.com with SMTP; 16 Nov 2009 15:33:40 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: x.A0hRYVM1nQmg67DJp_hFqHte8yM.ngcQhhs94kWSPACBS4zwbFKUjnXw.t.24hVcScHIaM56STV7Ksy8UO5bxlugyYFqIE8DYw_uoPIIJkIBGxoM_YwVBkDvS1Vt05XGdIIFcqIaRwEr8Qcqsta6KH9YgPVmbth7x9bAJv.Cyx2ASzO9UGLsLo7U5x..d8s0zPRfo3Nl4gS6vaM5S0rtptrEX1tlCTe4ONkATiB9nuHotGzR_gYj.1Q851vHUDQ65rd0g7Eoa59NDjavHbiWXpfZB8S97W5djyA2cleGOiwSvurTdswixeGy19nU.56fSqMoUZ3YpLG1aeGP7jpA1Mdu3ajPtrRWy_O31uoBnZmetHmylwIxV0YnjGL45xOG1T8UsRqPMcjEnASOenueAuMnZtn2R1poqODX0uADIGk5ss9D83V.OlMqWIQhaBSQ-- X-Yahoo-Newman-Property: ymail-3 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> Message-Id: <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> From: Roger Alexander To: Michael Richardson In-Reply-To: <13293.1258166652@marajade.sandelman.ca> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 16 Nov 2009 15:33:33 -0800 Cc: "roll@ietf.org" Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 23:33:49 -0000 On Nov 13, 2009, at 6:44 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Richard" == Richard Kelsey writes: > mcr> I guess it might be enough to have a bit that gets turned by > the > mcr> first non-root node that stores DAOs. > > Richard> I think you need two bits. One is turned on by the root > if > Richard> it stores DAOs and the other is turned on by any > Richard> intermediate node that stores them. > > I didn't realize that the root could *not* store DAOs...! > I'm trying to imagine how that works. > I can perhaps see how this might be the case with an ungrounded DAG, > where some random DAO-incapable node decides to become the new root. > > mcr> If I understand correctly, if the intermediate nodes do not > store > mcr> DAOs, then they won't have a routing table to other peers, > so p2p > mcr> traffic will have to travel all the way up to the root and out > mcr> again. > > Richard> Yes. On the other hand, the DAG formation mechanism works > Richard> to maximize downward fanout, which in turn maximizes the > Richard> number of P2P routes that go through the root even if all > Richard> nodes store DAOs. For example, if the root has N children > Richard> with roughly equal subgraphs, then each node can reach > only > Richard> 1/N of the network without through the root. > > Yeah, I can see how a relatively uniformly distributed DAG would have > this property. I can also see where this would not be the case, such > as a long linear network, such as a series of lampposts or utility > poles > along a rural road... where the grounded node is at one of the road. > >>> It seemed to me like a compromise that the root had to be able to >>> create source routes so that weaker intermediate nodes could >>> avoid storing the DAOs. That this wasn't the ideal situation, but >>> was a compromise. >>> >>> What happens if we insist all nodes store DAOs? (is it simpler?) > > Richard> That uses too much RAM for us to require it. > > Yes, I understand why we can not do it. > > You see, I'm asking what the real tradeoff is about this. > If ram and CPU was free, but network bandwidth was not, would we > decide to force all nodes to store DAOs? > JP has suggested that it helps. It does help when intermediate nodes store DAOs since DAO information should only need to be passed further up towards the root when the info represents a change in outward (to leaves) connectivity. That is, if a node changes parent and reattaches to a new branch that information only needs to travel inward towards the root to the point in the tree that held an outward table containing the given node. Granted it may be in some cases that point is at the root itself. However, in the absence of DAO storage at intermediate nodes a node's change of parent must always be conveyed all the way to the root so that outward connectivity (via source routing) can be supported. For nodes not maintaining state, the change of parent information must always flow back to the root or otherwise to the first DAO storing node (which may then need to update it's parent(s) if the stateless node was not previuosly reachable via the stateful node). > > I can see with a linear network where there is traffic up and down > the > line, that without DAO storing nodes in the middle, traffic has to go > all the way to the end and back. > >>> What happens if we insist that no nodes store DAOs? (is it >>> simpler?) > > Richard> Do you mean no nodes at all, or no nodes other than the > Richard> root? > > No nodes other than the root.... > Nothing would work if nobody knew the routes, right. > > Richard> If only the root stores DAOs, then most of the P2P traffic > Richard> will go through the root. As I said above, this is often > Richard> the case even if all node's store DAOs. I think this > would > Richard> be OK. Even without intermediate DAO storage, routing > Richard> packets directly to neighbors will reduce the P2P messages > Richard> traveling through the root. Devices that require more > Richard> bandwidth (in or out) can become roots of their own DAGs, > Richard> as long as the number of such devices is limited. > > To summarize, forbidding intermediate nodes to store DAOs: > - causes a loss in quality for p2p traffic for some topologies, It also creates additional routing traffic towards the root which is needed so that the reverse path information from the root to the node can be conveyed to the root for subsequent outward routing. > but for many topologies has a neglible effect > - causes no change for m2p > - massively reduces traffic when there is a new parent chosen > - simplifies the protocol (no need to record who records DAOs) Not clear why there is a need to know who records DAOs. In response to a new child a parent that does maintain state will add itself to the path information from the child and pass that information to it's parent. That information will pass inward towards the root until a node is encountered that can store the path information and previously supported connectivity to the node at the same cost. > - removes the need for code to do different things depending > upon whether there are DAO storing nodes above, when changing > parents. The node that do not store > > Or to be it another way, capable nodes that have the ram to store > DAOs > are causing load on less capable nodes. They aren't being very > helpful. > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF > AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl > p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 > WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko > xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF > YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg== > =slpm > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Mon Nov 16 15:42:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF30E3A6A15 for ; Mon, 16 Nov 2009 15:42:57 -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, 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 qTB7B7POybB1 for ; Mon, 16 Nov 2009 15:42:54 -0800 (PST) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id A86393A679C for ; Mon, 16 Nov 2009 15:42:54 -0800 (PST) Received: from [68.142.200.226] by n17.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2009 23:42:51 -0000 Received: from [68.142.201.248] by t7.bullet.mud.yahoo.com with NNFMP; 16 Nov 2009 23:42:51 -0000 Received: from [127.0.0.1] by omp409.mail.mud.yahoo.com with NNFMP; 16 Nov 2009 23:42:51 -0000 X-Yahoo-Newman-Id: 616499.41245.bm@omp409.mail.mud.yahoo.com Received: (qmail 1432 invoked from network); 16 Nov 2009 23:42:51 -0000 Received: from 166-205-133-088.mobile.mymmode.com (roger.alexander@166.205.133.88 with plain) by smtp106.biz.mail.sp1.yahoo.com with SMTP; 16 Nov 2009 15:42:47 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 1btSrckVM1ns5zx0sGMKa7VqJdV7.ljcVhIdiNbyIZuIfSEKRxoHnSkb0iIdSHl4WGbydPrHsDmMGGzFYdrOe4cY.iZUoqd8Z8fLpIa_eeShZhfY3uPj098IXd5RzYRee6SibsDFoXAbUYnI9wAv2gBKXPyqE.sf0vaLb_Njq9YaOkvaQoW9gOFXTkaDORV6C5EwFo3wj8hgfRXp.dPH5m2iffEfRcJBF5h3rBE3NDoPqKtQD19jzCP63RAWgP5dfC_9n6.q8.kEQDi6kSqmanIU1J8yM3Vpjh4AO4LVUd5aF8AYfwtav2DVJ5z8gXTAexszr9DsrQRBoQ-- X-Yahoo-Newman-Property: ymail-3 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> Message-Id: <6048261E-D42B-4366-A0CC-EBD56598020A@ekasystems.com> From: Roger Alexander To: Roger Alexander In-Reply-To: <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 16 Nov 2009 15:42:42 -0800 Cc: "roll@ietf.org" Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Nov 2009 23:42:57 -0000 Sorry for the earlier transmission of the incomplete email...(moving vehicle)...final thoughts completed below. Thanks. Roger On Nov 16, 2009, at 3:33 PM, Roger Alexander wrote: > > > On Nov 13, 2009, at 6:44 PM, Michael Richardson > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>>>>>> "Richard" == Richard Kelsey writes: >> mcr> I guess it might be enough to have a bit that gets turned by >> the >> mcr> first non-root node that stores DAOs. >> >> Richard> I think you need two bits. One is turned on by the root >> if >> Richard> it stores DAOs and the other is turned on by any >> Richard> intermediate node that stores them. >> >> I didn't realize that the root could *not* store DAOs...! >> I'm trying to imagine how that works. >> I can perhaps see how this might be the case with an ungrounded DAG, >> where some random DAO-incapable node decides to become the new root. >> >> mcr> If I understand correctly, if the intermediate nodes do not >> store >> mcr> DAOs, then they won't have a routing table to other peers, >> so p2p >> mcr> traffic will have to travel all the way up to the root and out >> mcr> again. >> >> Richard> Yes. On the other hand, the DAG formation mechanism works >> Richard> to maximize downward fanout, which in turn maximizes the >> Richard> number of P2P routes that go through the root even if all >> Richard> nodes store DAOs. For example, if the root has N children >> Richard> with roughly equal subgraphs, then each node can reach >> only >> Richard> 1/N of the network without through the root. >> >> Yeah, I can see how a relatively uniformly distributed DAG would have >> this property. I can also see where this would not be the case, >> such >> as a long linear network, such as a series of lampposts or utility >> poles >> along a rural road... where the grounded node is at one of the road. >> >>>> It seemed to me like a compromise that the root had to be able to >>>> create source routes so that weaker intermediate nodes could >>>> avoid storing the DAOs. That this wasn't the ideal situation, but >>>> was a compromise. >>>> >>>> What happens if we insist all nodes store DAOs? (is it simpler?) >> >> Richard> That uses too much RAM for us to require it. >> >> Yes, I understand why we can not do it. >> >> You see, I'm asking what the real tradeoff is about this. >> If ram and CPU was free, but network bandwidth was not, would we >> decide to force all nodes to store DAOs? >> JP has suggested that it helps. > > It does help when intermediate nodes store DAOs since DAO > information should only need to be passed further up towards the > root when the info represents a change in outward (to leaves) > connectivity. That is, if a node changes parent and reattaches to a > new branch that information only needs to travel inward towards the > root to the point in the tree that held an outward table containing > the given node. Granted it may be in some cases that point is at the > root itself. However, in the absence of DAO storage at intermediate > nodes a node's change of parent must always be conveyed all the way > to the root so that outward connectivity (via source routing) can be > supported. For nodes not maintaining state, the change of parent > information must always flow back to the root or otherwise to the > first DAO storing node (which may then need to update it's parent(s) > if the stateless node was not previuosly reachable via the stateful > node). >> >> I can see with a linear network where there is traffic up and down >> the >> line, that without DAO storing nodes in the middle, traffic has to go >> all the way to the end and back. >> >>>> What happens if we insist that no nodes store DAOs? (is it >>>> simpler?) >> >> Richard> Do you mean no nodes at all, or no nodes other than the >> Richard> root? >> >> No nodes other than the root.... >> Nothing would work if nobody knew the routes, right. >> >> Richard> If only the root stores DAOs, then most of the P2P traffic >> Richard> will go through the root. As I said above, this is often >> Richard> the case even if all node's store DAOs. I think this >> would >> Richard> be OK. Even without intermediate DAO storage, routing >> Richard> packets directly to neighbors will reduce the P2P messages >> Richard> traveling through the root. Devices that require more >> Richard> bandwidth (in or out) can become roots of their own DAGs, >> Richard> as long as the number of such devices is limited. >> >> To summarize, forbidding intermediate nodes to store DAOs: >> - causes a loss in quality for p2p traffic for some topologies, > > It also creates additional routing traffic towards the root which is > needed so that the reverse path information from the root to the > node can be conveyed to the root for subsequent outward routing. > >> but for many topologies has a neglible effect >> - causes no change for m2p >> - massively reduces traffic when there is a new parent chosen >> - simplifies the protocol (no need to record who records DAOs) > > Not clear why there is a need to know who records DAOs. In response > to a new child a parent that does maintain state will add itself to > the path information from the child and pass that information to > it's parent. That information will pass inward towards the root > until a node is encountered that can store the path information and > previously supported connectivity to the node at the same cost. > >> - removes the need for code to do different things depending >> upon whether there are DAO storing nodes above, when changing >> parents. > > The nodes that do not store DAOs can have a consistent behavior > while those that do can similarly also be consistent. >> >> Or to be it another way, capable nodes that have the ram to store >> DAOs >> are causing load on less capable nodes. They aren't being very >> helpful. >> It seems that the intermediate nodes that do maintain DAOs can limit overhead by avoiding the need for all changes in node connectivity to the DAG from having to always go all the way to the root to provide for maintaining an outward path. Furthermore if only the root stores DAOs the RPL reduces to a source routing protocol which may be an issue. >> - -- >> ] He who is tired of Weird Al is tired of life! | >> firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON | >> net architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | >> device driver[ >> Kyoto Plus: watch the video > > >> then sign the petition. >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Finger me for keys >> >> iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF >> AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl >> p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 >> WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko >> xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF >> YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg== >> =slpm >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 16 23:16:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E008F3A6B8A for ; Mon, 16 Nov 2009 23:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-a4ttvYnbta for ; Mon, 16 Nov 2009 23:16:28 -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 1DE623A6870 for ; Mon, 16 Nov 2009 23:16:27 -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: AkAAAEPcAUuQ/uCWe2dsb2JhbACCIiyZTwEBCwskBqITl3OCLIIPBA X-IronPort-AV: E=Sophos;i="4.44,757,1249257600"; d="scan'208,217";a="54529226" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2009 07:16:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAH7GK19019869 for ; Tue, 17 Nov 2009 07:16:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 08:16:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6755.DCA325A3" x-cr-puzzleid: {05F1D5CF-C7C9-46DF-AEFF-A8601A380804} x-cr-hashedpuzzle: AGLH Aq3L C16n C5Oa FUaB FiP5 G+kT Heac H2i2 I9Cv JRhl JpkX J1vQ KAjm Kdsj KyZ+; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {05F1D5CF-C7C9-46DF-AEFF-A8601A380804}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 17 Nov 2009 07:13:06 GMT; ZABvACAAdwBlACAAbgBlAGUAZAAgAGEAIABkAG8AbQBpAG4AYQB0AGkAbgBnACAAcwBlAHQAPwA= Content-class: urn:content-classes:message Date: Tue, 17 Nov 2009 08:13:06 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: do we need a dominating set? Thread-Index: AcpnVWi8F8N4DULWSviWtWbfWQg3iQ== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 17 Nov 2009 07:16:20.0710 (UTC) FILETIME=[DCC29060:01CA6755] Subject: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 07:16:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6755.DCA325A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 The current RPL draft uses trickle to address density. Trickle has a number of fine properties to throttle the control when things are stable. Still, when an accident occurs, like a parent high in the DAG degrades its rank, possibly most of the nodes in the whole network will have to reassess their rank and reset their trickle timer. My understanding of that process is that it can yield quite a bit of activity, that grows with the number of nodes acting as routers. =20 What I think is that even if we have trickle, we should be considering some control on the density of nodes that act as a router. To address that, there's already ample work and large WSN deployments that leverage the concept of dominating set. A dominating set is a connected set of routers that enables connectivity for all, that is all nodes in the network is connected to at least one member of the dominating set. =20 Because we have trickle, such a set does not need to be shrink to minimal/optimal. In fact, we'd want that each node in the network sees at least 2 members of the dominating set. =20 Can that be achieved simply? Possibly. =20 Each time a new sequence is spread, nodes are entitled to reassess their need to be a router. When the sequence spreads, a form of trickle could be used to decide Not TO advertise self as a router and act as a host for the new sequence. Like if enough neighbor routers advertise the new sequence before T elapse, then there might be no need for self to act as a router. =20 Thoughts? =20 Pascal ------_=_NextPart_001_01CA6755.DCA325A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

The current RPL draft uses trickle to address = density. Trickle has a number of fine properties to throttle the control when things are = stable.

Still, when an accident occurs, like a parent high = in the DAG degrades its rank, possibly most of the nodes in the whole network = will have to reassess their rank and reset their trickle = timer.

My understanding of that  process is that it = can yield quite a bit of activity, that grows with the number of nodes acting as = routers.

 

What I think is that even if we have trickle, we = should be considering some control on the density of nodes that act as a router. = To address that, there’s already ample work and large WSN deployments = that leverage the concept of dominating set.

 A dominating set is a connected set of = routers that enables connectivity for all, that is all nodes in the network is = connected to at least one member of the dominating set.

 

Because we have trickle, such a set does not need = to be  shrink to minimal/optimal. In fact, we’d want that each node in the = network sees at least 2 members of the dominating set.

 

Can that be achieved simply? = Possibly.

 

Each time a new sequence is spread, nodes are = entitled to reassess their need to be a router. When the sequence spreads, a form of trickle could be used to decide Not TO advertise self as a router and = act as a host for the new sequence.

Like if enough neighbor routers advertise the new = sequence before T elapse, then there might be no need for self to act as a = router.

 

Thoughts?

 

Pascal

------_=_NextPart_001_01CA6755.DCA325A3-- From maxence.dalmais@insa-lyon.fr Tue Nov 17 00:26:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABC03A6B9B for ; Tue, 17 Nov 2009 00:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 XJSmA00Y2eJh for ; Tue, 17 Nov 2009 00:26:11 -0800 (PST) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id 8D1F83A69FD for ; Tue, 17 Nov 2009 00:26:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id D1902F12CE for ; Tue, 17 Nov 2009 09:26:09 +0100 (CET) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVLkSoxnx7DE for ; Tue, 17 Nov 2009 09:26:09 +0100 (CET) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 8FAFBF12BC for ; Tue, 17 Nov 2009 09:26:09 +0100 (CET) Received: by fxm7 with SMTP id 7so6684720fxm.29 for ; Tue, 17 Nov 2009 00:26:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.167.83 with SMTP id f19mr68062hbe.34.1258446369142; Tue, 17 Nov 2009 00:26:09 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> From: Maxence Dalmais Date: Tue, 17 Nov 2009 09:25:49 +0100 Message-ID: To: "Pascal Thubert (pthubert)" , roll ROLL Content-Type: multipart/alternative; boundary=001485f0aceacd3a6004788ce0d4 Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 08:26:12 -0000 --001485f0aceacd3a6004788ce0d4 Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal, the idea seems good to me but I got a question : -How nodes act during the sequence spreading ? I mean : Does a node which acted as a router and currently does not advertise as it continue to route during the T time ? Moreover, does the fact to change his status of router or not does not increase packets lost or the number of sent ICMP Destination Unreachable packet ? Maxence. --001485f0aceacd3a6004788ce0d4 Content-Type: text/html; charset=ISO-8859-1 Hi Pascal,

the idea seems good to me but I got a question :
-How nodes act during the sequence spreading ?
I mean : Does a node which acted as a router and currently does not advertise as it continue to route during the T time ?
Moreover, does the fact to change his status of router or not does not increase packets lost or the number of sent ICMP Destination Unreachable packet ?

Maxence.
 --001485f0aceacd3a6004788ce0d4-- From pthubert@cisco.com Tue Nov 17 03:39:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49983A6836 for ; Tue, 17 Nov 2009 03:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[AWL=1.100, 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 bmk5dUMU00Zz for ; Tue, 17 Nov 2009 03:39:06 -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 9AD863A67DF for ; Tue, 17 Nov 2009 03:39:05 -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: AjwAAF4aAkuQ/uCWe2dsb2JhbACcHQEBCwskBqF2mBaEOwSBbQ X-IronPort-AV: E=Sophos;i="4.44,757,1249257600"; d="scan'208";a="54558169" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2009 11:38:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHBcvPE010156; Tue, 17 Nov 2009 11:38:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 12:38:57 +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: Tue, 17 Nov 2009 12:38:52 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABA8F@XMB-AMS-107.cisco.com> In-Reply-To: <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing on Ticket #10 Thread-Index: AcpkjZXDkwiquFlmSiySU8E4ks6xlgC63noA References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com><5896.1258078243@marajade.sandelman.ca><87r5s24fh9.fsf@kelsey-ws.hq.ember.com><9328.1258127853@marajade.sandelman.ca> <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , "Michael Richardson" X-OriginalArrivalTime: 17 Nov 2009 11:38:57.0397 (UTC) FILETIME=[8C7A3250:01CA677A] Cc: roll@ietf.org Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 11:39:06 -0000 Hi Richard >My hope is that we will need no more than one or two OFxs. >The reason we need to be flexible now is not that we are >likely to need many of them, but that we don't know which >ones are the right ones. We disagree on this. There might be one or 2 OCPs coming out with for RPL for this round of specification, OK. Probably more if we really need to meet all the requirement drafts. But there could be many different sorts of deployments that we do not cover here, and thus many OCPs, some defined in some future at the IETF, some designed by other SDOs like of ETSI, ISA or IEC, and some proprietary value-added proposals. As long as the OCP conform the general rules in RPL, that should be fine, and the generic part of the wheel does not have to be reinvented each time. My hope when I designed the plugins in MANEMO was to build a generic DV platform that could be instantiated for many specific environments, just like SIP can. RPL inherited the concept, though it lost/barred the capability to mix OCPs and degrade to OCP0 at the edges.=20 Still, the loop avoidance remains totally generic, based on an abstract rank, so RPL retains the capability to be instantiated in many fashions. I think that is a powerful idea. Pascal From Jerald.P.Martocci@jci.com Tue Nov 17 06:32:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9563A689E; Tue, 17 Nov 2009 06:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.704 X-Spam-Level: X-Spam-Status: No, score=-4.704 tagged_above=-999 required=5 tests=[AWL=1.894, BAYES_00=-2.599, 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 dp62-4soIqjZ; Tue, 17 Nov 2009 06:32:06 -0800 (PST) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with ESMTP id 7A7FF28C15C; Tue, 17 Nov 2009 06:32:04 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKSwKz3Bae5St/GSaR3LY/ipFSGjgu8Oct@postini.com; Tue, 17 Nov 2009 06:32:04 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111708343048-3167079 ; Tue, 17 Nov 2009 08:34:30 -0600 In-Reply-To: <20924.1258401002@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 08:31:40 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 08:31:48 AM, Serialize complete at 11/17/2009 08:31:48 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 08:34:30 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 08:34:45 AM, Serialize complete at 11/17/2009 08:34:45 AM Content-Type: multipart/alternative; boundary="=_alternative 004FCF0E86257671_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 14:32:08 -0000 This is a multipart message in MIME format. --=_alternative 004FCF0E86257671_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Yes you're right, whether the responses to a DIS are multicast or unicast, the packet count is the same. However, if the responses are multicasts (rather than unicasts) then other nodes are necessarily interpreting packets that are really not destined to them. I would prefer the responses to a multicast DIS be a series of unicast DIOs. Michael Richardson Sent by: roll-bounces@ietf.org 11/16/2009 01:50 PM To ROLL WG cc Subject Re: [Roll] need clarification: DIS processing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I agree with Julien that we need a DIO solicitation message Jerald> (i.e. DIS) since as he says a packet can't wait around for Jerald> hours waiting for a new DAG parent. I buy that and agree Jerald> with it. However, I am a bit confused why a multicast DIS Jerald> should trigger a multicast DIO. This seems to simply add Jerald> unnecessary packets onto the network. I am reacting to the last sentence. I'd have thought that multicast avoids unncesary packets!!!! So perhaps we are not talking about the same thing? Maybe we need better terminology. I think that there are three kinds of transmission: a) unicast b) link-level multicast c) subnet-level multicast On ethernet, (b) and (c) are the same thing. On 6lowpan-type networks, I think (b) is what happens when you transmit to the nodes that can hear you, and (c) is what you do via a whiteboard or multicast relay. (Maybe there are accepted terms for this, of which I am ignorant) Only transmissions of type (c) cause more packets on the wire. Transmissions of type (b) would save packets, because one message arrives at many receivers at the same time. Maybe (b) causes receivers that would otherwise have been happy to sleep (doze?) to wake up. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg== =MCIA -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 004FCF0E86257671_= Content-Type: text/html; charset="US-ASCII"

Hi Michael,

Yes you're right, whether the responses to a DIS are multicast or unicast, the packet count is the same.  However, if the responses are multicasts (rather than unicasts) then other nodes are necessarily interpreting packets that are really not destined to them.  I would prefer the responses to a multicast DIS be a series of unicast DIOs.




Michael Richardson <mcr@sandelman.ca>
Sent by: roll-bounces@ietf.org

11/16/2009 01:50 PM

To
ROLL WG <roll@ietf.org>
cc
Subject
Re: [Roll] need clarification: DIS processing





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
   Jerald> I agree with Julien that we need a DIO solicitation message
   Jerald> (i.e. DIS) since as he says a packet can't wait around for
   Jerald> hours waiting for a new DAG parent.  I buy that and agree
   Jerald> with it.  However, I am a bit confused why a multicast DIS
   Jerald> should trigger a multicast DIO.  This seems to simply add
   Jerald> unnecessary packets onto the network.  

 I am reacting to the last sentence.
 I'd have thought that multicast avoids unncesary packets!!!!
 So perhaps we are not talking about the same thing?

 Maybe we need better terminology.
 I think that there are three kinds of transmission:
   a) unicast
   b) link-level multicast
   c) subnet-level multicast
 On ethernet, (b) and (c) are the same thing.

 On 6lowpan-type networks, I think (b) is what happens when you
transmit to the nodes that can hear you, and (c) is what you do via a
whiteboard or multicast relay.

 (Maybe there are accepted terms for this, of which I am ignorant)

 Only transmissions of type (c) cause more packets on the wire.

 Transmissions of type (b) would save packets, because one message
arrives at many receivers at the same time.  Maybe (b) causes receivers
that would otherwise have been happy to sleep (doze?) to wake up.

- --
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH
LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL
IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s
eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp
U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG
VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg==
=MCIA
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 004FCF0E86257671_=-- From mcr@marajade.sandelman.ca Tue Nov 17 07:12:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A3A3A6AB6; Tue, 17 Nov 2009 07:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znvjlkMysFTA; Tue, 17 Nov 2009 07:12:26 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 59BAF3A6AAE; Tue, 17 Nov 2009 07:12:25 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D5019342F5; Tue, 17 Nov 2009 10:03:56 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 589B34E793; Tue, 17 Nov 2009 10:12:23 -0500 (EST) From: Michael Richardson To: Jerald.P.Martocci@jci.com In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 17 Nov 2009 10:12:23 -0500 Message-ID: <9186.1258470743@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 15:12:27 -0000 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> Yes you're right, whether the responses to a DIS are Jerald> multicast or unicast, the packet count is the same. Jerald> However, if the responses are multicasts (rather than Jerald> unicasts) then other nodes are necessarily interpreting Jerald> packets that are really not destined to them. I would Jerald> prefer the responses to a multicast DIS be a series of Jerald> unicast DIOs. So, what concerns you is the wake-up cost of the extra DIOs. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From joakime@sics.se Tue Nov 17 07:20:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4393A6BC5 for ; Tue, 17 Nov 2009 07:20:20 -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 IR0hsJLKHWsm for ; Tue, 17 Nov 2009 07:20:19 -0800 (PST) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by core3.amsl.com (Postfix) with ESMTP id 6FB253A6AC4 for ; Tue, 17 Nov 2009 07:20:19 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC00FBCBBD for roll@ietf.org; Tue, 17 Nov 2009 16:20:17 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvZGAGdOAktV5BNMPGdsb2JhbAAImSiCYwEBAQE3uzOEOwQ X-IronPort-AV: E=Sophos;i="4.44,758,1249250400"; d="scan'208";a="4526063" Received: from c-4c13e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.19.76]) by ipb1.telenor.se with ESMTP; 17 Nov 2009 16:20:17 +0100 Message-ID: <4B02BF47.9030203@sics.se> Date: Tue, 17 Nov 2009 16:20:39 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Richardson References: <9186.1258470743@marajade.sandelman.ca> In-Reply-To: <9186.1258470743@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 15:20:20 -0000 On the other hand it might be possible to do redundancy-count of the multi-cast DIOs for all nodes in range and thereby get lower likelihood of sending a DIO when the trickle timer triggers next time!? Best regards, -- Joakim Eriksson, SICS Michael Richardson skrev: >>>>>> "Jerald" == Jerald P Martocci writes: > Jerald> Yes you're right, whether the responses to a DIS are > Jerald> multicast or unicast, the packet count is the same. > Jerald> However, if the responses are multicasts (rather than > Jerald> unicasts) then other nodes are necessarily interpreting > Jerald> packets that are really not destined to them. I would > Jerald> prefer the responses to a multicast DIS be a series of > Jerald> unicast DIOs. > > So, what concerns you is the wake-up cost of the extra DIOs. > From Jerald.P.Martocci@jci.com Tue Nov 17 07:42:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4AAB3A694F; Tue, 17 Nov 2009 07:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, 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 rc9x2capD7zS; Tue, 17 Nov 2009 07:42:14 -0800 (PST) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 055DB3A677E; Tue, 17 Nov 2009 07:42:13 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSwLETzBRerOeI8z1H7F1mOQK6VtCJcct@postini.com; Tue, 17 Nov 2009 07:42:13 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111709444181-3177106 ; Tue, 17 Nov 2009 09:44:41 -0600 In-Reply-To: <9186.1258470743@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 09:41:48 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 09:41:58 AM, Serialize complete at 11/17/2009 09:41:58 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 09:44:42 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 09:44:55 AM, Serialize complete at 11/17/2009 09:44:55 AM Content-Type: multipart/alternative; boundary="=_alternative 00563AC886257671_=" Cc: ROLL WG , roll-bounces@ietf.org, mcr@marajade.sandelman.ca Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 15:42:15 -0000 This is a multipart message in MIME format. --=_alternative 00563AC886257671_= Content-Type: text/plain; charset="US-ASCII" Michael, No. Just the extra processing requirement to handle messages not destined for the device. As I have stated many times, these devices are small controllers that provide environmental control as their first priority, and route packets as a side job. The less they need to deal with communication messages, the more they can control the environment. Jerry Michael Richardson Sent by: mcr@marajade.sandelman.ca 11/17/2009 09:12 AM To Jerald.P.Martocci@jci.com cc ROLL WG , roll-bounces@ietf.org Subject Re: [Roll] need clarification: DIS processing >>>>> "Jerald" == Jerald P Martocci writes: Jerald> Yes you're right, whether the responses to a DIS are Jerald> multicast or unicast, the packet count is the same. Jerald> However, if the responses are multicasts (rather than Jerald> unicasts) then other nodes are necessarily interpreting Jerald> packets that are really not destined to them. I would Jerald> prefer the responses to a multicast DIS be a series of Jerald> unicast DIOs. So, what concerns you is the wake-up cost of the extra DIOs. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. --=_alternative 00563AC886257671_= Content-Type: text/html; charset="US-ASCII"
Michael,

No. Just the extra processing requirement to handle messages not destined for the device.  As I have stated many times, these devices are small controllers that provide environmental control as their first priority, and route packets as a side job.  The less they need to deal with communication messages, the more they can control the environment.


Jerry




Michael Richardson <mcr@sandelman.ca>
Sent by: mcr@marajade.sandelman.ca

11/17/2009 09:12 AM

To
Jerald.P.Martocci@jci.com
cc
ROLL WG <roll@ietf.org>, roll-bounces@ietf.org
Subject
Re: [Roll] need clarification: DIS processing






>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
   Jerald> Yes you're right, whether the responses to a DIS are
   Jerald> multicast or unicast, the packet count is the same.
   Jerald> However, if the responses are multicasts (rather than
   Jerald> unicasts) then other nodes are necessarily interpreting
   Jerald> packets that are really not destined to them.  I would
   Jerald> prefer the responses to a multicast DIS be a series of
   Jerald> unicast DIOs.

So, what concerns you is the wake-up cost of the extra DIOs.

--
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.

--=_alternative 00563AC886257671_=-- From pal@cs.stanford.edu Tue Nov 17 08:09:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE723A6BC5; Tue, 17 Nov 2009 08:09:14 -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 j-st63pXSIYU; Tue, 17 Nov 2009 08:09:13 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 6CCA83A6AB6; Tue, 17 Nov 2009 08:09:13 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAQb8-0007sg-NZ; Tue, 17 Nov 2009 08:08:26 -0800 Message-Id: From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 08:08:02 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:09:14 -0000 On Nov 17, 2009, at 6:31 AM, Jerald.P.Martocci@jci.com wrote: > > > Hi Michael, > > Yes you're right, whether the responses to a DIS are multicast or > unicast, the packet count is the same. However, if the responses > are multicasts (rather than unicasts) then other nodes are > necessarily interpreting packets that are really not destined to > them. I would prefer the responses to a multicast DIS be a series > of unicast DIOs. How would this work? To what destination(s) would the node send a series of unicast DIOs? This should be a lower-layer decision: it's up to lower layers to know/decide how best to implement a multicast. Phil From pal@cs.stanford.edu Tue Nov 17 08:11:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8F028C16A for ; Tue, 17 Nov 2009 08:11:03 -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 DCEgN8ruQfMG for ; Tue, 17 Nov 2009 08:11:02 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 4D7BF28C17D for ; Tue, 17 Nov 2009 08:11:02 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAQdv-00084c-LL; Tue, 17 Nov 2009 08:11:00 -0800 Message-Id: <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 08:10:57 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: b0d2d5ababd8fe43140185de29a9e1cb Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:11:04 -0000 On Nov 16, 2009, at 11:13 PM, Pascal Thubert (pthubert) wrote: > Hi: > > The current RPL draft uses trickle to address density. Trickle has a =20= > number of fine properties to throttle the control when things are =20 > stable. > Still, when an accident occurs, like a parent high in the DAG =20 > degrades its rank, possibly most of the nodes in the whole network =20 > will have to reassess their rank and reset their trickle timer. > My understanding of that process is that it can yield quite a bit =20 > of activity, that grows with the number of nodes acting as routers. Not really, if you have a small redundancy constant. Don't forget, the =20= number of messages scales logarithmically with density. > > What I think is that even if we have trickle, we should be =20 > considering some control on the density of nodes that act as a =20 > router. To address that, there=92s already ample work and large WSN =20= > deployments that leverage the concept of dominating set. > A dominating set is a connected set of routers that enables =20 > connectivity for all > , that is all nodes in the network is connected to at least one =20 > member of the dominating set. > I don't think a dominating set is what you mean: a dominating set can =20= be disconnected. You're talking about a connected dominating set. > Because we have trickle, such a set does not need to be shrink to =20 > minimal/optimal. In fact, we=92d want that each node in the network =20= > sees at least 2 members of the dominating set. > > Can that be achieved simply? Possibly. > > Each time a new sequence is spread, nodes are entitled to reassess =20 > their need to be a router. When the sequence spreads, a form of =20 > trickle could be used to decide Not TO advertise self as a router =20 > and act as a host for the new sequence. > Like if enough neighbor routers advertise the new sequence before T =20= > elapse, then there might be no need for self to act as a router. This is exactly what trickle is designed to do, with its redundancy =20 counter. I thought the major design goal right now to make RPL *less* =20 complicated? Phil=20= From richard.kelsey@ember.com Tue Nov 17 08:15:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F23B3A684E for ; Tue, 17 Nov 2009 08:15:38 -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 O2Iafok2xGAB for ; Tue, 17 Nov 2009 08:15:37 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DB0E23A6847 for ; Tue, 17 Nov 2009 08:15:36 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:17:05 -0500 Date: Tue, 17 Nov 2009 11:12:00 -0500 Message-Id: <874oot3zcf.fsf@kelsey-ws.hq.ember.com> To: Roger Alexander In-reply-to: <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> (message from Roger Alexander on Mon, 16 Nov 2009 15:33:33 -0800) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> X-OriginalArrivalTime: 17 Nov 2009 16:17:05.0833 (UTC) FILETIME=[678F7190:01CA67A1] Cc: roll@ietf.org Subject: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:15:38 -0000 > From: Roger Alexander > Date: Mon, 16 Nov 2009 15:33:33 -0800 > > Not clear why there is a need to know who records DAOs. In response to > a new child a parent that does maintain state will add itself to the > path information from the child and pass that information to it's > parent. That information will pass inward towards the root until a > node is encountered that can store the path information and previously > supported connectivity to the node at the same cost. The difficulty is that, at present, there is no way of determining how much information needs to be passed up after a move. Here is the example I posted earlier. We start with this, where A is the root: A / \ B C | D | E Now D moves to C as its parent: A / \ B C | D | E If only A caches DAO data, then all D needs to do is send a DAO after the move. A receives it and changes its next hop for D and E to be C. If B and C both cache DAO data, then D needs to send a no-DAO before the move, to update B, and both D and E need to send DAOs after the move, so that C knows that it has downward paths to both of them. In the first case a single DAO needs to be sent. In the second case D has to send two DAOs and the nodes in its subdag, just E here, each need to send one. If only the root caches DAOs then the first case always applies. If other nodes may cache DAOs, then we have to assume that we are in the second case after every move. -Richard Kelsey From Jerald.P.Martocci@jci.com Tue Nov 17 08:29:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE503A68DA for ; Tue, 17 Nov 2009 08:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, 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 ijEVbY0bXylz for ; Tue, 17 Nov 2009 08:29:04 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id DFA263A684E for ; Tue, 17 Nov 2009 08:29:03 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSwLPSpK+o6teRgxCE22e45YrVE4YGB7g@postini.com; Tue, 17 Nov 2009 08:29:03 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111710294545-4445502 ; Tue, 17 Nov 2009 10:29:45 -0600 In-Reply-To: <4B02BF47.9030203@sics.se> MIME-Version: 1.0 To: Joakim Eriksson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 10:28:32 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 10:28:50 AM, Serialize complete at 11/17/2009 10:28:50 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 10:29:45 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 10:29:56 AM, Serialize complete at 11/17/2009 10:29:56 AM Content-Type: multipart/alternative; boundary="=_alternative 005A821F86257671_=" Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:29:05 -0000 This is a multipart message in MIME format. --=_alternative 005A821F86257671_= Content-Type: text/plain; charset="US-ASCII" I thought nodes always had to send DIOs on trickle timer expiration in case a new node is awaiting a DIO to join the DAG? Has there been any thought of dropping the periodic DIOs now that we have event based DIS/DIOs? It seems to me that as a new node wanting to join the DAG (or move around the DAG) I would be more inclined to simply issue a multicast DIS and immediately get the state of my neighbors than to wait around for an undetermined amount of time collecting periodic DIOs. Jerry Joakim Eriksson 11/17/2009 09:20 AM To Michael Richardson cc Jerald.P.Martocci@jci.com, ROLL WG Subject Re: [Roll] need clarification: DIS processing On the other hand it might be possible to do redundancy-count of the multi-cast DIOs for all nodes in range and thereby get lower likelihood of sending a DIO when the trickle timer triggers next time!? Best regards, -- Joakim Eriksson, SICS Michael Richardson skrev: >>>>>> "Jerald" == Jerald P Martocci writes: > Jerald> Yes you're right, whether the responses to a DIS are > Jerald> multicast or unicast, the packet count is the same. > Jerald> However, if the responses are multicasts (rather than > Jerald> unicasts) then other nodes are necessarily interpreting > Jerald> packets that are really not destined to them. I would > Jerald> prefer the responses to a multicast DIS be a series of > Jerald> unicast DIOs. > > So, what concerns you is the wake-up cost of the extra DIOs. > --=_alternative 005A821F86257671_= Content-Type: text/html; charset="US-ASCII"

I thought nodes always had to send DIOs on trickle timer expiration in case a new node is awaiting a DIO to join the DAG?

Has there been any thought of dropping the periodic DIOs now that we have event based DIS/DIOs?  It seems to me that as a new node wanting to join the DAG (or move around the DAG) I would be more inclined to simply issue a multicast DIS and immediately get the state of my neighbors than to wait around for an undetermined amount of time collecting periodic DIOs.

Jerry




Joakim Eriksson <joakime@sics.se>

11/17/2009 09:20 AM

To
Michael Richardson <mcr@sandelman.ca>
cc
Jerald.P.Martocci@jci.com, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] need clarification: DIS processing





On the other hand it might be possible to do redundancy-count of
the multi-cast DIOs for all nodes in range and thereby get lower
likelihood of sending a DIO when the trickle timer triggers next
time!?


Best regards,
-- Joakim Eriksson, SICS

Michael Richardson skrev:
>>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
>     Jerald> Yes you're right, whether the responses to a DIS are
>     Jerald> multicast or unicast, the packet count is the same.
>     Jerald> However, if the responses are multicasts (rather than
>     Jerald> unicasts) then other nodes are necessarily interpreting
>     Jerald> packets that are really not destined to them.  I would
>     Jerald> prefer the responses to a multicast DIS be a series of
>     Jerald> unicast DIOs.
>
> So, what concerns you is the wake-up cost of the extra DIOs.
>


--=_alternative 005A821F86257671_=-- From pthubert@cisco.com Tue Nov 17 08:37:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7493A6895 for ; Tue, 17 Nov 2009 08:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=0.660, 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 rQ0nwseeB+sx for ; Tue, 17 Nov 2009 08:37:45 -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 1BF2E3A6847 for ; Tue, 17 Nov 2009 08:37:44 -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: AjwAAIBgAkuQ/uCWe2dsb2JhbACcHwEBCwskBqNEmCCEOwQ X-IronPort-AV: E=Sophos;i="4.44,758,1249257600"; d="scan'208";a="54582284" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2009 16:37:42 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHGbgBZ005334; Tue, 17 Nov 2009 16:37:42 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 17:37:42 +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: Tue, 17 Nov 2009 17:37:42 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABD0E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] do we need a dominating set? Thread-Index: AcpnoGyPV6S7P74NTNyD/ycDJhUqQgAAgiRg References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Matteo Paris" , X-OriginalArrivalTime: 17 Nov 2009 16:37:42.0257 (UTC) FILETIME=[4886C610:01CA67A4] Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:37:46 -0000 Hi Matteo: An orphan can issue a DIS, and that could trigger nodes to switch back to hosts. Non orphan becoming orphan would keep sending packets along the previous sequence. Upon that, the node that turned off routing might either poison so the child becomes orphan,=20 or switch back to routing with the new sequence. To be designed :) Pascal >-----Original Message----- >From: Matteo Paris [mailto:matteo@ember.com] >Sent: mardi 17 novembre 2009 17:10 >To: Pascal Thubert (pthubert); roll@ietf.org >Subject: Re: [Roll] do we need a dominating set? > > >Hi Pascal, > >> Each time a new sequence is spread, nodes are entitled to reassess >> their need to be a router. When the sequence spreads, a form of >> trickle could be used to decide Not TO advertise self as a router >> and act as a host for the new sequence. Like if enough neighbor >> routers advertise the new sequence before T elapse, then there >> might be no need for self to act as a router. >> >> Thoughts? > >It is a nice idea and seems like it would work well in a network of >uniform density, so that the k-connectivity of the associated graph >is high. My concern is for the case when the graph contains a >cut-vertex. If the node at the cut-vertex hears many DIOs and >decides not to be a router, the graph becomes disconnected. > >Can this issue be avoided without requiring a lot of computational resources? > >Matteo From pthubert@cisco.com Tue Nov 17 08:38:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41603A6847 for ; Tue, 17 Nov 2009 08:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.048 X-Spam-Level: X-Spam-Status: No, score=-8.048 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, 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 Hpig6neIV4I7 for ; Tue, 17 Nov 2009 08:38:01 -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 F1A9F3A6895 for ; Tue, 17 Nov 2009 08:38:00 -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: AtoEAIBgAkurRN+K/2dsb2JhbACCIiy9V5gghDsE X-IronPort-AV: E=Sophos;i="4.44,758,1249257600"; d="scan'208,217";a="50546363" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2009 16:37:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAHGbw8e013635; Tue, 17 Nov 2009 16:37:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 17:37:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA67A4.49BA4135" Date: Tue, 17 Nov 2009 17:37:30 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABD0F@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] do we need a dominating set? Thread-Index: AcpnX7CgxsS645W6SU200C9i4GzIbQAQ2K7w References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Maxence Dalmais" , "roll ROLL" X-OriginalArrivalTime: 17 Nov 2009 16:37:44.0527 (UTC) FILETIME=[49E125F0:01CA67A4] Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:38:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA67A4.49BA4135 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Maxence =20 During a sequence transition, the draft says that a child using the older sequence can use a 'future' parent with the newer sequence. To avoid false positive in the loop detection mechanism, the rank is the Flow Label must be reset so the child appears as a host to its parent. =20 With what we discuss here, say a node that was router for sequence N-1 becomes non-router for sequence N. So the node never advertises N and all its children that see N should migrate over a transition period and stop using that parent. Over the transition period, the node should still perform as a N-1 router, acting as prescribed in the draft today, that is resetting the rank in the flow label for all packets it issues or forwards. =20 Pascal From: Maxence Dalmais [mailto:maxence.dalmais@insa-lyon.fr]=20 Sent: mardi 17 novembre 2009 09:26 To: Pascal Thubert (pthubert); roll ROLL Subject: Re: [Roll] do we need a dominating set? =20 Hi Pascal, the idea seems good to me but I got a question : -How nodes act during the sequence spreading ? I mean : Does a node which acted as a router and currently does not advertise as it continue to route during the T time ? Moreover, does the fact to change his status of router or not does not increase packets lost or the number of sent ICMP Destination Unreachable packet ? Maxence. ------_=_NextPart_001_01CA67A4.49BA4135 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Maxence

 

During a sequence transition, the draft says that a child = using the older sequence can use a ‘future’ parent with the newer sequence.

To avoid false positive in the loop detection mechanism, = the rank is the Flow Label must be reset so the child appears as a host to = its parent.

 

With what we discuss here,  say a  node that = was router for sequence N-1 becomes non-router for sequence N. So the node = never advertises N and all its children that see N should migrate over a transition = period and stop using that parent.

Over the transition period, the node should still perform = as a N-1 router, acting as prescribed in the draft today, that is resetting = the rank in the flow label for all packets it issues or = forwards.

 

Pascal

From:= Maxence = Dalmais [mailto:maxence.dalmais@insa-lyon.fr]
Sent: mardi 17 novembre 2009 09:26
To: Pascal Thubert (pthubert); roll ROLL
Subject: Re: [Roll] do we need a dominating = set?

 

Hi Pascal,

the idea seems good to me but I got a question :
-How nodes act during the sequence spreading ?
I mean : Does a node which acted as a router and currently does not = advertise as it continue to route during the T time ?
Moreover, does the fact to change his status of router or not does not = increase packets lost or the number of sent ICMP Destination Unreachable packet = ?

Maxence.

------_=_NextPart_001_01CA67A4.49BA4135-- From jhui@archrock.com Tue Nov 17 08:38:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373B33A694A for ; Tue, 17 Nov 2009 08:38:12 -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 a66olTGKjD-8 for ; Tue, 17 Nov 2009 08:38:11 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6BF043A6895 for ; Tue, 17 Nov 2009 08:38:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5F99BAF844; Tue, 17 Nov 2009 08:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o2p3pXnjmOe; Tue, 17 Nov 2009 08:38:05 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 6CDEBAF8EB; Tue, 17 Nov 2009 08:38:05 -0800 (PST) Message-Id: <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <874oot3zcf.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 08:38:03 -0800 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:38:12 -0000 On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote: >> From: Roger Alexander >> Date: Mon, 16 Nov 2009 15:33:33 -0800 >> >> Not clear why there is a need to know who records DAOs. In response >> to >> a new child a parent that does maintain state will add itself to the >> path information from the child and pass that information to it's >> parent. That information will pass inward towards the root until a >> node is encountered that can store the path information and >> previously >> supported connectivity to the node at the same cost. > [nice example of what DAOs need to be sent] > In the first case a single DAO needs to be sent. In the > second case D has to send two DAOs and the nodes in its > subdag, just E here, each need to send one. If only the > root caches DAOs then the first case always applies. If > other nodes may cache DAOs, then we have to assume that we > are in the second case after every move. I was in the process of creating a similar example. All I'll add is that, intuitively, the more places state gets "replicated" within the network, the more costly it is to maintain that state and the more you have to deal with inconsistencies between replicated instances. Of course, the hope in replicating this routing state is that it creates shorter paths and ultimately offsets the cost of maintaining that state. I'll have to admit that I'm not yet convinced of the benefits in storing DAO state as it currently exists in the draft. It seems like a mediocre attempt to optimize point-to-point routing and something that folks wanting P2P support aren't satisfied with. If that is the end-goal, then we should be developing better mechanisms. For now, we are focusing on one-to-many and many-to-one. And, I see more benefits to simply maintaining state at the root. -- Jonathan Hui From jhui@archrock.com Tue Nov 17 08:41:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D503A68EC for ; Tue, 17 Nov 2009 08:41:03 -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 syJyPm7cARDo for ; Tue, 17 Nov 2009 08:41:02 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AD9E93A688B for ; Tue, 17 Nov 2009 08:41:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id ACB44AF839; Tue, 17 Nov 2009 08:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQbzShlgmhpf; Tue, 17 Nov 2009 08:40:57 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id C35B6AF819; Tue, 17 Nov 2009 08:40:56 -0800 (PST) Message-Id: <4090690F-63C4-4823-8DBC-A9DB840A1FA9@archrock.com> From: Jonathan Hui To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 08:40:55 -0800 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:41:03 -0000 On Nov 17, 2009, at 8:28 AM, Jerald.P.Martocci@jci.com wrote: > I thought nodes always had to send DIOs on trickle timer expiration > in case a new node is awaiting a DIO to join the DAG? > > Has there been any thought of dropping the periodic DIOs now that we > have event based DIS/DIOs? It seems to me that as a new node > wanting to join the DAG (or move around the DAG) I would be more > inclined to simply issue a multicast DIS and immediately get the > state of my neighbors than to wait around for an undetermined amount > of time collecting periodic DIOs. Since link qualities vary over time, periodic DIOs are important if you want nodes already in the DAG to learn better routes and adapt to these temporal changes. -- Jonathan Hui From pthubert@cisco.com Tue Nov 17 08:48:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4243A6919 for ; Tue, 17 Nov 2009 08:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.842 X-Spam-Level: X-Spam-Status: No, score=-9.842 tagged_above=-999 required=5 tests=[AWL=0.757, 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 YV5TbYiI6AMa for ; Tue, 17 Nov 2009 08:48:23 -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 9D2883A6842 for ; Tue, 17 Nov 2009 08:48:22 -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: AjwAAMtiAkuQ/uCWe2dsb2JhbACcHgEBCwskBqNfmCGCLIIPBIxE X-IronPort-AV: E=Sophos;i="4.44,758,1249257600"; d="scan'208";a="54583292" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2009 16:48:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHGmK7l008333; Tue, 17 Nov 2009 16:48:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 17:48:20 +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: Tue, 17 Nov 2009 17:48:16 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> In-Reply-To: <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] do we need a dominating set? Thread-Index: AcpnoKL1CfClw7JKSv2htoE9dSAelwAA7Q5A References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 17 Nov 2009 16:48:20.0000 (UTC) FILETIME=[C4A6A200:01CA67A5] Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:48:24 -0000 Hi Phil: >> >> The current RPL draft uses trickle to address density. Trickle has a >> number of fine properties to throttle the control when things are >> stable. >> Still, when an accident occurs, like a parent high in the DAG >> degrades its rank, possibly most of the nodes in the whole network >> will have to reassess their rank and reset their trickle timer. >> My understanding of that process is that it can yield quite a bit >> of activity, that grows with the number of nodes acting as routers. > >Not really, if you have a small redundancy constant. Don't forget, the >number of messages scales logarithmically with density. I understand that the redundancy counter should eliminate redundancies.=20 I can see how DIO options that contain network wide constants can be omitted one the=20 But the fact that a node changes its rank is not a redundancy. Upon the accident up there, all nodes will have to advertise their new rank since they are being used wrongly if they don't. >> What I think is that even if we have trickle, we should be >> considering some control on the density of nodes that act as a >> router. To address that, there's already ample work and large WSN >> deployments that leverage the concept of dominating set. >> A dominating set is a connected set of routers that enables >> connectivity for all >> , that is all nodes in the network is connected to at least one >> member of the dominating set. >> > >I don't think a dominating set is what you mean: a dominating set can >be disconnected. You're talking about a connected dominating set. :) > >> Because we have trickle, such a set does not need to be shrink to >> minimal/optimal. In fact, we'd want that each node in the network >> sees at least 2 members of the dominating set. >> >> Can that be achieved simply? Possibly. >> >> Each time a new sequence is spread, nodes are entitled to reassess >> their need to be a router. When the sequence spreads, a form of >> trickle could be used to decide Not TO advertise self as a router >> and act as a host for the new sequence. >> Like if enough neighbor routers advertise the new sequence before T >> elapse, then there might be no need for self to act as a router. > >This is exactly what trickle is designed to do, with its redundancy >counter. I fail to see that we can do it in the example above. I see that if too many nodes act as router, we'll get many more paths to manage and many more DIOs generated in case of accident. I think we should trickle out the duplicate information in DIO (like DAG config) when many neighbors have already cried out loud that info. But we should also trickle out / redistribute the role of router when opportunity presents itself, that is upon a new sequence. >I thought the major design goal right now to make RPL *less* >complicated? Not having trickle would be a lot less complicated. But also a lot less efficient. So I'm not going there, see? Pascal From joakime@sics.se Tue Nov 17 08:52:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71193A69A0 for ; Tue, 17 Nov 2009 08:52: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 NAV-0O0rvU5E for ; Tue, 17 Nov 2009 08:52:40 -0800 (PST) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by core3.amsl.com (Postfix) with ESMTP id BA97C3A6903 for ; Tue, 17 Nov 2009 08:52:40 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC00FC8B62 for roll@ietf.org; Tue, 17 Nov 2009 17:52:38 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvZGAH9jAktV5BNMPGdsb2JhbAAImSiCZAEBAQE3vA+EOwQ X-IronPort-AV: E=Sophos;i="4.44,758,1249250400"; d="scan'208";a="4554249" Received: from c-4c13e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.19.76]) by ipb1.telenor.se with ESMTP; 17 Nov 2009 17:52:38 +0100 Message-ID: <4B02D4EC.8070900@sics.se> Date: Tue, 17 Nov 2009 17:53:00 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:52:41 -0000 Jerald.P.Martocci@jci.com skrev: > > > I thought nodes always had to send DIOs on trickle timer expiration in > case a new node is awaiting a DIO to join the DAG? As I understand it node only send if there was too few DIOs sent during the last period (last interval). This will keep the number of DIO transmission caused by the Trickle timers fairly low independent of the node density. Best regards, -- Joakim Eriksson, SICS > Has there been any thought of dropping the periodic DIOs now that we > have event based DIS/DIOs? It seems to me that as a new node wanting to > join the DAG (or move around the DAG) I would be more inclined to simply > issue a multicast DIS and immediately get the state of my neighbors than > to wait around for an undetermined amount of time collecting periodic DIOs. > > Jerry > > > > > *Joakim Eriksson * > > 11/17/2009 09:20 AM > > > To > Michael Richardson > cc > Jerald.P.Martocci@jci.com, ROLL WG > Subject > Re: [Roll] need clarification: DIS processing > > > > > > > > > On the other hand it might be possible to do redundancy-count of > the multi-cast DIOs for all nodes in range and thereby get lower > likelihood of sending a DIO when the trickle timer triggers next > time!? > > > Best regards, > -- Joakim Eriksson, SICS > > Michael Richardson skrev: > >>>>>> "Jerald" == Jerald P Martocci writes: > > Jerald> Yes you're right, whether the responses to a DIS are > > Jerald> multicast or unicast, the packet count is the same. > > Jerald> However, if the responses are multicasts (rather than > > Jerald> unicasts) then other nodes are necessarily interpreting > > Jerald> packets that are really not destined to them. I would > > Jerald> prefer the responses to a multicast DIS be a series of > > Jerald> unicast DIOs. > > > > So, what concerns you is the wake-up cost of the extra DIOs. > > > > From mcr@marajade.sandelman.ca Tue Nov 17 08:59:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AC43A68FA for ; Tue, 17 Nov 2009 08:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Zf9DTFggr1 for ; Tue, 17 Nov 2009 08:59:11 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 522EB3A694D for ; Tue, 17 Nov 2009 08:59:11 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id EFA20342F4 for ; Tue, 17 Nov 2009 11:50:42 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 14A374E796 for ; Tue, 17 Nov 2009 11:59:09 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 17 Nov 2009 11:59:09 -0500 Message-ID: <15846.1258477149@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 16:59:12 -0000 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I thought nodes always had to send DIOs on trickle timer Jerald> expiration in case a new node is awaiting a DIO to join the Jerald> DAG? Jerald> Has there been any thought of dropping the periodic DIOs now Jerald> that we have event based DIS/DIOs? It seems to me that as a Jerald> new node wanting to join the DAG (or move around the DAG) I Jerald> would be more inclined to simply issue a multicast DIS and Jerald> immediately get the state of my neighbors than to wait Jerald> around for an undetermined amount of time collecting Jerald> periodic DIOs. But, doesn't that multicast DIS disturb all the nodes as much as the multicast DIO reply? If the node is snoozing, ideally it has woken up, and will reply. Maybe one answer is that we should not using the all-routers/all-hosts multicast groups, but rather we should have new multicast groups for DIOs and DIS. That would permit nodes not interested in DIS (because they can only operate as leaves) to filter out the DIS in their hardware multicast filters... (he says, knowing that likely the simplest hardware doesn't even have that...) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Tue Nov 17 09:02:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC8F3A6876 for ; Tue, 17 Nov 2009 09:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPqhhhzmxm3P for ; Tue, 17 Nov 2009 09:02:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 436963A687F for ; Tue, 17 Nov 2009 09:02:39 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 43B9E3430B for ; Tue, 17 Nov 2009 11:54:11 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 68B274E796 for ; Tue, 17 Nov 2009 12:02:37 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 17 Nov 2009 12:02:37 -0500 Message-ID: <16061.1258477357@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:02:40 -0000 >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> I'll have to admit that I'm not yet convinced of the Jonathan> benefits in storing DAO state as it currently exists in Jonathan> the draft. It seems like a mediocre attempt to optimize Jonathan> point-to-point routing and something that folks wanting Jonathan> P2P support aren't satisfied with. If that is the Jonathan> end-goal, then we should be developing better mechanisms. Jonathan> For now, we are focusing on one-to-many and many-to-one. Jonathan> And, I see more benefits to simply maintaining state at Jonathan> the root. Thus, my proposal to forbid storing of state in intermediate nodes (at least in the base protocol) since it causes externalities. Perhaps someone can some up with a way to store some state (but not the DAOs) in such a way that does not impose externalities that need to be communicated in the protocol. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jhui@archrock.com Tue Nov 17 09:03:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531663A687F for ; Tue, 17 Nov 2009 09:03:42 -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 isnXc6oAiu4T for ; Tue, 17 Nov 2009 09:03:41 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 983E73A6876 for ; Tue, 17 Nov 2009 09:03:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9A195AF839; Tue, 17 Nov 2009 09:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APgcDdRsBae3; Tue, 17 Nov 2009 09:03:36 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id F33C9AF81F; Tue, 17 Nov 2009 09:03:35 -0800 (PST) Message-Id: From: Jonathan Hui To: Joakim Eriksson In-Reply-To: <4B02D4EC.8070900@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 09:03:35 -0800 References: <4B02D4EC.8070900@sics.se> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:03:42 -0000 On Nov 17, 2009, at 8:53 AM, Joakim Eriksson wrote: > Jerald.P.Martocci@jci.com skrev: >> I thought nodes always had to send DIOs on trickle timer expiration >> in case a new node is awaiting a DIO to join the DAG? > > As I understand it node only send if there was too few DIOs sent > during > the last period (last interval). This will keep the number of DIO > transmission caused by the Trickle timers fairly low independent of > the node density. Right. But to address Jerry's follow-on question below, it is important to have some lower bound on network-wide DIO transmissions to allow the network to adapt to varying link conditions. >> Has there been any thought of dropping the periodic DIOs now that >> we have event based DIS/DIOs? It seems to me that as a new node >> wanting to join the DAG (or move around the DAG) I would be more >> inclined to simply issue a multicast DIS and immediately get the >> state of my neighbors than to wait around for an undetermined >> amount of time collecting periodic DIOs. -- Jonathan Hui From Jerald.P.Martocci@jci.com Tue Nov 17 09:05:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84963A69C1 for ; Tue, 17 Nov 2009 09:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, 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 o+AL10qH5LmU for ; Tue, 17 Nov 2009 09:05:55 -0800 (PST) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with ESMTP id 9CE2E3A687F for ; Tue, 17 Nov 2009 09:05:54 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKSwLX711C9yh28IPqJ5qDl9Z89pJoVAZM@postini.com; Tue, 17 Nov 2009 09:05:53 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111711083143-3189105 ; Tue, 17 Nov 2009 11:08:31 -0600 In-Reply-To: <4090690F-63C4-4823-8DBC-A9DB840A1FA9@archrock.com> MIME-Version: 1.0 To: Jonathan Hui X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 11:05:39 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 11:05:46 AM, Serialize complete at 11/17/2009 11:05:46 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 11:08:31 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 11:08:37 AM, Serialize complete at 11/17/2009 11:08:37 AM Content-Type: multipart/alternative; boundary="=_alternative 005DE7FC86257671_=" Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:05:55 -0000 This is a multipart message in MIME format. --=_alternative 005DE7FC86257671_= Content-Type: text/plain; charset="US-ASCII" Not sure I buy that. If I'm not satisfied with my routes, why wouldn't I take the lead and issue a DIS as needed? It seems to me we should have either a time based algorithm or an event based algorithm, but not both. I could see having both if the time based algorithm was used mainly as a heartbeat to assure that the links are still in place. However, if this was the reason, the periodicity of the periodic DIOs would be in minutes no milliseconds. Jerry Jonathan Hui 11/17/2009 10:41 AM To Jerald.P.Martocci@jci.com cc Joakim Eriksson , ROLL WG Subject Re: [Roll] need clarification: DIS processing On Nov 17, 2009, at 8:28 AM, Jerald.P.Martocci@jci.com wrote: > I thought nodes always had to send DIOs on trickle timer expiration > in case a new node is awaiting a DIO to join the DAG? > > Has there been any thought of dropping the periodic DIOs now that we > have event based DIS/DIOs? It seems to me that as a new node > wanting to join the DAG (or move around the DAG) I would be more > inclined to simply issue a multicast DIS and immediately get the > state of my neighbors than to wait around for an undetermined amount > of time collecting periodic DIOs. Since link qualities vary over time, periodic DIOs are important if you want nodes already in the DAG to learn better routes and adapt to these temporal changes. -- Jonathan Hui --=_alternative 005DE7FC86257671_= Content-Type: text/html; charset="US-ASCII"

Not sure I buy that.  If I'm not satisfied with my routes, why wouldn't I take the lead and issue a DIS as needed?

 It seems to me we should have either a time based algorithm or an event based algorithm, but not both.  I could see having both if the time based algorithm was used mainly as a heartbeat to assure that the links are still in place.  However, if this was the reason, the periodicity of the periodic DIOs would be in minutes no milliseconds.

Jerry




Jonathan Hui <jhui@archrock.com>

11/17/2009 10:41 AM

To
Jerald.P.Martocci@jci.com
cc
Joakim Eriksson <joakime@sics.se>, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] need clarification: DIS processing






On Nov 17, 2009, at 8:28 AM, Jerald.P.Martocci@jci.com wrote:

> I thought nodes always had to send DIOs on trickle timer expiration  
> in case a new node is awaiting a DIO to join the DAG?
>
> Has there been any thought of dropping the periodic DIOs now that we  
> have event based DIS/DIOs?  It seems to me that as a new node  
> wanting to join the DAG (or move around the DAG) I would be more  
> inclined to simply issue a multicast DIS and immediately get the  
> state of my neighbors than to wait around for an undetermined amount  
> of time collecting periodic DIOs.

Since link qualities vary over time, periodic DIOs are important if  
you want nodes already in the DAG to learn better routes and adapt to  
these temporal changes.

--
Jonathan Hui
--=_alternative 005DE7FC86257671_=-- From jhui@archrock.com Tue Nov 17 09:06:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE673A6996 for ; Tue, 17 Nov 2009 09:06:45 -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 Qyhqx1gwvBJt for ; Tue, 17 Nov 2009 09:06:44 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A8F813A68DD for ; Tue, 17 Nov 2009 09:06:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B4153AF81F; Tue, 17 Nov 2009 09:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grS1TVXGGZS7; Tue, 17 Nov 2009 09:06:39 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id CAEB0AF839; Tue, 17 Nov 2009 09:06:38 -0800 (PST) Message-Id: <993A6A9B-2D0D-4A88-9A4F-62E154815260@archrock.com> From: Jonathan Hui To: Michael Richardson In-Reply-To: <16061.1258477357@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 09:06:37 -0800 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <16061.1258477357@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:06:45 -0000 On Nov 17, 2009, at 9:02 AM, Michael Richardson wrote: >>>>>> "Jonathan" == Jonathan Hui writes: > Jonathan> I'll have to admit that I'm not yet convinced of the > Jonathan> benefits in storing DAO state as it currently exists in > Jonathan> the draft. It seems like a mediocre attempt to optimize > Jonathan> point-to-point routing and something that folks wanting > Jonathan> P2P support aren't satisfied with. If that is the > Jonathan> end-goal, then we should be developing better mechanisms. > Jonathan> For now, we are focusing on one-to-many and many-to-one. > Jonathan> And, I see more benefits to simply maintaining state at > Jonathan> the root. > > Thus, my proposal to forbid storing of state in intermediate nodes > (at least in the base protocol) since it causes externalities. > > Perhaps someone can some up with a way to store some state (but not > the > DAOs) in such a way that does not impose externalities that need to be > communicated in the protocol. Yes. Sorry for not stating it clearly. I also propose to remove the ability to store downwards routing state at intermediate nodes from the base RPL document. A P2P proposal that satisfies the application requirements should be dealt with in a separate draft. -- Jonathan Hui From jhui@archrock.com Tue Nov 17 09:14:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658F33A6A37 for ; Tue, 17 Nov 2009 09:14:31 -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 ITEw5fJpN4UM for ; Tue, 17 Nov 2009 09:14:28 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 2B0213A69A1 for ; Tue, 17 Nov 2009 09:14:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EFDD3AF89E; Tue, 17 Nov 2009 09:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54bfMi70atpR; Tue, 17 Nov 2009 09:14:22 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 17E7DAF848; Tue, 17 Nov 2009 09:14:22 -0800 (PST) Message-Id: <75B9942C-E153-4849-87BD-F4E95DF891E4@archrock.com> From: Jonathan Hui To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 09:14:20 -0800 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:14:31 -0000 On Nov 17, 2009, at 9:05 AM, Jerald.P.Martocci@jci.com wrote: > Not sure I buy that. If I'm not satisfied with my routes, why > wouldn't I take the lead and issue a DIS as needed? In most cases, picking routes is based on relative terms (e.g. I chose route A because it is better than B, not because B is unsatisfactory). While I may have a working route, how would I discover a much better route if one exists? > It seems to me we should have either a time based algorithm or an > event based algorithm, but not both. I could see having both if the > time based algorithm was used mainly as a heartbeat to assure that > the links are still in place. However, if this was the reason, the > periodicity of the periodic DIOs would be in minutes no milliseconds. Well, "minutes" in some cases is not good enough. If routes are inconsistent or you need to discover a new one, waiting "minutes" to discover a new route may not be acceptable. But sending DIOs on the order of "seconds" is also not acceptable in those situations. Hence the need for an adaptive timer. Note that, for the most part, the timer is periodic - but that you can speed it up in certain situations. This tradeoff between fast and slow periods is nothing new. Many IP- based protocols operate by having a short period when reacting to some event and a long period to maintain the network. -- Jonathan Hui From pthubert@cisco.com Tue Nov 17 09:20:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3447728C153 for ; Tue, 17 Nov 2009 09:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 OFX6vT1loCau for ; Tue, 17 Nov 2009 09:20:30 -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 774EB28C166 for ; Tue, 17 Nov 2009 09:20: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: AjwAANJpAkuQ/uCWe2dsb2JhbACcHgEBCwskBqNXmCSEOwSBbQ X-IronPort-AV: E=Sophos;i="4.44,759,1249257600"; d="scan'208";a="54585849" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2009 17:20:27 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHHKRWx016048; Tue, 17 Nov 2009 17:20:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 18:20:26 +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: Tue, 17 Nov 2009 18:20:20 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> In-Reply-To: <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: AcpnpGkyHNnkrazpRtG5TaM+FhLUOAAAaPeQ References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 17 Nov 2009 17:20:26.0616 (UTC) FILETIME=[4100E780:01CA67AA] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:20:31 -0000 Hi Jonathan and Richard: My thought process lead me to following (buy or not :) design, that is what you find in the MANEMO implementations. * Nodes that can store should if that's what the deployment requires (that's policy).=20 * Source route trace a path. It can be done on traffic, one every so many messages with exponential backoff, using small messages that can be extended for the purpose of LSRR. * In particular when there are movements (churn) only a snapshot is consistent. Assembling asynchronous pieces some of which might be out of date into a routing header is doomed. A node that cannot store states=20 * needs *no* DAO support at all and the whole thing still works. Nodes that do DAO cohabit with nodes that do without a problem. * Announce in DIO but still silently absorb for the DAO if they come nevertheless. * But they forward and add to the source route. Adding to the source route means add up the SR stack the information about the next hop. That information is derived from the source of the packet. Then the node sets its own address as the source of the packet so it is topologically correct all the way. A Node that supports DAO states=20 * If the state matches the source route path then the node does not need to add to the source route header. A state matches if the route to the highest (newest) entry in the source route header is via the source of the packet. This confirms that the associated routing state learnt from DAO is still correct. * The node does not need to store the source route either. Only the endpoint does that. In our case the root could intercept and store. * The node still updates the source of the packet with their own address to keep it topologically correct and allow the next hop to record the right thing if it needs. * But if the states does not match the source route, then the states are obsolete, and the node should add to the source route header and set the source to self.=20 When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH (source route)), you see the source route RH2/4 grow upon movement and quickly shrink again as the NINA (DAO) states are reestablished.=20 When things are stable you only see as many entries as non DAO capable nodes along the path. In my case, the source route is done on a MIP/NEMO tunnel, so the RH states are stored in eth binding cache on the home agent. But we could store that at the root with exactly the same process. I can demo that next time we meet if you wish. http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header details the RRH, since there is not LSRR in IPv6. Note that in our case, the information in the header should be locally significant, like a label. cheers Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mardi 17 novembre 2009 17:38 >To: Richard Kelsey >Cc: roll@ietf.org >Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > >On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote: > >>> From: Roger Alexander >>> Date: Mon, 16 Nov 2009 15:33:33 -0800 >>> >>> Not clear why there is a need to know who records DAOs. In response >>> to >>> a new child a parent that does maintain state will add itself to the >>> path information from the child and pass that information to it's >>> parent. That information will pass inward towards the root until a >>> node is encountered that can store the path information and >>> previously >>> supported connectivity to the node at the same cost. >> > >[nice example of what DAOs need to be sent] > >> In the first case a single DAO needs to be sent. In the >> second case D has to send two DAOs and the nodes in its >> subdag, just E here, each need to send one. If only the >> root caches DAOs then the first case always applies. If >> other nodes may cache DAOs, then we have to assume that we >> are in the second case after every move. > >I was in the process of creating a similar example. All I'll add is >that, intuitively, the more places state gets "replicated" within the >network, the more costly it is to maintain that state and the more you >have to deal with inconsistencies between replicated instances. Of >course, the hope in replicating this routing state is that it creates >shorter paths and ultimately offsets the cost of maintaining that state. > >I'll have to admit that I'm not yet convinced of the benefits in >storing DAO state as it currently exists in the draft. It seems like >a mediocre attempt to optimize point-to-point routing and something >that folks wanting P2P support aren't satisfied with. If that is the >end-goal, then we should be developing better mechanisms. For now, we >are focusing on one-to-many and many-to-one. And, I see more benefits >to simply maintaining state at the root. > >-- >Jonathan Hui > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Nov 17 09:44:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97FC28C0FE; Tue, 17 Nov 2009 09:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, 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 VuuHTdPciw6M; Tue, 17 Nov 2009 09:44:58 -0800 (PST) Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by core3.amsl.com (Postfix) with ESMTP id 2FC9928C0DE; Tue, 17 Nov 2009 09:44:58 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKSwLhCI9TWx7Ow9n2/cKaeGx0Adzlkqv6@postini.com; Tue, 17 Nov 2009 09:44:57 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111711452493-4455597 ; Tue, 17 Nov 2009 11:45:24 -0600 In-Reply-To: <15846.1258477149@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 11:44:23 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 11:44:30 AM, Serialize complete at 11/17/2009 11:44:30 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 11:45:24 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 11:45:51 AM, Serialize complete at 11/17/2009 11:45:51 AM Content-Type: multipart/alternative; boundary="=_alternative 0061743586257671_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:45:00 -0000 This is a multipart message in MIME format. --=_alternative 0061743586257671_= Content-Type: text/plain; charset="US-ASCII" Michael, Comments interlaced below: Michael Richardson Sent by: roll-bounces@ietf.org 11/17/2009 10:59 AM To ROLL WG cc Subject Re: [Roll] need clarification: DIS processing >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I thought nodes always had to send DIOs on trickle timer Jerald> expiration in case a new node is awaiting a DIO to join the Jerald> DAG? Jerald> Has there been any thought of dropping the periodic DIOs now Jerald> that we have event based DIS/DIOs? It seems to me that as a Jerald> new node wanting to join the DAG (or move around the DAG) I Jerald> would be more inclined to simply issue a multicast DIS and Jerald> immediately get the state of my neighbors than to wait Jerald> around for an undetermined amount of time collecting Jerald> periodic DIOs. But, doesn't that multicast DIS disturb all the nodes as much as the multicast DIO reply? No. the multicast DIS is targeted only to the node's neighbors all of which need to get this data. Multicast DIOs on the other hand will go to 1) the DIS originator who really needs the info, but also 2) to all other nodes in its radio range which often times includes nodes that didn't receive the original DIS. NOTE: I am assuming that the DIS/DIO multicasts are all "link local" multicasts and hence are only going to devices within direct radio range of the transmitting device. Is this a valid assumption? If the node is snoozing, ideally it has woken up, and will reply. That probably won't happen. Sleeping nodes will be on a periodic timer and will likely be completely out of phase with the DIS message transmission. If an application has sleeping routers, there will need to be some other means to synchronize the network. In my application (Building Control) all our routers will be powered and hence I won't have that headache. Maybe one answer is that we should not using the all-routers/all-hosts multicast groups, but rather we should have new multicast groups for DIOs and DIS. That would permit nodes not interested in DIS (because they can only operate as leaves) to filter out the DIS in their hardware multicast filters... (he says, knowing that likely the simplest hardware doesn't even have that...) As I see it, all our sensors (temperature, occupancy, light, solar, etc) will be hosts positioned as leaves and not even in the DAG. They will sleep. Some will awake periodically (temp sensors), others on event (light switches). They will forward their data to the nearest DAG router destined for their requisite controller await their application ACK and go back snoozing. And yes, none of the devices in the DAG will have any special filtering hardware support. Furthermore, the devices must have zero-configuration hence defining special multicast groups is not feasible. Thanks, Jerry ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0061743586257671_= Content-Type: text/html; charset="US-ASCII"
Michael,

Comments interlaced below:



Michael Richardson <mcr@sandelman.ca>
Sent by: roll-bounces@ietf.org

11/17/2009 10:59 AM

To
ROLL WG <roll@ietf.org>
cc
Subject
Re: [Roll] need clarification: DIS processing






>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
   Jerald> I thought nodes always had to send DIOs on trickle timer
   Jerald> expiration in case a new node is awaiting a DIO to join the
   Jerald> DAG?

   Jerald> Has there been any thought of dropping the periodic DIOs now
   Jerald> that we have event based DIS/DIOs?  It seems to me that as a
   Jerald> new node wanting to join the DAG (or move around the DAG) I
   Jerald> would be more inclined to simply issue a multicast DIS and
   Jerald> immediately get the state of my neighbors than to wait
   Jerald> around for an undetermined amount of time collecting
   Jerald> periodic DIOs.

But, doesn't that multicast DIS disturb all the nodes as much as the
multicast DIO reply?  

No. the multicast DIS is targeted only to the node's neighbors all of which need to get this data.  Multicast DIOs on the other hand will go to 1) the DIS originator who really needs the info, but also 2) to all other nodes in its radio range which often times includes nodes that didn't receive the original DIS.

NOTE: I am assuming that the DIS/DIO multicasts are all "link local" multicasts and hence are only going to devices within direct radio range of the transmitting device.  Is this a valid assumption?

If the node is snoozing, ideally it has woken up, and will reply.

That probably won't happen.  Sleeping nodes will be on a periodic timer and will likely be completely out of phase with the DIS message transmission.  If an application has sleeping routers, there will need to be some other means to synchronize the network.  In my application (Building Control) all our routers will be powered and hence I won't have that headache.


Maybe one answer is that we should not using the all-routers/all-hosts
multicast groups, but rather we should have new multicast groups for
DIOs and DIS. That would permit nodes not interested in DIS (because
they can only operate as leaves) to filter out the DIS in their hardware
multicast filters... (he says, knowing that likely the simplest hardware
doesn't even have that...)

As I see it, all our sensors (temperature, occupancy, light, solar, etc) will be hosts positioned as leaves and not even in the DAG.  They will sleep.  Some will awake periodically (temp sensors), others on event (light switches).  They will forward their data to the nearest DAG router destined for their requisite controller await their application ACK and go back snoozing.
And yes, none of the devices in the DAG will have any special filtering hardware support.  Furthermore, the devices must have zero-configuration hence defining special multicast groups is not feasible.

Thanks,

Jerry


]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0061743586257671_=-- From jhui@archrock.com Tue Nov 17 09:56:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097E03A698B for ; Tue, 17 Nov 2009 09:56:22 -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 kG3sWYRJtNK6 for ; Tue, 17 Nov 2009 09:56:21 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4AE5E3A6843 for ; Tue, 17 Nov 2009 09:56:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 038FEAF93D; Tue, 17 Nov 2009 09:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNeC0VM3SdWs; Tue, 17 Nov 2009 09:56:16 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id DEC4EAF81F; Tue, 17 Nov 2009 09:56:15 -0800 (PST) Message-Id: <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 09:56:15 -0800 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 17:56:22 -0000 On Nov 17, 2009, at 9:20 AM, Pascal Thubert (pthubert) wrote: > When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH > (source route)), you see the source route RH2/4 grow upon movement and > quickly shrink again as the NINA (DAO) states are reestablished. > When things are stable you only see as many entries as non DAO capable > nodes along the path. In my case, the source route is done on a MIP/ > NEMO > tunnel, so the RH states are stored in eth binding cache on the home > agent. But we could store that at the root with exactly the same > process. > I can demo that next time we meet if you wish. > > http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header > details the RRH, since there is not LSRR in IPv6. > > Note that in our case, the information in the header should be locally > significant, like a label. Here lies the disconnect. The real benefit of storing state among nodes within the network is to reduce the size of the source route header not some attempt to support point-to-point traffic. If you buy that, then the mechanism to establish such state could be much better than what's currently defined in the draft. In particular, there are some interesting things we could achieve if we start treating next-hop information using locally significant labels rather than globally significant IP addresses, as you suggested. But if done properly, I think we can specify such a mechanism as an optimization to basic source-route/record-route. -- Jonathan Hui From sdhags@gmail.com Tue Nov 17 10:15:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A603A6841 for ; Tue, 17 Nov 2009 10:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-pIrl3DW19W for ; Tue, 17 Nov 2009 10:15:31 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 8A4E93A6808 for ; Tue, 17 Nov 2009 10:15:31 -0800 (PST) Received: by vws31 with SMTP id 31so86887vws.29 for ; Tue, 17 Nov 2009 10:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=+bx/Pqsul7E7RYhHGRiZQAYma/ouR7cNvfUU1XUCekw=; b=vpm1KD17kuwIDdkl4npXk+F9b2Vw+bMZfq+H4ej7TvLeShHQy7omPFn/6ltf9FMHK5 IBVrkqqS2OIUXNRgdcNMBmYZsYc/G5T9DoYiGBXnMIHwa8yU2mQaLUwrngTf55dLzwix 1m84UHsUIHG+qW1kCYxDkpQ4dYvxGIphysnq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=o6rQ5hzftKqVmHY6AAxO4sWeakxDNNrGrZAmpw+vLf/Tkzo7M5kPAx7sexcCAEREUd e9NcGHU8L4oYLgrayWFN5WjCpHGOz88nPq3cmxQ9lrxtxwe8Iyrc8ntewfzSYhrI5iVz PQ8G9Y1mHxZ1RV6SpLOIZzEFtF/viBjFW6ZoU= MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.220.121.233 with SMTP id i41mr5793233vcr.110.1258481725079; Tue, 17 Nov 2009 10:15:25 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> Date: Tue, 17 Nov 2009 10:15:25 -0800 X-Google-Sender-Auth: 08b84524828574e9 Message-ID: <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> From: Stephen Dawson-Haggerty To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 18:15:38 -0000 We have lots of evidence that trickle performs fine (well) in lots of settings, including dense ones, when used correctly. This "improvement" seems pretty speculative-- do we know that this is necessary __in_addition_to_trickle_? I'm only familiar with the MPRs in OLSR which seem to perform this function, but there trickle is not used. We'd need strong evidence that trickle was insufficient to include this. Steve On Tue, Nov 17, 2009 at 8:48 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > >>> >>> The current RPL draft uses trickle to address density. Trickle has a >>> number of fine properties to throttle the control when things are >>> stable. >>> Still, when an accident occurs, like a parent high in the DAG >>> degrades its rank, possibly most of the nodes in the whole network >>> will have to reassess their rank and reset their trickle timer. >>> My understanding of that =A0process is that it can yield quite a bit >>> of activity, that grows with the number of nodes acting as routers. >> >>Not really, if you have a small redundancy constant. Don't forget, the >>number of messages scales logarithmically with density. > > I understand that the redundancy counter should eliminate redundancies. > I can see how DIO options that contain network wide constants can be > omitted one the > But the fact that a node changes its rank is not a redundancy. > Upon the accident up there, all nodes will have to advertise their new > rank since they are being used wrongly if they don't. > >>> What I think is that even if we have trickle, we should be >>> considering some control on the density of nodes that act as a >>> router. To address that, there's already ample work and large WSN >>> deployments that leverage the concept of dominating set. >>> =A0A dominating set is a connected set of routers that enables >>> connectivity for all >>> , that is all nodes in the network is connected to at least one >>> member of the dominating set. >>> >> >>I don't think a dominating set is what you mean: a dominating set can >>be disconnected. You're talking about a connected dominating set. > > :) > >> >>> Because we have trickle, such a set does not need to be =A0shrink to >>> minimal/optimal. In fact, we'd want that each node in the network >>> sees at least 2 members of the dominating set. >>> >>> Can that be achieved simply? Possibly. >>> >>> Each time a new sequence is spread, nodes are entitled to reassess >>> their need to be a router. When the sequence spreads, a form of >>> trickle could be used to decide Not TO advertise self as a router >>> and act as a host for the new sequence. >>> Like if enough neighbor routers advertise the new sequence before T >>> elapse, then there might be no need for self to act as a router. >> >>This is exactly what trickle is designed to do, with its redundancy >>counter. > > I fail to see that we can do it in the example above. I see that if too > many nodes act as router, we'll get many more paths to manage and many > more DIOs generated in case of accident. > > I think we should trickle out the duplicate information in DIO (like DAG > config) when many neighbors have already cried out loud that info. > But we should also trickle out / redistribute the role of router when > opportunity presents itself, that is upon a new sequence. > > >>I thought the major design goal right now to make RPL *less* >>complicated? > > Not having trickle would be a lot less complicated. But also a lot less > efficient. So I'm not going there, see? > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From roger.alexander@ekasystems.com Tue Nov 17 12:26:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA9928C16E for ; Tue, 17 Nov 2009 12:26:50 -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, 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 bZUmT6QYTVTE for ; Tue, 17 Nov 2009 12:26:49 -0800 (PST) Received: from n62.bullet.mail.sp1.yahoo.com (n62.bullet.mail.sp1.yahoo.com [98.136.44.35]) by core3.amsl.com (Postfix) with SMTP id 0BCC928C0FA for ; Tue, 17 Nov 2009 12:26:48 -0800 (PST) Received: from [216.252.122.219] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 17 Nov 2009 20:25:40 -0000 Received: from [68.142.194.243] by t4.bullet.sp1.yahoo.com with NNFMP; 17 Nov 2009 20:25:40 -0000 Received: from [68.142.201.243] by t1.bullet.mud.yahoo.com with NNFMP; 17 Nov 2009 20:25:40 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 17 Nov 2009 20:25:40 -0000 X-Yahoo-Newman-Id: 211746.239.bm@omp404.mail.mud.yahoo.com Received: (qmail 10386 invoked from network); 17 Nov 2009 20:25:39 -0000 Received: from 166-205-130-252.mobile.mymmode.com (roger.alexander@166.205.130.252 with plain) by smtp104.biz.mail.sp1.yahoo.com with SMTP; 17 Nov 2009 12:25:37 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 0NklcywVM1k89K7s8dXnXHiHfBsErNNb9SVqfbznmDVTM.kLbWTBY.0lUs4j8hAPG8.vAS0scLX7sFxcQJicQdJCSYNplWpM6SL_1PaqmTo_D7VaGp9Tx7IE.4SPWtdot2hvGUmaT11gKGcVCo3PWvLTeBFSWJQqwUWa1p7xuFUVNOMKbwPCmAs4J4xkCkotSucZ25Y2FaqoRj_Shqgl5v0kzKiJDfv_ct8V7leOVIIncGC8fW21aNP9j8vCFsWs9kwTdnXjkV6MiHkJq9F4AxofqP_XtYoSv.X7jSHZcF0Dy04Q8lgc1UMTH1PQTaRlGiX0CUpanjCesA-- X-Yahoo-Newman-Property: ymail-3 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> Message-Id: <7AD445D4-22D3-493C-B9F4-094CBC080F20@ekasystems.com> From: Roger Alexander To: Richard Kelsey In-Reply-To: <874oot3zcf.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Tue, 17 Nov 2009 12:25:26 -0800 Cc: "roll@ietf.org" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 20:26:50 -0000 The conclusions drawn are not entirely valid in part due to the particular example given. Quite often the examples used to demonstrate the protocol are of necessity simpler ones but may not capture the larger variety of connectivity seen particularly in larger multihop networks. I will try to make the case using a slightly more complex network graph which illustrate the benefit of intermediate state storage and how it might work without explicit indications of which note are maintaining state. Roger On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote: >> From: Roger Alexander >> Date: Mon, 16 Nov 2009 15:33:33 -0800 >> >> Not clear why there is a need to know who records DAOs. In response >> to >> a new child a parent that does maintain state will add itself to the >> path information from the child and pass that information to it's >> parent. That information will pass inward towards the root until a >> node is encountered that can store the path information and >> previously >> supported connectivity to the node at the same cost. > > The difficulty is that, at present, there is no way of > determining how much information needs to be passed up after > a move. Here is the example I posted earlier. We start > with this, where A is the root: > > A > / \ > B C > | > D > | > E > > Now D moves to C as its parent: > > A > / \ > B C > | > D > | > E > > If only A caches DAO data, then all D needs to do is send a > DAO after the move. A receives it and changes its next hop > for D and E to be C. > > If B and C both cache DAO data, then D needs to send a > no-DAO before the move, to update B, and both D and E need > to send DAOs after the move, so that C knows that it has > downward paths to both of them. > > In the first case a single DAO needs to be sent. In the > second case D has to send two DAOs and the nodes in its > subdag, just E here, each need to send one. If only the > root caches DAOs then the first case always applies. If > other nodes may cache DAOs, then we have to assume that we > are in the second case after every move. > > -Richard Kelsey From jhui@archrock.com Tue Nov 17 12:49:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC643A6AF6 for ; Tue, 17 Nov 2009 12:49:52 -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 8eQp0mJzfWjH for ; Tue, 17 Nov 2009 12:49:51 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4137D3A6AE0 for ; Tue, 17 Nov 2009 12:49:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C8273AF83D; Tue, 17 Nov 2009 12:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEpseL9xPFx2; Tue, 17 Nov 2009 12:49:45 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 01803AF81E; Tue, 17 Nov 2009 12:49:44 -0800 (PST) Message-Id: <5DCB0E37-2480-4529-840C-0B2D41DF06A6@archrock.com> From: Jonathan Hui To: Roger Alexander In-Reply-To: <7AD445D4-22D3-493C-B9F4-094CBC080F20@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 12:49:43 -0800 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <7AD445D4-22D3-493C-B9F4-094CBC080F20@ekasystems.com> X-Mailer: Apple Mail (2.936) Cc: "roll@ietf.org" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 20:49:52 -0000 Hi Roger, On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: > The conclusions drawn are not entirely valid in part due to the > particular example given. Quite often the examples used to > demonstrate the protocol are of necessity simpler ones but may not > capture the larger variety of connectivity seen particularly in > larger multihop networks. I will try to make the case using a > slightly more complex network graph which illustrate the benefit of > intermediate state storage and how it might work without explicit > indications of which note are maintaining state. A fair characterization is that the change in down route state must be reflected up until there is a common ancestor that provides connectivity both before and after the change in connectivity *and* can store down routes. In the example that Richard provided, A was the common ancestor and it also happened to be the root. But it is also true that nodes within the sub-DAG of A must update their DAO routing state to reflect the change in topology. As Richard's example points out, when you allow nodes to chose whether they can store down route state, nodes within the sub-DAG must assume the worst case and originate their own DAO messages in case nodes between it and the common ancestors cannot maintain down routes. That said, the cost savings of having storage at intermediate nodes depends mostly on the depth of the common ancestor - a common ancestor with greater depth will result in less transmissions that propagate information towards the root. Of course, in the worst case, the common ancestor will be the root. An unfortunate edge case with hierarchical structures is that the common ancestor of you and your neighbor could be the root. I think it is fair to say that the current DAO caching capabilities specified in the RPL doc need quite a bit more thought before I would be comfortable with putting it into the base specification. If there is a way to treat it as an optimization, I would prefer to do so and work on that in a separate draft. -- Jonathan Hui From roger.alexander@ekasystems.com Tue Nov 17 13:02:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020FD3A680D for ; Tue, 17 Nov 2009 13:02:41 -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, 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 sRflUSIByYrd for ; Tue, 17 Nov 2009 13:02:39 -0800 (PST) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by core3.amsl.com (Postfix) with SMTP id 542DE3A680F for ; Tue, 17 Nov 2009 13:02:39 -0800 (PST) Received: from [68.142.200.226] by n23.bullet.mail.mud.yahoo.com with NNFMP; 17 Nov 2009 21:02:36 -0000 Received: from [68.142.201.246] by t7.bullet.mud.yahoo.com with NNFMP; 17 Nov 2009 21:02:35 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 17 Nov 2009 21:02:35 -0000 X-Yahoo-Newman-Id: 968864.43971.bm@omp407.mail.mud.yahoo.com Received: (qmail 51462 invoked from network); 17 Nov 2009 21:02:35 -0000 Received: from 166-205-130-240.mobile.mymmode.com (roger.alexander@166.205.130.240 with plain) by smtp103.biz.mail.sp1.yahoo.com with SMTP; 17 Nov 2009 13:02:31 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: yM2FbVEVM1np7bdx9KWJ4vvhce44mSkMrf60s8ZyAvKl.28mmPZHiLQDazowX.ay6LycbMkHF13166OBXsK0yFyLxK3jiMT8X0Cm5IyUkk0HMscdw2uPZ8oW12D9o50R1p74cgj1zszxE8AikP39TxQP9bKOpmPjfbVY1wLd8tTJjwMwdSBdpJ2zHZmKheO7Whm_tBFoEYJRM4dWZZNUF9CNNTemoU2ORSyU92yaEwnWaLCKt1pl7FjFbwkSBfUfjh5FZS_xoA27DPYGWbYn3M5szM_A_oQpDXHFgp9ibkzE4Mk8.DYZEUGAOooD9vTMeXhFlZ5DpaZiOG1cZ1jqJQZlnAg- X-Yahoo-Newman-Property: ymail-3 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <7AD445D4-22D3-493C-B9F4-094CBC080F20@ekasystems.com> <5DCB0E37-2480-4529-840C-0B2D41DF06A6@archrock.com> Message-Id: <5CA5D4B6-F223-404D-AC75-0953F365DD8C@ekasystems.com> From: Roger Alexander To: Jonathan Hui In-Reply-To: <5DCB0E37-2480-4529-840C-0B2D41DF06A6@archrock.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Tue, 17 Nov 2009 13:02:25 -0800 Cc: "roll@ietf.org" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 21:02:41 -0000 Flight about to take off but let me just add that source routing must remain an option so schemes to optimize its operation need to be kept in that context... Thx. Roger On Nov 17, 2009, at 12:49 PM, Jonathan Hui wrote: > > Hi Roger, > > On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: > >> The conclusions drawn are not entirely valid in part due to the >> particular example given. Quite often the examples used to >> demonstrate the protocol are of necessity simpler ones but may not >> capture the larger variety of connectivity seen particularly in >> larger multihop networks. I will try to make the case using a >> slightly more complex network graph which illustrate the benefit of >> intermediate state storage and how it might work without explicit >> indications of which note are maintaining state. > > A fair characterization is that the change in down route state must > be reflected up until there is a common ancestor that provides > connectivity both before and after the change in connectivity *and* > can store down routes. In the example that Richard provided, A was > the common ancestor and it also happened to be the root. But it is > also true that nodes within the sub-DAG of A must update their DAO > routing state to reflect the change in topology. As Richard's > example points out, when you allow nodes to chose whether they can > store down route state, nodes within the sub-DAG must assume the > worst case and originate their own DAO messages in case nodes > between it and the common ancestors cannot maintain down routes. > > That said, the cost savings of having storage at intermediate nodes > depends mostly on the depth of the common ancestor - a common > ancestor with greater depth will result in less transmissions that > propagate information towards the root. Of course, in the worst > case, the common ancestor will be the root. An unfortunate edge > case with hierarchical structures is that the common ancestor of you > and your neighbor could be the root. > > I think it is fair to say that the current DAO caching capabilities > specified in the RPL doc need quite a bit more thought before I > would be comfortable with putting it into the base specification. > If there is a way to treat it as an optimization, I would prefer to > do so and work on that in a separate draft. > > -- > Jonathan Hui > From Jerald.P.Martocci@jci.com Tue Nov 17 13:25:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBD83A6991; Tue, 17 Nov 2009 13:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, 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 Sq55V2gS9mzn; Tue, 17 Nov 2009 13:25:48 -0800 (PST) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by core3.amsl.com (Postfix) with ESMTP id 5655A3A6835; Tue, 17 Nov 2009 13:25:47 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKSwMU2VaRSkpfNzhsQbb7CHk/D6zik3Iq@postini.com; Tue, 17 Nov 2009 13:25:46 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111715263207-4481169 ; Tue, 17 Nov 2009 15:26:32 -0600 In-Reply-To: <5DCB0E37-2480-4529-840C-0B2D41DF06A6@archrock.com> MIME-Version: 1.0 To: Jonathan Hui X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 17 Nov 2009 15:25:31 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/17/2009 03:25:36 PM, Serialize complete at 11/17/2009 03:25:36 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 03:26:32 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/17/2009 03:26:40 PM, Serialize complete at 11/17/2009 03:26:40 PM Content-Type: multipart/alternative; boundary="=_alternative 0075B31386257671_=" Cc: "roll@ietf.org" , roll-bounces@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Nov 2009 21:25:49 -0000 This is a multipart message in MIME format. --=_alternative 0075B31386257671_= Content-Type: text/plain; charset="US-ASCII" Hi Jonathan, I am conflicted with the idea of discounting P2P messaging in this document in lieu of some future document. I am completely with you that if there will be no attempt to fix the current P2P in RPL then we should deprecate it. What RPL currently documents for P2P communication simply won't meet the requirements specified (at least within the commercial building market). On the other hand, if we pull P2P out of RPL, I'm afraid it will never get defined. In Geneva we discussed that as we complete the MP2P protocol and move it toward true implementations, it will be apparent that even for this presumably unidirectional protocol, these collection networks will still need to application ACK the packets to assure that the packet has been successfully delivered to its destination. Therefore. even MP2P networks will need a robust means to move packets outward down the DAG; and hence, it would be short-sighted to postpone this to a future draft. Unless those folks requiring MP2P communication are willing to use a protocol that does not support guaranteed delivery, I think we best work this out within the confines of this current document. Jerry Jonathan Hui Sent by: roll-bounces@ietf.org 11/17/2009 02:50 PM To Roger Alexander cc "roll@ietf.org" Subject Re: [Roll] updating DAO caches (was Re: Something to ADD) Hi Roger, On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: > The conclusions drawn are not entirely valid in part due to the > particular example given. Quite often the examples used to > demonstrate the protocol are of necessity simpler ones but may not > capture the larger variety of connectivity seen particularly in > larger multihop networks. I will try to make the case using a > slightly more complex network graph which illustrate the benefit of > intermediate state storage and how it might work without explicit > indications of which note are maintaining state. A fair characterization is that the change in down route state must be reflected up until there is a common ancestor that provides connectivity both before and after the change in connectivity *and* can store down routes. In the example that Richard provided, A was the common ancestor and it also happened to be the root. But it is also true that nodes within the sub-DAG of A must update their DAO routing state to reflect the change in topology. As Richard's example points out, when you allow nodes to chose whether they can store down route state, nodes within the sub-DAG must assume the worst case and originate their own DAO messages in case nodes between it and the common ancestors cannot maintain down routes. That said, the cost savings of having storage at intermediate nodes depends mostly on the depth of the common ancestor - a common ancestor with greater depth will result in less transmissions that propagate information towards the root. Of course, in the worst case, the common ancestor will be the root. An unfortunate edge case with hierarchical structures is that the common ancestor of you and your neighbor could be the root. I think it is fair to say that the current DAO caching capabilities specified in the RPL doc need quite a bit more thought before I would be comfortable with putting it into the base specification. If there is a way to treat it as an optimization, I would prefer to do so and work on that in a separate draft. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0075B31386257671_= Content-Type: text/html; charset="US-ASCII"
Hi Jonathan,

I am conflicted with the idea of discounting P2P messaging in this document in lieu of some future document.  I am completely with you that if there will be no attempt to fix the current P2P in RPL then we should deprecate it.  What RPL currently documents for P2P communication simply won't meet the requirements specified (at least within the commercial building market).  On the other hand, if we pull P2P out of RPL, I'm afraid it will never get defined.

In Geneva we discussed that as we complete the MP2P protocol and move it toward true implementations, it will be apparent that even for this presumably unidirectional protocol, these collection networks will still need to application ACK the packets to assure that the packet has been successfully delivered to its destination.  Therefore. even MP2P networks will need a robust means to move packets outward down the DAG; and hence, it would be short-sighted to postpone this to a future draft.

Unless those folks requiring MP2P communication are willing to use a protocol that does not support guaranteed delivery, I think we best work this out within the confines of this current document.

Jerry




Jonathan Hui <jhui@archrock.com>
Sent by: roll-bounces@ietf.org

11/17/2009 02:50 PM

To
Roger Alexander <roger.alexander@ekasystems.com>
cc
"roll@ietf.org" <roll@ietf.org>
Subject
Re: [Roll] updating DAO caches (was Re:  Something to ADD)






Hi Roger,

On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote:

> The conclusions drawn are not entirely valid in part due to the  
> particular example given. Quite often the examples used to  
> demonstrate the protocol are of necessity simpler ones but may not  
> capture the larger variety of connectivity seen particularly in  
> larger multihop networks. I will try to make the case using a  
> slightly more complex network graph which illustrate the benefit of  
> intermediate state storage and how it might work without explicit  
> indications of which note are maintaining state.

A fair characterization is that the change in down route state must be  
reflected up until there is a common ancestor that provides  
connectivity both before and after the change in connectivity *and*  
can store down routes.  In the example that Richard provided, A was  
the common ancestor and it also happened to be the root.  But it is  
also true that nodes within the sub-DAG of A must update their DAO  
routing state to reflect the change in topology.  As Richard's example  
points out, when you allow nodes to chose whether they can store down  
route state, nodes within the sub-DAG must assume the worst case and  
originate their own DAO messages in case nodes between it and the  
common ancestors cannot maintain down routes.

That said, the cost savings of having storage at intermediate nodes  
depends mostly on the depth of the common ancestor - a common ancestor  
with greater depth will result in less transmissions that propagate  
information towards the root.  Of course, in the worst case, the  
common ancestor will be the root.  An unfortunate edge case with  
hierarchical structures is that the common ancestor of you and your  
neighbor could be the root.

I think it is fair to say that the current DAO caching capabilities  
specified in the RPL doc need quite a bit more thought before I would  
be comfortable with putting it into the base specification.  If there  
is a way to treat it as an optimization, I would prefer to do so and  
work on that in a separate draft.

--
Jonathan Hui

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0075B31386257671_=-- From mcr@marajade.sandelman.ca Tue Nov 17 18:37:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF113A69F9 for ; Tue, 17 Nov 2009 18:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.453, 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 ar8lMABSa5qX for ; Tue, 17 Nov 2009 18:37:41 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7BAD13A682B for ; Tue, 17 Nov 2009 18:37:41 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 3D6E3342B6 for ; Tue, 17 Nov 2009 21:29:14 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5378A4E796 for ; Tue, 17 Nov 2009 21:37:38 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 17 Nov 2009 21:37:38 -0500 Message-ID: <18595.1258511858@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 02:37:42 -0000 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> As I see it, all our sensors (temperature, occupancy, light, Jerald> solar, etc) will be hosts positioned as leaves and not even Jerald> in the DAG. They will sleep. Some will awake periodically Jerald> (temp sensors), others on event (light switches). They will Jerald> forward their data to the nearest DAG router destined for Jerald> their requisite controller await their application ACK and Jerald> go back snoozing. By this, I think you mean that they will be on-link with an RPL router, as a normal IPv6 node. Jerald> And yes, none of the devices in the DAG will have any Jerald> special filtering hardware support. Furthermore, the Jerald> devices must have zero-configuration hence defining special Jerald> multicast groups is not feasible. The filters I'm talking about have been built into commodity ethernet MACs since 10Mb/s. (Classic Lance Ethernet chip in a sun2 of 25 years ago.. has this). So, the filters are not special, it's the normal multicast filters... However, there are now many devices that really are just a PHY and a high speed serial port (which can be USB, ethernet, sometimes even DVI...), with the rest of the MAC really being implemented in software and/or firmware (FPGA). I think the Atmel devices might fall into this category. I do not what the situation is in Zigbee or 802.11 low cost radios is though... They must able to some minor bits of filtering though. Are we talking about the same issue here? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From roger.alexander@ekasystems.com Tue Nov 17 18:47:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8ED33A685B for ; Tue, 17 Nov 2009 18:47:55 -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, 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 AnIpaSHO0eqn for ; Tue, 17 Nov 2009 18:47:55 -0800 (PST) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id D152F3A62C1 for ; Tue, 17 Nov 2009 18:47:54 -0800 (PST) Received: (qmail 99690 invoked from network); 18 Nov 2009 02:47:50 -0000 Received: from mobile-166-137-134-177.mycingular.net (roger.alexander@166.137.134.177 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 17 Nov 2009 18:47:49 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: RcaaqywVM1nodJzOIx.a.jV8zIzwaLSaXYfXhehMZLv3uQBEBkK1ewNfVUnSv9fLts8aeZDWa2kJmN4.SbCAfIiHB1g4hQEFRy37cGrMx22gu45.kaLuRI1fvzKFgw2XE5zQ8oFEhv0H4wbEFp9I8s2Xaw53zf5U3M5OLP6hAAjAqrFx789rN0FcPx3xoDpOciUbnfDBqo5Bz4e8rcDwj2xj1JiL6.eOUd73lyiNLoMpxsgIOxbVaLFZOPLXAqVpBgDRWOL_Ffkp_Yz5KK5rkQ8XlsRjz1UC1_nyRaXnYOjgtAPKILtLimKCcotYLT1bLL3gAMMmr5IZ51cIMBOViBHJf7Ltu2jeLCsb5U8scjlCbUSVFm1edGkU5J0LvHlPMQq79Hm_WahEHYCHQH1iFAf.dd25niyx2ylGM5s88aeRRqNgc8T.ie2RlqWnbaR1 X-Yahoo-Newman-Property: ymail-3 Message-Id: <5599FF5A-0501-4FE9-87C2-72FC3C2A8136@ekasystems.com> From: Roger Alexander To: Jonathan Hui Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Tue, 17 Nov 2009 21:47:43 -0500 Cc: "roll@ietf.org" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 02:47:56 -0000 Hi Jonathan, I do very much agree with the points you have made below. From the perspective of a network with only fully capable nodes I would like to see if there are ways for networks to operate with mixed capability nodes without undue overhead as also appears to be indicated in the type of approach discussed by Pascal. That should also allow RPL to be able to operate efficiently for networks where only the root maintains state. As I have indicated, the resulting source routing for networks that store DAOs only at the root must be an option not a base. In the AMI space, IPR lawsuits have been brought against many network companies that use source routing. As a company whose networks do not implement any form of source routing we would wish to ensure that we and others are free to preserve that operating capability even within the RPL framework. To ensure that networks that choose can also implement source routing, low-overhead coexistence should be the goal. Ideally, the ability to separate the protocol operation through distinct modes would be preferred though that may move the problem elsewhere. Roger On Nov 17, 2009, at 12:49 PM, Jonathan Hui wrote: > > Hi Roger, > > On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: > >> The conclusions drawn are not entirely valid in part due to the >> particular example given. Quite often the examples used to >> demonstrate the protocol are of necessity simpler ones but may not >> capture the larger variety of connectivity seen particularly in >> larger multihop networks. I will try to make the case using a >> slightly more complex network graph which illustrate the benefit of >> intermediate state storage and how it might work without explicit >> indications of which note are maintaining state. > > A fair characterization is that the change in down route state must > be reflected up until there is a common ancestor that provides > connectivity both before and after the change in connectivity *and* > can store down routes. In the example that Richard provided, A was > the common ancestor and it also happened to be the root. But it is > also true that nodes within the sub-DAG of A must update their DAO > routing state to reflect the change in topology. As Richard's > example points out, when you allow nodes to chose whether they can > store down route state, nodes within the sub-DAG must assume the > worst case and originate their own DAO messages in case nodes > between it and the common ancestors cannot maintain down routes. > > That said, the cost savings of having storage at intermediate nodes > depends mostly on the depth of the common ancestor - a common > ancestor with greater depth will result in less transmissions that > propagate information towards the root. Of course, in the worst > case, the common ancestor will be the root. An unfortunate edge > case with hierarchical structures is that the common ancestor of you > and your neighbor could be the root. > > I think it is fair to say that the current DAO caching capabilities > specified in the RPL doc need quite a bit more thought before I > would be comfortable with putting it into the base specification. > If there is a way to treat it as an optimization, I would prefer to > do so and work on that in a separate draft. > > -- > Jonathan Hui > From pthubert@cisco.com Tue Nov 17 23:03:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12FF3A6A69 for ; Tue, 17 Nov 2009 23:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 2Z+DgEup+i+M for ; Tue, 17 Nov 2009 23:03:09 -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 58CB73A6359 for ; Tue, 17 Nov 2009 23:03:09 -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: Aj4AAC4rA0uQ/uCWe2dsb2JhbACcAgEBCwskBqArmEeEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,763,1249257600"; d="scan'208";a="54619831" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2009 07:03:06 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAI736iO019146; Wed, 18 Nov 2009 07:03:06 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 08:03:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {F716554A-B856-453C-BEB0-C862B7419967} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: A19g A8y2 B8gr M3VF OIFE OJds PZvB S/xg WamB aE1c cBHO eF4E fHFY fVrC jdZe kBuK; 3; agBoAHUAaQBAAGEAcgBjAGgAcgBvAGMAawAuAGMAbwBtADsAcgBpAGMAaABhAHIAZAAuAGsAZQBsAHMAZQB5AEAAZQBtAGIAZQByAC4AYwBvAG0AOwByAG8AbABsAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F716554A-B856-453C-BEB0-C862B7419967}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 18 Nov 2009 06:50:34 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAHUAcABkAGEAdABpAG4AZwAgAEQAQQBPACAAYwBhAGMAaABlAHMAIAAoAHcAYQBzACAAUgBlADoAIAAgAFMAbwBtAGUAdABoAGkAbgBnACAAdABvACAAQQBEAEQAKQA= Content-class: urn:content-classes:message Date: Wed, 18 Nov 2009 08:03:05 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABEDA@XMB-AMS-107.cisco.com> In-Reply-To: <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: Acpnr2Auf8X78LKWRt2VDNBG8GfzuAAaoJsQ References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 18 Nov 2009 07:03:06.0109 (UTC) FILETIME=[2D8DD2D0:01CA681D] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 07:03:10 -0000 Hi Jonathan >> When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH >> (source route)), you see the source route RH2/4 grow upon movement and >> quickly shrink again as the NINA (DAO) states are reestablished. >> When things are stable you only see as many entries as non DAO capable >> nodes along the path. In my case, the source route is done on a MIP/ >> NEMO >> tunnel, so the RH states are stored in eth binding cache on the home >> agent. But we could store that at the root with exactly the same >> process. >> I can demo that next time we meet if you wish. >> >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header >> details the RRH, since there is not LSRR in IPv6. >> >> Note that in our case, the information in the header should be locally >> significant, like a label. > >Here lies the disconnect.=20 With the draft, not between us :) > The real benefit of storing state among >nodes within the network is to reduce the size of the source route >header not some attempt to support point-to-point traffic. =20 I'm sure we agree here.=20 I'd add that we get a unoptimized P2P if we are willing to have *all*=20 nodes support states. Otherwise you get something quite silly. That unoptimized P2P has interesting characteristics, in particular=20 it is very resilient to movement.=20 We should not bar that feature, just understand what it is good at=20 and what it not so suited for. Like Jerry's problem. > If you buy >that, then the mechanism to establish such state could be much better >than what's currently defined in the draft. In particular, there are >some interesting things we could achieve if we start treating next-hop >information using locally significant labels rather than globally >significant IP addresses, as you suggested. But if done properly, I >think we can specify such a mechanism as an optimization to basic >source-route/record-route. Looks good. The main consequence that I see at first glance is that=20 The DAO should be sent to only one parent, because maintaining multiple Source route path down the DAG makes little sense for reasons discussed Earlier in this list (combinatory explosion, no end to end retries...) Would you agree on that? Pascal From pthubert@cisco.com Tue Nov 17 23:16:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AC43A6881 for ; Tue, 17 Nov 2009 23:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 46220zwvaYC7 for ; Tue, 17 Nov 2009 23:16:08 -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 82ED33A67B6 for ; Tue, 17 Nov 2009 23:16:07 -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: Aj4AAMItA0uQ/uCWe2dsb2JhbACcAgEBCwskBqAnmEOEOwQ X-IronPort-AV: E=Sophos;i="4.44,763,1249257600"; d="scan'208";a="54620497" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2009 07:16:04 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAI7G4qc021288; Wed, 18 Nov 2009 07:16:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 08:16:04 +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: Wed, 18 Nov 2009 08:15:57 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABEE3@XMB-AMS-107.cisco.com> In-Reply-To: <5599FF5A-0501-4FE9-87C2-72FC3C2A8136@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: Acpn+YobHNxPXEVnSL+Vg+AE+OAKSQAIefgA References: <5599FF5A-0501-4FE9-87C2-72FC3C2A8136@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Roger Alexander" , "Jonathan Hui" X-OriginalArrivalTime: 18 Nov 2009 07:16:04.0163 (UTC) FILETIME=[FD4F7130:01CA681E] Cc: roll@ietf.org, "Dan Lang \(dlang\)" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 07:16:09 -0000 Hi Roger: The IPR can be very problematic. The IETF has rules about it. But if some group outside=20 the IETF and not playing by those rules is waiting for us to fall in their trap then we=20 should know about it. Cisco has IPR that covers some of the RPL operations. We have published a statement here https://datatracker.ietf.org/ipr/1134/ and as you see it is strictly defensive. The bright side is that we also have IPR that enables to compress/expand source route in In IP/MANET world, and we have all the label switching art on our side if we use labels. If the draft goes in that direction, this IPR and art might supersede the one you have=20 in mind (non IP is that right?) though I could not infer the result of a legal course.=20 Are there some external publications that we should know about? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Roger Alexander >Sent: mercredi 18 novembre 2009 03:48 >To: Jonathan Hui >Cc: roll@ietf.org >Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > >Hi Jonathan, > >I do very much agree with the points you have made below. From the >perspective of a network with only fully capable nodes I would like to >see if there are ways for networks to operate with mixed capability >nodes without undue overhead as also appears to be indicated in the >type of approach discussed by Pascal. That should also allow RPL to be >able to operate efficiently for networks where only the root maintains >state. > >As I have indicated, the resulting source routing for networks that >store DAOs only at the root must be an option not a base. In the AMI >space, IPR lawsuits have been brought against many network companies >that use source routing. As a company whose networks do not implement >any form of source routing we would wish to ensure that we and others >are free to preserve that operating capability even within the RPL >framework. To ensure that networks that choose can also implement >source routing, low-overhead coexistence should be the goal. Ideally, >the ability to separate the protocol operation through distinct modes >would be preferred though that may move the problem elsewhere. > >Roger > >On Nov 17, 2009, at 12:49 PM, Jonathan Hui wrote: > >> >> Hi Roger, >> >> On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: >> >>> The conclusions drawn are not entirely valid in part due to the >>> particular example given. Quite often the examples used to >>> demonstrate the protocol are of necessity simpler ones but may not >>> capture the larger variety of connectivity seen particularly in >>> larger multihop networks. I will try to make the case using a >>> slightly more complex network graph which illustrate the benefit of >>> intermediate state storage and how it might work without explicit >>> indications of which note are maintaining state. >> >> A fair characterization is that the change in down route state must >> be reflected up until there is a common ancestor that provides >> connectivity both before and after the change in connectivity *and* >> can store down routes. In the example that Richard provided, A was >> the common ancestor and it also happened to be the root. But it is >> also true that nodes within the sub-DAG of A must update their DAO >> routing state to reflect the change in topology. As Richard's >> example points out, when you allow nodes to chose whether they can >> store down route state, nodes within the sub-DAG must assume the >> worst case and originate their own DAO messages in case nodes >> between it and the common ancestors cannot maintain down routes. >> >> That said, the cost savings of having storage at intermediate nodes >> depends mostly on the depth of the common ancestor - a common >> ancestor with greater depth will result in less transmissions that >> propagate information towards the root. Of course, in the worst >> case, the common ancestor will be the root. An unfortunate edge >> case with hierarchical structures is that the common ancestor of you >> and your neighbor could be the root. >> >> I think it is fair to say that the current DAO caching capabilities >> specified in the RPL doc need quite a bit more thought before I >> would be comfortable with putting it into the base specification. >> If there is a way to treat it as an optimization, I would prefer to >> do so and work on that in a separate draft. >> >> -- >> Jonathan Hui >> > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Nov 18 00:07:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC6D3A69C4 for ; Wed, 18 Nov 2009 00:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.078 X-Spam-Level: X-Spam-Status: No, score=-8.078 tagged_above=-999 required=5 tests=[AWL=-1.478, 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 kHdJK2CPNkqZ for ; Wed, 18 Nov 2009 00:07:43 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7F2103A694C for ; Wed, 18 Nov 2009 00:07:43 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMI5A0urRN+K/2dsb2JhbAC8dJhAgiyCDwSMWw X-IronPort-AV: E=Sophos;i="4.44,764,1249257600"; d="scan'208";a="105871661" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2009 08:07:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAI87bPJ029213; Wed, 18 Nov 2009 08:07:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 09:07:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Nov 2009 09:07:36 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> In-Reply-To: <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] do we need a dominating set? Thread-Index: AcpnsfHq3pdhgOjVSmy0npWXUBgsYwAc98xQ References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Stephen Dawson-Haggerty" X-OriginalArrivalTime: 18 Nov 2009 08:07:40.0156 (UTC) FILETIME=[32AA7BC0:01CA6826] Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 08:07:44 -0000 Hi Stephen: I've seen evidence that " trickle performs fine (well)" for propagating = network invariants. The state of a node being NOT a network invariant, I see strong evidence = that we are using a very good hammer for pulling screws. The sequenceNb being a network invariant in an instance, my proposal = seems to be using trickle for what it is good at. Pascal >-----Original Message----- >From: sdhags@gmail.com [mailto:sdhags@gmail.com] On Behalf Of Stephen = Dawson-Haggerty >Sent: mardi 17 novembre 2009 19:15 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; roll@ietf.org >Subject: Re: [Roll] do we need a dominating set? > >We have lots of evidence that trickle performs fine (well) in lots of >settings, including dense ones, when used correctly. This >"improvement" seems pretty speculative-- do we know that this is >necessary __in_addition_to_trickle_? I'm only familiar with the MPRs >in OLSR which seem to perform this function, but there trickle is not >used. We'd need strong evidence that trickle was insufficient to >include this. > >Steve > >On Tue, Nov 17, 2009 at 8:48 AM, Pascal Thubert (pthubert) > wrote: >> Hi Phil: >> >>>> >>>> The current RPL draft uses trickle to address density. Trickle has = a >>>> number of fine properties to throttle the control when things are >>>> stable. >>>> Still, when an accident occurs, like a parent high in the DAG >>>> degrades its rank, possibly most of the nodes in the whole network >>>> will have to reassess their rank and reset their trickle timer. >>>> My understanding of that =A0process is that it can yield quite a = bit >>>> of activity, that grows with the number of nodes acting as routers. >>> >>>Not really, if you have a small redundancy constant. Don't forget, = the >>>number of messages scales logarithmically with density. >> >> I understand that the redundancy counter should eliminate = redundancies. >> I can see how DIO options that contain network wide constants can be >> omitted one the >> But the fact that a node changes its rank is not a redundancy. >> Upon the accident up there, all nodes will have to advertise their = new >> rank since they are being used wrongly if they don't. >> >>>> What I think is that even if we have trickle, we should be >>>> considering some control on the density of nodes that act as a >>>> router. To address that, there's already ample work and large WSN >>>> deployments that leverage the concept of dominating set. >>>> =A0A dominating set is a connected set of routers that enables >>>> connectivity for all >>>> , that is all nodes in the network is connected to at least one >>>> member of the dominating set. >>>> >>> >>>I don't think a dominating set is what you mean: a dominating set can >>>be disconnected. You're talking about a connected dominating set. >> >> :) >> >>> >>>> Because we have trickle, such a set does not need to be =A0shrink = to >>>> minimal/optimal. In fact, we'd want that each node in the network >>>> sees at least 2 members of the dominating set. >>>> >>>> Can that be achieved simply? Possibly. >>>> >>>> Each time a new sequence is spread, nodes are entitled to reassess >>>> their need to be a router. When the sequence spreads, a form of >>>> trickle could be used to decide Not TO advertise self as a router >>>> and act as a host for the new sequence. >>>> Like if enough neighbor routers advertise the new sequence before T >>>> elapse, then there might be no need for self to act as a router. >>> >>>This is exactly what trickle is designed to do, with its redundancy >>>counter. >> >> I fail to see that we can do it in the example above. I see that if = too >> many nodes act as router, we'll get many more paths to manage and = many >> more DIOs generated in case of accident. >> >> I think we should trickle out the duplicate information in DIO (like = DAG >> config) when many neighbors have already cried out loud that info. >> But we should also trickle out / redistribute the role of router when >> opportunity presents itself, that is upon a new sequence. >> >> >>>I thought the major design goal right now to make RPL *less* >>>complicated? >> >> Not having trickle would be a lot less complicated. But also a lot = less >> efficient. So I'm not going there, see? >> >> Pascal >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > >-- >stephen dawson-haggerty >http://cs.berkeley.edu/~stevedh >uc berkeley wireless and embedded systems lab >berkeley, ca 94720 From emmanuel.baccelli@gmail.com Wed Nov 18 02:06:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6ED3A6B6F for ; Wed, 18 Nov 2009 02:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u1b2xofyv47 for ; Wed, 18 Nov 2009 02:06:19 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 26CC93A682E for ; Wed, 18 Nov 2009 02:06:19 -0800 (PST) Received: by gxk28 with SMTP id 28so877630gxk.9 for ; Wed, 18 Nov 2009 02:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=D4u7bqJGB8JaI02Fr9/mpF/7EHZTiX1qd+XgTBe4pM8=; b=Bye9phGYnrRe1DeqpxvogRCJx17S2maSx4Y0xbHPVdVHnpP+bdjdS8Iz8M5z9t5g4a IC7YBrEQy7PdPbr0XR4hiIim2aHbZZEnQIaBElFo6mlQnR0/YIy68y180F2sdKNKAoP0 gkV9egRyyvpKrwQQ3rRrkc0n36axH1304qbK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=biwcQ5P97aROudGXlRQTy8KadLkLI5ZbXxu0E5U4iBdV8wwmku/2HBvdNT+Zt8yHIt vURWnn/zS6fxmGivPbbMwSGA0YaUstXjWSbwyWVfJz1IlcYas9n/Ank8BqWgv1Pptg/t OBm9zi9Q9Z8Q5GAemSorWGAJwySVDtNgZrrEQ= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.10.40 with SMTP id 40mr1806609agj.85.1258538774416; Wed, 18 Nov 2009 02:06:14 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> From: Emmanuel Baccelli Date: Wed, 18 Nov 2009 11:05:54 +0100 X-Google-Sender-Auth: 93891d7fb7cf15c6 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=0016361e88b295ccdf0478a26468 Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 10:06:20 -0000 --0016361e88b295ccdf0478a26468 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, indeed, MPR is what comes to mind in this context. This mechanism is used to identify and maintain connected dominating sets in RFC 5449, RFC 3626, and a slew of soon-to-be RFCs such as draft-ietf-manet-nhdp, draft-ietf-ospf-manet-or, draft-ietf-manet-olsrv2. In order for nodes to see 2 neighbors in the dominating set, you just need to set the value of the MPR_coverage parameter to 2. Emmanuel On Wed, Nov 18, 2009 at 9:07 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Stephen: > > I've seen evidence that " trickle performs fine (well)" for propagating > network invariants. > The state of a node being NOT a network invariant, I see strong evidence > that we are using a very good hammer for pulling screws. > The sequenceNb being a network invariant in an instance, my proposal seems > to be using trickle for what it is good at. > > Pascal > > >-----Original Message----- > >From: sdhags@gmail.com [mailto:sdhags@gmail.com] On Behalf Of Stephen > Dawson-Haggerty > >Sent: mardi 17 novembre 2009 19:15 > >To: Pascal Thubert (pthubert) > >Cc: Philip Levis; roll@ietf.org > >Subject: Re: [Roll] do we need a dominating set? > > > >We have lots of evidence that trickle performs fine (well) in lots of > >settings, including dense ones, when used correctly. This > >"improvement" seems pretty speculative-- do we know that this is > >necessary __in_addition_to_trickle_? I'm only familiar with the MPRs > >in OLSR which seem to perform this function, but there trickle is not > >used. We'd need strong evidence that trickle was insufficient to > >include this. > > > >Steve > > > >On Tue, Nov 17, 2009 at 8:48 AM, Pascal Thubert (pthubert) > > wrote: > >> Hi Phil: > >> > >>>> > >>>> The current RPL draft uses trickle to address density. Trickle has a > >>>> number of fine properties to throttle the control when things are > >>>> stable. > >>>> Still, when an accident occurs, like a parent high in the DAG > >>>> degrades its rank, possibly most of the nodes in the whole network > >>>> will have to reassess their rank and reset their trickle timer. > >>>> My understanding of that process is that it can yield quite a bit > >>>> of activity, that grows with the number of nodes acting as routers. > >>> > >>>Not really, if you have a small redundancy constant. Don't forget, the > >>>number of messages scales logarithmically with density. > >> > >> I understand that the redundancy counter should eliminate redundancies. > >> I can see how DIO options that contain network wide constants can be > >> omitted one the > >> But the fact that a node changes its rank is not a redundancy. > >> Upon the accident up there, all nodes will have to advertise their new > >> rank since they are being used wrongly if they don't. > >> > >>>> What I think is that even if we have trickle, we should be > >>>> considering some control on the density of nodes that act as a > >>>> router. To address that, there's already ample work and large WSN > >>>> deployments that leverage the concept of dominating set. > >>>> A dominating set is a connected set of routers that enables > >>>> connectivity for all > >>>> , that is all nodes in the network is connected to at least one > >>>> member of the dominating set. > >>>> > >>> > >>>I don't think a dominating set is what you mean: a dominating set can > >>>be disconnected. You're talking about a connected dominating set. > >> > >> :) > >> > >>> > >>>> Because we have trickle, such a set does not need to be shrink to > >>>> minimal/optimal. In fact, we'd want that each node in the network > >>>> sees at least 2 members of the dominating set. > >>>> > >>>> Can that be achieved simply? Possibly. > >>>> > >>>> Each time a new sequence is spread, nodes are entitled to reassess > >>>> their need to be a router. When the sequence spreads, a form of > >>>> trickle could be used to decide Not TO advertise self as a router > >>>> and act as a host for the new sequence. > >>>> Like if enough neighbor routers advertise the new sequence before T > >>>> elapse, then there might be no need for self to act as a router. > >>> > >>>This is exactly what trickle is designed to do, with its redundancy > >>>counter. > >> > >> I fail to see that we can do it in the example above. I see that if too > >> many nodes act as router, we'll get many more paths to manage and many > >> more DIOs generated in case of accident. > >> > >> I think we should trickle out the duplicate information in DIO (like DAG > >> config) when many neighbors have already cried out loud that info. > >> But we should also trickle out / redistribute the role of router when > >> opportunity presents itself, that is upon a new sequence. > >> > >> > >>>I thought the major design goal right now to make RPL *less* > >>>complicated? > >> > >> Not having trickle would be a lot less complicated. But also a lot less > >> efficient. So I'm not going there, see? > >> > >> Pascal > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > > > > > > > >-- > >stephen dawson-haggerty > >http://cs.berkeley.edu/~stevedh > >uc berkeley wireless and embedded systems lab > >berkeley, ca 94720 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0016361e88b295ccdf0478a26468 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stephen,

indeed, MPR=A0is=A0what=A0comes=A0to=A0mind= =A0in=A0this=A0context.=A0This mechanism=A0is=A0used=A0to identify and main= tain connected dominating sets=A0in=A0RFC=A05449,=A0RFC=A03626,=A0and a sle= w of soon-to-be RFCs such as=A0draft-ietf-manet-nhdp,=A0draft-ietf-ospf-man= et-or,=A0draft-ietf-manet-olsrv2.=A0

In order for nodes to see 2 neighbors in the dominating= set, you just need to set the value of the MPR_coverage parameter to 2.

Emmanuel



On Wed, Nov 18, 2009 at 9:07 AM, Pascal Thub= ert (pthubert) <= pthubert@cisco.com> wrote:
Hi Stephen:

I've seen evidence that " trickle performs fine (well)" for p= ropagating network invariants.
The state of a node being NOT a network invariant, I see strong evidence th= at we are using a very good hammer for pulling screws.
The sequenceNb being a network invariant in an instance, my proposal seems = to be using trickle for what it is good at.

Pascal

>-----Original Message-----
>From: sdhags@gmail.com [mailto:= sdhags@gmail.com] On Behalf Of Step= hen Dawson-Haggerty
>Sent: mardi 17 novembre 2009 19:15
>To: Pascal Thubert (pthubert)
>Cc: Philip Levis; roll@ietf.org >Subject: Re: [Roll] do we need a dominating set?
>
>We have lots of evidence that t= rickle performs fine (well) in lots of
>settings, including dense ones, when used correctly. =A0This
>"improvement" seems pretty speculative-- do we know that this= is
>necessary __in_addition_to_trickle_? =A0I'm only familiar with the = MPRs
>in OLSR which seem to perform this function, but there trickle is not >used. =A0We'd need strong evidence that trickle was insufficient to=
>include this.
>
>Steve
>
>On Tue, Nov 17, 2009 at 8:48 AM, Pascal Thubert (pthubert)
><pthubert@cisco.com> wr= ote:
>> Hi Phil:
>>
>>>>
>>>> The current RPL draft uses trickle to address density. Tri= ckle has a
>>>> number of fine properties to throttle the control when thi= ngs are
>>>> stable.
>>>> Still, when an accident occurs, like a parent high in the = DAG
>>>> degrades its rank, possibly most of the nodes in the whole= network
>>>> will have to reassess their rank and reset their trickle t= imer.
>>>> My understanding of that =A0process is that it can yield q= uite a bit
>>>> of activity, that grows with the number of nodes acting as= routers.
>>>
>>>Not really, if you have a small redundancy constant. Don't = forget, the
>>>number of messages scales logarithmically with density.
>>
>> I understand that the redundancy counter should eliminate redundan= cies.
>> I can see how DIO options that contain network wide constants can = be
>> omitted one the
>> But the fact that a node changes its rank is not a redundancy.
>> Upon the accident up there, all nodes will have to advertise their= new
>> rank since they are being used wrongly if they don't.
>>
>>>> What I think is that even if we have trickle, we should be=
>>>> considering some control on the density of nodes that act = as a
>>>> router. To address that, there's already ample work an= d large WSN
>>>> deployments that leverage the concept of dominating set. >>>> =A0A dominating set is a connected set of routers that ena= bles
>>>> connectivity for all
>>>> , that is all nodes in the network is connected to at leas= t one
>>>> member of the dominating set.
>>>>
>>>
>>>I don't think a dominating set is what you mean: a dominati= ng set can
>>>be disconnected. You're talking about a connected dominatin= g set.
>>
>> :)
>>
>>>
>>>> Because we have trickle, such a set does not need to be = =A0shrink to
>>>> minimal/optimal. In fact, we'd want that each node in = the network
>>>> sees at least 2 members of the dominating set.
>>>>
>>>> Can that be achieved simply? Possibly.
>>>>
>>>> Each time a new sequence is spread, nodes are entitled to = reassess
>>>> their need to be a router. When the sequence spreads, a fo= rm of
>>>> trickle could be used to decide Not TO advertise self as a= router
>>>> and act as a host for the new sequence.
>>>> Like if enough neighbor routers advertise the new sequence= before T
>>>> elapse, then there might be no need for self to act as a r= outer.
>>>
>>>This is exactly what trickle is designed to do, with its redund= ancy
>>>counter.
>>
>> I fail to see that we can do it in the example above. I see that i= f too
>> many nodes act as router, we'll get many more paths to manage = and many
>> more DIOs generated in case of accident.
>>
>> I think we should trickle out the duplicate information in DIO (li= ke DAG
>> config) when many neighbors have already cried out loud that info.=
>> But we should also trickle out / redistribute the role of router w= hen
>> opportunity presents itself, that is upon a new sequence.
>>
>>
>>>I thought the major design goal right now to make RPL *less* >>>complicated?
>>
>> Not having trickle would be a lot less complicated. But also a lot= less
>> efficient. So I'm not going there, see?
>>
>> Pascal
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>
>
>
>--
>stephen dawson-haggerty
>http://cs= .berkeley.edu/~stevedh
>uc berkeley wireless and embedded systems lab
>berkeley, ca 94720
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0016361e88b295ccdf0478a26468-- From pthubert@cisco.com Wed Nov 18 04:22:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AA33A68E3 for ; Wed, 18 Nov 2009 04:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 zXLqDZlbVoRb for ; Wed, 18 Nov 2009 04:22:01 -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 C20743A6914 for ; Wed, 18 Nov 2009 04:22:00 -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: AjUAAAd1A0uQ/uCWe2dsb2JhbACcAgEBCwskBqBEmDOEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,765,1249257600"; d="scan'208";a="54650316" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2009 12:21:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAICLvId013585; Wed, 18 Nov 2009 12:21:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:21:57 +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: Wed, 18 Nov 2009 13:21:46 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAAC13E@XMB-AMS-107.cisco.com> In-Reply-To: <993A6A9B-2D0D-4A88-9A4F-62E154815260@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: AcpnqGKMwav+IAgxS8GsiPO6VvjYXgAnwd7A References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com><10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com><16061.1258477357@marajade.sandelman.ca> <993A6A9B-2D0D-4A88-9A4F-62E154815260@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Michael Richardson" X-OriginalArrivalTime: 18 Nov 2009 12:21:57.0100 (UTC) FILETIME=[B88362C0:01CA6849] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 12:22:02 -0000 Hi Jonathan and Michael. Both the source route and the DAO depend on the DAG specification. The other way around, the DAG specification does not depend on them. And arguably, one deployment could use source route only whereas Another that needs all end to end connectivity would use DAO states Yet another could take an unspecified-yet limited P2P solution to compute only required on-demand constrained routes. Even more fun, it is very possible to mix DAO states into a source route network. Since we have not designed a more specific on demand P2P solution, or even proven that=20 the existing MANET solutions are not enough for the job, I can only infer that the best=20 contender is probably DYMO, in which case it has no dependency at all. =20 Since we already took the path of not having a minimum Interop set in one spec by removing OCP0,=20 * I have no philosophical opposition in splitting the draft to make the DAO separate. * Also make a source route document that can work with no states yet explains how the DAO states can compress the source route when they are present=20 * Then study the applicability of existing on demand protocol and see what we need to do there. >From there, the applicability statement will have to guide us in which sets we need to pick in an implementation. But those documents should still make a consistent set, for instance for the purpose of loop detection. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mardi 17 novembre 2009 18:07 >To: Michael Richardson >Cc: roll@ietf.org >Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > >On Nov 17, 2009, at 9:02 AM, Michael Richardson wrote: > >>>>>>> "Jonathan" =3D=3D Jonathan Hui writes: >> Jonathan> I'll have to admit that I'm not yet convinced of the >> Jonathan> benefits in storing DAO state as it currently exists in >> Jonathan> the draft. It seems like a mediocre attempt to optimize >> Jonathan> point-to-point routing and something that folks wanting >> Jonathan> P2P support aren't satisfied with. If that is the >> Jonathan> end-goal, then we should be developing better mechanisms. >> Jonathan> For now, we are focusing on one-to-many and many-to-one. >> Jonathan> And, I see more benefits to simply maintaining state at >> Jonathan> the root. >> >> Thus, my proposal to forbid storing of state in intermediate nodes >> (at least in the base protocol) since it causes externalities. >> >> Perhaps someone can some up with a way to store some state (but not >> the >> DAOs) in such a way that does not impose externalities that need to be >> communicated in the protocol. > >Yes. Sorry for not stating it clearly. I also propose to remove the >ability to store downwards routing state at intermediate nodes from >the base RPL document. A P2P proposal that satisfies the application >requirements should be dealt with in a separate draft. > >-- >Jonathan Hui > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Wed Nov 18 07:24:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCF93A6A64 for ; Wed, 18 Nov 2009 07:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, 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 96DWJnhubPsI for ; Wed, 18 Nov 2009 07:24:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 38F073A6915 for ; Wed, 18 Nov 2009 07:24:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEEANegA0tAZnwN/2dsb2JhbACCIy27RpghhDsE X-IronPort-AV: E=Sophos;i="4.44,765,1249257600"; d="scan'208,217";a="68754579" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2009 15:24:11 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAIFO7U2005272 for ; Wed, 18 Nov 2009 15:24:10 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 16:24:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6863.2C828F6A" Date: Wed, 18 Nov 2009 16:24:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Role of the OF Thread-Index: AcpoYywFgAAjkqI7RxOmOaBQ0QKSNA== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 18 Nov 2009 15:24:08.0585 (UTC) FILETIME=[2C2F9F90:01CA6863] Subject: [Roll] Role of the OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 15:24:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6863.2C828F6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 for me an OF is a logic used to compare parents, i.e. from 2 parents A, A a is better than B. This can be used for a full sort (from a list of x parents, order them) or a best paret election (from a list of x parents, which is the best) an OF should not know what RPL states mean (preferred or backup has no meaning for an OF).=20 In short the OF is equivalent to the > sign, but for parents=20 =20 Is this correct? If yes the text in the OF0 description should not have any reference to "prefered/backup..." =20 Best, Julien ------_=_NextPart_001_01CA6863.2C828F6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
for me = an OF is a=20 logic used to compare parents, i.e. from 2 parents A, A a is better than = B. This=20 can be used for a full sort (from a list of x parents, order them) or a = best=20 paret election (from a list of x parents, which is the = best)
an OF should not know what RPL states mean = (preferred or=20 backup has no meaning for an OF).
In = short the OF is=20 equivalent to the > sign, but for parents 
 
Is = this correct? If=20 yes the text in the OF0 description should not have any reference to=20 "prefered/backup..."
 
Best,
Julien
------_=_NextPart_001_01CA6863.2C828F6A-- From jvasseur@cisco.com Wed Nov 18 08:20:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F52D28C105 for ; Wed, 18 Nov 2009 08:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.542 X-Spam-Level: X-Spam-Status: No, score=-9.542 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM9CFvvNfhRy for ; Wed, 18 Nov 2009 08:20: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 CE27228C101 for ; Wed, 18 Nov 2009 08:20:30 -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: AjcAAH6tA0uQ/uCWe2dsb2JhbACCIi6ZMgEBCwskBqF+mBmEOwQ X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208,217";a="54674004" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2009 16:20:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAIGKSto018622 for ; Wed, 18 Nov 2009 16:20:28 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 17:20:27 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 17:20:27 +0100 Message-Id: From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-236--1066330850 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 17:20:26 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Nov 2009 16:20:27.0559 (UTC) FILETIME=[0A362370:01CA686B] Cc: ROLL WG Subject: Re: [Roll] Role of the OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 16:20:33 -0000 --Apple-Mail-236--1066330850 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Julien, On Nov 18, 2009, at 4:24 PM, Julien Abeille (jabeille) wrote: > Hi all, > > for me an OF is a logic used to compare parents, i.e. from 2 parents > A, A a is better than B. This can be used for a full sort (from a > list of x parents, order them) or a best paret election (from a list > of x parents, which is the best) > an OF should not know what RPL states mean (preferred or backup has > no meaning for an OF). > In short the OF is equivalent to the > sign, but for parents > > Is this correct? If yes the text in the OF0 description should not > have any reference to "prefered/backup..." There are scenario where this might be useful, in addition to the "preferred" relationship. For example the OF may tell you to systematically to connect to N parents so as to increase the degree of meshing to improve P2P paths for example. > > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-236--1066330850 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Julien,

On = Nov 18, 2009, at 4:24 PM, Julien Abeille (jabeille) wrote:

=
Hi= all,
 
for me an = OF is a logic used to compare parents, i.e. from 2 parents A, A a is = better than B. This can be used for a full sort (from a list of x = parents, order them) or a best paret election (from a list of x parents, = which is the best)
an OF = should not know what RPL states mean (preferred or backup has no meaning = for an OF).
In short = the OF is equivalent to the > sign, but for = parents 
 
Is this = correct? If yes the text in the OF0 description should not have any = reference to "prefered/backup..."

Ther= e are scenario where this might be useful, in addition to the = "preferred" relationship. For example the OF may tell you to = systematically to connect to N parents so as to increase the degree of = meshing to improve P2P paths for example.

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

= --Apple-Mail-236--1066330850-- From jabeille@cisco.com Wed Nov 18 08:23:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCF028C10C for ; Wed, 18 Nov 2009 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOXjnAo1Ab0H for ; Wed, 18 Nov 2009 08:23:01 -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 76C3C3A68E9 for ; Wed, 18 Nov 2009 08:23:00 -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: AjgAAKquA0uQ/uCWe2dsb2JhbACCIy2ZMgEBCwskBqF/mBqEOwQ X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208,217";a="54674369" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2009 16:22:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAIGMvSw019634 for ; Wed, 18 Nov 2009 16:22:57 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 17:22:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA686B.638066B0" Date: Wed, 18 Nov 2009 17:22:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Role of the OF Thread-Index: Acpoawp8X7x/gg4mQ8qqSYY7pz7ksQAAB+LQ References: From: "Julien Abeille (jabeille)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 18 Nov 2009 16:22:56.0703 (UTC) FILETIME=[631BB4F0:01CA686B] Cc: ROLL WG Subject: Re: [Roll] Role of the OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 16:23:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA686B.638066B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable if i understand this it is about choosing the DAG which has more parents? If yes I agree, but still this removes the backup parent selection section? Julien =20 ________________________________ From: JP Vasseur (jvasseur)=20 Sent: mercredi 18 novembre 2009 17:20 To: Julien Abeille (jabeille) Cc: ROLL WG Subject: Re: [Roll] Role of the OF =09 =09 Hi Julien,=20 On Nov 18, 2009, at 4:24 PM, Julien Abeille (jabeille) wrote: Hi all, =20 for me an OF is a logic used to compare parents, i.e. from 2 parents A, A a is better than B. This can be used for a full sort (from a list of x parents, order them) or a best paret election (from a list of x parents, which is the best) an OF should not know what RPL states mean (preferred or backup has no meaning for an OF).=20 In short the OF is equivalent to the > sign, but for parents=20 =20 Is this correct? If yes the text in the OF0 description should not have any reference to "prefered/backup..." =09 There are scenario where this might be useful, in addition to the "preferred" relationship. For example the OF may tell you to systematically to connect to N parents so as to increase the degree of meshing to improve P2P paths for example. =20 Best, Julien _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CA686B.638066B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
if i understand this it is about choosing the = DAG which has=20 more parents? If yes I agree, but still this removes the backup parent = selection=20 section?
Julien
 

From: JP Vasseur (jvasseur) =
Sent:=20 mercredi 18 novembre 2009 17:20
To: Julien Abeille=20 (jabeille)
Cc: ROLL WG
Subject: Re: [Roll] Role of = the=20 OF

Hi Julien,

On Nov 18, 2009, at 4:24 PM, Julien Abeille (jabeille) = wrote:
Hi = all,
 
for me an OF is=20 a logic used to compare parents, i.e. from 2 parents A, A a is = better than=20 B. This can be used for a full sort (from a list of x parents, order = them)=20 or a best paret election (from a list of x parents, which is the=20 best)
an OF should = not know what=20 RPL states mean (preferred or backup has no meaning for an OF).=20
In = short the OF=20 is equivalent to the > sign, but for = parents 
 
Is = this correct?=20 If yes the text in the OF0 description should not have any reference = to=20 "prefered/backup..."

There are scenario where this might be useful, in addition to the = "preferred" relationship. For example the OF may tell you to = systematically to=20 connect to N parents so as to increase the degree of meshing to = improve P2P=20 paths for example.

 
Best,
Julien
________________________________= _______________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= ------_=_NextPart_001_01CA686B.638066B0-- From pal@cs.stanford.edu Wed Nov 18 09:20:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B823A6951 for ; Wed, 18 Nov 2009 09:20:47 -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 J6H1fpwR9Epm for ; Wed, 18 Nov 2009 09:20:46 -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 7D9173A67A4 for ; Wed, 18 Nov 2009 09:20:46 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAoCx-0000kd-0w; Wed, 18 Nov 2009 09:20:44 -0800 Message-Id: <916D30AD-8254-488B-AAFF-EC3389AA93BE@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 09:20:41 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 17:20:47 -0000 On Nov 18, 2009, at 2:05 AM, Emmanuel Baccelli wrote: > Hi Stephen, > > indeed, MPR is what comes to mind in this context. This mechanism is > used to identify and maintain connected dominating sets in RFC 5449, > RFC 3626, and a slew of soon-to-be RFCs such as draft-ietf-manet- > nhdp, draft-ietf-ospf-manet-or, draft-ietf-manet-olsrv2. > > In order for nodes to see 2 neighbors in the dominating set, you > just need to set the value of the MPR_coverage parameter to 2. > Of course, RPL is a distance vector protocol, while OLSR/OSPF are link state protocols; that state makes connected dominating sets straight- forward to compute. Are there examples of connected dominating sets (or variants thereof) being used in a distance vector protocol? It seems like there would be a lot of complications. Phil From pal@cs.stanford.edu Wed Nov 18 09:30:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB01C3A6993 for ; Wed, 18 Nov 2009 09:30: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 KNFgXYKKyDV3 for ; Wed, 18 Nov 2009 09:30:20 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AD3853A697C for ; Wed, 18 Nov 2009 09:30:20 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAoME-00023L-EI; Wed, 18 Nov 2009 09:30:18 -0800 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 09:30:15 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <8FC2D57F-98E9-46D1-B196-D8154DC1ED08@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5DAABD26@XMB-AMS-107.cisco.com> <44680fe70911171015i4abaaadahb21d2b92be8bfcdc@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5DAABF19@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 17:30:21 -0000 On Nov 18, 2009, at 12:07 AM, Pascal Thubert (pthubert) wrote: > Hi Stephen: > > I've seen evidence that " trickle performs fine (well)" for > propagating network invariants. > The state of a node being NOT a network invariant, I see strong > evidence that we are using a very good hammer for pulling screws. > The sequenceNb being a network invariant in an instance, my proposal > seems to be using trickle for what it is good at. "Propagating" is probably the wrong word here, as Trickle's events can be local (e.g. local repair). Generally, Trickle's mechanisms each have advantages for a variety of uses: 1) The exponential timer makes it efficiently maintaining eventual consistency 2) The suppression constant makes it efficiently support broadcast operations. 3) Its randomization helps it support broadcasts, and also evenly distributes load. Etc. There is always a tension between maintenance and discovery. You want to get more information from the active parents/routes/etc., yet do not want this to preclude getting information from other nodes who may happen to be better options. It seems to me that the protocol specification allows this already. If some higher-level dominating set algorithm (which *clearly* should not be in the draft) can improve the protocol, then the fact that transmissions MAY increment C is the way to handle this. If a node that is a member of this hypothetical dominating set doesn't increment C when it hears messages, it isn't suppressed. So I don't see why the specification needs to change. Phil From roger.alexander@ekasystems.com Wed Nov 18 10:57:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6333A67DB for ; Wed, 18 Nov 2009 10:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyMBMkIfST9c for ; Wed, 18 Nov 2009 10:57:24 -0800 (PST) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id 814EA3A67D9 for ; Wed, 18 Nov 2009 10:57:24 -0800 (PST) Received: (qmail 29310 invoked from network); 18 Nov 2009 18:57:20 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 18 Nov 2009 10:57:20 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: usBne.kVM1mFgrbkRUTtTIUDkgnowZmEiiM5jwQHB1PDETlA2RkdUvw33iLzBASAWNY7HSnMdgfNs1eipD_I9NVp6HXknFd5QhPh5nbeyoMxp0INZrCJ4cd9.sQgzUgTq2lF2Y1EG2XO7plEZ.yHlAuokjnlp7TNSaz2ZulHmBYl_jlBTYPH7sw1if.0GGL1KSL5aALZXLNa9gaWFUVfZqyfxn1FsNxqOkSxkSfNjQhLpRPhKFJMciK3x324uzptmWQL4w.BpWSpqy6GaccRS0QNn34URNtFVN7i4PjeNmMyLFWJbElbaSL376ovrrcD51QsNXYocPARfD7W1EqcyGsYUdj0Gp.6taKKUZuzm1Ayr9reEartDFh62M2Y69Mm.mxSXCFly2AJpLeS9D60JBTLLaPGsNsalNSUxZDpmt.Ft_BRbJdYGtF3 X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Pascal Thubert \(pthubert\)'" , "'Jonathan Hui'" References: <5599FF5A-0501-4FE9-87C2-72FC3C2A8136@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5DAABEE3@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABEE3@XMB-AMS-107.cisco.com> Date: Wed, 18 Nov 2009 13:59:54 -0500 Message-ID: <020701ca6881$50996320$f1cc2960$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpn+YobHNxPXEVnSL+Vg+AE+OAKSQAIefgAABUej+A= Content-Language: en-us Cc: roll@ietf.org, "'Dan Lang \(dlang\)'" Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 18:57:26 -0000 Hi Pascal, See link to a public reference as appearing in 'RFC Express' (a very different RFC). The article provides references to the cited patents (the texts of which can be found on the web). http://www.rfcexpress.com/lawsuit-news.asp?id=3461 Since we do not practice any form of source routing we continue to contest the allegation, though it is believed others may have settled. Based on what we have seen, this type of litigation is an emerging part of the AMI industry. Roger > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, November 18, 2009 2:16 AM > To: Roger Alexander; Jonathan Hui > Cc: roll@ietf.org; Dan Lang (dlang) > Subject: RE: [Roll] updating DAO caches (was Re: Something to ADD) > > Hi Roger: > > The IPR can be very problematic. The IETF has rules about it. But if > some group outside > the IETF and not playing by those rules is waiting for us to fall in > their trap then we > should know about it. > > Cisco has IPR that covers some of the RPL operations. We have published > a statement > here https://datatracker.ietf.org/ipr/1134/ and as you see it is > strictly defensive. > > The bright side is that we also have IPR that enables to > compress/expand > source route in > In IP/MANET world, and we have all the label switching art on our side > if we use labels. > > If the draft goes in that direction, this IPR and art might supersede > the one you have > in mind (non IP is that right?) though I could not infer the result of > a > legal course. > > Are there some external publications that we should know about? > > Pascal > > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Roger Alexander > >Sent: mercredi 18 novembre 2009 03:48 > >To: Jonathan Hui > >Cc: roll@ietf.org > >Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > >Hi Jonathan, > > > >I do very much agree with the points you have made below. From the > >perspective of a network with only fully capable nodes I would like to > >see if there are ways for networks to operate with mixed capability > >nodes without undue overhead as also appears to be indicated in the > >type of approach discussed by Pascal. That should also allow RPL to be > >able to operate efficiently for networks where only the root maintains > >state. > > > >As I have indicated, the resulting source routing for networks that > >store DAOs only at the root must be an option not a base. In the AMI > >space, IPR lawsuits have been brought against many network companies > >that use source routing. As a company whose networks do not implement > >any form of source routing we would wish to ensure that we and others > >are free to preserve that operating capability even within the RPL > >framework. To ensure that networks that choose can also implement > >source routing, low-overhead coexistence should be the goal. Ideally, > >the ability to separate the protocol operation through distinct modes > >would be preferred though that may move the problem elsewhere. > > > >Roger > > > >On Nov 17, 2009, at 12:49 PM, Jonathan Hui wrote: > > > >> > >> Hi Roger, > >> > >> On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote: > >> > >>> The conclusions drawn are not entirely valid in part due to the > >>> particular example given. Quite often the examples used to > >>> demonstrate the protocol are of necessity simpler ones but may not > >>> capture the larger variety of connectivity seen particularly in > >>> larger multihop networks. I will try to make the case using a > >>> slightly more complex network graph which illustrate the benefit of > >>> intermediate state storage and how it might work without explicit > >>> indications of which note are maintaining state. > >> > >> A fair characterization is that the change in down route state must > >> be reflected up until there is a common ancestor that provides > >> connectivity both before and after the change in connectivity *and* > >> can store down routes. In the example that Richard provided, A was > >> the common ancestor and it also happened to be the root. But it is > >> also true that nodes within the sub-DAG of A must update their DAO > >> routing state to reflect the change in topology. As Richard's > >> example points out, when you allow nodes to chose whether they can > >> store down route state, nodes within the sub-DAG must assume the > >> worst case and originate their own DAO messages in case nodes > >> between it and the common ancestors cannot maintain down routes. > >> > >> That said, the cost savings of having storage at intermediate nodes > >> depends mostly on the depth of the common ancestor - a common > >> ancestor with greater depth will result in less transmissions that > >> propagate information towards the root. Of course, in the worst > >> case, the common ancestor will be the root. An unfortunate edge > >> case with hierarchical structures is that the common ancestor of you > >> and your neighbor could be the root. > >> > >> I think it is fair to say that the current DAO caching capabilities > >> specified in the RPL doc need quite a bit more thought before I > >> would be comfortable with putting it into the base specification. > >> If there is a way to treat it as an optimization, I would prefer to > >> do so and work on that in a separate draft. > >> > >> -- > >> Jonathan Hui > >> > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Wed Nov 18 13:10:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A110D3A6ABD; Wed, 18 Nov 2009 13:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ1EHYD1e-VY; Wed, 18 Nov 2009 13:10:34 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id D5B293A6A88; Wed, 18 Nov 2009 13:10:33 -0800 (PST) Received: by bwz23 with SMTP id 23so1711257bwz.29 for ; Wed, 18 Nov 2009 13:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.24.2 with SMTP id t2mr6819247bkb.65.1258578625234; Wed, 18 Nov 2009 13:10:25 -0800 (PST) Date: Wed, 18 Nov 2009 22:10:23 +0100 Message-ID: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> From: Ulrich Herberg To: 6lowpan <6lowpan@ietf.org>, manet@ietf.org, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] SNMP optimizations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 21:10:36 -0000 Hi, I am sending this message to the 6lowpan, ROLL and MANET mailing list, since I think this topic concerns all three working groups, and I am not sure in which WG this is to be tackled. During the MANET WG meeting and also during an OLSRv2 Interop workshop, we had discussions about SNMP deployments in such ad-hoc networks we are dealing with. The issue that was raised (and which is also described in draft-hamid-6lowpan-snmp-optimizations) is that SNMP may be too memory-/CPU-/bandwidth-consuming for low-power devices. However, a solution for monitoring and management of these devices is desired (and also required by IETF). The before-mentioned draft describes very well how to optimize SNMP for running it on 6lowpan devices, and shows that the SNMP payload can fit into 6lowpan packets. However, it is unclear whether the code footprint of SNMP implementations can fit into the memory of small devices. From discussions with several persons from the MANET WG, I conclude that for MANET the same problem exists. (and I think for ROLL, too?) I have several questions that came to my mind about this topic: - First of all, to which WG does this issue belong to? Or is it -- as I suppose -- a common problem for the three working groups addressed in this mail? - Is this really an issue? Are there implementations of SNMP (maybe not open-source) that can be run on very small devices such as considered in 6lowpan/ROLL/MANET? Is there any experimental (or theoretical) analysis whether SNMP (or any other standardized management protocol) can run on these devices? - If SNMP cannot be used for small devices, how can we manage and monitor these devices then? (e.g. using proxies, different message formats such as proposed in 6lowapp, etc.). Do we need a different lightweight protocol for management? - Can we provide SNMP not only on a single device, but for a whole network? That might need an aggregator device that runs full SNMP and collects the data from the low power devices. This would imply to monitor statistics of a whole network (e.g. number of links, average throughput, average path-length, etc.) - What kind of objects should be provided in a MIB running on a MANET/6lowpan/ROLL device? This might be specific to the routing protocol, but there can be commonalities. Regards, Ulrich From mcr@marajade.sandelman.ca Wed Nov 18 13:15:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A98C3A6AD6 for ; Wed, 18 Nov 2009 13:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_05=-1.11, 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 ZqOYrLtk-r-1 for ; Wed, 18 Nov 2009 13:15:28 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3E8263A68DA for ; Wed, 18 Nov 2009 13:15:27 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D575342D6 for ; Wed, 18 Nov 2009 16:07:04 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EAF764E793 for ; Wed, 18 Nov 2009 13:40:05 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 18 Nov 2009 13:40:05 -0500 Message-ID: <5016.1258569605@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 21:15:29 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> A dominating set is a connected set of routers that enables Pascal> connectivity for all, that is all nodes in the network is Pascal> connected to at least one member of the dominating set. So, in a straight tree arrangement, the dominating set is the non-leaf nodes. In a linear arrangement, the dominating set is all the nodes, except for the last one. Is this correct? Pascal> Each time a new sequence is spread, nodes are entitled to Pascal> reassess their need to be a router. When the sequence Pascal> spreads, a form of trickle could be used to decide Not TO Pascal> advertise self as a router and act as a host for the new Pascal> sequence. Pascal> Like if enough neighbor routers advertise the new sequence Pascal> before T elapse, then there might be no need for self to act Pascal> as a router. It sounds like it needs some pseudo-random delays to avoid races. If the delays are truly random, then the dominating set might flap quite a lot. I don't think that's good. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Wed Nov 18 13:32:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE053A65A5 for ; Wed, 18 Nov 2009 13:32:40 -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 DoMViP9AYXzA for ; Wed, 18 Nov 2009 13:32:39 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 34E133A69E7 for ; Wed, 18 Nov 2009 13:32:39 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAs8i-0006J5-Ow; Wed, 18 Nov 2009 13:32:37 -0800 Message-Id: <645DB8EE-221C-43C7-BE9A-57659504301B@cs.stanford.edu> From: Philip Levis To: Michael Richardson In-Reply-To: <5016.1258569605@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 13:32:36 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <5016.1258569605@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6b0537b5faa14548adc1759647fcb4de Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 21:32:40 -0000 On Nov 18, 2009, at 10:40 AM, Michael Richardson wrote: > >>>>>> "Pascal" == Pascal Thubert <(pthubert)" > >>>>>> writes: > Pascal> A dominating set is a connected set of routers that > enables > Pascal> connectivity for all, that is all nodes in the network is > Pascal> connected to at least one member of the dominating set. > > So, in a straight tree arrangement, the dominating set is the non-leaf > nodes. In a linear arrangement, the dominating set is all the nodes, > except for the last one. > Is this correct? No. Unfortunately, that's not the definition of a dominating set. Dominating set is a precise term that's been used for decades in graph algorithms. It helps to not try to redefine such terms, as all it does is lead to confusion. Here's the wikipedia page for dominating set: http://en.wikipedia.org/wiki/Dominating_set Note that neither example (a) nor (b) satisfy Pascal's description. Pascal is referring to something else, similar to a spanning tree where the edges to leaf nodes are not included. Sorry to be a stickler on this, but if we start misusing well defined terminology now, it will just make everything harder to understand further along in the process. Phil From mcr@marajade.sandelman.ca Wed Nov 18 14:08:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F93A3A68C2 for ; Wed, 18 Nov 2009 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.420, 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 4Bz9qbcQrihY for ; Wed, 18 Nov 2009 14:08:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 455C13A67EE for ; Wed, 18 Nov 2009 14:08:10 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id E5F80342D1; Wed, 18 Nov 2009 16:59:46 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7B5EA4E782; Wed, 18 Nov 2009 17:08:07 -0500 (EST) From: Michael Richardson To: Philip Levis In-Reply-To: <645DB8EE-221C-43C7-BE9A-57659504301B@cs.stanford.edu> References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <5016.1258569605@marajade.sandelman.ca> <645DB8EE-221C-43C7-BE9A-57659504301B@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 18 Nov 2009 17:08:07 -0500 Message-ID: <8390.1258582087@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 22:08:11 -0000 >>>>> "Philip" == Philip Levis writes: >>>>>>> "Pascal" == Pascal Thubert <(pthubert)" >>>>>>> > writes: Pascal> A dominating set is a connected set of routers that enables Pascal> connectivity for all, that is all nodes in the network is Pascal> connected to at least one member of the dominating set. >> So, in a straight tree arrangement, the dominating set is the >> non-leaf nodes. In a linear arrangement, the dominating set is >> all the nodes, except for the last one. Is this correct? Philip> No. Unfortunately, that's not the definition of a dominating Philip> set. Dominating set is a precise term that's been used for Philip> decades in graph algorithms. It helps to not try to redefine Philip> such terms, as all it does is lead to confusion. Philip> Here's the wikipedia page for dominating set: Philip> http://en.wikipedia.org/wiki/Dominating_set So my examples are correct interpretations of Pascal's definition, but what we've defined does not go by that term. :-) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Wed Nov 18 14:11:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A273A6A03 for ; Wed, 18 Nov 2009 14:11:16 -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 Glc+4agPLtqz for ; Wed, 18 Nov 2009 14:11:11 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E97773A68E1 for ; Wed, 18 Nov 2009 14:11:09 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NAsjy-00006V-Kp; Wed, 18 Nov 2009 14:11:08 -0800 Message-Id: <75896ABB-A87D-440C-92FB-E66E3AD2B326@cs.stanford.edu> From: Philip Levis To: Michael Richardson In-Reply-To: <8390.1258582087@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 14:11:05 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <5016.1258569605@marajade.sandelman.ca> <645DB8EE-221C-43C7-BE9A-57659504301B@cs.stanford.edu> <8390.1258582087@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Nov 2009 22:11:16 -0000 On Nov 18, 2009, at 2:08 PM, Michael Richardson wrote: > >>>>>> "Philip" == Philip Levis writes: >>>>>>>> "Pascal" == Pascal Thubert <(pthubert)" >>>>>>>> > writes: > > Pascal> A dominating set is a connected set of routers that enables > Pascal> connectivity for all, that is all nodes in the network is > Pascal> connected to at least one member of the dominating set. > >>> So, in a straight tree arrangement, the dominating set is the >>> non-leaf nodes. In a linear arrangement, the dominating set is >>> all the nodes, except for the last one. Is this correct? > > Philip> No. Unfortunately, that's not the definition of a > dominating > Philip> set. Dominating set is a precise term that's been used for > Philip> decades in graph algorithms. It helps to not try to > redefine > Philip> such terms, as all it does is lead to confusion. > > Philip> Here's the wikipedia page for dominating set: > > Philip> http://en.wikipedia.org/wiki/Dominating_set > > So my examples are correct interpretations of Pascal's definition, > but > what we've defined does not go by that term. :-) Yes. :) What Pascal defined is called a "connected dominating set." Phil From j.schoenwaelder@jacobs-university.de Wed Nov 18 15:58:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2474D3A6B17; Wed, 18 Nov 2009 15:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4PDO+jXl2jA; Wed, 18 Nov 2009 15:58:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CCA773A69B8; Wed, 18 Nov 2009 15:58:27 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68044C0031; Thu, 19 Nov 2009 00:58:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JqwdzLmlVIDF; Thu, 19 Nov 2009 00:58:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26303C002B; Thu, 19 Nov 2009 00:58:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB5CDE2A42D; Thu, 19 Nov 2009 00:58:22 +0100 (CET) Date: Thu, 19 Nov 2009 00:58:22 +0100 From: Juergen Schoenwaelder To: Ulrich Herberg Message-ID: <20091118235822.GB7886@elstar.local> Mail-Followup-To: Ulrich Herberg , 6lowpan <6lowpan@ietf.org>, "manet@ietf.org" , "roll@ietf.org" References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "manet@ietf.org" , 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" Subject: Re: [Roll] [6lowpan] SNMP optimizations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:58:29 -0000 On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote: [... we should restrict this to one mailing list...] > However, it is unclear whether the code footprint of SNMP > implementations can fit into the memory of small devices. From > discussions with several persons from the MANET WG, I conclude that > for MANET the same problem exists. (and I think for ROLL, too?) > > I have several questions that came to my mind about this topic: > > - First of all, to which WG does this issue belong to? Or is it -- as > I suppose -- a common problem for the three working groups addressed > in this mail? I don't know. > - Is this really an issue? Are there implementations of SNMP (maybe > not open-source) that can be run on very small devices such as > considered in 6lowpan/ROLL/MANET? Is there any experimental (or > theoretical) analysis whether SNMP (or any other standardized > management protocol) can run on these devices? The question is under specified. What is a "very small device" and how much can a "very small device" devote to SNMP? And what is SNMP? The SNMPv3 specs are pretty modular. One of the more important questions is how you deal with security - the security code has the potential to be bigger than the rest of the SNMP engine. And it boils down to the question of how many MIB objects you support and to what extend you hardwire things. Remember that SNMP is a child of the late 80s and early versions were sometimes embedded into devices that could not afford TCP. Of course, the 80s version of SNMP did not care much about security... > - If SNMP cannot be used for small devices, how can we manage and > monitor these devices then? (e.g. using proxies, different message > formats such as proposed in 6lowapp, etc.). Do we need a different > lightweight protocol for management? Again, the big question is how to deal with the security aspect. SNMP originally was lightweight because there was no security. It took the IETF many years to find a workable security solution and even today people are working on utilizing transport layer security protocols within SNMP (see ISMS working group). > - Can we provide SNMP not only on a single device, but for a whole > network? That might need an aggregator device that runs full SNMP and > collects the data from the low power devices. This would imply to > monitor statistics of a whole network (e.g. number of links, average > throughput, average path-length, etc.) Sure, there are ways of doing this. For read-only objects, this is relatively easy - it can get a bit messy if you have read-write objects. Whether this direction is worthwhile to explore depends on how you solve the security issues and whether a dependency on a "gateway" is desirable in the first place. > - What kind of objects should be provided in a MIB running on a > MANET/6lowpan/ROLL device? This might be specific to the routing > protocol, but there can be commonalities. In general, the IETF tends to break MIB modules down along protocol functions. Following this approach, a ROLL MIB module would report data about the ROLL routing protocol. A 6LoWPAN MIB would report data about the 6LoWPAN layer, that is for example the list of supported 6LoWPAN protocol features and counters for 6LoWPAN processing failures (e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues. I would hope that some IPv6 MIB objects apply as well and then there should ideally be an IEEE 802.15.4 MIB module for this particular radio technology. I do not think there is much overlap if things get structured well. This, however, might be difficult to achieve if work is spread over several WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pthubert@cisco.com Wed Nov 18 23:50:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3483A6A3B for ; Wed, 18 Nov 2009 23:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fy2B+wS52qc for ; Wed, 18 Nov 2009 23:50:42 -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 88FF23A6A4D for ; Wed, 18 Nov 2009 23:50:41 -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: AjoAADuHBEuQ/uCWe2dsb2JhbACCJCyZMgEBCwskBqIzl3aEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208,217";a="54721140" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 07:50:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ7oc11028472 for ; Thu, 19 Nov 2009 07:50:38 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 08:50:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA68EC.FBEAAE64" Date: Thu, 19 Nov 2009 08:50:34 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAAC5E7@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Role of the OF Thread-Index: AcpoYywFgAAjkqI7RxOmOaBQ0QKSNAACmnnw References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "ROLL WG" X-OriginalArrivalTime: 19 Nov 2009 07:50:38.0283 (UTC) FILETIME=[FBFEC9B0:01CA68EC] Subject: Re: [Roll] Role of the OF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 07:50:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA68EC.FBEAAE64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien: =20 The OF selects the ordered list, not just the best. Some pearl of OCP awareness might also influence the packet forwarding time to use that list. =20 The text for OCP0 will be separated but the text about OCPs in general will stay. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: mercredi 18 novembre 2009 16:24 To: ROLL WG Subject: [Roll] Role of the OF =20 Hi all, =20 for me an OF is a logic used to compare parents, i.e. from 2 parents A, A a is better than B. This can be used for a full sort (from a list of x parents, order them) or a best paret election (from a list of x parents, which is the best) an OF should not know what RPL states mean (preferred or backup has no meaning for an OF).=20 In short the OF is equivalent to the > sign, but for parents=20 =20 Is this correct? If yes the text in the OF0 description should not have any reference to "prefered/backup..." =20 Best, Julien ------_=_NextPart_001_01CA68EC.FBEAAE64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien:

 

The OF selects the ordered list, not just the best. Some = pearl of OCP awareness might also influence the packet forwarding time to use = that list.

 

The text for OCP0 will be separated but the text about = OCPs in general will stay.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: mercredi 18 novembre 2009 16:24
To: ROLL WG
Subject: [Roll] Role of the OF

 

Hi all,

 

for me an OF is a logic used to compare parents, i.e. from 2 parents A, A a = is better than B. This can be used for a full sort (from a list of x = parents, order them) or a best paret election (from a list of x parents, which is = the best)

an OF should not know what RPL states mean (preferred or backup has no = meaning for an OF).

In short the OF is equivalent to the > sign, but for = parents 

 

Is this correct? If yes the text in the OF0 description should not have any reference to "prefered/backup..."

 

Best,<= o:p>

Julien=

------_=_NextPart_001_01CA68EC.FBEAAE64-- From jvasseur@cisco.com Thu Nov 19 00:22:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0373A6814 for ; Thu, 19 Nov 2009 00:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.894 X-Spam-Level: X-Spam-Status: No, score=-7.894 tagged_above=-999 required=5 tests=[AWL=-1.295, 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 5tCpY+3POgp1 for ; Thu, 19 Nov 2009 00:22:41 -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 CDA203A63EB for ; Thu, 19 Nov 2009 00:22:41 -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: ApoEAG+PBEurRN+J/2dsb2JhbAC+Uok8jjyEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="51480814" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 08:22:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8MdtQ012551; Thu, 19 Nov 2009 08:22:39 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:22:38 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:22:38 +0100 Message-Id: From: JP Vasseur To: Michael Richardson In-Reply-To: <14800.1258168139@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:22:37 +0100 References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com> <4AFE0F21.6080304@acm.org> <14800.1258168139@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:22:38.0618 (UTC) FILETIME=[749AA7A0:01CA68F1] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.004 X-TM-AS-Result: No--31.827400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:22:42 -0000 On Nov 14, 2009, at 4:08 AM, Michael Richardson wrote: > >>>>>> "Tim" == Tim Winter writes: > Tim> My opinion is for Option 1. I think that the applicability > Tim> statements are the right place to start pinning down > Tim> interoperability w.r.t. OFs - as appropriate to each > Tim> application space. This may also include interoperability > Tim> between application spaces. > > I'm fine with that. The applicability statements will be the main > anchor > into the standard, that's fine. My concern is that it appeared that > some wanted to leave to do other industry "fora" to declare. As > long as > there is an IETF standards track document that says what is what, then > I'm happy. Excellent. Issue resolved. Just note that applicability statements are part of our charter and will be informational. Thanks. JP. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 00:38:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DDF3A693E for ; Thu, 19 Nov 2009 00:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.57 X-Spam-Level: X-Spam-Status: No, score=-9.57 tagged_above=-999 required=5 tests=[AWL=1.029, 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 8n7BbnhZJQ97 for ; Thu, 19 Nov 2009 00:38: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 BFDEF3A63EB for ; Thu, 19 Nov 2009 00:38:33 -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: AjQAAC+TBEuQ/uCWe2dsb2JhbACcAgEBCwskBqIaiTyOOoQ7BIFv X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54725632" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 08:38:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8cU8d010613; Thu, 19 Nov 2009 08:38:30 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:38:30 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:38:30 +0100 Message-Id: From: JP Vasseur To: Michael Richardson In-Reply-To: <20924.1258401002@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:38:29 +0100 References: <20924.1258401002@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:38:30.0437 (UTC) FILETIME=[ABEEB550:01CA68F3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.004 X-TM-AS-Result: No--35.132600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:38:35 -0000 On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Jerald" == Jerald P Martocci writes: > Jerald> I agree with Julien that we need a DIO solicitation message > Jerald> (i.e. DIS) since as he says a packet can't wait around for > Jerald> hours waiting for a new DAG parent. I buy that and agree > Jerald> with it. However, I am a bit confused why a multicast DIS > Jerald> should trigger a multicast DIO. This seems to simply add > Jerald> unnecessary packets onto the network. > > I am reacting to the last sentence. > I'd have thought that multicast avoids unncesary packets!!!! > So perhaps we are not talking about the same thing? > > Maybe we need better terminology. > I think that there are three kinds of transmission: > a) unicast > b) link-level multicast > c) subnet-level multicast > On ethernet, (b) and (c) are the same thing. > Just bear in mind that we always refer to IP multicast, since we are not link layer specific. > On 6lowpan-type networks, I think (b) is what happens when you > transmit to the nodes that can hear you, and (c) is what you do via a > whiteboard or multicast relay. > > (Maybe there are accepted terms for this, of which I am ignorant) > > Only transmissions of type (c) cause more packets on the wire. > > Transmissions of type (b) would save packets, because one message > arrives at many receivers at the same time. Maybe (b) causes > receivers > that would otherwise have been happy to sleep (doze?) to wake up. > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH > LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL > IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s > eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp > U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG > VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg== > =MCIA > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 00:43:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4022C3A6A6E for ; Thu, 19 Nov 2009 00:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.776 X-Spam-Level: X-Spam-Status: No, score=-9.776 tagged_above=-999 required=5 tests=[AWL=0.823, 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 aWkNAXdJNyHf for ; Thu, 19 Nov 2009 00:43:47 -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 0A5B93A6858 for ; Thu, 19 Nov 2009 00:43:46 -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: AjQAAFuUBEuQ/uCWe2dsb2JhbACcAgEBCwskBqIDl3aEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54726257" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 08:43:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8hhGm012324; Thu, 19 Nov 2009 08:43:44 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:43:43 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:43:43 +0100 Message-Id: <11D2A45B-E85F-4847-8334-8B7C7344EE5D@cisco.com> From: JP Vasseur To: Joakim Eriksson In-Reply-To: <4B02BF47.9030203@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:43:42 +0100 References: <9186.1258470743@marajade.sandelman.ca> <4B02BF47.9030203@sics.se> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:43:43.0412 (UTC) FILETIME=[667AE740:01CA68F4] Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:43:48 -0000 On Nov 17, 2009, at 4:20 PM, Joakim Eriksson wrote: > On the other hand it might be possible to do redundancy-count of > the multi-cast DIOs for all nodes in range and thereby get lower > likelihood of sending a DIO when the trickle timer triggers next > time!? It is a possible approach (implemented actually on several non IP systems), but as pointed out by Jerry the node needs to process the multicast DIO, keep track of who also sent one, reset timers, etc ... which cost in term of energy. > > > Best regards, > -- Joakim Eriksson, SICS > > Michael Richardson skrev: >>>>>>> "Jerald" == Jerald P Martocci >>>>>>> writes: >> Jerald> Yes you're right, whether the responses to a DIS are >> Jerald> multicast or unicast, the packet count is the same. >> Jerald> However, if the responses are multicasts (rather than >> Jerald> unicasts) then other nodes are necessarily interpreting >> Jerald> packets that are really not destined to them. I would >> Jerald> prefer the responses to a multicast DIS be a series of >> Jerald> unicast DIOs. >> So, what concerns you is the wake-up cost of the extra DIOs. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 00:48:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E553A68B7 for ; Thu, 19 Nov 2009 00:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.913 X-Spam-Level: X-Spam-Status: No, score=-7.913 tagged_above=-999 required=5 tests=[AWL=-1.314, 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 T+BmHEVcODh0 for ; Thu, 19 Nov 2009 00:48:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0ED4B3A68AE for ; Thu, 19 Nov 2009 00:48:08 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEqVBEtAZnwM/2dsb2JhbAC+Upd2hDsE X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="68846231" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2009 08:48:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8m66V007828; Thu, 19 Nov 2009 08:48:06 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:48:05 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:48:04 +0100 Message-Id: <2BC52EF6-1325-46B5-9988-477C09F60D03@cisco.com> From: JP Vasseur To: Jonathan Hui In-Reply-To: <75B9942C-E153-4849-87BD-F4E95DF891E4@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:48:04 +0100 References: <75B9942C-E153-4849-87BD-F4E95DF891E4@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:48:05.0148 (UTC) FILETIME=[027CA5C0:01CA68F5] Cc: ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:48:10 -0000 On Nov 17, 2009, at 6:14 PM, Jonathan Hui wrote: > > On Nov 17, 2009, at 9:05 AM, Jerald.P.Martocci@jci.com wrote: > >> Not sure I buy that. If I'm not satisfied with my routes, why >> wouldn't I take the lead and issue a DIS as needed? > > In most cases, picking routes is based on relative terms (e.g. I > chose route A because it is better than B, not because B is > unsatisfactory). While I may have a working route, how would I > discover a much better route if one exists? > >> It seems to me we should have either a time based algorithm or an >> event based algorithm, but not both. I could see having both if >> the time based algorithm was used mainly as a heartbeat to assure >> that the links are still in place. However, if this was the >> reason, the periodicity of the periodic DIOs would be in minutes no >> milliseconds. > > Well, "minutes" in some cases is not good enough. If routes are > inconsistent or you need to discover a new one, waiting "minutes" to > discover a new route may not be acceptable. But sending DIOs on the > order of "seconds" is also not acceptable in those situations. > Hence the need for an adaptive timer. Note that, for the most part, > the timer is periodic - but that you can speed it up in certain > situations. > > This tradeoff between fast and slow periods is nothing new. Many IP- > based protocols operate by having a short period when reacting to > some event and a long period to maintain the network. Indeed, note that this is why (on a different subject) global repair is also a reoptimization mechanism. In many IP protocols you do use indeed fast mechanism for immediate actions combined with longer term strategies for reoptimization. Repair is one of the notorious examples. > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 00:52:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C6D3A686E for ; Thu, 19 Nov 2009 00:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.726 X-Spam-Level: X-Spam-Status: No, score=-7.726 tagged_above=-999 required=5 tests=[AWL=-1.127, 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 NPjTGlzhjgJh for ; Thu, 19 Nov 2009 00:52:59 -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 233693A6838 for ; Thu, 19 Nov 2009 00:52:59 -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: ApoEAHeWBEurRN+J/2dsb2JhbAC+UZd3hDsEgW8 X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="51491631" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 08:52:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8qjnt001101; Thu, 19 Nov 2009 08:52:56 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:52:55 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:52:54 +0100 Message-Id: <9980C241-5196-4642-B33F-7D3E054694A4@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABA8F@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:52:54 +0100 References: <997EF847-B942-48A2-8A2E-E23613225D21@cisco.com><5896.1258078243@marajade.sandelman.ca><87r5s24fh9.fsf@kelsey-ws.hq.ember.com><9328.1258127853@marajade.sandelman.ca> <87pr7m47jn.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5DAABA8F@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:52:54.0848 (UTC) FILETIME=[AF295C00:01CA68F5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.004 X-TM-AS-Result: No--13.428900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] Closing on Ticket #10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:52:59 -0000 On Nov 17, 2009, at 12:38 PM, Pascal Thubert (pthubert) wrote: > Hi Richard > >> My hope is that we will need no more than one or two OFxs. >> The reason we need to be flexible now is not that we are >> likely to need many of them, but that we don't know which >> ones are the right ones. > > We disagree on this. There might be one or 2 OCPs coming out with for > RPL for this round of specification, OK. Probably more if we really > need > to meet all the requirement drafts. But there could be many different > sorts of deployments that we do not cover here, and thus many OCPs, > some > defined in some future at the IETF, some designed by other SDOs like > of > ETSI, ISA or IEC, and some proprietary value-added proposals. As > long as > the OCP conform the general rules in RPL, that should be fine, and the > generic part of the wheel does not have to be reinvented each time. > > My hope when I designed the plugins in MANEMO was to build a generic > DV > platform that could be instantiated for many specific environments, > just > like SIP can. > RPL inherited the concept, though it lost/barred the capability to mix > OCPs and degrade to OCP0 at the edges. Yes, pretty old concept used for many protocols indeed. Issue is closed. JP. > Still, the loop avoidance remains totally generic, based on an > abstract > rank, so RPL retains the capability to be instantiated in many > fashions. > I think that is a powerful idea. > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 00:57:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC823A68AE for ; Thu, 19 Nov 2009 00:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[AWL=1.014, 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 MTDWkU8FrVVi for ; Thu, 19 Nov 2009 00:57:24 -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 7C7823A67EC for ; Thu, 19 Nov 2009 00:57:23 -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: AjQAALeWBEuQ/uCWe2dsb2JhbACcAwEBCwskBqIMiTyOO4Q7BIFv X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54727258" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 08:57:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ8vKc5015173; Thu, 19 Nov 2009 08:57:20 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:57:20 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:57:19 +0100 Message-Id: <6E95627F-0352-43EF-90BD-40EC71CE4A0D@cisco.com> From: JP Vasseur To: Roger Alexander In-Reply-To: <6048261E-D42B-4366-A0CC-EBD56598020A@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 09:57:18 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <6048261E-D42B-4366-A0CC-EBD56598020A@ekasystems.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 08:57:19.0959 (UTC) FILETIME=[4D2E1670:01CA68F6] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.004 X-TM-AS-Result: No--33.255000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "roll@ietf.org" Subject: Re: [Roll] Something to ADD X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 08:57:25 -0000 Hi Roger, The spec is exactly along the lines of what you wrote: intermediate nodes can store routes of course, and RPL does not mandate to store route at the DAG only. Some networks will exclusively use hop by hop routing with route storage at each hop, others won't, others will have a mixed of nodes and RPL does support them all. Cheers. JP. On Nov 17, 2009, at 12:42 AM, Roger Alexander wrote: > Sorry for the earlier transmission of the incomplete email...(moving > vehicle)...final thoughts completed below. > > Thanks. > > Roger > > On Nov 16, 2009, at 3:33 PM, Roger Alexander > wrote: > >> >> >> On Nov 13, 2009, at 6:44 PM, Michael Richardson >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>>>>>>> "Richard" == Richard Kelsey writes: >>> mcr> I guess it might be enough to have a bit that gets turned by >>> the >>> mcr> first non-root node that stores DAOs. >>> >>> Richard> I think you need two bits. One is turned on by the root >>> if >>> Richard> it stores DAOs and the other is turned on by any >>> Richard> intermediate node that stores them. >>> >>> I didn't realize that the root could *not* store DAOs...! >>> I'm trying to imagine how that works. >>> I can perhaps see how this might be the case with an ungrounded DAG, >>> where some random DAO-incapable node decides to become the new root. >>> >>> mcr> If I understand correctly, if the intermediate nodes do not >>> store >>> mcr> DAOs, then they won't have a routing table to other peers, >>> so p2p >>> mcr> traffic will have to travel all the way up to the root and out >>> mcr> again. >>> >>> Richard> Yes. On the other hand, the DAG formation mechanism works >>> Richard> to maximize downward fanout, which in turn maximizes the >>> Richard> number of P2P routes that go through the root even if all >>> Richard> nodes store DAOs. For example, if the root has N children >>> Richard> with roughly equal subgraphs, then each node can reach >>> only >>> Richard> 1/N of the network without through the root. >>> >>> Yeah, I can see how a relatively uniformly distributed DAG would >>> have >>> this property. I can also see where this would not be the case, >>> such >>> as a long linear network, such as a series of lampposts or utility >>> poles >>> along a rural road... where the grounded node is at one of the road. >>> >>>>> It seemed to me like a compromise that the root had to be able to >>>>> create source routes so that weaker intermediate nodes could >>>>> avoid storing the DAOs. That this wasn't the ideal situation, but >>>>> was a compromise. >>>>> >>>>> What happens if we insist all nodes store DAOs? (is it simpler?) >>> >>> Richard> That uses too much RAM for us to require it. >>> >>> Yes, I understand why we can not do it. >>> >>> You see, I'm asking what the real tradeoff is about this. >>> If ram and CPU was free, but network bandwidth was not, would we >>> decide to force all nodes to store DAOs? >>> JP has suggested that it helps. >> >> It does help when intermediate nodes store DAOs since DAO >> information should only need to be passed further up towards the >> root when the info represents a change in outward (to leaves) >> connectivity. That is, if a node changes parent and reattaches to a >> new branch that information only needs to travel inward towards the >> root to the point in the tree that held an outward table containing >> the given node. Granted it may be in some cases that point is at >> the root itself. However, in the absence of DAO storage at >> intermediate nodes a node's change of parent must always be >> conveyed all the way to the root so that outward connectivity (via >> source routing) can be supported. For nodes not maintaining state, >> the change of parent information must always flow back to the root >> or otherwise to the first DAO storing node (which may then need to >> update it's parent(s) if the stateless node was not previuosly >> reachable via the stateful node). >>> >>> I can see with a linear network where there is traffic up and down >>> the >>> line, that without DAO storing nodes in the middle, traffic has to >>> go >>> all the way to the end and back. >>> >>>>> What happens if we insist that no nodes store DAOs? (is it >>>>> simpler?) >>> >>> Richard> Do you mean no nodes at all, or no nodes other than the >>> Richard> root? >>> >>> No nodes other than the root.... >>> Nothing would work if nobody knew the routes, right. >>> >>> Richard> If only the root stores DAOs, then most of the P2P traffic >>> Richard> will go through the root. As I said above, this is often >>> Richard> the case even if all node's store DAOs. I think this >>> would >>> Richard> be OK. Even without intermediate DAO storage, routing >>> Richard> packets directly to neighbors will reduce the P2P messages >>> Richard> traveling through the root. Devices that require more >>> Richard> bandwidth (in or out) can become roots of their own DAGs, >>> Richard> as long as the number of such devices is limited. >>> >>> To summarize, forbidding intermediate nodes to store DAOs: >>> - causes a loss in quality for p2p traffic for some topologies, >> >> It also creates additional routing traffic towards the root which >> is needed so that the reverse path information from the root to the >> node can be conveyed to the root for subsequent outward routing. >> >>> but for many topologies has a neglible effect >>> - causes no change for m2p >>> - massively reduces traffic when there is a new parent chosen >>> - simplifies the protocol (no need to record who records DAOs) >> >> Not clear why there is a need to know who records DAOs. In response >> to a new child a parent that does maintain state will add itself to >> the path information from the child and pass that information to >> it's parent. That information will pass inward towards the root >> until a node is encountered that can store the path information and >> previously supported connectivity to the node at the same cost. >> >>> - removes the need for code to do different things depending >>> upon whether there are DAO storing nodes above, when changing >>> parents. >> >> The nodes that do not store DAOs can have a consistent behavior >> while those that do can similarly also be consistent. >>> >>> Or to be it another way, capable nodes that have the ram to store >>> DAOs >>> are causing load on less capable nodes. They aren't being very >>> helpful. >>> > It seems that the intermediate nodes that do maintain DAOs can limit > overhead by avoiding the need for all changes in node connectivity > to the DAG from having to always go all the way to the root to > provide for maintaining an outward path. Furthermore if only the > root stores DAOs the RPL reduces to a source routing protocol which > may be an issue. >>> - -- >>> ] He who is tired of Weird Al is tired of life! | >>> firewalls [ >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON | >>> net architect[ >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | >>> device driver[ >>> Kyoto Plus: watch the video >> > >>> then sign the petition. >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> Comment: Finger me for keys >>> >>> iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF >>> AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl >>> p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 >>> WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko >>> xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF >>> YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg== >>> =slpm >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 01:02:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C79D3A6899 for ; Thu, 19 Nov 2009 01:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CrJjjqTYasJi for ; Thu, 19 Nov 2009 01:02:14 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8E3C93A6858 for ; Thu, 19 Nov 2009 01:02:14 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABuYBEurRN+J/2dsb2JhbACCJCy7bpd4giyCDwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208,217";a="106524881" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Nov 2009 09:02:12 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ92BPK006283 for ; Thu, 19 Nov 2009 09:02:12 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 04:02:11 -0500 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 04:02:10 -0500 Message-Id: <699F0082-EC8C-4509-9C8A-19C814436B20@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-248--1006228131 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 10:02:09 +0100 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 09:02:11.0075 (UTC) FILETIME=[FAB2DD30:01CA68F6] Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 09:02:15 -0000 --Apple-Mail-248--1006228131 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Pascal, On Nov 17, 2009, at 8:13 AM, Pascal Thubert (pthubert) wrote: > Hi: > > The current RPL draft uses trickle to address density. Trickle has a =20= > number of fine properties to throttle the control when things are =20 > stable. > Still, when an accident occurs, like a parent high in the DAG =20 > degrades its rank, possibly most of the nodes in the whole network =20 > will have to reassess their rank and reset their trickle timer. > My understanding of that process is that it can yield quite a bit =20 > of activity, that grows with the number of nodes acting as routers. > > What I think is that even if we have trickle, we should be =20 > considering some control on the density of nodes that act as a =20 > router. To address that, there=92s already ample work and large WSN =20= > deployments that leverage the concept of dominating set. > A dominating set is a connected set of routers that enables =20 > connectivity for all, that is all nodes in the network is connected =20= > to at least one member of the dominating set. > > Because we have trickle, such a set does not need to be shrink to =20 > minimal/optimal. In fact, we=92d want that each node in the network =20= > sees at least 2 members of the dominating set. > > Can that be achieved simply? Possibly. > > Each time a new sequence is spread, nodes are entitled to reassess =20 > their need to be a router. When the sequence spreads, a form of =20 > trickle could be used to decide Not TO advertise self as a router =20 > and act as a host for the new sequence. > Like if enough neighbor routers advertise the new sequence before T =20= > elapse, then there might be no need for self to act as a router. > > Thoughts? I do see your reasoning and that notion is indeed used in other =20 protocols but the issue here is that you need to determined who you =20 put in the set since they need to have connectivity. If you use C and =20= set it low enough, isn't it sufficient ? Cheers. JP. > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-248--1006228131 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal,

On = Nov 17, 2009, at 8:13 AM, Pascal Thubert (pthubert) wrote:

Hi:
The current RPL draft uses trickle = to address density. Trickle has a number of fine properties to throttle = the control when things are stable.
 
Because we have trickle, such a set = does not need to be  shrink to minimal/optimal. In fact, we=92d = want that each node in the network sees at least 2 members of the = dominating set.
 
Each time a new sequence is spread, = nodes are entitled to reassess their need to be a router. When the = sequence spreads, a form of trickle could be used to decide Not TO = advertise self as a router and act as a host for the new = sequence.
Like if enough neighbor routers = advertise the new sequence before T elapse, then there might be no need = for self to act as a router.
Thoughts?
 
; Thu, 19 Nov 2009 10:20:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:19:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6901.D7F3EB53" Date: Thu, 19 Nov 2009 11:19:48 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DAAC710@XMB-AMS-107.cisco.com> In-Reply-To: <699F0082-EC8C-4509-9C8A-19C814436B20@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] do we need a dominating set? Thread-Index: Acpo9vwRfRB5a5B/RPm+pxTg6pEJ3gAB29kQ References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <699F0082-EC8C-4509-9C8A-19C814436B20@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 19 Nov 2009 10:19:57.0403 (UTC) FILETIME=[D80C02B0:01CA6901] Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 10:20:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6901.D7F3EB53 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP: =20 What we end up with at the moment is too many routers and then blind suppression of routing updates.=20 =20 I'd rather have less routers and less-to-no suppression. IOW suppress the role of routers as opposed to the control messages.=20 Same "trickle" thinking though, but applied on a different level (router role as opposed to control message). =20 Loss of control messages is the source of all evils in DV. That's what cause count to infinity in RIP in the first place.=20 The way we use it, C is equivalent to forcing control packet loss. =20 CTP copes by having reactive detection. Detection causes the message to be resent so at the end of the day it is not saved. In the meantime, convergence was delayed and risk of CTI increased. =20 In the meantime, packets are lost which might be acceptable in some environment and not in other. Same reasoning as poisoning. =20 The thing that helps a bit is that amongst the many routers that are not needed as routers, a good number is actually not used as routers, so no detection, and thus no retrigger. But:=20 * Those guys still issue useless DIOs * We end up with more routers and more fine grained paths than necessary * Those paths all need to be maintained thus more control messages etc... =20 I'm advocating that the graph should have less (and larger) branches, and that those branches could be reevaluated at each new sequence, for instance to adapt to the battery level of the active routers. That's good for control overhead and that's good for multicast. =20 I'm claiming that we can do that using trickle, for all the great properties that Phil has listed in many places. Once we are at that we can discuss the algorithm but there's enough info in this thread for people to figure out how. =20 I still see the value of trickling the control packets because of the exponential backoff piece but wish to limit the suppression of routing information as much as possible. =20 Pascal From: JP Vasseur (jvasseur)=20 Sent: jeudi 19 novembre 2009 10:02 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? =20 Hi Pascal, =20 On Nov 17, 2009, at 8:13 AM, Pascal Thubert (pthubert) wrote: Hi: =20 The current RPL draft uses trickle to address density. Trickle has a number of fine properties to throttle the control when things are stable. Still, when an accident occurs, like a parent high in the DAG degrades its rank, possibly most of the nodes in the whole network will have to reassess their rank and reset their trickle timer. My understanding of that process is that it can yield quite a bit of activity, that grows with the number of nodes acting as routers. =20 What I think is that even if we have trickle, we should be considering some control on the density of nodes that act as a router. To address that, there's already ample work and large WSN deployments that leverage the concept of dominating set. A dominating set is a connected set of routers that enables connectivity for all, that is all nodes in the network is connected to at least one member of the dominating set. =20 Because we have trickle, such a set does not need to be shrink to minimal/optimal. In fact, we'd want that each node in the network sees at least 2 members of the dominating set. =20 Can that be achieved simply? Possibly. =20 Each time a new sequence is spread, nodes are entitled to reassess their need to be a router. When the sequence spreads, a form of trickle could be used to decide Not TO advertise self as a router and act as a host for the new sequence. Like if enough neighbor routers advertise the new sequence before T elapse, then there might be no need for self to act as a router. =20 Thoughts? =20 I do see your reasoning and that notion is indeed used in other protocols but the issue here is that you need to determined who you put in the set since they need to have connectivity. If you use C and set it low enough, isn't it sufficient ? =20 Cheers. =20 JP. =20 Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA6901.D7F3EB53 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP:

 

What we end up with at the moment is too many routers and = then blind suppression of routing updates.

 

I’d rather have less routers and less-to-no = suppression. IOW suppress the role of routers as opposed to the control messages. =

Same “trickle” thinking though, but applied = on a different level (router role as opposed to control = message).

 

Loss of control messages is the source of all evils in = DV. That’s what cause count to infinity in RIP in the first place. =

The way we use it, C is equivalent to forcing control = packet loss.

 

CTP copes by having reactive detection. Detection causes = the message to be resent so at the end of the day it is not saved. In the = meantime, convergence was delayed and risk of CTI increased.

 

In the meantime, packets are lost which might be = acceptable in some environment and not in other. Same reasoning as = poisoning.

 

The thing that helps a bit is that amongst the many = routers that are not needed as routers, a good number is actually not used as = routers, so no detection, and thus no retrigger.

But:

·         Those guys still issue useless DIOs

·         We end up with more routers and more fine grained paths = than necessary

·         Those paths all need to be maintained thus more control = messages etc…

 

I’m advocating that the graph should have less (and = larger) branches, and that those branches could be reevaluated at each new = sequence, for instance to adapt to the battery level of the active routers. = That’s good for control overhead and that’s good for = multicast.

 

I’m claiming that we can do that using trickle, for = all the great properties that Phil has listed in many places. Once we are at = that we can discuss the algorithm but there’s enough info in this thread = for people to figure out how.

 

I still see the value of trickling the control packets = because of the exponential backoff piece but wish to limit the suppression of = routing information as much as possible.

 

Pascal

From:= JP Vasseur = (jvasseur)
Sent: jeudi 19 novembre 2009 10:02
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] do we need a dominating = set?

 

Hi Pascal,

 

On Nov 17, 2009, at 8:13 AM, Pascal Thubert = (pthubert) wrote:



Hi:

 

The current RPL draft uses trickle to address density. = Trickle has a number of fine properties to throttle the control when things are = stable.

Still, when an accident occurs, like a parent high in the = DAG degrades its rank, possibly most of the nodes in the whole network will = have to reassess their rank and reset their trickle timer.

My understanding of that  process is that it can yield = quite a bit of activity, that grows with the number of nodes acting as = routers.

 

What I think is that even if we have trickle, we should be considering some control on the density of nodes that act as a router. = To address that, there’s already ample work and large WSN deployments = that leverage the concept of dominating set.

 A dominating set is a connected set of routers that = enables connectivity for all, that is all nodes in the network is connected to = at least one member of the dominating set.

 

Because we have trickle, such a set does not need to be  shrink to minimal/optimal. In fact, we’d want that each node = in the network sees at least 2 members of the dominating = set.

 

Can that be achieved simply? = Possibly.

 

Each time a new sequence is spread, nodes are entitled to = reassess their need to be a router. When the sequence spreads, a form of trickle = could be used to decide Not TO advertise self as a router and act as a host = for the new sequence.

Like if enough neighbor routers advertise the new sequence = before T elapse, then there might be no need for self to act as a = router.

 

Thoughts?

 

I do see your reasoning and that notion is indeed = used in other protocols but the issue here is that you need to determined who = you put in the set since they need to have connectivity. If you use C and set it = low enough, isn't it sufficient ?

 

Cheers.

 

JP.



 

Pascal

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

 

------_=_NextPart_001_01CA6901.D7F3EB53-- From jvasseur@cisco.com Thu Nov 19 02:36:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7122828C176 for ; Thu, 19 Nov 2009 02:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.697 X-Spam-Level: X-Spam-Status: No, score=-9.697 tagged_above=-999 required=5 tests=[AWL=0.902, 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 k3-0CYY0ZTrK for ; Thu, 19 Nov 2009 02:36:52 -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 242143A6860 for ; Thu, 19 Nov 2009 02:36:51 -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: AjQAACKuBEuQ/uCWe2dsb2JhbACcBQEBCwskBqExl3mEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54735819" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 10:36:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJAamR4009647; Thu, 19 Nov 2009 10:36:48 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:48 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:47 +0100 Message-Id: <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <874oot3zcf.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:36:47 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 10:36:48.0357 (UTC) FILETIME=[329F5950:01CA6904] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.005 X-TM-AS-Result: No--16.492400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 10:36:53 -0000 On Nov 17, 2009, at 5:12 PM, Richard Kelsey wrote: >> From: Roger Alexander >> Date: Mon, 16 Nov 2009 15:33:33 -0800 >> >> Not clear why there is a need to know who records DAOs. In response >> to >> a new child a parent that does maintain state will add itself to the >> path information from the child and pass that information to it's >> parent. That information will pass inward towards the root until a >> node is encountered that can store the path information and >> previously >> supported connectivity to the node at the same cost. > > The difficulty is that, at present, there is no way of > determining how much information needs to be passed up after > a move. Here is the example I posted earlier. We start > with this, where A is the root: > > A > / \ > B C > | > D > | > E > > Now D moves to C as its parent: > > A > / \ > B C > | > D > | > E > > If only A caches DAO data, then all D needs to do is send a > DAO after the move. A receives it and changes its next hop > for D and E to be C. Well I think that you still need the no-DAO since A may continue to send packets to D via both B and C. > > If B and C both cache DAO data, then D needs to send a > no-DAO before the move, to update B, and both D and E need > to send DAOs after the move, so that C knows that it has > downward paths to both of them. Note that with DAO packing only D will send one DAO for local prefixes and E's prefixes but that's not the topic. > > In the first case a single DAO needs to be sent. In the > second case D has to send two DAOs and the nodes in its > subdag, just E here, each need to send one. If only the > root caches DAOs then the first case always applies. If > other nodes may cache DAOs, then we have to assume that we > are in the second case after every move. Yes but I think that we need no-DAO to avoid nodes upper in the DAG to continue to use an old path anyway and the issues of the number of DAO is IMO larger and packing will sort it out. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 02:36:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558313A6860 for ; Thu, 19 Nov 2009 02:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.788 X-Spam-Level: X-Spam-Status: No, score=-9.788 tagged_above=-999 required=5 tests=[AWL=0.811, 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 SUAGph4SXiWN for ; Thu, 19 Nov 2009 02:36:53 -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 197D028C16E for ; Thu, 19 Nov 2009 02:36:52 -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: AjQAACKuBEuQ/uCWe2dsb2JhbACcBQEBCwskBqExl3mEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54735823" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 10:36:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJAapvk009658; Thu, 19 Nov 2009 10:36:51 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:50 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:50 +0100 Message-Id: From: JP Vasseur To: Jonathan Hui In-Reply-To: <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:36:49 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 10:36:50.0263 (UTC) FILETIME=[33C22E70:01CA6904] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.005 X-TM-AS-Result: No--13.900400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 10:36:54 -0000 On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > > On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote: > >>> From: Roger Alexander >>> Date: Mon, 16 Nov 2009 15:33:33 -0800 >>> >>> Not clear why there is a need to know who records DAOs. In >>> response to >>> a new child a parent that does maintain state will add itself to the >>> path information from the child and pass that information to it's >>> parent. That information will pass inward towards the root until a >>> node is encountered that can store the path information and >>> previously >>> supported connectivity to the node at the same cost. >> > > [nice example of what DAOs need to be sent] > >> In the first case a single DAO needs to be sent. In the >> second case D has to send two DAOs and the nodes in its >> subdag, just E here, each need to send one. If only the >> root caches DAOs then the first case always applies. If >> other nodes may cache DAOs, then we have to assume that we >> are in the second case after every move. > > I was in the process of creating a similar example. All I'll add is > that, intuitively, the more places state gets "replicated" within > the network, the more costly it is to maintain that state and the > more you have to deal with inconsistencies between replicated > instances. Of course, the hope in replicating this routing state is > that it creates shorter paths and ultimately offsets the cost of > maintaining that state. > > I'll have to admit that I'm not yet convinced of the benefits in > storing DAO state as it currently exists in the draft. It seems > like a mediocre attempt to optimize point-to-point routing and > something that folks wanting P2P support aren't satisfied with. If > that is the end-goal, then we should be developing better > mechanisms. For now, we are focusing on one-to-many and many-to- > one. And, I see more benefits to simply maintaining state at the > root. > I do agree with the first statement but not with the second paragraph. I do see several deployment cases where no storing DAO would lead to extremely sub-optimal paths and even more importantly traffic congestion when getting closer to the root of course. This is true with several networks where the amount of P2P traffic may ned up being not so negligible. The beauty with the current spec is that it allows both deployment models. > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 02:37:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDDE28C182 for ; Thu, 19 Nov 2009 02:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=0.738, 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 1TZc9JIFOglA for ; Thu, 19 Nov 2009 02:37:03 -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 B9D8C28C183 for ; Thu, 19 Nov 2009 02:37:00 -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: AjQAACKuBEuQ/uCWe2dsb2JhbACcBQEBCwskBqExl3mEOwSBbw X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54735836" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 10:36:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJAavk5009691; Thu, 19 Nov 2009 10:36:57 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:57 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:36:56 +0100 Message-Id: From: JP Vasseur To: Jonathan Hui In-Reply-To: <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:36:55 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 10:36:56.0670 (UTC) FILETIME=[3793CFE0:01CA6904] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.005 X-TM-AS-Result: No--5.468000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 10:37:03 -0000 On Nov 17, 2009, at 6:56 PM, Jonathan Hui wrote: > > On Nov 17, 2009, at 9:20 AM, Pascal Thubert (pthubert) wrote: > >> When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH >> (source route)), you see the source route RH2/4 grow upon movement >> and >> quickly shrink again as the NINA (DAO) states are reestablished. >> When things are stable you only see as many entries as non DAO >> capable >> nodes along the path. In my case, the source route is done on a MIP/ >> NEMO >> tunnel, so the RH states are stored in eth binding cache on the home >> agent. But we could store that at the root with exactly the same >> process. >> I can demo that next time we meet if you wish. >> >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header >> details the RRH, since there is not LSRR in IPv6. >> >> Note that in our case, the information in the header should be >> locally >> significant, like a label. > > Here lies the disconnect. The real benefit of storing state among > nodes within the network is to reduce the size of the source route > header not some attempt to support point-to-point traffic. If you > buy that, then the mechanism to establish such state could be much > better than what's currently defined in the draft. In particular, > there are some interesting things we could achieve if we start > treating next-hop information using locally significant labels > rather than globally significant IP addresses, as you suggested. > But if done properly, I think we can specify such a mechanism as an > optimization to basic source-route/record-route. I'm with you, well as someone used to work on MPLS, no surprise. But still that does not solve the traffic matrix issue: not storing DAO leads to all traffic transiting via the root, which is not acceptable in many networks. > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 02:42:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1293A6820 for ; Thu, 19 Nov 2009 02:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.922 X-Spam-Level: X-Spam-Status: No, score=-9.922 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIUK1hCBVlwm for ; Thu, 19 Nov 2009 02:42:56 -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 BE4213A6860 for ; Thu, 19 Nov 2009 02:42:55 -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: AjcAAHuwBEuQ/uCWe2dsb2JhbACCIS+ZNwEBCwskBqErl3eEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208,217";a="54736517" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 10:42:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJAglXR011532; Thu, 19 Nov 2009 10:42:47 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:42:46 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:42:45 +0100 Message-Id: <4911BF02-A4D5-4174-B357-8F3874C09421@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAABEDA@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-255--1000192229 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 11:42:45 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABEDA@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 10:42:46.0223 (UTC) FILETIME=[07ED5DF0:01CA6905] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 10:42:58 -0000 --Apple-Mail-255--1000192229 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [snip] > >> If you buy >> that, then the mechanism to establish such state could be much better >> than what's currently defined in the draft. In particular, there are >> some interesting things we could achieve if we start treating next- >> hop >> information using locally significant labels rather than globally >> significant IP addresses, as you suggested. But if done properly, I >> think we can specify such a mechanism as an optimization to basic >> source-route/record-route. > > Looks good. The main consequence that I see at first glance is that > The DAO should be sent to only one parent, because maintaining > multiple > Source route path down the DAG makes little sense for reasons > discussed > Earlier in this list (combinatory explosion, no end to end retries...) > > Would you agree on that? > I do. Fairly simple, already supported. If the node cannot store the route then you go back to the root but the support of DAO must stay in the base spec for all networks that need it to (1) avoid too much traffic as you get closer to the root and (2) where the current P2P mechanisms provide a good enough path. JP. > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-255--1000192229 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable [snip]


=             &n= bsp;           &nbs= p;            =             &n= bsp;      If you = buy
that, then the mechanism = to establish such state could be much better
than what's currently defined in the draft.  In = particular, there are
some = interesting things we could achieve if we start treating = next-hop
information using = locally significant labels rather than = globally
significant IP = addresses, as you suggested.  But if done properly, = I
think we can specify such a = mechanism as an optimization to basic
source-route/record-route.

Looks good. = The main consequence that I see at first glance is that
The DAO = should be sent to only one parent, because maintaining = multiple
Source route path down the DAG makes little sense for = reasons discussed
Earlier in this list (combinatory explosion, no end = to end retries...)

Would you agree on = that?


I do. Fairly simple, = already supported. If the node cannot store the route then you go back = to the root 
but the support of DAO must stay in the base = spec for all networks that need it to (1) avoid too = much
traffic as you get closer to the root and (2) where the = current P2P mechanisms provide a good = enough
path.

JP.

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

= --Apple-Mail-255--1000192229-- From richard.kelsey@ember.com Thu Nov 19 03:05:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0A73A69CB for ; Thu, 19 Nov 2009 03:05:05 -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 UiIhBxFnAXUH for ; Thu, 19 Nov 2009 03:05:04 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id AA25D3A6820 for ; Thu, 19 Nov 2009 03:05:03 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 06:06:27 -0500 Date: Thu, 19 Nov 2009 06:01:14 -0500 Message-Id: <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Thu, 19 Nov 2009 11:36:49 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> X-OriginalArrivalTime: 19 Nov 2009 11:06:27.0046 (UTC) FILETIME=[56CDC060:01CA6908] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 11:05:05 -0000 > From: JP Vasseur > Date: Thu, 19 Nov 2009 11:36:49 +0100 > > On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > > > I'll have to admit that I'm not yet convinced of the benefits in > > storing DAO state as it currently exists in the draft. [...] > > > I do agree with the first statement but not with the second paragraph. > I do see several deployment cases where no storing DAO would lead to > extremely sub-optimal paths and even more importantly traffic > congestion when getting closer to the root of course. Can you share these cases with us? I agree with Jonathan that storing DAO states will typically not provide much improvement in P2P routing. > I do see several deployment cases where no storing DAO would lead to > extremely sub-optimal paths and even more importantly traffic > congestion when getting closer to the root of course. This is true > with several networks where the amount of P2P traffic may ned up being > not so negligible. The beauty with the current spec is that it allows > both deployment models. It claims to allow both, but fails to actually do so. That is the point of the example that I gave and the reason I keep going on about this. While the draft says that intermediate nodes can cache DAOs, it doesn't say how those caches are updated after a node changes parents. And however this is done, we need to avoid the cost of sending cache updates in the absense of any actual caches. -Richard Kelsey From richard.kelsey@ember.com Thu Nov 19 03:12:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61F73A681B for ; Thu, 19 Nov 2009 03:12:44 -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 wgiQfCsfh+yn for ; Thu, 19 Nov 2009 03:12:43 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 62E8A3A67FD for ; Thu, 19 Nov 2009 03:12:43 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 06:14:12 -0500 Date: Thu, 19 Nov 2009 06:09:00 -0500 Message-Id: <87iqd6wz3n.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> (message from JP Vasseur on Thu, 19 Nov 2009 11:36:47 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> X-OriginalArrivalTime: 19 Nov 2009 11:14:12.0765 (UTC) FILETIME=[6C64D4D0:01CA6909] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 11:12:44 -0000 > From: JP Vasseur > Date: Thu, 19 Nov 2009 11:36:47 +0100 > > On Nov 17, 2009, at 5:12 PM, Richard Kelsey wrote: > > > The difficulty is that, at present, there is no way of > > determining how much information needs to be passed up after > > a move. Here is the example I posted earlier. We start > > with this, where A is the root: > > > > A > > / \ > > B C > > | > > D > > | > > E > > > > Now D moves to C as its parent: > > > > A > > / \ > > B C > > | > > D > > | > > E > > > > If only A caches DAO data, then all D needs to do is send a > > DAO after the move. A receives it and changes its next hop > > for D and E to be C. > > Well I think that you still need the no-DAO since A may continue to send > packets to D via both B and C. Yes, if DAOs can be sent to multiple parents. No if DAOs are only sent to one parent (because then A will only store the most recently received path to D). > > no-DAO before the move, to update B, and both D and E need > > to send DAOs after the move, so that C knows that it has > > downward paths to both of them. > > Note that with DAO packing only D will send one DAO for local prefixes > and E's prefixes but that's not the topic. No, because D doesn't have a cache. E has to send its prefixes, whether packing is present or not. > > In the first case a single DAO needs to be sent. In the > > second case D has to send two DAOs and the nodes in its > > subdag, just E here, each need to send one. If only the > > root caches DAOs then the first case always applies. If > > other nodes may cache DAOs, then we have to assume that we > > are in the second case after every move. > > Yes but I think that we need no-DAO to avoid nodes upper > in the DAG to continue to use an old path anyway and the > issues of the number of DAO is IMO larger and packing will > sort it out. The issue is only partly the number of DAO. It is also who has to send them. If switching parents requires that every node in the sub-DAG send a DAO, we need to take that cost into account and avoid it when it is possible to do so. DAO packing is not a magic bullet that makes DAOs free. -Richard Kelsey From jvasseur@cisco.com Thu Nov 19 04:19:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9481B3A691B for ; Thu, 19 Nov 2009 04:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.975 X-Spam-Level: X-Spam-Status: No, score=-9.975 tagged_above=-999 required=5 tests=[AWL=0.624, 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 XGHLec2KZRBf for ; Thu, 19 Nov 2009 04:19:01 -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 4A1FE3A6A00 for ; Thu, 19 Nov 2009 04:19:01 -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: AjQAAL7GBEuQ/uCWe2dsb2JhbACcCAEBCwskBqEnl3KEOwQ X-IronPort-AV: E=Sophos;i="4.44,770,1249257600"; d="scan'208";a="54747523" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 12:18:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJCIvx9011731; Thu, 19 Nov 2009 12:18:58 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 13:18:57 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 13:18:56 +0100 Message-Id: <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 13:18:56 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 12:18:56.0604 (UTC) FILETIME=[7757A1C0:01CA6912] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 12:19:02 -0000 On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Thu, 19 Nov 2009 11:36:49 +0100 >> >> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: >> >>> I'll have to admit that I'm not yet convinced of the benefits in >>> storing DAO state as it currently exists in the draft. [...] >>> >> I do agree with the first statement but not with the second >> paragraph. >> I do see several deployment cases where no storing DAO would lead to >> extremely sub-optimal paths and even more importantly traffic >> congestion when getting closer to the root of course. > > Can you share these cases with us? I agree with Jonathan > that storing DAO states will typically not provide much > improvement in P2P routing. Sure. I'll take the example of an inter primary+secondary substation network (could be the smart metering network) that supports traffic for various purposes: meter read-out, DA alarms, ... etc. Thus traffic of various nature: P2MP, MP2P and P2P. There are many such networks where not storing DAO just does not work since all P2P traffic will have to transit via the root (unacceptable delays for alarms) and the traffic around the root will be way too high. This is why I am saying that having an RFC that forms a DAG that cannot be used for outward traffic is a non-starter. > >> I do see several deployment cases where no storing DAO would lead to >> extremely sub-optimal paths and even more importantly traffic >> congestion when getting closer to the root of course. This is true >> with several networks where the amount of P2P traffic may ned up >> being >> not so negligible. The beauty with the current spec is that it allows >> both deployment models. > > It claims to allow both, but fails to actually do so. That > is the point of the example that I gave and the reason I > keep going on about this. While the draft says that > intermediate nodes can cache DAOs, it doesn't say how those > caches are updated after a node changes parents. And > however this is done, we need to avoid the cost of sending > cache updates in the absense of any actual caches. Yes I agree with you on this and this is why DAO packing is also important. Thus I would propose to all work on this and make it work while still allowing some nodes to not store any DAO is they want to of course. Does that make sense ? Cheers. JP. > > -Richard Kelsey From rstruik@certicom.com Thu Nov 19 05:40:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D063A6B2E; Thu, 19 Nov 2009 05:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 rulYNc9ZloVN; Thu, 19 Nov 2009 05:40:39 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D61B13A6816; Thu, 19 Nov 2009 05:40:38 -0800 (PST) X-AuditID: 0a401fcb-b7b71ae000002562-42-4b054ad2924c Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id D3.8B.09570.2DA450B4; Thu, 19 Nov 2009 08:40:35 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 08:40:34 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 19 Nov 2009 08:40:12 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> In-Reply-To: <20091118235822.GB7886@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SNMP optimizations Thread-Index: AcpoqwfI1nGPctU3TdC+bUXVaDY1KQAcdwxw References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> <20091118235822.GB7886@elstar.local> From: "Rene Struik" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 19 Nov 2009 13:40:34.0684 (UTC) FILETIME=[DED353C0:01CA691D] X-Brightmail-Tracker: AAAAAwAAAZERyCBQEctxlg== Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [Roll] [6lowpan] SNMP optimizations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 13:40:40 -0000 Hi Juergen: I submitted a 6lowapp draft on security considerations precisely because one needs a description of the problem space and make sure it is not "forgotten". I do understand that people may wish and use some functionality that is already out there, but question is whether it supports the desired security functionality over the lifecycle of the system. Could you recommend an overview paper on SNMP that would make it easy to see what the supposed security features are suitable to sensor-type applications and how these are delivered (mechanisms, communication overhead, etc.). This should make it easier to provide a more quantitative assessment. Best regards, Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, November 18, 2009 6:58 PM To: Ulrich Herberg Cc: manet@ietf.org; 6lowpan; roll@ietf.org Subject: Re: [6lowpan] SNMP optimizations On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote: [... we should restrict this to one mailing list...] > However, it is unclear whether the code footprint of SNMP > implementations can fit into the memory of small devices. From > discussions with several persons from the MANET WG, I conclude that > for MANET the same problem exists. (and I think for ROLL, too?) > > I have several questions that came to my mind about this topic: > > - First of all, to which WG does this issue belong to? Or is it -- as > I suppose -- a common problem for the three working groups addressed > in this mail? I don't know. > - Is this really an issue? Are there implementations of SNMP (maybe > not open-source) that can be run on very small devices such as > considered in 6lowpan/ROLL/MANET? Is there any experimental (or > theoretical) analysis whether SNMP (or any other standardized > management protocol) can run on these devices? The question is under specified. What is a "very small device" and how much can a "very small device" devote to SNMP? And what is SNMP? The SNMPv3 specs are pretty modular. One of the more important questions is how you deal with security - the security code has the potential to be bigger than the rest of the SNMP engine. And it boils down to the question of how many MIB objects you support and to what extend you hardwire things. Remember that SNMP is a child of the late 80s and early versions were sometimes embedded into devices that could not afford TCP. Of course, the 80s version of SNMP did not care much about security... > - If SNMP cannot be used for small devices, how can we manage and > monitor these devices then? (e.g. using proxies, different message > formats such as proposed in 6lowapp, etc.). Do we need a different > lightweight protocol for management? Again, the big question is how to deal with the security aspect. SNMP originally was lightweight because there was no security. It took the IETF many years to find a workable security solution and even today people are working on utilizing transport layer security protocols within SNMP (see ISMS working group). > - Can we provide SNMP not only on a single device, but for a whole > network? That might need an aggregator device that runs full SNMP and > collects the data from the low power devices. This would imply to > monitor statistics of a whole network (e.g. number of links, average > throughput, average path-length, etc.) Sure, there are ways of doing this. For read-only objects, this is relatively easy - it can get a bit messy if you have read-write objects. Whether this direction is worthwhile to explore depends on how you solve the security issues and whether a dependency on a "gateway" is desirable in the first place. > - What kind of objects should be provided in a MIB running on a > MANET/6lowpan/ROLL device? This might be specific to the routing > protocol, but there can be commonalities. In general, the IETF tends to break MIB modules down along protocol functions. Following this approach, a ROLL MIB module would report data about the ROLL routing protocol. A 6LoWPAN MIB would report data about the 6LoWPAN layer, that is for example the list of supported 6LoWPAN protocol features and counters for 6LoWPAN processing failures (e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues. I would hope that some IPv6 MIB objects apply as well and then there should ideally be an IEEE 802.15.4 MIB module for this particular radio technology. I do not think there is much overlap if things get structured well. This, however, might be difficult to achieve if work is spread over several WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pal@cs.stanford.edu Thu Nov 19 06:06:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2483A69DB for ; Thu, 19 Nov 2009 06:06:59 -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 i3vUoRHn4kTt for ; Thu, 19 Nov 2009 06:06:58 -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 93D623A6930 for ; Thu, 19 Nov 2009 06:06:58 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NB7ex-0005AX-OC; Thu, 19 Nov 2009 06:06:56 -0800 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DAAC710@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 06:06:55 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DAAB837@XMB-AMS-107.cisco.com> <699F0082-EC8C-4509-9C8A-19C814436B20@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DAAC710@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: roll@ietf.org Subject: Re: [Roll] do we need a dominating set? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:06:59 -0000 On Nov 19, 2009, at 2:19 AM, Pascal Thubert (pthubert) wrote: > I still see the value of trickling the control packets because of > the exponential backoff piece but wish to limit the suppression of > routing information as much as possible. Then you cannot scale to dense networks. This is not a decision the specification should make unilaterally. I don't see what the big deal is: the specification already allows this flexibility by saying MAY increment C. Phil From Jerald.P.Martocci@jci.com Thu Nov 19 06:37:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4AF3A695F; Thu, 19 Nov 2009 06:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, 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 0T3yqq8kSBiS; Thu, 19 Nov 2009 06:37:48 -0800 (PST) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 94CC83A681F; Thu, 19 Nov 2009 06:37:47 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSwVYMiTBPzk9muwO4y+PC+0NolVweKXB@postini.com; Thu, 19 Nov 2009 06:37:46 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111908404671-3396359 ; Thu, 19 Nov 2009 08:40:46 -0600 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 19 Nov 2009 08:37:19 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/19/2009 08:37:28 AM, Serialize complete at 11/19/2009 08:37:28 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/19/2009 08:40:47 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/19/2009 08:41:04 AM, Serialize complete at 11/19/2009 08:41:04 AM Content-Type: multipart/alternative; boundary="=_alternative 0050534586257673_=" Cc: roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:37:49 -0000 This is a multipart message in MIME format. --=_alternative 0050534586257673_= Content-Type: text/plain; charset="US-ASCII" Hi JP, I don't think RPL can simply state 'IP Multicast' as you note below. As Michael mentions there are a) unicasts, b) link-level multicast and c) subnet-level multicasts. He further mentions that on Ethernet link-level and subnet level multicasts are the same. I totally agree with this. However, the converse of this is not true; on wireless mesh networks link-level multicast and subnet-level multicasts are very different. On a 6LowPAN based mesh network for example the link-level multcast domain will be simply the nodes within direct radio range of the source; while a subnet level multicast domain will cover the entire LLN. I believe RPL has to clearly state the extent of the multicast domain in every case; else different implementations may define different multicast domains yielding no interoperability. Furthermore the network traffic patterns will be hugely impacted if multicasts cross the entire LLN, when the algorithm was meant to be limited to the source's neighbors. Jerry JP Vasseur Sent by: roll-bounces@ietf.org 11/19/2009 02:38 AM To Michael Richardson cc ROLL WG Subject Re: [Roll] need clarification: DIS processing On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Jerald" == Jerald P Martocci writes: > Jerald> I agree with Julien that we need a DIO solicitation message > Jerald> (i.e. DIS) since as he says a packet can't wait around for > Jerald> hours waiting for a new DAG parent. I buy that and agree > Jerald> with it. However, I am a bit confused why a multicast DIS > Jerald> should trigger a multicast DIO. This seems to simply add > Jerald> unnecessary packets onto the network. > > I am reacting to the last sentence. > I'd have thought that multicast avoids unncesary packets!!!! > So perhaps we are not talking about the same thing? > > Maybe we need better terminology. > I think that there are three kinds of transmission: > a) unicast > b) link-level multicast > c) subnet-level multicast > On ethernet, (b) and (c) are the same thing. > Just bear in mind that we always refer to IP multicast, since we are not link layer specific. > On 6lowpan-type networks, I think (b) is what happens when you > transmit to the nodes that can hear you, and (c) is what you do via a > whiteboard or multicast relay. > > (Maybe there are accepted terms for this, of which I am ignorant) > > Only transmissions of type (c) cause more packets on the wire. > > Transmissions of type (b) would save packets, because one message > arrives at many receivers at the same time. Maybe (b) causes > receivers > that would otherwise have been happy to sleep (doze?) to wake up. > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE > > > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH > LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL > IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s > eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp > U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG > VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg== > =MCIA > -----END PGP SIGNATURE----- > _______________________________________________ > 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 --=_alternative 0050534586257673_= Content-Type: text/html; charset="US-ASCII"
Hi JP,


I don't think RPL can simply state 'IP Multicast' as you note below.  As Michael mentions there are a) unicasts, b) link-level multicast and c) subnet-level multicasts.  He further mentions that on Ethernet link-level and subnet level multicasts are the same.  I totally agree with this.  However, the converse of this is not true; on wireless mesh networks link-level multicast and subnet-level multicasts are very different.  

On a 6LowPAN based mesh network for example the link-level multcast domain will be simply the nodes within direct radio range of the source; while a subnet level multicast domain will cover the entire LLN.  I believe RPL has to clearly state the extent of the multicast domain in every case; else different implementations may define different multicast domains yielding no interoperability.  Furthermore the network traffic patterns will be hugely impacted if multicasts cross the entire LLN, when the algorithm was meant to be limited to the source's neighbors.

Jerry





JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

11/19/2009 02:38 AM

To
Michael Richardson <mcr@sandelman.ca>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] need clarification: DIS processing






On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
>    Jerald> I agree with Julien that we need a DIO solicitation message
>    Jerald> (i.e. DIS) since as he says a packet can't wait around for
>    Jerald> hours waiting for a new DAG parent.  I buy that and agree
>    Jerald> with it.  However, I am a bit confused why a multicast DIS
>    Jerald> should trigger a multicast DIO.  This seems to simply add
>    Jerald> unnecessary packets onto the network.
>
>  I am reacting to the last sentence.
>  I'd have thought that multicast avoids unncesary packets!!!!
>  So perhaps we are not talking about the same thing?
>
>  Maybe we need better terminology.
>  I think that there are three kinds of transmission:
>    a) unicast
>    b) link-level multicast
>    c) subnet-level multicast
>  On ethernet, (b) and (c) are the same thing.
>

Just bear in mind that we always refer to IP multicast, since we are  
not link layer specific.

>  On 6lowpan-type networks, I think (b) is what happens when you
> transmit to the nodes that can hear you, and (c) is what you do via a
> whiteboard or multicast relay.
>
>  (Maybe there are accepted terms for this, of which I am ignorant)
>
>  Only transmissions of type (c) cause more packets on the wire.
>
>  Transmissions of type (b) would save packets, because one message
> arrives at many receivers at the same time.  Maybe (b) causes  
> receivers
> that would otherwise have been happy to sleep (doze?) to wake up.
>
> - --
> ]       He who is tired of Weird Al is tired of life!           |  
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net  
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |
> device driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE
> >
>                                 then sign the petition.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH
> LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL
> IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s
> eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp
> U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG
> VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg==
> =MCIA
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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
--=_alternative 0050534586257673_=-- From jvasseur@cisco.com Thu Nov 19 06:41:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1B03A6AA8; Thu, 19 Nov 2009 06:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.019 X-Spam-Level: X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXP4QXO+nvkf; Thu, 19 Nov 2009 06:41: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 DBBE23A68AF; Thu, 19 Nov 2009 06:41:33 -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: AkYAAI7nBEuQ/uCWe2dsb2JhbACCIS8hhEWUVAEBCwskBqFKiTyOOoQ7BIFv X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208,217";a="54760515" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 14:41:30 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJEfUIU018559; Thu, 19 Nov 2009 14:41:30 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:41:29 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:41:29 +0100 Message-Id: <411E24D5-C217-4068-A862-C90F2272C854@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-261--985869493 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 15:41:28 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 14:41:29.0551 (UTC) FILETIME=[614BC5F0:01CA6926] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.005 X-TM-AS-Result: No--52.581000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] need clarification: DIS processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:41:36 -0000 --Apple-Mail-261--985869493 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sorry Jerry I was not clear ... I just wanted to clarify that the term multicast is used in an IP context (not referring to the link layer). On Nov 19, 2009, at 3:37 PM, Jerald.P.Martocci@jci.com wrote: > > Hi JP, > > > I don't think RPL can simply state 'IP Multicast' as you note > below. As Michael mentions there are a) unicasts, b) link-level > multicast and c) subnet-level multicasts. He further mentions that > on Ethernet link-level and subnet level multicasts are the same. I > totally agree with this. However, the converse of this is not true; > on wireless mesh networks link-level multicast and subnet-level > multicasts are very different. > > On a 6LowPAN based mesh network for example the link-level multcast > domain will be simply the nodes within direct radio range of the > source; while a subnet level multicast domain will cover the entire > LLN. I believe RPL has to clearly state the extent of the multicast > domain in every case; else different implementations may define > different multicast domains yielding no interoperability. > Furthermore the network traffic patterns will be hugely impacted if > multicasts cross the entire LLN, when the algorithm was meant to be > limited to the source's neighbors. > > Jerry > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 11/19/2009 02:38 AM > > To > Michael Richardson > cc > ROLL WG > Subject > Re: [Roll] need clarification: DIS processing > > > > > > > On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >>>>>> "Jerald" == Jerald P Martocci > writes: > > Jerald> I agree with Julien that we need a DIO solicitation > message > > Jerald> (i.e. DIS) since as he says a packet can't wait around > for > > Jerald> hours waiting for a new DAG parent. I buy that and agree > > Jerald> with it. However, I am a bit confused why a multicast > DIS > > Jerald> should trigger a multicast DIO. This seems to simply add > > Jerald> unnecessary packets onto the network. > > > > I am reacting to the last sentence. > > I'd have thought that multicast avoids unncesary packets!!!! > > So perhaps we are not talking about the same thing? > > > > Maybe we need better terminology. > > I think that there are three kinds of transmission: > > a) unicast > > b) link-level multicast > > c) subnet-level multicast > > On ethernet, (b) and (c) are the same thing. > > > > Just bear in mind that we always refer to IP multicast, since we are > not link layer specific. > > > On 6lowpan-type networks, I think (b) is what happens when you > > transmit to the nodes that can hear you, and (c) is what you do > via a > > whiteboard or multicast relay. > > > > (Maybe there are accepted terms for this, of which I am ignorant) > > > > Only transmissions of type (c) cause more packets on the wire. > > > > Transmissions of type (b) would save packets, because one message > > arrives at many receivers at the same time. Maybe (b) causes > > receivers > > that would otherwise have been happy to sleep (doze?) to wake up. > > > > - -- > > ] He who is tired of Weird Al is tired of life! | > > firewalls [ > > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > > architect[ > > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > > device driver[ > > Kyoto Plus: watch the video > > > > then sign the petition. > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > Comment: Finger me for keys > > > > iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH > > LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL > > IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s > > eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp > > U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG > > VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg== > > =MCIA > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-261--985869493 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sorry Jerry I was not clear ... = I just wanted to clarify that the term multicast is used in an IP = context (not referring to the link layer).

On Nov 19, = 2009, at 3:37 PM, Jerald.P.Martocci@jci.com = wrote:


Hi JP, =


I don't think RPL can = simply state 'IP Multicast' as you note below.  As Michael mentions = there are a) unicasts, b) link-level multicast and c) subnet-level = multicasts.  He further mentions that on Ethernet link-level and = subnet level multicasts are the same.  I totally agree with this. =  However, the converse of this is not true; on wireless mesh = networks link-level multicast and subnet-level multicasts are very = different.  

On = a 6LowPAN based mesh network for example the link-level multcast domain = will be simply the nodes within direct radio range of the source; while = a subnet level multicast domain will cover the entire LLN.  I = believe RPL has to clearly state the extent of the multicast domain in = every case; else different implementations may define different = multicast domains yielding no interoperability.  Furthermore the = network traffic patterns will be hugely impacted if multicasts cross the = entire LLN, when the algorithm was meant to be limited to the source's = neighbors.

Jerry





=
JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">11/19/2009 02:38 AM =

To
Michael Richardson <mcr@sandelman.ca> =
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] need clarification: DIS = processing

=




= On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote:

> = -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
= >
>>>>>> "Jerald" =3D=3D Jerald P Martocci = <Jerald.P.Martocci@jci.com>= ; writes:
>    Jerald> I agree with Julien that we = need a DIO solicitation message
>    Jerald> (i.e. = DIS) since as he says a packet can't wait around for
>   =  Jerald> hours waiting for a new DAG parent.  I buy that = and agree
>    Jerald> with it.  However, I am = a bit confused why a multicast DIS
>    Jerald> = should trigger a multicast DIO.  This seems to simply add
> =    Jerald> unnecessary packets onto the network.
= >
>  I am reacting to the last sentence.
> =  I'd have thought that multicast avoids unncesary packets!!!!
= >  So perhaps we are not talking about the same thing?
= >
>  Maybe we need better terminology.
>  I = think that there are three kinds of transmission:
>   =  a) unicast
>    b) link-level multicast
> =    c) subnet-level multicast
>  On ethernet, (b) = and (c) are the same thing.
>

Just bear in mind that we = always refer to IP multicast, since we are  
not link layer = specific.

>  On 6lowpan-type networks, I think (b) is = what happens when you
> transmit to the nodes that can hear you, = and (c) is what you do via a
> whiteboard or multicast relay.
= >
>  (Maybe there are accepted terms for this, of which I = am ignorant)
>
>  Only transmissions of type (c) = cause more packets on the wire.
>
>  Transmissions of = type (b) would save packets, because one message
> arrives at = many receivers at the same time.  Maybe (b) causes  
> = receivers
> that would otherwise have been happy to sleep (doze?) = to wake up.
>
> - --
> ]       He = who is tired of Weird Al is tired of life!         =   |  
> firewalls  [
> ]   Michael = Richardson, Sandelman Software Works, Ottawa, ON    |net =  
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on= .ca/ |
> device driver[
>   Kyoto Plus: watch = the video <http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE
> >
>     =                     =         then sign the petition.
> -----BEGIN = PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> = Comment: Finger me for keys
>
> = iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH
= > = LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL
= > = IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s
= > = eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp
= > = U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG
= > VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg=3D=3D
= > =3DMCIA
> -----END PGP SIGNATURE-----
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll

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

= --Apple-Mail-261--985869493-- From robert.cole@jhuapl.edu Thu Nov 19 06:41:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AAB3A68AF; Thu, 19 Nov 2009 06:41:48 -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 RaB2qnKV7Cek; Thu, 19 Nov 2009 06:41:47 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id C8A8328C0F8; Thu, 19 Nov 2009 06:41:42 -0800 (PST) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.35047878; Thu, 19 Nov 2009 09:40:30 -0500 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 19 Nov 2009 09:41:32 -0500 From: "Cole, Robert G." To: Ulrich Herberg , 6lowpan <6lowpan@ietf.org>, "manet@ietf.org" , "roll@ietf.org" Date: Thu, 19 Nov 2009 09:41:30 -0500 Thread-Topic: [manet] SNMP optimizations Thread-Index: Acpok58TtW4sKSpDQS2tzvjWYhSwMQAkjpvA Message-ID: <0A8F66C42F49E448A40E99946404EE5B717B8531D1@aplesstar.dom1.jhuapl.edu> References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> In-Reply-To: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.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-Mailman-Approved-At: Thu, 19 Nov 2009 06:44:43 -0800 Cc: "dromasca@avaya.com" , "andy@netconfcentral.com" Subject: Re: [Roll] [manet] SNMP optimizations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:41:48 -0000 Ulrich, The was some prior related work in the RMON WG on the RAQMON model (RFCs 47= 10 and 4711). This monitoring framework was explicitly designed to monitor= low-power, hand held devices, e.g., phones. Dan was one of the co-authors= . Folks may want to read thru these RFCs. Thanks, Bob -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of U= lrich Herberg Sent: Wednesday, November 18, 2009 4:10 PM To: 6lowpan; manet@ietf.org; roll@ietf.org Subject: [manet] SNMP optimizations Hi, I am sending this message to the 6lowpan, ROLL and MANET mailing list, sinc= e I think this topic concerns all three working groups, and I am not sure i= n which WG this is to be tackled. During the MANET WG meeting and also during an OLSRv2 Interop workshop, we = had discussions about SNMP deployments in such ad-hoc networks we are deali= ng with. The issue that was raised (and which is also described in draft-ha= mid-6lowpan-snmp-optimizations) is that SNMP may be too memory-/CPU-/bandwi= dth-consuming for low-power devices. However, a solution for monitoring and management of these devices is desir= ed (and also required by IETF). The before-mentioned draft describes very w= ell how to optimize SNMP for running it on 6lowpan devices, and shows that = the SNMP payload can fit into 6lowpan packets. However, it is unclear whether the code footprint of SNMP implementations c= an fit into the memory of small devices. From discussions with several pers= ons from the MANET WG, I conclude that for MANET the same problem exists. (= and I think for ROLL, too?) I have several questions that came to my mind about this topic: - First of all, to which WG does this issue belong to? Or is it -- as I sup= pose -- a common problem for the three working groups addressed in this mai= l? - Is this really an issue? Are there implementations of SNMP (maybe not ope= n-source) that can be run on very small devices such as considered in 6lowp= an/ROLL/MANET? Is there any experimental (or theoretical) analysis whether SNMP (or any other standardized management pr= otocol) can run on these devices? - If SNMP cannot be used for small devices, how can we manage and monitor t= hese devices then? (e.g. using proxies, different message formats such as p= roposed in 6lowapp, etc.). Do we need a different lightweight protocol for = management? - Can we provide SNMP not only on a single device, but for a whole network= ? That might need an aggregator device that runs full SNMP and collects the= data from the low power devices. This would imply to monitor statistics of= a whole network (e.g. number of links, average throughput, average path-le= ngth, etc.) - What kind of objects should be provided in a MIB running on a MANET/6low= pan/ROLL device? This might be specific to the routing protocol, but there = can be commonalities. Regards, Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From richard.kelsey@ember.com Thu Nov 19 06:45:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B5728C164 for ; Thu, 19 Nov 2009 06:45: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 MKTas6Eq6Du9 for ; Thu, 19 Nov 2009 06:45:34 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id EA7C03A681F for ; Thu, 19 Nov 2009 06:45:33 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 09:46:55 -0500 Date: Thu, 19 Nov 2009 09:41:41 -0500 Message-Id: <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> (message from JP Vasseur on Thu, 19 Nov 2009 13:18:56 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> X-OriginalArrivalTime: 19 Nov 2009 14:46:55.0015 (UTC) FILETIME=[2349A370:01CA6927] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:45:35 -0000 > From: JP Vasseur > Date: Thu, 19 Nov 2009 13:18:56 +0100 > > On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: > > JP> From: JP Vasseur > JP> Date: Thu, 19 Nov 2009 11:36:49 +0100 > JP> > JP> I do see several deployment cases where no storing DAO would lead to > JP> extremely sub-optimal paths and even more importantly traffic > JP> congestion when getting closer to the root of course. > > Richard> Can you share these cases with us? I agree with Jonathan > Richard> that storing DAO states will typically not provide much > Richard> improvement in P2P routing. > > Sure. I'll take the example of an inter primary+secondary > substation network (could be the smart metering network) > that supports traffic for various purposes: meter > read-out, DA alarms, ... etc. Thus traffic of various > nature: P2MP, MP2P and P2P. Yes, I think we all agree that reasonably efficient P2P is a requirement for many use cases. The issue isn't whether or not we need good P2P routing. The issue is whether or not the DAO mechanism does a good enough job to be worth the effort. RPL ignores P2P when choosing parents. Getting a good P2P route out of RPL is a matter of luck, not design. > There are many such networks > where not storing DAO just does not work since all P2P > traffic will have to transit via the root (unacceptable > delays for alarms) and the traffic around the root will be > way too high. Yes, and in many cases most P2P traffic will have to transit via the root even if all nodes store DAOs. This is a side effect of how RPL chooses parents. Minimizing the lengths of the paths to the root maximizes the number of pairwise paths that include the root. If this is unacceptable, then we should stop tweaking the DAOs and work on a better solution. -Richard Kelsey From jvasseur@cisco.com Thu Nov 19 06:49:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B4A3A68CC for ; Thu, 19 Nov 2009 06:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.967 X-Spam-Level: X-Spam-Status: No, score=-9.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 0wh5ifg1fH2p for ; Thu, 19 Nov 2009 06:49:20 -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 9A34A3A6935 for ; Thu, 19 Nov 2009 06:49:19 -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: AjQAAKrpBEuQ/uCWe2dsb2JhbACcCgEBCwskBqFTl3aEOwQ X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208";a="54760958" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 14:49:16 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJEnGYK019901; Thu, 19 Nov 2009 14:49:16 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:49:16 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:49:15 +0100 Message-Id: <24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 15:49:15 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 14:49:16.0101 (UTC) FILETIME=[7761A750:01CA6927] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.005 X-TM-AS-Result: No--19.888700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:49:20 -0000 On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Thu, 19 Nov 2009 13:18:56 +0100 >> >> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: >> >> JP> From: JP Vasseur >> JP> Date: Thu, 19 Nov 2009 11:36:49 +0100 >> JP> >> JP> I do see several deployment cases where no storing DAO would >> lead to >> JP> extremely sub-optimal paths and even more importantly traffic >> JP> congestion when getting closer to the root of course. >> >> Richard> Can you share these cases with us? I agree with Jonathan >> Richard> that storing DAO states will typically not provide much >> Richard> improvement in P2P routing. >> >> Sure. I'll take the example of an inter primary+secondary >> substation network (could be the smart metering network) >> that supports traffic for various purposes: meter >> read-out, DA alarms, ... etc. Thus traffic of various >> nature: P2MP, MP2P and P2P. > > Yes, I think we all agree that reasonably efficient > P2P is a requirement for many use cases. > > The issue isn't whether or not we need good P2P routing. > The issue is whether or not the DAO mechanism does a good > enough job to be worth the effort. > > RPL ignores P2P when choosing parents. Getting a good P2P > route out of RPL is a matter of luck, not design. > First, you can certainly tune the OF to increase the P2P quality. Second, in the VERY worst non probable case you would transit via the route. Last but not least, without DAO how do you send traffic outward ? Need to wait until you receive a packet, then record route and do source routing ? >> There are many such networks >> where not storing DAO just does not work since all P2P >> traffic will have to transit via the root (unacceptable >> delays for alarms) and the traffic around the root will be >> way too high. > > Yes, and in many cases most P2P traffic will have to transit > via the root even if all nodes store DAOs. This is a side > effect of how RPL chooses parents. Minimizing the lengths > of the paths to the root maximizes the number of pairwise > paths that include the root. If this is unacceptable, then > we should stop tweaking the DAOs and work on a better > solution. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Thu Nov 19 06:55:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9729B3A6969 for ; Thu, 19 Nov 2009 06:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 ziStkeHkwBft for ; Thu, 19 Nov 2009 06:55:22 -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 B19833A68F5 for ; Thu, 19 Nov 2009 06:55:22 -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: ApoEAOHqBEurRN+K/2dsb2JhbAC+HZd2hDsE X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208";a="51605981" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2009 14:55:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAJEtHG5018305; Thu, 19 Nov 2009 14:55:20 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:55:18 +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: Thu, 19 Nov 2009 15:55:16 +0100 Message-ID: In-Reply-To: <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: AcppEn3Xatw0rIN8Qyek8tem1lHBsAABlZSw References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com><10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com><87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> From: "Julien Abeille (jabeille)" To: "JP Vasseur (jvasseur)" , "Richard Kelsey" X-OriginalArrivalTime: 19 Nov 2009 14:55:18.0455 (UTC) FILETIME=[4F5C7C70:01CA6928] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:55:23 -0000 Hi JP, all, I agree that we should keep DAOs in RPL. A routing protocol that installs routes in one direction only makes no sense to me. By the way if in a deployment some do not want to store DAOs, they can. Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of JP Vasseur (jvasseur) > Sent: jeudi 19 novembre 2009 13:19 > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) >=20 >=20 > On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: >=20 > >> From: JP Vasseur > >> Date: Thu, 19 Nov 2009 11:36:49 +0100 > >> > >> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > >> > >>> I'll have to admit that I'm not yet convinced of the benefits in=20 > >>> storing DAO state as it currently exists in the draft. [...] > >>> > >> I do agree with the first statement but not with the second=20 > >> paragraph. > >> I do see several deployment cases where no storing DAO=20 > would lead to=20 > >> extremely sub-optimal paths and even more importantly traffic=20 > >> congestion when getting closer to the root of course. > > > > Can you share these cases with us? I agree with Jonathan=20 > that storing=20 > > DAO states will typically not provide much improvement in=20 > P2P routing. >=20 > Sure. I'll take the example of an inter primary+secondary=20 > substation network (could be the smart metering network) that=20 > supports traffic for various purposes: > meter read-out, DA alarms, ... etc. Thus traffic of various nature: =20 > P2MP, MP2P > and P2P. There are many such networks where not storing DAO=20 > just does not work since all P2P traffic will have to transit=20 > via the root (unacceptable delays for > alarms) and the traffic around the root will be way too high. >=20 > This is why I am saying that having an RFC that forms a DAG=20 > that cannot be used for outward traffic is a non-starter. >=20 > > > >> I do see several deployment cases where no storing DAO=20 > would lead to > >> extremely sub-optimal paths and even more importantly traffic > >> congestion when getting closer to the root of course. This is true > >> with several networks where the amount of P2P traffic may ned up =20 > >> being > >> not so negligible. The beauty with the current spec is=20 > that it allows > >> both deployment models. > > > > It claims to allow both, but fails to actually do so. That > > is the point of the example that I gave and the reason I > > keep going on about this. While the draft says that > > intermediate nodes can cache DAOs, it doesn't say how those > > caches are updated after a node changes parents. And > > however this is done, we need to avoid the cost of sending > > cache updates in the absense of any actual caches. >=20 > Yes I agree with you on this and this is why DAO packing is also =20 > important. > Thus I would propose to all work on this and make it work=20 > while still =20 > allowing > some nodes to not store any DAO is they want to of course. >=20 > Does that make sense ? >=20 > Cheers. >=20 > JP. >=20 > > > > -Richard Kelsey >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jabeille@cisco.com Thu Nov 19 06:57:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EED3A693B for ; Thu, 19 Nov 2009 06:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMTh+NkVco6R for ; Thu, 19 Nov 2009 06:57:57 -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 99F153A68F5 for ; Thu, 19 Nov 2009 06:57:56 -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: AjYAAETsBEuQ/uCWe2dsb2JhbACCJSuZOgEBCwskBqFcl3aEOwQ X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208,217";a="54761776" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 14:57:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJEvnUX022092 for ; Thu, 19 Nov 2009 14:57:49 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:57:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6928.A8F2CEC8" Date: Thu, 19 Nov 2009 15:57:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trickle clarification: (in)consistency Thread-Index: AcppKKhboIjg0YjmSzmUkYKmlGQKnw== From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 19 Nov 2009 14:57:48.0963 (UTC) FILETIME=[A9122F30:01CA6928] Subject: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 14:57:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6928.A8F2CEC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 - when the DAG is considered inconsistent, I think we do not double I when I fires. Correct? - when do we increment C?=20 - most importantly: how does a node know it is in consistent mode? =20 Best, Julien =20 ------_=_NextPart_001_01CA6928.A8F2CEC8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
- when = the DAG is=20 considered inconsistent, I think we do not double I when I fires.=20 Correct?
- when = do we=20 increment C?
- most = importantly:=20 how does a node know it is in consistent mode?
 
Best,
Julien
 
------_=_NextPart_001_01CA6928.A8F2CEC8-- From j.schoenwaelder@jacobs-university.de Thu Nov 19 07:00:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E6D3A6969; Thu, 19 Nov 2009 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FawpsBOO2NNy; Thu, 19 Nov 2009 07:00:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B99DD3A6959; Thu, 19 Nov 2009 07:00:34 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11B80C003F; Thu, 19 Nov 2009 16:00:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eIn3Rp3FP+H4; Thu, 19 Nov 2009 16:00:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AD0BC0009; Thu, 19 Nov 2009 16:00:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2FE71E2C3FD; Thu, 19 Nov 2009 16:00:30 +0100 (CET) Date: Thu, 19 Nov 2009 16:00:30 +0100 From: Juergen Schoenwaelder To: Rene Struik Message-ID: <20091119150030.GB1545@elstar.local> Mail-Followup-To: Rene Struik , "6lowapp@ietf.org" <6lowapp@ietf.org>, 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> <20091118235822.GB7886@elstar.local> <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "roll@ietf.org" , 6lowpan <6lowpan@ietf.org>, "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [Roll] [6lowpan] SNMP optimizations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:00:35 -0000 On Thu, Nov 19, 2009 at 02:40:12PM +0100, Rene Struik wrote: > Could you recommend an overview paper on SNMP that would make it easy to > see what the supposed security features are suitable to sensor-type > applications and how these are delivered (mechanisms, communication > overhead, etc.). This should make it easier to provide a more > quantitative assessment. I can provide you with a draft of a paper discussing the impact of security on SNMP in general. http://cnds.eecs.jacobs-university.de/people/schoenw/drafts/snmp-security.pdf This paper requires some updates - some of the references etc. are meanwhile outdated. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Jerald.P.Martocci@jci.com Thu Nov 19 07:40:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED31E3A6958; Thu, 19 Nov 2009 07:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, 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 r7QNM3fjg5wO; Thu, 19 Nov 2009 07:40:42 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id A54613A6889; Thu, 19 Nov 2009 07:40:41 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSwVm93eg9P+SgCp5dn/tNPmpZEmCS5zr@postini.com; Thu, 19 Nov 2009 07:40:40 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009111909434898-3405370 ; Thu, 19 Nov 2009 09:43:48 -0600 In-Reply-To: <24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 19 Nov 2009 09:40:21 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/19/2009 09:40:30 AM, Serialize complete at 11/19/2009 09:40:30 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/19/2009 09:43:49 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/19/2009 09:43:58 AM, Serialize complete at 11/19/2009 09:43:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0056192D86257673_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 15:40:44 -0000 This is a multipart message in MIME format. --=_alternative 0056192D86257673_= Content-Type: text/plain; charset="US-ASCII" Hi JP, Sorry to be beating you up today on the mailing list. It's not intentional; maybe it's just your turn :) In Geneva, I thought we had reached an epiphany when Thomas noted so adroitly that destination nodes cannot a priori know what source nodes might be sending them packets in the future. I believe he referenced the pain Google would have if it somehow needed to define a connection to potentially everyone wanting to someday access its website!!! I hoped that discussion would be the impetus to find an on-demand means to pass a packet outward. The idea of every node having to form a connection to every other node in the DAG to be maintained ad infinitum on the off-chance that someday a packet may need to be passed to that node is very inefficient. As probably the strongest proponent of the P2P requirement on this mailing list, I will readily admit that even in building control only about 25% of the router nodes need to pass intra-LLN P2P messages. As I understand the DAO algorithm in RPL 4.0 using the preferred parent requirement there will be one and only one outward path defined to each node. If that lonely path should happen to be dropped, the outbound packet would be in a limbo state for an undetermined amount of time until the DAG recognizes the problem, issues a sequence number change and the DAG is fully repaired with a new set of DAO exchanges. The source node will have long ago exhausted its retry count and flagged the destination node off-line. So yes, I think we either need to design outward traffic into the DAG at the same level as we do inward traffic; or devise an on-demand scheme where a node can easily 'discover' another node in the DAG as needed. Richard's comment below is profound saying that right now establishing a good outward link is a matter of luck, not design. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 11/19/2009 08:49 AM To Richard Kelsey cc roll@ietf.org Subject Re: [Roll] updating DAO caches (was Re: Something to ADD) On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Thu, 19 Nov 2009 13:18:56 +0100 >> >> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: >> >> JP> From: JP Vasseur >> JP> Date: Thu, 19 Nov 2009 11:36:49 +0100 >> JP> >> JP> I do see several deployment cases where no storing DAO would >> lead to >> JP> extremely sub-optimal paths and even more importantly traffic >> JP> congestion when getting closer to the root of course. >> >> Richard> Can you share these cases with us? I agree with Jonathan >> Richard> that storing DAO states will typically not provide much >> Richard> improvement in P2P routing. >> >> Sure. I'll take the example of an inter primary+secondary >> substation network (could be the smart metering network) >> that supports traffic for various purposes: meter >> read-out, DA alarms, ... etc. Thus traffic of various >> nature: P2MP, MP2P and P2P. > > Yes, I think we all agree that reasonably efficient > P2P is a requirement for many use cases. > > The issue isn't whether or not we need good P2P routing. > The issue is whether or not the DAO mechanism does a good > enough job to be worth the effort. > > RPL ignores P2P when choosing parents. Getting a good P2P > route out of RPL is a matter of luck, not design. > First, you can certainly tune the OF to increase the P2P quality. Second, in the VERY worst non probable case you would transit via the route. Last but not least, without DAO how do you send traffic outward ? Need to wait until you receive a packet, then record route and do source routing ? >> There are many such networks >> where not storing DAO just does not work since all P2P >> traffic will have to transit via the root (unacceptable >> delays for alarms) and the traffic around the root will be >> way too high. > > Yes, and in many cases most P2P traffic will have to transit > via the root even if all nodes store DAOs. This is a side > effect of how RPL chooses parents. Minimizing the lengths > of the paths to the root maximizes the number of pairwise > paths that include the root. If this is unacceptable, then > we should stop tweaking the DAOs and work on a better > solution. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0056192D86257673_= Content-Type: text/html; charset="US-ASCII"

Hi JP,

Sorry to be beating you up today on the mailing list.  It's not intentional; maybe it's just your turn :)

In Geneva, I thought we had reached an epiphany when Thomas noted so adroitly that destination nodes cannot a priori know what source nodes might be sending them packets in the future.  I believe he referenced the pain Google would have if it somehow needed to define a connection to potentially everyone wanting to someday access its website!!!  I hoped that discussion would be the impetus to find an on-demand means to pass a packet outward.  The idea of every node having to form a connection to every other node in the DAG to be maintained ad infinitum on the off-chance that someday a packet may need to be passed to that node is very inefficient.  

As probably the strongest proponent of the P2P requirement on this mailing list, I will readily admit that even in building control only about 25% of the router nodes need to pass intra-LLN P2P messages.  As I understand the DAO algorithm in RPL 4.0 using the preferred parent requirement there will be one and only one outward path defined to each node.  If that lonely path should happen to be dropped, the outbound packet would be in a limbo state for an undetermined amount of time until the DAG recognizes the problem, issues a sequence number change and the DAG is fully repaired with a new set of DAO exchanges.  The source node will have long ago exhausted its retry count and flagged the destination node off-line.

So yes, I think we either need to design outward traffic into the DAG at the same level as we do inward traffic; or devise an on-demand scheme where a node can easily 'discover' another node in the DAG as needed.  Richard's comment below is profound saying that right now establishing a good outward link is a matter of luck, not design.

Regards,

Jerry




JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

11/19/2009 08:49 AM

To
Richard Kelsey <richard.kelsey@ember.com>
cc
roll@ietf.org
Subject
Re: [Roll] updating DAO caches (was Re:  Something to ADD)






On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote:

>> From: JP Vasseur <jvasseur@cisco.com>
>> Date: Thu, 19 Nov 2009 13:18:56 +0100
>>
>> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote:
>>
>> JP> From: JP Vasseur <jvasseur@cisco.com>
>> JP> Date: Thu, 19 Nov 2009 11:36:49 +0100
>> JP>
>> JP> I do see several deployment cases where no storing DAO would  
>> lead to
>> JP> extremely sub-optimal paths and even more importantly traffic
>> JP> congestion when getting closer to the root of course.
>>
>> Richard> Can you share these cases with us?  I agree with Jonathan
>> Richard> that storing DAO states will typically not provide much
>> Richard> improvement in P2P routing.
>>
>> Sure. I'll take the example of an inter primary+secondary
>> substation network (could be the smart metering network)
>> that supports traffic for various purposes: meter
>> read-out, DA alarms, ... etc. Thus traffic of various
>> nature: P2MP, MP2P and P2P.
>
> Yes, I think we all agree that reasonably efficient
> P2P is a requirement for many use cases.
>
> The issue isn't whether or not we need good P2P routing.
> The issue is whether or not the DAO mechanism does a good
> enough job to be worth the effort.
>
> RPL ignores P2P when choosing parents.  Getting a good P2P
> route out of RPL is a matter of luck, not design.
>

First, you can certainly tune the OF to increase the P2P quality.
Second, in the VERY worst non probable case you would transit via
the route.
Last but not least, without DAO how do you send traffic outward ?
Need to wait until you receive a packet, then record route and do
source routing ?

>> There are many such networks
>> where not storing DAO just does not work since all P2P
>> traffic will have to transit via the root (unacceptable
>> delays for alarms) and the traffic around the root will be
>> way too high.
>
> Yes, and in many cases most P2P traffic will have to transit
> via the root even if all nodes store DAOs.  This is a side
> effect of how RPL chooses parents.  Minimizing the lengths
> of the paths to the root maximizes the number of pairwise
> paths that include the root.  If this is unacceptable, then
> we should stop tweaking the DAOs and work on a better
> solution.
>                                  -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0056192D86257673_=-- From pal@cs.stanford.edu Thu Nov 19 07:43:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6348B3A67A7 for ; Thu, 19 Nov 2009 07:43:17 -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 l1Q-oj4Zv3es for ; Thu, 19 Nov 2009 07:43:16 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 78E003A67E7 for ; Thu, 19 Nov 2009 07:43:16 -0800 (PST) Received: from dnab42203a.stanford.edu ([171.66.32.58]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NB9A9-0005hs-SA; Thu, 19 Nov 2009 07:43:14 -0800 Message-Id: <76249419-1F28-4074-957B-67D94EFE73F8@cs.stanford.edu> From: Philip Levis To: Roger K. Alexander In-Reply-To: <020701ca6881$50996320$f1cc2960$@alexander@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 07:14:57 -0800 References: <5599FF5A-0501-4FE9-87C2-72FC3C2A8136@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5DAABEE3@XMB-AMS-107.cisco.com> <020701ca6881$50996320$f1cc2960$@alexander@ekasystems.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: "'Dan Lang \(dlang\)'" , roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 15:43:17 -0000 On Nov 18, 2009, at 10:59 AM, Roger K. Alexander wrote: > Hi Pascal, > > See link to a public reference as appearing in 'RFC Express' (a very > different RFC). The article provides references to the cited patents > (the > texts of which can be found on the web). > > http://www.rfcexpress.com/lawsuit-news.asp?id=3461 > > Since we do not practice any form of source routing we continue to > contest > the allegation, though it is believed others may have settled. Based > on what > we have seen, this type of litigation is an emerging part of the AMI > industry. Bummer. Since contesting infringement can be easier than validity and settlement can be attractive, the patent remains. Phil From richard.kelsey@ember.com Thu Nov 19 07:53:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228AB3A6AAB for ; Thu, 19 Nov 2009 07:53:38 -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 WhSexXqy9D6G for ; Thu, 19 Nov 2009 07:53:37 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 185FD3A6A75 for ; Thu, 19 Nov 2009 07:53:36 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:55:06 -0500 Date: Thu, 19 Nov 2009 10:49:53 -0500 Message-Id: <87einu3466.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> (message from JP Vasseur on Thu, 19 Nov 2009 15:49:15 +0100) From: Richard Kelsey References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> <24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> X-OriginalArrivalTime: 19 Nov 2009 15:55:06.0156 (UTC) FILETIME=[A9CC36C0:01CA6930] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 15:53:38 -0000 > From: JP Vasseur > Date: Thu, 19 Nov 2009 15:49:15 +0100 > > > On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote: > > > The issue isn't whether or not we need good P2P routing. > > The issue is whether or not the DAO mechanism does a good > > enough job to be worth the effort. > > > > RPL ignores P2P when choosing parents. Getting a good P2P > > route out of RPL is a matter of luck, not design. > > First, you can certainly tune the OF to increase the P2P quality. I haven't thought about it a lot, but it isn't at all clear to me how you would do this. I believe that we can get good P2P routes using RPL as a base. Doing so will require more than just coming up with an appropriate OF. > Second, in the VERY worst non probable case you would > transit via the root. We clearly have very different images of the DAGs that RPL will produce. The DAG formation mechanism works to maximize downward fanout, which in turn maximizes the number of P2P routes that go through the root even if all nodes store DAOs. For example, if the root has N children with roughly equal subgraphs, then each node can reach only 1/N of the network without through the root. > Last but not least, without DAO how do you send traffic > outward? Need to wait until you receive a packet, then > record route and do source routing? My point is that your argument in favor of requiring multiple DAO caches is also an argument that DAO is not adequate for P2P routing. You are claiming that we have to cache DAOs in non-root nodes because otherwise there is too much traffic through the root. If there is too much traffic through the root without the caching, then there is almost certainly too much even with the caching. Having nodes cache DAOs cannot be counted on to greatly reduce the traffic throught the root. If the DAO mechanism meets the requirements for P2P, then it meets those requirements with DAOs only cached at the root. -Richard Kelsey From pal@cs.stanford.edu Thu Nov 19 07:59:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920853A6A20 for ; Thu, 19 Nov 2009 07:59:51 -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 1YAdE0LwyfWD for ; Thu, 19 Nov 2009 07:59:51 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 019953A6878 for ; Thu, 19 Nov 2009 07:59:51 -0800 (PST) Received: from dnab42203a.stanford.edu ([171.66.32.58]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NB9QC-0006dI-W6; Thu, 19 Nov 2009 07:59:49 -0800 Message-Id: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 07:59:48 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 15:59:51 -0000 On Nov 19, 2009, at 6:57 AM, Julien Abeille (jabeille) wrote: > Hi all, > > - when the DAG is considered inconsistent, I think we do not double > I when I fires. Correct? When the node detects that there's an inconsistency (or another issue that requires routing updates), the node resets I to I_min and starts a new interval. You always double I when it fires. > - when do we increment C? The node MAY increment C when it hears another DIO. > - most importantly: how does a node know it is in consistent mode? When it doesn't detect any inconsistencies. :) Phil From roger.alexander@ekasystems.com Thu Nov 19 08:13:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346D83A68F5 for ; Thu, 19 Nov 2009 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsmYF7hrxuVC for ; Thu, 19 Nov 2009 08:13:54 -0800 (PST) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id 0481B3A6A71 for ; Thu, 19 Nov 2009 08:13:53 -0800 (PST) Received: (qmail 54201 invoked from network); 19 Nov 2009 16:13:49 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:13:49 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: sbZmn9IVM1mYQnKLk.HMjTH_J6AgyFSdlcmWZ7Lx7s0qDQw7m3Q9OahhdlSFmMke49kSzTyxCu3AFLVEctozRnXD1XsxirS.nR26I5cQEbbirihK2dISDsMXRAZmoGiXArPjOpyu1kluGDT6MwY46Zao78WLKHZMdU87quKvzqYV15Xeo1xF9zpdNKkH4rxVEUp_FL_SXfCkQ4tuoDTArJ75I8Knaypoqr2_gcER8kVmbv1cVd1blW3oRg.GY1.aGxv_SwanKh3J61Rb7H24_pDwEXxHbRLnpPGoeZKchgtFIfLDcTTNrRQNdSzSOCgVYBkpLD6oEG1G0BHEHMAML.fDnqP76HVLsaMcOiIJExQk39D3R2iFK9GCVitcaxDJuNJmkf0W4ywPjQjvxKCdieYdckJa8L_6O0OO_t.ZijeR4A-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'JP Vasseur'" , "'Richard Kelsey'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> In-Reply-To: <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> Date: Thu, 19 Nov 2009 11:16:24 -0500 Message-ID: <029401ca6933$a409e180$ec1da480$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppBDMBarPmPT2rTwC2SjB8uwUcYQAI8w3Q Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:13:55 -0000 > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, November 19, 2009 5:37 AM > To: Richard Kelsey > Cc: Roger Alexander; roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > On Nov 17, 2009, at 5:12 PM, Richard Kelsey wrote: > > >> From: Roger Alexander > >> Date: Mon, 16 Nov 2009 15:33:33 -0800 > >> > >> Not clear why there is a need to know who records DAOs. In response > >> to > >> a new child a parent that does maintain state will add itself to the > >> path information from the child and pass that information to it's > >> parent. That information will pass inward towards the root until a > >> node is encountered that can store the path information and > >> previously > >> supported connectivity to the node at the same cost. > > > > The difficulty is that, at present, there is no way of > > determining how much information needs to be passed up after > > a move. Here is the example I posted earlier. We start > > with this, where A is the root: > > > > A > > / \ > > B C > > | > > D > > | > > E > > > > Now D moves to C as its parent: > > > > A > > / \ > > B C > > | > > D > > | > > E > > > > If only A caches DAO data, then all D needs to do is send a > > DAO after the move. A receives it and changes its next hop > > for D and E to be C. > > Well I think that you still need the no-DAO since A may continue to > send > packets to D via both B and C. > > > > > If B and C both cache DAO data, then D needs to send a > > no-DAO before the move, to update B, and both D and E need > > to send DAOs after the move, so that C knows that it has > > downward paths to both of them. > > Note that with DAO packing only D will send one DAO for local prefixes > and E's prefixes but that's not the topic. > > > > > In the first case a single DAO needs to be sent. In the > > second case D has to send two DAOs and the nodes in its > > subdag, just E here, each need to send one. If only the > > root caches DAOs then the first case always applies. If > > other nodes may cache DAOs, then we have to assume that we > > are in the second case after every move. > The protocol must work without the need to send no-DAOs. In some cases the change of a parent is due to loss of link connectivity to the prior parent. In such cases, there is no opportunity for a no-DAO to be received. Instead, the new DAO information will be passed inward to the highest state-storing 'common ancestor' (as Jonathon correctly cites) node located at a rank above the old and new parent (which in some cases may indeed be the root). The common ancestor will then be able to correct subsequent outward routing. Any broken routing will be temporary. As indicated earlier, with larger multi-hop networks there will be more potential common ancestor nodes between the node changing its parent and the root. As such, a DAO issued as a result of a change of parent will need to travel only to the point at which such a state-storing common ancestor node is encountered. It some cases this may be the root but in all other cases the extent of the DAO update transmission is reduced relative to the case in which only the root maintains state. > Yes but I think that we need no-DAO to avoid nodes upper in the DAG to > continue > to use an old path anyway and the issues of the number of DAO is IMO > larger and > packing will sort it out. > > > > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Thu Nov 19 08:14:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6072628C0E6 for ; Thu, 19 Nov 2009 08:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgAh2qVHwL0s for ; Thu, 19 Nov 2009 08:14:35 -0800 (PST) Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by core3.amsl.com (Postfix) with SMTP id 7B5333A68F5 for ; Thu, 19 Nov 2009 08:14:34 -0800 (PST) Received: (qmail 36384 invoked from network); 19 Nov 2009 16:14:32 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:14:32 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: Qa16VS8VM1mzRxzxGI73hiB7_4sCAfehDuFWchiSiT6ncWdAXyiyXYsnu0JmKwI305bPz4hPWG0BwpuyZG3SO6rdF_KDLGwZEAJ3mXpY0vEYYUuIKb8pgEylM0E.Q0rtkvvkFVhkWpxcz7AbOgRqvBUDyUCGxeKjNc1xeZa5DTV1Vywxn0VD3ZOZw2loNUYrlORAO.kgAqnpRgw8tuuH08a__NUuOL63PvJ3JFYeErGyY8s5sJMUjh1a.sGvnrhsxVcS8Ikzm1QnB6MP6_YOWvfPfOCDixmsZE1r3phEqPTfSiLto0.D3Uyl_La90bhC2OvaPiSZiccibwwP5iAILA7R8qQkmQBuJ1tZbCcE_HPw5Cwx2ErxCh73_8YtMjktJX6M8Xx1Is8j01IpQoRT0hpqcoFAwMp7esZKWMRH1hoBqQ-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'JP Vasseur'" , "'Jonathan Hui'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> In-Reply-To: Date: Thu, 19 Nov 2009 11:17:07 -0500 Message-ID: <029501ca6933$bdab2900$39017b00$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppBDoogw8gaJ2BQxuNpDomZ7Pi/gAJrDUw Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:14:39 -0000 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur > Sent: Thursday, November 19, 2009 5:37 AM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > > > > > On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote: > > > >>> From: Roger Alexander > >>> Date: Mon, 16 Nov 2009 15:33:33 -0800 > >>> > >>> Not clear why there is a need to know who records DAOs. In > >>> response to > >>> a new child a parent that does maintain state will add itself to > the > >>> path information from the child and pass that information to it's > >>> parent. That information will pass inward towards the root until a > >>> node is encountered that can store the path information and > >>> previously > >>> supported connectivity to the node at the same cost. > >> > > > > [nice example of what DAOs need to be sent] > > > >> In the first case a single DAO needs to be sent. In the > >> second case D has to send two DAOs and the nodes in its > >> subdag, just E here, each need to send one. If only the > >> root caches DAOs then the first case always applies. If > >> other nodes may cache DAOs, then we have to assume that we > >> are in the second case after every move. > > > > I was in the process of creating a similar example. All I'll add is > > that, intuitively, the more places state gets "replicated" within > > the network, the more costly it is to maintain that state and the > > more you have to deal with inconsistencies between replicated > > instances. Of course, the hope in replicating this routing state is > > that it creates shorter paths and ultimately offsets the cost of > > maintaining that state. > > > > I'll have to admit that I'm not yet convinced of the benefits in > > storing DAO state as it currently exists in the draft. It seems > > like a mediocre attempt to optimize point-to-point routing and > > something that folks wanting P2P support aren't satisfied with. If > > that is the end-goal, then we should be developing better > > mechanisms. For now, we are focusing on one-to-many and many-to- > > one. And, I see more benefits to simply maintaining state at the > > root. > > I think even if the current focus is one-to-many and many-to-one, a default capability that allows less than optimal one-to-one routing is still worthwhile. Particularly in the context of larger networks in which nodes are not state-constrained, there will be latency and traffic benefits by avoiding always having to loop all traffic through the root. Furthermore, that default routing comes without the need to, as yet, introduce any special mechanisms. > > I do agree with the first statement but not with the second paragraph. > I do see several deployment cases where no storing DAO would lead to > extremely sub-optimal paths and even more importantly traffic > congestion when getting closer to the root of course. This is true > with several networks where the amount of P2P traffic may ned up being > not so negligible. The beauty with the current spec is that it allows > both deployment models. > > > -- > > Jonathan Hui > > > > _______________________________________________ > > 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 roger.alexander@ekasystems.com Thu Nov 19 08:21:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E9728C195 for ; Thu, 19 Nov 2009 08:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXjtyUMjbaQd for ; Thu, 19 Nov 2009 08:21:01 -0800 (PST) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id 2FEC928C19C for ; Thu, 19 Nov 2009 08:19:05 -0800 (PST) Received: (qmail 13500 invoked from network); 19 Nov 2009 16:18:59 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:18:59 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: mru5XGoVM1lU9O67y1zCUDljn_wpkQXhIG9mQ0.dInHKCq4ZE1YHlPkLfSZdj4sXr4rVloVWUTBSJAJVziqsjJCUnpYZfAaDiU9Bd4Q0z01jTJdUCb5PksieQOc2CTsFnAXHk9Az5v2s4atfIsYOGh8ds1uWm7GTelnoZJG97JZ5t9N2Cx2s3rTlMRe8B.dxeob1EwE79a0H02Q7nCiS3jaxLK.fbHFb3ISlvejc0XGx10NuHjbwUQucIfdtH6DHhL172mEWEpRIf9aZFXD8du31IB3vxuYodgZMLu1jyVzRlz3jg9r7Dvq64NpTJ_sksgrkyVmBeu03MGZuBupWwqikgY2ElYEtgJ3_K5O6tmO2EUfgmifTBXV9RoqrLVGwktP3WJSQhj6k84reG0N7IEIjGhYonzPN0IdK4A-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'JP Vasseur'" , "'Jonathan Hui'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> In-Reply-To: Date: Thu, 19 Nov 2009 11:21:35 -0500 Message-ID: <029601ca6934$5d36aa80$17a3ff80$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppBD+FK6JusUmcS6W5BA1DvNHaBAAKMcYw Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:21:02 -0000 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JP Vasseur > Sent: Thursday, November 19, 2009 5:37 AM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > On Nov 17, 2009, at 6:56 PM, Jonathan Hui wrote: > > > > > On Nov 17, 2009, at 9:20 AM, Pascal Thubert (pthubert) wrote: > > > >> When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH > >> (source route)), you see the source route RH2/4 grow upon movement > >> and > >> quickly shrink again as the NINA (DAO) states are reestablished. > >> When things are stable you only see as many entries as non DAO > >> capable > >> nodes along the path. In my case, the source route is done on a MIP/ > >> NEMO > >> tunnel, so the RH states are stored in eth binding cache on the home > >> agent. But we could store that at the root with exactly the same > >> process. > >> I can demo that next time we meet if you wish. > >> > >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header > >> details the RRH, since there is not LSRR in IPv6. > >> > >> Note that in our case, the information in the header should be > >> locally > >> significant, like a label. > > > > Here lies the disconnect. The real benefit of storing state among > > nodes within the network is to reduce the size of the source route > > header not some attempt to support point-to-point traffic. If you > > buy that, then the mechanism to establish such state could be much > > better than what's currently defined in the draft. In particular, > > there are some interesting things we could achieve if we start > > treating next-hop information using locally significant labels > > rather than globally significant IP addresses, as you suggested. > > But if done properly, I think we can specify such a mechanism as an > > optimization to basic source-route/record-route. > > I'm with you, well as someone used to work on MPLS, no surprise. > But still that does not solve the traffic matrix issue: not storing > DAO leads to all traffic transiting via the root, which is not > acceptable in many networks. Agreed. The emphasis needs to be on ensuring that we can reduce the DAO update information overhead which benefits networks in which nodes can maintain state as well as those in which only the root stores state. I still believe that there can be a DAO specification in which nodes that do not store state can include Reverse Route info that can then be alternately removed by state-maintaining nodes and added by stateless nodes as the DAO information is passed inward towards the root (to the highest rank state-maintaining common ancestor node that sits above an old and new parent). > > > > > -- > > Jonathan Hui > > > > _______________________________________________ > > 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 roger.alexander@ekasystems.com Thu Nov 19 08:21:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EE428C171 for ; Thu, 19 Nov 2009 08:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMcyT0N2stJ3 for ; Thu, 19 Nov 2009 08:21:11 -0800 (PST) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id 98EF728C1A6 for ; Thu, 19 Nov 2009 08:19:33 -0800 (PST) Received: (qmail 48819 invoked from network); 19 Nov 2009 16:19:29 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:19:28 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: EKJrrpUVM1k7cwYyPnvvXsE2RijVhKUhCb0fvHaFFeQNI2ZN55fEQc.mEqBclAhlEpz3D93QXIKheCBnOTo3GSA2Botu4Z333rwtKSc4aykvc3DGoV_Cbh1BWpd_L2iqMXTeB9aXQFRdm1HA8W6cqHV4mVLf7tY.wp895FRGp4J1.cHbRT5XQZnu4FoXrjMPCeCFJJmCXYpExoALCndHBm2UCRWrLeW80o5mKFBVFF.quMs2pHrBxFeooyN0.qXQ5jB_3vCES6lMZYEDNJ86q68O0WT50rUDhfuAF6tcwAm0V4RoRacyW6iQWtkKucDxuk5yBPFE2PAGtvi4LHV3e4lNQH.S2pwoYdyZJ3XN45kEH_EpUBg9rlN_Sb2RRHmjffqkvG8gXKEzuFS.7ZVFL5JNkZaJZUUoZ0n2Xw-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'JP Vasseur'" , "'Pascal Thubert \(pthubert\)'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABD57@XMB-AMS-107.cisco.com> <4A8BBD1A-96D1-4FEA-B36C-7EB3D0EE563B@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DAABEDA@XMB-AMS-107.cisco.com> <4911BF02-A4D5-4174-B357-8F3874C09421@cisco.com> In-Reply-To: <4911BF02-A4D5-4174-B357-8F3874C09421@cisco.com> Date: Thu, 19 Nov 2009 11:22:04 -0500 Message-ID: <029701ca6934$6e715f20$4b541d60$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01CA690A.859B5720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppBQ7y0p5/QPdeReOemOs1ThiWqwAK+Bjg Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:21:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0298_01CA690A.859B5720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, November 19, 2009 5:43 AM To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) [snip] If you buy that, then the mechanism to establish such state could be much better than what's currently defined in the draft. In particular, there are some interesting things we could achieve if we start treating next-hop information using locally significant labels rather than globally significant IP addresses, as you suggested. But if done properly, I think we can specify such a mechanism as an optimization to basic source-route/record-route. Looks good. The main consequence that I see at first glance is that The DAO should be sent to only one parent, because maintaining multiple Source route path down the DAG makes little sense for reasons discussed Earlier in this list (combinatory explosion, no end to end retries...) Would you agree on that? I do. Fairly simple, already supported. If the node cannot store the route then you go back to the root but the support of DAO must stay in the base spec for all networks that need it to (1) avoid too much traffic as you get closer to the root and (2) where the current P2P mechanisms provide a good enough path. I would be fully supportive of such an initial approach. JP. Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0298_01CA690A.859B5720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Thursday, November 19, 2009 5:43 AM
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] updating DAO caches (was Re: Something to = ADD)

 

[snip]

 



         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          If you buy

that, then the mechanism to establish such state = could be much better

than what's currently defined in the draft. =  In particular, there are

some interesting things we could achieve if we = start treating next-hop

information using locally significant labels rather = than globally

significant IP addresses, as you suggested. =  But if done properly, I

think we can specify such a mechanism as an = optimization to basic

source-route/record-route.


Looks good. The main consequence that I see at first glance is that
The DAO should be sent to only one parent, because maintaining = multiple
Source route path down the DAG makes little sense for reasons = discussed
Earlier in this list (combinatory explosion, no end to end = retries...)

Would you agree on that?

 

I do. Fairly simple, already supported. If the node = cannot store the route then you go back to the root 

but the support of DAO must stay in the base spec = for all networks that need it to (1) avoid too much

traffic as you get closer to the root and (2) where = the current P2P mechanisms provide a good enough

path.

 

 

I would be fully supportive of such an initial = approach.

 

 

JP.



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

 

------=_NextPart_000_0298_01CA690A.859B5720-- From roger.alexander@ekasystems.com Thu Nov 19 08:24:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41F73A6973 for ; Thu, 19 Nov 2009 08:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK7xstbD+8wo for ; Thu, 19 Nov 2009 08:24:48 -0800 (PST) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id A92223A6A71 for ; Thu, 19 Nov 2009 08:24:48 -0800 (PST) Received: (qmail 48232 invoked from network); 19 Nov 2009 16:24:44 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:24:43 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: UOC60G4VM1lvWSvZrFl..7KCPA22Huwc_WKBaTIHervNESmq2.oEn9OSll1_W91FJatzR1mSdLEHbkXmhP8UNjTJJe5spTtNwYN6zabsBbdpvnuaqthVzKLzNrzrW92XelC6dCa9D5gopSyqnDHaM57n68FU8fqidsrMHjJAHPesORIVtjUD5cX_6hOH4uLiRmogeL_1QjfkOKhViMucqGwcO98UMSOlAHOxS4DFbDDKDYipSPottqlh3m7PdOktKuvOHBw0JD1ihfA0p_T2OeMUNeE0yMBMjYBIIV_7Wvq4kX2b.LOUVaa3s6bUdMCuzUi50wJTkYNbG6adGaXX6TVd.bMLg9lbaRxSnzUZ6jqqXiRIM2a8tz5CqvkSG9fO_rjpki42TpmVE23AR0ShBjNsaWT1v7acV68ssJXq6nV5vw-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Richard Kelsey'" , "'JP Vasseur'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <1AA50243-72B0-460F-841C-2A5EE2E94943@cisco.com> <87iqd6wz3n.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87iqd6wz3n.fsf@kelsey-ws.hq.ember.com> Date: Thu, 19 Nov 2009 11:27:14 -0500 Message-ID: <029c01ca6935$2a40e680$7ec2b380$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppCTWyBnOBp1zPT9qz8NYtIwFFtwAKGKfQ Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:24:49 -0000 > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Thursday, November 19, 2009 6:09 AM > To: JP Vasseur > Cc: roger.alexander@ekasystems.com; roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > From: JP Vasseur > > Date: Thu, 19 Nov 2009 11:36:47 +0100 > > > > On Nov 17, 2009, at 5:12 PM, Richard Kelsey wrote: > > > > > The difficulty is that, at present, there is no way of > > > determining how much information needs to be passed up after > > > a move. Here is the example I posted earlier. We start > > > with this, where A is the root: > > > > > > A > > > / \ > > > B C > > > | > > > D > > > | > > > E > > > > > > Now D moves to C as its parent: > > > > > > A > > > / \ > > > B C > > > | > > > D > > > | > > > E > > > > > > If only A caches DAO data, then all D needs to do is send a > > > DAO after the move. A receives it and changes its next hop > > > for D and E to be C. > > > > Well I think that you still need the no-DAO since A may continue to > send > > packets to D via both B and C. > > Yes, if DAOs can be sent to multiple parents. No if DAOs > are only sent to one parent (because then A will only > store the most recently received path to D). No-DAOs cannot be a requirement even in the case of multiple parents since the link connectivity may not be there. Even with multiple parents the broken connectivity must be solved by the state-storing common ancestor to the old and new parents. With multiple parents information consistency will require that all current parents receive the DAO. > > > > no-DAO before the move, to update B, and both D and E need > > > to send DAOs after the move, so that C knows that it has > > > downward paths to both of them. > > > > Note that with DAO packing only D will send one DAO for local > prefixes > > and E's prefixes but that's not the topic. > > No, because D doesn't have a cache. E has to send its > prefixes, whether packing is present or not. > > > > In the first case a single DAO needs to be sent. In the > > > second case D has to send two DAOs and the nodes in its > > > subdag, just E here, each need to send one. If only the > > > root caches DAOs then the first case always applies. If > > > other nodes may cache DAOs, then we have to assume that we > > > are in the second case after every move. > > > > Yes but I think that we need no-DAO to avoid nodes upper > > in the DAG to continue to use an old path anyway and the > > issues of the number of DAO is IMO larger and packing will > > sort it out. > > The issue is only partly the number of DAO. It is also who > has to send them. If switching parents requires that every > node in the sub-DAG send a DAO, we need to take that cost > into account and avoid it when it is possible to do so. DAO > packing is not a magic bullet that makes DAOs free. > > -Richard Kelsey From roger.alexander@ekasystems.com Thu Nov 19 08:25:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D9C3A6A83 for ; Thu, 19 Nov 2009 08:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg-fmx-FXck4 for ; Thu, 19 Nov 2009 08:25:50 -0800 (PST) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by core3.amsl.com (Postfix) with SMTP id 1FB1C3A6885 for ; Thu, 19 Nov 2009 08:25:50 -0800 (PST) Received: (qmail 5911 invoked from network); 19 Nov 2009 16:25:46 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 19 Nov 2009 08:25:45 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 7KUgDdYVM1mguxSYUOeVqh77zuRWf_YQ3D5AdbV.F7uNEkcavpBItxgpY9UUlDoVU64..CFv0qEdX39CymVL_g_NdJtrUKYRThRfXPzptQ2LtNB4SqJBTMPd8Gzk1ACzWM77F.TKqJ.Qo2jLYsN_vmfx1bTpIRXF6FIayXvy3_Iy0nWYoWXGq4GlwhWz3hyU7tDCun_KQTLJBEBei0PtpmVfEBVlf9It4maJ.sRGjylvh8cqYIVJvq1rVff2QAt64eGvWrnwlpBNPiKqVRMIyae99QXqAHJQXoFg3x4CU5Kd4iS9Y.O62yPJYEHxmGdQ_eX3cUIK.1AC6MQx5qQNCWkm6LHGz2NJK8DgaqxQz3tqWBPz8W8rOqeMyoJSLvOfhAZDRqFKgMI74oAKdvvGu9u3LH67aVmhZkmWsQ-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Richard Kelsey'" , "'JP Vasseur'" References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> Date: Thu, 19 Nov 2009 11:28:20 -0500 Message-ID: <029d01ca6935$4f4f9840$edeec8c0$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppJvOYbQK8/dU1Tei6hFvXiJ3Y8gACzafQ Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 16:25:51 -0000 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Thursday, November 19, 2009 9:42 AM > To: JP Vasseur > Cc: roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > From: JP Vasseur > > Date: Thu, 19 Nov 2009 13:18:56 +0100 > > > > On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: > > > > JP> From: JP Vasseur > > JP> Date: Thu, 19 Nov 2009 11:36:49 +0100 > > JP> > > JP> I do see several deployment cases where no storing DAO would lead > to > > JP> extremely sub-optimal paths and even more importantly traffic > > JP> congestion when getting closer to the root of course. > > > > Richard> Can you share these cases with us? I agree with Jonathan > > Richard> that storing DAO states will typically not provide much > > Richard> improvement in P2P routing. > > > > Sure. I'll take the example of an inter primary+secondary > > substation network (could be the smart metering network) > > that supports traffic for various purposes: meter > > read-out, DA alarms, ... etc. Thus traffic of various > > nature: P2MP, MP2P and P2P. > > Yes, I think we all agree that reasonably efficient > P2P is a requirement for many use cases. > > The issue isn't whether or not we need good P2P routing. > The issue is whether or not the DAO mechanism does a good > enough job to be worth the effort. > > RPL ignores P2P when choosing parents. Getting a good P2P > route out of RPL is a matter of luck, not design. > > > There are many such networks > > where not storing DAO just does not work since all P2P > > traffic will have to transit via the root (unacceptable > > delays for alarms) and the traffic around the root will be > > way too high. > > Yes, and in many cases most P2P traffic will have to transit > via the root even if all nodes store DAOs. This is a side > effect of how RPL chooses parents. Minimizing the lengths > of the paths to the root maximizes the number of pairwise > paths that include the root. If this is unacceptable, then > we should stop tweaking the DAOs and work on a better > solution. Until a focused P2P mechanism is introduced I would agree that the potential for P2P traffic flowing through the root will be a consequence that has to be accepted. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Nov 19 09:21:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1002D3A68D9 for ; Thu, 19 Nov 2009 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.004 X-Spam-Level: X-Spam-Status: No, score=-8.004 tagged_above=-999 required=5 tests=[AWL=-1.405, 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 0MFN6vUdFtHv for ; Thu, 19 Nov 2009 09:21:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ECA963A687C for ; Thu, 19 Nov 2009 09:21:26 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEsNBUutJV2d/2dsb2JhbAC+RZdxhDsE X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="68991919" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2009 17:21:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id nAJHLE7s030175; Thu, 19 Nov 2009 17:21:23 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 18:21:22 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 18:21:21 +0100 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87einu3466.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 18:21:21 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <87fx8a37bu.fsf@kelsey-ws.hq.ember.com> <24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> <87einu3466.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 17:21:21.0728 (UTC) FILETIME=[B6ADD400:01CA693C] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 17:21:28 -0000 On Nov 19, 2009, at 4:49 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Thu, 19 Nov 2009 15:49:15 +0100 >> >> >> On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote: >> >>> The issue isn't whether or not we need good P2P routing. >>> The issue is whether or not the DAO mechanism does a good >>> enough job to be worth the effort. >>> >>> RPL ignores P2P when choosing parents. Getting a good P2P >>> route out of RPL is a matter of luck, not design. >> >> First, you can certainly tune the OF to increase the P2P quality. > > I haven't thought about it a lot, but it isn't at all clear > to me how you would do this. > > I believe that we can get good P2P routes using RPL as a > base. Doing so will require more than just coming up with > an appropriate OF. I need to provide more data to back this up. Will do shortly. > >> Second, in the VERY worst non probable case you would >> transit via the root. > > We clearly have very different images of the DAGs that RPL > will produce. The DAG formation mechanism works to maximize > downward fanout, which in turn maximizes the number of P2P > routes that go through the root even if all nodes store > DAOs. For example, if the root has N children with roughly > equal subgraphs, then each node can reach only 1/N of the > network without through the root. > In the very worst case (your ancestor is the root) you have to go through the root. If you have DAO and cache routes, you have a shortcut. >> Last but not least, without DAO how do you send traffic >> outward? Need to wait until you receive a packet, then >> record route and do source routing? > > My point is that your argument in favor of requiring > multiple DAO caches is also an argument that DAO is not > adequate for P2P routing. > > You are claiming that we have to cache DAOs in non-root > nodes because otherwise there is too much traffic through > the root. If there is too much traffic through the root > without the caching, then there is almost certainly too much > even with the caching. Having nodes cache DAOs cannot be > counted on to greatly reduce the traffic throught the root. > Why makes you think this ? > If the DAO mechanism meets the requirements for P2P, then it > meets those requirements with DAOs only cached at the root. > > -Richard Kelsey From mdurvy@cisco.com Thu Nov 19 09:24:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E933B28C0E7 for ; Thu, 19 Nov 2009 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 C5sWWI8RTiim for ; Thu, 19 Nov 2009 09:24:55 -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 C37943A6882 for ; Thu, 19 Nov 2009 09:24:54 -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: AkAAADoOBUuQ/uCWe2dsb2JhbACcCwEBCwskBqF1l3GEOwSMdg X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="54775906" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 17:24:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJHOpTO002310; Thu, 19 Nov 2009 17:24:51 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 18:24:51 +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: Thu, 19 Nov 2009 18:24:50 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> In-Reply-To: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle clarification: (in)consistency Thread-Index: AcppMVdXmBTY30jERpCxDSGexl8nWQACyNbg References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu> From: "Mathilde Durvy (mdurvy)" To: "Philip Levis" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 19 Nov 2009 17:24:51.0307 (UTC) FILETIME=[33990BB0:01CA693D] Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 17:24:56 -0000 Hi Phil, =20 > - when do we increment C? The node MAY increment C when it hears another DIO. I think the spec says that a node MAY increment C each time it hears a "consistent DIO for this DAG from a DAG parent". What fields are included in the consistency check? If only generic DAG information are checked you might want to look at DIO from non-DAG parents, no? Best, Mathilde _______________________________________________ From jabeille@cisco.com Thu Nov 19 09:42:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024D63A66B4 for ; Thu, 19 Nov 2009 09:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 NToWBNcsJJLN for ; Thu, 19 Nov 2009 09:42:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E159C3A6837 for ; Thu, 19 Nov 2009 09:42:43 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOoSBUtAZnwN/2dsb2JhbAC+OpdxhDsE X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="68937798" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2009 17:42:35 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAJHgYvJ007332; Thu, 19 Nov 2009 17:42:35 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 18:42:34 +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: Thu, 19 Nov 2009 18:42:32 +0100 Message-ID: In-Reply-To: <87einu3466.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches (was Re: Something to ADD) Thread-Index: AcppMHmPiy5P5JamS8WzVAVkO3wAVgADrKuw References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com><874op2l1s2.fsf@kelsey-ws.hq.ember.com><87hbt22djo.fsf@kelsey-ws.hq.ember.com><87ljidpg45.fsf@kelsey-ws.hq.ember.com><10442.1257951943@marajade.sandelman.ca><87r5s31ly9.fsf@kelsey-ws.hq.ember.com><31012.1258061765@marajade.sandelman.ca><87my2q43mv.fsf@kelsey-ws.hq.ember.com><13293.1258166652@marajade.sandelman.ca><59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com><874oot3zcf.fsf@kelsey-ws.hq.ember.com><10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com><87k4xmwzgl.fsf@kelsey-ws.hq.ember.com><9D5D1087-7501-4584-960E-A007B86560DC@cisco.com><87fx8a37bu.fsf@kelsey-ws.hq.ember.com><24E78E01-9E84-4BFD-BAAA-950584DCD99D@cisco.com> <87einu3466.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Richard Kelsey" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 19 Nov 2009 17:42:34.0447 (UTC) FILETIME=[AD4755F0:01CA693F] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 17:42:45 -0000 Hi Richard, Pure source routing is supported in the draft. I think it's much less random to maintain this with specific messages (non stored DAOs) than with application traffic. This way the root always has a route to every node. What are you missing for your scenario? Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: jeudi 19 novembre 2009 16:50 > To: JP Vasseur (jvasseur) > Cc: roll@ietf.org > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) >=20 > > From: JP Vasseur > > Date: Thu, 19 Nov 2009 15:49:15 +0100 > >=20 > >=20 > > On Nov 19, 2009, at 3:41 PM, Richard Kelsey wrote: > >=20 > > > The issue isn't whether or not we need good P2P routing. > > > The issue is whether or not the DAO mechanism does a good=20 > enough job=20 > > > to be worth the effort. > > > > > > RPL ignores P2P when choosing parents. Getting a good=20 > P2P route out=20 > > > of RPL is a matter of luck, not design. > >=20 > > First, you can certainly tune the OF to increase the P2P quality. >=20 > I haven't thought about it a lot, but it isn't at all clear=20 > to me how you would do this. >=20 > I believe that we can get good P2P routes using RPL as a=20 > base. Doing so will require more than just coming up with an=20 > appropriate OF. >=20 > > Second, in the VERY worst non probable case you would=20 > transit via the=20 > > root. >=20 > We clearly have very different images of the DAGs that RPL=20 > will produce. The DAG formation mechanism works to maximize=20 > downward fanout, which in turn maximizes the number of P2P=20 > routes that go through the root even if all nodes store DAOs.=20 > For example, if the root has N children with roughly equal=20 > subgraphs, then each node can reach only 1/N of the network=20 > without through the root. >=20 > > Last but not least, without DAO how do you send traffic=20 > outward? Need=20 > > to wait until you receive a packet, then record route and do source=20 > > routing? >=20 > My point is that your argument in favor of requiring multiple=20 > DAO caches is also an argument that DAO is not adequate for=20 > P2P routing. >=20 > You are claiming that we have to cache DAOs in non-root nodes=20 > because otherwise there is too much traffic through the root.=20 > If there is too much traffic through the root without the=20 > caching, then there is almost certainly too much even with=20 > the caching. Having nodes cache DAOs cannot be counted on to=20 > greatly reduce the traffic throught the root. >=20 > If the DAO mechanism meets the requirements for P2P, then it=20 > meets those requirements with DAOs only cached at the root. >=20 > -Richard Kelsey=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From ietf-roll@mulligan.org Thu Nov 19 11:23:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AC228C164 for ; Thu, 19 Nov 2009 11:23: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=[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 nugp9+uJtu2R for ; Thu, 19 Nov 2009 11:23:33 -0800 (PST) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 516D63A68BE for ; Thu, 19 Nov 2009 11:23:33 -0800 (PST) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 00A58A10C1; Thu, 19 Nov 2009 12:23:36 -0700 (MST) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlkRRWQU32FG; Thu, 19 Nov 2009 12:23:34 -0700 (MST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id E7D75A10BE; Thu, 19 Nov 2009 12:23:33 -0700 (MST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id nAJJNQmw027676; Thu, 19 Nov 2009 12:23:27 -0700 (MST) Resent-Date: Thu, 19 Nov 2009 12:23:27 -0700 (MST) Resent-Message-Id: <200911191923.nAJJNQmw027676@server1.coslabs.com> From: Geoff Mulligan To: "Julien Abeille (jabeille)" In-Reply-To: References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> Content-Type: text/plain Message-Id: <1258655418.3792.4.camel@dellx1> Mime-Version: 1.0 Resent-From: Geoff Mulligan Resent-To: "Julien Abeille (jabeille)" Resent-Cc: "JP Vasseur (jvasseur)" , Richard Kelsey , roll@ietf.org Date: Thu, 19 Nov 2009 12:23:22 -0700 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 19:23:34 -0000 While I agree that in most networks you would want to store DAOs so that you can send packets in both directions, I can also see networks that likely just collect data from sensor end-nodes and DAOs would be unnecessary. But I agree with Richard, that for many P2P applications even storing DAOs will not provide even a "good enough" P2P route and that some other alternative routing mechanism/protocol is necessary. geoff On Thu, 2009-11-19 at 15:55 +0100, Julien Abeille (jabeille) wrote: > Hi JP, all, > > I agree that we should keep DAOs in RPL. A routing protocol that > installs routes in one direction only makes no sense to me. By the way > if in a deployment some do not want to store DAOs, they can. > > Best, > Julien > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > Behalf Of JP Vasseur (jvasseur) > > Sent: jeudi 19 novembre 2009 13:19 > > To: Richard Kelsey > > Cc: roll@ietf.org > > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > > > > > > On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: > > > > >> From: JP Vasseur > > >> Date: Thu, 19 Nov 2009 11:36:49 +0100 > > >> > > >> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > > >> > > >>> I'll have to admit that I'm not yet convinced of the benefits in > > >>> storing DAO state as it currently exists in the draft. [...] > > >>> > > >> I do agree with the first statement but not with the second > > >> paragraph. > > >> I do see several deployment cases where no storing DAO > > would lead to > > >> extremely sub-optimal paths and even more importantly traffic > > >> congestion when getting closer to the root of course. > > > > > > Can you share these cases with us? I agree with Jonathan > > that storing > > > DAO states will typically not provide much improvement in > > P2P routing. > > > > Sure. I'll take the example of an inter primary+secondary > > substation network (could be the smart metering network) that > > supports traffic for various purposes: > > meter read-out, DA alarms, ... etc. Thus traffic of various nature: > > P2MP, MP2P > > and P2P. There are many such networks where not storing DAO > > just does not work since all P2P traffic will have to transit > > via the root (unacceptable delays for > > alarms) and the traffic around the root will be way too high. > > > > This is why I am saying that having an RFC that forms a DAG > > that cannot be used for outward traffic is a non-starter. > > > > > > > >> I do see several deployment cases where no storing DAO > > would lead to > > >> extremely sub-optimal paths and even more importantly traffic > > >> congestion when getting closer to the root of course. This is true > > >> with several networks where the amount of P2P traffic may ned up > > >> being > > >> not so negligible. The beauty with the current spec is > > that it allows > > >> both deployment models. > > > > > > It claims to allow both, but fails to actually do so. That > > > is the point of the example that I gave and the reason I > > > keep going on about this. While the draft says that > > > intermediate nodes can cache DAOs, it doesn't say how those > > > caches are updated after a node changes parents. And > > > however this is done, we need to avoid the cost of sending > > > cache updates in the absense of any actual caches. > > > > Yes I agree with you on this and this is why DAO packing is also > > important. > > Thus I would propose to all work on this and make it work > > while still > > allowing > > some nodes to not store any DAO is they want to of course. > > > > Does that make sense ? > > > > Cheers. > > > > JP. > > > > > > > > -Richard Kelsey > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Nov 19 11:26:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C144528C15E for ; Thu, 19 Nov 2009 11:26:10 -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 Uzhwj3uTDg0F for ; Thu, 19 Nov 2009 11:26:09 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B328028C178 for ; Thu, 19 Nov 2009 11:26:09 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 14:27:39 -0500 Date: Thu, 19 Nov 2009 14:22:25 -0500 Message-Id: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 19 Nov 2009 19:27:39.0140 (UTC) FILETIME=[5B2B2440:01CA694E] Subject: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 19:26:10 -0000 Below is an actual concrete proposal for managing DAO caches. I believe that this would work well when all nodes cache DAOs and when no nodes do so. It does a reasonable job when only some nodes cache DAOs, although in some situations there will be some superfluous DAOs transmitted. This assumes that DAOs are sent only to the preferred parent. If DAO are sent to multiple parents the situation becomes more complex. In a network with no DAO caches the new (C) flag is never set. Whenever a node moves it sends a single DAO that propagates to the root, which stores the nodes new location. In a network where all nodes cache DAOs, a node that moves sends the contents of its cache to its new parent. These propagate up the tree, with each node forwarding on only those prefixes which are new to its cache. The forwarding stops when it reaches the least common ancestor of the node's old and new locations. In a mixed network, nodes with caches and nodes whose only caching ancestor is the root will have the same behavior as above. A node without a cache will send its own DAO and set the Destination Advertisement Trigger to cause its sub-DAG to send DAOs as well. The Trigger will propagate downwards causing more DAOs to be sent, but descedents that have a cache will not propagate the Trigger to their own sub-DAG. -Richard Kelsey ---------------- Proposal: Add a new DIO flag: Destination Advertisements Cache (C): The Destination Advertisement Cache (C) flag is set when a node below the DAG root in the successor chain caches DAOs sent upwards. DAG roots NUST NOT set this flag. Nodes below the root that maintain a DAO cache MUST set this flag. Nodes below the root that do not maintain a DAO cache MUST set this flag to the value received from their preferred DAG Parent. In 5.10.1.1. replace A node that modifies its DAG Parent set may set the `D' bit in subsequent DIO propagation in order to trigger destination advertisements to be updated to its DAG Parents and other ancestors on the DAG. Additional recommendations and guidelines regarding the use of this mechanism are still under consideration and will be elaborated in a future revision of this specification. with When a node selects a new preferred parent it MUST send that parent a unicast DIO. If the node maintains a DIO cache the DIO sent MUST include the prefixes in the DAO cache. If the node does not maintain a DIO cache and either the new preferred parent's DIO or the old preferred parent's DIO has the Destination Advertisements Cache set, then the node MUST set the Destination Advertisement Trigger in its own subsequent DIO. ---------------- From mcr@marajade.sandelman.ca Thu Nov 19 13:31:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438813A6851 for ; Thu, 19 Nov 2009 13:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.453, 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 oQ+z9+EkEyPi for ; Thu, 19 Nov 2009 13:31:18 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 35BA83A699D for ; Thu, 19 Nov 2009 13:31:17 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D0EA6342BB; Thu, 19 Nov 2009 16:22:57 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EC6514E796; Thu, 19 Nov 2009 16:31:13 -0500 (EST) From: Michael Richardson To: Richard Kelsey In-Reply-To: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 19 Nov 2009 16:31:13 -0500 Message-ID: <2765.1258666273@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 21:31:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" == Richard Kelsey writes: Richard> In a network where all nodes cache DAOs, a node that moves Richard> sends the contents of its cache to its new parent. These Richard> propagate up the tree, with each node forwarding on only Richard> those prefixes which are new to its cache. The forwarding Richard> stops when it reaches the least common ancestor of the Richard> node's old and new locations. Please confirm... at the least common ancestor, the contents of the cache change, but nothing is new..? Richard> In a mixed network, nodes with caches and nodes whose only Richard> caching ancestor is the root will have the same behavior Richard> as above. A node without a cache will send its own DAO and Richard> set the Destination Advertisement Trigger to cause its So, in effect, a node that does not cache, has a cache size of 0, so all DAOs are always "new" I think this works. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwW5IYCLcPvd0N1lAQJvnQgAr0h5sziEUfQMXMRihoA8P6BQXjHyclvm mLZ/pWURJu86DebH15uxpmSOJ+QDT/bTX7jAb6u2f1IBKutkH7e43nVXN5WBeLZZ QwVlFosw5WD+fihEueG9af4Ah19nPPchJSSadnaOjXWE8om0akPEdJ8X84tXHjIQ dECjapijLFyS/wcXPCkH/5ijijCebW4QjUJG+Ssv3vovcvxUd2C0miBR8vUcInh8 5K0MlDuzptG5mKJXgzNraXMx0xQMnNQQQ7yPXanUqKDHTNrypw/kaLUriMut2VJ/ eW9Zkr1wnX2BmKS/2yykq7lMTYSni70QlsZGWwwzKCNhyNIidGrHBw== =0DwC -----END PGP SIGNATURE----- From jvasseur@cisco.com Thu Nov 19 13:31:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D4A3A6851 for ; Thu, 19 Nov 2009 13:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.926 X-Spam-Level: X-Spam-Status: No, score=-7.926 tagged_above=-999 required=5 tests=[AWL=-1.327, 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 d+8qF0Wb29QB for ; Thu, 19 Nov 2009 13:31:48 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7FDE93A699D for ; Thu, 19 Nov 2009 13:31:48 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAONHBUurR7Ht/2dsb2JhbAC+FZd1hDsE X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="272969961" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Nov 2009 21:31:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJLVj5p015460; Thu, 19 Nov 2009 21:31:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 22:31:45 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 22:31:44 +0100 Message-Id: From: JP Vasseur To: Geoff Mulligan In-Reply-To: <1258655418.3792.4.camel@dellx1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 22:31:43 +0100 References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <1258655418.3792.4.camel@dellx1> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Nov 2009 21:31:45.0037 (UTC) FILETIME=[B144DBD0:01CA695F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17018.007 X-TM-AS-Result: No--22.474100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 21:31:49 -0000 On Nov 19, 2009, at 8:23 PM, Geoff Mulligan wrote: > While I agree that in most networks you would want to store DAOs so > that > you can send packets in both directions, I can also see networks that > likely just collect data from sensor end-nodes and DAOs would be > unnecessary. They surely exist but ... back to our requirement documents we need more than unidirectional flows ... > > But I agree with Richard, that for many P2P applications even storing > DAOs will not provide even a "good enough" P2P route and that some > other > alternative routing mechanism/protocol is necessary. would you have any evidence of this ? > > geoff > > On Thu, 2009-11-19 at 15:55 +0100, Julien Abeille (jabeille) wrote: >> Hi JP, all, >> >> I agree that we should keep DAOs in RPL. A routing protocol that >> installs routes in one direction only makes no sense to me. By the >> way >> if in a deployment some do not want to store DAOs, they can. >> >> Best, >> Julien >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of JP Vasseur (jvasseur) >>> Sent: jeudi 19 novembre 2009 13:19 >>> To: Richard Kelsey >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) >>> >>> >>> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: >>> >>>>> From: JP Vasseur >>>>> Date: Thu, 19 Nov 2009 11:36:49 +0100 >>>>> >>>>> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: >>>>> >>>>>> I'll have to admit that I'm not yet convinced of the benefits in >>>>>> storing DAO state as it currently exists in the draft. [...] >>>>>> >>>>> I do agree with the first statement but not with the second >>>>> paragraph. >>>>> I do see several deployment cases where no storing DAO >>> would lead to >>>>> extremely sub-optimal paths and even more importantly traffic >>>>> congestion when getting closer to the root of course. >>>> >>>> Can you share these cases with us? I agree with Jonathan >>> that storing >>>> DAO states will typically not provide much improvement in >>> P2P routing. >>> >>> Sure. I'll take the example of an inter primary+secondary >>> substation network (could be the smart metering network) that >>> supports traffic for various purposes: >>> meter read-out, DA alarms, ... etc. Thus traffic of various nature: >>> P2MP, MP2P >>> and P2P. There are many such networks where not storing DAO >>> just does not work since all P2P traffic will have to transit >>> via the root (unacceptable delays for >>> alarms) and the traffic around the root will be way too high. >>> >>> This is why I am saying that having an RFC that forms a DAG >>> that cannot be used for outward traffic is a non-starter. >>> >>>> >>>>> I do see several deployment cases where no storing DAO >>> would lead to >>>>> extremely sub-optimal paths and even more importantly traffic >>>>> congestion when getting closer to the root of course. This is true >>>>> with several networks where the amount of P2P traffic may ned up >>>>> being >>>>> not so negligible. The beauty with the current spec is >>> that it allows >>>>> both deployment models. >>>> >>>> It claims to allow both, but fails to actually do so. That >>>> is the point of the example that I gave and the reason I >>>> keep going on about this. While the draft says that >>>> intermediate nodes can cache DAOs, it doesn't say how those >>>> caches are updated after a node changes parents. And >>>> however this is done, we need to avoid the cost of sending >>>> cache updates in the absense of any actual caches. >>> >>> Yes I agree with you on this and this is why DAO packing is also >>> important. >>> Thus I would propose to all work on this and make it work >>> while still >>> allowing >>> some nodes to not store any DAO is they want to of course. >>> >>> Does that make sense ? >>> >>> Cheers. >>> >>> JP. >>> >>>> >>>> -Richard Kelsey >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@marajade.sandelman.ca Thu Nov 19 13:33:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94A13A69EC for ; Thu, 19 Nov 2009 13:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.339, 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 Ggm18RcQbslg for ; Thu, 19 Nov 2009 13:33:34 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 499BF3A699D for ; Thu, 19 Nov 2009 13:33:34 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C3322342D6; Thu, 19 Nov 2009 16:25:14 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 1D33E4E796; Thu, 19 Nov 2009 16:33:31 -0500 (EST) From: Michael Richardson To: Richard Kelsey In-Reply-To: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 19 Nov 2009 16:33:31 -0500 Message-ID: <2912.1258666411@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 21:33:35 -0000 Let me add that Richard's preamble text is good, clear discussion that also belongs in the draft. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From richard.kelsey@ember.com Thu Nov 19 13:51:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495D13A6808 for ; Thu, 19 Nov 2009 13:51:27 -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 BoLN7Dyw9HEK for ; Thu, 19 Nov 2009 13:51:26 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 71FA73A67A5 for ; Thu, 19 Nov 2009 13:51:26 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 16:52:55 -0500 Date: Thu, 19 Nov 2009 16:47:41 -0500 Message-Id: <878we22nlu.fsf@kelsey-ws.hq.ember.com> To: Michael Richardson In-reply-to: <2765.1258666273@marajade.sandelman.ca> (message from Michael Richardson on Thu, 19 Nov 2009 16:31:13 -0500) From: Richard Kelsey References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> <2765.1258666273@marajade.sandelman.ca> X-OriginalArrivalTime: 19 Nov 2009 21:52:55.0874 (UTC) FILETIME=[A6BF3220:01CA6962] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 21:51:27 -0000 > From: Michael Richardson > Date: Thu, 19 Nov 2009 16:31:13 -0500 > > >>>>> "Richard" == Richard Kelsey writes: > Richard> In a network where all nodes cache DAOs, a node that moves > Richard> sends the contents of its cache to its new parent. These > Richard> propagate up the tree, with each node forwarding on only > Richard> those prefixes which are new to its cache. The forwarding > Richard> stops when it reaches the least common ancestor of the > Richard> node's old and new locations. > > Please confirm... at the least common ancestor, the contents of the > cache change, but nothing is new..? At the least common ancestor the prefixes in the cache do not change, but the associated next hops do. Because DAOs contain only the prefixes, and not the next hops, the least common ancestor does not need to send a new one. -Richard Kelsey From ietf-roll@mulligan.org Thu Nov 19 13:55:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E233F3A69E7 for ; Thu, 19 Nov 2009 13:55:21 -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 wcbQ6MqxMOt2 for ; Thu, 19 Nov 2009 13:55:20 -0800 (PST) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id B766A3A67A1 for ; Thu, 19 Nov 2009 13:55:20 -0800 (PST) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id D5086A10C1; Thu, 19 Nov 2009 14:55:24 -0700 (MST) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKQX4jIUYmQl; Thu, 19 Nov 2009 14:55:22 -0700 (MST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id C18ACA109E; Thu, 19 Nov 2009 14:55:22 -0700 (MST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id nAJLtFx4029031; Thu, 19 Nov 2009 14:55:15 -0700 (MST) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: <34039830-7A8C-488B-A080-04013FBFC769@cisco.com> <874op2l1s2.fsf@kelsey-ws.hq.ember.com> <87hbt22djo.fsf@kelsey-ws.hq.ember.com> <87ljidpg45.fsf@kelsey-ws.hq.ember.com> <10442.1257951943@marajade.sandelman.ca> <87r5s31ly9.fsf@kelsey-ws.hq.ember.com> <31012.1258061765@marajade.sandelman.ca> <87my2q43mv.fsf@kelsey-ws.hq.ember.com> <13293.1258166652@marajade.sandelman.ca> <59CDC556-1C4E-4DE7-A3A2-30D6AA86F3A3@ekasystems.com> <874oot3zcf.fsf@kelsey-ws.hq.ember.com> <10F8F803-5EE2-4E71-8BF4-DB94D749DD62@archrock.com> <87k4xmwzgl.fsf@kelsey-ws.hq.ember.com> <9D5D1087-7501-4584-960E-A007B86560DC@cisco.com> <1258655418.3792.4.camel@dellx1> Content-Type: text/plain Date: Thu, 19 Nov 2009 14:55:11 -0700 Message-Id: <1258667711.3792.95.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Nov 2009 21:55:22 -0000 As I understand the requirements for building automation or home control or industrial control there are requirements for two way flows. Collection is flow and control is a flow - do you consider these as two unidirectional flows? As for "evidence" about the need for an alternative protocol, the fact that it appears we will have sub-optimal P2P routing (need to traverse potentially to the DAG root or at best case a common parent in the DAG) would strongly indicate that for building and home control applications and smart grid control applications DAGs will very likely not provide the needed performance - both Richard and Jerry have said this. Since no one has yet been able to implement RPL we don't have proof and I am fully supportive of getting RPL done so that we can see what it can and can't do. we need to understand and be ready to start work on a solution if RPL cannot adequately support bidirectional and P2P flows. geoff On Thu, 2009-11-19 at 22:31 +0100, JP Vasseur wrote: > On Nov 19, 2009, at 8:23 PM, Geoff Mulligan wrote: > > > While I agree that in most networks you would want to store DAOs so > > that > > you can send packets in both directions, I can also see networks that > > likely just collect data from sensor end-nodes and DAOs would be > > unnecessary. > > They surely exist but ... back to our requirement documents we need > more than unidirectional flows ... > > > > > But I agree with Richard, that for many P2P applications even storing > > DAOs will not provide even a "good enough" P2P route and that some > > other > > alternative routing mechanism/protocol is necessary. > > would you have any evidence of this ? > > > > > geoff > > > > On Thu, 2009-11-19 at 15:55 +0100, Julien Abeille (jabeille) wrote: > >> Hi JP, all, > >> > >> I agree that we should keep DAOs in RPL. A routing protocol that > >> installs routes in one direction only makes no sense to me. By the > >> way > >> if in a deployment some do not want to store DAOs, they can. > >> > >> Best, > >> Julien > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > >>> Behalf Of JP Vasseur (jvasseur) > >>> Sent: jeudi 19 novembre 2009 13:19 > >>> To: Richard Kelsey > >>> Cc: roll@ietf.org > >>> Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) > >>> > >>> > >>> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote: > >>> > >>>>> From: JP Vasseur > >>>>> Date: Thu, 19 Nov 2009 11:36:49 +0100 > >>>>> > >>>>> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote: > >>>>> > >>>>>> I'll have to admit that I'm not yet convinced of the benefits in > >>>>>> storing DAO state as it currently exists in the draft. [...] > >>>>>> > >>>>> I do agree with the first statement but not with the second > >>>>> paragraph. > >>>>> I do see several deployment cases where no storing DAO > >>> would lead to > >>>>> extremely sub-optimal paths and even more importantly traffic > >>>>> congestion when getting closer to the root of course. > >>>> > >>>> Can you share these cases with us? I agree with Jonathan > >>> that storing > >>>> DAO states will typically not provide much improvement in > >>> P2P routing. > >>> > >>> Sure. I'll take the example of an inter primary+secondary > >>> substation network (could be the smart metering network) that > >>> supports traffic for various purposes: > >>> meter read-out, DA alarms, ... etc. Thus traffic of various nature: > >>> P2MP, MP2P > >>> and P2P. There are many such networks where not storing DAO > >>> just does not work since all P2P traffic will have to transit > >>> via the root (unacceptable delays for > >>> alarms) and the traffic around the root will be way too high. > >>> > >>> This is why I am saying that having an RFC that forms a DAG > >>> that cannot be used for outward traffic is a non-starter. > >>> > >>>> > >>>>> I do see several deployment cases where no storing DAO > >>> would lead to > >>>>> extremely sub-optimal paths and even more importantly traffic > >>>>> congestion when getting closer to the root of course. This is true > >>>>> with several networks where the amount of P2P traffic may ned up > >>>>> being > >>>>> not so negligible. The beauty with the current spec is > >>> that it allows > >>>>> both deployment models. > >>>> > >>>> It claims to allow both, but fails to actually do so. That > >>>> is the point of the example that I gave and the reason I > >>>> keep going on about this. While the draft says that > >>>> intermediate nodes can cache DAOs, it doesn't say how those > >>>> caches are updated after a node changes parents. And > >>>> however this is done, we need to avoid the cost of sending > >>>> cache updates in the absense of any actual caches. > >>> > >>> Yes I agree with you on this and this is why DAO packing is also > >>> important. > >>> Thus I would propose to all work on this and make it work > >>> while still > >>> allowing > >>> some nodes to not store any DAO is they want to of course. > >>> > >>> Does that make sense ? > >>> > >>> Cheers. > >>> > >>> JP. > >>> > >>>> > >>>> -Richard Kelsey > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > >>> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Fri Nov 20 07:41:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7BC3A6A85 for ; Fri, 20 Nov 2009 07:41:28 -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 DBRoAwgxA9ce for ; Fri, 20 Nov 2009 07:41:28 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 10A7C3A68CC for ; Fri, 20 Nov 2009 07:41:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B19CDAF83D; Fri, 20 Nov 2009 07:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0zGBptef3yW; Fri, 20 Nov 2009 07:41:21 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id ECED0AF833; Fri, 20 Nov 2009 07:41:20 -0800 (PST) Message-Id: From: Jonathan Hui To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 07:41:19 -0800 References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu> <8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 15:41:28 -0000 Hi Mathilde, On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: >> - when do we increment C? > > The node MAY increment C when it hears another DIO. > > I think the spec says that a node MAY increment C each time it hears a > "consistent DIO for this DAG from a DAG parent". What fields are > included in the consistency check? If only generic DAG information are > checked you might want to look at DIO from non-DAG parents, no? You're right, this text in the draft is incorrect. There's an important distinction to make here. We want to quickly send DIO transmissions (reset the Trickle timer) whenever *inconsistencies* are detected. But you want to suppress DIO transmissions (increment C) whenever *redundancies* are detected. While you can detect inconsistencies by listening to your DAG parent(s), redundancies will probably come from your siblings/cousins. We are looking to update the text around incrementing C and make what constitutes a redundancy more precise. -- Jonathan Hui From jhui@archrock.com Fri Nov 20 08:02:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB753A694E for ; Fri, 20 Nov 2009 08:02:02 -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 JYpEErIq5x3a for ; Fri, 20 Nov 2009 08:02:01 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8E4263A6946 for ; Fri, 20 Nov 2009 08:02:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 60435AF83D; Fri, 20 Nov 2009 08:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89fd485FE3tW; Fri, 20 Nov 2009 08:01:52 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 2344EAF833; Fri, 20 Nov 2009 08:01:52 -0800 (PST) Message-Id: <4804F6FF-1792-40DA-B0CB-EDD7E16345D3@archrock.com> From: Jonathan Hui To: "Mathilde Durvy (mdurvy)" In-Reply-To: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 08:01:50 -0800 References: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: "roll@ietf.org WG" Subject: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 16:02:02 -0000 Hi Mathilde, I think the criteria for choosing as well as the maintenance of =20 neighbors and candidate neighbors should be left out of scope of the =20 core RPL specification. While we could say that candidate neighbors =20 are based on the set of REACHABLE neighbors, I don't think that really =20= clarifies much since it doesn't define what a REACHABLE neighbor is =20 and/or implies that it is defined by RFC 4861 which may not be the =20 definition we want. That being said, it might be appropriate to provide some suggestions =20 or implementation guidelines within the appendix to identify important =20= parameters to consider. For example, some versions of the draft had =20 words saying that both the link quality metric *and* confidence in the =20= link quality metric should be considered when choosing candidate =20 neighbors. Confidence is important since link qualities are =20 statistical values based on discrete samples over time. -- Jonathan Hui On Oct 28, 2009, at 7:51 AM, roll issue tracker wrote: > #3: Need Clarification on Candidate Neighbor > --------------------------------=20 > +------------------------------------------- > Reporter: jpv@=85 | Owner: wintert@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------=20 > +------------------------------------------- > Question from Mathilde Durvy: > > Hi All, > > I'm trying to understand better the need for 'candidate neighbors'. > My current understanding is that 'candidate parents' (RPL) are a =20 > subset of > 'candidate neighbors' (RPL) which are themselves a subset of =20 > 'neighbors' > (ND). > My question is, do we really need to maintain 'candidate neighbors' in > addition to 'neighbors' and 'candidate parents'? > If yes what should be the data structure and corresponding fields for > 'candidate neighbors'? Section 5.2.1 gives very little details... > I have a feeling that 'candidate neighbors' could simply be the set of > REACHABLE 'neighbors' and be associated with a DAG once they become > candidate parents. > > --=20 > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Fri Nov 20 09:15:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904C928C0E6 for ; Fri, 20 Nov 2009 09:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq5pnD4bDC6d for ; Fri, 20 Nov 2009 09:15:09 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id BFC593A6358 for ; Fri, 20 Nov 2009 09:15:08 -0800 (PST) Received: by ywh13 with SMTP id 13so4084221ywh.29 for ; Fri, 20 Nov 2009 09:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=eO9JvE0PQ1iDNF7U1AorzEr10JhKZJ0tKDf4LjdAA8g=; b=OPXFCz5oXft4q5tjlaQ0thAwCIXXKlDjEPWPgwBXcS9EBiubTlj45jijnduNtC6jcU 4benPjs0BNlX0IQXZgSwMcNC0g++AIZhSV0Q/MFV8oJMBsuT0qqHkG16vVj4TkwN2UCJ wuvpzF179KLPaRk5IdnVouc+gO80iu7LS+zG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=sg6zqDeYkn/wiPBUINM2ci5j2xZUHzTq752BAKpp7nV1YX4y++K+iSgwokxuO3drP/ EEAdG+z0Cpt2VcSbOBPI6bZqxF5knRTbTBKa4TKn0zWO0sZcg9iOT0l8w4/71d1RUOVe JoBOZpN8w4E0JsMEJfCe9TUq961YusZI7/GXM= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.203.1 with SMTP id f1mr2674157agq.55.1258737302047; Fri, 20 Nov 2009 09:15:02 -0800 (PST) In-Reply-To: References: <20091026224501.E98D33A682F@core3.amsl.com> From: Emmanuel Baccelli Date: Fri, 20 Nov 2009 18:13:35 +0100 X-Google-Sender-Auth: 918e5581c4e687ed Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=001636af018fc10b0b0478d09dc7 Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-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: Fri, 20 Nov 2009 17:15:10 -0000 --001636af018fc10b0b0478d09dc7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have received no comments on this earlier on when I posted it first so let me repost, as I think a lot of things we discussed in Hiroshima are in line with what I propose or talk about in this previous email to the list, i.e. shorter spec focusing on just one instance and one root, no siblings, being more explicit about the core set of requirements etc. Please do give some feedback on this. So here are some thoughts I had about draft-ietf-roll-rpl-04. Overall I think we are moving along the right direction compared to -03, but we are still somewhat far from the spec I think we should aim for, if we plan on keeping our tight standardization schedule. I insist on the fact that we should first concentrate on the "overview" section (currently Section 3) and on an explicit Applicability section. We should agree once and for all what these sections should outline, and then re-populate the rest of the document accordingly (reusing most of the corresponding existing text if possible). This is a sure way of getting somewhere if we want to converge quickly to a solid and consise document. So, focusing on an applicability section and on section 3 (overview of the protocol), I have hacked the tentative "to-the-bone" text below, during a recent jabber chat with Thomas Clausen. Essentially it aims at clarifying some key points, including the following: - this protocol is about communications from sensors to a sink, - the core set of requirements is explicit in the applicability section, - multiple instances of the protocol are not discussed in the document (the applicability section just states it is out of scope), - siblings are not considered, only parents. I think that we need to boil down to such simpler, very explicit goals if we want a clear spec soon. I note that draft-ietf-roll-rpl-04 is still in the 100 pages ball-park. I think we should aim at a spec that is less than half this size, more focused, along the above-mentionned lines. The idea is that additional considerations and companion documents should off-spring from a simple, rock-solid base. So here it is. Again, keep in mind that this is tentative text, hacked up in a hurry, so there is indeed room for improvement -- but maybe not enough room for 100 pages in my book ;) Applicability This protocol is build to support a subset of the requirements from for routing in low-power sensor networks with lossy links. This subset corresponds to a core set of functionalities that enable up to a few thousand fixed sensors to send data to a single, well known data sink. This protocol provides store-and-forward functionalities at the IP level, in order to enable such communications. The protocol is designed to work even when some, or all sensors are very limited in terms of memory (in the order of a kByte), in terms of radio link capacity (in the order of a kB/s), as well as in terms of CPU and battery capacity. Multiple instances of this protocol may be used in order to provide paths to multiple sinks. For example different traffic classes may require different paths to be calculated towards the sink, e.g. to accommodate low-latency requirements or prioritize urgent signaling. Similarly, there may be multiple nodes in the network, each of which having a distinct application significance, and for each of which a LLN router may have to calculate paths. However, the specification of the interaction between multiple instance of the protocol is out of the scope of this document. Protocol Overview As the traffic flows originate from sensors and are directed towards the sink node, each LLN router must find paths towards that sink node. The union of all these paths form a directed acyclic graph (DAG), rooted in that the sink node. This protocol supports the discovery and maintenance of such a DAG, identified uniquely by a given DAG ID, rooted at a single sink node in the network, while respecting some given environmental constraints, i.e. paths calculated according to a specific well-known path metric. The DAG can thus be seen as a collection of paths of similar kind towards similar destination. The DAG is boot-strapped by the self-aware sink, which signals its presence via an extension of IPv6 RA signalling. Such signalling spreads hop by hop, among direct neighbors: each router joining the DAG chooses a collection of parents which are closer to the root, and starts signalling the DAG in its own RAs. This signalling contains the necessary local information about the DAG, including the metric used to compute paths, the DAG ID, and the distance of the emiting router to the root of the DAG. Regards, Emmanuel On Thu, Oct 29, 2009 at 7:29 PM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > > > > > > On Mon, Oct 26, 2009 at 11:45 PM, 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-04.txt >> Pages : 82 >> Date : 2009-10-26 >> >> Low power and Lossy Networks (LLNs) are a class of network in which >> both the routers and their interconnect are constrained: LLN routers >> typically operate with constraints on (any subset of) processing >> power, memory and energy (battery), and their interconnects are >> characterized by (any subset of) high loss rates, low data rates and >> instability. LLNs are comprised of anything from a few dozen and up >> to thousands of LLN routers, and support point-to- point traffic >> (between devices inside the LLN), point-to-multipoint traffic (from a >> central control point to a subset of devices inside the LLN) and >> multipoint-to- point traffic (from devices inside the LLN towards a >> central control point). This document specifies the IPv6 Routing >> Protocol for LLNs (RPL), which provides a mechanism whereby >> multipoint-to-point traffic from devices inside the LLN towards a >> central control point, as well as point-to-multipoint traffic from >> the central control point to the devices inside the LLN, is >> supported. Support for point-to-point traffic is also available. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-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. >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --001636af018fc10b0b0478d09dc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have received no comments on this earlier on w= hen I posted it first so let me repost, as I think a lot of things we discu= ssed in Hiroshima are in line with what I propose or talk about in this pre= vious email to the list, i.e. shorter spec focusing on just one instance an= d one root, no siblings, being more explicit about the core set of requirem= ents etc. Please do give some feedback on this.

So=A0here are some thoughts I had about=A0draft-ie= tf-roll-rpl-04. Overall I think we are moving along the right direction com= pared to -03, but we are still somewhat far from the spec I think we should= aim for,=A0if=A0we=A0plan=A0on=A0keeping=A0our=A0tight standardization=A0s= chedule.

I insist=A0on=A0the=A0fact=A0that we=A0should first con= centrate=A0on=A0the=A0"overview" section (currently Section 3) an= d on an explicit Applicability section.=A0We=A0should=A0agree=A0once=A0and= =A0for=A0all=A0what=A0these sections should=A0outline,=A0and=A0then=A0re-po= pulate=A0the rest of the document accordingly (reusing most of the correspo= nding existing text if possible). This is a sure way of getting somewhere i= f we want to converge quickly to a solid and consise document.

So, focusing on an applicability section and on section= 3 (overview of the protocol), I have hacked the tentative "to-the-bon= e" text below, during a recent jabber chat with Thomas Clausen. Essent= ially it aims at clarifying some key points, including the following:

- this protocol is about communications from sensors to= a sink,
- the core set of requirements is explicit in the applic= ability section,
- multiple instances of the protocol are not dis= cussed in the document (the applicability section just states it is out of = scope),
- siblings are not considered, only parents.

= I think that we need to boil down to such simpler, very explicit goals if w= e want a clear spec soon. I note that=A0draft-ietf-roll-rpl-04 is still in = the 100 pages ball-park. I think we should aim at a spec that is less than = half this size, more focused, along the above-mentionned lines. The idea is= that additional considerations and companion documents should off-spring f= rom a simple, rock-solid base.=A0

So here it is. Again, keep in mind that this is tentati= ve text, hacked up in a hurry, so there is indeed room for improvement -- b= ut maybe not enough room for 100 pages in my book ;)



Applicability

<= div>This protocol is build to support a subset of the requirements from <= ;reqd. doc's> for routing in low-power sensor networks with lossy li= nks. This subset corresponds to a core set of functionalities that enable u= p to a few thousand fixed sensors to send data to a single, well known data= sink. This protocol provides store-and-forward functionalities at the IP l= evel, in order to enable such communications. The protocol is designed to w= ork even when some, or all sensors are very limited in terms of memory (in = the order of a kByte), in terms of radio link capacity (in the order of a k= B/s), as well as in terms of CPU and battery capacity.

Multiple instances of this protocol may be used in orde= r to provide paths to multiple sinks. For example different traffic classes= may require different paths to be calculated towards the sink, e.g. to acc= ommodate low-latency requirements or prioritize urgent signaling. =A0Simila= rly, there may be =A0multiple nodes in the network, each of which having a = distinct application significance, and for each of which a LLN router may h= ave to calculate paths.

However, the specification of the interaction between m= ultiple instance of the protocol is out of the scope of this document.=A0


Protocol Overview

As the traffic flows originate from sensors and are directed towards t= he sink node, each LLN router must find paths towards that sink node. The u= nion of all these paths form a directed acyclic graph (DAG), rooted in that= the sink node.

This protocol supports the discovery and maintenance of= such a=A0DAG, identified uniquely by a given DAG ID, rooted at a single si= nk node in the network, while respecting some given environmental constrain= ts, i.e. paths calculated according to a specific well-known path metric. T= he DAG can thus be seen as a collection of paths of similar kind towards si= milar destination.

The DAG is boot-strapped by the self-aware sink, which = signals its presence via an extension of IPv6 RA signalling. Such signallin= g spreads=A0hop by hop,=A0among direct neighbors: each router joining the D= AG chooses a collection of parents which are closer to the root, and starts= signalling the DAG in its own RAs. This signalling contains the necessary = local information about the DAG, including the metric used to compute paths= , the DAG ID, and the distance of the emiting router to the root of the DAG= .




Rega= rds,
Emmanuel


= On Thu, Oct 29, 2009 at 7:29 PM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr&= gt; wrote:




=
On Mon, Oct 26, 2009 at 11:45 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 networks = Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RPL: IPv6 Routing Protocol for = Low power and Lossy Networks
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Winter, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-roll-rpl-04.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 82
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-26

Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained: LLN routers
typically operate with constraints on (any subset of) processing
power, memory and energy (battery), and their interconnects are
characterized by (any subset of) high loss rates, low data rates and
instability. =A0LLNs are comprised of anything from a few dozen and up
to thousands of LLN routers, and support point-to- point traffic
(between devices inside the LLN), point-to-multipoint traffic (from a
central control point to a subset of devices inside the LLN) and
multipoint-to- point traffic (from devices inside the LLN towards a
central control point). =A0This 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. =A0Support 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-0= 4.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
ht= tps://www.ietf.org/mailman/listinfo/roll



--001636af018fc10b0b0478d09dc7-- From pal@cs.stanford.edu Fri Nov 20 10:31:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6702928C0F1 for ; Fri, 20 Nov 2009 10:31: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 incfhQyDWN+e for ; Fri, 20 Nov 2009 10:31:17 -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 ADB7B28C0E7 for ; Fri, 20 Nov 2009 10:31:17 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NBYG7-0004Us-EP; Fri, 20 Nov 2009 10:31:04 -0800 Message-Id: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> From: Philip Levis To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 10:30:57 -0800 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: ROLL WG Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 18:31:18 -0000 On Oct 28, 2009, at 9:29 AM, Julien Abeille (jabeille) wrote: > Hi all, > > regarding usage of multicast DAO: in the following scenario: > A > / \ > B C > > if the purpose is to to allow B and C to talk to each other > directly, the multicast DAO is equivalent to an unsolicited NA. > > In the scenarios like: > > A > / \ > B C > | > D > if the purpose is to have B talk to D through C (instead of A then > C), then the multicast DAO (including destination prefix option) > makes sense. > Is this scenario needed by some applications? Julien, The text in -04 reads: "The objective [of multicast DAOs] is to enable direct P2P communication, between destinations directly supported by neighboring nodes, without needing the RPL routing structure to relay the packets." So the case it's concerned with is the latter one: B to C to D. Clearly one could use NA for the B-C case. Point-to-point communication between nodes is needed by some applications. Section 5.2.2 of draft-ietf-roll-building-routing-reqs-07: "A network device MUST be able to communicate in a point-to-point manner with any other device on the network." Do you agree? Is it OK to resolve this ticket? Phil From pthubert@cisco.com Fri Nov 20 11:12:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5633A68D1 for ; Fri, 20 Nov 2009 11:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.971 X-Spam-Level: X-Spam-Status: No, score=-7.971 tagged_above=-999 required=5 tests=[AWL=-1.372, 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 dgZxoo03vK94 for ; Fri, 20 Nov 2009 11:12:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C22E03A697C for ; Fri, 20 Nov 2009 11:12:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFd4BktAZnwN/2dsb2JhbAC9P5dhhDwE X-IronPort-AV: E=Sophos;i="4.47,260,1257120000"; d="scan'208";a="69190021" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2009 19:11:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAKJBxSo008699; Fri, 20 Nov 2009 19:11:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 20:11:58 +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, 20 Nov 2009 20:11:54 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DB09B96@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle clarification: (in)consistency Thread-Index: Acpp9++VTBRRh6cSSsC6iBmBfj4wSQAG/3sQ References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu><8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 20 Nov 2009 19:11:58.0618 (UTC) FILETIME=[54FC9FA0:01CA6A15] Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 19:12:29 -0000 Hi Mathilde; I agree with Jonathan that we want to avoid redundancy. The rank of metric that a node advertises is an information about self that cannot be inferred from the neighbors so it is *not* redundant. If a number of nodes go down at the same time and one does not advertise, then that node will look better and will attract the traffic. It will also attract the neighbors that went down and that will be tempted to reattach to that apparent survivor. The information in the DIO that relates to the DAG configuration will be centralized in an option that IS redundant. We could add text that a node that see C of it MAY filter it out from its DIO. Finally the new sequence is redundant. I proposed to use it to limit the density of routers using trickle. When you hear C router advertising a new sequence you are entitled to stop being a router for that sequence (stop trickle timer). The trickle timer would then be restarted upon a DIS to serve orphans, and upon a next sequence to redistribute the load. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: vendredi 20 novembre 2009 16:41 >To: Mathilde Durvy (mdurvy) >Cc: roll@ietf.org >Subject: Re: [Roll] Trickle clarification: (in)consistency > > >Hi Mathilde, > >On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: > >>> - when do we increment C? >> >> The node MAY increment C when it hears another DIO. >> >> I think the spec says that a node MAY increment C each time it hears a >> "consistent DIO for this DAG from a DAG parent". What fields are >> included in the consistency check? If only generic DAG information are >> checked you might want to look at DIO from non-DAG parents, no? > >You're right, this text in the draft is incorrect. There's an >important distinction to make here. We want to quickly send DIO >transmissions (reset the Trickle timer) whenever *inconsistencies* are >detected. But you want to suppress DIO transmissions (increment C) >whenever *redundancies* are detected. While you can detect >inconsistencies by listening to your DAG parent(s), redundancies will >probably come from your siblings/cousins. > >We are looking to update the text around incrementing C and make what >constitutes a redundancy more precise. > >-- >Jonathan Hui > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Nov 20 11:25:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049373A6812 for ; Fri, 20 Nov 2009 11:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 R2-AUfZb339h for ; Fri, 20 Nov 2009 11:25:33 -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 B26D43A66B4 for ; Fri, 20 Nov 2009 11:25:32 -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: AhkAANt7BkuQ/uCWiWdsb2JhbACcBAEBAQoLERMGoQGXYII2ggYE X-IronPort-AV: E=Sophos;i="4.47,260,1257120000"; d="scan'208";a="54870767" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2009 19:25:29 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAKJPSc0001521; Fri, 20 Nov 2009 19:25:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 20:25:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {3C95749B-3E4C-44F1-96FA-15F3B411D2FE} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: lgA= Acru Bj7H EEoJ GCgp GdqD IDTR IMRc LwWv NsQ8 P9Ml RMAY R9HV S4U1 TAnu UC3W; 2; agBoAHUAaQBAAGEAcgBjAGgAcgBvAGMAawAuAGMAbwBtADsAcgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3C95749B-3E4C-44F1-96FA-15F3B411D2FE}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 20 Nov 2009 19:24:54 GMT; UgBFADoAIABbAFIAbwBsAGwAXQAgAFsAcgBvAGwAbABdACAAIwAzADoAIABOAGUAZQBkACAAQwBsAGEAcgBpAGYAaQBjAGEAdABpAG8AbgAgAG8AbgAgAEMAYQBuAGQAaQBkAGEAdABlACAATgBlAGkAZwBoAGIAbwByAA== Content-class: urn:content-classes:message Date: Fri, 20 Nov 2009 20:24:54 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DB09B9A@XMB-AMS-107.cisco.com> In-Reply-To: <4804F6FF-1792-40DA-B0CB-EDD7E16345D3@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #3: Need Clarification on Candidate Neighbor Thread-Index: Acpp+tCl9cWo59C/QIeW4XrleA6R3wAGz8TA References: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> <4804F6FF-1792-40DA-B0CB-EDD7E16345D3@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 20 Nov 2009 19:25:28.0774 (UTC) FILETIME=[37E09E60:01CA6A17] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 19:25:34 -0000 Hi Jonathan and Mathilde >I think the criteria for choosing as well as the maintenance of >neighbors and candidate neighbors should be left out of scope of the >core RPL specification. While we could say that candidate neighbors >are based on the set of REACHABLE neighbors, I don't think that really >clarifies much since it doesn't define what a REACHABLE neighbor is >and/or implies that it is defined by RFC 4861 which may not be the >definition we want. REACHABLE is a good starting point as long as we base our neighbor loss detection on NUD.=20 At least it is consistent. But we do want to be able to use other neighboring mechanisms, in that case the goal would be to have the equivalent of REACHABLE with that mechanism as opposed to stick to 4861's REACHABLE, of course. >That being said, it might be appropriate to provide some suggestions >or implementation guidelines within the appendix to identify important >parameters to consider. For example, some versions of the draft had >words saying that both the link quality metric *and* confidence in the >link quality metric should be considered when choosing candidate >neighbors. Confidence is important since link qualities are >statistical values based on discrete samples over time. We started discussing a companion Informational spec with recommendation such as FSM. We figure a number of things today that might be wrong. We made the draft pretty=20 Elastic to enable a large capability of tuning and adaptations to the needs. The risk of being too elastic and not enough specific being a lack of interoperability=20 and the possibility to make an implementation that plain does not work. We are trying to avoid that of course and I expect that the next rounds of review like IESG will be sensitive to that aspect. Pascal From mcr@marajade.sandelman.ca Fri Nov 20 11:38:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2B83A6916 for ; Fri, 20 Nov 2009 11:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.350, 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 tBOPtL-VDe28 for ; Fri, 20 Nov 2009 11:38:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 67FCB3A66B4 for ; Fri, 20 Nov 2009 11:38:45 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id C4008342D0 for ; Fri, 20 Nov 2009 14:30:29 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 13FAE4E796 for ; Fri, 20 Nov 2009 14:38:41 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 20 Nov 2009 14:38:41 -0500 Message-ID: <19015.1258745921@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 19:38:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> As probably the strongest proponent of the P2P requirement Jerald> on this mailing list, I will readily admit that even in Jerald> building control only about 25% of the router nodes need to Jerald> pass intra-LLN P2P messages. As I understand the DAO 1/4 of the nodes need P2P messages, but how much traffic does that represent? Is it a big percentage of overall traffic? Does it have particular characteristics that make a trip through the root bad (i.e. latency) Jerald> So yes, I think we either need to design outward traffic Jerald> into the DAG at the same level as we do inward traffic; or Jerald> devise an on-demand scheme where a node can easily Jerald> 'discover' another node in the DAG as needed. Richard's Jerald> comment below is profound saying that right now establishing Jerald> a good outward link is a matter of luck, not design. When you say "discover", I think you mean: discover a path through cousin nodes that avoids the root I too, would like to have this. I think that this could be a different protocol --- that it could leverage the communication used by the DAG to implement some kind of flood-fill algorithm to learn specific P2P routes that are important. I think the constraints of least-capable nodes excludes this from the base protocol -- but it's really want I think I care about. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwbwP4CLcPvd0N1lAQIOjAf/VrBNnnxuVjhoV7CVZL2vuT1lJhJiMOH3 iDWPlL5OCjwjpkjnC2HLYIxxIYh+kMKrqUvea2BnEoMYIAgfG7MsjuU6eFIY5hMe gywIbHhf5Zs69HkWxO6uUj4h4F2eiJAJjrTp8b207DWEY+oR/Ky0m1ffH1TCGuOz jlwqsSMI94M/RLPSwCw/iGD/zLNDyjvI9Sird16YQ7TP2FM2JTRTqJPOpt74dNCR KPeWOUIfK5kKd3S9tYOYC1BRyWUNUFlDO1iApA5YCIcFhQbi3rCqtfJWQqqKcumC Ojw1sPchsmdfLb7ScYgYKOgdimkzG4Ga+jOdtCv0HqvrviwNJy+A3Q== =Ujy3 -----END PGP SIGNATURE----- From jhui@archrock.com Fri Nov 20 11:47:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9823A6812 for ; Fri, 20 Nov 2009 11:47:43 -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 AYPmYghViS35 for ; Fri, 20 Nov 2009 11:47:42 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 46E063A67E7 for ; Fri, 20 Nov 2009 11:47:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AF49FAF8E7; Fri, 20 Nov 2009 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HMuKZ9isaRd; Fri, 20 Nov 2009 11:47:35 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id A3115AF8AB; Fri, 20 Nov 2009 11:47:34 -0800 (PST) Message-Id: <4AFE38DD-40E7-4B05-9FB2-744A6C1BDC3B@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DB09B9A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 11:47:33 -0800 References: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> <4804F6FF-1792-40DA-B0CB-EDD7E16345D3@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5DB09B9A@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Nov 2009 19:47:43 -0000 Hi Pascal, On Nov 20, 2009, at 11:24 AM, Pascal Thubert (pthubert) wrote: >> I think the criteria for choosing as well as the maintenance of >> neighbors and candidate neighbors should be left out of scope of the >> core RPL specification. While we could say that candidate neighbors >> are based on the set of REACHABLE neighbors, I don't think that >> really >> clarifies much since it doesn't define what a REACHABLE neighbor is >> and/or implies that it is defined by RFC 4861 which may not be the >> definition we want. > > REACHABLE is a good starting point as long as we base our neighbor > loss > detection on NUD. > At least it is consistent. But we do want to be able to use other > neighboring mechanisms, > in that case the goal would be to have the equivalent of REACHABLE > with > that mechanism > as opposed to stick to 4861's REACHABLE, of course. My point is that 4861 NUD is most likely not what we want to maintain the neighbor set. Just because a single RFC 4861 NUD fails doesn't mean we should remove the node as a candidate neighbor, and thus, candidate parent. At the very least, we will need to better define what NUD really means in this space. >> That being said, it might be appropriate to provide some suggestions >> or implementation guidelines within the appendix to identify >> important >> parameters to consider. For example, some versions of the draft had >> words saying that both the link quality metric *and* confidence in >> the >> link quality metric should be considered when choosing candidate >> neighbors. Confidence is important since link qualities are >> statistical values based on discrete samples over time. > > We started discussing a companion Informational spec with > recommendation > such as FSM. > We figure a number of things today that might be wrong. We made the > draft pretty > Elastic to enable a large capability of tuning and adaptations to the > needs. > > The risk of being too elastic and not enough specific being a lack of > interoperability > and the possibility to make an implementation that plain does not > work. > We are trying > to avoid that of course and I expect that the next rounds of review > like > IESG will be > sensitive to that aspect. A large open hole I see today (which I have raised before) is that we lack a standard mechanism to estimate link qualities to neighboring nodes. I think it is needed and the discussion hasn't even started yet. But this mechanism should not be specified in the core RPL spec. -- Jonathan Hui From roger.alexander@ekasystems.com Sat Nov 21 10:14:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11EE3A69FF for ; Sat, 21 Nov 2009 10:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, 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 7RtxPz+K1uJB for ; Sat, 21 Nov 2009 10:14:23 -0800 (PST) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 8F5273A6A30 for ; Sat, 21 Nov 2009 10:14:22 -0800 (PST) Received: (qmail 35398 invoked from network); 21 Nov 2009 18:14:17 -0000 Received: from c-69-143-218-61.hsd1.md.comcast.net (roger.alexander@69.143.218.61 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 21 Nov 2009 10:14:16 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: e8m4a.MVM1k1qhkr7Fy4FC4K6ZGT3Idnx4RzmLb7iJHooegrAGyroZNbuXoQgRR5wOh515.Gp2av80oXyJfLm8bW7M997zWSKelP5o9kxW9PE9itqmiCOpWhRSwBpGC1isCzI_ZlK3lHIImsm860gDZscujUXZkD6FTogScZfPDzJz3FXqwqzecAXTdZwZs.gsPBRxDdymcav2YfGD9NFe3Ct62oRD7AWjhDj6Jd7YOEOBYFr0jlVsmE.2bUGqNBdqTcz6DZzKepZXRTLm5p4GHjf3ndviKltlt.PbZLUxsA3aiw4iw_csyLfiSe56aggM9DbvLpRFdZdnB6MD98s2uIVhnXIJCkjodGXe4gQa8JPem8NWIlrGiSn6hn29Czv6FBZ_wuEZVvs_MCmaYmoT4.6qFWJiYTjC48O7uOPSFrYq9l7w-- X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Richard Kelsey'" , References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> Date: Sat, 21 Nov 2009 13:16:53 -0500 Message-ID: <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppTiaiTPJz8xPXRHmjmg7D1D1BFwAz88yA Content-Language: en-us Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Nov 2009 18:14:25 -0000 Hi Richard, As indicated below, I would support this proposal as a base for further DAO operation specification. Roger > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Thursday, November 19, 2009 2:22 PM > To: roll@ietf.org > Subject: [Roll] updating DAO caches - a proposal > > > Below is an actual concrete proposal for managing DAO > caches. I believe that this would work well when all nodes > cache DAOs and when no nodes do so. It does a reasonable > job when only some nodes cache DAOs, although in some > situations there will be some superfluous DAOs transmitted. > > This assumes that DAOs are sent only to the preferred > parent. If DAO are sent to multiple parents the situation > becomes more complex. > > In a network with no DAO caches the new (C) flag is never > set. Whenever a node moves it sends a single DAO that > propagates to the root, which stores the nodes new location. > > In a network where all nodes cache DAOs, a node that moves > sends the contents of its cache to its new parent. These > propagate up the tree, with each node forwarding on only > those prefixes which are new to its cache. The forwarding > stops when it reaches the least common ancestor of the > node's old and new locations. Agreed. > In a mixed network, nodes with caches and nodes whose only > caching ancestor is the root will have the same behavior > as above. A node without a cache will send its own DAO and > set the Destination Advertisement Trigger to cause its > sub-DAG to send DAOs as well. The Trigger will propagate > downwards causing more DAOs to be sent, but descedents that > have a cache will not propagate the Trigger to their own > sub-DAG. Some further refinement may need to be considered. Where nodes maintain DAO caches the triggering of outward routing updates to the sub-DAG is not needed unless there has been a change in the path cost from the moving node to the DAG root, which would then affect connectivity decisions of the sub-DAG nodes (one of the traffic reducing benefits of multiple parents is the potential to mute the effect of individual link connectivity changes). For nodes that do not maintain DAO caches, it should be possible to apply the same mechanism since the moving parent node sends a DAO update towards the root updating subsequent outward routes. > > -Richard Kelsey > > ---------------- > Proposal: > > Add a new DIO flag: > > Destination Advertisements Cache (C): The Destination > Advertisement Cache (C) flag is set when a node below > the DAG root in the successor chain caches DAOs sent > upwards. DAG roots NUST NOT set this flag. Nodes > below the root that maintain a DAO cache MUST set this > flag. Nodes below the root that do not maintain a DAO > cache MUST set this flag to the value received from > their preferred DAG Parent. > > > In 5.10.1.1. replace > > A node that modifies its DAG Parent set may set the `D' bit in > subsequent DIO propagation in order to trigger destination > advertisements to be updated to its DAG Parents and other ancestors > on the DAG. Additional recommendations and guidelines regarding > the use of this mechanism are still under consideration and will be > elaborated in a future revision of this specification. > > with > > When a node selects a new preferred parent it MUST send that parent > a unicast DIO. If the node maintains a DIO cache the DIO sent MUST > include the prefixes in the DAO cache. If the node does not > maintain a DIO cache and either the new preferred parent's DIO or > the old preferred parent's DIO has the Destination Advertisements > Cache set, then the node MUST set the Destination Advertisement > Trigger in its own subsequent DIO. > > ---------------- > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Sun Nov 22 13:55:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E7E3A697E for ; Sun, 22 Nov 2009 13:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 n4m0tisT-Fpl for ; Sun, 22 Nov 2009 13:55:22 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D01F73A697B for ; Sun, 22 Nov 2009 13:55:22 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHpCCUurRN+J/2dsb2JhbAC8PJZGhDwE X-IronPort-AV: E=Sophos;i="4.47,267,1257120000"; d="scan'208";a="107901225" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2009 21:55:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAMLtIaL020988; Sun, 22 Nov 2009 21:55:19 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 22:55:18 +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: Sun, 22 Nov 2009 22:55:17 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DB09B96@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle clarification: (in)consistency Thread-Index: Acpp9++VTBRRh6cSSsC6iBmBfj4wSQAG/3sQAGqLUaA= References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu><8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DB09B96@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Jonathan Hui" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 22 Nov 2009 21:55:18.0058 (UTC) FILETIME=[7ABC00A0:01CA6BBE] Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Nov 2009 21:55:23 -0000 Hi Pascal, Not sure I understand your explanation. In a DIO there are informations that are global to the DAG and some that are node specific. We use trickle because we consider DIO sending a consitency problem, hence we focus on the global information. They come both from parents and childs, so I would also increment C when hearing from a child. Am I missing something? Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: vendredi 20 novembre 2009 20:12 > To: Jonathan Hui; Mathilde Durvy (mdurvy) > Cc: roll@ietf.org > Subject: Re: [Roll] Trickle clarification: (in)consistency >=20 > Hi Mathilde; >=20 > I agree with Jonathan that we want to avoid redundancy. >=20 > The rank of metric that a node advertises is an information=20 > about self that cannot be inferred from the neighbors so it=20 > is *not* redundant. If a number of nodes go down at the same=20 > time and one does not advertise, then that node will look=20 > better and will attract the traffic. It will also attract the=20 > neighbors that went down and that will be tempted to reattach=20 > to that apparent survivor. >=20 > The information in the DIO that relates to the DAG=20 > configuration will be centralized in an option that IS=20 > redundant. We could add text that a node that see C of it MAY=20 > filter it out from its DIO. >=20 > Finally the new sequence is redundant. I proposed to use it=20 > to limit the density of routers using trickle. When you hear=20 > C router advertising a new sequence you are entitled to stop=20 > being a router for that sequence (stop trickle timer). The=20 > trickle timer would then be restarted upon a DIS to serve=20 > orphans, and upon a next sequence to redistribute the load. >=20 > Pascal >=20 > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf Of > Jonathan Hui > >Sent: vendredi 20 novembre 2009 16:41 > >To: Mathilde Durvy (mdurvy) > >Cc: roll@ietf.org > >Subject: Re: [Roll] Trickle clarification: (in)consistency > > > > > >Hi Mathilde, > > > >On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: > > > >>> - when do we increment C? > >> > >> The node MAY increment C when it hears another DIO. > >> > >> I think the spec says that a node MAY increment C each=20 > time it hears > a > >> "consistent DIO for this DAG from a DAG parent". What fields are=20 > >> included in the consistency check? If only generic DAG information > are > >> checked you might want to look at DIO from non-DAG parents, no? > > > >You're right, this text in the draft is incorrect. There's an=20 > >important distinction to make here. We want to quickly send DIO=20 > >transmissions (reset the Trickle timer) whenever=20 > *inconsistencies* are=20 > >detected. But you want to suppress DIO transmissions (increment C)=20 > >whenever *redundancies* are detected. While you can detect=20 > >inconsistencies by listening to your DAG parent(s),=20 > redundancies will=20 > >probably come from your siblings/cousins. > > > >We are looking to update the text around incrementing C and=20 > make what=20 > >constitutes a redundancy more precise. > > > >-- > >Jonathan Hui > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jabeille@cisco.com Sun Nov 22 13:59:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CECE3A6941 for ; Sun, 22 Nov 2009 13:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 lXs2mBzRbTej for ; Sun, 22 Nov 2009 13:59:37 -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 E454E3A691B for ; Sun, 22 Nov 2009 13:59:36 -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: Aj8AAPJCCUuQ/uCWe2dsb2JhbACcCwEBCwskBp9wlkaCNoIGBA X-IronPort-AV: E=Sophos;i="4.47,267,1257120000"; d="scan'208";a="54956674" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2009 21:59:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAMLxWhJ020273; Sun, 22 Nov 2009 21:59:32 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 22:59:32 +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: Sun, 22 Nov 2009 22:59:32 +0100 Message-ID: In-Reply-To: <4AFE38DD-40E7-4B05-9FB2-744A6C1BDC3B@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #3: Need Clarification on Candidate Neighbor Thread-Index: AcpqGlVAVNjmDEjdSxG0V88dy/1WdwBpGpJQ References: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org><4804F6FF-1792-40DA-B0CB-EDD7E16345D3@archrock.com><6A2A459175DABE4BB11DE2026AA50A5DB09B9A@XMB-AMS-107.cisco.com> <4AFE38DD-40E7-4B05-9FB2-744A6C1BDC3B@archrock.com> From: "Julien Abeille (jabeille)" To: "Jonathan Hui" , "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 22 Nov 2009 21:59:32.0028 (UTC) FILETIME=[121CBFC0:01CA6BBF] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Nov 2009 21:59:38 -0000 Hi Jonathan, NUD is probably not appropriate for RPL neighboring concept. So we just should use other means, which could by the way make use of NUD, plus other things. Reachability as far as ND is concerned can also be updated by external protocols (e.g. a reliable transport, this is from 4861) Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Jonathan Hui > Sent: vendredi 20 novembre 2009 20:48 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] #3: Need Clarification on=20 > Candidate Neighbor >=20 >=20 > Hi Pascal, >=20 > On Nov 20, 2009, at 11:24 AM, Pascal Thubert (pthubert) wrote: >=20 > >> I think the criteria for choosing as well as the maintenance of=20 > >> neighbors and candidate neighbors should be left out of=20 > scope of the=20 > >> core RPL specification. While we could say that candidate=20 > neighbors=20 > >> are based on the set of REACHABLE neighbors, I don't think that=20 > >> really clarifies much since it doesn't define what a REACHABLE=20 > >> neighbor is and/or implies that it is defined by RFC 4861=20 > which may=20 > >> not be the definition we want. > > > > REACHABLE is a good starting point as long as we base our neighbor=20 > > loss detection on NUD. > > At least it is consistent. But we do want to be able to use other=20 > > neighboring mechanisms, in that case the goal would be to have the=20 > > equivalent of REACHABLE with that mechanism as opposed to stick to=20 > > 4861's REACHABLE, of course. >=20 > My point is that 4861 NUD is most likely not what we want to=20 > maintain the neighbor set. Just because a single RFC 4861=20 > NUD fails doesn't mean we should remove the node as a=20 > candidate neighbor, and thus, candidate parent. At the very=20 > least, we will need to better define what NUD really means in=20 > this space. >=20 > >> That being said, it might be appropriate to provide some=20 > suggestions=20 > >> or implementation guidelines within the appendix to identify=20 > >> important parameters to consider. For example, some=20 > versions of the=20 > >> draft had words saying that both the link quality metric *and*=20 > >> confidence in the link quality metric should be considered when=20 > >> choosing candidate neighbors. Confidence is important since link=20 > >> qualities are statistical values based on discrete samples=20 > over time. > > > > We started discussing a companion Informational spec with=20 > > recommendation such as FSM. > > We figure a number of things today that might be wrong. We made the=20 > > draft pretty Elastic to enable a large capability of tuning and=20 > > adaptations to the needs. > > > > The risk of being too elastic and not enough specific being=20 > a lack of=20 > > interoperability and the possibility to make an implementation that=20 > > plain does not work. > > We are trying > > to avoid that of course and I expect that the next rounds of review=20 > > like IESG will be sensitive to that aspect. >=20 >=20 > A large open hole I see today (which I have raised before) is=20 > that we lack a standard mechanism to estimate link qualities=20 > to neighboring nodes. I think it is needed and the=20 > discussion hasn't even started yet. But this mechanism=20 > should not be specified in the core RPL spec. >=20 > -- > Jonathan Hui >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pthubert@cisco.com Sun Nov 22 23:55:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5753A6896 for ; Sun, 22 Nov 2009 23:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.934 X-Spam-Level: X-Spam-Status: No, score=-7.934 tagged_above=-999 required=5 tests=[AWL=-1.335, 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 2OmSx4aVyOSB for ; Sun, 22 Nov 2009 23:55:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D03EC3A67F0 for ; Sun, 22 Nov 2009 23:55:00 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN7OCUtAZnwN/2dsb2JhbAC8M5ZShDwE X-IronPort-AV: E=Sophos;i="4.47,270,1257120000"; d="scan'208";a="69695181" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Nov 2009 07:54:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAN7snGH003464; Mon, 23 Nov 2009 07:54:56 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 08:54:55 +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, 23 Nov 2009 08:54:50 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DB09D76@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle clarification: (in)consistency Thread-Index: Acpp9++VTBRRh6cSSsC6iBmBfj4wSQAG/3sQAGqLUaAAFOzHIA== References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu><8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DB09B96@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Jonathan Hui" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 23 Nov 2009 07:54:55.0483 (UTC) FILETIME=[3EF364B0:01CA6C12] Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 07:55:02 -0000 Hi Julien Seems to me that so far we are saying the same thing. We'll be concentrating the DAG information in one option. That option should be consistent in an iteration. It should thus be subject to elision if it is redundant with C messages already heard during the trickle period. Other fields in the DIO might not be redundant though. My main concern is the routing information. My Rank is not my neighbor's Rank. Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: dimanche 22 novembre 2009 22:55 >To: Pascal Thubert (pthubert); Jonathan Hui; Mathilde Durvy (mdurvy) >Cc: roll@ietf.org >Subject: RE: [Roll] Trickle clarification: (in)consistency > >Hi Pascal, > >Not sure I understand your explanation. In a DIO there are informations that are global to the DAG and >some that are node specific. We use trickle because we consider DIO sending a consitency problem, >hence we focus on the global information. They come both from parents and childs, so I would also >increment C when hearing from a child. Am I missing something? > >Julien > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Pascal Thubert (pthubert) >> Sent: vendredi 20 novembre 2009 20:12 >> To: Jonathan Hui; Mathilde Durvy (mdurvy) >> Cc: roll@ietf.org >> Subject: Re: [Roll] Trickle clarification: (in)consistency >> >> Hi Mathilde; >> >> I agree with Jonathan that we want to avoid redundancy. >> >> The rank of metric that a node advertises is an information >> about self that cannot be inferred from the neighbors so it >> is *not* redundant. If a number of nodes go down at the same >> time and one does not advertise, then that node will look >> better and will attract the traffic. It will also attract the >> neighbors that went down and that will be tempted to reattach >> to that apparent survivor. >> >> The information in the DIO that relates to the DAG >> configuration will be centralized in an option that IS >> redundant. We could add text that a node that see C of it MAY >> filter it out from its DIO. >> >> Finally the new sequence is redundant. I proposed to use it >> to limit the density of routers using trickle. When you hear >> C router advertising a new sequence you are entitled to stop >> being a router for that sequence (stop trickle timer). The >> trickle timer would then be restarted upon a DIS to serve >> orphans, and upon a next sequence to redistribute the load. >> >> Pascal >> >> >-----Original Message----- >> >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] >> On Behalf Of >> Jonathan Hui >> >Sent: vendredi 20 novembre 2009 16:41 >> >To: Mathilde Durvy (mdurvy) >> >Cc: roll@ietf.org >> >Subject: Re: [Roll] Trickle clarification: (in)consistency >> > >> > >> >Hi Mathilde, >> > >> >On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: >> > >> >>> - when do we increment C? >> >> >> >> The node MAY increment C when it hears another DIO. >> >> >> >> I think the spec says that a node MAY increment C each >> time it hears >> a >> >> "consistent DIO for this DAG from a DAG parent". What fields are >> >> included in the consistency check? If only generic DAG information >> are >> >> checked you might want to look at DIO from non-DAG parents, no? >> > >> >You're right, this text in the draft is incorrect. There's an >> >important distinction to make here. We want to quickly send DIO >> >transmissions (reset the Trickle timer) whenever >> *inconsistencies* are >> >detected. But you want to suppress DIO transmissions (increment C) >> >whenever *redundancies* are detected. While you can detect >> >inconsistencies by listening to your DAG parent(s), >> redundancies will >> >probably come from your siblings/cousins. >> > >> >We are looking to update the text around incrementing C and >> make what >> >constitutes a redundancy more precise. >> > >> >-- >> >Jonathan Hui >> > >> >_______________________________________________ >> >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 jvasseur@cisco.com Mon Nov 23 02:45:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4223A6A40 for ; Mon, 23 Nov 2009 02:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.856 X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 eE+ruW1aYunx for ; Mon, 23 Nov 2009 02:45:26 -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 63A413A6A37 for ; Mon, 23 Nov 2009 02:45:26 -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: AjcAALf2CUuQ/uCWe2dsb2JhbACcDQEBCwskBqAziT6NHIQ8BIFw X-IronPort-AV: E=Sophos;i="4.47,271,1257120000"; d="scan'208";a="54990332" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 10:45:21 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANAjLoc010548; Mon, 23 Nov 2009 10:45:21 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:45:21 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:45:20 +0100 Message-Id: <0C3B45FF-175D-4A6A-8CF8-D1FA926D048A@cisco.com> From: JP Vasseur To: Michael Richardson In-Reply-To: <19015.1258745921@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Nov 2009 11:45:20 +0100 References: <19015.1258745921@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Nov 2009 10:45:20.0976 (UTC) FILETIME=[0DD1CD00:01CA6C2A] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 10:45:27 -0000 On Nov 20, 2009, at 8:38 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Jerald" == Jerald P Martocci writes: > Jerald> As probably the strongest proponent of the P2P requirement > Jerald> on this mailing list, I will readily admit that even in > Jerald> building control only about 25% of the router nodes need to > Jerald> pass intra-LLN P2P messages. As I understand the DAO > > 1/4 of the nodes need P2P messages, but how much traffic does that > represent? Is it a big percentage of overall traffic? Does it have > particular characteristics that make a trip through the root bad > (i.e. latency) > > Jerald> So yes, I think we either need to design outward traffic > Jerald> into the DAG at the same level as we do inward traffic; or > Jerald> devise an on-demand scheme where a node can easily > Jerald> 'discover' another node in the DAG as needed. Richard's > Jerald> comment below is profound saying that right now > establishing > Jerald> a good outward link is a matter of luck, not design. > > When you say "discover", I think you mean: > discover a path through cousin nodes that avoids the root > > I too, would like to have this. > > I think that this could be a different protocol --- that it could > leverage the communication used by the DAG to implement some kind of > flood-fill algorithm to learn specific P2P routes that are important. > Let's first figure out if we need any other mechanisms beyond what we have. You might gae notice the presence of route-tag to tag important routes, this could be used to improve P2P path but let's first determine if we need anything more first. > I think the constraints of least-capable nodes excludes this from the > base protocol -- but it's really want I think I care about. > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBSwbwP4CLcPvd0N1lAQIOjAf/VrBNnnxuVjhoV7CVZL2vuT1lJhJiMOH3 > iDWPlL5OCjwjpkjnC2HLYIxxIYh+kMKrqUvea2BnEoMYIAgfG7MsjuU6eFIY5hMe > gywIbHhf5Zs69HkWxO6uUj4h4F2eiJAJjrTp8b207DWEY+oR/Ky0m1ffH1TCGuOz > jlwqsSMI94M/RLPSwCw/iGD/zLNDyjvI9Sird16YQ7TP2FM2JTRTqJPOpt74dNCR > KPeWOUIfK5kKd3S9tYOYC1BRyWUNUFlDO1iApA5YCIcFhQbi3rCqtfJWQqqKcumC > Ojw1sPchsmdfLb7ScYgYKOgdimkzG4Ga+jOdtCv0HqvrviwNJy+A3Q== > =Ujy3 > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 23 07:06:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA73C28C164 for ; Mon, 23 Nov 2009 07:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.89 X-Spam-Level: X-Spam-Status: No, score=-9.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 GLrexXdANP5k for ; Mon, 23 Nov 2009 07:06:39 -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 C8A8928C162 for ; Mon, 23 Nov 2009 07:06:38 -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: AjcAAKYzCkuQ/uCWe2dsb2JhbACcDgEBCwskBqJRlmyEPAQ X-IronPort-AV: E=Sophos;i="4.47,272,1257120000"; d="scan'208";a="55016559" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 15:06:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANF6XDK023773; Mon, 23 Nov 2009 15:06:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 16:06:33 +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, 23 Nov 2009 16:06:18 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DB0A1BD@XMB-AMS-107.cisco.com> In-Reply-To: <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches - a proposal Thread-Index: AcppTiaiTPJz8xPXRHmjmg7D1D1BFwAz88yAAIcmq2A= References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Roger K. Alexander" , "Richard Kelsey" , X-OriginalArrivalTime: 23 Nov 2009 15:06:33.0638 (UTC) FILETIME=[8B743C60:01CA6C4E] Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 15:06:40 -0000 Hello Roger (and Richard) I think I'm mostly with you too.=20 Need to make sure we're fully on the same page. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Roger K. Alexander >Sent: samedi 21 novembre 2009 19:17 >To: 'Richard Kelsey'; roll@ietf.org >Subject: Re: [Roll] updating DAO caches - a proposal > >Hi Richard, > >As indicated below, I would support this proposal as a base for further DAO >operation specification. > >Roger > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Richard Kelsey >> Sent: Thursday, November 19, 2009 2:22 PM >> To: roll@ietf.org >> Subject: [Roll] updating DAO caches - a proposal >> >> >> Below is an actual concrete proposal for managing DAO >> caches. I believe that this would work well when all nodes >> cache DAOs and when no nodes do so. It does a reasonable >> job when only some nodes cache DAOs, although in some >> situations there will be some superfluous DAOs transmitted. >> >> This assumes that DAOs are sent only to the preferred >> parent. If DAO are sent to multiple parents the situation >> becomes more complex. YES.=20 Fanning out does not guarantee multipath opportunities on the way back. And that creates overload of states. >> In a network with no DAO caches the new (C) flag is never >> set. Whenever a node moves it sends a single DAO that >> propagates to the root, which stores the nodes new location. But then its children that are dragged along do not update the root?=20 That would work only if you use DAO for one_hop information and leave it up to the root to rebuild the source route. Please let us know what you have in mind here, since that might yield complexities. I'll continue with the assumption that the Reverse Route Stack contains multiple hops. >> In a network where all nodes cache DAOs, a node that moves >> sends the contents of its cache to its new parent. These >> propagate up the tree, with each node forwarding on only >> those prefixes which are new to its cache. The forwarding >> stops when it reaches the least common ancestor of the >> node's old and new locations. > >Agreed. IF we all agree on the above, that is sending only to one preferred parent, then there can only be one child that advertises a DAO destination. Thus there can be only one route to a destination. Thus if 2 children advertise a same destination, one is wrong. The newest sequence in the DAO indicates the one that is correct. The other one should be cleaned up. Do we agree in this one? > >> In a mixed network, nodes with caches and nodes whose only >> caching ancestor is the root will have the same behavior >> as above. A node without a cache will send its own DAO and >> set the Destination Advertisement Trigger to cause its >> sub-DAG to send DAOs as well. The Trigger will propagate >> downwards causing more DAOs to be sent, but descedents that >> have a cache will not propagate the Trigger to their own >> sub-DAG. > >Some further refinement may need to be considered. Where nodes maintain DAO >caches the triggering of outward routing updates to the sub-DAG is not >needed unless there has been a change in the path cost from the moving node We agree. For all I understand, a node that caches 'absorbs' the D bit; that is it updates the parent that has set the D bit with its all cache and does not propagate the D bit.=20 Metrics changes are subject to the trickle exponential backoff but that is a different process. If there is a significant change, the child will be told by the parent from that process, and either dump its cache (if it caches) or send its DAO and send a DIO with the D bit set (if it does not cache). >to the DAG root, which would then affect connectivity decisions of the >sub-DAG nodes (one of the traffic reducing benefits of multiple parents is >the potential to mute the effect of individual link connectivity changes). >For nodes that do not maintain DAO caches, it should be possible to apply >the same mechanism since the moving parent node sends a DAO update towards >the root updating subsequent outward routes. > Hum. I fear that we are back to the 'one hop' source route collection I discussed above with the root rebuilding the source route recursively. I hope we are not going that way... >> >> -Richard Kelsey >> >> ---------------- >> Proposal: >> >> Add a new DIO flag: >> >> Destination Advertisements Cache (C): The Destination >> Advertisement Cache (C) flag is set when a node below >> the DAG root in the successor chain caches DAOs sent >> upwards. DAG roots NUST NOT set this flag. Nodes >> below the root that maintain a DAO cache MUST set this >> flag. Nodes below the root that do not maintain a DAO >> cache MUST set this flag to the value received from >> their preferred DAG Parent. >> >> >> In 5.10.1.1. replace >> >> A node that modifies its DAG Parent set may set the `D' bit in >> subsequent DIO propagation in order to trigger destination >> advertisements to be updated to its DAG Parents and other ancestors >> on the DAG. Additional recommendations and guidelines regarding >> the use of this mechanism are still under consideration and will be >> elaborated in a future revision of this specification. >> >> with >> >> When a node selects a new preferred parent it MUST send that parent >> a unicast DIO. If the node maintains a DIO cache the DIO sent MUST DAO I presume? >> include the prefixes in the DAO cache. If the node does not >> maintain a DIO cache and either the new preferred parent's DIO or >> the old preferred parent's DIO has the Destination Advertisements >> Cache set, then the node MUST set the Destination Advertisement >> Trigger in its own subsequent DIO. >> Several things: - A node should prefer a parent that can cache; If that's generic enough that should be in the DIO. - I fail to see why the DAG root does not set the flag. What happens if it is the only one that caches then? It appears that movements do not trigger DAOs though the source route path changes. - the D bit is not enough. The initial spec has a hash. In multihop source route, are you sure the D will propagate without a loss? The hash is one of those values that would cause resetting trickle if changed so it should propagate efficiently. - I think the node that does not cache should send a DAO to its parent when the hash in the DIO changes. The hash should start up there at the first parent (included) that caches and include the path down the preferred tree to this node. So if anything happens between the cache and this node, or if the parent that caches changes, this node knows and sends a DOA, and propagate the DIO with itself added to the changed hash, so the hash changes. IOW if there is a cache up there and if the path to that cache or the cache itself changes then this node must send a DAO to inform nodes along that path. DAOs can be absorbed by the cache up there if that yields no difference that requires informing its own parent. Are we on the same line? Pascal >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Mon Nov 23 07:15:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8607628C11E; Mon, 23 Nov 2009 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 gV3scGyFNbLr; Mon, 23 Nov 2009 07:15:44 -0800 (PST) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id 3D9083A6833; Mon, 23 Nov 2009 07:15:43 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKSwqnFq8SFxvVcijFAPnHm4vTavsynulr@postini.com; Mon, 23 Nov 2009 07:15:40 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009112309155027-105519 ; Mon, 23 Nov 2009 09:15:50 -0600 In-Reply-To: <19015.1258745921@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 23 Nov 2009 09:15:15 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/23/2009 09:15:27 AM, Serialize complete at 11/23/2009 09:15:27 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/23/2009 09:15:50 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/23/2009 09:16:01 AM, Serialize complete at 11/23/2009 09:16:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0053CAC886257677_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 15:15:45 -0000 This is a multipart message in MIME format. --=_alternative 0053CAC886257677_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Comments interlaced below. Jerry Michael Richardson Sent by: roll-bounces@ietf.org 11/20/2009 01:39 PM To roll@ietf.org cc Subject Re: [Roll] updating DAO caches (was Re: Something to ADD) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> As probably the strongest proponent of the P2P requirement Jerald> on this mailing list, I will readily admit that even in Jerald> building control only about 25% of the router nodes need to Jerald> pass intra-LLN P2P messages. As I understand the DAO 1/4 of the nodes need P2P messages, but how much traffic does that represent? Is it a big percentage of overall traffic? Does it have particular characteristics that make a trip through the root bad (i.e. latency) The traffic generated by these 25% of these intra-LLN is also about 25% of the overall traffic. As an example, a room controller may need to access the 'outdoor air temperature' and 'relative humidity' sensors so it can properly calculate its control algorithm. These two points are common to many rooms and will only be instrumented once. All other room control will need to reference these points. As for latency, this is important since the room control algorithm cannot be calculated until all input variables have been accessed. We need to complete the read request in under 500 ms. Jerald> So yes, I think we either need to design outward traffic Jerald> into the DAG at the same level as we do inward traffic; or Jerald> devise an on-demand scheme where a node can easily Jerald> 'discover' another node in the DAG as needed. Richard's Jerald> comment below is profound saying that right now establishing Jerald> a good outward link is a matter of luck, not design. When you say "discover", I think you mean: discover a path through cousin nodes that avoids the root Yes. Maybe 'discover' may mean something different in IETF parlance. Maybe 'find' a path would be better. The point I am trying to make is that right now using DAOs, we need to create and maintain a link for every node in the DAG on the chance that there may need to one day be a message that must traverse the link. So, on a 200 node network where every node might need to talk to any other node, there would need to be 39,800 (i.e. 200*199) links created and maintained. In reality only 50 links (i.e. 200*25%) are required. I'm suggesting that if we had a means to find a P2P path as needed, we could save significant processing power and DAG overhead. I too, would like to have this. good! I think that this could be a different protocol --- that it could leverage the communication used by the DAG to implement some kind of flood-fill algorithm to learn specific P2P routes that are important. I think the constraints of least-capable nodes excludes this from the base protocol -- but it's really want I think I care about. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSwbwP4CLcPvd0N1lAQIOjAf/VrBNnnxuVjhoV7CVZL2vuT1lJhJiMOH3 iDWPlL5OCjwjpkjnC2HLYIxxIYh+kMKrqUvea2BnEoMYIAgfG7MsjuU6eFIY5hMe gywIbHhf5Zs69HkWxO6uUj4h4F2eiJAJjrTp8b207DWEY+oR/Ky0m1ffH1TCGuOz jlwqsSMI94M/RLPSwCw/iGD/zLNDyjvI9Sird16YQ7TP2FM2JTRTqJPOpt74dNCR KPeWOUIfK5kKd3S9tYOYC1BRyWUNUFlDO1iApA5YCIcFhQbi3rCqtfJWQqqKcumC Ojw1sPchsmdfLb7ScYgYKOgdimkzG4Ga+jOdtCv0HqvrviwNJy+A3Q== =Ujy3 -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0053CAC886257677_= Content-Type: text/html; charset="US-ASCII"

Hi Michael,

Comments interlaced below.


Jerry




Michael Richardson <mcr@sandelman.ca>
Sent by: roll-bounces@ietf.org

11/20/2009 01:39 PM

To
roll@ietf.org
cc
Subject
Re: [Roll] updating DAO caches (was Re: Something to ADD)





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci@jci.com> writes:
   Jerald> As probably the strongest proponent of the P2P requirement
   Jerald> on this mailing list, I will readily admit that even in
   Jerald> building control only about 25% of the router nodes need to
   Jerald> pass intra-LLN P2P messages.  As I understand the DAO

1/4 of the nodes need P2P messages, but how much traffic does that
represent?  Is it a big percentage of overall traffic?  Does it have
particular characteristics that make a trip through the root bad
(i.e. latency)

The traffic generated by these 25% of these intra-LLN is also about 25% of the overall traffic.  As an example, a room controller may need to access the 'outdoor air temperature' and 'relative humidity' sensors so it can properly calculate its control algorithm.  These two points are common to many rooms and will only be instrumented once.  All other room control will need to reference these points.  As for latency, this is important since the room control algorithm cannot be calculated until all input variables have been accessed.  We need to complete the read request in under 500 ms.

   Jerald> So yes, I think we either need to design outward traffic
   Jerald> into the DAG at the same level as we do inward traffic; or
   Jerald> devise an on-demand scheme where a node can easily
   Jerald> 'discover' another node in the DAG as needed. Richard's
   Jerald> comment below is profound saying that right now establishing
   Jerald> a good outward link is a matter of luck, not design.

When you say "discover", I think you mean:
    discover a path through cousin nodes that avoids the root

Yes.  Maybe 'discover' may mean something different in IETF parlance.  Maybe 'find' a path would be better.  The point I am trying to make is that right now using DAOs, we need to create and maintain a link for every node in the DAG on the chance that there may need to one day be a message that must traverse the link.  So, on a 200 node network where every node might need to talk to any other node, there would need to be 39,800 (i.e. 200*199) links created and maintained.   In reality only 50 links (i.e. 200*25%) are required.  I'm suggesting that if we had a means to find a P2P path as needed, we could save significant processing power and DAG overhead.

I too, would like to have this.

good!

I think that this could be a different protocol --- that it could
leverage the communication used by the DAG to implement some kind of
flood-fill algorithm to learn specific P2P routes that are important.


I think the constraints of least-capable nodes excludes this from the
base protocol -- but it's really want I think I care about.

- --
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSwbwP4CLcPvd0N1lAQIOjAf/VrBNnnxuVjhoV7CVZL2vuT1lJhJiMOH3
iDWPlL5OCjwjpkjnC2HLYIxxIYh+kMKrqUvea2BnEoMYIAgfG7MsjuU6eFIY5hMe
gywIbHhf5Zs69HkWxO6uUj4h4F2eiJAJjrTp8b207DWEY+oR/Ky0m1ffH1TCGuOz
jlwqsSMI94M/RLPSwCw/iGD/zLNDyjvI9Sird16YQ7TP2FM2JTRTqJPOpt74dNCR
KPeWOUIfK5kKd3S9tYOYC1BRyWUNUFlDO1iApA5YCIcFhQbi3rCqtfJWQqqKcumC
Ojw1sPchsmdfLb7ScYgYKOgdimkzG4Ga+jOdtCv0HqvrviwNJy+A3Q==
=Ujy3
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0053CAC886257677_=-- From richard.kelsey@ember.com Mon Nov 23 08:23:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66663A6926 for ; Mon, 23 Nov 2009 08:23:39 -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 X5U5uMhVCPHI for ; Mon, 23 Nov 2009 08:23:38 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 946A43A68E7 for ; Mon, 23 Nov 2009 08:23:38 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:25:09 -0500 Date: Mon, 23 Nov 2009 11:19:40 -0500 Message-Id: <871vjp2oyr.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5DB0A1BD@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5DB0A1BD@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 23 Nov 2009 16:25:09.0078 (UTC) FILETIME=[86134760:01CA6C59] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 16:23:39 -0000 > Date: Mon, 23 Nov 2009 16:06:18 +0100 > From: "Pascal Thubert (pthubert)" > > Richard> In a network with no DAO caches the new (C) flag is never > Richard> set. Whenever a node moves it sends a single DAO that > Richard> propagates to the root, which stores the nodes new location. > > But then its children that are dragged along do not update the root? Correct. > That would work only if you use DAO for one_hop > information and leave it up to the root to rebuild the > source route. Please let us know what you have in mind > here, since that might yield complexities. Yes, it is what I have in mind. If the root has A->B->C->D->E in its cache and then it receives F->G->C, its route to E becomes F->G->C->D->E. I do not see where complexities could arise. > I'll continue with the assumption that the Reverse Route > Stack contains multiple hops. I wasn't proposing otherwise. > Richard> In a network where all nodes cache DAOs, a node that moves > Richard> sends the contents of its cache to its new parent. These > Richard> propagate up the tree, with each node forwarding on only > Richard> those prefixes which are new to its cache. The forwarding > Richard> stops when it reaches the least common ancestor of the > Richard> node's old and new locations. > > IF we all agree on the above, that is sending only to one preferred > parent, then there can only be one child that advertises a DAO > destination. Thus there can be only one route to a destination. Thus if > 2 children advertise a same destination, one is wrong. Not necessarily, if the destination is not on the subnet. There may be be redundant routes. > The newest sequence in the DAO indicates the one that is > correct. The other one should be cleaned up. The newest sequence is assumed to be correct. Earlier sequences may also be correct, but they are redundant and not saved. > Several things: > > - I fail to see why the DAG root does not set the flag. What happens if > it is the only one that caches then? It appears that movements do not > trigger DAOs though the source route path changes. If the DAG root sets the flag then sub-DAGs have to send DAOs after every move. Those DAOs contain no information that is not already cached on the root, so it is wasteful to send them. > - the D bit is not enough. The initial spec has a hash. In multihop > source route, are you sure the D will propagate without a loss? The hash > is one of those values that would cause resetting trickle if changed so > it should propagate efficiently. This is a good point. A hash doesn't work for what I am proposing, because a change in the route to the root does not necessarily require that a new DAO be sent. A sequence number might work. I'll have to think about it. As an aside, the DAO mechanism depends on the link layer being 100% reliable. If the link layer can lose messages a number of changes will be necessary. The ROLL document needs to be explicit about the link-layer requirements. > - I think the node that does not cache should send a DAO to its parent > when the hash in the DIO changes. The hash should start up there at the > first parent (included) that caches and include the path down the > preferred tree to this node. So if anything happens between the cache > and this node, or if the parent that caches changes, this node knows and > sends a DOA, and propagate the DIO with itself added to the changed > hash, so the hash changes. IOW if there is a cache up there and if the > path to that cache or the cache itself changes then this node must send > a DAO to inform nodes along that path. DAOs can be absorbed by the cache > up there if that yields no difference that requires informing its own > parent. This will again require nodes to send redundant DAOs, especially in the case where the only the root stores DAOs. -Richard Kelsey From pthubert@cisco.com Mon Nov 23 11:44:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE603A6781 for ; Mon, 23 Nov 2009 11:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.678, 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 YyKo47Zl+IlC for ; Mon, 23 Nov 2009 11:44:32 -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 580053A6AB3 for ; Mon, 23 Nov 2009 11:44:32 -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: AjEAAEZ1CkuQ/uCWe2dsb2JhbACcEwEBCwskBqMxlx+EPAQ X-IronPort-AV: E=Sophos;i="4.47,273,1257120000"; d="scan'208";a="55036255" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 19:44:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANJiRqE023357; Mon, 23 Nov 2009 19:44:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 20:44:27 +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, 23 Nov 2009 20:44:20 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DB6ED59@XMB-AMS-107.cisco.com> In-Reply-To: <871vjp2oyr.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches - a proposal Thread-Index: AcpsWU9nmbMvDUvhS+u/VvyCnvmCrgAF9T9g References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5DB0A1BD@XMB-AMS-107.cisco.com> <871vjp2oyr.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 23 Nov 2009 19:44:27.0185 (UTC) FILETIME=[5DA99A10:01CA6C75] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 19:44:34 -0000 Hi Richard >> >> But then its children that are dragged along do not update the root? > >Correct. > >> That would work only if you use DAO for one_hop >> information and leave it up to the root to rebuild the >> source route. Please let us know what you have in mind >> here, since that might yield complexities. > >Yes, it is what I have in mind. If the root has >A->B->C->D->E in its cache and then it receives >F->G->C, its route to E becomes F->G->C->D->E. > >I do not see where complexities could arise. One would be the massaging; It is easier for the node that caches to just store the source route info with the destination and not care about the path as you do here. But then, obviously there's a waste. Your proposal saves a lot of bandwidth. Another could be the sequence. DAOs can be out of sequence because they are cached. This is why DAOs have a sequence in the first place, an old sequence must not overwrite a newer one. Cache do not propagate source route so that's less of an issue. Still an info might pass another one. How can we be sure that F->G->C is newer than A->B->C->D->E. Should we really do F->G->C->D->E? If we compare your proposal with what I thought I understood from you at some point. Say that the source route DAOs are in the form E-via-D, so you end up with D-via-C etc... Then the nodes that do not cache just forward the bubbles unchanged up to the cache. One advantage is that each info can have its own sequence. Another is that when E' and E" both children of D send their own source route, there's no need to repeat the information for A->B->C->D. >From your algorithm, things become, nodes send a DAO to their parent with self as destination and a new sequence each time.=20 - If the parent caches, then it set a route down via the source of the DAO, caches, and later resend a DAO with the same destination as if it owned the destination. Such process could recurse to the top if all nodes cache, that's the normal DAO processing. - if the parent does not cache (say D->E, D does not cache), then D places 'viaD' in E's DAO. The DAO then flies unchanged up to the cache. - when the cache gets a DAO with a viaD information, it stores it together with the destination. During the route lookup, it will reassemble the via informations into a Routing header. The cache advertises all destinations as if it owns them and it hides that E has a via, so in its DAO. Flies? > >> I'll continue with the assumption that the Reverse Route >> Stack contains multiple hops. > >I wasn't proposing otherwise. I figured it made sense that you would :) >> Richard> In a network where all nodes cache DAOs, a node that moves >> Richard> sends the contents of its cache to its new parent. These >> Richard> propagate up the tree, with each node forwarding on only >> Richard> those prefixes which are new to its cache. The forwarding >> Richard> stops when it reaches the least common ancestor of the >> Richard> node's old and new locations. >> >> IF we all agree on the above, that is sending only to one preferred >> parent, then there can only be one child that advertises a DAO >> destination. Thus there can be only one route to a destination. Thus if >> 2 children advertise a same destination, one is wrong. > >Not necessarily, if the destination is not on the subnet. >There may be be redundant routes. Aie, I did not have that in mind; should we support that? >> The newest sequence in the DAO indicates the one that is >> correct. The other one should be cleaned up. > >The newest sequence is assumed to be correct. Earlier >sequences may also be correct, but they are redundant >and not saved. If we support the above. I thought we would not do transit but just stub. >> Several things: >> >> - I fail to see why the DAG root does not set the flag. What happens if >> it is the only one that caches then? It appears that movements do not >> trigger DAOs though the source route path changes. > >If the DAG root sets the flag then sub-DAGs have to send >DAOs after every move. Those DAOs contain no information >that is not already cached on the root, so it is wasteful >to send them. Makes more sense with your=20 A->B->C->D->E in its cache and then it receives F->G->C, its route to E becomes F->G->C->D->E I did not expect that behavior. >> - the D bit is not enough. The initial spec has a hash. In multihop >> source route, are you sure the D will propagate without a loss? The hash >> is one of those values that would cause resetting trickle if changed so >> it should propagate efficiently. > >This is a good point. A hash doesn't work for what I am >proposing, because a change in the route to the root does >not necessarily require that a new DAO be sent. A sequence >number might work. I'll have to think about it. If the sequence nb has also an id of the cache >As an aside, the DAO mechanism depends on the link layer >being 100% reliable. If the link layer can lose messages a >number of changes will be necessary. The ROLL document >needs to be explicit about the link-layer requirements. DAOs are repeated over and over. If one indicating a change is missed, there is a service interruption till the next > >> - I think the node that does not cache should send a DAO to its parent >> when the hash in the DIO changes. The hash should start up there at the >> first parent (included) that caches and include the path down the >> preferred tree to this node. So if anything happens between the cache >> and this node, or if the parent that caches changes, this node knows and >> sends a DOA, and propagate the DIO with itself added to the changed >> hash, so the hash changes. IOW if there is a cache up there and if the >> path to that cache or the cache itself changes then this node must send >> a DAO to inform nodes along that path. DAOs can be absorbed by the cache >> up there if that yields no difference that requires informing its own >> parent. > >This will again require nodes to send redundant DAOs, >especially in the case where the only the root stores DAOs. > Yes, I see what you have in mind now; Would work. We need to better understand all the pro/cons. cheers > -Richard Kelsey From richard.kelsey@ember.com Mon Nov 23 12:55:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECD03A688A for ; Mon, 23 Nov 2009 12:55:27 -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 p6DHhcJ6-xEo for ; Mon, 23 Nov 2009 12:55:27 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D358D3A6A18 for ; Mon, 23 Nov 2009 12:55:26 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:56:57 -0500 Date: Mon, 23 Nov 2009 15:51:27 -0500 Message-Id: <87ocmt0xtc.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5DB6ED59@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87d43e2uby.fsf@kelsey-ws.hq.ember.com> <035501ca6ad6$cd94ff40$68befdc0$@alexander@ekasystems.com> <6A2A459175DABE4BB11DE2026AA50A5DB0A1BD@XMB-AMS-107.cisco.com> <871vjp2oyr.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5DB6ED59@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 23 Nov 2009 20:56:57.0390 (UTC) FILETIME=[7E9634E0:01CA6C7F] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Nov 2009 20:55:27 -0000 > Date: Mon, 23 Nov 2009 20:44:20 +0100 > From: "Pascal Thubert (pthubert)" Pascal, I have to consider your response to my proposal. For now I will just respond to points you made about DAOs in the current draft. > >> IF we all agree on the above, that is sending only to one preferred > >> parent, then there can only be one child that advertises a DAO > >> destination. Thus there can be only one route to a destination. Thus > >> if 2 children advertise a same destination, one is wrong. > > > >Not necessarily, if the destination is not on the subnet. > >There may be be redundant routes. > > Aie, I did not have that in mind; should we support that? We do not prohibit it, which I would think means that we support it. I don't care one way or the other. > >As an aside, the DAO mechanism depends on the link layer > >being 100% reliable. If the link layer can lose messages a > >number of changes will be necessary. The ROLL document > >needs to be explicit about the link-layer requirements. > > DAOs are repeated over and over. If one indicating a change is missed, > there is a service interruption till the next If DAOs are sent repeatedly, what is the purpose of the `D' destination advertisement bit? Is it just to synchronize the sending of new DAOs rather than waiting for them to be sent? Also, in -04, section 5.9.1.3. says: When sending a destination advertisement to a DA parent, a node includes the DAOs for prefix entries not already reported (since the last DA Trigger from an DIO message) in the Reachable and Connected lists, as well as no-DAOs for all the entries in the Unreachable list. This indicates that a new DAO only includes new information. Prefix entries sent in an earlier DAO are not included in a later one. -Richard Kelsey From mdurvy@cisco.com Tue Nov 24 23:08:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118C83A6A1A for ; Tue, 24 Nov 2009 23:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.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 6kMM251uFNGu for ; Tue, 24 Nov 2009 23:08:16 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B19C13A6827 for ; Tue, 24 Nov 2009 23:08:15 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACZmDEutJV2d/2dsb2JhbAC9eZgEhDkE X-IronPort-AV: E=Sophos;i="4.47,284,1257120000"; d="scan'208";a="70115488" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 25 Nov 2009 07:08:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id nAP789g5028373; Wed, 25 Nov 2009 07:08:09 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 08:08:09 +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: Wed, 25 Nov 2009 08:08:08 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EECC4C1C@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DB09D76@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Trickle clarification: (in)consistency Thread-Index: Acpp9++VTBRRh6cSSsC6iBmBfj4wSQAG/3sQAGqLUaAAFOzHIABiwRTg References: <689FB194-FDF4-4940-BB9E-A9899C6EB2B4@cs.stanford.edu><8A977BDC5A7B0E429B0F521E8D6F91EEC4F345@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DB09B96@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DB09D76@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Julien Abeille (jabeille)" , "Jonathan Hui" X-OriginalArrivalTime: 25 Nov 2009 07:08:09.0214 (UTC) FILETIME=[0B1C39E0:01CA6D9E] Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Nov 2009 07:08:17 -0000 Hi Pascal, Jonathan, Thanks for your answers. I think we agree that child and other nodes could play a role to detect a consistent situation.=20 Hence, we need to see how this affects the DIO processing rules as you actually typically don't process DIOs from node deeper than you in the DAG... I also agree with Pascal and Julien when they say that consistency should concentrate on global or common DAG information. Best, Mathilde -----Original Message----- From: Pascal Thubert (pthubert)=20 Sent: lundi, 23. novembre 2009 08:55 To: Julien Abeille (jabeille); 'Jonathan Hui'; Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] Trickle clarification: (in)consistency Hi Julien Seems to me that so far we are saying the same thing. We'll be concentrating the DAG information in one option. That option should be consistent in an iteration. It should thus be subject to elision if it is redundant with C messages already heard during the trickle period. Other fields in the DIO might not be redundant though. My main concern is the routing information. My Rank is not my neighbor's Rank. Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: dimanche 22 novembre 2009 22:55 >To: Pascal Thubert (pthubert); Jonathan Hui; Mathilde Durvy (mdurvy) >Cc: roll@ietf.org >Subject: RE: [Roll] Trickle clarification: (in)consistency > >Hi Pascal, > >Not sure I understand your explanation. In a DIO there are informations >that are global to the DAG and some that are node specific. We use=20 >trickle because we consider DIO sending a consitency problem, hence we=20 >focus on the global information. They come both from parents and childs, so I would also increment C when hearing from a child. Am I missing something? > >Julien > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 >> Of Pascal Thubert (pthubert) >> Sent: vendredi 20 novembre 2009 20:12 >> To: Jonathan Hui; Mathilde Durvy (mdurvy) >> Cc: roll@ietf.org >> Subject: Re: [Roll] Trickle clarification: (in)consistency >> >> Hi Mathilde; >> >> I agree with Jonathan that we want to avoid redundancy. >> >> The rank of metric that a node advertises is an information about=20 >> self that cannot be inferred from the neighbors so it is *not*=20 >> redundant. If a number of nodes go down at the same time and one does >> not advertise, then that node will look better and will attract the=20 >> traffic. It will also attract the neighbors that went down and that=20 >> will be tempted to reattach to that apparent survivor. >> >> The information in the DIO that relates to the DAG configuration will >> be centralized in an option that IS redundant. We could add text that >> a node that see C of it MAY filter it out from its DIO. >> >> Finally the new sequence is redundant. I proposed to use it to limit=20 >> the density of routers using trickle. When you hear C router=20 >> advertising a new sequence you are entitled to stop being a router=20 >> for that sequence (stop trickle timer). The trickle timer would then=20 >> be restarted upon a DIS to serve orphans, and upon a next sequence to >> redistribute the load. >> >> Pascal >> >> >-----Original Message----- >> >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] >> On Behalf Of >> Jonathan Hui >> >Sent: vendredi 20 novembre 2009 16:41 >> >To: Mathilde Durvy (mdurvy) >> >Cc: roll@ietf.org >> >Subject: Re: [Roll] Trickle clarification: (in)consistency >> > >> > >> >Hi Mathilde, >> > >> >On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: >> > >> >>> - when do we increment C? >> >> >> >> The node MAY increment C when it hears another DIO. >> >> >> >> I think the spec says that a node MAY increment C each >> time it hears >> a >> >> "consistent DIO for this DAG from a DAG parent". What fields are=20 >> >> included in the consistency check? If only generic DAG information >> are >> >> checked you might want to look at DIO from non-DAG parents, no? >> > >> >You're right, this text in the draft is incorrect. There's an=20 >> >important distinction to make here. We want to quickly send DIO=20 >> >transmissions (reset the Trickle timer) whenever >> *inconsistencies* are >> >detected. But you want to suppress DIO transmissions (increment C)=20 >> >whenever *redundancies* are detected. While you can detect=20 >> >inconsistencies by listening to your DAG parent(s), >> redundancies will >> >probably come from your siblings/cousins. >> > >> >We are looking to update the text around incrementing C and >> make what >> >constitutes a redundancy more precise. >> > >> >-- >> >Jonathan Hui >> > >> >_______________________________________________ >> >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 jabeille@cisco.com Wed Nov 25 01:43:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D341428C1F7 for ; Wed, 25 Nov 2009 01:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.71 X-Spam-Level: X-Spam-Status: No, score=-9.71 tagged_above=-999 required=5 tests=[AWL=0.889, 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 46k6UgkzYDVW for ; Wed, 25 Nov 2009 01:43:50 -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 94A623A684C for ; Wed, 25 Nov 2009 01:43:49 -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: AkAAAKaLDEuQ/uCWe2dsb2JhbACcFwEBCwskBqFLmAWEOQSNGA X-IronPort-AV: E=Sophos;i="4.47,285,1257120000"; d="scan'208";a="55166145" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2009 09:43:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAP9hhYb016073; Wed, 25 Nov 2009 09:43:43 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:43:43 +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: Wed, 25 Nov 2009 10:43:41 +0100 Message-ID: In-Reply-To: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] multicast DAO Thread-Index: AcpqD7pOO01zNr2wQ7mC/JtJH+quRQDo3nYA References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> From: "Julien Abeille (jabeille)" To: "Philip Levis" X-OriginalArrivalTime: 25 Nov 2009 09:43:43.0727 (UTC) FILETIME=[C6E9DFF0:01CA6DB3] Cc: ROLL WG Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Nov 2009 09:43:50 -0000 Hi Phil,=20 Sorry for the delayed response.=20 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: vendredi 20 novembre 2009 19:31 > To: Julien Abeille (jabeille) > Cc: ROLL WG > Subject: Re: [Roll] multicast DAO >=20 >=20 > On Oct 28, 2009, at 9:29 AM, Julien Abeille (jabeille) wrote: >=20 > > Hi all, > > > > regarding usage of multicast DAO: in the following scenario: > > A > > / \ > > B C > > > > if the purpose is to to allow B and C to talk to each other=20 > directly,=20 > > the multicast DAO is equivalent to an unsolicited NA. > > > > In the scenarios like: > > > > A > > / \ > > B C > > | > > D > > if the purpose is to have B talk to D through C (instead of=20 > A then C),=20 > > then the multicast DAO (including destination prefix option) makes=20 > > sense. > > Is this scenario needed by some applications? >=20 > Julien, >=20 > The text in -04 reads: >=20 > "The objective [of multicast DAOs] is to enable direct P2P=20 > communication, between destinations directly supported by=20 > neighboring nodes, without needing the RPL routing structure=20 > to relay the packets." >=20 > So the case it's concerned with is the latter one: B to C to D. =20 > Clearly one could use NA for the B-C case. >=20 Two questions: is it really a scenario (B to C to D) that happens a lot. I feel it is not generic at all, hence we should focus on a more generic way to solve the P2P problem.=20 > Point-to-point communication between nodes is needed by some=20 > applications. Section 5.2.2 of=20 > draft-ietf-roll-building-routing-reqs-07: >=20 > "A network device MUST be able to communicate in a=20 > point-to-point manner with any other device on the network." >=20 Sure, and DAOs (whether stored only at root are not) solve this issue. May not be the most efficient, but the sceanrios multicast DAOs solve are so limited that we will end up with 10 solutions for 10 scenarios if we go that path. I would personaly drop multicast DAOs Best, Julien > Do you agree? Is it OK to resolve this ticket? >=20 > Phil >=20 >=20 From richard.kelsey@ember.com Wed Nov 25 05:43:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8D628C11A for ; Wed, 25 Nov 2009 05:43:10 -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 xDTz54Brfsbm for ; Wed, 25 Nov 2009 05:43:09 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A2ABB28C10A for ; Wed, 25 Nov 2009 05:43:09 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 08:44:40 -0500 Date: Wed, 25 Nov 2009 08:39:03 -0500 Message-Id: <87k4xe207c.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> X-OriginalArrivalTime: 25 Nov 2009 13:44:40.0593 (UTC) FILETIME=[6FE09010:01CA6DD5] Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Nov 2009 13:43:10 -0000 > Date: Wed, 25 Nov 2009 10:43:41 +0100 > From: "Julien Abeille (jabeille)" > > From: Philip Levis [mailto:pal@cs.stanford.edu] > > Sent: vendredi 20 novembre 2009 19:31 > > > > Point-to-point communication between nodes is needed by some > > applications. Section 5.2.2 of > > draft-ietf-roll-building-routing-reqs-07: > > > > "A network device MUST be able to communicate in a > > point-to-point manner with any other device on the network." > > Sure, and DAOs (whether stored only at root are not) solve this issue. > May not be the most efficient, but the sceanrios multicast DAOs solve > are so limited that we will end up with 10 solutions for 10 scenarios if > we go that path. > > I would personaly drop multicast DAOs I agree. As we have done with unicasts, we need to look carefully at the multicast requirements and find ways to solve the easy and/or common cases first. I do not think that there is a workable one-size-fits-all multicast solution. -Richard Kelsey From prvs=57375d984=mukul@uwm.edu Wed Nov 25 10:36:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2503A68DE for ; Wed, 25 Nov 2009 10:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foJ08p3gLe5M for ; Wed, 25 Nov 2009 10:36:23 -0800 (PST) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 9A7F63A6359 for ; Wed, 25 Nov 2009 10:36:23 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 25 Nov 2009 12:36:16 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4E346C085C8 for ; Wed, 25 Nov 2009 12:36:16 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgl8gcHzsYWY for ; Wed, 25 Nov 2009 12:36:16 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 2B670C085A0 for ; Wed, 25 Nov 2009 12:36:16 -0600 (CST) Date: Wed, 25 Nov 2009 12:36:16 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <2124521039.3952161259174176083.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] A paper on routing loops in DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Nov 2009 18:37:11 -0000 Hi all, Here is a simulations-based paper on transient routing loops in DAGs and the efficacy of loop avoidance (advertise infinite rank before increasing rank) in dealing with routing loops: http://www.cs.uwm.edu/~mukul/dag_loops.pdf We basically make the point that, in most cases, the routing loops get resolved quickly on their own and any extra loop avoidance (involving advertising an infinite rank and consequent dismantling of the sub-DAG) may cause more turmoil in the network than the routing loops themselves. Thanks Mukul From mdurvy@cisco.com Thu Nov 26 02:30:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C328C0FB for ; Thu, 26 Nov 2009 02:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=-3.473, BAYES_20=-0.74, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Ob+zMNCGVymp for ; Thu, 26 Nov 2009 02:30:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 016923A62C1 for ; Thu, 26 Nov 2009 02:30:50 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GALPnDUtAZnwM/2dsb2JhbACCIywhuVmXZAKEMAQ X-IronPort-AV: E=Sophos;i="4.47,292,1257120000"; d="gif'147?scan'147,208,217,147";a="70350765" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Nov 2009 10:30:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAQAUasG011701 for ; Thu, 26 Nov 2009 10:30:45 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 11:30:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA6E83.80A0934A" Date: Thu, 26 Nov 2009 11:30:39 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EED23EB0@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification: Stale DAO Thread-Index: Acpug3/bwKnJoGxwRsaMmgmSSOcgfA== From: "Mathilde Durvy (mdurvy)" To: "ROLL WG" X-OriginalArrivalTime: 26 Nov 2009 10:30:41.0757 (UTC) FILETIME=[8100E0D0:01CA6E83] Subject: [Roll] Clarification: Stale DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Nov 2009 10:30:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6E83.80A0934A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6E83.80A0934A" ------_=_NextPart_002_01CA6E83.80A0934A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I need some clarification on the paragraph below: The sequence counter is incremented by the source of the DAO message = (the node that owns the prefix, or learned the prefix via some other means), each time it issues a DAO message for its prefix.... Further, if the DAO message appears to be out of synch (the sequence counter is 2 or more behind the present value) then the DAO state is considered to be stale and may be purged, and the DAO message is discarded. =20 It seems to me that out of synch DAO message can only happen if a node = receives DAO message for the same prefix from two different children = (note that this implies multiple DA parents). =20 If that is the case it means that the node should remove the route going = through the child advertising the prefix with a stale sequence number = (and keep the more up-to-date route via the other child) =20 Is my reasoning correct? =20 Best, Mathilde =20 =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA6E83.80A0934A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I need some clarification on = the paragraph=20 below:


   The=20 sequence counter is incremented by the source of the DAO = message=20 (the
   node that = owns the=20 prefix, or learned the prefix via some other
   means), each time it = issues a DAO=20 message for its prefix....

   Further, if the DAO message appears = to be out of=20 synch (the sequence
  =20 counter is 2 or more behind the present value) then the DAO state = is
   considered = to be stale=20 and may be purged, and the DAO message is
   = discarded.

 

It seems to me that out of = synch DAO=20 message can only happen if a node receives DAO message for the same = prefix from=20 two different children (note that this implies multiple = DA=20 parents).

 

If that is the case it means = that the node=20 should remove the route going through the child advertising the prefix = with a=20 stale sequence number (and keep the more up-to-date route via the other=20 child)

 

Is my reasoning = correct?

 

Best,

Mathilde

 

 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA6E83.80A0934A-- ------_=_NextPart_001_01CA6E83.80A0934A Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA6E83.80A0934A Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA6E83.80A0934A-- From gnawali@cs.stanford.edu Sun Nov 29 05:53:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05EE3A68AA for ; Sun, 29 Nov 2009 05:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZMHOxeY8hsY for ; Sun, 29 Nov 2009 05:53:31 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 406703A6403 for ; Sun, 29 Nov 2009 05:53:31 -0800 (PST) Received: from mail-qy0-f191.google.com ([209.85.221.191]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NEkDM-0007Mp-0h for roll@ietf.org; Sun, 29 Nov 2009 05:53:24 -0800 Received: by qyk29 with SMTP id 29so1178370qyk.32 for ; Sun, 29 Nov 2009 05:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.15.210 with SMTP id l18mr1545284qaa.91.1259502803067; Sun, 29 Nov 2009 05:53:23 -0800 (PST) In-Reply-To: <4AFEEC0D.80002@sics.se> References: <5D97617F-EC66-4DA6-9A97-2AFE07C380D0@cs.stanford.edu> <4AFEC9B8.1080102@sics.se> <4AFEEC0D.80002@sics.se> Date: Sun, 29 Nov 2009 05:53:23 -0800 Message-ID: From: Omprakash Gnawali To: Joakim Eriksson Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll Subject: Re: [Roll] trickle question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Nov 2009 13:53:32 -0000 On Sat, Nov 14, 2009 at 9:42 AM, Joakim Eriksson wrote: > Hi, > > Well the difference is that you do not need to treat the I > (interval) as a timer, so it would be: > > Some pseudo code: > > When T triggers: > -- > if (C > REDUNDANCY_CONSTANT) sendDIO(); That was a typo "When the timer fires at time T, the node compares C to the redundancy constant, DEFAULT_DIO_REDUNDANCY_CONSTANT. If C is less than that value, the node generates a new RA and broadcasts it." ... > C = 0; > if (doublings++ < max_doublings) I = I * 2; > T.start(I/2 + rand() * I/2); > -- > > The only timer that is needed is T in this case. > > > Based on specification it needs to be: > > When T triggers: > -- > if (C > REDUNDANCY_CONSTANT) sendDIO(); Same typo. - om_p From gnawali@cs.stanford.edu Sun Nov 29 13:13:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2631A3A681F for ; Sun, 29 Nov 2009 13:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze7S9XaG6NKH for ; Sun, 29 Nov 2009 13:13:06 -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 B7ED228C0D7 for ; Sun, 29 Nov 2009 13:13:06 -0800 (PST) Received: from mail-qy0-f191.google.com ([209.85.221.191]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NEr4l-00068D-KU for roll@ietf.org; Sun, 29 Nov 2009 13:13:00 -0800 Received: by qyk29 with SMTP id 29so1277175qyk.32 for ; Sun, 29 Nov 2009 13:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.102.207 with SMTP id h15mr1715337qao.139.1259529178750; Sun, 29 Nov 2009 13:12:58 -0800 (PST) Date: Sun, 29 Nov 2009 13:12:58 -0800 Message-ID: From: Omprakash Gnawali To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: roll Subject: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Nov 2009 21:13:17 -0000 On Sat, Nov 14, 2009 at 11:12 AM, Philip Levis wrote: > > On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: > >> Hello Phil and Julien, >> >> Is it really necessary to wait until the complete I interval has >> passed before doubling I and restarting T (with the new interval)? >> >> It feels that we get basically the same behavior with less complex >> code if we skip the wait for the complete interval to pass. > > Hm -- I can't recall if I tried this variant. I'm searching around for th= e > analytical simulator source code, if I find it, I'll let you know. > > One thing is that trickle is more efficient when intervals are synchroniz= ed > (it sends half as many messages). Let's say you reset the interval after = T. > First, the average interval length is 0.75I, leading to 33% more messages= . > Second, it will inherently desynchronize intervals, leading to twice as m= any > messages compared to the best case. This is a total overhead of sending > approximately 2.5 times as many messages if you don't. Of course, the 33% > also results in a lower detection latency. > > Given how the interval length changes, if you want to implement it this w= ay, > *all* nodes need to do so, or you break load balancing. > > But this is just off the top of my head. The behavior of protocols like > these can often be not something you'd expect (e.g., "basically the same > behavior"). I would definitely run some tests to see how it behaves under > very high density. It could be that nodes which pick small T values end u= p > shouldering more of the load due to a variant of the short listen problem= . > =A0My intuition is that this is a shortcut which probably isn't worth it = as it > might bite you later, but that intuition could be wrong. > > Usually, it's just easier to keep track of the rand() result, rather than > keep two timers. I ran the version than Joakim suggested (Truncated interval) and the one of the draft (Full interval). Here are the results: http://stuff.stanford.edu/~om_p/ctp/trickle-interval/beacontime.html (Graph with lots of lines show number of beacons for each node). Experiment setup: - 55 nodes with cc2420 radios (Tutornet) - max interval 512s - 0 dBm transmit power - CTP Noe as is and with modifications for truncated interval Result: Larger number of beacons with Truncated intervals, otherwise performance measured in delivery ratio and cost (excluding control pkts) similar. We can use a larger interval with the truncated interval to match the number of beacons with the full interval. It makes sense to use the simplified specification. - om_p From pal@cs.stanford.edu Sun Nov 29 18:08:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436833A67C0 for ; Sun, 29 Nov 2009 18:08:49 -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 lyKs9E-dMedY for ; Sun, 29 Nov 2009 18:08:48 -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 5819B3A67AA for ; Sun, 29 Nov 2009 18:08:48 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NEvgu-00005P-Ip; Sun, 29 Nov 2009 18:08:40 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Sun, 29 Nov 2009 18:08:35 -0800 To: Omprakash Gnawali X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 02:08:49 -0000 On Nov 29, 2009, at 1:12 PM, Omprakash Gnawali wrote: > On Sat, Nov 14, 2009 at 11:12 AM, Philip Levis > wrote: >> >> On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: >> >>> Hello Phil and Julien, >>> >>> Is it really necessary to wait until the complete I interval has >>> passed before doubling I and restarting T (with the new interval)? >>> >>> It feels that we get basically the same behavior with less complex >>> code if we skip the wait for the complete interval to pass. >> >> Hm -- I can't recall if I tried this variant. I'm searching around >> for the >> analytical simulator source code, if I find it, I'll let you know. >> >> One thing is that trickle is more efficient when intervals are >> synchronized >> (it sends half as many messages). Let's say you reset the interval >> after T. >> First, the average interval length is 0.75I, leading to 33% more >> messages. >> Second, it will inherently desynchronize intervals, leading to >> twice as many >> messages compared to the best case. This is a total overhead of >> sending >> approximately 2.5 times as many messages if you don't. Of course, >> the 33% >> also results in a lower detection latency. >> >> Given how the interval length changes, if you want to implement it >> this way, >> *all* nodes need to do so, or you break load balancing. >> >> But this is just off the top of my head. The behavior of protocols >> like >> these can often be not something you'd expect (e.g., "basically >> the same >> behavior"). I would definitely run some tests to see how it >> behaves under >> very high density. It could be that nodes which pick small T >> values end up >> shouldering more of the load due to a variant of the short listen >> problem. >> My intuition is that this is a shortcut which probably isn't >> worth it as it >> might bite you later, but that intuition could be wrong. >> >> Usually, it's just easier to keep track of the rand() result, >> rather than >> keep two timers. > > I ran the version than Joakim suggested (Truncated interval) and the > one of the draft (Full interval). Here are the results: > http://stuff.stanford.edu/~om_p/ctp/trickle-interval/beacontime.html > > (Graph with lots of lines show number of beacons for each node). > > Experiment setup: > - 55 nodes with cc2420 radios (Tutornet) > - max interval 512s > - 0 dBm transmit power > - CTP Noe as is and with modifications for truncated interval > > Result: Larger number of beacons with Truncated intervals, otherwise > performance measured in delivery ratio and cost (excluding control > pkts) similar. We can use a larger interval with the truncated > interval to match the number of beacons with the full interval. > > It makes sense to use the simplified specification. Om -- I think it deserves greater investigation than a single experiment. Joakim has been examining the effect more deeply. There are other optimizations that one can do (such as Gummadi's suggestion of suppression time). Phil From roger.alexander@ekasystems.com Sun Nov 29 19:18:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CE13A688C for ; Sun, 29 Nov 2009 19:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_40=-0.185, 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 bnWkq11SnF5z for ; Sun, 29 Nov 2009 19:18:15 -0800 (PST) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id 6BA9A3A683D for ; Sun, 29 Nov 2009 19:18:15 -0800 (PST) Received: (qmail 83747 invoked from network); 30 Nov 2009 03:18:06 -0000 Received: from c-69-143-218-61.hsd1.md.comcast.net (roger.alexander@69.143.218.61 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 29 Nov 2009 19:18:06 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: rTH8Y.IVM1nEmqzkITnOiWfzeXQP_LoD4UDi_kdJexIQajR248AOggIAL3BV.IJDC3B9o.jGr8XC7iWzBekN.jMFuagQoajfExtHBUurSBQJYYu6JRt3QZxGPEgWA8bwON.G9_lCzGJLb_Gime0FY2swIBNK8IHiycFnGMuTbfDCaxlDUc7OFcWur5ymFcarV0lCKfPVwii4k66OPkHCAu5Rmyr24MpvDxM_2KcZYMlMhUWma9VzFu8XHgP3TEiP7o3uG_iCm7EPlYI4VcCJfUCCzbG2DwQSTIvIEFCfnk.d8l_Y4eJQIu2bPXPWbV5xrg8ewOP4DpjvXGTWrsWKYmi1ICFOOEB5fEs22rHzGFt3wcxIcVaKTxCF1yD_kCyR7OjFpfA9jNLYLuqp6Eqami7HfvZo X-Yahoo-Newman-Property: ymail-3 Message-Id: From: Roger Alexander To: "Pascal Thubert \(pthubert\)" Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 29 Nov 2009 22:18:02 -0500 Cc: "" Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 03:18:18 -0000 Hi Pascal, Richard, others, On Nov 23, 2009, at 7:06 AM, "Pascal Thubert (pthubert)" wrote: > Hello Roger (and Richard) > > I think I'm mostly with you too. > Need to make sure we're fully on the same page. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > Roger K. Alexander >> Sent: samedi 21 novembre 2009 19:17 >> To: 'Richard Kelsey'; roll@ietf.org >> Subject: Re: [Roll] updating DAO caches - a proposal >> >> Hi Richard, >> >> As indicated below, I would support this proposal as a base for >> further > DAO >> operation specification. >> >> Roger >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >>> Richard Kelsey >>> Sent: Thursday, November 19, 2009 2:22 PM >>> To: roll@ietf.org >>> Subject: [Roll] updating DAO caches - a proposal >>> >>> >>> Below is an actual concrete proposal for managing DAO >>> caches. I believe that this would work well when all nodes >>> cache DAOs and when no nodes do so. It does a reasonable >>> job when only some nodes cache DAOs, although in some >>> situations there will be some superfluous DAOs transmitted. >>> >>> This assumes that DAOs are sent only to the preferred >>> parent. If DAO are sent to multiple parents the situation >>> becomes more complex. > > YES. > > Fanning out does not guarantee multipath opportunities on the way > back. > And that creates overload of states. > > Indeed multiple parents do not guarantee diverse outward end-to-end paths but it improves the potential. The use of just a single (acknowledged) parent should be left as an implementation choice (note that nodes can also maintain state for other non-acknowledged parent nodes without sending DAO updates to those nodes). Multiple parents need to be supported as part of the core RPL specification. >>> In a network with no DAO caches the new (C) flag is never >>> set. Whenever a node moves it sends a single DAO that >>> propagates to the root, which stores the nodes new location. > > But then its children that are dragged along do not update the root? > > That would work only if you use DAO for one_hop information and > leave it > up to the root to rebuild the source route. > Please let us know what you have in mind here, since that might yield > complexities. > > I'll continue with the assumption that the Reverse Route Stack > contains > multiple hops. > >>> In a network where all nodes cache DAOs, a node that moves >>> sends the contents of its cache to its new parent. These >>> propagate up the tree, with each node forwarding on only >>> those prefixes which are new to its cache. The forwarding >>> stops when it reaches the least common ancestor of the >>> node's old and new locations. >> >> Agreed. > > IF we all agree on the above, that is sending only to one preferred > parent, then there can only be one child that advertises a DAO > destination. Thus there can be only one route to a destination. Thus > if > 2 children advertise a same destination, one is wrong. > The specification should allow nodes to be able to maintain multiple (acknowledged) parents. > The newest sequence in the DAO indicates the one that is correct. The > other one should be cleaned up. > > > Do we agree in this one? Yes. Furthermore, with multiple parents the given sequence number associated with the update will ensure that updates arriving on different paths allow a common ancestor to maintain multiple forward (outward) routes. Note, delays or loss of DAO updates on different paths to the common ancestor can lead to temporary elimination of segments of the potential multiple outward paths. > >> >>> In a mixed network, nodes with caches and nodes whose only >>> caching ancestor is the root will have the same behavior >>> as above. A node without a cache will send its own DAO and >>> set the Destination Advertisement Trigger to cause its >>> sub-DAG to send DAOs as well. The Trigger will propagate >>> downwards causing more DAOs to be sent, but descedents that >>> have a cache will not propagate the Trigger to their own >>> sub-DAG. >> >> Some further refinement may need to be considered. Where nodes >> maintain > DAO >> caches the triggering of outward routing updates to the sub-DAG is >> not >> needed unless there has been a change in the path cost from the >> moving > node > > We agree. For all I understand, a node that caches 'absorbs' the D > bit; > that is it updates the parent that has set the D bit with its all > cache > and does not propagate the D bit. > > Metrics changes are subject to the trickle exponential backoff but > that > is a different process. If there is a significant change, the child > will > be told by the parent from that process, and either dump its cache (if > it caches) or send its DAO and send a DIO with the D bit set (if it > does > not cache). Agreed. >> to the DAG root, which would then affect connectivity decisions of >> the >> sub-DAG nodes (one of the traffic reducing benefits of multiple >> parents > is >> the potential to mute the effect of individual link connectivity > changes). >> For nodes that do not maintain DAO caches, it should be possible to > apply >> the same mechanism since the moving parent node sends a DAO update > towards >> the root updating subsequent outward routes. >> > > Hum. I fear that we are back to the 'one hop' source route > collection I > discussed above with the root rebuilding the source route > recursively. I > hope we are not going that way... The root or other state-maintaining node would be capable of rebuilding the source route recursively. For 'mixed' node environments, other stateful nodes will need to support this processing as well. > >>> >>> -Richard Kelsey >>> >>> ---------------- >>> Proposal: >>> >>> Add a new DIO flag: >>> >>> Destination Advertisements Cache (C): The Destination >>> Advertisement Cache (C) flag is set when a node below >>> the DAG root in the successor chain caches DAOs sent >>> upwards. DAG roots NUST NOT set this flag. Nodes >>> below the root that maintain a DAO cache MUST set this >>> flag. Nodes below the root that do not maintain a DAO >>> cache MUST set this flag to the value received from >>> their preferred DAG Parent. >>> >>> >>> In 5.10.1.1. replace >>> >>> A node that modifies its DAG Parent set may set the `D' bit in >>> subsequent DIO propagation in order to trigger destination >>> advertisements to be updated to its DAG Parents and other > ancestors >>> on the DAG. Additional recommendations and guidelines regarding >>> the use of this mechanism are still under consideration and will > be >>> elaborated in a future revision of this specification. >>> >>> with >>> >>> When a node selects a new preferred parent it MUST send that > parent >>> a unicast DIO. If the node maintains a DIO cache the DIO sent > MUST > > DAO I presume? > >>> include the prefixes in the DAO cache. If the node does not >>> maintain a DIO cache and either the new preferred parent's DIO or >>> the old preferred parent's DIO has the Destination Advertisements >>> Cache set, then the node MUST set the Destination Advertisement >>> Trigger in its own subsequent DIO. >>> > > > Several things: > > - A node should prefer a parent that can cache; If that's generic > enough > that should be in the DIO. > OK. > - I fail to see why the DAG root does not set the flag. What happens > if > it is the only one that caches then? It appears that movements do not > trigger DAOs though the source route path changes. > > - the D bit is not enough. The initial spec has a hash. In multihop > source route, are you sure the D will propagate without a loss? The > hash > is one of those values that would cause resetting trickle if changed > so > it should propagate efficiently. > > - I think the node that does not cache should send a DAO to its parent > when the hash in the DIO changes. The hash should start up there at > the > first parent (included) that caches and include the path down the > preferred tree to this node. So if anything happens between the cache > and this node, or if the parent that caches changes, this node knows > and > sends a DOA, and propagate the DIO with itself added to the changed > hash, so the hash changes. IOW if there is a cache up there and if the > path to that cache or the cache itself changes then this node must > send > a DAO to inform nodes along that path. DAOs can be absorbed by the > cache > up there if that yields no difference that requires informing its own > parent. > > Are we on the same line? > Yes. I think this may be part of the tradeoff for a stateless node. A node that maintains state will send a DIO on its sub-DAG only if there is a cost change to the root. > > Pascal > > >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Sun Nov 29 19:37:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E80D3A67AB for ; Sun, 29 Nov 2009 19:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, 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 dryCRpYspIVT for ; Sun, 29 Nov 2009 19:37:33 -0800 (PST) Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by core3.amsl.com (Postfix) with SMTP id A40FC3A6765 for ; Sun, 29 Nov 2009 19:37:32 -0800 (PST) Received: (qmail 70159 invoked from network); 30 Nov 2009 03:37:23 -0000 Received: from c-69-143-218-61.hsd1.md.comcast.net (roger.alexander@69.143.218.61 with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 29 Nov 2009 19:37:22 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 5MmugVEVM1n5GWUzT1v2PbeO5lwVual50CM1e1BR8qB7q33WhW4Hqyj9V_jCzaRS28aSuSfHiJY4hSVI659wbIneCeSnsNQgzUhJXS.KS6jzD08bo8jax4VXudcY7tcGb48ov195YIklcwHGtxZ6ezIk5QPMeYWsvyCVum6ySQvCarjJt026GaaSbvWDEgpSrtULJzBde26ff9g3ToTXdCrbA0jCyDhR7PHgOysRAaCT.vMDzIimZlSeToQGOZdxWM_IzfF23M_v3hfbNNoH0ZNRafcpOa.aVo0Fo5qecimb._d_2mr_0QoqMJAwphR909v0jhngK98AbdRhzht8IUdILwsVe3SkAkRb1ENwF6uyi5XQDmaNyUlIr5LUIfxUIUVYGaVPiSWDNXOcJfZkZWk.TOFW X-Yahoo-Newman-Property: ymail-3 Message-Id: From: Roger Alexander To: "Pascal Thubert \(pthubert\)" Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 29 Nov 2009 22:37:20 -0500 Cc: "" Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 03:37:34 -0000 On Nov 23, 2009, at 12:44 PM, "Pascal Thubert (pthubert)" wrote: > Hi Richard > >>> >>> But then its children that are dragged along do not update the root? >> >> Correct. >> >>> That would work only if you use DAO for one_hop >>> information and leave it up to the root to rebuild the >>> source route. Please let us know what you have in mind >>> here, since that might yield complexities. >> >> Yes, it is what I have in mind. If the root has >> A->B->C->D->E in its cache and then it receives >> F->G->C, its route to E becomes F->G->C->D->E. >> >> I do not see where complexities could arise. > > One would be the massaging; It is easier for the node that caches to > just store the source route info with the destination and not care > about > the path as you do here. But then, obviously there's a waste. Your > proposal saves a lot of bandwidth. > > Another could be the sequence. DAOs can be out of sequence because > they > are cached. This is why DAOs have a sequence in the first place, an > old > sequence must not overwrite a newer one. Cache do not propagate source > route so that's less of an issue. Still an info might pass another > one. > How can we be sure that F->G->C is newer than A->B->C->D->E. Should we > really do F->G->C->D->E? > > If we compare your proposal with what I thought I understood from > you at > some point. Say that the source route DAOs are in the form E-via-D, so > you end up with D-via-C etc... Then the nodes that do not cache just > forward the bubbles unchanged up to the cache. One advantage is that > each info can have its own sequence. Another is that when E' and E" > both > children of D send their own source route, there's no need to repeat > the > information for A->B->C->D. > > From your algorithm, things become, nodes send a DAO to their parent > with self as destination and a new sequence each time. > - If the parent caches, then it set a route down via the source of the > DAO, caches, and later resend a DAO with the same destination as if it > owned the destination. Such process could recurse to the top if all > nodes cache, that's the normal DAO processing. > - if the parent does not cache (say D->E, D does not cache), then D > places 'viaD' in E's DAO. The DAO then flies unchanged up to the > cache. > - when the cache gets a DAO with a viaD information, it stores it > together with the destination. During the route lookup, it will > reassemble the via informations into a Routing header. The cache > advertises all destinations as if it owns them and it hides that E > has a > via, so in its DAO. > > Flies? Yes it is also consistent with the vision of a model in which the DAO update process works uniformly independent of whether nodes maintain or do not maintain state. > >> >>> I'll continue with the assumption that the Reverse Route >>> Stack contains multiple hops. >> >> I wasn't proposing otherwise. > > I figured it made sense that you would :) > > >>> Richard> In a network where all nodes cache DAOs, a node that moves >>> Richard> sends the contents of its cache to its new parent. These >>> Richard> propagate up the tree, with each node forwarding on only >>> Richard> those prefixes which are new to its cache. The forwarding >>> Richard> stops when it reaches the least common ancestor of the >>> Richard> node's old and new locations. >>> >>> IF we all agree on the above, that is sending only to one preferred >>> parent, then there can only be one child that advertises a DAO >>> destination. Thus there can be only one route to a destination. Thus > if >>> 2 children advertise a same destination, one is wrong. >> >> Not necessarily, if the destination is not on the subnet. >> There may be be redundant routes. > > Aie, I did not have that in mind; should we support that? > > > >>> The newest sequence in the DAO indicates the one that is >>> correct. The other one should be cleaned up. >> >> The newest sequence is assumed to be correct. Earlier >> sequences may also be correct, but they are redundant >> and not saved. > > If we support the above. I thought we would not do transit but just > stub. > > >>> Several things: >>> >>> - I fail to see why the DAG root does not set the flag. What happens > if >>> it is the only one that caches then? It appears that movements do >>> not >>> trigger DAOs though the source route path changes. >> >> If the DAG root sets the flag then sub-DAGs have to send >> DAOs after every move. Those DAOs contain no information >> that is not already cached on the root, so it is wasteful >> to send them. > > Makes more sense with your > A->B->C->D->E in its cache and then it receives > F->G->C, its route to E becomes F->G->C->D->E > I did not expect that behavior. > >>> - the D bit is not enough. The initial spec has a hash. In multihop >>> source route, are you sure the D will propagate without a loss? The > hash >>> is one of those values that would cause resetting trickle if changed > so >>> it should propagate efficiently. >> >> This is a good point. A hash doesn't work for what I am >> proposing, because a change in the route to the root does >> not necessarily require that a new DAO be sent. A sequence >> number might work. I'll have to think about it. > > If the sequence nb has also an id of the cache > > >> As an aside, the DAO mechanism depends on the link layer >> being 100% reliable. If the link layer can lose messages a >> number of changes will be necessary. The ROLL document >> needs to be explicit about the link-layer requirements. > > DAOs are repeated over and over. If one indicating a change is missed, > there is a service interruption till the next > Also any loss of a diverse outward segment would be corrected with subsequent updates. > >> >>> - I think the node that does not cache should send a DAO to its > parent >>> when the hash in the DIO changes. The hash should start up there at > the >>> first parent (included) that caches and include the path down the >>> preferred tree to this node. So if anything happens between the >>> cache >>> and this node, or if the parent that caches changes, this node knows > and >>> sends a DOA, and propagate the DIO with itself added to the changed >>> hash, so the hash changes. IOW if there is a cache up there and if > the >>> path to that cache or the cache itself changes then this node must > send >>> a DAO to inform nodes along that path. DAOs can be absorbed by the > cache >>> up there if that yields no difference that requires informing its >>> own >>> parent. >> >> This will again require nodes to send redundant DAOs, >> especially in the case where the only the root stores DAOs. >> I think this may be part of the tradeoff of stateless node existence. > Yes, I see what you have in mind now; Would work. > We need to better understand all the pro/cons. Yes. > > cheers > >> -Richard Kelsey From joakime@sics.se Mon Nov 30 00:37:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBF33A69FF for ; Mon, 30 Nov 2009 00:37:04 -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 PDism+SRWc32 for ; Mon, 30 Nov 2009 00:37:03 -0800 (PST) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by core3.amsl.com (Postfix) with ESMTP id D60F43A685A for ; Mon, 30 Nov 2009 00:37:02 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC0150789D for roll@ietf.org; Mon, 30 Nov 2009 09:36:54 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsjAH0TE0tV5B3ePGdsb2JhbAAImR+CWgEBAQE3uF+EMQSNJw X-IronPort-AV: E=Sophos;i="4.47,312,1257116400"; d="scan'208";a="9452854" Received: from c-de1de455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.29.222]) by ipb1.telenor.se with ESMTP; 30 Nov 2009 09:36:48 +0100 Message-ID: <4B138424.9030409@sics.se> Date: Mon, 30 Nov 2009 09:36:52 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> In-Reply-To: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 08:37:04 -0000 Philip Levis skrev: > > On Nov 29, 2009, at 1:12 PM, Omprakash Gnawali wrote: > >> On Sat, Nov 14, 2009 at 11:12 AM, Philip Levis >> wrote: >>> >>> On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: >>> >>>> Hello Phil and Julien, >>>> >>>> Is it really necessary to wait until the complete I interval has >>>> passed before doubling I and restarting T (with the new interval)? >>>> >>>> It feels that we get basically the same behavior with less complex >>>> code if we skip the wait for the complete interval to pass. >>> >>> Hm -- I can't recall if I tried this variant. I'm searching around >>> for the >>> analytical simulator source code, if I find it, I'll let you know. >>> >>> One thing is that trickle is more efficient when intervals are >>> synchronized >>> (it sends half as many messages). Let's say you reset the interval >>> after T. >>> First, the average interval length is 0.75I, leading to 33% more >>> messages. >>> Second, it will inherently desynchronize intervals, leading to twice >>> as many >>> messages compared to the best case. This is a total overhead of sending >>> approximately 2.5 times as many messages if you don't. Of course, the >>> 33% >>> also results in a lower detection latency. >>> >>> Given how the interval length changes, if you want to implement it >>> this way, >>> *all* nodes need to do so, or you break load balancing. >>> >>> But this is just off the top of my head. The behavior of protocols like >>> these can often be not something you'd expect (e.g., "basically the same >>> behavior"). I would definitely run some tests to see how it behaves >>> under >>> very high density. It could be that nodes which pick small T values >>> end up >>> shouldering more of the load due to a variant of the short listen >>> problem. >>> My intuition is that this is a shortcut which probably isn't worth >>> it as it >>> might bite you later, but that intuition could be wrong. >>> >>> Usually, it's just easier to keep track of the rand() result, rather >>> than >>> keep two timers. >> >> I ran the version than Joakim suggested (Truncated interval) and the >> one of the draft (Full interval). Here are the results: >> http://stuff.stanford.edu/~om_p/ctp/trickle-interval/beacontime.html >> >> (Graph with lots of lines show number of beacons for each node). >> >> Experiment setup: >> - 55 nodes with cc2420 radios (Tutornet) >> - max interval 512s >> - 0 dBm transmit power >> - CTP Noe as is and with modifications for truncated interval >> >> Result: Larger number of beacons with Truncated intervals, otherwise >> performance measured in delivery ratio and cost (excluding control >> pkts) similar. We can use a larger interval with the truncated >> interval to match the number of beacons with the full interval. >> >> It makes sense to use the simplified specification. > > Om -- I think it deserves greater investigation than a single > experiment. Joakim has been examining the effect more deeply. There are > other optimizations that one can do (such as Gummadi's suggestion of > suppression time). Yes, there are quite a lot of interesting modifications that can be made. This simplification will remove one of the possible problems, the sensitivity to unsynchronized networks, but will add more total packets sent by ~13-14 percent (when compensating for the shorter interval). The "optimal" version of Trickle needs to listen a full interval to avoid missing packets, but that is going to be slightly more complex than the original Trickle. The question is: what are the priorities for the timer? My guess is that we can get rid of the small problems that Trickle has and still keep it fairly simple and resource efficient. Best regards, -- Joakim Eriksson, SICS > > Phil From joakime@sics.se Mon Nov 30 01:59:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA63D3A688E for ; Mon, 30 Nov 2009 01:59:51 -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 Y0vpzwOtCVJk for ; Mon, 30 Nov 2009 01:59:50 -0800 (PST) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by core3.amsl.com (Postfix) with ESMTP id 1EDDB3A6864 for ; Mon, 30 Nov 2009 01:59:50 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy1.bredband.net (7.3.140.3) id 4AD3E1C0014F77F0 for roll@ietf.org; Mon, 30 Nov 2009 10:59:42 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsjADMmE0tV5B3ePGdsb2JhbAAImR+CVAEBAQE3uE+EMQQ X-IronPort-AV: E=Sophos;i="4.47,312,1257116400"; d="scan'208";a="9489906" Received: from c-de1de455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.29.222]) by ipb1.telenor.se with ESMTP; 30 Nov 2009 10:59:41 +0100 Message-ID: <4B139792.6030707@sics.se> Date: Mon, 30 Nov 2009 10:59:46 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> <4B138424.9030409@sics.se> In-Reply-To: <4B138424.9030409@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 09:59:51 -0000 Hello, some more results on Trickle. I have been trying lots of different versions of Trickle and realized that it is quite interesting and difficult to predict what is going to happen when a knob is tuned. I did some simulations on the simplified trickle that skips waiting for the interval (as previously suggested) and to get relevant results I made the interval 33% longer. The first simulation is the scalability test (same as figure 6 in the original Trickle paper): http://www.sics.se/~joakime/tricklem0-scale.pdf The settings are the K are 1, all nodes have a perfect medium (e.g. no loss, single hop). It shows: - Trickle is synchronized (one packet per interval, all the time). - Trickle without synchronization where T is taken from 0 - I (disaster) - Trickle without synchronization (almost two packets with 512 nodes) - Modified Trickle without synch (1.5 packets with 512 nodes) - The best version i got currently (opt?) (< 1.1 packets with 512 nodes) Trickle and the modified trickle are both good enough here I believe. But Trickle's load balancing can break in some situations. I did a simulation with K=1, 10 nodes synchronized and an 11:th node joining out of synch. The results of this can be seen in the following figure: http://www.sics.se/~joakime/trickle-phase-k1-000.pdf The joining node is lucky when it gets in before 50% of the cycle has passed. At above 20% it does never need to send at all (since one of the other 10 did the job already). Is the node later than 50% it will take all the workload - this is what I would like to get avoid if I was a node ;-) The modified (simplified) version that does not wait out the interval will never end up synchronized for more than a very short time so the same simulation ends up looking like this: http://www.sics.se/~joakime/tricklemod0-phase-000.pdf Best regards, -- Joakim Eriksson, SICS Joakim Eriksson skrev: > Philip Levis skrev: >> >> On Nov 29, 2009, at 1:12 PM, Omprakash Gnawali wrote: >> >>> On Sat, Nov 14, 2009 at 11:12 AM, Philip Levis >>> wrote: >>>> On Nov 14, 2009, at 7:16 AM, Joakim Eriksson wrote: >>>>> Hello Phil and Julien, >>>>> Is it really necessary to wait until the complete I interval has >>>>> passed before doubling I and restarting T (with the new interval)? >>>>> >>>>> It feels that we get basically the same behavior with less complex >>>>> code if we skip the wait for the complete interval to pass. >>>> >>>> Hm -- I can't recall if I tried this variant. I'm searching around >>>> for the >>>> analytical simulator source code, if I find it, I'll let you know. >>>> >>>> One thing is that trickle is more efficient when intervals are >>>> synchronized >>>> (it sends half as many messages). Let's say you reset the interval >>>> after T. >>>> First, the average interval length is 0.75I, leading to 33% more >>>> messages. >>>> Second, it will inherently desynchronize intervals, leading to twice >>>> as many >>>> messages compared to the best case. This is a total overhead of sending >>>> approximately 2.5 times as many messages if you don't. Of course, >>>> the 33% >>>> also results in a lower detection latency. >>>> >>>> Given how the interval length changes, if you want to implement it >>>> this way, >>>> *all* nodes need to do so, or you break load balancing. >>>> >>>> But this is just off the top of my head. The behavior of protocols like >>>> these can often be not something you'd expect (e.g., "basically the >>>> same >>>> behavior"). I would definitely run some tests to see how it behaves >>>> under >>>> very high density. It could be that nodes which pick small T values >>>> end up >>>> shouldering more of the load due to a variant of the short listen >>>> problem. >>>> My intuition is that this is a shortcut which probably isn't worth >>>> it as it >>>> might bite you later, but that intuition could be wrong. >>>> >>>> Usually, it's just easier to keep track of the rand() result, rather >>>> than >>>> keep two timers. >>> >>> I ran the version than Joakim suggested (Truncated interval) and the >>> one of the draft (Full interval). Here are the results: >>> http://stuff.stanford.edu/~om_p/ctp/trickle-interval/beacontime.html >>> >>> (Graph with lots of lines show number of beacons for each node). >>> >>> Experiment setup: >>> - 55 nodes with cc2420 radios (Tutornet) >>> - max interval 512s >>> - 0 dBm transmit power >>> - CTP Noe as is and with modifications for truncated interval >>> >>> Result: Larger number of beacons with Truncated intervals, otherwise >>> performance measured in delivery ratio and cost (excluding control >>> pkts) similar. We can use a larger interval with the truncated >>> interval to match the number of beacons with the full interval. >>> >>> It makes sense to use the simplified specification. >> >> Om -- I think it deserves greater investigation than a single >> experiment. Joakim has been examining the effect more deeply. There >> are other optimizations that one can do (such as Gummadi's suggestion >> of suppression time). > > Yes, there are quite a lot of interesting modifications that can be > made. This simplification will remove one of the possible problems, > the sensitivity to unsynchronized networks, but will add more total > packets sent by ~13-14 percent (when compensating for the shorter > interval). The "optimal" version of Trickle needs to listen a full > interval to avoid missing packets, but that is going to be slightly > more complex than the original Trickle. > > The question is: what are the priorities for the timer? My guess is > that we can get rid of the small problems that Trickle has and still > keep it fairly simple and resource efficient. > > > Best regards, > -- Joakim Eriksson, SICS > >> >> Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Mon Nov 30 02:15:02 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E1FE3A6820; Mon, 30 Nov 2009 02:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091130101502.3E1FE3A6820@core3.amsl.com> Date: Mon, 30 Nov 2009 02:15:02 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-09.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, 30 Nov 2009 10: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 : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : A. Brandt, J. Buron Filename : draft-ietf-roll-home-routing-reqs-09.txt Pages : 18 Date : 2009-11-30 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-09.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-home-routing-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-30021332.I-D@ietf.org> --NextPart-- From abr@sdesigns.dk Mon Nov 30 02:20:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A100B3A68B7 for ; Mon, 30 Nov 2009 02:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdXYRyB26Nap for ; Mon, 30 Nov 2009 02:20:13 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 96B5A3A688F for ; Mon, 30 Nov 2009 02:20:13 -0800 (PST) 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, 30 Nov 2009 11:20:05 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429C59@zensys17.zensys.local> In-Reply-To: <20091130101502.3E1FE3A6820@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-09.txt Thread-Index: AcpxphbSGKOaO+AURROdigns72z5FAAAEH6A References: <20091130101502.3E1FE3A6820@core3.amsl.com> From: "Anders Brandt" To: Subject: Re: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-09.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, 30 Nov 2009 10:20:14 -0000 Hi Another version of the home control requirements has been submitted to reflect the changes during the last call process. Most changes are editorial. A few changes have been made to the security section. Cheers, Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 30. november 2009 11:15 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : A. Brandt, J. Buron Filename : draft-ietf-roll-home-routing-reqs-09.txt Pages : 18 Date : 2009-11-30 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-09 .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. From jabeille@cisco.com Mon Nov 30 05:46:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB9E3A6A81 for ; Mon, 30 Nov 2009 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.798 X-Spam-Level: X-Spam-Status: No, score=-7.798 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, 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 ofTD1v70OApo for ; Mon, 30 Nov 2009 05:46:58 -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 817CB3A6A67 for ; Mon, 30 Nov 2009 05:46:58 -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: ApsEACtbE0urRN+K/2dsb2JhbACCUb06lmSEMQSBcg X-IronPort-AV: E=Sophos;i="4.47,314,1257120000"; d="scan'208,217";a="55327487" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2009 13:46:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAUDkgMQ028226 for ; Mon, 30 Nov 2009 13:46:50 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 14:46:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA71C3.8D965BC3" Date: Mon, 30 Nov 2009 14:46:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCP0 text Thread-Index: Acpxw4yaQzp1hjJzTgW5N4UZ+OOuBg== From: "Julien Abeille (jabeille)" To: X-OriginalArrivalTime: 30 Nov 2009 13:46:44.0277 (UTC) FILETIME=[8DA9FE50:01CA71C3] Subject: [Roll] OCP0 text X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 13:46:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA71C3.8D965BC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I think the ocp0 text could be made clearer. appart from the administrative (interface allowed or not...) considerations, the variables that come into play are: 1 grounded better than not grounded 2 highest preference better 3 lowest rank better 4 DAG with alternate parents available better 5 parent with link determined to be stable better than no info on link stability 6 freshest DIO better 7 current DAG better 8 current parent better =20 when there is a tie on one test, we go to the next. The question is about the order of the tests. Does the one above (1 to 8) seem reasonable?=20 =20 Best, Julien ------_=_NextPart_001_01CA71C3.8D965BC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I = think the ocp0=20 text could be made clearer. appart from the administrative (interface = allowed or=20 not...) considerations, the variables that come into play=20 are:
1 grounded=20 better than not grounded
2 highest=20 preference better
3 lowest rank=20 better
4 DAG with = alternate=20 parents available better
5 parent with=20 link determined to be stable better than no info on link=20 stability
6 freshest DIO=20 better
7 current DAG=20 better
8 current=20 parent better
 
when = there is a tie=20 on one test, we go to the next.
The = question is=20 about the order of the tests. Does the one above (1 to 8) seem = reasonable?=20
 
Best,
Julien
------_=_NextPart_001_01CA71C3.8D965BC3-- From pthubert@cisco.com Mon Nov 30 05:53:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175F528C112 for ; Mon, 30 Nov 2009 05:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 uYvk6kXDZJnS for ; Mon, 30 Nov 2009 05:53:46 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 94C043A6944 for ; Mon, 30 Nov 2009 05:53:46 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAtdE0urRN+J/2dsb2JhbADAD5ZlhDEE X-IronPort-AV: E=Sophos;i="4.47,314,1257120000"; d="scan'208";a="111324690" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2009 13:53:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAUDraDE004542; Mon, 30 Nov 2009 13:53:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 14:53:37 +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, 30 Nov 2009 14:53:27 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches - a proposal Thread-Index: Acpxa8sBJ2NNKbpTRC6sd85Cs1rx9AAHEBow References: From: "Pascal Thubert (pthubert)" To: "Roger Alexander" , "Richard Kelsey" X-OriginalArrivalTime: 30 Nov 2009 13:53:37.0001 (UTC) FILETIME=[83AAAD90:01CA71C4] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 13:53:48 -0000 Hi Roger and Richard: For R05 I think we will not have time to converge on source route.=20 I'll make a separate thread for R05 for the common pieces. This thread is about source route so I keep it this way.=20 To integrate source route I think that we'll need to convert the routing header in a string of shorter tags. Here's how that could happen: - ack the DAO. What about a DA Confirm (DAC) ? - Multiple destination info may be piggy backed (BNF?) - DAO Originator and caching parent MAY send the DAO to multiple parents, details left out.=20 - A parent keeps track of its children. For each child, it maintains the tag that points onto the child and associated to that, the link local and the (destinations, originator sequence) for destinations owned by that child. This is done to aggregate multiple destinations in one messages, enable no-DAOs, etc... - a caching parent also keeps track of destinations. For those destinations, it maintains the tag that points onto the next_hop child and associated to that, the link local and the (destinations, originator sequence) for destinations owned by or reachable via that child. - A DAO emitted by the Originator node and a caching parent contains only the destination and sequence set by the originator.=20 - A parent that propagates a DAO without caching it adds a local tag that points onto the child (see that as a locally significant compression of the child LLA, or an index on that child).=20 - A Node that sends DIOs maintains its own cache_sequence that it places in the DIO. The sequence is increments to request the children to send their DIOs.=20 - A child that changes its parent or gets a new cache_sequence from its parent dumps its DAO info. If the node does not cache all DAOs or if the D bit is set then the node needs to update its own cache_sequence, and propagate the DIO with the same setting of the D bit. What do you think? Pascal >-----Original Message----- >From: Roger Alexander [mailto:roger.alexander@ekasystems.com] >Sent: lundi 30 novembre 2009 04:18 >To: Pascal Thubert (pthubert) >Cc: Richard Kelsey; >Subject: Re: [Roll] updating DAO caches - a proposal > >Hi Pascal, Richard, others, > > >On Nov 23, 2009, at 7:06 AM, "Pascal Thubert (pthubert)" > wrote: > >> Hello Roger (and Richard) >> >> I think I'm mostly with you too. >> Need to make sure we're fully on the same page. >> >> Pascal >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of >> Roger K. Alexander >>> Sent: samedi 21 novembre 2009 19:17 >>> To: 'Richard Kelsey'; roll@ietf.org >>> Subject: Re: [Roll] updating DAO caches - a proposal >>> >>> Hi Richard, >>> >>> As indicated below, I would support this proposal as a base for >>> further >> DAO >>> operation specification. >>> >>> Roger >>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of >>>> Richard Kelsey >>>> Sent: Thursday, November 19, 2009 2:22 PM >>>> To: roll@ietf.org >>>> Subject: [Roll] updating DAO caches - a proposal >>>> >>>> >>>> Below is an actual concrete proposal for managing DAO >>>> caches. I believe that this would work well when all nodes >>>> cache DAOs and when no nodes do so. It does a reasonable >>>> job when only some nodes cache DAOs, although in some >>>> situations there will be some superfluous DAOs transmitted. >>>> >>>> This assumes that DAOs are sent only to the preferred >>>> parent. If DAO are sent to multiple parents the situation >>>> becomes more complex. >> >> YES. >> >> Fanning out does not guarantee multipath opportunities on the way >> back. >> And that creates overload of states. >> >> > >Indeed multiple parents do not guarantee diverse outward end-to-end >paths but it improves the potential. > >The use of just a single (acknowledged) parent should be left as an >implementation choice (note that nodes can also maintain state for >other non-acknowledged parent nodes without sending DAO updates to >those nodes). Multiple parents need to be supported as part of the >core RPL specification. > >>>> In a network with no DAO caches the new (C) flag is never >>>> set. Whenever a node moves it sends a single DAO that >>>> propagates to the root, which stores the nodes new location. >> >> But then its children that are dragged along do not update the root? >> >> That would work only if you use DAO for one_hop information and >> leave it >> up to the root to rebuild the source route. >> Please let us know what you have in mind here, since that might yield >> complexities. >> >> I'll continue with the assumption that the Reverse Route Stack >> contains >> multiple hops. >> >>>> In a network where all nodes cache DAOs, a node that moves >>>> sends the contents of its cache to its new parent. These >>>> propagate up the tree, with each node forwarding on only >>>> those prefixes which are new to its cache. The forwarding >>>> stops when it reaches the least common ancestor of the >>>> node's old and new locations. >>> >>> Agreed. >> >> IF we all agree on the above, that is sending only to one preferred >> parent, then there can only be one child that advertises a DAO >> destination. Thus there can be only one route to a destination. Thus >> if >> 2 children advertise a same destination, one is wrong. >> > >The specification should allow nodes to be able to maintain multiple >(acknowledged) parents. > >> The newest sequence in the DAO indicates the one that is correct. The >> other one should be cleaned up. >> >> >> Do we agree in this one? > >Yes. Furthermore, with multiple parents the given sequence number >associated with the update will ensure that updates arriving on >different paths allow a common ancestor to maintain multiple forward >(outward) routes. Note, delays or loss of DAO updates on different >paths to the common ancestor can lead to temporary elimination of >segments of the potential multiple outward paths. > >> >>> >>>> In a mixed network, nodes with caches and nodes whose only >>>> caching ancestor is the root will have the same behavior >>>> as above. A node without a cache will send its own DAO and >>>> set the Destination Advertisement Trigger to cause its >>>> sub-DAG to send DAOs as well. The Trigger will propagate >>>> downwards causing more DAOs to be sent, but descedents that >>>> have a cache will not propagate the Trigger to their own >>>> sub-DAG. >>> >>> Some further refinement may need to be considered. Where nodes >>> maintain >> DAO >>> caches the triggering of outward routing updates to the sub-DAG is >>> not >>> needed unless there has been a change in the path cost from the >>> moving >> node >> >> We agree. For all I understand, a node that caches 'absorbs' the D >> bit; >> that is it updates the parent that has set the D bit with its all >> cache >> and does not propagate the D bit. >> >> Metrics changes are subject to the trickle exponential backoff but >> that >> is a different process. If there is a significant change, the child >> will >> be told by the parent from that process, and either dump its cache (if >> it caches) or send its DAO and send a DIO with the D bit set (if it >> does >> not cache). > >Agreed. > >>> to the DAG root, which would then affect connectivity decisions of >>> the >>> sub-DAG nodes (one of the traffic reducing benefits of multiple >>> parents >> is >>> the potential to mute the effect of individual link connectivity >> changes). >>> For nodes that do not maintain DAO caches, it should be possible to >> apply >>> the same mechanism since the moving parent node sends a DAO update >> towards >>> the root updating subsequent outward routes. >>> >> >> Hum. I fear that we are back to the 'one hop' source route >> collection I >> discussed above with the root rebuilding the source route >> recursively. I >> hope we are not going that way... > >The root or other state-maintaining node would be capable of >rebuilding the source route recursively. For 'mixed' node >environments, other stateful nodes will need to support this >processing as well. > >> >>>> >>>> -Richard Kelsey >>>> >>>> ---------------- >>>> Proposal: >>>> >>>> Add a new DIO flag: >>>> >>>> Destination Advertisements Cache (C): The Destination >>>> Advertisement Cache (C) flag is set when a node below >>>> the DAG root in the successor chain caches DAOs sent >>>> upwards. DAG roots NUST NOT set this flag. Nodes >>>> below the root that maintain a DAO cache MUST set this >>>> flag. Nodes below the root that do not maintain a DAO >>>> cache MUST set this flag to the value received from >>>> their preferred DAG Parent. >>>> >>>> >>>> In 5.10.1.1. replace >>>> >>>> A node that modifies its DAG Parent set may set the `D' bit in >>>> subsequent DIO propagation in order to trigger destination >>>> advertisements to be updated to its DAG Parents and other >> ancestors >>>> on the DAG. Additional recommendations and guidelines regarding >>>> the use of this mechanism are still under consideration and will >> be >>>> elaborated in a future revision of this specification. >>>> >>>> with >>>> >>>> When a node selects a new preferred parent it MUST send that >> parent >>>> a unicast DIO. If the node maintains a DIO cache the DIO sent >> MUST >> >> DAO I presume? >> >>>> include the prefixes in the DAO cache. If the node does not >>>> maintain a DIO cache and either the new preferred parent's DIO or >>>> the old preferred parent's DIO has the Destination Advertisements >>>> Cache set, then the node MUST set the Destination Advertisement >>>> Trigger in its own subsequent DIO. >>>> >> >> >> Several things: >> >> - A node should prefer a parent that can cache; If that's generic >> enough >> that should be in the DIO. >> >OK. > >> - I fail to see why the DAG root does not set the flag. What happens >> if >> it is the only one that caches then? It appears that movements do not >> trigger DAOs though the source route path changes. >> >> - the D bit is not enough. The initial spec has a hash. In multihop >> source route, are you sure the D will propagate without a loss? The >> hash >> is one of those values that would cause resetting trickle if changed >> so >> it should propagate efficiently. >> >> - I think the node that does not cache should send a DAO to its parent >> when the hash in the DIO changes. The hash should start up there at >> the >> first parent (included) that caches and include the path down the >> preferred tree to this node. So if anything happens between the cache >> and this node, or if the parent that caches changes, this node knows >> and >> sends a DOA, and propagate the DIO with itself added to the changed >> hash, so the hash changes. IOW if there is a cache up there and if the >> path to that cache or the cache itself changes then this node must >> send >> a DAO to inform nodes along that path. DAOs can be absorbed by the >> cache >> up there if that yields no difference that requires informing its own >> parent. >> >> Are we on the same line? >> > >Yes. I think this may be part of the tradeoff for a stateless node. A >node that maintains state will send a DIO on its sub-DAG only if there >is a cost change to the root. > >> >> Pascal >> >> >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Nov 30 07:07:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DE13A66B4 for ; Mon, 30 Nov 2009 07:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.394 X-Spam-Level: X-Spam-Status: No, score=-7.394 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 BQNhuAg+4G1q for ; Mon, 30 Nov 2009 07:07:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B6E033A6768 for ; Mon, 30 Nov 2009 07:07:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image002.jpg : 1987 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKVuE0tAZnwM/2dsb2JhbACCJyq+bJZxAoQvBA X-IronPort-AV: E=Sophos;i="4.47,314,1257120000"; d="jpg'145?scan'145,208,217,145";a="111364932" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2009 15:07:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAUF7Abl016684 for ; Mon, 30 Nov 2009 15:07:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 16:07:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CA71CE.D169140B"; type="multipart/alternative" X-CR-Hashedpuzzle: YbE= a1w= ASje AW8U CoDz DAmV FlCa Fqqo GCSP G55v HDUJ HjIG IYuY Ilx0 JaEv K7AY; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {B6AB8D39-BB64-4B7D-BEAE-899E0B36B4F2}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 30 Nov 2009 14:03:07 GMT; cwB0AGEAdABlAGYAdQBsACAARABBAE8A X-CR-Puzzleid: {B6AB8D39-BB64-4B7D-BEAE-899E0B36B4F2} Content-class: urn:content-classes:message Date: Mon, 30 Nov 2009 16:07:22 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DBD52C6@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: stateful DAO Thread-Index: Acpxxde1QXash/92QRe6iaYU2xKNqA== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 30 Nov 2009 15:07:22.0299 (UTC) FILETIME=[D15990B0:01CA71CE] Subject: [Roll] stateful DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 15:07:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA71CE.D169140B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA71CE.D169140B" ------_=_NextPart_002_01CA71CE.D169140B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 The recent discussions introduced a number of questions for DAO, even = for the stateful case where all nodes actually cache routes. =20 I'd wish to take the pulse of the ML regarding those questions: =20 - D bit.=20 o The D bit is designed to refresh periodically the DAOs over the = whole DAG. But it may be lost and some states might not be refreshed o Also we found a need for source route where we just need to refresh = the DAOs till the next caching node that can dump its own cache. =F0 Proposed solution: add a per node sequence that triggers an update - DAO o DAO might be lost. Whether that is a DAO or a no-DAO, this causes=20 =F0 Proposed solution: ACK the DAO , NACK it when the node cannot take = more children - Fanning out o Fanning out might provide some advantages at a cost. The cost is = multiplied when doing source route =F0 Proposed solution: make it a MAY for cached and originators only =20 What do you think? =20 =20 =20 Pascal Thubert IP Engineering TC pthubert@cisco.com =20 Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3=20 400, Avenue Roumanille 06410 Biot - Sophia Antipolis =20 France www.cisco.com/global/FR/ =20 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 =20 ------_=_NextPart_002_01CA71CE.D169140B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

The recent discussions introduced a number of = questions for DAO, even for the stateful case where all nodes actually cache = routes.

 

I’d wish to take the pulse of the ML = regarding those questions:

 

-          D bit.

o   The D bit is designed to refresh = periodically the DAOs over the whole DAG. But it may be lost and some states might = not be refreshed

o   =A0Also we found a need for source route = where we just need to refresh the DAOs till the next caching node that can dump = its own cache.

=F0  Proposed solution: add a per node sequence that triggers an update

-          DAO

o   DAO might be lost. Whether that is a DAO = or a no-DAO, this causes

=F0  Proposed solution: ACK the DAO , NACK it when the node cannot take more = children

-          Fanning out

o   Fanning out might provide some advantages = at a cost. The cost is multiplied when doing=A0 source route

=F0  Proposed solution: make it a MAY for cached and originators only

 

What do you think?

 

 

<= /p>

= Pascal Thubert
IP Engineering TC

pthubert@cisco.com
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco = Systems=
=A0 Village d'Entreprises Green Side bat. T3
=A0 400, Avenue Roumanille
=A0 06410 Biot - Sophia Antipolis=A0
=A0 France
=A0 www.cisco.com/global/FR/

This e-mail may contain confidential and privileged = material for the sole use of the intended recipient. Any review, use, = distribution or disclosure by others is strictly prohibited. If you are not the = intended recipient (or authorized to receive for the recipient), please = contact the sender by reply e-mail and delete all copies of this = message.

 

 

------_=_NextPart_002_01CA71CE.D169140B-- ------_=_NextPart_001_01CA71CE.D169140B Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABWAIEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKoXmsWdjqFrYzybZrokRj 1py6tZtqzaWJR9pVN5T2rj/GH/I/eHf95f8A0OrjG7szOc7K6O9oqnqWq2mkwLPeSeWjuEB9zVtS GUMDkEZFRYu/QWimswRSzHAUZJqrpmqWmrWxuLOTfGGKk+4osF+gyy1mz1C9urS3k3S2rbZBV+uC 8Ef8jn4h/wCuh/8AQzXYf2tZjVxpfmj7UY/M2e1XKNnZEQnzRuy7RRRUGgUUUUAFFFFABRRRQAVy /hPxFea1qerW9yqBLWXEe30yR/SuoqnZaVZ6fNcTW0QR7l98hHc1SasyWndWOOtv+Sw3H/XD/wBk Wjxh/wAj94d/3h/6HXYrpVmuqNqYiH2lk2F/asTX/D1zqXinSNRiYCK0b95n2Oa0UlzL0MZQai15 md8VP+QHZ/8AXz/7Ka3tb1GbSfCUt9bhTLFApXd05wP61f1HTLTVYFhvIhIiuHAPqKkurOC8s5LS dA0Mi7WX2qOZWSL5HeTXUy9L1CbVfByX04USzWzFgvTOCKxPhZ/yLk//AF8n/wBBFdfb2kFrZpaR IFhRdgX2qPTtMtdKtjb2cYjjLFiPc0cys0PkfMm+hxvgj/kc/EP/AF0P/oZpW/5LIv8A17f+061f Dnh650rxDq99MwMd2+Y8ehJP9a2/7LtDqo1Pyh9pCbN/tVuS5n6GcYPlS8zD8T+IrzSNc0izt1Qx 3cmJN3XGQP611FU7zSrO+ube4uIg8ls26MnsauVm2rKxsk03cKKKKkoKKKKACiiigApGYKpZjgAZ JpapaxDLcaPeQwZ8x4WC49cUDSu7HD6r8VCNQks9C0x7/wAokM/ODj0x2rq9K16TUPC41iS1MMnl s5hbjBXt+leefC/XNH0NL+z1WRLW7Mud8g6gDBXP1zXo899aal4aurqxkWSB4ZNrKODwc1jCTau2 ejiqUKclTjDa2vco+EvFn/CS6PPqM1qLVYHKkB93AHXoK5w/E7Uby8m/sfQJby0hbDyDOf0qT4UL E/hO9WbHlmZg+fTHNcvq9ufBbHUfDXiVJYZZebcNlu/UdxUuUuVM2hQo+3nTtr03sesahrtppWhj Vb8mGPYrFD97JH3frXE2vxTvr29jMGgyGyeUJ5vJIz+GKZ8QZLzWvh5p2peWVyVkmVRwMjrWz4Y8 X+GF8O2MC3MMDqixtARzv6Hj3NU5NytexlCjCFHncOZ3a9DV8U+LbDwtYpPdBpJZf9VCvVv/AK1c np3xaJvETV9Le0t5ThJRnp68/wBKp/FBDa+K9I1O7iMtgoUMOoOGyR+VL8R/Eugav4ft7TTXjubl 3Vo/LXmMen9MVMpu712NaGGpuEE4t8277HqUciTRLLGwZHAKkdxT6yvDEE1t4Z06C4BEqW6hweuc Vq1utjyZJKTSCiiimSFFFFABRRRQAUUUUAc9q3gXw7rNybm7sB5x5Z42KlvritOy0exsNKXS7eHb aqhTZkng9eavUUuVXuaOrNxUW3ZGbpfh/S9GspbKwtRDBKSXTcTnP1NY0Pw18LQXKziwLMrbsPIS Pyrq6KXLHsNV6qbak9dyJ7aCS2Ns8SNCV2mMjjHpiucX4c+GEvlu0sNrq4cKJDtB+ldRRTcU9xQq zhflbVypqGmWWq2jWl9bpPC38LCsbTfAHhvSrsXVvYAyr90yMW2n1ANdJRQ4pu7CNWpGLjFtIKKK KZmFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== ------_=_NextPart_001_01CA71CE.D169140B-- From pthubert@cisco.com Mon Nov 30 10:15:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE66428C139 for ; Mon, 30 Nov 2009 10:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.825 X-Spam-Level: X-Spam-Status: No, score=-7.825 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, 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 DNu-xwBfpeqb for ; Mon, 30 Nov 2009 10:14:59 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 014F528C168 for ; Mon, 30 Nov 2009 10:14:58 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL+ZE0tAZnwM/2dsb2JhbACCUcAdln6EMQSBcg X-IronPort-AV: E=Sophos;i="4.47,315,1257120000"; d="scan'208,217";a="71107770" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2009 18:14:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAUIEo4a026111 for ; Mon, 30 Nov 2009 18:14:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 19:14:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA71E9.01039729" Date: Mon, 30 Nov 2009 19:14:32 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DBD5425@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] OCP0 text Thread-Index: Acpxw4yaQzp1hjJzTgW5N4UZ+OOuBgAAmgtQ References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , X-OriginalArrivalTime: 30 Nov 2009 18:14:49.0033 (UTC) FILETIME=[00ECFB90:01CA71E9] Subject: Re: [Roll] OCP0 text X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 18:15:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA71E9.01039729 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien: =20 That's close enough... =20 The freshness in time is a dangerous beast though. I assume we'll use the sequence for that. =20 When a node sees a new sequence, there must be a probation time of one or more trickle timers and then a router with the new sequence has more appeal than one with an older sequence. =20 Also, the preference is used only in the absence of grounded. Otherwise, you might select a root far, far away if such a root had a better preference. =20 Finally, the stability test might be placed differently for the preferred and for the back up. The preferred needs to be preevaluated if possible whereas the backup can be under evaluation, so your placement would apply to the back up. =20 I'll post the of0 draft soon and then we can discuss the wording.... =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: lundi 30 novembre 2009 14:47 To: roll@ietf.org Subject: [Roll] OCP0 text =20 Hi all, =20 I think the ocp0 text could be made clearer. appart from the administrative (interface allowed or not...) considerations, the variables that come into play are: 1 grounded better than not grounded 2 highest preference better 3 lowest rank better 4 DAG with alternate parents available better 5 parent with link determined to be stable better than no info on link stability 6 freshest DIO better 7 current DAG better 8 current parent better =20 when there is a tie on one test, we go to the next. The question is about the order of the tests. Does the one above (1 to 8) seem reasonable?=20 =20 Best, Julien ------_=_NextPart_001_01CA71E9.01039729 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien:

 

That’s close enough…

 

 The freshness in time is a dangerous beast though. = I assume we’ll use the sequence for that.

 

When a node sees a new sequence, there must be a = probation time of one or more trickle timers and then a router with the new sequence = has more appeal than one with an older sequence.

 

 Also, the preference is used only in the absence of grounded. Otherwise, you might select a root far, far away if such a = root had a better preference.

 

Finally, the stability test might be placed differently = for the preferred and for the back up. The preferred needs to be preevaluated if possible whereas the backup can be under evaluation, so your placement = would apply to the back up.

 

I’ll post the of0 draft soon and then we can = discuss the wording….

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: lundi 30 novembre 2009 14:47
To: roll@ietf.org
Subject: [Roll] OCP0 text

 

Hi all,

 

I think the ocp0 text could be made clearer. appart from the = administrative (interface allowed or not...) considerations, the variables that = come into play are:

1 ground= ed better than not grounded

2 highes= t preference better

3 lowest= rank better

4 DAG with alternate parents available better

5 parent= with link determined to be stable better than no info on link = stability

6 freshe= st DIO better

7 curren= t DAG better

8 curren= t parent better

 

when there is a tie on one test, we go to the next.

The question is about the order of the tests. Does the one above (1 to 8) = seem reasonable?

 

Best,<= o:p>

Julien=

------_=_NextPart_001_01CA71E9.01039729-- From pal@cs.stanford.edu Mon Nov 30 10:22:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1053A6982 for ; Mon, 30 Nov 2009 10:22:03 -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 it5HkuFOZ2x7 for ; Mon, 30 Nov 2009 10:22:02 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C13653A693C for ; Mon, 30 Nov 2009 10:22:02 -0800 (PST) Received: from dnab404633.stanford.edu ([171.64.70.51]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NFAsl-0004HI-KB; Mon, 30 Nov 2009 10:21:56 -0800 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <87k4xe207c.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 08:57:04 -0800 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 18:22:03 -0000 On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: >> Date: Wed, 25 Nov 2009 10:43:41 +0100 >> From: "Julien Abeille (jabeille)" > >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: vendredi 20 novembre 2009 19:31 >>> >>> Point-to-point communication between nodes is needed by some >>> applications. Section 5.2.2 of >>> draft-ietf-roll-building-routing-reqs-07: >>> >>> "A network device MUST be able to communicate in a >>> point-to-point manner with any other device on the network." >> >> Sure, and DAOs (whether stored only at root are not) solve this >> issue. >> May not be the most efficient, but the sceanrios multicast DAOs solve >> are so limited that we will end up with 10 solutions for 10 >> scenarios if >> we go that path. >> >> I would personaly drop multicast DAOs > > I agree. As we have done with unicasts, we need to look > carefully at the multicast requirements and find ways to > solve the easy and/or common cases first. I do not think > that there is a workable one-size-fits-all multicast > solution. Because the current mandate is for greater simplicity, it makes sense to remove RPL features/mechanisms that don't have strong proponents. Does anyone think multicast DAOs should remain? If so, it would help if you could explain your reasoning on the tradeoff between the benefits and drawbacks (increased complexity). Phil From pal@cs.stanford.edu Mon Nov 30 10:22:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4193A694F for ; Mon, 30 Nov 2009 10:22:14 -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 IVomIWrLNoJn for ; Mon, 30 Nov 2009 10:22:13 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8F1AB3A6985 for ; Mon, 30 Nov 2009 10:22:13 -0800 (PST) Received: from dnab404633.stanford.edu ([171.64.70.51]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NFAsv-0004HI-L8; Mon, 30 Nov 2009 10:22:06 -0800 Message-Id: <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> From: Philip Levis To: Joakim Eriksson In-Reply-To: <4B139792.6030707@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 09:14:17 -0800 References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> <4B138424.9030409@sics.se> <4B139792.6030707@sics.se> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6214ac49f2cb083a0c8190805312a710 Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 18:22:14 -0000 On Nov 30, 2009, at 1:59 AM, Joakim Eriksson wrote: > Hello, some more results on Trickle. > > .... > > The joining node is lucky when it gets in before 50% of the cycle has > passed. At above 20% it does never need to send at all > (since one of the other 10 did the job already). Is the node later > than > 50% it will take all the workload - this is what I would like to get > avoid if I was a node ;-) > > The modified (simplified) version that does not wait out the interval > will never end up synchronized for more than a very short time so the > same simulation ends up looking like this: > > http://www.sics.se/~joakime/tricklemod0-phase-000.pdf > Tom Anderson noted this issue when the paper was first published: there are three considerations which, in practice, make this behavior amazingly unlikely and therefore of limited concern: 1) Having all nodes perfectly synchronized is difficult/impossible 1a) Packet losses mean that nodes typically do not agree on exactly when an interval starts 1b) Nodes will, over time, fall out of synchronization due to local clock variations 2) Networks have packet losses 2a) At some point the lagging node will not hear a transmission, will transmit, and suppress the others 3) The network is single-hop In essence, this behavior is only really apparent in tightly controlled, aberrant settings (such as a single-hop simulation with no clock skew, perfect synchronization, and lossless packet communication). This doesn't mean that also covering this case isn't beneficial: it just needs to be judged against the performance effects in less aberrant cases. Phil From joakime@sics.se Mon Nov 30 11:13:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402D23A67F1 for ; Mon, 30 Nov 2009 11:13:36 -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 1lvc6F5IrEdI for ; Mon, 30 Nov 2009 11:13:35 -0800 (PST) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by core3.amsl.com (Postfix) with ESMTP id 1F8073A6858 for ; Mon, 30 Nov 2009 11:13:35 -0800 (PST) Received: from ipb2.telenor.se (195.54.127.165) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC0155C992 for roll@ietf.org; Mon, 30 Nov 2009 20:13:27 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowjAEeoE0tV5B3ePGdsb2JhbAAImR6CVQEBAQE3vGyEMQSNJw X-IronPort-AV: E=Sophos;i="4.47,315,1257116400"; d="scan'208";a="9710447" Received: from c-de1de455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.29.222]) by ipb2.telenor.se with ESMTP; 30 Nov 2009 20:13:27 +0100 Message-ID: <4B14195B.5060302@sics.se> Date: Mon, 30 Nov 2009 20:13:31 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> <4B138424.9030409@sics.se> <4B139792.6030707@sics.se> <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> In-Reply-To: <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 19:13:36 -0000 Philip Levis skrev: > > On Nov 30, 2009, at 1:59 AM, Joakim Eriksson wrote: > >> Hello, some more results on Trickle. >> >> .... >> >> The joining node is lucky when it gets in before 50% of the cycle has >> passed. At above 20% it does never need to send at all >> (since one of the other 10 did the job already). Is the node later than >> 50% it will take all the workload - this is what I would like to get >> avoid if I was a node ;-) >> >> The modified (simplified) version that does not wait out the interval >> will never end up synchronized for more than a very short time so the >> same simulation ends up looking like this: >> >> http://www.sics.se/~joakime/tricklemod0-phase-000.pdf >> > > Tom Anderson noted this issue when the paper was first published: there > are three considerations which, in practice, make this behavior > amazingly unlikely and therefore of limited concern: > > 1) Having all nodes perfectly synchronized is difficult/impossible > 1a) Packet losses mean that nodes typically do not agree on exactly > when an interval starts > 1b) Nodes will, over time, fall out of synchronization due to local > clock variations Over time they will, but assuming that many nodes will receive the same new DIO at the same time there will be quite a long period of fairly synchronized nodes (given that the max interval is several minutes). Any node joining while this situation persist might end up in a bad or good case. > 2) Networks have packet losses > 2a) At some point the lagging node will not hear a transmission, will > transmit, and suppress the others Yes, but it will be back in the same "problematic" or lucky state the next interval since it will not move from its position in the interval due to the packet loss. > 3) The network is single-hop Yes, but I have seen the same situation in multi-hop simulations where I am running hundreds of nodes over ~10 hops or so. Some nodes get much more of the load than others. > In essence, this behavior is only really apparent in tightly controlled, > aberrant settings (such as a single-hop simulation with no clock skew, > perfect synchronization, and lossless packet communication). This > doesn't mean that also covering this case isn't beneficial: it just > needs to be judged against the performance effects in less aberrant cases. Yes, what I would like to have is something that performs as well as original Trickle in the normal case, and better in the worst cases. I guess Trickle is good enough, but there are potential improvements that I think needs to be studied carefully before we go ahead and finalize the version that goes into RPL. Best regards, -- Joakim Eriksson, SICS > > Phil From roger.alexander@ekasystems.com Mon Nov 30 15:41:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997A63A6851 for ; Mon, 30 Nov 2009 15:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQG1UIIxYPVY for ; Mon, 30 Nov 2009 15:41:41 -0800 (PST) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id E3DD33A69CF for ; Mon, 30 Nov 2009 15:41:40 -0800 (PST) Received: (qmail 62801 invoked from network); 30 Nov 2009 23:41:31 -0000 Received: from (roger.alexander@209.48.242.70 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 30 Nov 2009 15:41:30 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 1.pFHgwVM1nCnwz15SRJNtENonfiA4oxxC95kdbhcuLghB97nZBSY.KEncXNjY2F4c2SDpNJ.F0cT380QrnWrDEBaM5E1yp58SPX1V0AHmZGWbSrPCMEY6QUsaay10CthayjE6MOl58r9Bc8sx82p1RkwsypP53r5o1pgWQszFjgp4HC4MU2fe225TIcAqbTqAQyq9_BXFW8a35BJOiXR6y668yCVNPZZYEgXUE7FUN7jSJd8PnyB.0CcKhp91FcaYKzfPurA1ZOIt5eXJF9gonoCXfLYvF5OKzgUcJkW4xonVuPQ7db9WLCTJ9s_rXQi.ZI7Rzi8vIKpZRwf_Q4aCJ6k5u2qWke1CR86L72U_q4T8qRq1mI8bd_wT8TqaFgHOwg1Ljc X-Yahoo-Newman-Property: ymail-3 From: "Roger K. Alexander" To: "'Pascal Thubert \(pthubert\)'" , "'Richard Kelsey'" References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> Date: Mon, 30 Nov 2009 18:44:14 -0500 Message-ID: <048201ca7217$0629fdf0$127df9d0$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpxa8sBJ2NNKbpTRC6sd85Cs1rx9AAHEBowABZfLWA= Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Nov 2009 23:41:42 -0000 Hi Pascal, General agreement. Thanks. Roger > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Monday, November 30, 2009 8:53 AM > To: Roger Alexander; Richard Kelsey > Cc: roll@ietf.org; wintert@acm.org > Subject: RE: [Roll] updating DAO caches - a proposal > > Hi Roger and Richard: > > For R05 I think we will not have time to converge on source route. > I'll make a separate thread for R05 for the common pieces. > > This thread is about source route so I keep it this way. > > To integrate source route I think that we'll need to convert the > routing > header in a string of shorter tags. > > Here's how that could happen: > > - ack the DAO. What about a DA Confirm (DAC) ? Agreed. This could be in the form of a DIO with Ack indicator. > > - Multiple destination info may be piggy backed (BNF?) Agreed. > > - DAO Originator and caching parent MAY send the DAO to multiple > parents, details left out. Agreed. More generically, "a node MAY send the DAO to multiple parents". In any event, there may not always be multiple candidate parents. > > - A parent keeps track of its children. For each child, it maintains > the > tag that points onto the child and associated to that, the link local > and the (destinations, originator sequence) for destinations owned by > that child. This is done to aggregate multiple destinations in one > messages, enable no-DAOs, etc... > - a caching parent also keeps track of destinations. For those > destinations, it maintains the tag that points onto the next_hop child > and associated to that, the link local and the (destinations, > originator > sequence) for destinations owned by or reachable via that child. Agreed. > > - A DAO emitted by the Originator node and a caching parent contains > only the destination and sequence set by the originator. Agreed. The sequence number must be as set by each originator. This will allow a common ancestor to maintain diverse outward routing entries where applicable and similarly purge outdated entries as needed. > - A parent that propagates a DAO without caching it adds a local tag > that points onto the child (see that as a locally significant > compression of the child LLA, or an index on that child). > OK. > - A Node that sends DIOs maintains its own cache_sequence that it > places > in the DIO. The sequence is increments to request the children to send > their DIOs. > - A child that changes its parent or gets a new cache_sequence from its > parent dumps its DAO info. OK. This will allow for some recovery of lost DIOs. However the D bit setting of the lost DIO is not recovered. > If the node does not cache all DAOs or if > the > D bit is set then the node needs to update its own cache_sequence, and > propagate the DIO with the same setting of the D bit. > > What do you think? I need to give some further thought to the final mechanism. Thanks. > > Pascal > > >-----Original Message----- > >From: Roger Alexander [mailto:roger.alexander@ekasystems.com] > >Sent: lundi 30 novembre 2009 04:18 > >To: Pascal Thubert (pthubert) > >Cc: Richard Kelsey; > >Subject: Re: [Roll] updating DAO caches - a proposal > > > >Hi Pascal, Richard, others, > > > > > >On Nov 23, 2009, at 7:06 AM, "Pascal Thubert (pthubert)" > > > wrote: > > > >> Hello Roger (and Richard) > >> > >> I think I'm mostly with you too. > >> Need to make sure we're fully on the same page. > >> > >> Pascal > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > >>> Behalf Of > >> Roger K. Alexander > >>> Sent: samedi 21 novembre 2009 19:17 > >>> To: 'Richard Kelsey'; roll@ietf.org > >>> Subject: Re: [Roll] updating DAO caches - a proposal > >>> > >>> Hi Richard, > >>> > >>> As indicated below, I would support this proposal as a base for > >>> further > >> DAO > >>> operation specification. > >>> > >>> Roger > >>> > >>>> -----Original Message----- > >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf > >> Of > >>>> Richard Kelsey > >>>> Sent: Thursday, November 19, 2009 2:22 PM > >>>> To: roll@ietf.org > >>>> Subject: [Roll] updating DAO caches - a proposal > >>>> > >>>> > >>>> Below is an actual concrete proposal for managing DAO > >>>> caches. I believe that this would work well when all nodes > >>>> cache DAOs and when no nodes do so. It does a reasonable > >>>> job when only some nodes cache DAOs, although in some > >>>> situations there will be some superfluous DAOs transmitted. > >>>> > >>>> This assumes that DAOs are sent only to the preferred > >>>> parent. If DAO are sent to multiple parents the situation > >>>> becomes more complex. > >> > >> YES. > >> > >> Fanning out does not guarantee multipath opportunities on the way > >> back. > >> And that creates overload of states. > >> > >> > > > >Indeed multiple parents do not guarantee diverse outward end-to-end > >paths but it improves the potential. > > > >The use of just a single (acknowledged) parent should be left as an > >implementation choice (note that nodes can also maintain state for > >other non-acknowledged parent nodes without sending DAO updates to > >those nodes). Multiple parents need to be supported as part of the > >core RPL specification. > > > >>>> In a network with no DAO caches the new (C) flag is never > >>>> set. Whenever a node moves it sends a single DAO that > >>>> propagates to the root, which stores the nodes new location. > >> > >> But then its children that are dragged along do not update the root? > >> > >> That would work only if you use DAO for one_hop information and > >> leave it > >> up to the root to rebuild the source route. > >> Please let us know what you have in mind here, since that might > yield > >> complexities. > >> > >> I'll continue with the assumption that the Reverse Route Stack > >> contains > >> multiple hops. > >> > >>>> In a network where all nodes cache DAOs, a node that moves > >>>> sends the contents of its cache to its new parent. These > >>>> propagate up the tree, with each node forwarding on only > >>>> those prefixes which are new to its cache. The forwarding > >>>> stops when it reaches the least common ancestor of the > >>>> node's old and new locations. > >>> > >>> Agreed. > >> > >> IF we all agree on the above, that is sending only to one preferred > >> parent, then there can only be one child that advertises a DAO > >> destination. Thus there can be only one route to a destination. Thus > >> if > >> 2 children advertise a same destination, one is wrong. > >> > > > >The specification should allow nodes to be able to maintain multiple > >(acknowledged) parents. > > > >> The newest sequence in the DAO indicates the one that is correct. > The > >> other one should be cleaned up. > >> > >> > >> Do we agree in this one? > > > >Yes. Furthermore, with multiple parents the given sequence number > >associated with the update will ensure that updates arriving on > >different paths allow a common ancestor to maintain multiple forward > >(outward) routes. Note, delays or loss of DAO updates on different > >paths to the common ancestor can lead to temporary elimination of > >segments of the potential multiple outward paths. > > > >> > >>> > >>>> In a mixed network, nodes with caches and nodes whose only > >>>> caching ancestor is the root will have the same behavior > >>>> as above. A node without a cache will send its own DAO and > >>>> set the Destination Advertisement Trigger to cause its > >>>> sub-DAG to send DAOs as well. The Trigger will propagate > >>>> downwards causing more DAOs to be sent, but descedents that > >>>> have a cache will not propagate the Trigger to their own > >>>> sub-DAG. > >>> > >>> Some further refinement may need to be considered. Where nodes > >>> maintain > >> DAO > >>> caches the triggering of outward routing updates to the sub-DAG is > >>> not > >>> needed unless there has been a change in the path cost from the > >>> moving > >> node > >> > >> We agree. For all I understand, a node that caches 'absorbs' the D > >> bit; > >> that is it updates the parent that has set the D bit with its all > >> cache > >> and does not propagate the D bit. > >> > >> Metrics changes are subject to the trickle exponential backoff but > >> that > >> is a different process. If there is a significant change, the child > >> will > >> be told by the parent from that process, and either dump its cache > (if > >> it caches) or send its DAO and send a DIO with the D bit set (if it > >> does > >> not cache). > > > >Agreed. > > > >>> to the DAG root, which would then affect connectivity decisions of > >>> the > >>> sub-DAG nodes (one of the traffic reducing benefits of multiple > >>> parents > >> is > >>> the potential to mute the effect of individual link connectivity > >> changes). > >>> For nodes that do not maintain DAO caches, it should be possible to > >> apply > >>> the same mechanism since the moving parent node sends a DAO update > >> towards > >>> the root updating subsequent outward routes. > >>> > >> > >> Hum. I fear that we are back to the 'one hop' source route > >> collection I > >> discussed above with the root rebuilding the source route > >> recursively. I > >> hope we are not going that way... > > > >The root or other state-maintaining node would be capable of > >rebuilding the source route recursively. For 'mixed' node > >environments, other stateful nodes will need to support this > >processing as well. > > > >> > >>>> > >>>> -Richard Kelsey > >>>> > >>>> ---------------- > >>>> Proposal: > >>>> > >>>> Add a new DIO flag: > >>>> > >>>> Destination Advertisements Cache (C): The Destination > >>>> Advertisement Cache (C) flag is set when a node below > >>>> the DAG root in the successor chain caches DAOs sent > >>>> upwards. DAG roots NUST NOT set this flag. Nodes > >>>> below the root that maintain a DAO cache MUST set this > >>>> flag. Nodes below the root that do not maintain a DAO > >>>> cache MUST set this flag to the value received from > >>>> their preferred DAG Parent. > >>>> > >>>> > >>>> In 5.10.1.1. replace > >>>> > >>>> A node that modifies its DAG Parent set may set the `D' bit in > >>>> subsequent DIO propagation in order to trigger destination > >>>> advertisements to be updated to its DAG Parents and other > >> ancestors > >>>> on the DAG. Additional recommendations and guidelines regarding > >>>> the use of this mechanism are still under consideration and will > >> be > >>>> elaborated in a future revision of this specification. > >>>> > >>>> with > >>>> > >>>> When a node selects a new preferred parent it MUST send that > >> parent > >>>> a unicast DIO. If the node maintains a DIO cache the DIO sent > >> MUST > >> > >> DAO I presume? > >> > >>>> include the prefixes in the DAO cache. If the node does not > >>>> maintain a DIO cache and either the new preferred parent's DIO or > >>>> the old preferred parent's DIO has the Destination Advertisements > >>>> Cache set, then the node MUST set the Destination Advertisement > >>>> Trigger in its own subsequent DIO. > >>>> > >> > >> > >> Several things: > >> > >> - A node should prefer a parent that can cache; If that's generic > >> enough > >> that should be in the DIO. > >> > >OK. > > > >> - I fail to see why the DAG root does not set the flag. What happens > >> if > >> it is the only one that caches then? It appears that movements do > not > >> trigger DAOs though the source route path changes. > >> > >> - the D bit is not enough. The initial spec has a hash. In multihop > >> source route, are you sure the D will propagate without a loss? The > >> hash > >> is one of those values that would cause resetting trickle if changed > >> so > >> it should propagate efficiently. > >> > >> - I think the node that does not cache should send a DAO to its > parent > >> when the hash in the DIO changes. The hash should start up there at > >> the > >> first parent (included) that caches and include the path down the > >> preferred tree to this node. So if anything happens between the > cache > >> and this node, or if the parent that caches changes, this node knows > >> and > >> sends a DOA, and propagate the DIO with itself added to the changed > >> hash, so the hash changes. IOW if there is a cache up there and if > the > >> path to that cache or the cache itself changes then this node must > >> send > >> a DAO to inform nodes along that path. DAOs can be absorbed by the > >> cache > >> up there if that yields no difference that requires informing its > own > >> parent. > >> > >> Are we on the same line? > >> > > > >Yes. I think this may be part of the tradeoff for a stateless node. A > >node that maintains state will send a DIO on its sub-DAG only if there > >is a cost change to the root. > > > >> > >> Pascal > >> > >> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Roll mailing list > >>>> Roll@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/roll > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Mon Nov 30 21:23:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD0A3A67F5 for ; Mon, 30 Nov 2009 21:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_83=0.6, 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 litBvA6Co3Sr for ; Mon, 30 Nov 2009 21:23:55 -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 4254B3A6828 for ; Mon, 30 Nov 2009 21:23:55 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.26]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NFLDH-0003AV-K1 for roll@ietf.org; Mon, 30 Nov 2009 21:23:48 -0800 Received: by qw-out-2122.google.com with SMTP id 9so889278qwb.31 for ; Mon, 30 Nov 2009 21:23:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.78.162 with SMTP id l34mr316116qak.260.1259645026731; Mon, 30 Nov 2009 21:23:46 -0800 (PST) In-Reply-To: <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> <4B138424.9030409@sics.se> <4B139792.6030707@sics.se> <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> Date: Mon, 30 Nov 2009 21:23:46 -0800 Message-ID: From: Omprakash Gnawali To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: b05cf9a5276a81ca133e41a937654b06 Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 05:23:56 -0000 On Mon, Nov 30, 2009 at 9:14 AM, Philip Levis wrote: > > On Nov 30, 2009, at 1:59 AM, Joakim Eriksson wrote: > >> Hello, some more results on Trickle. >> >> .... >> >> The joining node is lucky when it gets in before 50% of the cycle has >> passed. At above 20% it does never need to send at all >> (since one of the other 10 did the job already). Is the node later than >> 50% it will take all the workload - this is what I would like to get >> avoid if I was a node ;-) >> >> The modified (simplified) version that does not wait out the interval >> will never end up synchronized for more than a very short time so the >> same simulation ends up looking like this: >> >> http://www.sics.se/~joakime/tricklemod0-phase-000.pdf >> > > Tom Anderson noted this issue when the paper was first published: there a= re > three considerations which, in practice, make this behavior amazingly > unlikely and therefore of limited concern: > > 1) Having all nodes perfectly synchronized is difficult/impossible > =A01a) Packet losses mean that nodes typically do not agree on exactly wh= en an > interval starts > =A01b) Nodes will, over time, fall out of synchronization due to local cl= ock > variations > 2) Networks have packet losses > =A02a) At some point the lagging node will not hear a transmission, will > transmit, and suppress the others > 3) The network is single-hop > > In essence, this behavior is only really apparent in tightly controlled, > aberrant settings (such as a single-hop simulation with no clock skew, > perfect synchronization, and lossless packet communication). This doesn't > mean that also covering this case isn't beneficial: it just needs to be > judged against the performance effects in less aberrant cases. This synchronization might be more commonplace that what we think. I think Joakim was discussing that in one of the later emails. In one experiment, I rebooted a few nodes in the middle of the quiet period (the first half when the timers don't fire), only to find the network synchronize after a few intervals. Here is the graph: http://stuff.stanford.edu/~om_p/ctp/trickle-interval/trickle-fullint-reboot= s/beacontime.html Experiment: 56 nodes, cc2420, 0 dBm. At approx. 2100s, reboot 3 nodes. Pick 10 random nodes in the network, divide them into three groups, reboot each group at a time, group reboots separated by number of seconds (corresponding to the three steps on the graph). I only have this experiment about synchronization, which does not prove much, other than that a network can get synchronized. >> It makes sense to use the simplified specification. > Om -- I think it deserves greater investigation than a single experiment. I forgot to mention that I have run full and truncated intervals with redundancy constant=3Dinf,15,10,5, two hrs for each redundancy constant. I think Joakim's experiments provide a different perspective on how these timers and the modifications work. - om_p From pal@cs.stanford.edu Mon Nov 30 21:58:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907C53A6AF1 for ; Mon, 30 Nov 2009 21:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 LDmoD6kwkCEz for ; Mon, 30 Nov 2009 21:58:41 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7467B3A687B for ; Mon, 30 Nov 2009 21:58:41 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NFLkv-0001dQ-I8; Mon, 30 Nov 2009 21:58:34 -0800 Message-Id: From: Philip Levis To: Omprakash Gnawali In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 21:58:33 -0800 References: <3C8DEBE5-9CD9-46A8-BD9B-CD828D503BBF@cs.stanford.edu> <4B138424.9030409@sics.se> <4B139792.6030707@sics.se> <042E3370-5D0F-4761-AB64-103C4EADC3CB@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-Scan-Signature: dfe9a19d2d5d3f4658608889c96f7beb Cc: roll Subject: Re: [Roll] simplified Trickle (was Re: trickle question) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 05:58:42 -0000 On Nov 30, 2009, at 9:23 PM, Omprakash Gnawali wrote: > On Mon, Nov 30, 2009 at 9:14 AM, Philip Levis > wrote: >> >> On Nov 30, 2009, at 1:59 AM, Joakim Eriksson wrote: >> >>> Hello, some more results on Trickle. >>> >>> .... >>> >>> The joining node is lucky when it gets in before 50% of the cycle >>> has >>> passed. At above 20% it does never need to send at all >>> (since one of the other 10 did the job already). Is the node later >>> than >>> 50% it will take all the workload - this is what I would like to get >>> avoid if I was a node ;-) >>> >>> The modified (simplified) version that does not wait out the >>> interval >>> will never end up synchronized for more than a very short time so >>> the >>> same simulation ends up looking like this: >>> >>> http://www.sics.se/~joakime/tricklemod0-phase-000.pdf >>> >> >> Tom Anderson noted this issue when the paper was first published: >> there are >> three considerations which, in practice, make this behavior amazingly >> unlikely and therefore of limited concern: >> >> 1) Having all nodes perfectly synchronized is difficult/impossible >> 1a) Packet losses mean that nodes typically do not agree on >> exactly when an >> interval starts >> 1b) Nodes will, over time, fall out of synchronization due to >> local clock >> variations >> 2) Networks have packet losses >> 2a) At some point the lagging node will not hear a transmission, >> will >> transmit, and suppress the others >> 3) The network is single-hop >> >> In essence, this behavior is only really apparent in tightly >> controlled, >> aberrant settings (such as a single-hop simulation with no clock >> skew, >> perfect synchronization, and lossless packet communication). This >> doesn't >> mean that also covering this case isn't beneficial: it just needs >> to be >> judged against the performance effects in less aberrant cases. > > > This synchronization might be more commonplace that what we think. I > think Joakim was discussing that in one of the later emails. In one > experiment, I rebooted a few nodes in the middle of the quiet period > (the first half when the timers don't fire), only to find the network > synchronize after a few intervals. Here is the graph: > http://stuff.stanford.edu/~om_p/ctp/trickle-interval/trickle-fullint-reboots/beacontime.html > > Experiment: 56 nodes, cc2420, 0 dBm. At approx. 2100s, reboot 3 nodes. > Pick 10 random nodes in the network, divide them into three groups, > reboot each group at a time, group reboots separated by number of > seconds (corresponding to the three steps on the graph). > > I only have this experiment about synchronization, which does not > prove much, other than that a network can get synchronized. Right -- the synchronization happens when a node sends a packet with the pull bit. The synchronization effect of request/response exchanges is well known: Deluge takes advantage of it to remove the listen-only period. But there are other events which reset intervals and *break* synchrony, such as a datapath inconsistency. The important result for Joakim's experiment is that load balancing works fine in a perfectly synchronized network and an unsynchronized one, but is imperfect in one which is mostly synchronized (a few nodes are out of phase). A better indication of the degree of synchrony you see, I think, is one of the figures from your SenSys slides, where you shown the beacons over time. > >>> It makes sense to use the simplified specification. >> Om -- I think it deserves greater investigation than a single >> experiment. > > I forgot to mention that I have run full and truncated intervals with > redundancy constant=inf,15,10,5, two hrs for each redundancy constant. > I think Joakim's experiments provide a different perspective on how > these timers and the modifications work. Maybe the two of you should compare notes? Phil From jvasseur@cisco.com Mon Nov 30 23:34:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89D228C1C1 for ; Mon, 30 Nov 2009 23:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=-3.233, 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 e142tO9DEW77 for ; Mon, 30 Nov 2009 23:34:28 -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 95F103A68F9 for ; Mon, 30 Nov 2009 23:34:27 -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: AkoAAHxVFEuQ/uCWe2dsb2JhbACbbAEBCwskBqJtl2qEMgQ X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="282051" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Dec 2009 07:08:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB17YJ5I005510; Tue, 1 Dec 2009 07:34:19 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:34:19 +0100 Received: from [144.254.21.8] ([144.254.21.8]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:34:18 +0100 Message-Id: <8E3B3CED-1D09-4EC3-ADE5-C18984F26364@cisco.com> From: JP Vasseur To: "Roger K. Alexander" In-Reply-To: <048201ca7217$0629fdf0$127df9d0$@alexander@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 08:33:47 +0100 References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> <048201ca7217$0629fdf0$127df9d0$@alexander@ekasystems.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 07:34:18.0790 (UTC) FILETIME=[B1210460:01CA7258] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17042.005 X-TM-AS-Result: No--36.794700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:34:30 -0000 Hi, Looks good. I had a proposal for the DAO packing - let me send it to the list for discussion. Thanks. JP. On Dec 1, 2009, at 12:44 AM, Roger K. Alexander wrote: > Hi Pascal, > > General agreement. Thanks. > > Roger > >> -----Original Message----- >> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >> Sent: Monday, November 30, 2009 8:53 AM >> To: Roger Alexander; Richard Kelsey >> Cc: roll@ietf.org; wintert@acm.org >> Subject: RE: [Roll] updating DAO caches - a proposal >> >> Hi Roger and Richard: >> >> For R05 I think we will not have time to converge on source route. >> I'll make a separate thread for R05 for the common pieces. >> >> This thread is about source route so I keep it this way. >> >> To integrate source route I think that we'll need to convert the >> routing >> header in a string of shorter tags. >> >> Here's how that could happen: >> >> - ack the DAO. What about a DA Confirm (DAC) ? > > Agreed. This could be in the form of a DIO with Ack indicator. > >> >> - Multiple destination info may be piggy backed (BNF?) > > Agreed. > >> >> - DAO Originator and caching parent MAY send the DAO to multiple >> parents, details left out. > > Agreed. More generically, "a node MAY send the DAO to multiple > parents". In > any event, there may not always be multiple candidate parents. > >> >> - A parent keeps track of its children. For each child, it maintains >> the >> tag that points onto the child and associated to that, the link local >> and the (destinations, originator sequence) for destinations owned by >> that child. This is done to aggregate multiple destinations in one >> messages, enable no-DAOs, etc... >> - a caching parent also keeps track of destinations. For those >> destinations, it maintains the tag that points onto the next_hop >> child >> and associated to that, the link local and the (destinations, >> originator >> sequence) for destinations owned by or reachable via that child. > > Agreed. > >> >> - A DAO emitted by the Originator node and a caching parent contains >> only the destination and sequence set by the originator. > > Agreed. The sequence number must be as set by each originator. This > will > allow a common ancestor to maintain diverse outward routing entries > where > applicable and similarly purge outdated entries as needed. > >> - A parent that propagates a DAO without caching it adds a local tag >> that points onto the child (see that as a locally significant >> compression of the child LLA, or an index on that child). >> > > OK. > >> - A Node that sends DIOs maintains its own cache_sequence that it >> places >> in the DIO. The sequence is increments to request the children to >> send >> their DIOs. >> - A child that changes its parent or gets a new cache_sequence from >> its >> parent dumps its DAO info. > > OK. This will allow for some recovery of lost DIOs. However the D bit > setting of the lost DIO is not recovered. > >> If the node does not cache all DAOs or if >> the >> D bit is set then the node needs to update its own cache_sequence, >> and >> propagate the DIO with the same setting of the D bit. >> >> What do you think? > > I need to give some further thought to the final mechanism. Thanks. > >> >> Pascal >> >>> -----Original Message----- >>> From: Roger Alexander [mailto:roger.alexander@ekasystems.com] >>> Sent: lundi 30 novembre 2009 04:18 >>> To: Pascal Thubert (pthubert) >>> Cc: Richard Kelsey; >>> Subject: Re: [Roll] updating DAO caches - a proposal >>> >>> Hi Pascal, Richard, others, >>> >>> >>> On Nov 23, 2009, at 7:06 AM, "Pascal Thubert (pthubert)" >> >>> wrote: >>> >>>> Hello Roger (and Richard) >>>> >>>> I think I'm mostly with you too. >>>> Need to make sure we're fully on the same page. >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>>>> Behalf Of >>>> Roger K. Alexander >>>>> Sent: samedi 21 novembre 2009 19:17 >>>>> To: 'Richard Kelsey'; roll@ietf.org >>>>> Subject: Re: [Roll] updating DAO caches - a proposal >>>>> >>>>> Hi Richard, >>>>> >>>>> As indicated below, I would support this proposal as a base for >>>>> further >>>> DAO >>>>> operation specification. >>>>> >>>>> Roger >>>>> >>>>>> -----Original Message----- >>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Richard Kelsey >>>>>> Sent: Thursday, November 19, 2009 2:22 PM >>>>>> To: roll@ietf.org >>>>>> Subject: [Roll] updating DAO caches - a proposal >>>>>> >>>>>> >>>>>> Below is an actual concrete proposal for managing DAO >>>>>> caches. I believe that this would work well when all nodes >>>>>> cache DAOs and when no nodes do so. It does a reasonable >>>>>> job when only some nodes cache DAOs, although in some >>>>>> situations there will be some superfluous DAOs transmitted. >>>>>> >>>>>> This assumes that DAOs are sent only to the preferred >>>>>> parent. If DAO are sent to multiple parents the situation >>>>>> becomes more complex. >>>> >>>> YES. >>>> >>>> Fanning out does not guarantee multipath opportunities on the way >>>> back. >>>> And that creates overload of states. >>>> >>>> >>> >>> Indeed multiple parents do not guarantee diverse outward end-to-end >>> paths but it improves the potential. >>> >>> The use of just a single (acknowledged) parent should be left as an >>> implementation choice (note that nodes can also maintain state for >>> other non-acknowledged parent nodes without sending DAO updates to >>> those nodes). Multiple parents need to be supported as part of the >>> core RPL specification. >>> >>>>>> In a network with no DAO caches the new (C) flag is never >>>>>> set. Whenever a node moves it sends a single DAO that >>>>>> propagates to the root, which stores the nodes new location. >>>> >>>> But then its children that are dragged along do not update the >>>> root? >>>> >>>> That would work only if you use DAO for one_hop information and >>>> leave it >>>> up to the root to rebuild the source route. >>>> Please let us know what you have in mind here, since that might >> yield >>>> complexities. >>>> >>>> I'll continue with the assumption that the Reverse Route Stack >>>> contains >>>> multiple hops. >>>> >>>>>> In a network where all nodes cache DAOs, a node that moves >>>>>> sends the contents of its cache to its new parent. These >>>>>> propagate up the tree, with each node forwarding on only >>>>>> those prefixes which are new to its cache. The forwarding >>>>>> stops when it reaches the least common ancestor of the >>>>>> node's old and new locations. >>>>> >>>>> Agreed. >>>> >>>> IF we all agree on the above, that is sending only to one preferred >>>> parent, then there can only be one child that advertises a DAO >>>> destination. Thus there can be only one route to a destination. >>>> Thus >>>> if >>>> 2 children advertise a same destination, one is wrong. >>>> >>> >>> The specification should allow nodes to be able to maintain multiple >>> (acknowledged) parents. >>> >>>> The newest sequence in the DAO indicates the one that is correct. >> The >>>> other one should be cleaned up. >>>> >>>> >>>> Do we agree in this one? >>> >>> Yes. Furthermore, with multiple parents the given sequence number >>> associated with the update will ensure that updates arriving on >>> different paths allow a common ancestor to maintain multiple forward >>> (outward) routes. Note, delays or loss of DAO updates on different >>> paths to the common ancestor can lead to temporary elimination of >>> segments of the potential multiple outward paths. >>> >>>> >>>>> >>>>>> In a mixed network, nodes with caches and nodes whose only >>>>>> caching ancestor is the root will have the same behavior >>>>>> as above. A node without a cache will send its own DAO and >>>>>> set the Destination Advertisement Trigger to cause its >>>>>> sub-DAG to send DAOs as well. The Trigger will propagate >>>>>> downwards causing more DAOs to be sent, but descedents that >>>>>> have a cache will not propagate the Trigger to their own >>>>>> sub-DAG. >>>>> >>>>> Some further refinement may need to be considered. Where nodes >>>>> maintain >>>> DAO >>>>> caches the triggering of outward routing updates to the sub-DAG is >>>>> not >>>>> needed unless there has been a change in the path cost from the >>>>> moving >>>> node >>>> >>>> We agree. For all I understand, a node that caches 'absorbs' the D >>>> bit; >>>> that is it updates the parent that has set the D bit with its all >>>> cache >>>> and does not propagate the D bit. >>>> >>>> Metrics changes are subject to the trickle exponential backoff but >>>> that >>>> is a different process. If there is a significant change, the child >>>> will >>>> be told by the parent from that process, and either dump its cache >> (if >>>> it caches) or send its DAO and send a DIO with the D bit set (if it >>>> does >>>> not cache). >>> >>> Agreed. >>> >>>>> to the DAG root, which would then affect connectivity decisions of >>>>> the >>>>> sub-DAG nodes (one of the traffic reducing benefits of multiple >>>>> parents >>>> is >>>>> the potential to mute the effect of individual link connectivity >>>> changes). >>>>> For nodes that do not maintain DAO caches, it should be possible >>>>> to >>>> apply >>>>> the same mechanism since the moving parent node sends a DAO update >>>> towards >>>>> the root updating subsequent outward routes. >>>>> >>>> >>>> Hum. I fear that we are back to the 'one hop' source route >>>> collection I >>>> discussed above with the root rebuilding the source route >>>> recursively. I >>>> hope we are not going that way... >>> >>> The root or other state-maintaining node would be capable of >>> rebuilding the source route recursively. For 'mixed' node >>> environments, other stateful nodes will need to support this >>> processing as well. >>> >>>> >>>>>> >>>>>> -Richard Kelsey >>>>>> >>>>>> ---------------- >>>>>> Proposal: >>>>>> >>>>>> Add a new DIO flag: >>>>>> >>>>>> Destination Advertisements Cache (C): The Destination >>>>>> Advertisement Cache (C) flag is set when a node below >>>>>> the DAG root in the successor chain caches DAOs sent >>>>>> upwards. DAG roots NUST NOT set this flag. Nodes >>>>>> below the root that maintain a DAO cache MUST set this >>>>>> flag. Nodes below the root that do not maintain a DAO >>>>>> cache MUST set this flag to the value received from >>>>>> their preferred DAG Parent. >>>>>> >>>>>> >>>>>> In 5.10.1.1. replace >>>>>> >>>>>> A node that modifies its DAG Parent set may set the `D' bit in >>>>>> subsequent DIO propagation in order to trigger destination >>>>>> advertisements to be updated to its DAG Parents and other >>>> ancestors >>>>>> on the DAG. Additional recommendations and guidelines regarding >>>>>> the use of this mechanism are still under consideration and will >>>> be >>>>>> elaborated in a future revision of this specification. >>>>>> >>>>>> with >>>>>> >>>>>> When a node selects a new preferred parent it MUST send that >>>> parent >>>>>> a unicast DIO. If the node maintains a DIO cache the DIO sent >>>> MUST >>>> >>>> DAO I presume? >>>> >>>>>> include the prefixes in the DAO cache. If the node does not >>>>>> maintain a DIO cache and either the new preferred parent's DIO or >>>>>> the old preferred parent's DIO has the Destination Advertisements >>>>>> Cache set, then the node MUST set the Destination Advertisement >>>>>> Trigger in its own subsequent DIO. >>>>>> >>>> >>>> >>>> Several things: >>>> >>>> - A node should prefer a parent that can cache; If that's generic >>>> enough >>>> that should be in the DIO. >>>> >>> OK. >>> >>>> - I fail to see why the DAG root does not set the flag. What >>>> happens >>>> if >>>> it is the only one that caches then? It appears that movements do >> not >>>> trigger DAOs though the source route path changes. >>>> >>>> - the D bit is not enough. The initial spec has a hash. In multihop >>>> source route, are you sure the D will propagate without a loss? The >>>> hash >>>> is one of those values that would cause resetting trickle if >>>> changed >>>> so >>>> it should propagate efficiently. >>>> >>>> - I think the node that does not cache should send a DAO to its >> parent >>>> when the hash in the DIO changes. The hash should start up there at >>>> the >>>> first parent (included) that caches and include the path down the >>>> preferred tree to this node. So if anything happens between the >> cache >>>> and this node, or if the parent that caches changes, this node >>>> knows >>>> and >>>> sends a DOA, and propagate the DIO with itself added to the changed >>>> hash, so the hash changes. IOW if there is a cache up there and if >> the >>>> path to that cache or the cache itself changes then this node must >>>> send >>>> a DAO to inform nodes along that path. DAOs can be absorbed by the >>>> cache >>>> up there if that yields no difference that requires informing its >> own >>>> parent. >>>> >>>> Are we on the same line? >>>> >>> >>> Yes. I think this may be part of the tradeoff for a stateless >>> node. A >>> node that maintains state will send a DIO on its sub-DAG only if >>> there >>> is a cost change to the root. >>> >>>> >>>> Pascal >>>> >>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 30 23:34:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088463A68F9 for ; Mon, 30 Nov 2009 23:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=-3.086, 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 s2vaeooTT6He for ; Mon, 30 Nov 2009 23:34:29 -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 AC5E328C1C0 for ; Mon, 30 Nov 2009 23:34:28 -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: AkoAAHxVFEuQ/uCWe2dsb2JhbACbbAEBCwskBqJtl2qEMgSNKw X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="282053" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Dec 2009 07:08:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB17YKri005522; Tue, 1 Dec 2009 07:34:20 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:34:20 +0100 Received: from [144.254.21.8] ([144.254.21.8]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:34:19 +0100 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 08:33:58 +0100 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 07:34:19.0946 (UTC) FILETIME=[B1D168A0:01CA7258] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17042.005 X-TM-AS-Result: No--16.912300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:34:30 -0000 On Nov 30, 2009, at 5:57 PM, Philip Levis wrote: > > On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: > >>> Date: Wed, 25 Nov 2009 10:43:41 +0100 >>> From: "Julien Abeille (jabeille)" >> >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: vendredi 20 novembre 2009 19:31 >>>> >>>> Point-to-point communication between nodes is needed by some >>>> applications. Section 5.2.2 of >>>> draft-ietf-roll-building-routing-reqs-07: >>>> >>>> "A network device MUST be able to communicate in a >>>> point-to-point manner with any other device on the network." >>> >>> Sure, and DAOs (whether stored only at root are not) solve this >>> issue. >>> May not be the most efficient, but the sceanrios multicast DAOs >>> solve >>> are so limited that we will end up with 10 solutions for 10 >>> scenarios if >>> we go that path. >>> >>> I would personaly drop multicast DAOs >> >> I agree. As we have done with unicasts, we need to look >> carefully at the multicast requirements and find ways to >> solve the easy and/or common cases first. I do not think >> that there is a workable one-size-fits-all multicast >> solution. > > Because the current mandate is for greater simplicity, it makes > sense to remove RPL features/mechanisms that don't have strong > proponents. > > Does anyone think multicast DAOs should remain? If so, it would help > if you could explain your reasoning on the tradeoff between the > benefits and drawbacks (increased complexity). I do think so. It makes little sense to remove something just because it makes it more simpler. Multicast DAO does help to come up with shorter path, which is quite important for P2P and the level of complexity is close to 0. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 30 23:39:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DBA3A68F9 for ; Mon, 30 Nov 2009 23:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=-3.086, 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 b15d+VFKkl1x for ; Mon, 30 Nov 2009 23:39:34 -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 058A03A68AD for ; Mon, 30 Nov 2009 23:39:33 -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: AkoAAKdWFEuQ/uCWe2dsb2JhbACbbAEBCwskBqJ7l2qEMgSNKw X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="282509" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Dec 2009 07:13:45 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB17dP9Z006771; Tue, 1 Dec 2009 07:39:25 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:25 +0100 Received: from dhcp-144-254-20-111.cisco.com ([144.254.20.111]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:25 +0100 Message-Id: <4387A3F5-2DF7-47A9-8AA0-ECE3555C1717@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 08:35:27 +0100 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 07:39:25.0394 (UTC) FILETIME=[67E11320:01CA7259] Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:39:34 -0000 On Nov 30, 2009, at 5:57 PM, Philip Levis wrote: > > On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: > >>> Date: Wed, 25 Nov 2009 10:43:41 +0100 >>> From: "Julien Abeille (jabeille)" >> >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: vendredi 20 novembre 2009 19:31 >>>> >>>> Point-to-point communication between nodes is needed by some >>>> applications. Section 5.2.2 of >>>> draft-ietf-roll-building-routing-reqs-07: >>>> >>>> "A network device MUST be able to communicate in a >>>> point-to-point manner with any other device on the network." >>> >>> Sure, and DAOs (whether stored only at root are not) solve this >>> issue. >>> May not be the most efficient, but the sceanrios multicast DAOs >>> solve >>> are so limited that we will end up with 10 solutions for 10 >>> scenarios if >>> we go that path. >>> >>> I would personaly drop multicast DAOs >> >> I agree. As we have done with unicasts, we need to look >> carefully at the multicast requirements and find ways to >> solve the easy and/or common cases first. I do not think >> that there is a workable one-size-fits-all multicast >> solution. > > Because the current mandate is for greater simplicity, it makes > sense to remove RPL features/mechanisms that don't have strong > proponents. > > Does anyone think multicast DAOs should remain? If so, it would help > if you could explain your reasoning on the tradeoff between the > benefits and drawbacks (increased complexity). I do think so. It makes little sense to remove something just because it makes it more simpler. Multicast DAO does help to come up with shorter path, which is quite important for P2P and the level of complexity is close to 0. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 30 23:39:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673C228C1C0 for ; Mon, 30 Nov 2009 23:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=-3.086, 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 Hv6FWg1qcrTR for ; Mon, 30 Nov 2009 23:39:35 -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 CDDFF3A68AD for ; Mon, 30 Nov 2009 23:39:34 -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: AkoAAKdWFEuQ/uCWe2dsb2JhbACbbAEBCwskBqJ7l2qEMgSNKw X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="282514" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Dec 2009 07:13:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB17dRLt006786; Tue, 1 Dec 2009 07:39:27 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:27 +0100 Received: from dhcp-144-254-20-111.cisco.com ([144.254.20.111]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:26 +0100 Message-Id: <57E563A2-0FAE-4317-82CA-DC01C9FEF4D4@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 08:37:25 +0100 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 07:39:26.0956 (UTC) FILETIME=[68CF6AC0:01CA7259] Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:39:35 -0000 On Nov 30, 2009, at 5:57 PM, Philip Levis wrote: > > On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: > >>> Date: Wed, 25 Nov 2009 10:43:41 +0100 >>> From: "Julien Abeille (jabeille)" >> >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: vendredi 20 novembre 2009 19:31 >>>> >>>> Point-to-point communication between nodes is needed by some >>>> applications. Section 5.2.2 of >>>> draft-ietf-roll-building-routing-reqs-07: >>>> >>>> "A network device MUST be able to communicate in a >>>> point-to-point manner with any other device on the network." >>> >>> Sure, and DAOs (whether stored only at root are not) solve this >>> issue. >>> May not be the most efficient, but the sceanrios multicast DAOs >>> solve >>> are so limited that we will end up with 10 solutions for 10 >>> scenarios if >>> we go that path. >>> >>> I would personaly drop multicast DAOs >> >> I agree. As we have done with unicasts, we need to look >> carefully at the multicast requirements and find ways to >> solve the easy and/or common cases first. I do not think >> that there is a workable one-size-fits-all multicast >> solution. > > Because the current mandate is for greater simplicity, it makes > sense to remove RPL features/mechanisms that don't have strong > proponents. > > Does anyone think multicast DAOs should remain? If so, it would help > if you could explain your reasoning on the tradeoff between the > benefits and drawbacks (increased complexity). I do think so. It makes little sense to remove something just because it makes it more simpler. Multicast DAO does help to come up with shorter path, which is quite important for P2P and the level of complexity is close to 0. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Nov 30 23:39:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5714128C1CA for ; Mon, 30 Nov 2009 23:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=-3.086, 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 HymNbpRLbGGI for ; Mon, 30 Nov 2009 23:39:37 -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 B751E28C1C5 for ; Mon, 30 Nov 2009 23:39:36 -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: AkoAAKdWFEuQ/uCWe2dsb2JhbACbbAEBCwskBqJ7l2qEMgSNKw X-IronPort-AV: E=Sophos;i="4.47,319,1257120000"; d="scan'208";a="282519" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 01 Dec 2009 07:13:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB17dTbo006809; Tue, 1 Dec 2009 07:39:29 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:29 +0100 Received: from dhcp-144-254-20-111.cisco.com ([144.254.20.111]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:39:29 +0100 Message-Id: <8203DD69-8CF7-49B7-9429-382903BA67B0@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 08:39:24 +0100 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 07:39:29.0285 (UTC) FILETIME=[6A32CB50:01CA7259] Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:39:37 -0000 On Nov 30, 2009, at 5:57 PM, Philip Levis wrote: > > On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: > >>> Date: Wed, 25 Nov 2009 10:43:41 +0100 >>> From: "Julien Abeille (jabeille)" >> >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: vendredi 20 novembre 2009 19:31 >>>> >>>> Point-to-point communication between nodes is needed by some >>>> applications. Section 5.2.2 of >>>> draft-ietf-roll-building-routing-reqs-07: >>>> >>>> "A network device MUST be able to communicate in a >>>> point-to-point manner with any other device on the network." >>> >>> Sure, and DAOs (whether stored only at root are not) solve this >>> issue. >>> May not be the most efficient, but the sceanrios multicast DAOs >>> solve >>> are so limited that we will end up with 10 solutions for 10 >>> scenarios if >>> we go that path. >>> >>> I would personaly drop multicast DAOs >> >> I agree. As we have done with unicasts, we need to look >> carefully at the multicast requirements and find ways to >> solve the easy and/or common cases first. I do not think >> that there is a workable one-size-fits-all multicast >> solution. > > Because the current mandate is for greater simplicity, it makes > sense to remove RPL features/mechanisms that don't have strong > proponents. > > Does anyone think multicast DAOs should remain? If so, it would help > if you could explain your reasoning on the tradeoff between the > benefits and drawbacks (increased complexity). I do think so. It makes little sense to remove something just because it makes it more simpler. Multicast DAO does help to come up with shorter path, which is quite important for P2P and the level of complexity is close to 0. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll