From roll@tanglewoodnet.com Thu Mar 1 08:42:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB48521E8133 for ; Thu, 1 Mar 2012 08:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6ZYshvhMHFd for ; Thu, 1 Mar 2012 08:42:27 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id CFDBA21F87E0 for ; Thu, 1 Mar 2012 08:42:26 -0800 (PST) Received: from Tanglewood (cpc1-sotn6-0-0-cust253.15-1.cable.virginmedia.com [213.105.212.254]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Mddoi-1Rmjj30cFY-00PXur; Thu, 01 Mar 2012 17:42:25 +0100 From: "Peter Burnett" To: "'Dario Tedeschi'" , References: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> <4F4F1692.7050500@exegin.com> In-Reply-To: <4F4F1692.7050500@exegin.com> Date: Thu, 1 Mar 2012 16:42:33 -0000 Organization: Tanglewood Networks Message-ID: <038101ccf7ca$4dd57130$e9805390$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0382_01CCF7CA.4DD57130" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3dEMLuBRMby3mQYi8E3blxAMHHAAVQJYw Content-Language: en-gb X-Provags-ID: V02:K0:dY9oAXANN4WzL050NcvIhX0iTtPwl6GcpVU9lCVjMQi w/hOeh7n6bVfPHRWN0Sb/ssHIOL2S9g+ln4Bl8X3xFFzSKvc17 0Uxzjw0jsbpnkyhpSpm1gFa5tdzYQmsLH8riPamZlm0yQ1o98e 3UI5IGf40O1csf+64xQOsBWPglgcyvTWsMvhbfSbN0cNOeG0d2 FiEKhjq3sr4a5cJt7Zc9DG4yxo+fPPR0rJgRMaDFa0rR9CmUiY aqzjAXT1hv8dQfKo4e8xPDYGnmahkGM0i43vBEMd1rkeFvIS9Y E+gfnSVMFgFGF2DJLhyG0mp5BcJETPXhof1rEBs39mgpvd7ivI kDzRReKipwqLluBW7LTZc0YJhokcniEgcmR/cJeXT Subject: Re: [Roll] MRHOF Objective function (using ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Mar 2012 16:42:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0382_01CCF7CA.4DD57130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Another related difficulty for me is that section 3.3 seems to say that the rank of a non-root node is the path cost through the worst parent. However 3.4 says that the advertised rank is the path cost through the preferred parent, the min_path_cost. How can these be reconciled? Thanks Peter Burnett From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dario Tedeschi Sent: 01 March 2012 06:26 To: roll@ietf.org Subject: Re: [Roll] MRHOF Objective function (using ETX metric) Yes, how exactly is MinHopRankIncrease used for rank calculation in MRHOF? In the case of using the ETX metric, could it be something like the following: my_rank = cur_min_path_cost = parent_rank + (MinHopRankIncrease * {ETX of link with parent}) Where MinHopRankIncrease = 128. Please could someone clarify. Dario On 12-02-21 12:17 PM, Costin Michaela Catalina-B06063 wrote: Hello guys, While reading MRHOF draft (for ETX metric), I identified some discrepancies between the RPL and the MRHOF draft: The rank of a DODAG root according to ROLL RPL draft is MinHopRankIncrease (default value = 0x100). According to MRHOF, the rank of the DODAG root is MIN_PATH_COST (default value = 0) The algorithm for computing node rank is not clearly described in the MRHOF draft. Once the path cost for all neighbors is computed and the preferred parent is selected, the node rank is calculated just by adding MinHopRankIncrease to the smallest path cost (to the preferred parent path cost)? Do you have any comments related to these issues? Thanks, Catalina Costin Freescale Semiconductor Romania Phone: +40 21 3052217 mihaela.costin@freescale.com ======================================================= This e-mail, and any associated attachments have been classified as: [x] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0382_01CCF7CA.4DD57130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another related = difficulty for me is that section 3.3 seems to say that the rank of a = non-root node is the path cost through the worst parent. However 3.4 = says that the advertised rank is the path cost through the preferred = parent, the min_path_cost. How can these be = reconciled?

 

Thanks

Peter = Burnett

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Dario Tedeschi
Sent: 01 March 2012 06:26
To: = roll@ietf.org
Subject: Re: [Roll] MRHOF Objective function = (using ETX metric)

 

Yes, how = exactly is MinHopRankIncrease used for rank calculation in = MRHOF?

In the case of using the ETX metric, could it be something = like the following:
my_rank =3D cur_min_path_cost =3D parent_rank + = (MinHopRankIncrease * {ETX of link with parent})
Where = MinHopRankIncrease =3D 128.

Please could someone = clarify.

Dario

On 12-02-21 12:17 PM, Costin Michaela = Catalina-B06063 wrote:

Hello = guys,

 

While reading MRHOF draft (for ETX metric),  I = identified some discrepancies between the RPL and the MRHOF = draft:

The rank of a DODAG root according to ROLL = RPL draft is MinHopRankIncrease (default value =3D 0x100). According to = MRHOF,  the rank of the DODAG root is MIN_PATH_COST (default value = =3D 0)

The algorithm for computing node rank is = not clearly described in the MRHOF draft. Once the path cost for all = neighbors is computed and the preferred parent is selected, the node = rank is calculated just by adding MinHopRankIncrease to the smallest = path cost (to the preferred parent path cost)?

 

Do you have = any comments related to these issues?

 

Thanks,

 

 

Catalina Costin
Freescale= Semiconductor Romania
Phone: +40 21 3052217
mihaela.costin@freescale.com=
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
This e-mail, and any associated attachments have been classified = as:
[x] Public
[  ] Freescale Semiconductor Internal Use = Only
[  ] Freescale Semiconductor Confidential = Proprietary

 

 
<=
o:p> 
______________________________________________=
_
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll

 

------=_NextPart_000_0382_01CCF7CA.4DD57130-- From internet-drafts@ietf.org Fri Mar 2 06:24:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826B521F84B3; Fri, 2 Mar 2012 06:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wtl7JBWWMkv; Fri, 2 Mar 2012 06:24:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0C21F84A1; Fri, 2 Mar 2012 06:24:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302142456.713.80163.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 06:24:56 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 14:24:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-08.txt Pages : 30 Date : 2012-03-02 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meets specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-08.txt From prvs=4021e4268=mukul@uwm.edu Sat Mar 3 14:23:05 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625921F851D for ; Sat, 3 Mar 2012 14:23:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8-4E-L-cHEZ for ; Sat, 3 Mar 2012 14:23:04 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id A370721F8504 for ; Sat, 3 Mar 2012 14:23:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFeZUk9/AAAB/2dsb2JhbABDhUGyEQEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJEIduC59Kjg2IG4EfgS+OGIEWBIhQjG6QEoMCgTUFAhA Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9BA371FD014 for ; Sat, 3 Mar 2012 16:23:03 -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 ftJQ5i733-WS for ; Sat, 3 Mar 2012 16:23:02 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 60E5A1FD013 for ; Sat, 3 Mar 2012 16:23:02 -0600 (CST) Date: Sat, 3 Mar 2012 16:23:02 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1767016292.1458481.1330813382261.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120302142456.713.80163.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - FF3.0 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Mar 2012 22:23:05 -0000 Hi all, The main changes in P2P-RPL-08 over the previous version are as follows: 1) allow P2P-RPL to discover routes to multiple targets at the same time: - The target address in P2P-RDO can specify either a unicast address or a multicast one. - Additional target addresses (unicast or multicast) can be specified by including one or more RPL Target options inside the P2P mode DIO. 2) Defined a new Data option to piggyback time-critical application data in DIOs and DROs. The origin (the target) can include one or more Data Options inside the DIO (DRO) to deliver time-critical application data to the targets (origin). 3) The origin now explicitly states in the P2P-RDO whether the target(s) should generate DRO replies or not. Removed the Direction flag from the P2P-RDO. 4) Made it clear that on receiving a DRO with stop flag set, a router should not send or receive any more DIOs for this temporary DAG. The router should continue to process DROs and maintain its membership in the temporary DAG until its life time is over. 5) Allow the inclusion of Route Information and Prefix Information options inside a P2P mode DIO. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Friday, March 2, 2012 8:24:56 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-08.txt Pages : 30 Date : 2012-03-02 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meets specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-08.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From internet-drafts@ietf.org Sun Mar 4 11:00:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88BB21F860B; Sun, 4 Mar 2012 11:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLA+YOkS7anc; Sun, 4 Mar 2012 11:00:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4821E21F84F8; Sun, 4 Mar 2012 11:00:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304190042.21791.72373.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2012 11:00:42 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Mar 2012 19:00:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-03.txt Pages : 19 Date : 2012-03-04 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-03.txt From pal@cs.stanford.edu Sun Mar 4 15:45:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E510721F860B for ; Sun, 4 Mar 2012 15:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPPGQg8TgER4 for ; Sun, 4 Mar 2012 15:45:58 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id E821721F8600 for ; Sun, 4 Mar 2012 15:45:58 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S4L7f-0005eP-Uy; Sun, 04 Mar 2012 15:45:52 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> Date: Sun, 4 Mar 2012 15:45:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <77887DB3-230D-40AC-A774-4F0A237FF256@cs.stanford.edu> References: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> To: Costin Michaela Catalina-B06063 X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: "roll@ietf.org" Subject: Re: [Roll] MRHOF Objective function (using ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Mar 2012 23:46:00 -0000 On Feb 21, 2012, at 2:17 AM, Costin Michaela Catalina-B06063 wrote: > Hello guys, > =20 > While reading MRHOF draft (for ETX metric), I identified some = discrepancies between the RPL and the MRHOF draft: > =B7 The rank of a DODAG root according to ROLL RPL draft is = MinHopRankIncrease (default value =3D 0x100). According to MRHOF, the = rank of the DODAG root is MIN_PATH_COST (default value =3D 0) This is an error -- the RPL specification is correct. > =B7 The algorithm for computing node rank is not clearly = described in the MRHOF draft. Once the path cost for all neighbors is = computed and the preferred parent is selected, the node rank is = calculated just by adding MinHopRankIncrease to the smallest path cost = (to the preferred parent path cost)? No -- it is rank calculated the preferred parent path cost. = MinHopRankIncrease sets a minimum value it must increase by. So if the = node's Rank is less than its worst parent + MinHopRankIncrease, then its = Rank is worst parent + MinHopRankIncrease. I'm clearing these things up in -05; I greatly appreciate the pointers = and questions. Phil From pal@cs.stanford.edu Sun Mar 4 15:47:32 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86E21F866B for ; Sun, 4 Mar 2012 15:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fd2Klbk+wQO for ; Sun, 4 Mar 2012 15:47:32 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id D19DC21F8669 for ; Sun, 4 Mar 2012 15:47:28 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S4L9B-0008K1-Ch; Sun, 04 Mar 2012 15:47:25 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <038101ccf7ca$4dd57130$e9805390$@com> Date: Sun, 4 Mar 2012 15:47:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4538B777-EA8C-46F0-BEAF-ABFAC296EAAF@cs.stanford.edu> References: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> <4F4F1692.7050500@exegin.com> <038101ccf7ca$4dd57130$e9805390$@com> To: Peter Burnett X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: roll@ietf.org Subject: Re: [Roll] MRHOF Objective function (using ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Mar 2012 23:47:32 -0000 On Mar 1, 2012, at 8:42 AM, Peter Burnett wrote: > Another related difficulty for me is that section 3.3 seems to say = that the rank of a non-root node is the path cost through the worst = parent. However 3.4 says that the advertised rank is the path cost = through the preferred parent, the min_path_cost. How can these be = reconciled? The first is correct. I'm fixing this in -05, thanks for catching it. Phil= From pal@cs.stanford.edu Sun Mar 4 15:50:49 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F021F8675 for ; Sun, 4 Mar 2012 15:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5kAzAgP3OSj for ; Sun, 4 Mar 2012 15:50:48 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 839E221F8674 for ; Sun, 4 Mar 2012 15:50:48 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S4LCN-0005z6-PI; Sun, 04 Mar 2012 15:50:43 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> Date: Sun, 4 Mar 2012 15:50:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <22931FE0-35FF-44DE-B9DC-61A94D70A077@cs.stanford.edu> References: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 768232f66e6ec7ed279584ab5539d282 Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Mar 2012 23:50:49 -0000 On Sep 27, 2011, at 7:59 AM, Adrian Farrel wrote: > Hi, >=20 > Here is my AD review of your draft. I was hoping to get away with a = few > typos we could punt to a later stage, but I think there are a couple = of > issues we need to iron out with a quick new revision. >=20 > I have put the I-D into "revised I-D needed" state and will issue the = IETF Last > Call when I see a new revision. >=20 > Thanks, > Adrian >=20 First off, I apologize for how long this took. Om and I miscommunicated; = he thought I was handling the revision and I thought he was.=20 > --- >=20 > In progressing the OG0 draft we learnt that there was no clear > understanding of what an objective function is. I think your draft = does > a good job at explaining, but in an attempt to learn from the past, = can > you please have a look at the text that got added to the OF0 document = to > see whether anything can be added here. >=20 > --- >=20 > Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not=20 > MROFH? I've changed the title to reflect the acronym. >=20 > --- >=20 > During the review process for OF0 we ended up adding the following=20 > paragraph. Would you consider adding something similar to make this > point crystal clear? >=20 > The RPL specification [I-D.ietf-roll-rpl] requires the use of a > common OF by all nodes in a network. The possible use of multiple > OFs with a single network is for further study. Added. >=20 > --- >=20 > Section 2... >=20 > This document introduces two terms: >=20 > There are three terms! Or 11 terms! ;) Corrected. >=20 > --- >=20 > Section 5.1 >=20 > Can you add a statement on default values? There's an earlier section with default values; this section now = references it. >=20 > Can you also have a look at Section 7 of the OF0 draft. This gives a > more substantive approach to describing manageability. I've fleshed out the section accordingly, following the model in OF0. >=20 > --- >=20 > 7. IANA Considerations >=20 > You need to point the IANA at the specific registry. This would be the > "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for > Low Power and Lossy Networks (RPL)" registry. >=20 > This specification requires an allocated OCP. A value of 1 is > requested. >=20 > s/requested/suggested/ Fixed. >=20 > --- >=20 > 8. Security Considerations >=20 > Security considerations to be developed in accordance to the output > of the WG. >=20 > I don't think we will get this past the Security directorate :-) >=20 > How about... >=20 > This specification makes simple extensions to RPL and so is > vulnerable to and benefits from the security issues and mechanisms > described in [I-D.ietf-roll-rpl] and > [I-D.ietf-roll-security-framework]. This document does not = introduce > new flows or new messages, thus requires no specific mitigation for > new threats. >=20 > MRHOF depends on information exchanged in a number RPL protocol > elements. If those elements were compromised, then an = implementation > of MRHOF might generate the wrong path for a packet, resulting in it > being misrouted. Therefore, deployments are RECOMMENDED to use RPL > security mechanisms if there is a risk that routing information = might > be modified or spoofed. >=20 Added. Phil= From internet-drafts@ietf.org Sun Mar 4 15:52:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5321F8681; Sun, 4 Mar 2012 15:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hyJ0vWrhKAd; Sun, 4 Mar 2012 15:52:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7347821F8679; Sun, 4 Mar 2012 15:52:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304235214.14100.71244.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2012 15:52:14 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Mar 2012 23:52:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : The Minimum Rank with Hysteresis Objective Function Author(s) : Omprakash Gnawali Philip Levis Filename : draft-ietf-roll-minrank-hysteresis-of-05.txt Pages : 12 Date : 2012-03-04 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0= 5.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-05= .txt From prvs=4041738a5=mukul@uwm.edu Sun Mar 4 16:37:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5921F867A for ; Sun, 4 Mar 2012 16:37:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwdLndO7wXaM for ; Sun, 4 Mar 2012 16:37:40 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2021F8672 for ; Sun, 4 Mar 2012 16:37:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFsKVE9/AAAB/2dsb2JhbABDhTSyEwEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJh34LmE6ODYgUiQeBL44YgRYEiFCMbpASgwI Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 29F65E6A88 for ; Sun, 4 Mar 2012 18:37:39 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eCxx1qoQHTs for ; Sun, 4 Mar 2012 18:37:38 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id D28EDE6A82 for ; Sun, 4 Mar 2012 18:37:38 -0600 (CST) Date: Sun, 4 Mar 2012 18:37:38 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <864738222.1463472.1330907858739.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120304190042.21791.72373.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - FF3.0 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 00:37:41 -0000 Hi all The main difference over the previous version is that now RPL Instance defines the scope of the Measurement Object messages. A router MUST drop an MO message if it is not aware of the RPL Instance specified in the message. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Sunday, March 4, 2012 1:00:42 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-03.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 : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-03.txt Pages : 19 Date : 2012-03-04 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-03.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Mon Mar 5 10:53:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B10221F8857; Mon, 5 Mar 2012 10:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qtREwG4ZZcA; Mon, 5 Mar 2012 10:52:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A80EC21F8836; Mon, 5 Mar 2012 10:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q25IqjpP004456; Mon, 5 Mar 2012 19:52:45 +0100 (CET) Received: from eduroam-pool6-0113.wlan.uni-bremen.de (eduroam-pool6-0113.wlan.uni-bremen.de [134.102.24.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D02DB38B; Mon, 5 Mar 2012 19:52:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> Date: Mon, 5 Mar 2012 19:52:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95A48EF5-8E0A-46C7-9677-83D5B218497F@tzi.org> References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> To: 6lowpan@ietf.org, "core@ietf.org WG" , roll@ietf.org, lwip@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [Roll] [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 18:53:01 -0000 In the final agenda, homenet and 6man have exchanged places. 6man still is a bit of a conflict for core, but much less so than = homenet. Thanks to our ADs for fixing this! https://datatracker.ietf.org/meeting/83/agenda.html Gr=FC=DFe, Carsten On Feb 24, 2012, at 09:25, Carsten Bormann wrote: > Here is my usual compilation of the draft agenda for IETF83. > Note that this agenda is subject to change, so please don't plan = travel around it. > This time, we are nicely spread out over the week, so a lot of things = will happen between the meeting slots. >=20 > Gr=FC=DFe, Carsten >=20 >=20 > ***DRAFT*** Agenda for Constrained Node/Network related events during > IETF 83 in Paris > ***Subject to change*** -- don't plan travel around this >=20 > * FRIDAY, March 23, 2012 >=20 > IAB Workshop on Smart Object Security >=20 > * SATURDAY, March 24, 2012; SUNDAY, March 25, 2012 >=20 > ETSI CoAP plugfest >=20 > * MONDAY, March 26, 2012 >=20 > 0900-1130 > Maillot OPS v6ops IPv6 Operations WG >=20 > * TUESDAY, March 27, 2012 >=20 > 0900-1130 > 243 APP *core* Constrained RESTful Environments WG > Maillot INT homenet Home Networking WG >=20 > 1300-1500 > 241 OPS eman Energy Management WG >=20 > * WEDNESDAY, March 28, 2012 >=20 > 0900-1130 > 242AB INT 6man IPv6 Maintenance WG >=20 > 1300-1500 > 241 RTG *roll* Routing Over Low power and Lossy networks WG >=20 > * THURSDAY, March 29, 2012 >=20 > 1300-1500 > Maillot INT intarea Internet Area Working Group WG >=20 > 1520-1720 > 252B INT *lwig* Light-Weight Implementation Guidance WG > Maillot OPS v6ops IPv6 Operations WG >=20 > * FRIDAY, March 30, 2012 >=20 > 0900-1100 > 253 APP *core* Constrained RESTful Environments WG >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From mcr@sandelman.ca Mon Mar 5 12:36:11 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0BB11E80B2 for ; Mon, 5 Mar 2012 12:36:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBDwmZTmO5-8 for ; Mon, 5 Mar 2012 12:36:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F721F8901 for ; Mon, 5 Mar 2012 12:36:10 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 0F4BB344DA; Mon, 5 Mar 2012 15:33:40 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0DACA98280; Mon, 5 Mar 2012 15:35:48 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0A0589827F; Mon, 5 Mar 2012 15:35:48 -0500 (EST) From: Michael Richardson To: roll In-Reply-To: <1767016292.1458481.1330813382261.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1767016292.1458481.1330813382261.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 05 Mar 2012 15:35:47 -0500 Message-ID: <21905.1330979747@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 20:36:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> Hi all, Mukul> The main changes in P2P-RPL-08 over the previous version are Mukul> as follows: Mukul> 1) allow P2P-RPL to discover routes to multiple targets at Mukul> the same time: - The target address in P2P-RDO can specify Mukul> either a unicast address or a multicast one.=20=20 When it's a multicast address, is the idea that all stations which are member of that group respond? Or=20 Also, a question about: "upto four source" why the number four? How does a sender know how to send time-critical messages to the target if the target doesn't send back DROs: "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver time-=09 critical application data to the target(s)." I'm guessing that the info is piggy backed into the RPL message itself, using these Data Options. Do we need to specify what is in these Data Options? (My opinion... it's an IPv6 Upper-Layer Protocol...) re the H-flag: The origin sets this flag to 1 if it desires hop-by-hop routes.=09 The origin sets this flag to 0 if it desires source routes.=20=20 It might be worth giving an example of each. I think I'm not sure what a hop-by-hop route is, exactly. Your glossary says: Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route. but I think that I don't understand what's going on.=20=20 I'm not sure I know how to use this information on the origin node. Well... wait... is this only useful for storing nodes? maybe I need to read: I-D.ietf-6man-rpl-option , which I haven't yet. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT1Ujo4qHRg3pndX9AQLEiAQAsXwkpKu0NGpEQYMtIV2SCX7+MSeWXt0J WRchzgcoOGA0nPxC8/01tplDehly+/FfEFSvhlNi2opeiRD7UpozIsG97WNkhcuX 4q54y2vv0O0sWZ+Q/26pSj8+ibWylChDEOhj19YOWTdHeKjM/ssZiP5+PknmRG7L 0Li8M0evuIY= =fphv -----END PGP SIGNATURE----- --=-=-=-- From jreddy@ti.com Mon Mar 5 13:42:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AC721F8873 for ; Mon, 5 Mar 2012 13:42:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+ssmJnMe+oJ for ; Mon, 5 Mar 2012 13:42:27 -0800 (PST) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by ietfa.amsl.com (Postfix) with ESMTP id EC48421F8870 for ; Mon, 5 Mar 2012 13:42:26 -0800 (PST) Received: from dlep26.itg.ti.com ([157.170.170.121]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id q25LgKgE011687; Mon, 5 Mar 2012 15:42:20 -0600 Received: from DFLE70.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id q25LgKKQ024038; Mon, 5 Mar 2012 15:42:20 -0600 (CST) Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Mon, 5 Mar 2012 15:42:20 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" , Philip Levis Thread-Topic: Roll Digest, Vol 50, Issue 4 Thread-Index: AQHM+wqq1evztPgNr0qkL9XjI0N8WJZcOpSQ Date: Mon, 5 Mar 2012 21:42:20 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2C987A54@DLEE10.ent.ti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Roll Digest, Vol 50, Issue 4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 21:42:27 -0000 Hi Phil, I believe the Rank should be computed as the path cost from the best parent= and not worst one. We had this discussion on this topic previously on the reflector....see http://www.ietf.org/mail-archive/web/roll/current/msg06077.html -Regards, Joseph ------------------------------ Message: 2 Date: Sun, 4 Mar 2012 15:47:23 -0800 From: Philip Levis To: Peter Burnett Cc: roll@ietf.org Subject: Re: [Roll] MRHOF Objective function (using ETX metric) Message-ID: <4538B777-EA8C-46F0-BEAF-ABFAC296EAAF@cs.stanford.edu> Content-Type: text/plain; charset=3Dus-ascii On Mar 1, 2012, at 8:42 AM, Peter Burnett wrote: > Another related difficulty for me is that section 3.3 seems to say that t= he rank of a non-root node is the path cost through the worst parent. Howev= er 3.4 says that the advertised rank is the path cost through the preferred= parent, the min_path_cost. How can these be reconciled? The first is correct. I'm fixing this in -05, thanks for catching it. Phil From pal@cs.stanford.edu Mon Mar 5 14:00:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8763921F8855 for ; Mon, 5 Mar 2012 14:00: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83rUW+p7kjCw for ; Mon, 5 Mar 2012 14:00:58 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8636D21F8850 for ; Mon, 5 Mar 2012 14:00:58 -0800 (PST) Received: from dn522197.sunet ([10.33.5.39]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S4fxh-00037M-AU; Mon, 05 Mar 2012 14:00:57 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2C987A54@DLEE10.ent.ti.com> Date: Mon, 5 Mar 2012 14:00:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AA5AC69E924D149A8D63EB676AF87DB2C987A54@DLEE10.ent.ti.com> To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: "roll@ietf.org" Subject: Re: [Roll] Roll Digest, Vol 50, Issue 4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 22:00:59 -0000 You are absolutely right, my edits to -05 were rushed to make the = deadline; I'll be sure to put this clarification in my short = presentation (assuming I have a slot) and in a -06 post-IETF. Phil On Mar 5, 2012, at 1:42 PM, Reddy, Joseph wrote: >=20 > Hi Phil, >=20 > I believe the Rank should be computed as the path cost from the best = parent and not worst one. >=20 > We had this discussion on this topic previously on the = reflector....see > http://www.ietf.org/mail-archive/web/roll/current/msg06077.html >=20 > -Regards, Joseph >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Sun, 4 Mar 2012 15:47:23 -0800 > From: Philip Levis > To: Peter Burnett > Cc: roll@ietf.org > Subject: Re: [Roll] MRHOF Objective function (using ETX metric) > Message-ID: <4538B777-EA8C-46F0-BEAF-ABFAC296EAAF@cs.stanford.edu> > Content-Type: text/plain; charset=3Dus-ascii >=20 >=20 > On Mar 1, 2012, at 8:42 AM, Peter Burnett wrote: >=20 >> Another related difficulty for me is that section 3.3 seems to say = that the rank of a non-root node is the path cost through the worst = parent. However 3.4 says that the advertised rank is the path cost = through the preferred parent, the min_path_cost. How can these be = reconciled? >=20 > The first is correct. I'm fixing this in -05, thanks for catching it. >=20 > Phil >=20 >=20 >=20 From prvs=4041738a5=mukul@uwm.edu Mon Mar 5 14:13:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A057D21F87C1 for ; Mon, 5 Mar 2012 14:13:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShQQPX6ewwUC for ; Mon, 5 Mar 2012 14:13:21 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1321F87C0 for ; Mon, 5 Mar 2012 14:13:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFg5VU9/AAAB/2dsb2JhbAA5CoU0sjcBAQUjVgwPEQQBAQMCDRkCHjMIBhMZh24LpjSEPYRJiQeBL4hjhSeBFgSHAYFPjG6MBoQMgwKBNQc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7913F2B3ED4; Mon, 5 Mar 2012 16:13:18 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGfq0jHVa1C6; Mon, 5 Mar 2012 16:13:18 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 16D242B3EC2; Mon, 5 Mar 2012 16:13:18 -0600 (CST) Date: Mon, 5 Mar 2012 16:13:18 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1364394120.1477518.1330985597987.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <21905.1330979747@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - FF3.0 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 22:13:22 -0000 [Michael] >When it's a multicast address, is the idea that all stations which are member of that group respond? Or [Mukul] Any node that belongs to the multicast group and receives the DIO. There is no guarantee that all nodes in the multicast group would received the DIO. [Michael] >Also, a question about: "upto four source" why the number four? [Mukul] Because we have just 2 bits available for the purpose. Redundant source routes are mighty useful in many scenarios. [Michael] >How does a sender know how to send time-critical messages to the target if the target doesn't send back DROs: "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver time- critical application data to the target(s)." I'm guessing that the info is piggy backed into the RPL message itself, using these Data Options. Do we need to specify what is in these Data Options? (My opinion... it's an IPv6 Upper-Layer Protocol...) [Mukul] Yes, the data is piggy backed on RPL message itself via Data Options. I think we need not specify whats inside the data options. RPL would simply pass the contents to the higher layer. Its the higher layer's headache to interpret this information. [Michael] re the H-flag: The origin sets this flag to 1 if it desires hop-by-hop routes. The origin sets this flag to 0 if it desires source routes. It might be worth giving an example of each. I think I'm not sure what a hop-by-hop route is, exactly. Your glossary says: Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route. but I think that I don't understand what's going on. I'm not sure I know how to use this information on the origin node. Well... wait... is this only useful for storing nodes? maybe I need to read: I-D.ietf-6man-rpl-option , which I haven't yet. [Mukul] Indeed the hop-by-hop route would require the use of RPL option to specify the RPLInstanceID of the route. A router would use: 1) RPLInstanceID 2) Source IPv6 Address (since RPLInstanceID will be a local value) 3) Destination IPv6 Address to identify the next hop for the packet. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "roll" Cc: "Mukul Goyal" Sent: Monday, March 5, 2012 2:35:47 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-08.txt >>>>> "Mukul" == Mukul Goyal writes: Mukul> Hi all, Mukul> The main changes in P2P-RPL-08 over the previous version are Mukul> as follows: Mukul> 1) allow P2P-RPL to discover routes to multiple targets at Mukul> the same time: - The target address in P2P-RDO can specify Mukul> either a unicast address or a multicast one. When it's a multicast address, is the idea that all stations which are member of that group respond? Or Also, a question about: "upto four source" why the number four? How does a sender know how to send time-critical messages to the target if the target doesn't send back DROs: "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver time- critical application data to the target(s)." I'm guessing that the info is piggy backed into the RPL message itself, using these Data Options. Do we need to specify what is in these Data Options? (My opinion... it's an IPv6 Upper-Layer Protocol...) re the H-flag: The origin sets this flag to 1 if it desires hop-by-hop routes. The origin sets this flag to 0 if it desires source routes. It might be worth giving an example of each. I think I'm not sure what a hop-by-hop route is, exactly. Your glossary says: Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route. but I think that I don't understand what's going on. I'm not sure I know how to use this information on the origin node. Well... wait... is this only useful for storing nodes? maybe I need to read: I-D.ietf-6man-rpl-option , which I haven't yet. -- ] 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 adrian@olddog.co.uk Tue Mar 6 03:42:35 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5808321F88DF for ; Tue, 6 Mar 2012 03:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuRPsLmKPknm for ; Tue, 6 Mar 2012 03:42:34 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49021F88E1 for ; Tue, 6 Mar 2012 03:42:34 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q26BgOIv020789; Tue, 6 Mar 2012 11:42:24 GMT Received: from 950129200 ([90.84.146.254]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q26BgBej020653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Mar 2012 11:42:22 GMT From: "Adrian Farrel" To: "'Philip Levis'" Date: Tue, 6 Mar 2012 11:42:11 -0000 Message-ID: <02d401ccfb8e$32351850$969f48f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz7Gc9Ih/XPZrdqQsyqKZciTJk8UA== Content-Language: en-gb Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:42:35 -0000 Good job, thanks! I'll sort out the next step for the document. Adrian > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: 04 March 2012 23:51 > To: adrian@olddog.co.uk > Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org; roll@ietf.org > Subject: Re: AD review of draft-ietf-roll-minrank-hysteresis-of-04 > > > On Sep 27, 2011, at 7:59 AM, Adrian Farrel wrote: > > > Hi, > > > > Here is my AD review of your draft. I was hoping to get away with a few > > typos we could punt to a later stage, but I think there are a couple of > > issues we need to iron out with a quick new revision. > > > > I have put the I-D into "revised I-D needed" state and will issue the IETF Last > > Call when I see a new revision. > > > > Thanks, > > Adrian > > > > First off, I apologize for how long this took. Om and I miscommunicated; he > thought I was handling the revision and I thought he was. > > > > --- > > > > In progressing the OG0 draft we learnt that there was no clear > > understanding of what an objective function is. I think your draft does > > a good job at explaining, but in an attempt to learn from the past, can > > you please have a look at the text that got added to the OF0 document to > > see whether anything can be added here. > > > > --- > > > > Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not > > MROFH? > > I've changed the title to reflect the acronym. > > > > > --- > > > > During the review process for OF0 we ended up adding the following > > paragraph. Would you consider adding something similar to make this > > point crystal clear? > > > > The RPL specification [I-D.ietf-roll-rpl] requires the use of a > > common OF by all nodes in a network. The possible use of multiple > > OFs with a single network is for further study. > > > Added. > > > > > --- > > > > Section 2... > > > > This document introduces two terms: > > > > There are three terms! > > > Or 11 terms! ;) Corrected. > > > > > > > --- > > > > Section 5.1 > > > > Can you add a statement on default values? > > > There's an earlier section with default values; this section now references it. > > > > > Can you also have a look at Section 7 of the OF0 draft. This gives a > > more substantive approach to describing manageability. > > I've fleshed out the section accordingly, following the model in OF0. > > > > > > --- > > > > 7. IANA Considerations > > > > You need to point the IANA at the specific registry. This would be the > > "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for > > Low Power and Lossy Networks (RPL)" registry. > > > > This specification requires an allocated OCP. A value of 1 is > > requested. > > > > s/requested/suggested/ > > > Fixed. > > > > > --- > > > > 8. Security Considerations > > > > Security considerations to be developed in accordance to the output > > of the WG. > > > > I don't think we will get this past the Security directorate :-) > > > > How about... > > > > This specification makes simple extensions to RPL and so is > > vulnerable to and benefits from the security issues and mechanisms > > described in [I-D.ietf-roll-rpl] and > > [I-D.ietf-roll-security-framework]. This document does not introduce > > new flows or new messages, thus requires no specific mitigation for > > new threats. > > > > MRHOF depends on information exchanged in a number RPL protocol > > elements. If those elements were compromised, then an implementation > > of MRHOF might generate the wrong path for a packet, resulting in it > > being misrouted. Therefore, deployments are RECOMMENDED to use RPL > > security mechanisms if there is a risk that routing information might > > be modified or spoofed. > > > > Added. > > Phil= From B06063@freescale.com Tue Mar 6 04:09:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D12521F890B for ; Tue, 6 Mar 2012 04:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doVsC5aCtUsp for ; Tue, 6 Mar 2012 04:09:27 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF7F21F8916 for ; Tue, 6 Mar 2012 04:09:26 -0800 (PST) Received: from mail178-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 6 Mar 2012 12:09:25 +0000 Received: from mail178-va3 (localhost [127.0.0.1]) by mail178-va3-R.bigfish.com (Postfix) with ESMTP id 345B92C015F; Tue, 6 Mar 2012 12:09:25 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz9371I542M1432N98dK148cMzz1202hzz1033IL8275dhz2dh2a8h668h839h8e2h8e3h944hbe9k) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3 (MessageSwitch) id 1331035762225030_21096; Tue, 6 Mar 2012 12:09:22 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.241]) by mail178-va3.bigfish.com (Postfix) with ESMTP id 07B1C32009A; Tue, 6 Mar 2012 12:09:22 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 6 Mar 2012 12:09:19 +0000 Received: from 039-SN2MPN1-021.039d.mgd.msft.net ([169.254.1.196]) by 039-SN1MMR1-001.039d.mgd.msft.net ([10.84.1.13]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 06:09:18 -0600 From: Costin Michaela Catalina-B06063 To: Philip Levis Thread-Topic: [Roll] MRHOF Objective function (using ETX metric) Thread-Index: Aczwgf8SiO9dz4XLQYG0i+MzdpDhPgKETlQAAD9AZHA= Date: Tue, 6 Mar 2012 12:09:18 +0000 Message-ID: <6B6AF64303C21343BF760595E1DF15FF04C3B9@039-SN2MPN1-021.039d.mgd.msft.net> References: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> <77887DB3-230D-40AC-A774-4F0A237FF256@cs.stanford.edu> In-Reply-To: <77887DB3-230D-40AC-A774-4F0A237FF256@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.171.73.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com Cc: "roll@ietf.org" Subject: Re: [Roll] MRHOF Objective function (using ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Mar 2012 12:09:27 -0000 Hello Phil, Thanks for updating the draft! Now, regarding the PARENT_SWITCH_THRESHOLD parameter: 1. in chapter 5 the PARENT_SWITCH_THRESHOLD is defined as the difference = between two metrics 2. in chapter 3.2 the PARENT_SWITCH_THRESHOLD parameter is seen as a diff= erence between two path costs. We need to clarify how we are going to use it based on the method used for = computing the rank (whether we use the best parent or worst parent in rank = calculation). Catalina Costin =20 -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: Monday, March 05, 2012 1:46 AM To: Costin Michaela Catalina-B06063 Cc: roll@ietf.org Subject: Re: [Roll] MRHOF Objective function (using ETX metric) On Feb 21, 2012, at 2:17 AM, Costin Michaela Catalina-B06063 wrote: > Hello guys, > =20 > While reading MRHOF draft (for ETX metric), I identified some discrepanc= ies between the RPL and the MRHOF draft: > * The rank of a DODAG root according to ROLL RPL draft is MinHopR= ankIncrease (default value =3D 0x100). According to MRHOF, the rank of the= DODAG root is MIN_PATH_COST (default value =3D 0) This is an error -- the RPL specification is correct. > * The algorithm for computing node rank is not clearly described = in the MRHOF draft. Once the path cost for all neighbors is computed and th= e preferred parent is selected, the node rank is calculated just by adding = MinHopRankIncrease to the smallest path cost (to the preferred parent path = cost)? No -- it is rank calculated the preferred parent path cost. MinHopRankIncre= ase sets a minimum value it must increase by. So if the node's Rank is less= than its worst parent + MinHopRankIncrease, then its Rank is worst parent = + MinHopRankIncrease. I'm clearing these things up in -05; I greatly appreciate the pointers and = questions. Phil From internet-drafts@ietf.org Tue Mar 6 04:38:32 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341AF21F88D3; Tue, 6 Mar 2012 04:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR7Pj86HX68r; Tue, 6 Mar 2012 04:38:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4821F88BB; Tue, 6 Mar 2012 04:38:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306123804.2408.34775.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 04:38:04 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Mar 2012 12:38:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-09.txt Pages : 30 Date : 2012-03-06 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meets specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-09.txt From prvs=405d9ad7e=mukul@uwm.edu Tue Mar 6 04:43:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ADD21F88C8 for ; Tue, 6 Mar 2012 04:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Bh0-MdpbfX for ; Tue, 6 Mar 2012 04:43:41 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 016C321F88C0 for ; Tue, 6 Mar 2012 04:43:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPUFVk9/AAAB/2dsb2JhbABDhUGyOAEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJh34LnzyOD4klgR+BL44ZgRYEiFKMbZAWgwKBNRc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 525DB12E3BC for ; Tue, 6 Mar 2012 06:43:40 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXurDl98bIV3 for ; Tue, 6 Mar 2012 06:43:39 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F0DEA12E3BD for ; Tue, 6 Mar 2012 06:43:39 -0600 (CST) Date: Tue, 6 Mar 2012 06:43:39 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <2072738218.1483097.1331037819900.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120306123804.2408.34775.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - FF3.0 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Mar 2012 12:43:41 -0000 A minor revision over the previous version made necessary due to changes in upcoming SRH RFC. SRH no longer specifies an RPLInstanceID. So, routers on a source route, discovered using P2P-RPL, need not remember the RPLInstanceID (of the temporary DAG used for route discovery) either. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Tuesday, March 6, 2012 6:38:04 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-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 : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-09.txt Pages : 30 Date : 2012-03-06 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meets specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-09.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Mar 6 08:05:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9511221F8618 for ; Tue, 6 Mar 2012 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAxD1OWv6k92 for ; Tue, 6 Mar 2012 08:05:00 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 304E121F860E for ; Tue, 6 Mar 2012 08:05:00 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S4wsl-0000Az-0Q; Tue, 06 Mar 2012 08:04:59 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6B6AF64303C21343BF760595E1DF15FF04C3B9@039-SN2MPN1-021.039d.mgd.msft.net> Date: Tue, 6 Mar 2012 08:05:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B6AF64303C21343BF760595E1DF15FF04609A@039-SN2MPN1-021.039d.mgd.msft.net> <77887DB3-230D-40AC-A774-4F0A237FF256@cs.stanford.edu> <6B6AF64303C21343BF760595E1DF15FF04C3B9@039-SN2MPN1-021.039d.mgd.msft.net> To: Costin Michaela Catalina-B06063 X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: "roll@ietf.org" Subject: Re: [Roll] MRHOF Objective function (using ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Mar 2012 16:05:00 -0000 On Mar 6, 2012, at 4:09 AM, Costin Michaela Catalina-B06063 wrote: > Hello Phil, >=20 > Thanks for updating the draft! >=20 > Now, regarding the PARENT_SWITCH_THRESHOLD parameter: > 1. in chapter 5 the PARENT_SWITCH_THRESHOLD is defined as the = difference between two metrics > 2. in chapter 3.2 the PARENT_SWITCH_THRESHOLD parameter is seen as a = difference between two path costs. >=20 > We need to clarify how we are going to use it based on the method used = for computing the rank (whether we use the best parent or worst parent = in rank calculation). >=20 >=20 > Catalina Costin Catalina -- thanks for the catch. In making the edits for -05 it became = clear to me that the document needs a good editing pass to clean up = inconsistencies like these that have creeped in (as well as a few = inconsistencies with the RPL specification). I'll add this to the list = for a -06. Phil= From pal@cs.stanford.edu Tue Mar 6 16:18:58 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6FD21E801F for ; Tue, 6 Mar 2012 16:18:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qaJDVhJlu5m for ; Tue, 6 Mar 2012 16:18:58 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2302E21E800F for ; Tue, 6 Mar 2012 16:18:58 -0800 (PST) Received: from 23-24-194-2-static.hfc.comcastbusiness.net ([23.24.194.2] helo=[192.168.1.135]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S54an-0003tI-EQ; Tue, 06 Mar 2012 16:18:57 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 6 Mar 2012 16:18:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2CBCBB35-A2C5-4FAA-85F2-A1894E569725@cs.stanford.edu> References: <2AA5AC69E924D149A8D63EB676AF87DB2C987A54@DLEE10.ent.ti.com> To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Cc: "roll@ietf.org" Subject: Re: [Roll] Roll Digest, Vol 50, Issue 4 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 00:18:58 -0000 On Mar 5, 2012, at 2:00 PM, Philip Levis wrote: > You are absolutely right, my edits to -05 were rushed to make the = deadline; I'll be sure to put this clarification in my short = presentation (assuming I have a slot) and in a -06 post-IETF. >=20 > Phil >=20 > On Mar 5, 2012, at 1:42 PM, Reddy, Joseph wrote: >=20 >>=20 >> Hi Phil, >>=20 >> I believe the Rank should be computed as the path cost from the best = parent and not worst one. >>=20 >> We had this discussion on this topic previously on the = reflector....see >> http://www.ietf.org/mail-archive/web/roll/current/msg06077.html >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 2 >> Date: Sun, 4 Mar 2012 15:47:23 -0800 >> From: Philip Levis >> To: Peter Burnett >> Cc: roll@ietf.org >> Subject: Re: [Roll] MRHOF Objective function (using ETX metric) >> Message-ID: <4538B777-EA8C-46F0-BEAF-ABFAC296EAAF@cs.stanford.edu> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> On Mar 1, 2012, at 8:42 AM, Peter Burnett wrote: >>=20 >>> Another related difficulty for me is that section 3.3 seems to say = that the rank of a non-root node is the path cost through the worst = parent. However 3.4 says that the advertised rank is the path cost = through the preferred parent, the min_path_cost. How can these be = reconciled? >>=20 >> The first is correct. I'm fixing this in -05, thanks for catching it. >>=20 >> Phil After going back through the email thread and the RPL specification = (8.2.1), I've updated MRHOF to say: "A node sets its Rank to the maximum of three values: 1. The Rank associated with the path through the preferred parent 2. The Rank of the member of the parent set with the highest advertised Rank plus one 3. The Rank of the path through the member of the parent set with the highest path cost, minus MaxRankIncrease The first case is the Rank associated with the path through the preferred parent. The second case covers requirement 4 of Rank advertisements in Section 8.2.1 of [I-D.ietf-roll-rpl]. The third case ensures that a node does not advertise a Rank which then precludes it from using members of its parent set." "Rank associated with the path" means "Rank calculated from the metrics = associated with the path." I'm submitting an updated -06 that incorporates the comments from the = WG. PARENT_SWITCH_THRESHOLD is defined in terms of cost, not metric, and = the recommended parameters have been changed accordingly. Phil= From internet-drafts@ietf.org Tue Mar 6 16:20:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C121F8659; Tue, 6 Mar 2012 16:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahs32A2wKnSy; Tue, 6 Mar 2012 16:20:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5921F8653; Tue, 6 Mar 2012 16:20:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307002048.12556.36609.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 16:20:48 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 00:20:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : The Minimum Rank with Hysteresis Objective Function Author(s) : Omprakash Gnawali Philip Levis Filename : draft-ietf-roll-minrank-hysteresis-of-06.txt Pages : 13 Date : 2012-03-06 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0= 6.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-06= .txt From internet-drafts@ietf.org Tue Mar 6 21:49:33 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794F421F8545; Tue, 6 Mar 2012 21:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu7+m1J6e6Nv; Tue, 6 Mar 2012 21:49:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4621F8534; Tue, 6 Mar 2012 21:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307054913.20046.96662.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 21:49:13 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 05:49:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-04.txt Pages : 19 Date : 2012-03-06 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-04.txt From prvs=406e493cc=mukul@uwm.edu Tue Mar 6 21:55:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A561E21E8066 for ; Tue, 6 Mar 2012 21:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awyl7womAKgy for ; Tue, 6 Mar 2012 21:55:22 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9662721E8077 for ; Tue, 6 Mar 2012 21:55:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACP4Vk9/AAAB/2dsb2JhbABDhTSyWgEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJh34LmUKOD4kgiQeBL44rgRYEiFKMbZAWgwI Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E1E871FD014 for ; Tue, 6 Mar 2012 23:55:00 -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 NgB3lalNtB1c for ; Tue, 6 Mar 2012 23:55:00 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 959CE1FD013 for ; Tue, 6 Mar 2012 23:55:00 -0600 (CST) Date: Tue, 6 Mar 2012 23:55:00 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1179546956.1498580.1331099700400.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120307054913.20046.96662.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 05:55:22 -0000 The main modification is that a Measurement Object message now has RPL routing domain as its scope (rather than an RPL Instance). This change is in accordance with the corresponding change in upcoming SRH RFC. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Tuesday, March 6, 2012 11:49:13 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-04.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 : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-04.txt Pages : 19 Date : 2012-03-06 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-04.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Wed Mar 7 03:39:04 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB11C21F87BE for ; Wed, 7 Mar 2012 03:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWO9Y9ti43H5 for ; Wed, 7 Mar 2012 03:38:59 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFEAA21F87A8 for ; Wed, 7 Mar 2012 03:38:57 -0800 (PST) Received: by werb10 with SMTP id b10so4842784wer.31 for ; Wed, 07 Mar 2012 03:38:56 -0800 (PST) Received: by 10.180.78.130 with SMTP id b2mr25705179wix.1.1331120336719; Wed, 07 Mar 2012 03:38:56 -0800 (PST) Received: from [192.168.0.178] ([41.6.248.185]) by mx.google.com with ESMTPS id cc3sm93937924wib.7.2012.03.07.03.38.50 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 03:38:56 -0800 (PST) Message-ID: <4F5748B6.6030503@exegin.com> Date: Wed, 07 Mar 2012 13:38:30 +0200 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlX0Tz6lz6yeYrzOWD+0dftxa91ilAhAxKEJrcSCq6fJhv/NVHPNPB4QrthUIh5ZduCnqx4 Subject: [Roll] MRHOF draft-06 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 11:39:04 -0000 Below are some comments and questions on a few areas in the latest MRHOF draft that seem a little confusing. In section 3.3. " MRHOF uses this Rank value to compute the Rank it associates with the path through each member of the parent set. The Rank associated with a path through a member of the parent set is the maximum of the corresponding calculated Rank value from above and that node's advertised Rank plus MinHopRankIncrease. " Which of the following formulae match the above description? PathRank = RankValue + AdvRank + MinHopRankIncrease PathRank = MAX(RankValue, AdvRank) + MinHopRankIncrease PathRank = MAX(RankValue, (AdvRank + MinHopRankIncrease)) Where: PathRank is the Rank associated with a path through a member of the parent set AdvRank is a node's advertised Rank RankValue is the Rank value taken from Table 1 in the draft. Perhaps adding something like one of the above formulae would help in describing exactly how a node arrives at its own Rank? In section 3.3. " A node sets its Rank to the maximum of three values: ... " Could the above be simplified/removed by just saying that members in the parent set meet the following condition: ( DAGRank(PathRank) < DAGRank(thisNode.AdvRank) ) Where: thisNode.AdvRank is a joining node's current Rank (starting at infinity before having joined a DODAG). The above condition allows a parent's path Rank to vary up to an upper bound implicitly set by MinHopRankIncrease, before a node might exclude that parent from the set and possibly choose another preferred parent. In section 3.4. " This value is the path cost of the member of the parent set with the highest path cost. Thus, while cur_min_path_cost is the cost through the preferred parent, a node advertises the highest cost path from the node to the root through a member of the parent set. The value of the highest cost path is carried in the metric container corresponding to the selected metric when DIO messages are sent. " It's quite strange that the advertised path cost could be one associated with a member in the parent set that isn't currently in the path to the root. In my view, this could quite easily distort a DODAG away from its optimum, because nodes may advertised costs that are more pessimistic than need be. Surely once a node has selected a preferred parent, it should advertise the cost of that path through that parent, since that is the real and optimal cost to the root. Reading the section further, MRHOF with ETX is exclude from the above requirement. Was that intentional? Regards Dario From jpv@cisco.com Wed Mar 7 05:15:19 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D221F869A for ; Wed, 7 Mar 2012 05:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.078 X-Spam-Level: X-Spam-Status: No, score=-110.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAXLW7qTfeS3 for ; Wed, 7 Mar 2012 05:15:18 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 950B321F85A3 for ; Wed, 7 Mar 2012 05:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3702; q=dns/txt; s=iport; t=1331126113; x=1332335713; h=from:subject:date:message-id:to:mime-version; bh=ej9BZyouiwO7jtYFnkZQAq9OTObyydBhHGGO2iC/q+4=; b=NAtfJXpYT5/r8RGfZ4yjeEXMYtm1L1r1w9RSflgkFIDnAC6dgSJGXzDw Idg/owcpqZN0+igSzBkQiFQ58eaeprJRHaBrx7bUqrqP30MGtVzXTKypR mclPLCBWPP9CLT6xwMwaYtF9mICg6Rw/mwC/LEN7Vi4LG6H4ea5C7t9zK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFleV0+Q/khN/2dsb2JhbABDrAgBiQ2BB4IPFAFUByqBHzWHZguZC4EnAZ8mkAxjBJVBkBeCZA X-IronPort-AV: E=Sophos;i="4.73,545,1325462400"; d="scan'208,217";a="67891636" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 13:15:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27DFC6X008418 for ; Wed, 7 Mar 2012 13:15: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.4675); Wed, 7 Mar 2012 14:15:12 +0100 Received: from ams-jvasseur-8918.cisco.com ([10.61.82.186]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 14:15:12 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_0AC4F6A5-D639-4356-B27E-11DAFA75B30E" Date: Wed, 7 Mar 2012 14:15:12 +0100 Message-Id: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 07 Mar 2012 13:15:12.0330 (UTC) FILETIME=[5402CAA0:01CCFC64] Subject: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 13:15:20 -0000 --Apple-Mail=_0AC4F6A5-D639-4356-B27E-11DAFA75B30E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, The two documents draft-ietf-roll-p2p-measurement and = draft-ietf-roll-p2p-rpl have been discussed on the mailing list and = during=20 WG meetings for some time, there several implementations that are now = stable, and the authors believe that the documents are ready for WG Last Call. Thus, this starts a Working Group Last Call on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Furthermore, an interoperability was carried out last month with INRIA's = implementation against Sigma Design's implementation. The report can be found: = http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf Experiments with P2P-RPL have also taken place on the Senslab testbed = gathering boards based on MSP430 and 802.15.4 at 2.4GHz:=20 http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf The WG Last Call will last 3-weeks and will end on March 29, at noon ET. = Please send your comments on the mailing list and copy=20 the authors. Thanks. JP and Michael. =20= --Apple-Mail=_0AC4F6A5-D639-4356-B27E-11DAFA75B30E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

The two documents = draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been = discussed on the mailing list and during 
WG = meetings for some time, there several implementations that are = now stable, and the authors believe that the documents = are
ready for WG Last Call.

Thus, = this starts a Working Group Last Call on:
* = draft-ietf-roll-p2p-measurement-04
and
*= = draft-ietf-roll-p2p-rpl-09

Furthermore,&n= bsp;an interoperability was carried out last month = with INRIA's implementation against Sigma Design's = implementation.
MRHOF uses this Rank value to compute the Rank it associates with = the > path through each member of the parent set. The Rank associated = with > a path through a member of the parent set is the maximum of the > corresponding calculated Rank value from above and that node's > advertised Rank plus MinHopRankIncrease. > " >=20 > Which of the following formulae match the above description? > PathRank =3D RankValue + AdvRank + MinHopRankIncrease > PathRank =3D MAX(RankValue, AdvRank) + MinHopRankIncrease > PathRank =3D MAX(RankValue, (AdvRank + MinHopRankIncrease)) The last one. I'll clarify in the next revision. I appreciate your = pointing out the lack of clarity in the current text. > Where: > PathRank is the Rank associated with a path through a member of the = parent set > AdvRank is a node's advertised Rank > RankValue is the Rank value taken from Table 1 in the draft. >=20 > Perhaps adding something like one of the above formulae would help in = describing exactly how a node arrives at its own Rank? >=20 > In section 3.3. " > A node sets its Rank to the maximum of three values: > ... > " > Could the above be simplified/removed by just saying that members in = the parent set meet the following condition: > ( DAGRank(PathRank) < DAGRank(thisNode.AdvRank) ) I don't think so. Among other things, the node decides on its advertised = rank based on the parent set. Or are you saying that the parent set at = execution i should be affected by the node's advertised rank at = execution i-1? Or that a node picks a desired DAGRank and then sets its = parent set accordingly? The reason this part of the specification becomes complicated is because = it's possible for Rank and metric values to diverge due to = MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This = corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path = whose links have an ETX of 1, then the metric value will be 512 but the = Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't = difficult, but it starts to be weird on metrics like Node Energy. Hence = the recommendation at the end about the relationship of = MinHopRankIncrease and metrics. > Where: > thisNode.AdvRank is a joining node's current Rank (starting at = infinity before having joined a DODAG). > The above condition allows a parent's path Rank to vary up to an upper = bound implicitly set by MinHopRankIncrease, before a node might exclude = that parent from the set and possibly choose another preferred parent. >=20 > In section 3.4. " > This value is the path cost of the member = of > the parent set with the highest path cost. Thus, while > cur_min_path_cost is the cost through the preferred parent, a node > advertises the highest cost path from the node to the root through a > member of the parent set. The value of the highest cost path is > carried in the metric container corresponding to the selected metric > when DIO messages are sent. > " > It's quite strange that the advertised path cost could be one = associated with a member in the parent set that isn't currently in the = path to the root. In my view, this could quite easily distort a DODAG = away from its optimum, because nodes may advertised costs that are more = pessimistic than need be. Surely once a node has selected a preferred = parent, it should advertise the cost of that path through that parent, = since that is the real and optimal cost to the root. There is a good reason for this, which is in line with the RPL = specification: MaxRankIncrease. MaxRankIncrease creates a tension = between advertising the Rank associated with the path through the = preferred parent and requiring a new DODAG iteration. If a node = advertises the Rank associated with the path through its preferred = parent, but the next best member of the parent set is more than = MaxRankIncrease greater in path length, then if the preferred parent = fails the node can no longer route. So a node can advertise a = conservative Rank which gives it flexibility in selection of a preferred = parent in case of failure.=20 There is also a tension between the size of the parent set and how = conservative the advertised Rank is. For example, let's say = MaxRankIncrease is very large, such that nodes can move down in the = DODAG very freely, depending on the data path to detect possible routing = loops. Then a node can maintain a parent set of size 1, its preferred = parent, and advertise a very accurate Rank value. > Reading the section further, MRHOF with ETX is exclude from the above = requirement. Was that intentional? No -- can you point me to the exact text which leads you to this = conclusion, so I can fix it? Thank you for your comments -- very helpful! Phil= From jpv@cisco.com Wed Mar 7 09:58:12 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF9B21F850B for ; Wed, 7 Mar 2012 09:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.547 X-Spam-Level: X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_LEO_LINE03e=0.635, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rvrDuDkCTgP for ; Wed, 7 Mar 2012 09:58:11 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B0DB221F84FE for ; Wed, 7 Mar 2012 09:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=18513; q=dns/txt; s=iport; t=1331143090; x=1332352690; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=WqfaaC79BRwAkj/Aorqf1J35ZeBitZ93D1bYz4zZbuU=; b=XPh3AzWRnuo0MXxCeGnv4paTFZ/sV2EMx/ud/yXWFYOQg/BfV3w1Ju/C HZifVT+2ySusDbECF9FzbrcnRWWrH30b2u1Ad1lwSUvd6ZFo1gB3bDKJK d8zW/nD8Z/vtGmXhT4JlFfGl3Iz2xJRG9I/6l+9vV5fcQuMAyoadj/dx0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACShV0+Q/khR/2dsb2JhbABEgkWpSQGJDoEHggoBAQECAQEBAQEPAVsLBQsvFwsnMAYTCRmHYQULmkQBjS6RbJAMYwSVQZAXgmSBUwQD X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208,217";a="67923264" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 17:58:08 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q27Hw82R024569; Wed, 7 Mar 2012 17:58:08 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 18:58:08 +0100 Received: from ams-jvasseur-8918.cisco.com ([10.61.82.186]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 18:58:07 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5CDA400-C33C-4840-9D9B-B9CB626747DF" From: JP Vasseur In-Reply-To: Date: Wed, 7 Mar 2012 18:58:07 +0100 Message-Id: <66E3C128-84D0-4850-BA7A-0EEBF5D15ADC@cisco.com> References: To: roll WG X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 07 Mar 2012 17:58:07.0998 (UTC) FILETIME=[DA4C29E0:01CCFC8B] Cc: Michael Richardson , David Culler Subject: [Roll] Reminder -- Re: Reminder: important dates, slots request for Paris' meeting, draft agenda, ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 17:58:12 -0000 --Apple-Mail=_E5CDA400-C33C-4840-9D9B-B9CB626747DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you haven't done so yet, please send your slot request by tomorrow. Many thanks. JP. On Feb 25, 2012, at 3:31 AM, JP Vasseur wrote: > Dear all, >=20 > As a reminder, here are the important dates: >=20 > IETF 83: March 25-30, 2012, Paris, France > Download .ICS file of important dates for IETF 83 > Subscribe to important dates calendar for IETF 83: = http://www.ietf.org/meeting/83/IETF-83-important-dates.ics >=20 > 2011-12-19 (Week of): IETF Online Registration opens. > 2011-12-19 (Monday): Working Group and BOF scheduling begins. To = request a Working Group session, use the IETF Meeting Session Request = Tool. > 2012-01-30 (Monday): Cutoff date for requests to schedule Working = Group meetings at 17:00 PT (UTC -8). To request a Working Group session, = use the IETF Meeting Session Request Tool. > 2012-02-13 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (UTC -8). To request a BOF, please see = instructions on Requesting a BOF. > 2012-02-16 (Thursday): Cutoff date for Area Directors to approve BOFs = at 17:00 PT (UTC -8). > 2012-02-23 (Thursday): Preliminary agenda published for comment. > 2012-02-27 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (UTC -8). > 2012-02-27 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (UTC -8). > 2012-03-02 (Friday): Final agenda to be published. > 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool. > 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 = PT (UTC -7), upload using IETF ID Submission Tool. > 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT = (UTC -7), upload using IETF Meeting Materials Management Tool. > 2012-03-16 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (UTC -7). > 2012-03-19 (Monday): Revised Working Group agendas due by 17:00 PT = (UTC -7), upload using IETF Meeting Materials Management Tool. > 2012-03-19 (Monday): Registration cancellation cut-off at 17:00 PT = (UTC -7). > 2012-03-23 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local meeting time. > 2012-03-25 - 2012-03-30: 83rd IETF Meeting in Paris, France. > 2012-04-27 (Friday): Proceedings submission cutoff date by 17:00 PT = (UTC -7), upload using IETF Meeting Materials Management Tool. > 2012-05-16 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (UTC -7), upload usingIETF Meeting Materials Management = Tool. >=20 > Draft agenda: >=20 > WEDNESDAY, March 28, 2012 >=20 >=20 > 1130-1300 Break - Hall Maillot A > 1300-1500 Afternoon Session I > 252B APP hybi=09 > BiDirectional or Server-Initiated HTTP WG = drafts: tar|pdf > 243 APP repute=09 > Reputation Services WG drafts: tar|pdf > 253 INT netext=09 > Network-Based Mobility Extensions WG drafts: = tar|pdf > 252A RAI ecrit=09 > Emergency Context Resolution with Internet = Technologies WG drafts: tar|pdf > 242AB RTG karp=09 > Keying and Authentication for Routing = Protocols WG drafts: tar|pdf > Maillot RTG nvo3=09 > Overlay Networking BOF drafts: tar|pdf > 241 RTG roll=09 > Routing Over Low power and Lossy networks WG = drafts: tar|pdf > 212/213 SEC nea=09 > Network Endpoint Assessment WG drafts: = tar|pdf >=20 > Please let us know no later than March 3 if you would like to request = a slot for the ROLL Working Group meeting. >=20 > Thanks. >=20 > JP and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_E5CDA400-C33C-4840-9D9B-B9CB626747DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If = you haven't done so yet, please send your slot request by = tomorrow.

Many = thanks.

JP.

On Feb 25, = 2012, at 3:31 AM, JP Vasseur wrote:

Dear all,

As = a reminder, here are the important dates:

IETF 83: March 25-30, 2012, = Paris, France

Download .ICS file of important dates for IETF 83
Subscribe to = important dates calendar for IETF 83: http:/= /www.ietf.org/meeting/83/IETF-83-important-dates.ics

    = IETF Meeting Session Request Tool.
  • 2012-01-30 = (Monday): Cutoff date for requests to schedule Working = Group meetings at 17:00 PT (UTC -8). To request a Working Group session, = use the = IETF Meeting Session Request Tool.
  • 2012-02-13 = (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (UTC -8). To request a BOF, please see = instructions on Requesting a = BOF.
  • 2012-02-16 (Thursday): Cutoff = date for Area Directors to approve BOFs at 17:00 PT (UTC = -8).
  • 2012-02-23 (Thursday): Preliminary = agenda published for comment.
  • 2012-02-27 = (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (UTC -8).
  • 2012-02-27 = (Monday): Working Group Chair approval for initial = document (Version -00) submissions appreciated by 17:00 PT (UTC = -8).
  • 2012-03-02 (Friday): Final agenda to = be published.
  • 2012-03-05 = (Monday): Internet Draft Cut-off for initial document = (-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission = Tool.
  • 2012-03-12 (Monday): Internet = Draft final submission cut-off by 17:00 PT (UTC -7), upload = using IETF ID = Submission Tool.
  • 2012-03-14 = (Wednesday): Draft Working Group agendas due by 17:00 PT = (UTC -7), upload using IETF = Meeting Materials Management Tool.
  • 2012-03-16 = (Friday): Early Bird registration and payment cut-off at = 17:00 PT (UTC -7).
  • 2012-03-19 = (Monday): Revised Working Group agendas due by 17:00 PT = (UTC -7), upload using IETF = Meeting Materials Management Tool.
  • 2012-03-19 = (Monday): Registration cancellation cut-off at 17:00 PT = (UTC -7).
  • 2012-03-23 (Friday): Final = Pre-Registration and Pre-Payment cut-off at 17:00 local meeting = time.
  • 2012-03-25 - 2012-03-30: 83rd IETF Meeting in = Paris, France.
  • 2012-04-27 = (Friday): Proceedings submission cutoff date by 17:00 PT = (UTC -7), upload using IETF = Meeting Materials Management Tool.
  • 2012-05-16 = (Wednesday): Proceedings submission corrections cutoff = date by 17:00 PT (UTC -7), upload usingIETF = Meeting Materials Management = Tool.

Draft = agenda:

WEDNESDAY, March 28, = 2012

Hall= Maillot A
1300-1500 Afternoon Session I
252BAPPhybi
drafts: ta= r|pd= f
243APPrepute
= tar|= pdf
253INTnetext
= tar|= pdf
252ARAIecrit
drafts: t= ar|p= df
242ABRTGkarp
drafts: ta= r|pd= f
Maillotnvo3
ta= r|pd= f
241RTGroll
drafts: ta= r|pd= f
212/213nea
tar= |pdf=

Please = let us know no later than March 3 if you would like to request a slot = for the ROLL Working Group meeting.

Thanks.

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

= --Apple-Mail=_E5CDA400-C33C-4840-9D9B-B9CB626747DF-- From jpv@cisco.com Wed Mar 7 09:59:54 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59621E80DA for ; Wed, 7 Mar 2012 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.139 X-Spam-Level: X-Spam-Status: No, score=-110.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZTE2o2i7Z4t for ; Wed, 7 Mar 2012 09:59:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB9FE21E80B2 for ; Wed, 7 Mar 2012 09:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=201; q=dns/txt; s=iport; t=1331143192; x=1332352792; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=uhwb2BYgXLJoTYLwjlTc1+/n3juQuaXg3Yj5//jMXOk=; b=RE2CnqyhjCeGdWEM8ixVXTJiDAvBXILg4NLsqI0eNd8XCHgku+adzdCI p2EFf0926M8j8mnHtjmvslws8B/usHK1MbtqbQ+TFOEwamkyrLkn3YdnG YGUcb+BL4fxC0sJjM1aNR2HY0k4hEBPbQukPa0nbe1BBB/+Z7Av4bxrMU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAMWhV0+Q/khN/2dsb2JhbABEtR2BB4IjASc/gT41h2aaRAGfGpAMYwSVQZAXgmQ X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="131623370" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 07 Mar 2012 17:59:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27Hxpbr009665; Wed, 7 Mar 2012 17:59:51 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 18:59:51 +0100 Received: from ams-jvasseur-8918.cisco.com ([10.61.82.186]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 18:59:51 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 18:59:50 +0100 Message-Id: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> To: Thomas Heide Clausen Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 07 Mar 2012 17:59:51.0249 (UTC) FILETIME=[17D70410:01CCFC8C] Cc: roll WG Subject: [Roll] Your draft draft-clausen-lln-rpl-experiences-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2012 17:59:54 -0000 Dear Thomas, I did not see a request for a slot to discuss = draft-clausen-lln-rpl-experiences-00 at IETF-83. Would you be interested in presenting your ID to the WG ? Kind Regards. JP.= From ietf@thomasclausen.org Thu Mar 8 04:14:39 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0444021F86C2 for ; Thu, 8 Mar 2012 04:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phHh8maJ-oVR for ; Thu, 8 Mar 2012 04:14:38 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD321F86B9 for ; Thu, 8 Mar 2012 04:14:38 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 0B82FCD258 for ; Thu, 8 Mar 2012 04:14:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5EDF41C084B; Thu, 8 Mar 2012 04:14:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 78E571C07CE; Thu, 8 Mar 2012 04:14:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> Date: Thu, 8 Mar 2012 13:14:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15B9297C-5552-4AB6-A7D9-35B534208FFB@thomasclausen.org> References: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG Subject: Re: [Roll] Your draft draft-clausen-lln-rpl-experiences-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Mar 2012 12:14:39 -0000 Dear JP, Apologies for replying almost a day after your mail - I and the other = authors have been busy updating this document (among other documents) = for the coming deadline. We would, of course, be pleased to present our findings and this = document to the ROLL WG, and we thank you for your kind offer. We will = make sure to announce the -01 to the WG mailing list, as soon as we've = finished our last review and it has hit the IETF servers. Respectfully, and on behalf of all the authors, Thomas On Mar 7, 2012, at 18:59 , JP Vasseur wrote: > Dear Thomas, >=20 > I did not see a request for a slot to discuss = draft-clausen-lln-rpl-experiences-00 at IETF-83. >=20 > Would you be interested in presenting your ID to the WG ? >=20 > Kind Regards. >=20 > JP. From dat@exegin.com Thu Mar 8 04:20:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236521F8648 for ; Thu, 8 Mar 2012 04:20:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2iPn1D+DbEo for ; Thu, 8 Mar 2012 04:20:49 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7521F867E for ; Thu, 8 Mar 2012 04:20:39 -0800 (PST) Received: by werb10 with SMTP id b10so348966wer.31 for ; Thu, 08 Mar 2012 04:20:38 -0800 (PST) Received: by 10.180.79.135 with SMTP id j7mr31252949wix.19.1331209238446; Thu, 08 Mar 2012 04:20:38 -0800 (PST) Received: from [192.168.0.178] ([41.2.79.22]) by mx.google.com with ESMTPS id p10sm44626433wic.0.2012.03.08.04.20.35 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 04:20:37 -0800 (PST) Message-ID: <4F58A410.1040106@exegin.com> Date: Thu, 08 Mar 2012 14:20:32 +0200 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Philip Levis References: <4F5748B6.6030503@exegin.com> <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> In-Reply-To: <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmmbOlxUAnWU+GaD2MXuzXSKbUd/QzNpn0c3n1JPs0ZXUvP14pm7vDGg9UitGFrEWsGXFzG Cc: roll@ietf.org Subject: Re: [Roll] MRHOF draft-06 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Mar 2012 12:20:50 -0000 Hi Philip Thank you for the quick response. Please see my comments in-line. On 12-03-07 05:38 PM, Philip Levis wrote: > On Mar 7, 2012, at 3:38 AM, Dario Tedeschi wrote: > >> In section 3.3. " >> A node sets its Rank to the maximum of three values: >> ... >> " >> Could the above be simplified/removed by just saying that members in the parent set meet the following condition: >> ( DAGRank(PathRank)< DAGRank(thisNode.AdvRank) ) > I don't think so. Among other things, the node decides on its advertised rank based on the parent set. That seems wrong to me: Shouldn't a node's advertised rank be based on the preferred parent it selects and the cost through that parent, while the preferred parent is selected based on the path costs of each member in the parent set. The parent set is a sub-set of those nodes closer to the root (lesser integer rank) than yourself. > Or are you saying that the parent set at execution i should be affected by the node's advertised rank at execution i-1? Yes, except I'd change "should" to "could". Also, perhaps I should have used the word CurrentRank instead of thisNode.AdvRank to be more clear. I realise there is a bootstrap issue here, but the way I see it, a node starts off with an infinite rank (even though it would not advertise that). Starting at the bottom of the DODAG, the node ratchets up closer to the root as it hears and selects a new parent with sufficiently lower path cost. > The reason this part of the specification becomes complicated is because it's possible for Rank and metric values to diverge due to MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path whose links have an ETX of 1, then the metric value will be 512 but the Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't difficult, but it starts to be weird on metrics like Node Energy. Hence the recommendation at the end about the relationship of MinHopRankIncrease and metrics. > OK, but the node still has to determine path Rank for each potential parent so why not use it to determine the parent set. Essentially if the path Rank of node A would not cause node B's advertised rank to increase more than one integer step (should node A be selected as a parent), then node A can be considered as a member of the parent set of node B. Otherwise, node A cannot be a member of node B's parent set. This would also ensure that node B never advertises a rank higher than it had previously advertised, because it could never have members in its parent set that would cause it to do so. Another question I have for section 3.3: Item 2 says, "The Rank of the member of the parent set with the highest advertised Rank plus one". Is that really just "plus one" or should it be "plus MinHopRankIncrease" (i.e. plus one step in integer rank)? > >> In section 3.4 ... >> >> Reading the section further, MRHOF with ETX is exclude from the above requirement. Was that intentional? > No -- can you point me to the exact text which leads you to this conclusion, so I can fix it? In section 3.4 " If ETX is the selected metric, cur_min_path_cost is directly used as Rank and never advertised in a metric container. " If cur_min_path_cost is the path cost through the preferred parent how would the OF (using ETX) advertise the highest path cost of a member in the parent set. Or is it that the second and subsequent sentences in the first paragraph of section 3.4 do not apply to MRHOF when it's using ETX. Regards Dario From jpv@cisco.com Thu Mar 8 05:45:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E321F8670 for ; Thu, 8 Mar 2012 05:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.197 X-Spam-Level: X-Spam-Status: No, score=-110.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyP4wxmApMl9 for ; Thu, 8 Mar 2012 05:45:50 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AFA8E21F8661 for ; Thu, 8 Mar 2012 05:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=984; q=dns/txt; s=iport; t=1331214349; x=1332423949; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hTRSXt0YGfY6UeXk/QUainAide4/5GvcR0o1wJ1SZEc=; b=NYVODKMBx0K9K9SHqWkN94XAEy8MCya9eURfs6hNkG0/mV1+BmMOHM5o LlhIfsA0aIaYw67uj96q/7WSr2DLPKcp/7KTpeGoWjbUQn445xB543XUj Cjr+KIJ59UQT/qBov5OuoBfZobPPRRVy6lHdIzEZYLmILvUSZmm5UzFVD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGAMm2WE+Q/khN/2dsb2JhbABDgwmyFYEHggoBAQEDARIBJzQLBQsLGC5XBjWHYwWbJgGfH4oohWNjBJVFhWWKM4JkgVs X-IronPort-AV: E=Sophos;i="4.73,552,1325462400"; d="scan'208";a="67992028" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 13:45:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28Djmk1016897; Thu, 8 Mar 2012 13:45:48 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:45:48 +0100 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:45:48 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <15B9297C-5552-4AB6-A7D9-35B534208FFB@thomasclausen.org> Date: Thu, 8 Mar 2012 14:45:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> <15B9297C-5552-4AB6-A7D9-35B534208FFB@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 08 Mar 2012 13:45:48.0447 (UTC) FILETIME=[C4D5C2F0:01CCFD31] Cc: roll WG Subject: Re: [Roll] Your draft draft-clausen-lln-rpl-experiences-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Mar 2012 13:45:50 -0000 Thanks Thomas, I'll update the agenda accordingly. Kind Regards. JP. On Mar 8, 2012, at 1:14 PM, Thomas Heide Clausen wrote: > Dear JP, >=20 > Apologies for replying almost a day after your mail - I and the other = authors have been busy updating this document (among other documents) = for the coming deadline. >=20 > We would, of course, be pleased to present our findings and this = document to the ROLL WG, and we thank you for your kind offer. We will = make sure to announce the -01 to the WG mailing list, as soon as we've = finished our last review and it has hit the IETF servers. >=20 > Respectfully, and on behalf of all the authors, >=20 > Thomas >=20 > On Mar 7, 2012, at 18:59 , JP Vasseur wrote: >=20 >> Dear Thomas, >>=20 >> I did not see a request for a slot to discuss = draft-clausen-lln-rpl-experiences-00 at IETF-83. >>=20 >> Would you be interested in presenting your ID to the WG ? >>=20 >> Kind Regards. >>=20 >> JP. >=20 From Alireza.Sahami@vis.uni-stuttgart.de Wed Feb 29 11:47:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDC221F87FC; Wed, 29 Feb 2012 11:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfy+Z2KAi5Fc; Wed, 29 Feb 2012 11:47:24 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.informatik.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3E21F87D5; Wed, 29 Feb 2012 11:47:21 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.02.0247.003; Wed, 29 Feb 2012 20:47:19 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: MoDeSense'12 in conj. with INSS'12- International Workshop on Applications, Systems, and Services for Mobile Device Sensing Thread-Index: AQHM9xryGt+E6CWOXEOXeKmzqTtgkg== Date: Wed, 29 Feb 2012 19:47:19 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.216.79.149] Content-Type: multipart/alternative; boundary="_000_CB74162A2B0E7alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Mar 2012 08:26:26 -0800 Subject: [Roll] MoDeSense'12 in conj. with INSS'12- International Workshop on Applications, Systems, and Services for Mobile Device Sensing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Feb 2012 19:47:26 -0000 --_000_CB74162A2B0E7alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---------------------------------------------------------------------- Call for Papers The 2012 International Workshop on Applications, Systems, and Services for = Mobile Device Sensing (MoDeSense 2012) In conjunction with The Ninth International Conference on Networked Sensing= Systems (INSS 2012), Antwerp, Belgium, June 11, 2012 http://www.cse.oulu.fi/MoDeSense2012 Scope: ------ A state-of-the-art mobile phone knows its location, has a capability to rec= ognize its orientation and movement patterns, can modify its display bright= ness settings according to the lighting conditions, can use embedded camera= s for sensing the user's activities, can communicate through vibration, sou= nd and NFC tags, and send/receive information through wireless channels. Th= is kind of device enables research in participatory sensing, human probes, = vehicle probes, floating cars, urban sensing, co-operating sensing, to name= a few branches. The increasing capabilities of portable devices including = highly capable smart phones are creating new opportunities not seen before. Emerging and existing application domains include traffic, social networkin= g, entertainment, education, advertisement, environmental preservation, sur= veillance and safety, business, and health care. Among above, real-time int= eraction with social networking is a promising application domain where peo= ple can share location and activity data, as well as photos and update thei= r status through their social networking services in real-time manner. Howe= ver, effective design and deployment of such applications involves addressi= ng many research issues ranging from efficient platform design, data and im= age processing, storage, data mining, power management, user interface, com= munication of large amounts of data, and privacy issues inherent to portabl= e device sensing. This workshop aims at bringing together researchers from academia and indus= try to showcase their work and obtain feedback. The workshop expects to act= as a forum for research community to discuss practical issues in providing= portable device sensing applications. The workshop encourages position pap= ers, novel ideas, early-stage research ideas, and in-progress work on syste= m architecture, enabling technologies, and emerging applications. The topic= areas of interest include, but are not limited to, the following: - Applications and services for portable device sensing - Platforms and middleware for sensing with small portable devices - Efficient algorithms for capturing, storing, retrieving, and distributin= g interesting patterns from sensory data - Participatory sensing using portable devices - Power management - Human-computer interaction and user interfaces - Data mining for data streams - Camera based applications and services - Social networking using sensory or image data - Security and privacy protection - Testbeds and platforms for experimenting with portable device sensing - User experiences and case studies from real-world deployments Submission Instruction: ----------------------- The paper submissions should be up to 5 pages, in double-column IEEE procee= ding format. The IEEE proceedings format can be found here: http://www.ieee= .org/publications_standards/publications/authors/authors_journals.html#sect= 2. The papers will undergo a review process. The workshop will have a viewing slot for demonstrations that present the i= deas in the papers. The demonstration should be a 1-2 page description of t= he system. Papers and demo descriptions must be in PDF format and must be submitted vi= a the EasyChair submission site: http://www.easychair.org/conferences/confe= rence_dir.cgi?a=3Dc02a1c60d5d6. Important Dates: ---------------- Paper and demo submission deadline: March 25, 2012 Notification of acceptance: April 5, 2012 Camera-ready paper due: April 15, 2012 Workshop day: June 11, 2012 Organizing committee -------------------- Professor Hannuksela Jari, University of Oulu, Finland Dr. Pirttikangas Susanna, University of Oulu, Finland Assistant Professor Thepvilojanapong Niwat, Mie University, Japan Workshop program committee -------------------------- Alenius Sakari, Nokia Research Center, Finland Bilcu Radu, Nokia Research Center, Finland Fujinami Kaori, Tokyo University of Agriculture and Technology, Japan Iwai Masayuki, University of Tokyo, Japan Iwamoto Takeshi, Toyama Prefectural University, Japan Riekki Jukka, University of Oulu, Finland Shiraishi Yoh, Future University Hakodate, Japan Takashio Kazunori, Keio University, Japan Terabayashi Kenji, Chuo University, Japan Wang Haipeng, Northwestern Polytechnical University, China ---------------------------------------------------------------------- --_000_CB74162A2B0E7alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C6C40E5415EED4B8F87FC63930BF034@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
----------------------------------------------------------------------=
Call for Papers

The 2012 International Workshop on Applications, Systems, and Services= for Mobile Device Sensing (MoDeSense 2012)
In conjunction with The Ninth International Conference on Networked Se= nsing Systems (INSS 2012),
Antwerp, Belgium, June 11, 2012


Scope: 
------
A state-of-the-art mobile phone knows its location, has a capability t= o recognize its orientation and movement patterns, can modify its display b= rightness settings according to the lighting conditions, can use embedded c= ameras for sensing the user's activities, can communicate through vibration, sound and NFC tags, and send/receive in= formation through wireless channels. This kind of device enables research i= n participatory sensing, human probes, vehicle probes, floating cars, urban= sensing, co-operating sensing, to name a few branches. The increasing capabilities of portable devices in= cluding highly capable smart phones are creating new opportunities not seen= before. 

Emerging and existing application domains include traffic, social netw= orking, entertainment, education, advertisement, environmental preservation= , surveillance and safety, business, and health care. Among above, real-tim= e interaction with social networking is a promising application domain where people can share location and acti= vity data, as well as photos and update their status through their social n= etworking services in real-time manner. However, effective design and deplo= yment of such applications involves addressing many research issues ranging from efficient platform design, da= ta and image processing, storage, data mining, power management, user inter= face, communication of large amounts of data, and privacy issues inherent t= o portable device sensing. 

This workshop aims at bringing together researchers from academia and = industry to showcase their work and obtain feedback. The workshop expects t= o act as a forum for research community to discuss practical issues in prov= iding portable device sensing applications. The workshop encourages position papers, novel ideas, early-stage research= ideas, and in-progress work on system architecture, enabling technologies,= and emerging applications. The topic areas of interest include, but are no= t limited to, the following: 
 - Applications and services for portable device sensing 
 - Platforms and middleware for sensing with small portable devic= es
 - Efficient algorithms for capturing, storing, retrieving, and d= istributing interesting patterns from sensory data
 - Participatory sensing using portable devices
 - Power management 
 - Human-computer interaction and user interfaces 
 - Data mining for data streams 
 - Camera based applications and services
 - Social networking using sensory or image data 
 - Security and privacy protection 
 - Testbeds and platforms for experimenting with portable device = sensing 
 - User experiences and case studies from real-world deployments&= nbsp;

Submission Instruction:
-----------------------
The paper submissions should be up to 5 pages, in double-column IEEE p= roceeding format. The IEEE proceedings format can be found here: http://www.ieee.org/publications_standards/publications/authors/authors_jou= rnals.html#sect2. The papers will undergo a review process.

The workshop will have a viewing slot for demonstrations that present = the ideas in the papers. The demonstration should be a 1-2 page description= of the system. 
Papers and demo descriptions must be in PDF format and must be submitt= ed via the EasyChair submission site: http://www.easychair.org/conferences/conference_dir.cgi?a=3Dc02a1c60d5d6.

Important Dates:
----------------
Paper and demo submission deadline: March 25, 2012
Notification of acceptance: April 5, 2012
Camera-ready paper due: April 15, 2012
Workshop day: June 11, 2012

Organizing committee
--------------------
Professor Hannuksela Jari, University of Oulu, Finland
Dr. Pirttikangas Susanna, University of Oulu, Finland
Assistant Professor Thepvilojanapong Niwat, Mie University, Japan

Workshop program committee
--------------------------
Alenius Sakari, Nokia Research Center, Finland 
Bilcu Radu, Nokia Research Center, Finland 
Fujinami Kaori, Tokyo University of Agriculture and Technology, Japan&= nbsp;
Iwai Masayuki, University of Tokyo, Japan 
Iwamoto Takeshi, Toyama Prefectural University, Japan 
Riekki Jukka, University of Oulu, Finland 
Shiraishi Yoh, Future University Hakodate, Japan
Takashio Kazunori, Keio University, Japan 
Terabayashi Kenji, Chuo University, Japan 
Wang Haipeng, Northwestern Polytechnical University, China 
----------------------------------------------------------------------=
--_000_CB74162A2B0E7alirezasahamivisunistuttgartde_-- From Alireza.Sahami@vis.uni-stuttgart.de Fri Mar 2 11:07:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100B21E801F; Fri, 2 Mar 2012 11:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shoB9wnou6yU; Fri, 2 Mar 2012 11:07:01 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.informatik.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id DF1F621E8019; Fri, 2 Mar 2012 11:06:59 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.02.0247.003; Fri, 2 Mar 2012 20:06:58 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: INSS 2012 Call for Demo - Deadline extended 14 March 2012 Thread-Index: AQHM+KejVuvFV2j9G0CSVQ5YQRPv4w== Date: Fri, 2 Mar 2012 19:06:57 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.216.79.149] Content-Type: multipart/alternative; boundary="_000_CB76D8DE2B193alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Mar 2012 08:26:26 -0800 Subject: [Roll] INSS 2012 Call for Demo - Deadline extended 14 March 2012 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 19:07:02 -0000 --_000_CB76D8DE2B193alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept our apology if you receive this announcement through multiple= lists) ********************************************************************** FINAL CALL FOR DEMONSTRATIONS - !EXTENDED DEADLINE! INSS 2012 - The Ninth International Conference of Networked Sensing Systems Antwerp, Belgium, June 11-14, 2012 EXTENDED SUBMISSION DEADLINE: March 14, 2012 (IEEEXplore publication) http://www.inss-conf.org/2012/cfd.shtml ********************************************************************** During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as THE scientific event where academic = and industrial experts from the areas of sensor systems, wireless networks,= and sensor network applications come together. The INSS provides a forum to hear about the latest developments in these ar= eas, to exchange ideas, and to start up collaborations within these fields = and between industry and academia. Demonstrations are a great way to exchange and present latest research resu= lts, creative ideas and innovative applications in an open, living fashion.= Our experience from recent INSS conferences revealed that they promote int= ense and fruitful discussions with interested participants from industry an= d academia to exchange knowledge, novel methodologies, new concepts and new= perceptions directly. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research from the fie= ld of sensor technology, wireless networking, or application of networked s= ensor systems (for full list of topics please refer to http://www.inss-conf= .org/2012/cfp.shtml). The conference especially encourages submissions that address research issu= es shared between those areas. ********************************************************************** You are invited to submit a demo proposal to INSS 2012 either as a separate= contribution or as a companion to an accepted paper in the conference. Sub= missions from both industries and universities are encouraged. Separate demo contributions will be peer- reviewed and evaluated on the bas= is of originality, technical correctness, and presentation. Extended abstr= acts must be 1-2 pages long (two-column format). Abstracts should be forma= tted according to the IEEE transactions format. All accepted submissions w= ill be published at IEEE Xplore digital library. Authors are required to de= monstrate their work during the conference. All submissions including the companion submissions should additionally fea= ture a short, informal description of the demo setup. Submissions should be in PDF format and will be handled through EasyChair: http://www.easychair.org/conferences/?conf=3Dinss2012demos ********************************************************************** The EXTENDED SUBMISSION DEADLINE for extended abstracts is March 14, 2012. If you have any inquiries about submissions please don't hesitate to contac= t the demo chairs. ********************************************************************** Mathieu Boussard(mathieu.boussard@alcatel-lucent.com) Till Riedel (riedel@teco.edu) (Demo Co-Chairs) Demo Program Comittee Members: Felix B=B8sching (TU Braunschweig) Matthias Kranz (TU Munich) Simon Mayer (ETH Zurich) Phil Scholl (TU Darmstadt) --_000_CB76D8DE2B193alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1178C3B3E6A4CA4FAF3929110AD6A3D6@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
Please accept our apology if you receive this announcement through mul= tiple lists)

**********************************************************************=

FINAL CALL FOR DEMONSTRATIONS - !EXTENDED DEADLINE!

INSS 2012 - The Ninth International Conference of Networked Sensing Sy= stems
Antwerp, Belgium, June 11-14, 2012

EXTENDED SUBMISSION DEADLINE: March 14, 2012
(IEEEXplore publication)

http://www.inss-conf.org/2012/cfd.shtml

**********************************************************************=

During the past years, the International Conference on Networked Sensi= ng Systems (INSS) has established itself as THE scientific event where acad= emic and industrial experts from the areas of sensor systems, wireless netw= orks, and sensor network applications come together.

The INSS provides a forum to hear about the latest developments in the= se areas, to exchange ideas, and to start up collaborations within these fi= elds and between industry and academia.

Demonstrations are a great way to exchange and present latest research= results, creative ideas and innovative applications in an open, living fas= hion. Our experience from recent INSS conferences revealed that they promot= e intense and fruitful discussions with interested participants from industry and academia to exchange knowle= dge, novel methodologies, new concepts and new perceptions directly.

INSS 2012 is the ninth annual conference in the series, and features a= highly selective technical program. We invite outstanding research from th= e field of sensor technology, wireless networking, or application of networ= ked sensor systems (for full list of topics please refer to http://www.inss-conf.org/2012/cfp.shtml).

The conference especially encourages submissions that address research= issues shared between those areas.

**********************************************************************=

You are invited to submit a demo proposal to INSS 2012 either as a sep= arate contribution or as a companion to an accepted paper in the conference= . Submissions from both industries and universities are encouraged.

Separate demo contributions will be peer- reviewed and evaluated on th= e basis of originality, technical correctness, and presentation.  Exte= nded abstracts must be 1-2 pages long (two-column format).  Abstracts = should be formatted according to the IEEE transactions format.  All accepted submissions will be published at I= EEE Xplore digital library. Authors are required to demonstrate their work = during the conference.

All submissions including the companion submissions should additionall= y feature a short, informal description of the demo setup.

Submissions should be in PDF format and will be handled through EasyCh= air:

http://www.easychair.org/conferences/?conf=3Dinss2012demos

**********************************************************************=


The EXTENDED SUBMISSION DEADLINE for extended abstracts is 
March 14, 2012.

If you have any inquiries about submissions please don't hesitate to c= ontact the demo chairs.

**********************************************************************=

Mathieu Boussard(mathieu.boussard@alcatel-lucent.com)
Till Riedel (riedel@teco.edu)

(Demo Co-Chairs)

Demo Program Comittee Members:

Felix = B=B8sching (TU Braunschweig)
Matthias Kranz (TU Munich)
Simon = Mayer (ETH Zurich)
Phil S= choll (TU Darmstadt) 
--_000_CB76D8DE2B193alirezasahamivisunistuttgartde_-- From pal@cs.stanford.edu Thu Mar 8 09:53:40 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B616B21F866E for ; Thu, 8 Mar 2012 09:53:40 -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, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8sO1xvIu4ZM for ; Thu, 8 Mar 2012 09:53:40 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8221F865B for ; Thu, 8 Mar 2012 09:53:39 -0800 (PST) Received: from [192.5.67.11] (helo=[10.255.241.255]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S5hWy-0003mI-Po; Thu, 08 Mar 2012 09:53:38 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4F58A410.1040106@exegin.com> Date: Thu, 8 Mar 2012 08:44:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <76DBCAC8-114B-48C5-9D2D-A733D2A4AF39@cs.stanford.edu> References: <4F5748B6.6030503@exegin.com> <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> <4F58A410.1040106@exegin.com> To: Dario Tedeschi X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 338c3cf868ffc68e9019f8ff8af72f6c Cc: roll@ietf.org Subject: Re: [Roll] MRHOF draft-06 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Mar 2012 17:53:41 -0000 Responses inline. On Mar 8, 2012, at 4:20 AM, Dario Tedeschi wrote: > Hi Philip >=20 > Thank you for the quick response. Please see my comments in-line. >=20 > On 12-03-07 05:38 PM, Philip Levis wrote: >> On Mar 7, 2012, at 3:38 AM, Dario Tedeschi wrote: >>=20 >>> In section 3.3. " >>> A node sets its Rank to the maximum of three values: >>> ... >>> " >>> Could the above be simplified/removed by just saying that members in = the parent set meet the following condition: >>> ( DAGRank(PathRank)< DAGRank(thisNode.AdvRank) ) >> I don't think so. Among other things, the node decides on its = advertised rank based on the parent set. > That seems wrong to me: Shouldn't a node's advertised rank be based on = the preferred parent it selects and the cost through that parent, while = the preferred parent is selected based on the path costs of each member = in the parent set. The parent set is a sub-set of those nodes closer to = the root (lesser integer rank) than yourself. This isn't how DIO advertisements and parent sets work: take a look at = the RPL spec. The parent set is the set of neighbors a node decides it = might route through. It might change its preferred parent to another = element of the preferred parent set very quickly, more quickly than you = want to advertise Rank changes through DIOs (think fast failover in case = of a link seeing a burst of losses). Because of MaxRankIncrease, this = means that a node must advertise a Rank conservative enough to use any = member of its parent set. I.e. if you have a MaxRankIncrease of 10, a = MinHopRankIncrease of 10, a preferred parent whose path has a Rank of 30 = and a second parent whose past cost has a Rank of 51, you have to = advertise a Rank >=3D 41, or you will not be able to fail over to the = second parent when the first parent fails. The specification is written this way in order to clearly separate the = role of an OF -- neighbor set, parent set, and preferred parent = selection, Rank computation -- from how RPL operates and maintains its = invariants with respect to Rank. >> Or are you saying that the parent set at execution i should be = affected by the node's advertised rank at execution i-1? > Yes, except I'd change "should" to "could". Also, perhaps I should = have used the word CurrentRank instead of thisNode.AdvRank to be more = clear. I realise there is a bootstrap issue here, but the way I see it, = a node starts off with an infinite rank (even though it would not = advertise that). Starting at the bottom of the DODAG, the node ratchets = up closer to the root as it hears and selects a new parent with = sufficiently lower path cost. I'd argue that this is an implementation detail/decision? >=20 >> The reason this part of the specification becomes complicated is = because it's possible for Rank and metric values to diverge due to = MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This = corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path = whose links have an ETX of 1, then the metric value will be 512 but the = Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't = difficult, but it starts to be weird on metrics like Node Energy. Hence = the recommendation at the end about the relationship of = MinHopRankIncrease and metrics. >>=20 > OK, but the node still has to determine path Rank for each potential = parent so why not use it to determine the parent set. Essentially if the = path Rank of node A would not cause node B's advertised rank to increase = more than one integer step (should node A be selected as a parent), then = node A can be considered as a member of the parent set of node B. = Otherwise, node A cannot be a member of node B's parent set. This would = also ensure that node B never advertises a rank higher than it had = previously advertised, because it could never have members in its parent = set that would cause it to do so. >=20 Note that the specification does *not* say how the parent set is = selected. That is an implementation-specific decision. I feel it would = be a mistake to specify parent set selection; I've seen enough = variations and tweaks to achieve different goals, with different = tradeoffs, that I'm uncomfortable making a strong recommendation of how = to do it. That's why it's stayed out of the specification.=20 > Another question I have for section 3.3: Item 2 says, "The Rank of the = member of the parent set with the highest advertised Rank plus one". Is = that really just "plus one" or should it be "plus MinHopRankIncrease" = (i.e. plus one step in integer rank)? It should be plus one, to maintain the invariant that a node advertises = a Rank higher than every element of its parent set. I should review these values again to make sure they satisfy all of = RPL's invariants. Hm -- I should probably also add a note about MaxRankIncrease and how = this affects parent selection. >=20 >>=20 >>> In section 3.4 ... >>>=20 >>> Reading the section further, MRHOF with ETX is exclude from the = above requirement. Was that intentional? >> No -- can you point me to the exact text which leads you to this = conclusion, so I can fix it? >=20 > In section 3.4 " > If ETX is the selected metric, cur_min_path_cost is directly used = as > Rank and never advertised in a metric container. > " > If cur_min_path_cost is the path cost through the preferred parent how = would the OF (using ETX) advertise the highest path cost of a member in = the parent set. Or is it that the second and subsequent sentences in the = first paragraph of section 3.4 do not apply to MRHOF when it's using = ETX. Ah, great, thanks. Just wanted to be sure I nail the exact text you see = an issue with. Phil= From ietf@thomasclausen.org Thu Mar 8 21:37:09 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0277A21E804B for ; Thu, 8 Mar 2012 21:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHzX4xq5aSOC for ; Thu, 8 Mar 2012 21:37:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3F03721E802B for ; Thu, 8 Mar 2012 21:37:05 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1A543CD0CF for ; Thu, 8 Mar 2012 21:37:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CBBE8242962; Thu, 8 Mar 2012 21:37:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 75B26242961; Thu, 8 Mar 2012 21:37:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Clausen In-Reply-To: Date: Fri, 9 Mar 2012 06:37:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C6B1EC1-F027-419D-9888-1CA658835816@thomasclausen.org> References: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> <15B9297C-5552-4AB6-A7D9-35B534208FFB@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG Subject: Re: [Roll] Your draft draft-clausen-lln-rpl-experiences-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 05:37:09 -0000 Dear JP, In accordance with what we promised, the -01 has now been posted, at the = usual URL, and we wanted to notify you and the WG: = https://datatracker.ietf.org/doc/draft-clausen-lln-rpl-experiences/ Respectfully, and on behalf of all the authors, Thomas On Mar 8, 2012, at 2:45 PM, JP Vasseur wrote: > Thanks Thomas, I'll update the agenda accordingly. > Kind Regards. >=20 > JP. >=20 > On Mar 8, 2012, at 1:14 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP, >>=20 >> Apologies for replying almost a day after your mail - I and the other = authors have been busy updating this document (among other documents) = for the coming deadline. >>=20 >> We would, of course, be pleased to present our findings and this = document to the ROLL WG, and we thank you for your kind offer. We will = make sure to announce the -01 to the WG mailing list, as soon as we've = finished our last review and it has hit the IETF servers. >>=20 >> Respectfully, and on behalf of all the authors, >>=20 >> Thomas >>=20 >> On Mar 7, 2012, at 18:59 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> I did not see a request for a slot to discuss = draft-clausen-lln-rpl-experiences-00 at IETF-83. >>>=20 >>> Would you be interested in presenting your ID to the WG ? >>>=20 >>> Kind Regards. >>>=20 >>> JP. >>=20 >=20 From dat@exegin.com Thu Mar 8 21:52:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A80121F8550 for ; Thu, 8 Mar 2012 21:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEHiL6S8UZWF for ; Thu, 8 Mar 2012 21:52:00 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A35AB21F854E for ; Thu, 8 Mar 2012 21:52:00 -0800 (PST) Received: by werb10 with SMTP id b10so1080587wer.31 for ; Thu, 08 Mar 2012 21:51:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=7I8r+pF3RwR6Z9Y1HRk8nmdQpHgayuSmZzRHDOQDHic=; b=asitkc3I9XEyvG7pL3D3jRDDPieAd16BEpd7QJua2kEC9i6z/lYYd8LvDfSILfpEqJ HEne4JwN6o3vFRJjIr1qxfHylnqWxP+TCYSdqLBnqo2D8zlysUXwBQFzTS0bVo8qrx4D OPMsLmS/+wNy/mQ+Cb9Pr/2nvgHPXBMXh3gor/Uj76tz7z8i4YAjGclcRHAFDbPMmHo8 Aaxgq9HtsSlqFjXeThk6YNUXVTzFa3ji+bVJxVqBBs5rqWLkula/cIXZUb1zAHpziCZi 3ClsS+XSYDhOGyNfvc7ES46mTYRlMat/TQLkq5UbdbcUqEQtDfVkk3uxTSKlSrxQlON5 03Mw== Received: by 10.180.19.37 with SMTP id b5mr1568798wie.9.1331272319616; Thu, 08 Mar 2012 21:51:59 -0800 (PST) Received: from [192.168.0.178] ([41.4.57.108]) by mx.google.com with ESMTPS id fa9sm4784775wib.5.2012.03.08.21.51.55 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 21:51:58 -0800 (PST) Message-ID: <4F589CD9.9030308@exegin.com> Date: Thu, 08 Mar 2012 13:49:45 +0200 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Philip Levis References: <4F5748B6.6030503@exegin.com> <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> In-Reply-To: <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmbHxzWjK8YmwAe1cAJkEYiQMKcDDQDPTfv8H5prUIm2XfTRVPZdGeNU5rSOioD+ldZs63F Cc: roll@ietf.org Subject: Re: [Roll] MRHOF draft-06 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 05:52:02 -0000 Hi Philip Thank you for the quick response. Please see my comments in-line. On 12-03-07 05:38 PM, Philip Levis wrote: > On Mar 7, 2012, at 3:38 AM, Dario Tedeschi wrote: > >> In section 3.3. " >> A node sets its Rank to the maximum of three values: >> ... >> " >> Could the above be simplified/removed by just saying that members in the parent set meet the following condition: >> ( DAGRank(PathRank)< DAGRank(thisNode.AdvRank) ) > I don't think so. Among other things, the node decides on its advertised rank based on the parent set. That seems wrong to me: Shouldn't a node's advertised rank be based on the preferred parent it selects, while the preferred parent is selected based on the path costs of each member in the parent set. The parent set is a sub-set of those nodes closer to the root (lesser integer rank) than yourself. > Or are you saying that the parent set at execution i should be affected by the node's advertised rank at execution i-1? Yes, except I'd change "should" to "could". Also, perhaps I should have used the word CurrentRank instead of thisNode.AdvRank. I realise there is a bootstrap issue here, but the way I see it, a node starts off with an infinite rank (even though it would not advertise that). Starting at the bottom of the DODAG, the node ratchets up closer to the root as it hears and selects a new parent with sufficiently lower path cost. > The reason this part of the specification becomes complicated is because it's possible for Rank and metric values to diverge due to MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path whose links have an ETX of 1, then the metric value will be 512 but the Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't difficult, but it starts to be weird on metrics like Node Energy. Hence the recommendation at the end about the relationship of MinHopRankIncrease and metrics. > OK, but the node still has to determine path Rank for each potential parent so why not use it to determine the parent set. Essentially, if the path Rank of node A would not cause node B's advertised rank to increase more than one integer step (should node A be selected as a parent), then node A can be considered as a member of the parent set of node B. Otherwise, node A cannot be a member of node B's parent set. This would also ensure that node B never advertises a rank higher than it has previously advertised. One additional question for section 3.3. >> In section 3.4. "Reading the section further, MRHOF with ETX is exclude from the above requirement. Was that intentional? > No -- can you point me to the exact text which leads you to this conclusion, so I can fix it? In section 3.4 " If ETX is the selected metric, cur_min_path_cost is directly used as Rank and never advertised in a metric container. " If cur_min_path_cost is the path cost through the preferred parent how would the OF (using ETX) advertise the highest path cost of a member in the parent set. Regards Dario From dat@exegin.com Thu Mar 8 22:23:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C976121F864D for ; Thu, 8 Mar 2012 22:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuvP0dm4-ofo for ; Thu, 8 Mar 2012 22:23:00 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 996DA21F855B for ; Thu, 8 Mar 2012 22:22:59 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so918321wgb.13 for ; Thu, 08 Mar 2012 22:22:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=1cshWgfjh4opxlNT+wiMm6ix6dWgr1qV52X9OfGoJww=; b=CSOlhHf1ujc5JQ7zWfLbr93LmwhPRLjrcwQSrdMhFbGocs4Y52xGCNsShXRNUqUZZn 8ienG5tPqAhCqVSsGgBu1AV4MxcwPZR3jiG/ELSma/5bxi6YdBU4G28OkKhPdIw3QH/7 z8vfIaFJR/Hq1UiMyKKMbLUUZtShRxudKPV3Y4Am6rrYCKYejDlwibod2BMvLCdRz5ty 7TYbYojdF7+6ISM/+Af+eQQInMyfTbFszIfdvAmLGs5vc8gLDShWGU7807r10/lcEViX PDYR9tiVlbtfE7ICQSvnJ2MKvdvB+PZIa8JleGzmSbJGYlXaBXOKi3uWenRRFUjPspgU DS9Q== Received: by 10.180.24.66 with SMTP id s2mr1780592wif.7.1331274178635; Thu, 08 Mar 2012 22:22:58 -0800 (PST) Received: from [192.168.0.178] ([41.4.57.108]) by mx.google.com with ESMTPS id h19sm2452142wiw.9.2012.03.08.22.22.55 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 22:22:57 -0800 (PST) Message-ID: <4F59A1BD.9000904@exegin.com> Date: Fri, 09 Mar 2012 08:22:53 +0200 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Philip Levis References: <4F5748B6.6030503@exegin.com> <0D1B6BAA-F1A5-4BDC-934A-F19259560562@cs.stanford.edu> <4F58A410.1040106@exegin.com> <76DBCAC8-114B-48C5-9D2D-A733D2A4AF39@cs.stanford.edu> In-Reply-To: <76DBCAC8-114B-48C5-9D2D-A733D2A4AF39@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm8TZz4QcqksyfqH/zeRnF2Ojhpqs8s8BvBfU6xiRhzioDiaQf3QUjoVTtGq2cYLj8OLu6x Cc: roll@ietf.org Subject: Re: [Roll] MRHOF draft-06 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 06:23:00 -0000 Thanks Philip I think you have answered all my questions. I look forward to reading the next draft. Dario On 12-03-08 06:44 PM, Philip Levis wrote: > Responses inline. > > On Mar 8, 2012, at 4:20 AM, Dario Tedeschi wrote: > >> Hi Philip >> >> Thank you for the quick response. Please see my comments in-line. >> >> On 12-03-07 05:38 PM, Philip Levis wrote: >>> On Mar 7, 2012, at 3:38 AM, Dario Tedeschi wrote: >>> >>>> In section 3.3. " >>>> A node sets its Rank to the maximum of three values: >>>> ... >>>> " >>>> Could the above be simplified/removed by just saying that members in the parent set meet the following condition: >>>> ( DAGRank(PathRank)< DAGRank(thisNode.AdvRank) ) >>> I don't think so. Among other things, the node decides on its advertised rank based on the parent set. >> That seems wrong to me: Shouldn't a node's advertised rank be based on the preferred parent it selects and the cost through that parent, while the preferred parent is selected based on the path costs of each member in the parent set. The parent set is a sub-set of those nodes closer to the root (lesser integer rank) than yourself. > This isn't how DIO advertisements and parent sets work: take a look at the RPL spec. The parent set is the set of neighbors a node decides it might route through. It might change its preferred parent to another element of the preferred parent set very quickly, more quickly than you want to advertise Rank changes through DIOs (think fast failover in case of a link seeing a burst of losses). Because of MaxRankIncrease, this means that a node must advertise a Rank conservative enough to use any member of its parent set. I.e. if you have a MaxRankIncrease of 10, a MinHopRankIncrease of 10, a preferred parent whose path has a Rank of 30 and a second parent whose past cost has a Rank of 51, you have to advertise a Rank>= 41, or you will not be able to fail over to the second parent when the first parent fails. > > The specification is written this way in order to clearly separate the role of an OF -- neighbor set, parent set, and preferred parent selection, Rank computation -- from how RPL operates and maintains its invariants with respect to Rank. > >>> Or are you saying that the parent set at execution i should be affected by the node's advertised rank at execution i-1? >> Yes, except I'd change "should" to "could". Also, perhaps I should have used the word CurrentRank instead of thisNode.AdvRank to be more clear. I realise there is a bootstrap issue here, but the way I see it, a node starts off with an infinite rank (even though it would not advertise that). Starting at the bottom of the DODAG, the node ratchets up closer to the root as it hears and selects a new parent with sufficiently lower path cost. > I'd argue that this is an implementation detail/decision? > >>> The reason this part of the specification becomes complicated is because it's possible for Rank and metric values to diverge due to MinHopRankIncrease. I.e., let's say that MinHopRankIncrease is 512. This corresponds to an ETX of 4 (metric value 512). If you have a 3 hop path whose links have an ETX of 1, then the metric value will be 512 but the Rank will be 2048. Reconciling ETX and MinHopRankIncrease isn't difficult, but it starts to be weird on metrics like Node Energy. Hence the recommendation at the end about the relationship of MinHopRankIncrease and metrics. >>> >> OK, but the node still has to determine path Rank for each potential parent so why not use it to determine the parent set. Essentially if the path Rank of node A would not cause node B's advertised rank to increase more than one integer step (should node A be selected as a parent), then node A can be considered as a member of the parent set of node B. Otherwise, node A cannot be a member of node B's parent set. This would also ensure that node B never advertises a rank higher than it had previously advertised, because it could never have members in its parent set that would cause it to do so. >> > Note that the specification does *not* say how the parent set is selected. That is an implementation-specific decision. I feel it would be a mistake to specify parent set selection; I've seen enough variations and tweaks to achieve different goals, with different tradeoffs, that I'm uncomfortable making a strong recommendation of how to do it. That's why it's stayed out of the specification. > >> Another question I have for section 3.3: Item 2 says, "The Rank of the member of the parent set with the highest advertised Rank plus one". Is that really just "plus one" or should it be "plus MinHopRankIncrease" (i.e. plus one step in integer rank)? > It should be plus one, to maintain the invariant that a node advertises a Rank higher than every element of its parent set. > > I should review these values again to make sure they satisfy all of RPL's invariants. > > Hm -- I should probably also add a note about MaxRankIncrease and how this affects parent selection. > >>>> In section 3.4 ... >>>> >>>> Reading the section further, MRHOF with ETX is exclude from the above requirement. Was that intentional? >>> No -- can you point me to the exact text which leads you to this conclusion, so I can fix it? >> In section 3.4 " >> If ETX is the selected metric, cur_min_path_cost is directly used as >> Rank and never advertised in a metric container. >> " >> If cur_min_path_cost is the path cost through the preferred parent how would the OF (using ETX) advertise the highest path cost of a member in the parent set. Or is it that the second and subsequent sentences in the first paragraph of section 3.4 do not apply to MRHOF when it's using ETX. > Ah, great, thanks. Just wanted to be sure I nail the exact text you see an issue with. > > Phil From jpv@cisco.com Thu Mar 8 23:27:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA3321F865B for ; Thu, 8 Mar 2012 23:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.241 X-Spam-Level: X-Spam-Status: No, score=-110.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-zKhiMvM7Pl for ; Thu, 8 Mar 2012 23:27:20 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74121F8642 for ; Thu, 8 Mar 2012 23:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1573; q=dns/txt; s=iport; t=1331278041; x=1332487641; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hTUVLczoyS1iUi9pixt62/D0Xy6/DMt+hpX8ibUleWk=; b=fwR/2ZhhxM9WTrG+jplr9NyUlJSWc6g5C164s2vprqD56L6mlX39iSMo ZForvQOZm2WZWnF2VMI44qhDB1gPyCsBR2M6JSBaSiTr5abJevLoBhgkg 7npSHDdeT+ZfNg5mqyyqcPIwx93/7UjdTFUUrdZ2VFMHkCjkvTV4eBE6g s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HAGiwWU+Q/khR/2dsb2JhbABDgwmyJ4EHggoBAQEDARIBJzQLBQsLDgouVwY1h2MFC5s7AZ5aBIoohUtjBJVIhWaKNIJkgVs X-IronPort-AV: E=Sophos;i="4.73,556,1325462400"; d="scan'208";a="68053179" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 07:27:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q297RJTj030583; Fri, 9 Mar 2012 07:27: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.4675); Fri, 9 Mar 2012 08:27:19 +0100 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 08:27:18 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <3C6B1EC1-F027-419D-9888-1CA658835816@thomasclausen.org> Date: Fri, 9 Mar 2012 08:27:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <564CFFAB-F589-456A-9F50-25D5CC6EF7CD@cisco.com> References: <9D9885BF-5C06-4DBB-846B-621029FB8B83@cisco.com> <15B9297C-5552-4AB6-A7D9-35B534208FFB@thomasclausen.org> <3C6B1EC1-F027-419D-9888-1CA658835816@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 09 Mar 2012 07:27:18.0789 (UTC) FILETIME=[0F3CB350:01CCFDC6] Cc: roll WG Subject: Re: [Roll] Your draft draft-clausen-lln-rpl-experiences-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 07:27:21 -0000 Hi Thomas, Thanks, looking forward to seeing you in Paris. Kind Regards. JP. On Mar 9, 2012, at 6:37 AM, Thomas Clausen wrote: > Dear JP, >=20 > In accordance with what we promised, the -01 has now been posted, at = the usual URL, and we wanted to notify you and the WG: >=20 > = https://datatracker.ietf.org/doc/draft-clausen-lln-rpl-experiences/ >=20 > Respectfully, and on behalf of all the authors, >=20 > Thomas >=20 > On Mar 8, 2012, at 2:45 PM, JP Vasseur wrote: >=20 >> Thanks Thomas, I'll update the agenda accordingly. >> Kind Regards. >>=20 >> JP. >>=20 >> On Mar 8, 2012, at 1:14 PM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP, >>>=20 >>> Apologies for replying almost a day after your mail - I and the = other authors have been busy updating this document (among other = documents) for the coming deadline. >>>=20 >>> We would, of course, be pleased to present our findings and this = document to the ROLL WG, and we thank you for your kind offer. We will = make sure to announce the -01 to the WG mailing list, as soon as we've = finished our last review and it has hit the IETF servers. >>>=20 >>> Respectfully, and on behalf of all the authors, >>>=20 >>> Thomas >>>=20 >>> On Mar 7, 2012, at 18:59 , JP Vasseur wrote: >>>=20 >>>> Dear Thomas, >>>>=20 >>>> I did not see a request for a slot to discuss = draft-clausen-lln-rpl-experiences-00 at IETF-83. >>>>=20 >>>> Would you be interested in presenting your ID to the WG ? >>>>=20 >>>> Kind Regards. >>>>=20 >>>> JP. >>>=20 >>=20 >=20 From jpv@cisco.com Fri Mar 9 09:23:53 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DECE21F8665 for ; Fri, 9 Mar 2012 09:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPFRpZpBCTHv for ; Fri, 9 Mar 2012 09:23:52 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B021F8682 for ; Fri, 9 Mar 2012 09:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3448; q=dns/txt; s=iport; t=1331313832; x=1332523432; h=from:subject:date:message-id:cc:to:mime-version; bh=eF7SQCVaaHtnzAo3xG4NUahaPvyLXeMNVtxlyzC7KrA=; b=k97wNmFM4EqFkmUJV9Uzkdz9SvKZQGPgwOTrQCuRKx5/UcMWwV1ZWCbR +6bqMQHlfHc74K+rkDepC8KRB/IGlGhI/7wPVAqWuINvuI05BwS9PUfm2 Svsc3AcY8iwx5LuO0ssLiH2BXzQYb1Nx6fSSuA8rqjWrtcJ8fjaWDX+9P Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8FAEc8Wk9Io8UY/2dsb2JhbABCgxazMIIjAWYfgR81h2igDgGXGo93YwSVSYVmijaCZIFb X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="7568918" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 Mar 2012 17:23:50 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29HNoJ5030324; Fri, 9 Mar 2012 17:23:50 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 01:23:49 +0800 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 01:23:49 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_E1CB110B-822B-43B1-849A-090009699ADB" Date: Fri, 9 Mar 2012 18:23:45 +0100 Message-Id: To: roll WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 09 Mar 2012 17:23:49.0538 (UTC) FILETIME=[642F9820:01CCFE19] Cc: Michael Richardson Subject: [Roll] Draft Agenda - ROLL WG Meeting IETF-83 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 17:23:53 -0000 --Apple-Mail=_E1CB110B-822B-43B1-849A-090009699ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for sending via email (experiencing issues with the Web Site), = please find a draft agenda, let us know if you would like to propose any = change: Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 15 mn) [20] 2) The Minimum Rank with Hysteresis Objective Function draft-ietf-roll-minrank-hysteresis-of-06 - (Phil Levis - 5mn) [25] 3) "Applicability Statement for the Routing Protocol for Low Power and = Lossy Networks (RPL) in AMI Networks" - draft-popa-roll-applicability-ami-04 (TBD - 10mn) [35] 4) Update on P2P (Emmanuel - 20mn) [55] * Update on the RPL P2P Work * Updated on draft-ietf-roll-p2p-measurement-02 5) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65] - draft-vanderstok-roll-mcreq-00 6) Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks - draft-clausen-lln-rpl-experiences-01 (Thomas - 10mn) [75] 7) Discussion on Security - 45 mn (Discussion led by Michael) [120] draft-dvir-roll-security-authentication (Amit - 10mn) draft-alexander-roll-amikey-lln-key-mgmt (Roger Alexander TBC - 10mn) draft-qiu-roll-kemp-00 (QIU Ying - 10mn) Open Mic: 15mn JP, David and Michael.= --Apple-Mail=_E1CB110B-822B-43B1-849A-090009699ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry = for sending via email (experiencing issues with the Web Site), please = find a draft agenda, let us know if you would like to propose any = change:

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

1) WG Status (Chairs - 15 mn) = [20]

2) The Minimum Rank with = Hysteresis Objective = Function
draft-ietf-roll-minrank-hysteresis-of-06 - = (Phil Levis - 5mn) [25]

3) = "Applicability Statement for the Routing Protocol for Low Power and = Lossy
Networks (RPL) in AMI Networks" - = draft-popa-roll-applicability-ami-04
(TBD - 10mn) = [35]

4) Update on P2P (Emmanuel - = 20mn) [55]
* Update on the RPL P2P = Work
* Updated on = draft-ietf-roll-p2p-measurement-02

= 5) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65]
- = draft-vanderstok-roll-mcreq-00

6) = Experiences with RPL: IPv6 Routing Protocol for Low power and = Lossy
Networks - draft-clausen-lln-rpl-experiences-01 = (Thomas - 10mn) [75]

7) = Discussion on Security - 45 mn (Discussion led by Michael) = [120]
draft-dvir-roll-security-authentication (Amit - = 10mn)
draft-alexander-roll-amikey-lln-key-mgmt (Roger = Alexander TBC - 10mn)
draft-qiu-roll-kemp-00 (QIU Ying = - 10mn)
Open Mic: = 15mn

JP, David and = Michael.
= --Apple-Mail=_E1CB110B-822B-43B1-849A-090009699ADB-- From jpv@cisco.com Fri Mar 9 09:42:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090DA21F86AB for ; Fri, 9 Mar 2012 09:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLTotwwmsEUv for ; Fri, 9 Mar 2012 09:42:01 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3C21F86D5 for ; Fri, 9 Mar 2012 09:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6826; q=dns/txt; s=iport; t=1331314917; x=1332524517; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=cKeMuHhl9XWDN5XYHpq0ywYXBKy5ocp/PcbqLX59jWI=; b=kAVslfxuyS3Cc1B257p4Gn8k2oVurd0Rh9vRwdyVcDLVfQN4ae65M/0U C23ZnP2uVVa56S8kP1yuhTWFO6HzMa/Laedwx35GcLGykxll0GFmajd9f m0gaVSK+E5xVbXjVRbo8mWVw/dws+E6OPBsmUIULi7UymmiXDl3nvIZH2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4GALxAWk+Q/khN/2dsb2JhbABCgxayKYEHggoBAQEDAQEBAQ8BWwsFCwtGJzAGEyKHYwULoAQBlxkEj3djBJVJhWaKNoJkgVs X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="68115230" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 17:41:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q29Hftnp015271; Fri, 9 Mar 2012 17:41:55 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:41:55 +0100 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:41:54 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_6A1F29EE-DA2E-4663-9DE9-EF5D1A83391D" From: JP Vasseur In-Reply-To: Date: Fri, 9 Mar 2012 18:41:51 +0100 Message-Id: References: To: roll WG X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 09 Mar 2012 17:41:54.0937 (UTC) FILETIME=[EB225690:01CCFE1B] Cc: Michael Richardson Subject: Re: [Roll] Draft Agenda - ROLL WG Meeting IETF-83 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 17:42:02 -0000 --Apple-Mail=_6A1F29EE-DA2E-4663-9DE9-EF5D1A83391D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fixing a typo: Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 15 mn) [20] 2) The Minimum Rank with Hysteresis Objective Function draft-ietf-roll-minrank-hysteresis-of-06 - (Phil Levis - 5mn) [25] 3) "Applicability Statement for the Routing Protocol for Low Power and = Lossy Networks (RPL) in AMI Networks" - draft-ietf-roll-applicability-ami-05 (TBD - 10mn) [35] 4) Update on P2P (Emmanuel - 20mn) [55] * Update on the RPL P2P Work * Updated on draft-ietf-roll-p2p-measurement-02 5) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65] - draft-vanderstok-roll-mcreq-00 6) Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks - draft-clausen-lln-rpl-experiences-01 (Thomas - 10mn) [75] 7) Discussion on Security - 45 mn (Discussion led by Michael) [120] draft-dvir-roll-security-authentication (Amit - 10mn) draft-alexander-roll-amikey-lln-key-mgmt (Roger Alexander - 10mn) draft-qiu-roll-kemp-00 (QIU Ying - 10mn) Open Mic: 15mn On Mar 9, 2012, at 6:23 PM, JP Vasseur wrote: > Sorry for sending via email (experiencing issues with the Web Site), = please find a draft agenda, let us know if you would like to propose any = change: >=20 > Agenda/admin (Chairs - 5mn) [5] >=20 > 1) WG Status (Chairs - 15 mn) [20] >=20 > 2) The Minimum Rank with Hysteresis Objective Function > draft-ietf-roll-minrank-hysteresis-of-06 - (Phil Levis - 5mn) [25] >=20 > 3) "Applicability Statement for the Routing Protocol for Low Power and = Lossy > Networks (RPL) in AMI Networks" - draft-popa-roll-applicability-ami-04 > (TBD - 10mn) [35] >=20 > 4) Update on P2P (Emmanuel - 20mn) [55] > * Update on the RPL P2P Work > * Updated on draft-ietf-roll-p2p-measurement-02 >=20 > 5) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65] > - draft-vanderstok-roll-mcreq-00 >=20 > 6) Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy > Networks - draft-clausen-lln-rpl-experiences-01 (Thomas - 10mn) [75] >=20 > 7) Discussion on Security - 45 mn (Discussion led by Michael) [120] > draft-dvir-roll-security-authentication (Amit - 10mn) > draft-alexander-roll-amikey-lln-key-mgmt (Roger Alexander TBC - 10mn) > draft-qiu-roll-kemp-00 (QIU Ying - 10mn) > Open Mic: 15mn >=20 > JP, David and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_6A1F29EE-DA2E-4663-9DE9-EF5D1A83391D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(TBD - 10mn) [35]






Sorry for sending via = email (experiencing issues with the Web Site), please find a draft = agenda, let us know if you would like to propose any = change:

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

1) WG Status (Chairs - 15 mn) = [20]

2) The Minimum Rank with = Hysteresis Objective = Function
draft-ietf-roll-minrank-hysteresis-of-06 - = (Phil Levis - 5mn) [25]

3) = "Applicability Statement for the Routing Protocol for Low Power and = Lossy
Networks (RPL) in AMI Networks" - = draft-popa-roll-applicability-ami-04
(TBD - 10mn) = [35]

4) Update on P2P (Emmanuel - = 20mn) [55]
* Update on the RPL P2P = Work
* Updated on = draft-ietf-roll-p2p-measurement-02

= 5) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65]
- = draft-vanderstok-roll-mcreq-00

6) = Experiences with RPL: IPv6 Routing Protocol for Low power and = Lossy
Networks - draft-clausen-lln-rpl-experiences-01 = (Thomas - 10mn) [75]

7) = Discussion on Security - 45 mn (Discussion led by Michael) = [120]
draft-dvir-roll-security-authentication (Amit - = 10mn)
draft-alexander-roll-amikey-lln-key-mgmt (Roger = Alexander TBC - 10mn)
draft-qiu-roll-kemp-00 (QIU Ying = - 10mn)
Open Mic: = 15mn

JP, David and = Michael.
_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail=_6A1F29EE-DA2E-4663-9DE9-EF5D1A83391D-- From j.schoenwaelder@jacobs-university.de Fri Mar 9 09:52:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6908F21F8716 for ; Fri, 9 Mar 2012 09:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fpo+fLWXUN09 for ; Fri, 9 Mar 2012 09:52:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA021F8715 for ; Fri, 9 Mar 2012 09:52:22 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DC3920D28; Fri, 9 Mar 2012 18:52:21 +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 b7UA2UzIMpHQ; Fri, 9 Mar 2012 18:52:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09BD620D21; Fri, 9 Mar 2012 18:52:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 065DC1DCAE18; Fri, 9 Mar 2012 18:52:19 +0100 (CET) Date: Fri, 9 Mar 2012 18:52:18 +0100 From: Juergen Schoenwaelder To: JP Vasseur Message-ID: <20120309175218.GA47392@elstar.local> Mail-Followup-To: JP Vasseur , roll WG , Michael Richardson References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michael Richardson , roll WG Subject: Re: [Roll] Draft Agenda - ROLL WG Meeting IETF-83 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 09 Mar 2012 17:52:24 -0000 On Fri, Mar 09, 2012 at 06:23:45PM +0100, JP Vasseur wrote: > Sorry for sending via email (experiencing issues with the Web Site), > please find a draft agenda, let us know if you would like to propose > any change: [...] Hi, I would appreciate to have some time to go over some issues of draft-sehgal-roll-rpl-mib. See also my message from Feb 24. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Fri Mar 9 10:04:54 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3C21E8079; Fri, 9 Mar 2012 10:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw6Kh0Y5kVuo; Fri, 9 Mar 2012 10:04:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC321E804B; Fri, 9 Mar 2012 10:04:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309180454.27147.54571.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 10:04:54 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 18:04:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : The Minimum Rank with Hysteresis Objective Function Author(s) : Omprakash Gnawali Philip Levis Filename : draft-ietf-roll-minrank-hysteresis-of-07.txt Pages : 13 Date : 2012-03-09 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0= 7.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-07= .txt From jpv@cisco.com Fri Mar 9 10:07:20 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7903821E8084 for ; Fri, 9 Mar 2012 10:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.306 X-Spam-Level: X-Spam-Status: No, score=-110.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXrmTEKe6-ES for ; Fri, 9 Mar 2012 10:07:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A627521E807F for ; Fri, 9 Mar 2012 10:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=869; q=dns/txt; s=iport; t=1331316439; x=1332526039; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=s8NIywQsY5P+3VQSQfAC+RuD0MftPbyfYIb/pNkAQlE=; b=mprC9wrfrWB42RiOY8tiJ8Mj6UQOlNG3NRROLEguiX6vrfz2rHLLLU17 LBS9KDTWcrhHR4urHB7xzkjGHWkHul5s+69t2UH5FhCv9V0DiAkAUoGA4 KzRLf0zT+lSamUrn91rH311jQejZJn5plJSARxwFs/3isp7x86uUHre4p 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAAFGWk+Q/khR/2dsb2JhbABAA4MJsimBB4IKAQEBAwESASc/BQkCCw4CCC4bPAY1h2MFnBIBnwMEjU2CRGMElUmFZoo2gmSBWw X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="131865762" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 18:07:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29I7HbN013242; Fri, 9 Mar 2012 18:07:17 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 19:07:17 +0100 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 19:07:16 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <20120309175218.GA47392@elstar.local> Date: Fri, 9 Mar 2012 19:07:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D7F5FE1-93B1-44B0-BE15-57E59B8EDDD3@cisco.com> References: <20120309175218.GA47392@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 09 Mar 2012 18:07:16.0471 (UTC) FILETIME=[760A0070:01CCFE1F] Cc: Michael Richardson , roll WG Subject: Re: [Roll] Draft Agenda - ROLL WG Meeting IETF-83 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 18:07:20 -0000 Dear Juergen, On Mar 9, 2012, at 6:52 PM, Juergen Schoenwaelder wrote: > On Fri, Mar 09, 2012 at 06:23:45PM +0100, JP Vasseur wrote: >=20 >> Sorry for sending via email (experiencing issues with the Web Site), >> please find a draft agenda, let us know if you would like to propose >> any change: >=20 > [...] >=20 > Hi, >=20 > I would appreciate to have some time to go over some issues of > draft-sehgal-roll-rpl-mib. See also my message from Feb 24. >=20 I do remember, give us a few days to see if we can find time in the = agenda, since your I-D is not yet in our charter. Thanks. JP. > Thanks, >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From pal@cs.stanford.edu Fri Mar 9 10:10:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41A321E8058 for ; Fri, 9 Mar 2012 10:10:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf2OrpiWLzvv for ; Fri, 9 Mar 2012 10:10:26 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6221E8087 for ; Fri, 9 Mar 2012 10:10:26 -0800 (PST) Received: from dn0a210245.sunet ([10.33.2.69]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S64Gm-0007WM-8j; Fri, 09 Mar 2012 10:10:24 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Philip Levis In-Reply-To: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> Date: Fri, 9 Mar 2012 10:09:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> To: roll-chairs@tools.ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, adrian@olddog.co.uk, roll@ietf.org X-Mailer: Apple Mail (2.1257) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 18:10:27 -0000 On Mar 9, 2012, at 10:04 AM, internet-drafts@ietf.org wrote: > New version (-07) has been submitted for = draft-ietf-roll-minrank-hysteresis-of-07.txt. > = http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-= 07.txt >=20 >=20 > Diff from previous version: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-minrank-hysteresis-of= -07 >=20 > IETF Secretariat. >=20 Significant changes: 1. Reworded Rank calculation text so it is clearly max(calculated Rank, = (advertised Rank + MinHopRankIncrease)) 2. Clarified "Rank associated with path" to "Rank calculated for path" 3. Added note about how case 3 of Rank advertisement places a tradeoff = between parent set size and Rank advertisement precision 4. Clarified text about the ETX case based on feedback: this added some = BOLD requirements; feedback greatly appreciated. Phil From gnawali@cs.uh.edu Sat Mar 10 17:36:52 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F9821F8554 for ; Sat, 10 Mar 2012 17:36: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNvXZ7MyOXrh for ; Sat, 10 Mar 2012 17:36:51 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id C540521F8497 for ; Sat, 10 Mar 2012 17:36:51 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 7ABD723CA85 for ; Sat, 10 Mar 2012 19:36:53 -0600 (CST) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7uUwQ9JWBDC for ; Sat, 10 Mar 2012 19:36:51 -0600 (CST) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D2A0D23CA86 for ; Sat, 10 Mar 2012 19:36:51 -0600 (CST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by it.cs.uh.edu (Postfix) with ESMTP id 3A34B5490001 for ; Sat, 10 Mar 2012 20:03:35 -0600 (CST) Received: by werb10 with SMTP id b10so2685745wer.31 for ; Sat, 10 Mar 2012 17:36:48 -0800 (PST) Received: by 10.216.135.69 with SMTP id t47mr4261028wei.85.1331429808425; Sat, 10 Mar 2012 17:36:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.91.69 with HTTP; Sat, 10 Mar 2012 17:36:27 -0800 (PST) In-Reply-To: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> From: Omprakash Gnawali Date: Sun, 11 Mar 2012 01:36:27 +0000 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Mar 2012 01:36:52 -0000 Dear ROLL WG, I just refreshed this draft with comments from JP, Cedric, Joakim, and Ulrich. Please keep your comments coming, especially those who have implemented and deployed RPL. Thanks. - om_p ---------- Forwarded message ---------- From: Date: Sun, Mar 11, 2012 at 1:34 AM Subject: New Version Notification for draft-gnawali-roll-rpl-recommendations-03.txt To: gnawali@cs.uh.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL Creation date: =A0 2012-03-10 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 6 Abstract: =A0 RPL is a flexible routing protocol applicable to a wide range of Low =A0 Power and Lossy Networks. =A0To enable this wide applicability, RPL =A0 provides many configuration options and gives implementers choices on =A0 how to implement various components of RPL. =A0Drawing on our =A0 experiences, we distill the design choices and configuration =A0 parameters that lead to efficient RPL implementations and operations. The IETF Secretariat From jpv@cisco.com Sun Mar 11 03:13:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8020421F86A5 for ; Sun, 11 Mar 2012 03:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.265 X-Spam-Level: X-Spam-Status: No, score=-107.265 tagged_above=-999 required=5 tests=[AWL=3.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBeaTTypl4-9 for ; Sun, 11 Mar 2012 03:13:12 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id A258721F869E for ; Sun, 11 Mar 2012 03:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7168; q=dns/txt; s=iport; t=1331460792; x=1332670392; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=+1Zi0ii1rcqzLvI4zyF66G1JClTrFqJB2CXt4GktGAY=; b=HS9SEvicVC1LdbEdmiGkXBk2N7FCVGcHyJe6fMM2ZY4+12g+2YP8kH9Z jCXBSQmNJKuZ8ycibBA8B/XYobrCIe14J3pTRqEQTItKKZ22nyHJxd+Mo twNEDcYqNwE5Qt4wmf9PdNtoioB8GPhZKMgzM/bl77305o7YuqgpWlMh6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQGAIV6XE9Io8UY/2dsb2JhbABCDoMIsz+CCQEBAQMBAQEBDwFbCwULHAMBAi8nKAgGEyKHYwULn2oBlgYEkB5jBJVMhWmKOoIsOA X-IronPort-AV: E=Sophos;i="4.73,566,1325462400"; d="scan'208,217";a="7613655" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 11 Mar 2012 10:13:10 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2BAD98f008553; Sun, 11 Mar 2012 10:13:09 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 18:13:09 +0800 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 18:13:08 +0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_19F448BB-52D3-4E13-85CC-2C1387428584" From: JP Vasseur In-Reply-To: Date: Sun, 11 Mar 2012 11:13:06 +0100 Message-Id: <6D6A454F-E77F-4857-8FB4-182A36442BAA@cisco.com> References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 11 Mar 2012 10:13:08.0786 (UTC) FILETIME=[8EB94120:01CCFF6F] Cc: ROLL WG Subject: [Roll] Slight modification of the agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Mar 2012 10:13:13 -0000 --Apple-Mail=_19F448BB-52D3-4E13-85CC-2C1387428584 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 New Agenda: Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 15 mn) [20] 2) The Minimum Rank with Hysteresis Objective Function draft-ietf-roll-minrank-hysteresis-of-06 - (Phil Levis - 5mn) [25] 3) Recommendations for Efficient Implementation of RPL (Phil - 5mn) [30] draft-gnawali-roll-rpl-recommendations-03 4) "Applicability Statement for the Routing Protocol for Low Power and = Lossy Networks (RPL) in AMI Networks" - draft-ietf-roll-applicability-ami-05 (TBD - 10mn) [40] 5) Update on P2P (Emmanuel - 15mn) [55] * Update on the RPL P2P Work * Updated on draft-ietf-roll-p2p-measurement-02 6) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65] - draft-vanderstok-roll-mcreq-00 7) Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks - draft-clausen-lln-rpl-experiences-01 (Thomas - 10mn) [75] 8) Discussion on Security - 45 mn (Discussion led by Michael) [120] draft-dvir-roll-security-authentication (Amit - 10mn) draft-alexander-roll-amikey-lln-key-mgmt (Roger Alexander - 10mn) draft-qiu-roll-kemp-00 (QIU Ying - 10mn) Open Mic: 15mn JP. On Mar 11, 2012, at 2:36 AM, Omprakash Gnawali wrote: > Dear ROLL WG, >=20 > I just refreshed this draft with comments from JP, Cedric, Joakim, and > Ulrich. Please keep your comments coming, especially those who have > implemented and deployed RPL. >=20 > Thanks. >=20 > - om_p >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Mar 11, 2012 at 1:34 AM > Subject: New Version Notification for > draft-gnawali-roll-rpl-recommendations-03.txt > To: gnawali@cs.uh.edu > Cc: pal@cs.stanford.edu >=20 >=20 > A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. >=20 > Filename: draft-gnawali-roll-rpl-recommendations > Revision: 03 > Title: Recommendations for Efficient Implementation of RPL > Creation date: 2012-03-10 > WG ID: Individual Submission > Number of pages: 6 >=20 > Abstract: > RPL is a flexible routing protocol applicable to a wide range of Low > Power and Lossy Networks. To enable this wide applicability, RPL > provides many configuration options and gives implementers choices = on > how to implement various components of RPL. Drawing on our > experiences, we distill the design choices and configuration > parameters that lead to efficient RPL implementations and = operations. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_19F448BB-52D3-4E13-85CC-2C1387428584 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 New = Agenda:

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

1) WG Status (Chairs - 15 mn) = [20]

2) The Minimum Rank with = Hysteresis Objective = Function
draft-ietf-roll-minrank-hysteresis-of-06 - = (Phil Levis - 5mn) [25]

3) = Recommendations for Efficient Implementation of RPL (Phil - 5mn) = [30]
draft-gnawali-roll-rpl-recommendations-03
<= div>
4) "Applicability Statement for the Routing = Protocol for Low Power and Lossy
Networks (RPL) in AMI = Networks" - draft-ietf-roll-applicability-ami-05
(TBD - = 10mn) [40]

5) Update on P2P = (Emmanuel - 15mn) [55]
* Update on the RPL P2P = Work
* Updated on = draft-ietf-roll-p2p-measurement-02

= 6) Multicast requirements for control over LLN (Peter van der stok - = 10mn) [65]
- = draft-vanderstok-roll-mcreq-00

7) = Experiences with RPL: IPv6 Routing Protocol for Low power and = Lossy
Networks - draft-clausen-lln-rpl-experiences-01 = (Thomas - 10mn) [75]

8) = Discussion on Security - 45 mn (Discussion led by Michael) = [120]
draft-dvir-roll-security-authentication (Amit - = 10mn)
draft-alexander-roll-amikey-lln-key-mgmt (Roger = Alexander - 10mn)
draft-qiu-roll-kemp-00 (QIU Ying - = 10mn)
Open Mic: = 15mn

JP.

On = Mar 11, 2012, at 2:36 AM, Omprakash Gnawali wrote:

Dear = ROLL WG,

I just refreshed this draft with comments from JP, = Cedric, Joakim, and
Ulrich. Please keep your comments coming, = especially those who have
implemented and deployed = RPL.

Thanks.

- om_p

---------- Forwarded message = ----------
From:  <internet-drafts@ietf.org><= br>Date: Sun, Mar 11, 2012 at 1:34 AM
Subject: New Version = Notification for
draft-gnawali-roll-rpl-recommendations-03.txt
To: = gnawali@cs.uh.edu
Cc: pal@cs.stanford.edu


A = new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt
has = been successfully submitted by Omprakash Gnawali and posted to = the
IETF repository.

Filename:       =  draft-gnawali-roll-rpl-recommendations
Revision:     =    03
Title:           = Recommendations for Efficient Implementation of RPL
Creation date: =   2012-03-10
WG ID:           = Individual Submission
Number of pages: 6

Abstract:
  = RPL is a flexible routing protocol applicable to a wide range of = Low
  Power and Lossy Networks.  To enable this wide = applicability, RPL
  provides many configuration options and = gives implementers choices on
  how to implement various = components of RPL.  Drawing on our
  experiences, we = distill the design choices and configuration
  parameters that = lead to efficient RPL implementations and = operations.




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

= --Apple-Mail=_19F448BB-52D3-4E13-85CC-2C1387428584-- From peter.van.der.stok@philips.com Mon Mar 12 03:50:52 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FC321F8713 for ; Mon, 12 Mar 2012 03:50:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiKt9GMsBb0p for ; Mon, 12 Mar 2012 03:50:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2821F86DD for ; Mon, 12 Mar 2012 03:50:51 -0700 (PDT) Received: from mail153-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Mar 2012 10:50:50 +0000 Received: from mail153-tx2 (localhost [127.0.0.1]) by mail153-tx2-R.bigfish.com (Postfix) with ESMTP id 408DF440159 for ; Mon, 12 Mar 2012 10:50:50 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz217bL15d6O9251J936eKc85fhzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail153-tx2 (localhost.localdomain [127.0.0.1]) by mail153-tx2 (MessageSwitch) id 1331549448476387_6829; Mon, 12 Mar 2012 10:50:48 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.238]) by mail153-tx2.bigfish.com (Postfix) with ESMTP id 6580A24004A for ; Mon, 12 Mar 2012 10:50:48 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Mar 2012 10:50:47 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.139]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 10:52:22 +0000 From: "Stok, Peter van der" To: "roll@ietf.org" Thread-Topic: new draft submitted: draft-vanderstok-roll-mcreq-01.txt Thread-Index: Ac0APelOb303XGEzTgerkLZrS279HQ== Date: Mon, 12 Mar 2012 10:52:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.102] Content-Type: multipart/alternative; boundary="_000_A31CB84F6F0BFC449C6807DF752A715B03DB1A011DB3MPN1061MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [Roll] new draft submitted: draft-vanderstok-roll-mcreq-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2012 10:50:52 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B03DB1A011DB3MPN1061MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A 01 version of draft : draft-vanderstok-roll-mcreq-01.txt has been submitt= ed. This version includes comments received on version 0 and removes inconsiste= ncies in the text. Meta-Data from the Draft Document draft-vanderstok-roll-mcreq [View first two pages] Revision 01 WG Individual Submission Document date 2012-03-12 Submission date 2012-03-12 Title Multicast requirements for control over LLN Author information Author 1 Peter van der Stok Abstract This is a working document intended to focus discussion on requirements for multicast in Low-power and Lossy Networks in the area of M2M communication for control purposes. The Trickle algorithm, which uses re-broadcasting to assure that messages arrive at all destinations, is proposed as the ROLL multicast protocol. In this draft additional requirements on Trickle, such as timeliness and ordering, are motivated by building control. Re-broadcasting and timeliness can be mutually exclusive properties. To alleviate that problem, this draft considers minimizing re-broadcast by limiting the number of re-broadcasting devices in the wireless network. Pages 11 File size 22.8 KB Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A31CB84F6F0BFC449C6807DF752A715B03DB1A011DB3MPN1061MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A 01 version of draft : draft-vanderstok-roll-mcreq-= 01.txt has been submitted.

This version includes comments received on version 0= and removes inconsistencies in the text.

 

Me= ta-Data from the Draft

Document

draft-vanderstok-roll-mcreq
[View first two pages]

Revision

01

WG

Individual Submission

Document date

2012-03-12

Submission date

2012-03-12

Title

Multicast requirements for control over = LLN

Author information

Author 1

Peter van der Stok <peter= .van.der.stok@philips.com>

Abstract

This is a working document intended to f= ocus discussion on
requirements for multicast in Low-power and Lossy Networks in the
area of M2M communication for control purposes. The Trickle
algorithm, which uses re-broadcasting to assure that messages arrive
at all destinations, is proposed as the ROLL multicast protocol. In
this draft additional requirements on Trickle, such as timeliness and
ordering, are motivated by building control. Re-broadcasting and
timeliness can be mutually exclusive properties. To alleviate that
problem, this draft considers minimizing re-broadcast by limiting the
number of re-broadcasting devices in the wireless network.

Pages

11

File size

22.8 KB

 

 

Peter van der Stok

Philips Research Laboratories Eind= hoven

High Tech Campus       &nb= sp;            =             &nb= sp;            =              HT= C 34 (WB) 1-067

5656 AA Eindhoven       &n= bsp;            = ;            &n= bsp;            = ;         The Netherlands

phone +31 40 2749657      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A31CB84F6F0BFC449C6807DF752A715B03DB1A011DB3MPN1061MGDP_-- From prvs=411ee4bd1=Roger.Alexander@cooperindustries.com Mon Mar 12 07:11:05 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF021F85AF for ; Mon, 12 Mar 2012 07:11:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DSgkFJ5eIff for ; Mon, 12 Mar 2012 07:11:04 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1ED21F8672 for ; Mon, 12 Mar 2012 07:11:03 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.73,570,1325480400"; d="scan'208";a="45139882" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Mar 2012 10:11:01 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 10:11:02 -0400 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, 12 Mar 2012 10:11:01 -0400 Message-ID: <85A23E0910B2FB4B8EF60D0888CB08365611D7@EVS2.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-03.txt Thread-Index: Ac0AWBt57YEIJ2GsT6yInIAJ+YeQqAAAEsIA From: "Alexander, Roger" To: X-OriginalArrivalTime: 12 Mar 2012 14:11:02.0443 (UTC) FILETIME=[F4E637B0:01CD0059] Cc: "Tsao, Tzeta" Subject: [Roll] FW: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2012 14:11:05 -0000 RGVhciBXRywNCg0KQW4gdXBkYXRlIG9mIHRoZSBwcm9wb3NlZCBSUEwga2V5IG1hbmFnZW1lbnQg SS1EIGlzIGF2YWlsYWJsZSBhdCB0aGUgVVJMIGJlbG93LiBUaGlzIHVwZGF0ZSBpbmNvcnBvcmF0 ZXMgYSBuZXcgc2VjdGlvbiAzLjQuMSB3aGljaCBwcm92aWRlcyBzcGVjaWZpYyBleGFtcGxlcyBv ZiBBTUlLRVkgYXBwbGllZCBmb3Iga2V5IG1hbmFnZW1lbnQgaW4gUlBMLiBUaGUgbWF0ZXJpYWwg aXMgYmFzZWQgb24gaW5mb3JtYXRpb24gdGhhdCB3YXMgcHJldmlvdXNseSBwb3N0ZWQgdG8gdGhl IFdHIGxpc3QgYW5kIHByb3ZpZGVkIGZvciBwcmVzZW50YXRpb24gYXQgdGhlIElFVEYtODIgbWVl dGluZy4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWVkLg0KDQpUaGFua3MsDQoNClJvZ2VyDQoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5 LWxsbi1rZXktbWdtdC8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IE1vbmRheSwgTWFyY2ggMTIsIDIwMTIgOTo1OCBBTQ0KVG86IEFsZXhhbmRlciwgUm9n ZXINCkNjOiBUc2FvLCBUemV0YQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cmRyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wMy50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0w My50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2dlciBLLiBBbGV4YW5k ZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdA0KUmV2aXNpb246CSAwMw0KVGl0bGU6 CQkgQWRhcHRlZCBNdWx0aW1lZGlhIEludGVybmV0IEtFWWluZyAoQU1JS0VZKTogQW4gZXh0ZW5z aW9uIG9mIE11bHRpbWVkaWEgSW50ZXJuZXQgS0VZaW5nIChNSUtFWSkgTWV0aG9kcyBmb3IgR2Vu ZXJpYyBMTE4gRW52aXJvbm1lbnRzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wMy0xMg0KV0cgSUQ6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQyDQoNCkFic3RyYWN0 Og0KICAgTXVsdGltZWRpYSBJbnRlcm5ldCBLZXlpbmcgKE1JS0VZKSBpcyBhIGtleSBtYW5hZ2Vt ZW50IHByb3RvY29sIHVzZWQNCiAgIGZvciByZWFsLXRpbWUgYXBwbGljYXRpb25zLiAgQXMgc3Rh bmRhcmRpemVkIHdpdGhpbiBSRkMzODMwIGl0DQogICBkZWZpbmVzIGZvdXIga2V5IGRpc3RyaWJ1 dGlvbiBtZXRob2RzLCBpbmNsdWRpbmcgcHJlLXNoYXJlZCBrZXlzLA0KICAgcHVibGljLWtleSBl bmNyeXB0aW9uLCBhbmQgRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlLCB3aXRoDQogICBhbGxv d2FuY2VzIGZvciByZWFkeSBwcm90b2NvbCBleHRlbnNpb24uICBBIG51bWJlciBvZiBhZGRpdGlv bmFsDQogICBtZXRob2RzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIGNvbnRpbnVlIHRvIGJlIGJ1 aWx0IGZyb20gdGhlIGJhc2UNCiAgIHByb3RvY29sIChzZWUgZm9yIGV4YW1wbGUsIFJGQzQ0NDIs IFJGQzQ1NjMsIFJGQzQ2NTAsIFJGQzQ3MzgsDQogICBSRkM1NDEwLCBSRkM2MDQzIGFuZCBSRkM2 MjY3LiAgSG93ZXZlciwgaW4gc3BpdGUgb2YgaXRzIGV4dGVuc2liaWxpdHkNCiAgIGFuZCBtb3Jl IGdlbmVyYWwgYXBwbGljYWJpbGl0eSwgTUlLRVkgYW5kIGl0cyByZWxhdGVkIGV4dGVuc2lvbnMg aGF2ZQ0KICAgcHJpbWFyaWx5IGZvY3VzZWQgb24gdGhlIHN1cHBvcnQgb2YgdGhlIFNlY3VyZSBS ZWFsLXRpbWUgVHJhbnNwb3J0DQogICBQcm90b2NvbCAoU1JUUCkuDQoNCiAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGEgc2ltcGxlIGFkYXB0YXRpb24gb2YgdGhlIE1JS0VZDQogICBzcGVjaWZp Y2F0aW9uIHRvIGFsbG93IHRoZSBiYXNlIHByb3RvY29sIGFuZCBpdHMgdmFyaW91cyBrZXkNCiAg IG1hbmFnZW1lbnQgbW9kZSBleHRlbnNpb25zIHRvIGJlIHJlYWRpbHkgYXBwbGllZCBpbiBtb3Jl IGdlbmVyYWwNCiAgIGVudmlyb25tZW50cyBiZXlvbmQgdGhlIG11bHRpbWVkaWEgU1JUUCBkb21h aW4uICBJbiBwYXJ0aWN1bGFyLCB0aGUNCiAgIGRvY3VtZW50IGRlZmluZXMgYSByZXB1cnBvc2lu ZyBvZiB0aGUgTUlLRVkgbXVsdGltZWRpYSBjcnlwdG8NCiAgIHNlc3Npb25zIHN0cnVjdHVyZSBh bmQgaW50cm9kdWNlcyBhIHNldCBvZiBtZXNzYWdlIGV4dGVuc2lvbnMgdG8gdGhlDQogICBiYXNl IHNwZWNpZmljYXRpb24gdG8gYWxsb3cgdGhlIE1JS0VZIGtleSBtYW5hZ2VtZW50IG1ldGhvZHMg dG8gYmUNCiAgIGFwcGxpZWQgd2l0aGluIExvdy1wb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgKExM TnMpIGFuZCBvdGhlciBnZW5lcmFsDQogICBjb25zdHJhaW5lZC1kZXZpY2UgbmV0d29ya3MuDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From iesg-secretary@ietf.org Mon Mar 12 09:46:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7BC21F87FD; Mon, 12 Mar 2012 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtGyHeAJcRhY; Mon, 12 Mar 2012 09:46:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB5821F87BF; Mon, 12 Mar 2012 09:46:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312164620.27993.19357.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 09:46:20 -0700 Cc: roll@ietf.org Subject: [Roll] Last Call: (The Minimum Rank with Hysteresis Objective Function) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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, 12 Mar 2012 16:46:21 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'The Minimum Rank with Hysteresis Objective Function' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-06 (date set to longer than 2 weeks to allow for IETF meeting). Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ballot/ No IPR declarations have been submitted directly on this I-D. From adrian@olddog.co.uk Tue Mar 13 15:36:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE021E802F for ; Tue, 13 Mar 2012 15:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAVi9wumjkqp for ; Tue, 13 Mar 2012 15:36:41 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id EF7F321E8028 for ; Tue, 13 Mar 2012 15:36:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2DMadrs030618 for ; Tue, 13 Mar 2012 22:36:39 GMT Received: from 950129200 ([90.84.144.128]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2DMaXtW030577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Mar 2012 22:36:37 GMT From: "Adrian Farrel" To: References: <20120313222911.19346.18511.idtracker@ietfa.amsl.com> In-Reply-To: <20120313222911.19346.18511.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2012 22:36:36 -0000 Message-ID: <012b01cd0169$c2c1d850$484588f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFvgRCdiG1lmsk0CmGozmytJxNFL5cj0TnA Content-Language: en-gb Subject: [Roll] FW: New Non-WG Mailing List: its -- Intelligent Transportation Systems X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:36:41 -0000 FYI > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: 13 March 2012 22:29 > To: IETF Announcement List > Cc: alexandru.petrescu@gmail.com; thierry.ernst@inria.fr; its@ietf.org > Subject: New Non-WG Mailing List: its -- Intelligent Transportation Systems > > A new IETF non-working group email list has been created. > > List address: its@ietf.org > Archive: http://www.ietf.org/mail-archive/web/its/ > To subscribe: https://www.ietf.org/mailman/listinfo/its > > Purpose: This list is for discussions relative to the use of Internet > communication protocols in Intelligent Transportation Systems. This > includes but is not limited to vehicular communications. The particular > topics to be addressed are to be shaped up in this list. Standards > Development Organizations considered are IEEE 802.11p, ETSI ITS, and ISO. > > For additional information, please contact the list administrators. From koo@comnets.uni-bremen.de Tue Mar 13 22:14:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC9921F85A5 for ; Tue, 13 Mar 2012 22:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtGBxSmfwxMW for ; Tue, 13 Mar 2012 22:14:14 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5421F8594 for ; Tue, 13 Mar 2012 22:14:13 -0700 (PDT) Received: from koojanalaptop (unknown [10.8.0.34]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id E5399D403FE; Wed, 14 Mar 2012 06:14:11 +0100 (CET) From: "Koojana Kuladinithi" To: "'ROLL WG'" , "'Omprakash Gnawali'" References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 14 Mar 2012 06:14:23 +0100 Message-ID: <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz/J3KyB8YUAMhaS2OHy7o9LMQ2fgCd3S/w Content-Language: en-us Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2012 05:14:14 -0000 Hi, I read your draft. We have done some tests with TinyRPL (RPL = implementation in TinyOS) in container filled with fruits. In one test, we had a situation that the border router (RPL root node) = was disconnected for several hours. The sensor nodes start sending DIS (DIS-INTERVAL was set to 3 sec for this test). We found that this = degrades the use of battery voltage. One alternative is to use a higher value = for DIS-INTERVAL. In real deployment, the RPL root node should setup at the last, after loading all the sensors.=20 I would like to know -> Why is DIS sending at a constant interval (I am not sure this is set constant only in the implementation)? Should it be adaptive if it does = not receive a DIO?=20 Is this an issue ("setting of DIS INTERVAL for different cases") that = your draft should address? Kind regards Koojana =20 =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Omprakash Gnawali > Sent: Sunday, March 11, 2012 2:36 AM > To: ROLL WG > Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll- > rpl-recommendations-03.txt >=20 > Dear ROLL WG, >=20 > I just refreshed this draft with comments from JP, Cedric, Joakim, and > Ulrich. Please keep your comments coming, especially those who have > implemented and deployed RPL. >=20 > Thanks. >=20 > - om_p >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Mar 11, 2012 at 1:34 AM > Subject: New Version Notification for > draft-gnawali-roll-rpl-recommendations-03.txt > To: gnawali@cs.uh.edu > Cc: pal@cs.stanford.edu >=20 >=20 > A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. >=20 > Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations > Revision: =A0 =A0 =A0 =A003 > Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient = Implementation of RPL > Creation date: =A0 2012-03-10 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 6 >=20 > Abstract: > =A0 RPL is a flexible routing protocol applicable to a wide range of = Low > =A0 Power and Lossy Networks. =A0To enable this wide applicability, = RPL > =A0 provides many configuration options and gives implementers choices = on > =A0 how to implement various components of RPL. =A0Drawing on our > =A0 experiences, we distill the design choices and configuration > =A0 parameters that lead to efficient RPL implementations and = operations. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Alireza.Sahami@vis.uni-stuttgart.de Wed Mar 14 10:33:28 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28D21E8010; Wed, 14 Mar 2012 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJvVBTHjBOVR; Wed, 14 Mar 2012 10:33:27 -0700 (PDT) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.informatik.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 62E2221F8758; Wed, 14 Mar 2012 10:33:26 -0700 (PDT) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.02.0247.003; Wed, 14 Mar 2012 18:33:24 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: INSS 2012 - Call for Demo (Deadline extended: March 18,2012) Thread-Index: AQHNAgiOLDg5KfUAiUS81Kphx6FkrA== Date: Wed, 14 Mar 2012 17:33:24 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.69.180.23] Content-Type: multipart/alternative; boundary="_000_CB8694F32C400alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 15 Mar 2012 08:03:00 -0700 Subject: [Roll] INSS 2012 - Call for Demo (Deadline extended: March 18, 2012) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2012 17:33:28 -0000 --_000_CB8694F32C400alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept our apology if you receive this announcement through multiple= lists) ********************************************************************** FINAL CALL FOR DEMONSTRATIONS - !EXTENDED DEADLINE! INSS 2012 - The Ninth International Conference of Networked Sensing Systems Antwerp, Belgium, June 11-14, 2012 EXTENDED SUBMISSION DEADLINE: March 18, 2012 (IEEEXplore publication) http://www.inss-conf.org/2012/cfd.shtml ********************************************************************** During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as THE scientific event where academic = and industrial experts from the areas of sensor systems, wireless networks,= and sensor network applications come together. The INSS provides a forum to hear about the latest developments in these ar= eas, to exchange ideas, and to start up collaborations within these fields = and between industry and academia. Demonstrations are a great way to exchange and present latest research resu= lts, creative ideas and innovative applications in an open, living fashion.= Our experience from recent INSS conferences revealed that they promote int= ense and fruitful discussions with interested participants from industry an= d academia to exchange knowledge, novel methodologies, new concepts and new= perceptions directly. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research from the fie= ld of sensor technology, wireless networking, or application of networked s= ensor systems (for full list of topics please refer to http://www.inss-conf= .org/2012/cfp.shtml). The conference especially encourages submissions that address research issu= es shared between those areas. ********************************************************************** You are invited to submit a demo proposal to INSS 2012 either as a separate= contribution or as a companion to an accepted paper in the conference. Sub= missions from both industries and universities are encouraged. Separate demo contributions will be peer- reviewed and evaluated on the bas= is of originality, technical correctness, and presentation. Extended abstr= acts must be 1-2 pages long (two-column format). Abstracts should be forma= tted according to the IEEE transactions format. All accepted submissions w= ill be published at IEEE Xplore digital library. Authors are required to de= monstrate their work during the conference. All submissions including the companion submissions should additionally fea= ture a short, informal description of the demo setup. Submissions should be in PDF format and will be handled through EasyChair: http://www.easychair.org/conferences/?conf=3Dinss2012demos ********************************************************************** The EXTENDED SUBMISSION DEADLINE for extended abstracts is March 18, 2012. If you have any inquiries about submissions please don't hesitate to contac= t the demo chairs. ********************************************************************** Mathieu Boussard(mathieu.boussard@alcatel-lucent.com) Till Riedel (riedel@teco.edu) (Demo Co-Chairs) Demo Program Comittee Members: Felix B=FCsching (TU Braunschweig) Matthias Kranz (TU Munich) Simon Mayer (ETH Zurich) Phil Scholl (TU Darmstadt) --_000_CB8694F32C400alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0B3C693DE6452D4C908FC8D2F826ECB4@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
Please accept our apology if you receive this announcement through multiple= lists)

**********************************************************************

FINAL CALL FOR DEMONSTRATIONS - !EXTENDED DEADLINE!

INSS 2012 - The Ninth International Conference of Networked Sensing Systems=
Antwerp, Belgium, June 11-14, 2012

EXTENDED SUBMISSION DEADLINE: March 18, 2012
(IEEEXplore publication)

http://www.inss-conf.org/2012/cfd.shtml

**********************************************************************

During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as THE scientific event where academic = and industrial experts from the areas of sensor systems, wireless networks,= and sensor network applications come together.

The INSS provides a forum to hear about the latest developments in these ar= eas, to exchange ideas, and to start up collaborations within these fields = and between industry and academia.

Demonstrations are a great way to exchange and present latest research resu= lts, creative ideas and innovative applications in an open, living fashion.= Our experience from recent INSS conferences revealed that they promote int= ense and fruitful discussions with interested participants from industry and academia to exchange knowledge, = novel methodologies, new concepts and new perceptions directly.

INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research from the fie= ld of sensor technology, wireless networking, or application of networked s= ensor systems (for full list of topics please refer to http://www.inss-conf.org/2012/cfp.shtml).

The conference especially encourages submissions that address research issu= es shared between those areas.

**********************************************************************

You are invited to submit a demo proposal to INSS 2012 either as a separate= contribution or as a companion to an accepted paper in the conference. Sub= missions from both industries and universities are encouraged.

Separate demo contributions will be peer- reviewed and evaluated on the bas= is of originality, technical correctness, and presentation.  Extended = abstracts must be 1-2 pages long (two-column format).  Abstracts shoul= d be formatted according to the IEEE transactions format.  All accepted submissions will be published at IEEE Xplore di= gital library. Authors are required to demonstrate their work during the co= nference.

All submissions including the companion submissions should additionally fea= ture a short, informal description of the demo setup.

Submissions should be in PDF format and will be handled through EasyChair:<= /div>

http://www.easychair.org/conferences/?conf=3Dinss2012demos

**********************************************************************

The EXTENDED SUBMISSION DEADLINE for extended abstracts is 
March 18, 2012.

If you have any inquiries about submissions please don't hesitate to contac= t the demo chairs.

**********************************************************************

Mathieu Boussard(mathieu.boussard@alcatel-lucent.com)
Till Riedel (riedel@teco.edu)

(Demo Co-Chairs)

Demo Program Comittee Members:

Felix B=FCsching (TU Braunschweig)
Matthias Kr= anz (TU Munich)
Simon Mayer= (ETH Zurich)
Phil Scholl= (TU Darmstadt) 
--_000_CB8694F32C400alirezasahamivisunistuttgartde_-- From jpv@cisco.com Fri Mar 16 00:14:31 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6121F870B for ; Fri, 16 Mar 2012 00:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.934 X-Spam-Level: X-Spam-Status: No, score=-109.934 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffuD5nWFmjgf for ; Fri, 16 Mar 2012 00:14:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AC27B21F870A for ; Fri, 16 Mar 2012 00:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4781; q=dns/txt; s=iport; t=1331882070; x=1333091670; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=nOHAf5PEUsKp2a+P4CGuPqywsp23aAA0tTwv1AmvoYA=; b=l4uvzHKSPLkvWVUi+Y4LTD/QZsM+owLEd3fUJBTGQ1PuOd6ZJGW4TSfk m5coX5Hy81cwD7FyIJOVDhQE61DYVkyNLss/bzpQ9mejcq2TypbkYWwsk /8BQzgthX+gId0MWVT9IB2hMFqY3nSXu5/pd0uLnOR7xpCyjRskV/JLwZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsIAPbmYk+rRDoI/2dsb2JhbABDgwyqMAGIdIEHggkBAQECAQEBAQEPAVQHEAsLBEInMAYTIodjBAELmm2efpAWYwSVYoVsiFOBaIJn X-IronPort-AV: E=Sophos;i="4.73,595,1325462400"; d="scan'208,217";a="33263782" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 16 Mar 2012 07:14:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2G7EUud022793 for ; Fri, 16 Mar 2012 07:14:30 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 00:14:30 -0700 Received: from [10.60.114.235] ([10.60.114.235]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 00:14:29 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F488E330-EB78-4445-8FA3-20920AA21B71" Date: Fri, 16 Mar 2012 08:14:27 +0100 In-Reply-To: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> To: ROLL WG References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> Message-Id: <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 16 Mar 2012 07:14:29.0835 (UTC) FILETIME=[6DCBE1B0:01CD0344] Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 07:14:31 -0000 --Apple-Mail=_F488E330-EB78-4445-8FA3-20920AA21B71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is just a reminder that we have 2 documents in WG Last Call, which = will terminate on March 29, at noon. Comments appreciated. Thanks. JP. On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote: > Dear all, >=20 > The two documents draft-ietf-roll-p2p-measurement and = draft-ietf-roll-p2p-rpl have been discussed on the mailing list and = during=20 > WG meetings for some time, there several implementations that are now = stable, and the authors believe that the documents are > ready for WG Last Call. >=20 > Thus, this starts a Working Group Last Call on: > * draft-ietf-roll-p2p-measurement-04 > and > * draft-ietf-roll-p2p-rpl-09 >=20 > Furthermore, an interoperability was carried out last month with = INRIA's implementation against Sigma Design's implementation. > The report can be found: = http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf >=20 > Experiments with P2P-RPL have also taken place on the Senslab testbed = gathering boards based on MSP430 and 802.15.4 at 2.4GHz:=20 > http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf >=20 > The WG Last Call will last 3-weeks and will end on March 29, at noon = ET. Please send your comments on the mailing list and copy=20 > the authors. >=20 > Thanks. >=20 > JP and Michael. =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_F488E330-EB78-4445-8FA3-20920AA21B71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is just a reminder that we have 2 documents in WG Last Call, which will = terminate on March 29, at noon.
Comments = appreciated.
Thanks.

JP.

=
On Mar 7, 2012, at 2:15 PM, JP Vasseur = wrote:

Dear = all,

The two documents = draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been = discussed on the mailing list and during 
WG = meetings for some time, there several implementations that are = now stable, and the authors believe that the documents = are
ready for WG Last Call.

Thus, = this starts a Working Group Last Call on:
* = draft-ietf-roll-p2p-measurement-04
and
*= = draft-ietf-roll-p2p-rpl-09

Furthermore,&n= bsp;an interoperability was carried out last month = with INRIA's implementation against Sigma Design's = implementation.
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail=_F488E330-EB78-4445-8FA3-20920AA21B71-- From pthubert@cisco.com Fri Mar 16 01:53:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11A521F85D1 for ; Fri, 16 Mar 2012 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuh5utSsT-dq for ; Fri, 16 Mar 2012 01:53:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 687D121F85CE for ; Fri, 16 Mar 2012 01:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3537; q=dns/txt; s=iport; t=1331887999; x=1333097599; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=sy+FjR/ORDUwxkjmYgb02nSZ1tKl2FnzISI2jCcFeVI=; b=FlUDy9MmmYlU2gVuFSoGdc4wTqTIwYO+CIHabPttaf3eYeA+X6gbEm35 CF05xkMtVbMVo+LDZhMaE3KRAH6e7JyjhxGRfhVYTk4DdDYPbOq3Ssw7S nla3ZywBTrVoL84hlTXKVLplayYeU5MXbfc2Zdu18d6evGsLtqOls5IVE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANf+Yk+Q/khN/2dsb2JhbABCDrYngQeCCQEBAQQBAQEPARQJPgkOBAIBCA4DAwEBAQsGFwEGASYfCQgBAQQBEggah2gLmmWfBpAaYwSII5wCgWiCLziBUwU X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208";a="68624383" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2012 08:53:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2G8rIMU015542; Fri, 16 Mar 2012 08:53:18 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 09:53: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 09:52:49 +0100 Message-ID: In-Reply-To: <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notificationfor draft-gnawali-roll-rpl-recommendations-03.txt Thread-Index: Acz/J3KyB8YUAMhaS2OHy7o9LMQ2fgCd3S/wAGy3U8A= References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> From: "Pascal Thubert (pthubert)" To: "Koojana Kuladinithi" , "ROLL WG" , "Omprakash Gnawali" X-OriginalArrivalTime: 16 Mar 2012 08:53:18.0500 (UTC) FILETIME=[3B8E5E40:01CD0352] Subject: Re: [Roll] Fwd: New Version Notificationfor draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 08:53:21 -0000 Hello Koojana =20 I hope you're doing well : ) In your case an exponential backoff seems to make a lot of sense. There is work about DIS tuning in = http://tools.ietf.org/html/draft-goyal-roll-dis-modifications-00=20 Maybe you can contribute? Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Koojana Kuladinithi Sent: mercredi 14 mars 2012 06:14 To: 'ROLL WG'; 'Omprakash Gnawali' Subject: Re: [Roll] Fwd: New Version Notificationfor = draft-gnawali-roll-rpl-recommendations-03.txt Hi, I read your draft. We have done some tests with TinyRPL (RPL = implementation in TinyOS) in container filled with fruits. In one test, we had a situation that the border router (RPL root node) = was disconnected for several hours. The sensor nodes start sending DIS = (DIS-INTERVAL was set to 3 sec for this test). We found that this = degrades the use of battery voltage. One alternative is to use a higher = value for DIS-INTERVAL. In real deployment, the RPL root node should setup at the last, after = loading all the sensors.=20 I would like to know -> Why is DIS sending at a constant interval (I am not sure this is set = constant only in the implementation)? Should it be adaptive if it does = not receive a DIO?=20 Is this an issue ("setting of DIS INTERVAL for different cases") that = your draft should address? Kind regards Koojana =20 =20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Omprakash Gnawali > Sent: Sunday, March 11, 2012 2:36 AM > To: ROLL WG > Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-=20 > rpl-recommendations-03.txt >=20 > Dear ROLL WG, >=20 > I just refreshed this draft with comments from JP, Cedric, Joakim, and = > Ulrich. Please keep your comments coming, especially those who have=20 > implemented and deployed RPL. >=20 > Thanks. >=20 > - om_p >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Mar 11, 2012 at 1:34 AM > Subject: New Version Notification for > draft-gnawali-roll-rpl-recommendations-03.txt > To: gnawali@cs.uh.edu > Cc: pal@cs.stanford.edu >=20 >=20 > A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt > has been successfully submitted by Omprakash Gnawali and posted to the = > IETF repository. >=20 > Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations > Revision: =A0 =A0 =A0 =A003 > Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient = Implementation of RPL=20 > Creation date: =A0 2012-03-10 WG ID: =A0 =A0 =A0 =A0 =A0 Individual = Submission=20 > Number of pages: 6 >=20 > Abstract: > =A0 RPL is a flexible routing protocol applicable to a wide range of = Low > =A0 Power and Lossy Networks. =A0To enable this wide applicability, = RPL > =A0 provides many configuration options and gives implementers choices = > on > =A0 how to implement various components of RPL. =A0Drawing on our > =A0 experiences, we distill the design choices and configuration > =A0 parameters that lead to efficient RPL implementations and = operations. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Mar 16 08:29:45 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6321F86C4 for ; Fri, 16 Mar 2012 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QrZpUeQ6CO1 for ; Fri, 16 Mar 2012 08:29:45 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7747521F86C2 for ; Fri, 16 Mar 2012 08:29:44 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S8Z65-0006vv-0T; Fri, 16 Mar 2012 08:29:43 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: Date: Fri, 16 Mar 2012 08:29:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Cc: ROLL WG Subject: Re: [Roll] New Version Notificationfor draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 15:29:46 -0000 On Mar 16, 2012, at 1:52 AM, Pascal Thubert (pthubert) wrote: > Hello Koojana =20 >=20 > I hope you're doing well : ) >=20 > In your case an exponential backoff seems to make a lot of sense. >=20 > There is work about DIS tuning in = http://tools.ietf.org/html/draft-goyal-roll-dis-modifications-00=20 >=20 > Maybe you can contribute? Well, to be precise, the above document is not at all about DIS tuning; = it's about tuning the responses to DIS messages. That being said, it's probably useful to engage the TinyRPL developers = to ask about their choice of DIS timing, and also ask other developers. Phil= From pal@cs.stanford.edu Fri Mar 16 12:50:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568A121F8610 for ; Fri, 16 Mar 2012 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNqMLi-Kbo6K for ; Fri, 16 Mar 2012 12:50:54 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5E72821E8015 for ; Fri, 16 Mar 2012 12:50:54 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S8dAs-0000yV-4K for roll@ietf.org; Fri, 16 Mar 2012 12:50:54 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Philip Levis In-Reply-To: <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> Date: Fri, 16 Mar 2012 12:50:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 19:50:55 -0000 Comments on p2p-measurement: Overall this draft is very solid. It sets out a very simple mechanism = and its options. The use cases are especially helpful. The one major thing that seems to be missing in the document, however, = is exactly how one populates and updates the metric container. For = example, what metrics should a node put into the metric container? The = metrics that the DODAG root is advertising for that RPL Instance? What = happens if the network is using MRHOF and so ETX directly through Rank? = The only text I can find is the last paragraph of 5.0: " Next, the router MUST update the routing metric objects, contained = in the Metric Container options inside the MO, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. After updating the routing metrics, the router MUST unicast the MO to the next hop." Is it that the metric container behavior is specified elsewhere? If not, = then it's possible for a node meeting this document specification to do = whatever it wants with the metric container. I can see a few options: 1) The originator specifies the metrics of interest and nodes update = this value as they generate responses/replies. Part of the challenge = here is a question of whether one is measuring the forward or reverse = route, something the document should be clearer on. This has the = advantage that it requires less coordination and specification with = respect to RPL and OFs. It has the disadvantage that a node could = request a metric the network does not support. 2) All nodes follow the metrics in DIOs. This has the advantage that the = ability to handle these metrics is well defined by a RPL instance. It = has the disadvantage that it requires coordinating how OFs manage = metrics with path discovery. Phil= From pal@cs.stanford.edu Fri Mar 16 12:57:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F721E8076 for ; Fri, 16 Mar 2012 12:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdw2t35Yiumc for ; Fri, 16 Mar 2012 12:57:26 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 69CB021E8075 for ; Fri, 16 Mar 2012 12:57:26 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S8dHC-0005mc-8c for roll@ietf.org; Fri, 16 Mar 2012 12:57:26 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Philip Levis In-Reply-To: <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> Date: Fri, 16 Mar 2012 12:57:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C613552-3C03-4B7F-96D3-741694082FCE@cs.stanford.edu> References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 19:57:26 -0000 Comments on draft-ietf-roll-p2p-rpl-09: I did not review the entire document; I read through the basic = mechanisms and focused on 9.2 (Trickle operation for P2P Mode DIOs). I = think that this section is well written and clearly states how p2p = should interact with Trickle. Furthermore, those interactions seem = sound. I'll read through some of the experimental reports and send more = complete comments later. Phil From jeonggil.ko@gmail.com Fri Mar 16 14:12:32 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A512221E8024 for ; Fri, 16 Mar 2012 14:12:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQjFrSdS56JK for ; Fri, 16 Mar 2012 14:12:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF26D21E800C for ; Fri, 16 Mar 2012 14:12:31 -0700 (PDT) Received: by yenm5 with SMTP id m5so5301346yen.31 for ; Fri, 16 Mar 2012 14:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dogNL1sdsC7VFNYu7P0sL48094oEZHPCK8abS00lUOM=; b=KFF9eLFYMyphT9QY+dZQtDJfzh0WyThhkOPAwOmVfQWm9rkgrhBZ64RF5cZ0Ze2Ueq j5UVnwk5MImkYQbcpbXowRM8t8msu7TjJb8I+kXPM7arDdgOlyN5vIIQvceb5jip8Smt 1hRperuQXpLmWdTZfmIxJ6VRvRT6k0sox75iHsve1X0kBLUG9bOO+QQR4Bwdqa0Rm9Xy 89qGocineyiwLb7LrEzMKMCKVV8mvXHcnbH9jM5B+xA5tuUEuMeunX6V29c6uAyVZr5k LDrEUxdY/v78V5I817/Ly5KwVnbpIiePXoqyl4GJ45wEJPiE582ZL39Q4X8S8UAh/pUA vUCw== Received: by 10.224.177.145 with SMTP id bi17mr5719623qab.17.1331932351266; Fri, 16 Mar 2012 14:12:31 -0700 (PDT) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu. [128.220.71.105]) by mx.google.com with ESMTPS id h11sm11912649qae.3.2012.03.16.14.12.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 14:12:30 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: JeongGil Ko In-Reply-To: <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> Date: Fri, 16 Mar 2012 17:12:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> To: Koojana Kuladinithi X-Mailer: Apple Mail (2.1257) Cc: 'ROLL WG' Subject: Re: [Roll] New Version Notification for draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 21:12:32 -0000 Koojana, In terms of why the DIS is sent at different intervals is rather simple = to explain. A Trickle Timer is typically used when the network is stable = and nothing needs to happen. At least this is the philosophy I tried to = follow when implementing TinyRPL. However, when a node is NOT connected, = this indicates that the network is not stable AT ALL. Therefore, it = should try to aggressively find a next hop node rather than to save = power. The goal of the node should be, at this point, to connect to a = DODAG.=20 Furthermore, it is not really necessary to install the root last in a = RPL deployment. I don't see why this HAS TO be the case. If you install = the root first, then nodes will quickly connect to the network and the = Trickle Timer for DIO packets will start operating.=20 Thanks! -John ------ JeongGil Ko Ph.D. Candidate Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko On Mar 14, 2012, at 1:14 AM, Koojana Kuladinithi wrote: > Hi, >=20 > I read your draft. We have done some tests with TinyRPL (RPL = implementation > in TinyOS) in container filled with fruits. > In one test, we had a situation that the border router (RPL root node) = was > disconnected for several hours. The sensor nodes start sending DIS > (DIS-INTERVAL was set to 3 sec for this test). We found that this = degrades > the use of battery voltage. One alternative is to use a higher value = for > DIS-INTERVAL. >=20 > In real deployment, the RPL root node should setup at the last, after > loading all the sensors.=20 >=20 > I would like to know -> >=20 > Why is DIS sending at a constant interval (I am not sure this is set > constant only in the implementation)? Should it be adaptive if it does = not > receive a DIO?=20 > Is this an issue ("setting of DIS INTERVAL for different cases") that = your > draft should address? >=20 > Kind regards >=20 > Koojana =20 >=20 >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >> Omprakash Gnawali >> Sent: Sunday, March 11, 2012 2:36 AM >> To: ROLL WG >> Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll- >> rpl-recommendations-03.txt >>=20 >> Dear ROLL WG, >>=20 >> I just refreshed this draft with comments from JP, Cedric, Joakim, = and >> Ulrich. Please keep your comments coming, especially those who have >> implemented and deployed RPL. >>=20 >> Thanks. >>=20 >> - om_p >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Mar 11, 2012 at 1:34 AM >> Subject: New Version Notification for >> draft-gnawali-roll-rpl-recommendations-03.txt >> To: gnawali@cs.uh.edu >> Cc: pal@cs.stanford.edu >>=20 >>=20 >> A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt >> has been successfully submitted by Omprakash Gnawali and posted to = the >> IETF repository. >>=20 >> Filename: draft-gnawali-roll-rpl-recommendations >> Revision: 03 >> Title: Recommendations for Efficient Implementation of RPL >> Creation date: 2012-03-10 >> WG ID: Individual Submission >> Number of pages: 6 >>=20 >> Abstract: >> RPL is a flexible routing protocol applicable to a wide range of = Low >> Power and Lossy Networks. To enable this wide applicability, RPL >> provides many configuration options and gives implementers choices = on >> how to implement various components of RPL. Drawing on our >> experiences, we distill the design choices and configuration >> parameters that lead to efficient RPL implementations and = operations. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From pal@cs.stanford.edu Fri Mar 16 14:29:51 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946FC21F85F9 for ; Fri, 16 Mar 2012 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urc95Kx8QM7h for ; Fri, 16 Mar 2012 14:29:50 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63221F85ED for ; Fri, 16 Mar 2012 14:29:17 -0700 (PDT) Received: from [199.188.193.145] (helo=[172.30.3.112]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1S8ei4-00011j-VB; Fri, 16 Mar 2012 14:29:17 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> Date: Fri, 16 Mar 2012 14:29:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> To: Matteo Paris X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: "draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org" , "roll@ietf.org" Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 21:29:51 -0000 On Mar 16, 2012, at 1:44 PM, Matteo Paris wrote: >=20 > Hi Phil. These changes were helpful. But I am still unclear on the = rank computation in section 3.3. =46rom the RPL draft: >=20 > RPL Section 3.5.1: "DAGRank(rank) =3D = floor(rank/MinHopRankIncrease)" > RPL Section 3.5.1: "A node A has a rank less than the rank of a node = B if DAGRank(A) is less than DAGRank(B)." > RPL Section 3.5.2: "[F]or a node N, all parents in the DODAG parent = set must be of rank less than DAGRank(N)." > RPL Section 8.2.1: "A node's rank MUST be greater than all elements = of its DODAG parent set." >=20 > The rank computation in MRHOF section 3.3 can result in parents P for = which DAGRank(P) is not less than DAGRank(N), > which would seem to violate the third and fourth clauses above, given = the definitions in the first two clauses. How? I intended case 2 in 3.3 to cover this. Can you explain the edge = case you see where it does not? >=20 > One other minor question. In the sentence, "The second case covers = requirement 4..." of MRHOF section 3.3, do you mean requirement 5? Yes! It should be requirement 5. I will fix this in the next revision. = Thank you for catching it. Phil= From prvs=415a2c140=mukul@uwm.edu Fri Mar 16 14:53:47 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA88F21F854E for ; Fri, 16 Mar 2012 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqZjj+bQwOkU for ; Fri, 16 Mar 2012 14:53:42 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1921F846C for ; Fri, 16 Mar 2012 14:53:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHO1Y09/AAAB/2dsb2JhbABCDoUwtAwBAQEEAQEBIEsLDA8OAwQBAQMCDRkCKSgIBhOICgunRIkYiQMEgS+OOIEWBIhWjRCQJ4IvVQ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9BC8812E3B2; Fri, 16 Mar 2012 16:53:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awvhIfuTBSLV; Fri, 16 Mar 2012 16:53:41 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 397BA12E3AD; Fri, 16 Mar 2012 16:53:41 -0500 (CDT) Date: Fri, 16 Mar 2012 16:53:41 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <580081911.1617881.1331934821123.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 21:53:47 -0000 Hi Phil Thanks for pointing out the problem. >1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. This is what we have in mind. I will make it clear in the next revision of the draft. Also, I will clarify that the route being measured is the one in forward direction (from the origin to the target) and an intermediate router MUST drop a Measurement Request if it cannot update (or add local value to) a routing metric specified inside the Metric Container. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "ROLL WG" Sent: Friday, March 16, 2012 2:50:51 PM Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 Comments on p2p-measurement: Overall this draft is very solid. It sets out a very simple mechanism and its options. The use cases are especially helpful. The one major thing that seems to be missing in the document, however, is exactly how one populates and updates the metric container. For example, what metrics should a node put into the metric container? The metrics that the DODAG root is advertising for that RPL Instance? What happens if the network is using MRHOF and so ETX directly through Rank? The only text I can find is the last paragraph of 5.0: " Next, the router MUST update the routing metric objects, contained in the Metric Container options inside the MO, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. After updating the routing metrics, the router MUST unicast the MO to the next hop." Is it that the metric container behavior is specified elsewhere? If not, then it's possible for a node meeting this document specification to do whatever it wants with the metric container. I can see a few options: 1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. 2) All nodes follow the metrics in DIOs. This has the advantage that the ability to handle these metrics is well defined by a RPL instance. It has the disadvantage that it requires coordinating how OFs manage metrics with path discovery. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From koo@comnets.uni-bremen.de Sun Mar 18 23:13:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB021F8597 for ; Sun, 18 Mar 2012 23:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxQ6wjQ9ql98 for ; Sun, 18 Mar 2012 23:13:12 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id 675CB21F8596 for ; Sun, 18 Mar 2012 23:13:12 -0700 (PDT) Received: from koojanalaptop (unknown [10.8.0.34]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 90EE9D406F6; Mon, 19 Mar 2012 07:13:10 +0100 (CET) From: "Koojana Kuladinithi" To: "'JeongGil Ko'" References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> In-Reply-To: Date: Mon, 19 Mar 2012 07:13:09 +0100 Message-ID: <000101cd0597$5c29b450$147d1cf0$@uni-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0DuYBNMaOR2NdvSyyH1nVimRHmewB2n3tQ Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] New Version Notification for draft-gnawali-roll-rpl-recommendations-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Mar 2012 06:13:13 -0000 Hi John, > > Koojana, > > In terms of why the DIS is sent at different intervals is rather simple > to explain. A Trickle Timer is typically used when the network is > stable and nothing needs to happen. At least this is the philosophy I > tried to follow when implementing TinyRPL. However, when a node is NOT > connected, this indicates that the network is not stable AT ALL. > Therefore, it should try to aggressively find a next hop node rather > than to save power. The goal of the node should be, at this point, to > connect to a DODAG. > [koo] Yes > Furthermore, it is not really necessary to install the root last in a > RPL deployment. I don't see why this HAS TO be the case. [koo] Unfortunately, this is not the case for our scenario in reality. E.g., Fruits will be placed in boxes together with sensor nodes (at the field) and will be loaded to a container (at the harbor) later. The DODAG root (the BR) will be attached to the container. Until the sensor nodes see any reachable DODAG root, it may takes 1 - 2 days. Therefore, the sending of DIS messages periodically is not a good option. As Pascal pointed out, the use of exponential back-off would be an alternative to reduce numbers of DIS generated. I am not very familiar with RPL draft. I think, there is no possibility to let a sensor node know to trigger sending of DIS messages after a certain time. This may helpful for some scenarios like ours to save the power during the setup time. Thanks Koojana If you install > the root first, then nodes will quickly connect to the network and the > Trickle Timer for DIO packets will start operating. > > Thanks! > > -John > > ------ > JeongGil Ko > Ph.D. Candidate > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko > > On Mar 14, 2012, at 1:14 AM, Koojana Kuladinithi wrote: > > > Hi, > > > > I read your draft. We have done some tests with TinyRPL (RPL > implementation > > in TinyOS) in container filled with fruits. > > In one test, we had a situation that the border router (RPL root > node) was > > disconnected for several hours. The sensor nodes start sending DIS > > (DIS-INTERVAL was set to 3 sec for this test). We found that this > degrades > > the use of battery voltage. One alternative is to use a higher value > for > > DIS-INTERVAL. > > > > In real deployment, the RPL root node should setup at the last, after > > loading all the sensors. > > > > I would like to know -> > > > > Why is DIS sending at a constant interval (I am not sure this is set > > constant only in the implementation)? Should it be adaptive if it > does not > > receive a DIO? > > Is this an issue ("setting of DIS INTERVAL for different cases") that > your > > draft should address? > > > > Kind regards > > > > Koojana > > > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > >> Omprakash Gnawali > >> Sent: Sunday, March 11, 2012 2:36 AM > >> To: ROLL WG > >> Subject: [Roll] Fwd: New Version Notification for draft-gnawali- > roll- > >> rpl-recommendations-03.txt > >> > >> Dear ROLL WG, > >> > >> I just refreshed this draft with comments from JP, Cedric, Joakim, > and > >> Ulrich. Please keep your comments coming, especially those who have > >> implemented and deployed RPL. > >> > >> Thanks. > >> > >> - om_p > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: Sun, Mar 11, 2012 at 1:34 AM > >> Subject: New Version Notification for > >> draft-gnawali-roll-rpl-recommendations-03.txt > >> To: gnawali@cs.uh.edu > >> Cc: pal@cs.stanford.edu > >> > >> > >> A new version of I-D, draft-gnawali-roll-rpl-recommendations-03.txt > >> has been successfully submitted by Omprakash Gnawali and posted to > the > >> IETF repository. > >> > >> Filename: draft-gnawali-roll-rpl-recommendations > >> Revision: 03 > >> Title: Recommendations for Efficient Implementation of RPL > >> Creation date: 2012-03-10 > >> WG ID: Individual Submission > >> Number of pages: 6 > >> > >> Abstract: > >> RPL is a flexible routing protocol applicable to a wide range of > Low > >> Power and Lossy Networks. To enable this wide applicability, RPL > >> provides many configuration options and gives implementers choices > on > >> how to implement various components of RPL. Drawing on our > >> experiences, we distill the design choices and configuration > >> parameters that lead to efficient RPL implementations and > operations. > >> > >> > >> > >> > >> The IETF Secretariat > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > From jpv@cisco.com Fri Mar 23 05:48:53 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C821F8462 for ; Fri, 23 Mar 2012 05:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UENBiJOyzqO8 for ; Fri, 23 Mar 2012 05:48:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7521F845D for ; Fri, 23 Mar 2012 05:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=27087; q=dns/txt; s=iport; t=1332506928; x=1333716528; h=from:subject:date:references:to:message-id:mime-version; bh=Hs/PiXhhX1Rars/N7NSYMD6I+4ALMWWetKbdBsDoZQU=; b=XPTZ6wgHt0UmNZed3cXpNL3RrI14Kgqm1jIfTu+XZXYmnvKxu6ku8QWL qLbSbP/z+ovU9Y4CY4TnfcNcEGP2H9z7GHjHmBNZvPB4t6BznLqilZhq/ CeeumEiVEFc9XwVkXK8oxkPyiOaoBiGgywH1WqutG83PcucQ61xw7zxHy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIMAPpvbE+rRDoJ/2dsb2JhbABEgw6FG69egQeCCQEBAQMBEgEHAywMEwUCDwscAQIBAi9JBAIIBhMJEAmHYwQBC5lOnn2KXgqFOmMElWCFbohWgWiBN4ExgVMBARc X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208,217";a="37371251" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Mar 2012 12:48:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2NCmkot015785 for ; Fri, 23 Mar 2012 12:48:46 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 05:48:46 -0700 Received: from [10.60.114.235] ([10.60.114.235]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 05:48:45 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_B8199C4B-190E-4F38-BD53-42B14EFBEE0F" Date: Fri, 23 Mar 2012 13:48:42 +0100 References: <1332504949625.899@iaria.org> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 23 Mar 2012 12:48:45.0520 (UTC) FILETIME=[48CECD00:01CD08F3] Subject: [Roll] Fwd: Deadline Extension: SENSORCOMM 2012 || August 19-24, 2012 - Rome, Italy X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Mar 2012 12:48:53 -0000 --Apple-Mail=_B8199C4B-190E-4F38-BD53-42B14EFBEE0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Petre Dini > Subject: Deadline Extension: SENSORCOMM 2012 || August 19-24, 2012 - = Rome, Italy > Date: March 23, 2012 1:15:49 PM GMT+01:00 > To: jvasseur@cisco.com >=20 >=20 > INVITATION: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Please consider to contribute to and/or forward to the appropriate = groups the following opportunity to submit and publish original = scientific results to SENSORCOMM 2012. >=20 > The submission deadline has been extended to to April 16, 2012. >=20 > In addition, authors of selected papers will be invited to submit = extended article versions to one of the IARIA Journals: = http://www.iariajournals.org >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SENSORCOMM 2012 | Call for = Papers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > CALL FOR PAPERS, TUTORIALS, PANELS >=20 > SENSORCOMM 2012: The Sixth International Conference on Sensor = Technologies and Applications >=20 > August 19-24, 2012 - Rome, Italy >=20 >=20 > General page: http://www.iaria.org/conferences2012/SENSORCOMM12.html >=20 > Call for Papers: = http://www.iaria.org/conferences2012/CfPSENSORCOMM12.html >=20 > - regular papers >=20 > - short papers (work in progress) >=20 > - posters >=20 > Submission page: = http://www.iaria.org/conferences2012/SubmitSENSORCOMM12.html >=20 >=20 > Submission deadline: April 16, 2012 >=20 > Sponsored by IARIA, www.iaria.org >=20 >=20 > Extended versions of selected papers will be published in IARIA = Journals: http://www.iariajournals.org >=20 >=20 > Please note the Poster and Work in Progress options. >=20 > The topics suggested by the conference can be discussed in term of = concepts, state of the art, research, standards, implementations, = running experiments, applications, and industrial case studies. Authors = are invited to submit complete unpublished papers, which are not under = review in any other conference or journal in the following, but not = limited to, topic areas.=20 > All tracks are open to both research and industry contributions, in = terms of Regular papers, Posters, Work in progress, = Technical/marketing/business presentations, Demos, Tutorials, and = Panels. >=20 > Before submission, please check and comply with the Editorial rules: = http://www.iaria.org/editorialrules.html >=20 > SENSORCOMM 2012 Topics (topics and submission details: see CfP on the = site) >=20 >=20 > APASN: Architectures, protocols and algorithms of sensor networks >=20 > Network planning, provisioning and deployment; Network Architectures = for Sensor Networks; Network Protocols for Sensor Networks; Structural = design; Distributed Sensor Networks; Dynamic sensor networks; Scalable = and heterogeneous architectures; Hierarchical clustering architectures; = Group-based Architectures; Network topologies; Mesh networking; Device = centric sensor networks; Distributed coordination algorithms; Topology = construction; Routing protocols; Routing Metrics; Distributed = Algorithms; Attribute-based named nets; Mobility and Scalability; = Attribute-based named Sensor Networks; Query optimization; = Self-organization and self-configuration algorithms; Reconfigurability; = Time Synchronization; MAC protocols for sensor networks (801.11, = 802.15.4, UWB, etc); Location and time service; Integration with other = systems; Distributed inference and fusion; Cross-layer design and = optimization; Complexity analysis of algorithms; Sensor networks and the = Web; Integration with other systems (e.g., Web-based information = systems, process control, enterprise software, etc.); Target tracking; = RFID tags; Traffic scheduling >=20 > MECSN: Energy, management and control of sensor networks >=20 > Energy models; Energy optimization; Energy management; Power-aware = and energy-efficient design; Power sources in sensor networks; Battery = technology; Power management; Algorithms and theories for management; = Communication strategies for topology control; Algorithms and theories = for supervisory control; Sensor tasking and control; Distributed control = and actuation; Location and mobility management; Bandwidth management; = Distributed networked sensing; Resource provisioning; Resource = management and dynamic resource management; Schemes to maximize accuracy = and minimize false alarms; Online self-calibration and self-testing; = Handoff and mobility management and seamless internetworking; = Distributed actuation and control; Topology control >=20 > RASQOFT: Resource allocation, services, QoS and fault tolerance in = sensor networks >=20 > Algorithms to support quality of service in sensor networks; = Protocols to support quality of service in sensor networks; QoS/SLA in = sensor networks; Provisioning of QoS in terms of bandwidth and delay = assurance; System services and distributed services in sensor networks; = Delay tolerant networks and opportunistic networking; Failure resilience = and fault isolation; Information assurance in sensor networks; Fault = tolerance and reliability; Admission control; Resource allocation and = fairness; Real-time resource scheduling; Scheduling and optimisation; = Capacity planning >=20 > PESMOSN: Performance, simulation and modelling of sensor networks >=20 > Performance measurement of sensor networks; Performance evaluation = and analysis of sensor networks; Performance comparison on capacity, = coverage and connectivity; Modelling techniques of sensor networks; = Validation of sensor network architectures; Simulation and theoretical = analysis; Simulation software tools and environments; Theoretical = performance analysis: complexity, correctness and scalability; Design, = simulation and optimization tools for deployment and operation; Platform = modelling and analysis tools; Analytical, mobility and validation = models; System debugging and testing >=20 > SEMOSN: Security and monitoring of sensor networks >=20 > Security and privacy in sensor networks; Reliability aspects in = sensor networks; Monitoring distributed sensor networks; Mechanisms for = authentication; Secure communication in sensor networks; Encryption = algorithms for sensor networks; Sensor secure management; Data = integrity; Trustworthiness issues in sensor networks; Trade-off analysis >=20 > SECSED: Sensor circuits and sensor devices >=20 > Methods for sensor deployment; Instrumentation and models for = deployment of sensors networks; Sensor architecture; Abstractions for = modular design; Design and deployment of embedded system platforms; = Embedded architectures and tools; Embedded processors; Embedded chip = design; Micro and Nano devices; Biosensors; Optical sensors; Smart = sensors; Acoustic Sensors; Microwave sensors; Middleware design; Sensor = Prototypes; Sensor node components; Sensor interfaces; Actuators; = Independent Component Analysis; Design of cost effective and economical = sensors; Smart Material Applications to design sensors; Microfabrication = Technologies for Microsystem Integration; Integration of sensors into = engineered systems; Hardware platforms; Test-beds incorporating multiple = sensors; Operating system and middleware support >=20 > RIWISN: Radio issues in wireless sensor networks >=20 > Wireless Sensor Communications; Network connectivity & longevity; = Tracking objects; Geo-location problems; Network coverage; Algorithms = for sensor localization and tracking; Detection, classification and = estimation; Physical layer impact on higher level protocols; Directional = and smart antennas for sensor networks; Coverage maintenance; = Transceiver and antenna design; Ubiquitous wireless connectivity >=20 > SAPSN: Software, applications and programming of sensor networks >=20 > Applications and demonstrations of sensor networks; Software = platforms and development tools; Architectural design and optimization = tools for sensor nodes; Computation and programming models of sensor = networks; Languages and operating systems of Sensors; Programming and = Interfacing; Programming abstraction; Programming models for sensors; = Programming methodology for sensor environments; Intelligent sensor = theory and applications; Machine learning applications to sensor = networks; Wireless sensor applications; Applications for sensor network = management; Software tools for chip programming; Application = requirements; Application evaluation and comparison; Demos and prototype = testing >=20 > DAIPSN: Data allocation and information in sensor networks >=20 > Techniques for the interpretation and use of sensor data in = decision-making processes; Distributed data processing; Distributed = signal processing; Array signal processing; Statistical signal = processing; Distributed query processing; Distributed information = processing; Distributed algorithms for collaborative information and = signal processing; Task allocation, reprogramming and reconfiguration; = Coding and information theory; In-network processing and aggregation; = Data analysis and visualisation; Data storage in sensor networks; Data = retrieval; Data dissemination; Data compression and aggregation; Data = transport in wireless sensor networks; Data gathering and fusion in = wireless sensor networks; Theories and models on fundamental information = and communication aspects of sensor networks; Redundancy >=20 > DISN: Deployments and implementations of sensor networks >=20 > Methods for sensor networks deployment; Practical implementations = and real-world experiences; Real-life deployments; System = implementation; End-user aspects; Operational experience and test-beds; = Industrial and commercial developments and applications; Measurements = from experimental systems, test-beds and demonstrations; Intelligent = sensors, body sensors and their utilisation; Analysis of real-world = systems and fundamental limits; Smart Sensors for building surveillance; = Sensing in health care; Games using sensor networks; Peer-to-peer, = overlay, and content distribution wireless sensor networks; Use cases = (e.g., Automotive, Battlefield, Defense, Construction, Disaster = recovery, Environmental, Medical, Security, Biomedical, Unmanned Aerial = Vehicles, etc.); Sensor networks for Rural and Agricultural = environments; Sensors for railway systems; Pattern Recognition; Machine = Intelligence; Sensor-equipped Smart Environment; Deployments in Harsh = Environments; Potential application areas >=20 > UNWAT: Under water sensors and systems >=20 > Protocols for underwater sensor networks; Underwater hardware; = Underwater wired systems; Underwater wireless sensor networks; = Underwater sensors for neutrino telescopes; Acoustic and radio = underwater communication; Aquatic environments and applications; = Unmanned underwater exploration; Underwater localization and knowledge = acquisition; Scalable underwater monitoring and measurement systems; = Fixed and mobile underwater wireless sensors; Aquatic surveillance = applications; QoS/Performance in underwater communication; = Surface-floating and underwater sensor communication; Access control in = underwater networks; Latency effects for critical applications and = synchronization; Synchronization and delays in underwater sensor = networks; Localization in underwater sensor networks; Advanced = underwater sensor-based applications >=20 > ENOPT: Energy optimization in wireless sensor networks >=20 > Energy supply, lifetime and transmission power; Energy efficiency; = State-driven energy optimization; Power consumption models; Energy-aware = adaptive low power; Optimal energy-aware clustering; Lifetime-oriented = energy provisioning; Sensor placement and accessibility; Random sensor = deployment and density function; Fixed and adjustable transmission = power; Traffic and energy consumption rate; Energy-efficient topology = control; Energy optimization in multi-hop communications; Energy = harvesting for autonomous sensors >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_B8199C4B-190E-4F38-BD53-42B14EFBEE0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Petre Dini <petre@iaria.org>
Subject: = Deadline Extension: SENSORCOMM 2012 || August = 19-24, 2012 - Rome, Italy
Date: March 23, 2012 1:15:49 PM = GMT+01:00
=

INVITATION:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Please consider to contribute to and/or forward to the = appropriate groups the following opportunity to submit and publish = original scientific results to SENSORCOMM 2012.

The submission = deadline has been extended to to April 16, 2012.

In addition, = authors of selected papers will be invited to submit extended article = versions to one of the IARIA Journals: http://www.iariajournals.org
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SENSORCOMM 2012 | Call for Papers = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CALL FOR PAPERS, = TUTORIALS, PANELS

SENSORCOMM 2012: The Sixth International = Conference on Sensor Technologies and Applications

August 19-24, = 2012 - Rome, Italy


General page: http://www= .iaria.org/conferences2012/SENSORCOMM12.html

Call for Papers: = http://= www.iaria.org/conferences2012/CfPSENSORCOMM12.html

- regular = papers

- short papers (work in progress)

- = posters

Submission page: http= ://www.iaria.org/conferences2012/SubmitSENSORCOMM12.html


Su= bmission deadline: April 16, 2012

Sponsored by IARIA, www.iaria.org


Extended = versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org
=

Please note the Poster and Work in Progress options.

The = topics suggested by the conference can be discussed in term of concepts, = state of the art, research, standards, implementations, running = experiments, applications, and industrial case studies. Authors are = invited to submit complete unpublished papers, which are not under = review in any other conference or journal in the following, but not = limited to, topic areas.
All tracks are open to both research and = industry contributions, in terms of Regular papers, Posters, Work in = progress, Technical/marketing/business presentations, Demos, Tutorials, = and Panels.

Before submission, please check and comply with the = Editorial rules: http://www.iaria.org/edi= torialrules.html

SENSORCOMM 2012 Topics (topics and = submission details: see CfP on the site)


APASN: = Architectures, protocols and algorithms of sensor networks

=   Network planning, provisioning and deployment; Network = Architectures for Sensor Networks; Network Protocols for Sensor = Networks; Structural design; Distributed Sensor Networks; Dynamic sensor = networks; Scalable and heterogeneous architectures; Hierarchical = clustering architectures; Group-based Architectures; Network topologies; = Mesh networking; Device centric sensor networks; Distributed = coordination algorithms; Topology construction; Routing protocols; = Routing Metrics; Distributed Algorithms; Attribute-based named nets; = Mobility and Scalability; Attribute-based named Sensor Networks; Query = optimization; Self-organization and self-configuration algorithms; = Reconfigurability; Time Synchronization; MAC protocols for sensor = networks (801.11, 802.15.4, UWB, etc); Location and time service; = Integration with other systems; Distributed inference and fusion; = Cross-layer design and optimization; Complexity analysis of algorithms; = Sensor networks and the Web; Integration with other systems (e.g., = Web-based information systems, process control, enterprise software, = etc.); Target tracking; RFID tags; Traffic scheduling

MECSN: = Energy, management and control of sensor networks

=   Energy models; Energy optimization; Energy management; = Power-aware and energy-efficient design; Power sources in sensor = networks; Battery technology; Power management; Algorithms and theories = for management; Communication strategies for topology control; = Algorithms and theories for supervisory control; Sensor tasking and = control; Distributed control and actuation; Location and mobility = management; Bandwidth management; Distributed networked sensing; = Resource provisioning; Resource management and dynamic resource = management; Schemes to maximize accuracy and minimize false alarms; = Online self-calibration and self-testing; Handoff and mobility = management and seamless internetworking; Distributed actuation and = control; Topology control

RASQOFT: Resource allocation, services, = QoS and fault tolerance in sensor networks

=   Algorithms to support quality of service in sensor networks; = Protocols to support quality of service in sensor networks; QoS/SLA in = sensor networks; Provisioning of QoS in terms of bandwidth and delay = assurance; System services and distributed services in sensor networks; = Delay tolerant networks and opportunistic networking; Failure resilience = and fault isolation; Information assurance in sensor networks; Fault = tolerance and reliability; Admission control; Resource allocation and = fairness; Real-time resource scheduling; Scheduling and optimisation; = Capacity planning

PESMOSN: Performance, simulation and modelling = of sensor networks

  Performance measurement of sensor = networks; Performance evaluation and analysis of sensor networks; = Performance comparison on capacity, coverage and connectivity; Modelling = techniques of sensor networks; Validation of sensor network = architectures; Simulation and theoretical analysis; Simulation software = tools and environments; Theoretical performance analysis: complexity, = correctness and scalability; Design, simulation and optimization tools = for deployment and operation; Platform modelling and analysis tools; = Analytical, mobility and validation models; System debugging and = testing

SEMOSN: Security and monitoring of sensor = networks

  Security and privacy in sensor networks; = Reliability aspects in sensor networks; Monitoring distributed sensor = networks; Mechanisms for authentication; Secure communication in sensor = networks; Encryption algorithms for sensor networks; Sensor secure = management; Data integrity; Trustworthiness issues in sensor networks; = Trade-off analysis

SECSED: Sensor circuits and sensor = devices

  Methods for sensor deployment; = Instrumentation and models for deployment of sensors networks; Sensor = architecture; Abstractions for modular design; Design and deployment of = embedded system platforms; Embedded architectures and tools; Embedded = processors; Embedded chip design; Micro and Nano devices; Biosensors; = Optical sensors; Smart sensors; Acoustic Sensors; Microwave sensors; = Middleware design; Sensor Prototypes; Sensor node components; Sensor = interfaces; Actuators; Independent Component Analysis; Design of cost = effective and economical sensors; Smart Material Applications to design = sensors; Microfabrication Technologies for Microsystem Integration; = Integration of sensors into engineered systems; Hardware platforms; = Test-beds incorporating multiple sensors; Operating system and = middleware support

RIWISN: Radio issues in wireless sensor = networks

  Wireless Sensor Communications; Network = connectivity & longevity; Tracking objects; Geo-location problems; = Network coverage; Algorithms for sensor localization and tracking; = Detection, classification and estimation; Physical layer impact on = higher level protocols; Directional and smart antennas for sensor = networks; Coverage maintenance; Transceiver and antenna design; = Ubiquitous wireless connectivity

SAPSN: Software, applications = and programming of sensor networks

  Applications and = demonstrations of sensor networks; Software platforms and development = tools; Architectural design and optimization tools for sensor nodes; = Computation and programming models of sensor networks; Languages and = operating systems of Sensors; Programming and Interfacing; Programming = abstraction; Programming models for sensors; Programming methodology for = sensor environments; Intelligent sensor theory and applications; Machine = learning applications to sensor networks; Wireless sensor applications; = Applications for sensor network management; Software tools for chip = programming; Application requirements; Application evaluation and = comparison; Demos and prototype testing

DAIPSN: Data allocation = and information in sensor networks

  Techniques for = the interpretation and use of sensor data in decision-making processes; = Distributed data processing; Distributed signal processing; Array signal = processing; Statistical signal processing; Distributed query processing; = Distributed information processing; Distributed algorithms for = collaborative information and signal processing; Task allocation, = reprogramming and reconfiguration; Coding and information theory; = In-network processing and aggregation; Data analysis and visualisation; = Data storage in sensor networks; Data retrieval; Data dissemination; = Data compression and aggregation; Data transport in wireless sensor = networks; Data gathering and fusion in wireless sensor networks; = Theories and models on fundamental information and communication aspects = of sensor networks; Redundancy

DISN: Deployments and = implementations of sensor networks

  Methods for = sensor networks deployment; Practical implementations and real-world = experiences; Real-life deployments; System implementation; End-user = aspects; Operational experience and test-beds; Industrial and commercial = developments and applications; Measurements from experimental systems, = test-beds and demonstrations; Intelligent sensors, body sensors and = their utilisation; Analysis of real-world systems and fundamental = limits; Smart Sensors for building surveillance; Sensing in health care; = Games using sensor networks; Peer-to-peer, overlay, and content = distribution wireless sensor networks; Use cases (e.g., Automotive, = Battlefield, Defense, Construction, Disaster recovery, Environmental, = Medical, Security, Biomedical, Unmanned Aerial Vehicles, etc.); Sensor = networks for Rural and Agricultural environments; Sensors for railway = systems; Pattern Recognition; Machine Intelligence; Sensor-equipped = Smart Environment; Deployments in Harsh Environments; Potential = application areas

UNWAT: Under water sensors and systems

=   Protocols for underwater sensor networks; Underwater = hardware; Underwater wired systems; Underwater wireless sensor networks; = Underwater sensors for neutrino telescopes; Acoustic and radio = underwater communication; Aquatic environments and applications; = Unmanned underwater exploration; Underwater localization and knowledge = acquisition; Scalable underwater monitoring and measurement systems; = Fixed and mobile underwater wireless sensors; Aquatic surveillance = applications; QoS/Performance in underwater communication; = Surface-floating and underwater sensor communication; Access control in = underwater networks; Latency effects for critical applications and = synchronization; Synchronization and delays in underwater sensor = networks; Localization in underwater sensor networks; Advanced = underwater sensor-based applications

ENOPT: Energy optimization = in wireless sensor networks

  Energy supply, lifetime = and transmission power; Energy efficiency; State-driven energy = optimization; Power consumption models; Energy-aware adaptive low power; = Optimal energy-aware clustering; Lifetime-oriented energy provisioning; = Sensor placement and accessibility; Random sensor deployment and density = function; Fixed and adjustable transmission power; Traffic and energy = consumption rate; Energy-efficient topology control; Energy optimization = in multi-hop communications; Energy harvesting for autonomous = sensors



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

= --Apple-Mail=_B8199C4B-190E-4F38-BD53-42B14EFBEE0F-- From jpv@cisco.com Fri Mar 23 08:48:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171CC21F85AD for ; Fri, 23 Mar 2012 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.377 X-Spam-Level: X-Spam-Status: No, score=-108.377 tagged_above=-999 required=5 tests=[AWL=2.223, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT6al7UfwDId for ; Fri, 23 Mar 2012 08:48:33 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 901BF21F8597 for ; Fri, 23 Mar 2012 08:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=107; q=dns/txt; s=iport; t=1332517712; x=1333727312; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=t4Hi9+j7VBLqxDPmhYJBgq5a4kgNHxD6ZgrbvXmNFew=; b=bX7Yz15nZCyhPPlaYkjaUNkgEtmUKqMWuUwg3R4yD7hhn/9Upc/zw9xU 6pLsFtXVLQNDRBLRKDGkCfHIZk7PAs0inWVrfeQfVzKnnGei8ue3Atmc1 /AzAujPupr/AOpZ1VP0F8rIscdtInnVO3OLCz7eJB8wGaBybyHa5Wlu6H 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQGAGSabE9Io8UY/2dsb2JhbABFgw62AYIFHQEnP4EiHDWFJgeCKRKaCZ8FkQUElWCFbohWgWiCaA X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="8494752" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 23 Mar 2012 15:48:30 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2NFmUSW009283; Fri, 23 Mar 2012 15:48:30 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 23:48:29 +0800 Received: from [10.60.114.235] ([10.60.114.235]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 23:48:29 +0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 23 Mar 2012 16:48:27 +0100 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 23 Mar 2012 15:48:29.0516 (UTC) FILETIME=[649200C0:01CD090C] Cc: Michael Richardson Subject: [Roll] Slide please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Mar 2012 15:48:37 -0000 Dear all, Please send your slide no later than Monday 26 to the chairs and Dan. Many Thanks. JP. From wwwrun@rfc-editor.org Mon Mar 26 04:38:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AFF21F863E; Mon, 26 Mar 2012 04:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm8vL5gS0oaB; Mon, 26 Mar 2012 04:38:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C20F921F8628; Mon, 26 Mar 2012 04:38:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4390DB1E002; Mon, 26 Mar 2012 04:37:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120326113719.4390DB1E002@rfc-editor.org> Date: Mon, 26 Mar 2012 04:37:19 -0700 (PDT) Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 6550 on RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2012 11:38:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6550 Title: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Author: T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Status: Standards Track Stream: IETF Date: March 2012 Mailbox: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com Pages: 157 Characters: 360651 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-rpl-19.txt URL: http://www.rfc-editor.org/rfc/rfc6550.txt Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (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 are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Mar 26 04:38:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9421F863F; Mon, 26 Mar 2012 04:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnLzvp3Z54-V; Mon, 26 Mar 2012 04:38:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 067C321F85B1; Mon, 26 Mar 2012 04:38:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 267E4B1E003; Mon, 26 Mar 2012 04:37:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120326113733.267E4B1E003@rfc-editor.org> Date: Mon, 26 Mar 2012 04:37:33 -0700 (PDT) Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 6551 on Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2012 11:38:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6551 Title: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks Author: JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel Status: Standards Track Stream: IETF Date: March 2012 Mailbox: jpv@cisco.com, mjkim@kt.com, kpister@dustnetworks.com, nicolas.dejean@coronis.com, dominique.barthel@orange-ftgroup.com Pages: 30 Characters: 67707 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-routing-metrics-18.txt URL: http://www.rfc-editor.org/rfc/rfc6551.txt Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Mar 26 04:39:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB10721F8659; Mon, 26 Mar 2012 04:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.28 X-Spam-Level: X-Spam-Status: No, score=-104.28 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7EUA4guCOkl; Mon, 26 Mar 2012 04:39:02 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 558D121F8649; Mon, 26 Mar 2012 04:39:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6A23BB1E002; Mon, 26 Mar 2012 04:37:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120326113745.6A23BB1E002@rfc-editor.org> Date: Mon, 26 Mar 2012 04:37:45 -0700 (PDT) Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 6552 on Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2012 11:39:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6552 Title: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) Author: P. Thubert, Ed. Status: Standards Track Stream: IETF Date: March 2012 Mailbox: pthubert@cisco.com Pages: 14 Characters: 30419 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-of0-20.txt URL: http://www.rfc-editor.org/rfc/rfc6552.txt The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From culler@EECS.Berkeley.EDU Mon Mar 26 05:39:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD321F8680 for ; Mon, 26 Mar 2012 05:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXjajZUfyTsM for ; Mon, 26 Mar 2012 05:39:40 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by ietfa.amsl.com (Postfix) with ESMTP id E21DD21F867C for ; Mon, 26 Mar 2012 05:39:40 -0700 (PDT) Received: from cullersmac2.darty (93.173-226-89.dsl.completel.net [89.226.173.93]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.5/8.13.5) with ESMTP id q2QCdZOQ020973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Mar 2012 05:39:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: David Culler In-Reply-To: <20120326113719.4390DB1E002@rfc-editor.org> Date: Mon, 26 Mar 2012 05:39:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E090BEE-AE59-46A8-9038-5652D9890BC8@EECS.Berkeley.EDU> References: <20120326113719.4390DB1E002@rfc-editor.org> To: roll WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Roll] RFC 6550 on RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2012 12:39:41 -0000 Mission Accomplished. Great work WG. David Culler culler@eecs.berkeley.edu Chair Computer Science Faculty Director i4Energy On Mar 26, 2012, at 4:37 AM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6550 >=20 > Title: RPL: IPv6 Routing Protocol for=20 > Low-Power and Lossy Networks=20 > Author: T. Winter, Ed., > P. Thubert, Ed., > A. Brandt, J. Hui, > R. Kelsey, P. Levis, > K. Pister, R. Struik, > JP. Vasseur, R. Alexander > Status: Standards Track > Stream: IETF > Date: March 2012 > Mailbox: wintert@acm.org,=20 > pthubert@cisco.com,=20 > abr@sdesigns.dk, jhui@archrock.com,=20 > kelsey@ember.com, pal@cs.stanford.edu,=20 > kpister@dustnetworks.com, rstruik.ext@gmail.com,=20= > jpv@cisco.com, = roger.alexander@cooperindustries.com > Pages: 157 > Characters: 360651 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-roll-rpl-19.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6550.txt >=20 > Low-Power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen to thousands of routers. Supported > traffic flows include point-to-point (between devices inside the > LLN), point-to-multipoint (from a central control point to a subset > of devices inside the LLN), and multipoint-to-point (from devices > inside the LLN towards a central control point). This document > specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks > (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 are supported. Support for point-to-point > traffic is also available. [STANDARDS-TRACK] >=20 > This document is a product of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Mar 26 07:04:08 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3B421F8736 for ; Mon, 26 Mar 2012 07:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.042 X-Spam-Level: X-Spam-Status: No, score=-110.042 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv2cCbThwL3U for ; Mon, 26 Mar 2012 07:04:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A6BE021F8608 for ; Mon, 26 Mar 2012 07:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=20051; q=dns/txt; s=iport; t=1332770646; x=1333980246; h=from:mime-version:subject:date:references:cc:to: message-id; bh=4XqLxkTJ5bjwEjpM52pX8FjXXX7G0u9jO9HJgcpF8kg=; b=f4GnHpO7lkNtSN2qnJxzuWMaFdlbcvSBu2OlqJWtj2DsgV7g5zfxa3gz SfBxHYNk9v6J+dLra8N/Xn3s06Abq1+qvqgm82Nu99mYzZeGD2q8ZWHcl k4PqrzhnEABgOGtr+FHYoY1VFvCT1EaLmDw/bnjoK4QV/s8w1ZiuyfrBg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIHACx2cE+rRDoJ/2dsb2JhbABFgkZIrB8BiHuBB4IJAQEBAwEBAQEPARohIAsFCxwDAQINIiEGChwCCAYTCQsHAgQBh2MEAQuaCJ5aiXF1hV9jBJVggRGEXoVCgxSBaIJpgVo X-IronPort-AV: E=Sophos;i="4.73,650,1325462400"; d="scan'208,217";a="34565403" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Mar 2012 14:04:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2QE45wQ001063; Mon, 26 Mar 2012 14:04:05 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 07:04:05 -0700 Received: from [10.60.114.235] ([10.60.114.235]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 07:04:04 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD0C4B49-A610-4925-99E6-0E9D7199DDAA" Date: Mon, 26 Mar 2012 16:04:00 +0200 References: <20120326113719.4390DB1E002@rfc-editor.org> To: ROLL WG Message-Id: <1A5D5706-0554-406E-B789-44544F30DE17@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 26 Mar 2012 14:04:04.0714 (UTC) FILETIME=[4DB254A0:01CD0B59] Subject: [Roll] Fwd: RFC 6550 on RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2012 14:04:08 -0000 --Apple-Mail=_CD0C4B49-A610-4925-99E6-0E9D7199DDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear ROLL WG, We're DELIGHTED to let you know that after 4 years of really hard work, = the Working Group has completed the standardization of RPL, a new = routing protocol designed for large-scale IPv6 constrained and harsh = environments, and especially for the Internet Of Things. RPL is made of = several components (RFC6550) with 4 companions RFC listed below. RPL is the result of the hard work on the whole ROLL WG! Even more importantly, not only other standards and alliances who = adopted RPL as their routing protocol of choice (Zigbee/IP, Wave2M, =85), = but we are ware of more than 15 independent implementations, and we = start to see actual deployments in the field. As far as we know, there = is already a 3,000 and 4,000 node networks deployed with a single DAG = and first results look excellent. We're hoping to see IETF I-D = describing these deployments. Feel free to share on the ROLL mailing = list. The main body of work is now done, although we will undoubtedly find = limitations and issues in the field, and we will go through standard = process to continue improving the protocol (summarily to any other = protocols) and adding extensions, in addition to the other WG items of = course =96 This is undoubtedly a key milestone. Set of RPL Standards: RFC 6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RFC 6551: Routing Metrics Used for Path Calculation in Low-Power and = Lossy Networks RFC 6552: Objective Function Zero for the Routing Protocol for Low-Power = and Lossy Networks (RPL) RFC 6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) = Option for Carrying RPL Information in Data-Plane Datagrams RFC 6554: An IPv6 Routing Header for Source Routes with the = Routing Protocol for Low-Power and Lossy Networks (RPL). =20 JP, David, Adrian and Michael. =20 Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 6550 on RPL: IPv6 Routing Protocol for Low-Power and = Lossy Networks > Date: March 26, 2012 1:37:19 PM GMT+02:00 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: roll@ietf.org, rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6550 >=20 > Title: RPL: IPv6 Routing Protocol for=20 > Low-Power and Lossy Networks=20 > Author: T. Winter, Ed., > P. Thubert, Ed., > A. Brandt, J. Hui, > R. Kelsey, P. Levis, > K. Pister, R. Struik, > JP. Vasseur, R. Alexander > Status: Standards Track > Stream: IETF > Date: March 2012 > Mailbox: wintert@acm.org,=20 > pthubert@cisco.com,=20 > abr@sdesigns.dk, jhui@archrock.com,=20 > kelsey@ember.com, pal@cs.stanford.edu,=20 > kpister@dustnetworks.com, rstruik.ext@gmail.com,=20= > jpv@cisco.com, = roger.alexander@cooperindustries.com > Pages: 157 > Characters: 360651 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-roll-rpl-19.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6550.txt >=20 > Low-Power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen to thousands of routers. Supported > traffic flows include point-to-point (between devices inside the > LLN), point-to-multipoint (from a central control point to a subset > of devices inside the LLN), and multipoint-to-point (from devices > inside the LLN towards a central control point). This document > specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks > (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 are supported. Support for point-to-point > traffic is also available. [STANDARDS-TRACK] >=20 > This document is a product of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 --Apple-Mail=_CD0C4B49-A610-4925-99E6-0E9D7199DDAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = ROLL WG,

We're DELIGHTED to let you know that after 4 years of = really hard work, the Working Group has completed the standardization = of RPL, a new routing protocol designed for large-scale IPv6 = constrained and harsh environments, and especially for the Internet Of = Things. RPL is made of several components (RFC6550) with 4 companions = RFC listed below.

RPL is the result of the hard = work on the whole ROLL WG!

Even more importantly, not = only other standards and alliances who adopted RPL as their routing = protocol of choice (Zigbee/IP, Wave2M, =85), but we are ware of more = than 15 independent implementations, and we start to see actual = deployments in the field. As far as we know, there is already a 3,000 = and 4,000 node networks deployed with a single DAG and first results = look excellent. We're hoping to see IETF I-D describing these = deployments. Feel free to share on the ROLL mailing = list.

The main body of work is now = done, although we will undoubtedly find limitations and issues in the = field, and we will go through standard process to continue improving the = protocol (summarily to any other protocols) and adding extensions, in = addition to the other WG items of course =96 This is undoubtedly a key = milestone.

Set of RPL = Standards:

RFC 6550: RPL: IPv6 Routing Protocol for Low-Power =
and Lossy Networks
RFC 6551: Routing =
Metrics Used for Path Calculation in Low-Power and Lossy =
Networks
RFC 6552: Objective Function Zero for the Routing =
Protocol for Low-Power and Lossy Networks =
(RPL)
RFC 6553: The Routing Protocol for Low-Power and =
Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane =
Datagrams
RFC 6554: An IPv6 Routing Header for Source Routes =
with       the Routing =
Protocol for Low-Power and Lossy Networks =
(RPL).
 
JP, David, Adrian and =
Michael.

 


Begin forwarded message:

Subject: RFC 6550 on RPL: IPv6 Routing Protocol for = Low-Power and Lossy Networks
Date: March 26, 2012 1:37:19 PM = GMT+02:00


A new Request for Comments is now available = in online RFC libraries.


=        RFC 6550

=        Title: =      RPL: IPv6 Routing Protocol for
=             &n= bsp;      Low-Power and Lossy Networks =
       Author: =     T. Winter, Ed.,
=             &n= bsp;      P. Thubert, Ed.,
=             &n= bsp;      A. Brandt, J. Hui,
=             &n= bsp;      R. Kelsey, P. Levis,
=             &n= bsp;      K. Pister, R. Struik,
=             &n= bsp;      JP. Vasseur, R. Alexander
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       March 2012
=        Mailbox:    wintert@acm.org,
=             &n= bsp;      pthubert@cisco.com,
=             &n= bsp;      abr@sdesigns.dk,  jhui@archrock.com,
=             &n= bsp;      kelsey@ember.com,  pal@cs.stanford.edu,
=             &n= bsp;      kpister@dustnetworks.com, =  rstruik.ext@gmail.com, =
=             &n= bsp;      jpv@cisco.com,  roger.alexander@coope= rindustries.com
       Pages: =      157
=        Characters: 360651
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-roll-rpl-19.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc6550.txt

Low-Power and Lossy Networks (LLNs) are a = class of network in which
both the routers and their interconnect are = constrained.  LLN routers
typically operate with constraints on = processing power, memory, and
energy (battery power).  Their = interconnects are characterized by
high loss rates, low data rates, = and instability.  LLNs are comprised
of anything from a few = dozen to thousands of routers.  Supported
traffic flows include = point-to-point (between devices inside the
LLN), point-to-multipoint = (from a central control point to a subset
of devices inside the LLN), = and multipoint-to-point (from devices
inside the LLN towards a = central control point).  This document
specifies the IPv6 = Routing Protocol for Low-Power and Lossy Networks
(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 are supported.  Support for = point-to-point
traffic is also available. =  [STANDARDS-TRACK]

This document is a product of the Routing = Over Low power and Lossy networks Working Group of the IETF.

This = is now a Proposed Standard Protocol.

STANDARDS TRACK: This = document specifies an Internet standards track
protocol for the = Internet community,and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Internet
Official Protocol Standards (STD 1) for the standardization = state and
status of this protocol.  Distribution of this memo is = unlimited.

This announcement is sent to the IETF-Announce and = rfc-dist lists.
To subscribe or unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html.

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
Association Management Solutions, = LLC



= --Apple-Mail=_CD0C4B49-A610-4925-99E6-0E9D7199DDAA-- From sensys@cfpmail.info Thu Mar 22 21:42:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEB921E8013 for ; Thu, 22 Mar 2012 21:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzyJDXDIPIwq for ; Thu, 22 Mar 2012 21:42:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEE821E803C for ; Thu, 22 Mar 2012 21:42:25 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb4so2402125obb.31 for ; Thu, 22 Mar 2012 21:42:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=RRU7AQ67xJhrIfh+7IZ01H0oUoyCkCzO0sDrw1fl60o=; b=dLqpV8aesfeO1bWBryLA/23d16PhOSsbW3bpr5PwFxFtaxvGwZL9KUN3udm0LhC5UA z1dv7rn0DLcTY2qUeHSOrB3p6rKHnSuWuS6s0bXb/kO5GL3I9kBQ/uQAhMLFnoJod4bB n5FVaRZbhZFBBWChSeDNh5FuyANmgBl8eGgeiL5wGAk+9rl1HSBxJ/AcybjaOoZxcHkN yBGKHT57hOO4L2kQySa92Sdn8KpqJa9r3yHY4XwdyY+Qyed2+dhFaTTHZ0InrDxjgufC DKWKkcxkjgqneOtRKL8eXCvll92To1pcmD8nHtqOUNLL1gvMRvYc6Xn9M/SxC/XmjppW /o6w== MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr12920734obp.49.1332477744047; Thu, 22 Mar 2012 21:42:24 -0700 (PDT) Received: by 10.182.32.133 with HTTP; Thu, 22 Mar 2012 21:42:24 -0700 (PDT) X-Originating-IP: [71.88.215.247] Date: Fri, 23 Mar 2012 00:42:24 -0400 Message-ID: From: "SenSys'12 Publicity" To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlBW0ta88VaNQhTaNAbMN623dWYy2E7b7s72zagH3I9dlm8DYN/6JUX63T9DNN/ZvCMta12 X-Mailman-Approved-At: Mon, 26 Mar 2012 08:01:02 -0700 Subject: [Roll] [CFP] SenSys 2012: The ACM Conference on Embedded Networked Sensor Systems X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Mar 2012 04:42:26 -0000 *Paper Registration and Abstract: April 1, 2012, 11:59 pm PDT* C A L L F O R P A P E R S **** ACM SenSys 2012 **** Toronto, Canada November 6-9, 2012 http://sensys.acm.org/2012/ The ACM Conference on Embedded Networked Sensor Systems (SenSys 2012) solicits innovative research papers on the systems issues of networked, embedded sensing and control. This is an exciting time in the development of the conference, as we reach the 10th anniversary of the first conference held in Los Angeles. ACM SenSys brings together academic industry, and government professionals to a premier single-track, highly selective forum on sensor network design, implementation, and application. We seek technical papers describing original ideas, groundbreaking results and/or quantified system experiences involving sensor systems. SenSys takes a broad systems perspective of sensor applications and systems. Topics of interest include, but are not limited to, the following: - Experience with real-world deployments and applications - Resource management and OS support for sensing systems - Energy management and harvesting for long-term operation - Innovative sensing applications across broad areas (e.g., environmental monitoring, mobile healthcare, transportation, education) - Wireless communication systems and protocols for sensor networks - Sensor systems leveraging smart phones, body area networks, RFIDs, robots, etc. - Sensing technologies for pervasive computing - Sensor network measurement and characterization - Programming paradigms and models for distributed sensing - Sensor network debugging, fault-tolerance and reliability - Sensing, actuation and control in cyber-physical systems - Distributed sensor data storage, retrieval, processing and management - Approaches to sensor network architecture - Sensor data quality, integrity, and trustworthiness - In-network data reduction, inference, and signal processing - Security and privacy in sensor networks - Time and location estimation and management Submissions will be judged on originality, significance, clarity, relevance, and correctness. In addition to citing relevant, published work, authors must relate their submissions to relevant submissions of their own that are simultaneously under review for this or other venues. SUBMISSION GUIDELINES Submissions must be full papers, at most 14 single-spaced 8.5" x 11" pages, including figures, tables, and references, two-column format, using 10-point type on 11-point (tight single-spaced) leading, with a maximum text block of 7" wide x 9" deep with an intercolumn spacing of .25". Authors must make a good faith effort to anonymize their submissions. Papers that do not meet the size, formatting, and anonymization requirements will not be reviewed. Accepted submissions will be available on the ACM digital library at least one week before the conference. All papers must be submitted through the conference submission site: http://sensys2012.eecs.harvard.edu/ IMPORTANT DATES Paper Registration and Abstract: April 1, 2012, 11:59 pm PDT Paper Submission Deadline: April 8, 2012, 11:59 pm PDT Notification of Paper Acceptance: July 16, 2012 Note that these are hard deadlines - no extensions will be granted. === Committees Organizing committee General Chair Rasit Eskicioglu (University of Manitoba) Program Chairs Andrew T. Campbell (Dartmouth College) Koen Langendoen (Delft University of Technology) Poster Chair Thomas Schmid (University of Utah) Demo Chairs Jakob Eriksson (University of Illinois, Chicago) Pei Zhang (CMU) Local Arrangements Chairs Geoffrey Challen (University of Buffalo) Publicity Chairs Qing Cao (University of Tennessee) Alberta Cerpa (UC Merced) Xiaofan Jiang (Microsoft Research Asia) Chiara Petrioli (University of Rome La Sapienza) Publication Chair Karthik Dantu (Harvard University) Workshop Chair Bodhi Priyantha (Microsoft Research) N2Women Chair Geethapriya Thamilarasu (SUNYIT) Doctoral Colloquium Chair Polly Huang (NTU) Student Travel Award Chair Radu Stoleru (Texas A&M University) Web Site Chair Chieh-Jan Mike Liang (Microsoft Research Asia) Technical program committee Tarek Abdelzaher (UIUC) Philippe Bonnet (Copenhagen) Srdjan Capkun (ETH Zurich) Geoffrey Challen (Buffalo) Hao Chu (NTU) Landon Cox (Duke University) Prabal Dutta (Michigan) Jakob Eriksson (UIC) Deepak Ganesan (UMASS Amherst) Jie Gao (Stony Brook) Omprakash Gnawali (Houston) Santosh Kumar (Memphis) Brano Kusy (CSIRO) Philip Levis (Stanford) Chenyang Lu (WUSTL) Cecilia Mascolo (Cambridge) Emiliano Miluzzo (AT&T Labs) Thomas Moscibroda (Microsoft) Luca Mottola (SICS) Amy Murphy (FBK) Vijay Raghunathan (Purdue) Utz Roedig (Lancaster) Anthony Rowe (CMU) Sivan Toledo (Tel-Aviv) Niki Trigoni (Oxford) Kamin Whitehouse (Virginia) Steering committee SIGMOBILE representative: Chiara Petrioli SIGCOMM representative: Sylvia Ratnasamy (2008-) Sensys 2011 chairs: Jie Liu, Philip Levis, Kay Roemer Sensys 2010 chairs: Jan Beutel, Deepak Ganesan, John Stankovic (current SC chair, 2011) Sensys 2009 chairs: David Culler, Jie Liu, Matt Welsh (SC chair, 2010) ============================================================================== From sensys@cfpmail.info Thu Mar 22 23:43:03 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAEC21E8037 for ; Thu, 22 Mar 2012 23:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4gE-JiQkkww for ; Thu, 22 Mar 2012 23:43:02 -0700 (PDT) Received: from mail-ob0-f194.google.com (mail-ob0-f194.google.com [209.85.214.194]) by ietfa.amsl.com (Postfix) with ESMTP id 68B3A21E8050 for ; Thu, 22 Mar 2012 23:43:02 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so791032obb.1 for ; Thu, 22 Mar 2012 23:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=blotrs7m22HZUQckq0UGVT6gHgaVZGtRv635odHUJxk=; b=kfZX7WpGjrwqt9vjVgb8o1ssQUJGeEk5zl0mcp8KjalVu/QqXqXHOgUBgPDZcSryO8 pG415XxUGF+y0I0DzU4yo5RW7YOmkPQNbR1WBCltQKzuhup4NXdwUYmRiuLVGv9Ki3G3 CaPYHxg+pHR2p0IM94+H8g3e0BStv9mRaFRhrBdukkBaLdoo0tZM5gyb4aKXdQCDQkT+ ixibP+Hq6ypxafnpclzs2YlZoaUavd/8Zy0TIOr7TNlkAaj2jsm4Y7yf9JlcIl3f+GzN JwdTgjkA1pFb2CVJ4kqE+EBQl2J430ZagQd/S7WA8aR1c+ICFGtHoWUTLTrboSloWLsh jpiQ== MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr12783298obl.79.1332477987650; Thu, 22 Mar 2012 21:46:27 -0700 (PDT) Received: by 10.182.32.133 with HTTP; Thu, 22 Mar 2012 21:46:27 -0700 (PDT) X-Originating-IP: [71.88.215.247] Date: Fri, 23 Mar 2012 00:46:27 -0400 Message-ID: From: "SenSys'12 Publicity" To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl4BLUjJY8VI5M48nZeW9SgI/osMm4S+y8zsl5t5vDmPYPWvXtWZqLtwmzqIJ+V/kx0VxDm X-Mailman-Approved-At: Mon, 26 Mar 2012 08:01:02 -0700 Subject: [Roll] ACM SenSys 2012: Call for Workshop Proposals X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Mar 2012 06:43:03 -0000 [Apologies if you got multiple copies of this email.] ====================================================================== Call for Workshop Proposals ACM SenSys 2012 Toronto, Canada November 6-9, 2012 http://sensys.acm.org/2012/ The 10th ACM Conference on Embedded Networked Sensor Systems (SenSys 2012) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities allow for an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. Workshops will be a full day event on the first day of the conference. The ideal workshop proposal should focus on a specific area, be of current interest, and be able to attract a number of high-quality submissions. The proposal should be no longer than three pages and should clearly identify the name of the workshop, theme of the workshop, topic areas of interest to define the scope, names and affiliation of main organizers/program chairs and potential program committee members, the name of the organizing committee member who will be the main point of contact, a tentative call for papers with workshop deadlines and expected number of submissions and participants. The proposal should also specify if this will be a full-day or half-day workshop, and any logistical needs (demos/audio/video projection etc). If this workshop has been held before, also include its history (number of submissions, number of accepted papers, and number of attendees). Please send proposals in PDF format by March 23rd, 2012, 12:00 midnight EST, to the workshop chair, Bodhi Priyantha at bodhip@microsoft.com IMPORTANT DATES: March 23rd, 2012: Proposal submission deadline April 13th, 2012: Notification of acceptance November 6, 2012: SenSys'12 Workshops November 7-9, 2012: SenSys'12 Technical Sessions We look forward to your submissions, Workshop Chair Bodhi Priyantha, Microsoft Research General Chair Rasit Eskicioglu, University of Manitoba From sensys@cfpmail.info Thu Mar 22 23:47:03 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFAA21E8042 for ; Thu, 22 Mar 2012 23:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+Af46EpL9sh for ; Thu, 22 Mar 2012 23:47:03 -0700 (PDT) Received: from mail-ob0-f194.google.com (mail-ob0-f194.google.com [209.85.214.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5745221E8039 for ; Thu, 22 Mar 2012 23:47:03 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so791785obb.1 for ; Thu, 22 Mar 2012 23:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=blotrs7m22HZUQckq0UGVT6gHgaVZGtRv635odHUJxk=; b=I8rVn4ly5gTH8zp7WHh0uqcxvz1brqetL3ej4v7OGD8hXlRfGeq2yWrfYEeD483O/Q HWlDqtHIC4ME77/CKIsOHxteOvLXxr/27IP5vBUjEgNVlOBw6YDP9DueKKJap2IVUWy/ 1lIDixeNF9+EZANFpWsH8VvxoJgByBzkaY0cegZqsD9vkTmpMAo/7vECetHNFwNCa75F VFzWwgCVBGwP0uB7OTt1zPR8SawZ+R6jyUL9Zxxqo92UMV0CTPpzzXfI8myIb16xAmhQ avoWN0Vq3YW0Zohwh/8dO4KvMRKLValj1qIbob1r4JnAL/qDD/45GyxOQF2U7Ms4tuSt R+IA== MIME-Version: 1.0 Received: by 10.60.3.9 with SMTP id 9mr12569368oey.49.1332478128234; Thu, 22 Mar 2012 21:48:48 -0700 (PDT) Received: by 10.182.32.133 with HTTP; Thu, 22 Mar 2012 21:48:48 -0700 (PDT) X-Originating-IP: [71.88.215.247] In-Reply-To: References: Date: Fri, 23 Mar 2012 00:48:48 -0400 Message-ID: From: "SenSys'12 Publicity" To: "SenSys'12 Publicity" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQldD8oeZrvCNx2sj9xA2lyAwkROSizd5vTaobXBxcFSFNQf+r6DYffzIEyY+ZeQLTCTCdLK X-Mailman-Approved-At: Mon, 26 Mar 2012 08:01:02 -0700 Subject: [Roll] ACM SenSys 2012: Call for Workshop Proposals X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Mar 2012 06:47:03 -0000 [Apologies if you got multiple copies of this email.] ====================================================================== Call for Workshop Proposals ACM SenSys 2012 Toronto, Canada November 6-9, 2012 http://sensys.acm.org/2012/ The 10th ACM Conference on Embedded Networked Sensor Systems (SenSys 2012) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities allow for an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. Workshops will be a full day event on the first day of the conference. The ideal workshop proposal should focus on a specific area, be of current interest, and be able to attract a number of high-quality submissions. The proposal should be no longer than three pages and should clearly identify the name of the workshop, theme of the workshop, topic areas of interest to define the scope, names and affiliation of main organizers/program chairs and potential program committee members, the name of the organizing committee member who will be the main point of contact, a tentative call for papers with workshop deadlines and expected number of submissions and participants. The proposal should also specify if this will be a full-day or half-day workshop, and any logistical needs (demos/audio/video projection etc). If this workshop has been held before, also include its history (number of submissions, number of accepted papers, and number of attendees). Please send proposals in PDF format by March 23rd, 2012, 12:00 midnight EST, to the workshop chair, Bodhi Priyantha at bodhip@microsoft.com IMPORTANT DATES: March 23rd, 2012: Proposal submission deadline April 13th, 2012: Notification of acceptance November 6, 2012: SenSys'12 Workshops November 7-9, 2012: SenSys'12 Technical Sessions We look forward to your submissions, Workshop Chair Bodhi Priyantha, Microsoft Research General Chair Rasit Eskicioglu, University of Manitoba From jpv@cisco.com Tue Mar 27 13:31:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6F021E80BC for ; Tue, 27 Mar 2012 13:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6bwp3Bk02kz for ; Tue, 27 Mar 2012 13:31:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1387E21E80BB for ; Tue, 27 Mar 2012 13:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2; q=dns/txt; s=iport; t=1332880317; x=1334089917; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=ZZ3enrJQQ89rHbqvdt3XcBb6ELnQwRGAprfn0nJTyen9YxcAFuFzdJOI 1/X51cMBsXH/ghdXjHnXTDPbSyPZCVFvwocf8mQql+R+3CbEUYWDoSLU5 EMBtShAXVquvPx90pa9FyOh50rr42qYOTchotv2JVp9JWVhKn6FobtvPt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8JAH8jck+Q/khM/2dsb2JhbABFgw6EcLBegQeCBR0BBmCBPjWFJgeCKRKbKJ8NkCxjBJVhhW+IVoFogmk X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="69485746" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 20:31:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RKVtSY014860; Tue, 27 Mar 2012 20:31:55 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 22:31:55 +0200 Received: from [10.108.71.209] ([10.61.81.4]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 22:31:54 +0200 From: JP Vasseur Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 27 Mar 2012 22:31:53 +0200 Message-Id: <315AAD71-0D26-4779-9E92-90DE1AE54475@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 27 Mar 2012 20:31:55.0377 (UTC) FILETIME=[A6817610:01CD0C58] Subject: [Roll] =?windows-1252?q?LAST_REMINDER_=85_SLIDES_ARE_DUE_TODAY_if?= =?windows-1252?q?_you_have_a_presentation_slot_tomorrow=2E?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Mar 2012 20:31:58 -0000 From admin@ipv6it.org Tue Mar 27 15:07:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFCC21E810F for ; Tue, 27 Mar 2012 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm7SG8aM+btu for ; Tue, 27 Mar 2012 15:07:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0DA21F8516 for ; Tue, 27 Mar 2012 15:07:23 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so260631wgb.13 for ; Tue, 27 Mar 2012 15:07:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=nsJUbJAxkBXmZBWRWPQZAIQUhyqU2Jun99yZhsziTT0=; b=hYeiuMRQDT1n4v2oHGOBxNZiTGypMdjRHogPK/x5GOHW1UQj5+5Diqt8fNR+v6l4bS XB+j7fTOJFo/IPuScOtZ9nUIlJd6C9zUXc+dahJ4Ass7lUBho+RjR7vcUIB48Amrw+jL t8PC4kPPBOwD5u4BAaJ3gUum/H50ya3LO4Qsre/1lFWhHS0PzZYtWczXjP06XYkm332q jnj0PD30FJRW96j7j2I1KfOAorzkfnv3OkigsvP1vkxfHzObqfd8YUob4B55wv+GFB8A wwl8YRgfW910qEw40mrBeibftO4DHEvL5c2qa2vyPudWXjqVekfBhyfXcZ5S75LRXtUN Nd7g== Received: by 10.216.144.138 with SMTP id n10mr15691578wej.56.1332886042771; Tue, 27 Mar 2012 15:07:22 -0700 (PDT) Received: from [127.0.0.1] (host243-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.243]) by mx.google.com with ESMTPS id l5sm52783081wia.11.2012.03.27.15.07.21 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:07:21 -0700 (PDT) Message-ID: <4F723A15.7040900@ipv6it.org> Date: Wed, 28 Mar 2012 00:07:17 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Roll@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlMnkP8OZYHlGuqYAbdc5WWoyzlnXmJu4XuCm1POaMAkpIzAQyczHJuyhsKUfag1TEjsn43 Subject: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Mar 2012 22:08:01 -0000 Hi, I have a doubt about the root's rank with ETX. Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: A is root B is non-root Link between A and B has a cost of 256 (ETX=2) A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*). B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256. But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*). (1*) MRHOF - Section 3.1 "Root nodes (Grounded or Floating) set the variable cur_min_path_cost to MIN_PATH_COST." (2*) MRHOF - Section 3.3 "DAG roots set their Rank to MinHopRankIncrease." (3*) MRHOF - Section 5. "MIN_PATH_COST: 0. At root, the expected transmission count is 0." (4*) RPL-RFC Section 17 "DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256" (5*) RPL-RFC Section 3.4 "the rank of the nodes must monotonically decrease as the DODAG version is followed towards the DODAG destination" (6*) MRHOF Section 3.5. "If ETX is the selected metric, a node SHOULD NOT advertise it in a metric container. Instead, a node MUST advertise an approximation of its ETX in its advertised Rank value" (7*) MRHOF Section 3.3 max(256+0,0+1,256-256) -> 256+0 -> 256 -- Regards Consoli Federico From jpv@cisco.com Tue Mar 27 22:09:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A9B21F86CA for ; Tue, 27 Mar 2012 22:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.205 X-Spam-Level: X-Spam-Status: No, score=-110.205 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JLS-RDnfVgy for ; Tue, 27 Mar 2012 22:08:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9321F86C1 for ; Tue, 27 Mar 2012 22:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=263; q=dns/txt; s=iport; t=1332911337; x=1334120937; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=PTQ3lVSAJTHkCowr8peGER9dMVDl2pKSY5YyCUxOOYY=; b=nG+Cip7TxFuWFD5i1+t4LOr1N86otU5e8CqI2U/ucT2LGlHXxTREkbhg e57VIvlfCieGURsK4QkBsULX2/hhukzLFmoZtAm40nXs6zmFJtiWgRktG 3X9h2kXunAz8ukzay+NktUGJw844SzMnW75w1j7qMDZI1vDOGIvEp9Dcq o=; X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="133549788" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2012 05:08:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2S58uMX017523; Wed, 28 Mar 2012 05:08:56 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 07:08:56 +0200 Received: from [10.108.71.178] ([10.61.83.94]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 07:08:55 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: JP Vasseur In-Reply-To: <315AAD71-0D26-4779-9E92-90DE1AE54475@cisco.com> Date: Wed, 28 Mar 2012 07:08:56 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <315AAD71-0D26-4779-9E92-90DE1AE54475@cisco.com> To: ROLL WG , JP Vasseur X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 28 Mar 2012 05:08:55.0825 (UTC) FILETIME=[E0223010:01CD0CA0] Subject: Re: [Roll] =?windows-1252?q?LAST_REMINDER_=85_SLIDES_ARE_DUE_TODAY_if?= =?windows-1252?q?_you_have_a_presentation_slot_tomorrow=2E?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 05:09:02 -0000 Still waiting for the missing slides - thanks to send them ASAP. JP. On Mar 27, 2012, at 10:31 PM, JP Vasseur wrote: > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Mar 28 02:57:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE15F21F89DB for ; Wed, 28 Mar 2012 02:57:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWc3W4AM+5rH for ; Wed, 28 Mar 2012 02:57:00 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6C23521F89D1 for ; Wed, 28 Mar 2012 02:57:00 -0700 (PDT) Received: from dhcp-1702.meeting.ietf.org ([130.129.23.2]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SCpcg-0004oT-GW; Wed, 28 Mar 2012 02:56:58 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4F723A15.7040900@ipv6it.org> Date: Wed, 28 Mar 2012 11:56:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> References: <4F723A15.7040900@ipv6it.org> To: Federico Consoli X-Mailer: Apple Mail (2.1257) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 09:57:01 -0000 On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: > Hi, I have a doubt about the root's rank with ETX. > Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: > A is root > B is non-root > Link between A and B has a cost of 256 (ETX=3D2) >=20 > A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in = its DIO message in its advertised Rank value(6*). >=20 > B will receive a DIO with rank value =3D 0 so B will set his rank to = 256(7*) and will annunce a path_cost of 256. >=20 > But now I got 2 nodes with the same rank value. I think it's not a = problem with the algorith of DODAG creation but it's not RPL = complaint(5*). Good catch. I think the issue here is the MRHOF draft is not clear: A (a root) = should advertise a Rank of 256, and B, following 3.3, would advertise a = Rank of 256 + MinHopRankIncrease (case 3 of 3.3). This does get at a more fundamental issue, one where the rules on Rank = and the rules on metrics can diverge. I'd argue that the text saying = Root nodes set to MIN_PATH_COST should instead relate to = MinHopRankIncrease; 3.3 was designed given the RPL specification, but I = think the cur_min_path_cost clause is out of sync with it. What do you = think? Phil= From pthubert@cisco.com Wed Mar 28 03:25:11 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49E421F8A2C for ; Wed, 28 Mar 2012 03:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.084 X-Spam-Level: X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiYL1t9qWhOl for ; Wed, 28 Mar 2012 03:25:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7127A21F8950 for ; Wed, 28 Mar 2012 03:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4562; q=dns/txt; s=iport; t=1332930310; x=1334139910; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=jpMDYl4ZSqZvg9RAjRUmZrTLyxbrhrPaykuBP11QwXo=; b=k3C2jForeC4kxRn8yBlar7dVYXjSp/euv6PLJjxxDTMMcy85ufUnHAFz w+0GfhHi0GFDh9efqiDDSX5AEhtX96Xs1uAArQMDC6PBLHBNFC+Ai3DQi 2Gj4lSzAfs2ZSpUNxxLeiCNeCIC833AZwe8EPK/Tpj7KFd4L32gF3S3dW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKbmck+Q/khN/2dsb2JhbABFuG2BB4ILAQQSAR0KUQEqBhgHVwEEGxqHaJoigSefGZAvYwSkJoFogmmBUhc X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="69530372" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2012 10:25:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2SAP9Fm002059 for ; Wed, 28 Mar 2012 10:25:09 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 12:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2012 12:23:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: G.RE: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 Thread-Index: Ac0MzNPxg/XWhC8bR2iM+2O3LzHJDQ== From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 28 Mar 2012 10:25:09.0299 (UTC) FILETIME=[0D349030:01CD0CCD] Subject: [Roll] G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 10:25:11 -0000 Dear authors: The draft is really clear and readable. Thanks a lot for this excellent work. General ---------- I understand the need for concise messaging, which tends to create specific options with one stop shopping for all needed information in there. OTOH RPL has a modular use of options that enable multiple sorts of combinations and factorization. Using Target option is a good move. Main suggestions: 1) Remove the target from the new P2P route discovery option. So you can place one or more times a P2P RD Option each followed by one or more target option(s), or set different lookup parameters for different targets. 2) Allow for targets that are not necessarily unicast. 3) Allow for (compressed) UDP header in the data. The completely opaque forms limits the use of the option a bit too drastically. /* In another draft I'd think we need to allow a mode with target but not P2P RD option. This would be done to trigger DAOs, e.g. to complete a hole in a Source Route recursion, or save space in storing mode. */ Detailed review "Forward Route: A route in the forward direction, i.e., from the origin to the target." I think you want to define the forward direction first and then the forward route. In both case you probably want to capitalize all instances in the text. Same goes for the following terms. "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver timecritical application data to the target(s)." If DRO establishes path from origin to target then without a DRO, the target can send to the origin, not the other way around? If so I'd reword like if DRO is not requested, the DAG can only be used unidirectionally to report data from the target(s) to the origin. "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. " A P2P mode DIO: o MUST carry one (and only one) P2P Route Discovery Option (described in Section 7.1). The P2P Route Discovery Option allows for the specification of one unicast or multicast address for the target." Well; I can see how there would be only a target and no RDO, if we have good defaults. And I can see how a target could have a different DRO than the next target in the same DIO. So I do not agree with that statement at all. " MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... " When a target receives a P2P mode DIO, it forwards the data in any Data Options to the higher layer." As I hinted, this is not well enough defined. You're really using the DIO as a transport, so you need a minimum transport paradigm like a compressed UDP header. This comment applies to DRO as well, obviously. " Options: The DRO message: * MUST carry one P2P-RDO that MUST specify a complete route between the target and the origin;" If we establish a hop by hop with default values, could we live with just a target? /*I did not review the trickle piece considering that Phil went through it and was satisfied */ 9.4: I'ma bit confused about the node that received multiple DIOs.=20 Like: Should a node wait a bit before issuing its own DIO, to accommodate for a better route being received later?=20 Can the data option be different from one DIO to the next?=20 "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater.=20 But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. " A target MUST NOT forward a P2P mode DIO any further."=20 That is, if it is the only target in the DIO, AND the target is unicast. Cheers! Pascal Pascal From geoff.ietf@mulligan.com Wed Mar 28 03:31:38 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC0D21F86BE for ; Wed, 28 Mar 2012 03:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTlvONy82h7F for ; Wed, 28 Mar 2012 03:31:37 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by ietfa.amsl.com (Postfix) with ESMTP id D096921F8744 for ; Wed, 28 Mar 2012 03:31:36 -0700 (PDT) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTPS id B3C8418077 for ; Wed, 28 Mar 2012 04:31:36 -0600 (MDT) Received: from [130.129.16.171] (dhcp-10ab.meeting.ietf.org [130.129.16.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id 29B261FF13 for ; Wed, 28 Mar 2012 04:31:23 -0600 (MDT) Message-ID: <4F72E885.60108@mulligan.com> Date: Wed, 28 Mar 2012 04:31:33 -0600 From: "Geoff Mulligan (IETF)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Comments on draft-ietf-roll-applicability-ami-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 10:31:38 -0000 First, I do not understand why this document is not still draft-popa rather than being a working group document. It was never adequately explained how this draft went from being submitted to becoming a working group document in just a few hours with absolutely no discussion on the Roll mailing list. While that might be allowed it certainly is not in the spirit of IETF process. So, away from process and to the draft itself... In the first paragraph of section 1.3: Current text: RPL provides routing functionality for mesh networks that can scale up to thousands of devices... New text: RPL provides routing functionality for mesh networks that might be able to scale up to thousands of devices... Alternate new text: RPL provides routing functionality for mesh networks that hopefully will be shown to scale up to thousands of devices... On the same page: Current text: RPL was designed to meeting the requirements of Building Automation. New text: RPL was designed to meeting the requirements of Building Automation, but does not currently meet these requirements In section 2.1.1... Current text: ... the nearest LBR may be composed of several hops or even several tens of hops. New text: ... the nearest LBR may be composed of several hops or even several tens of hops. While RPL has been shown to work over 1 or 2 hops, it will hopefully be shown to work over tens of hops. Section 2.2.1... The fourth paragraph states that SMD traffic is highly asymmetric. While for meter data this may be true for traffic volume, but it should be noted that for number of packets this is probably not the case when packet ACKs are taken into account. Also since this is a draft about AMI, it is not correct to extrapolate meter data to a full AMI deployment where much more data and packets will be sent to the home and the data and packets may be nearly symmetric. It should be pointed out that while RPL appears to support MP2P pretty well, it is unclear how well RPL will be able to support P2MP or P2P on a large scale as required in potential AMI networks. Current text: Current SMD traffic patterns are fairly uniform and well-understood. The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads, while traffic generated by the metering devices is typically uniformly spread over some periodic read time-window. New Text: While current SMD traffic patterns are fairly uniform and well-understood, the traffic patterns for AMI deployments is not yet well-understood. For SMD, the traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads, while traffic generated by the metering devices is typically uniformly spread over some periodic read time-window, whereas in future AMI deployments traffic may not be dominated by just meter reading and may instead be dominated by command/control messaging and may not be uniformly spread over a time-window. Current text: From a routing perspective, SMD applications require efficient P2MP communication between the devices in the network and one or more LBRs. New text: From a routing perspective, while SMD applications require efficient MP2P communication between the devices in the network and one or more LBRs, AMI networks will likely require efficient P2MP and P2P communications. Section 2.2.2 DA comms This section defines some requirements for DA and it is implied that RPL meets these requirements, but it does not that it does or how it does. RPL has not been shown to meet these requirements, but it appears the draft would like the reader to assume that RPL does. Section 4.1.2 This paragraph: When meters are memory constrained and cannot adequately store the route tables necessary to support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On the other hand, when nodes are capable of storing such routing tables, the use of storing mode may lead to reduced overhead and route repair latency. However, in high-density environments, storing routes can be challenging because some nodes may have to maintain routing information for a large number of descendents. When the routing table size becomes challenging, it is RECOMMENDED that nodes perform route aggregation, similarly to the approach taken by other routing protocols, although the required set of mechanism may differ. This paragraph fails to warn the reader of the problems associated with storing vs. non-storing mode and implies that all this is solved. It needs to be expanded to explain the trade-offs of band-width, packets sizes, contention vs memory requirements and it is not a simple if you don't have enough memory, just use non-storing mode or just use route aggregation which is not yet a solved problem in RPL. Section 4.1.3 Current text: Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send DAO messages to establish downward paths from the root to themselves. Is this a MUST? Section 4.1.5 Current text: Two objective functions for RPL have been defined at the time of this writing, OF0 and MRHOF, both of which define the selection of a preferred parent and backup parents, and are suitable for AMI deployments. New text: Two objective functions for RPL have been defined at the time of this writing, OF0 and MRHOF, both of which define the selection of a preferred parent and backup parents, and either may be suitable for AMI deployments. Section 4.1.6 Current text: While detached, a node advertises an infinite rank value so that its children can select a different parent. New text: While detached, a node advertises an infinite rank value so that its children can select a different parent. During this time the entire sub DODAG is unstable and does not have connectivity to the LBR or the rest of the network. Current text: Setting the DAGMaxRankIncrease to a non-zero value enables this mechanism, and setting it to a value of less than infinity limits the cost of count-to-infinity scenarios when they occur, thus controlling the duration of disconnection applications may experience. Some numbers would be helpful. What numbers provide what durations. Section 4.1.7 Current text: Multicast support for RPL in non-storing mode will be defined in companion RFCs. New text: Multicast support for RPL in non-storing mode will be defined in companion RFCs, so therefore multicast for large networks with memory constrained devices is not yet supported or defined. Section 4.1.8 Current text: AMI deployments operate in areas that do not provide any physical security. For this reason, the link layer, transport layer and application layer technologies utilized within AMI networks typically provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness. As a result, AMI deployments may not need to implement RPL's security mechanisms and could rely on link layer and higher layer security features. New text: AMI deployments operate in areas that do not provide any physical security. For this reason, the link layer, transport layer and application layer technologies utilized within AMI networks typically provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness of the AMI data but not the authentication, integrity or freshness of the routing control information. As a result, AMI deployments SHOULD implement RPL's security mechanisms and cannot rely on link layer and higher layer security features. Section 4.2.1 Current text: In high density environments, relatively low values for Imin may cause a short period of congestion when an inconsistency is detected and DIO updates are sent by a large number of neighboring nodes nearly simultaneously. While the Trickle timer will exponentially backoff, some time may elapse before the congestion subsides. It would be good to nail down some values. What is a "relatively low value" that will result in what kind of short period of congestion. What is "some time"? What orders of magnitude? Seconds, minutes, micro-seconds... DIOIntervalMin: This paragraph recommends a value - GREAT, but what is the result of this choice? What happens if you choose a number greater or smaller? DIOIntervalDoublings: Same comment - what if I choose a different value? What is the result? What is the result in performance if I choose either of these values. Section 4.2.2 Current text: AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 bits of resolution (e.g., for the ETX metric). What are the results of choosing 256. Why 256 and not 128 or 512 or any other number. Current text: To enable local repair, AMI deployments SHOULD set MaxRankIncrease to a value that allows a device to move a small number of hops away from the root. With a MinHopRankIncrease of 256, a MaxRankIncrease of 1024 would allow a device to move up to 4 hops away. What is the result of choosing 256. How did you arrive at this number. What is performance trade-off? Is this based on some specific bandwidth, number of nodes in the network, depth of the network, ... Section 6 Current text: As a result link-layer, transport-layer and/or application-layer security mechanisms are typically in place and using RPL's secure mode is not necessary. Same comment as the previous section on security. From weiyinxing@gmail.com Wed Mar 28 05:01:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0721E817F for ; Wed, 28 Mar 2012 05:01:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW54PQh11iCb for ; Wed, 28 Mar 2012 05:01:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3888621E8179 for ; Wed, 28 Mar 2012 05:01:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so724062vbb.31 for ; Wed, 28 Mar 2012 05:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sEFat5EPp+3rohhvi9rCIvIoxcTQ8njfehDgwQehUoU=; b=dIB7tH0wiLd2BouCPUp//p3kpKDh4eIvrirejl/o2D4S9ZoMIhCZ1GX4oURM9Ui1pM gvlzYjXYpz2tfBV8ea4ZvqnZmEUXP561UJwk2seZno91k6toZcPrqLNzYU3VC7JPbKKK DRqO3jSJgNhGPraaamLHIx+Lchz1UZ5UjQVmJqksrIH9O1wzl+s4N5NSaGd7BTNmMp1Y zG5va/bHNi9ibm4c9atufztjJQ7Cb3N0EPXxyfplQ5MSlKeMcDbI1XSYi9OTGMDCwLWU smngl995Yg1uAb9X+byCTvXRezgETkga1OZziHOzGRwDKbW6BLV1d561GGvzJRnIvPh+ zfRQ== MIME-Version: 1.0 Received: by 10.52.64.234 with SMTP id r10mr11625269vds.39.1332936117409; Wed, 28 Mar 2012 05:01:57 -0700 (PDT) Received: by 10.220.182.13 with HTTP; Wed, 28 Mar 2012 05:01:57 -0700 (PDT) Date: Wed, 28 Mar 2012 20:01:57 +0800 Message-ID: From: yinxing wei To: roll@ietf.org Content-Type: multipart/alternative; boundary=20cf307ac775c9566604bc4c5f51 Subject: [Roll] [roll] Question: What is the identity in roll to be used in authentication and other security purposes? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 12:02:00 -0000 --20cf307ac775c9566604bc4c5f51 Content-Type: text/plain; charset=ISO-8859-1 Hi, There are several documents related to security. When I read the document, I have no idea what the identity of a node is. I think this is the basis for authentication and other security mechanisms. Am I missing some text? Hope someone can answer it. Thanks! ------------------ Yinxing Wei --20cf307ac775c9566604bc4c5f51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

=A0 There are several documents related to security.= When I read the document, I have no idea what the identity of a node is. I= think this is the basis for authentication and other security mechanisms. = Am I missing some text? Hope someone can answer it.

Thanks!

------------------
Yinxing Wei
--20cf307ac775c9566604bc4c5f51-- From jpv@cisco.com Wed Mar 28 07:21:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E521E81F5 for ; Wed, 28 Mar 2012 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAQmQlWoYwED for ; Wed, 28 Mar 2012 07:21:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6321E805F for ; Wed, 28 Mar 2012 07:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=26300; q=dns/txt; s=iport; t=1332944473; x=1334154073; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=U5pB8D0o5Vvahgi5NPhDBgbgvy5IV/GEWiyG5D7tuwI=; b=insQpilP4teO3p48nRB7nWMIC+owZjd4EzjZvDgPumRUUMp/CQ5BBBwv uzWc1qk6ig7P/1FvZit4bcU2Z5Xdo8ulChUdtpO2m39HhxqmWuu9AttKK PUuCtlKL07jMSsNcGmBAL1i67YTZTSfLW5K7DqVfKOBMNCNaA43nqpfjy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAOUdc0+Q/khR/2dsb2JhbABFgkatMIh3gQeCCQEBAQMBAQEBDwEHVAsFCwstGScwBhMcBodjBQubWZ8ejWKCTWMElWGBEYReiFaBaIJpgVo X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208,217";a="69557408" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2012 14:21:11 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SELB0O018368; Wed, 28 Mar 2012 14:21:11 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 16:21:10 +0200 Received: from [64.103.29.144] ([64.103.29.144]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 16:21:10 +0200 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0FE8540-244F-405E-BD2A-CC0834C77C9C" From: JP Vasseur In-Reply-To: <4F72E885.60108@mulligan.com> Date: Wed, 28 Mar 2012 16:21:10 +0200 Message-Id: References: <4F72E885.60108@mulligan.com> To: Geoff Mulligan (IETF) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 28 Mar 2012 14:21:10.0513 (UTC) FILETIME=[05F25610:01CD0CEE] Cc: ROLL WG Subject: Re: [Roll] Comments on draft-ietf-roll-applicability-ami-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 14:21:17 -0000 --Apple-Mail=_B0FE8540-244F-405E-BD2A-CC0834C77C9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Geoff, =20 Just to handle the process question. You are a working group chair so = you know how the process works. I am sure you went to the working group = chairs' training at Maastricht where we discussed the parameters for = adopting working group drafts. = (http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchai= rs-Adrian-Farrel.ppt) =20 We have a working group deliverable, and we were asked by the IESG to = make sure we deliver this work. The working group needs a place to do = its work - a working group draft. =20 We now have one and the WG can drive the changes as you are doing in the = rest of your email. Thanks for the comments below, the authors will surely address them. JP. On Mar 28, 2012, at 12:31 PM, Geoff Mulligan (IETF) wrote: > First, I do not understand why this document is not still draft-popa = rather than being a working group document. It was never adequately = explained how this draft went from being submitted to becoming a working = group document in just a few hours with absolutely no discussion on the = Roll mailing list. While that might be allowed it certainly is not in = the spirit of IETF process. >=20 > So, away from process and to the draft itself... >=20 > In the first paragraph of section 1.3: > Current text: RPL provides routing functionality for mesh networks = that can scale up to thousands of devices... >=20 > New text: RPL provides routing functionality for mesh networks that = might be able to scale up to thousands of devices... >=20 > Alternate new text: RPL provides routing functionality for mesh = networks that hopefully will be shown to scale up to thousands of = devices... >=20 > On the same page: > Current text: RPL was designed to meeting the requirements of Building = Automation. >=20 > New text: RPL was designed to meeting the requirements of Building = Automation, but does not currently meet these requirements >=20 > In section 2.1.1... > Current text: ... the nearest LBR may be composed of several hops or = even several tens of hops. >=20 > New text: ... the nearest LBR may be composed of several hops or even = several tens of hops. While RPL has been shown to work over 1 or 2 hops, = it will hopefully be shown to work over tens of hops. >=20 > Section 2.2.1... > The fourth paragraph states that SMD traffic is highly asymmetric. = While for meter data this may be true for traffic volume, but it should = be noted that for number of packets this is probably not the case when = packet ACKs are taken into account. >=20 > Also since this is a draft about AMI, it is not correct to extrapolate = meter data to a full AMI deployment where much more data and packets = will be sent to the home and the data and packets may be nearly = symmetric. >=20 > It should be pointed out that while RPL appears to support MP2P pretty = well, it is unclear how well RPL will be able to support P2MP or P2P on = a large scale as required in potential AMI networks. >=20 > Current text: Current SMD traffic patterns are fairly uniform and = well-understood. The traffic generated by the head-end server and = destined to metering devices is dominated by periodic meter reads, while = traffic generated by the metering devices is typically uniformly spread = over some periodic read time-window. >=20 > New Text: While current SMD traffic patterns are fairly uniform and = well-understood, the traffic patterns for AMI deployments is not yet = well-understood. For SMD, the traffic generated by the head-end server = and destined to metering devices is dominated by periodic meter reads, = while traffic generated by the metering devices is typically uniformly = spread over some periodic read time-window, whereas in future AMI = deployments traffic may not be dominated by just meter reading and may = instead be dominated by command/control messaging and may not be = uniformly spread over a time-window. >=20 > Current text: =46rom a routing perspective, SMD applications require = efficient P2MP communication between the devices in the network and one = or more LBRs. >=20 > New text: =46rom a routing perspective, while SMD applications require = efficient MP2P communication between the devices in the network and one = or more LBRs, AMI networks will likely require efficient P2MP and P2P = communications. >=20 > Section 2.2.2 DA comms > This section defines some requirements for DA and it is implied that = RPL meets these requirements, but it does not that it does or how it = does. RPL has not been shown to meet these requirements, but it appears = the draft would like the reader to assume that RPL does. >=20 > Section 4.1.2 > This paragraph: > When meters are memory constrained and cannot adequately store the = route tables necessary to support hop-by-hop routing, RPL non-storing = mode SHOULD be preferred. On the other hand, when nodes are capable of = storing such routing tables, the use of storing mode may lead to reduced = overhead and route repair latency. However, in high-density = environments, storing routes can be challenging because some nodes may = have to maintain routing information for a large number of descendents. = When the routing table size becomes challenging, it is RECOMMENDED that = nodes perform route aggregation, similarly to the approach taken by = other routing protocols, although the required set of mechanism may = differ. >=20 > This paragraph fails to warn the reader of the problems associated = with storing vs. non-storing mode and implies that all this is solved. = It needs to be expanded to explain the trade-offs of band-width, packets = sizes, contention vs memory requirements and it is not a simple if you = don't have enough memory, just use non-storing mode or just use route = aggregation which is not yet a solved problem in RPL. >=20 > Section 4.1.3 > Current text: > Two-way communication is a requirement in AMI systems. As a result, = nodes SHOULD send DAO messages to establish downward paths from the root = to themselves. >=20 > Is this a MUST? >=20 > Section 4.1.5 > Current text: > Two objective functions for RPL have been defined at the time of this = writing, OF0 and MRHOF, both of which define the selection of a = preferred parent and backup parents, and are suitable for AMI = deployments. >=20 > New text: > Two objective functions for RPL have been defined at the time of this = writing, OF0 and MRHOF, both of which define the selection of a = preferred parent and backup parents, and either may be suitable for AMI = deployments. >=20 > Section 4.1.6 > Current text: > While detached, a node advertises an infinite rank value so that its = children can select a different parent. >=20 > New text: > While detached, a node advertises an infinite rank value so that its = children can select a different parent. During this time the entire sub = DODAG is unstable and does not have connectivity to the LBR or the rest = of the network. >=20 > Current text: > Setting the DAGMaxRankIncrease to a non-zero value enables this = mechanism, and setting it to a value of less than infinity limits the = cost of count-to-infinity scenarios when they occur, thus controlling = the duration of disconnection applications may experience. >=20 > Some numbers would be helpful. What numbers provide what durations. >=20 > Section 4.1.7 > Current text: > Multicast support for RPL in non-storing mode will be defined in = companion RFCs. >=20 > New text: > Multicast support for RPL in non-storing mode will be defined in = companion RFCs, so therefore multicast for large networks with memory = constrained devices is not yet supported or defined. >=20 > Section 4.1.8 > Current text: > AMI deployments operate in areas that do not provide any physical = security. For this reason, the link layer, transport layer and = application layer technologies utilized within AMI networks typically = provide security mechanisms to ensure authentication, confidentiality, = integrity, and freshness. As a result, AMI deployments may not need to = implement RPL's security mechanisms and could rely on link layer and = higher layer security features. >=20 > New text: > AMI deployments operate in areas that do not provide any physical = security. For this reason, the link layer, transport layer and = application layer technologies utilized within AMI networks typically = provide security mechanisms to ensure authentication, confidentiality, = integrity, and freshness of the AMI data but not the authentication, = integrity or freshness of the routing control information. As a result, = AMI deployments SHOULD implement RPL's security mechanisms and cannot = rely on link layer and higher layer security features. >=20 > Section 4.2.1 > Current text: > In high density environments, relatively low values for Imin may cause = a short period of congestion when an inconsistency is detected and DIO = updates are sent by a large number of neighboring nodes nearly = simultaneously. While the Trickle timer will exponentially backoff, some = time may elapse before the congestion subsides. >=20 > It would be good to nail down some values. What is a "relatively low = value" that will result in what kind of short period of congestion. = What is "some time"? What orders of magnitude? Seconds, minutes, = micro-seconds... >=20 > DIOIntervalMin: This paragraph recommends a value - GREAT, but what is = the result of this choice? What happens if you choose a number greater = or smaller? >=20 > DIOIntervalDoublings: Same comment - what if I choose a different = value? What is the result? What is the result in performance if I = choose either of these values. >=20 > Section 4.2.2 > Current text: > AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 = bits of resolution (e.g., for the ETX metric). >=20 > What are the results of choosing 256. Why 256 and not 128 or 512 or = any other number. >=20 > Current text: > To enable local repair, AMI deployments SHOULD set MaxRankIncrease to = a value that allows a device to move a small number of hops away from = the root. With a MinHopRankIncrease of 256, a MaxRankIncrease of 1024 = would allow a device to move up to 4 hops away. >=20 > What is the result of choosing 256. How did you arrive at this = number. What is performance trade-off? Is this based on some specific = bandwidth, number of nodes in the network, depth of the network, ... >=20 > Section 6 > Current text: > As a result link-layer, transport-layer and/or application-layer = security mechanisms are typically in place and using RPL's secure mode = is not necessary. >=20 > Same comment as the previous section on security. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_B0FE8540-244F-405E-BD2A-CC0834C77C9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just = to handle the process question. You are a working group chair so you = know how the process works. I am sure you went to the working group = chairs' training at Maastricht where we discussed the parameters for = adopting working group drafts. (http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGcha= irs-Adrian-Farrel.ppt)
We = have a working group deliverable, and we were asked by the IESG to make = sure we deliver this work. The working group needs a place to do its = work - a working group draft.
We = now have one and the WG can drive the changes as you are doing in the = rest of your email.
Thanks for the comments = below, the authors will surely address them.

JP.

On Mar = 28, 2012, at 12:31 PM, Geoff Mulligan (IETF) wrote:

First, = I do not understand why this document is not still draft-popa rather = than being a working group document.  It was never adequately = explained how this draft went from being submitted to becoming a working = group document in just a few hours with absolutely no discussion on the = Roll mailing list.  While that might be allowed it certainly is not = in the spirit of IETF process.

So, away from process and to the = draft itself...

In the first paragraph of section 1.3:
Current = text: RPL provides routing functionality for mesh networks that can = scale up to thousands of devices...

New text: RPL provides = routing functionality for mesh networks that might be able to scale up = to thousands of devices...

Alternate new text: RPL provides = routing functionality for mesh networks that hopefully will be shown to = scale up to thousands of devices...

On the same page:
Current = text: RPL was designed to meeting the requirements of Building = Automation.

New text: RPL was designed to meeting the = requirements of Building Automation, but does not currently meet these = requirements

In section 2.1.1...
Current text: ... the nearest = LBR may be composed of several hops or even several tens of = hops.

New text: ... the nearest LBR may be composed of several = hops or even several tens of hops. While RPL has been shown to work over = 1 or 2 hops, it will hopefully be shown to work over tens of = hops.

Section 2.2.1...
The fourth paragraph states that SMD = traffic is highly asymmetric.  While for meter data this may be = true for traffic volume, but it should be noted that for number of = packets this is probably not the case when packet ACKs are taken into = account.

Also since this is a draft about AMI, it is not correct = to extrapolate meter data to a full AMI deployment where much more data = and packets will be sent to the home and the data and packets may be = nearly symmetric.

It should be pointed out that while RPL appears = to support MP2P pretty well, it is unclear how well RPL will be able to = support P2MP or P2P on a large scale as required in potential AMI = networks.

Current text: Current SMD traffic patterns are fairly = uniform and well-understood. The traffic generated by the head-end = server and destined to metering devices is dominated by periodic meter = reads, while traffic generated by the metering devices is typically = uniformly spread over some periodic read time-window.

New Text: = While current SMD traffic patterns are fairly uniform and = well-understood, the traffic patterns for AMI deployments is not yet = well-understood.  For SMD, the traffic generated by the head-end = server and destined to metering devices is dominated by periodic meter = reads, while traffic generated by the metering devices is typically = uniformly spread over some periodic read time-window, whereas in future = AMI deployments traffic may not be dominated by just meter reading and = may instead be dominated by command/control messaging and may not be = uniformly spread over a time-window.

Current text: =46rom a = routing perspective, SMD applications require efficient P2MP = communication between the devices in the network and one or more = LBRs.

New text: =46rom a routing perspective, while SMD = applications require efficient MP2P communication between the devices in = the network and one or more LBRs, AMI networks will likely require = efficient P2MP and P2P communications.

Section 2.2.2 DA = comms
This section  defines some requirements for DA and it is = implied that RPL meets these requirements, but it does not that it does = or how it does.  RPL has not been shown to meet these requirements, = but it appears the draft would like the reader to assume that RPL = does.

Section 4.1.2
This paragraph:
When meters are memory = constrained and cannot adequately store the route tables necessary to = support hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On = the other hand, when nodes are capable of storing such routing tables, = the use of storing mode may lead to reduced overhead and route repair = latency. However, in high-density environments, storing routes can be = challenging because some nodes may have to maintain routing information = for a large number of descendents. When the routing table size becomes = challenging, it is RECOMMENDED that nodes perform route aggregation, = similarly to the approach taken by other routing protocols, although the = required set of mechanism may differ.

This paragraph fails to = warn the reader of the problems associated with storing vs. non-storing = mode and implies that all this is solved.  It needs to be expanded = to explain the trade-offs of band-width, packets sizes, contention vs = memory requirements and it is not a simple if you don't have enough = memory, just use non-storing mode or just use route aggregation which is = not yet a solved problem in RPL.

Section 4.1.3
Current = text:
Two-way communication is a requirement in AMI systems. As a = result, nodes SHOULD send DAO messages to establish downward paths from = the root to themselves.

Is this a MUST?

Section = 4.1.5
Current text:
Two objective functions for RPL have been = defined at the time of this writing, OF0 and MRHOF, both of which define = the selection of a preferred parent and backup parents, and are suitable = for AMI deployments.

New text:
Two objective functions for RPL = have been defined at the time of this writing, OF0 and MRHOF, both of = which define the selection of a preferred parent and backup parents, and = either may be suitable for AMI deployments.

Section = 4.1.6
Current text:
While detached, a node advertises an infinite = rank value so that its children can select a different = parent.

New text:
While detached, a node advertises an = infinite rank value so that its children can select a different parent. = During this time the entire sub DODAG is unstable and does not have = connectivity to the LBR or the rest of the network.

Current = text:
Setting the DAGMaxRankIncrease to a non-zero value enables this = mechanism, and setting it to a value of less than infinity limits the = cost of count-to-infinity scenarios when they occur, thus controlling = the duration of disconnection applications may experience.

Some = numbers would be helpful.  What numbers provide what = durations.

Section 4.1.7
Current text:
Multicast support = for RPL in non-storing mode will be defined in companion = RFCs.

New text:
Multicast support for RPL in non-storing mode = will be defined in companion RFCs, so therefore multicast for large = networks with memory constrained devices is not yet supported or = defined.

Section 4.1.8
Current text:
AMI deployments = operate in areas that do not provide any physical security. For this = reason, the link layer, transport layer and application layer = technologies utilized within AMI networks typically provide security = mechanisms to ensure authentication, confidentiality, integrity, and = freshness. As a result, AMI deployments may not need to implement RPL's = security mechanisms and could rely on link layer and higher layer = security features.

New text:
AMI deployments operate in areas = that do not provide any physical security. For this reason, the link = layer, transport layer and application layer technologies utilized = within AMI networks typically provide security mechanisms to ensure = authentication, confidentiality, integrity, and freshness of the AMI = data but not the authentication, integrity or freshness of the routing = control information. As a result, AMI deployments SHOULD implement RPL's = security mechanisms and cannot rely on link layer and higher layer = security features.

Section 4.2.1
Current text:
In high = density environments, relatively low values for Imin may cause a short = period of congestion when an inconsistency is detected and DIO updates = are sent by a large number of neighboring nodes nearly simultaneously. = While the Trickle timer will exponentially backoff, some time may elapse = before the congestion subsides.

It would be good to nail down = some values.  What is a "relatively low value" that will result in = what kind of short period of congestion.  What is "some time"? What = orders of magnitude? Seconds, minutes, = micro-seconds...

DIOIntervalMin: This paragraph recommends a = value - GREAT, but what is the result of this choice?  What happens = if you choose a number greater or smaller?

DIOIntervalDoublings: = Same comment - what if I choose a different value?  What is the = result?  What is the result in performance if I choose either of = these values.

Section 4.2.2
Current text:
AMI deployments = SHOULD set MinHopRankIncrease to 256, resulting in 8 bits of resolution = (e.g., for the ETX metric).

What are the results of choosing 256. =  Why 256 and not 128 or 512 or any other number.

Current = text:
To enable local repair, AMI deployments SHOULD set = MaxRankIncrease to a value that allows a device to move a small number = of hops away from the root. With a MinHopRankIncrease of 256, a = MaxRankIncrease of 1024 would allow a device to move up to 4 hops = away.

What is the result of choosing 256.  How did you = arrive at this number.  What is performance trade-off?  Is = this based on some specific bandwidth, number of nodes in the network, = depth of the network, ...

Section 6
Current text:
As a = result link-layer, transport-layer and/or application-layer security = mechanisms are typically in place and using RPL's secure mode is not = necessary.

Same comment as the previous section on = security.

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

= --Apple-Mail=_B0FE8540-244F-405E-BD2A-CC0834C77C9C-- From ulrich@herberg.name Wed Mar 28 08:52:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2921E82B3 for ; Wed, 28 Mar 2012 08:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMsntpvCDM4q for ; Wed, 28 Mar 2012 08:51:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 773D721E82B0 for ; Wed, 28 Mar 2012 08:51:59 -0700 (PDT) Received: by yenm5 with SMTP id m5so899691yen.31 for ; Wed, 28 Mar 2012 08:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=FvJL48DvBzPsqvLe4bYxu80h6TvcL0PN2fgn4ynzUyU=; b=iMP72A+Rnj0Y4M/XczBauwaDwbBU0tYk6mK7aC+v8R63m+55JKsRy4xgIkAJw9iW07 dt9+4qEXVjnshxR/IvZDwpIEA45V3Na8COhrKVzQ+gcpF1T3OiHvoElHEV1mYt+pdoF6 RgRsIg0F+I3ZfziKdjBDC7PTqnOvn1OiXojyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=FvJL48DvBzPsqvLe4bYxu80h6TvcL0PN2fgn4ynzUyU=; b=ITrWuh6COWPtBLJ15FDHRxuGXRGjXn5w8mKxivFkHD9USLQLLGxFtGsPhxiy+rTCsE /Ex3Djq4Vji7AafGuMsJgD0rTSDjtth+tOicgS3NIF5MowxuIfo69ymjNdVQ/58oS5Cg BZAZna22/mP/HdwM4ckKrtqqUiAE7EaaAN691DUoSSxfavq7ZrOrKyZiOxW/Txeh+PRU Tvi+GfuJsYaIV39voyv9q4Vli0zR0cWeVk4ntKRwxSihaxsr823FckzBHA8BLtut84Q8 zYDhmHehFwrUGyrNy2OlMHaPBiZvYFDduxXDije+AYRb2K2iLKjOiojHiWdK+pEAqBpK LdBA== MIME-Version: 1.0 Received: by 10.68.130.163 with SMTP id of3mr72728790pbb.85.1332949918565; Wed, 28 Mar 2012 08:51:58 -0700 (PDT) Received: by 10.143.29.18 with HTTP; Wed, 28 Mar 2012 08:51:58 -0700 (PDT) Date: Wed, 28 Mar 2012 17:51:58 +0200 Message-ID: From: Ulrich Herberg To: roll WG Content-Type: multipart/alternative; boundary=047d7b15a7f366464404bc4f96ad X-Gm-Message-State: ALoCoQny7CzANhjxRNiVRL4gVBwhS0Di65//FRcJP944H98WHX8PUl0uLwkjqB82Dkkj5Aj/DqwQ Subject: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 15:52:00 -0000 --047d7b15a7f366464404bc4f96ad Content-Type: text/plain; charset=ISO-8859-1 Hi, as I mentioned today on the microphone, I would be interested to see results of the different deployments in terms of performance, overhead, delay, required state etc. Section 2 ("The Use Cases") says that: Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG's root, and thus routes across this DAG are desirable. I don't see anywhere in this section that the draft is only limited to 4-5 hops, as mentioned today. If the protocol can run in larger networks but only for routers in maximum hop distance of 4-5, that should be spelled out (together with a warning that TTL of the control messages has to be set to 4-5 to avoid network wide flooding). Regards Ulrich --047d7b15a7f366464404bc4f96ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

as I mentioned today on the microphone, I would be interested to= see results of the different deployments in terms of performance, overhead= , delay, required state etc.

Section 2 ("The Use Cases") s= ays that:
   Another use case, common in a commercial building=
 environment,
   involves a large LLN deployment where P2P communication along a
   particular DAG among hundreds (or thousands) of routers creates
   severe traffic congestion near that DAG's root, and thus routes
   across this DAG are desirable.
I don't see anywhere in this sec= tion that the draft is only limited to 4-5 hops, as mentioned today. If the= protocol can run in larger networks but only for routers in maximum hop di= stance of 4-5, that should be spelled out (together with a warning that TTL= of the control messages has to be set to 4-5 to avoid network wide floodin= g).

Regards
Ulrich
--047d7b15a7f366464404bc4f96ad-- From prvs=4276677de=mukul@uwm.edu Wed Mar 28 09:09:16 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DB921E808F for ; Wed, 28 Mar 2012 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1Wo25xkv5PL for ; Wed, 28 Mar 2012 09:09:15 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id F271221E8252 for ; Wed, 28 Mar 2012 09:09:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAI82c09/AAAB/2dsb2JhbABFhUC2PAEBAQQBAQEgSwsMDxEEAQEDAg0ZAikoCAYTiAoLqHiJCIkFBIEviUOFCIEYBIhYjQmQLYMFgTY Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8797112E3BB; Wed, 28 Mar 2012 11:09:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahVTdeR19VKZ; Wed, 28 Mar 2012 11:09:12 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3A43C12E3BA; Wed, 28 Mar 2012 11:09:12 -0500 (CDT) Date: Wed, 28 Mar 2012 11:09:12 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1981586546.1722108.1332950952120.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 16:09:16 -0000 >I don't see anywhere in this section that the draft is only limited to 4-5 hops, as mentioned today. If the protocol can run in larger networks but only for routers in maximum hop distance of 4-5, that should be spelled out (together with a warning that TTL of the control messages has to be set to 4-5 to avoid network wide flooding). P2P-RPL can certainly discover routes of any hop length, just that its application would be most useful when the target is within 4-5 hops. If the target is further out, the route along a global DAG might be almost as good. This ofcourse depends on network topology and routing metrics in use etc. Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "roll WG" Sent: Wednesday, March 28, 2012 10:51:58 AM Subject: [Roll] Scalability of P2P-RPL Hi, as I mentioned today on the microphone, I would be interested to see results of the different deployments in terms of performance, overhead, delay, required state etc. Section 2 ("The Use Cases") says that: Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG's root, and thus routes across this DAG are desirable. I don't see anywhere in this section that the draft is only limited to 4-5 hops, as mentioned today. If the protocol can run in larger networks but only for routers in maximum hop distance of 4-5, that should be spelled out (together with a warning that TTL of the control messages has to be set to 4-5 to avoid network wide flooding). Regards Ulrich _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Wed Mar 28 09:16:40 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659D021E8135 for ; Wed, 28 Mar 2012 09:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdTjunAbd3LU for ; Wed, 28 Mar 2012 09:16:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6D2E21E808F for ; Wed, 28 Mar 2012 09:16:39 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2052868pbb.31 for ; Wed, 28 Mar 2012 09:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ygAKM/PUgdSXycJUvbX52+3kyYcKQvj6Pd2sBxRy6gU=; b=m1qkeABdfsZHhPZ5zxaaRPeTD5c/GiQJmG+Se1XsW74VC8z6SL4ES3V24dILlIb83V 2EiR0F3AzyjfMNUgZV6VFlLuttcFEhTxmT11xJ8cANujL/M0jSOlGaBSnew55T7tt1NS GGeXS+ro+5zlfd1Qo8L+q4X5PVgySsmsfe4Uw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ygAKM/PUgdSXycJUvbX52+3kyYcKQvj6Pd2sBxRy6gU=; b=nyZTld8UZueasukWwfWIbwjlWdPVAMHupIzj3qHz/7/sjec77HeI65SAACZZpUSEdZ /T7QN0d4yRIA1+gYtEBIFwHQ8IGPYavxW15/JvfFM20T9v+jQetkvNznaUiP21yqjr5E B/PA5sgbfJwQxmnM3PJ6CEeAOeypY2rDmAQvVAMbWIqqYObPM3HObTdn31FhNzjkjPyI 56V4Y8q0smOZce1kUais5HU8QPNSwovdQcHlxzk6B0oRsr2h5+bdpJhJT5ZOxSETba1+ pNSBEMlgRJTxJ2cIdMcTra0X6A8PzQ5MO0C1fQDtUlGJbdqeRd9j9NzSK+r7m0ke6pRF XKsw== MIME-Version: 1.0 Received: by 10.68.220.137 with SMTP id pw9mr72514389pbc.122.1332951399468; Wed, 28 Mar 2012 09:16:39 -0700 (PDT) Received: by 10.143.29.18 with HTTP; Wed, 28 Mar 2012 09:16:39 -0700 (PDT) In-Reply-To: <1981586546.1722108.1332950952120.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1981586546.1722108.1332950952120.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 28 Mar 2012 18:16:39 +0200 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlakbbBwxVnb5gvBF3DPTIcIY02yqKL6aYoo1IDsWkM7mnNV9SxQLV6ZzUlYcHShpFV1sgT Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 16:16:40 -0000 Mukul, On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal wrote: > > >I don't see anywhere in this section that the draft is only limited to > > 4-5 hops, as mentioned today. If the protocol can run in larger networks but > > only for routers in maximum hop distance of 4-5, that should be spelled out > > (together with a warning that TTL of the control messages has to be set to > > 4-5 to avoid network wide flooding). > > P2P-RPL can certainly discover routes of any hop length, just that its > application would be most useful when the target is within 4-5 hops. If the > target is further out, the route along a global DAG might be almost as good. > This ofcourse depends on network topology and routing metrics in use etc. Okay, but I think that should be explicitly mentioned in the use case section (or somewhere else). Regards Ulrich From emmanuel.baccelli@gmail.com Wed Mar 28 09:28:49 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1871621E8099 for ; Wed, 28 Mar 2012 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhcNEdhtlwHy for ; Wed, 28 Mar 2012 09:28:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAE21E8091 for ; Wed, 28 Mar 2012 09:28:47 -0700 (PDT) Received: by qcsq13 with SMTP id q13so903365qcs.31 for ; Wed, 28 Mar 2012 09:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=e6qd57KXjve8ZWdVnKhdkK87+vHoqGtVIGkcAHe6g04=; b=BjpeICRKrvCkXxf6r1mpylyzKckoe7GLWXI5dCFwzxPEr27AZ4YqbHKLgtKbZq4sHt Hdonlh4f+kPg/YQUs1Se1nSU6yAq/acu3reJFdGRQ2A3rt/PzxPZyotB27Pf6EfNZugK mbY+UyVfyshyOOXlRdXNU1DK8g5cjyYQ2ISPlGjGJKwkdUKrYAXMduB/ZY35h5TWTikB cTsCN9Pp7eJ+MMmlTNbqhlPTKM22hgIBby9aTuJNOR0Vv6f3PgUZebpmaQ2p6wchozg4 dE+6PvF+VjSnFte2VSDpjuh/6TiUKvQWqmPI6fhN+WFKqVSPCVHM3q7PGUqJWQmKXuXy qyuA== Received: by 10.224.77.80 with SMTP id f16mr39449240qak.10.1332952127256; Wed, 28 Mar 2012 09:28:47 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.40.134 with HTTP; Wed, 28 Mar 2012 09:28:27 -0700 (PDT) In-Reply-To: <1025488915.135270.1332949927389.JavaMail.root@zmbs1.inria.fr> References: <1025488915.135270.1332949927389.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Wed, 28 Mar 2012 18:28:27 +0200 X-Google-Sender-Auth: 6cFghI0seDf4th1x-jZrdGFP8S4 Message-ID: To: roll WG Content-Type: multipart/alternative; boundary=20cf3074d4f60c395104bc501a3c Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 16:28:49 -0000 --20cf3074d4f60c395104bc501a3c Content-Type: text/plain; charset=ISO-8859-1 Hi Ulrich, actually, as I tried to explain during the meeting, a P2P-RPL route discovery will take place within a controlled scope around its origin. This scope is expressed as a constraint in the metric container carried with the discovery message, as specified in the document. If the overall network is actually larger than this scope, nodes outside of this scope are unaffected in terms of extra overhead and control traffic. In this sense at least, the P2P-RPL extension can work in large networks. The typical scenario that is targeted is connecting a switch with light bulb, expected to be rather nearby, for instance within a 4-5 hops radius (look at the scenario described in section 4 for example). We'd be glad to learn about other scenarios that are interesting to target, and to work on another spec that will target those too. Emmanuel On Wed, Mar 28, 2012 at 5:52 PM, Ulrich Herberg wrote: > Hi, > > as I mentioned today on the microphone, I would be interested to see > results of the different deployments in terms of performance, overhead, > delay, required state etc. > > Section 2 ("The Use Cases") says that: > > Another use case, common in a commercial building environment, > involves a large LLN deployment where P2P communication along a > particular DAG among hundreds (or thousands) of routers creates > severe traffic congestion near that DAG's root, and thus routes > across this DAG are desirable. > > I don't see anywhere in this section that the draft is only limited to 4-5 > hops, as mentioned today. If the protocol can run in larger networks but > only for routers in maximum hop distance of 4-5, that should be spelled out > (together with a warning that TTL of the control messages has to be set to > 4-5 to avoid network wide flooding). > > Regards > Ulrich > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --20cf3074d4f60c395104bc501a3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ulrich,

actually, as I tried to explain during the meeting,= a P2P-RPL route discovery will take place within a controlled scope around= its origin. This scope is expressed as a constraint in the metric containe= r carried with the discovery message, as specified in the document.=A0

If the overall network is actually larger than this sco= pe, nodes outside of this scope are unaffected in terms of extra overhead a= nd control traffic. In this sense at least, the P2P-RPL extension can work = in large networks.

The typical scenario that is targeted is connecting a s= witch with light bulb, expected to be rather nearby, for instance within a = 4-5 hops radius (look at the scenario described in section 4 for example).= =A0

We'd be glad to learn about other scenarios that ar= e interesting to target, and to work on another spec that will target those= too.

Emmanuel



On Wed, Mar 28, 2012 at 5:52 PM, Ulrich Herberg = <ulrich@herberg= .name> wrote:
Hi,

as I mentioned today on = the microphone, I would be interested to see results of the different deplo= yments in terms of performance, overhead, delay, required state etc.
Section 2 ("The Use Cases") says that:
   Another use case, common in a commercial building environment,
   involves a large LLN deployment where P2P communication along a
   particular DAG among hundreds (or thousands) of routers creates
   severe traffic congestion near that DAG's root, and thus routes
   across this DAG are desirable.
I don't see anywhere in this sec= tion that the draft is only limited to 4-5 hops, as mentioned today. If the= protocol can run in larger networks but only for routers in maximum hop di= stance of 4-5, that should be spelled out (together with a warning that TTL= of the control messages has to be set to 4-5 to avoid network wide floodin= g).

Regards
Ulrich

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


--20cf3074d4f60c395104bc501a3c-- From prvs=4276677de=mukul@uwm.edu Wed Mar 28 09:29:03 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8D21E8144 for ; Wed, 28 Mar 2012 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNCvCVLiM4tb for ; Wed, 28 Mar 2012 09:29:03 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2221E80F3 for ; Wed, 28 Mar 2012 09:29:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EADw7c09/AAAB/2dsb2JhbABFhUC2PAEBBSNWDA8RBAEBAQICDRkCUQgGE4gKqQeJC4kJgS+JQ4UIgRgEiFiNCZAtgwWBNg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9040512E3BB; Wed, 28 Mar 2012 11:29:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GExbTiQe50KN; Wed, 28 Mar 2012 11:29:02 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 640D512E3BE; Wed, 28 Mar 2012 11:29:02 -0500 (CDT) Date: Wed, 28 Mar 2012 11:29:02 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <650476877.1722531.1332952142290.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 16:29:04 -0000 >Okay, but I think that should be explicitly mentioned in the use case section (or somewhere else). Sure. I will add text to that effect. Note that the tradeoff is not straightforward: even when the P2P-RPL routes are not much shorter than routes along a global DAG, they would still avoid traffic concentration around the root. Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "Mukul Goyal" Cc: "roll WG" Sent: Wednesday, March 28, 2012 11:16:39 AM Subject: Re: [Roll] Scalability of P2P-RPL Mukul, On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal wrote: > > >I don't see anywhere in this section that the draft is only limited to > > 4-5 hops, as mentioned today. If the protocol can run in larger networks but > > only for routers in maximum hop distance of 4-5, that should be spelled out > > (together with a warning that TTL of the control messages has to be set to > > 4-5 to avoid network wide flooding). > > P2P-RPL can certainly discover routes of any hop length, just that its > application would be most useful when the target is within 4-5 hops. If the > target is further out, the route along a global DAG might be almost as good. > This ofcourse depends on network topology and routing metrics in use etc. Okay, but I think that should be explicitly mentioned in the use case section (or somewhere else). Regards Ulrich From c.chauvenet@watteco.com Wed Mar 28 16:14:16 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC121E815C for ; Wed, 28 Mar 2012 16:14:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLdOOzQghFFP for ; Wed, 28 Mar 2012 16:14:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB5C21E8157 for ; Wed, 28 Mar 2012 16:14:07 -0700 (PDT) Received: from mail212-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 23:14:05 +0000 Received: from mail212-ch1 (localhost [127.0.0.1]) by mail212-ch1-R.bigfish.com (Postfix) with ESMTP id AD7D44403E2; Wed, 28 Mar 2012 23:14:05 +0000 (UTC) X-SpamScore: -35 X-BigFish: VPS-35(zz9371Ic89bh542Mc85dh1dbaL1418M98dKzz1202hzz1033IL8275bh8275dh84d07hz2dh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail212-ch1 (localhost.localdomain [127.0.0.1]) by mail212-ch1 (MessageSwitch) id 133297643930202_17864; Wed, 28 Mar 2012 23:13:59 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail212-ch1.bigfish.com (Postfix) with ESMTP id 5AC58C00C0; Wed, 28 Mar 2012 23:13:58 +0000 (UTC) Received: from AMXPRD0510HT005.eurprd05.prod.outlook.com (157.56.248.181) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 23:13:56 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.57.40]) with mapi id 14.16.0135.002; Wed, 28 Mar 2012 23:13:55 +0000 From: C Chauvenet To: Mukul Goyal Thread-Topic: [Roll] Scalability of P2P-RPL Thread-Index: AQHNDPq8wWOP5S/ZxEWhSdXuiX6uUJZ/4EQAgAACFYCAAAN2AIAAcR4A Date: Wed, 28 Mar 2012 23:13:55 +0000 Message-ID: <71B69BDB-1701-4813-8B30-1873233D43B0@watteco.com> References: <650476877.1722531.1332952142290.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <650476877.1722531.1332952142290.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.10] Content-Type: multipart/alternative; boundary="_000_71B69BDB170148138B301873233D43B0wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2012 23:14:16 -0000 --_000_71B69BDB170148138B301873233D43B0wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Le 28 mars 2012 =E0 18:29, Mukul Goyal a =E9crit : Okay, but I think that should be explicitly mentioned in the use case As discussed today during the meeting, numbers need to be placed given a pa= rticular context. So, if we put explicitly "4-5 hops" in the requirements, this has to be in = regards to the total number of nodes, the topology, the technology used, th= e environment, and other numerous parameters that could justify this "4-5" = value for a particular case. For instance, if you consider 15.4 in the sub Ghz band, 15.4 in the 2.4 Ghz= band or PLC technology where RPL applies, the 4-5 hops physical distance v= ary from at least one or two order of magnitude. So people working over the 2.4 Ghz may use the 4-5 hops boundary, whereas p= eople running over sub Ghz may be happy within a single hop boundary. There is a section in the P2P draft that is quite generic, so applicable to= most of the use case, and shed some light on the tradeoff regarding using= or not the P2P extension, and limit the scope of the flooding : A network designer may take into consideration both the benefits (potential= ly better routes; no need to maintain routes proactively) and costs (control messages generated during the route discovery process) when using P2P-RPL. We may expand this sentence to be more precise on the flooding region. What do you think ? I think numbers are always dangerous in documents that need to be frozen at= some point. But I agree that they are very relevant to share, when you want to leverage= on other experiments. Putting fixed numbers in protocols that target very wide scope and emerging= applications is like asking to a commercial guy to put a fixed price on a = product for the 20 years to come ! Just my 2 cts C=E9dric. section (or somewhere else). Sure. I will add text to that effect. Note that the tradeoff is not straigh= tforward: even when the P2P-RPL routes are not much shorter than routes alo= ng a global DAG, they would still avoid traffic concentration around the ro= ot. Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" > To: "Mukul Goyal" > Cc: "roll WG" > Sent: Wednesday, March 28, 2012 11:16:39 AM Subject: Re: [Roll] Scalability of P2P-RPL Mukul, On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal > wrote: I don't see anywhere in this section that the draft is only limited to 4-5 hops, as mentioned today. If the protocol can run in larger networks bu= t only for routers in maximum hop distance of 4-5, that should be spelled out (together with a warning that TTL of the control messages has to be set to 4-5 to avoid network wide flooding). P2P-RPL can certainly discover routes of any hop length, just that its application would be most useful when the target is within 4-5 hops. If the target is further out, the route along a global DAG might be almost as good= . This ofcourse depends on network topology and routing metrics in use etc. Okay, but I think that should be explicitly mentioned in the use case section (or somewhere else). Regards Ulrich _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_71B69BDB170148138B301873233D43B0wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3914B2BF54B7424CB8A28E5ACC61EC9C@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi, 


Le 28 mars 2012 =E0 18:29, Mukul Goyal a =E9crit :

Okay, but I think that should be explicitly menti= oned in the use case

As discussed today during the meeting, numbers need to be placed given= a particular context.
So, if we put explicitly "4-5 hops" in the requirements, thi= s has to be in regards to the total number of nodes, the topology, the tech= nology used, the environment, and other numerous parameters that could just= ify this "4-5" value for a particular case.
For instance, if you consider 15.4 in the sub Ghz band, 15.4 in the 2.= 4 Ghz band or PLC technology where RPL applies, the 4-5 hops physical dista= nce vary from at least one or two order of magnitude.
So people working over the 2.4 Ghz may use the 4-5 hops boundary, wher= eas people running over sub Ghz may be happy within a single hop boundary.<= /div>

There is a section in the P2P draft that is quite generic, so applicab= le to most of the use case,  and shed some light on the tradeoff regar= ding using or not the P2P extension, and limit the scope of the flooding :&= nbsp;

A network designer may take into co=
nsideration both the benefits (potentially better routes;
no need to maintain routes proactively) and costs (control messages
generated during the route discovery process) when using P2P-RPL.

We may expand this sentence to be more precise on the flooding region.=

What do you think ?

I think numbers are always dangerous in documents that need to be froz= en at some point.
But I agree that they are very relevant to share, when you want to lev= erage on other experiments.
Putting fixed numbers in protocols that target very wide scope and eme= rging applications is like asking to a commercial guy to put a fixed price = on a product for the 20 years to come !

Just my 2 cts

C=E9dric.

section (or somewhere else).

Sure. I will add text to that effect. Note that the tradeoff is not straigh= tforward: even when the P2P-RPL routes are not much shorter than routes alo= ng a global DAG, they would still avoid traffic concentration around the ro= ot.

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <ulrich@herberg.name>
To: "Mukul Goyal" <mukul@uwm.= edu>
Cc: "roll WG" <roll@ietf.org<= /a>>
Sent: Wednesday, March 28, 2012 11:16:39 AM
Subject: Re: [Roll] Scalability of P2P-RPL

Mukul,

On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal <mukul@uwm.edu> wrote:

I don't see anywhere in this section that the dra= ft is only limited to
4-5 hops, as mentioned today. If the protocol can= run in larger networks but
only for routers in maximum hop distance of 4-5, = that should be spelled out
(together with a warning that TTL of the control = messages has to be set to
4-5 to avoid network wide flooding).

P2P-RPL can certainly discover routes of any hop = length, just that its
application would be most useful when the target = is within 4-5 hops. If the
target is further out, the route along a global D= AG might be almost as good.
This ofcourse depends on network topology and rou= ting metrics in use etc.

Okay, but I think that should be explicitly mentioned in the use case
section (or somewhere else).

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


--_000_71B69BDB170148138B301873233D43B0wattecocom_-- From c.chauvenet@watteco.com Wed Mar 28 17:18:19 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFEC21E8040 for ; Wed, 28 Mar 2012 17:18:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dnhseJJv+63 for ; Wed, 28 Mar 2012 17:18:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 699DE21E8020 for ; Wed, 28 Mar 2012 17:18:16 -0700 (PDT) Received: from mail80-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 00:18:15 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 3DA2E40235; Thu, 29 Mar 2012 00:18:15 +0000 (UTC) X-SpamScore: -34 X-BigFish: VPS-34(zz14dfR9371Ic89bhc85dh98dKzz1202hzz1033IL8275bh8275dh5eeeKz2dh2a8h668h839hd25hbe3k) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 133298029384744_31554; Thu, 29 Mar 2012 00:18:13 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.251]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 04A322004A; Thu, 29 Mar 2012 00:18:13 +0000 (UTC) Received: from AMXPRD0510HT001.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 00:18:12 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.57.36]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 00:18:13 +0000 From: C Chauvenet To: JP Vasseur Thread-Topic: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 Thread-Index: AQHNA0R82CgDw9IobUCpkn1Xqt9NWZaAfFCA Date: Thu, 29 Mar 2012 00:18:12 +0000 Message-ID: References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> In-Reply-To: <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: multipart/alternative; boundary="_000_A484DA396BCB439D8FDEA249BD492014wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: ROLL WG Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 00:18:19 -0000 --_000_A484DA396BCB439D8FDEA249BD492014wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here is my review of the P2P draft : Overall, I think this mechanism is very relevant for certain RPL applicatio= ns such as home or building automation, or when you think that the effort t= o find a more optimal route is worth compare to the DAG that the RPL core s= pecification can form. Also, it provides an "on demand" route discovery tha= t can significantly melt down the control overhead of a route that is used = for a limited period of time, rather that being continuoulsy maintained. On big question that rise my mind is, what happened if the route discovery = fail ? Some protocols sends out an error message when the route discovery fails or= get stuck. Do authors think that it could be relevant to add a "discovery-error" messa= ge as defined in other route discovery protocols ? Another point that has been discussed today during the ROLL meeting, is tha= t some people may find other mechanisms than trickle more efficient to floo= d the RDO. Could we let the door opened to other flooding optimization mechanism, or e= xplicitly say that the trickle mechanism MUST be used ? In details : p3 : P2P-RPL does not guarantee discovery of a route. But how do we know if the RDO has been lost, of if the request has failed ? in other words, how do we know if the route doesn't exist, or if the reques= t has been lost ? In addition, it may be relevant to cite an example where the discovery of a= route cannot be achieved. p5 : If there is no existing route between the origin and the target(s) or the cost measurement for the existing routes fails, the origin will have to guess the constraints to be used in the initial route discovery. Any recommendation to guess the metric in use ? Is it relevant to use hop c= ount by default (to limit the scope) ? p6 : P2P-RPL allows for the discovery of one hop-by-hop route or upto four source routes per target. upto --> up to. Why 4 ? Any reason to limit the choice to 4 ? p6 : P2P-RPL does not guarantee discovery of a route to a target. Same text, same remark as before ! p6 : A P2P mode DIO always carries one P2P Route Discovery Option (defined in Section 7.1) in which the origin specifies the following information: So you should put a MUST for this. p9 : o DIOIntervalMin: 6, which translates to 64ms as the value for Imin parameter in Trickle operation. Should we really fix numbers in this spec ? Could we turn the MUST of these= parameters into recommended values ? Not sure this timing is applicable to all RPL networks. p12 : This specification does not allow for the establishment of hop-by-hop routes in the backward direction. Why ? This would enable to establish 2 routes within a single route request= . Furthermore, you stipulates in the draft that links have to be bidirectiona= l to propagates RDO, in order to be able to send back the DRO. So if I understand it correctly you ensure that you have a reliable path in= both ways. Why using it in a single way only ? p13 : The IPv6 addresses in the Address vector MUST be reachable in both forward and backward directions. Does it means that links have to be bidirectional on the path ? How do you = verify that ? p14 : A DRO message travels from the target to the origin via link-local multicast along the route specified inside the Address vector in the P2P-RDO. Why using multicast if you know every destinators ? Could we unicast packets to each destinators in the address vector ? p15 : Stop (S): This flag, when set to one by a target, indicates that the P2P-RPL route discovery is over. Is this bit really usefull ? My guess is that it will be always set to 1. If you hear a DRO, this indeed means that the RDO has reached the target, s= o you could just stop processing RDO when you hear a DRO. Do we really need a flag to stop RDO processing or the hearing of a DRO typ= e message could do the job ? p21 : Example methods include selecting each route that meets the specified routing constraints until the desired number have been selected or selecting the best routes discovered over a certain time period. How could we know the time to wait until we get all the RDO ? Is there a way to evaluate it according to some parameters related to the n= etwork (diameter of the network for instance) ? p25 : o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a value of 1 second. I'm not sure it is compliant with all RPL deployments. Could we adapt it to the characteristics of the network used ? p28 : References need to be updated according to recent RFCs. Best, C=E9dric. Le 16 mars 2012 =E0 08:14, JP Vasseur a =E9crit : This is just a reminder that we have 2 documents in WG Last Call, which wil= l terminate on March 29, at noon. Comments appreciated. Thanks. JP. On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote: Dear all, The two documents draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-r= pl have been discussed on the mailing list and during WG meetings for some time, there several implementations that are now stabl= e, and the authors believe that the documents are ready for WG Last Call. Thus, this starts a Working Group Last Call on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Furthermore, an interoperability was carried out last month with INRIA's im= plementation against Sigma Design's implementation. The report can be found: http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.p= df Experiments with P2P-RPL have also taken place on the Senslab testbed gathe= ring boards based on MSP430 and 802.15.4 at 2.4GHz: http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf The WG Last Call will last 3-weeks and will end on March 29, at noon ET. Pl= ease send your comments on the mailing list and copy the authors. Thanks. JP and Michael. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_A484DA396BCB439D8FDEA249BD492014wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3FD9E0E57A7F194998B2CC10E0C0C4E2@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

Here is my review of the P2P draft : 

Overall, I think this mechanism is very relevant for certain RPL appli= cations such as home or building automation, or when you think that the eff= ort to find a more optimal route is worth compare to the DAG that the RPL c= ore specification can form. Also, it provides an "on demand" route discovery that can significantl= y melt down the control overhead of a route that is used for a limited peri= od of time, rather that being continuoulsy maintained.

On big question that rise my mind is, what happened if the route disco= very fail ?
Some protocols sends out an error message when the route discovery fai= ls or get stuck. 
Do authors think that it could be relevant to add a "discovery-er= ror" message as defined in other route discovery protocols ?

Another point that has been discussed today during the ROLL meeting, i= s that some people may find other mechanisms than trickle more efficient to= flood the RDO.
Could we let the door opened to other flooding optimization mechanism,= or explicitly say that the trickle mechanism MUST be used ?

In details : 

p3 : P2P-RPL does not guarantee dis=
covery of a route.
But how do we know if the RDO has been lost, of if the request has fai= led ?
in other words, how do we know if the route doesn't exist, or if the r= equest has been lost ?
In addition, it may be relevant to cite an example where the discovery= of a route cannot be achieved.

p5 : If there is
   no existing route between the or=
igin and the target(s) or the cost
   measurement for the existing routes fails, the origin will have to
   guess the constraints to be used in the initial route discovery.
Any recommendation to guess the metric in use ? Is it relevant to use = hop count by default (to limit the scope) ?

p6 : P2P-RPL
   allows for the discovery of one =
hop-by-hop route or upto four source
   routes per target.
upto --> up to.
Why 4 ? Any reason to limit the choice to 4 ?

p6 : P2P-RPL does not guarantee disco= very of a route to a
   target.
Same text, same remark as before !

p6 : A P2P mode DIO always carries on= e P2P Route Discovery
   Option (defined in Section 7.=
1) in which the origin specifies the
   following information:
So you should put a MUST for this.

p9 : o DIOIntervalMin: 6, which trans= lates to 64ms as the value for Imin
      parameter in Trickle operatio=
n.
Should we really fix numbers in this spec ? Could we turn the MUST of = these parameters into recommended values ?
Not sure this timing is applicable to all RPL networks.

p12 : This specification does not all= ow for
      the establishment of hop-by-h=
op routes in the backward direction.
Why ? This would enable to establish 2 routes within a single route re= quest.
Furthermore, you stipulates in the draft that links have to be bidirec= tional to propagates RDO, in order to be able to send back the DRO.
So if I understand it correctly you ensure that you have a reliable pa= th in both ways. Why using it in a single way only ?

p13 : The IPv6 addresses in the Addre= ss vector MUST be reachable in
         both forward and backward =
directions.
Does it means that links have to be bidirectional on the path ? How do= you verify that ?

p14 :  A DRO message travels 
   from the target to the origin vi=
a link-local multicast along the
   route specified inside the Address vector in the P2P-RDO.
Why using multicast if you know every destinators ?
Could we unicast packets to each destinators in the address vector ?

p15 :  Stop (S): This flag, when set = to one by a target, indicates that
      the P2P-RPL route discovery i=
s over.
Is this bit really usefull ? My guess is that it will be always set to= 1.
If you hear a DRO, this indeed means that the RDO has reached the targ= et, so you could just stop processing RDO when you hear a DRO.
Do we really need a flag to stop RDO processing or the hearing of a DR= O type message could do the job ?

p21 : Example methods include<= /div> 
   selecting each route that meets =
the specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.
How could we know the time to wait until we get all the RDO ?
Is there a way to evaluate it according to some parameters related to = the network (diameter of the network for instance) ?

p25 : o DRO_ACK_WAIT_TIME: The time d= uration a target waits for the DRO-
      ACK before retransmitting a D=
RO message.  DRO_ACK_WAIT_TIME has a
      value of 1 second.
I'm not sure it is compliant with all RPL deployments.
Could we adapt it to the characteristics of the network used ?

p28 : References need to be updated according to recent RFCs.

Best,

C=E9dric.

Le 16 mars 2012 =E0 08:14, JP Vasseur a =E9crit :

This is just a reminder that we have 2 documents in WG Last Call, which wil= l terminate on March 29, at noon.
Comments appreciated.
Thanks.

JP.

On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote:

Dear all,

The two documents draft-ietf-roll-p2p-measurement and draft-ietf-roll-= p2p-rpl have been discussed on the mailing list and during <= /div>
WG meetings for some time, there several implementations that are now&= nbsp;stable, and the authors believe that the documents are
ready for WG Last Call.

Thus, this starts a Working Group Last Call on:
* draft-ietf-roll-p2p-measurement-04
and
* draft-ietf-roll-p2p-rpl-09

Furthermore, an interoperability was carried out last month with INRI= A's implementation against Sigma Design's implementation.

Experime= nts with P2P-RPL have also taken place on the Senslab testbed gathering boa= rds based on MSP430 and 802.15.4 at 2.4GHz: 

The WG Last Call will last 3-weeks and will end on March 29, at noon E= T. Please send your comments on the mailing list and copy 
the authors.

Thanks.

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

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

--_000_A484DA396BCB439D8FDEA249BD492014wattecocom_-- From ulrich@herberg.name Wed Mar 28 23:33:33 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACF321E80A7 for ; Wed, 28 Mar 2012 23:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5MMZWdVWuXl for ; Wed, 28 Mar 2012 23:33:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 323C121E80AA for ; Wed, 28 Mar 2012 23:33:32 -0700 (PDT) Received: by obbta17 with SMTP id ta17so106854obb.31 for ; Wed, 28 Mar 2012 23:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IyTmmss69T+MWUffYcIc7u2W9fhhokQIcayBXWw6WlU=; b=cetu5KnmJuw/2b8eYaCjhSpJEVSXAAfKOzyXBCIqVhFg52w+4Mfo8WMNtFQxpdzSxR 8lpKveWjmdfUWU3QgfyYUL1nQkjUq9Z/+5QcedMZ5x1NEMrw9iKoysMKiGI7fW4CkXth SQc0Jx8o3Tz6dZzBV4J8tfP9q0lM/IithdsMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=IyTmmss69T+MWUffYcIc7u2W9fhhokQIcayBXWw6WlU=; b=orUhDBjGvlnftlzZEXulADunbasjDZhIp2znz0U6boMtDqIgrWy+hmmmDSUfhCwZEv i5ByevBVJXrcY2wB1tKPb7jNy6vC8ujBnPiOIfWYbOQ9tTKfNWXwZ5YK6Y5k81fq4OOe KqAli8Le8Wc2sHOZ4KJdmLrlxShWE67y141v/laWqWWeoNxOmzwuMI2YT7S0Gyni7tc7 pNsBXukVoK0ZH8/e9Ek51n2sJ3KMxz8rZ/qGx17t9BQFxrh0suWPJ7xHBBhoKUmKvsL5 GicDevoeYLrjC5btCmMow/7svEkNvBdmp3zY6T9ohGfMMQFOhjzCATu9vPOpHrstcJ5k LcZg== MIME-Version: 1.0 Received: by 10.68.242.38 with SMTP id wn6mr3101144pbc.72.1333002808043; Wed, 28 Mar 2012 23:33:28 -0700 (PDT) Received: by 10.143.29.18 with HTTP; Wed, 28 Mar 2012 23:33:27 -0700 (PDT) In-Reply-To: <71B69BDB-1701-4813-8B30-1873233D43B0@watteco.com> References: <650476877.1722531.1332952142290.JavaMail.root@mail17.pantherlink.uwm.edu> <71B69BDB-1701-4813-8B30-1873233D43B0@watteco.com> Date: Thu, 29 Mar 2012 08:33:27 +0200 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnA14GWTaBEq+jK2O3C1SidSsCvBoBVP9mdFertDg35TwJiEE9TpWG6AZGII7WgccBBgbf1 Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 06:33:33 -0000 C=E9dric, On Thu, Mar 29, 2012 at 1:13 AM, C Chauvenet wrot= e: > Hi, > > > Le 28 mars 2012 =E0 18:29, Mukul Goyal a =E9crit : > > Okay, but I think that should be explicitly mentioned in the use case > > > As discussed today during the meeting, numbers need to be placed given a > particular context. > So, if we put explicitly "4-5 hops" in the requirements, this has to be i= n > regards to the total number of nodes, the topology, the technology used, = the > environment, and other numerous parameters that could justify this "4-5" > value for a particular case. I am aware that the precise number of hops depends on a number of things. However, I think it should be spelled out that the draft has limitations in terms of scope and is not always applicable in general LLNs of thousands of nodes (at least that's what I infer from the talk yesterday). > For instance, if you consider 15.4 in the sub Ghz band, 15.4 in the 2.4 G= hz > band or PLC technology where RPL applies, the 4-5 hops physical distance > vary from at least one or two order of magnitude. I doubt that the hop distance varies by two orders of magnitude, i.e. up to 500 hops (even one seems a lot). > So people working over the 2.4 Ghz may use the 4-5 hops boundary, whereas > people running over sub Ghz may be happy within a single hop boundary. Sure, I never doubted that depending on the link layer / the topology / the traffic patterns etc there are differences in scope. I just request to add one sentence to make it clear to the reader what the applicability of the draft is. > > There is a section in the P2P draft that is quite generic, so applicable = to > most of the use case, > and shed some light on the tradeoff regarding using > or not the P2P extension, and limit the scope of the flooding : > > A network designer may take into consideration both the benefits > (potentially better routes; > no need to maintain routes proactively) and costs (control messages > generated during the route discovery process) when using P2P-RPL. > > > We may expand this sentence to be more precise on the flooding region. > > What do you think ? That can be done. But I also think that the Use Cases section should be more specific in which scenarios the draft can be used. > > I think numbers are always dangerous in documents that need to be frozen = at > some point. I do not insist on fixed numbers, I am aware that the number 4 or 5 was just named as example. But it was clear from them that the draft is limited to small-size networks (or at least close peers in a larger network). I don't say that this is a problem, but just that it should be spelled out in the draft. Best regards Ulrich > But I agree that they are very relevant to share, when you want to levera= ge > on other experiments. > Putting fixed numbers in protocols that target very wide scope and emergi= ng > applications is like asking to a commercial guy to put a fixed price on a > product for the 20 years to come ! > > Just my 2 cts > > C=E9dric. > > section (or somewhere else). > > Sure. I will add text to that effect. Note that the tradeoff is not > straightforward: even when the P2P-RPL routes are not much shorter than > routes along a global DAG, they would still avoid traffic concentration > around the root. > > Thanks > Mukul > > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Mukul Goyal" > Cc: "roll WG" > Sent: Wednesday, March 28, 2012 11:16:39 AM > Subject: Re: [Roll] Scalability of P2P-RPL > > Mukul, > > On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal wrote: > > > I don't see anywhere in this section that the draft is only limited to > > 4-5 hops, as mentioned today. If the protocol can run in larger networks = but > > only for routers in maximum hop distance of 4-5, that should be spelled o= ut > > (together with a warning that TTL of the control messages has to be set t= o > > 4-5 to avoid network wide flooding). > > > P2P-RPL can certainly discover routes of any hop length, just that its > > application would be most useful when the target is within 4-5 hops. If t= he > > target is further out, the route along a global DAG might be almost as go= od. > > This ofcourse depends on network topology and routing metrics in use etc. > > > Okay, but I think that should be explicitly mentioned in the use case > section (or somewhere else). > > Regards > Ulrich > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From c.chauvenet@watteco.com Thu Mar 29 00:00:29 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDFC21E80DD for ; Thu, 29 Mar 2012 00:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEooz9QWr8p3 for ; Thu, 29 Mar 2012 00:00:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2821E80D3 for ; Thu, 29 Mar 2012 00:00:26 -0700 (PDT) Received: from mail160-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Thu, 29 Mar 2012 07:00:21 +0000 Received: from mail160-va3 (localhost [127.0.0.1]) by mail160-va3-R.bigfish.com (Postfix) with ESMTP id 20CDB3E08C7; Thu, 29 Mar 2012 07:00:21 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz9371Ic89bh542M1dbaL1432N1418M98dKzz1202hzz1033IL8275bh8275dh84d07hz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 1333004417499222_23555; Thu, 29 Mar 2012 07:00:17 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.252]) by mail160-va3.bigfish.com (Postfix) with ESMTP id 6A6194A011E; Thu, 29 Mar 2012 07:00:17 +0000 (UTC) Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 07:00:15 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 07:00:13 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [Roll] Scalability of P2P-RPL Thread-Index: AQHNDPq8wWOP5S/ZxEWhSdXuiX6uUJZ/4EQAgAACFYCAAAN2AIAAcR4AgAB6z4CAAAd6AA== Date: Thu, 29 Mar 2012 07:00:13 +0000 Message-ID: <4DF54090-A30F-47D5-A510-D72253B9F265@watteco.com> References: <650476877.1722531.1332952142290.JavaMail.root@mail17.pantherlink.uwm.edu> <71B69BDB-1701-4813-8B30-1873233D43B0@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.11] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <43628553C040164DA2573E13E85E5BF3@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 07:00:29 -0000 Ulrich,=20 Le 29 mars 2012 =E0 08:33, Ulrich Herberg a =E9crit : > C=E9dric, >=20 > On Thu, Mar 29, 2012 at 1:13 AM, C Chauvenet wr= ote: >> Hi, >>=20 >>=20 >> Le 28 mars 2012 =E0 18:29, Mukul Goyal a =E9crit : >>=20 >> Okay, but I think that should be explicitly mentioned in the use case >>=20 >>=20 >> As discussed today during the meeting, numbers need to be placed given a >> particular context. >> So, if we put explicitly "4-5 hops" in the requirements, this has to be = in >> regards to the total number of nodes, the topology, the technology used,= the >> environment, and other numerous parameters that could justify this "4-5" >> value for a particular case. >=20 > I am aware that the precise number of hops depends on a number of > things. However, I think it should be spelled out that the draft has > limitations in terms of scope and is not always applicable in general > LLNs of thousands of nodes (at least that's what I infer from the talk > yesterday). >=20 >=20 >> For instance, if you consider 15.4 in the sub Ghz band, 15.4 in the 2.4 = Ghz >> band or PLC technology where RPL applies, the 4-5 hops physical distance >> vary from at least one or two order of magnitude. >=20 > I doubt that the hop distance varies by two orders of magnitude, i.e. > up to 500 hops (even one seems a lot). I was thinking about 1 Vs 10, and this may be more if you compare RF 2.4 VS= PLC across multiple floors in a building. >=20 >> So people working over the 2.4 Ghz may use the 4-5 hops boundary, wherea= s >> people running over sub Ghz may be happy within a single hop boundary. >=20 > Sure, I never doubted that depending on the link layer / the topology > / the traffic patterns etc there are differences in scope. I just > request to add one sentence to make it clear to the reader what the > applicability of the draft is. >=20 >>=20 >> There is a section in the P2P draft that is quite generic, so applicable= to >> most of the use case, >> and shed some light on the tradeoff regarding using >> or not the P2P extension, and limit the scope of the flooding : >>=20 >> A network designer may take into consideration both the benefits >> (potentially better routes; >> no need to maintain routes proactively) and costs (control messages >> generated during the route discovery process) when using P2P-RPL. >>=20 >>=20 >> We may expand this sentence to be more precise on the flooding region. >>=20 >> What do you think ? >=20 > That can be done. But I also think that the Use Cases section should > be more specific in which scenarios the draft can be used. >=20 >=20 >>=20 >> I think numbers are always dangerous in documents that need to be frozen= at >> some point. >=20 > I do not insist on fixed numbers, I am aware that the number 4 or 5 > was just named as example. But it was clear from them that the draft > is limited to small-size networks (or at least close peers in a larger > network). I don't say that this is a problem, but just that it should > be spelled out in the draft. Sure, this would be useful to precise the scope. >=20 > Best regards > Ulrich C=E9dric. >=20 >> But I agree that they are very relevant to share, when you want to lever= age >> on other experiments. >> Putting fixed numbers in protocols that target very wide scope and emerg= ing >> applications is like asking to a commercial guy to put a fixed price on = a >> product for the 20 years to come ! >>=20 >> Just my 2 cts >>=20 >> C=E9dric. >>=20 >> section (or somewhere else). >>=20 >> Sure. I will add text to that effect. Note that the tradeoff is not >> straightforward: even when the P2P-RPL routes are not much shorter than >> routes along a global DAG, they would still avoid traffic concentration >> around the root. >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "Ulrich Herberg" >> To: "Mukul Goyal" >> Cc: "roll WG" >> Sent: Wednesday, March 28, 2012 11:16:39 AM >> Subject: Re: [Roll] Scalability of P2P-RPL >>=20 >> Mukul, >>=20 >> On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal wrote: >>=20 >>=20 >> I don't see anywhere in this section that the draft is only limited to >>=20 >> 4-5 hops, as mentioned today. If the protocol can run in larger networks= but >>=20 >> only for routers in maximum hop distance of 4-5, that should be spelled = out >>=20 >> (together with a warning that TTL of the control messages has to be set = to >>=20 >> 4-5 to avoid network wide flooding). >>=20 >>=20 >> P2P-RPL can certainly discover routes of any hop length, just that its >>=20 >> application would be most useful when the target is within 4-5 hops. If = the >>=20 >> target is further out, the route along a global DAG might be almost as g= ood. >>=20 >> This ofcourse depends on network topology and routing metrics in use etc= . >>=20 >>=20 >> Okay, but I think that should be explicitly mentioned in the use case >> section (or somewhere else). >>=20 >> Regards >> Ulrich >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 From admin@ipv6it.org Thu Mar 29 04:18:15 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022EC21F8915 for ; Thu, 29 Mar 2012 04:18:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3fdj1B5cXaP for ; Thu, 29 Mar 2012 04:18:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6677D21F8894 for ; Thu, 29 Mar 2012 04:18:13 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2026255bku.31 for ; Thu, 29 Mar 2012 04:18:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=7RvkBDr1ihjLxdpA/zxGc0fZ8t1A/aQAM7DVJ0AOvyY=; b=Cu5wO4f8c8sR4sAqhtXiAtxpjRG1QGpRtYl66rB/5YV+lrTTVZdXZKtb1Rf5pGQm28 AErQgTnce4ru+KplSpYbwf7TCRifAfDsQWy9nE47rf8HOFRH2/znmRp8lDnrSL0gOxk9 /Xqp4zZeVPVhSRyrdM29TsoBEveCANndhrCNwXX2LhxLR5RkrAqd5RNBhwu6HG0BJKn5 r7ZonXiGcGjJfWv0KhhKlyHlk1HYElIw5eu+vsEVJwrSFMBmWgxjmpQZ3WeFsb6fkmOg otsUpqt1/8K488mPWv+9o+YoGLwvFHwW0CnzuF4hqdosyV6P9XK0/hQ7E2jNP8cug1A1 ay4w== Received: by 10.205.137.14 with SMTP id im14mr13863276bkc.137.1333019892298; Thu, 29 Mar 2012 04:18:12 -0700 (PDT) Received: from [127.0.0.1] (myskyn.iet.unipi.it. [131.114.59.252]) by mx.google.com with ESMTPS id u5sm12985555bka.5.2012.03.29.04.18.09 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:18:10 -0700 (PDT) Message-ID: <4F7444F0.3020101@ipv6it.org> Date: Thu, 29 Mar 2012 13:18:08 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Philip Levis References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> In-Reply-To: <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkFKfOjqHoGs8Ghajnct4yKsTquLJd4fWxgE0wVtOnxYJNJVDpqGL4qu3vxGFb055+vqF1n Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 11:18:15 -0000 Il 28/03/2012 11.56, Philip Levis ha scritto: > On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: > >> Hi, I have a doubt about the root's rank with ETX. >> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: >> A is root >> B is non-root >> Link between A and B has a cost of 256 (ETX=2) >> >> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*). >> >> B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256. >> >> But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*). > Good catch. > > I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3). > > This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to MinHopRankIncrease; 3.3 was designed given the RPL specification, but I think the cur_min_path_cost clause is out of sync with it. What do you think? > > Phil Hi, thank you for your reply. I think that if the root node advertise a Rank of 256 it means that it got a path_cost to the worst parent of 256 (1*), so it means that it got a ETX of 2 to the worst parent. It's not RPL complaint(2*). If instead we suppose that root send packet to itself, it means that the root can lost packet (ETX=2) to itself. IMHO, a way to fix that (still assuming that root send packet to itself) is that root could advertise a Rank of 128 (ETX=1) so it got no loss to itself. Anyway I don't like this fix. I think that a goot fix is that a root set it's rank to MinHopRankIncrease and (only root) MUST use the metric container to carry ETX=0. I think it's a pretty significant change in MRHOF but I have other ideas. What do you think? (1*) MRHOF - Section 3.4 "...It then calculates the metric it will advertise in its metric container. This value is the path cost of the member of the parent set with the highest path cost..." (2*) RPL-RFC - Section 8.2.1 - Rules 2 "A DODAG root MUST have a DODAG parent set of size zero" -- Regards Consoli Federico. From admin@ipv6it.org Thu Mar 29 05:34:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138D921F8ACC for ; Thu, 29 Mar 2012 05:34:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEjX4F+RPKYA for ; Thu, 29 Mar 2012 05:34:12 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46EB421F8AC3 for ; Thu, 29 Mar 2012 05:34:11 -0700 (PDT) Received: by eeke51 with SMTP id e51so1163523eek.31 for ; Thu, 29 Mar 2012 05:34:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=Pu+6AQFmXxVXaFs0gaZdbqkwHOlOQeX52KMVdPxmEdY=; b=F1KplELkIIU/DNAfQKBExIdnt4IMHM8JuukN2NsWta+Xfoa77VAptkQYfq+XlCY8Vc /y/huTrUMTyrVV+t/0izY9oKJP8KhxPqoS4BWUPI/zYBsWB54DPIES4FmHHBjRXuMUJ8 gd6QImGSG13CzwWYaKULVsNufXtjoIwvHx2jCzfBSHC93+stjv0Rw5CFUpD7E1Q6WtCV 712XJIKqbaumIPLN8ofS1xSJ6XrAST6+WUWPLMEQ8Vsbger1GIGr7UoNsr1bF8Y3cvZ4 LspJThJ5hxHTz40QidrDFX9Z4gooVTEKmyPxwjDsOZl3KP9bQ5EZS5SgbUVeHwVZB2gF kLTQ== Received: by 10.213.22.201 with SMTP id o9mr983677ebb.110.1333024450799; Thu, 29 Mar 2012 05:34:10 -0700 (PDT) Received: from [127.0.0.1] (myskyn.iet.unipi.it. [131.114.59.252]) by mx.google.com with ESMTPS id y11sm20817891eem.3.2012.03.29.05.34.09 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:34:09 -0700 (PDT) Message-ID: <4F7456BF.9000204@ipv6it.org> Date: Thu, 29 Mar 2012 14:34:07 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Roll@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk86GOEbz5ueY9QqS6jGnV6g3p4i+BjmaxnY38ZL7eb+sKExyTeS/qCnaRJBL1UO8xtqecO Subject: [Roll] RPL RFC 6550 - Path Control Example - Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 12:34:13 -0000 Hi, I have a doubt regarding the Path Control Example. From Section 9.9.1 "1. Let C1 send a DAO containing a Target T with a Path Control 10000000b. Node N stores an entry associating 10000000b with the Path Control field for C1 and Target T. " And that's ok. "2. Let C2 send a DAO containing a Target T with a Path Control 00010000b. Node N stores an entry associating 00010000b with the Path Control field for C1 and Target T." Why C1? I think that it should be C2. "3. Let C3 send a DAO containing a Target T with a Path Control 00001100b. Node N stores an entry associating 00001100b with the Path Control field for C1 and Target T." Same issue. I think that it should be C3. -- Regards Consoli Federico From prvs=4280f81cd=mukul@uwm.edu Thu Mar 29 10:03:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F621F89C8 for ; Thu, 29 Mar 2012 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMgUJiZIV3VL for ; Thu, 29 Mar 2012 10:03:33 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8871421F893F for ; Thu, 29 Mar 2012 10:03:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJuVdE9/AAAB/2dsb2JhbABDhUy2ZyNWNQINGQJZBiyHcaxeiRyBIYEvjliBGASIWI0JkC6DBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 76C64E6A8D; Thu, 29 Mar 2012 12:03:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxd+MERpimYd; Thu, 29 Mar 2012 12:03:15 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 3D46CE6A72; Thu, 29 Mar 2012 12:03:15 -0500 (CDT) Date: Thu, 29 Mar 2012 12:03:15 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1473626647.1740869.1333040595136.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: [Roll] Part 1: Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 17:03:34 -0000 Hi Pascal Thanks for your detailed comments! [Pascal] General ---------- I understand the need for concise messaging, which tends to create specific options with one stop shopping for all needed information in there. OTOH RPL has a modular use of options that enable multiple sorts of combinations and factorization. Using Target option is a good move. [Mukul] I understand your desire for modular design. But I think the need to save bytes is equally compelling. Specifying the (first) target inside the P2P-RDO allows byte savings in two ways: 1) 4 bytes saved by not specifying type, length, flags and prefix length fields of the target option 2) additional bytes saved by eliding the well known prefix part of the target address. By including the target address in the P2P-RDO, we have optimized for the common case. The RPL target option does come into picture when more than one target addresses need to be specified. [Pascal] Main suggestions: 1) Remove the target from the new P2P route discovery option. So you can place one or more times a P2P RD Option each followed by one or more target option(s), or set different lookup parameters for different targets. [Mukul] My feeling is that allowing multiple P2P-RDOs inside a P2P mode DIO is not a good idea because: 1) P2P-RDO specifies general parameters of route discovery: whether we want hop-by-hop route or source routes; if source route than how many; what is the life time of the temporary DAG; what is the max rank allowed inside the temporary DAG. We do allow discovery of routes to multiple targets with one invocation of P2P-RPL mechanism, but it seems that the general parameters of route discovery would not vary across targets. 2)P2P-RDO accumulates a route. We obviously dont want multiple copies of the accumulated route inside a DIO. Also, if we were to accumulate route in one P2P-RDO but not in others, that sounds complicated too. [Pascal] 2) Allow for targets that are not necessarily unicast. [Mukul] We do allow that already! The target address could be unicast or multicast. [Pascal] 3) Allow for (compressed) UDP header in the data. The completely opaque forms limits the use of the option a bit too drastically. [Mukul] I understand your logic and I am receptive to this idea. Let me get back to you on this. My objective was to keep things flexible. But looks like the common case is that the Data option would have UDP header+payload. [Pascal] /* In another draft I'd think we need to allow a mode with target but not P2P RD option. This would be done to trigger DAOs, e.g. to complete a hole in a Source Route recursion, or save space in storing mode. */ [Mukul] That sounds like a good idea. [Pascal] Detailed review "Forward Route: A route in the forward direction, i.e., from the origin to the target." I think you want to define the forward direction first and then the forward route. In both case you probably want to capitalize all instances in the text. Same goes for the following terms. [Mukul] Sounds good. I will address your remaining comments in the next message. Thanks Mukul From jpv@cisco.com Thu Mar 29 10:15:46 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3321E810A for ; Thu, 29 Mar 2012 10:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.385 X-Spam-Level: X-Spam-Status: No, score=-110.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cINiFzmul9qZ for ; Thu, 29 Mar 2012 10:15:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C987121E80F3 for ; Thu, 29 Mar 2012 10:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6324; q=dns/txt; s=iport; t=1333041344; x=1334250944; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=bPADMeGLK0dFvt8blQGZ5zV3chsUMRsTQDVcWjIcgOI=; b=mYWQpTYpRq41VT8E5Kd4Zpgpn2NZwsx/VLzMh95WJ4UeSoEDd3vXIBCq 9MQOTyi9mF0kXeP+LpMzcgE/rvWcsSyFoEI0HnXPxtHLKq+BsuNkVUycD 1p5LcbsGsFMSYsHxTSbblD/CNtQzMf07hn25coQwygrlc+yn8amezkeBp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAFCXdE+Q/khR/2dsb2JhbABFsCIBiHCBB4IJAQEBAgEBAQEBDwFUBxALIyMLJzAGEyKHYwULnASfLJA8YwSVYY5GgWiCaQ X-IronPort-AV: E=Sophos;i="4.75,669,1330905600"; d="scan'208,217";a="69676897" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 17:15:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2THFggL021850 for ; Thu, 29 Mar 2012 17:15:42 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 19:15:42 +0200 Received: from dhcp-15c4.meeting.ietf.org ([10.55.82.79]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 19:15:42 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C7C5279-ED37-4C33-9733-95FD525D6ABC" Date: Thu, 29 Mar 2012 19:15:42 +0200 In-Reply-To: <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> To: ROLL WG References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> Message-Id: <2A95B759-1675-48F3-8B37-190949E0D8FF@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 29 Mar 2012 17:15:42.0666 (UTC) FILETIME=[923FD2A0:01CD0DCF] Subject: [Roll] * end of Last Call * Re: ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 17:15:46 -0000 --Apple-Mail=_0C7C5279-ED37-4C33-9733-95FD525D6ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, WG Last calls have now ended. Thanks to all of you who commented - as a = reminder this document will follow the EXPERIMENTAL track (as a reminder = since this was asked during the ROLL WG meeting). Authors, could you please address the number of comments posted on the = mailing list ? Thanks. JP and Michael. On Mar 16, 2012, at 8:14 AM, JP Vasseur wrote: > This is just a reminder that we have 2 documents in WG Last Call, = which will terminate on March 29, at noon. > Comments appreciated. > Thanks. >=20 > JP. >=20 > On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> The two documents draft-ietf-roll-p2p-measurement and = draft-ietf-roll-p2p-rpl have been discussed on the mailing list and = during=20 >> WG meetings for some time, there several implementations that are now = stable, and the authors believe that the documents are >> ready for WG Last Call. >>=20 >> Thus, this starts a Working Group Last Call on: >> * draft-ietf-roll-p2p-measurement-04 >> and >> * draft-ietf-roll-p2p-rpl-09 >>=20 >> Furthermore, an interoperability was carried out last month with = INRIA's implementation against Sigma Design's implementation. >> The report can be found: = http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf >>=20 >> Experiments with P2P-RPL have also taken place on the Senslab testbed = gathering boards based on MSP430 and 802.15.4 at 2.4GHz:=20 >> http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf >>=20 >> The WG Last Call will last 3-weeks and will end on March 29, at noon = ET. Please send your comments on the mailing list and copy=20 >> the authors. >>=20 >> Thanks. >>=20 >> JP and Michael. =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 --Apple-Mail=_0C7C5279-ED37-4C33-9733-95FD525D6ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

WG Last calls have now ended. Thanks to all of = you who commented - as a reminder this document will follow the = EXPERIMENTAL track (as a reminder since this was asked during the ROLL = WG meeting).

Authors, could you please address = the number of comments posted on the mailing list = ?

Thanks.

JP and = Michael.

On Mar 16, 2012, at 8:14 AM, JP Vasseur = wrote:

This is just a reminder = that we have 2 documents in WG Last Call, which will terminate = on March 29, at noon.
Comments = appreciated.
Thanks.

JP.

=
On Mar 7, 2012, at 2:15 PM, JP Vasseur = wrote:

Dear = all,

The two documents = draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been = discussed on the mailing list and during 
WG = meetings for some time, there several implementations that are = now stable, and the authors believe that the documents = are
ready for WG Last Call.

Thus, = this starts a Working Group Last Call on:
* = draft-ietf-roll-p2p-measurement-04
and
*= = draft-ietf-roll-p2p-rpl-09

Furthermore,&n= bsp;an interoperability was carried out last month = with INRIA's implementation against Sigma Design's = implementation.

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

= --Apple-Mail=_0C7C5279-ED37-4C33-9733-95FD525D6ABC-- From pal@cs.stanford.edu Thu Mar 29 10:27:46 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1148021E8152 for ; Thu, 29 Mar 2012 10:27:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK9TkUGNK184 for ; Thu, 29 Mar 2012 10:27:45 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCF521E8055 for ; Thu, 29 Mar 2012 10:27:42 -0700 (PDT) Received: from ast-lambert-153-1-157-249.w90-44.abo.wanadoo.fr ([90.44.96.249] helo=[192.168.100.145]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SDJ8P-0002ij-0C; Thu, 29 Mar 2012 10:27:41 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4F7444F0.3020101@ipv6it.org> Date: Thu, 29 Mar 2012 19:27:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> To: Federico Consoli X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 3912120d3a1bcf28d29a6770933a4e79 Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 17:27:46 -0000 On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote: > Il 28/03/2012 11.56, Philip Levis ha scritto: >> On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: >>=20 >>> Hi, I have a doubt about the root's rank with ETX. >>> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: >>> A is root >>> B is non-root >>> Link between A and B has a cost of 256 (ETX=3D2) >>>=20 >>> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in = its DIO message in its advertised Rank value(6*). >>>=20 >>> B will receive a DIO with rank value =3D 0 so B will set his rank to = 256(7*) and will annunce a path_cost of 256. >>>=20 >>> But now I got 2 nodes with the same rank value. I think it's not a = problem with the algorith of DODAG creation but it's not RPL = complaint(5*). >> Good catch. >>=20 >> I think the issue here is the MRHOF draft is not clear: A (a root) = should advertise a Rank of 256, and B, following 3.3, would advertise a = Rank of 256 + MinHopRankIncrease (case 3 of 3.3). >>=20 >> This does get at a more fundamental issue, one where the rules on = Rank and the rules on metrics can diverge. I'd argue that the text = saying Root nodes set to MIN_PATH_COST should instead relate to = MinHopRankIncrease; 3.3 was designed given the RPL specification, but I = think the cur_min_path_cost clause is out of sync with it. What do you = think? >>=20 >> Phil > Hi, thank you for your reply. >=20 > I think that if the root node advertise a Rank of 256 it means that it = got a path_cost to the worst parent of 256 (1*), so it means that it got = a ETX of 2 to the worst parent. > It's not RPL complaint(2*). > If instead we suppose that root send packet to itself, it means that = the root can lost packet (ETX=3D2) to itself. > IMHO, a way to fix that (still assuming that root send packet to = itself) is that root could advertise a Rank of 128 (ETX=3D1) so it got = no loss to itself. > Anyway I don't like this fix. >=20 > I think that a goot fix is that a root set it's rank to = MinHopRankIncrease and (only root) MUST use the metric container to = carry ETX=3D0. >=20 > I think it's a pretty significant change in MRHOF but I have other = ideas. What do you think? >=20 >=20 >=20 >=20 > (1*) MRHOF - Section 3.4 > "...It then calculates the metric it will advertise in > its metric container. This value is the path cost of the member of > the parent set with the highest path cost..." >=20 > (2*) RPL-RFC - Section 8.2.1 - Rules 2 > "A DODAG root MUST have a DODAG parent set of size zero" >=20 The RPL specification is what says the Rank value a root must advertise. 8.2.2.2 says 2. A DODAG root MUST advertise a rank of ROOT_RANK. To some degree, absolute ETX values do not matter -- what matters is = their relative values. If all DODAG Roots advertise a Rank of 256, = corresponding to an ETX of 2, then that's what they advertise, and a = route with an computed ETX of 5 involves 3 transmissions within the LLN. I don't think I'm understanding the issue -- could you explain it again? Phil= From admin@ipv6it.org Thu Mar 29 10:55:19 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250121F8911 for ; Thu, 29 Mar 2012 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qIRBnkqm9eV for ; Thu, 29 Mar 2012 10:55:18 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA94721F8912 for ; Thu, 29 Mar 2012 10:55:17 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2474401bku.31 for ; Thu, 29 Mar 2012 10:55:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=4VPYJhLRup8wEDeWDrhXgQex5ODmmwrrmHFPI5q0LaU=; b=I5Gi3zy3cGIyW+3JG2jdxyes6fatGoNSvP4//cXZ4VL21uBDK9KTOyUlWLYPzJBVEh h9btjpECoUDevNk2vfnJsCAV7i5VvHAe3c1Y2trvCQOaYUCNKbUDyJ98Rhcky77z8gAi 4rC0gNqcQj9nq3T6uMCjGTr44NmlZ6MctJNM2kdsNJVoryTEuIw9LcsVQISDQ369LBhN 7/rWi4uQcsvJ+2VxglrE/0c4X6pCe4YlrhQMA4CqjF+P0+PLIKXuXixCdLDIzia57Olu l8rcWJmoHfe4H/5rus4RYso6ysz7NGZhN/OnmuUFMIYJdTf0cLnK47EzMt4CYfP7fqUr 5tEg== Received: by 10.204.156.206 with SMTP id y14mr14681764bkw.14.1333043716831; Thu, 29 Mar 2012 10:55:16 -0700 (PDT) Received: from [127.0.0.1] (host243-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.243]) by mx.google.com with ESMTPS id f6sm15371770bkg.10.2012.03.29.10.55.15 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 10:55:15 -0700 (PDT) Message-ID: <4F74A202.2040206@ipv6it.org> Date: Thu, 29 Mar 2012 19:55:14 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 CC: Roll@ietf.org References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnSDXfual81a0sF4hsJBAFc0N2/05oJUYxTQTab6TSjA5tyeQH1nLhfp6Um5VHoiKahbTpz Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2012 17:55:19 -0000 Il 29/03/2012 19.27, Philip Levis ha scritto: > On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote: > >> Il 28/03/2012 11.56, Philip Levis ha scritto: >>> On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: >>> >>>> Hi, I have a doubt about the root's rank with ETX. >>>> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: >>>> A is root >>>> B is non-root >>>> Link between A and B has a cost of 256 (ETX=2) >>>> >>>> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*). >>>> >>>> B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256. >>>> >>>> But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*). >>> Good catch. >>> >>> I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3). >>> >>> This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to MinHopRankIncrease; 3.3 was designed given the RPL specification, but I think the cur_min_path_cost clause is out of sync with it. What do you think? >>> >>> Phil >> Hi, thank you for your reply. >> >> I think that if the root node advertise a Rank of 256 it means that it got a path_cost to the worst parent of 256 (1*), so it means that it got a ETX of 2 to the worst parent. >> It's not RPL complaint(2*). >> If instead we suppose that root send packet to itself, it means that the root can lost packet (ETX=2) to itself. >> IMHO, a way to fix that (still assuming that root send packet to itself) is that root could advertise a Rank of 128 (ETX=1) so it got no loss to itself. >> Anyway I don't like this fix. >> >> I think that a goot fix is that a root set it's rank to MinHopRankIncrease and (only root) MUST use the metric container to carry ETX=0. >> >> I think it's a pretty significant change in MRHOF but I have other ideas. What do you think? >> >> >> >> >> (1*) MRHOF - Section 3.4 >> "...It then calculates the metric it will advertise in >> its metric container. This value is the path cost of the member of >> the parent set with the highest path cost..." >> >> (2*) RPL-RFC - Section 8.2.1 - Rules 2 >> "A DODAG root MUST have a DODAG parent set of size zero" >> > The RPL specification is what says the Rank value a root must advertise. > > 8.2.2.2 says > 2. A DODAG root MUST advertise a rank of ROOT_RANK. Yes. I agree with that. Root nodes got rank=256. > > To some degree, absolute ETX values do not matter -- what matters is their relative values. If all DODAG Roots advertise a Rank of 256, corresponding to an ETX of 2, then that's what they advertise, and a route with an computed ETX of 5 involves 3 transmissions within the LLN. > > I don't think I'm understanding the issue -- could you explain it again? > > Phil I don't agree that root nodes could advertise a ETX=2. "Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to its preferred parent. It then calculates the metric it will advertise in its metric container. This value is the path cost of the member of the parent set with the highest path cost." Root nodes have parent set of size zero so they got a cur_min_path_cost=0 so ETX=0. Because "a node MUST advertise an approximation of its ETX in its advertised Rank value" root nodes must advertise ETX=0. I agree with the fact that absolute ETX do not matter but I think that the root advertisement does not match the definition in the MRHOF draft. -- Regards Consoli Federico From prvs=42940cc68=mukul@uwm.edu Thu Mar 29 22:53:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD52621F86F0 for ; Thu, 29 Mar 2012 22:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WphCusgPZI7 for ; Thu, 29 Mar 2012 22:53:01 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD021F8793 for ; Thu, 29 Mar 2012 22:53:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAChJdU9/AAAB/2dsb2JhbABEhUa2byNWNQINGQJZBogdqHuJDIkJgS+OSYEYBIhYjQmQLoMFgTYX Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 80B33E6A90; Fri, 30 Mar 2012 00:53:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kDiNaNTI7ze; Fri, 30 Mar 2012 00:53:00 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 2B922E6A72; Fri, 30 Mar 2012 00:53:00 -0500 (CDT) Date: Fri, 30 Mar 2012 00:52:59 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <376974897.1749451.1333086779802.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 05:53:02 -0000 Hi Pascal, [Pascal] "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver timecritical application data to the target(s)." If DRO establishes path from origin to target then without a DRO, the target can send to the origin, not the other way around? If so I'd reword like if DRO is not requested, the DAG can only be used unidirectionally to report data from the target(s) to the origin. [Mukul] What I meant was that an origin could use P2P mode DIOs to send time critical data to the target(s) without discovering routes to these targets. Note that the temporary DAG itself cant be used for routing. The target ofcourse would know of a source route back to the origin when it receives a P2P mode DIO. [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal] " A P2P mode DIO: o MUST carry one (and only one) P2P Route Discovery Option (described in Section 7.1). The P2P Route Discovery Option allows for the specification of one unicast or multicast address for the target." Well; I can see how there would be only a target and no RDO, if we have good defaults. [Mukul] Sure, the RPL target option could be used in the manner you described earlier. I don't think a P2P-RPL route discovery can take place without a P2P-RDO. You need P2P-RDO to accumulate the route even if you somehow already knew what kind of route you want to discover etc. [Pascal] And I can see how a target could have a different DRO than the next target in the same DIO. So I do not agree with that statement at all. [Mukul] It is certainly possible that you want to discover a source route to one target and a hop-by-hop route to another. But, it seems to me that such flexibility might not be very useful in practice. The common case seems to be that same type of routes need to be discovered for all the targets. Plus, if there are multiple P2P-RDOs in a P2P mode DIO, I will have to create a separate option to do the route accumulation (because I dont want to replicate the accumulated route in all the P2P-RDOs in the DIO). I guess you would like that approach better since it is more modular. But, as I mentioned earlier, home/building world applications have a deep desire to save bytes whereever possible and extra options mean extra overhead in terms of bytes. [Pascal] " MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal] " When a target receives a P2P mode DIO, it forwards the data in any Data Options to the higher layer." As I hinted, this is not well enough defined. You're really using the DIO as a transport, so you need a minimum transport paradigm like a compressed UDP header. This comment applies to DRO as well, obviously. [Mukul] I am working on this. We could impart more structure to the data option. My fear is that if that particular structure (say a particular way to compress the UDP header) is not convenient to use in a particular deployment, the data option itself becomes useless. Would it be preferable if we simply suggest that the data in the data option be transport layer header+payload without actually enforcing a particular structure? What do you think? [Pascal] " Options: The DRO message: * MUST carry one P2P-RDO that MUST specify a complete route between the target and the origin;" If we establish a hop by hop with default values, could we live with just a target? [Mukul] I guess not because we still have to accumulate a route (which will be done inside the P2P-RDO). [Pascal] /*I did not review the trickle piece considering that Phil went through it and was satisfied */ 9.4: I'ma bit confused about the node that received multiple DIOs. Like: Should a node wait a bit before issuing its own DIO, to accommodate for a better route being received later? [Mukul] This depends on trickle parameters, how you define consistent/inconsistent events. We have made our recommendations in the trickle section of the draft. [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal] "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater. But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. [Mukul] All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin. [Pascal] " A target MUST NOT forward a P2P mode DIO any further." That is, if it is the only target in the DIO, AND the target is unicast. [Mukul] Right! Thanks for catching this. Thanks Mukul From pthubert@cisco.com Fri Mar 30 02:08:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002121F889C for ; Fri, 30 Mar 2012 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tvxYtxI291c for ; Fri, 30 Mar 2012 02:08:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4521F8896 for ; Fri, 30 Mar 2012 02:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=14796; q=dns/txt; s=iport; t=1333098480; x=1334308080; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=83eC08UASty+vO83eeLQaxJCpuExQBhse//HnnsK5CI=; b=NDXKIy3rv41PLKuf9TH3b8K+dqXoUvO8mAaLSDtNhGBUuCdemih26t1N pBlIJwyk8zD5QBo+CWK+zy7OzbzAZZ60LAeH3DamyL8by6UXnxg3aRcaF jxGtGob3vSxhsud5ieOtsqO1F4dG4mwLxwNnF+CGdP5nE37Bp2pcbJYOu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPV2dU+Q/khM/2dsb2JhbABEDoU4shd/gQeCCgEBBBIBEA0EPgcQAgEIGgIGBhgCAgIBAVUBAQQbGodom2qNCJIOgS+JQQuEfTVjBKQngWiCMDmBUgEW X-IronPort-AV: E=Sophos;i="4.75,342,1330905600"; d="scan'208";a="69725229" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2012 09:07:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2U97vCh005220; Fri, 30 Mar 2012 09:07:57 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 11:07:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 30 Mar 2012 11:06:32 +0200 Message-ID: In-Reply-To: <376974897.1749451.1333086779802.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Part 2 Re: [Roll] G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 Thread-Index: Ac0OOV71oAKayjdYRHqltEyyXbaykQAD9y8g References: <376974897.1749451.1333086779802.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 30 Mar 2012 09:07:57.0687 (UTC) FILETIME=[99602870:01CD0E54] Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 09:08:02 -0000 DQoiQnkgbm90IGFsbG93aW5nIHRoZSBnZW5lcmF0aW9uIG9mIERSTyBtZXNzYWdlcywgYW4gb3Jp Z2luIGNhbiB1c2UgUDJQLVJQTCBhcyBwdXJlbHkgYSBtZWNoYW5pc20gdG8gZGVsaXZlciB0aW1l Y3JpdGljYWwgYXBwbGljYXRpb24gZGF0YSB0byB0aGUgdGFyZ2V0KHMpLiINCg0KSWYgRFJPIGVz dGFibGlzaGVzIHBhdGggZnJvbSBvcmlnaW4gdG8gdGFyZ2V0IHRoZW4gd2l0aG91dCBhIERSTywg dGhlIHRhcmdldCBjYW4gc2VuZCB0byB0aGUgb3JpZ2luLCBub3QgdGhlIG90aGVyIHdheSBhcm91 bmQ/DQpJZiBzbyBJJ2QgcmV3b3JkIGxpa2UgaWYgRFJPIGlzIG5vdCByZXF1ZXN0ZWQsIHRoZSBE QUcgY2FuIG9ubHkgYmUgdXNlZCB1bmlkaXJlY3Rpb25hbGx5IHRvIHJlcG9ydCBkYXRhIGZyb20g dGhlIHRhcmdldChzKSB0byB0aGUgb3JpZ2luLg0KDQpbTXVrdWxdDQpXaGF0IEkgbWVhbnQgd2Fz IHRoYXQgYW4gb3JpZ2luIGNvdWxkIHVzZSBQMlAgbW9kZSBESU9zIHRvIHNlbmQgdGltZSBjcml0 aWNhbCBkYXRhIHRvIHRoZSB0YXJnZXQocykgd2l0aG91dCBkaXNjb3ZlcmluZyByb3V0ZXMgdG8g dGhlc2UgdGFyZ2V0cy4gTm90ZSB0aGF0IHRoZSB0ZW1wb3JhcnkgREFHIGl0c2VsZiBjYW50IGJl IHVzZWQgZm9yIHJvdXRpbmcuIFRoZSB0YXJnZXQgb2Zjb3Vyc2Ugd291bGQga25vdyBvZiBhIHNv dXJjZSByb3V0ZSBiYWNrIHRvIHRoZSBvcmlnaW4gd2hlbiBpdCByZWNlaXZlcyBhIFAyUCBtb2Rl IERJTy4NCg0KW1Bhc2NhbDJdIE1ha2VzIHNlbnNlLiBJIHRoaW5rIHlvdSBuZWVkIHRvIGFydGlj dWxhdGUgdGhlIDIgcG9zc2libGUgdXNlIGNhc2VzLiANCjEpIElmIHlvdSBqdXN0IHdhbnQgdG8g cG9zdCBvbmUgZGF0YWdyYW0gdG8gdGhlIHRhcmdldChzKSwgd2hhdCBoYXBwZW5zLCB3aGF0J3Mg dGhlIG1pbmltdW0gc2V0IG9mIGluZm9ybWF0aW9uIGluIHRoZSBESU8/IEUuZy4gSWYgbm8gcmVz cG9uc2UgaXMgZXhwZWN0ZWQsIHlvdSBkbyBub3QgbmVlZCB0byByZWNvcmQgYSByb3V0ZS4gDQoy KSBTYW1lIHF1ZXN0aW9uIGlmIHlvdSB3YW50IHRvIGNyZWF0ZSBzdGF0ZXMgYXQgdGhlIHRhcmdl dCB0byByb3V0ZSBiYWNrLiBIb3cgbG9uZyBkb2VzIHRoZSB0YXJnZXQgbmVlZCB0byBtYWludGFp biB0aGUgcm91dGU/IFdobyBjb250cm9scyB0aGF0LCB0aGUgb3JpZ2luIG9yIHRoZSB0YXJnZXQ/ IEknZCBleHBlY3QgdG8gZmluZCBhIHN1Z2dlc3RlZCBsaWZldGltZSBpbiB0aGUgUkRPIHdpdGgg YSBjb25maXJtYXRpb24gaW4gdGhlIERSTyB0byBsZXQgdGhlIHRhcmdldCBhbWVuZCBpdC4NCg0K DQoNCltQYXNjYWxdDQoiUlBMSW5zdGFuY2VJRDogUlBMSW5zdGFuY2VJRCBNVVNUIGJlIGEgbG9j YWwgdmFsdWUgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xIG9mIFtJLUQuaWV0Zi1yb2xsLXJw bF0uIFRoZSBvcmlnaW4gTVVTVCBOT1QgdXNlIHRoZSBzYW1lIFJQTEluc3RhbmNlSUQgaW4gdHdv IG9yIG1vcmUgY29uY3VycmVudCByb3V0ZSBkaXNjb3Zlcmllcy4iDQoNCkknZCBzdWdnZXN0IHRo YXQgeW91IGVuZm9yY2UgYSByb3VuZCByb2JpbiBvciBhbiBvcGFxdWUgY2lyY3VsYXRpb24gc28g dGhhdCB0aGUgbmV3IGluc3RhbmNlSUQgaXMgdGhlIGxlYXN0IHJlY2VudGx5IHVzZWQgb25lIG91 dCBvZiB0aGUgNjQgcG9zc2libGUuDQoNCltNdWt1bF0NCkkgdGhpbmsgd2Ugc2hvdWxkIGxlYXZl IGl0IHRvIHRoZSBvcmlnaW4gdG8gZGVjaWRlIHdoaWNoIHZhbHVlIGl0IHdhbnRzIHRvIHVzZSBm b3IgUlBMSW5zdGFuY2VJRC4gSSBrbm93IHNvbWUgaW1wbGVtZW50YXRpb25zIGFyZSBwbGFubmlu ZyB0byB1c2UgYSBmaXhlZCBSUExJbnN0YW5jZUlEIHZhbHVlIGZvciBhbGwgcm91dGUgZGlzY292 ZXJpZXMuDQoNCltQYXNjYWwyXSBDaGFuZ2luZyB0aGUgaW5zdGFuY2UgSUQgd2lsbCBoZWxwIGRl YnVnIHRoZSBuZXR3b3JrIGFuZCBhdm9pZCBjb25mbGljdHMgd2l0aCBzdGFsZSBzdGF0ZXMuIFdo YXQncyByZWFsbHkgdXAgdG8gdGhlIGRldmljZSBpcyB0aGUgaW5pdGlhbCBzZXF1ZW5jZS4gTGVh dmluZyBpdCB1cCB0byB0aGUgb3JpZ2luIG1heSBoZWxwIHRoZSBvcmlnaW4gZGVmZWF0IHNvbWUg YXR0YWNrcyB0byBzb21lIGRlZ3JlZS4gT1RPSCwgYWZ0ZXIgYWxsIHRoZSBpbnN0YW5jZXMgaGF2 ZSBiZWVuIHBsYXllZCwgTFJVIGZvcmNlcyB0byByZXBsYXkgdGhlIHNhbWUgc2VxdWVuY2UgYWdh aW4gc28gdGhlIHNoaWVsZCBkcm9wcy4gTXkgcHJlZmVycmVkIGFwcHJvYWNoIHdvdWxkIGJlIGEg U0hPVUxEIHRoYXQgd291bGQgc2F5IHRoYXQgdGhlIG5leHQgaW5zdGFuY2UgSUQgU0hPVUxEIE5P VCBiZSBvbmUgb2YgdGhlICgxNj8pIG1vc3QgcmVjZW50bHkgdXNlZCBhbmQgTVVTVCBOT1QgYmUg b25lIGZvciB3aGljaCBzdGF0ZXMgbWlnaHQgc3RpbGwgZXhpc3QgaW4gdGhlIG5ldHdvcmsuIElP VyBlaXRoZXIgdGhlIHN0YXRlcyBkZWxldGlvbiB3YXMgYWNrbm93bGVkZ2VkLCBvciBhbGwgcGVu ZGluZyBsaWZldGltZXMgYXJlIGV4aGF1c3RlZC4NCg0KDQoNCg0KW1Bhc2NhbF0NCiIgR3JvdW5k ZWQgKEcpIEZsYWc6IE1VU1QgYmUgc2V0IHRvIHplcm8gc2luY2UgdGhpcyBEQUcgaXMgdGVtcG9y YXJ5IGluIG5hdHVyZSwgaXMgY3JlYXRlZCBzb2xlbHkgZm9yIHRoZSBwdXJwb3NlIG9mIFAyUC1S UEwgcm91dGUgZGlzY292ZXJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIGZvciBwYWNrZXQgcm91dGlu Zy4iDQoNCk9uIHRoZSBjb250cmFyeSBJJ2Qgc2V0IGl0IHRvIDEuIFRoZSBnb2FsIC1iZWluZyB0 byByZWFjaCB0aGUgb3JpZ2luLSBpcyBhY3R1YWxseSBhY2hpZXZlZCBieSB0aGlzIERBRy4NCg0K W011a3VsXQ0KQWN0dWFsbHksIHRoZSBEQUcgaXMgdGVtcG9yYXJ5IGluIG5hdHVyZSBhbmQgdmFu aXNoZXMgYWZ0ZXIgYSBzaG9ydCB3aGlsZS4gRXZlbiB3aGVuIGl0IGV4aXN0cywgaXQgbXVzdC9z aG91bGQgbm90IGJlIHVzZWQgZm9yIHJvdXRpbmcgcGFja2V0cyBiYWNrIHRvIHRoZSBvcmlnaW4u IFNvLCBJIHRoaW5rIHRoZSBHcm91bmRlZCBmbGFnIHNob3VsZCBiZSB6ZXJvLg0KDQpbUGFzY2Fs Ml0gUGxlYXNlIHJldmlzaXQgUkZDIDY2NTAgcGFnZSAxMi4gDQpHIG1lYW5zIHRoYXQgYSBnb2Fs IGlzIGFjaGlldmVkLiBTbyBmaXJzdCB5b3UgZGVmaW5lIHRoZSBnb2FsIGFuZCB0aGVuIHRoZSBi aXQgYmVjb21lcyBvYnZpb3VzLiBXaGF0J3MgeW91ciBnb2FsPyANCkNhbiB0aGVyZSBiZSBQMlAg REFHcyB0aGF0IGFjaGlldmUgdGhlIGdvYWwgYW5kIG90aGVycyB0aGF0IG1ha2Ugc2Vuc2UgdG8g YnVpbGQgYW5kIHlldCBkbyBub3QgYWNoaWV2ZSB0aGUgZ29hbD8NCklmIHlvdSBhY2NlcHQgdGhh dCB5b3VyIG9wZXJhdGlvbiBjYW4gYWN0dWFsbHkgZGVwZW5kIG9uIE9GIGxvZ2ljLCB0aGVuIHRo ZSBzZXR0aW5nIG9mIHRoZSBnb2FsIGluZmx1ZW5jZXMgdGhhdCBsb2dpYy4NCkJ5IGZvcmNpbmcg YSB2YWx1ZSB0byB0aGUgZ29hbCBpbiB0aGUgUFRQIHNwZWMsIHdlIGFjdHVhbGx5IGxpbWl0IHRo ZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBkcmFmdC4gDQpNYXliZSB5b3UgY2FuIGRlZmluZSBhIGRl ZmF1bHQgZ29hbCBhbmQgYSBkZWZhdWx0IHNldHRpbmcuIEJ1dCBkbyBub3QgTVVTVCB0aGF0IGl0 IGlzIHNldCB0byAwLi4uDQoNCltQYXNjYWxdIiBBIFAyUCBtb2RlIERJTzoNCm8gTVVTVCBjYXJy eSBvbmUgKGFuZCBvbmx5IG9uZSkgUDJQIFJvdXRlIERpc2NvdmVyeSBPcHRpb24gKGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDcuMSkuIFRoZSBQMlAgUm91dGUgRGlzY292ZXJ5IE9wdGlvbiBhbGxvd3Mg Zm9yIHRoZSBzcGVjaWZpY2F0aW9uIG9mIG9uZSB1bmljYXN0IG9yIG11bHRpY2FzdCBhZGRyZXNz IGZvciB0aGUgdGFyZ2V0LiINCg0KV2VsbDsgSSBjYW4gc2VlIGhvdyB0aGVyZSB3b3VsZCBiZSBv bmx5IGEgdGFyZ2V0IGFuZCBubyBSRE8sIGlmIHdlIGhhdmUgZ29vZCBkZWZhdWx0cy4NCg0KW011 a3VsXQ0KU3VyZSwgdGhlIFJQTCB0YXJnZXQgb3B0aW9uIGNvdWxkIGJlIHVzZWQgaW4gdGhlIG1h bm5lciB5b3UgZGVzY3JpYmVkIGVhcmxpZXIuIEkgZG9uJ3QgdGhpbmsgYSBQMlAtUlBMIHJvdXRl IGRpc2NvdmVyeSBjYW4gdGFrZSBwbGFjZSB3aXRob3V0IGEgUDJQLVJETy4gWW91IG5lZWQgUDJQ LVJETyB0byBhY2N1bXVsYXRlIHRoZSByb3V0ZSBldmVuIGlmIHlvdSBzb21laG93IGFscmVhZHkg a25ldyB3aGF0IGtpbmQgb2Ygcm91dGUgeW91IHdhbnQgdG8gZGlzY292ZXIgZXRjLg0KDQpbUGFz Y2FsMl0gSSBjYW4gc2VlIHdoeSBtb3N0IG9mIHRoZSB0aW1lIGluIHRoZSB1c2FnZSB5b3UgaGF2 ZSBpbiBtaW5kIHRoZSBSRE8gd2lsbCBiZSB0aGVyZS4gTmVlZCA9PiB1c2UgaXMgZmluZSB3aXRo IG1lLiBCdXQgTVVTVGluZyB0aGUgdXNlIGhhcyB0aGUgbG9naWMgYmFja3dhcmRzIGFuZCBhZ2Fp biB5b3UgYXJlIGxpbWl0aW5nIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHlvdXIgZHJhZnQuDQplLmcu IEkgcmVhZCBhYm92ZSB0aGF0IHlvdSBtaWdodCB1c2UgRElPIHRvIGRlbGl2ZXIgY3JpdGljYWwg ZGF0YSB0byB0aGUgdGFyZ2V0LiBJIGhhdmUgbm90IHJlYWQgdGhhdCB0aGlzIGFsd2F5cyBpbXBs aWVzIGFuIGFjayBiYWNrLiBTbyB3aHkgc3RvcmUgdGhlIHJvdXRlPw0KDQoNCltQYXNjYWxdDQpB bmQgSSBjYW4gc2VlIGhvdyBhIHRhcmdldCBjb3VsZCBoYXZlIGEgZGlmZmVyZW50IERSTyB0aGFu IHRoZSBuZXh0IHRhcmdldCBpbiB0aGUgc2FtZSBESU8uDQpTbyBJIGRvIG5vdCBhZ3JlZSB3aXRo IHRoYXQgc3RhdGVtZW50IGF0IGFsbC4NCg0KW011a3VsXQ0KSXQgaXMgY2VydGFpbmx5IHBvc3Np YmxlIHRoYXQgeW91IHdhbnQgdG8gZGlzY292ZXIgYSBzb3VyY2Ugcm91dGUgdG8gb25lIHRhcmdl dCBhbmQgYSBob3AtYnktaG9wIHJvdXRlIHRvIGFub3RoZXIuIEJ1dCwgaXQgc2VlbXMgdG8gbWUg dGhhdCBzdWNoIGZsZXhpYmlsaXR5IG1pZ2h0IG5vdCBiZSB2ZXJ5IHVzZWZ1bCBpbiBwcmFjdGlj ZS4gVGhlIGNvbW1vbiBjYXNlIHNlZW1zIHRvIGJlIHRoYXQgc2FtZSB0eXBlIG9mIHJvdXRlcyBu ZWVkIHRvIGJlIGRpc2NvdmVyZWQgZm9yIGFsbCB0aGUgdGFyZ2V0cy4gUGx1cywgaWYgdGhlcmUg YXJlIG11bHRpcGxlIFAyUC1SRE9zIGluIGEgUDJQIG1vZGUgRElPLCBJIHdpbGwgaGF2ZSB0byBj cmVhdGUgYSBzZXBhcmF0ZSBvcHRpb24gdG8gZG8gdGhlIHJvdXRlIGFjY3VtdWxhdGlvbiAoYmVj YXVzZSBJIGRvbnQgd2FudCB0byByZXBsaWNhdGUgdGhlIGFjY3VtdWxhdGVkIHJvdXRlIGluIGFs bCB0aGUgUDJQLVJET3MgaW4gdGhlIERJTykuIEkgZ3Vlc3MgeW91IHdvdWxkIGxpa2UgdGhhdCBh cHByb2FjaCBiZXR0ZXIgc2luY2UgaXQgaXMgbW9yZSBtb2R1bGFyLiBCdXQsIGFzIEkgbWVudGlv bmVkIGVhcmxpZXIsIGhvbWUvYnVpbGRpbmcgd29ybGQgYXBwbGljYXRpb25zIGhhdmUgYSBkZWVw IGRlc2lyZSB0byBzYXZlIGJ5dGVzIHdoZXJlZXZlciBwb3NzaWJsZSBhbmQgZXh0cmEgb3B0aW9u cyBtZWFuIGV4dHJhIG92ZXJoZWFkIGluIHRlcm1zIG9mIGJ5dGVzLg0KICANCltQYXNjYWwyXSBC VFcgdHlwbyB1cCB0aGVyZSwgSSBtZWFudCBSRE8uIEl0J3MgKHNsaWdodGx5IHRvbykgZWFzeSB0 byBtaXggdGhvc2UgMiB1cC4uLiBBbmQgSSB1bmRlcnN0YW5kIHlvdSBoYXZlIHRvIGZpbmQgYSB0 cmFkZS1vZmYuIFlvdSBoYXZlIHRvIHBhY2thZ2UgdG9nZXRoZXIgdGhpbmdzIHRoYXQgaGF2ZSBh IHN0cm9uZyBsb2dpY2FsIHJlbGF0aW9uc2hpcC4gQW5kIHNwbGl0IHRoaW5ncyB0aGF0IGNhbiBi ZSB1c2VkIHNlcGFyYXRlbHkgYXMgbXVjaCBhcyB5b3UgY2FuIGFmZm9yZCB3aXRoaW4gcHJhY3Rp Y2FsIGNvbnN0cmFpbnRzLi4uIE5vdCBhbiBlYXN5IHRhc2suIFdoZW4gSSBsb29rIGF0IHRoZSBS RE8sIG15IHByZWZlcnJlZCBzcGxpdCBpcyB0byB0YWtlIHRoZSB0YXJnZXQgb3V0IGFuZCBrZWVw IHRoZSByZXN0IGluLiBJIGhhdmUgYSBkb3VidCB3aXRoIHJlZ2FyZHMgdG8gdGhlIGxpZmV0aW1l IGZpZWxkIHRob3VnaDsgbWF5YmUgd2UgY291bGQgYWN0dWFsbHkgbW92ZSBpdCB0byB0aGUgcmVz ZXJ2ZWQgZmllbGQgaW50byB0aGUgRElPIGJhc2Ugb2JqZWN0LiBJIGNhbiBzZWUgaG93IHRoZSB1 c2FnZSBjYW4gYmUgZ2VuZXJhbGl6ZWQgdG8gbm9uIFAyUCB5ZXQgdHJhbnNpZW50IERBR3MuIFRo YXQgd291bGQgZ2l2ZSB5b3UgbW9yZSBncmFudWxhcml0eWZybyBib3RoIGxpZmV0aW1lIGFuZCBt YXhyYW5rLiANCiAgDQoNCg0KW1Bhc2NhbF0iIE1BWSBjYXJyeSBvbmUgb3IgbW9yZSBSUEwgVGFy Z2V0IE9wdGlvbnMgdG8gc3BlY2lmeSBhZGRpdGlvbmFsIHVuaWNhc3QvbXVsdGljYXN0IGFkZHJl c3NlcyBmb3IgdGhlIHRhcmdldC4iDQpOb3cgaGVyZSBJIHdvdWxkIGhhdmUgYSBNVVNUIGNhcnJ5 IGF0IGxlYXN0IG9uZSB0YXJnZXQuIFRoYXQgaXMgaW5kZWVkIHdoYXQgbWFrZXMgaXMgYSBsb29r dXAgRElPLi4uDQoNCltNdWt1bF0NCkFzIEkgc3RhdGVkIGluIHRoZSBwcmV2aW91cyBtZXNzYWdl LCB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhlIHRhcmdldCBpbiB0aGUgUDJQLVJETyB0byBzYXZlIGJ5 dGVzIGZvciB0aGUgY29tbW9uIGNhc2UgKGRpc2NvdmVyIHJvdXRlIHRvIG9uZSB1bmljYXN0L211 bHRpY2FzdCB0YXJnZXQpLiBTbywgd2UgY2Fubm90IG1ha2UgdXNpbmcgdGhlIHRhcmdldCBvcHRp b24gYSBNVVNULg0KDQpbUGFzY2FsMl0gQ2VydGFpbmx5LiBJIHByZWZlciB0aGUgc3BsaXQsIGlu IHdoaWNoIGNhc2UgdGhlIE1VU1QgSU1ITyBnb2VzIHRvIHRoZSB0YXJnZXQgYXMgb3Bwb3NlZCB0 byB0aGUgUkRPLiBJbiBhIGNhc2Ugd2hlcmUgdGhlIFJETyBpcyBub3QgbmVlZGVkLCB0aGUgdGFy Z2V0IG9ubHkgbWVzc2FnZSBpcyBhY3R1YWxseSBzaG9ydGVyLi4uDQogDQoNCltQYXNjYWxdDQoi IFdoZW4gYSB0YXJnZXQgcmVjZWl2ZXMgYSBQMlAgbW9kZSBESU8sIGl0IGZvcndhcmRzIHRoZSBk YXRhIGluIGFueSBEYXRhIE9wdGlvbnMgdG8gdGhlIGhpZ2hlciBsYXllci4iDQpBcyBJIGhpbnRl ZCwgdGhpcyBpcyBub3Qgd2VsbCBlbm91Z2ggZGVmaW5lZC4gWW91J3JlIHJlYWxseSB1c2luZyB0 aGUgRElPIGFzIGEgdHJhbnNwb3J0LCBzbyB5b3UgbmVlZCBhIG1pbmltdW0gdHJhbnNwb3J0IHBh cmFkaWdtIGxpa2UgYSBjb21wcmVzc2VkIFVEUCBoZWFkZXIuDQpUaGlzIGNvbW1lbnQgYXBwbGll cyB0byBEUk8gYXMgd2VsbCwgb2J2aW91c2x5Lg0KDQpbTXVrdWxdDQpJIGFtIHdvcmtpbmcgb24g dGhpcy4gV2UgY291bGQgaW1wYXJ0IG1vcmUgc3RydWN0dXJlIHRvIHRoZSBkYXRhIG9wdGlvbi4g TXkgZmVhciBpcyB0aGF0IGlmIHRoYXQgcGFydGljdWxhciBzdHJ1Y3R1cmUgKHNheSBhIHBhcnRp Y3VsYXIgd2F5IHRvIGNvbXByZXNzIHRoZSBVRFAgaGVhZGVyKSBpcyBub3QgY29udmVuaWVudCB0 byB1c2UgaW4gYSBwYXJ0aWN1bGFyIGRlcGxveW1lbnQsIHRoZSBkYXRhIG9wdGlvbiBpdHNlbGYg YmVjb21lcyB1c2VsZXNzLiBXb3VsZCBpdCBiZSBwcmVmZXJhYmxlIGlmIHdlIHNpbXBseSBzdWdn ZXN0IHRoYXQgdGhlIGRhdGEgaW4gdGhlIGRhdGEgb3B0aW9uIGJlIHRyYW5zcG9ydCBsYXllciBo ZWFkZXIrcGF5bG9hZCB3aXRob3V0IGFjdHVhbGx5IGVuZm9yY2luZyBhIHBhcnRpY3VsYXIgc3Ry dWN0dXJlPyBXaGF0IGRvIHlvdSB0aGluaz8gDQoNCltQYXNjYWwyXSBZb3UgbmVlZCB0byBzcGVj aWZ5IGF0IGxlYXN0IG9uZSBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgIm5leHQgaGVhZGVyIi4gTWF5 YmUgeW91IGNvdWxkIGxvb2sgYXQgaG93IFJGQyA2MjgyIGRvZXMgaXQgZm9yIFVEUD8gIEFzIGFu IGFsdGVybmF0ZSB0byBVRFAsIHlvdSBjb3VsZCBkZWZpbmUgYSAnd2VsbCBrbm93biwgZnJlZSBm b3JtJyAgTkggZm9yIGEgZGV2aWNlIHRoYXQgaGFzIG9ubHkgb25lIHBvc3NpYmxlIGNvbnN1bWVy IGZvciB0aGUgZGF0YS4NCg0KDQoNCltQYXNjYWxdDQoiIE9wdGlvbnM6IFRoZSBEUk8gbWVzc2Fn ZToNCiogTVVTVCBjYXJyeSBvbmUgUDJQLVJETyB0aGF0IE1VU1Qgc3BlY2lmeSBhIGNvbXBsZXRl IHJvdXRlIGJldHdlZW4gdGhlIHRhcmdldCBhbmQgdGhlIG9yaWdpbjsiDQpJZiB3ZSBlc3RhYmxp c2ggYSBob3AgYnkgaG9wIHdpdGggZGVmYXVsdCB2YWx1ZXMsIGNvdWxkIHdlIGxpdmUgd2l0aCBq dXN0IGEgdGFyZ2V0Pw0KDQpbTXVrdWxdDQpJIGd1ZXNzIG5vdCBiZWNhdXNlIHdlIHN0aWxsIGhh dmUgdG8gYWNjdW11bGF0ZSBhIHJvdXRlICh3aGljaCB3aWxsIGJlIGRvbmUgaW5zaWRlIHRoZSBQ MlAtUkRPKS4NCg0KW1Bhc2NhbDJdIE9vdXBzIE9LIA0KDQpbUGFzY2FsXQ0KLypJIGRpZCBub3Qg cmV2aWV3IHRoZSB0cmlja2xlIHBpZWNlIGNvbnNpZGVyaW5nIHRoYXQgUGhpbCB3ZW50IHRocm91 Z2ggaXQgYW5kIHdhcyBzYXRpc2ZpZWQgKi8NCg0KOS40OiBJJ21hIGJpdCBjb25mdXNlZCBhYm91 dCB0aGUgbm9kZSB0aGF0IHJlY2VpdmVkIG11bHRpcGxlIERJT3MuIA0KTGlrZTogU2hvdWxkIGEg bm9kZSB3YWl0IGEgYml0IGJlZm9yZSBpc3N1aW5nIGl0cyBvd24gRElPLCB0byBhY2NvbW1vZGF0 ZSBmb3IgYSBiZXR0ZXIgcm91dGUgYmVpbmcgcmVjZWl2ZWQgbGF0ZXI/DQoNCltNdWt1bF0NClRo aXMgZGVwZW5kcyBvbiB0cmlja2xlIHBhcmFtZXRlcnMsIGhvdyB5b3UgZGVmaW5lIGNvbnNpc3Rl bnQvaW5jb25zaXN0ZW50IGV2ZW50cy4gV2UgaGF2ZSBtYWRlIG91ciByZWNvbW1lbmRhdGlvbnMg aW4gdGhlIHRyaWNrbGUgc2VjdGlvbiBvZiB0aGUgZHJhZnQuDQoNCltQYXNjYWwyXSBPb3VwcyBP Sw0KDQoNCltQYXNjYWxdDQpDYW4gdGhlIGRhdGEgb3B0aW9uIGJlIGRpZmZlcmVudCBmcm9tIG9u ZSBESU8gdG8gdGhlIG5leHQ/IA0KDQpbTXVrdWxdDQpUaGUgY29udGVudHMgb2YgdGhlIGRhdGEg b3B0aW9uIGFyZSBzcGVjaWZpZWQgYnkgdGhlIG9yaWdpbiAoZm9yIHRoZSBESU8pIG9yIHRoZSB0 YXJnZXQgKGZvciB0aGUgRFJPKS4gSW4gdGhlb3J5LCBhbiBvcmlnaW4gY2FuIHNlbmQgZGlmZmVy ZW50IGRhdGEgb3B0aW9ucyBpbiBkaWZmZXJlbnQgRElPcyBpdCBnZW5lcmF0ZXMgZm9yIGEgcGFy dGljdWxhciByb3V0ZSBkaXNjb3ZlcnkgKGFzc3VtaW5nIHRoYXQgaXQgZG9lcyBnZW5lcmF0ZSBt dWx0aXBsZSBESU9zOyBpdCBpcyB2ZXJ5IG11Y2ggcG9zc2libGUgdGhhdCB0aGUgb3JpZ2luIGdl bmVyYXRlcyBqdXN0IG9uZSBESU8gYW5kIHRoZW4gc2l0cyBzaWxlbnQpLiBCdXQsIHRoZW4gdGhl IG9yaWdpbiBpcyB0YWtpbmcgdGhlIHJpc2sgdGhhdCBzb21lIG9mIHRoZSBkYXRhIG9wdGlvbnMg d291bGQgbmV2ZXIgZWFjaCB0aGUgdGFyZ2V0KHMpLiBJIGd1ZXNzIHRoZSBvcmlnaW4gbWlnaHQg ZG8gdGhpcyBpZiB0aGUgZGF0YSBzZW50IGVhcmxpZXIgaXMgbm93IHN0YWxlIGFuZCB0aGUgb3Jp Z2luIHdvdWxkIGxpa2UgdGhlIHRhcmdldChzKSB0byByZWNlaXZlIG5ld2VyIGRhdGEuDQoNCg0K W1Bhc2NhbDJdIFRoaXMgc2hvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQuIFlvdSBuZWVk IHRvIHNldCB0aGUgZXhwZWN0YXRpb24gZm9yIHRoZSB1cHBlciBsYXllcihzKS4gSXMgdGhlcmUg YSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBkaWZmZXJlbnQgZGF0YSBzZXRzPyBFZyBpbnN0YW5jZSBv ciBzZXF1ZW5jZSBuYj8NCk15IHN1Z2dlc3Rpb24gc28gZmFyIGlzIHRoYXQgdGhlIGRhdGEgc2hv dWxkIGhhdmUgMyBiaXRzIG9mIG5leHQgaGVhZGVyIGFuZCA1IGJpdHMgb2Ygc2VxdWVuY2UuDQoN CiANCg0KW1Bhc2NhbF0NCiJXaGVuIGFuDQppbnRlcm1lZGlhdGUgcm91dGVyIGFkZHMgaXRzZWxm IHRvIGEgcm91dGUsIGl0IE1VU1QgZW5zdXJlIHRoYXQgdGhlDQpJUHY2IGFkZHJlc3MgYWRkZWQg dG8gdGhlIHJvdXRlIGlzIHJlYWNoYWJsZSBpbiBib3RoIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRp cmVjdGlvbnMuIg0KVGhpcyBpcyB3cml0dGVuIHdpdGggdGhlIHZpc2lvbiB0aGF0IHRoZSByb3V0 ZXIgaGFzIGEgc2luZ2xlIGludGVyZmFjZSBhbmQgYWN0cyBhcyBhIHJlcGVhdGVyLiANCkJ1dCBy ZWFsbHkgYSByb3V0ZXIgY291bGQgaGF2ZSAyIGludGVyZmFjZXMgb24gYSBzYW1lIHN1Ym5ldCBp biB3aGljaCBjYXNlIHRoYXQgY2xhdXNlIGRvZXMgbm90IGZseS4NCg0KW011a3VsXQ0KQWxsIEkg bWVhbiBpcyB0aGF0IHRoZSBhY2N1bXVsYXRlZCByb3V0ZSBNVVNUIE5PVCBoYXZlIGFuIGFkZHJl c3MgdGhhdCBjYW5ub3QgYmUgYWNjZXNzZWQgaW4gb25lIG9mIHRoZSBkaXJlY3Rpb25zLiBJZiB0 aGUgYWRkcmVzcyBjYW5ub3QgYmUgYWNjZXNzZWQgaW4gdGhlIGJhY2t3YXJkIGRpcmVjdGlvbiwg dGhlbiB0aGUgRFJPIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHRyYXZlbCB0byB0aGUgb3JpZ2luLg0K DQpbUGFzY2FsMl0gVGhlbiB5b3UncmUgcHJldmVudGluZyBhIHJvdXRlciB3aXRoIDIgaW50ZXJm YWNlcy4gVGhhdCdzIHNhZC4gSSdtIGZpbmUgZm9yIGFuIGV4cGVyaW1lbnRhbCBkcmFmdCAgIGJ1 dCBmb3Igc3RhbmRhcmQgdHJhY2sgdGhhdCB3aWxsIGhhdmUgdG8gYmUgY2hhbmdlZC4NCg0KW1Bh c2NhbF0NCiIgQSB0YXJnZXQgTVVTVCBOT1QgZm9yd2FyZCBhIFAyUCBtb2RlIERJTyBhbnkgZnVy dGhlci4iIA0KVGhhdCBpcywgaWYgaXQgaXMgdGhlIG9ubHkgdGFyZ2V0IGluIHRoZSBESU8sIEFO RCB0aGUgdGFyZ2V0IGlzIHVuaWNhc3QuDQoNCltNdWt1bF0NClJpZ2h0ISBUaGFua3MgZm9yIGNh dGNoaW5nIHRoaXMuDQoNCltdIENoZWVyczsNCg0KUGFzY2FsDQo= From pal@cs.stanford.edu Fri Mar 30 02:53:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6361021F8919 for ; Fri, 30 Mar 2012 02:53:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3-LaeJVvs8K for ; Fri, 30 Mar 2012 02:53:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6913521F8916 for ; Fri, 30 Mar 2012 02:53:55 -0700 (PDT) Received: from ast-lambert-153-1-157-249.w90-44.abo.wanadoo.fr ([90.44.96.249] helo=[192.168.100.145]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SDYWp-00073n-2s; Fri, 30 Mar 2012 02:53:55 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4F74A202.2040206@ipv6it.org> Date: Fri, 30 Mar 2012 11:53:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55B55877-4CF8-444C-9E09-711C6990BC9D@cs.stanford.edu> References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> <4F74A202.2040206@ipv6it.org> To: Federico Consoli X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 5d5bd4b8133540f30bea22ef470d169d Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 09:53:57 -0000 On Mar 29, 2012, at 7:55 PM, Federico Consoli wrote: > Il 29/03/2012 19.27, Philip Levis ha scritto: >> On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote: >>=20 >>> Il 28/03/2012 11.56, Philip Levis ha scritto: >>>> On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: >>>>=20 >>>>> Hi, I have a doubt about the root's rank with ETX. >>>>> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: >>>>> A is root >>>>> B is non-root >>>>> Link between A and B has a cost of 256 (ETX=3D2) >>>>>=20 >>>>> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) = in its DIO message in its advertised Rank value(6*). >>>>>=20 >>>>> B will receive a DIO with rank value =3D 0 so B will set his rank = to 256(7*) and will annunce a path_cost of 256. >>>>>=20 >>>>> But now I got 2 nodes with the same rank value. I think it's not a = problem with the algorith of DODAG creation but it's not RPL = complaint(5*). >>>> Good catch. >>>>=20 >>>> I think the issue here is the MRHOF draft is not clear: A (a root) = should advertise a Rank of 256, and B, following 3.3, would advertise a = Rank of 256 + MinHopRankIncrease (case 3 of 3.3). >>>>=20 >>>> This does get at a more fundamental issue, one where the rules on = Rank and the rules on metrics can diverge. I'd argue that the text = saying Root nodes set to MIN_PATH_COST should instead relate to = MinHopRankIncrease; 3.3 was designed given the RPL specification, but I = think the cur_min_path_cost clause is out of sync with it. What do you = think? >>>>=20 >>>> Phil >>> Hi, thank you for your reply. >>>=20 >>> I think that if the root node advertise a Rank of 256 it means that = it got a path_cost to the worst parent of 256 (1*), so it means that it = got a ETX of 2 to the worst parent. >>> It's not RPL complaint(2*). >>> If instead we suppose that root send packet to itself, it means that = the root can lost packet (ETX=3D2) to itself. >>> IMHO, a way to fix that (still assuming that root send packet to = itself) is that root could advertise a Rank of 128 (ETX=3D1) so it got = no loss to itself. >>> Anyway I don't like this fix. >>>=20 >>> I think that a goot fix is that a root set it's rank to = MinHopRankIncrease and (only root) MUST use the metric container to = carry ETX=3D0. >>>=20 >>> I think it's a pretty significant change in MRHOF but I have other = ideas. What do you think? >>>=20 >>>=20 >>>=20 >>>=20 >>> (1*) MRHOF - Section 3.4 >>> "...It then calculates the metric it will advertise in >>> its metric container. This value is the path cost of the member of >>> the parent set with the highest path cost..." >>>=20 >>> (2*) RPL-RFC - Section 8.2.1 - Rules 2 >>> "A DODAG root MUST have a DODAG parent set of size zero" >>>=20 >> The RPL specification is what says the Rank value a root must = advertise. >>=20 >> 8.2.2.2 says >> 2. A DODAG root MUST advertise a rank of ROOT_RANK. > Yes. I agree with that. Root nodes got rank=3D256. >>=20 >> To some degree, absolute ETX values do not matter -- what matters is = their relative values. If all DODAG Roots advertise a Rank of 256, = corresponding to an ETX of 2, then that's what they advertise, and a = route with an computed ETX of 5 involves 3 transmissions within the LLN. >>=20 >> I don't think I'm understanding the issue -- could you explain it = again? >>=20 >> Phil > I don't agree that root nodes could advertise a ETX=3D2. >=20 > "Once the preferred parent is selected, the node sets its = cur_min_path_cost variable to the path cost corresponding to its = preferred parent. It then calculates the metric it will advertise in its = metric container. This value is the path cost of the member of the = parent set with the highest path cost." >=20 > Root nodes have parent set of size zero so they got a = cur_min_path_cost=3D0 so ETX=3D0. >=20 > Because "a node MUST advertise an approximation of its ETX in its = advertised Rank value" root nodes must advertise ETX=3D0. > I agree with the fact that absolute ETX do not matter but I think that = the root advertisement does not match the definition in the MRHOF draft. Ah, this is a good catch. I'll adjust the text to note this edge case. I = chose the word "approximation" carefully there -- but the issues you're = pointing out make it clear that the draft should explain what's going on = in greater detail. In particular, how would you feel about some text = along the lines of "RPL's Rank advertisement rules can require a DODAG Root to advertise a = Rank higher than its corresponding ETX value, as a DODAG Root advertises = a Rank of MinHopRankIncrease. Because all DODAG Roots within a DODAG = Version advertise the same Rank, this constant value typically does not = affect route selection. Nevertheless, it means that if a DODAG Version = has a MinHopRankIncrease of M and a path has an advertised ETX of E, = then the actual ETX of the path is likely closer to a value of E-M than = a value of E." Phil From admin@ipv6it.org Fri Mar 30 04:42:49 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0B21F86C2 for ; Fri, 30 Mar 2012 04:42:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx-lZIvl+8YC for ; Fri, 30 Mar 2012 04:42:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3621F869C for ; Fri, 30 Mar 2012 04:42:47 -0700 (PDT) Received: by bkuw5 with SMTP id w5so461661bku.31 for ; Fri, 30 Mar 2012 04:42:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-gm-message-state:content-type :content-transfer-encoding; bh=EzrG6j07nbEhfX9AyQDEupamYo06FsjUWgd/wUvnk8E=; b=RENDuwyZYk6lDTc9diCXy4ho8HinXp7VHXxNqHe/uZoScMjoV3iNFQT7klVfMOlxfb qh+nNbC8EUMoUHm9yx9Wbgju14Luhh6Ny4p8uYJ4ytrkQVO1eWkp2/MITpru5E9F7P17 ISKJIHJLvFL5Xj4ldPqLw2DzYfhLsE9mKEt/hIB3b7WoRP6ATD/TOp4U15RYFucSAGdS M/0O5MZ7MiNxSrpuHigW/6MbVipfftxpxkWNoGIgU6W1AaEUyFvOTbrfHBP7z5FQH2NO z9VCZsjDe/mEAtWMLr/JuaXxYJfMurAywTT3tsvOfgMMW1pmSNDFUFyMZTTw69YjqTRi DuxA== Received: by 10.205.133.208 with SMTP id hz16mr816272bkc.56.1333107766791; Fri, 30 Mar 2012 04:42:46 -0700 (PDT) Received: from [127.0.0.1] (host232-59-dynamic.60-82-r.retail.telecomitalia.it. [82.60.59.232]) by mx.google.com with ESMTPS id b3sm11148483bki.16.2012.03.30.04.42.42 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 04:42:45 -0700 (PDT) Message-ID: <4F759C31.2050306@ipv6it.org> Date: Fri, 30 Mar 2012 13:42:41 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Philip Levis References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> <4F74A202.2040206@ipv6it.org> <55B55877-4CF8-444C-9E09-711C6990BC9D@cs.stanford.edu> In-Reply-To: <55B55877-4CF8-444C-9E09-711C6990BC9D@cs.stanford.edu> X-Gm-Message-State: ALoCoQlKXdqD9CtB6td4ADpkOLFDKWPHceqM/D3QbDr+QWsJo/H5HPfzQqi6yVCunMAb/wvkRctd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 11:42:49 -0000 Il 30/03/2012 11.53, Philip Levis ha scritto: > On Mar 29, 2012, at 7:55 PM, Federico Consoli wrote: > >> Il 29/03/2012 19.27, Philip Levis ha scritto: >>> On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote: >>> >>>> Il 28/03/2012 11.56, Philip Levis ha scritto: >>>>> On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote: >>>>> >>>>>> Hi, I have a doubt about the root's rank with ETX. >>>>>> Assume I have 2 nodes A and B and I use ETX as metric with MRHOF: >>>>>> A is root >>>>>> B is non-root >>>>>> Link between A and B has a cost of 256 (ETX=2) >>>>>> >>>>>> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*). >>>>>> >>>>>> B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256. >>>>>> >>>>>> But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*). >>>>> Good catch. >>>>> >>>>> I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3). >>>>> >>>>> This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to MinHopRankIncrease; 3.3 was designed given the RPL specification, but I think the cur_min_path_cost clause is out of sync with it. What do you think? >>>>> >>>>> Phil >>>> Hi, thank you for your reply. >>>> >>>> I think that if the root node advertise a Rank of 256 it means that it got a path_cost to the worst parent of 256 (1*), so it means that it got a ETX of 2 to the worst parent. >>>> It's not RPL complaint(2*). >>>> If instead we suppose that root send packet to itself, it means that the root can lost packet (ETX=2) to itself. >>>> IMHO, a way to fix that (still assuming that root send packet to itself) is that root could advertise a Rank of 128 (ETX=1) so it got no loss to itself. >>>> Anyway I don't like this fix. >>>> >>>> I think that a goot fix is that a root set it's rank to MinHopRankIncrease and (only root) MUST use the metric container to carry ETX=0. >>>> >>>> I think it's a pretty significant change in MRHOF but I have other ideas. What do you think? >>>> >>>> >>>> >>>> >>>> (1*) MRHOF - Section 3.4 >>>> "...It then calculates the metric it will advertise in >>>> its metric container. This value is the path cost of the member of >>>> the parent set with the highest path cost..." >>>> >>>> (2*) RPL-RFC - Section 8.2.1 - Rules 2 >>>> "A DODAG root MUST have a DODAG parent set of size zero" >>>> >>> The RPL specification is what says the Rank value a root must advertise. >>> >>> 8.2.2.2 says >>> 2. A DODAG root MUST advertise a rank of ROOT_RANK. >> Yes. I agree with that. Root nodes got rank=256. >>> To some degree, absolute ETX values do not matter -- what matters is their relative values. If all DODAG Roots advertise a Rank of 256, corresponding to an ETX of 2, then that's what they advertise, and a route with an computed ETX of 5 involves 3 transmissions within the LLN. >>> >>> I don't think I'm understanding the issue -- could you explain it again? >>> >>> Phil >> I don't agree that root nodes could advertise a ETX=2. >> >> "Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to its preferred parent. It then calculates the metric it will advertise in its metric container. This value is the path cost of the member of the parent set with the highest path cost." >> >> Root nodes have parent set of size zero so they got a cur_min_path_cost=0 so ETX=0. >> >> Because "a node MUST advertise an approximation of its ETX in its advertised Rank value" root nodes must advertise ETX=0. >> I agree with the fact that absolute ETX do not matter but I think that the root advertisement does not match the definition in the MRHOF draft. > Ah, this is a good catch. I'll adjust the text to note this edge case. I chose the word "approximation" carefully there -- but the issues you're pointing out make it clear that the draft should explain what's going on in greater detail. In particular, how would you feel about some text along the lines of > > "RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease. Because all DODAG Roots within a DODAG Version advertise the same Rank, this constant value typically does not affect route selection. Nevertheless, it means that if a DODAG Version has a MinHopRankIncrease of M and a path has an advertised ETX of E, then the actual ETX of the path is likely closer to a value of E-M than a value of E." > > Phil > Ok. I agree with you. I got a question about the PARENT_SET_SIZE. "PARENT_SET_SIZE: The number of candidate parents, including the preferred parent, in the parent set." "candidate parents" = "candidate neighbour" or are different? "A node MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors in its parent set." It's a upper bound? Could a node have more than PARENT_SET_SIZE additional candidate neighbors in its parents set? -- Regards Consoli Federico From pal@cs.stanford.edu Fri Mar 30 09:06:23 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24C321F8670 for ; Fri, 30 Mar 2012 09:06:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9AhvQFOvgR3 for ; Fri, 30 Mar 2012 09:06:23 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2271821F8671 for ; Fri, 30 Mar 2012 09:06:23 -0700 (PDT) Received: from ast-lambert-153-1-157-249.w90-44.abo.wanadoo.fr ([90.44.96.249] helo=[192.168.100.145]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SDeLG-0008Af-Jp; Fri, 30 Mar 2012 09:06:22 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4F759C31.2050306@ipv6it.org> Date: Fri, 30 Mar 2012 18:06:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> <4F74A202.2040206@ipv6it.org> <55B55877-4CF8-444C-9E09-711C6990BC9D@cs.stanford.edu> <4F759C31.2050306@ipv6it.org> To: Federico Consoli X-Mailer: Apple Mail (2.1257) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: Roll@ietf.org Subject: Re: [Roll] MRHOF draft-07 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 16:06:23 -0000 On Mar 30, 2012, at 1:42 PM, Federico Consoli wrote: >=20 > I got a question about the PARENT_SET_SIZE. >=20 > "PARENT_SET_SIZE: The number of candidate parents, including the = preferred parent, in the parent set." > "candidate parents" =3D "candidate neighbour" or are different? RFC 6550, 8.2.1: RPL's Upward route discovery algorithms and processing are in terms of three logical sets of link-local nodes. First, the candidate neighbor set is a subset of the nodes that can be reached via link- local multicast. The selection of this set is implementation and OF dependent. Second, the parent set is a restricted subset of the candidate neighbor set. Finally, the preferred parent is a member of the parent set that is the preferred next hop in Upward routes. Conceptually, the preferred parent is a single parent; although, it may be a set of multiple parents if those parents are equally preferred and have identical Rank. >=20 > "A node MAY include up to PARENT_SET_SIZE-1 additional candidate = neighbors in its parent set." > It's a upper bound? Could a node have more than PARENT_SET_SIZE = additional candidate neighbors in its parents set? Yes: there is no MUST NOT or even a SHOULD NOT. Phil= From pthubert@cisco.com Fri Mar 30 09:41:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B516921F8716 for ; Fri, 30 Mar 2012 09:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3SqEWU-q3K2 for ; Fri, 30 Mar 2012 09:41:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2B21F864B for ; Fri, 30 Mar 2012 09:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4672; q=dns/txt; s=iport; t=1333125718; x=1334335318; h=mime-version:subject:date:message-id:from:to; bh=NSg1hzlkQHTRRZtDQC342WSerPMizR/OraRbQA+nobE=; b=m+4h4Qys+rxig3keYMbL0NoR/1isSEyILiIb5iSgV9RWY/+ycA7VMJFM 9cBQum3fsYO4IM6rOW1qDRePaxQh1hc6NKLqwNslMn37Hdc1BTCWjM4xf dGrKRSa3OgHJ+3td1X03iJ9cKFG1cxZBmmMXE5Heq9hWlAW19NbXBMO4P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFABjidU+Q/khL/2dsb2JhbABFgkatMAGIdIEHggsBBBIBCREDWwEqBhgHVwEEGxqHZwuaJoEnnxeQLWMElnSNNYFogmk X-IronPort-AV: E=Sophos;i="4.75,345,1330905600"; d="scan'208,217";a="133866608" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2012 16:41:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2UGfiqH014399 for ; Fri, 30 Mar 2012 16:41:44 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 18:41:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0E93.FDC1FEA5" Date: Fri, 30 Mar 2012 18:40:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Forwarding (and recovering) Fragments Thread-Index: Ac0Ok79Rb1VmSYl0TeGiSKm82r8o+w== From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 30 Mar 2012 16:41:44.0772 (UTC) FILETIME=[FDFBA040:01CD0E93] Subject: [Roll] Forwarding (and recovering) Fragments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2012 16:41:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0E93.FDC1FEA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: =20 Considering the renewed attention on fragments and fragment forwarding at multiple groups during this IEFT meeting, the authors republished http://tools.ietf.org/html/draft-thubert-roll-forwarding-frags . This was originally proposed at 6LoWPAN but that was probably too early. The times are probably ripe now and since we are dealing with forwarding in LLNs, the area and the WG seem a good match. =20 On the side, I received individual feedback that the bitmap compression mechanism created more complexity than value. I did not remove that text yet but I'd especially appreciate feedback on that part. =20 Cheers, =20 Pascal =20 ------_=_NextPart_001_01CD0E93.FDC1FEA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

Considering the renewed attention on fragments and fragment = forwarding at multiple groups during this IEFT meeting, the authors = republished h= ttp://tools.ietf.org/html/draft-thubert-roll-forwarding-frags =  .

This was originally proposed at 6LoWPAN but that was = probably too early. The times are probably ripe now and since we are = dealing with forwarding in LLNs, the area and the WG seem a good = match.

 

On the side, I received individual feedback that the bitmap = compression mechanism created more complexity than value. I did not = remove that text yet but I’d especially appreciate feedback on = that part.

 

Cheers,

 

Pascal

 

------_=_NextPart_001_01CD0E93.FDC1FEA5-- From prvs=430150c07=mukul@uwm.edu Sat Mar 31 16:41:23 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1859E21F864C for ; Sat, 31 Mar 2012 16:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4xxOL2WP4AW for ; Sat, 31 Mar 2012 16:41:21 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 747E021F8792 for ; Sat, 31 Mar 2012 16:41:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAAaVd09/AAAB/2dsb2JhbABChVS2TSNPBxsaAg0ZAlkGLIdwrRGIKIEhgS+JUQuEeYEYBIhYjQmQL4MFgTYBFg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A62A01FD0B8; Sat, 31 Mar 2012 18:41:20 -0500 (CDT) 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 NocfSnYD+2zl; Sat, 31 Mar 2012 18:41:20 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 14E8F1FD0B7; Sat, 31 Mar 2012 18:41:20 -0500 (CDT) Date: Sat, 31 Mar 2012 18:41:19 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <404086078.1764222.1333237279941.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 Mar 2012 23:41:23 -0000 Hi Pascal Separating each point with "********". Also, I have removed points where you did not have further comments. ******************************************************************* [Pascal] "By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver timecritical application data to the target(s)." If DRO establishes path from origin to target then without a DRO, the target can send to the origin, not the other way around? If so I'd reword like if DRO is not requested, the DAG can only be used unidirectionally to report data from the target(s) to the origin. [Mukul] What I meant was that an origin could use P2P mode DIOs to send time critical data to the target(s) without discovering routes to these targets. Note that the temporary DAG itself cant be used for routing. The target ofcourse would know of a source route back to the origin when it receives a P2P mode DIO. [Pascal2] Makes sense. I think you need to articulate the 2 possible use cases. 1) If you just want to post one datagram to the target(s), what happens, what's the minimum set of information in the DIO? E.g. If no response is expected, you do not need to record a route. [Mukul2] I will add text to the effect that address accumulation need not take place if the Reply flag is zero. I think every thing else stays same. [Pascal2] 2) Same question if you want to create states at the target to route back. How long does the target need to maintain the route? Who controls that, the origin or the target? I'd expect to find a suggested lifetime in the RDO with a confirmation in the DRO to let the target amend it. [Mukul2] If the target wants DRO-ACK it needs to maintain state until DRO-ACK is received. Otherwise, the target needs to remember things until it is done sending all the DROs. I will add the text to this effect. ************************************************************************************* [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal2] Changing the instance ID will help debug the network and avoid conflicts with stale states. What's really up to the device is the initial sequence. Leaving it up to the origin may help the origin defeat some attacks to some degree. OTOH, after all the instances have been played, LRU forces to replay the same sequence again so the shield drops. My preferred approach would be a SHOULD that would say that the next instance ID SHOULD NOT be one of the (16?) most recently used and MUST NOT be one for which states might still exist in the network. IOW either the states deletion was acknowledged, or all pending lifetimes are exhausted. [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes. Using a "MUST NOT" may not be OK since a node may never be 100% sure about non-existence of stale state with a particular instance id (thus, all possible instance id values will become suspect and hence unusable after a while). **************************************************************************************** [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal2] Please revisit RFC 6650 page 12. G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal? If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic. By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0... [Mukul2] When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." ************************************************************************** [Pascal]" A P2P mode DIO: o MUST carry one (and only one) P2P Route Discovery Option (described in Section 7.1). The P2P Route Discovery Option allows for the specification of one unicast or multicast address for the target." Well; I can see how there would be only a target and no RDO, if we have good defaults. [Mukul] Sure, the RPL target option could be used in the manner you described earlier. I don't think a P2P-RPL route discovery can take place without a P2P-RDO. You need P2P-RDO to accumulate the route even if you somehow already knew what kind of route you want to discover etc. [Pascal2] I can see why most of the time in the usage you have in mind the RDO will be there. Need => use is fine with me. But MUSTing the use has the logic backwards and again you are limiting the applicability of your draft. e.g. I read above that you might use DIO to deliver critical data to the target. I have not read that this always implies an ack back. So why store the route? [Mukul2] Indeed the route accumulation is not required when the P2P mode DIO is simply carrying data with no route discovery intended. In that case, the R flag in the P2P-RDO would tell nodes not to do route accumulation. We would still be forming a temporary DAG, hence we need the L field inside the P2P-RDO to tell the nodes about the life time of the temporary DAG. The Compr field would still be useful to elide some bytes from the target address and the MaxRank field could still be used to constrain the temporary DAG. So, P2P-RDO is useful in the particular scenario where P2P-RPL is being used as a pure data delivery mechanism. P2P-RPL is primarily a reactive route discovery protocol that uses trickle-controlled propagation of discovery messages by creating a temporary DAG. By its very nature, its hard for me to imagine P2P-RPL invocation where a P2P mode DIO does not need to carry a P2P-RDO. The kind of flexibility you have in mind is more suitable for the underlying mechanisms - the trickle algorithm and the concept of DAG creation/maintenance. Just my views. ************************************************************************ [Pascal] And I can see how a target could have a different DRO than the next target in the same DIO. So I do not agree with that statement at all. [Mukul] It is certainly possible that you want to discover a source route to one target and a hop-by-hop route to another. But, it seems to me that such flexibility might not be very useful in practice. The common case seems to be that same type of routes need to be discovered for all the targets. Plus, if there are multiple P2P-RDOs in a P2P mode DIO, I will have to create a separate option to do the route accumulation (because I dont want to replicate the accumulated route in all the P2P-RDOs in the DIO). I guess you would like that approach better since it is more modular. But, as I mentioned earlier, home/building world applications have a deep desire to save bytes whereever possible and extra options mean extra overhead in terms of bytes. [Pascal2] BTW typo up there, I meant RDO. It's (slightly too) easy to mix those 2 up... [Mukul2] I know! My co-authors mix up RDO-DRO all the time. But, I would still like to name them the way they are named.:) [Pascal2] And I understand you have to find a trade-off. You have to package together things that have a strong logical relationship. And split things that can be used separately as much as you can afford within practical constraints... Not an easy task. When I look at the RDO, my preferred split is to take the target out and keep the rest in. I have a doubt with regards to the lifetime field though; maybe we could actually move it to the reserved field into the DIO base object. I can see how the usage can be generalized to non P2P yet transient DAGs. That would give you more granularityfro both lifetime and maxrank. [Mukul2]: At the moment, P2P-RPL is the only RPL extension that needs transient DAGs. I guess moving the lifetime to DIO base object would make sense when additional applications/extensions emerge that would benefit from such a move. When that happens, we could define a new version of P2P-RDO. **************************************************************************************** [Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter... [Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree! **************************************************************************************** [Pascal] " When a target receives a P2P mode DIO, it forwards the data in any Data Options to the higher layer." As I hinted, this is not well enough defined. You're really using the DIO as a transport, so you need a minimum transport paradigm like a compressed UDP header. This comment applies to DRO as well, obviously. [Mukul] I am working on this. We could impart more structure to the data option. My fear is that if that particular structure (say a particular way to compress the UDP header) is not convenient to use in a particular deployment, the data option itself becomes useless. Would it be preferable if we simply suggest that the data in the data option be transport layer header+payload without actually enforcing a particular structure? What do you think? [Pascal2] You need to specify at least one field to indicate the "next header". Maybe you could look at how RFC 6282 does it for UDP? As an alternate to UDP, you could define a 'well known, free form' NH for a device that has only one possible consumer for the data. [Mukul2] I like the proposal you make next (3 bits of next header and 5 bits of sequence). ************************************************************************************************ [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb? My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence. [Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. *********************************************************************************************** [Pascal] "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater. But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. [Mukul] All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin. [Pascal2] Then you're preventing a router with 2 interfaces. That's sad. I'm fine for an experimental draft but for standard track that will have to be changed. [Mukul2] OK, I am keeping it the way it is. Regards, Mukul