From joydeep.tripathi@gmail.com Wed Dec 23 16:32:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691A53A659C for ; Wed, 23 Dec 2009 16:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0BvNCb49m9D for ; Wed, 23 Dec 2009 16:32:14 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id A90943A67F1 for ; Wed, 23 Dec 2009 16:32:13 -0800 (PST) Received: by ewy6 with SMTP id 6so5851046ewy.29 for ; Wed, 23 Dec 2009 16:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+RW362Bv6VOSNMSUC3TAnkDCVx7ttqhPMcT30aS8vGw=; b=WxWOMzPux9qVpEd0dG0lV+H7ODFC56HBkSKB+ewCH1/LqWMn14gDPp+xV56sY7/xYk o97lONJwSdwxzx7nEum3XYIfdqEvkxxSjpjb4Ib21bC1Q6J3BxC6u59r84Vz/hH1mzxY hfqrdtsb5qWDYXUJqKDgXmlmZa+c7YjOtH4CA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t2qWILJ0myGZBZd7gR/POVpbL966mxExJwYeMMYBWoM2EkXqsyqYEYzMy9bmGL0O2u dcuk6u9igWo/wb0RwJM9XjbKCwsIQXrHqb/b15bD0J1NMr2fX9REBE0gdIfikQNRGZmK h4WC74mwgF5UGJ7oyWml2GP+lS39YPnGuM/24= MIME-Version: 1.0 Received: by 10.216.89.130 with SMTP id c2mr3794941wef.44.1261614713306; Wed, 23 Dec 2009 16:31:53 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Wed, 23 Dec 2009 19:31:53 -0500 Message-ID: From: Joydeep Tripathi To: Hajime Tazaki Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 04 Jan 2010 09:38:29 -0800 Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 00:35:40 -0000 Hi, For those who cannot find the pdf version, you can click this link http://tools.ietf.org/pdf/draft-tripathi-roll-rpl-simulation-01.pdf Thanks, Joydeep On Wed, Dec 23, 2009 at 7:26 PM, Hajime Tazaki wrot= e: > > Dear authors, > > I also really wanna see the pdf with figures. > > regards, > hajime > > At Tue, 22 Dec 2009 23:09:59 -0800, > Omprakash Gnawali wrote: >> >>It is great to start understanding how RPL would work. >> >>On this file: >>http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 >> >>I don't see the figures... >> >>- om_p >> >>On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira >> wrote: >>> Dear WG, >>> We have just posted draft-tripathi-roll-rpl-simulation-01with a detaile= d >>> performance evaluation of RPL for several metrics of interest (please s= ee >>> PDF file with plots). We are currently working on results with local re= pair >>> and shall post them shortly. We would love feedback/suggestions from th= e WG. >>> Are there other metrics you would like to see? >>> Cheers, >>> Jau. >>> >>> >>> >>> >>> Jaudelice C. de Oliveira >>> Associate Professor >>> ECE Dept.,=A0Drexel University >>> http://www.ece.drexel.edu/faculty/deoliveira/ >>> >>> >>> >>> >>> >>> Begin forwarded message: >>> >>> From: IETF I-D Submission Tool >>> Date: December 21, 2009 10:58:21 PM EST >>> To: jau@ece.drexel.edu >>> Cc: jt369@drexel.edu,jpv@cisco.com >>> Subject: New Version Notification for >>> draft-tripathi-roll-rpl-simulation-01 >>> >>> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has bee= n >>> successfuly submitted by Jaudelice Oliveira and posted to the IETF >>> repository. >>> Filename: draft-tripathi-roll-rpl-simulation >>> Revision: 01 >>> Title: Performance Evaluation of Routing Protocol for Low Power and Los= sy >>> Networks (RPL) >>> Creation_date: 2009-12-21 >>> WG ID: Independent Submission >>> Number_of_pages: 12 >>> Abstract: >>> This document presents a performance evaluation of the Routing >>> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed >>> simulations are carried out to produce several routing performance >>> metrics using a set of real-life scenarios. >>> Status of this Memo >>> This Internet-Draft is submitted to IETF in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF), its areas, and its working groups.=A0 Note that >>> other groups may also distribute working documents as Internet- >>> Drafts. >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time.=A0 It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> The list of current Internet-Drafts can be accessed at >>> http://www.ietf.org/ietf/1id-abstracts.txt. >>> The list of Internet-Draft Shadow Directories can be accessed at >>> http://www.ietf.org/shadow.html. >>> This Internet-Draft will expire on June 24, 2010. >>> Copyright Notice >>> Copyright (c) 2009 IETF Trust and the persons identified as the >>> document authors.=A0 All rights reserved. >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document.=A0 Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document.=A0 Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the BSD License. >>> >>> >>> 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 joydeep.tripathi@gmail.com Wed Dec 23 16:33:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3593A659C for ; Wed, 23 Dec 2009 16:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPDOxYqGieN2 for ; Wed, 23 Dec 2009 16:33:55 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id F2B8C3A67F1 for ; Wed, 23 Dec 2009 16:33:54 -0800 (PST) Received: by ewy6 with SMTP id 6so5851965ewy.29 for ; Wed, 23 Dec 2009 16:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=42GN9Lwf/EwPizNUAyslz4pVXoKtKaPYyWj1X5ByLQw=; b=aU/ySDf/2xAf9FnqWsajrSn3cnN7+JlcRzyj3eNtKWqg+guqqiRSpo2wHNBlhGyiTH 4DYo/t37PXUg6Z05ba5QgGB1xjqy1O4Som9J2wINwyY3/cgiVOmgCTY7S1Emu6WDqH5b m77gVhBIHIrZvETe16ZQBJdzvYxeUvLli9liI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QLM7YwERlE6x51R9MyYXAY65z5OKm86LdbhZPXz9IJ2wQlx3KV05NuSVfD5iPhCo01 eusIUPMz48y3ctiYZeh2bptFtVlKl1gfpBhF5ji2t6/uuPVS2l5IGx0MkcbT5LNzhELf WnAtFACnuxTKDLBAmS4kOiYazYtyVktQiGpe8= MIME-Version: 1.0 Received: by 10.216.89.202 with SMTP id c52mr263458wef.215.1261614813719; Wed, 23 Dec 2009 16:33:33 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Wed, 23 Dec 2009 19:33:33 -0500 Message-ID: From: Joydeep Tripathi To: Omprakash Gnawali , ROLL WG Content-Type: multipart/alternative; boundary=0016e6d64b18d0b0cf047b6e96f4 X-Mailman-Approved-At: Mon, 04 Jan 2010 09:38:29 -0800 Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 00:36:53 -0000 --0016e6d64b18d0b0cf047b6e96f4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali wrote: > I managed to find the pdf with the graphs. Here are some comments. > > It will help greatly if more information about the link model were > included. -01 mentions: > > "* Link failure model: Time varying real network traces containing > packet delivery probability for each > link and over all channels for both indoor network deployment and > outdoor network deployment were used. > Thus, di erent types of link characteristics are used in the study. > * Topology: The topologies are gathered from real-life deployment > (traces mentioned above) as opposed > to random topology simulations. are repeated here:" > Actually,we collected real-life traces with hundreds of links varying with time for the network, and simulated the same variation in PDR for each link as in the real deployment. > Is the simulation topology a topology from real-world deployment or > the one mentioned in figure 1? > It is indeed from a real life deployment of an indoor network, where the topology looks like the one shown in figure 1. We have shown a link between two nodes in the topology if they are heard by each other. > > Some graphs showing link characteristics (including temporal > characteristics) will also be helpful. Right now, we just know that > the link is modeled on real world deployments. What radio was used? > Indoor/outdoor? And any other relevant information. > That is a wonderful idea. We will include temporal link characteristics in further revision which we plan to submit very soon. > > These additional information will help us understand how and why of > RPL's performance. > > A lot of people are interested in path stretch for p2p routing. Some > of this information is available on the plots but not directly. It > will be great if we can have a plot that shows the distribution of > path stretch for p2p routing. > We also plan to show this metric, keeping in mind the typical scenarios of P2P routing in building and home routing (or any other interesting scenario, on request). Once again, thanks for your feedback. Thanks, Joydeep > > - om_p > > On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira > > wrote: > >> Dear WG, > >> We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed > >> performance evaluation of RPL for several metrics of interest (please > see > >> PDF file with plots). We are currently working on results with local > repair > >> and shall post them shortly. We would love feedback/suggestions from the > WG. > >> Are there other metrics you would like to see? > >> Cheers, > >> Jau. > >> > >> > >> > >> > >> Jaudelice C. de Oliveira > >> Associate Professor > >> ECE Dept., Drexel University > >> http://www.ece.drexel.edu/faculty/deoliveira/ > >> > >> > >> > >> > >> > >> Begin forwarded message: > >> > >> From: IETF I-D Submission Tool > >> Date: December 21, 2009 10:58:21 PM EST > >> To: jau@ece.drexel.edu > >> Cc: jt369@drexel.edu,jpv@cisco.com > >> Subject: New Version Notification for > >> draft-tripathi-roll-rpl-simulation-01 > >> > >> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been > >> successfuly submitted by Jaudelice Oliveira and posted to the IETF > >> repository. > >> Filename: draft-tripathi-roll-rpl-simulation > >> Revision: 01 > >> Title: Performance Evaluation of Routing Protocol for Low Power and > Lossy > >> Networks (RPL) > >> Creation_date: 2009-12-21 > >> WG ID: Independent Submission > >> Number_of_pages: 12 > >> Abstract: > >> This document presents a performance evaluation of the Routing > >> Protocol for Low power and Lossy Networks (RPL). Detailed > >> simulations are carried out to produce several routing performance > >> metrics using a set of real-life scenarios. > >> Status of this Memo > >> This Internet-Draft is submitted to IETF in full conformance with the > >> provisions of BCP 78 and BCP 79. > >> Internet-Drafts are working documents of the Internet Engineering > >> Task Force (IETF), its areas, and its working groups. Note that > >> other groups may also distribute working documents as Internet- > >> Drafts. > >> Internet-Drafts are draft documents valid for a maximum of six months > >> and may be updated, replaced, or obsoleted by other documents at any > >> time. It is inappropriate to use Internet-Drafts as reference > >> material or to cite them other than as "work in progress." > >> The list of current Internet-Drafts can be accessed at > >> http://www.ietf.org/ietf/1id-abstracts.txt. > >> The list of Internet-Draft Shadow Directories can be accessed at > >> http://www.ietf.org/shadow.html. > >> This Internet-Draft will expire on June 24, 2010. > >> Copyright Notice > >> Copyright (c) 2009 IETF Trust and the persons identified as the > >> document authors. All rights reserved. > >> This document is subject to BCP 78 and the IETF Trust's Legal > >> Provisions Relating to IETF Documents > >> (http://trustee.ietf.org/license-info) in effect on the date of > >> publication of this document. Please review these documents > >> carefully, as they describe your rights and restrictions with respect > >> to this document. Code Components extracted from this document must > >> include Simplified BSD License text as described in Section 4.e of > >> the Trust Legal Provisions and are provided without warranty as > >> described in the BSD License. > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > >> > > > --0016e6d64b18d0b0cf047b6e96f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 23, 2009 at 2:52 AM, Ompraka= sh Gnawali <gnawali@cs.stanford.edu> wrote:
I managed to find the pdf with the graphs. Here are some comments.

It will help greatly if more information about the link model were
included. -01 mentions:

"* Link failure model: Time varying real network traces containing
packet delivery probability for each
link and over all channels for both indoor network deployment and
outdoor network deployment were used.
Thus, di erent types of link characteristics are used in the study.
* Topology: The topologies are gathered from real-life deployment
(traces mentioned above) as opposed
to random topology simulations. are repeated here:"

Actually,we collected real-life traces with hundreds of links varyin= g with time for the network,=A0 and simulated the same variation in PDR for= each link as in the real deployment.


Is the simulation topology a topology from real-world deployment or
the one mentioned in figure 1?

It is indeed from a= real life deployment of an indoor network, where the topology looks like t= he one shown in figure 1. We have shown a link between two nodes in the top= ology if they are heard by each other.
=A0

Some graphs showing link characteristics (including temporal
characteristics) will also be helpful. Right now, we just know that
the link is modeled on real world deployments. What radio was used?
Indoor/outdoor? And any other relevant information.
That is a wonderful idea. We will include temporal link characteristics i= n further revision which we plan to submit very soon.

These additional information will help us understand how and why of
RPL's performance.

A lot of people are interested in path stretch for p2p routing. Some
of this information is available on the plots but not directly. It
will be great if we can have a plot that shows the distribution of
path stretch for p2p routing.

We also plan to show= this metric, keeping in mind the typical scenarios of P2P routing in build= ing and home routing (or any other interesting scenario, on request). Once = again, thanks for your feedback.

Thanks,
Joydeep

- om_p
=A0
> On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira
> <jau@ece.dr= exel.edu> wrote:
>> Dear WG,
>> We have just posted draft-tripathi-roll-rpl-simulation-01with a de= tailed
>> performance evaluation of RPL for several metrics of interest (ple= ase see
>> PDF file with plots). We are currently working on results with loc= al repair
>> and shall post them shortly. We would love feedback/suggestions fr= om the WG.
>> Are there other metrics you would like to see?
>> Cheers,
>> Jau.
>>
>>
>>
>>
>> Jaudelice C. de Oliveira
>> Associate Professor
>> ECE Dept.,=A0Drexel University
>> http://www.ece.drexel.edu/faculty/deoliveira/
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>> Date: December 21, 2009 10:58:21 PM EST
>> To: jau@ec= e.drexel.edu
>> Cc: jt369@dr= exel.edu,jpv@cisco.c= om
>> Subject: New Version Notification for
>> draft-tripathi-roll-rpl-simulation-01
>>
>> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt ha= s been
>> successfuly submitted by Jaudelice Oliveira and posted to the IETF=
>> repository.
>> Filename: draft-tripathi-roll-rpl-simulation
>> Revision: 01
>> Title: Performance Evaluation of Routing Protocol for Low Power an= d Lossy
>> Networks (RPL)
>> Creation_date: 2009-12-21
>> WG ID: Independent Submission
>> Number_of_pages: 12
>> Abstract:
>> This document presents a performance evaluation of the Routing
>> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed
>> simulations are carried out to produce several routing performance=
>> metrics using a set of real-life scenarios.
>> Status of this Memo
>> This Internet-Draft is submitted to IETF in full conformance with = the
>> provisions of BCP 78 and BCP 79.
>> Internet-Drafts are working documents of the Internet Engineering<= br> >> Task Force (IETF), its areas, and its working groups.=A0 Note that=
>> other groups may also distribute working documents as Internet- >> Drafts.
>> Internet-Drafts are draft documents valid for a maximum of six mon= ths
>> and may be updated, replaced, or obsoleted by other documents at a= ny
>> time.=A0 It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress.&quo= t;
>> The list of current Internet-Drafts can be accessed at
>> http://www.ietf.org/ietf/1id-abstracts.txt.
>> The list of Internet-Draft Shadow Directories can be accessed at >> http= ://www.ietf.org/shadow.html.
>> This Internet-Draft will expire on June 24, 2010.
>> Copyright Notice
>> Copyright (c) 2009 IETF Trust and the persons identified as the >> document authors.=A0 All rights reserved.
>> This document is subject to BCP 78 and the IETF Trust's Legal<= br> >> Provisions Relating to IETF Documents
>> (http://trustee.ietf.org/license-info) in effect on the date of
>> publication of this document.=A0 Please review these documents
>> carefully, as they describe your rights and restrictions with resp= ect
>> to this document.=A0 Code Components extracted from this document = must
>> include Simplified BSD License text as described in Section 4.e of=
>> the Trust Legal Provisions and are provided without warranty as >> described in the BSD License.
>>
>>
>> The IETF Secretariat.
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>

--0016e6d64b18d0b0cf047b6e96f4-- From root@core3.amsl.com Wed Jan 6 01:45:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B5CD33A676A; Wed, 6 Jan 2010 01:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106094501.B5CD33A676A@core3.amsl.com> Date: Wed, 6 Jan 2010 01:45:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 09:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : A. Brandt, J. Buron Filename : draft-ietf-roll-home-routing-reqs-10.txt Pages : 18 Date : 2010-01-06 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-06013442.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Wed Jan 6 05:23:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04D53A68D1; Wed, 6 Jan 2010 05:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y81dMfd4uHlw; Wed, 6 Jan 2010 05:23:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D042B3A685E; Wed, 6 Jan 2010 05:23:39 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEcdREtAZnwN/2dsb2JhbAC+TJNahDAE X-IronPort-AV: E=Sophos;i="4.49,229,1262563200"; d="scan'208";a="78629929" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2010 13:23:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o06DNbrk004315; Wed, 6 Jan 2010 13:23:37 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 14:23:37 +0100 Received: from dhcp-lyon-144-254-54-120.cisco.com ([144.254.54.120]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 14:23:36 +0100 Message-Id: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> From: JP Vasseur To: Jon Smirl In-Reply-To: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 6 Jan 2010 12:39:27 +0100 References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jan 2010 13:23:36.0767 (UTC) FILETIME=[73ED84F0:01CA8ED3] Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 13:23:41 -0000 Hi, On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: > What are the plans for a 6lowapp reference implementation? > > For example there is a 6lowpan implementation in Contiki, but nobody > is updating it to track the current proposals. > Does a ROLL reference implementation exist? The IETF does not produce "reference implementation" but protocol specifications and applicability statement. For ROLL we have plans to work on such documents that will provide guidance on how to use RPL in different environments. Is this what you had in mind ? Thanks. JP. > > -- > Jon Smirl > jonsmirl@gmail.com > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From leila.ben.saad@ens-lyon.fr Wed Jan 6 06:52:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352E53A677C for ; Wed, 6 Jan 2010 06:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6BlQwb8lye3 for ; Wed, 6 Jan 2010 06:52:58 -0800 (PST) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by core3.amsl.com (Postfix) with ESMTP id 5F10A3A6850 for ; Wed, 6 Jan 2010 06:52:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id C3B431EB1F4 for ; Wed, 6 Jan 2010 15:52:56 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn61K12lU4fV for ; Wed, 6 Jan 2010 15:52:55 +0100 (CET) Received: from agrobate-domu-webmail.ens-lyon.fr (agrobate-domu-webmail.ens-lyon.fr [140.77.51.15]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 153611EB20C for ; Wed, 6 Jan 2010 15:52:54 +0100 (CET) Received: by agrobate-domu-webmail.ens-lyon.fr (Postfix, from userid 33) id 004F3581B9; Wed, 6 Jan 2010 15:52:54 +0100 (CET) Received: from dhcp-13-80.lip.ens-lyon.fr (dhcp-13-80.lip.ens-lyon.fr [140.77.13.80]) by webmail.ens-lyon.fr (Horde Framework) with HTTP; Wed, 06 Jan 2010 15:52:54 +0100 Message-ID: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> Date: Wed, 06 Jan 2010 15:52:54 +0100 From: Leila Ben Saad To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 Subject: [Roll] Nodes Mobility Support in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:52:59 -0000 Dear WG, Is RPL able to support the mobility of DAG roots ? Because if we move DAG roots frequently, the topology will be modified, new DODAGS must be constructed, more DIO messages will be sent which can can diminish the energy of nodes and limit their lifetime. Has RPL been already evaluated in network with mobile nodes ? Thanks, Leila Ben Saad PhD Student ENS Lyon France From richard.kelsey@ember.com Wed Jan 6 07:03:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8DB3A6887 for ; Wed, 6 Jan 2010 07:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CneLgYNcEV4H for ; Wed, 6 Jan 2010 07:03:15 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A1E443A659B for ; Wed, 6 Jan 2010 07:03:15 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 10:05:18 -0500 Date: Wed, 06 Jan 2010 09:59:12 -0500 Message-Id: <871vi32san.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <3C0BFC81-8F24-49B1-9804-9BD51201D180@cs.stanford.edu> (message from Philip Levis on Tue, 29 Dec 2009 12:06:44 -0800) From: Richard Kelsey References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> <87hbrju07x.fsf@kelsey-ws.hq.ember.com> <3C0BFC81-8F24-49B1-9804-9BD51201D180@cs.stanford.edu> X-OriginalArrivalTime: 06 Jan 2010 15:05:18.0594 (UTC) FILETIME=[A8E66E20:01CA8EE1] Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:03:17 -0000 Phil, > From: Philip Levis > Date: Tue, 29 Dec 2009 12:06:44 -0800 > > Richard -- I agree with your analysis of Rank. Right now it seems to > be a bit vague, and operating under the assumption that we'll figure > it out later. It is a mix of a logical property for loop avoidance and > a route quality property. It should be clearly one or the other. For additive metrics like ETX there is no need for separate rank and metric values. The metric on its own is sufficient for loop avoidance. > At > the very least, if we follow the current hybrid approach, there need > to be constraints on how much Rank can increment on each hop, and this > value needs to be considered in the field width. For example, with OF0 > it's a bit strange that two neighbors, both of whom have a hopcount of > 2, can have Ranks of 2 and 32. I'm also a bit worried as to how Rank > will translate from highly variable metrics such as latency, or > decreasing metrics, such as a throughput. Latency, being additive, works fine for loop avoidance on its own. As for throughput, I would think that any DAG would require some additive metric in addition to throughput, in order to prefer shorter paths over longer ones with the same throughput. > These are the kinds of things we should be discussing and resolving > with respect to the draft. Before we start adding additional > mechanisms for optimization, we need to make sure the existing ones > are sound and effective. Not to mention being understood. As things stand now, for additive metrics like ETX the rank is unnecessary and for non-additive metrics like throughput its usage and effects are unclear. > It seems to me that RPL would be much simpler if there were a strong > division between Rank and metric, with the former being used for loop > avoidance and detection and the latter being used for route > optimization. I don't think that is possible with a single, fixed-width rank field. Dynamic Source Routing would work, but that would require keeping the entire path in the DIOs. -Richard Kelsey From emmanuel.baccelli@gmail.com Wed Jan 6 07:11:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3193A67D9 for ; Wed, 6 Jan 2010 07:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHmDvI7XqGqN for ; Wed, 6 Jan 2010 07:11:08 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 2C2543A63C9 for ; Wed, 6 Jan 2010 07:11:08 -0800 (PST) Received: by ewy6 with SMTP id 6so16555465ewy.29 for ; Wed, 06 Jan 2010 07:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=y03ocFd2l2k7TwXvO2s8VAO1SwuVUqflP4wMFkChxMY=; b=PuW9T9lAvD22VWwpcPJr0nLj+OQYlqqQQEeLcPt1t8NeOKn1d6iZ34KflsiOdScaK2 aP36j2wBMfrI0iTUipZG07U10SmZ1/Xmlmoit7pGNal0WdvBKC9XQBEVO/SAz+TfqdX1 D94qJ1aUecn+CeVupno3mq+jmNtmqLl1bv4cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=T/3T4pGtqqL/V9ExwWMUnRyfS880/T2LDmV4+oRnUMbc+2l/OhurzeiE2dnLwBfJN1 +0JNbjbQE9ksW44s9qMMCDEPL7l0LDh3mZvmADZStEjvclytSR7PQNTxYO+t8CU/1idH Njyyy6QxOTIenXXpWv81hX5C2AJP0LmSiACMY= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.99.207 with SMTP id v15mr13369013ebn.73.1262790662879; Wed, 06 Jan 2010 07:11:02 -0800 (PST) In-Reply-To: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> References: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> From: Emmanuel Baccelli Date: Wed, 6 Jan 2010 16:10:42 +0100 X-Google-Sender-Auth: 0e56d59074ecc2c9 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=00504502d374e2f972047c805c61 Subject: Re: [Roll] Nodes Mobility Support in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:11:09 -0000 --00504502d374e2f972047c805c61 Content-Type: text/plain; charset=ISO-8859-1 Hi Leila, basically RPL targets sensor where nodes basically do not move relatively to one another. So in that sense, the answer to your question is: not really ;) cheers, Emmanuel On Wed, Jan 6, 2010 at 3:52 PM, Leila Ben Saad wrote: > Dear WG, > > Is RPL able to support the mobility of DAG roots ? Because if we move DAG > roots frequently, the topology will be modified, new DODAGS must be > constructed, more DIO messages will be sent which can can diminish the > energy of nodes and limit their lifetime. > > Has RPL been already evaluated in network with mobile nodes ? > > Thanks, > > Leila Ben Saad > PhD Student > ENS Lyon France > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00504502d374e2f972047c805c61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Leila,

basically RPL targets sensor where nodes basic= ally do not move relatively to one another. So in that sense, the answer to= your question is: not really ;)

cheers,

Emmanuel


On Wed= , Jan 6, 2010 at 3:52 PM, Leila Ben Saad <leila.ben.saad@ens-lyon.fr>= wrote:
Dear WG,

Is RPL able to support the mobility of DAG roots ? Because if we move DAG r= oots frequently, the topology will be modified, new DODAGS must be construc= ted, more DIO messages will be sent which can can diminish the energy of no= des and limit their lifetime.

Has RPL been already evaluated in network with mobile nodes ?

Thanks,

Leila Ben Saad
PhD Student
ENS Lyon France




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

--00504502d374e2f972047c805c61-- From jonsmirl@gmail.com Wed Jan 6 07:44:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25AA63A67AE; Wed, 6 Jan 2010 07:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DAgqJT1ShFF; Wed, 6 Jan 2010 07:44:05 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 627363A63C9; Wed, 6 Jan 2010 07:44:05 -0800 (PST) Received: by pxi16 with SMTP id 16so3504776pxi.29 for ; Wed, 06 Jan 2010 07:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oxJZtZFczbZToM33sCY6MPOoqca0fcKx9WpyHptm65c=; b=qhNhEcImm67LRLtOcGVz0B9O555bd1+9DYYhN+7qQbJuxutTHuHOmA2/NTIFh56Vmg STA23l1yIF55dp99ypcItK9zD5PV39w0eI3xGdp1iExlrC55ImmLpyaHnv1QyhrPaS1h hcCdvuFTb467Aocs88G8p5mST+pQPKLcUgkt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UNYbawvpaGhEUUyl2HIskjutDnCGLizIh2AYeJn5t99x4ZEV+MflqYwOotkL5EYgCV 7KITxPseREavYmO2qjS54HlizBH6UoA61aXEYdJtOxNa6/nmrYdLf/hlasXWr7PN1GqU fZA62VkTpNPSNk3blSRuaJdVMbG+g5MaXG/rg= MIME-Version: 1.0 Received: by 10.143.20.39 with SMTP id x39mr16513020wfi.213.1262792641431; Wed, 06 Jan 2010 07:44:01 -0800 (PST) In-Reply-To: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> Date: Wed, 6 Jan 2010 10:44:01 -0500 Message-ID: <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> From: Jon Smirl To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 15:44:06 -0000 On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: > Hi, > > On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: > >> What are the plans for a 6lowapp reference implementation? >> >> For example there is a 6lowpan implementation in Contiki, but nobody >> is updating it to track the current proposals. >> Does a ROLL reference implementation exist? > > The IETF does not produce "reference implementation" but protocol > specifications and applicability statement. For ROLL we have plans to > work on such documents that will provide guidance on how to use > RPL in different environments. Is this what you had in mind ? Standards often have problem with specifying behavior in mainstream cases and leaving the corner cases ambiguous. Nobody knows about these corner case problems until some kind of interop event occurs. Another method for achieving conforming standards implementations is to produce an open source implementation of the spec that everyone can use and contribute to. Then all of the people with private implementations can test against the public one. Since the reference code base was produced as a joint effort from all people involved it becomes the arbiter for behavior in the corner cases. > > Thanks. > > JP. > >> >> -- >> Jon Smirl >> jonsmirl@gmail.com >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > -- Jon Smirl jonsmirl@gmail.com From mcr@sandelman.ca Wed Jan 6 07:49:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9563D3A6812 for ; Wed, 6 Jan 2010 07:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2OOZ0uMR37B for ; Wed, 6 Jan 2010 07:49:22 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9C9A33A6809 for ; Wed, 6 Jan 2010 07:49:22 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 1DF5934327 for ; Wed, 6 Jan 2010 10:40:46 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4D36C4E778 for ; Wed, 6 Jan 2010 10:49:19 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 06 Jan 2010 10:49:18 -0500 Message-ID: <10100.1262792958@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] RPL router nodes and multiple prefixes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 15:49:23 -0000 At some point it was suggested that there would be subsystems of multiple nodes where one node would run RPL, and the others nodes would be tethered in some way to that node. (For instance, a residential house participating in a neighbourhood DAG, where the systems inside the house are wired. Or all the actuators and sensors components on a large machine...) That is, not every system in a DAG needed to run RPL, as long as they had good connectivity to one that did. I was thinking about this the other day, and forgot about the wired part of this initially, and was thinking about a situation where one node would run RPL (with a single radio for instance, but multiple antenna), such that the other nodes would need to hear RAs from some place, and need to be given addresses. I worried that the RAs from the node would be heard by the other RPL nodes, and then thought that this might not work. Well, it does, if you have a wired interface, or multiple radios and the RPL node acts as bridge, and the bridge can therefore filter traffic a bit. It's not clear to me that this works well if "local" traffic can leak. But, if you have multiple interfaces, you might also do L3 routing instead. Do people imagine this? Is it reasonable to use DHCPv6-PD to number that interface? I think that it is not a problem for the DIO to contain those prefixes... -- ] 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 jvasseur@cisco.com Wed Jan 6 10:14:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449EB3A693A; Wed, 6 Jan 2010 10:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOCjcAzmYySU; Wed, 6 Jan 2010 10:14:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B24763A6937; Wed, 6 Jan 2010 10:14:29 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADliREtAZnwM/2dsb2JhbAC/DZNghDAE X-IronPort-AV: E=Sophos;i="4.49,230,1262563200"; d="scan'208";a="78583601" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2010 18:14:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o06IEL9V011172; Wed, 6 Jan 2010 18:14:27 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 19:14:21 +0100 Received: from dhcp-lyon-144-254-54-120.cisco.com ([144.254.54.120]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 19:14:20 +0100 Message-Id: <21BFCBB5-1497-4FF9-9653-65170EE1D281@cisco.com> From: JP Vasseur To: Jorge Amodio In-Reply-To: <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 6 Jan 2010 19:14:18 +0100 References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jan 2010 18:14:20.0851 (UTC) FILETIME=[11698030:01CA8EFC] Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 18:14:31 -0000 On Jan 6, 2010, at 5:19 PM, Jorge Amodio wrote: >>> What are the plans for a 6lowapp reference implementation? >>> >>> For example there is a 6lowpan implementation in Contiki, but nobody >>> is updating it to track the current proposals. >>> Does a ROLL reference implementation exist? >> >> The IETF does not produce "reference implementation" but protocol >> specifications and applicability statement. For ROLL we have plans to >> work on such documents that will provide guidance on how to use >> RPL in different environments. Is this what you had in mind ? > > Yes you are right the IETF does not produce "reference implementation" > but the original question I believe was not directed to the IETF but > to the individuals interested in 6LoWPAN (I'm one among them) and as > you probably know there is an old standing and still current mantra > clearly expressed for years in the Tao of IETF (RFC4677): > > ""We reject kings, presidents and voting. We believe in rough > consensus and running code" > > So no harm, and nothing wrong for somebody to ask for "running > code" ... Oh we're strongly agreeing here, I was trying to understand what you were requesting, that's all. > > On the other hand, while the formal specification of a protocol can be > expressed in a RFC, there is nothing better than pseudo-code or > running code to clearly show how the protocol should be or must be > implemented. But still ... could you tell us what you would like to get ? Thanks. JP. > > My .02 > Regards > Jorge From pal@cs.stanford.edu Wed Jan 6 12:49:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4921E3A6938; Wed, 6 Jan 2010 12:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fge+nti7eF0i; Wed, 6 Jan 2010 12:49:04 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 983EF3A689F; Wed, 6 Jan 2010 12:49:04 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NScoQ-0004eS-UF; Wed, 06 Jan 2010 12:49:03 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> Date: Wed, 6 Jan 2010 12:49:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> To: Jon Smirl X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 20:49:05 -0000 On Jan 6, 2010, at 7:44 AM, Jon Smirl wrote: > On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: >> Hi, >>=20 >> On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: >>=20 >>> What are the plans for a 6lowapp reference implementation? >>>=20 >>> For example there is a 6lowpan implementation in Contiki, but nobody >>> is updating it to track the current proposals. >>> Does a ROLL reference implementation exist? >>=20 >> The IETF does not produce "reference implementation" but protocol >> specifications and applicability statement. For ROLL we have plans to >> work on such documents that will provide guidance on how to use >> RPL in different environments. Is this what you had in mind ? >=20 > Standards often have problem with specifying behavior in mainstream > cases and leaving the corner cases ambiguous. Nobody knows about these > corner case problems until some kind of interop event occurs. Another > method for achieving conforming standards implementations is to > produce an open source implementation of the spec that everyone can > use and contribute to. Then all of the people with private > implementations can test against the public one. Since the reference > code base was produced as a joint effort from all people involved it > becomes the arbiter for behavior in the corner cases. Well, that sounds like an excellent reason for you to go implement it! = :) There's an open-source implementation in TinyOS. It's currently behind = the drafts, but that's going to change in the next month or so. Phil= From jonsmirl@gmail.com Wed Jan 6 16:54:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C368E3A6960; Wed, 6 Jan 2010 16:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dghnu4rNlYdW; Wed, 6 Jan 2010 16:54:46 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id D9E173A695F; Wed, 6 Jan 2010 16:54:46 -0800 (PST) Received: by pwi20 with SMTP id 20so12464523pwi.29 for ; Wed, 06 Jan 2010 16:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NP9IT6Jv/mkp7coSlraYdfIIO/kOJWWZym43KhCsW0Y=; b=H53GNXOZV1nJSgsRhdCY0/kabRnkhFQD4WdUltKHcsLTzzKmcAWhDjfDvMcEzlbvsn BZTK3groFiaQ/BfKpkFmaYNEPo3Lk4bJU2vKfC6b07FmB4iI4fxwuHf66Bf9xRg7ybs8 gVkR9Et/NcxaiuoXGgy7aBGTS0uzRaWjke5aA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VaU6nwCa1zlHCx4+m/d2ccSzcQnKv1iWWiHvr+3XSUeBDscpb9CqQ++z1HsAOdFXwb GbKXfZpob+aPjKKplixm2i8suDS62YdKR2HScY/bbTZdFEYYZftprJ9FjRavSke5HKgR JF0gLqAs2r1FWefadesdwBgTwaTXUWh8v9BOM= MIME-Version: 1.0 Received: by 10.143.20.37 with SMTP id x37mr3511618wfi.208.1262825682732; Wed, 06 Jan 2010 16:54:42 -0800 (PST) In-Reply-To: <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> <9e4733911001060744p2c9cd27bm473eafb775fcbf39@mail.gmail.com> <8A858A30-14AC-4F78-B1ED-4004328F831D@cs.stanford.edu> Date: Wed, 6 Jan 2010 19:54:42 -0500 Message-ID: <9e4733911001061654s5a11d327vd997062820999804@mail.gmail.com> From: Jon Smirl To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Jan 2010 00:54:47 -0000 On Wed, Jan 6, 2010 at 3:49 PM, Philip Levis wrote: > > On Jan 6, 2010, at 7:44 AM, Jon Smirl wrote: > >> On Wed, Jan 6, 2010 at 6:39 AM, JP Vasseur wrote: >>> Hi, >>> >>> On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote: >>> >>>> What are the plans for a 6lowapp reference implementation? >>>> >>>> For example there is a 6lowpan implementation in Contiki, but nobody >>>> is updating it to track the current proposals. >>>> Does a ROLL reference implementation exist? >>> >>> The IETF does not produce "reference implementation" but protocol >>> specifications and applicability statement. For ROLL we have plans to >>> work on such documents that will provide guidance on how to use >>> RPL in different environments. Is this what you had in mind ? >> >> Standards often have problem with specifying behavior in mainstream >> cases and leaving the corner cases ambiguous. Nobody knows about these >> corner case problems until some kind of interop event occurs. =A0Another >> method for achieving conforming standards implementations is to >> produce an open source implementation of the spec that everyone can >> use and contribute to. =A0Then all of the people with private >> implementations can test against the public one. Since the reference >> code base was produced as a joint effort from all people involved it >> becomes the arbiter for behavior in the corner cases. > > Well, that sounds like an excellent reason for you to go implement it! :) I've already released open source support for IPv6 with 6lowpan on the mc13224. I have used it to implement a web server. It is based on the Atmel Raven support already in Contiki. I'm also working on serial support for the mc13224 to get it working with the internal Linux 802.15.4 implementation by Seimens. > > There's an open-source implementation in TinyOS. It's currently behind th= e drafts, but that's going to change in the next month or so. I'll check it out. Maybe I can move my mc13224 radio driver into TinyOS or pull the ROLL code into Contiki. Working together on BSD licensed code means everyone can pull it back into their proprietary products if they choose. The BSD code could also be pulled into the Linux kernel, but not the other way. > > Phil --=20 Jon Smirl jonsmirl@gmail.com From jmamodio@gmail.com Wed Jan 6 08:19:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5843A688C; Wed, 6 Jan 2010 08:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AJxXVa0O++B; Wed, 6 Jan 2010 08:19:19 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id B7E1F3A684F; Wed, 6 Jan 2010 08:19:18 -0800 (PST) Received: by pwi20 with SMTP id 20so12086095pwi.29 for ; Wed, 06 Jan 2010 08:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vyAzoQIJ1WRt8mrXp+GIbWDy/4XxGpmUCRKeM23IQhI=; b=GVQMReC+kO6c0/ONKQXS5SZcos5go3Yu0lz4NXwys9uuPcESu683RamQ7slbeu+1tq ZRSizYqLVxN7v7Y9xy44pweO5JDAiAuoOxT3tpvYliX3eVnoE8KBiY6kJg+XVo0zukWP 7+kIdZ5PtS/2teLD3C4KyAj9BfGZK7rmSPgWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AEna4aAadhflj0+7orNtmZ9+CeyYRG1Wrdsv+KXSuxtLxsoCdZH+RqiB+AmPUEBvcT QGWrMqWdFXuPjKab3oJSH6Dxyw8me3ByzKLsVRM3ogLr7udBjcJxLiXtN1USl8skbNx3 hWQO7cnWyJ4bSih7w63B/c6wQvfEi99dnl6sc= MIME-Version: 1.0 Received: by 10.142.6.1 with SMTP id 1mr15435308wff.224.1262794752713; Wed, 06 Jan 2010 08:19:12 -0800 (PST) In-Reply-To: <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> References: <9e4733910912300911m513f7826uc29d2b6e2abc132e@mail.gmail.com> <5B8E5879-683D-448F-9DD1-4278B7047B38@cisco.com> Date: Wed, 6 Jan 2010 10:19:12 -0600 Message-ID: <202705b1001060819t3ef909a4sf86a405d6b996152@mail.gmail.com> From: Jorge Amodio To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 07 Jan 2010 08:41:30 -0800 Cc: ROLL WG , 6lowapp@ietf.org Subject: Re: [Roll] [6lowapp] Reference implementation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Jan 2010 16:19:19 -0000 >> What are the plans for a 6lowapp reference implementation? >> >> For example there is a 6lowpan implementation in Contiki, but nobody >> is updating it to track the current proposals. >> Does a ROLL reference implementation exist? > > The IETF does not produce "reference implementation" but protocol > specifications and applicability statement. For ROLL we have plans to > work on such documents that will provide guidance on how to use > RPL in different environments. Is this what you had in mind ? Yes you are right the IETF does not produce "reference implementation" but the original question I believe was not directed to the IETF but to the individuals interested in 6LoWPAN (I'm one among them) and as you probably know there is an old standing and still current mantra clearly expressed for years in the Tao of IETF (RFC4677): ""We reject kings, presidents and voting. We believe in rough consensus and running code" So no harm, and nothing wrong for somebody to ask for "running code" ... On the other hand, while the formal specification of a protocol can be expressed in a RFC, there is nothing better than pseudo-code or running code to clearly show how the protocol should be or must be implemented. My .02 Regards Jorge From adam@sics.se Sat Jan 9 01:54:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F623A6970; Sat, 9 Jan 2010 01:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMAUD-fCRwXG; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id B98373A67E4; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from [10.1.1.90] (unknown [10.1.1.90]) by letter.sics.se (Postfix) with ESMTPS id 831F140328; Sat, 9 Jan 2010 10:54:54 +0100 (CET) Message-ID: <4B485117.3090004@sics.se> Date: Sat, 09 Jan 2010 10:49:11 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org, 6lowpan <6lowpan@ietf.org>, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] CFP HotEmNets 2010 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 09:54:59 -0000 HotEMNETS 2010 6th Workshop on Hot Topics in Embedded Networked Sensors June 28-29, 2010 http://www.hotemnets2010.org/ Call for Papers Important Dates * Papers Due: February 22, 2010 * Notification: April 15, 2010 * Camera Ready: May 10, 2010 * Conference: June 28-29, 2010 The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. HotEmNets 2010 will by invitation only. Authors of accepted papers, TPC and SC members as well as other distinguished members of the community will be invited to enable a focused and productive discussion. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Submission Guidelines: Papers should be submitted in Adobe PDF format. No longer than five pages in US letter or A4 paper size Two column formatting. One-inch margins on all sides. Minimum 10-point font size (smaller fonts are acceptable for footnotes, references, and figure captions). Organizing Committee General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From joydeep.tripathi@gmail.com Tue Jan 12 10:13:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C4C3A68FA for ; Tue, 12 Jan 2010 10:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKPNCEnh5Oq5 for ; Tue, 12 Jan 2010 10:13:29 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9B8CF3A67FD for ; Tue, 12 Jan 2010 10:13:28 -0800 (PST) Received: by bwz23 with SMTP id 23so15026783bwz.29 for ; Tue, 12 Jan 2010 10:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=e87Y6u6Scrd5263hIuq93xjx7Epy539chJd4Y7jQQNM=; b=fcvo3vxlnsrKvoJXpQWJyDLlsF9gKIU82Y/je1zwUZwcj/JDGzLk/Mc8kInDwY6r3Q 52QG1U0/V7q6Bpvwz1YZ3SJAAvbvVssdhx/tizifUVdv22yILONP5+B5gzQHPFRZNuKb feJ4uAMYpH8SNhMCnJLJ5iBAGBpStVOwqqcJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=MR2hlQ2fjyJ4PCF+9esrtYT2UcxuryvDiayKIU7Uc2ZkIdt3l5+vL9BrfOx1IQKwf5 9sfjlq0Mv90ZiV3j7EHN0QaqLS9LZVgGUkVbQ6ZTiS079dh/k2u+OzXwvmrhPSQDk13L Onrs9KPvi0I8XFW4NBLscytOyurWcVAwLuEy0= MIME-Version: 1.0 Received: by 10.204.154.219 with SMTP id p27mr4935324bkw.115.1263320001504; Tue, 12 Jan 2010 10:13:21 -0800 (PST) In-Reply-To: References: <85789f858ecd.858ecd85789f@drexel.edu> Date: Tue, 12 Jan 2010 13:13:21 -0500 Message-ID: From: Joydeep Tripathi To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Jan 2010 18:13:30 -0000 Dear WG, We have just posted draft-tripathi-roll-rpl-simulation-02 with performance evaluation of RPL for several metrics of interest (please see PDF file with plots), this time Local Repair mechanism (poisoning the sub-DAG) added. We also shown a sample link PDR variation over time from the gathered trace. We would love feedback/suggestions from the WG. Are there other metrics you would like to see? Regards, Joydeep. P.S. I already posted this twice , but for some reason it did not get through the mailing list. ---------- Forwarded message ---------- From: Joydeep Tripathi Date: Fri, Jan 1, 2010 at 10:06 PM Subject: Fwd: New Version Notification for draft-tripathi-roll-rpl-simulati= on-02 To: ROLL WG Cc: Jaudelice de Oliveira , JP Vasseur Dear WG, We have just posted draft-tripathi-roll-rpl-simulation-02 with performance evaluation of RPL for several metrics of interest (please see PDF file with plots), this time Local Repair mechanism (poisoning the sub-DAG) added. We also shown a sample link PDR variation over time from the gathered trace. We would love feedback/suggestions from the WG. Are there other metrics you would like to see? Regards, Joydeep. ---------- Forwarded message ---------- From: Joydeep Tripathi Date: Fri, Jan 1, 2010 at 10:03 PM Subject: Fwd: New Version Notification for draft-tripathi-roll-rpl-simulati= on-02 To: joydeep.tripathi@gmail.com ---------- Forwarded message ---------- From:=A0IETF I-D Submission Tool To:=A0jt369@drexel.edu Date:=A0Fri, 01 Jan 2010 19:02:21 -0800 (PST) Subject:=A0New Version Notification for draft-tripathi-roll-rpl-simulation-= 02 A new version of I-D, draft-tripathi-roll-rpl-simulation-02.txt has been successfuly submitted by Joydeep Tripathi and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-tripathi-roll-rpl-simulation Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Performance Evaluation of Routing Protocol for L= ow Power and Lossy Networks (RPL) Creation_date: =A0 2009-12-31 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 12 Abstract: This document presents a performance evaluation of the Routing Protocol for Low power and Lossy Networks (RPL). =A0Detailed simulations are carried out to produce several routing performance metrics using a set of real-life scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. =A0Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. =A0It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. =A0All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. =A0Please review these documents carefully, as they describe your rights and restrictions with respect to this document. =A0Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. From joydeep.tripathi@gmail.com Wed Jan 13 00:24:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA7F28C10F for ; Wed, 13 Jan 2010 00:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t3GWI6a9cgF for ; Wed, 13 Jan 2010 00:24:43 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 96A2328C10B for ; Wed, 13 Jan 2010 00:24:43 -0800 (PST) Received: by bwz23 with SMTP id 23so15429352bwz.29 for ; Wed, 13 Jan 2010 00:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=eqysrEo7QI0GkDGxyHvta+DAmLfnmIk++hpVVj+bcz4=; b=L9qBAQXKjUU/dIXMwCKXK640jDUC26KiIkB29nJU0Ir8squcqxaRrOnERtCOVtAViS 4JG0AB/eV495O5MSL4f6ZiokuAdagmw9y6esXkL6QQbigmmAkrypvs5yjRyynoHTgkAd VSj/Y54SK25cWDO0jqVan6yCa29F2z1XWnQv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Cm47QSgZelLxvFQWpnt/z1wTi/0LXu9pZFEeNhtl1cMw7aS7cwxeTjddjcE9yBQ50z xHmk8m2ntYtjjYGWVgkPKK5fvQsHza0mccd07zhqj3i9W18UuutuQKql+we+CeCOANHO 8ySn9dD7Q0DfOC/dRMR4ZY2OWnJGAeLz2FAFI= MIME-Version: 1.0 Received: by 10.204.136.150 with SMTP id r22mr5084089bkt.109.1263371076145; Wed, 13 Jan 2010 00:24:36 -0800 (PST) Date: Wed, 13 Jan 2010 03:24:36 -0500 Message-ID: From: Joydeep Tripathi To: Jerald.P.Martocci@jci.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Jan 2010 08:24:44 -0000 Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep From mdurvy@cisco.com Wed Jan 13 00:57:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC833A68E9 for ; Wed, 13 Jan 2010 00:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.178 X-Spam-Level: X-Spam-Status: No, score=-9.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utjdWJ8KEAMr for ; Wed, 13 Jan 2010 00:57:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DDDF13A685A for ; Wed, 13 Jan 2010 00:57:47 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAKoZTUtAZnwN/2dsb2JhbACCFRq+R5RMAoQuBA X-IronPort-AV: E=Sophos;i="4.49,267,1262563200"; d="gif'147?p7s'147?scan'147,208,217,147";a="79803118" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2010 08:57:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0D8vgxM024233 for ; Wed, 13 Jan 2010 08:57:44 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 09:57:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jan 2010 09:57:41 +0100 Content-Type: multipart/signed; boundary="----=_NextPart_000_00D1_01CA9436.D884B100"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE011B676D@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on OCP format Thread-Index: AcqULnat+uYtXtoGRvaoTCcqVFLbtw== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 13 Jan 2010 08:57:42.0464 (UTC) FILETIME=[77505400:01CA942E] Subject: [Roll] Clarification on OCP format X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 08:57:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D1_01CA9436.D884B100 Content-Type: multipart/related; boundary="----=_NextPart_001_00D2_01CA9436.D884B100" ------=_NextPart_001_00D2_01CA9436.D884B100 Content-Type: multipart/alternative; boundary="----=_NextPart_002_00D3_01CA9436.D884B100" ------=_NextPart_002_00D3_01CA9436.D884B100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 It is not clear in the drafts whether the OCP is a DIO suboption or = whether it is contained in the DAG Metric Container.=20 =20 DIO suboption (as mentioned in Section 6 of the metric draft): " The OCP object is used to specify the OF and is carried as a sub- option within the DIO Base Option object defined in [I-D.ietf-roll-rpl ]." DAG Metric Container (as mentioned in the RPL draft Section 6.1.3.1.1.4 = and Section 2 of the metric draft): " The DAG Metric Container MUST include the value for the DAG Objective Code Point." " Note that the routing metric objects defined in this document can appear in any order in the DAG Metric Container object with the exception of the Objective Function object that MUST appear first" =20 I have no strong preference. Maybe the later makes more sense, since = without the values of the metrics and constraints the OCP is pretty useless. =20 Best, Mathilde =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print. = Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message.=09 =20 ------=_NextPart_002_00D3_01CA9436.D884B100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = All,
 
It is not clear = in the=20 drafts whether the OCP is a = DIO=20 suboption or whether it is contained in the DAG Metric Container.
 
DIO suboption (as = mentioned in Section=20 6 of the metric draft):
" The OCP object is used to specify the OF = and is=20 carried as a sub-
   option within the DIO Base Option = object=20 defined in
   [I-D.ietf-roll-rpl]."
DAG Metric Container (as mentioned in the RPL = draft=20 Section 6.1.3.1.1.4 and Section 2 of the metric=20 draft):
" The DAG=20 Metric Container MUST include the value for the DAG = Objective
  =20 Code Point."
" Note that the routing metric objects = defined in this=20 document can
   appear in any order in the DAG Metric = Container=20 object with the
   exception of the Objective Function = object that=20 MUST appear first"
 
I have no strong preference. Maybe the later = makes more=20 sense, since without the values of the metrics and constraints the OCP = is pretty=20 useless.
 
Best,
Mathilde
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

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

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

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------=_NextPart_002_00D3_01CA9436.D884B100-- ------=_NextPart_001_00D2_01CA9436.D884B100 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_00D2_01CA9436.D884B100 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_00D2_01CA9436.D884B100-- ------=_NextPart_000_00D1_01CA9436.D884B100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDExMzA4NTc0MVowIwYJKoZI hvcNAQkEMRYEFCvLUFRcAbbfOSz/eBm+Mu95FuxRMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAV2jn Mtj3fWFamGnU3h83bKSNhoUlTFVdx2lMC1b5QGXp1Q10B4WOaBC0E4PT2ISMCyT8IwzZchCbp8Te +vHrjxWXzjnKzaSjiGRwJ+MK0JzuP8NRMhRA0SnLdfGYctVPb4pm43qKxLpE5+MWUXen/c0SkO9Y b1gBvMiEQGkVwtUAAAAAAAA= ------=_NextPart_000_00D1_01CA9436.D884B100-- From alexandru.petrescu@gmail.com Wed Jan 13 06:00:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BDD28C110 for ; Wed, 13 Jan 2010 06:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFh2lPTtK8LN for ; Wed, 13 Jan 2010 06:00:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C1C8728C139 for ; Wed, 13 Jan 2010 06:00:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0DE0EVf007928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Jan 2010 15:00:14 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0DE0E8Z030603 for ; Wed, 13 Jan 2010 15:00:14 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0DE0D9j024034 for ; Wed, 13 Jan 2010 15:00:14 +0100 Message-ID: <4B4DD1ED.2060800@gmail.com> Date: Wed, 13 Jan 2010 15:00:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: roll@ietf.org References: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> In-Reply-To: <20100106155254.118778x52ubhsqti@webmail.ens-lyon.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Nodes Mobility Support in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 14:00:22 -0000 As a pre-requisite, I would consider looking at the RoLL requirements documents and search for 'mobil' and find some use cases which were used as motivators for RoLL. But during the subsequent RoLL work, the mobility aspects were not hugely important. Le 06/01/2010 15:52, Leila Ben Saad a écrit : > Dear WG, > > Is RPL able to support the mobility of DAG roots ? Well I guess DAG roots could move around a little bit and stay within the link-layer's reachability range (e.g. 10meters). If this is considered 'mobility' then automatically RPL does support it I believe. On another hand, if we consider 'mobility' to involve a change of the address assigned to a node then I don't think RPL has much support for it. I am not sure this is needed either in RPL. > Because if we move DAG roots frequently, the topology will be > modified, new DODAGS must be constructed, more DIO messages will be > sent which can can diminish the energy of nodes and limit their > lifetime. > > Has RPL been already evaluated in network with mobile nodes ? I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or just entities which could be mobile? I.e. is a DAG Root a Mobile Node? Or are only the nodes within the RoLL network (not the DAG Root) mobile nodes? Just some comments, Alex > > Thanks, > > Leila Ben Saad PhD Student ENS Lyon France > > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From root@core3.amsl.com Wed Jan 13 07:15:02 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 57C973A681F; Wed, 13 Jan 2010 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100113151502.57C973A681F@core3.amsl.com> Date: Wed, 13 Jan 2010 07:15:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : A. Brandt, J. Buron Filename : draft-ietf-roll-home-routing-reqs-11.txt Pages : 18 Date : 2010-01-13 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-13071401.I-D@ietf.org> --NextPart-- From prvs=62235897d=mukul@uwm.edu Wed Jan 13 08:17:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1233A67A7 for ; Wed, 13 Jan 2010 08:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVG7w3YcjPQw for ; Wed, 13 Jan 2010 08:17:14 -0800 (PST) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id A9EC03A67D6 for ; Wed, 13 Jan 2010 08:17:13 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta2.uwm.edu with ESMTP; 13 Jan 2010 10:17:10 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 68C70B20002; Wed, 13 Jan 2010 10:17:10 -0600 (CST) X-Virus-Scanned: amavisd-new at 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 EpBbZjiehJBD; Wed, 13 Jan 2010 10:17:10 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0205FB20001; Wed, 13 Jan 2010 10:17:10 -0600 (CST) Date: Wed, 13 Jan 2010 10:17:09 -0600 (CST) From: Mukul Goyal To: Joydeep Tripathi Message-ID: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <706668471.992211263398457269.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Jan 2010 16:17:52 -0000 Joydeep Here are a few suggestions for your simulations: 1. Simulate a 100 node and a 1000 node topology operating under a single DAG 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From leila.ben.saad@ens-lyon.fr Wed Jan 13 23:11:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697973A6917 for ; Wed, 13 Jan 2010 23:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frjI3MHKxMAE for ; Wed, 13 Jan 2010 23:11:52 -0800 (PST) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by core3.amsl.com (Postfix) with ESMTP id 386DE3A680A for ; Wed, 13 Jan 2010 23:11:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 9B2521EB1F4 for ; Thu, 14 Jan 2010 08:11:48 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdmw+uTzHAyr for ; Thu, 14 Jan 2010 08:11:46 +0100 (CET) Received: from agrobate-domu-webmail.ens-lyon.fr (agrobate-domu-webmail.ens-lyon.fr [140.77.51.15]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 0858F1EB1B6 for ; Thu, 14 Jan 2010 08:11:45 +0100 (CET) Received: by agrobate-domu-webmail.ens-lyon.fr (Postfix, from userid 33) id C7F6B5822A; Thu, 14 Jan 2010 08:11:45 +0100 (CET) Received: from mne69-7-82-243-147-216.fbx.proxad.net (mne69-7-82-243-147-216.fbx.proxad.net [82.243.147.216]) by webmail.ens-lyon.fr (Horde Framework) with HTTP; Thu, 14 Jan 2010 08:11:45 +0100 Message-ID: <20100114081145.38205z4w5djmu181@webmail.ens-lyon.fr> Date: Thu, 14 Jan 2010 08:11:45 +0100 From: Leila Ben Saad To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 Subject: Re: [Roll] Nodes Mobility Support in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 07:11:53 -0000 I mean by my question if RPL is able to support the case where DAG =20 roots are mobile nodes ? The example of this can be a wireless sensor =20 network with mobile sinks where the sinks move to different locations =20 of the network in order to balance the energy consumption of the fixed =20 sensor nodes and improve the network lifetime. Alexandru Petrescu a =E9crit : > As a pre-requisite, I would consider looking at the RoLL requirements > documents and search for 'mobil' and find some use cases which were used > as motivators for RoLL. But during the subsequent RoLL work, the > mobility aspects were not hugely important. > > Le 06/01/2010 15:52, Leila Ben Saad a =E9crit : >> Dear WG, >> >> Is RPL able to support the mobility of DAG roots ? > > Well I guess DAG roots could move around a little bit and stay within > the link-layer's reachability range (e.g. 10meters). If this is > considered 'mobility' then automatically RPL does support it I believe. > > On another hand, if we consider 'mobility' to involve a change of the > address assigned to a node then I don't think RPL has much support for > it. I am not sure this is needed either in RPL. > >> Because if we move DAG roots frequently, the topology will be >> modified, new DODAGS must be constructed, more DIO messages will be >> sent which can can diminish the energy of nodes and limit their >> lifetime. >> >> Has RPL been already evaluated in network with mobile nodes ? > > I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or just > entities which could be mobile? I.e. is a DAG Root a Mobile Node? Or > are only the nodes within the RoLL network (not the DAG Root) mobile nodes? > > Just some comments, > > Alex > >> >> Thanks, >> >> Leila Ben Saad PhD Student ENS Lyon France >> >> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu Jan 14 03:07:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0333A6830 for ; Thu, 14 Jan 2010 03:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i36vrgxqT2K9 for ; Thu, 14 Jan 2010 03:07:26 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8A70F3A63EC for ; Thu, 14 Jan 2010 03:07:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0EB7LCQ001321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jan 2010 12:07:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0EB7Lt8028893; Thu, 14 Jan 2010 12:07:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0EB7KTD031674; Thu, 14 Jan 2010 12:07:21 +0100 Message-ID: <4B4EFAE8.5010305@gmail.com> Date: Thu, 14 Jan 2010 12:07:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Leila Ben Saad References: <20100114081145.38205z4w5djmu181@webmail.ens-lyon.fr> In-Reply-To: <20100114081145.38205z4w5djmu181@webmail.ens-lyon.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Nodes Mobility Support in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 11:07:27 -0000 Le 14/01/2010 08:11, Leila Ben Saad a écrit : > I mean by my question if RPL is able to support the case where DAG > roots are mobile nodes ? The example of this can be a wireless sensor > network with mobile sinks where the sinks move to different > locations How far is the new location of the mobile sink? If it is within the range of the link layer capabilities (e.g. 10meters for a PAN like Bluetooth) then I guess RPL-to-be supports it. If on the other hand the mobile sink moves further than the range of the link-layer then some big changes must happen in addressing and routing for RPL-to-be in order to support this kind of mobility. Just some thoughts, Alex > of the network in order to balance the energy consumption of the > fixed sensor nodes and improve the network lifetime. > > > Alexandru Petrescu a écrit : > >> As a pre-requisite, I would consider looking at the RoLL > requirements >> documents and search for 'mobil' and find some use cases which >> were > used >> as motivators for RoLL. But during the subsequent RoLL work, the >> mobility aspects were not hugely important. >> >> Le 06/01/2010 15:52, Leila Ben Saad a écrit : >>> Dear WG, >>> >>> Is RPL able to support the mobility of DAG roots ? >> >> Well I guess DAG roots could move around a little bit and stay > within >> the link-layer's reachability range (e.g. 10meters). If this is >> considered 'mobility' then automatically RPL does support it I > believe. >> >> On another hand, if we consider 'mobility' to involve a change of > the >> address assigned to a node then I don't think RPL has much support > for >> it. I am not sure this is needed either in RPL. >> >>> Because if we move DAG roots frequently, the topology will be >>> modified, new DODAGS must be constructed, more DIO messages will > be >>> sent which can can diminish the energy of nodes and limit their >>> lifetime. >>> >>> Has RPL been already evaluated in network with mobile nodes ? >> >> I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or > just >> entities which could be mobile? I.e. is a DAG Root a Mobile Node? > Or >> are only the nodes within the RoLL network (not the DAG Root) > mobile nodes? > > > >> >> Just some comments, >> >> Alex >> >>> >>> Thanks, >>> >>> Leila Ben Saad PhD Student ENS Lyon France >>> >>> >>> >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From Jerald.P.Martocci@jci.com Thu Jan 14 10:10:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9034C3A6810 for ; Thu, 14 Jan 2010 10:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjhp-QchGQvf for ; Thu, 14 Jan 2010 10:10:53 -0800 (PST) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id C15C73A697A for ; Thu, 14 Jan 2010 10:10:52 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKS09eKJNcgu1M9kymOZK+rjItsyw5Ehj3@postini.com; Thu, 14 Jan 2010 10:10:50 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010011412124461-8977924 ; Thu, 14 Jan 2010 12:12:44 -0600 In-Reply-To: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 To: Joydeep Tripathi X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 Jan 2010 12:10:38 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/14/2010 12:10:44 PM, Serialize complete at 01/14/2010 12:10:44 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/14/2010 12:12:44 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/14/2010 12:12:50 PM, Serialize complete at 01/14/2010 12:12:50 PM Content-Type: multipart/related; boundary="=_related 0063DB5E862576AB_=" Cc: ROLL WG Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Jan 2010 18:10:55 -0000 This is a multipart message in MIME format. --=_related 0063DB5E862576AB_= Content-Type: multipart/alternative; boundary="=_alternative 0063DB5E862576AB_=" --=_alternative 0063DB5E862576AB_= Content-Type: text/plain; charset="US-ASCII" Hi Joydeep, Mukul's been doing some simulations for my company for the past 3 years. He has a good handle on the commercial building performance requirements. It would be good for you to run those he notes below. It might be advantageous then for you two to share the results to better correlate the simulations. I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. Of course, this is now a function on DAG depth. Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. That would be the worst case scenario. If other nodes could short circuit the packets through a shorter path, that would on;y help. Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue. Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. However, what will really affect the system performance is 'DAG Repair'. I have no sense how long a packet in transit would have to wait if the DAG was under repair. Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access. This is not a good situation. The source node can only assume that its data is inaccessible, not just held up in transit. The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. This will all be logged to the operator which is a bad thing!!! That was what was nice about an AODV concept, because even route repair was fairly deterministic. So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific. Hope this makes sense. Jerry Mukul Goyal 01/13/2010 10:17 AM To Joydeep Tripathi cc ROLL WG , Jerald P Martocci Subject Re: [Roll] RPL Simulation Joydeep Here are a few suggestions for your simulations: 1. Simulate a 100 node and a 1000 node topology operating under a single DAG 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0063DB5E862576AB_= Content-Type: text/html; charset="US-ASCII"
Hi Joydeep,

Mukul's been doing some simulations for my company for the past 3 years.  He has a good handle on the commercial building performance requirements.  It would be good for you to run those he notes below.  It might be advantageous then for you two to share the results to better correlate the simulations.

I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node.  Of course, this is now a function on DAG depth.  Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR.  That would be the worst case scenario.  If other nodes could short circuit the packets through a shorter path, that would on;y help.

Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue.  Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth.  However, what will really affect the system performance is 'DAG Repair'.  I have no sense how long a packet in transit would have to wait if the DAG was under repair.  Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3).  After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access.  This is not a good situation.  The source node can only assume that its data is inaccessible, not just held up in transit.  The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes.  This will all be logged to the operator which is a bad thing!!!  That was what was nice about an AODV concept, because even route repair was fairly deterministic.

So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific.

Hope this makes sense.

Jerry






Mukul Goyal <mukul@uwm.edu>

01/13/2010 10:17 AM

To
Joydeep Tripathi <joydeep.tripathi@gmail.com>
cc
ROLL WG <roll@ietf.org>, Jerald P Martocci <Jerald.P.Martocci@jci.com>
Subject
Re: [Roll] RPL Simulation





Joydeep

Here are a few suggestions for your simulations:

1. Simulate a 100 node and a 1000 node topology operating under a single DAG

2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root).

3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology:
a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths.
b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node).

4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <joydeep.tripathi@gmail.com>
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
Cc: "ROLL WG" <roll@ietf.org>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central
Subject: [Roll] RPL Simulation

Hi,

In the next revision, we are also planning to implement a typical
building routing scenario, where 60-70% of the P2P traffic are
confined within 1 hop physical distance and, 20% of the P2P traffic
are to a 2 -hop distance destination, and observe the performance of
RPL against the ideal shortest route. Also, please let us know if
there is any other scenario or traffic pattern you want to be
implemented.

Thanks,
Joydeep
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0063DB5E862576AB_=-- --=_related 0063DB5E862576AB_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_04D2824804D27B640063DB5E862576AB> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 0063DB5E862576AB_=-- From robert.assimiti@nivis.com Thu Jan 14 12:44:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A093A6861 for ; Thu, 14 Jan 2010 12:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVWNjZWwuyPx for ; Thu, 14 Jan 2010 12:44:56 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by core3.amsl.com (Postfix) with ESMTP id C92FE3A6405 for ; Thu, 14 Jan 2010 12:44:55 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 14 Jan 2010 15:44:52 -0500 From: Robert Assimiti To: "roll@ietf.org" Date: Thu, 14 Jan 2010 15:44:48 -0500 Thread-Topic: DAG ID - Do we really need 128 bits to identify a DAG Thread-Index: AcqVRO8r4HfdvrBoSq+cUxciNPopjwAFF3WQ Message-ID: <67442429D9C35E4C975B89BE73BD33D0159F89FCBD@ATLEXCH02.nivis.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AkLQ Aq9K BF2A Bbbo BmTe BshF CA51 EIxl Ecwy FYyl HEz9 Hb7x HqJJ Hwfg JAHd JMxO; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {FF0400CB-EF77-4E40-8D7A-FEF70408172F}; cgBvAGIAZQByAHQALgBhAHMAcwBpAG0AaQB0AGkAQABuAGkAdgBpAHMALgBjAG8AbQA=; Thu, 14 Jan 2010 20:44:48 GMT; RABBAEcAIABJAEQAIAAtACAARABvACAAdwBlACAAcgBlAGEAbABsAHkAIABuAGUAZQBkACAAMQAyADgAIABiAGkAdABzACAAdABvACAAaQBkAGUAbgB0AGkAZgB5ACAAYQAgAEQAQQBHAA== x-cr-puzzleid: {FF0400CB-EF77-4E40-8D7A-FEF70408172F} acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] DAG ID - Do we really need 128 bits to identify a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 20:44:57 -0000 Going through draft-ietf-roll-rpl-05 I have noticed that the DAGID is an 12= 8-bit unsigned int. The scope of the DAGID is a DAG instance within an LLN. The DAGID could be = global IPv6 address of the DAG root. Do we really need 128-bits (transferred over lossy links) just to indentify= a parameter with such limited scope? IMHO, we either increase the scope (global) or decrease the length. Am I missing something here? Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of rol= l-request@ietf.org Sent: Thursday, January 14, 2010 1:11 PM To: roll@ietf.org Subject: Roll Digest, Vol 24, Issue 7 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Nodes Mobility Support in RPL (Leila Ben Saad) 2. Re: Nodes Mobility Support in RPL (Alexandru Petrescu) 3. Re: RPL Simulation (Jerald.P.Martocci@jci.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Jan 2010 08:11:45 +0100 From: Leila Ben Saad Subject: Re: [Roll] Nodes Mobility Support in RPL To: roll@ietf.org Message-ID: <20100114081145.38205z4w5djmu181@webmail.ens-lyon.fr> Content-Type: text/plain; charset=3DISO-8859-1; DelSp=3D"Yes"; format=3D"flowed" I mean by my question if RPL is able to support the case where DAG roots are mobile nodes ? The example of this can be a wireless sensor network with mobile sinks where the sinks move to different locations of the network in order to balance the energy consumption of the fixed sensor nodes and improve the network lifetime. Alexandru Petrescu a ?crit : > As a pre-requisite, I would consider looking at the RoLL requirements > documents and search for 'mobil' and find some use cases which were used > as motivators for RoLL. But during the subsequent RoLL work, the > mobility aspects were not hugely important. > > Le 06/01/2010 15:52, Leila Ben Saad a ?crit : >> Dear WG, >> >> Is RPL able to support the mobility of DAG roots ? > > Well I guess DAG roots could move around a little bit and stay within > the link-layer's reachability range (e.g. 10meters). If this is > considered 'mobility' then automatically RPL does support it I believe. > > On another hand, if we consider 'mobility' to involve a change of the > address assigned to a node then I don't think RPL has much support for > it. I am not sure this is needed either in RPL. > >> Because if we move DAG roots frequently, the topology will be >> modified, new DODAGS must be constructed, more DIO messages will be >> sent which can can diminish the energy of nodes and limit their >> lifetime. >> >> Has RPL been already evaluated in network with mobile nodes ? > > I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or just > entities which could be mobile? I.e. is a DAG Root a Mobile Node? Or > are only the nodes within the RoLL network (not the DAG Root) mobile nodes? > > Just some comments, > > Alex > >> >> Thanks, >> >> Leila Ben Saad PhD Student ENS Lyon France >> >> >> >> >> _______________________________________________ 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 > ------------------------------ Message: 2 Date: Thu, 14 Jan 2010 12:07:20 +0100 From: Alexandru Petrescu Subject: Re: [Roll] Nodes Mobility Support in RPL To: Leila Ben Saad Cc: roll@ietf.org Message-ID: <4B4EFAE8.5010305@gmail.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Le 14/01/2010 08:11, Leila Ben Saad a ?crit : > I mean by my question if RPL is able to support the case where DAG > roots are mobile nodes ? The example of this can be a wireless sensor > network with mobile sinks where the sinks move to different > locations How far is the new location of the mobile sink? If it is within the range of the link layer capabilities (e.g. 10meters for a PAN like Bluetooth) then I guess RPL-to-be supports it. If on the other hand the mobile sink moves further than the range of the link-layer then some big changes must happen in addressing and routing for RPL-to-be in order to support this kind of mobility. Just some thoughts, Alex > of the network in order to balance the energy consumption of the > fixed sensor nodes and improve the network lifetime. > > > Alexandru Petrescu a ?crit : > >> As a pre-requisite, I would consider looking at the RoLL > requirements >> documents and search for 'mobil' and find some use cases which >> were > used >> as motivators for RoLL. But during the subsequent RoLL work, the >> mobility aspects were not hugely important. >> >> Le 06/01/2010 15:52, Leila Ben Saad a ?crit : >>> Dear WG, >>> >>> Is RPL able to support the mobility of DAG roots ? >> >> Well I guess DAG roots could move around a little bit and stay > within >> the link-layer's reachability range (e.g. 10meters). If this is >> considered 'mobility' then automatically RPL does support it I > believe. >> >> On another hand, if we consider 'mobility' to involve a change of > the >> address assigned to a node then I don't think RPL has much support > for >> it. I am not sure this is needed either in RPL. >> >>> Because if we move DAG roots frequently, the topology will be >>> modified, new DODAGS must be constructed, more DIO messages will > be >>> sent which can can diminish the energy of nodes and limit their >>> lifetime. >>> >>> Has RPL been already evaluated in network with mobile nodes ? >> >> I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or > just >> entities which could be mobile? I.e. is a DAG Root a Mobile Node? > Or >> are only the nodes within the RoLL network (not the DAG Root) > mobile nodes? > > > >> >> Just some comments, >> >> Alex >> >>> >>> Thanks, >>> >>> Leila Ben Saad PhD Student ENS Lyon France >>> >>> >>> >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > ------------------------------ Message: 3 Date: Thu, 14 Jan 2010 12:10:38 -0600 From: Jerald.P.Martocci@jci.com Subject: Re: [Roll] RPL Simulation To: Joydeep Tripathi Cc: ROLL WG Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Joydeep, Mukul's been doing some simulations for my company for the past 3 years. He has a good handle on the commercial building performance requirements. It would be good for you to run those he notes below. It might be advantageous then for you two to share the results to better correlate the simulations. I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. Of course, this is now a function on DAG depth. Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. That would be the worst case scenario. If other nodes could short circuit the packets through a shorter path, that would on;y help. Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue. Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. However, what will really affect the system performance is 'DAG Repair'. I have no sense how long a packet in transit would have to wait if the DAG was under repair. Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access. This is not a good situation. The source node can only assume that its data is inaccessible, not just held up in transit. The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. This will all be logged to the operator which is a bad thing!!! That was what was nice about an AODV concept, because even route repair was fairly deterministic. So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific. Hope this makes sense. Jerry Mukul Goyal 01/13/2010 10:17 AM To Joydeep Tripathi cc ROLL WG , Jerald P Martocci Subject Re: [Roll] RPL Simulation Joydeep Here are a few suggestions for your simulations: 1. Simulate a 100 node and a 1000 node topology operating under a single DAG 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12611 bytes Desc: not available Url : ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 24, Issue 7 *********************************** This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. From moulchan@cisco.com Thu Jan 14 21:45:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9073A6A3A for ; Thu, 14 Jan 2010 21:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G31nvs5paoz8 for ; Thu, 14 Jan 2010 21:45:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0564528C0F4 for ; Thu, 14 Jan 2010 21:45:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF+QT0tAZnwM/2dsb2JhbADCO5UZhDEEjUQ X-IronPort-AV: E=Sophos;i="4.49,280,1262563200"; d="scan'208";a="80224961" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2010 05:45:11 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.188]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0F5jBqf026925; Fri, 15 Jan 2010 05:45:11 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 23:45:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jan 2010 23:45:08 -0600 Message-ID: In-Reply-To: <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Potential RPL Enhancements Thread-Index: Acp6bsvxFYVOe9NjSM2YWgePLcnDpQbNkW5w References: <2050276922.9714591260541913420.JavaMail.root@mail02.pantherlink.uwm.edu> <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Mouli Chandramouli (moulchan)" To: "Mukul Goyal" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 15 Jan 2010 05:45:11.0443 (UTC) FILETIME=[E731E630:01CA95A5] Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Jan 2010 05:45:29 -0000 A nit.=20 Please add the reference for [Khanna1989] In the references section. A. Khanna , J. Zinky, The revised ARPANET routing metric, ACM SIGCOMM Computer Communication Review, v.19 n.4, p.45-56, Sep. 1989. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Friday, December 11, 2009 8:02 PM To: JP Vasseur (jvasseur) Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements JP "We reached a point where the protocol is getting stable with all must-=20 have features (except security, our next top priority item)." I am not sure if many people are convinced regarding the suitability of RPL for P2P routing. Thanks Mukul=20 ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Friday, December 11, 2009 8:20:26 AM GMT -06:00 US/Canada Central Subject: [Roll] Potential RPL Enhancements Dear all, As a follow up to my previous email with regards to the version 05 of =20 RPL, I wanted to elaborate a little bit on the process that we will be =20 following with regards to further RPL enhancements. We reached a point where the protocol is getting stable with all must-=20 have features (except security, our next top priority item). It is now =20 time to get feed-back from implementers. There will of course be proposals to enhance and improve the protocol =20 and here is the proposed way to proceed: 1) If there is a request to modify RPL because an issue has been =20 found, a ticket will be opened and the issue will be solved. 2) If there is "nice to have" enhancements, we'll open a ticket =20 flagged as "enhancement", to be addressed at some point (e.g. DIS =20 enhancement) 3) New features will be addressed in separate documents. Plan for rev-06 and -07: 1) clarification and potential enhancements to DAO processing 2) potentially DAO packing if it is shown that such mechanism is needed 3) Security Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From emmanuel.baccelli@gmail.com Fri Jan 15 05:39:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711993A687B for ; Fri, 15 Jan 2010 05:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY3xMP1wvWV8 for ; Fri, 15 Jan 2010 05:39:47 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 3496D3A6A86 for ; Fri, 15 Jan 2010 05:39:46 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so33269eye.5 for ; Fri, 15 Jan 2010 05:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=pStutFP5XRvtoeWuZ0WYnDqJEV9rYkq+60AX1thj4xk=; b=epFh2OR7blApQvfsGsYlLIlFQep/bUe+lLXS3w39xXLSIVbg//MQENLrVIZvUL9BPV UTjGaI1X6UmuXpBoWFzto28TrcrFxDITnBiVOoE8ynzQOol1BiHiv5PSrMw1E+zvubkX kmfaOBJQn+JEa/DG8QSXRx+ylBGWip8FGtlNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=Mq8YSfVunqAR2/rSGV6fwBnCDhVRjuyDscvGZ6lJ24TsBdaaYoQL3UzsTs9BJ0gjkD yjtFasm0BbQ6wYHAdEu/Omi27Gfa13hXU0uq4GWRlBkPP7EdmhF3yTlWmdjluxT9siI3 EYhu6q53RZ+Lw8MBGRVYgw+x+63/LKdEcYPV8= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.109.148 with SMTP id j20mr981580ebp.2.1263562779143; Fri, 15 Jan 2010 05:39:39 -0800 (PST) In-Reply-To: References: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> From: Emmanuel Baccelli Date: Fri, 15 Jan 2010 14:39:19 +0100 X-Google-Sender-Auth: 843e46ba1745ca89 Message-ID: To: ROLL WG Content-Type: multipart/related; boundary=000e0ce0445a9a2dbe047d34227d Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Jan 2010 13:39:48 -0000 --000e0ce0445a9a2dbe047d34227d Content-Type: multipart/alternative; boundary=000e0ce0445a9a2db8047d34227c --000e0ce0445a9a2db8047d34227c Content-Type: text/plain; charset=ISO-8859-1 Hi Joydeep, I concur with Jerry and Mukul. More studies, in particular on route stretch and delays with the use of RPL as it stands for now, are needed in order to validate the current design with respect to the goals RPL attempts at achieving. Regards, Emmanuel On Thu, Jan 14, 2010 at 7:10 PM, wrote: > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 years. > He has a good handle on the commercial building performance requirements. > It would be good for you to run those he notes below. It might be > advantageous then for you two to share the results to better correlate the > simulations. > > I would also look at the latency for P2P messages when the packet(s) need > to traverse the DAG all the way up to the LBR and back down to the > destination node. Of course, this is now a function on DAG depth. Also > since all our messages require ACK, the additional latency of the ACK having > to return possibly through a different set of nodes yet via the LBR. That > would be the worst case scenario. If other nodes could short circuit the > packets through a shorter path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning on > lights, etc) latency is a big issue. Moving the packet up and down the DAG > is reasonably deterministic and should be primarily a function of the DAG > depth. However, what will really affect the system performance is 'DAG > Repair'. I have no sense how long a packet in transit would have to wait if > the DAG was under repair. Since we require ACKs of every message, the > source node would time-out and retry a few times (usually 3). After that, > the source node would have to fall into some 'failsoft' mode depending on > the type of data it was trying to access. This is not a good situation. > The source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis since it > can't be constantly dithering between modes. This will all be logged to the > operator which is a bad thing!!! That was what was nice about an AODV > concept, because even route repair was fairly deterministic. > > So... if your simulation could measure packet latency as a function of DAG > repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > *Mukul Goyal * > > 01/13/2010 10:17 AM > To > Joydeep Tripathi > cc > ROLL WG , Jerald P Martocci > Subject > Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a single > DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG > from a source to a destination passes through their closest common ancestor) > and DAG routes through root (all DAG paths have to go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over the DAG > versus the length/cost of ideal routes) for given number of flows: 100, > 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in > the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% > flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from each > possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic loads > as well as packet loss/delay along the DAG links. Compare these values > against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > 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 > > --000e0ce0445a9a2db8047d34227c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joydeep,

I concur with Jerry and Mukul. More studies, in particul= ar on route stretch and delays with the use of RPL as it stands for now, ar= e=A0 needed in order to validate the current design with respect to the goa= ls RPL attempts at achieving.

Regards,

Emmanuel


On Thu, = Jan 14, 2010 at 7:10 PM, <Jerald.P.Martocci@jci.com> wrote:

Hi Joydeep,

Mukul's been doing some simula= tions for my company for the past 3 years. =A0He has a good handle on the commercial building performance requirements. =A0It would be good for you to run those he notes below. =A0It might be advantageous then for you two to share the results to better correlate the simulations.

I would also look at the latency f= or P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. =A0Of course, this is now a function on DAG depth. =A0Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. =A0That would be the worst case scenario. =A0If other nodes could short circuit the packets through a shorter path, that would on;y help.

Since Building systems are real-ti= me (smoke/fire detection, turning on lights, etc) latency is a big issue. =A0Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. =A0However, what will really affect the system performance is 'DAG Repair'. =A0I hav= e no sense how long a packet in transit would have to wait if the DAG was under repair. =A0Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). =A0After that, the source node would have to fall into some 'failsoft' mode depend= ing on the type of data it was trying to access. =A0This is not a good situatio= n. =A0The source node can only assume that its data is inaccessible, not just held up in transit. =A0The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. =A0This will all be logged to the operator which is a bad thing!!! =A0That was what was nice about an AODV concept, because even route repair was fairly determinis= tic.

So... if your simulation could mea= sure packet latency as a function of DAG repair severity, that would be terrific= .

Hope this makes sense.

Jerry






Mukul Goyal <<= a href=3D"mailto:mukul@uwm.edu" target=3D"_blank">mukul@uwm.edu>

01/13/2010 10:17 AM

To
Joydeep Tri= pathi <j= oydeep.tripathi@gmail.com>
cc
ROLL WG <roll@ietf.org>, Jerald P Martocci <Jerald.P.Martocci@jci.com>
Subject
Re: [Roll] RPL Simulation





Joydeep

Here are a few suggestions for your simulations:

1. Simulate a 100 node and a 1000 node topology operating under a single DAG

2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root).

3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology:
a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths.
b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node).

4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <joydeep.tripathi@gmail.com>
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
Cc: "ROLL WG" <roll@ietf.org>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation

Hi,

In the next revision, we are also planning to implement a typical
building routing scenario, where 60-70% of the P2P traffic are
confined within 1 hop physical distance and, 20% of the P2P traffic
are to a 2 -hop distance destination, and observe the performance of
RPL against the ideal shortest route. Also, please let us know if
there is any other scenario or traffic pattern you want to be
implemented.

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

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


--000e0ce0445a9a2db8047d34227c-- --000e0ce0445a9a2dbe047d34227d Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <_2_04D2824804D27B640063DB5E862576AB> X-Attachment-Id: 0.0.1 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --000e0ce0445a9a2dbe047d34227d-- From joydeep.tripathi@gmail.com Fri Jan 15 15:25:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40123A69C2 for ; Fri, 15 Jan 2010 15:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKynhpHAyioj for ; Fri, 15 Jan 2010 15:25:40 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id C8DE73A69AE for ; Fri, 15 Jan 2010 15:25:39 -0800 (PST) Received: by bwz23 with SMTP id 23so714912bwz.29 for ; Fri, 15 Jan 2010 15:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zMwDqWQanDk143KiqOxm0+bVlOfWxVMD9+1uXChZ27o=; b=AVyDCW6os0kYWx23Jnwv20uhiYZ3Umwm0i2QNtmjqQYVKzTDvisvx4b+rdnf9BFDHm r0eMuYRLG1W3R9x25iPUt+ixRxABaNp4/sP3kE5OsJ6P7u1tPZHUA5GobYbGRsiriaA7 IG+pCXExfxrLcUec+cbE9SzuaEEmcMn/HpXVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WqM7k3SWre5PCufMUnJ1upP4qdfCMS5yleVVw+cGJVfj4wL7sihNoOumfxcmTsv1zX FWezFi9yRsyVUE+0zUadOP764rMgvu1yv/ZUtLQ9E5KSQsitcReaKdgSGo/369/dJSqq O9mRc6E2/9J5F8P63abvOEON2UAsh6D3wh/90= MIME-Version: 1.0 Received: by 10.204.32.140 with SMTP id c12mr1687817bkd.59.1263597932673; Fri, 15 Jan 2010 15:25:32 -0800 (PST) In-Reply-To: References: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 15 Jan 2010 18:25:32 -0500 Message-ID: From: Joydeep Tripathi To: Jerald.P.Martocci@jci.com Content-Type: multipart/alternative; boundary=000325553a36ea7acb047d3c5151 Cc: ROLL WG Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Jan 2010 23:25:41 -0000 --000325553a36ea7acb047d3c5151 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks a ton for your feedback. We will look into simulating the specific routing scenarios and coming up with latency result and path stretch. Thanks, Joydeep On Thu, Jan 14, 2010 at 1:10 PM, wrote: > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 years. > He has a good handle on the commercial building performance requirements. > It would be good for you to run those he notes below. It might be > advantageous then for you two to share the results to better correlate the > simulations. > > I would also look at the latency for P2P messages when the packet(s) need > to traverse the DAG all the way up to the LBR and back down to the > destination node. Of course, this is now a function on DAG depth. Also > since all our messages require ACK, the additional latency of the ACK having > to return possibly through a different set of nodes yet via the LBR. That > would be the worst case scenario. If other nodes could short circuit the > packets through a shorter path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning on > lights, etc) latency is a big issue. Moving the packet up and down the DAG > is reasonably deterministic and should be primarily a function of the DAG > depth. However, what will really affect the system performance is 'DAG > Repair'. I have no sense how long a packet in transit would have to wait if > the DAG was under repair. Since we require ACKs of every message, the > source node would time-out and retry a few times (usually 3). After that, > the source node would have to fall into some 'failsoft' mode depending on > the type of data it was trying to access. This is not a good situation. > The source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis since it > can't be constantly dithering between modes. This will all be logged to the > operator which is a bad thing!!! That was what was nice about an AODV > concept, because even route repair was fairly deterministic. > > So... if your simulation could measure packet latency as a function of DAG > repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > *Mukul Goyal * > > 01/13/2010 10:17 AM > To > Joydeep Tripathi > cc > ROLL WG , Jerald P Martocci > Subject > Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a single > DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG > from a source to a destination passes through their closest common ancestor) > and DAG routes through root (all DAG paths have to go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over the DAG > versus the length/cost of ideal routes) for given number of flows: 100, > 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in > the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% > flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from each > possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic loads > as well as packet loss/delay along the DAG links. Compare these values > against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" > To: "Jerald P Martocci" > Cc: "ROLL WG" > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --000325553a36ea7acb047d3c5151 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks a ton for your feedback. We will look into simulating the= specific routing scenarios and coming up with latency result and path stre= tch.

Thanks,
Joydeep

On Thu, J= an 14, 2010 at 1:10 PM, <Jerald.P.Martocci@jci.com>= wrote:

Hi Joydeep,

Mukul's been doing some simula= tions for my company for the past 3 years. =A0He has a good handle on the commercial building performance requirements. =A0It would be good for you to run those he notes below. =A0It might be advantageous then for you two to share the results to better correlate the simulations.

I would also look at the latency f= or P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. =A0Of course, this is now a function on DAG depth. =A0Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. =A0That would be the worst case scenario. =A0If other nodes could short circuit the packets through a shorter path, that would on;y help.

Since Building systems are real-ti= me (smoke/fire detection, turning on lights, etc) latency is a big issue. =A0Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. =A0However, what will really affect the system performance is 'DAG Repair'. =A0I hav= e no sense how long a packet in transit would have to wait if the DAG was under repair. =A0Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). =A0After that, the source node would have to fall into some 'failsoft' mode depend= ing on the type of data it was trying to access. =A0This is not a good situatio= n. =A0The source node can only assume that its data is inaccessible, not just held up in transit. =A0The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. =A0This will all be logged to the operator which is a bad thing!!! =A0That was what was nice about an AODV concept, because even route repair was fairly determinis= tic.

So... if your simulation could mea= sure packet latency as a function of DAG repair severity, that would be terrific= .

Hope this makes sense.

Jerry






Mukul Goyal <<= a href=3D"mailto:mukul@uwm.edu" target=3D"_blank">mukul@uwm.edu>

01/13/2010 10:17 AM

To
Joydeep Tripathi <joydeep.tripat= hi@gmail.com>
cc
ROLL WG <roll@ietf.org>, Jerald P Martocci <Jerald.P.Martocci@jci.com>
Subject
Re: [Roll] RPL Simulation





Joydeep

Here are a few suggestions for your simulations:

1. Simulate a 100 node and a 1000 node topology operating under a single DAG

2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root).

3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology:
a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths.
b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node).

4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <joydeep.tripathi@gmail.com>
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
Cc: "ROLL WG" <roll@ietf.org>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation

Hi,

In the next revision, we are also planning to implement a typical
building routing scenario, where 60-70% of the P2P traffic are
confined within 1 hop physical distance and, 20% of the P2P traffic
are to a 2 -hop distance destination, and observe the performance of
RPL against the ideal shortest route. Also, please let us know if
there is any other scenario or traffic pattern you want to be
implemented.

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

--000325553a36ea7acb047d3c5151-- From jvasseur@cisco.com Sun Jan 17 23:04:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A663A6A7B for ; Sun, 17 Jan 2010 23:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=-3.361, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzs+RReBOqwP for ; Sun, 17 Jan 2010 23:04:31 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7851B3A680E for ; Sun, 17 Jan 2010 23:04:31 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAACaXU0uQ/uCWe2dsb2JhbACCFplmAQEWJAajXZNjhDIE X-IronPort-AV: E=Sophos;i="4.49,294,1262563200"; d="scan'208,217";a="2519829" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 18 Jan 2010 06:35:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0I74Qaa013135 for ; Mon, 18 Jan 2010 07:04:27 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:26 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:26 +0100 Message-Id: <4C2FEE47-2C11-4F9C-92AC-6A831A80C8A4@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-55--124366136 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 18 Jan 2010 08:02:38 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Jan 2010 07:04:26.0473 (UTC) FILETIME=[78A72590:01CA980C] Subject: [Roll] IETF 77 - Important Dates X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Jan 2010 07:04:33 -0000 --Apple-Mail-55--124366136 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). 2010-03-21 - 2010-03-26: 77th IETF Meeting in Anaheim, California, USA. --Apple-Mail-55--124366136 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
  • 2010-02-26 = (Friday): Final agenda to be published.
  • 2010-03-01 (Monday): = Internet Draft Cut-off for initial document (-00) submission by 17:00 = PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission = Tool.
  • IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2010-03-12 (Friday): Early = Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, = March 13 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2010-03-15 (Monday): = Registration cancellation cut-off at 17:00 PDT (24:00 UTC).
  • 2010-03-19 = (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 PDT (24:00 UTC).
  • 2010-03-21 - 2010-03-26: 77th IETF Meeting in = Anaheim, California, USA.
= --Apple-Mail-55--124366136-- From pthubert@cisco.com Mon Jan 18 00:33:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5183A680C for ; Mon, 18 Jan 2010 00:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZKMsyt4Rr4m for ; Mon, 18 Jan 2010 00:33:32 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 898503A63C9 for ; Mon, 18 Jan 2010 00:33:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ6rU0tAZnwM/2dsb2JhbADAMIklCYopAoIpEAyBawQ X-IronPort-AV: E=Sophos;i="4.49,295,1262563200"; d="scan'208";a="80607570" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2010 08:33:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0I8WPdl002192; Mon, 18 Jan 2010 08:33:22 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 09:32:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jan 2010 09:32:53 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01065235@XMB-AMS-107.cisco.com> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D0159F89FCBD@ATLEXCH02.nivis.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAG ID - Do we really need 128 bits to identify a DAG Thread-Index: AcqVRO8r4HfdvrBoSq+cUxciNPopjwAFF3WQAK/L6UA= References: <67442429D9C35E4C975B89BE73BD33D0159F89FCBD@ATLEXCH02.nivis.com> From: "Pascal Thubert (pthubert)" To: "Robert Assimiti" , X-OriginalArrivalTime: 18 Jan 2010 08:32:58.0803 (UTC) FILETIME=[D70C6030:01CA9818] Subject: Re: [Roll] DAG ID - Do we really need 128 bits to identify a DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 08:33:34 -0000 Hi Robert: This and many other things could and should be compressed. For instance the DAO, the source route info in particular but also the way we pack DAO together, and a number of other fields. At the moment we are looking at making the protocol sane and secure, and then we'll focus on making the PDU shorter. Have a great year! Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Assimiti Sent: jeudi 14 janvier 2010 21:45 To: roll@ietf.org Subject: [Roll] DAG ID - Do we really need 128 bits to identify a DAG Going through draft-ietf-roll-rpl-05 I have noticed that the DAGID is an 128-bit unsigned int. The scope of the DAGID is a DAG instance within an LLN. The DAGID could be global IPv6 address of the DAG root. Do we really need 128-bits (transferred over lossy links) just to indentify a parameter with such limited scope? IMHO, we either increase the scope (global) or decrease the length. Am I missing something here? Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of roll-request@ietf.org Sent: Thursday, January 14, 2010 1:11 PM To: roll@ietf.org Subject: Roll Digest, Vol 24, Issue 7 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Nodes Mobility Support in RPL (Leila Ben Saad) 2. Re: Nodes Mobility Support in RPL (Alexandru Petrescu) 3. Re: RPL Simulation (Jerald.P.Martocci@jci.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Jan 2010 08:11:45 +0100 From: Leila Ben Saad Subject: Re: [Roll] Nodes Mobility Support in RPL To: roll@ietf.org Message-ID: <20100114081145.38205z4w5djmu181@webmail.ens-lyon.fr> Content-Type: text/plain; charset=3DISO-8859-1; DelSp=3D"Yes"; format=3D"flowed" I mean by my question if RPL is able to support the case where DAG roots are mobile nodes ? The example of this can be a wireless sensor network with mobile sinks where the sinks move to different locations of the network in order to balance the energy consumption of the fixed sensor nodes and improve the network lifetime. Alexandru Petrescu a ?crit : > As a pre-requisite, I would consider looking at the RoLL requirements > documents and search for 'mobil' and find some use cases which were used > as motivators for RoLL. But during the subsequent RoLL work, the > mobility aspects were not hugely important. > > Le 06/01/2010 15:52, Leila Ben Saad a ?crit : >> Dear WG, >> >> Is RPL able to support the mobility of DAG roots ? > > Well I guess DAG roots could move around a little bit and stay within > the link-layer's reachability range (e.g. 10meters). If this is > considered 'mobility' then automatically RPL does support it I believe. > > On another hand, if we consider 'mobility' to involve a change of the > address assigned to a node then I don't think RPL has much support for > it. I am not sure this is needed either in RPL. > >> Because if we move DAG roots frequently, the topology will be >> modified, new DODAGS must be constructed, more DIO messages will be >> sent which can can diminish the energy of nodes and limit their >> lifetime. >> >> Has RPL been already evaluated in network with mobile nodes ? > > I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or just > entities which could be mobile? I.e. is a DAG Root a Mobile Node? Or > are only the nodes within the RoLL network (not the DAG Root) mobile nodes? > > Just some comments, > > Alex > >> >> Thanks, >> >> Leila Ben Saad PhD Student ENS Lyon France >> >> >> >> >> _______________________________________________ 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 > ------------------------------ Message: 2 Date: Thu, 14 Jan 2010 12:07:20 +0100 From: Alexandru Petrescu Subject: Re: [Roll] Nodes Mobility Support in RPL To: Leila Ben Saad Cc: roll@ietf.org Message-ID: <4B4EFAE8.5010305@gmail.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Le 14/01/2010 08:11, Leila Ben Saad a ?crit : > I mean by my question if RPL is able to support the case where DAG > roots are mobile nodes ? The example of this can be a wireless sensor > network with mobile sinks where the sinks move to different > locations How far is the new location of the mobile sink? If it is within the range of the link layer capabilities (e.g. 10meters for a PAN like Bluetooth) then I guess RPL-to-be supports it. If on the other hand the mobile sink moves further than the range of the link-layer then some big changes must happen in addressing and routing for RPL-to-be in order to support this kind of mobility. Just some thoughts, Alex > of the network in order to balance the energy consumption of the > fixed sensor nodes and improve the network lifetime. > > > Alexandru Petrescu a ?crit : > >> As a pre-requisite, I would consider looking at the RoLL > requirements >> documents and search for 'mobil' and find some use cases which >> were > used >> as motivators for RoLL. But during the subsequent RoLL work, the >> mobility aspects were not hugely important. >> >> Le 06/01/2010 15:52, Leila Ben Saad a ?crit : >>> Dear WG, >>> >>> Is RPL able to support the mobility of DAG roots ? >> >> Well I guess DAG roots could move around a little bit and stay > within >> the link-layer's reachability range (e.g. 10meters). If this is >> considered 'mobility' then automatically RPL does support it I > believe. >> >> On another hand, if we consider 'mobility' to involve a change of > the >> address assigned to a node then I don't think RPL has much support > for >> it. I am not sure this is needed either in RPL. >> >>> Because if we move DAG roots frequently, the topology will be >>> modified, new DODAGS must be constructed, more DIO messages will > be >>> sent which can can diminish the energy of nodes and limit their >>> lifetime. >>> >>> Has RPL been already evaluated in network with mobile nodes ? >> >> I don't know. Do you mean a Mobile Node as in Mobile IPv6? Or > just >> entities which could be mobile? I.e. is a DAG Root a Mobile Node? > Or >> are only the nodes within the RoLL network (not the DAG Root) > mobile nodes? > > > >> >> Just some comments, >> >> Alex >> >>> >>> Thanks, >>> >>> Leila Ben Saad PhD Student ENS Lyon France >>> >>> >>> >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > ------------------------------ Message: 3 Date: Thu, 14 Jan 2010 12:10:38 -0600 From: Jerald.P.Martocci@jci.com Subject: Re: [Roll] RPL Simulation To: Joydeep Tripathi Cc: ROLL WG Message-ID: =20 Content-Type: text/plain; charset=3D"us-ascii" Hi Joydeep, Mukul's been doing some simulations for my company for the past 3 years. He has a good handle on the commercial building performance requirements. It would be good for you to run those he notes below. It might be advantageous then for you two to share the results to better correlate the simulations. I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. Of course, this is now a function on DAG depth. Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. That would be the worst case scenario. If other nodes could short circuit the packets through a shorter path, that would on;y help. Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue. Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. However, what will really affect the system performance is 'DAG Repair'. I have no sense how long a packet in transit would have to wait if the DAG was under repair. Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access. This is not a good situation. The source node can only assume that its data is inaccessible, not just held up in transit. The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. This will all be logged to the operator which is a bad thing!!! That was what was nice about an AODV concept, because even route repair was fairly deterministic. So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific. Hope this makes sense. Jerry Mukul Goyal 01/13/2010 10:17 AM To Joydeep Tripathi cc ROLL WG , Jerald P Martocci Subject Re: [Roll] RPL Simulation Joydeep Here are a few suggestions for your simulations: 1. Simulate a 100 node and a 1000 node topology operating under a single DAG 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12611 bytes Desc: not available Url : ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 24, Issue 7 *********************************** This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From wwwrun@core3.amsl.com Tue Jan 19 06:59:05 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C1CCF3A6A7B; Tue, 19 Jan 2010 06:59:05 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100119145905.C1CCF3A6A7B@core3.amsl.com> Date: Tue, 19 Jan 2010 06:59:05 -0800 (PST) Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Document Action: 'Home Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Jan 2010 14:59:05 -0000 The IESG has approved the following document: - 'Home Automation Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-11.txt Technical Summary This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Basic home control modules such as wall switches and plug-in modules may be turned into an advanced home automation solution via the use of an IP-enabled application responding to events generated by wall switches, motion sensors, light sensors, rain sensors, and so on. Network nodes may be sensors and actuators at the same time. An example is a wall switch for replacement in existing buildings. The push buttons may generate events for a controller node or for activating other actuator nodes. At the same time, a built-in relay may act as actuator for a controller or other remote sensors. Because ROLL nodes only cover a limited radio range, routing is often required. These devices are usually highly constrained in term of resources such as battery and memory and operate in unstable environments. Persons moving around in a house, opening or closing a door or starting a microwave oven affect the reception of weak radio signals. Reflection and absorption may cause a reliable radio link to turn unreliable for a period of time and then being reusable again, thus the term "lossy". Unlike other categories of PANs, the connected home area is very much consumer-oriented. The implication on network nodes is that devices are very cost sensitive, which leads to resource- constrained environments having slow CPUs and small memory footprints. At the same time, nodes have to be physically small which puts a limit to the physical size of the battery; and thus, the battery capacity. As a result, it is common for low-power sensor-style nodes to shut down radio and CPU resources for most of the time. The radio tends to use the same power for listening as for transmitting Section 2 describes a few typical use cases for home automation applications. Section 3 discusses the routing requirements for networks comprising such constrained devices in a home network environment. These requirements may be overlapping requirements derived from other application-specific routing requirements. A full list of requirements documents may be found in the end of the document. Working Group Summary No controversy. Document Quality The I-D is informational and specifies routing requirements Personnel JP Vasseur (jpv@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 1 ADD new paragraph before the paragraph beginning "Section 2 describes a few..." Although this document focuses its text on radio-based wireless networks, home automation networks may also operate using a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. Many such low power link technologies share similar characteristics with low power wireless and this document should be regarded as applying equally to all such links. --- Section 3.3 OLD Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated "smart" home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. NEW Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of devices may form a home automation network in a fully populated "smart" home, and a large proportion of those may be low power devices. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol needs to be able to support a basic home deployment and so MUST be able to support at least 250 devices in the network. Furthermore, the protocol SHOULD be extensible to support more sophisticated and future deployments with a larger number of devices. --- Section 3.4 OLD The routing protocol MUST converge within 0.5 second if no nodes have moved. NEW The routing protocol MUST converge within 0.5 second if no nodes have moved (see Section 3.2 for motivation). --- Section 3.4 OLD The routing protocol MUST converge within 4 seconds if nodes have moved. NEW The routing protocol MUST converge within 4 seconds if nodes have moved to re-establish connectivity within a time that a human operator would find tolerable as, for example, when moving a remote control unit. --- Section 4 OLD Remote controls have a similar transmit pattern to wall switches, but are activated more frequently. NEW Remote controls have a similar transmit pattern to wall switches, but may be activated more frequently in some deployments. --- Section 4 DELETE As mentioned in the introduction, all messages are carried in IPv6 packets; typically as UDP but ICMP echo and other types may also appear. In order to save bandwidth, the transport layer will typically be using header compression [I-D.Hui-HeaderCompression]. --- From abr@sdesigns.dk Tue Jan 19 07:14:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5636D3A6AB1 for ; Tue, 19 Jan 2010 07:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.462 X-Spam-Level: X-Spam-Status: No, score=0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MY_CID_AND_ARIAL2=1.46] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu0ddCiuBEga for ; Tue, 19 Jan 2010 07:14:55 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 361BB3A6AAE for ; Tue, 19 Jan 2010 07:14:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA991A.23C4C140" Date: Tue, 19 Jan 2010 16:14:48 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429D8F@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Simulation Thread-Index: AcqVRO6FaZEhLAV3QJeOFk6pEghfgQD1B3rA References: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: , "Joydeep Tripathi" Cc: ROLL WG Subject: Re: [Roll] RPL Simulation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Jan 2010 15:14:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA991A.23C4C140 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA991A.23C4C140" ------_=_NextPart_002_01CA991A.23C4C140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jerry, =20 >That was what was nice about an AODV concept, because even route repair was fairly deterministic.=20 As far as I am informed some reactive discovery mechanism is still needed for all the reasons that you list below. You may remember that we have the same needs in home automation. By utilizing the fact that source routing is already used to jump between RPL-capable routers AND the fact that the (time critical) point-to-point communication is limited to 5 hops or less, some TTL-aware, source-route-based AODV hybrid may not cause so much flooding as one could fear. =20 - Anders =20 =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, January 14, 2010 19:11 To: Joydeep Tripathi Cc: ROLL WG Subject: Re: [Roll] RPL Simulation Hi Joydeep,=20 Mukul's been doing some simulations for my company for the past 3 years. He has a good handle on the commercial building performance requirements. It would be good for you to run those he notes below. It might be advantageous then for you two to share the results to better correlate the simulations.=20 I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. Of course, this is now a function on DAG depth. Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. That would be the worst case scenario. If other nodes could short circuit the packets through a shorter path, that would on;y help.=20 Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue. Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. However, what will really affect the system performance is 'DAG Repair'. I have no sense how long a packet in transit would have to wait if the DAG was under repair. Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access. This is not a good situation. The source node can only assume that its data is inaccessible, not just held up in transit. The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. This will all be logged to the operator which is a bad thing!!! That was what was nice about an AODV concept, because even route repair was fairly deterministic.=20 So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific.=20 Hope this makes sense.=20 Jerry=20 =20 Mukul Goyal =20 01/13/2010 10:17 AM=20 To Joydeep Tripathi =20 cc ROLL WG , Jerald P Martocci =20 Subject Re: [Roll] RPL Simulation =09 Joydeep Here are a few suggestions for your simulations: 1. Simulate a 100 node and a 1000 node topology operating under a single DAG 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation Hi, In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. Thanks, Joydeep _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_002_01CA991A.23C4C140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jerry,
 
>That was what was nice about an AODV concept, because even = route=20 repair was fairly deterministic. =

As far as I am = informed some=20 reactive discovery mechanism is still needed for all the reasons that = you list=20 below.
You may remember = that we have=20 the same needs in home automation.
By utilizing the fact that source = routing=20 is already used to jump between RPL-capable routers AND the fact that = the (time=20 critical)
point-to-point communication is limited to 5 hops or less, = some=20 TTL-aware, source-route-based AODV hybrid may not cause so
much = flooding=20 as one could fear.
 
-=20 Anders
 
 
From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com
Sent: Thursday, January 14, 2010 = 19:11
To: Joydeep Tripathi
Cc: ROLL = WG
Subject:=20 Re: [Roll] RPL Simulation


Hi Joydeep, =

Mukul's been doing some simulations for my = company for=20 the past 3 years.  He has a good handle on the commercial building=20 performance requirements.  It would be good for you to run those he = notes=20 below.  It might be advantageous then for you two to share the = results to=20 better correlate the simulations.

I=20 would also look at the latency for P2P messages when the packet(s) need = to=20 traverse the DAG all the way up to the LBR and back down to the = destination=20 node.  Of course, this is now a function on DAG depth.  Also = since all=20 our messages require ACK, the additional latency of the ACK having to = return=20 possibly through a different set of nodes yet via the LBR.  That = would be=20 the worst case scenario.  If other nodes could short circuit the = packets=20 through a shorter path, that would on;y help.

Since Building systems are real-time = (smoke/fire=20 detection, turning on lights, etc) latency is a big issue.  Moving = the=20 packet up and down the DAG is reasonably deterministic and should be = primarily a=20 function of the DAG depth.  However, what will really affect the = system=20 performance is 'DAG Repair'.  I have no sense how long a packet in = transit=20 would have to wait if the DAG was under repair.  Since we require = ACKs of=20 every message, the source node would time-out and retry a few times = (usually 3).=20  After that, the source node would have to fall into some = 'failsoft' mode=20 depending on the type of data it was trying to access.  This is not = a good=20 situation.  The source node can only assume that its data is = inaccessible,=20 not just held up in transit.  The fail-soft mode will have large = hysteresis=20 since it can't be constantly dithering between modes.  This will = all be=20 logged to the operator which is a bad thing!!!  That was what was = nice=20 about an AODV concept, because even route repair was fairly=20 deterministic.

So... if = your=20 simulation could measure packet latency as a function of DAG repair = severity,=20 that would be terrific.

Hope this=20 makes sense.

Jerry=20






Mukul Goyal=20 <mukul@uwm.edu>

01/13/2010 10:17 AM =

To
Joydeep Tripathi=20 <joydeep.tripathi@gmail.com>=20
cc
ROLL WG = <roll@ietf.org>,=20 Jerald P Martocci <Jerald.P.Martocci@jci.com>=20
Subject
Re: [Roll] RPL=20 Simulation

=




Joydeep

Here are a few suggestions for your=20 simulations:

1. Simulate a 100 node and a 1000 node topology = operating=20 under a single DAG

2. Simulate both scenarios: optimal DAG routes = (ie the=20 path through the DAG from a source to a destination passes through their = closest=20 common ancestor) and DAG routes through root (all DAG paths have to go = through=20 the DAG root).

3. Study the stretch factor (increase in = length/cost of=20 routes over the DAG versus the length/cost of ideal routes) for given = number of=20 flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the = number of=20 nodes in the topology:
a) the scenario you suggested: Choose 20% = flows over 2=20 hop neighbors, 10% flows over longer paths.
b) randomly selected = source and=20 destinations (in n*(n-1) case, from each possible source node to each = possible=20 destination node).

4. In addition to the stretch factor,=20 calculate/simulate the traffic loads as well as packet loss/delay along = the DAG=20 links. Compare these values against values with ideal P2P=20 routing.

Thanks
Mukul
----- Original Message -----
From: = "Joydeep Tripathi" <joydeep.tripathi@gmail.com>
To: "Jerald P = Martocci"=20 <Jerald.P.Martocci@jci.com>
Cc: "ROLL WG"=20 <roll@ietf.org>
Sent: Wednesday, January 13, 2010 2:24:36 AM = GMT -06:00=20 US/Canada Central
Subject: [Roll] RPL Simulation

Hi,

In = the=20 next revision, we are also planning to implement a typical
building = routing=20 scenario, where 60-70% of the P2P traffic are
confined within 1 hop = physical=20 distance and, 20% of the P2P traffic
are to a 2 -hop distance = destination,=20 and observe the performance of
RPL against the ideal shortest route. = Also,=20 please let us know if
there is any other scenario or traffic pattern = you want=20 to=20 be
implemented.

Thanks,
Joydeep
_________________________= ______________________
Roll=20 mailing=20 list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_002_01CA991A.23C4C140-- ------_=_NextPart_001_01CA991A.23C4C140 Content-Type: image/jpeg; name="ATT129641.jpg" Content-Transfer-Encoding: base64 Content-ID: <523590615@19012010-3238> Content-Description: ATT129641.jpg Content-Location: ATT129641.jpg /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= ------_=_NextPart_001_01CA991A.23C4C140-- From ietfroll@yahoo.com Tue Jan 19 14:04:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA793A67AB for ; Tue, 19 Jan 2010 14:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnV5S3ltmv4x for ; Tue, 19 Jan 2010 14:04:53 -0800 (PST) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id 7CF8E3A67BD for ; Tue, 19 Jan 2010 14:04:53 -0800 (PST) Received: from [69.147.84.144] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 19 Jan 2010 22:04:48 -0000 Received: from [67.195.9.82] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 19 Jan 2010 22:04:48 -0000 Received: from [67.195.9.108] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jan 2010 22:04:48 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 19 Jan 2010 22:04:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 29772.73275.bm@omp112.mail.gq1.yahoo.com Received: (qmail 58698 invoked by uid 60001); 19 Jan 2010 22:04:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263938687; bh=fQ8tIzu6QpVBqMNUnzf6Povv7fvFmdY8YTw/FKlnjQ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=LTv9Sl63f1YILQdEXzlzHaBVXo+QCnu8v6Ht5rTjcAZJjKQYtyR6uHuo1u3JCLXPZW0LtNhW1xDmAUNX8/xQwk0fW3Th1D9vHAhMpOEzC/I5zB8kzd2BY5nS+V0bXKP1tzgUZ4qN1F1rsBTEeQ4+dEs0yfRq86NhuW5q5Axzgd8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=lHhTTkUcXqZb8+QdWxlcLSksuRsj0gdwrQwVUriaSvIopQM5ffuJVppqMHd0yLNEcBBMehECImeSVUG122m+k+omkJQBFMKnayHBkMRqypJeTYjlcXc8cGuZVwzMGWCXPhz4qYr99KNOgXN3LMZrKvtdV/U4bIF3HDmnRToccVE=; Message-ID: <942450.58477.qm@web113901.mail.gq1.yahoo.com> X-YMail-OSG: sUYYAw4VM1kFwiVUJxsBP91JeRRTQhDTSMJREk4u8myXIuPq6qTdexGF7pBrNhGyhmfUuXogQmtLGv9nblvNrHEVORxdLbV6nKUZxS.wAPTsSQvYD8PWv.VsS0N4lKmnErFwJcElKOUFxrzKjs4ibqZnG70q6tff86oNyTr2A2pTY8WSCn9gqwBf3pap8RNUtPUhF4Hj6UYYN.sbU60IYzruH4OTUn562hvjyJwotXj4Jlgj41U6O.0CEMNlWY8sKmjCf7S_Ld0ZoBzxD48CeOMlLPCJ7He6ZCZ5R5MocryKxDL31.2k7cfWypWjEMVtqIr9NjqJ01ZU.KtOKdAh_2QXmjNbTGXda3Y1QrR1ObR04Dovvd.4DubfcWm6Bdii7uY0uKgLhlevdZtYc8K67YBoXh21sg-- Received: from [209.62.95.170] by web113901.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 14:04:47 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Tue, 19 Jan 2010 14:04:47 -0800 (PST) From: Ietf Roll To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Jan 2010 22:04:54 -0000 ROLLers, Did anyone see the Cisco announcement about IPR in RPL. If you didn't it was probably because it was only sent to the IETF IPR list. I don't know why it wasn't sent to the ROLL list. If you didn't see it here is a link: http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html I'm a bit confused and concerned that this IPR annoucement was sent so late in the process (December 3) - given that Cisco folks were working on the design team from the beginning. We are now so late in the design and development that it would be nearly impossible for us to figure out how avoid this patent. There is a free license to use the patent in RPL so long as you and your company doesn't sue Cisco over ANY other patent for ANYTHING. Can we avoid the use of the patented technology in RPL? Should we? Do we want to? Did this IPR announcement come too late? Rav From d.sturek@att.net Tue Jan 19 14:15:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5A33A68A8 for ; Tue, 19 Jan 2010 14:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpSDNf+fVi-I for ; Tue, 19 Jan 2010 14:15:43 -0800 (PST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 861903A683D for ; Tue, 19 Jan 2010 14:15:43 -0800 (PST) Received: (qmail 58879 invoked from network); 19 Jan 2010 22:15:37 -0000 Received: from adsl-69-232-84-27.dsl.sndg02.pacbell.net (d.sturek@69.232.84.27 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Jan 2010 14:15:37 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 3hJ6s.0VM1n.EjO0zrq18HbXsUvFJnaBjiI9qPpBfHjENkscYesX3fhR76JctZm9khLV_MuwAPB5ZxaF9ojhGjJVQaIFuGB.eBbVma_jjAAeh7WNfiHQG.A7k4pSSXKU5iu8iNOsFvYFBAa6mqOX8MozlMjNhYAo.tkmFwiHjvx17B79dUkf61egeAQm3t.445u2gF4T6qB1CKhvOu16HXylarqfmWGyDOKz.DTKMxknaRS7qaP8FVVKVBz8PBMqjvR_uZ4fAlybuEWbA0_Q7jG6lywdZwqZh__lGX1BAzvU9TsfJiGqjfb8Irmm.biAEsY- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Ietf Roll'" , References: <942450.58477.qm@web113901.mail.gq1.yahoo.com> In-Reply-To: <942450.58477.qm@web113901.mail.gq1.yahoo.com> Date: Tue, 19 Jan 2010 14:15:31 -0800 Message-ID: <014901ca9954$eb463570$c1d2a050$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqZU21iuQn9fr1sRW2tOA/MBk59RQAAQ5lg Content-Language: en-us Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:15:44 -0000 Hi Rav, I have been involved in mesh networking for some time. It was actually a good thing to see the IPR statement from Cisco. Having some certainty around IPR seems like a good thing for large deployments like Smart Energy. Best Regards, Don Sturek -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ietf Roll Sent: Tuesday, January 19, 2010 2:05 PM To: roll@ietf.org Subject: [Roll] RPL Patents ROLLers, Did anyone see the Cisco announcement about IPR in RPL. If you didn't it was probably because it was only sent to the IETF IPR list. I don't know why it wasn't sent to the ROLL list. If you didn't see it here is a link: http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html I'm a bit confused and concerned that this IPR annoucement was sent so late in the process (December 3) - given that Cisco folks were working on the design team from the beginning. We are now so late in the design and development that it would be nearly impossible for us to figure out how avoid this patent. There is a free license to use the patent in RPL so long as you and your company doesn't sue Cisco over ANY other patent for ANYTHING. Can we avoid the use of the patented technology in RPL? Should we? Do we want to? Did this IPR announcement come too late? Rav _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Tue Jan 19 14:48:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B8E3A6811 for ; Tue, 19 Jan 2010 14:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKHFqzNz20hq for ; Tue, 19 Jan 2010 14:48:14 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 44D573A6801 for ; Tue, 19 Jan 2010 14:48:14 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.25]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NXMrq-00081B-7p for roll@ietf.org; Tue, 19 Jan 2010 14:48:10 -0800 Received: by qw-out-2122.google.com with SMTP id 5so218706qwi.31 for ; Tue, 19 Jan 2010 14:47:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.86.220 with SMTP id t28mr5797134qal.43.1263941240225; Tue, 19 Jan 2010 14:47:20 -0800 (PST) In-Reply-To: <942450.58477.qm@web113901.mail.gq1.yahoo.com> References: <942450.58477.qm@web113901.mail.gq1.yahoo.com> From: Omprakash Gnawali Date: Tue, 19 Jan 2010 14:47:00 -0800 Message-ID: To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Jan 2010 22:48:15 -0000 Here is a list of patents mentioned in the IPR announcement: 7,190,678: Arrangement for router attachments between roaming mobile routers in a clustered network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David Charlton (Reading, GB) http://www.google.com/patents?vid=3DUSPAT7190678 7,203,175: Arrangement for router attachments between roaming mobile routers in a mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David Charlton (Reading, GB) http://www.google.com/patents?vid=3DUSPAT7203175 7,209,978: Arrangement in a router of a mobile network for optimizing use of messages carrying reverse routing headers Thubert; Pascal (La Colle sur Loup, FR), Molteni; Marco (Antibes, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Auerbach; David (Biot, FR) http://www.google.com/patents?vid=3DUSPAT7209978 7,366,111: Arrangement for providing optimized connections between peer routers in a tree-based ad hoc mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Mouans Sartoux, FR), Ribiere; Vincent Jean (Biot, FR), Levy-Abegnoli; Eric M. (Valbonne, FR) http://www.google.com/patents?vid=3DUSPAT7366111 7,428,221: Arrangement for providing network prefix information from attached mobile routers to a clusterhead in a tree-based ad hoc mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Mouans Sartoux, FR), Molteni; Marco (Antibes, FR), Moon; Billy G. (Cary, NC) http://www.google.com/patents?vid=3DUSPAT7428221 - om_p On Tue, Jan 19, 2010 at 2:04 PM, Ietf Roll wrote: > ROLLers, > =A0Did anyone see the Cisco announcement about IPR in RPL. =A0If you didn= 't it was probably because it was only sent to the IETF IPR list. =A0I don'= t know why it wasn't sent to the ROLL list. =A0If you didn't see it here is= a link: > > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > I'm a bit confused and concerned that this IPR annoucement was sent so la= te in the process (December 3) - given that Cisco folks were working on the= design team from the beginning. =A0We are now so late in the design and de= velopment that it would be nearly impossible for us to figure out how avoid= this patent. > > There is a free license to use the patent in RPL so long as you and your = company doesn't sue Cisco over ANY other patent for ANYTHING. > > Can we avoid the use of the patented technology in RPL? =A0Should we? =A0= Do we want to? > > Did this IPR announcement come too late? > > =A0 =A0Rav > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From gnawali@cs.stanford.edu Tue Jan 19 14:48:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1273A696B for ; Tue, 19 Jan 2010 14:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc29mIfqdH1r for ; Tue, 19 Jan 2010 14:48:19 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 9EDD33A6921 for ; Tue, 19 Jan 2010 14:48:19 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.24]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NXMrv-00033i-Rq for roll@ietf.org; Tue, 19 Jan 2010 14:48:16 -0800 Received: by qw-out-2122.google.com with SMTP id 5so218745qwi.31 for ; Tue, 19 Jan 2010 14:48:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.86.220 with SMTP id t28mr5797134qal.43.1263941240225; Tue, 19 Jan 2010 14:47:20 -0800 (PST) In-Reply-To: <942450.58477.qm@web113901.mail.gq1.yahoo.com> References: <942450.58477.qm@web113901.mail.gq1.yahoo.com> From: Omprakash Gnawali Date: Tue, 19 Jan 2010 14:47:00 -0800 Message-ID: To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Jan 2010 22:48:19 -0000 Here is a list of patents mentioned in the IPR announcement: 7,190,678: Arrangement for router attachments between roaming mobile routers in a clustered network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David Charlton (Reading, GB) http://www.google.com/patents?vid=3DUSPAT7190678 7,203,175: Arrangement for router attachments between roaming mobile routers in a mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David Charlton (Reading, GB) http://www.google.com/patents?vid=3DUSPAT7203175 7,209,978: Arrangement in a router of a mobile network for optimizing use of messages carrying reverse routing headers Thubert; Pascal (La Colle sur Loup, FR), Molteni; Marco (Antibes, FR), Wetterwald; Patrick (Cagnes sur Mer, FR), Auerbach; David (Biot, FR) http://www.google.com/patents?vid=3DUSPAT7209978 7,366,111: Arrangement for providing optimized connections between peer routers in a tree-based ad hoc mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Mouans Sartoux, FR), Ribiere; Vincent Jean (Biot, FR), Levy-Abegnoli; Eric M. (Valbonne, FR) http://www.google.com/patents?vid=3DUSPAT7366111 7,428,221: Arrangement for providing network prefix information from attached mobile routers to a clusterhead in a tree-based ad hoc mobile network Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; Patrick (Mouans Sartoux, FR), Molteni; Marco (Antibes, FR), Moon; Billy G. (Cary, NC) http://www.google.com/patents?vid=3DUSPAT7428221 - om_p On Tue, Jan 19, 2010 at 2:04 PM, Ietf Roll wrote: > ROLLers, > =A0Did anyone see the Cisco announcement about IPR in RPL. =A0If you didn= 't it was probably because it was only sent to the IETF IPR list. =A0I don'= t know why it wasn't sent to the ROLL list. =A0If you didn't see it here is= a link: > > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > I'm a bit confused and concerned that this IPR annoucement was sent so la= te in the process (December 3) - given that Cisco folks were working on the= design team from the beginning. =A0We are now so late in the design and de= velopment that it would be nearly impossible for us to figure out how avoid= this patent. > > There is a free license to use the patent in RPL so long as you and your = company doesn't sue Cisco over ANY other patent for ANYTHING. > > Can we avoid the use of the patented technology in RPL? =A0Should we? =A0= Do we want to? > > Did this IPR announcement come too late? > > =A0 =A0Rav > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Tue Jan 19 22:58:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDD53A6A33 for ; Tue, 19 Jan 2010 22:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+qRTlok9qie for ; Tue, 19 Jan 2010 22:58:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8DEF03A6A27 for ; Tue, 19 Jan 2010 22:58:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFI4VktAZnwN/2dsb2JhbADBI5VMhDYE X-IronPort-AV: E=Sophos;i="4.49,308,1262563200"; d="scan'208";a="80993561" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2010 06:58:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0K6wPLB010069; Wed, 20 Jan 2010 06:58:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 07:58:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 07:58:21 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> In-Reply-To: <942450.58477.qm@web113901.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Patents Thread-Index: AcqZU3wtAvHP15AkQWy4EtyYOdBE2wASe+jA References: <942450.58477.qm@web113901.mail.gq1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Ietf Roll" , X-OriginalArrivalTime: 20 Jan 2010 06:58:25.0910 (UTC) FILETIME=[F6911960:01CA999D] Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Jan 2010 06:58:31 -0000 Hi: Just to make things straight, Cisco published to IETF and announced that IPR on April 16th to the ROLL ML: http://www.ietf.org/mail-archive/web/roll/current/msg01181.html=20 There has been some administrative delay porting the message to the RPL draft, but the content is basically the same. Cheers; Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ietf Roll Sent: mardi 19 janvier 2010 23:05 To: roll@ietf.org Subject: [Roll] RPL Patents ROLLers, Did anyone see the Cisco announcement about IPR in RPL. If you didn't it was probably because it was only sent to the IETF IPR list. I don't know why it wasn't sent to the ROLL list. If you didn't see it here is a link: http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html I'm a bit confused and concerned that this IPR annoucement was sent so late in the process (December 3) - given that Cisco folks were working on the design team from the beginning. We are now so late in the design and development that it would be nearly impossible for us to figure out how avoid this patent. There is a free license to use the patent in RPL so long as you and your company doesn't sue Cisco over ANY other patent for ANYTHING. Can we avoid the use of the patented technology in RPL? Should we? Do we want to? Did this IPR announcement come too late? Rav =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Jan 20 07:25:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2173A6942 for ; Wed, 20 Jan 2010 07:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.115 X-Spam-Level: X-Spam-Status: No, score=-9.115 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m22Ds88jJkBx for ; Wed, 20 Jan 2010 07:25:13 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13FC73A6855 for ; Wed, 20 Jan 2010 07:25:13 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEABqvVkutJV2d/2dsb2JhbACCF5hJqSmVSIQ2BA X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208,217";a="469896140" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2010 15:25:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0KFOSVU017588 for ; Wed, 20 Jan 2010 15:25:08 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 16:25:02 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 16:25:01 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-139-78561557 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 20 Jan 2010 16:24:46 +0100 References: <20100119145905.BA2DB3A682E@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jan 2010 15:25:01.0366 (UTC) FILETIME=[BBAB9D60:01CA99E4] Subject: [Roll] Fwd: ID Tracker State Update Notice: draft-ietf-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Jan 2010 15:25:14 -0000 --Apple-Mail-139-78561557 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The document has now been approved by the IESG. We're working on the building requirement to move it forward. JP. Begin forwarded message: > From: The IESG > Date: January 19, 2010 3:59:05 PM CEST > To: roll-chairs@tools.ietf.org, draft-ietf-roll-home-routing-reqs@tools.ietf.org > Subject: ID Tracker State Update Notice: draft-ietf-roll-home- > routing-reqs > Reply-To: ietf-secretariat-reply@ietf.org > > IESG has approved and state has been changed to 'Approved- > Announcement sent' by Amy Vezza. > ID Tracker URL: https://datatracker.ietf.org/?command=view_id&dTag=17265&rfc_flag=0 > --Apple-Mail-139-78561557 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The document has now been = approved by the IESG.
We're working on the building requirement to = move it forward.

JP.

Begin = forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Date: January 19, 2010 3:59:05 PM = CEST
Subject: = ID Tracker State Update Notice: = draft-ietf-roll-home-routing-reqs

=
IESG has approved and state has been changed to = 'Approved-Announcement sent' by Amy Vezza.
ID Tracker URL: https://datatracker.ietf.org/?command=3Dview_id&dTag=3D= 17265&rfc_flag=3D0


= --Apple-Mail-139-78561557-- From alexandru.petrescu@gmail.com Wed Jan 20 07:36:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC333A681E for ; Wed, 20 Jan 2010 07:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AHKWBgk1yz6 for ; Wed, 20 Jan 2010 07:36:34 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C0ABC3A6452 for ; Wed, 20 Jan 2010 07:36:33 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0KFaSVQ018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jan 2010 16:36:28 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0KFaSlZ030526 for ; Wed, 20 Jan 2010 16:36:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0KFaRKI010019 for ; Wed, 20 Jan 2010 16:36:28 +0100 Message-ID: <4B5722FB.2080406@gmail.com> Date: Wed, 20 Jan 2010 16:36:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: roll@ietf.org References: <942450.58477.qm@web113901.mail.gq1.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Jan 2010 15:36:34 -0000 Le 20/01/2010 07:58, Pascal Thubert (pthubert) a écrit : > Hi: > > Just to make things straight, Cisco published to IETF and announced > that IPR on April 16th to the ROLL ML: > http://www.ietf.org/mail-archive/web/roll/current/msg01181.html YEs, I thought the same, but after digging I realize the above statement pertains to : draft-thubert-roll-fundamentals-01 whereas the statement forwarded by 'Rav' pertains to another draft: draft-dt-roll-rpl So we end up with two Cisco IPR statements, which is good IMHO. My interest, in this RoLL landscape, is whether there's somebody else than Cisco claiming IPR on RoLL technologies and whether the different claims converge to the benefit of everybody else. Alex > > There has been some administrative delay porting the message to the > RPL draft, but the content is basically the same. > > Cheers; > > Pascal > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Ietf Roll Sent: mardi 19 > janvier 2010 23:05 To: roll@ietf.org Subject: [Roll] RPL Patents > > ROLLers, Did anyone see the Cisco announcement about IPR in RPL. If > you didn't it was probably because it was only sent to the IETF IPR > list. I don't know why it wasn't sent to the ROLL list. If you > didn't see it here is a link: > > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > I'm a bit confused and concerned that this IPR annoucement was sent > so late in the process (December 3) - given that Cisco folks were > working on the design team from the beginning. We are now so late in > the design and development that it would be nearly impossible for us > to figure out how avoid this patent. > > There is a free license to use the patent in RPL so long as you and > your company doesn't sue Cisco over ANY other patent for ANYTHING. > > Can we avoid the use of the patented technology in RPL? Should we? > Do we want to? > > Did this IPR announcement come too late? > > Rav > > > > > _______________________________________________ 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 ietfroll@yahoo.com Mon Jan 18 09:51:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875E63A6940 for ; Mon, 18 Jan 2010 09:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe8cvBvjMaIu for ; Mon, 18 Jan 2010 09:51:51 -0800 (PST) Received: from n6.bullet.mail.gq1.yahoo.com (n6.bullet.mail.gq1.yahoo.com [98.137.27.133]) by core3.amsl.com (Postfix) with SMTP id B2CB03A68BC for ; Mon, 18 Jan 2010 09:51:51 -0800 (PST) Received: from [67.195.9.83] by n6.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jan 2010 17:51:46 -0000 Received: from [67.195.9.100] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jan 2010 17:51:45 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 18 Jan 2010 17:51:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 905927.28256.bm@omp104.mail.gq1.yahoo.com Received: (qmail 49605 invoked by uid 60001); 18 Jan 2010 17:51:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263837105; bh=w2zgMLEp3BUHdia1Qlt39FPOBBkLL7e41oftmIiZaBo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=nxdizMzeRJoAh3tZLefdBbCqNXVmw9vxYjMSyy9Tktb3LomJOS006oLNTQYyChviv2/DeYUusVFTyW+CXOHZLaaRYLsMXNmGfEWmhyJihPcZrlMyGaCzSAqBlJx4HG+ugyfOzqmxII5uuDeb/Y6saI0HPXeS6F03L7Z6L9UjzIA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=0ERXjFTvHihfkDS80isthuiWCS0EI2oYwAhiDVKMf0fWA1Y37Qpn/SZp90zyVcbcb5qMCJ7jx6AmYcN7ZmpGTrZ1kRPTR+Fs6rKTvb/y9JHu0p8V6SNAXXZxW3FhLU1fQUYG2vYS7ILGpFwqpm3ri5kUzcBC9YmFlfyFMa0j65c=; Message-ID: <820482.49389.qm@web113911.mail.gq1.yahoo.com> X-YMail-OSG: hQxv2FMVM1niezc0KiiEygY1D2.j69fJOmxIwasFlpadBePG.VpzJMBXUn1z14PQcIgscoX2Ym_GRIVGV.UbKXAAI8.uvRaJNPrcJx2RLhd7oKjMxMjEHAGfG6ij.JfDP99RxEUGZIE4psxeeOhVhDQNSgCfjFxNWy2IbOZuVFppkhCiQpLuClzdcCRaavTe.LDhLRr8_vnEMeazvXYUDwSGaYsHuEEjXKJfopqlC2bHHmX6LU_sQsEwBn_qmzXXsKNJb_37vp_vR2Z56lJktckPfuRkLFDb1w7T6Lmyx33TQ6Af5Vvky76Jk3NKeLjWO8d5bq3GR5Sl92bNHA3859vAdDSAP7.e1Mmu9eFbw5dfnBgfgFY.WnWr37vVcQZ1tPj9iVo344rLOQK73yBn.33otNzIfTJj2QvlcZKJBmfsgaq1BTM- Received: from [65.114.195.189] by web113911.mail.gq1.yahoo.com via HTTP; Mon, 18 Jan 2010 09:51:45 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Mon, 18 Jan 2010 09:51:45 -0800 (PST) From: Ietf Roll To: roll@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-592568510-1263837105=:49389" X-Mailman-Approved-At: Wed, 20 Jan 2010 08:02:41 -0800 Subject: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:16:45 -0000 --0-592568510-1263837105=:49389 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ROLLers, =A0 Did anyone see the Cisco announcement about IPR in RPL.=A0 If you didn'= t it was probably because it was only sent to the IETF IPR list.=A0 I don't= know why it wasn't sent to the ROLL list.=A0 If you didn't see it here is = a link: http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html I'm a bit confused and concerned that this IPR annoucement was sent so late= in the process (December 3).=A0 Given that Cisco folks were working on the= design team from the beginning why did it take so long for cisco to identi= fy the IPR.=A0 We are now so late in the design and development that it wou= ld be nearly impossible for us to figure out how avoid this patent. There is a free license to use the patent in RPL so long as you and your co= mpany doesn't sue Cisco over ANY other patent for ANYTHING. Can we avoid the use of the patented technology in RPL?=A0 Should we?=A0 Do= we want to? Did this IPR announcement come too late? =A0=A0=A0 Rav =0A=0A=0A --0-592568510-1263837105=:49389 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
ROLLers,
  Did anyone see the Cisco a= nnouncement about IPR in RPL.  If you didn't it was probably because i= t was only sent to the IETF IPR list.  I don't know why it wasn't sent= to the ROLL list.  If you didn't see it here is a link:

http:/= /www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html

I'= m a bit confused and concerned that this IPR annoucement was sent so late i= n the process (December 3).  Given that Cisco folks were working on th= e design team from the beginning why did it take so long for cisco to ident= ify the IPR.  We are now so late in the design and development that it= would be nearly impossible for us to figure out how avoid this patent.
=
There is a free license to use the patent in RPL so long as you and you= r company doesn't sue Cisco over ANY other patent for ANYTHING.

Can = we avoid the use of the patented technology in RPL?  Should we?  Do= we want to?

Did this IPR announcement come too late?

 &= nbsp;  Rav

=0A=0A --0-592568510-1263837105=:49389-- From pal@cs.stanford.edu Wed Jan 20 09:26:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65993A659B for ; Wed, 20 Jan 2010 09:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jyMnSLUjgHL for ; Wed, 20 Jan 2010 09:26:34 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id CBCF53A6403 for ; Wed, 20 Jan 2010 09:26:34 -0800 (PST) Received: from dnab404630.stanford.edu ([171.64.70.48]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NXeK6-0000Gf-Gm; Wed, 20 Jan 2010 09:26:31 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-103-85865787 From: Philip Levis In-Reply-To: <820482.49389.qm@web113911.mail.gq1.yahoo.com> Date: Wed, 20 Jan 2010 09:26:30 -0800 Message-Id: <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> References: <820482.49389.qm@web113911.mail.gq1.yahoo.com> To: Ietf Roll X-Mailer: Apple Mail (2.1077) X-Scan-Signature: cb5916722246bf80bd9488153e8e2604 Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:26:36 -0000 --Apple-Mail-103-85865787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > ROLLers, > Did anyone see the Cisco announcement about IPR in RPL. If you = didn't it was probably because it was only sent to the IETF IPR list. I = don't know why it wasn't sent to the ROLL list. If you didn't see it = here is a link: >=20 > = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >=20 > I'm a bit confused and concerned that this IPR annoucement was sent so = late in the process (December 3). Given that Cisco folks were working = on the design team from the beginning why did it take so long for cisco = to identify the IPR. We are now so late in the design and development = that it would be nearly impossible for us to figure out how avoid this = patent. >=20 > There is a free license to use the patent in RPL so long as you and = your company doesn't sue Cisco over ANY other patent for ANYTHING. >=20 > Can we avoid the use of the patented technology in RPL? Should we? = Do we want to? I think we can, want to, and should. Phil= --Apple-Mail-103-85865787 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
ROLLers,
  Did anyone see the Cisco announcement about = IPR in RPL.  If you didn't it was probably because it was only sent = to the IETF IPR list.  I don't know why it wasn't sent to the ROLL = list.  If you didn't see it here is a link:

http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.= html

I'm a bit confused and concerned that this IPR = annoucement was sent so late in the process (December 3).  Given = that Cisco folks were working on the design team from the beginning why = did it take so long for cisco to identify the IPR.  We are now so = late in the design and development that it would be nearly impossible = for us to figure out how avoid this patent.

There is a free = license to use the patent in RPL so long as you and your company doesn't = sue Cisco over ANY other patent for ANYTHING.

Can we avoid the use of the patented technology in RPL?  Should we?  = Do we want = to?

I think we = can, want to, and = should.

Phil
= --Apple-Mail-103-85865787-- From emmanuel.baccelli@gmail.com Wed Jan 20 09:31:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E223A696F for ; Wed, 20 Jan 2010 09:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZSX5MegyUPv for ; Wed, 20 Jan 2010 09:31:57 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id D4DFC3A6A15 for ; Wed, 20 Jan 2010 09:31:56 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so1119769eye.51 for ; Wed, 20 Jan 2010 09:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=Vs7RO5099FrIClvyPo1Ys1oOJA0XOpHsb8egHnRYtOc=; b=dFyNNowZiK64eVIoZ0O+okGHCtwy2abEuzNmux3HXWlsbUPkccCITuWszR8NThKv07 +ovF4xPAyGUOAguxEPkr3jJKnC8gQcPgcS0ke5Mov7geHvNKI+qkjsvWVKAnNbZ5wtWR NRxlu+sh/YpLbYB58exWEvU7XeFC9emSgVQcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=l/ihMSQdCUEZzXX/nVWRhJlLVDulrcXkUTYle+Aq6J5r84ybdnVHwbOARJrB3iz3gV j7afoxG2Eetg5VKQzIMC+MXDUmQsd4qQpoDgDE93ain5FPNjDKvVuLgeE0j+tenhY84r tLHrhczjJwfXoVLcOn3U6V8les+0W7FAE7dbY= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.41.199 with SMTP id p7mr1240835ebe.39.1264008709450; Wed, 20 Jan 2010 09:31:49 -0800 (PST) In-Reply-To: <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> References: <820482.49389.qm@web113911.mail.gq1.yahoo.com> <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> From: Emmanuel Baccelli Date: Wed, 20 Jan 2010 18:31:29 +0100 X-Google-Sender-Auth: 80ec929230e7a2ad Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=001485eb9fc41ead0f047d9bf6ed Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:31:58 -0000 --001485eb9fc41ead0f047d9bf6ed Content-Type: text/plain; charset=ISO-8859-1 I agree we should try to avoid such patent related issues. In the long run, it is probably worth spending extra time and energy to do so. Emmanuel On Wed, Jan 20, 2010 at 6:26 PM, Philip Levis wrote: > > On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > > ROLLers, > Did anyone see the Cisco announcement about IPR in RPL. If you didn't it > was probably because it was only sent to the IETF IPR list. I don't know > why it wasn't sent to the ROLL list. If you didn't see it here is a link: > > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > I'm a bit confused and concerned that this IPR annoucement was sent so late > in the process (December 3). Given that Cisco folks were working on the > design team from the beginning why did it take so long for cisco to identify > the IPR. We are now so late in the design and development that it would be > nearly impossible for us to figure out how avoid this patent. > > There is a free license to use the patent in RPL so long as you and your > company doesn't sue Cisco over ANY other patent for ANYTHING. > > Can we avoid the use of the patented technology in RPL? Should we? Do we > want to? > > > I think we can, want to, and should. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001485eb9fc41ead0f047d9bf6ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree we should try to avoid such patent related issues. In the long run,= it is probably worth spending extra time and energy to do so.
Emmanuel=



On Wed, Jan 20, = 2010 at 6:26 PM, Philip Levis <pal@cs.stanford.edu> wrote:

On Jan 18, 2010, at 9:51 AM, Ietf = Roll wrote:

ROLLers,=A0 Did anyone see the Cisco announcement about IPR in RPL.=A0 If you didn= 't it was probably because it was only sent to the IETF IPR list.=A0 I = don't know why it wasn't sent to the ROLL list.=A0 If you didn'= t see it here is a link:

http://www.ietf.org/mail-archive/web/ipr-ann= ounce/current/msg00167.html

I'm a bit confused and concerned= that this IPR annoucement was sent so late in the process (December 3).=A0= Given that Cisco folks were working on the design team from the beginning = why did it take so long for cisco to identify the IPR.=A0 We are now so lat= e in the design and development that it would be nearly impossible for us t= o figure out how avoid this patent.

There is a free license to use the patent in RPL so long as you and you= r company doesn't sue Cisco over ANY other patent for ANYTHING.

= Can we avoid the use of the patented technology in RPL?=A0 Should we?=A0 Do we wa= nt to?

I think we can, want to, and should.

Phil

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


--001485eb9fc41ead0f047d9bf6ed-- From alexandru.petrescu@gmail.com Wed Jan 20 09:42:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354483A6A7A for ; Wed, 20 Jan 2010 09:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBesZikUVMGr for ; Wed, 20 Jan 2010 09:42:11 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id CEE313A6403 for ; Wed, 20 Jan 2010 09:42:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0KHg5FH019251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jan 2010 18:42:05 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0KHg5HX026282 for ; Wed, 20 Jan 2010 18:42:05 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0KHg5sP019842 for ; Wed, 20 Jan 2010 18:42:05 +0100 Message-ID: <4B57406C.7080304@gmail.com> Date: Wed, 20 Jan 2010 18:42:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: roll@ietf.org References: <820482.49389.qm@web113911.mail.gq1.yahoo.com> <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> In-Reply-To: <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:42:12 -0000 Le 20/01/2010 18:26, Philip Levis a écrit : > > On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > >> ROLLers, Did anyone see the Cisco announcement about IPR in RPL. >> If you didn't it was probably because it was only sent to the IETF >> IPR list. I don't know why it wasn't sent to the ROLL list. If you >> didn't see it here is a link: >> >> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >> >> >> >> I'm a bit confused and concerned that this IPR annoucement was >> sent so late in the process (December 3). Given that Cisco folks >> were working on the design team from the beginning why did it take >> so long for cisco to identify the IPR. We are now so late in the >> design and development that it would be nearly impossible for us >> to figure out how avoid this patent. >> >> There is a free license to use the patent in RPL so long as you >> and your company doesn't sue Cisco over ANY other patent for >> ANYTHING. >> >> Can we avoid the use of the patented technology in RPL? Should we? >> Do we want to? >> > > I think we can, want to, and should. I don't think we can - it's too late. We can't now discard the DT output and documents. Also, I don't think we want to avoid the use of patented technology in RPL. The IPR statements were on this list as early as April 2009. Since then work was ongoing showing high interest from many parties. That says we didn't want to. Or maybe we have changed mind recently? Or maybe we want to dissect the RPL document, identify the IPRed parts and remove them? Alex > > Phil > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Wed Jan 20 09:57:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E803A687B for ; Wed, 20 Jan 2010 09:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eDrDeQGMce3 for ; Wed, 20 Jan 2010 09:57:29 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 3FBDB3A6403 for ; Wed, 20 Jan 2010 09:57:29 -0800 (PST) Received: from mail-qy0-f188.google.com ([209.85.221.188]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NXeo1-0002J6-2g for roll@ietf.org; Wed, 20 Jan 2010 09:57:25 -0800 Received: by qyk26 with SMTP id 26so1991784qyk.5 for ; Wed, 20 Jan 2010 09:57:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.50.11 with SMTP id x11mr183421qaf.248.1264009840085; Wed, 20 Jan 2010 09:50:40 -0800 (PST) In-Reply-To: <4B57406C.7080304@gmail.com> References: <820482.49389.qm@web113911.mail.gq1.yahoo.com> <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> <4B57406C.7080304@gmail.com> From: Omprakash Gnawali Date: Wed, 20 Jan 2010 09:50:20 -0800 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:57:30 -0000 On Wed, Jan 20, 2010 at 9:42 AM, Alexandru Petrescu wrote: > Le 20/01/2010 18:26, Philip Levis a =E9crit : >> >> On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: >> >>> ROLLers, Did anyone see the Cisco announcement about IPR in RPL. >>> If you didn't it was probably because it was only sent to the IETF >>> IPR list. I don't know why it wasn't sent to the ROLL list. If you >>> didn't see it here is a link: >>> >>> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>> >>> >>> >>> =A0I'm a bit confused and concerned that this IPR annoucement was >>> sent so late in the process (December 3). Given that Cisco folks >>> were working on the design team from the beginning why did it take >>> so long for cisco to identify the IPR. We are now so late in the >>> design and development that it would be nearly impossible for us >>> to figure out how avoid this patent. >>> >>> There is a free license to use the patent in RPL so long as you >>> and your company doesn't sue Cisco over ANY other patent for >>> ANYTHING. >>> >>> Can we avoid the use of the patented technology in RPL? Should we? >>> Do we want to? >>> >> >> I think we can, want to, and should. > > I don't think we can - it's too late. =A0We can't now discard the DT > output and documents. > > Also, I don't think we want to avoid the use of patented technology in > RPL. =A0The IPR statements were on this list as early as April 2009. > Since then work was ongoing showing high interest from many parties. > That says we didn't want to. > > Or maybe we have changed mind recently? > > Or maybe we want to dissect the RPL document, identify the IPRed parts an= d > remove them? I don't think it is too late to consider this issue. It will be great if the patented parts of RPL were clearly identified. Maybe Pascal et al. can help in doing that. - om_p From jvasseur@cisco.com Thu Jan 21 00:09:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177DA3A68BE for ; Thu, 21 Jan 2010 00:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xonKGxPC98OJ for ; Thu, 21 Jan 2010 00:09:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 19CA93A6884 for ; Thu, 21 Jan 2010 00:09:48 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEOaV0utJV2c/2dsb2JhbADCKZVvhDwE X-IronPort-AV: E=Sophos;i="4.49,316,1262563200"; d="scan'208";a="81223823" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2010 08:09:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0L8972N009367; Thu, 21 Jan 2010 08:09:42 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 09:09:28 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 09:09:27 +0100 Message-Id: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jan 2010 09:09:26 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Jan 2010 08:09:27.0650 (UTC) FILETIME=[0D2CC420:01CA9A71] Cc: Adrian Farrel Subject: [Roll] Volunteer to join a small new Design Team to work on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Jan 2010 08:09:49 -0000 Dear WG, I think that we can all be very happy with our progress so far with the core specification of RPL. There are still a few open issues that we need to solve before IETF-77: * Detailed DAO mechanisms * Detailed mode of operation with multicast * Use of Flow Label versus new IPv6 header * Potential needed optimization such as DAO packing * Editorial work * ... We are on track for all of these. The one item we absolutely need to speed on is security. As you know there is a security framework document that is still not a WG document and we now need to start the work on the RPL security aspects. To that end, we will form a small Design Team with aggressive milestones, the objective being to have the RPL security item almost completed by end of Feb, ready for the IETF-77. If you have a good understanding of RPL and routing security expertise, please go back to me (unicast). Thanks. JP. From trac@tools.ietf.org Thu Jan 21 06:20:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E263A6774 for ; Thu, 21 Jan 2010 06:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIySwYlq+V8H for ; Thu, 21 Jan 2010 06:20:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7BAAC3A67DD for ; Thu, 21 Jan 2010 06:20:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NXxth-00014H-RN; Thu, 21 Jan 2010 06:20:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 21 Jan 2010 14:20:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/23 Message-ID: <055.8cd7d82a653733e971efd9d86758435d@tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #23: OCP Object X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 14:20:42 -0000 #23: OCP Object --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- This is a minor point but we need to correct some inconsistency. As pointed out in the metric-ID, the OCP object is a sub-option within the DIO Base Option. This must be reflected in Section 6.1.3.1.1.4 of the RPL ID: 6.1.3.1.1.4. DAG Metric Container The DAG Metric Container suboption may be aligned as necessary to support its contents. Its format is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Type = 2 | Container Length | DAG Metric Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 8: DAG Metric Container The DAG Metric Container is used to report aggregated path metrics along the DODAG. The DAG Metric Container may contain a number of discrete node, link, and aggregate path metrics as chosen by the implementer. The Container Length field contains the length in octets of the DAG Metric Data. The order, content, and coding of the DAG Metric Container data is as specified in [ Internet-Draft Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: "JeongGil Ko (John)" In-Reply-To: Date: Thu, 21 Jan 2010 13:13:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820482.49389.qm@web113911.mail.gq1.yahoo.com> <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> <4B57406C.7080304@gmail.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:15:42 -0000 I agree that we should try find a way to avoid these patent issues. = However, at this point, with the given information, its hard to locate = the patented parts though :( -John On Jan 20, 2010, at 9:50 AM, Omprakash Gnawali wrote: > On Wed, Jan 20, 2010 at 9:42 AM, Alexandru Petrescu > wrote: >> Le 20/01/2010 18:26, Philip Levis a =E9crit : >>>=20 >>> On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: >>>=20 >>>> ROLLers, Did anyone see the Cisco announcement about IPR in RPL. >>>> If you didn't it was probably because it was only sent to the IETF >>>> IPR list. I don't know why it wasn't sent to the ROLL list. If you >>>> didn't see it here is a link: >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>>>=20 >>>>=20 >>>>=20 >>>> I'm a bit confused and concerned that this IPR annoucement was >>>> sent so late in the process (December 3). Given that Cisco folks >>>> were working on the design team from the beginning why did it take >>>> so long for cisco to identify the IPR. We are now so late in the >>>> design and development that it would be nearly impossible for us >>>> to figure out how avoid this patent. >>>>=20 >>>> There is a free license to use the patent in RPL so long as you >>>> and your company doesn't sue Cisco over ANY other patent for >>>> ANYTHING. >>>>=20 >>>> Can we avoid the use of the patented technology in RPL? Should we? >>>> Do we want to? >>>>=20 >>>=20 >>> I think we can, want to, and should. >>=20 >> I don't think we can - it's too late. We can't now discard the DT >> output and documents. >>=20 >> Also, I don't think we want to avoid the use of patented technology = in >> RPL. The IPR statements were on this list as early as April 2009. >> Since then work was ongoing showing high interest from many parties. >> That says we didn't want to. >>=20 >> Or maybe we have changed mind recently? >>=20 >> Or maybe we want to dissect the RPL document, identify the IPRed = parts and >> remove them? >=20 > I don't think it is too late to consider this issue. >=20 > It will be great if the patented parts of RPL were clearly identified. > Maybe Pascal et al. can help in doing that. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jvasseur@cisco.com Fri Jan 22 03:23:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6383B3A67D9 for ; Fri, 22 Jan 2010 03:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.902 X-Spam-Level: X-Spam-Status: No, score=-9.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksAk2ASNt2RS for ; Fri, 22 Jan 2010 03:23:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5BEE03A6993 for ; Fri, 22 Jan 2010 03:23:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKkZWUutJV2a/2dsb2JhbADCWpY7hDwE X-IronPort-AV: E=Sophos;i="4.49,323,1262563200"; d="scan'208";a="81572159" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2010 11:23:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0MBMwBU031319 for ; Fri, 22 Jan 2010 11:23:07 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 12:23:05 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 12:23:04 +0100 Message-Id: <776FACA0-0AD9-444F-B94D-FAE111B39505@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Fri, 22 Jan 2010 12:23:03 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jan 2010 11:23:04.0630 (UTC) FILETIME=[43D8FD60:01CA9B55] Subject: [Roll] Fwd: RFC 5706 on Guidelines for Considering Operations and Management ofNew Protocols and Protocol Extensions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Jan 2010 11:23:13 -0000 Please look at it. >> A new Request for Comments is now available in online RFC libraries. >> >> RFC 5706 >> >> Title: Guidelines for Considering Operations and >> Management of New Protocols and Protocol >> Extensions >> Author: D. Harrington >> Status: Informational >> Date: November 2009 >> Mailbox: ietfdbh@comcast.net >> Pages: 35 >> Characters: 82165 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-opsawg-operations-and-management-09.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc5706.txt >> >> New protocols or protocol extensions are best designed with due >> consideration of the functionality needed to operate and manage the >> protocols. Retrofitting operations and management is sub-optimal. >> The purpose of this document is to provide guidance to authors and >> reviewers of documents that define new protocols or protocol >> extensions regarding aspects of operations and management that should >> be considered. This memo provides information for the Internet >> community. >> >> This document is a product of the Operations and Management Area >> Working >> Group Working Group of the IETF. >> >> INFORMATIONAL: This memo provides information for the Internet >> community. >> It does not specify an Internet standard of any kind. Distribution of >> this memo is unlimited. > From ietfroll@yahoo.com Fri Jan 22 14:38:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7D63A67DF for ; Fri, 22 Jan 2010 14:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksUDJoi5d576 for ; Fri, 22 Jan 2010 14:38:58 -0800 (PST) Received: from n5-vm0.bullet.mail.gq1.yahoo.com (n5-vm0.bullet.mail.gq1.yahoo.com [67.195.8.62]) by core3.amsl.com (Postfix) with SMTP id BA9723A677C for ; Fri, 22 Jan 2010 14:38:58 -0800 (PST) Received: from [67.195.9.82] by n5.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:38:52 -0000 Received: from [67.195.9.104] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:38:52 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:38:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 95375.38271.bm@omp108.mail.gq1.yahoo.com Received: (qmail 38992 invoked by uid 60001); 22 Jan 2010 22:38:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264199932; bh=N5GUJRE/PwC+jSmsdfkCbnJMV6EtKcxr6j80eRubBf4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mcIUuzgW86vwqRuPsJZgZ238g7xHrulNoLcPp4mSl0b7hUjsvbXb5ZhlnET4cLr7jjXLlzMsRgiOI4k4WwH1RRRz92t5aUiPdeWCNqsUspWg9uuNlSH8b+9FVzcfZRsOzbRwlObpkhull8Tg89P/oqgjNpsPwyjvQkevgg+2+5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ox2nSYa0OshZUStf++GCMzFUEUiYle4LFzlCngmTm8xY3jhmo66VToTQxpaWFueTpkf0iL2y6nvn56iCPrDafgZXCeyEE6LnVOA079GZKQT6WuptKquUHrf/1q+F3tN089tHVkEOXoQdsL2dDyloWJsB37YjgF3lwzxJ9E5XpYc=; Message-ID: <15321.37888.qm@web113909.mail.gq1.yahoo.com> X-YMail-OSG: bXPyTNgVM1npVGYjFDY6iDE9_HBI0LY06oRErfmXOwJnXMXZ.bYqBTcC8IiNHM7WOpy0_wvhKKwKbNqpQA8.NNe72Rj59DS6AroXS4b1DH3IxGIgdobi0VmF8XAO1AyO2sstJJX8Icea87Swv3U5lxvpD4QmVn2sY5ismkPNS7huKcLu7jdWVu.1BHpSIOPLuEIz4yTyO0PLojaWt_3PwD3.EG1xdJ9doXlHci_YkGylTTlLp0EDC1oXUEtSFrFLRHHlIUhw5Bz4E3RR0by3bYAanzLk_yI86MmTbtMqr57loq320q1U0kfu2xfVV4AO6ZgK0LJDn6q5mJQttgh5rp3dBW8d9YsjXp4_vWAtLQ_r_I26QQLHMfIeAHbEmMc- Received: from [209.62.95.170] by web113909.mail.gq1.yahoo.com via HTTP; Fri, 22 Jan 2010 14:38:51 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Fri, 22 Jan 2010 14:38:51 -0800 (PST) From: Ietf Roll To: roll@ietf.org, Omprakash Gnawali In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Jan 2010 22:38:59 -0000 Do we know how any of these apply to RPL? What applies to what parts of RP= L? What can we change in RPL to avoid these patents? - RAV --- On Tue, 1/19/10, Omprakash Gnawali wrote: > From: Omprakash Gnawali > Subject: Re: [Roll] RPL Patents > To: roll@ietf.org > Date: Tuesday, January 19, 2010, 10:47 PM > Here is a list of patents mentioned > in the IPR announcement: >=20 > 7,190,678: > Arrangement for router attachments between roaming mobile > routers in a > clustered network > Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; > Patrick (Cagnes > sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David > Charlton > (Reading, GB) > http://www.google.com/patents?vid=3DUSPAT7190678 >=20 > 7,203,175: > Arrangement for router attachments between roaming mobile > routers in a > mobile network > Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; > Patrick (Cagnes > sur Mer, FR), Molteni; Marco (Antibes, FR), Forster; David > Charlton > (Reading, GB) > http://www.google.com/patents?vid=3DUSPAT7203175 >=20 > 7,209,978: > Arrangement in a router of a mobile network for optimizing > use of > messages carrying reverse routing headers > Thubert; Pascal (La Colle sur Loup, FR), Molteni; Marco > (Antibes, FR), > Wetterwald; Patrick (Cagnes sur Mer, FR), Auerbach; David > (Biot, FR) > http://www.google.com/patents?vid=3DUSPAT7209978 >=20 > 7,366,111: > Arrangement for providing optimized connections between > peer routers > in a tree-based ad hoc mobile network > Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; > Patrick (Mouans > Sartoux, FR), Ribiere; Vincent Jean (Biot, FR), > Levy-Abegnoli; Eric M. > (Valbonne, FR) > http://www.google.com/patents?vid=3DUSPAT7366111 >=20 > 7,428,221: > Arrangement for providing network prefix information from > attached > mobile routers to a clusterhead in a tree-based ad hoc > mobile network > Thubert; Pascal (La Colle sur Loup, FR), Wetterwald; > Patrick (Mouans > Sartoux, FR), Molteni; Marco (Antibes, FR), Moon; Billy G. > (Cary, NC) > http://www.google.com/patents?vid=3DUSPAT7428221 >=20 > - om_p >=20 > On Tue, Jan 19, 2010 at 2:04 PM, Ietf Roll > wrote: > > ROLLers, > > =A0Did anyone see the Cisco announcement about IPR in > RPL. =A0If you didn't it was probably because it was only > sent to the IETF IPR list. =A0I don't know why it wasn't sent > to the ROLL list. =A0If you didn't see it here is a link: > > > > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > > > I'm a bit confused and concerned that this IPR > annoucement was sent so late in the process (December 3) - > given that Cisco folks were working on the design team from > the beginning. =A0We are now so late in the design and > development that it would be nearly impossible for us to > figure out how avoid this patent. > > > > There is a free license to use the patent in RPL so > long as you and your company doesn't sue Cisco over ANY > other patent for ANYTHING. > > > > Can we avoid the use of the patented technology in > RPL? =A0Should we? =A0Do we want to? > > > > Did this IPR announcement come too late? > > > > =A0 =A0Rav > > > > > > > > > > _______________________________________________ > > 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 > =0A=0A=0A From ietfroll@yahoo.com Fri Jan 22 14:46:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF25D3A68B3 for ; Fri, 22 Jan 2010 14:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guN-sY6XYAYe for ; Fri, 22 Jan 2010 14:46:27 -0800 (PST) Received: from n16b.bullet.mail.mud.yahoo.com (n16b.bullet.mail.mud.yahoo.com [68.142.207.237]) by core3.amsl.com (Postfix) with SMTP id CCCE43A677C for ; Fri, 22 Jan 2010 14:46:26 -0800 (PST) Received: from [68.142.194.244] by n16.bullet.mail.mud.yahoo.com with NNFMP; 22 Jan 2010 22:46:21 -0000 Received: from [67.195.9.83] by t2.bullet.mud.yahoo.com with NNFMP; 22 Jan 2010 22:46:21 -0000 Received: from [67.195.9.111] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:46:20 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:46:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880692.4285.bm@omp115.mail.gq1.yahoo.com Received: (qmail 18104 invoked by uid 60001); 22 Jan 2010 22:46:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264200380; bh=ttH+jDoWIxGe+0RSbZdPyxWdPPzDTu8VZiHd7vqKZhQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Uh6j1eRNTs3i//KaR4Q0NfCT0FBXQQY3ltmPRQrUCcQiNT3s5xb5knWXyXH2eiy+M8M2xKpcwmtLyTyqSnoEZLx6AVM2qyf9/0cmSDYUAQaZPehprg7YiBf1HcJjo+3ALfYXgX2y3GDNu1iH3UWnFNWyAjXzH9ylzLuCfCRXrEY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HbJ2BiZfcrpqQQaw9IA7oY+kj4hbilWUH3liZMX5OB/grreQDkKM4qBTbN3edL8z/A4FhN2TF/nLbp72WDJflarJuWqQ0G1hl6rwHl6l49na28ALGW4TkFt6+kiLkBRvE5WRNtcIFdGasY7Yt5dvfwgminKXHYcalrG+6aFV+/I=; Message-ID: <787016.17576.qm@web113919.mail.gq1.yahoo.com> X-YMail-OSG: lXWdWl0VM1lZk6vmO_OO7tU4NGUBEwkx3ZhVMBx7lrCVHX0d.Ca30AgjCkt4u09e07kTvECMJGy4n0zPl5Kux2MtbYkb6SpOhjkncda0zUXBkEvsVkVwQo5Jx2J9bhMXSEb2N0v9VRPgvFGMkFZgW_0bLNw6ECxymivUENxWcHfvxlGwRW1js_f0WePZvEUfzEgnGs8bdsoTGwANxjLInesD8Xu4smfg4jQc9QEUOJF7JMK6plgNIy1GwaUsRV6F1Rp4Kicl9Tb7t3bTXWnAQaqtJ0KLZCqWrQqD Received: from [209.62.95.170] by web113919.mail.gq1.yahoo.com via HTTP; Fri, 22 Jan 2010 14:46:20 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Fri, 22 Jan 2010 14:46:20 -0800 (PST) From: Ietf Roll To: roll@ietf.org, "Pascal Thubert \(pthubert\)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Jan 2010 22:46:28 -0000 I don't think that is at all true. The original IPR statement published wa= s applicable only to draft-thubert-roll-fundamentals. There was no indicat= ion for many months that the IPR statment made about draft-thubert-roll-fun= damentals was at all applicable to the work coming from the RPL DT. I think it is very unfortunate that this information was not made available= to the working long long ago so that before investing these many months of= effort we could have understood that the design was encumbered with Cisco = intellectual property. You were on the DT, so I don't understand why the IPR statement about the o= utput of the DT was not made months ago and also why when the IPR was publi= shed, why didn't anyone send it to the ROLL list??? - Rav --- On Wed, 1/20/10, Pascal Thubert (pthubert) wrote: > From: Pascal Thubert (pthubert) > Subject: RE: [Roll] RPL Patents > To: "Ietf Roll" , roll@ietf.org > Date: Wednesday, January 20, 2010, 6:58 AM > Hi: >=20 > Just to make things straight, Cisco published to IETF and > announced that > IPR on April 16th to the ROLL ML: > http://www.ietf.org/mail-archive/web/roll/current/msg01181.html >=20 >=20 > There has been some administrative delay porting the > message to the RPL > draft, but the content is basically the same. >=20 > Cheers; >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] > On Behalf Of > Ietf Roll > Sent: mardi 19 janvier 2010 23:05 > To: roll@ietf.org > Subject: [Roll] RPL Patents >=20 > ROLLers, > =A0 Did anyone see the Cisco announcement about IPR in > RPL.=A0 If you didn't > it was probably because it was only sent to the IETF IPR > list.=A0 I don't > know why it wasn't sent to the ROLL list.=A0 If you > didn't see it here is > a link: >=20 > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >=20 > I'm a bit confused and concerned that this IPR annoucement > was sent so > late in the process (December 3) - given that Cisco folks > were working > on the design team from the beginning.=A0 We are now so > late in the design > and development that it would be nearly impossible for us > to figure out > how avoid this patent. >=20 > There is a free license to use the patent in RPL so long as > you and your > company doesn't sue Cisco over ANY other patent for > ANYTHING. >=20 > Can we avoid the use of the patented technology in > RPL?=A0 Should we?=A0 Do > we want to? >=20 > Did this IPR announcement come too late? >=20 > =A0 =A0 Rav >=20 >=20 > =A0 =A0 =A0=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =0A=0A=0A From ietfroll@yahoo.com Fri Jan 22 14:49:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636863A6944 for ; Fri, 22 Jan 2010 14:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2mDhfTFlf-c for ; Fri, 22 Jan 2010 14:49:32 -0800 (PST) Received: from n3b.bullet.mail.ac4.yahoo.com (n3b.bullet.mail.ac4.yahoo.com [76.13.13.73]) by core3.amsl.com (Postfix) with SMTP id 67E103A677C for ; Fri, 22 Jan 2010 14:49:32 -0800 (PST) Received: from [76.13.13.26] by n3.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2010 22:49:25 -0000 Received: from [67.195.9.81] by t3.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2010 22:49:25 -0000 Received: from [67.195.9.109] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:49:25 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:49:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 224422.66426.bm@omp113.mail.gq1.yahoo.com Received: (qmail 96990 invoked by uid 60001); 22 Jan 2010 22:49:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264200565; bh=6KQF5lB9+saKRgA5V6yneewg59TLUkGidwAlaxrDUzE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GxTAunPRMidNslc3bKKEnE6qYXwt9LUe+Z77/TuTfdyydyWnYhrKfn1CYSHgr6CVV4myUaUwXTf7SArzuyHtU6XsmMZg0PbWOkuohlPvmseoa6adccO6mSB4oqwLZUTokqwwn9XNSU4eQGkI+MVfJ+np8dIt5M9Yqd3GlYOKM+s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o/Dr6kLK8blVi51Dr1xTuHHqvpUVhmVoxwPWQ5gGx8rnKeD4+7sn3T1JxKDSLWhnw6ZAFg6rTmcWSSLGakHSFk5Y2THk56bTJIS5PHJkjA/YgXvT38jUAubIj1duNpNzGk2HB18uYwkb6Mt+enxQUO5DDUAoi+SzYXyBjY53Srk=; Message-ID: <143847.96883.qm@web113911.mail.gq1.yahoo.com> X-YMail-OSG: NcJSSsEVM1mXWHfeMYCgZ.BoWfPj5XwXhbxTWS23hFkhc4XnxLvn2de._wfLSn1lOuRKmaGd93BkzbbDzY3Gh9WjD.5SRlSRtixT4ATZxp_nHMf1Yd7ZG2WOGOzWuknUKS92ZVCjpPyMyUQZ2yveDyjFUgnuF7zIJrOdC75QJUz33.SBHKCTwrgyj05zlTLsZeS8dnqnLAWiP656m74_JAV2l0qlgNE.MD.JPar7ylqVe6c8zVpQmKLbqOXe1FH907oPDcXkSTOG_085G0H7e3ZQ4oAeloyd1eXD Received: from [209.62.95.170] by web113911.mail.gq1.yahoo.com via HTTP; Fri, 22 Jan 2010 14:49:25 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Fri, 22 Jan 2010 14:49:25 -0800 (PST) From: Ietf Roll To: Philip Levis In-Reply-To: <44BD33AB-2A60-439E-97B5-5E2B1E490989@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:49:33 -0000 Mr Levis, I agree, but how do we do so? What parts of these patents are using in R= PL and how do we start the process to extricate RPL from the patents. - RAV --- On Wed, 1/20/10, Philip Levis wrote: > From: Philip Levis > Subject: Re: [Roll] Patents on RPL > To: "Ietf Roll" > Cc: roll@ietf.org > Date: Wednesday, January 20, 2010, 5:26 PM >=20 > On Jan 18, 2010, at 9:51 AM, Ietf Roll > wrote: > ROLLers, > =A0 Did anyone see the Cisco announcement about IPR in > RPL.=A0 If you didn't it was probably because it was > only sent to the IETF IPR list.=A0 I don't know why > it wasn't sent to the ROLL list.=A0 If you didn't > see it here is a link: >=20 > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >=20 > I'm a bit confused and concerned that this IPR > annoucement was sent so late in the process (December > 3).=A0 Given that Cisco folks were working on the design > team from the beginning why did it take so long for cisco to > identify the IPR.=A0 We are now so late in the design and > development that it would be nearly impossible for us to > figure out how avoid this patent. >=20 > There is a free license to use the patent in RPL so long as > you and your company doesn't sue Cisco over ANY other > patent for ANYTHING. >=20 > Can we > avoid the use of the patented technology in RPL?=A0 > Should we?=A0 Do we want to? >=20 > I think we can, want to, and should. > Phil=0A=0A=0A From ietfroll@yahoo.com Fri Jan 22 14:53:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979293A67E2 for ; Fri, 22 Jan 2010 14:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvB1PgbrVt7i for ; Fri, 22 Jan 2010 14:53:17 -0800 (PST) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by core3.amsl.com (Postfix) with SMTP id BEA933A67DF for ; Fri, 22 Jan 2010 14:53:17 -0800 (PST) Received: from [216.252.122.218] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 22 Jan 2010 22:52:07 -0000 Received: from [67.195.9.81] by t3.bullet.sp1.yahoo.com with NNFMP; 22 Jan 2010 22:52:07 -0000 Received: from [67.195.9.110] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:52:07 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 22 Jan 2010 22:52:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 480514.22387.bm@omp114.mail.gq1.yahoo.com Received: (qmail 63194 invoked by uid 60001); 22 Jan 2010 22:52:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264200727; bh=UuLa9n+hbYcB7KGjK8qcA2RH4tzfpARznMquSVfm1mw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CrvazUpyUSxLGzW1z4Ca76By5KytNwN1+TqE6gp257u1pbJcKS5iVQq67EJb3YzHr/vdighzBVAC0iiNnY6vVQYoDimQV+sP+bpRF2icTnG9dBjP1zmNKNVKpe75KiphC95tEtL8Qs3t4OUH2pPx5cuD8zwBx5Yz9ZTugtAOLLE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=otPSSNqTRN1Q9Lcu8rQMrdx+5HhcVQMyYl5KaWUNg3q+q6V5HxTpuV844O4yqjfF3YsQdin8Qd9Gridi5q460dKJ/tCvOv46nMksU7JtcGYJ6mCaP6rt8Wv3TYOuzYMsSyyErJ22HnyIPcyD+LFlshEF8pQMfxgD4L/SzzLTHyE=; Message-ID: <397245.61314.qm@web113920.mail.gq1.yahoo.com> X-YMail-OSG: X6EUWh8VM1l.c2ntnQ6nz1aj1mB0FHdc_eu66cSFBJAmhg8Taw0UpfTNN7UlZojNssHa9sMCN4tIC_wRSjaF4sWPneJoGy1rnnkI9sWqgaM0VwParNAWEJI6zkjnqdiEeFw40rv3Ds7VhhyGx.BhdiaWbi7kG6jMvtbHPf_fRFwpnnGA.oRfmv47n41aWPtEHYiyf9MXoAVs317zhMchkCW.O9FroTRU9MK4c5Bu82tIsGaMCWOCJUn2PRV4K5n8M8iQzfSKYDYqvX3unvO57ai0_097SXWI.muc Received: from [209.62.95.170] by web113920.mail.gq1.yahoo.com via HTTP; Fri, 22 Jan 2010 14:52:07 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Fri, 22 Jan 2010 14:52:07 -0800 (PST) From: Ietf Roll To: Alexandru Petrescu , Omprakash Gnawali In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:53:18 -0000 Can Mr. Thubert identify the issues in RPL? --- On Wed, 1/20/10, Omprakash Gnawali wrote: > From: Omprakash Gnawali > Subject: Re: [Roll] Patents on RPL > To: "Alexandru Petrescu" > Cc: roll@ietf.org > Date: Wednesday, January 20, 2010, 5:50 PM > On Wed, Jan 20, 2010 at 9:42 AM, > Alexandru Petrescu > > wrote: > > Le 20/01/2010 18:26, Philip Levis a =E9crit : > >> > >> On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > >> > >>> ROLLers, Did anyone see the Cisco announcement > about IPR in RPL. > >>> If you didn't it was probably because it was > only sent to the IETF > >>> IPR list. I don't know why it wasn't sent to > the ROLL list. If you > >>> didn't see it here is a link: > >>> > >>> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.ht= ml > >>> > >>> > >>> > >>> =A0I'm a bit confused and concerned that this > IPR annoucement was > >>> sent so late in the process (December 3). > Given that Cisco folks > >>> were working on the design team from the > beginning why did it take > >>> so long for cisco to identify the IPR. We are > now so late in the > >>> design and development that it would be nearly > impossible for us > >>> to figure out how avoid this patent. > >>> > >>> There is a free license to use the patent in > RPL so long as you > >>> and your company doesn't sue Cisco over ANY > other patent for > >>> ANYTHING. > >>> > >>> Can we avoid the use of the patented > technology in RPL? Should we? > >>> Do we want to? > >>> > >> > >> I think we can, want to, and should. > > > > I don't think we can - it's too late. =A0We can't now > discard the DT > > output and documents. > > > > Also, I don't think we want to avoid the use of > patented technology in > > RPL. =A0The IPR statements were on this list as early > as April 2009. > > Since then work was ongoing showing high interest from > many parties. > > That says we didn't want to. > > > > Or maybe we have changed mind recently? > > > > Or maybe we want to dissect the RPL document, identify > the IPRed parts and > > remove them? >=20 > I don't think it is too late to consider this issue. >=20 > It will be great if the patented parts of RPL were clearly > identified. > Maybe Pascal et al. can help in doing that. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =0A=0A=0A From pthubert@cisco.com Sun Jan 24 23:31:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DC43A6814 for ; Sun, 24 Jan 2010 23:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl0yzkVk7GCZ for ; Sun, 24 Jan 2010 23:31:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E9CB13A67B0 for ; Sun, 24 Jan 2010 23:31:58 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIzXXEutJV2Z/2dsb2JhbACPZ7EElUKEOwQ X-IronPort-AV: E=Sophos;i="4.49,338,1262563200"; d="scan'208";a="472244640" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 25 Jan 2010 07:32:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0P7W35H001699; Mon, 25 Jan 2010 07:32:03 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 08:32:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 08:31:58 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0114402E@XMB-AMS-107.cisco.com> In-Reply-To: <787016.17576.qm@web113919.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Patents Thread-Index: AcqbtNQytIe8OBL0QmCKM0NymLx+pwB2x2bQ References: <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> <787016.17576.qm@web113919.mail.gq1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Ietf Roll" , X-OriginalArrivalTime: 25 Jan 2010 07:32:03.0207 (UTC) FILETIME=[7D08F170:01CA9D90] Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2010 07:31:59 -0000 Hum... The IPR listed has not changed. The broad operations that are covered by = the IPR are the same in both drafts. People who actually contribute to this work can see that, and go beyond = names. Names change all the time anyway. Sorry you don't. What's your interest then? Pascal -----Original Message----- From: Ietf Roll [mailto:ietfroll@yahoo.com]=20 Sent: vendredi 22 janvier 2010 23:46 To: roll@ietf.org; Pascal Thubert (pthubert) Subject: RE: [Roll] RPL Patents I don't think that is at all true. The original IPR statement published = was applicable only to draft-thubert-roll-fundamentals. There was no = indication for many months that the IPR statment made about = draft-thubert-roll-fundamentals was at all applicable to the work coming = from the RPL DT. I think it is very unfortunate that this information was not made = available to the working long long ago so that before investing these = many months of effort we could have understood that the design was = encumbered with Cisco intellectual property. You were on the DT, so I don't understand why the IPR statement about = the output of the DT was not made months ago and also why when the IPR = was published, why didn't anyone send it to the ROLL list??? - Rav --- On Wed, 1/20/10, Pascal Thubert (pthubert) = wrote: > From: Pascal Thubert (pthubert) > Subject: RE: [Roll] RPL Patents > To: "Ietf Roll" , roll@ietf.org > Date: Wednesday, January 20, 2010, 6:58 AM > Hi: >=20 > Just to make things straight, Cisco published to IETF and > announced that > IPR on April 16th to the ROLL ML: > http://www.ietf.org/mail-archive/web/roll/current/msg01181.html >=20 >=20 > There has been some administrative delay porting the > message to the RPL > draft, but the content is basically the same. >=20 > Cheers; >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] > On Behalf Of > Ietf Roll > Sent: mardi 19 janvier 2010 23:05 > To: roll@ietf.org > Subject: [Roll] RPL Patents >=20 > ROLLers, > =A0 Did anyone see the Cisco announcement about IPR in > RPL.=A0 If you didn't > it was probably because it was only sent to the IETF IPR > list.=A0 I don't > know why it wasn't sent to the ROLL list.=A0 If you > didn't see it here is > a link: >=20 > = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >=20 > I'm a bit confused and concerned that this IPR annoucement > was sent so > late in the process (December 3) - given that Cisco folks > were working > on the design team from the beginning.=A0 We are now so > late in the design > and development that it would be nearly impossible for us > to figure out > how avoid this patent. >=20 > There is a free license to use the patent in RPL so long as > you and your > company doesn't sue Cisco over ANY other patent for > ANYTHING. >=20 > Can we avoid the use of the patented technology in > RPL?=A0 Should we?=A0 Do > we want to? >=20 > Did this IPR announcement come too late? >=20 > =A0 =A0 Rav >=20 >=20 > =A0 =A0 =A0=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 =20 From pthubert@cisco.com Sun Jan 24 23:39:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660043A6782 for ; Sun, 24 Jan 2010 23:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MscDaIjs3+PT for ; Sun, 24 Jan 2010 23:39:04 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 84E803A677D for ; Sun, 24 Jan 2010 23:39:04 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANvZXEutJV2a/2dsb2JhbACPZ7EClUKEOwQ X-IronPort-AV: E=Sophos;i="4.49,338,1262563200"; d="scan'208";a="472246924" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 25 Jan 2010 07:39:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0P7cjPm018193; Mon, 25 Jan 2010 07:39:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 08:39:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 08:38:56 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01144033@XMB-AMS-107.cisco.com> In-Reply-To: <787016.17576.qm@web113919.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Patents Thread-Index: AcqbtNQytIe8OBL0QmCKM0NymLx+pwB3D6og References: <6A2A459175DABE4BB11DE2026AA50A5D010DD4FC@XMB-AMS-107.cisco.com> <787016.17576.qm@web113919.mail.gq1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Ietf Roll" X-OriginalArrivalTime: 25 Jan 2010 07:39:00.0517 (UTC) FILETIME=[75C56550:01CA9D91] Cc: roll@ietf.org Subject: Re: [Roll] RPL Patents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2010 07:39:05 -0000 Talking about unfortunate,=20 I do not think that your email address is appropriate in this list.=20 It is actually confusing the autocompletion in my mail client, and could = end up confuse readers. I suggest you peek another one, maybe with something that would more = openly indicate your name and interests... Pascal -----Original Message----- From: Ietf Roll [mailto:ietfroll@yahoo.com]=20 Sent: vendredi 22 janvier 2010 23:46 To: roll@ietf.org; Pascal Thubert (pthubert) Subject: RE: [Roll] RPL Patents I don't think that is at all true. The original IPR statement published = was applicable only to draft-thubert-roll-fundamentals. There was no = indication for many months that the IPR statment made about = draft-thubert-roll-fundamentals was at all applicable to the work coming = from the RPL DT. I think it is very unfortunate that this information was not made = available to the working long long ago so that before investing these = many months of effort we could have understood that the design was = encumbered with Cisco intellectual property. You were on the DT, so I don't understand why the IPR statement about = the output of the DT was not made months ago and also why when the IPR = was published, why didn't anyone send it to the ROLL list??? - Rav --- On Wed, 1/20/10, Pascal Thubert (pthubert) = wrote: > From: Pascal Thubert (pthubert) > Subject: RE: [Roll] RPL Patents > To: "Ietf Roll" , roll@ietf.org > Date: Wednesday, January 20, 2010, 6:58 AM > Hi: >=20 > Just to make things straight, Cisco published to IETF and > announced that > IPR on April 16th to the ROLL ML: > http://www.ietf.org/mail-archive/web/roll/current/msg01181.html >=20 >=20 > There has been some administrative delay porting the > message to the RPL > draft, but the content is basically the same. >=20 > Cheers; >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] > On Behalf Of > Ietf Roll > Sent: mardi 19 janvier 2010 23:05 > To: roll@ietf.org > Subject: [Roll] RPL Patents >=20 > ROLLers, > =A0 Did anyone see the Cisco announcement about IPR in > RPL.=A0 If you didn't > it was probably because it was only sent to the IETF IPR > list.=A0 I don't > know why it wasn't sent to the ROLL list.=A0 If you > didn't see it here is > a link: >=20 > = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >=20 > I'm a bit confused and concerned that this IPR annoucement > was sent so > late in the process (December 3) - given that Cisco folks > were working > on the design team from the beginning.=A0 We are now so > late in the design > and development that it would be nearly impossible for us > to figure out > how avoid this patent. >=20 > There is a free license to use the patent in RPL so long as > you and your > company doesn't sue Cisco over ANY other patent for > ANYTHING. >=20 > Can we avoid the use of the patented technology in > RPL?=A0 Should we?=A0 Do > we want to? >=20 > Did this IPR announcement come too late? >=20 > =A0 =A0 Rav >=20 >=20 > =A0 =A0 =A0=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 =20 From pthubert@cisco.com Sun Jan 24 23:57:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE28C3A6767 for ; Sun, 24 Jan 2010 23:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.046 X-Spam-Level: X-Spam-Status: No, score=-8.046 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkitmlLKpWme for ; Sun, 24 Jan 2010 23:57:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A10E73A6909 for ; Sun, 24 Jan 2010 23:57:50 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB3eXEtAZnwN/2dsb2JhbADAYpVDgi+CDASNYg X-IronPort-AV: E=Sophos;i="4.49,338,1262563200"; d="scan'208";a="81800816" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2010 07:57:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0P7veni008089; Mon, 25 Jan 2010 07:57:53 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 08:57:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 08:57:31 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0114403F@XMB-AMS-107.cisco.com> In-Reply-To: <397245.61314.qm@web113920.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Patents on RPL Thread-Index: AcqbtbNmhfn1SGQRSjaYPIMk7OFokQB2V+bQ References: <397245.61314.qm@web113920.mail.gq1.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Omprakash Gnawali" X-OriginalArrivalTime: 25 Jan 2010 07:57:42.0484 (UTC) FILETIME=[1283F940:01CA9D94] Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:57:52 -0000 Hi: I think this is asking the wrong question. There are tons of IPR related = to sensor work, most of it not declared to this list. Some of it might = be claimed to apply to work we are doing or could be doing in this WG, = but the people involved simply wait for our work to complete before they = launch the attack. I'm not joking, this is known to have happened to = other SDOs and has been discussed in this ML already.=20 Do we have a strategy to avoid it? In fact, we have some. We have academic papers such as CTP that make = dates and can be used to prove prior art in court, when things go that = far. But as you figure, issued IPR announced to match the RFC is a lot = stronger deterrent; in that regard, we could and probably should = consider the cisco IPR as a counter-fire. People and organizations that = comply with the terms are not only safe from Cisco, but also a lot safer = from the rest of the existing but undeclared IPR than they would be = without the cisco IPR. The 'standard' Cisco terms are quite generous, and usually well accepted = for IETF activities. I have personally worked in other groups that have = accepted those terms, and from which actual code and products derive, = including open source implementations. I do not think that working = around our own defense and open the door to attacks from unknown parties = is the right strategy for this WG. Let us focus on delivering, time is short. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Ietf Roll Sent: vendredi 22 janvier 2010 23:52 To: Alexandru Petrescu; Omprakash Gnawali Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL Can Mr. Thubert identify the issues in RPL? --- On Wed, 1/20/10, Omprakash Gnawali wrote: > From: Omprakash Gnawali > Subject: Re: [Roll] Patents on RPL > To: "Alexandru Petrescu" > Cc: roll@ietf.org > Date: Wednesday, January 20, 2010, 5:50 PM > On Wed, Jan 20, 2010 at 9:42 AM, > Alexandru Petrescu > > wrote: > > Le 20/01/2010 18:26, Philip Levis a =E9crit : > >> > >> On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > >> > >>> ROLLers, Did anyone see the Cisco announcement > about IPR in RPL. > >>> If you didn't it was probably because it was > only sent to the IETF > >>> IPR list. I don't know why it wasn't sent to > the ROLL list. If you > >>> didn't see it here is a link: > >>> > >>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > >>> > >>> > >>> > >>> =A0I'm a bit confused and concerned that this > IPR annoucement was > >>> sent so late in the process (December 3). > Given that Cisco folks > >>> were working on the design team from the > beginning why did it take > >>> so long for cisco to identify the IPR. We are > now so late in the > >>> design and development that it would be nearly > impossible for us > >>> to figure out how avoid this patent. > >>> > >>> There is a free license to use the patent in > RPL so long as you > >>> and your company doesn't sue Cisco over ANY > other patent for > >>> ANYTHING. > >>> > >>> Can we avoid the use of the patented > technology in RPL? Should we? > >>> Do we want to? > >>> > >> > >> I think we can, want to, and should. > > > > I don't think we can - it's too late. =A0We can't now > discard the DT > > output and documents. > > > > Also, I don't think we want to avoid the use of > patented technology in > > RPL. =A0The IPR statements were on this list as early > as April 2009. > > Since then work was ongoing showing high interest from > many parties. > > That says we didn't want to. > > > > Or maybe we have changed mind recently? > > > > Or maybe we want to dissect the RPL document, identify > the IPRed parts and > > remove them? >=20 > I don't think it is too late to consider this issue. >=20 > It will be great if the patented parts of RPL were clearly > identified. > Maybe Pascal et al. can help in doing that. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Mon Jan 25 07:09:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327713A635F for ; Mon, 25 Jan 2010 07:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.084 X-Spam-Level: *** X-Spam-Status: No, score=3.084 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okOngj4-j6Ex for ; Mon, 25 Jan 2010 07:09:19 -0800 (PST) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id 4010E3A6817 for ; Mon, 25 Jan 2010 07:09:19 -0800 (PST) Received: (qmail 24250 invoked from network); 25 Jan 2010 15:09:22 -0000 Received: from adsl-67-124-201-60.dsl.sndg02.pacbell.net (d.sturek@67.124.201.60 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 25 Jan 2010 07:09:22 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: DQFeiQAVM1kxNfJiop44gsdAY.azIymE8aTJUFcq9vWgB8.Au_FZlHLTpCyx0hnt762djl9rpqRPloWQH1rTdJf05c2k7kKzKnecNg5VVDvo.nADkcxiTECG.CTIkdDnVaxTuiXUdtolxbXxeTl_81hS8c8QfZrIXsBMfmLy2n0qQqDOxelzbJMe_OM8maS5j9l_YRBvlvlou5KwmlWCehaX453LT6e9On9xgNhMiHOkCDVyAOZ4AIgfNNXs9xmhB_Hy0o9eh8LINaXCnyO7sb6a7qYFXOM80gYCux8c4M.xzEZFi0Y- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , "'Alexandru Petrescu'" , "'Omprakash Gnawali'" References: <397245.61314.qm@web113920.mail.gq1.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D0114403F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0114403F@XMB-AMS-107.cisco.com> Date: Mon, 25 Jan 2010 07:09:16 -0800 Message-ID: <008801ca9dd0$5d2821b0$17786510$@sturek@att.net> 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: AcqbtbNmhfn1SGQRSjaYPIMk7OFokQB2V+bQABAsANA= Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 15:09:20 -0000 Although I don't know the details on selection of technology for the RPL = DT, I agree with Pascal's note below. We will NOT be avoiding patents. We = will only potentially be selecting someone else's IPR that we will find out = about when we deploy. Pascal's note is correct. Other SDO's involved in mesh networking are finding issues during deployment with companies claiming to have = essential patents on mesh networking. For ROLL, I think it is actually better to know there is IPR and have = clear access to it than to design out all known IPR and find out later..... Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Sunday, January 24, 2010 11:58 PM To: Alexandru Petrescu; Omprakash Gnawali Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL Hi: I think this is asking the wrong question. There are tons of IPR related = to sensor work, most of it not declared to this list. Some of it might be claimed to apply to work we are doing or could be doing in this WG, but = the people involved simply wait for our work to complete before they launch = the attack. I'm not joking, this is known to have happened to other SDOs and = has been discussed in this ML already.=20 Do we have a strategy to avoid it? In fact, we have some. We have academic papers such as CTP that make = dates and can be used to prove prior art in court, when things go that far. = But as you figure, issued IPR announced to match the RFC is a lot stronger deterrent; in that regard, we could and probably should consider the = cisco IPR as a counter-fire. People and organizations that comply with the = terms are not only safe from Cisco, but also a lot safer from the rest of the existing but undeclared IPR than they would be without the cisco IPR. The 'standard' Cisco terms are quite generous, and usually well accepted = for IETF activities. I have personally worked in other groups that have = accepted those terms, and from which actual code and products derive, including = open source implementations. I do not think that working around our own = defense and open the door to attacks from unknown parties is the right strategy = for this WG. Let us focus on delivering, time is short. Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Ietf Roll Sent: vendredi 22 janvier 2010 23:52 To: Alexandru Petrescu; Omprakash Gnawali Cc: roll@ietf.org Subject: Re: [Roll] Patents on RPL Can Mr. Thubert identify the issues in RPL? --- On Wed, 1/20/10, Omprakash Gnawali wrote: > From: Omprakash Gnawali > Subject: Re: [Roll] Patents on RPL > To: "Alexandru Petrescu" > Cc: roll@ietf.org > Date: Wednesday, January 20, 2010, 5:50 PM > On Wed, Jan 20, 2010 at 9:42 AM, > Alexandru Petrescu > > wrote: > > Le 20/01/2010 18:26, Philip Levis a =E9crit : > >> > >> On Jan 18, 2010, at 9:51 AM, Ietf Roll wrote: > >> > >>> ROLLers, Did anyone see the Cisco announcement > about IPR in RPL. > >>> If you didn't it was probably because it was > only sent to the IETF > >>> IPR list. I don't know why it wasn't sent to > the ROLL list. If you > >>> didn't see it here is a link: > >>> > >>> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > >>> > >>> > >>> > >>> =A0I'm a bit confused and concerned that this > IPR annoucement was > >>> sent so late in the process (December 3). > Given that Cisco folks > >>> were working on the design team from the > beginning why did it take > >>> so long for cisco to identify the IPR. We are > now so late in the > >>> design and development that it would be nearly > impossible for us > >>> to figure out how avoid this patent. > >>> > >>> There is a free license to use the patent in > RPL so long as you > >>> and your company doesn't sue Cisco over ANY > other patent for > >>> ANYTHING. > >>> > >>> Can we avoid the use of the patented > technology in RPL? Should we? > >>> Do we want to? > >>> > >> > >> I think we can, want to, and should. > > > > I don't think we can - it's too late. =A0We can't now > discard the DT > > output and documents. > > > > Also, I don't think we want to avoid the use of > patented technology in > > RPL. =A0The IPR statements were on this list as early > as April 2009. > > Since then work was ongoing showing high interest from > many parties. > > That says we didn't want to. > > > > Or maybe we have changed mind recently? > > > > Or maybe we want to dissect the RPL document, identify > the IPRed parts and > > remove them? >=20 > I don't think it is too late to consider this issue. >=20 > It will be great if the patented parts of RPL were clearly > identified. > Maybe Pascal et al. can help in doing that. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Mon Jan 25 13:32:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95FBD3A6926 for ; Mon, 25 Jan 2010 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grLr6whRKBNK for ; Mon, 25 Jan 2010 13:32:53 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 8638B3A691F for ; Mon, 25 Jan 2010 13:32:53 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so379613fgg.13 for ; Mon, 25 Jan 2010 13:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=yso5+TJBJpo01/ZcT1TcYVgKkr8bT8yF0ylpgqK2oII=; b=Kae4fVIvOBqU+ZLCZWatUNHKskZNP9sk5mDPOjkC7OIc6AtWolIdopfnhupKEq/a7P WIGsBIKY0Qjjrley+ChwdX+3HfuNZhEsv6wQN0eGS7hKuuRsyfQjf7rqkrcref79GPso zG9q9D6rkcflkqeXlGD34Re0ZUUOD7o4b6TFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=kEzRUeZWqY+2yZVeAMfTQgAqSii/7CoXgefkZ3oDc2DPP6VV8z5JhDaZVdxc/CHw7O dmdRE2wPW/Wm+cB4VxGV/0u0qQXhOLDWGrtfUXfVTa10bzTs+VSx5Mrsl7x21gh4jKzf as7s4I2D5QrWmY98lZldrHW8OT1knvCtGu6Us= Received: by 10.87.35.15 with SMTP id n15mr7415729fgj.14.1264455177356; Mon, 25 Jan 2010 13:32:57 -0800 (PST) Received: from dnab4046eb.stanford.edu (DNab4046eb.Stanford.EDU [171.64.70.235]) by mx.google.com with ESMTPS id 12sm11750863fgg.22.2010.01.25.13.32.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 13:32:56 -0800 (PST) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 13:32:52 -0800 Message-Id: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] Questions while implementing RPL. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:32:54 -0000 Hi. I am in the process of trying to implement RPL with respect to the rpl = and metrics drafts. In the process, I had a few questions that was = unclear in the writeups. Maybe someone can clear them up for me :) I will take ETX as an example. Let's say our goal is to find a route = that 'minimizes' the aggregated ETX to the gateway (root of the DODAG). = The flags of the routing metric/constraint header will indicate R=3D0, = G=3D1, A=3D0x00, C=3D0, and O=3D0. When nodes send DIO messages will = include this information for nodes that receive the DIO to parse and = compute its own ETX for a specific path/parent. In this case, how would = we indicate that 'minimizing' the ETX metric is our goal?=20 On a receiving node's perspective it just received a DIO message saying = that it is including a metric and the routing object type will be 7 = (recommended for ETX; pp. 20 of [draft-ietf-roll-routing-metrics]). As a = result, the node will have different ETX values from different potential = next hops and would have to select one from them as the preferred parent = node. In the selection process, should it be already known that = minimizing the ETX is the goal (OF) at the node in compile time? Or is = there a way/scheme to infer that minimizing the ETX is the goal? To make = nodes support different OFs dynamically in-run time, having a way to = infer/notify the new OFs (goals) would be nice but I wonder if this is = interesting. If everything is given in compile time, then we can simply = make the nodes that do not recognize what to do with the OFs as leaf = nodes (as stated in the rpl draft). Thanks. -John From jvasseur@cisco.com Mon Jan 25 15:22:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610E63A691C for ; Mon, 25 Jan 2010 15:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQW8tvsGJz9u for ; Mon, 25 Jan 2010 15:22:43 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1EEDF3A691A for ; Mon, 25 Jan 2010 15:22:42 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAGi2XUuQ/uCWe2dsb2JhbACcCAEBFiQGpk2WSIQ5BI1i X-IronPort-AV: E=Sophos;i="4.49,342,1262563200"; d="scan'208";a="2768086" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 25 Jan 2010 22:52:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0PNMnDK020114; Mon, 25 Jan 2010 23:22:49 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 00:22:49 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 00:22:48 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Tzeta Tsao , Roger Alexander , David Ward , Philip Levis In-Reply-To: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 00:22:47 +0100 References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jan 2010 23:22:48.0799 (UTC) FILETIME=[4EDB7EF0:01CA9E15] Cc: Adrian Farrel Subject: [Roll] New Design Team to work on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2010 23:22:44 -0000 Dear all, This is to announce the formation of a new RPL Security Design Team, made of the following members: * Tzeta Tsao * Roger Alexander * Dave Ward * Phil Levis Thanks to the four of you for volunteering. Rene Struik will help the team as our security advisor. As a reminder: * The work produced by a Design Team has no special status in the WG and is subject to WG consensus as any other individual submission * We ask the Design Team to request for input from the WG and to provide regular updates on the progress: please send input requests to the mailing list, post regular updates of the document to get a chance to everybody to comment, ... * All: please provide input to the Design Team and copy the mailing list. Charter ###### The charter of the security design team is to produce a Security Framework document and the potential routing security extensions to RPL in the context of that framework (or document how existing routing mechanisms should be used). With regards to the framework, the Security DT may choose to use http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt as a starting point (the document has been presented and discussed at the last two Working Group meetings). Please make sure to be aligned with the ROLL terminology document and provide input to their authors should new terms be introduced. Milestones ######### Milestones are pretty aggressive. Feb 10: produce a first draft of Security Framework to be submitted to the WG for WG adoption Feb 29: produce a first draft on the potential security extensions for RPL as a separate document (that may be incorporated in the core specification of RPL in a second step). The Design Team may not be dissolved after the completion of the security work for RPL as security in routing within LLN may apply to future specifications produced by the Working Group. It is strongly encouraged to produce new version as the document progress (each time a substantial change is made to the document). Thanks. JP and David. On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: > Dear WG, > > I think that we can all be very happy with our progress so far with > the core specification of RPL. There are still a few open issues > that we need to solve before IETF-77: > > * Detailed DAO mechanisms > * Detailed mode of operation with multicast > * Use of Flow Label versus new IPv6 header > * Potential needed optimization such as DAO packing > * Editorial work > * ... > > We are on track for all of these. > > The one item we absolutely need to speed on is security. As you know > there is a security framework document that is still not a WG > document and we now need to start the work on the RPL security > aspects. To that end, we will form a small Design Team with > aggressive milestones, the objective being to have the RPL security > item almost completed by end of Feb, ready for the IETF-77. > > If you have a good understanding of RPL and routing security > expertise, please go back to me (unicast). > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Jan 26 01:25:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0023A686E for ; Tue, 26 Jan 2010 01:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4LAmXAYV+1F for ; Tue, 26 Jan 2010 01:25:25 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 0D29A3A67EB for ; Tue, 26 Jan 2010 01:25:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0Q9PWCD015795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Jan 2010 10:25:32 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0Q9PWke002400 for ; Tue, 26 Jan 2010 10:25:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0Q9PVwo010079 for ; Tue, 26 Jan 2010 10:25:32 +0100 Message-ID: <4B5EB50B.6050809@gmail.com> Date: Tue, 26 Jan 2010 10:25:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] New Design Team to work on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 09:25:26 -0000 JP, Thanks for the Security DT announcement and I hope to see excellent output. I would like to ask about IPR aspects on RoLL security. Is there any IPR on the base security draft ? http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt Is there any IPR on the documents it relies, for example [Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zhang, "Fast Authenticated Key Establishment Protocols for Self-Organizing Sensor Networks", in Proceedings of the 2nd ACM International Conference on Wireless Sensor Networks and Applications, San Diego, CA, USA, pp. 141- 150, Sept. 19 2003. This is good to know prior to engaging to good work. Thanks, Alex Le 26/01/2010 00:22, JP Vasseur a écrit : > Dear all, > > This is to announce the formation of a new RPL Security Design Team, > made of the following members: * Tzeta Tsao * Roger Alexander * Dave > Ward * Phil Levis > > Thanks to the four of you for volunteering. > > Rene Struik will help the team as our security advisor. > > As a reminder: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission * > We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... * All: please provide input to > the Design Team and copy the mailing list. > > Charter ###### > > The charter of the security design team is to produce a Security > Framework document and the potential routing security extensions to > RPL in the context of that framework (or document how existing > routing mechanisms should be used). With regards to the framework, > the Security DT may choose to use > http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt as > a starting point (the document has been presented and discussed at > the last two Working Group meetings). > > Please make sure to be aligned with the ROLL terminology document > and provide input to their authors should new terms be introduced. > > Milestones ######### > > Milestones are pretty aggressive. > > Feb 10: produce a first draft of Security Framework to be submitted > to the WG for WG adoption Feb 29: produce a first draft on the > potential security extensions for RPL as a separate document (that > may be incorporated in the core specification of RPL in a second > step). > > The Design Team may not be dissolved after the completion of the > security work for RPL as security in routing within LLN may apply to > future specifications produced by the Working Group. > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP and David. > > On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: > >> Dear WG, >> >> I think that we can all be very happy with our progress so far >> with the core specification of RPL. There are still a few open >> issues that we need to solve before IETF-77: >> >> * Detailed DAO mechanisms * Detailed mode of operation with >> multicast * Use of Flow Label versus new IPv6 header * Potential >> needed optimization such as DAO packing * Editorial work * ... >> >> We are on track for all of these. >> >> The one item we absolutely need to speed on is security. As you >> know there is a security framework document that is still not a WG >> document and we now need to start the work on the RPL security >> aspects. To that end, we will form a small Design Team with >> aggressive milestones, the objective being to have the RPL >> security item almost completed by end of Feb, ready for the >> IETF-77. >> >> If you have a good understanding of RPL and routing security >> expertise, please go back to me (unicast). >> >> Thanks. >> >> JP. _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Tue Jan 26 06:18:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91F83A696E for ; Tue, 26 Jan 2010 06:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.298 X-Spam-Level: X-Spam-Status: No, score=-8.298 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcB5FoJzcM2S for ; Tue, 26 Jan 2010 06:18:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BC6483A6966 for ; Tue, 26 Jan 2010 06:18:45 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAOqIXktAZnwN/2dsb2JhbACCFxq/QZcNgi2CDAQ X-IronPort-AV: E=Sophos;i="4.49,346,1262563200"; d="scan'208,217";a="82190662" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2010 14:18:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0QEIk7H004724; Tue, 26 Jan 2010 14:18:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 15:18:50 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 15:18:49 +0100 Message-Id: <64994F3E-3C07-4332-AA2A-1AA54AF57DF6@cisco.com> From: JP Vasseur To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429DB3@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-138-593003566 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 15:18:48 +0100 References: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01429D8F@zensys17.zensys.local> <072911B3-B0AE-448D-85D4-3334F544A156@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3EF16DAD@zensys17.zensys.local> <2B6E6AEA-EB0C-493A-892A-62A46E5C91E9@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429DAA@zensys17.zensys.local> <69B8AFAA-6815-43D3-8730-AF5B991AD86C@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429DB0@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01429DB3@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jan 2010 14:18:49.0309 (UTC) FILETIME=[7A9E50D0:01CA9E92] Cc: ROLL WG Subject: Re: [Roll] RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 14:18:48 -0000 --Apple-Mail-138-593003566 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Copying the list to continue that discussion - see below Anders> >> Anyway, >> the use case is quite simple: >> >> Z - R1 - R2 - R3 - A >> >> 1) Lamp module A was recently controlled by controller Z via router >> 1 -> router 2 -> router 3 >> Z - R1 - R2 - R3 - A >> >> 2) Something renders the radio connection unusable from router 3 to >> lamp module A >> 3) The lamp module can however be reached via router 1 -> router 4 - >> > router 5 >> but router 5 has never been routing traffic to lamp module A >> Z - R1 - R2 - R3 - . >> \ >> - R4 - R5 - A >> 4) Controller Z sends another command to lamp module A via router 1 >> 5) Router 1 sends the command to router 2 which forwards the >> command to router 3 >> 6) Router 3 is unable to deliver the command >> >> What happens now? > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > >> Will the lamp go on within 250ms? >> So you raise the issue of convergence time, fair. It all depends on how you tune RPL and A selects R5 as a new parent. Note that you do not have to keep sending control traffic for that. If you links are extremely lossy you will have to make the DAG fairly reactive, which means more control traffic of course. If you are using a reactive mechanism instead of proactive, this is not a magic solution either since you flood your network and add control messages too. What I think is that by using these mechanism you can achieve a good level of convergence time with reasonable traffic in presence of lossy link w/o too much control traffic. We can try to quantify if you can provide an example topology, few stats on the link flaps trying few RPL tuning. Could you ? Thanks. JP. >> Thanks, >> Anders >> >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Thursday, January 21, 2010 09:11 >> To: Anders Brandt >> Subject: Re: SV: [Roll] RPL Simulation >> >> Hi Anders, >> >> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: >> >>> Sorry JP >>> >>> I really have no intention of spreading FUD. >>> Guess this mainly indicates that I and Jerry need education of >>> what RPL is expected/able to deliver. >>> >>> At the most recent telecon we again touched the issue of e.g. a >>> lamp module which due to rf phenomena >>> cannot be reached via the recent router - and I thought we had a >>> common understanding that some reactive mechanism >>> would be needed. >>> >>> Can RPL - in its current shape - identify a new route via a router >>> which did not previously forward traffic to said lamp module? >> >> Not sure of what you mean by this ? >> >>> I would love that but I need to understand how - and I would love >>> to see your evidence! >>> >> >> Here is what I can propose: could you provide a home network >> topology that I could use to provide >> simulations results ? >> >> Cheers. >> >> JP. >> >>> Thanks, >>> Anders >>> >>> >>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>> Sent: Wednesday, January 20, 2010 18:21 >>> To: Anders Brandt >>> Subject: Re: SV: [Roll] RPL Simulation >>> >>> Hi Anders, >>> >>> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: >>> >>>> Hi JP >>>> >>>> > Are you saying that RPL is not good enough for P2P in home and >>>> building? >>>> >>>> Well - which incarnation of RPL? (!) >>>> I was of the impression that we had a common understanding that >>>> the ability to >>>> operate in a reactive fasion is critical to home & building and >>>> that the DAG update >>>> signaling currently designed will have much bigger delays than >>>> the 250ms real-time >>>> users will tolerate. >>> >>> Where does that come from ? >>> >>>> >>>> > Since I have evidence that it is not the case. >>>> > Do you have data that shows different results ? >>>> >>>> I may have misunderstood the telecon conclusions, but I got it so >>>> that over time >>>> DAG routes will reconstructed, but that the current spec cannot >>>> find a lost target on demand (?). >>>> >>>> > Because as you know it is now in our charter to work on other >>>> protocols. >>>> now? I guess you mean "not" ? (!) >>>> My conclusion from the Rolle interim was that we needed something >>>> special to find routes across the cloud. >>>> If the DAG can re-establish contact within 250ms to an >>>> operational node that was just lost in a routing table, >>>> I would really love it. Is that the case? >>> >>> mmm I do not think so ... happy to discuss it live with you though. >>> >>> Cheers! >>> >>> JP. >>> >>>> >>>> Cheers, >>>> Anders >>>> >>>> Fra: JP Vasseur [mailto:jvasseur@cisco.com] >>>> Sendt: on 20-01-2010 17:02 >>>> Til: Anders Brandt >>>> Emne: Re: [Roll] RPL Simulation >>>> >>>> Hi Anders, >>>> >>>> off-line first. >>>> >>>> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: >>>> >>>>> Jerry, >>>>> >>>>> >That was what was nice about an AODV concept, because even >>>>> route repair was fairly deterministic. >>>>> >>>>> As far as I am informed some reactive discovery mechanism is >>>>> still needed for all the reasons that you list below. >>>>> You may remember that we have the same needs in home automation. >>>>> By utilizing the fact that source routing is already used to >>>>> jump between RPL-capable routers AND the fact that the (time >>>>> critical) >>>>> point-to-point communication is limited to 5 hops or less, some >>>>> TTL-aware, source-route-based AODV hybrid may not cause so >>>>> much flooding as one could fear. >>>> >>>> Are you saying that RPL is not good enough for P2P in home and >>>> building ? Since I have evidence that it is not the case. >>>> Do you have data that shows different results ? >>>> Because as you know it is now in our charter to work on other >>>> protocols. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>>> >>>>> - Anders >>>>> >>>>> >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>>>> Behalf Of Jerald.P.Martocci@jci.com >>>>> Sent: Thursday, January 14, 2010 19:11 >>>>> To: Joydeep Tripathi >>>>> Cc: ROLL WG >>>>> Subject: Re: [Roll] RPL Simulation >>>>> >>>>> >>>>> Hi Joydeep, >>>>> >>>>> Mukul's been doing some simulations for my company for the past >>>>> 3 years. He has a good handle on the commercial building >>>>> performance requirements. It would be good for you to run those >>>>> he notes below. It might be advantageous then for you two to >>>>> share the results to better correlate the simulations. >>>>> >>>>> I would also look at the latency for P2P messages when the >>>>> packet(s) need to traverse the DAG all the way up to the LBR and >>>>> back down to the destination node. Of course, this is now a >>>>> function on DAG depth. Also since all our messages require ACK, >>>>> the additional latency of the ACK having to return possibly >>>>> through a different set of nodes yet via the LBR. That would be >>>>> the worst case scenario. If other nodes could short circuit the >>>>> packets through a shorter path, that would on;y help. >>>>> >>>>> Since Building systems are real-time (smoke/fire detection, >>>>> turning on lights, etc) latency is a big issue. Moving the >>>>> packet up and down the DAG is reasonably deterministic and >>>>> should be primarily a function of the DAG depth. However, what >>>>> will really affect the system performance is 'DAG Repair'. I >>>>> have no sense how long a packet in transit would have to wait if >>>>> the DAG was under repair. Since we require ACKs of every >>>>> message, the source node would time-out and retry a few times >>>>> (usually 3). After that, the source node would have to fall >>>>> into some 'failsoft' mode depending on the type of data it was >>>>> trying to access. This is not a good situation. The source >>>>> node can only assume that its data is inaccessible, not just >>>>> held up in transit. The fail-soft mode will have large >>>>> hysteresis since it can't be constantly dithering between >>>>> modes. This will all be logged to the operator which is a bad >>>>> thing!!! That was what was nice about an AODV concept, because >>>>> even route repair was fairly deterministic. >>>>> >>>>> So... if your simulation could measure packet latency as a >>>>> function of DAG repair severity, that would be terrific. >>>>> >>>>> Hope this makes sense. >>>>> >>>>> Jerry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Mukul Goyal >>>>> 01/13/2010 10:17 AM >>>>> >>>>> To >>>>> Joydeep Tripathi >>>>> cc >>>>> ROLL WG , Jerald P Martocci >>>> > >>>>> Subject >>>>> Re: [Roll] RPL Simulation >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Joydeep >>>>> >>>>> Here are a few suggestions for your simulations: >>>>> >>>>> 1. Simulate a 100 node and a 1000 node topology operating under >>>>> a single DAG >>>>> >>>>> 2. Simulate both scenarios: optimal DAG routes (ie the path >>>>> through the DAG from a source to a destination passes through >>>>> their closest common ancestor) and DAG routes through root (all >>>>> DAG paths have to go through the DAG root). >>>>> >>>>> 3. Study the stretch factor (increase in length/cost of routes >>>>> over the DAG versus the length/cost of ideal routes) for given >>>>> number of flows: 100, 1000, 10000 and possibly n*(n-1) flows >>>>> (where n is the number of nodes in the topology: >>>>> a) the scenario you suggested: Choose 20% flows over 2 hop >>>>> neighbors, 10% flows over longer paths. >>>>> b) randomly selected source and destinations (in n*(n-1) case, >>>>> from each possible source node to each possible destination node). >>>>> >>>>> 4. In addition to the stretch factor, calculate/simulate the >>>>> traffic loads as well as packet loss/delay along the DAG links. >>>>> Compare these values against values with ideal P2P routing. >>>>> >>>>> Thanks >>>>> Mukul >>>>> ----- Original Message ----- >>>>> From: "Joydeep Tripathi" >>>>> To: "Jerald P Martocci" >>>>> Cc: "ROLL WG" >>>>> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/ >>>>> Canada Central >>>>> Subject: [Roll] RPL Simulation >>>>> >>>>> Hi, >>>>> >>>>> In the next revision, we are also planning to implement a typical >>>>> building routing scenario, where 60-70% of the P2P traffic are >>>>> confined within 1 hop physical distance and, 20% of the P2P >>>>> traffic >>>>> are to a 2 -hop distance destination, and observe the >>>>> performance of >>>>> RPL against the ideal shortest route. Also, please let us know if >>>>> there is any other scenario or traffic pattern you want to be >>>>> implemented. >>>>> >>>>> Thanks, >>>>> Joydeep >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> >> > --Apple-Mail-138-593003566 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Copying the list to continue = that discussion - see = below 

Anders>

Anyway,
the use case is quite = simple:
 
Z - R1 - R2 - R3 - = A
 
1) Lamp module A was recently controlled by = controller Z via router 1 -> router 2 -> router = 3
  Z - R1 - R2 - R3 - A
 
2) Something renders the radio connection = unusable from router 3 to lamp module A
3) The lamp module can = however be reached via router 1 -> router 4 -> router = 5
    but router 5 has never been routing = traffic to lamp module A
  Z - R1 - R2 - R3 - = .
        \=
         - R4 - = R5 - A
4) Controller Z sends another command to = lamp module A via router 1
5) Router 1 sends the command to router 2 = which forwards the command to router 3
6) Router 3 is unable to = deliver the command
 
What happens = now?

This is = exactly why I was asking you the reason why you think that it should be = reactive.
What you describe is routing protocol convergence, = which of course does not imply that the
protocol should be = reactive. This is a typical case where the topology is changing and = RPL
needs to adapt to it, which it does. The way to meet your = time requirements is to adjust
the RPL parameters to make it = quicker to converge. If there is a link between A and R5, 
=
as soon as it becomes operational, A can send a DAO and R1 will = direct the traffic to R4
instead of R2.

Will the lamp go on within = 250ms?
 
=

So you raise the issue of convergence = time, fair. It all depends on how you tune RPL and A
selects = R5 as a new parent. Note that you do not have to keep sending control = traffic for 
that. If you links are extremely lossy you = will have to make the DAG fairly reactive, which 
means = more control traffic of course. If you are using a reactive mechanism = instead of 
proactive, this is not a magic solution = either since you flood your network and add control
messages = too. 

What I think is that by using these = mechanism you can achieve a good level of convergence
time = with reasonable traffic in presence of lossy link w/o too much control = traffic. We can try 
to quantify if you can provide an = example topology, few stats on the link flaps trying few = RPL
tuning. Could you = ?

Thanks.

JP.

<= blockquote type=3D"cite">
Thanks,
  Anders

=
From: JP = Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, January 21, 2010 09:11
To: Anders = Brandt
Subject: Re: SV: [Roll] RPL = Simulation

Hi Anders,

=
On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:

Sorry JP
 
=
I really have no intention = of spreading FUD.
Guess this mainly indicates that I and = Jerry need education of what RPL is expected/able to = deliver.
 
At the most recent telecon we again touched = the issue of e.g. a lamp module which due to rf phenomena
cannot = be reached via the recent router - and I thought we had a common = understanding that some reactive mechanism
would be = needed.

Can RPL - in its current shape - identify a new route = via a router which did not previously forward traffic to said lamp = module?
=

Not sure of what you mean by this ?

=
=
I would love that but I need = to understand how - and I would love to see your = evidence!
 
=

Here is what I can propose: could you provide a = home network topology that I could use to provide
=
simulations results ?

Cheers.
=

JP.

Thanks,
  = Anders
 

=
From: = JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Wednesday, January 20, 2010 18:21
To: Anders = Brandt
Subject: Re: SV: [Roll] RPL = Simulation

Hi Anders,

=
On Jan 20, 2010, at 5:44 PM, Anders Brandt = wrote:

Hi JP
=
 
> Are you saying that RPL is not good = enough for P2P  in home and building?
=
 
Well - which incarnation of RPL? (!)
=
I was of the impression that we had a common understanding that = the ability to
operate in a reactive fasion is critical to home = & building and that the DAG update
signaling currently = designed will have much bigger delays than the 250ms = real-time
users will = tolerate.

=
Where does that come from ? 

 
=
> Since I have evidence that it is not the case.
=
> Do you have data that shows different results ?
=
 
I may have misunderstood the telecon = conclusions, but I got it so that over time
DAG routes will = reconstructed, but that the current spec cannot find a lost target = on demand (?).
 
> = Because as you know it is now in our charter to work on other = protocols.
now? I guess you mean "not" ? (!)
=
My conclusion from the Rolle interim was that we needed something = special to find routes across the cloud.
If the DAG = can re-establish contact within 250ms to an operational node that = was just lost in a routing table,
I would really love it. Is = that the case?
=

mmm I do not think so ... happy to discuss it = live with you though.

Cheers!
=

JP.

=
 
=
Cheers,
  Anders
=

Fra: JP Vasseur [mailto:jvasseur@cisco.com]
Se= ndt: on 20-01-2010 17:02
Til: Anders = Brandt
Emne: Re: [Roll] RPL = Simulation

Hi Anders, =

off-line first.

=
On Jan 19, 2010, at 4:14 PM, Anders Brandt = wrote:

Jerry,
 
>That was what was nice about an AODV concept, because = even route repair was fairly deterministic.

As far as I am informed = some reactive discovery mechanism is still needed for all the = reasons that you list below.
You may remember that we have the same needs in home = automation.
By utilizing the fact that source routing is = already used to jump between RPL-capable routers AND the fact = that the (time critical)
point-to-point communication is = limited to 5 hops or less, some TTL-aware, source-route-based AODV = hybrid may not cause so
much flooding as one could = fear.

=
Are you saying that RPL is not good enough for P2P  in = home and building ? Since I have evidence that it is not the = case.
Do you have data that shows different results = ?
Because as you know it is now in our charter to work = on other protocols.

=
Thanks.

JP.

=
 
- = Anders
 
 
= From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Jerald.P.Martocci@jci.comSent: Thursday, January 14, 2010 19:11
To: = Joydeep Tripathi
Cc: ROLL WG
Subject: Re: = [Roll] RPL Simulation

=

Hi Joydeep, =

Mukul's been doing = some simulations for my company for the past 3 years.  He = has a good handle on the commercial building performance = requirements.  It would be good for you to run those he = notes below.  It might be advantageous then for you two to = share the results to better correlate the simulations. =

I would also look at the = latency for P2P messages when the packet(s) need to traverse the = DAG all the way up to the LBR and back down to the destination = node.  Of course, this is now a function on DAG depth. =  Also since all our messages require ACK, the additional = latency of the ACK having to return possibly through a different = set of nodes yet via the LBR.  That would be the worst case = scenario.  If other nodes could short circuit the packets = through a shorter path, that would on;y help. =

Since Building systems are = real-time (smoke/fire detection, turning on lights, etc) latency = is a big issue.  Moving the packet up and down the DAG is = reasonably deterministic and should be primarily a function of = the DAG depth.  However, what will really affect the system = performance is 'DAG Repair'.  I have no sense how long a = packet in transit would have to wait if the DAG was under = repair.  Since we require ACKs of every message, the source = node would time-out and retry a few times (usually 3). =  After that, the source node would have to fall into some = 'failsoft' mode depending on the type of data it was trying to = access.  This is not a good situation.  The source node can = only assume that its data is inaccessible, not just held up in = transit.  The fail-soft mode will have large hysteresis = since it can't be constantly dithering between modes.  This = will all be logged to the operator which is a bad thing!!! =  That was what was nice about an AODV concept, because even = route repair was fairly deterministic.

So... if your simulation could = measure packet latency as a function of DAG repair severity, that would = be terrific.

Hope this makes sense.

Jerry



<ATT129641.jpg>


= =
Mukul= Goyal <mukul@uwm.edu> =

01/13/2010 10:17 = AM

= = = = = =
To
Joydeep Tripathi <joydeep.tripathi@gmail.com&= gt;
cc
ROLL WG <roll@ietf.org>, Jerald P = Martocci <Jerald.P.Martocci@jci.com>= ;
Subject
Re: [Roll] RPL = Simulation

= = =




Joydeep

Here are a few suggestions for your = simulations:

1. Simulate a 100 node and a 1000 node topology = operating under a single DAG

2. Simulate both scenarios: = optimal DAG routes (ie the path through the DAG from a source to = a destination passes through their closest common ancestor) and = DAG routes through root (all DAG paths have to go through the = DAG root).

3. Study the stretch factor (increase in = length/cost of routes over the DAG versus the length/cost of = ideal routes) for given number of flows: 100, 1000, 10000 and = possibly n*(n-1) flows (where n is the number of nodes in the = topology:
a) the scenario you suggested: Choose 20% flows over = 2 hop neighbors, 10% flows over longer paths.
b) randomly selected = source and destinations (in n*(n-1) case, from each possible = source node to each possible destination node).

4. In = addition to the stretch factor, calculate/simulate the traffic = loads as well as packet loss/delay along the DAG links. Compare = these values against values with ideal P2P = routing.

Thanks
Mukul
----- Original Message = -----
From: "Joydeep Tripathi" <joydeep.tripathi@gmail.com&= gt;
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>= ;
Cc: "ROLL WG" <roll@ietf.org>
Sent: Wednesday, = January 13, 2010 2:24:36 AM GMT -06:00 US/Canada = Central
Subject: [Roll] RPL Simulation

Hi,

In = the next revision, we are also planning to implement a = typical
building routing scenario, where 60-70% of the P2P = traffic are
confined within 1 hop physical distance and, 20% = of the P2P traffic
are to a 2 -hop distance destination, and = observe the performance of
RPL against the ideal shortest route. = Also, please let us know if
there is any other scenario or traffic = pattern you want to = be
implemented.

Thanks,
Joydeep
__________________________= _____________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

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





= --Apple-Mail-138-593003566-- From tzeta.tsao@ekasystems.com Tue Jan 26 06:44:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274D328B56A for ; Tue, 26 Jan 2010 06:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWMKaJZ9Kc7n for ; Tue, 26 Jan 2010 06:44:37 -0800 (PST) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id D60893A6803 for ; Tue, 26 Jan 2010 06:44:36 -0800 (PST) Received: (qmail 56928 invoked from network); 26 Jan 2010 14:44:44 -0000 Received: from (tzeta.tsao@209.48.242.70 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 26 Jan 2010 06:44:43 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: KZjtBdQVM1ntzphT1F8hmiBmNTtvqNVLz2lrAMSObbSIdOuZay0fN83aOSeXLO8Aws7BfBsqCsfluKR8XEPmfB01H0mlVnCDJPM8aj8_oZNRGl8a8IE.z78OQqq.CIl3VNXK9d8OWQl4RAZdzEiLaFTetZaJJCuU.gaLAFWfTBsU5tGlsKguFAcBZZaK9TPkpYh0Ap7T_rvt5Vof02fKGVYPgRMRFApBrSXuYavF5MrXmOVoyS4YWjxHGe7jI_brmmqJYT3kbygUq.wC0QZpUNXhaHZE1x0DsnuNP5k3IgYQjpxcs2BhSo7pp2j24JY1ZsKPh0yLE2GDoXg.ffPQEFSUXIpQCFWKYxYP1EZu8wP8C_ABFzmpSByJsxxeHdU_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B5EFFD8.60607@ekasystems.com> Date: Tue, 26 Jan 2010 09:44:40 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Alexandru Petrescu References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> <4B5EB50B.6050809@gmail.com> In-Reply-To: <4B5EB50B.6050809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] New Design Team to work on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 14:44:38 -0000 Hi Alex, There are no IPR issues with that previous draft, to the best of my knowledge. Thanks for the reference; I will take a close look. Regards, Tzeta Alexandru Petrescu wrote: > JP, > > Thanks for the Security DT announcement and I hope to see excellent output. > > I would like to ask about IPR aspects on RoLL security. > > Is there any IPR on the base security draft ? > http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt > > Is there any IPR on the documents it relies, for example > [Huang2003] > Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. > Zhang, "Fast Authenticated Key Establishment Protocols for > Self-Organizing Sensor Networks", in Proceedings of the > 2nd ACM International Conference on Wireless Sensor > Networks and Applications, San Diego, CA, USA, pp. 141- > 150, Sept. 19 2003. > > This is good to know prior to engaging to good work. > > Thanks, > > Alex > > Le 26/01/2010 00:22, JP Vasseur a écrit : >> Dear all, >> >> This is to announce the formation of a new RPL Security Design Team, >> made of the following members: * Tzeta Tsao * Roger Alexander * Dave >> Ward * Phil Levis >> >> Thanks to the four of you for volunteering. >> >> Rene Struik will help the team as our security advisor. >> >> As a reminder: >> >> * The work produced by a Design Team has no special status in the WG >> and is subject to WG consensus as any other individual submission * >> We ask the Design Team to request for input from the WG and to >> provide regular updates on the progress: please send input requests >> to the mailing list, post regular updates of the document to get a >> chance to everybody to comment, ... * All: please provide input to >> the Design Team and copy the mailing list. >> >> Charter ###### >> >> The charter of the security design team is to produce a Security >> Framework document and the potential routing security extensions to >> RPL in the context of that framework (or document how existing >> routing mechanisms should be used). With regards to the framework, >> the Security DT may choose to use >> http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt as >> a starting point (the document has been presented and discussed at >> the last two Working Group meetings). >> >> Please make sure to be aligned with the ROLL terminology document >> and provide input to their authors should new terms be introduced. >> >> Milestones ######### >> >> Milestones are pretty aggressive. >> >> Feb 10: produce a first draft of Security Framework to be submitted >> to the WG for WG adoption Feb 29: produce a first draft on the >> potential security extensions for RPL as a separate document (that >> may be incorporated in the core specification of RPL in a second >> step). >> >> The Design Team may not be dissolved after the completion of the >> security work for RPL as security in routing within LLN may apply to >> future specifications produced by the Working Group. >> >> It is strongly encouraged to produce new version as the document >> progress (each time a substantial change is made to the document). >> >> Thanks. >> >> JP and David. >> >> On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> I think that we can all be very happy with our progress so far >>> with the core specification of RPL. There are still a few open >>> issues that we need to solve before IETF-77: >>> >>> * Detailed DAO mechanisms * Detailed mode of operation with >>> multicast * Use of Flow Label versus new IPv6 header * Potential >>> needed optimization such as DAO packing * Editorial work * ... >>> >>> We are on track for all of these. >>> >>> The one item we absolutely need to speed on is security. As you >>> know there is a security framework document that is still not a WG >>> document and we now need to start the work on the RPL security >>> aspects. To that end, we will form a small Design Team with >>> aggressive milestones, the objective being to have the RPL >>> security item almost completed by end of Feb, ready for the >>> IETF-77. >>> >>> If you have a good understanding of RPL and routing security >>> expertise, please go back to me (unicast). >>> >>> Thanks. >>> >>> JP. _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abr@sdesigns.dk Tue Jan 26 07:08:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3753228C0D6 for ; Tue, 26 Jan 2010 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJDhR76ipegI for ; Tue, 26 Jan 2010 07:08:14 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 3C0103A6803 for ; Tue, 26 Jan 2010 07:08:13 -0800 (PST) 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_01CA9E99.66F0FF72" Date: Tue, 26 Jan 2010 16:08:22 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429DFD@zensys17.zensys.local> In-Reply-To: <64994F3E-3C07-4332-AA2A-1AA54AF57DF6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SV: [Roll] RPL Simulation in the home Thread-Index: AcqekoA7wo25bHRnTRadLv8xjyvvRgABd9Gw References: <1119544315.1001641263399429873.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01429D8F@zensys17.zensys.local> <072911B3-B0AE-448D-85D4-3334F544A156@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3EF16DAD@zensys17.zensys.local> <2B6E6AEA-EB0C-493A-892A-62A46E5C91E9@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429DAA@zensys17.zensys.local> <69B8AFAA-6815-43D3-8730-AF5B991AD86C@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429DB0@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01429DB3@zensys17.zensys.local> <64994F3E-3C07-4332-AA2A-1AA54AF57DF6@cisco.com> From: "Anders Brandt" To: "JP Vasseur" Cc: ROLL WG Subject: Re: [Roll] RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 15:08:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9E99.66F0FF72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP =20 I see two assumptions which I would like to discuss: =20 1) "...as soon as it becomes operational, A can send a DAO ..." The point is that A has been operational all the time. RF conditions just changed so that A cannot be reached via R3. Therefore A is not even aware that it is missing a parent =3D> it may not send a DAO for the next many minutes =20 2) "..If you are using a reactive mechanism instead of proactive, this is not a magic solution either ..." Sure. We agree in this. As discussed on the RPL editor list recently, using the flooding trick is a backup option which should only be used if you are in a hurry - which users turning on light are always. Also, the scope of that flooding does not need to be more than a diameter of 5 hops. This would suffice for home as well as for building applications. I do not argue for flooding the entire Internet! =20 Cheers, Anders=20 =20 ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Tuesday, January 26, 2010 15:19 To: Anders Brandt Cc: ROLL WG Subject: Re: SV: [Roll] RPL Simulation in the home Copying the list to continue that discussion - see below =20 Anders> Anyway, the use case is quite simple: =20 Z - R1 - R2 - R3 - A =20 1) Lamp module A was recently controlled by controller Z via router 1 -> router 2 -> router 3 =09 Z - R1 - R2 - R3 - A =20 2) Something renders the radio connection unusable from router 3 to lamp module A 3) The lamp module can however be reached via router 1 -> router 4 -> router 5 but router 5 has never been routing traffic to lamp module A =09 Z - R1 - R2 - R3 - . \ - R4 - R5 - A 4) Controller Z sends another command to lamp module A via router 1 5) Router 1 sends the command to router 2 which forwards the command to router 3 6) Router 3 is unable to deliver the command =20 What happens now? This is exactly why I was asking you the reason why you think that it should be reactive. What you describe is routing protocol convergence, which of course does not imply that the protocol should be reactive. This is a typical case where the topology is changing and RPL needs to adapt to it, which it does. The way to meet your time requirements is to adjust the RPL parameters to make it quicker to converge. If there is a link between A and R5,=20 as soon as it becomes operational, A can send a DAO and R1 will direct the traffic to R4 instead of R2. Will the lamp go on within 250ms? =20 So you raise the issue of convergence time, fair. It all depends on how you tune RPL and A selects R5 as a new parent. Note that you do not have to keep sending control traffic for=20 that. If you links are extremely lossy you will have to make the DAG fairly reactive, which=20 means more control traffic of course. If you are using a reactive mechanism instead of=20 proactive, this is not a magic solution either since you flood your network and add control messages too.=20 What I think is that by using these mechanism you can achieve a good level of convergence time with reasonable traffic in presence of lossy link w/o too much control traffic. We can try=20 to quantify if you can provide an example topology, few stats on the link flaps trying few RPL tuning. Could you ? Thanks. JP. Thanks, Anders ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, January 21, 2010 09:11 To: Anders Brandt Subject: Re: SV: [Roll] RPL Simulation =09 =09 Hi Anders,=20 On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: Sorry JP =20 I really have no intention of spreading FUD. Guess this mainly indicates that I and Jerry need education of what RPL is expected/able to deliver. =20 At the most recent telecon we again touched the issue of e.g. a lamp module which due to rf phenomena cannot be reached via the recent router - and I thought we had a common understanding that some reactive mechanism would be needed. =09 Can RPL - in its current shape - identify a new route via a router which did not previously forward traffic to said lamp module? =09 Not sure of what you mean by this ? I would love that but I need to understand how - and I would love to see your evidence! =20 Here is what I can propose: could you provide a home network topology that I could use to provide simulations results ? Cheers. JP. Thanks, Anders =20 ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, January 20, 2010 18:21 To: Anders Brandt Subject: Re: SV: [Roll] RPL Simulation =09 =09 Hi Anders,=20 On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: =09 Hi JP =20 > Are you saying that RPL is not good enough for P2P in home and building? =20 Well - which incarnation of RPL? (!) I was of the impression that we had a common understanding that the ability to operate in a reactive fasion is critical to home & building and that the DAG update signaling currently designed will have much bigger delays than the 250ms real-time users will tolerate. Where does that come from ?=20 =09 =20 > Since I have evidence that it is not the case. > Do you have data that shows different results ? =20 I may have misunderstood the telecon conclusions, but I got it so that over time DAG routes will reconstructed, but that the current spec cannot find a lost target on demand (?). =20 > Because as you know it is now in our charter to work on other protocols. now? I guess you mean "not" ? (!) My conclusion from the Rolle interim was that we needed something special to find routes across the cloud. If the DAG can re-establish contact within 250ms to an operational node that was just lost in a routing table, I would really love it. Is that the case? mmm I do not think so ... happy to discuss it live with you though. Cheers! JP. =09 =20 Cheers, Anders ________________________________ Fra: JP Vasseur [mailto:jvasseur@cisco.com] Sendt: on 20-01-2010 17:02 Til: Anders Brandt Emne: Re: [Roll] RPL Simulation =09 =09 Hi Anders,=20 off-line first. On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: Jerry, =20 >That was what was nice about an AODV concept, because even route repair was fairly deterministic.=20 =09 As far as I am informed some reactive discovery mechanism is still needed for all the reasons that you list below. =09 You may remember that we have the same needs in home automation. By utilizing the fact that source routing is already used to jump between RPL-capable routers AND the fact that the (time critical) point-to-point communication is limited to 5 hops or less, some TTL-aware, source-route-based AODV hybrid may not cause so much flooding as one could fear. =09 Are you saying that RPL is not good enough for P2P in home and building ? Since I have evidence that it is not the case. Do you have data that shows different results ? Because as you know it is now in our charter to work on other protocols. Thanks. JP. =20 - Anders =20 =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, January 14, 2010 19:11 To: Joydeep Tripathi Cc: ROLL WG Subject: Re: [Roll] RPL Simulation =09 =09 Hi Joydeep,=20 =09 Mukul's been doing some simulations for my company for the past 3 years. He has a good handle on the commercial building performance requirements. It would be good for you to run those he notes below. It might be advantageous then for you two to share the results to better correlate the simulations.=20 =09 I would also look at the latency for P2P messages when the packet(s) need to traverse the DAG all the way up to the LBR and back down to the destination node. Of course, this is now a function on DAG depth. Also since all our messages require ACK, the additional latency of the ACK having to return possibly through a different set of nodes yet via the LBR. That would be the worst case scenario. If other nodes could short circuit the packets through a shorter path, that would on;y help.=20 =09 Since Building systems are real-time (smoke/fire detection, turning on lights, etc) latency is a big issue. Moving the packet up and down the DAG is reasonably deterministic and should be primarily a function of the DAG depth. However, what will really affect the system performance is 'DAG Repair'. I have no sense how long a packet in transit would have to wait if the DAG was under repair. Since we require ACKs of every message, the source node would time-out and retry a few times (usually 3). After that, the source node would have to fall into some 'failsoft' mode depending on the type of data it was trying to access. This is not a good situation. The source node can only assume that its data is inaccessible, not just held up in transit. The fail-soft mode will have large hysteresis since it can't be constantly dithering between modes. This will all be logged to the operator which is a bad thing!!! That was what was nice about an AODV concept, because even route repair was fairly deterministic.=20 =09 So... if your simulation could measure packet latency as a function of DAG repair severity, that would be terrific.=20 =09 Hope this makes sense.=20 =09 Jerry=20 =09 =09 =09 =20 =09 =09 =09 Mukul Goyal =20 01/13/2010 10:17 AM=20 To Joydeep Tripathi =09 cc ROLL WG , Jerald P Martocci =09 Subject Re: [Roll] RPL Simulation=09 =09 Joydeep =09 Here are a few suggestions for your simulations: =09 1. Simulate a 100 node and a 1000 node topology operating under a single DAG =09 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG from a source to a destination passes through their closest common ancestor) and DAG routes through root (all DAG paths have to go through the DAG root). =09 3. Study the stretch factor (increase in length/cost of routes over the DAG versus the length/cost of ideal routes) for given number of flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the topology: a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% flows over longer paths. b) randomly selected source and destinations (in n*(n-1) case, from each possible source node to each possible destination node). =09 4. In addition to the stretch factor, calculate/simulate the traffic loads as well as packet loss/delay along the DAG links. Compare these values against values with ideal P2P routing. =09 Thanks Mukul ----- Original Message ----- From: "Joydeep Tripathi" To: "Jerald P Martocci" Cc: "ROLL WG" Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central Subject: [Roll] RPL Simulation =09 Hi, =09 In the next revision, we are also planning to implement a typical building routing scenario, where 60-70% of the P2P traffic are confined within 1 hop physical distance and, 20% of the P2P traffic are to a 2 -hop distance destination, and observe the performance of RPL against the ideal shortest route. Also, please let us know if there is any other scenario or traffic pattern you want to be implemented. =09 Thanks, Joydeep =09 _______________________________________________ Roll mailing list Roll@ietf.org =09 https://www.ietf.org/mailman/listinfo/roll =09 =09 =09 _______________________________________________ Roll mailing list Roll@ietf.org =09 https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CA9E99.66F0FF72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP
 
I see two assumptions which I would like to=20 discuss:
 
1) "...as soon as it becomes operational, A can send a DAO=20 ..."
   = The point=20 is that A has been operational all the time. RF conditions just=20 changed
   so that A cannot be reached via R3. Therefore A = is not=20 even aware that it is missing
   = a parent=20 =3D> it may not send a DAO for the next many = minutes
 
2)=20 "..If you = are using a=20 reactive mechanism instead of  proactive, this is not a=20 magic solution = either=20 ..."
   = Sure. We=20 agree in this. As discussed on the RPL editor list recently, = using the=20 flooding trick is
   = a backup=20 option which should only be used if you are in a hurry - which users = turning on=20 light are always.
   = Also, the=20 scope of that flooding does not need to be more than a diameter of 5 = hops. This=20 would suffice
   for home as well as for building=20 applications.
   I do=20 not argue for flooding the entire Internet!
 
Cheers,
 =20 Anders 
 

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Tuesday, January 26, 2010 15:19
To: Anders=20 Brandt
Cc: ROLL WG
Subject: Re: SV: [Roll] RPL = Simulation in=20 the home

Copying the list to continue that discussion - see = below 

Anders>

Anyway,
the use case is quite = simple:
 
Z - R1 - R2 - R3 -=20 A
 
1) Lamp module A was recently controlled by = controller=20 Z via router 1 -> router 2 -> router 3
  Z - R1 - R2 - = R3 -=20 A
 
2) Something renders the radio connection = unusable from=20 router 3 to lamp module A
3) The lamp module can however be reached = via router 1=20 -> router 4 -> router 5
    but router 5 has never = been routing=20 traffic to lamp module A
  Z - R1 - R2 - = R3 -=20 .
        \<= /DIV>
         - R4 = - R5 -=20 A
4) Controller Z sends another command to = lamp module A=20 via router 1
5) Router 1 sends the command to router 2 = which=20 forwards the command to router 3
6) Router 3 is unable to deliver the=20 command
 
What happens = now?

This is exactly why I was asking you the reason why you think = that it=20 should be reactive.
What you describe is routing protocol convergence, which of = course does=20 not imply that the
protocol should be reactive. This is a typical case where the = topology is=20 changing and RPL
needs to adapt to it, which it does. The way to meet your time=20 requirements is to adjust
the RPL parameters to make it quicker to converge. If there is a = link=20 between A and R5, 
as soon as it becomes operational, A can send a DAO and R1 will = direct=20 the traffic to R4
instead of R2.

Will the lamp go on within = 250ms?
 
<= /BLOCKQUOTE>

So you raise the issue of convergence time, fair. It all depends on = how you=20 tune RPL and A
selects R5 as a new parent. Note that you do not have to keep = sending=20 control traffic for 
that. If you links are extremely lossy you will have to make the = DAG fairly=20 reactive, which 
means more control traffic of course. If you are using a reactive = mechanism=20 instead of 
proactive, this is not a magic solution either since you flood your = network=20 and add control
messages too. 

What I think is that by using these mechanism you can achieve a = good level=20 of convergence
time with reasonable traffic in presence of lossy link w/o too much = control=20 traffic. We can try 
to quantify if you can provide an example topology, few stats on = the link=20 flaps trying few RPL
tuning. Could you ?

Thanks.

JP.

Thanks,
  Anders

From: JP Vasseur [mailto:jvasseur@cisco.com]=20
Sent: Thursday, January 21, 2010 09:11
To: = Anders=20 Brandt
Subject: Re: SV: [Roll] RPL = Simulation

Hi Anders,=20

On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
Sorry JP
 
I really have no intention of spreading=20 FUD.
Guess this mainly indicates that I and = Jerry need=20 education of what RPL is expected/able to = deliver.
 
At the most recent telecon we again = touched the issue=20 of e.g. a lamp module which due to rf phenomena
cannot be = reached via=20 the recent router - and I thought we had a common understanding = that some=20 reactive mechanism
would be needed.

Can RPL - in its current shape - = identify a new=20 route via a router which did not previously forward traffic to = said lamp=20 module?

Not sure of what you mean by this ?

I would love that but I need to = understand how - and=20 I would love to see your evidence!
 

Here is what I can propose: could you provide a home network = topology=20 that I could use to provide
simulations results ?

Cheers.

JP.

Thanks,
  Anders
 

From: JP Vasseur [mailto:jvasseur@cisco.com]=20
Sent: Wednesday, January 20, 2010 18:21
To: = Anders=20 Brandt
Subject: Re: SV: [Roll] RPL=20 Simulation

Hi Anders,=20

On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
Hi JP
 
> Are you saying that RPL is not good enough for P2P =  in=20 home and building?
 
Well - which incarnation of RPL? (!)
I was of the impression that we had a common understanding = that the=20 ability to
operate in a reactive fasion is critical to home = &=20 building and that the DAG update
signaling currently designed = will=20 have much bigger delays than the 250ms real-time
users will=20 tolerate.

Where does that come from ? 

 
> Since I have evidence that it is not the case.
> Do you have data that shows different results ?
 
I may have misunderstood the telecon conclusions, but I got = it so=20 that over time
DAG routes will reconstructed, but that the = current=20 spec cannot find a lost target on demand (?).
 
> Because as you know it is now in our charter to work = on other=20 protocols.
now? I guess you mean "not" ? (!)
My conclusion from the Rolle interim was that we needed = something=20 special to find routes across the cloud.
If the DAG can re-establish contact within 250ms to an = operational=20 node that was just lost in a routing table,
I would really = love it.=20 Is that the = case?

mmm I do not think so ... happy to discuss it live with you=20 though.

Cheers!

JP.

 
Cheers,
  Anders

Fra: JP Vasseur [mailto:jvasseur@cisco.com]
S= endt:=20 on 20-01-2010 17:02
Til: Anders Brandt
Emne: = Re:=20 [Roll] RPL Simulation

Hi Anders,=20

off-line first.

On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
Jerry,
 
>That was what was nice about an AODV = concept,=20 because even route repair was fairly deterministic. =

As far as I am informed = some=20 reactive discovery mechanism is still needed for all the = reasons that=20 you list below.
You may=20 remember that we have the same needs in home automation.
By = utilizing the fact that source routing is already used to jump = between=20 RPL-capable routers AND the fact that the (time=20 critical)
point-to-point communication is limited to 5 hops = or=20 less, some TTL-aware, source-route-based AODV hybrid may = not=20 cause so
much flooding as one could=20 fear.

Are you saying that RPL is not good enough for P2P  in = home=20 and building ? Since I have evidence that it is not the = case.
Do you have data that shows different results ?
Because as you know it is now in our charter to work on = other=20 protocols.

Thanks.

JP.

 
- Anders
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 On Behalf Of Jerald.P.Martocci@jci.comSent:=20 Thursday, January 14, 2010 19:11
To: Joydeep=20 Tripathi
Cc: ROLL WG
Subject: Re: [Roll] = RPL=20 Simulation


Hi = Joydeep,=20

Mukul's been doing = some=20 simulations for my company for the past 3 years.  He has = a good=20 handle on the commercial building performance requirements. =  It=20 would be good for you to run those he notes below.  It = might be=20 advantageous then for you two to share the results to better = correlate=20 the simulations.

I would=20 also look at the latency for P2P messages when the packet(s) = need to=20 traverse the DAG all the way up to the LBR and back down to = the=20 destination node.  Of course, this is now a function on = DAG=20 depth.  Also since all our messages require ACK, the = additional=20 latency of the ACK having to return possibly through a = different set=20 of nodes yet via the LBR.  That would be the worst case = scenario.=20  If other nodes could short circuit the packets through a = shorter=20 path, that would on;y help.

Since Building systems are real-time (smoke/fire = detection,=20 turning on lights, etc) latency is a big issue.  Moving = the=20 packet up and down the DAG is reasonably deterministic and = should be=20 primarily a function of the DAG depth.  However, what = will really=20 affect the system performance is 'DAG Repair'.  I have no = sense=20 how long a packet in transit would have to wait if the DAG was = under=20 repair.  Since we require ACKs of every message, the = source node=20 would time-out and retry a few times (usually 3).  After = that,=20 the source node would have to fall into some 'failsoft' mode = depending=20 on the type of data it was trying to access.  This is not = a good=20 situation.  The source node can only assume that its data = is=20 inaccessible, not just held up in transit.  The fail-soft = mode=20 will have large hysteresis since it can't be constantly = dithering=20 between modes.  This will all be logged to the operator = which is=20 a bad thing!!!  That was what was nice about an AODV = concept,=20 because even route repair was fairly deterministic.=20

So... if your = simulation could=20 measure packet latency as a function of DAG repair severity, = that=20 would be terrific.

Hope=20 this makes sense.

Jerry



<ATT129641.jpg> =


Mukul Goyal=20 <mukul@uwm.edu>=20

01/13/2010 10:17 = AM=20

To
 Joydeep = Tripathi <joydeep.tripathi@gmail.com= >=20
cc
 ROLL WG <roll@ietf.org>, Jerald=20 P Martocci <Jerald.P.Martocci@jci.com&g= t;=20
Subject
 Re: [Roll] RPL=20 Simulation

=




<= FONT=20 size=3D2>Joydeep

Here are a few suggestions for = your=20 simulations:

1. Simulate a 100 node and a 1000 node = topology=20 operating under a single DAG

2. Simulate both = scenarios:=20 optimal DAG routes (ie the path through the DAG from a source = to a=20 destination passes through their closest common ancestor) and = DAG=20 routes through root (all DAG paths have to go through the DAG=20 root).

3. Study the stretch factor (increase in = length/cost of=20 routes over the DAG versus the length/cost of ideal routes) = for given=20 number of flows: 100, 1000, 10000 and possibly n*(n-1) flows = (where n=20 is the number of nodes in the topology:
a) the scenario you = suggested: Choose 20% flows over 2 hop neighbors, 10% flows = over=20 longer paths.
b) randomly selected source and destinations = (in=20 n*(n-1) case, from each possible source node to each possible=20 destination node).

4. In addition to the stretch = factor,=20 calculate/simulate the traffic loads as well as packet = loss/delay=20 along the DAG links. Compare these values against values with = ideal=20 P2P routing.

Thanks
Mukul
----- Original Message=20 -----
From: "Joydeep Tripathi" <joydeep.tripathi@gmail.com= >
To:=20 "Jerald P Martocci" <Jerald.P.Martocci@jci.com&g= t;
Cc:=20 "ROLL WG" <roll@ietf.org>
Sent: = Wednesday,=20 January 13, 2010 2:24:36 AM GMT -06:00 US/Canada = Central
Subject:=20 [Roll] RPL Simulation

Hi,

In the next revision, = we are=20 also planning to implement a typical
building routing = scenario,=20 where 60-70% of the P2P traffic are
confined within 1 hop = physical=20 distance and, 20% of the P2P traffic
are to a 2 -hop = distance=20 destination, and observe the performance of
RPL against the = ideal=20 shortest route. Also, please let us know if
there is any = other=20 scenario or traffic pattern you want to=20 = be
implemented.

Thanks,
Joydeep
_________________________= ______________________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll

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





------_=_NextPart_001_01CA9E99.66F0FF72-- From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 08:30:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912A93A68CD for ; Tue, 26 Jan 2010 08:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rdd5kqhNuXis for ; Tue, 26 Jan 2010 08:30:04 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id BB0FB3A68A9 for ; Tue, 26 Jan 2010 08:30:03 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 26 Jan 2010 10:30:13 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3CD222C382D7; Tue, 26 Jan 2010 10:30:13 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GTb2z603KrS; Tue, 26 Jan 2010 10:30:12 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A302E2C382D6; Tue, 26 Jan 2010 10:30:12 -0600 (CST) Date: Tue, 26 Jan 2010 10:30:12 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <1481020643.492311264523412552.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <64994F3E-3C07-4332-AA2A-1AA54AF57DF6@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 16:30:21 -0000 JP, The obvious problem with proactive approaches, such as RPL, is the need to = maintain reachability information for all possible destinations to which so= me source might send a packet some day. That's why we need source-initiated= route discovery, i.e. a reactive approach. Thanks Mukul =20 ----- Original Message ----- From: "JP Vasseur" To: "Anders Brandt" Cc: "ROLL WG" Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL Simulation in the home Copying the list to continue that discussion - see below=C2=A0=20 Anders>=20 Anyway,=20 the use case is quite simple:=20 =C2=A0=20 Z - R1 - R2 - R3 - A=20 =C2=A0=20 1) Lamp module A was recently controlled by controller Z via router 1 -> ro= uter 2 -> router 3=20 =C2=A0 Z - R1 - R2 - R3 - A=20 =C2=A0=20 2) Something renders the radio connection unusable from router 3 to lamp mo= dule A=20 3) The lamp module can however be reached via router 1 -> router 4 -> route= r 5=20 =C2=A0=C2=A0=C2=A0 but router 5 has never been routing traffic to lamp modu= le A=20 =C2=A0 Z - R1 - R2 - R3 - .=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0\=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- R4 - R5 - A=20 4) Controller Z sends another command to lamp module A via router 1=20 5) Router 1 sends the command to router 2 which forwards the command to rou= ter 3=20 6) Router 3 is unable to deliver the command=20 =C2=A0=20 What happens now?=20 This is exactly why I was asking you the reason why you think that it shoul= d be reactive.=20 What you describe is routing protocol convergence, which of course does not= imply that the=20 protocol should be reactive. This is a typical case where the topology is c= hanging and RPL=20 needs to adapt to it, which it does. The way to meet your time requirements= is to adjust=20 the RPL parameters to make it quicker to converge. If there is a link betwe= en A and R5,=C2=A0=20 as soon as it becomes operational, A can send a DAO and R1 will direct the = traffic to R4=20 instead of R2.=20 Will the lamp go on within 250ms?=20 =C2=A0=20 So you raise the issue of convergence time, fair. It all depends on how you= tune RPL and A=20 selects R5 as a new parent. Note that you do not have to keep sending contr= ol traffic for=C2=A0=20 that. If you links are extremely lossy you will have to make the DAG fairly= reactive, which=C2=A0=20 means more control traffic of course. If you are using a reactive mechanism= instead of=C2=A0=20 proactive, this is not a magic solution either since you flood your network= and add control=20 messages too.=C2=A0=20 What I think is that by using these mechanism you can achieve a good level = of convergence=20 time with reasonable traffic in presence of lossy link w/o too much control= traffic. We can try=C2=A0=20 to quantify if you can provide an example topology, few stats on the link f= laps trying few RPL=20 tuning. Could you ?=20 Thanks.=20 JP.=20 Thanks,=20 =C2=A0 Anders=20 From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 Sent: Thursday, January 21, 2010 09:11=20 To: Anders Brandt=20 Subject: Re: SV: [Roll] RPL Simulation=20 Hi Anders,=20 On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:=20 Sorry JP=20 =C2=A0=20 I really have no intention of spreading FUD.=20 Guess this mainly indicates that I and Jerry need education of what RPL is = expected/able to deliver.=20 =C2=A0=20 At the most recent telecon we again touched the issue of e.g. a lamp module= which due to rf phenomena=20 cannot be reached via the recent router - and I thought we had a common und= erstanding that some reactive mechanism=20 would be needed.=20 Can RPL - in its current shape - identify a new route via a router which di= d not previously forward traffic to said lamp module?=20 Not sure of what you mean by this ?=20 I would love that but I need to understand how - and I would love to see yo= ur evidence!=20 =C2=A0=20 Here is what I can propose: could you provide a home network topology that = I could use to provide=20 simulations results ?=20 Cheers.=20 JP.=20 Thanks,=20 =C2=A0 Anders=20 =C2=A0=20 From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 Sent: Wednesday, January 20, 2010 18:21=20 To: Anders Brandt=20 Subject: Re: SV: [Roll] RPL Simulation=20 Hi Anders,=20 On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:=20 Hi JP=20 =C2=A0=20 > Are you saying that RPL is not good enough for P2P =C2=A0in home and buil= ding?=20 =C2=A0=20 Well - which incarnation of RPL? (!)=20 I was of the impression that we had a common understanding that the ability= to=20 operate in a reactive fasion is critical to home & building and that the DA= G update=20 signaling currently designed will have much bigger delays than the 250ms re= al-time=20 users will tolerate.=20 Where does that come from ?=C2=A0=20 =C2=A0=20 > Since I have evidence that it is not the case.=20 > Do you have data that shows different results ?=20 =C2=A0=20 I may have misunderstood the telecon conclusions, but I got it so that over= time=20 DAG routes will reconstructed, but that the current spec cannot find a lost= target on demand (?).=20 =C2=A0=20 > Because as you know it is now in our charter to work on other protocols.= =20 now? I guess you mean "not" ? (!)=20 My conclusion from the Rolle interim was that we needed something special t= o find routes across the cloud.=20 If the DAG can re-establish contact within 250ms to an operational node tha= t was just lost in a routing table,=20 I would really love it. Is that the case?=20 mmm I do not think so ... happy to discuss it live with you though.=20 Cheers!=20 JP.=20 =C2=A0=20 Cheers,=20 =C2=A0 Anders=20 Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 Sendt: on 20-01-2010 17:02=20 Til: Anders Brandt=20 Emne: Re: [Roll] RPL Simulation=20 Hi Anders,=20 off-line first.=20 On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:=20 Jerry,=20 =C2=A0=20 >That was what was nice about an AODV concept, because even route repair wa= s fairly deterministic.=20 As far as I am informed some reactive discovery mechanism is still needed f= or all the reasons that you list below.=20 You may remember that we have the same needs in home automation.=20 By utilizing the fact that source routing is already used to jump between R= PL-capable routers AND the fact that the (time critical)=20 point-to-point communication is limited to 5 hops or less, some TTL-aware, = source-route-based AODV hybrid=C2=A0may not cause so=20 much flooding as one could fear.=20 Are you saying that RPL is not good enough for P2P =C2=A0in home and buildi= ng ? Since I have evidence that it is not the case.=20 Do you have data that shows different results ?=20 Because as you know it is now in our charter to work on other protocols.=20 Thanks.=20 JP.=20 =C2=A0=20 - Anders=20 =C2=A0=20 =C2=A0=20 From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of J= erald.P.Martocci@jci.com=20 Sent: Thursday, January 14, 2010 19:11=20 To: Joydeep Tripathi=20 Cc: ROLL WG=20 Subject: Re: [Roll] RPL Simulation=20 Hi Joydeep,=20 Mukul's been doing some simulations for my company for the past 3 years. = =C2=A0He has a good handle on the commercial building performance requireme= nts. =C2=A0It would be good for you to run those he notes below. =C2=A0It m= ight be advantageous then for you two to share the results to better correl= ate the simulations.=20 I would also look at the latency for P2P messages when the packet(s) need t= o traverse the DAG all the way up to the LBR and back down to the destinati= on node. =C2=A0Of course, this is now a function on DAG depth. =C2=A0Also s= ince all our messages require ACK, the additional latency of the ACK having= to return possibly through a different set of nodes yet via the LBR. =C2= =A0That would be the worst case scenario. =C2=A0If other nodes could short = circuit the packets through a shorter path, that would on;y help.=20 Since Building systems are real-time (smoke/fire detection, turning on ligh= ts, etc) latency is a big issue. =C2=A0Moving the packet up and down the DA= G is reasonably deterministic and should be primarily a function of the DAG= depth. =C2=A0However, what will really affect the system performance is 'D= AG Repair'. =C2=A0I have no sense how long a packet in transit would have t= o wait if the DAG was under repair. =C2=A0Since we require ACKs of every me= ssage, the source node would time-out and retry a few times (usually 3). = =C2=A0After that, the source node would have to fall into some 'failsoft' m= ode depending on the type of data it was trying to access. =C2=A0This is no= t a good situation. =C2=A0The source node can only assume that its data is = inaccessible, not just held up in transit. =C2=A0The fail-soft mode will ha= ve large hysteresis since it can't be constantly dithering between modes. = =C2=A0This will all be logged to the operator which is a bad thing!!! =C2= =A0That was what was nice about an AODV concept, because even route repair = was fairly deterministic.=20 So... if your simulation could measure packet latency as a function of DAG = repair severity, that would be terrific.=20 Hope this makes sense.=20 Jerry=20 =20 Mukul Goyal < mukul@uwm.edu >=20 01/13/2010 10:17 AM =09 To =09Joydeep Tripathi < joydeep.tripathi@gmail.com >=20 cc =09ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.= com >=20 Subject =09Re: [Roll] RPL Simulation=20 =09 Joydeep=20 Here are a few suggestions for your simulations:=20 1. Simulate a 100 node and a 1000 node topology operating under a single DA= G=20 2. Simulate both scenarios: optimal DAG routes (ie the path through the DAG= from a source to a destination passes through their closest common ancesto= r) and DAG routes through root (all DAG paths have to go through the DAG ro= ot).=20 3. Study the stretch factor (increase in length/cost of routes over the DAG= versus the length/cost of ideal routes) for given number of flows: 100, 10= 00, 10000 and possibly n*(n-1) flows (where n is the number of nodes in the= topology:=20 a) the scenario you suggested: Choose 20% flows over 2 hop neighbors, 10% f= lows over longer paths.=20 b) randomly selected source and destinations (in n*(n-1) case, from each po= ssible source node to each possible destination node).=20 4. In addition to the stretch factor, calculate/simulate the traffic loads = as well as packet loss/delay along the DAG links. Compare these values agai= nst values with ideal P2P routing.=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >=20 To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >=20 Cc: "ROLL WG" < roll@ietf.org >=20 Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada Central= =20 Subject: [Roll] RPL Simulation=20 Hi,=20 In the next revision, we are also planning to implement a typical=20 building routing scenario, where 60-70% of the P2P traffic are=20 confined within 1 hop physical distance and, 20% of the P2P traffic=20 are to a 2 -hop distance destination, and observe the performance of=20 RPL against the ideal shortest route. Also, please let us know if=20 there is any other scenario or traffic pattern you want to be=20 implemented.=20 Thanks,=20 Joydeep=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Jan 26 09:01:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A150F3A67F4 for ; Tue, 26 Jan 2010 09:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.865 X-Spam-Level: X-Spam-Status: No, score=-8.865 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-yAu1-toNqE for ; Tue, 26 Jan 2010 09:01:39 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A59A43A67CC for ; Tue, 26 Jan 2010 09:01:38 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADiuXktAZnwM/2dsb2JhbADDcpckgi2CDASNYg X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="82097055" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2010 17:01:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0QH1d8E005634; Tue, 26 Jan 2010 17:01:41 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:01:14 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:01:13 +0100 Message-Id: <66B586A5-4A79-4B91-A1A6-0E5EEA0C2EB2@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1481020643.492311264523412552.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 18:01:12 +0100 References: <1481020643.492311264523412552.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jan 2010 17:01:13.0683 (UTC) FILETIME=[2AB7CA30:01CA9EA9] Cc: ROLL WG Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 17:01:40 -0000 Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Jan 26 09:20:27 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC723A67CC; Tue, 26 Jan 2010 09:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P93z2EeMlX1; Tue, 26 Jan 2010 09:20:24 -0800 (PST) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by core3.amsl.com (Postfix) with ESMTP id 671EF3A67AE; Tue, 26 Jan 2010 09:20:19 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKS18kXTQclLLaWLEX1rY4aE1SBtd/AzeZ@postini.com; Tue, 26 Jan 2010 09:20:30 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010012611202991-222213 ; Tue, 26 Jan 2010 11:20:29 -0600 In-Reply-To: <66B586A5-4A79-4B91-A1A6-0E5EEA0C2EB2@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 26 Jan 2010 11:20:20 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/26/2010 11:20:22 AM, Serialize complete at 01/26/2010 11:20:22 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 11:20:29 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 11:20:37 AM, Serialize complete at 01/26/2010 11:20:37 AM Content-Type: multipart/alternative; boundary="=_alternative 005F3E6A862576B7_=" Cc: ROLL WG , Mukul Goyal , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 17:20:27 -0000 This is a multipart message in MIME format. --=_alternative 005F3E6A862576B7_= Content-Type: text/plain; charset="US-ASCII" Hi JP, My $.02 on your answers: 1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building. 2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes. 2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 01/26/2010 11:01 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 005F3E6A862576B7_= Content-Type: text/html; charset="US-ASCII"
Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes.

Regards,

Jerry




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

01/26/2010 11:01 AM

To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation        in the home





Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the  
> need to maintain reachability information for all possible  
> destinations to which some source might send a packet some day.  
> That's why we need source-initiated route discovery, i.e. a reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 -
> > router 5
>    but router 5 has never been routing traffic to lamp module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that  
> it should be reactive.
> What you describe is routing protocol convergence, which of course  
> does not imply that the
> protocol should be reactive. This is a typical case where the  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep  
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a reactive  
> mechanism instead of
> proactive, this is not a magic solution either since you flood your  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router  
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the  
> ability to
> operate in a reactive fasion is critical to home & building and that  
> the DAG update
> signaling currently designed will have much bigger delays than the  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so  
> that over time
> DAG routes will reconstructed, but that the current spec cannot find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route  
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still  
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump  
> between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P  in home and  
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On  
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3  
> years.  He has a good handle on the commercial building performance  
> requirements.  It would be good for you to run those he notes  
> below.  It might be advantageous then for you two to share the  
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s)  
> need to traverse the DAG all the way up to the LBR and back down to  
> the destination node.  Of course, this is now a function on DAG  
> depth.  Also since all our messages require ACK, the additional  
> latency of the ACK having to return possibly through a different set  
> of nodes yet via the LBR.  That would be the worst case scenario.  
> If other nodes could short circuit the packets through a shorter  
> path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning  
> on lights, etc) latency is a big issue.  Moving the packet up and  
> down the DAG is reasonably deterministic and should be primarily a  
> function of the DAG depth.  However, what will really affect the  
> system performance is 'DAG Repair'.  I have no sense how long a  
> packet in transit would have to wait if the DAG was under repair.  
> Since we require ACKs of every message, the source node would time-
> out and retry a few times (usually 3).  After that, the source node  
> would have to fall into some 'failsoft' mode depending on the type  
> of data it was trying to access.  This is not a good situation.  The  
> source node can only assume that its data is inaccessible, not just  
> held up in transit.  The fail-soft mode will have large hysteresis  
> since it can't be constantly dithering between modes.  This will all  
> be logged to the operator which is a bad thing!!!  That was what was  
> nice about an AODV concept, because even route repair was fairly  
> deterministic.
>
> So... if your simulation could measure packet latency as a function  
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM                  
> To                  Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc                  ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com
>  >
>
> Subject                  Re: [Roll] RPL Simulation
>                  
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a  
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through  
> the DAG from a source to a destination passes through their closest  
> common ancestor) and DAG routes through root (all DAG paths have to  
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over  
> the DAG versus the length/cost of ideal routes) for given number of  
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the  
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop  
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from  
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic  
> loads as well as packet loss/delay along the DAG links. Compare  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada  
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic
> are to a 2 -hop distance destination, and observe the performance of
> RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 005F3E6A862576B7_=-- From d.sturek@att.net Tue Jan 26 09:47:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F31F3A67CC for ; Tue, 26 Jan 2010 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD1ixLPJnq1J for ; Tue, 26 Jan 2010 09:46:59 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id A7D8C3A6774 for ; Tue, 26 Jan 2010 09:46:59 -0800 (PST) Received: (qmail 42841 invoked from network); 26 Jan 2010 17:47:08 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2010 09:47:07 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: lBtabWEVM1mnDsiOWAOJXwyBIuRLR6dN_wq2Q2w6H.QOQ3vc9Bfr2zAOownIK8navHfUWKfuBt0DuMya2xGvIvVVIs0hKtwUHDegah6WyMitGHTcyA_KvxyU1ykcFNLTCDU5YxPwNbNuJ5wYWiiTbmYL8ck3.9zqDUHr0EUhHsXyVlRjWhde0Wt44vfpUF7LySGZktixf4fZDvXKN92g_jm2XKVvWoohJzz0Le7lJHOZxVSoZtFvCIW9mbUt8XN6ZiQMhVptfBHMSL3eOFSNk_6FphBvZHe3qej421uq9PoxSB3bgqM- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: , "'JP Vasseur'" References: <66B586A5-4A79-4B91-A1A6-0E5EEA0C2EB2@cisco.com> In-Reply-To: Date: Tue, 26 Jan 2010 09:47:03 -0800 Message-ID: <01be01ca9eaf$91db8a70$b5929f50$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01CA9E6C.83B84A70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqeq+MW3bGpQKRIQrG4EG+Iyra3DQAAl06Q Content-Language: en-us Cc: 'ROLL WG' , 'Mukul Goyal' , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:47:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01BF_01CA9E6C.83B84A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jerry, I think the note below correctly reflects building automation requirements. Having 1000 devices on a building floor would not be a surprise. The trouble with reactive route discovery is many of the existing MANET protocols like AODV scale with the number of devices in the network (so have to be tailored by deployment). For example, route table size is an example of a scaling resource in AODV. I think in cases where there is a needed reactive route discovery, we need to identify how to avoid making the solution scale with deployment while still supporting low latency messaging. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Tuesday, January 26, 2010 9:20 AM To: JP Vasseur Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi JP, My $.02 on your answers: 1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building. 2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes. 2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 01/26/2010 11:01 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_01BF_01CA9E6C.83B84A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jerry,

 

I think the note below correctly reflects building = automation requirements.   Having 1000 devices on a building floor would not be a = surprise.

 

The trouble with reactive route discovery is many of the existing MANET protocols like AODV scale with the number of devices in = the network (so have to be tailored by deployment).   For example, = route table size is an example of a scaling resource in AODV.  I think in = cases where there is a needed reactive route discovery, we need to identify = how to avoid making the solution scale with deployment while still supporting = low latency messaging.

 

Don

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home

 


Hi = JP,

My = $.02 on your answers:

1) In = a building there may 1000 devices in an LLN; hence even if Anders does not = have this requirement for a home, I do have this requirement for a = building.

2) My understanding is that for 6LoWPAN networks all devices are on a flat = network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is = no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a = priori way to preselect routes.

Regards,

Jerry =



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

01/26/2010 11:01 AM

To=

Mukul Goyal <mukul@UWM.EDU>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation =        in the home

 




Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is = the  
> need to maintain reachability information for all possible =  
> destinations to which some source might send a packet some day. =  
> That's why we need source-initiated route discovery, i.e. a = reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home = ?
2) In so, this is where route aggregation/summarization can = help.

This is why I'm challenging the need for an a priori reactive =  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" = <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see = below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via = router  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router = 3 to  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> = router 4 -
> > router 5
>    but router 5 has never been routing traffic to = lamp module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via = router 1
> 5) Router 1 sends the command to router 2 which forwards the = command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think = that  
> it should be reactive.
> What you describe is routing protocol convergence, which of = course  
> does not imply that the
> protocol should be reactive. This is a typical case where the =  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time =  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is = a  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will =  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all = depends on  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep =  
> sending control traffic for
> that. If you links are extremely lossy you will have to make = the DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a = reactive  
> mechanism instead of
> proactive, this is not a magic solution either since you flood = your  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a = good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too = much  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats = on the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of = what  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a = lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had = a  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a = router  
> which did not previously forward traffic to said lamp = module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would = love to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network =  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in = home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that = the  
> ability to
> operate in a reactive fasion is critical to home & building = and that  
> the DAG update
> signaling currently designed will have much bigger delays than = the  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it = so  
> that over time
> DAG routes will reconstructed, but that the current spec cannot = find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on = other  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed = something  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an = operational  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you = though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even = route  
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is = still  
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home = automation.
> By utilizing the fact that source routing is already used to = jump  
> between RPL-capable routers AND the fact that the (time = critical)
> point-to-point communication is limited to 5 hops or less, some = TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P  in = home and  
> building ? Since I have evidence that it is not the = case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other =  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =  
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past = 3  
> years.  He has a good handle on the commercial building performance  
> requirements.  It would be good for you to run those he = notes  
> below.  It might be advantageous then for you two to share = the  
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the = packet(s)  
> need to traverse the DAG all the way up to the LBR and back = down to  
> the destination node.  Of course, this is now a function = on DAG  
> depth.  Also since all our messages require ACK, the = additional  
> latency of the ACK having to return possibly through a = different set  
> of nodes yet via the LBR.  That would be the worst case = scenario.  
> If other nodes could short circuit the packets through a = shorter  
> path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, = turning  
> on lights, etc) latency is a big issue.  Moving the packet = up and  
> down the DAG is reasonably deterministic and should be = primarily a  
> function of the DAG depth.  However, what will really = affect the  
> system performance is 'DAG Repair'.  I have no sense how = long a  
> packet in transit would have to wait if the DAG was under = repair.  
> Since we require ACKs of every message, the source node would = time-
> out and retry a few times (usually 3).  After that, the = source node  
> would have to fall into some 'failsoft' mode depending on the = type  
> of data it was trying to access.  This is not a good = situation.  The  
> source node can only assume that its data is inaccessible, not = just  
> held up in transit.  The fail-soft mode will have large hysteresis  
> since it can't be constantly dithering between modes. =  This will all  
> be logged to the operator which is a bad thing!!!  That = was what was  
> nice about an AODV concept, because even route repair was = fairly  
> deterministic.
>
> So... if your simulation could measure packet latency as a = function  
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM             =      
> To                  Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc                 =  ROLL WG < roll@ietf.org >, Jerald P Martocci < = Jerald.P.Martocci@jci.com
>  >
>
> Subject                  Re: [Roll] RPL Simulation
>                 =  
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under = a  
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path = through  
> the DAG from a source to a destination passes through their = closest  
> common ancestor) and DAG routes through root (all DAG paths = have to  
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes = over  
> the DAG versus the length/cost of ideal routes) for given = number of  
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is = the  
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop =  
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, = from  
> each possible source node to each possible destination = node).
>
> 4. In addition to the stretch factor, calculate/simulate the = traffic  
> loads as well as packet loss/delay along the DAG links. Compare =  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < = joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < = Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 = US/Canada  
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a = typical
> building routing scenario, where 60-70% of the P2P traffic = are
> confined within 1 hop physical distance and, 20% of the P2P = traffic
> are to a 2 -hop distance destination, and observe the = performance of
> RPL against the ideal shortest route. Also, please let us know = if
> there is any other scenario or traffic pattern you want to = be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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

=
------=_NextPart_000_01BF_01CA9E6C.83B84A70-- From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 10:19:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDC63A6892; Tue, 26 Jan 2010 10:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sneZyfOxmu2K; Tue, 26 Jan 2010 10:19:13 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 38EB73A687C; Tue, 26 Jan 2010 10:19:12 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 26 Jan 2010 12:19:22 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8DAD52C382C9; Tue, 26 Jan 2010 12:19:22 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuS71tFW3lrZ; Tue, 26 Jan 2010 12:19:21 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id DC1E32C382C6; Tue, 26 Jan 2010 12:19:21 -0600 (CST) Date: Tue, 26 Jan 2010 12:19:21 -0600 (CST) From: Mukul Goyal To: Jerald P Martocci Message-ID: <90673155.575771264529961762.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 18:19:16 -0000 Just to add to the 2nd point Jerry raised: I am not sure how prefix aggrega= tion is going to work in 6lowpan/ROLL networks. Neither were most of people= I talked to in this regard. So, there is a need for a document (or a secti= on in RPL draft) explaining in detail how this would be done. Thanks Mukul =20 ----- Original Message ----- From: "Jerald P Martocci" To: "JP Vasseur" Cc: "Mukul Goyal" , "ROLL WG" , roll-bounces@= ietf.org Sent: Tuesday, January 26, 2010 11:20:20 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation= =09in the home Hi JP,=20 My $.02 on your answers:=20 1) In a building there may 1000 devices in an LLN; hence even if Anders doe= s not have this requirement for a home, I do have this requirement for a bu= ilding.=20 2) My understanding is that for 6LoWPAN networks all devices are on a flat = network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence the= re is no way to aggregate routes.=20 2a) Source/destination routes are completely random; hence there is no a pr= iori way to preselect routes.=20 Regards,=20 Jerry=20 JP Vasseur =20 Sent by: roll-bounces@ietf.org=20 01/26/2010 11:01 AM =09 To =09Mukul Goyal =20 cc =09ROLL WG =20 Subject =09Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulati= on =C2=A0 =C2=A0 =C2=A0 =C2=A0in the home=20 =09 Hi Mukul,=20 On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:=20 > JP,=20 >=20 > The obvious problem with proactive approaches, such as RPL, is the =C2=A0= =20 > need to maintain reachability information for all possible =C2=A0=20 > destinations to which some source might send a packet some day. =C2=A0=20 > That's why we need source-initiated route discovery, i.e. a reactive =C2= =A0=20 > approach.=20 >=20 Several answers here:=20 1) Are there such as huge number of unicast addresses in a home ?=20 2) In so, this is where route aggregation/summarization can help.=20 This is why I'm challenging the need for an a priori reactive =C2=A0=20 mechanism here before we prove that=20 reactive is not good enough.=20 Makes sense ?=20 ps: again acting with no co-chair hat.=20 Thanks.=20 JP.=20 > Thanks=20 > Mukul=20 >=20 > ----- Original Message -----=20 > From: "JP Vasseur" =20 > To: "Anders Brandt" =20 > Cc: "ROLL WG" =20 > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =C2=A0=20 > Central=20 > Subject: Re: [Roll] RPL Simulation in the home=20 >=20 >=20 > Copying the list to continue that discussion - see below=20 >=20 >=20 >=20 > Anders>=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Anyway,=20 > the use case is quite simple:=20 >=20 > Z - R1 - R2 - R3 - A=20 >=20 > 1) Lamp module A was recently controlled by controller Z via router =C2= =A0=20 > 1 -> router 2 -> router 3=20 >=20 > =C2=A0Z - R1 - R2 - R3 - A=20 >=20 > 2) Something renders the radio connection unusable from router 3 to =C2= =A0=20 > lamp module A=20 > 3) The lamp module can however be reached via router 1 -> router 4 -=20 > > router 5=20 > =C2=A0 =C2=A0but router 5 has never been routing traffic to lamp module A= =20 >=20 > =C2=A0Z - R1 - R2 - R3 - .=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0\=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 - R4 - R5 - A=20 > 4) Controller Z sends another command to lamp module A via router 1=20 > 5) Router 1 sends the command to router 2 which forwards the command =C2= =A0=20 > to router 3=20 > 6) Router 3 is unable to deliver the command=20 >=20 > What happens now?=20 >=20 >=20 > This is exactly why I was asking you the reason why you think that =C2=A0= =20 > it should be reactive.=20 > What you describe is routing protocol convergence, which of course =C2=A0= =20 > does not imply that the=20 > protocol should be reactive. This is a typical case where the =C2=A0=20 > topology is changing and RPL=20 > needs to adapt to it, which it does. The way to meet your time =C2=A0=20 > requirements is to adjust=20 > the RPL parameters to make it quicker to converge. If there is a =C2=A0= =20 > link between A and R5,=20 > as soon as it becomes operational, A can send a DAO and R1 will =C2=A0=20 > direct the traffic to R4=20 > instead of R2.=20 >=20 >=20 >=20 >=20 > Will the lamp go on within 250ms?=20 >=20 >=20 >=20 > So you raise the issue of convergence time, fair. It all depends on =C2= =A0=20 > how you tune RPL and A=20 > selects R5 as a new parent. Note that you do not have to keep =C2=A0=20 > sending control traffic for=20 > that. If you links are extremely lossy you will have to make the DAG =C2= =A0=20 > fairly reactive, which=20 > means more control traffic of course. If you are using a reactive =C2=A0= =20 > mechanism instead of=20 > proactive, this is not a magic solution either since you flood your =C2= =A0=20 > network and add control=20 > messages too.=20 >=20 >=20 > What I think is that by using these mechanism you can achieve a good =C2= =A0=20 > level of convergence=20 > time with reasonable traffic in presence of lossy link w/o too much =C2= =A0=20 > control traffic. We can try=20 > to quantify if you can provide an example topology, few stats on the =C2= =A0=20 > link flaps trying few RPL=20 > tuning. Could you ?=20 >=20 >=20 > Thanks.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks,=20 > =C2=A0Anders=20 >=20 >=20 > From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sent: Thursday, January 21, 2010 09:11=20 > To: Anders Brandt=20 > Subject: Re: SV: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 >=20 > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 > Sorry JP=20 >=20 > I really have no intention of spreading FUD.=20 > Guess this mainly indicates that I and Jerry need education of what =C2= =A0=20 > RPL is expected/able to deliver.=20 >=20 > At the most recent telecon we again touched the issue of e.g. a lamp =C2= =A0=20 > module which due to rf phenomena=20 > cannot be reached via the recent router - and I thought we had a =C2=A0= =20 > common understanding that some reactive mechanism=20 > would be needed.=20 >=20 > Can RPL - in its current shape - identify a new route via a router =C2=A0= =20 > which did not previously forward traffic to said lamp module?=20 >=20 >=20 >=20 > Not sure of what you mean by this ?=20 >=20 >=20 >=20 >=20 > I would love that but I need to understand how - and I would love to =C2= =A0=20 > see your evidence!=20 >=20 >=20 >=20 > Here is what I can propose: could you provide a home network =C2=A0=20 > topology that I could use to provide=20 > simulations results ?=20 >=20 >=20 > Cheers.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 > Thanks,=20 > =C2=A0Anders=20 >=20 >=20 >=20 > From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sent: Wednesday, January 20, 2010 18:21=20 > To: Anders Brandt=20 > Subject: Re: SV: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 >=20 > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi JP=20 >=20 >> Are you saying that RPL is not good enough for P2P =C2=A0in home and =C2= =A0=20 >> building?=20 >=20 > Well - which incarnation of RPL? (!)=20 > I was of the impression that we had a common understanding that the =C2= =A0=20 > ability to=20 > operate in a reactive fasion is critical to home & building and that =C2= =A0=20 > the DAG update=20 > signaling currently designed will have much bigger delays than the =C2=A0= =20 > 250ms real-time=20 > users will tolerate.=20 >=20 >=20 > Where does that come from ?=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Since I have evidence that it is not the case.=20 >> Do you have data that shows different results ?=20 >=20 > I may have misunderstood the telecon conclusions, but I got it so =C2=A0= =20 > that over time=20 > DAG routes will reconstructed, but that the current spec cannot find =C2= =A0=20 > a lost target on demand (?).=20 >=20 >=20 >> Because as you know it is now in our charter to work on other =C2=A0=20 >> protocols.=20 > now? I guess you mean "not" ? (!)=20 > My conclusion from the Rolle interim was that we needed something =C2=A0= =20 > special to find routes across the cloud.=20 > If the DAG can re-establish contact within 250ms to an operational =C2=A0= =20 > node that was just lost in a routing table,=20 > I would really love it. Is that the case?=20 >=20 >=20 > mmm I do not think so ... happy to discuss it live with you though.=20 >=20 >=20 > Cheers!=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Cheers,=20 > =C2=A0Anders=20 >=20 >=20 > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sendt: on 20-01-2010 17:02=20 > Til: Anders Brandt=20 > Emne: Re: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 > off-line first.=20 >=20 >=20 >=20 > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 > Jerry,=20 >=20 >> That was what was nice about an AODV concept, because even route =C2=A0= =20 >> repair was fairly deterministic.=20 >=20 > As far as I am informed some reactive discovery mechanism is still =C2=A0= =20 > needed for all the reasons that you list below.=20 >=20 > You may remember that we have the same needs in home automation.=20 > By utilizing the fact that source routing is already used to jump =C2=A0= =20 > between RPL-capable routers AND the fact that the (time critical)=20 > point-to-point communication is limited to 5 hops or less, some TTL-=20 > aware, source-route-based AODV hybrid may not cause so=20 > much flooding as one could fear.=20 >=20 >=20 >=20 > Are you saying that RPL is not good enough for P2P =C2=A0in home and =C2= =A0=20 > building ? Since I have evidence that it is not the case.=20 > Do you have data that shows different results ?=20 > Because as you know it is now in our charter to work on other =C2=A0=20 > protocols.=20 >=20 >=20 > Thanks.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 > - Anders=20 >=20 >=20 >=20 > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =C2=A0=20 > Behalf Of Jerald.P.Martocci@jci.com=20 > Sent: Thursday, January 14, 2010 19:11=20 > To: Joydeep Tripathi=20 > Cc: ROLL WG=20 > Subject: Re: [Roll] RPL Simulation=20 >=20 >=20 >=20 > Hi Joydeep,=20 >=20 > Mukul's been doing some simulations for my company for the past 3 =C2=A0= =20 > years. =C2=A0He has a good handle on the commercial building performance = =C2=A0=20 > requirements. =C2=A0It would be good for you to run those he notes =C2=A0= =20 > below. =C2=A0It might be advantageous then for you two to share the =C2= =A0=20 > results to better correlate the simulations.=20 >=20 > I would also look at the latency for P2P messages when the packet(s) =C2= =A0=20 > need to traverse the DAG all the way up to the LBR and back down to =C2= =A0=20 > the destination node. =C2=A0Of course, this is now a function on DAG =C2= =A0=20 > depth. =C2=A0Also since all our messages require ACK, the additional =C2= =A0=20 > latency of the ACK having to return possibly through a different set =C2= =A0=20 > of nodes yet via the LBR. =C2=A0That would be the worst case scenario. = =C2=A0=20 > If other nodes could short circuit the packets through a shorter =C2=A0= =20 > path, that would on;y help.=20 >=20 > Since Building systems are real-time (smoke/fire detection, turning =C2= =A0=20 > on lights, etc) latency is a big issue. =C2=A0Moving the packet up and = =C2=A0=20 > down the DAG is reasonably deterministic and should be primarily a =C2=A0= =20 > function of the DAG depth. =C2=A0However, what will really affect the =C2= =A0=20 > system performance is 'DAG Repair'. =C2=A0I have no sense how long a =C2= =A0=20 > packet in transit would have to wait if the DAG was under repair. =C2=A0= =20 > Since we require ACKs of every message, the source node would time-=20 > out and retry a few times (usually 3). =C2=A0After that, the source node = =C2=A0=20 > would have to fall into some 'failsoft' mode depending on the type =C2=A0= =20 > of data it was trying to access. =C2=A0This is not a good situation. =C2= =A0The =C2=A0=20 > source node can only assume that its data is inaccessible, not just =C2= =A0=20 > held up in transit. =C2=A0The fail-soft mode will have large hysteresis = =C2=A0=20 > since it can't be constantly dithering between modes. =C2=A0This will all= =C2=A0=20 > be logged to the operator which is a bad thing!!! =C2=A0That was what was= =C2=A0=20 > nice about an AODV concept, because even route repair was fairly =C2=A0= =20 > deterministic.=20 >=20 > So... if your simulation could measure packet latency as a function =C2= =A0=20 > of DAG repair severity, that would be terrific.=20 >=20 > Hope this makes sense.=20 >=20 > Jerry=20 >=20 >=20 >=20 > =20 >=20 >=20 > Mukul Goyal < mukul@uwm.edu >=20 >=20 > 01/13/2010 10:17 AM =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=20 > To =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Joydeep = Tripathi < joydeep.tripathi@gmail.com >=20 >=20 > cc =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ROLL WG = < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com=20 > =C2=A0>=20 >=20 > Subject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Re:= [Roll] RPL Simulation=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 >=20 >=20 >=20 > Joydeep=20 >=20 > Here are a few suggestions for your simulations:=20 >=20 > 1. Simulate a 100 node and a 1000 node topology operating under a =C2=A0= =20 > single DAG=20 >=20 > 2. Simulate both scenarios: optimal DAG routes (ie the path through =C2= =A0=20 > the DAG from a source to a destination passes through their closest =C2= =A0=20 > common ancestor) and DAG routes through root (all DAG paths have to =C2= =A0=20 > go through the DAG root).=20 >=20 > 3. Study the stretch factor (increase in length/cost of routes over =C2= =A0=20 > the DAG versus the length/cost of ideal routes) for given number of =C2= =A0=20 > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =C2=A0= =20 > number of nodes in the topology:=20 > a) the scenario you suggested: Choose 20% flows over 2 hop =C2=A0=20 > neighbors, 10% flows over longer paths.=20 > b) randomly selected source and destinations (in n*(n-1) case, from =C2= =A0=20 > each possible source node to each possible destination node).=20 >=20 > 4. In addition to the stretch factor, calculate/simulate the traffic =C2= =A0=20 > loads as well as packet loss/delay along the DAG links. Compare =C2=A0=20 > these values against values with ideal P2P routing.=20 >=20 > Thanks=20 > Mukul=20 > ----- Original Message -----=20 > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >=20 > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >=20 > Cc: "ROLL WG" < roll@ietf.org >=20 > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =C2=A0= =20 > Central=20 > Subject: [Roll] RPL Simulation=20 >=20 > Hi,=20 >=20 > In the next revision, we are also planning to implement a typical=20 > building routing scenario, where 60-70% of the P2P traffic are=20 > confined within 1 hop physical distance and, 20% of the P2P traffic=20 > are to a 2 -hop distance destination, and observe the performance of=20 > RPL against the ideal shortest route. Also, please let us know if=20 > there is any other scenario or traffic pattern you want to be=20 > implemented.=20 >=20 > Thanks,=20 > Joydeep=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 10:23:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D093A6823; Tue, 26 Jan 2010 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MllFc0xAZJyB; Tue, 26 Jan 2010 10:23:44 -0800 (PST) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 65CF13A6804; Tue, 26 Jan 2010 10:23:44 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta2.uwm.edu with ESMTP; 26 Jan 2010 12:23:36 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id EA4A62C382BC; Tue, 26 Jan 2010 12:23:36 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35FAhZs0UQ9d; Tue, 26 Jan 2010 12:23:36 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 583762C382B4; Tue, 26 Jan 2010 12:23:36 -0600 (CST) Date: Tue, 26 Jan 2010 12:23:36 -0600 (CST) From: Mukul Goyal To: d sturek Message-ID: <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1915415853.577721264530147452.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 18:23:46 -0000 Don, I think it would be possible to find ways to avoid scaling problems with re= active route discovery. I suggested one possibility in the following draft: http://tools.ietf.org/html/draft-goyal-roll-dv-01 Lets first agree that we do need source-initiated route discovery. Thanks Mukul =20 ----- Original Message ----- From: "Don Sturek" To: "Jerald P Martocci" , "JP Vasseur" Cc: "ROLL WG" , "Mukul Goyal" , roll-bounces@= ietf.org Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation= =09in the home Hi Jerry,=20 =C2=A0=20 I think the note below correctly reflects building automation requirements.= =C2=A0=C2=A0 Having 1000 devices on a building floor would not be a surpris= e.=20 =C2=A0=20 The trouble with reactive route discovery is many of the existing MANET pro= tocols like AODV scale with the number of devices in the network (so have t= o be tailored by deployment).=C2=A0 =C2=A0For example, route table size is = an example of a scaling resource in AODV.=C2=A0 I think in cases where ther= e is a needed reactive route discovery, we need to identify how to avoid ma= king the solution scale with deployment while still supporting low latency = messaging.=20 =C2=A0=20 Don=20 =C2=A0=20 =C2=A0=20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jer= ald.P.Martocci@jci.com=20 Sent: Tuesday, January 26, 2010 9:20 AM=20 To: JP Vasseur=20 Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org=20 Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation= in the home=20 =C2=A0=20 Hi JP,=20 My $.02 on your answers:=20 1) In a building there may 1000 devices in an LLN; hence even if Anders doe= s not have this requirement for a home, I do have this requirement for a bu= ilding.=20 2) My understanding is that for 6LoWPAN networks all devices are on a flat = network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence the= re is no way to aggregate routes.=20 2a) Source/destination routes are completely random; hence there is no a pr= iori way to preselect routes.=20 Regards,=20 Jerry=20 JP Vasseur =20 Sent by: roll-bounces@ietf.org=20 01/26/2010 11:01 AM =09 To =09 Mukul Goyal =20 cc =09 ROLL WG =20 Subject =09 Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation =C2=A0 = =C2=A0 =C2=A0 =C2=A0in the home=20 =C2=A0 =09 Hi Mukul,=20 On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:=20 > JP,=20 >=20 > The obvious problem with proactive approaches, such as RPL, is the =C2=A0= =20 > need to maintain reachability information for all possible =C2=A0=20 > destinations to which some source might send a packet some day. =C2=A0=20 > That's why we need source-initiated route discovery, i.e. a reactive =C2= =A0=20 > approach.=20 >=20 Several answers here:=20 1) Are there such as huge number of unicast addresses in a home ?=20 2) In so, this is where route aggregation/summarization can help.=20 This is why I'm challenging the need for an a priori reactive =C2=A0=20 mechanism here before we prove that=20 reactive is not good enough.=20 Makes sense ?=20 ps: again acting with no co-chair hat.=20 Thanks.=20 JP.=20 > Thanks=20 > Mukul=20 >=20 > ----- Original Message -----=20 > From: "JP Vasseur" =20 > To: "Anders Brandt" =20 > Cc: "ROLL WG" =20 > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =C2=A0=20 > Central=20 > Subject: Re: [Roll] RPL Simulation in the home=20 >=20 >=20 > Copying the list to continue that discussion - see below=20 >=20 >=20 >=20 > Anders>=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Anyway,=20 > the use case is quite simple:=20 >=20 > Z - R1 - R2 - R3 - A=20 >=20 > 1) Lamp module A was recently controlled by controller Z via router =C2= =A0=20 > 1 -> router 2 -> router 3=20 >=20 > =C2=A0Z - R1 - R2 - R3 - A=20 >=20 > 2) Something renders the radio connection unusable from router 3 to =C2= =A0=20 > lamp module A=20 > 3) The lamp module can however be reached via router 1 -> router 4 -=20 > > router 5=20 > =C2=A0 =C2=A0but router 5 has never been routing traffic to lamp module A= =20 >=20 > =C2=A0Z - R1 - R2 - R3 - .=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0\=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 - R4 - R5 - A=20 > 4) Controller Z sends another command to lamp module A via router 1=20 > 5) Router 1 sends the command to router 2 which forwards the command =C2= =A0=20 > to router 3=20 > 6) Router 3 is unable to deliver the command=20 >=20 > What happens now?=20 >=20 >=20 > This is exactly why I was asking you the reason why you think that =C2=A0= =20 > it should be reactive.=20 > What you describe is routing protocol convergence, which of course =C2=A0= =20 > does not imply that the=20 > protocol should be reactive. This is a typical case where the =C2=A0=20 > topology is changing and RPL=20 > needs to adapt to it, which it does. The way to meet your time =C2=A0=20 > requirements is to adjust=20 > the RPL parameters to make it quicker to converge. If there is a =C2=A0= =20 > link between A and R5,=20 > as soon as it becomes operational, A can send a DAO and R1 will =C2=A0=20 > direct the traffic to R4=20 > instead of R2.=20 >=20 >=20 >=20 >=20 > Will the lamp go on within 250ms?=20 >=20 >=20 >=20 > So you raise the issue of convergence time, fair. It all depends on =C2= =A0=20 > how you tune RPL and A=20 > selects R5 as a new parent. Note that you do not have to keep =C2=A0=20 > sending control traffic for=20 > that. If you links are extremely lossy you will have to make the DAG =C2= =A0=20 > fairly reactive, which=20 > means more control traffic of course. If you are using a reactive =C2=A0= =20 > mechanism instead of=20 > proactive, this is not a magic solution either since you flood your =C2= =A0=20 > network and add control=20 > messages too.=20 >=20 >=20 > What I think is that by using these mechanism you can achieve a good =C2= =A0=20 > level of convergence=20 > time with reasonable traffic in presence of lossy link w/o too much =C2= =A0=20 > control traffic. We can try=20 > to quantify if you can provide an example topology, few stats on the =C2= =A0=20 > link flaps trying few RPL=20 > tuning. Could you ?=20 >=20 >=20 > Thanks.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks,=20 > =C2=A0Anders=20 >=20 >=20 > From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sent: Thursday, January 21, 2010 09:11=20 > To: Anders Brandt=20 > Subject: Re: SV: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 >=20 > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 > Sorry JP=20 >=20 > I really have no intention of spreading FUD.=20 > Guess this mainly indicates that I and Jerry need education of what =C2= =A0=20 > RPL is expected/able to deliver.=20 >=20 > At the most recent telecon we again touched the issue of e.g. a lamp =C2= =A0=20 > module which due to rf phenomena=20 > cannot be reached via the recent router - and I thought we had a =C2=A0= =20 > common understanding that some reactive mechanism=20 > would be needed.=20 >=20 > Can RPL - in its current shape - identify a new route via a router =C2=A0= =20 > which did not previously forward traffic to said lamp module?=20 >=20 >=20 >=20 > Not sure of what you mean by this ?=20 >=20 >=20 >=20 >=20 > I would love that but I need to understand how - and I would love to =C2= =A0=20 > see your evidence!=20 >=20 >=20 >=20 > Here is what I can propose: could you provide a home network =C2=A0=20 > topology that I could use to provide=20 > simulations results ?=20 >=20 >=20 > Cheers.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 > Thanks,=20 > =C2=A0Anders=20 >=20 >=20 >=20 > From: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sent: Wednesday, January 20, 2010 18:21=20 > To: Anders Brandt=20 > Subject: Re: SV: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 >=20 > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi JP=20 >=20 >> Are you saying that RPL is not good enough for P2P =C2=A0in home and =C2= =A0=20 >> building?=20 >=20 > Well - which incarnation of RPL? (!)=20 > I was of the impression that we had a common understanding that the =C2= =A0=20 > ability to=20 > operate in a reactive fasion is critical to home & building and that =C2= =A0=20 > the DAG update=20 > signaling currently designed will have much bigger delays than the =C2=A0= =20 > 250ms real-time=20 > users will tolerate.=20 >=20 >=20 > Where does that come from ?=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Since I have evidence that it is not the case.=20 >> Do you have data that shows different results ?=20 >=20 > I may have misunderstood the telecon conclusions, but I got it so =C2=A0= =20 > that over time=20 > DAG routes will reconstructed, but that the current spec cannot find =C2= =A0=20 > a lost target on demand (?).=20 >=20 >=20 >> Because as you know it is now in our charter to work on other =C2=A0=20 >> protocols.=20 > now? I guess you mean "not" ? (!)=20 > My conclusion from the Rolle interim was that we needed something =C2=A0= =20 > special to find routes across the cloud.=20 > If the DAG can re-establish contact within 250ms to an operational =C2=A0= =20 > node that was just lost in a routing table,=20 > I would really love it. Is that the case?=20 >=20 >=20 > mmm I do not think so ... happy to discuss it live with you though.=20 >=20 >=20 > Cheers!=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Cheers,=20 > =C2=A0Anders=20 >=20 >=20 > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]=20 > Sendt: on 20-01-2010 17:02=20 > Til: Anders Brandt=20 > Emne: Re: [Roll] RPL Simulation=20 >=20 >=20 > Hi Anders,=20 >=20 >=20 > off-line first.=20 >=20 >=20 >=20 > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:=20 >=20 >=20 >=20 >=20 > Jerry,=20 >=20 >> That was what was nice about an AODV concept, because even route =C2=A0= =20 >> repair was fairly deterministic.=20 >=20 > As far as I am informed some reactive discovery mechanism is still =C2=A0= =20 > needed for all the reasons that you list below.=20 >=20 > You may remember that we have the same needs in home automation.=20 > By utilizing the fact that source routing is already used to jump =C2=A0= =20 > between RPL-capable routers AND the fact that the (time critical)=20 > point-to-point communication is limited to 5 hops or less, some TTL-=20 > aware, source-route-based AODV hybrid may not cause so=20 > much flooding as one could fear.=20 >=20 >=20 >=20 > Are you saying that RPL is not good enough for P2P =C2=A0in home and =C2= =A0=20 > building ? Since I have evidence that it is not the case.=20 > Do you have data that shows different results ?=20 > Because as you know it is now in our charter to work on other =C2=A0=20 > protocols.=20 >=20 >=20 > Thanks.=20 >=20 >=20 > JP.=20 >=20 >=20 >=20 >=20 >=20 > - Anders=20 >=20 >=20 >=20 > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =C2=A0=20 > Behalf Of Jerald.P.Martocci@jci.com=20 > Sent: Thursday, January 14, 2010 19:11=20 > To: Joydeep Tripathi=20 > Cc: ROLL WG=20 > Subject: Re: [Roll] RPL Simulation=20 >=20 >=20 >=20 > Hi Joydeep,=20 >=20 > Mukul's been doing some simulations for my company for the past 3 =C2=A0= =20 > years. =C2=A0He has a good handle on the commercial building performance = =C2=A0=20 > requirements. =C2=A0It would be good for you to run those he notes =C2=A0= =20 > below. =C2=A0It might be advantageous then for you two to share the =C2= =A0=20 > results to better correlate the simulations.=20 >=20 > I would also look at the latency for P2P messages when the packet(s) =C2= =A0=20 > need to traverse the DAG all the way up to the LBR and back down to =C2= =A0=20 > the destination node. =C2=A0Of course, this is now a function on DAG =C2= =A0=20 > depth. =C2=A0Also since all our messages require ACK, the additional =C2= =A0=20 > latency of the ACK having to return possibly through a different set =C2= =A0=20 > of nodes yet via the LBR. =C2=A0That would be the worst case scenario. = =C2=A0=20 > If other nodes could short circuit the packets through a shorter =C2=A0= =20 > path, that would on;y help.=20 >=20 > Since Building systems are real-time (smoke/fire detection, turning =C2= =A0=20 > on lights, etc) latency is a big issue. =C2=A0Moving the packet up and = =C2=A0=20 > down the DAG is reasonably deterministic and should be primarily a =C2=A0= =20 > function of the DAG depth. =C2=A0However, what will really affect the =C2= =A0=20 > system performance is 'DAG Repair'. =C2=A0I have no sense how long a =C2= =A0=20 > packet in transit would have to wait if the DAG was under repair. =C2=A0= =20 > Since we require ACKs of every message, the source node would time-=20 > out and retry a few times (usually 3). =C2=A0After that, the source node = =C2=A0=20 > would have to fall into some 'failsoft' mode depending on the type =C2=A0= =20 > of data it was trying to access. =C2=A0This is not a good situation. =C2= =A0The =C2=A0=20 > source node can only assume that its data is inaccessible, not just =C2= =A0=20 > held up in transit. =C2=A0The fail-soft mode will have large hysteresis = =C2=A0=20 > since it can't be constantly dithering between modes. =C2=A0This will all= =C2=A0=20 > be logged to the operator which is a bad thing!!! =C2=A0That was what was= =C2=A0=20 > nice about an AODV concept, because even route repair was fairly =C2=A0= =20 > deterministic.=20 >=20 > So... if your simulation could measure packet latency as a function =C2= =A0=20 > of DAG repair severity, that would be terrific.=20 >=20 > Hope this makes sense.=20 >=20 > Jerry=20 >=20 >=20 >=20 > =20 >=20 >=20 > Mukul Goyal < mukul@uwm.edu >=20 >=20 > 01/13/2010 10:17 AM =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=20 > To =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Joydeep = Tripathi < joydeep.tripathi@gmail.com >=20 >=20 > cc =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ROLL WG = < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com=20 > =C2=A0>=20 >=20 > Subject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Re:= [Roll] RPL Simulation=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 >=20 >=20 >=20 > Joydeep=20 >=20 > Here are a few suggestions for your simulations:=20 >=20 > 1. Simulate a 100 node and a 1000 node topology operating under a =C2=A0= =20 > single DAG=20 >=20 > 2. Simulate both scenarios: optimal DAG routes (ie the path through =C2= =A0=20 > the DAG from a source to a destination passes through their closest =C2= =A0=20 > common ancestor) and DAG routes through root (all DAG paths have to =C2= =A0=20 > go through the DAG root).=20 >=20 > 3. Study the stretch factor (increase in length/cost of routes over =C2= =A0=20 > the DAG versus the length/cost of ideal routes) for given number of =C2= =A0=20 > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =C2=A0= =20 > number of nodes in the topology:=20 > a) the scenario you suggested: Choose 20% flows over 2 hop =C2=A0=20 > neighbors, 10% flows over longer paths.=20 > b) randomly selected source and destinations (in n*(n-1) case, from =C2= =A0=20 > each possible source node to each possible destination node).=20 >=20 > 4. In addition to the stretch factor, calculate/simulate the traffic =C2= =A0=20 > loads as well as packet loss/delay along the DAG links. Compare =C2=A0=20 > these values against values with ideal P2P routing.=20 >=20 > Thanks=20 > Mukul=20 > ----- Original Message -----=20 > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >=20 > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >=20 > Cc: "ROLL WG" < roll@ietf.org >=20 > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =C2=A0= =20 > Central=20 > Subject: [Roll] RPL Simulation=20 >=20 > Hi,=20 >=20 > In the next revision, we are also planning to implement a typical=20 > building routing scenario, where 60-70% of the P2P traffic are=20 > confined within 1 hop physical distance and, 20% of the P2P traffic=20 > are to a 2 -hop distance destination, and observe the performance of=20 > RPL against the ideal shortest route. Also, please let us know if=20 > there is any other scenario or traffic pattern you want to be=20 > implemented.=20 >=20 > Thanks,=20 > Joydeep=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Jan 26 11:20:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695413A69A5; Tue, 26 Jan 2010 11:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caDhGEDjdHyB; Tue, 26 Jan 2010 11:20:39 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id 71FBC3A6807; Tue, 26 Jan 2010 11:20:38 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKS19Akbz/GHGI0sTVzpRgjNHrwEt5hDdQ@postini.com; Tue, 26 Jan 2010 11:20:50 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010012613205194-236233 ; Tue, 26 Jan 2010 13:20:51 -0600 In-Reply-To: <01be01ca9eaf$91db8a70$b5929f50$@sturek@att.net> MIME-Version: 1.0 To: X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 26 Jan 2010 13:20:39 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/26/2010 01:20:43 PM, Serialize complete at 01/26/2010 01:20:43 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 01:20:51 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 01:20:57 PM, Serialize complete at 01/26/2010 01:20:57 PM Content-Type: multipart/alternative; boundary="=_alternative 006A4248862576B7_=" Cc: 'ROLL WG' , 'Mukul Goyal' , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 19:20:43 -0000 This is a multipart message in MIME format. --=_alternative 006A4248862576B7_= Content-Type: text/plain; charset="US-ASCII" Hey Don, I guess I miss your point. If we use the proactive model then for a 1000 node LLN, each node will have to define and maintain routes to 999 other nodes on the oft chance that a message needs to be sent to any random node on the LLN. This seems way less scalable than keeping a 'least recently used' list of links that the node has needed to communicate to in the recent past. Also, I am not sure why you think AODV overhead is a function of node count. If my room controller needs to talk to its temperature, occupancy and humidity sensor, it doesn't really care if there are 10 other nodes in the LLN or 1000 other nodes. To me, scalability has to do with the application requirements, not the LLN size. Jerry "Don Sturek" 01/26/2010 11:47 AM Please respond to To , "'JP Vasseur'" cc "'ROLL WG'" , "'Mukul Goyal'" , Subject RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Jerry, I think the note below correctly reflects building automation requirements. Having 1000 devices on a building floor would not be a surprise. The trouble with reactive route discovery is many of the existing MANET protocols like AODV scale with the number of devices in the network (so have to be tailored by deployment). For example, route table size is an example of a scaling resource in AODV. I think in cases where there is a needed reactive route discovery, we need to identify how to avoid making the solution scale with deployment while still supporting low latency messaging. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Tuesday, January 26, 2010 9:20 AM To: JP Vasseur Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi JP, My $.02 on your answers: 1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building. 2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes. 2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 01/26/2010 11:01 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006A4248862576B7_= Content-Type: text/html; charset="US-ASCII"
Hey Don,

I guess I miss your point.  If we use the proactive model then for a 1000 node LLN, each node will have to define and maintain routes to 999 other nodes on the oft chance that a message needs to be sent to any random node on the LLN.  This seems way less scalable than keeping a 'least recently used' list of links that the node has needed to communicate to in the recent past.

Also, I am not sure why you think AODV overhead is a function of node count.  If my room controller needs to talk to its temperature, occupancy and humidity sensor, it doesn't really care if there are 10 other nodes in the LLN or 1000 other nodes.  To me, scalability has to do with the application requirements, not the LLN size.

Jerry





"Don Sturek" <d.sturek@att.net>

01/26/2010 11:47 AM
Please respond to
<d.sturek@att.net>
To
<Jerald.P.Martocci@jci.com>, "'JP Vasseur'" <jvasseur@cisco.com>
cc
"'ROLL WG'" <roll@ietf.org>, "'Mukul Goyal'" <mukul@UWM.EDU>, <roll-bounces@ietf.org>
Subject
RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation        in the home





Hi Jerry,
 
I think the note below correctly reflects building automation requirements.   Having 1000 devices on a building floor would not be a surprise.
 
The trouble with reactive route discovery is many of the existing MANET protocols like AODV scale with the number of devices in the network (so have to be tailored by deployment).   For example, route table size is an example of a scaling resource in AODV.  I think in cases where there is a needed reactive route discovery, we need to identify how to avoid making the solution scale with deployment while still supporting low latency messaging.
 
Don
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home
 

Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes.

Regards,

Jerry


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

01/26/2010 11:01 AM


To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation        in the home

 







Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the  
> need to maintain reachability information for all possible  
> destinations to which some source might send a packet some day.  
> That's why we need source-initiated route discovery, i.e. a reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 -
> > router 5
>    but router 5 has never been routing traffic to lamp module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that  
> it should be reactive.
> What you describe is routing protocol convergence, which of course  
> does not imply that the
> protocol should be reactive. This is a typical case where the  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep  
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a reactive  
> mechanism instead of
> proactive, this is not a magic solution either since you flood your  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router  
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the  
> ability to
> operate in a reactive fasion is critical to home & building and that  
> the DAG update
> signaling currently designed will have much bigger delays than the  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so  
> that over time
> DAG routes will reconstructed, but that the current spec cannot find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route  
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still  
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump  
> between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P  in home and  
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On  
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3  
> years.  He has a good handle on the commercial building performance  
> requirements.  It would be good for you to run those he notes  
> below.  It might be advantageous then for you two to share the  
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s)  
> need to traverse the DAG all the way up to the LBR and back down to  
> the destination node.  Of course, this is now a function on DAG  
> depth.  Also since all our messages require ACK, the additional  
> latency of the ACK having to return possibly through a different set  
> of nodes yet via the LBR.  That would be the worst case scenario.  
> If other nodes could short circuit the packets through a shorter  
> path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning  
> on lights, etc) latency is a big issue.  Moving the packet up and  
> down the DAG is reasonably deterministic and should be primarily a  
> function of the DAG depth.  However, what will really affect the  
> system performance is 'DAG Repair'.  I have no sense how long a  
> packet in transit would have to wait if the DAG was under repair.  
> Since we require ACKs of every message, the source node would time-
> out and retry a few times (usually 3).  After that, the source node  
> would have to fall into some 'failsoft' mode depending on the type  
> of data it was trying to access.  This is not a good situation.  The  
> source node can only assume that its data is inaccessible, not just  
> held up in transit.  The fail-soft mode will have large hysteresis  
> since it can't be constantly dithering between modes.  This will all  
> be logged to the operator which is a bad thing!!!  That was what was  
> nice about an AODV concept, because even route repair was fairly  
> deterministic.
>
> So... if your simulation could measure packet latency as a function  
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM                  
> To                  Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc                  ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com
>  >
>
> Subject                  Re: [Roll] RPL Simulation
>                  
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a  
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through  
> the DAG from a source to a destination passes through their closest  
> common ancestor) and DAG routes through root (all DAG paths have to  
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over  
> the DAG versus the length/cost of ideal routes) for given number of  
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the  
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop  
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from  
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic  
> loads as well as packet loss/delay along the DAG links. Compare  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada  
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic
> are to a 2 -hop distance destination, and observe the performance of
> RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006A4248862576B7_=-- From hrogge@googlemail.com Tue Jan 26 11:25:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32D93A6954; Tue, 26 Jan 2010 11:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em2B8LGvpvcU; Tue, 26 Jan 2010 11:25:10 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 784E53A681E; Tue, 26 Jan 2010 11:25:10 -0800 (PST) Received: by ewy8 with SMTP id 8so5841949ewy.29 for ; Tue, 26 Jan 2010 11:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=z9w2SpQ6iYcN42WmwFUD5Mo4vCXCK3q+oVtDo0RDqQk=; b=ENhWVNMSOUI2hLYdj1kYeKPxv77GpKbvIdeiXN6xeJgjbVsCy9ZkA0EiSY8hAIA0QN hR8jlc3b9kfOq4J5RsN+XIe3pVxWNOyKNukevnr0clwu5+L4kybyDc8TFY9Ukv+sRVu6 lywg9++whoWSsXp7CjJycrzZF/xEA9y4atIws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=w3fye6EbJhcE2xQhDhGqPijN8jzkohlG3GQdw8HI42r9U6CqMG1LYvcUWY78CXn8ti EiNj30xHl6ikE3YvcxH3cNYWaLZ9s+qWS5cIbkd7jnfTDwXVJPogRSrZ5Lr2+nvOpU38 IuYo9GkUVXc1kpyrvig4pBgginMLUxT/6uMds= Received: by 10.213.109.136 with SMTP id j8mr3132218ebp.75.1264533920318; Tue, 26 Jan 2010 11:25:20 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 14sm5470149ewy.15.2010.01.26.11.25.18 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 11:25:19 -0800 (PST) From: Henning Rogge To: roll@ietf.org Date: Tue, 26 Jan 2010 20:25:11 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.32-gentoo-r2; KDE/4.3.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4108491.moIH1JkMMD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001262025.17833.hrogge@googlemail.com> Cc: roll-bounces@ietf.org Subject: Re: [Roll] =?iso-8859-15?q?Reactive_versus_Proactive_approaches_Re=3A?= =?iso-8859-15?q?_RPL_Simulation=09in_the_home?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 19:25:12 -0000 --nextPart4108491.moIH1JkMMD Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, >=20 > I guess I miss your point. If we use the proactive model then for a 1000 > node LLN, each node will have to define and maintain routes to 999 other > nodes on the oft chance that a message needs to be sent to any random node > on the LLN. This seems way less scalable than keeping a 'least recently > used' list of links that the node has needed to communicate to in the > recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see=20 experiments with 10000 nodes how well AODV does scale (experiments, not jus= t=20 simulations). Henning Rogge --nextPart4108491.moIH1JkMMD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAktfQZ0ACgkQcenvcwAcHWfE7wCeIH46nGeL0jQ1sjVr8anqNcu6 VdoAnjz129qUlcbs16wF+/wSVhgBf07U =LR6j -----END PGP SIGNATURE----- --nextPart4108491.moIH1JkMMD-- From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 11:57:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A19A3A68DF; Tue, 26 Jan 2010 11:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic-P6X22AaPC; Tue, 26 Jan 2010 11:57:20 -0800 (PST) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 57DEE3A68DA; Tue, 26 Jan 2010 11:57:20 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta2.uwm.edu with ESMTP; 26 Jan 2010 13:57:31 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 2EA022C382E6; Tue, 26 Jan 2010 13:57:31 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbf9pyg2dPqt; Tue, 26 Jan 2010 13:57:31 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 048C42C382E4; Tue, 26 Jan 2010 13:57:31 -0600 (CST) Date: Tue, 26 Jan 2010 13:57:30 -0600 (CST) From: Mukul Goyal To: Henning Rogge Message-ID: <496706315.659531264535850961.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <201001262025.17833.hrogge@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 19:57:21 -0000 Henning, We clearly do not want a route discovery based on immediate network-wide broadcast of route request messages (as in AODV). But we could still come up with a reactive approach that suits the needs of LLNs. Thanks Mukul ----- Original Message ----- From: "Henning Rogge" To: roll@ietf.org Cc: "Jerald P Martocci" , "d sturek" , "Mukul Goyal" , roll-bounces@ietf.org Sent: Tuesday, January 26, 2010 1:25:11 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a 1000 > node LLN, each node will have to define and maintain routes to 999 other > nodes on the oft chance that a message needs to be sent to any random node > on the LLN. This seems way less scalable than keeping a 'least recently > used' list of links that the node has needed to communicate to in the > recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge From abr@sdesigns.dk Tue Jan 26 12:30:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C105628C111; Tue, 26 Jan 2010 12:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dElQKcxNBUsG; Tue, 26 Jan 2010 12:30:51 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 53B8628C10E; Tue, 26 Jan 2010 12:30:51 -0800 (PST) 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_01CA9EC6.79ECF784" Date: Tue, 26 Jan 2010 21:31:01 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD454A@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Thread-Index: AcqevVDmkDwfaD6sSrSwIHgsNaaxwQAB3i3J References: <201001262025.17833.hrogge@googlemail.com> From: "Anders Brandt" To: "Henning Rogge" , Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 20:30:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9EC6.79ECF784 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Henning, =20 The trick is that we can limit the scope. We do not want to scan the entire Internet. =20 For home and building, a TTL limiting the discovery to 4 repeater nodes = would do the work. Combine this with a dampening function which prevents repeaters from = forwarding discovery messages if n other repeaters within direct reach = already forwarded the same message and your broadcast storm is converted = to a controlled wavefront forming a circle outwards. Piggyback the "Light on" command on the discovery message and your = latency is drastically reduced. Finally, let the Discovery result message kill all pending discovery = messages scheduled for later transmission. =20 As Jerry said, cache the discovered route and use it the next time. =20 Individually very simple mechanisms. Together, extremely efficient. =20 I may add that this runs in the real world. =20 Cheers, Anders. ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Henning Rogge Sendt: ti 26-01-2010 20:25 Til: roll@ietf.org Cc: roll-bounces@ietf.org Emne: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation = in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a = 1000 > node LLN, each node will have to define and maintain routes to 999 = other > nodes on the oft chance that a message needs to be sent to any random = node > on the LLN. This seems way less scalable than keeping a 'least = recently > used' list of links that the node has needed to communicate to in the > recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not = just simulations). Henning Rogge ------_=_NextPart_001_01CA9EC6.79ECF784 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] Reactive versus Proactive = approaches Re: RPL Simulation in the home=0A= =0A= =0A= =0A=

=0A=
Henning,
=0A=
 
=0A=
The trick is that we can = limit the scope.
=0A=
We do not want to scan the = entire Internet.
=0A=
 
=0A=
For home and building, a TTL = limiting the discovery to 4 repeater nodes would do the = work.
=0A=
Combine this with a dampening = function which prevents repeaters from forwarding discovery messages if = n other repeaters within direct reach already forwarded the same message = and your broadcast storm is converted to a controlled wavefront = forming a circle outwards.
=0A=
Piggyback the "Light on" = command on the discovery message and your latency is drastically = reduced.
=0A=
Finally, let the Discovery = result message kill all pending discovery messages scheduled for later = transmission.
=0A=
 
=0A=
As Jerry said, cache the = discovered route and use it the next time.
=0A=
 
=0A=
Individually very simple = mechanisms. Together, extremely efficient.
=0A=
 
=0A=
I may add that this runs in = the real world.
=0A=
 
=0A=
Cheers,
=0A=
  = Anders.
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Henning Rogge
Sendt: ti 26-01-2010 = 20:25
Til: roll@ietf.org
Cc: = roll-bounces@ietf.org
Emne: Re: [Roll] Reactive versus = Proactive approaches Re: RPL Simulation in the home

=0A=
=0A=

Am Dienstag 26 Januar 2010 20:20:39 schrieb = Jerald.P.Martocci@jci.com:
> Hey Don,
>
> I guess I = miss your point.  If we use the proactive model then for a = 1000
> node LLN, each node will have to define and maintain routes = to 999 other
> nodes on the oft chance that a message needs to be = sent to any random node
> on the LLN.  This seems way less = scalable than keeping a 'least recently
> used' list of links that = the node has needed to communicate to in the
> recent = past.

=0A=


1000 Nodes is no problem with proactive = protocolls. I have yet to see
experiments with 10000 nodes how well = AODV does scale (experiments, not just
simulations).

Henning = Rogge

------_=_NextPart_001_01CA9EC6.79ECF784-- From d.sturek@att.net Tue Jan 26 12:32:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684CE28C110 for ; Tue, 26 Jan 2010 12:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWfPjDUa7lPl for ; Tue, 26 Jan 2010 12:32:10 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 8CC943A69BF for ; Tue, 26 Jan 2010 12:32:06 -0800 (PST) Received: (qmail 68125 invoked from network); 26 Jan 2010 20:25:38 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2010 12:25:37 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: cfTDl1QVM1mlKUfTQqBlzufig855hdZ7fVnAEuxJJoRTNaVfzx1sfZdcIdJk7et7csdEIZjPWhqGMQi5JpkbpP4WJgkV3hXqT7nJ4t74aYORviLs3ZoJanPEEUL6Z.q6L33S15LTBSMff4h339anBV3YUldBC3zm7uYiVJmkfsgq3EJI.WxS9t4W7QyrwwyACpo7h4sn0X.ouKJtXzuC6FsmAYgvNDwoLq_V54dxVVO_ubH03qx4ddZtJP7r68JTx1mTuqdcB40Ex2FLdyWuDieoqFmhuHoaQlqx7nXvJfw7z98c1xXrwg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <01be01ca9eaf$91db8a70$b5929f50$@sturek@att.net> In-Reply-To: Date: Tue, 26 Jan 2010 12:25:22 -0800 Message-ID: <028301ca9ec5$b61759d0$22460d70$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0284_01CA9E82.A7F419D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqevK0uuQaHCaLYS76GUnkOFQmU7wAB8Kuw Content-Language: en-us Cc: 'ROLL WG' , 'Mukul Goyal' , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:32:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0284_01CA9E82.A7F419D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jerry, The issue with AODV is you need a route table in each router to indicate the next hop in the path. The more next hop options you have for a given router (as in a large network) the more table entries you need. Additionally, AODV uses flooding to establish routes so you also have to accommodate route discovery entries that grow with the number of devices in the network (maybe not "order n" but will definitely grow) A network of size 6 would have very different AODV resource requirements than a network of size 1000 since the route table and route discovery tables would be very different in size. For a device manufacturer, there must be planning in advance based on expected network topology to size the AODV resources correctly. Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Tuesday, January 26, 2010 11:21 AM To: d.sturek@att.net Cc: 'JP Vasseur'; 'Mukul Goyal'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hey Don, I guess I miss your point. If we use the proactive model then for a 1000 node LLN, each node will have to define and maintain routes to 999 other nodes on the oft chance that a message needs to be sent to any random node on the LLN. This seems way less scalable than keeping a 'least recently used' list of links that the node has needed to communicate to in the recent past. Also, I am not sure why you think AODV overhead is a function of node count. If my room controller needs to talk to its temperature, occupancy and humidity sensor, it doesn't really care if there are 10 other nodes in the LLN or 1000 other nodes. To me, scalability has to do with the application requirements, not the LLN size. Jerry "Don Sturek" 01/26/2010 11:47 AM Please respond to To , "'JP Vasseur'" cc "'ROLL WG'" , "'Mukul Goyal'" , Subject RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Jerry, I think the note below correctly reflects building automation requirements. Having 1000 devices on a building floor would not be a surprise. The trouble with reactive route discovery is many of the existing MANET protocols like AODV scale with the number of devices in the network (so have to be tailored by deployment). For example, route table size is an example of a scaling resource in AODV. I think in cases where there is a needed reactive route discovery, we need to identify how to avoid making the solution scale with deployment while still supporting low latency messaging. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Tuesday, January 26, 2010 9:20 AM To: JP Vasseur Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi JP, My $.02 on your answers: 1) In a building there may 1000 devices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building. 2) My understanding is that for 6LoWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes. 2a) Source/destination routes are completely random; hence there is no a priori way to preselect routes. Regards, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 01/26/2010 11:01 AM To Mukul Goyal cc ROLL WG Subject Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Mukul, On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > JP, > > The obvious problem with proactive approaches, such as RPL, is the > need to maintain reachability information for all possible > destinations to which some source might send a packet some day. > That's why we need source-initiated route discovery, i.e. a reactive > approach. > Several answers here: 1) Are there such as huge number of unicast addresses in a home ? 2) In so, this is where route aggregation/summarization can help. This is why I'm challenging the need for an a priori reactive mechanism here before we prove that reactive is not good enough. Makes sense ? ps: again acting with no co-chair hat. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Anders Brandt" > Cc: "ROLL WG" > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Simulation in the home > > > Copying the list to continue that discussion - see below > > > > Anders> > > > > > > > > > > > > Anyway, > the use case is quite simple: > > Z - R1 - R2 - R3 - A > > 1) Lamp module A was recently controlled by controller Z via router > 1 -> router 2 -> router 3 > > Z - R1 - R2 - R3 - A > > 2) Something renders the radio connection unusable from router 3 to > lamp module A > 3) The lamp module can however be reached via router 1 -> router 4 - > > router 5 > but router 5 has never been routing traffic to lamp module A > > Z - R1 - R2 - R3 - . > \ > - R4 - R5 - A > 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command > to router 3 > 6) Router 3 is unable to deliver the command > > What happens now? > > > This is exactly why I was asking you the reason why you think that > it should be reactive. > What you describe is routing protocol convergence, which of course > does not imply that the > protocol should be reactive. This is a typical case where the > topology is changing and RPL > needs to adapt to it, which it does. The way to meet your time > requirements is to adjust > the RPL parameters to make it quicker to converge. If there is a > link between A and R5, > as soon as it becomes operational, A can send a DAO and R1 will > direct the traffic to R4 > instead of R2. > > > > > Will the lamp go on within 250ms? > > > > So you raise the issue of convergence time, fair. It all depends on > how you tune RPL and A > selects R5 as a new parent. Note that you do not have to keep > sending control traffic for > that. If you links are extremely lossy you will have to make the DAG > fairly reactive, which > means more control traffic of course. If you are using a reactive > mechanism instead of > proactive, this is not a magic solution either since you flood your > network and add control > messages too. > > > What I think is that by using these mechanism you can achieve a good > level of convergence > time with reasonable traffic in presence of lossy link w/o too much > control traffic. We can try > to quantify if you can provide an example topology, few stats on the > link flaps trying few RPL > tuning. Could you ? > > > Thanks. > > > JP. > > > > > > > > > > Thanks, > Anders > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Thursday, January 21, 2010 09:11 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > Sorry JP > > I really have no intention of spreading FUD. > Guess this mainly indicates that I and Jerry need education of what > RPL is expected/able to deliver. > > At the most recent telecon we again touched the issue of e.g. a lamp > module which due to rf phenomena > cannot be reached via the recent router - and I thought we had a > common understanding that some reactive mechanism > would be needed. > > Can RPL - in its current shape - identify a new route via a router > which did not previously forward traffic to said lamp module? > > > > Not sure of what you mean by this ? > > > > > I would love that but I need to understand how - and I would love to > see your evidence! > > > > Here is what I can propose: could you provide a home network > topology that I could use to provide > simulations results ? > > > Cheers. > > > JP. > > > > > Thanks, > Anders > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sent: Wednesday, January 20, 2010 18:21 > To: Anders Brandt > Subject: Re: SV: [Roll] RPL Simulation > > > Hi Anders, > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > Hi JP > >> Are you saying that RPL is not good enough for P2P in home and >> building? > > Well - which incarnation of RPL? (!) > I was of the impression that we had a common understanding that the > ability to > operate in a reactive fasion is critical to home & building and that > the DAG update > signaling currently designed will have much bigger delays than the > 250ms real-time > users will tolerate. > > > Where does that come from ? > > > > > > > >> Since I have evidence that it is not the case. >> Do you have data that shows different results ? > > I may have misunderstood the telecon conclusions, but I got it so > that over time > DAG routes will reconstructed, but that the current spec cannot find > a lost target on demand (?). > > >> Because as you know it is now in our charter to work on other >> protocols. > now? I guess you mean "not" ? (!) > My conclusion from the Rolle interim was that we needed something > special to find routes across the cloud. > If the DAG can re-establish contact within 250ms to an operational > node that was just lost in a routing table, > I would really love it. Is that the case? > > > mmm I do not think so ... happy to discuss it live with you though. > > > Cheers! > > > JP. > > > > > > > > Cheers, > Anders > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > Sendt: on 20-01-2010 17:02 > Til: Anders Brandt > Emne: Re: [Roll] RPL Simulation > > > Hi Anders, > > > off-line first. > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > Jerry, > >> That was what was nice about an AODV concept, because even route >> repair was fairly deterministic. > > As far as I am informed some reactive discovery mechanism is still > needed for all the reasons that you list below. > > You may remember that we have the same needs in home automation. > By utilizing the fact that source routing is already used to jump > between RPL-capable routers AND the fact that the (time critical) > point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so > much flooding as one could fear. > > > > Are you saying that RPL is not good enough for P2P in home and > building ? Since I have evidence that it is not the case. > Do you have data that shows different results ? > Because as you know it is now in our charter to work on other > protocols. > > > Thanks. > > > JP. > > > > > > - Anders > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11 > To: Joydeep Tripathi > Cc: ROLL WG > Subject: Re: [Roll] RPL Simulation > > > > Hi Joydeep, > > Mukul's been doing some simulations for my company for the past 3 > years. He has a good handle on the commercial building performance > requirements. It would be good for you to run those he notes > below. It might be advantageous then for you two to share the > results to better correlate the simulations. > > I would also look at the latency for P2P messages when the packet(s) > need to traverse the DAG all the way up to the LBR and back down to > the destination node. Of course, this is now a function on DAG > depth. Also since all our messages require ACK, the additional > latency of the ACK having to return possibly through a different set > of nodes yet via the LBR. That would be the worst case scenario. > If other nodes could short circuit the packets through a shorter > path, that would on;y help. > > Since Building systems are real-time (smoke/fire detection, turning > on lights, etc) latency is a big issue. Moving the packet up and > down the DAG is reasonably deterministic and should be primarily a > function of the DAG depth. However, what will really affect the > system performance is 'DAG Repair'. I have no sense how long a > packet in transit would have to wait if the DAG was under repair. > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). After that, the source node > would have to fall into some 'failsoft' mode depending on the type > of data it was trying to access. This is not a good situation. The > source node can only assume that its data is inaccessible, not just > held up in transit. The fail-soft mode will have large hysteresis > since it can't be constantly dithering between modes. This will all > be logged to the operator which is a bad thing!!! That was what was > nice about an AODV concept, because even route repair was fairly > deterministic. > > So... if your simulation could measure packet latency as a function > of DAG repair severity, that would be terrific. > > Hope this makes sense. > > Jerry > > > > > > > Mukul Goyal < mukul@uwm.edu > > > 01/13/2010 10:17 AM > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > Subject Re: [Roll] RPL Simulation > > > > > Joydeep > > Here are a few suggestions for your simulations: > > 1. Simulate a 100 node and a 1000 node topology operating under a > single DAG > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > the DAG from a source to a destination passes through their closest > common ancestor) and DAG routes through root (all DAG paths have to > go through the DAG root). > > 3. Study the stretch factor (increase in length/cost of routes over > the DAG versus the length/cost of ideal routes) for given number of > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > number of nodes in the topology: > a) the scenario you suggested: Choose 20% flows over 2 hop > neighbors, 10% flows over longer paths. > b) randomly selected source and destinations (in n*(n-1) case, from > each possible source node to each possible destination node). > > 4. In addition to the stretch factor, calculate/simulate the traffic > loads as well as packet loss/delay along the DAG links. Compare > these values against values with ideal P2P routing. > > Thanks > Mukul > ----- Original Message ----- > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > Cc: "ROLL WG" < roll@ietf.org > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Simulation > > Hi, > > In the next revision, we are also planning to implement a typical > building routing scenario, where 60-70% of the P2P traffic are > confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if > there is any other scenario or traffic pattern you want to be > implemented. > > Thanks, > Joydeep > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0284_01CA9E82.A7F419D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jerry,

 

The issue with AODV is you need a route table in each = router to indicate the next hop in the path.  The more next hop options you = have for a given router (as in a large network) the more table entries you = need.  Additionally, AODV uses flooding to establish routes so you also have to accommodate route discovery entries that grow with the number of devices = in the network (maybe not “order n” but will definitely = grow)

 

A network of size 6 would have very different AODV = resource requirements than a network of size 1000 since the route table and route discovery tables would be very different in size.  For a device manufacturer, there must be planning in advance based on expected = network topology to size the AODV resources correctly.  =

 

Don

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Tuesday, January 26, 2010 11:21 AM
To: d.sturek@att.net
Cc: 'JP Vasseur'; 'Mukul Goyal'; 'ROLL WG'; = roll-bounces@ietf.org
Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home

 


Hey = Don,

I = guess I miss your point.  If we use the proactive model then for a 1000 node = LLN, each node will have to define and maintain routes to 999 other nodes on the = oft chance that a message needs to be sent to any random node on the LLN.  This seems way less scalable than keeping a 'least recently used' = list of links that the node has needed to communicate to in the recent = past.

Also, = I am not sure why you think AODV overhead is a function of node count.  If = my room controller needs to talk to its temperature, occupancy and humidity = sensor, it doesn't really care if there are 10 other nodes in the LLN or 1000 other = nodes.  To me, scalability has to do with the application requirements, = not the LLN size.

Jerry =




"Don Sturek" <d.sturek@att.net>

01/26/2010 11:47 AM

Please = respond to
<d.sturek@att.net>

To=

<Jerald.P.M= artocci@jci.com>, "'JP Vasseur'" <jvasseur@cisco.com> =

cc=

"'ROLL WG'" <roll@ietf.org>, "'Mukul Goyal'" <mukul@UWM.EDU>, <roll-bounces@ietf.org> =

Subject=

RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation =        in the home

 




Hi Jerry,
 
I think the note below correctly reflects building automation = requirements.   Having 1000 devices on a building floor would not be a = surprise.
 
The trouble with reactive route discovery is many of the existing MANET = protocols like AODV scale with the number of devices in the network (so have to be tailored by deployment).   For example, route table size is an = example of a scaling resource in AODV.  I think in cases where there is a = needed reactive route discovery, we need to identify how to avoid making the = solution scale with deployment while still supporting low latency = messaging.
 
Don
 
 
From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jerald.P.Martocci@jci.com
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL = Simulation in the home
 

Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders = does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6LoWPAN networks all devices are on a = flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence = there is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a = priori way to preselect routes.

Regards,

Jerry

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

01/26/2010 11:01 AM

 

To=

Mukul Goyal <mukul@UWM.EDU>

cc=

ROLL WG <roll@ietf.org>

Subject=

Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation =        in the home


 

 





Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the =  
> need to maintain reachability information for all possible =  
> destinations to which some source might send a packet some day. =  
> That's why we need source-initiated route discovery, i.e. a = reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router =  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to =  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router = 4 -
> > router 5
>    but router 5 has never been routing traffic to lamp = module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router = 1
> 5) Router 1 sends the command to router 2 which forwards the = command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that =  
> it should be reactive.
> What you describe is routing protocol convergence, which of course =  
> does not imply that the
> protocol should be reactive. This is a typical case where the =  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time =  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a =  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will =  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on =  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep =  
> sending control traffic for
> that. If you links are extremely lossy you will have to make the = DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a reactive =  
> mechanism instead of
> proactive, this is not a magic solution either since you flood your =  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a = good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much =  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on = the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what =  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a = lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a =  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router =  
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love = to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network =  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in = home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the =  
> ability to
> operate in a reactive fasion is critical to home & building and = that  
> the DAG update
> signaling currently designed will have much bigger delays than the =  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so =  
> that over time
> DAG routes will reconstructed, but that the current spec cannot = find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other =  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something =  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational =  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you = though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even = route  
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still =  
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home = automation.
> By utilizing the fact that source routing is already used to jump =  
> between RPL-capable routers AND the fact that the (time = critical)
> point-to-point communication is limited to 5 hops or less, some = TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P  in home = and  
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other =  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =  
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3 =  
> years.  He has a good handle on the commercial building = performance  
> requirements.  It would be good for you to run those he notes =  
> below.  It might be advantageous then for you two to share the =  
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the = packet(s)  
> need to traverse the DAG all the way up to the LBR and back down to =  
> the destination node.  Of course, this is now a function on = DAG  
> depth.  Also since all our messages require ACK, the = additional  
> latency of the ACK having to return possibly through a different = set  
> of nodes yet via the LBR.  That would be the worst case = scenario.  
> If other nodes could short circuit the packets through a shorter =  
> path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning =  
> on lights, etc) latency is a big issue.  Moving the packet up = and  
> down the DAG is reasonably deterministic and should be primarily a =  
> function of the DAG depth.  However, what will really affect = the  
> system performance is 'DAG Repair'.  I have no sense how long = a  
> packet in transit would have to wait if the DAG was under repair. =  
> Since we require ACKs of every message, the source node would time- =
> out and retry a few times (usually 3).  After that, the source = node  
> would have to fall into some 'failsoft' mode depending on the type =  
> of data it was trying to access.  This is not a good = situation.  The  
> source node can only assume that its data is inaccessible, not just =  
> held up in transit.  The fail-soft mode will have large = hysteresis  
> since it can't be constantly dithering between modes.  This = will all  
> be logged to the operator which is a bad thing!!!  That was = what was  
> nice about an AODV concept, because even route repair was fairly =  
> deterministic.
>
> So... if your simulation could measure packet latency as a function =  
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> 01/13/2010 10:17 AM             =      
> To                 =  Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc                 =  ROLL WG < roll@ietf.org >, Jerald P Martocci < = Jerald.P.Martocci@jci.com
>  >
>
> Subject                 =  Re: [Roll] RPL Simulation
>                  
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a =  
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through =  
> the DAG from a source to a destination passes through their closest =  
> common ancestor) and DAG routes through root (all DAG paths have to =  
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over =  
> the DAG versus the length/cost of ideal routes) for given number of =  
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =  
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop =  
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from =  
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the = traffic  
> loads as well as packet loss/delay along the DAG links. Compare =  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com = >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com = >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =  
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a = typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P = traffic
> are to a 2 -hop distance destination, and observe the performance = of
> RPL against the ideal shortest route. Also, please let us know = if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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

------=_NextPart_000_0284_01CA9E82.A7F419D0-- From pal@cs.stanford.edu Tue Jan 26 12:45:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4237228C107; Tue, 26 Jan 2010 12:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUgnkqpHb33i; Tue, 26 Jan 2010 12:45:27 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 8CFA928C12B; Tue, 26 Jan 2010 12:45:27 -0800 (PST) Received: from adsl-69-107-121-247.dsl.pltn13.pacbell.net ([69.107.121.247] helo=[192.168.1.123]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NZsI6-0007su-T4; Tue, 26 Jan 2010 12:45:39 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <496706315.659531264535850961.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Tue, 26 Jan 2010 12:45:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <28548509-09EB-4B2E-BD64-DCD3D96140D3@cs.stanford.edu> References: <496706315.659531264535850961.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 20:45:28 -0000 On Jan 26, 2010, at 11:57 AM, Mukul Goyal wrote: > Henning, >=20 > We clearly do not want a route discovery based on immediate = network-wide broadcast of route request messages (as in AODV). But we = could still come up with a reactive approach that suits the needs of = LLNs. Mukul, The goal here isn't to invent a new algorithm: that's the province of = the IRTF and the research community. Our goal is to build on existing = practice and define a standard. Phil= From d.sturek@att.net Tue Jan 26 12:59:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C377C3A68C5 for ; Tue, 26 Jan 2010 12:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbaRPfM7GkGQ for ; Tue, 26 Jan 2010 12:59:09 -0800 (PST) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id A24613A68BD for ; Tue, 26 Jan 2010 12:59:09 -0800 (PST) Received: (qmail 50717 invoked from network); 26 Jan 2010 20:52:41 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 26 Jan 2010 12:52:40 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: XIAzJGUVM1mGbdXuVU21zZWoJjhc1Vl3lUcEJzsT8fIC0ZwVcVAV4mod4rWHxcTaHqGBz7EckYH2jE0Ct7eHcoHy50AqFmznVyIWip.0_BHU6PhofW8eBNkfjHjuGYTLzRoI8t2PCsarMdnwNwJROaZEIkpoTHuo6L_Jcu9eJN0yrk8P1UCJuHTeWETla1a4p5U_4_LNS6Oj1SMvz55uk3SOq3f.Nb66wjnwvPUR83GQAkKH1kWcCXfaZKTY_tGb.GtBxlpU_FYD77Jo.Bz195pBdpVKh_941gIlImzeZOlXyBTuXg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Henning Rogge'" , References: <201001262025.17833.hrogge@googlemail.com> In-Reply-To: <201001262025.17833.hrogge@googlemail.com> Date: Tue, 26 Jan 2010 12:52:35 -0800 Message-ID: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqevU9OcHrazSnuRp2Km9fJsmislAACv1eQ Content-Language: en-us Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:59:09 -0000 Hi Henning, I think 1000 nodes in AODV is no problem if you know in advance you are dealing with a 1000 node deployment. The trouble comes when you size for something significantly different from 1000..... This is why I really liked the DAG in ROLL RPL. No matter how many devices are part of the network, the resource requirements are the same. The trick is to figure out how to deal with routing failures in the DAG now such that we don't lose low latency for applications like building automation. Don -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 11:25 AM To: roll@ietf.org Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to > any random node on the LLN. This seems way less scalable than keeping > a 'least recently used' list of links that the node has needed to > communicate to in the recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge From skip.ashton@ember.com Tue Jan 26 13:04:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE2828C10B; Tue, 26 Jan 2010 13:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fttLjeubLuhQ; Tue, 26 Jan 2010 13:04:55 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 9AB6E28C0EF; Tue, 26 Jan 2010 13:04:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 16:07:23 -0500 Message-ID: In-Reply-To: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home Thread-Index: AcqevU9OcHrazSnuRp2Km9fJsmislAACv1eQAAC9F0A= References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> From: "Skip Ashton" To: , "Henning Rogge" , Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 21:04:56 -0000 While the DAG may not care how many devices are in the network - that is because it is only setting up one direction of the connection needed. The DIO messages then do require resources on devices in the network or in the edge routers. =20 This is where we have seen very efficient implementations of source routing and record route in 15.4 networks so bi-directional routes can be maintained and be reactive without the overhead of these DIO messages. Skip=20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: Tuesday, January 26, 2010 3:53 PM To: 'Henning Rogge'; roll@ietf.org Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home Hi Henning, I think 1000 nodes in AODV is no problem if you know in advance you are dealing with a 1000 node deployment. The trouble comes when you size for something significantly different from 1000..... This is why I really liked the DAG in ROLL RPL. No matter how many devices are part of the network, the resource requirements are the same. The trick is to figure out how to deal with routing failures in the DAG now such that we don't lose low latency for applications like building automation. Don -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 11:25 AM To: roll@ietf.org Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, >=20 > I guess I miss your point. If we use the proactive model then for a=20 > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to=20 > any random node on the LLN. This seems way less scalable than keeping > a 'least recently used' list of links that the node has needed to=20 > communicate to in the recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From hrogge@googlemail.com Tue Jan 26 13:13:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6889F3A6882; Tue, 26 Jan 2010 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg2sntzWRrlr; Tue, 26 Jan 2010 13:13:18 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 63C4B3A69C5; Tue, 26 Jan 2010 13:13:16 -0800 (PST) Received: by ewy8 with SMTP id 8so5954116ewy.29 for ; Tue, 26 Jan 2010 13:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=2As2WvUJMDUNRp0Naii1KDirAFbS6dUjRn9vI1MCKOg=; b=rT6gDwEI4/uy4I8Xlbzh2yS3gbdPyWIjAv67fcy1UZ4ankFqsSeN+l3gb4qwnGJAZo q0i1T7z5bZ+xqldvcQ2SsEgZSAYU3iCN/MQRLdPukGbXw9PG4svbqQvpxnT9x5280SE5 94Ji9jHObfg03N+B6OOcfdf16hopY7C2MOGIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=KWwyRLcLHCszqIHi12wSwQUg7sNaEkv8G7BuFLLa31BjpqpGfpts1gtTX+UsglU/Pr inOXSuUkTW20/wcNq7EKQJOVCac0tiEQA0ef0LOpgLcpN0sPMC1ffq0ZoALw7AfT0Ahn qrcsqpztG9asA21uPt4l2OCK9545q6PtP8SZc= Received: by 10.213.109.70 with SMTP id i6mr5288476ebp.16.1264540403453; Tue, 26 Jan 2010 13:13:23 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 15sm5538649ewy.8.2010.01.26.13.13.21 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 13:13:22 -0800 (PST) From: Henning Rogge To: d.sturek@att.net Date: Tue, 26 Jan 2010 22:13:06 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.32-gentoo-r2; KDE/4.3.4; x86_64; ; ) References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> In-Reply-To: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1550647.WS9aG4r1Lo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001262213.11506.hrogge@googlemail.com> Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] =?iso-8859-1?q?Reactive_versus_Proactive_approaches_Re=3A_?= =?iso-8859-1?q?RPL_Simulation=09in_the_home?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 21:13:23 -0000 --nextPart1550647.WS9aG4r1Lo Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 26 Januar 2010 21:52:35 schrieb Don Sturek: > Hi Henning, >=20 > I think 1000 nodes in AODV is no problem if you know in advance you are > dealing with a 1000 node deployment. >=20 > The trouble comes when you size for something significantly different from > 1000..... >=20 > This is why I really liked the DAG in ROLL RPL. No matter how many devic= es > are part of the network, the resource requirements are the same. The tri= ck > is to figure out how to deal with routing failures in the DAG now such th= at > we don't lose low latency for applications like building automation. I'm not sure I understand Ripple completely, but infinite meshs (any size)= =20 with only constant memory requirements (and network requirements) sound a=20 little bit overoptimistic. Henning Rogge --nextPart1550647.WS9aG4r1Lo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAktfWucACgkQcenvcwAcHWfwVwCdFvadJ3u+QSpm2tgi61XVKUH8 +8gAnA4NV0Zkcd/x+zejCxQkvE9j/aPz =+QMl -----END PGP SIGNATURE----- --nextPart1550647.WS9aG4r1Lo-- From d.sturek@att.net Tue Jan 26 13:38:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D633A69F0 for ; Tue, 26 Jan 2010 13:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzte-Wo-QPQ9 for ; Tue, 26 Jan 2010 13:38:51 -0800 (PST) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 486DB3A6A03 for ; Tue, 26 Jan 2010 13:36:06 -0800 (PST) Received: (qmail 411 invoked from network); 26 Jan 2010 21:29:38 -0000 Received: from adsl-69-224-191-28.dsl.sndg02.pacbell.net (d.sturek@69.224.191.28 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 26 Jan 2010 13:29:38 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: pX.uAdAVM1nKrLCxeVagrZ2Yl33hNZCUt4QhduUAMbm3RubT4lMdm7TOi7LPmRl7w0wUNG4G6AU5h_25QihGb9wpqHgrZXbCiSQK2NNm50WbgGTahH.ErB.UYucaXjVnK5glICv9sIPqugkp1XLOW8fKu4TTpjonK2QrIyLV8rI4F.UzbDr5Jc6KBLB4sWgFHdwgCn9dD5GKa_XAoeL09yVQMcTNg6m145de6h.nsZNX3VdOqzy611H5s89J8CaCCqqbmSF1kB1r5tTuWLkpb0frCj3_bVXSneKxgP9dxk0px2qxsA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Henning Rogge'" References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> <201001262213.11506.hrogge@googlemail.com> In-Reply-To: <201001262213.11506.hrogge@googlemail.com> Date: Tue, 26 Jan 2010 13:29:33 -0800 Message-ID: <02da01ca9ece$a7221240$f56636c0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqezGbguBOiZWt3SI2m7FQ1eaHxJAAAbrMQ Content-Language: en-us Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 21:38:51 -0000 Hi Henning, I think what we need is not infinite mesh sizes with a constant memory size but the ability to deploy devices that don't have to be configured or optimized based on the deployment size. Ideally if a device manufacturer could put out devices that could address a range of deployment topologies and network sizes without customization that would be great. Don -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 1:13 PM To: d.sturek@att.net Cc: roll@ietf.org; Jerald.P.Martocci@jci.com; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 21:52:35 schrieb Don Sturek: > Hi Henning, > > I think 1000 nodes in AODV is no problem if you know in advance you > are dealing with a 1000 node deployment. > > The trouble comes when you size for something significantly different > from 1000..... > > This is why I really liked the DAG in ROLL RPL. No matter how many > devices are part of the network, the resource requirements are the > same. The trick is to figure out how to deal with routing failures in > the DAG now such that we don't lose low latency for applications like building automation. I'm not sure I understand Ripple completely, but infinite meshs (any size) with only constant memory requirements (and network requirements) sound a little bit overoptimistic. Henning Rogge From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 13:39:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBB43A69CB; Tue, 26 Jan 2010 13:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZNhi5xcwXyO; Tue, 26 Jan 2010 13:39:29 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 9BFEC3A69E5; Tue, 26 Jan 2010 13:38:22 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 26 Jan 2010 15:38:33 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id AB31C2C382EA; Tue, 26 Jan 2010 15:38:33 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO2UK1LyEYLu; Tue, 26 Jan 2010 15:38:33 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 7FE412C382AC; Tue, 26 Jan 2010 15:38:33 -0600 (CST) Date: Tue, 26 Jan 2010 15:38:33 -0600 (CST) From: Mukul Goyal To: d sturek Message-ID: <1963317378.737831264541913462.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 21:39:30 -0000 Don, >This is why I really liked the DAG in ROLL RPL. No matter how many devices >are part of the network, the resource requirements are the same. Not sure about this. For bidirectional communication, there is a need to store southbound reachability information for all the destinations in the network, which is clearly not constant cost in terms of memory. Thanks Mukul -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 11:25 AM To: roll@ietf.org Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to > any random node on the LLN. This seems way less scalable than keeping > a 'least recently used' list of links that the node has needed to > communicate to in the recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge From prvs=6358557b1=mukul@uwm.edu Tue Jan 26 13:44:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C403A67A4; Tue, 26 Jan 2010 13:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fInMdT+RObf; Tue, 26 Jan 2010 13:44:39 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 1BB2F3A6830; Tue, 26 Jan 2010 13:44:39 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta2.uwm.edu with ESMTP; 26 Jan 2010 15:44:50 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6AB002C382C6; Tue, 26 Jan 2010 15:44:50 -0600 (CST) X-Virus-Scanned: amavisd-new at pantherlink.uwm.edul Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4I8TB4VHcMX; Tue, 26 Jan 2010 15:44:50 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3EB8C2C382BD; Tue, 26 Jan 2010 15:44:50 -0600 (CST) Date: Tue, 26 Jan 2010 15:44:50 -0600 (CST) From: Mukul Goyal To: d sturek Message-ID: <885369308.743861264542290173.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <02da01ca9ece$a7221240$f56636c0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.21_GA_3150.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 21:44:40 -0000 Hi Don, >I think what we need is not infinite mesh sizes with a constant memory size >but the ability to deploy devices that don't have to be configured or >optimized based on the deployment size. RPL devices would need to be configured and optimized based on the deployment size and scenario. The need for southbound communication means that memory requirements are not constant irrespective of deployment size. The need for low latency means that protocol delays would need careful configuration. >Ideally if a device manufacturer could put out devices that could address a >range of deployment topologies and network sizes without customization that >would be great. Not sure if RPL meets this goal. (I guess it would be difficult for any protocol to meet this goal.) Thanks Mukul -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 1:13 PM To: d.sturek@att.net Cc: roll@ietf.org; Jerald.P.Martocci@jci.com; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 21:52:35 schrieb Don Sturek: > Hi Henning, > > I think 1000 nodes in AODV is no problem if you know in advance you > are dealing with a 1000 node deployment. > > The trouble comes when you size for something significantly different > from 1000..... > > This is why I really liked the DAG in ROLL RPL. No matter how many > devices are part of the network, the resource requirements are the > same. The trick is to figure out how to deal with routing failures in > the DAG now such that we don't lose low latency for applications like building automation. I'm not sure I understand Ripple completely, but infinite meshs (any size) with only constant memory requirements (and network requirements) sound a little bit overoptimistic. Henning Rogge From d.sturek@att.net Tue Jan 26 14:09:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56E428C0EE for ; Tue, 26 Jan 2010 14:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrA0XjFeT674 for ; Tue, 26 Jan 2010 14:09:31 -0800 (PST) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 0446828C0EA for ; Tue, 26 Jan 2010 14:09:30 -0800 (PST) Received: (qmail 6686 invoked from network); 26 Jan 2010 21:36:05 -0000 Received: from Studio (d.sturek@69.224.191.28 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 26 Jan 2010 13:36:05 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: b5XON_4VM1nt1UTFwaqsd7biFOyJpPJovXO5VxSPjnPBUcOSWD0fKfJxl7twB1aneMs51eQ0fpSq3llmSTS7Dv4NdDAEDAgM1zwMRhpv5xcS87DCVaTDkm_B6fBOESP2H7v8AU6SfDLkavZ1P8hxecAVZ6JGsgfz4VjI7BFv03xzyJMJoCARi8GztYhmsE2Ak5zZyF4JrTM7riTGX1GqO_BL8r1wDB4PqT2HfRkdPMG6U272_Wz3FRZH5LNVrrSZCKW3jr5pknafeQV7dxWvLGnp27xhGS5c.hhtONfF7do9LqLQOg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Skip Ashton'" , "'Henning Rogge'" , References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> In-Reply-To: Date: Tue, 26 Jan 2010 13:35:59 -0800 Message-ID: <02db01ca9ecf$8df17170$a9d45450$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqevU9OcHrazSnuRp2Km9fJsmislAACv1eQAAC9F0AAANpPYA== Content-Language: en-us Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 22:09:31 -0000 Hi Skip, I agree there are some optimizations needed around DIO messages. Source routing, route record and bi-directional link establishment/asymmetric link elimination are all very sound strategies. What is missing right now is recovery for the DAG where routing fails while maintaining latency. Hopefully, we can find solutions on this like those you identified for DIO messages. Don -----Original Message----- From: Skip Ashton [mailto:skip.ashton@ember.com] Sent: Tuesday, January 26, 2010 1:07 PM To: d.sturek@att.net; Henning Rogge; roll@ietf.org Cc: roll-bounces@ietf.org Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home While the DAG may not care how many devices are in the network - that is because it is only setting up one direction of the connection needed. The DIO messages then do require resources on devices in the network or in the edge routers. This is where we have seen very efficient implementations of source routing and record route in 15.4 networks so bi-directional routes can be maintained and be reactive without the overhead of these DIO messages. Skip -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: Tuesday, January 26, 2010 3:53 PM To: 'Henning Rogge'; roll@ietf.org Cc: roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home Hi Henning, I think 1000 nodes in AODV is no problem if you know in advance you are dealing with a 1000 node deployment. The trouble comes when you size for something significantly different from 1000..... This is why I really liked the DAG in ROLL RPL. No matter how many devices are part of the network, the resource requirements are the same. The trick is to figure out how to deal with routing failures in the DAG now such that we don't lose low latency for applications like building automation. Don -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 11:25 AM To: roll@ietf.org Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to > any random node on the LLN. This seems way less scalable than keeping > a 'least recently used' list of links that the node has needed to > communicate to in the recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Jan 26 14:30:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4EE628C108; Tue, 26 Jan 2010 14:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKtpurMm9LL9; Tue, 26 Jan 2010 14:30:23 -0800 (PST) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by core3.amsl.com (Postfix) with ESMTP id 76B743A68B7; Tue, 26 Jan 2010 14:30:21 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKS19tB6f3HN1M4986KWqifA+B9BHENP6f@postini.com; Tue, 26 Jan 2010 14:30:33 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010012616303816-257404 ; Tue, 26 Jan 2010 16:30:38 -0600 In-Reply-To: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> MIME-Version: 1.0 To: X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 26 Jan 2010 16:30:24 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/26/2010 04:30:28 PM, Serialize complete at 01/26/2010 04:30:28 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 04:30:38 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 01/26/2010 04:30:41 PM, Serialize complete at 01/26/2010 04:30:41 PM Content-Type: multipart/related; boundary="=_related 007BA1CD862576B7_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Jan 2010 22:30:24 -0000 This is a multipart message in MIME format. --=_related 007BA1CD862576B7_= Content-Type: multipart/alternative; boundary="=_alternative 007BA1CD862576B7_=" --=_alternative 007BA1CD862576B7_= Content-Type: text/plain; charset="US-ASCII" HI Don, The resource requirements might be the same for northbound only applications (e.g. collection networks); however for North/Southbound applications (e.g. P2P) source route data must be maintained to every node in the DAG since any node might send a message to any other node. Jerry "Don Sturek" 01/26/2010 02:52 PM Please respond to To "'Henning Rogge'" , cc , "'Mukul Goyal'" , Subject RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Hi Henning, I think 1000 nodes in AODV is no problem if you know in advance you are dealing with a 1000 node deployment. The trouble comes when you size for something significantly different from 1000..... This is why I really liked the DAG in ROLL RPL. No matter how many devices are part of the network, the resource requirements are the same. The trick is to figure out how to deal with routing failures in the DAG now such that we don't lose low latency for applications like building automation. Don -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com] Sent: Tuesday, January 26, 2010 11:25 AM To: roll@ietf.org Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to > any random node on the LLN. This seems way less scalable than keeping > a 'least recently used' list of links that the node has needed to > communicate to in the recent past. 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not just simulations). Henning Rogge --=_alternative 007BA1CD862576B7_= Content-Type: text/html; charset="US-ASCII"
HI Don,

The resource requirements might be the same for northbound only applications (e.g. collection networks); however for North/Southbound applications (e.g. P2P) source route data must be maintained to every node in the DAG since any node might send a message to any other node.

Jerry





"Don Sturek" <d.sturek@att.net>

01/26/2010 02:52 PM
Please respond to
<d.sturek@att.net>
To
"'Henning Rogge'" <hrogge@googlemail.com>, <roll@ietf.org>
cc
<Jerald.P.Martocci@jci.com>, "'Mukul Goyal'" <mukul@uwm.edu>, <roll-bounces@ietf.org>
Subject
RE: [Roll] Reactive versus Proactive approaches Re: RPL  Simulation        in the home





Hi Henning,

I think 1000 nodes in AODV is no problem if you know in advance you are
dealing with a 1000 node deployment.

The trouble comes when you size for something significantly different from
1000.....

This is why I really liked the DAG in ROLL RPL.  No matter how many devices
are part of the network, the resource requirements are the same.  The trick
is to figure out how to deal with routing failures in the DAG now such that
we don't lose low latency for applications like building automation.

Don


-----Original Message-----
From: Henning Rogge [mailto:hrogge@googlemail.com]
Sent: Tuesday, January 26, 2010 11:25 AM
To: roll@ietf.org
Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal';
roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation
in the home

Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com:
> Hey Don,
>
> I guess I miss your point.  If we use the proactive model then for a
> 1000 node LLN, each node will have to define and maintain routes to
> 999 other nodes on the oft chance that a message needs to be sent to
> any random node on the LLN.  This seems way less scalable than keeping
> a 'least recently used' list of links that the node has needed to
> communicate to in the recent past.
1000 Nodes is no problem with proactive protocolls. I have yet to see
experiments with 10000 nodes how well AODV does scale (experiments, not just
simulations).

Henning Rogge
--=_alternative 007BA1CD862576B7_=-- --=_related 007BA1CD862576B7_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_04D7C88C04D7C374007BA1CB862576B7> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 007BA1CD862576B7_=-- From emmanuel.baccelli@gmail.com Wed Jan 27 03:06:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE963A6916 for ; Wed, 27 Jan 2010 03:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWmHJ944iBbU for ; Wed, 27 Jan 2010 03:06:35 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id EB8A43A6A47 for ; Wed, 27 Jan 2010 03:06:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so1457256eye.51 for ; Wed, 27 Jan 2010 03:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=mLu3ZVXvAvKQ4iU3e0sCyyn4HTGabSgMYB5oQqBOyXw=; b=YPm9/5fdiagIr0NOvadnY0eKFAUchFWk+D7Mae7xdXwP1dnaFa6elGsgOvQnM+ZuaM hsuegDH1crJ4vHpSEosji1HayuRdp/yrMV64tP79KUvxvHM0/j0sMfSD4p13RV2meoqn lAZxWj2i3RZLXotxc2HURfF7RKILB8TExFTsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=MMaVBIdXrl9BV7bUq6PyREAGw3gvdGllkVvoK+h8kWoeI8LaYVQIwS0wx6JOOWDHb1 rgvPc2+/eOE/4iiQrtHPFAYsiYuF7Tf+KyLMpbzz2+aixbvo98iYE+gGgZW9hbPn/HiP tE4Pd45LMi/02g20lLzfNe+bKnuCnxSByL+FU= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.1.220 with SMTP id 28mr3465261ebg.59.1264590404278; Wed, 27 Jan 2010 03:06:44 -0800 (PST) In-Reply-To: <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> References: <1915415853.577721264530147452.JavaMail.root@mail02.pantherlink.uwm.edu> <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> From: Emmanuel Baccelli Date: Wed, 27 Jan 2010 12:06:24 +0100 X-Google-Sender-Auth: d05b3889aaa0598e Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf94f4d55e10047e23650a Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 11:06:38 -0000 --000e0cdf94f4d55e10047e23650a Content-Type: text/plain; charset=ISO-8859-1 I agree with Mukul. To my knowledge, nobody argues with the fact that RPL proposes an interesting approach to achieve the goal of northbound communications (from sensors to sink/LBR). The DIO mechanism described in the spec is relatively understandable, and though there is limited experience with it so far, one can already get an idea of what performance/reliability to expect. However, the other goals of RPL are unclear, and the mechanisms proposed in addition to the basic DIO scheme are not straightforward to grasp or to gauge. This is why we get into muddy debates at this time. This working group has been asked many times to finally agree on an applicability statement for RPL, that would explicitly enumerate the goals that RPL is aiming to achieve. So in my mind, we should break this debate in two steps: first let's agree on an applicability statement for RPL. Then, if some additional mechanisms are needed to fulfill left out requirements, let's discuss them in a second phase. Honestly, I don't see any other way around if we want a finite convergence time... regards, Emmanuel On Tue, Jan 26, 2010 at 7:23 PM, Mukul Goyal wrote: > Don, > > I think it would be possible to find ways to avoid scaling problems with > reactive route discovery. I suggested one possibility in the following > draft: > > http://tools.ietf.org/html/draft-goyal-roll-dv-01 > > Lets first agree that we do need source-initiated route discovery. > > Thanks > Mukul > > ----- Original Message ----- > From: "Don Sturek" > To: "Jerald P Martocci" , "JP Vasseur" < > jvasseur@cisco.com> > Cc: "ROLL WG" , "Mukul Goyal" , > roll-bounces@ietf.org > Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > > > > > Hi Jerry, > > > > I think the note below correctly reflects building automation > requirements. Having 1000 devices on a building floor would not be a > surprise. > > > > The trouble with reactive route discovery is many of the existing MANET > protocols like AODV scale with the number of devices in the network (so have > to be tailored by deployment). For example, route table size is an example > of a scaling resource in AODV. I think in cases where there is a needed > reactive route discovery, we need to identify how to avoid making the > solution scale with deployment while still supporting low latency messaging. > > > > Don > > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jerald.P.Martocci@jci.com > Sent: Tuesday, January 26, 2010 9:20 AM > To: JP Vasseur > Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > > > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if Anders > does not have this requirement for a home, I do have this requirement for a > building. > > 2) My understanding is that for 6LoWPAN networks all devices are on a flat > network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence > there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is no a > priori way to preselect routes. > > Regards, > > Jerry > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > > 01/26/2010 11:01 AM > > To > > Mukul Goyal > > > cc > > ROLL WG > > > Subject > > Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > > > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > > > JP, > > > > The obvious problem with proactive approaches, such as RPL, is the > > need to maintain reachability information for all possible > > destinations to which some source might send a packet some day. > > That's why we need source-initiated route discovery, i.e. a reactive > > approach. > > > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Anders Brandt" > > Cc: "ROLL WG" > > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > > Central > > Subject: Re: [Roll] RPL Simulation in the home > > > > > > Copying the list to continue that discussion - see below > > > > > > > > Anders> > > > > > > > > > > > > > > > > > > > > > > > > Anyway, > > the use case is quite simple: > > > > Z - R1 - R2 - R3 - A > > > > 1) Lamp module A was recently controlled by controller Z via router > > 1 -> router 2 -> router 3 > > > > Z - R1 - R2 - R3 - A > > > > 2) Something renders the radio connection unusable from router 3 to > > lamp module A > > 3) The lamp module can however be reached via router 1 -> router 4 - > > > router 5 > > but router 5 has never been routing traffic to lamp module A > > > > Z - R1 - R2 - R3 - . > > \ > > - R4 - R5 - A > > 4) Controller Z sends another command to lamp module A via router 1 > > 5) Router 1 sends the command to router 2 which forwards the command > > to router 3 > > 6) Router 3 is unable to deliver the command > > > > What happens now? > > > > > > This is exactly why I was asking you the reason why you think that > > it should be reactive. > > What you describe is routing protocol convergence, which of course > > does not imply that the > > protocol should be reactive. This is a typical case where the > > topology is changing and RPL > > needs to adapt to it, which it does. The way to meet your time > > requirements is to adjust > > the RPL parameters to make it quicker to converge. If there is a > > link between A and R5, > > as soon as it becomes operational, A can send a DAO and R1 will > > direct the traffic to R4 > > instead of R2. > > > > > > > > > > Will the lamp go on within 250ms? > > > > > > > > So you raise the issue of convergence time, fair. It all depends on > > how you tune RPL and A > > selects R5 as a new parent. Note that you do not have to keep > > sending control traffic for > > that. If you links are extremely lossy you will have to make the DAG > > fairly reactive, which > > means more control traffic of course. If you are using a reactive > > mechanism instead of > > proactive, this is not a magic solution either since you flood your > > network and add control > > messages too. > > > > > > What I think is that by using these mechanism you can achieve a good > > level of convergence > > time with reasonable traffic in presence of lossy link w/o too much > > control traffic. We can try > > to quantify if you can provide an example topology, few stats on the > > link flaps trying few RPL > > tuning. Could you ? > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > > > > > > > > > Thanks, > > Anders > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Thursday, January 21, 2010 09:11 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > > > > > > Sorry JP > > > > I really have no intention of spreading FUD. > > Guess this mainly indicates that I and Jerry need education of what > > RPL is expected/able to deliver. > > > > At the most recent telecon we again touched the issue of e.g. a lamp > > module which due to rf phenomena > > cannot be reached via the recent router - and I thought we had a > > common understanding that some reactive mechanism > > would be needed. > > > > Can RPL - in its current shape - identify a new route via a router > > which did not previously forward traffic to said lamp module? > > > > > > > > Not sure of what you mean by this ? > > > > > > > > > > I would love that but I need to understand how - and I would love to > > see your evidence! > > > > > > > > Here is what I can propose: could you provide a home network > > topology that I could use to provide > > simulations results ? > > > > > > Cheers. > > > > > > JP. > > > > > > > > > > Thanks, > > Anders > > > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Wednesday, January 20, 2010 18:21 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > > > > > > > > Hi JP > > > >> Are you saying that RPL is not good enough for P2P in home and > >> building? > > > > Well - which incarnation of RPL? (!) > > I was of the impression that we had a common understanding that the > > ability to > > operate in a reactive fasion is critical to home & building and that > > the DAG update > > signaling currently designed will have much bigger delays than the > > 250ms real-time > > users will tolerate. > > > > > > Where does that come from ? > > > > > > > > > > > > > > > >> Since I have evidence that it is not the case. > >> Do you have data that shows different results ? > > > > I may have misunderstood the telecon conclusions, but I got it so > > that over time > > DAG routes will reconstructed, but that the current spec cannot find > > a lost target on demand (?). > > > > > >> Because as you know it is now in our charter to work on other > >> protocols. > > now? I guess you mean "not" ? (!) > > My conclusion from the Rolle interim was that we needed something > > special to find routes across the cloud. > > If the DAG can re-establish contact within 250ms to an operational > > node that was just lost in a routing table, > > I would really love it. Is that the case? > > > > > > mmm I do not think so ... happy to discuss it live with you though. > > > > > > Cheers! > > > > > > JP. > > > > > > > > > > > > > > > > Cheers, > > Anders > > > > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sendt: on 20-01-2010 17:02 > > Til: Anders Brandt > > Emne: Re: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > off-line first. > > > > > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > > > > > > Jerry, > > > >> That was what was nice about an AODV concept, because even route > >> repair was fairly deterministic. > > > > As far as I am informed some reactive discovery mechanism is still > > needed for all the reasons that you list below. > > > > You may remember that we have the same needs in home automation. > > By utilizing the fact that source routing is already used to jump > > between RPL-capable routers AND the fact that the (time critical) > > point-to-point communication is limited to 5 hops or less, some TTL- > > aware, source-route-based AODV hybrid may not cause so > > much flooding as one could fear. > > > > > > > > Are you saying that RPL is not good enough for P2P in home and > > building ? Since I have evidence that it is not the case. > > Do you have data that shows different results ? > > Because as you know it is now in our charter to work on other > > protocols. > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > - Anders > > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > > Behalf Of Jerald.P.Martocci@jci.com > > Sent: Thursday, January 14, 2010 19:11 > > To: Joydeep Tripathi > > Cc: ROLL WG > > Subject: Re: [Roll] RPL Simulation > > > > > > > > Hi Joydeep, > > > > Mukul's been doing some simulations for my company for the past 3 > > years. He has a good handle on the commercial building performance > > requirements. It would be good for you to run those he notes > > below. It might be advantageous then for you two to share the > > results to better correlate the simulations. > > > > I would also look at the latency for P2P messages when the packet(s) > > need to traverse the DAG all the way up to the LBR and back down to > > the destination node. Of course, this is now a function on DAG > > depth. Also since all our messages require ACK, the additional > > latency of the ACK having to return possibly through a different set > > of nodes yet via the LBR. That would be the worst case scenario. > > If other nodes could short circuit the packets through a shorter > > path, that would on;y help. > > > > Since Building systems are real-time (smoke/fire detection, turning > > on lights, etc) latency is a big issue. Moving the packet up and > > down the DAG is reasonably deterministic and should be primarily a > > function of the DAG depth. However, what will really affect the > > system performance is 'DAG Repair'. I have no sense how long a > > packet in transit would have to wait if the DAG was under repair. > > Since we require ACKs of every message, the source node would time- > > out and retry a few times (usually 3). After that, the source node > > would have to fall into some 'failsoft' mode depending on the type > > of data it was trying to access. This is not a good situation. The > > source node can only assume that its data is inaccessible, not just > > held up in transit. The fail-soft mode will have large hysteresis > > since it can't be constantly dithering between modes. This will all > > be logged to the operator which is a bad thing!!! That was what was > > nice about an AODV concept, because even route repair was fairly > > deterministic. > > > > So... if your simulation could measure packet latency as a function > > of DAG repair severity, that would be terrific. > > > > Hope this makes sense. > > > > Jerry > > > > > > > > > > > > > > Mukul Goyal < mukul@uwm.edu > > > > > 01/13/2010 10:17 AM > > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < > Jerald.P.Martocci@jci.com > > > > > > > Subject Re: [Roll] RPL Simulation > > > > > > > > > > Joydeep > > > > Here are a few suggestions for your simulations: > > > > 1. Simulate a 100 node and a 1000 node topology operating under a > > single DAG > > > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > > the DAG from a source to a destination passes through their closest > > common ancestor) and DAG routes through root (all DAG paths have to > > go through the DAG root). > > > > 3. Study the stretch factor (increase in length/cost of routes over > > the DAG versus the length/cost of ideal routes) for given number of > > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > > number of nodes in the topology: > > a) the scenario you suggested: Choose 20% flows over 2 hop > > neighbors, 10% flows over longer paths. > > b) randomly selected source and destinations (in n*(n-1) case, from > > each possible source node to each possible destination node). > > > > 4. In addition to the stretch factor, calculate/simulate the traffic > > loads as well as packet loss/delay along the DAG links. Compare > > these values against values with ideal P2P routing. > > > > Thanks > > Mukul > > ----- Original Message ----- > > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > > Cc: "ROLL WG" < roll@ietf.org > > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > > Central > > Subject: [Roll] RPL Simulation > > > > Hi, > > > > In the next revision, we are also planning to implement a typical > > building routing scenario, where 60-70% of the P2P traffic are > > confined within 1 hop physical distance and, 20% of the P2P traffic > > are to a 2 -hop distance destination, and observe the performance of > > RPL against the ideal shortest route. Also, please let us know if > > there is any other scenario or traffic pattern you want to be > > implemented. > > > > Thanks, > > Joydeep > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000e0cdf94f4d55e10047e23650a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I agree with Mukul. To my knowledge, nobody argues with the = fact that RPL proposes an interesting approach to achieve the goal of north= bound communications (from sensors to sink/LBR). The DIO mechanism describe= d in the spec is relatively understandable, and though there is limited exp= erience with it so far, one can already get an idea of what performance/rel= iability to expect.

However, the other goals of RPL are unclear, and the mechani= sms proposed in addition to the basic DIO scheme are not straightforward to= grasp or to gauge. This is why we get into muddy debates at this time.

This working group has been asked many times to finally= agree on an applicability statement for RPL, that would explicitly enumera= te the goals that RPL is aiming to achieve.=A0

So in my mind, we should break this debate in two steps: first let's ag= ree on an applicability statement for RPL. Then, if some additional mechani= sms are needed to fulfill left out requirements, let's discuss them in = a second phase.=A0

Honestly, I don't see any other way around if we wa= nt=A0a finite convergence time...

regards,

Emmanuel



On Tue, Jan 26, 2010 at 7:23 PM, Mukul Goyal <mukul@uwm.edu> wrote:
Don,

I think it would be possible to find ways to avoid scaling problems with re= active route discovery. I suggested one possibility in the following draft:=

http://tools.ietf.org/html/draft-goyal-roll-dv-01

Lets first agree that we do need source-initiated route discovery.

Thanks
Mukul

----- Original Message -----
From: "Don Sturek" <d.stur= ek@att.net>
To: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>, "JP Vasseur" <jvasseur@cisco.com>
Cc: "ROLL WG" <roll@ietf.org<= /a>>, "Mukul Goyal" <mukul= @UWM.EDU>, roll-bounces@iet= f.org
Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation= =A0 =A0 in the home




Hi Jerry,

=A0

I think the note below correctly reflects building automation requirements.= =A0=A0 Having 1000 devices on a building floor would not be a surprise.

=A0

The trouble with reactive route discovery is many of the existing MANET pro= tocols like AODV scale with the number of devices in the network (so have t= o be tailored by deployment).=A0 =A0For example, route table size is an exa= mple of a scaling resource in AODV.=A0 I think in cases where there is a ne= eded reactive route discovery, we need to identify how to avoid making the = solution scale with deployment while still supporting low latency messaging= .

=A0

Don

=A0

=A0


From: roll= -bounces@ietf.org [mailto:roll= -bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; ro= ll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus Proac= tive approaches Re: RPL Simulation in the home

=A0


Hi JP,

My $.02 on your answers:

1) In a building there may 1000 devices in an LLN; hence even if Anders doe= s not have this requirement for a home, I do have this requirement for a bu= ilding.

2) My understanding is that for 6LoWPAN networks all devices are on a flat = network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence the= re is no way to aggregate routes.

2a) Source/destination routes are completely random; hence there is no a pr= iori way to preselect routes.

Regards,

Jerry





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

01/26/2010 11:01 AM

To

Mukul Goyal <mukul@UWM.EDU>


cc

ROLL WG <roll@ietf.org>


Subject

Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation =A0 =A0 = =A0 =A0in the home

=A0




Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the =A0=
> need to maintain reachability information for all possible =A0
> destinations to which some source might send a packet some day. =A0 > That's why we need source-initiated route discovery, i.e. a reacti= ve =A0
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive =A0
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <a= br@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf= .org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =A0 > Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router = =A0
> 1 -> router 2 -> router 3
>
> =A0Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to = =A0
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 = -
> > router 5
> =A0 =A0but router 5 has never been routing traffic to lamp module A >
> =A0Z - R1 - R2 - R3 - .
> =A0 =A0 =A0 =A0\
> =A0 =A0 =A0 =A0 - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1 > 5) Router 1 sends the command to router 2 which forwards the command = =A0
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that =A0=
> it should be reactive.
> What you describe is routing protocol convergence, which of course =A0=
> does not imply that the
> protocol should be reactive. This is a typical case where the =A0
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time =A0
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a =A0 > link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will =A0 > direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on = =A0
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep =A0
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG = =A0
> fairly reactive, which
> means more control traffic of course. If you are using a reactive =A0<= br> > mechanism instead of
> proactive, this is not a magic solution either since you flood your = =A0
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good = =A0
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much = =A0
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the = =A0
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
> =A0Anders
>
>
> From: JP Vasseur [ mailto:jvasse= ur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what = =A0
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp = =A0
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a =A0 > common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router =A0=
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to = =A0
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network =A0
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
> =A0Anders
>
>
>
> From: JP Vasseur [ mailto:jvasse= ur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P =A0in home and = =A0
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the = =A0
> ability to
> operate in a reactive fasion is critical to home & building and th= at =A0
> the DAG update
> signaling currently designed will have much bigger delays than the =A0=
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so =A0<= br> > that over time
> DAG routes will reconstructed, but that the current spec cannot find = =A0
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other =A0<= br> >> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something =A0<= br> > special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational =A0=
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though. >
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
> =A0Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseu= r@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route = =A0
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still =A0=
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump =A0<= br> > between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL- > aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P =A0in home and =A0<= br> > building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other =A0
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org<= /a> ] On =A0
> Behalf Of Jerald.P.Martoc= ci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3 = =A0
> years. =A0He has a good handle on the commercial building performance = =A0
> requirements. =A0It would be good for you to run those he notes =A0 > below. =A0It might be advantageous then for you two to share the =A0 > results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s) = =A0
> need to traverse the DAG all the way up to the LBR and back down to = =A0
> the destination node. =A0Of course, this is now a function on DAG =A0<= br> > depth. =A0Also since all our messages require ACK, the additional =A0<= br> > latency of the ACK having to return possibly through a different set = =A0
> of nodes yet via the LBR. =A0That would be the worst case scenario. = =A0
> If other nodes could short circuit the packets through a shorter =A0 > path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning = =A0
> on lights, etc) latency is a big issue. =A0Moving the packet up and = =A0
> down the DAG is reasonably deterministic and should be primarily a =A0=
> function of the DAG depth. =A0However, what will really affect the =A0=
> system performance is 'DAG Repair'. =A0I have no sense how lon= g a =A0
> packet in transit would have to wait if the DAG was under repair. =A0<= br> > Since we require ACKs of every message, the source node would time- > out and retry a few times (usually 3). =A0After that, the source node = =A0
> would have to fall into some 'failsoft' mode depending on the = type =A0
> of data it was trying to access. =A0This is not a good situation. =A0T= he =A0
> source node can only assume that its data is inaccessible, not just = =A0
> held up in transit. =A0The fail-soft mode will have large hysteresis = =A0
> since it can't be constantly dithering between modes. =A0This will= all =A0
> be logged to the operator which is a bad thing!!! =A0That was what was= =A0
> nice about an AODV concept, because even route repair was fairly =A0 > deterministic.
>
> So... if your simulation could measure packet latency as a function = =A0
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu &g= t;
>
> 01/13/2010 10:17 AM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> To =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com
> =A0>
>
> Subject =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Re: [Roll] RPL Simulation > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a =A0<= br> > single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through = =A0
> the DAG from a source to a destination passes through their closest = =A0
> common ancestor) and DAG routes through root (all DAG paths have to = =A0
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over = =A0
> the DAG versus the length/cost of ideal routes) for given number of = =A0
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =A0=
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop =A0
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from = =A0
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic = =A0
> loads as well as packet loss/delay along the DAG links. Compare =A0 > these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@iet= f.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =A0<= br> > Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of > RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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

--000e0cdf94f4d55e10047e23650a-- From jvasseur@cisco.com Wed Jan 27 03:42:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFF83A6A1E for ; Wed, 27 Jan 2010 03:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yhn-Yr9LaJI for ; Wed, 27 Jan 2010 03:42:43 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3C4A73A67F5 for ; Wed, 27 Jan 2010 03:42:43 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAFe1X0uQ/uCWe2dsb2JhbAA8mykBARYkBqQilwuEOAQ X-IronPort-AV: E=Sophos;i="4.49,353,1262563200"; d="scan'208";a="2817529" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 Jan 2010 11:12:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0RBgsis027493 for ; Wed, 27 Jan 2010 11:42:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 12:42:54 +0100 Received: from [64.103.30.149] ([64.103.30.149]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 12:42:54 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 08:10:10 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 11:42:54.0618 (UTC) FILETIME=[DD337FA0:01CA9F45] Subject: [Roll] Plan for the new RPL revision to come X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 11:42:44 -0000 Dear all, Just an update on the plan for the next revision of RPL (just focussing on RPL here): For Feb 6: Revision -06 * Finalize the DAO mechanisms (new text to be proposed to the list this week) * Incorporate proposed editorial changes to continue improve the text * Proposed change in the rank computation (TBD) For Feb 27: Revision -07 * Security * RPL Multicast operation * Flow label versus new IPv6 header * Potential needed optimization (e.g. DAO packing) * Improve manageability section Thanks. JP. From zach@sensinode.com Wed Jan 27 03:54:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C653A67E5 for ; Wed, 27 Jan 2010 03:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCE0SqqWJpaX for ; Wed, 27 Jan 2010 03:54:09 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E68433A6A43 for ; Wed, 27 Jan 2010 03:54:08 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0RBsEZh000752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 13:54:14 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 27 Jan 2010 13:54:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JP Vasseur X-Mailer: Apple Mail (2.1077) Cc: ROLL WG Subject: Re: [Roll] Plan for the new RPL revision to come X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 11:54:10 -0000 On Jan 27, 2010, at 9:10 , JP Vasseur wrote: > Dear all, >=20 > Just an update on the plan for the next revision of RPL (just = focussing on RPL here): >=20 > For Feb 6: Revision -06 > * Finalize the DAO mechanisms (new text to be proposed to the = list this week) > * Incorporate proposed editorial changes to continue improve the = text > * Proposed change in the rank computation (TBD) >=20 > For Feb 27: Revision -07 > * Security > * RPL Multicast operation > * Flow label versus new IPv6 header > * Potential needed optimization (e.g. DAO packing) =46rom the discussions in Hiroshima, Jonathan's presentation there, and = list discussions I don't consider DAO packing to be potential = optimization. This surely is a must, especially when used on LoWPANs. I = know the editors are really busy, but if at all possible let's try to = get something into -06.=20 Thanks, Zach > * Improve manageability section >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jvasseur@cisco.com Wed Jan 27 15:06:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED12C3A69E0 for ; Wed, 27 Jan 2010 15:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAN096jzx6jM for ; Wed, 27 Jan 2010 15:06:53 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A4C1A3A69A0 for ; Wed, 27 Jan 2010 15:06:52 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAFpWYEtAZnwM/2dsb2JhbAA9wQSXKoQ5BA X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="82432831" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2010 23:07:07 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.189]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN77Nh010461; Wed, 27 Jan 2010 23:07:07 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:07 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:06 -0600 Message-Id: <791EB4AF-9242-4BF0-A2EC-CA9850F934A6@cisco.com> From: JP Vasseur To: Zach Shelby In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 17:56:23 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:07.0066 (UTC) FILETIME=[725DF1A0:01CA9FA5] Cc: ROLL WG Subject: Re: [Roll] Plan for the new RPL revision to come X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:06:54 -0000 Hi Zach, On Jan 27, 2010, at 12:54 PM, Zach Shelby wrote: > On Jan 27, 2010, at 9:10 , JP Vasseur wrote: > >> Dear all, >> >> Just an update on the plan for the next revision of RPL (just >> focussing on RPL here): >> >> For Feb 6: Revision -06 >> * Finalize the DAO mechanisms (new text to be proposed to the list >> this week) >> * Incorporate proposed editorial changes to continue improve the >> text >> * Proposed change in the rank computation (TBD) >> >> For Feb 27: Revision -07 >> * Security >> * RPL Multicast operation >> * Flow label versus new IPv6 header >> * Potential needed optimization (e.g. DAO packing) > > From the discussions in Hiroshima, Jonathan's presentation there, > and list discussions I don't consider DAO packing to be potential > optimization. This surely is a must, especially when used on > LoWPANs. I know the editors are really busy, but if at all possible > let's try to get something into -06. > Thanks for the feed-back. Cheers. JP. > Thanks, > Zach > >> * Improve manageability section >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded > Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may > contain legally privileged information. If you are not the intended > recipient, please contact the sender and delete the e-mail from your > system without producing, distributing or retaining copies thereof. > > > > From jvasseur@cisco.com Wed Jan 27 15:07:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610793A69F6 for ; Wed, 27 Jan 2010 15:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.009 X-Spam-Level: X-Spam-Status: No, score=-10.009 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifdMpoU9uLfo for ; Wed, 27 Jan 2010 15:06:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1842228C0E0 for ; Wed, 27 Jan 2010 15:06:58 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAKZVYEutJV2Z/2dsb2JhbAA8wQeXJoItggwEjWo X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="293056654" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2010 23:07:13 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0RN7DKv012437; Wed, 27 Jan 2010 23:07:13 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:13 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:11 -0600 Message-Id: <43A8B57E-0DDF-42C3-A9C6-C2971F7F065F@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:09:46 +0100 References: <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:12.0316 (UTC) FILETIME=[757F07C0:01CA9FA5] Cc: ROLL WG Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:00 -0000 Hi Mukul, On Jan 26, 2010, at 7:23 PM, Mukul Goyal wrote: > Don, > > I think it would be possible to find ways to avoid scaling problems > with reactive route discovery. I suggested one possibility in the > following draft: > > http://tools.ietf.org/html/draft-goyal-roll-dv-01 > > Lets first agree that we do need source-initiated route discovery. > Again, co-chair hat off. You're right that we first need to agree that there is a need for a reactive mechanism. Pro-active routing does not imply high delays to discover how to reach a node after a topology change (node moving, failures, ...). What we need to explore is how RPL can be used to achieve the target in term of performance in light of the numbers spelled out in the requirement documents. Few possibilities are: o Tune the RPL parameters to join the DAG faster, and/or increase the degree of meshing (so as to get diverse path) to quickly recover connectivity o Trigger quick DAO refresh after connectivity loss to refresh the states (need to be discussed once the DAO mechanisms will have been stabilized. It is a sort of "reactive" mechanisms to speed up the whole process. In all cases, this means more control messages (regardless of the protocols) and must be well understood according to the context. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Don Sturek" > To: "Jerald P Martocci" , "JP Vasseur" > > Cc: "ROLL WG" , "Mukul Goyal" , roll-bounces@ietf.org > Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada > Central > Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > Hi Jerry, > > > > I think the note below correctly reflects building automation > requirements. Having 1000 devices on a building floor would not be > a surprise. > > > > The trouble with reactive route discovery is many of the existing > MANET protocols like AODV scale with the number of devices in the > network (so have to be tailored by deployment). For example, route > table size is an example of a scaling resource in AODV. I think in > cases where there is a needed reactive route discovery, we need to > identify how to avoid making the solution scale with deployment > while still supporting low latency messaging. > > > > Don > > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Jerald.P.Martocci@jci.com > Sent: Tuesday, January 26, 2010 9:20 AM > To: JP Vasseur > Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if > Anders does not have this requirement for a home, I do have this > requirement for a building. > > 2) My understanding is that for 6LoWPAN networks all devices are on > a flat network (i.e. all LLN nodes have the same prefix) (see RFC > 4944); hence there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is > no a priori way to preselect routes. > > Regards, > > Jerry > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > > 01/26/2010 11:01 AM > > To > > Mukul Goyal > > > cc > > ROLL WG > > > Subject > > Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > >> JP, >> >> The obvious problem with proactive approaches, such as RPL, is the >> need to maintain reachability information for all possible >> destinations to which some source might send a packet some day. >> That's why we need source-initiated route discovery, i.e. a reactive >> approach. >> > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Anders Brandt" >> Cc: "ROLL WG" >> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada >> Central >> Subject: Re: [Roll] RPL Simulation in the home >> >> >> Copying the list to continue that discussion - see below >> >> >> >> Anders> >> >> >> >> >> >> >> >> >> >> >> >> Anyway, >> the use case is quite simple: >> >> Z - R1 - R2 - R3 - A >> >> 1) Lamp module A was recently controlled by controller Z via router >> 1 -> router 2 -> router 3 >> >> Z - R1 - R2 - R3 - A >> >> 2) Something renders the radio connection unusable from router 3 to >> lamp module A >> 3) The lamp module can however be reached via router 1 -> router 4 - >>> router 5 >> but router 5 has never been routing traffic to lamp module A >> >> Z - R1 - R2 - R3 - . >> \ >> - R4 - R5 - A >> 4) Controller Z sends another command to lamp module A via router 1 >> 5) Router 1 sends the command to router 2 which forwards the command >> to router 3 >> 6) Router 3 is unable to deliver the command >> >> What happens now? >> >> >> This is exactly why I was asking you the reason why you think that >> it should be reactive. >> What you describe is routing protocol convergence, which of course >> does not imply that the >> protocol should be reactive. This is a typical case where the >> topology is changing and RPL >> needs to adapt to it, which it does. The way to meet your time >> requirements is to adjust >> the RPL parameters to make it quicker to converge. If there is a >> link between A and R5, >> as soon as it becomes operational, A can send a DAO and R1 will >> direct the traffic to R4 >> instead of R2. >> >> >> >> >> Will the lamp go on within 250ms? >> >> >> >> So you raise the issue of convergence time, fair. It all depends on >> how you tune RPL and A >> selects R5 as a new parent. Note that you do not have to keep >> sending control traffic for >> that. If you links are extremely lossy you will have to make the DAG >> fairly reactive, which >> means more control traffic of course. If you are using a reactive >> mechanism instead of >> proactive, this is not a magic solution either since you flood your >> network and add control >> messages too. >> >> >> What I think is that by using these mechanism you can achieve a good >> level of convergence >> time with reasonable traffic in presence of lossy link w/o too much >> control traffic. We can try >> to quantify if you can provide an example topology, few stats on the >> link flaps trying few RPL >> tuning. Could you ? >> >> >> Thanks. >> >> >> JP. >> >> >> >> >> >> >> >> >> >> Thanks, >> Anders >> >> >> From: JP Vasseur [ mailto:jvasseur@cisco.com ] >> Sent: Thursday, January 21, 2010 09:11 >> To: Anders Brandt >> Subject: Re: SV: [Roll] RPL Simulation >> >> >> Hi Anders, >> >> >> >> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: >> >> >> >> >> Sorry JP >> >> I really have no intention of spreading FUD. >> Guess this mainly indicates that I and Jerry need education of what >> RPL is expected/able to deliver. >> >> At the most recent telecon we again touched the issue of e.g. a lamp >> module which due to rf phenomena >> cannot be reached via the recent router - and I thought we had a >> common understanding that some reactive mechanism >> would be needed. >> >> Can RPL - in its current shape - identify a new route via a router >> which did not previously forward traffic to said lamp module? >> >> >> >> Not sure of what you mean by this ? >> >> >> >> >> I would love that but I need to understand how - and I would love to >> see your evidence! >> >> >> >> Here is what I can propose: could you provide a home network >> topology that I could use to provide >> simulations results ? >> >> >> Cheers. >> >> >> JP. >> >> >> >> >> Thanks, >> Anders >> >> >> >> From: JP Vasseur [ mailto:jvasseur@cisco.com ] >> Sent: Wednesday, January 20, 2010 18:21 >> To: Anders Brandt >> Subject: Re: SV: [Roll] RPL Simulation >> >> >> Hi Anders, >> >> >> >> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: >> >> >> >> >> >> >> Hi JP >> >>> Are you saying that RPL is not good enough for P2P in home and >>> building? >> >> Well - which incarnation of RPL? (!) >> I was of the impression that we had a common understanding that the >> ability to >> operate in a reactive fasion is critical to home & building and that >> the DAG update >> signaling currently designed will have much bigger delays than the >> 250ms real-time >> users will tolerate. >> >> >> Where does that come from ? >> >> >> >> >> >> >> >>> Since I have evidence that it is not the case. >>> Do you have data that shows different results ? >> >> I may have misunderstood the telecon conclusions, but I got it so >> that over time >> DAG routes will reconstructed, but that the current spec cannot find >> a lost target on demand (?). >> >> >>> Because as you know it is now in our charter to work on other >>> protocols. >> now? I guess you mean "not" ? (!) >> My conclusion from the Rolle interim was that we needed something >> special to find routes across the cloud. >> If the DAG can re-establish contact within 250ms to an operational >> node that was just lost in a routing table, >> I would really love it. Is that the case? >> >> >> mmm I do not think so ... happy to discuss it live with you though. >> >> >> Cheers! >> >> >> JP. >> >> >> >> >> >> >> >> Cheers, >> Anders >> >> >> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] >> Sendt: on 20-01-2010 17:02 >> Til: Anders Brandt >> Emne: Re: [Roll] RPL Simulation >> >> >> Hi Anders, >> >> >> off-line first. >> >> >> >> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: >> >> >> >> >> Jerry, >> >>> That was what was nice about an AODV concept, because even route >>> repair was fairly deterministic. >> >> As far as I am informed some reactive discovery mechanism is still >> needed for all the reasons that you list below. >> >> You may remember that we have the same needs in home automation. >> By utilizing the fact that source routing is already used to jump >> between RPL-capable routers AND the fact that the (time critical) >> point-to-point communication is limited to 5 hops or less, some TTL- >> aware, source-route-based AODV hybrid may not cause so >> much flooding as one could fear. >> >> >> >> Are you saying that RPL is not good enough for P2P in home and >> building ? Since I have evidence that it is not the case. >> Do you have data that shows different results ? >> Because as you know it is now in our charter to work on other >> protocols. >> >> >> Thanks. >> >> >> JP. >> >> >> >> >> >> - Anders >> >> >> >> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On >> Behalf Of Jerald.P.Martocci@jci.com >> Sent: Thursday, January 14, 2010 19:11 >> To: Joydeep Tripathi >> Cc: ROLL WG >> Subject: Re: [Roll] RPL Simulation >> >> >> >> Hi Joydeep, >> >> Mukul's been doing some simulations for my company for the past 3 >> years. He has a good handle on the commercial building performance >> requirements. It would be good for you to run those he notes >> below. It might be advantageous then for you two to share the >> results to better correlate the simulations. >> >> I would also look at the latency for P2P messages when the packet(s) >> need to traverse the DAG all the way up to the LBR and back down to >> the destination node. Of course, this is now a function on DAG >> depth. Also since all our messages require ACK, the additional >> latency of the ACK having to return possibly through a different set >> of nodes yet via the LBR. That would be the worst case scenario. >> If other nodes could short circuit the packets through a shorter >> path, that would on;y help. >> >> Since Building systems are real-time (smoke/fire detection, turning >> on lights, etc) latency is a big issue. Moving the packet up and >> down the DAG is reasonably deterministic and should be primarily a >> function of the DAG depth. However, what will really affect the >> system performance is 'DAG Repair'. I have no sense how long a >> packet in transit would have to wait if the DAG was under repair. >> Since we require ACKs of every message, the source node would time- >> out and retry a few times (usually 3). After that, the source node >> would have to fall into some 'failsoft' mode depending on the type >> of data it was trying to access. This is not a good situation. The >> source node can only assume that its data is inaccessible, not just >> held up in transit. The fail-soft mode will have large hysteresis >> since it can't be constantly dithering between modes. This will all >> be logged to the operator which is a bad thing!!! That was what was >> nice about an AODV concept, because even route repair was fairly >> deterministic. >> >> So... if your simulation could measure packet latency as a function >> of DAG repair severity, that would be terrific. >> >> Hope this makes sense. >> >> Jerry >> >> >> >> >> >> >> Mukul Goyal < mukul@uwm.edu > >> >> 01/13/2010 10:17 AM >> To Joydeep Tripathi < joydeep.tripathi@gmail.com > >> >> cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com >> > >> >> Subject Re: [Roll] RPL Simulation >> >> >> >> >> Joydeep >> >> Here are a few suggestions for your simulations: >> >> 1. Simulate a 100 node and a 1000 node topology operating under a >> single DAG >> >> 2. Simulate both scenarios: optimal DAG routes (ie the path through >> the DAG from a source to a destination passes through their closest >> common ancestor) and DAG routes through root (all DAG paths have to >> go through the DAG root). >> >> 3. Study the stretch factor (increase in length/cost of routes over >> the DAG versus the length/cost of ideal routes) for given number of >> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the >> number of nodes in the topology: >> a) the scenario you suggested: Choose 20% flows over 2 hop >> neighbors, 10% flows over longer paths. >> b) randomly selected source and destinations (in n*(n-1) case, from >> each possible source node to each possible destination node). >> >> 4. In addition to the stretch factor, calculate/simulate the traffic >> loads as well as packet loss/delay along the DAG links. Compare >> these values against values with ideal P2P routing. >> >> Thanks >> Mukul >> ----- Original Message ----- >> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > >> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > >> Cc: "ROLL WG" < roll@ietf.org > >> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada >> Central >> Subject: [Roll] RPL Simulation >> >> Hi, >> >> In the next revision, we are also planning to implement a typical >> building routing scenario, where 60-70% of the P2P traffic are >> confined within 1 hop physical distance and, 20% of the P2P traffic >> are to a 2 -hop distance destination, and observe the performance of >> RPL against the ideal shortest route. Also, please let us know if >> there is any other scenario or traffic pattern you want to be >> implemented. >> >> Thanks, >> Joydeep >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Jan 27 15:07:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251EC28C0E0; Wed, 27 Jan 2010 15:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.991 X-Spam-Level: X-Spam-Status: No, score=-9.991 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i0JhhxKXMSn; Wed, 27 Jan 2010 15:07:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 14A6428C0D8; Wed, 27 Jan 2010 15:07:03 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8GAFpWYEurRN+K/2dsb2JhbAA8gTgavzOJXY1Ngi2CDAQ X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208,217";a="141177540" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2010 23:07:18 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN7HVB011524; Wed, 27 Jan 2010 23:07:18 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:17 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:16 -0600 Message-Id: <832E0DFA-2543-48E4-BB65-67A9358DA5B9@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-66-689811916 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:12:16 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:16.0801 (UTC) FILETIME=[782B6310:01CA9FA5] Cc: 'Mukul Goyal' , 'ROLL WG' , roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:07 -0000 --Apple-Mail-66-689811916 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Jan 26, 2010, at 8:20 PM, Jerald.P.Martocci@jci.com wrote: > > Hey Don, > > I guess I miss your point. If we use the proactive model then for a > 1000 node LLN, each node will have to define and maintain routes to > 999 other nodes on the oft chance that a message needs to be sent to > any random node on the LLN. This seems way less scalable than > keeping a 'least recently used' list of links that the node has > needed to communicate to in the recent past. > If (1) you do not do any sort of aggregation (look at the Internet, we do not keep host routes in routing tables !) and (2) there is a cost in "flooding" the network each time you need a route to a host that is not yet present in the routing tables. > Also, I am not sure why you think AODV overhead is a function of > node count. If my room controller needs to talk to its temperature, > occupancy and humidity sensor, it doesn't really care if there are > 10 other nodes in the LLN or 1000 other nodes. To me, scalability > has to do with the application requirements, not the LLN size. > > Jerry > > > > > > "Don Sturek" > 01/26/2010 11:47 AM > Please respond to > > > To > , "'JP Vasseur'" > cc > "'ROLL WG'" , "'Mukul Goyal'" , > > Subject > RE: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > > Hi Jerry, > > I think the note below correctly reflects building automation > requirements. Having 1000 devices on a building floor would not be > a surprise. > > The trouble with reactive route discovery is many of the existing > MANET protocols like AODV scale with the number of devices in the > network (so have to be tailored by deployment). For example, route > table size is an example of a scaling resource in AODV. I think in > cases where there is a needed reactive route discovery, we need to > identify how to avoid making the solution scale with deployment > while still supporting low latency messaging. > > Don > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Jerald.P.Martocci@jci.com > Sent: Tuesday, January 26, 2010 9:20 AM > To: JP Vasseur > Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if > Anders does not have this requirement for a home, I do have this > requirement for a building. > > 2) My understanding is that for 6LoWPAN networks all devices are on > a flat network (i.e. all LLN nodes have the same prefix) (see RFC > 4944); hence there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is > no a priori way to preselect routes. > > Regards, > > Jerry > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 01/26/2010 11:01 AM > > > To > Mukul Goyal > cc > ROLL WG > Subject > Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > > > JP, > > > > The obvious problem with proactive approaches, such as RPL, is the > > need to maintain reachability information for all possible > > destinations to which some source might send a packet some day. > > That's why we need source-initiated route discovery, i.e. a reactive > > approach. > > > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Anders Brandt" > > Cc: "ROLL WG" > > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > > Central > > Subject: Re: [Roll] RPL Simulation in the home > > > > > > Copying the list to continue that discussion - see below > > > > > > > > Anders> > > > > > > > > > > > > > > > > > > > > > > > > Anyway, > > the use case is quite simple: > > > > Z - R1 - R2 - R3 - A > > > > 1) Lamp module A was recently controlled by controller Z via router > > 1 -> router 2 -> router 3 > > > > Z - R1 - R2 - R3 - A > > > > 2) Something renders the radio connection unusable from router 3 to > > lamp module A > > 3) The lamp module can however be reached via router 1 -> router 4 - > > > router 5 > > but router 5 has never been routing traffic to lamp module A > > > > Z - R1 - R2 - R3 - . > > \ > > - R4 - R5 - A > > 4) Controller Z sends another command to lamp module A via router 1 > > 5) Router 1 sends the command to router 2 which forwards the command > > to router 3 > > 6) Router 3 is unable to deliver the command > > > > What happens now? > > > > > > This is exactly why I was asking you the reason why you think that > > it should be reactive. > > What you describe is routing protocol convergence, which of course > > does not imply that the > > protocol should be reactive. This is a typical case where the > > topology is changing and RPL > > needs to adapt to it, which it does. The way to meet your time > > requirements is to adjust > > the RPL parameters to make it quicker to converge. If there is a > > link between A and R5, > > as soon as it becomes operational, A can send a DAO and R1 will > > direct the traffic to R4 > > instead of R2. > > > > > > > > > > Will the lamp go on within 250ms? > > > > > > > > So you raise the issue of convergence time, fair. It all depends on > > how you tune RPL and A > > selects R5 as a new parent. Note that you do not have to keep > > sending control traffic for > > that. If you links are extremely lossy you will have to make the DAG > > fairly reactive, which > > means more control traffic of course. If you are using a reactive > > mechanism instead of > > proactive, this is not a magic solution either since you flood your > > network and add control > > messages too. > > > > > > What I think is that by using these mechanism you can achieve a good > > level of convergence > > time with reasonable traffic in presence of lossy link w/o too much > > control traffic. We can try > > to quantify if you can provide an example topology, few stats on the > > link flaps trying few RPL > > tuning. Could you ? > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > > > > > > > > > Thanks, > > Anders > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Thursday, January 21, 2010 09:11 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > > > > > > Sorry JP > > > > I really have no intention of spreading FUD. > > Guess this mainly indicates that I and Jerry need education of what > > RPL is expected/able to deliver. > > > > At the most recent telecon we again touched the issue of e.g. a lamp > > module which due to rf phenomena > > cannot be reached via the recent router - and I thought we had a > > common understanding that some reactive mechanism > > would be needed. > > > > Can RPL - in its current shape - identify a new route via a router > > which did not previously forward traffic to said lamp module? > > > > > > > > Not sure of what you mean by this ? > > > > > > > > > > I would love that but I need to understand how - and I would love to > > see your evidence! > > > > > > > > Here is what I can propose: could you provide a home network > > topology that I could use to provide > > simulations results ? > > > > > > Cheers. > > > > > > JP. > > > > > > > > > > Thanks, > > Anders > > > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Wednesday, January 20, 2010 18:21 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > > > > > > > > Hi JP > > > >> Are you saying that RPL is not good enough for P2P in home and > >> building? > > > > Well - which incarnation of RPL? (!) > > I was of the impression that we had a common understanding that the > > ability to > > operate in a reactive fasion is critical to home & building and that > > the DAG update > > signaling currently designed will have much bigger delays than the > > 250ms real-time > > users will tolerate. > > > > > > Where does that come from ? > > > > > > > > > > > > > > > >> Since I have evidence that it is not the case. > >> Do you have data that shows different results ? > > > > I may have misunderstood the telecon conclusions, but I got it so > > that over time > > DAG routes will reconstructed, but that the current spec cannot find > > a lost target on demand (?). > > > > > >> Because as you know it is now in our charter to work on other > >> protocols. > > now? I guess you mean "not" ? (!) > > My conclusion from the Rolle interim was that we needed something > > special to find routes across the cloud. > > If the DAG can re-establish contact within 250ms to an operational > > node that was just lost in a routing table, > > I would really love it. Is that the case? > > > > > > mmm I do not think so ... happy to discuss it live with you though. > > > > > > Cheers! > > > > > > JP. > > > > > > > > > > > > > > > > Cheers, > > Anders > > > > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sendt: on 20-01-2010 17:02 > > Til: Anders Brandt > > Emne: Re: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > off-line first. > > > > > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > > > > > > Jerry, > > > >> That was what was nice about an AODV concept, because even route > >> repair was fairly deterministic. > > > > As far as I am informed some reactive discovery mechanism is still > > needed for all the reasons that you list below. > > > > You may remember that we have the same needs in home automation. > > By utilizing the fact that source routing is already used to jump > > between RPL-capable routers AND the fact that the (time critical) > > point-to-point communication is limited to 5 hops or less, some TTL- > > aware, source-route-based AODV hybrid may not cause so > > much flooding as one could fear. > > > > > > > > Are you saying that RPL is not good enough for P2P in home and > > building ? Since I have evidence that it is not the case. > > Do you have data that shows different results ? > > Because as you know it is now in our charter to work on other > > protocols. > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > - Anders > > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > > Behalf Of Jerald.P.Martocci@jci.com > > Sent: Thursday, January 14, 2010 19:11 > > To: Joydeep Tripathi > > Cc: ROLL WG > > Subject: Re: [Roll] RPL Simulation > > > > > > > > Hi Joydeep, > > > > Mukul's been doing some simulations for my company for the past 3 > > years. He has a good handle on the commercial building performance > > requirements. It would be good for you to run those he notes > > below. It might be advantageous then for you two to share the > > results to better correlate the simulations. > > > > I would also look at the latency for P2P messages when the packet(s) > > need to traverse the DAG all the way up to the LBR and back down to > > the destination node. Of course, this is now a function on DAG > > depth. Also since all our messages require ACK, the additional > > latency of the ACK having to return possibly through a different set > > of nodes yet via the LBR. That would be the worst case scenario. > > If other nodes could short circuit the packets through a shorter > > path, that would on;y help. > > > > Since Building systems are real-time (smoke/fire detection, turning > > on lights, etc) latency is a big issue. Moving the packet up and > > down the DAG is reasonably deterministic and should be primarily a > > function of the DAG depth. However, what will really affect the > > system performance is 'DAG Repair'. I have no sense how long a > > packet in transit would have to wait if the DAG was under repair. > > Since we require ACKs of every message, the source node would time- > > out and retry a few times (usually 3). After that, the source node > > would have to fall into some 'failsoft' mode depending on the type > > of data it was trying to access. This is not a good situation. The > > source node can only assume that its data is inaccessible, not just > > held up in transit. The fail-soft mode will have large hysteresis > > since it can't be constantly dithering between modes. This will all > > be logged to the operator which is a bad thing!!! That was what was > > nice about an AODV concept, because even route repair was fairly > > deterministic. > > > > So... if your simulation could measure packet latency as a function > > of DAG repair severity, that would be terrific. > > > > Hope this makes sense. > > > > Jerry > > > > > > > > > > > > > > Mukul Goyal < mukul@uwm.edu > > > > > 01/13/2010 10:17 AM > > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > > > > Subject Re: [Roll] RPL Simulation > > > > > > > > > > Joydeep > > > > Here are a few suggestions for your simulations: > > > > 1. Simulate a 100 node and a 1000 node topology operating under a > > single DAG > > > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > > the DAG from a source to a destination passes through their closest > > common ancestor) and DAG routes through root (all DAG paths have to > > go through the DAG root). > > > > 3. Study the stretch factor (increase in length/cost of routes over > > the DAG versus the length/cost of ideal routes) for given number of > > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > > number of nodes in the topology: > > a) the scenario you suggested: Choose 20% flows over 2 hop > > neighbors, 10% flows over longer paths. > > b) randomly selected source and destinations (in n*(n-1) case, from > > each possible source node to each possible destination node). > > > > 4. In addition to the stretch factor, calculate/simulate the traffic > > loads as well as packet loss/delay along the DAG links. Compare > > these values against values with ideal P2P routing. > > > > Thanks > > Mukul > > ----- Original Message ----- > > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > > Cc: "ROLL WG" < roll@ietf.org > > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > > Central > > Subject: [Roll] RPL Simulation > > > > Hi, > > > > In the next revision, we are also planning to implement a typical > > building routing scenario, where 60-70% of the P2P traffic are > > confined within 1 hop physical distance and, 20% of the P2P traffic > > are to a 2 -hop distance destination, and observe the performance of > > RPL against the ideal shortest route. Also, please let us know if > > there is any other scenario or traffic pattern you want to be > > implemented. > > > > Thanks, > > Joydeep > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-66-689811916 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Jan 26, 2010, at 8:20 PM, Jerald.P.Martocci@jci.com = wrote:


Hey Don, =

I guess I miss your point. =  If we use the proactive model then for a 1000 node LLN, each node = will have to define and maintain routes to 999 other nodes on the oft = chance that a message needs to be sent to any random node on the LLN. =  This seems way less scalable than keeping a 'least recently used' = list of links that the node has needed to communicate to in the recent = past.


If (1) you do not = do any sort of aggregation (look at the Internet, we do not keep host = routes in routing tables !)
and (2) there is a cost in = "flooding" the network each time you need a route to a host that is not = yet present in 
the routing tables.

Also, I am not sure = why you think AODV overhead is a function of node count.  If my = room controller needs to talk to its temperature, occupancy and humidity = sensor, it doesn't really care if there are 10 other nodes in the LLN or = 1000 other nodes.  To me, scalability has to do with the = application requirements, not the LLN size.

Jerry





=
"Don Sturek" <d.sturek@att.net> =

01/26/2010 11:47 = AM
Please respond to
<d.sturek@att.net>
To
<Jerald.P.Martocci@jci.com>= ;, "'JP Vasseur'" <jvasseur@cisco.com> =
cc
"'ROLL WG'" <roll@ietf.org>, "'Mukul Goyal'" = <mukul@UWM.EDU>, <roll-bounces@ietf.org>=
Subject
RE: [Roll] Reactive versus Proactive approaches Re: = RPL Simulation        in the = home

=



Hi Jerry,
 
I think the note below correctly = reflects building automation requirements.   Having 1000 devices on = a building floor would not be a surprise.
 
The trouble with reactive route = discovery is many of the existing MANET protocols like AODV scale with = the number of devices in the network (so have to be tailored by = deployment).   For example, route table size is an example of a = scaling resource in AODV.  I think in cases where there is a needed = reactive route discovery, we need to identify how to avoid making the = solution scale with deployment while still supporting low latency = messaging.
 
Don
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Jerald.P.Martocci@jci.com=
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP = Vasseur
Cc: ROLL WG; Mukul Goyal; = roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus = Proactive approaches Re: RPL Simulation in the home
 

Hi JP,

My $.02 on your = answers:
=
1) In a building there may = 1000 devices in an LLN; hence even if Anders does not have this = requirement for a home, I do have this requirement for a = building.
=
2) My understanding is that = for 6LoWPAN networks all devices are on a flat network (i.e. all LLN = nodes have the same prefix) (see RFC 4944); hence there is no way to = aggregate routes.
=
2a) Source/destination = routes are completely random; hence there is no a priori way to = preselect routes.
=
Regards,

Jerry


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

01/26/2010 11:01 AM


To
Mukul Goyal <mukul@UWM.EDU>
=
cc
= 		ROLL WG <roll@ietf.org>
=
Subject
= 		Re: [Roll] Reactive versus = Proactive approaches Re: RPL Simulation        in = the home

 


=
=





= Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:
=
> JP,
>
> The obvious problem with proactive = approaches, such as RPL, is the  
> need to maintain = reachability information for all possible  
> destinations = to which some source might send a packet some day.  
> = That's why we need source-initiated route discovery, i.e. a reactive =  
> approach.
>

Several answers here:
1) = Are there such as huge number of unicast addresses in a home ?
2) In = so, this is where route aggregation/summarization can help.

= This is why I'm challenging the need for an a priori reactive  
= mechanism here before we prove that
reactive is not good enough.
=
Makes sense ?

ps: again acting with no co-chair hat.
=
Thanks.

JP.

> Thanks
> Mukul
= >
> ----- Original Message -----
> From: "JP Vasseur" = <jvasseur@cisco.com>
= > To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: = "ROLL WG" <roll@ietf.org>
= > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =  
> Central
> Subject: Re: [Roll] RPL Simulation in = the home
>
>
> Copying the list to continue that = discussion - see below
>
>
>
> = Anders>
>
>
>
>
>
>
= >
>
>
>
>
> Anyway,
> the = use case is quite simple:
>
> Z - R1 - R2 - R3 - A
= >
> 1) Lamp module A was recently controlled by controller Z = via router  
> 1 -> router 2 -> router 3
>
= >  Z - R1 - R2 - R3 - A
>
> 2) Something renders = the radio connection unusable from router 3 to  
> lamp = module A
> 3) The lamp module can however be reached via router 1 = -> router 4 -
> > router 5
>    but = router 5 has never been routing traffic to lamp module A
>
= >  Z - R1 - R2 - R3 - .
>       =  \
>         - R4 - R5 - A
> 4) = Controller Z sends another command to lamp module A via router 1
= > 5) Router 1 sends the command to router 2 which forwards the = command  
> to router 3
> 6) Router 3 is unable to = deliver the command
>
> What happens now?
>
= >
> This is exactly why I was asking you the reason why you = think that  
> it should be reactive.
> What you = describe is routing protocol convergence, which of course  
= > does not imply that the
> protocol should be reactive. This = is a typical case where the  
> topology is changing and = RPL
> needs to adapt to it, which it does. The way to meet your = time  
> requirements is to adjust
> the RPL = parameters to make it quicker to converge. If there is a  
> = link between A and R5,
> as soon as it becomes operational, A can = send a DAO and R1 will  
> direct the traffic to R4
> = instead of R2.
>
>
>
>
> Will the = lamp go on within 250ms?
>
>
>
> So you = raise the issue of convergence time, fair. It all depends on  
= > how you tune RPL and A
> selects R5 as a new parent. Note = that you do not have to keep  
> sending control traffic = for
> that. If you links are extremely lossy you will have to = make the DAG  
> fairly reactive, which
> means more = control traffic of course. If you are using a reactive  
> = mechanism instead of
> proactive, this is not a magic solution = either since you flood your  
> network and add control
= > messages too.
>
>
> What I think is that by = using these mechanism you can achieve a good  
> level of = convergence
> time with reasonable traffic in presence of lossy = link w/o too much  
> control traffic. We can try
> = to quantify if you can provide an example topology, few stats on the =  
> link flaps trying few RPL
> tuning. Could you = ?
>
>
> Thanks.
>
>
> JP.
= >
>
>
>
>
>
>
>
= >
> Thanks,
>  Anders
>
>
> = From: JP Vasseur [ mailto:jvasseur@cisco.com ]
= > Sent: Thursday, January 21, 2010 09:11
> To: Anders = Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
= >
> Hi Anders,
>
>
>
> On Jan 21, = 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
= >
> Sorry JP
>
> I really have no intention of = spreading FUD.
> Guess this mainly indicates that I and Jerry = need education of what  
> RPL is expected/able to = deliver.
>
> At the most recent telecon we again touched = the issue of e.g. a lamp  
> module which due to rf = phenomena
> cannot be reached via the recent router - and I = thought we had a  
> common understanding that some reactive = mechanism
> would be needed.
>
> Can RPL - in its = current shape - identify a new route via a router  
> which = did not previously forward traffic to said lamp module?
>
= >
>
> Not sure of what you mean by this ?
>
= >
>
>
> I would love that but I need to = understand how - and I would love to  
> see your = evidence!
>
>
>
> Here is what I can = propose: could you provide a home network  
> topology that = I could use to provide
> simulations results ?
>
= >
> Cheers.
>
>
> JP.
>
= >
>
>
> Thanks,
>  Anders
= >
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
= > Sent: Wednesday, January 20, 2010 18:21
> To: Anders = Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
= >
> Hi Anders,
>
>
>
> On Jan 20, = 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
= >
>
>
> Hi JP
>
>> Are you = saying that RPL is not good enough for P2P  in home and  
= >> building?
>
> Well - which incarnation of RPL? = (!)
> I was of the impression that we had a common understanding = that the  
> ability to
> operate in a reactive = fasion is critical to home & building and that  
> the = DAG update
> signaling currently designed will have much bigger = delays than the  
> 250ms real-time
> users will = tolerate.
>
>
> Where does that come from ?
= >
>
>
>
>
>
>
>> = Since I have evidence that it is not the case.
>> Do you have = data that shows different results ?
>
> I may have = misunderstood the telecon conclusions, but I got it so  
> = that over time
> DAG routes will reconstructed, but that the = current spec cannot find  
> a lost target on demand = (?).
>
>
>> Because as you know it is now in our = charter to work on other  
>> protocols.
> now? I = guess you mean "not" ? (!)
> My conclusion from the Rolle interim = was that we needed something  
> special to find routes = across the cloud.
> If the DAG can re-establish contact within = 250ms to an operational  
> node that was just lost in a = routing table,
> I would really love it. Is that the case?
= >
>
> mmm I do not think so ... happy to discuss it = live with you though.
>
>
> Cheers!
>
= >
> JP.
>
>
>
>
>
= >
>
> Cheers,
>  Anders
>
= >
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
= > Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> = Emne: Re: [Roll] RPL Simulation
>
>
> Hi = Anders,
>
>
> off-line first.
>
>
= >
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
= >
>
>
>
> Jerry,
>
>> = That was what was nice about an AODV concept, because even route =  
>> repair was fairly deterministic.
>
> = As far as I am informed some reactive discovery mechanism is still =  
> needed for all the reasons that you list below.
= >
> You may remember that we have the same needs in home = automation.
> By utilizing the fact that source routing is = already used to jump  
> between RPL-capable routers AND the = fact that the (time critical)
> point-to-point communication is = limited to 5 hops or less, some TTL-
> aware, source-route-based = AODV hybrid may not cause so
> much flooding as one could = fear.
>
>
>
> Are you saying that RPL is not = good enough for P2P  in home and  
> building ? Since I = have evidence that it is not the case.
> Do you have data that = shows different results ?
> Because as you know it is now in our = charter to work on other  
> protocols.
>
= >
> Thanks.
>
>
> JP.
>
= >
>
>
>
> - Anders
>
>
= >
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On  
> Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11
> To: Joydeep = Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL = Simulation
>
>
>
> Hi Joydeep,
>
= > Mukul's been doing some simulations for my company for the past 3 =  
> years.  He has a good handle on the commercial = building performance  
> requirements.  It would be = good for you to run those he notes  
> below.  It might = be advantageous then for you two to share the  
> results to = better correlate the simulations.
>
> I would also look at = the latency for P2P messages when the packet(s)  
> need to = traverse the DAG all the way up to the LBR and back down to  
= > the destination node.  Of course, this is now a function on = DAG  
> depth.  Also since all our messages require = ACK, the additional  
> latency of the ACK having to return = possibly through a different set  
> of nodes yet via the = LBR.  That would be the worst case scenario.  
> If = other nodes could short circuit the packets through a shorter  
= > path, that would on;y help.
>
> Since Building = systems are real-time (smoke/fire detection, turning  
> on = lights, etc) latency is a big issue.  Moving the packet up and =  
> down the DAG is reasonably deterministic and should be = primarily a  
> function of the DAG depth.  However, = what will really affect the  
> system performance is 'DAG = Repair'.  I have no sense how long a  
> packet in = transit would have to wait if the DAG was under repair.  
> = Since we require ACKs of every message, the source node would time-
= > out and retry a few times (usually 3).  After that, the source = node  
> would have to fall into some 'failsoft' mode = depending on the type  
> of data it was trying to access. =  This is not a good situation.  The  
> source = node can only assume that its data is inaccessible, not just  
= > held up in transit.  The fail-soft mode will have large = hysteresis  
> since it can't be constantly dithering = between modes.  This will all  
> be logged to the = operator which is a bad thing!!!  That was what was  
> = nice about an AODV concept, because even route repair was fairly =  
> deterministic.
>
> So... if your = simulation could measure packet latency as a function  
> of = DAG repair severity, that would be terrific.
>
> Hope this = makes sense.
>
> Jerry
>
>
>
> = <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> = 01/13/2010 10:17 AM               =    
> To             =      Joydeep Tripathi < joydeep.tripathi@gmail.com = >
>
> cc             =      ROLL WG < roll@ietf.org >, Jerald P Martocci = < Jerald.P.Martocci@jci.com =
>  >
>
> Subject       =            Re: [Roll] RPL Simulation
= >                  
= >
>
>
> Joydeep
>
> Here are a few = suggestions for your simulations:
>
> 1. Simulate a 100 = node and a 1000 node topology operating under a  
> single = DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie = the path through  
> the DAG from a source to a destination = passes through their closest  
> common ancestor) and DAG = routes through root (all DAG paths have to  
> go through = the DAG root).
>
> 3. Study the stretch factor (increase = in length/cost of routes over  
> the DAG versus the = length/cost of ideal routes) for given number of  
> flows: = 100, 1000, 10000 and possibly n*(n-1) flows (where n is the  
= > number of nodes in the topology:
> a) the scenario you = suggested: Choose 20% flows over 2 hop  
> neighbors, 10% = flows over longer paths.
> b) randomly selected source and = destinations (in n*(n-1) case, from  
> each possible source = node to each possible destination node).
>
> 4. In = addition to the stretch factor, calculate/simulate the traffic =  
> loads as well as packet loss/delay along the DAG links. = Compare  
> these values against values with ideal P2P = routing.
>
> Thanks
> Mukul
> ----- Original = Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com = >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com = >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: = Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada  
= > Central
> Subject: [Roll] RPL Simulation
>
> = Hi,
>
> In the next revision, we are also planning to = implement a typical
> building routing scenario, where 60-70% of = the P2P traffic are
> confined within 1 hop physical distance = and, 20% of the P2P traffic
> are to a 2 -hop distance = destination, and observe the performance of
> RPL against the = ideal shortest route. Also, please let us know if
> there is any = other scenario or traffic pattern you want to be
> = implemented.
>
> Thanks,
> Joydeep
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll
>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll
>
>
>
>
= >
>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/m= ailman/listinfo/roll

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


= --Apple-Mail-66-689811916-- From jvasseur@cisco.com Wed Jan 27 15:07:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01B53A69E7; Wed, 27 Jan 2010 15:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4IDjta2rLPm; Wed, 27 Jan 2010 15:07:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 239CF28C0DD; Wed, 27 Jan 2010 15:07:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAKZVYEutJV2Z/2dsb2JhbAA8wQeXJoQ5BA X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="473897599" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2010 23:07:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0RN7bDT012498; Wed, 27 Jan 2010 23:07:37 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:37 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:36 -0600 Message-Id: From: JP Vasseur To: Skip Ashton In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:21:25 +0100 References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:36.0707 (UTC) FILETIME=[8408CD30:01CA9FA5] Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPLSimulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:23 -0000 Hi Skip, On Jan 26, 2010, at 10:07 PM, Skip Ashton wrote: > > While the DAG may not care how many devices are in the network - > that is > because it is only setting up one direction of the connection needed. > The DIO messages then do require resources on devices in the network > or > in the edge routers. > > This is where we have seen very efficient implementations of source > routing and record route in 15.4 networks so bi-directional routes can > be maintained and be reactive without the overhead of these DIO > messages. Let's just bear in mind that RPL is the mechanisms adopted by the WG. We are chartered to produce one routing protocol that meet the requirements spelled out in the requirements documents. Thanks. JP. > > Skip > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Don Sturek > Sent: Tuesday, January 26, 2010 3:53 PM > To: 'Henning Rogge'; roll@ietf.org > Cc: roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: > RPLSimulation in the home > > Hi Henning, > > I think 1000 nodes in AODV is no problem if you know in advance you > are > dealing with a 1000 node deployment. > > The trouble comes when you size for something significantly different > from 1000..... > > This is why I really liked the DAG in ROLL RPL. No matter how many > devices are part of the network, the resource requirements are the > same. > The trick is to figure out how to deal with routing failures in the > DAG > now such that we don't lose low latency for applications like building > automation. > > Don > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: Tuesday, January 26, 2010 11:25 AM > To: roll@ietf.org > Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; > roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: >> Hey Don, >> >> I guess I miss your point. If we use the proactive model then for a >> 1000 node LLN, each node will have to define and maintain routes to >> 999 other nodes on the oft chance that a message needs to be sent to >> any random node on the LLN. This seems way less scalable than >> keeping > >> a 'least recently used' list of links that the node has needed to >> communicate to in the recent past. > 1000 Nodes is no problem with proactive protocolls. I have yet to see > experiments with 10000 nodes how well AODV does scale (experiments, > not > just simulations). > > Henning Rogge > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Jan 27 15:07:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA3F3A635F; Wed, 27 Jan 2010 15:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEeLjdnbmQAr; Wed, 27 Jan 2010 15:07:31 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4A29028C0E1; Wed, 27 Jan 2010 15:07:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAFpWYEurR7H+/2dsb2JhbAA8wQWXKoQ5BA X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208,217";a="141177683" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2010 23:07:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN7Uew011089; Wed, 27 Jan 2010 23:07:32 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:31 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:30 -0600 Message-Id: From: JP Vasseur To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD454A@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-68-690162312 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:18:07 +0100 References: <201001262025.17833.hrogge@googlemail.com> <6D9687E95918C04A8B30A7D6DA805A3E01AD454A@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:31.0113 (UTC) FILETIME=[80B33990:01CA9FA5] Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:32 -0000 --Apple-Mail-68-690162312 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Anders, Co-chair "hat on", there are many ways to solve an issue. As a WG I =20 would just suggest to first make some analysis on whether the current solution =20 does address your requirements, which it has to, this is why we have requirements =20 documents, without jumping to additional mechanisms/protocols. Cheers. JP. On Jan 26, 2010, at 9:31 PM, Anders Brandt wrote: > Henning, > > The trick is that we can limit the scope. > We do not want to scan the entire Internet. > > For home and building, a TTL limiting the discovery to 4 repeater =20 > nodes would do the work. > Combine this with a dampening function which prevents repeaters from =20= > forwarding discovery messages if n other repeaters within direct =20 > reach already forwarded the same message and your broadcast storm is =20= > converted to a controlled wavefront forming a circle outwards. > Piggyback the "Light on" command on the discovery message and your =20 > latency is drastically reduced. > Finally, let the Discovery result message kill all pending discovery =20= > messages scheduled for later transmission. > > As Jerry said, cache the discovered route and use it the next time. > > Individually very simple mechanisms. Together, extremely efficient. > > I may add that this runs in the real world. > > Cheers, > Anders. > > Fra: roll-bounces@ietf.org p=E5 vegne af Henning Rogge > Sendt: ti 26-01-2010 20:25 > Til: roll@ietf.org > Cc: roll-bounces@ietf.org > Emne: Re: [Roll] Reactive versus Proactive approaches Re: RPL =20 > Simulation in the home > > Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > > Hey Don, > > > > I guess I miss your point. If we use the proactive model then for =20= > a 1000 > > node LLN, each node will have to define and maintain routes to 999 =20= > other > > nodes on the oft chance that a message needs to be sent to any =20 > random node > > on the LLN. This seems way less scalable than keeping a 'least =20 > recently > > used' list of links that the node has needed to communicate to in =20= > the > > recent past. > > > 1000 Nodes is no problem with proactive protocolls. I have yet to see > experiments with 10000 nodes how well AODV does scale (experiments, =20= > not just > simulations). > > Henning Rogge > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-68-690162312 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Anders,

Co-chair "hat on", there are many ways to = solve an issue. As a WG I would just 
suggest to first = make some analysis on whether the current solution does = address
your requirements, which it has to, this is why we = have requirements documents,
without jumping to additional = mechanisms/protocols.

Cheers.

JP.

On Jan 26, 2010, at 9:31 PM, Anders = Brandt wrote:

Henning,
 
The trick is that we can limit the scope.
=
We do not want to scan = the entire Internet.
 
For home and building, a TTL limiting the discovery to 4 = repeater nodes would do the work.
Combine this with a dampening function which = prevents repeaters from forwarding discovery messages if n other = repeaters within direct reach already forwarded the same message and = your broadcast storm is converted to a controlled wavefront forming = a circle outwards.
Piggyback the "Light on" command on the discovery message = and your latency is drastically reduced.
Finally, let the Discovery = result message kill all pending discovery messages scheduled for later = transmission.
 
As Jerry said, cache the discovered route and use it = the next time.
 
Individually very simple mechanisms. Together, extremely = efficient.
 
I may add that this runs in the real world.
=
 
=
Cheers,
=
  = Anders.

= Fra: roll-bounces@ietf.org p=E5 = vegne af Henning Rogge
Sendt: ti 26-01-2010 = 20:25
Til: roll@ietf.org
Cc: roll-bounces@ietf.org
Emne= : Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation = in the home

Am Dienstag 26 = Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com:> Hey Don,
>
> I guess I miss your point.  If we = use the proactive model then for a 1000
> node LLN, each node will = have to define and maintain routes to 999 other
> nodes on the oft = chance that a message needs to be sent to any random node
> on the = LLN.  This seems way less scalable than keeping a 'least = recently
> used' list of links that the node has needed to = communicate to in the
> recent past.


1000 Nodes is no problem with proactive protocolls. I = have yet to see
experiments with 10000 nodes how well AODV does scale = (experiments, not just
simulations).

Henning = Rogge

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

= --Apple-Mail-68-690162312-- From jvasseur@cisco.com Wed Jan 27 15:07:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EB43A635F; Wed, 27 Jan 2010 15:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVDIskjpA0La; Wed, 27 Jan 2010 15:07:32 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AABFA28C0E9; Wed, 27 Jan 2010 15:07:31 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAJdWYEtAZnwN/2dsb2JhbAA8wQCXKoQ5BA X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="82558575" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2010 23:07:34 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.189]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN7YQd015752; Wed, 27 Jan 2010 23:07:34 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:34 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:33 -0600 Message-Id: From: JP Vasseur To: d.sturek@att.net In-Reply-To: <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:19:16 +0100 References: <201001262025.17833.hrogge@googlemail.com> <028c01ca9ec9$7d68dd80$783a9880$@sturek@att.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:34.0285 (UTC) FILETIME=[82973BD0:01CA9FA5] Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:33 -0000 On Jan 26, 2010, at 9:52 PM, Don Sturek wrote: > Hi Henning, > > I think 1000 nodes in AODV is no problem if you know in advance you > are > dealing with a 1000 node deployment. > > The trouble comes when you size for something significantly > different from > 1000..... > > This is why I really liked the DAG in ROLL RPL. No matter how many > devices > are part of the network, the resource requirements are the same. > The trick > is to figure out how to deal with routing failures in the DAG now > such that > we don't lose low latency for applications like building automation. > Precisely. This is why we will have applicability statements. Cheers. JP. > Don > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: Tuesday, January 26, 2010 11:25 AM > To: roll@ietf.org > Cc: Jerald.P.Martocci@jci.com; d.sturek@att.net; 'Mukul Goyal'; > roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation > in the home > > Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: >> Hey Don, >> >> I guess I miss your point. If we use the proactive model then for a >> 1000 node LLN, each node will have to define and maintain routes to >> 999 other nodes on the oft chance that a message needs to be sent to >> any random node on the LLN. This seems way less scalable than >> keeping >> a 'least recently used' list of links that the node has needed to >> communicate to in the recent past. > 1000 Nodes is no problem with proactive protocolls. I have yet to see > experiments with 10000 nodes how well AODV does scale (experiments, > not just > simulations). > > Henning Rogge > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Jan 27 15:07:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C24D28C0EF for ; Wed, 27 Jan 2010 15:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GJSIvFYkjvm for ; Wed, 27 Jan 2010 15:07:31 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8B55228C0E7 for ; Wed, 27 Jan 2010 15:07:29 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAClWYEurRN+K/2dsb2JhbAA8wQWJXY1Ngi2CDAQ X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208,217";a="80026000" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2010 23:07:41 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN7eCK011754; Wed, 27 Jan 2010 23:07:40 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:40 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:38 -0600 Message-Id: <73B4C489-E3C1-4D7F-8C48-389B9124A07F@cisco.com> From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-69-690578702 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:25:03 +0100 References: <1915415853.577721264530147452.JavaMail.root@mail02.pantherlink.uwm.edu> <661715163.578691264530216256.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:39.0317 (UTC) FILETIME=[85970E50:01CA9FA5] Cc: roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:07:34 -0000 --Apple-Mail-69-690578702 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jan 27, 2010, at 12:06 PM, Emmanuel Baccelli wrote: > > I agree with Mukul. To my knowledge, nobody argues with the fact > that RPL proposes an interesting approach to achieve the goal of > northbound communications (from sensors to sink/LBR). The DIO > mechanism described in the spec is relatively understandable, and > though there is limited experience with it so far, one can already > get an idea of what performance/reliability to expect. > > However, the other goals of RPL are unclear, and the mechanisms > proposed in addition to the basic DIO scheme are not straightforward > to grasp or to gauge. This is why we get into muddy debates at this > time. > > This working group has been asked many times to finally agree on an > applicability statement for RPL, that would explicitly enumerate the > goals that RPL is aiming to achieve. > > So in my mind, we should break this debate in two steps: first let's > agree on an applicability statement for RPL. Yes indeed, the one comment I would make is that we need to look at the requirement documents. The applicability statements will be used to document how to use RPL in specific contexts. > Then, if some additional mechanisms are needed to fulfill left out > requirements, let's discuss them in a second phase. > > Honestly, I don't see any other way around if we want a finite > convergence time... > Right. JP. > regards, > > Emmanuel > > > > On Tue, Jan 26, 2010 at 7:23 PM, Mukul Goyal wrote: > Don, > > I think it would be possible to find ways to avoid scaling problems > with reactive route discovery. I suggested one possibility in the > following draft: > > http://tools.ietf.org/html/draft-goyal-roll-dv-01 > > Lets first agree that we do need source-initiated route discovery. > > Thanks > Mukul > > ----- Original Message ----- > From: "Don Sturek" > To: "Jerald P Martocci" , "JP Vasseur" > > Cc: "ROLL WG" , "Mukul Goyal" , roll-bounces@ietf.org > Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada > Central > Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > Hi Jerry, > > > > I think the note below correctly reflects building automation > requirements. Having 1000 devices on a building floor would not be > a surprise. > > > > The trouble with reactive route discovery is many of the existing > MANET protocols like AODV scale with the number of devices in the > network (so have to be tailored by deployment). For example, route > table size is an example of a scaling resource in AODV. I think in > cases where there is a needed reactive route discovery, we need to > identify how to avoid making the solution scale with deployment > while still supporting low latency messaging. > > > > Don > > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Jerald.P.Martocci@jci.com > Sent: Tuesday, January 26, 2010 9:20 AM > To: JP Vasseur > Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if > Anders does not have this requirement for a home, I do have this > requirement for a building. > > 2) My understanding is that for 6LoWPAN networks all devices are on > a flat network (i.e. all LLN nodes have the same prefix) (see RFC > 4944); hence there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is > no a priori way to preselect routes. > > Regards, > > Jerry > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > > 01/26/2010 11:01 AM > > To > > Mukul Goyal > > > cc > > ROLL WG > > > Subject > > Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > > > JP, > > > > The obvious problem with proactive approaches, such as RPL, is the > > need to maintain reachability information for all possible > > destinations to which some source might send a packet some day. > > That's why we need source-initiated route discovery, i.e. a reactive > > approach. > > > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Anders Brandt" > > Cc: "ROLL WG" > > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > > Central > > Subject: Re: [Roll] RPL Simulation in the home > > > > > > Copying the list to continue that discussion - see below > > > > > > > > Anders> > > > > > > > > > > > > > > > > > > > > > > > > Anyway, > > the use case is quite simple: > > > > Z - R1 - R2 - R3 - A > > > > 1) Lamp module A was recently controlled by controller Z via router > > 1 -> router 2 -> router 3 > > > > Z - R1 - R2 - R3 - A > > > > 2) Something renders the radio connection unusable from router 3 to > > lamp module A > > 3) The lamp module can however be reached via router 1 -> router 4 - > > > router 5 > > but router 5 has never been routing traffic to lamp module A > > > > Z - R1 - R2 - R3 - . > > \ > > - R4 - R5 - A > > 4) Controller Z sends another command to lamp module A via router 1 > > 5) Router 1 sends the command to router 2 which forwards the command > > to router 3 > > 6) Router 3 is unable to deliver the command > > > > What happens now? > > > > > > This is exactly why I was asking you the reason why you think that > > it should be reactive. > > What you describe is routing protocol convergence, which of course > > does not imply that the > > protocol should be reactive. This is a typical case where the > > topology is changing and RPL > > needs to adapt to it, which it does. The way to meet your time > > requirements is to adjust > > the RPL parameters to make it quicker to converge. If there is a > > link between A and R5, > > as soon as it becomes operational, A can send a DAO and R1 will > > direct the traffic to R4 > > instead of R2. > > > > > > > > > > Will the lamp go on within 250ms? > > > > > > > > So you raise the issue of convergence time, fair. It all depends on > > how you tune RPL and A > > selects R5 as a new parent. Note that you do not have to keep > > sending control traffic for > > that. If you links are extremely lossy you will have to make the DAG > > fairly reactive, which > > means more control traffic of course. If you are using a reactive > > mechanism instead of > > proactive, this is not a magic solution either since you flood your > > network and add control > > messages too. > > > > > > What I think is that by using these mechanism you can achieve a good > > level of convergence > > time with reasonable traffic in presence of lossy link w/o too much > > control traffic. We can try > > to quantify if you can provide an example topology, few stats on the > > link flaps trying few RPL > > tuning. Could you ? > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > > > > > > > > > Thanks, > > Anders > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Thursday, January 21, 2010 09:11 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > > > > > > Sorry JP > > > > I really have no intention of spreading FUD. > > Guess this mainly indicates that I and Jerry need education of what > > RPL is expected/able to deliver. > > > > At the most recent telecon we again touched the issue of e.g. a lamp > > module which due to rf phenomena > > cannot be reached via the recent router - and I thought we had a > > common understanding that some reactive mechanism > > would be needed. > > > > Can RPL - in its current shape - identify a new route via a router > > which did not previously forward traffic to said lamp module? > > > > > > > > Not sure of what you mean by this ? > > > > > > > > > > I would love that but I need to understand how - and I would love to > > see your evidence! > > > > > > > > Here is what I can propose: could you provide a home network > > topology that I could use to provide > > simulations results ? > > > > > > Cheers. > > > > > > JP. > > > > > > > > > > Thanks, > > Anders > > > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Wednesday, January 20, 2010 18:21 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > > > > > > > > Hi JP > > > >> Are you saying that RPL is not good enough for P2P in home and > >> building? > > > > Well - which incarnation of RPL? (!) > > I was of the impression that we had a common understanding that the > > ability to > > operate in a reactive fasion is critical to home & building and that > > the DAG update > > signaling currently designed will have much bigger delays than the > > 250ms real-time > > users will tolerate. > > > > > > Where does that come from ? > > > > > > > > > > > > > > > >> Since I have evidence that it is not the case. > >> Do you have data that shows different results ? > > > > I may have misunderstood the telecon conclusions, but I got it so > > that over time > > DAG routes will reconstructed, but that the current spec cannot find > > a lost target on demand (?). > > > > > >> Because as you know it is now in our charter to work on other > >> protocols. > > now? I guess you mean "not" ? (!) > > My conclusion from the Rolle interim was that we needed something > > special to find routes across the cloud. > > If the DAG can re-establish contact within 250ms to an operational > > node that was just lost in a routing table, > > I would really love it. Is that the case? > > > > > > mmm I do not think so ... happy to discuss it live with you though. > > > > > > Cheers! > > > > > > JP. > > > > > > > > > > > > > > > > Cheers, > > Anders > > > > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sendt: on 20-01-2010 17:02 > > Til: Anders Brandt > > Emne: Re: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > off-line first. > > > > > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > > > > > > Jerry, > > > >> That was what was nice about an AODV concept, because even route > >> repair was fairly deterministic. > > > > As far as I am informed some reactive discovery mechanism is still > > needed for all the reasons that you list below. > > > > You may remember that we have the same needs in home automation. > > By utilizing the fact that source routing is already used to jump > > between RPL-capable routers AND the fact that the (time critical) > > point-to-point communication is limited to 5 hops or less, some TTL- > > aware, source-route-based AODV hybrid may not cause so > > much flooding as one could fear. > > > > > > > > Are you saying that RPL is not good enough for P2P in home and > > building ? Since I have evidence that it is not the case. > > Do you have data that shows different results ? > > Because as you know it is now in our charter to work on other > > protocols. > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > - Anders > > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > > Behalf Of Jerald.P.Martocci@jci.com > > Sent: Thursday, January 14, 2010 19:11 > > To: Joydeep Tripathi > > Cc: ROLL WG > > Subject: Re: [Roll] RPL Simulation > > > > > > > > Hi Joydeep, > > > > Mukul's been doing some simulations for my company for the past 3 > > years. He has a good handle on the commercial building performance > > requirements. It would be good for you to run those he notes > > below. It might be advantageous then for you two to share the > > results to better correlate the simulations. > > > > I would also look at the latency for P2P messages when the packet(s) > > need to traverse the DAG all the way up to the LBR and back down to > > the destination node. Of course, this is now a function on DAG > > depth. Also since all our messages require ACK, the additional > > latency of the ACK having to return possibly through a different set > > of nodes yet via the LBR. That would be the worst case scenario. > > If other nodes could short circuit the packets through a shorter > > path, that would on;y help. > > > > Since Building systems are real-time (smoke/fire detection, turning > > on lights, etc) latency is a big issue. Moving the packet up and > > down the DAG is reasonably deterministic and should be primarily a > > function of the DAG depth. However, what will really affect the > > system performance is 'DAG Repair'. I have no sense how long a > > packet in transit would have to wait if the DAG was under repair. > > Since we require ACKs of every message, the source node would time- > > out and retry a few times (usually 3). After that, the source node > > would have to fall into some 'failsoft' mode depending on the type > > of data it was trying to access. This is not a good situation. The > > source node can only assume that its data is inaccessible, not just > > held up in transit. The fail-soft mode will have large hysteresis > > since it can't be constantly dithering between modes. This will all > > be logged to the operator which is a bad thing!!! That was what was > > nice about an AODV concept, because even route repair was fairly > > deterministic. > > > > So... if your simulation could measure packet latency as a function > > of DAG repair severity, that would be terrific. > > > > Hope this makes sense. > > > > Jerry > > > > > > > > > > > > > > Mukul Goyal < mukul@uwm.edu > > > > > 01/13/2010 10:17 AM > > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com > > > > > > > Subject Re: [Roll] RPL Simulation > > > > > > > > > > Joydeep > > > > Here are a few suggestions for your simulations: > > > > 1. Simulate a 100 node and a 1000 node topology operating under a > > single DAG > > > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > > the DAG from a source to a destination passes through their closest > > common ancestor) and DAG routes through root (all DAG paths have to > > go through the DAG root). > > > > 3. Study the stretch factor (increase in length/cost of routes over > > the DAG versus the length/cost of ideal routes) for given number of > > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > > number of nodes in the topology: > > a) the scenario you suggested: Choose 20% flows over 2 hop > > neighbors, 10% flows over longer paths. > > b) randomly selected source and destinations (in n*(n-1) case, from > > each possible source node to each possible destination node). > > > > 4. In addition to the stretch factor, calculate/simulate the traffic > > loads as well as packet loss/delay along the DAG links. Compare > > these values against values with ideal P2P routing. > > > > Thanks > > Mukul > > ----- Original Message ----- > > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > > Cc: "ROLL WG" < roll@ietf.org > > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > > Central > > Subject: [Roll] RPL Simulation > > > > Hi, > > > > In the next revision, we are also planning to implement a typical > > building routing scenario, where 60-70% of the P2P traffic are > > confined within 1 hop physical distance and, 20% of the P2P traffic > > are to a 2 -hop distance destination, and observe the performance of > > RPL against the ideal shortest route. Also, please let us know if > > there is any other scenario or traffic pattern you want to be > > implemented. > > > > Thanks, > > Joydeep > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-69-690578702 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jan 27, 2010, = at 12:06 PM, Emmanuel Baccelli wrote:


I agree with Mukul. To my knowledge, nobody = argues with the fact that RPL proposes an interesting approach to = achieve the goal of northbound communications (from sensors to = sink/LBR). The DIO mechanism described in the spec is relatively = understandable, and though there is limited experience with it so far, = one can already get an idea of what performance/reliability to = expect.

However, the other goals of RPL are unclear, = and the mechanisms proposed in addition to the basic DIO scheme are not = straightforward to grasp or to gauge. This is why we get into muddy = debates at this time.

This working group has = been asked many times to finally agree on an applicability statement for = RPL, that would explicitly enumerate the goals that RPL is aiming to = achieve. 

So in my mind, we should break = this debate in two steps: first let's agree on an applicability = statement for RPL.

Yes indeed, = the one comment I would make is that we need to look at the requirement = documents.
The applicability statements will be used to = document how to use RPL in specific contexts.

Then, if some additional mechanisms are needed to = fulfill left out requirements, let's discuss them in a second = phase. 

Honestly, I don't see any other = way around if we want a finite convergence = time...


Right.
<= div>
JP.

regards,

Emmanuel


On Tue, Jan 26, 2010 at = 7:23 PM, Mukul Goyal <mukul@uwm.edu> = wrote:
Don,

I = think it would be possible to find ways to avoid scaling problems with = reactive route discovery. I suggested one possibility in the following = draft:

http://tools.ietf.org/html/draft-goyal-roll-dv-01
Lets first agree that we do need source-initiated route = discovery.

Thanks
Mukul

----- = Original Message -----
From: "Don Sturek" <d.sturek@att.net>
To: = "Jerald P Martocci" <Jerald.P.Martocci@jci.com>= ;, "JP Vasseur" <jvasseur@cisco.com>
Cc: = "ROLL WG" <roll@ietf.org>, = "Mukul Goyal" <mukul@UWM.EDU>, = roll-bounces@ietf.org
= Sent: Tuesday, January 26, 2010 11:47:03 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] Reactive versus Proactive approaches Re: = RPL Simulation     in the home




Hi = Jerry,

 

I think the note below correctly = reflects building automation requirements.   Having 1000 = devices on a building floor would not be a surprise.

 
=
The trouble with reactive route discovery is many of the existing = MANET protocols like AODV scale with the number of devices in the = network (so have to be tailored by deployment).   For example, = route table size is an example of a scaling resource in AODV.  I = think in cases where there is a needed reactive route discovery, we need = to identify how to avoid making the solution scale with deployment while = still supporting low latency messaging.

 

Don
=
 

 


From: = roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On = Behalf Of Jerald.P.Martocci@jci.com
Sent: Tuesday, January 26, 2010 9:20 AM
= To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; roll-bounces@ietf.org
=
Subject: Re: [Roll] Reactive versus = Proactive approaches Re: RPL Simulation in the home

 
=

Hi JP,

My $.02 on your answers:

1) In a = building there may 1000 devices in an LLN; hence even if Anders does not = have this requirement for a home, I do have this requirement for a = building.

2) My understanding is that for 6LoWPAN networks all = devices are on a flat network (i.e. all LLN nodes have the same prefix) = (see RFC 4944); hence there is no way to aggregate routes.

2a) = Source/destination routes are completely random; hence there is no a = priori way to preselect routes.

Regards,

Jerry
=




JP Vasseur <jvasseur@cisco.com>
Sent = by: roll-bounces@ietf.org
=
01/26/2010 11:01 AM

To

Mukul Goyal <mukul@UWM.EDU>


cc
=
ROLL WG <roll@ietf.org>


= Subject

Re: [Roll] Reactive versus Proactive approaches Re: RPL = Simulation        in the home

 
=



Hi Mukul,

On Jan 26, 2010, at 5:30 PM, = Mukul Goyal wrote:

> JP,
>
> The obvious = problem with proactive approaches, such as RPL, is the  
> = need to maintain reachability information for all possible  
= > destinations to which some source might send a packet some day. =  
> That's why we need source-initiated route discovery, = i.e. a reactive  
> approach.
>

Several = answers here:
1) Are there such as huge number of unicast addresses = in a home ?
2) In so, this is where route aggregation/summarization = can help.

This is why I'm challenging the need for an a priori = reactive  
mechanism here before we prove that
reactive is = not good enough.

Makes sense ?

ps: again acting with = no co-chair hat.

Thanks.

JP.

> Thanks
= > Mukul
>
> ----- Original Message -----
> From: = "JP Vasseur" <jvasseur@cisco.com>
> = To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: = "ROLL WG" <roll@ietf.org>
= > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =  
> Central
> Subject: Re: [Roll] RPL Simulation in = the home
>
>
> Copying the list to continue that = discussion - see below
>
>
>
> = Anders>
>
>
>
>
>
>
= >
>
>
>
>
> Anyway,
> the = use case is quite simple:
>
> Z - R1 - R2 - R3 - A
= >
> 1) Lamp module A was recently controlled by controller Z = via router  
> 1 -> router 2 -> router 3
>
= >  Z - R1 - R2 - R3 - A
>
> 2) Something renders = the radio connection unusable from router 3 to  
> lamp = module A
> 3) The lamp module can however be reached via router 1 = -> router 4 -
> > router 5
>    but router = 5 has never been routing traffic to lamp module A
>
> =  Z - R1 - R2 - R3 - .
>        \
= >         - R4 - R5 - A
> 4) Controller Z = sends another command to lamp module A via router 1
> 5) Router 1 = sends the command to router 2 which forwards the command  
> = to router 3
> 6) Router 3 is unable to deliver the command
= >
> What happens now?
>
>
> This is = exactly why I was asking you the reason why you think that  
= > it should be reactive.
> What you describe is routing = protocol convergence, which of course  
> does not imply = that the
> protocol should be reactive. This is a typical case = where the  
> topology is changing and RPL
> needs to = adapt to it, which it does. The way to meet your time  
> = requirements is to adjust
> the RPL parameters to make it quicker = to converge. If there is a  
> link between A and R5,
= > as soon as it becomes operational, A can send a DAO and R1 will =  
> direct the traffic to R4
> instead of R2.
= >
>
>
>
> Will the lamp go on within = 250ms?
>
>
>
> So you raise the issue of = convergence time, fair. It all depends on  
> how you tune = RPL and A
> selects R5 as a new parent. Note that you do not have = to keep  
> sending control traffic for
> that. If = you links are extremely lossy you will have to make the DAG  
= > fairly reactive, which
> means more control traffic of = course. If you are using a reactive  
> mechanism instead = of
> proactive, this is not a magic solution either since you = flood your  
> network and add control
> messages = too.
>
>
> What I think is that by using these = mechanism you can achieve a good  
> level of = convergence
> time with reasonable traffic in presence of lossy = link w/o too much  
> control traffic. We can try
> = to quantify if you can provide an example topology, few stats on the =  
> link flaps trying few RPL
> tuning. Could you = ?
>
>
> Thanks.
>
>
> JP.
= >
>
>
>
>
>
>
>
= >
> Thanks,
>  Anders
>
>
> = From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> = Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
= > Subject: Re: SV: [Roll] RPL Simulation
>
>
> = Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 = AM, Anders Brandt wrote:
>
>
>
>
> = Sorry JP
>
> I really have no intention of spreading = FUD.
> Guess this mainly indicates that I and Jerry need = education of what  
> RPL is expected/able to deliver.
= >
> At the most recent telecon we again touched the issue of = e.g. a lamp  
> module which due to rf phenomena
> = cannot be reached via the recent router - and I thought we had a =  
> common understanding that some reactive mechanism
= > would be needed.
>
> Can RPL - in its current shape - = identify a new route via a router  
> which did not = previously forward traffic to said lamp module?
>
>
= >
> Not sure of what you mean by this ?
>
>
= >
>
> I would love that but I need to understand how - = and I would love to  
> see your evidence!
>
= >
>
> Here is what I can propose: could you provide a = home network  
> topology that I could use to provide
= > simulations results ?
>
>
> Cheers.
= >
>
> JP.
>
>
>
>
> = Thanks,
>  Anders
>
>
>
> From: = JP Vasseur [ mailto:jvasseur@cisco.com ]
> = Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
= > Subject: Re: SV: [Roll] RPL Simulation
>
>
> = Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 = PM, Anders Brandt wrote:
>
>
>
>
= >
>
> Hi JP
>
>> Are you saying that = RPL is not good enough for P2P  in home and  
>> = building?
>
> Well - which incarnation of RPL? (!)
= > I was of the impression that we had a common understanding that the =  
> ability to
> operate in a reactive fasion is = critical to home & building and that  
> the DAG = update
> signaling currently designed will have much bigger = delays than the  
> 250ms real-time
> users will = tolerate.
>
>
> Where does that come from ?
= >
>
>
>
>
>
>
>> = Since I have evidence that it is not the case.
>> Do you have = data that shows different results ?
>
> I may have = misunderstood the telecon conclusions, but I got it so  
> = that over time
> DAG routes will reconstructed, but that the = current spec cannot find  
> a lost target on demand = (?).
>
>
>> Because as you know it is now in our = charter to work on other  
>> protocols.
> now? I = guess you mean "not" ? (!)
> My conclusion from the Rolle interim = was that we needed something  
> special to find routes = across the cloud.
> If the DAG can re-establish contact within = 250ms to an operational  
> node that was just lost in a = routing table,
> I would really love it. Is that the case?
= >
>
> mmm I do not think so ... happy to discuss it = live with you though.
>
>
> Cheers!
>
= >
> JP.
>
>
>
>
>
= >
>
> Cheers,
>  Anders
>
= >
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> = Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: = Re: [Roll] RPL Simulation
>
>
> Hi Anders,
= >
>
> off-line first.
>
>
>
= > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
= >
>
>
> Jerry,
>
>> That was = what was nice about an AODV concept, because even route  
= >> repair was fairly deterministic.
>
> As far as I = am informed some reactive discovery mechanism is still  
> = needed for all the reasons that you list below.
>
> You = may remember that we have the same needs in home automation.
> By = utilizing the fact that source routing is already used to jump =  
> between RPL-capable routers AND the fact that the (time = critical)
> point-to-point communication is limited to 5 hops or = less, some TTL-
> aware, source-route-based AODV hybrid may not = cause so
> much flooding as one could fear.
>
>
= >
> Are you saying that RPL is not good enough for P2P =  in home and  
> building ? Since I have evidence that = it is not the case.
> Do you have data that shows different = results ?
> Because as you know it is now in our charter to work = on other  
> protocols.
>
>
> = Thanks.
>
>
> JP.
>
>
>
= >
>
> - Anders
>
>
>
> = From: roll-bounces@ietf.org = [ mailto:roll-bounces@ietf.org ] On =  
> Behalf Of Jerald.P.Martocci@jci.com > Sent: Thursday, January 14, 2010 19:11
> To: Joydeep = Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL = Simulation
>
>
>
> Hi Joydeep,
>
= > Mukul's been doing some simulations for my company for the past 3 =  
> years.  He has a good handle on the commercial = building performance  
> requirements.  It would be = good for you to run those he notes  
> below.  It might = be advantageous then for you two to share the  
> results to = better correlate the simulations.
>
> I would also look at = the latency for P2P messages when the packet(s)  
> need to = traverse the DAG all the way up to the LBR and back down to  
= > the destination node.  Of course, this is now a function on = DAG  
> depth.  Also since all our messages require = ACK, the additional  
> latency of the ACK having to return = possibly through a different set  
> of nodes yet via the = LBR.  That would be the worst case scenario.  
> If = other nodes could short circuit the packets through a shorter  
= > path, that would on;y help.
>
> Since Building = systems are real-time (smoke/fire detection, turning  
> on = lights, etc) latency is a big issue.  Moving the packet up and =  
> down the DAG is reasonably deterministic and should be = primarily a  
> function of the DAG depth.  However, = what will really affect the  
> system performance is 'DAG = Repair'.  I have no sense how long a  
> packet in = transit would have to wait if the DAG was under repair.  
> = Since we require ACKs of every message, the source node would time-
= > out and retry a few times (usually 3).  After that, the source = node  
> would have to fall into some 'failsoft' mode = depending on the type  
> of data it was trying to access. =  This is not a good situation.  The  
> source = node can only assume that its data is inaccessible, not just  
= > held up in transit.  The fail-soft mode will have large = hysteresis  
> since it can't be constantly dithering = between modes.  This will all  
> be logged to the = operator which is a bad thing!!!  That was what was  
> = nice about an AODV concept, because even route repair was fairly =  
> deterministic.
>
> So... if your = simulation could measure packet latency as a function  
> of = DAG repair severity, that would be terrific.
>
> Hope this = makes sense.
>
> Jerry
>
>
>
> = <ATT129641.jpg>
>
>
> Mukul Goyal < mukul@uwm.edu >
>
> = 01/13/2010 10:17 AM               =    
> To             =      Joydeep Tripathi < joydeep.tripathi@gmail.com = >
>
> cc             =      ROLL WG < roll@ietf.org >, Jerald P Martocci = < Jerald.P.Martocci@jci.com >  >
>
> Subject         =          Re: [Roll] RPL Simulation
> =                  
= >
>
>
> Joydeep
>
> Here are a few = suggestions for your simulations:
>
> 1. Simulate a 100 = node and a 1000 node topology operating under a  
> single = DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie = the path through  
> the DAG from a source to a destination = passes through their closest  
> common ancestor) and DAG = routes through root (all DAG paths have to  
> go through = the DAG root).
>
> 3. Study the stretch factor (increase = in length/cost of routes over  
> the DAG versus the = length/cost of ideal routes) for given number of  
> flows: = 100, 1000, 10000 and possibly n*(n-1) flows (where n is the  
= > number of nodes in the topology:
> a) the scenario you = suggested: Choose 20% flows over 2 hop  
> neighbors, 10% = flows over longer paths.
> b) randomly selected source and = destinations (in n*(n-1) case, from  
> each possible source = node to each possible destination node).
>
> 4. In = addition to the stretch factor, calculate/simulate the traffic =  
> loads as well as packet loss/delay along the DAG links. = Compare  
> these values against values with ideal P2P = routing.
>
> Thanks
> Mukul
> ----- Original = Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com = >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com = >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: = Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada  
= > Central
> Subject: [Roll] RPL Simulation
>
> = Hi,
>
> In the next revision, we are also planning to = implement a typical
> building routing scenario, where 60-70% of = the P2P traffic are
> confined within 1 hop physical distance = and, 20% of the P2P traffic
> are to a 2 -hop distance = destination, and observe the performance of
> RPL against the = ideal shortest route. Also, please let us know if
> there is any = other scenario or traffic pattern you want to be
> = implemented.
>
> Thanks,
> Joydeep
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/mailman/listinfo/roll
= >
> _______________________________________________
> = Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
= >
>
>
>
>
>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
= > https://www.ietf.org/mailman/listinfo/roll
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=

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

= --Apple-Mail-69-690578702-- From jvasseur@cisco.com Wed Jan 27 15:08:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D4628C0E2; Wed, 27 Jan 2010 15:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yFHcQkqEzBZ; Wed, 27 Jan 2010 15:08:17 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CFC0F3A6ACD; Wed, 27 Jan 2010 15:08:08 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAClWYEurRN+K/2dsb2JhbAA8wQWXKoQ5BI1q X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="80025861" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2010 23:07:23 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0RN7ND7011568; Wed, 27 Jan 2010 23:07:23 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:23 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:07:22 -0600 Message-Id: <3ECF3C11-A834-4B01-A1BA-82BBFE5F9F05@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <496706315.659531264535850961.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 18:13:26 +0100 References: <496706315.659531264535850961.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jan 2010 23:07:23.0020 (UTC) FILETIME=[7BE054C0:01CA9FA5] Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Jan 2010 23:08:18 -0000 On Jan 26, 2010, at 8:57 PM, Mukul Goyal wrote: > Henning, > > We clearly do not want a route discovery based on immediate network- > wide broadcast of route request messages (as in AODV). But we could > still come up with a reactive approach that suits the needs of LLNs. but again let's see where we can get with existing mechanisms before jumping to other ones. Makes sense ? Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "Henning Rogge" > To: roll@ietf.org > Cc: "Jerald P Martocci" , "d sturek" >, "Mukul Goyal" , roll-bounces@ietf.org > Sent: Tuesday, January 26, 2010 1:25:11 PM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL > Simulation in the home > > Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: >> Hey Don, >> >> I guess I miss your point. If we use the proactive model then for >> a 1000 >> node LLN, each node will have to define and maintain routes to 999 >> other >> nodes on the oft chance that a message needs to be sent to any >> random node >> on the LLN. This seems way less scalable than keeping a 'least >> recently >> used' list of links that the node has needed to communicate to in the >> recent past. > 1000 Nodes is no problem with proactive protocolls. I have yet to see > experiments with 10000 nodes how well AODV does scale (experiments, > not just > simulations). > > Henning Rogge > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Thu Jan 28 00:16:04 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755D73A68E5 for ; Thu, 28 Jan 2010 00:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-SizY8bx6h8 for ; Thu, 28 Jan 2010 00:16:03 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 69A953A692E for ; Thu, 28 Jan 2010 00:16:02 -0800 (PST) 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_01CA9FF2.2B0D968C" Date: Thu, 28 Jan 2010 09:16:18 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429E15@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home Thread-Index: AcqfpYuPj0zl1Zi0T3q2/9nqtTvI5QASJYVg References: <201001262025.17833.hrogge@googlemail.com> <6D9687E95918C04A8B30A7D6DA805A3E01AD454A@zensys17.zensys.local> From: "Anders Brandt" To: "JP Vasseur" Cc: roll@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Jan 2010 08:16:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9FF2.2B0D968C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP =20 I am still waiting eagerly for the convincing explanation on how RPL in = its current form can guarantee contact to a node within a not only finite but very well-defined short = period of time - a time which is significantly shorter than any reasonable route update interval. Yes, I know you think route diversity is the answer. This in itself = leads to two new questions: =20 1. Will you use link-layer acks to determine that an IP packet was not = delivered? If not - how will you then determine the need for using another = route? If yes - well, then I am happy - I just did not understand that = before now. =20 2. How many routes will you try? Each new routing attempt takes time and still you have no guarantee = that you actually reach the node with the information you have (chosen to have - remember: we = cannot store all neighbors) in your routing tables. =20 Given the issues above, I definitely see the need for a reactive = mechanism as a last resort. I fully agree that it would be nice if trickle-timed updates could do = everything for us everytime. Unfortunately, reality is not always working our way. Home and building = requirements clearly state the need for timely delivery of packets. =20 The notion of a node re-attaching to the DAG is wrong. The node has = never realized that it has lost contact. This sad fact is discovered the very moment when a user presses a button = on a lighting switch. This is not the time to start waiting for DIOs, DAOs and what not. Light has to turn = on deterministically quickly after the button press. Thus the need for the reactive last resort. Simulations are not needed to understand this situation. =20 It is true that reactive mechanisms tend to flood the network. BUT: I described a reactive discovery mechanism in a previous mail. The = intent is to show you that very simple tricks can be used to limit the amount of noise distributed in a = network. It can be scaled. It works with a finite response time. If a working = node is out there, it is found. This is what we need for home & building. A last resort to kick in where = proactiveness cannot deliver. =20 Thanks, Anders =20 ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, January 27, 2010 18:18 To: Anders Brandt Cc: Henning Rogge; roll@ietf.org; roll-bounces@ietf.org Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL = Simulation in the home Hi Anders,=20 Co-chair "hat on", there are many ways to solve an issue. As a WG I = would just=20 suggest to first make some analysis on whether the current solution does = address your requirements, which it has to, this is why we have requirements = documents, without jumping to additional mechanisms/protocols. Cheers. JP. On Jan 26, 2010, at 9:31 PM, Anders Brandt wrote: Henning, =20 The trick is that we can limit the scope. We do not want to scan the entire Internet. =20 For home and building, a TTL limiting the discovery to 4 repeater nodes = would do the work. Combine this with a dampening function which prevents repeaters from = forwarding discovery messages if n other repeaters within direct reach = already forwarded the same message and your broadcast storm is converted = to a controlled wavefront forming a circle outwards. Piggyback the "Light on" command on the discovery message and your = latency is drastically reduced. Finally, let the Discovery result message kill all pending discovery = messages scheduled for later transmission. =20 As Jerry said, cache the discovered route and use it the next time. =20 Individually very simple mechanisms. Together, extremely efficient. =20 I may add that this runs in the real world. =20 Cheers, Anders. ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Henning Rogge Sendt: ti 26-01-2010 20:25 Til: roll@ietf.org Cc: roll-bounces@ietf.org Emne: Re: [Roll] Reactive versus Proactive approaches Re: RPL = Simulation in the home =09 =09 Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com: > Hey Don, > > I guess I miss your point. If we use the proactive model then for a = 1000 > node LLN, each node will have to define and maintain routes to 999 = other > nodes on the oft chance that a message needs to be sent to any random = node > on the LLN. This seems way less scalable than keeping a 'least = recently > used' list of links that the node has needed to communicate to in the > recent past. =09 1000 Nodes is no problem with proactive protocolls. I have yet to see experiments with 10000 nodes how well AODV does scale (experiments, not = just simulations). =09 Henning Rogge =09 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CA9FF2.2B0D968C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP
 
I am still waiting eagerly for the = convincing=20 explanation on how RPL in its current form can = guarantee
contact to a node within a not only finite but = very=20 well-defined short period of time - a time which is
significantly shorter than any reasonable route = update=20 interval.
Yes, I know you think route diversity is the = answer. This=20 in itself leads to two new questions:
 
1. Will you use link-layer acks to determine = that an IP=20 packet was not delivered?
    If not - how will = you then=20 determine the need for using another route?
    If yes - well, then I am = happy - I just=20 did not understand that before now.
 
2. How many routes will you = try?
   Each new routing attempt takes = time and still=20 you have no guarantee that you actually reach the
   node = with the=20 information you have (chosen to have - remember: we cannot store all=20 neighbors)
   in your routing tables.
 
Given the issues above, I definitely see the = need for a=20 reactive mechanism as a last resort.
I fully agree that it would be nice if = trickle-timed=20 updates could do everything for us everytime.
Unfortunately, reality is not always working = our way. Home=20 and building requirements clearly state the
need for timely delivery = of=20 packets.
 
The notion of a node re-attaching to the DAG is = wrong. The=20 node has never realized that it has lost contact.
This sad fact is discovered the very moment = when a user=20 presses a button on a lighting switch. This is not
the time to start = waiting=20 for DIOs, DAOs and what not. Light has to turn on deterministically = quickly=20 after the
button press. Thus the need for the = reactive last=20 resort.
Simulations are not needed to understand this=20 situation.
 
It is true that reactive mechanisms tend to = flood the=20 network. BUT:
I described a reactive discovery mechanism in a = previous=20 mail. The intent is to show you that very=20 simple
tricks can be used to limit the amount of noise = distributed=20 in a network.
It can be scaled. It works with a finite = response time.=20 If a=20 working node is out there, it is = found.
This is what = we need for=20 home & building. A last resort to kick in where proactiveness = cannot=20 deliver.
 
Thanks,
 =20 Anders
 

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Wednesday, January 27, 2010 18:18
To: Anders=20 Brandt
Cc: Henning Rogge; roll@ietf.org;=20 roll-bounces@ietf.org
Subject: Re: [Roll] Reactive versus = Proactive=20 approaches Re: RPL Simulation in the home

Hi Anders,

Co-chair "hat on", there are many ways to solve an issue. As a WG I = would=20 just 
suggest to first make some analysis on whether the current solution = does=20 address
your requirements, which it has to, this is why we have = requirements=20 documents,
without jumping to additional mechanisms/protocols.

Cheers.

JP.

On Jan 26, 2010, at 9:31 PM, Anders Brandt wrote:
Henning,
 
The trick is that we can = limit the=20 scope.
We do not want to scan the = entire=20 Internet.
 
For home and building, a = TTL limiting the=20 discovery to 4 repeater nodes would do the work.
Combine this with a = dampening function=20 which prevents repeaters from forwarding discovery messages if n other = repeaters within direct reach already forwarded the same message and = your=20 broadcast storm is converted to a controlled wavefront forming a = circle=20 outwards.
Piggyback the "Light on" = command on the=20 discovery message and your latency is drastically = reduced.
Finally, let the Discovery = result message=20 kill all pending discovery messages scheduled for later=20 transmission.
 
As Jerry said, cache the = discovered=20 route and use it the next time.
 
Individually very simple = mechanisms.=20 Together, extremely efficient.
 
I may add that this runs in = the real=20 world.
 
Cheers,
  = Anders.

Fra: roll-bounces@ietf.org p=E5 = vegne af=20 Henning Rogge
Sendt: ti 26-01-2010 20:25
Til: roll@ietf.org
Cc: roll-bounces@ietf.org
Emn= e:=20 Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in = the=20 home

Am Dienstag 26 Januar 2010 20:20:39 schrieb Jerald.P.Martocci@jci.com:<= BR>>=20 Hey Don,
>
> I guess I miss your point.  If we use = the=20 proactive model then for a 1000
> node LLN, each node will have = to=20 define and maintain routes to 999 other
> nodes on the oft = chance that a=20 message needs to be sent to any random node
> on the LLN.  = This=20 seems way less scalable than keeping a 'least recently
> used' = list of=20 links that the node has needed to communicate to in the
> recent = past.


1000 Nodes is no problem with proactive = protocolls. I have=20 yet to see
experiments with 10000 nodes how well AODV does scale=20 (experiments, not just
simulations).

Henning=20 Rogge

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

------_=_NextPart_001_01CA9FF2.2B0D968C-- From jreddy@ti.com Thu Jan 28 09:30:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFAE3A6941 for ; Thu, 28 Jan 2010 09:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vYdhwlcnxLY for ; Thu, 28 Jan 2010 09:30:43 -0800 (PST) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id F0C163A6AA0 for ; Thu, 28 Jan 2010 09:30:42 -0800 (PST) Received: from dlep35.itg.ti.com ([157.170.170.118]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id o0SHV0eN003715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jan 2010 11:31:01 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id o0SHV0CJ015450 for ; Thu, 28 Jan 2010 11:31:00 -0600 (CST) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o0SHV0GW028355 for ; Thu, 28 Jan 2010 11:31:00 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Thu, 28 Jan 2010 11:31:00 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Thu, 28 Jan 2010 11:30:57 -0600 Thread-Topic: [Roll] Reactive versus Proactive approaches Re: RPL Thread-Index: AcqfpY1z29lFg3FNQgSFRcUHu0vqkQAmWTTw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:30:48 -0000 Hi JP, I agree that proactive routing does not necessarily mean larger delays in s= etting up a route. However, it usually has a larger delay in "detecting" a= route failure.=20 In most situations, a link failure is usually detected first on the sender = side. So I think having a discovery/recovery mechansim that can be initiate= d by the source device is necessary to meet the latency requirements for th= e more demanding applications ( like lighting etc. ) -Regards, Joseph >>Message: 2 >>Date: Wed, 27 Jan 2010 18:09:46 +0100 >>From: JP Vasseur >>Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL >> Simulation in the home >>To: Mukul Goyal >>Cc: ROLL WG >>Message-ID: <43A8B57E-0DDF-42C3-A9C6-C2971F7F065F@cisco.com> >>Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; delsp=3Dye= s >> >>Hi Mukul, >> >>On Jan 26, 2010, at 7:23 PM, Mukul Goyal wrote: >> >>> Don, >>> >>> I think it would be possible to find ways to avoid scaling problems=20 >>> with reactive route discovery. I suggested one possibility in the=20 >>> following draft: >>> >>> http://tools.ietf.org/html/draft-goyal-roll-dv-01 >>> >>> Lets first agree that we do need source-initiated route discovery. >>> >> >>Again, co-chair hat off. You're right that we first need to=20 >>agree that there is a need for a reactive mechanism. >> >>Pro-active routing does not imply high delays to discover how=20 >>to reach a node after a topology change (node moving,=20 >>failures, ...). What we need to explore is how RPL can be=20 >>used to achieve the target in term of performance in light of=20 >>the numbers spelled out in the requirement documents. >>Few possibilities are: >> o Tune the RPL parameters to join the DAG faster,=20 >>and/or increase the degree of meshing (so as to get diverse path) >> to quickly recover connectivity >> o Trigger quick DAO refresh after connectivity loss to=20 >>refresh the states (need to be discussed once the DAO mechanisms >> will have been stabilized. It is a sort of=20 >>"reactive" mechanisms to speed up the whole process. >>In all cases, this means more control messages (regardless of the >>protocols) and must be well understood according to the context. >> >>Thanks. >> >>JP. >> >>> Thanks >>> Mukul >>> From jvasseur@cisco.com Thu Jan 28 10:12:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738BD3A6967 for ; Thu, 28 Jan 2010 10:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd7wsPg0A0T7 for ; Thu, 28 Jan 2010 10:12:26 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 17C563A6800 for ; Thu, 28 Jan 2010 10:12:25 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAANiYUuQ/uCWe2dsb2JhbACbSgEBFiQGpmGXNYQ8BA X-IronPort-AV: E=Sophos;i="4.49,361,1262563200"; d="scan'208";a="56586972" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2010 18:12:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0SICgp1013071; Thu, 28 Jan 2010 18:12:43 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 19:12:02 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 19:12:01 +0100 Message-Id: From: JP Vasseur To: "Reddy, Joseph" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 19:12:00 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Jan 2010 18:12:01.0845 (UTC) FILETIME=[63A55E50:01CAA045] Cc: "roll@ietf.org" Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:12:36 -0000 Hi Joseph, On Jan 28, 2010, at 6:30 PM, Reddy, Joseph wrote: > > Hi JP, > > I agree that proactive routing does not necessarily mean larger > delays in setting up a route. However, it usually has a larger > delay in "detecting" a route failure. > Well one can show tons of situations where it is in fact the opposite. In these networks you could even repair the route before you even need it, thus avoiding to find a new path when you need it and loose time (=> increased delays). > In most situations, a link failure is usually detected first on the > sender side. So I think having a discovery/recovery mechansim that > can be initiated by the source device is necessary to meet the > latency requirements for the more demanding applications ( like > lighting etc. ) > This is what we need to show, which should not be too difficult using few representative examples. Note that we *may* need to tune RPL, add some reactiveness if/where needed of course. Cheers. JP. > -Regards, Joseph > > >>> Message: 2 >>> Date: Wed, 27 Jan 2010 18:09:46 +0100 >>> From: JP Vasseur >>> Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL >>> Simulation in the home >>> To: Mukul Goyal >>> Cc: ROLL WG >>> Message-ID: <43A8B57E-0DDF-42C3-A9C6-C2971F7F065F@cisco.com> >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >>> Hi Mukul, >>> >>> On Jan 26, 2010, at 7:23 PM, Mukul Goyal wrote: >>> >>>> Don, >>>> >>>> I think it would be possible to find ways to avoid scaling problems >>>> with reactive route discovery. I suggested one possibility in the >>>> following draft: >>>> >>>> http://tools.ietf.org/html/draft-goyal-roll-dv-01 >>>> >>>> Lets first agree that we do need source-initiated route discovery. >>>> >>> >>> Again, co-chair hat off. You're right that we first need to >>> agree that there is a need for a reactive mechanism. >>> >>> Pro-active routing does not imply high delays to discover how >>> to reach a node after a topology change (node moving, >>> failures, ...). What we need to explore is how RPL can be >>> used to achieve the target in term of performance in light of >>> the numbers spelled out in the requirement documents. >>> Few possibilities are: >>> o Tune the RPL parameters to join the DAG faster, >>> and/or increase the degree of meshing (so as to get diverse path) >>> to quickly recover connectivity >>> o Trigger quick DAO refresh after connectivity loss to >>> refresh the states (need to be discussed once the DAO mechanisms >>> will have been stabilized. It is a sort of >>> "reactive" mechanisms to speed up the whole process. >>> In all cases, this means more control messages (regardless of the >>> protocols) and must be well understood according to the context. >>> >>> Thanks. >>> >>> JP. >>> >>>> Thanks >>>> Mukul >>>> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From hrogge@googlemail.com Thu Jan 28 10:18:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56773A6803 for ; Thu, 28 Jan 2010 10:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g0f2n28mE5i for ; Thu, 28 Jan 2010 10:18:06 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id AE8BA3A6838 for ; Thu, 28 Jan 2010 10:18:05 -0800 (PST) Received: by ewy8 with SMTP id 8so1041590ewy.29 for ; Thu, 28 Jan 2010 10:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=XA2z/NlnN013Z2StH7IFpCm/KPrOJfxV77syeSzuxf0=; b=x6b2Lz2LuNypPHBjkrJD99mTicBBd3UUu1vOm+c1JkqeSEhrUaASXuFDkZNdCz/oa/ WPduMUs+yopDsUIJ/8NPmE1QryZ0JAy8qILvw0qq6cRAAOOnuoz1a5vxrFaSpHZlOpIp gga8Z+6r3emodpCe21snBOhTHiI+Mbg56t6OM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=XiKTa/An8akpHiaLtOq56wlEoriuKDSEFaDCEnwe/2GQeT8UpulMmMqM+UVFQvBTRE SiPRbglOFrxLGrAUvuhCl1oHym0W+wVsj/KWITlLmM/YL3FCE6nfva7ghu0uOdQXLHLZ bHP8MuAn1lyKZr7mbfdBhocAE/V1GnSZx6IjI= Received: by 10.213.37.206 with SMTP id y14mr3855251ebd.4.1264702701537; Thu, 28 Jan 2010 10:18:21 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 14sm799319ewy.15.2010.01.28.10.18.19 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 10:18:20 -0800 (PST) From: Henning Rogge To: roll@ietf.org Date: Thu, 28 Jan 2010 19:18:05 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.32-gentoo-r2; KDE/4.3.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2131984.xOnERLo3S4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001281918.09397.hrogge@googlemail.com> Cc: "Reddy, Joseph" Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:18:07 -0000 --nextPart2131984.xOnERLo3S4 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 28 Januar 2010 18:30:57 schrieb Reddy, Joseph: > Hi JP, >=20 > I agree that proactive routing does not necessarily mean larger delays in > setting up a route. However, it usually has a larger delay in "detectin= g" > a route failure. I think you got it the wrong way. A reactive protocol does not recognize a route failure (or a bad route) unt= il=20 traffic is sent over this route. A proactive protocol can (as the name says= )=20 detect this on it's own and repair the situation before traffic is lost. Typically reactive protocolls have a HUGE delay for the first traffic to a= =20 destination because they have to discover the route first. Proactive protoc= ols=20 don't have this problem. Henning Rogge --nextPart2131984.xOnERLo3S4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkth1OEACgkQcenvcwAcHWdiFACfa7PS1CXoGu6SNlrTNSHv7VqZ L3QAoIiKEwcqXgkLftMhMOTJehZ4Gidf =sqvV -----END PGP SIGNATURE----- --nextPart2131984.xOnERLo3S4-- From jvasseur@cisco.com Thu Jan 28 11:46:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDC03A68AB for ; Thu, 28 Jan 2010 11:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=-3.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4A2ER74TO7B for ; Thu, 28 Jan 2010 11:46:56 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1BFE13A689A for ; Thu, 28 Jan 2010 11:46:54 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAMN4YUuQ/uCWe2dsb2JhbACbSgEBFiQGpkSXNIQ8BA X-IronPort-AV: E=Sophos;i="4.49,362,1262563200"; d="scan'208";a="2872536" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 28 Jan 2010 19:17:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0SJlCn2025150; Thu, 28 Jan 2010 19:47:12 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 20:47:11 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 20:47:11 +0100 Message-Id: From: JP Vasseur To: ROLL WG , Pascal Thubert Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 20:47:10 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Jan 2010 19:47:11.0422 (UTC) FILETIME=[AED1ADE0:01CAA052] Subject: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Jan 2010 19:46:56 -0000 Dear all, Some of you expressed some concerns about IPR on RPL, more specifically, http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html Pascal Thubert, since you are the closest to this issue, could you please shed some light on the IPR statement for that invention ? Thanks. JP. From root@core3.amsl.com Thu Jan 28 12:30:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E469C3A695B; Thu, 28 Jan 2010 12:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100128203001.E469C3A695B@core3.amsl.com> Date: Thu, 28 Jan 2010 12:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-09.txt Pages : 26 Date : 2010-01-28 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-28122559.I-D@ietf.org> --NextPart-- From pthubert@cisco.com Fri Jan 29 01:51:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5359D3A6938 for ; Fri, 29 Jan 2010 01:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCT72r1DLnlX for ; Fri, 29 Jan 2010 01:51:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 104C23A6820 for ; Fri, 29 Jan 2010 01:51:22 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAAFI+YkuQ/uCWe2dsb2JhbACbSgEBFiQGpzOXV4RABA X-IronPort-AV: E=Sophos;i="4.49,367,1262563200"; d="scan'208";a="56603566" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2010 09:51:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0T9phcf027766 for ; Fri, 29 Jan 2010 09:51:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 10:51:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 10:51:43 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0123536A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPR issue Thread-Index: AcqgUrf0pZxpsR3gSe+vE7B8IFjiVAAatrLg References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 29 Jan 2010 09:51:43.0396 (UTC) FILETIME=[A9AB4E40:01CAA0C8] Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 09:51:24 -0000 Hi JP, Cisco announced IPR that might relate to the RPL work to the ROLL ML http://www.ietf.org/mail-archive/web/roll/current/msg01181.html on April 16th. As we exposed that IPR prior to the actual work, we decided to be very open and announced a rather broad list of publications at that time. Since then, the Cisco IPR issue had been discussed a number of times in this Mailing List. I never sensed a huge problem with it so far. This did not strike me as a surprise considering Cisco's terms. As I had mentioned before, Cisco's terms are quite generous. In layman's terms, Cisco will not sue anyone for products that implement the standard under any of its essential patents, and reserves the right to defend itself if someone sues Cisco for patent infringement. I believe this is essentially similar to a royalty-free license. (I'm an Engineer, not a Lawyer, so I'd encourage people in this group interested in the terms to see the exact language for themselves: http://www.ietf.org/ietf-ftp/IPR/cisco-ipr-draft-dt-roll-rpl-01.txt). =20 Given that Cisco is currently the only one who has filed an IPR declaration here, I don't understand those who are arguing that changing course now, and possibly subjecting the standard to other IPR licensing commitments that are not royalty-free, is a good thing for the WG. Moreover, numerous IETF standards have thrived with similar declarations without creating IPR problems. I trust that the breadth of Cisco's commitment will give everyone enough comfort to move past this issue. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: jeudi 28 janvier 2010 20:47 To: ROLL WG; Pascal Thubert Subject: [Roll] IPR issue Dear all, Some of you expressed some concerns about IPR on RPL, more specifically, http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html Pascal Thubert, since you are the closest to this issue, could you =20 please shed some light on the IPR statement for that invention ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Jan 29 05:52:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B793A69F8 for ; Fri, 29 Jan 2010 05:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNA9jVx2sc9z for ; Fri, 29 Jan 2010 05:52:22 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 48E273A690E for ; Fri, 29 Jan 2010 05:52:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0TDqcYP029038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 14:52:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0TDqcRe010193; Fri, 29 Jan 2010 14:52:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0TDqakM006197; Fri, 29 Jan 2010 14:52:38 +0100 Message-ID: <4B62E823.2030108@gmail.com> Date: Fri, 29 Jan 2010 14:52:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 13:52:23 -0000 JP, Thank for this note. Please help us understand _who_ is 'RAV' - the anonymous poster with address ietfroll@yahoo.com, who posted recently about IPR and ROLL. This helps better understand what's going on with IPR and RoLL. Alex Le 28/01/2010 20:47, JP Vasseur a écrit : > Dear all, > > Some of you expressed some concerns about IPR on RPL, more > specifically, > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > > Pascal Thubert, since you are the closest to this issue, could you > please shed some light on the IPR statement for that invention ? > > Thanks. > > JP. > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Jan 29 06:10:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2853A6A72 for ; Fri, 29 Jan 2010 06:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0VAk-yQ+Q4C for ; Fri, 29 Jan 2010 06:10:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 0773C3A6A6C for ; Fri, 29 Jan 2010 06:10:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0TEB0CS013213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 15:11:00 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0TEB0hC016793; Fri, 29 Jan 2010 15:11:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0TEAvhO013469; Fri, 29 Jan 2010 15:10:59 +0100 Message-ID: <4B62EC71.50408@gmail.com> Date: Fri, 29 Jan 2010 15:10:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D0123536A@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0123536A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 14:10:45 -0000 Pascal, thank you for this reply. I have some comments to your comments, see below. Le 29/01/2010 10:51, Pascal Thubert (pthubert) a écrit : > Hi JP, > > Cisco announced IPR that might relate to the RPL work to the ROLL ML > http://www.ietf.org/mail-archive/web/roll/current/msg01181.html on > April 16th. As we exposed that IPR prior to the actual work, we > decided to be very open and announced a rather broad list of > publications at that time. Since then, the Cisco IPR issue had been > discussed a number of times in this Mailing List. I never sensed a > huge problem with it so far. This did not strike me as a surprise > considering Cisco's terms. Well, I saw usually problems come up when document is in final stages and go to implementer ask to implement. Implementer then goes to open source communities and ask around and open source community asks back about IPR. Which then often stales with high-profile complaints about IPR and technology - it doesn't get implemented. > As I had mentioned before, Cisco's terms are quite generous. In > layman's terms, Cisco will not sue anyone for products that implement > the standard under any of its essential patents, and reserves the > right to defend itself if someone sues Cisco for patent > infringement. Well yes. I also consider generally that Cisco's IPR terms at IETF are ok with me. However, here we had 'RAV' asking this: "There is a free license to use the patent in RPL so long as you and your company doesn't sue Cisco over ANY other patent for ANYTHING." This means that if my company wants to implement _only_ RPL then my company has to not sue Cisco about, for example, the name "iPhone". Which may mean big trouble. In this context, what do you Pascal think about the question 'Rav' raised? Do you think s/he's right to worry that Cisco's free license implies a company engages too broadly to not sue Cisco? Or do you think a company has no reason to worry? > I believe this is essentially similar to a royalty-free license. (I'm > an Engineer, not a Lawyer, so I'd encourage people in this group > interested in the terms to see the exact language for themselves: > http://www.ietf.org/ietf-ftp/IPR/cisco-ipr-draft-dt-roll-rpl-01.txt). Me > too I am engineer not a lawyer. As an engineer, could you please identify the parts in RPL on which your employer's lawyers may claim IPR? For example - is section 6.3.1 "DAG Discovery Rules" covered by Cisco IPR? Is it not? Thanks. > Given that Cisco is currently the only one who has filed an IPR > declaration here, I don't understand those who are arguing that > changing course now, and possibly subjecting the standard to other > IPR licensing commitments that are not royalty-free, is a good thing > for the WG. Hmmm... I maintain that several IPR from several companies is better than a single IPR from a single company who BTW happens to be employing both a co-Chair and a main DT contributor and, err, some ADs maybe. Royalties are and money are not the only aspect of IPR. Names like "iPhone" are fundamental too, because they mean sentiments and money in the end. > Moreover, numerous IETF standards have thrived with similar > declarations without creating IPR problems. No no, very unsure about this. E.g. GRE did not thrive; I think it is so because it was exclusively Cisco. > I trust that the breadth of Cisco's commitment will give everyone > enough comfort to move past this issue. PErsonally, I do not have an IPR stake in this. I am an outsider. I do appreciate Cisco documents and the usual Cisco RAND. However, in this case I need to make sure this gets implemented and it doesn't get blocked. The way to help with this is if someone else than Cisco had some IPR claims on this, and that there was competition. Other ways to deal with this (eliminate the IPR-contaminated/tainted parts, or other) may exist. I am not sure what you people want to do, Alex > > Cheers, > > Pascal > > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) > Sent: jeudi 28 janvier 2010 20:47 To: ROLL WG; Pascal Thubert > Subject: [Roll] IPR issue > > Dear all, > > Some of you expressed some concerns about IPR on RPL, more > specifically, > http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html > > > > > Pascal Thubert, since you are the closest to this issue, could you > please shed some light on the IPR statement for that invention ? > > Thanks. > > JP. > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Jan 29 09:37:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA5C3A67D3 for ; Fri, 29 Jan 2010 09:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.327 X-Spam-Level: X-Spam-Status: No, score=-9.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBfI-ACg7H9M for ; Fri, 29 Jan 2010 09:37:04 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 09EA73A6901 for ; Fri, 29 Jan 2010 09:37:03 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsAAE6rYkuQ/uCWe2dsb2JhbACPM4wVAQEWJAamXZdehEIE X-IronPort-AV: E=Sophos;i="4.49,369,1262563200"; d="scan'208";a="56621989" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2010 17:37:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0THbPLW002718; Fri, 29 Jan 2010 17:37:25 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 18:37:25 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 18:37:24 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4B62E823.2030108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 18:37:23 +0100 References: <4B62E823.2030108@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Jan 2010 17:37:24.0793 (UTC) FILETIME=[B80A2290:01CAA109] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17162.000 X-TM-AS-Result: No--13.589700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 17:37:05 -0000 Dear Alex, On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: > JP, > > Thank for this note. > > Please help us understand _who_ is 'RAV' - the anonymous poster with > address ietfroll@yahoo.com, who posted recently about IPR and ROLL. > > This helps better understand what's going on with IPR and RoLL. > unfortunately I cannot tell you ... Just don't know. Thanks, JP. > Alex > > Le 28/01/2010 20:47, JP Vasseur a =E9crit : >> Dear all, >> >> Some of you expressed some concerns about IPR on RPL, more >> specifically, >> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >> >> >> > Pascal Thubert, since you are the closest to this issue, could you >> please shed some light on the IPR statement for that invention ? >> >> Thanks. >> >> JP. >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > From alexandru.petrescu@gmail.com Fri Jan 29 10:00:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3833A67DA for ; Fri, 29 Jan 2010 10:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4t1tMlP3PPK for ; Fri, 29 Jan 2010 10:00:32 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 90B543A6452 for ; Fri, 29 Jan 2010 10:00:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0TI0pkS016342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 19:00:51 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0TI0obr013750; Fri, 29 Jan 2010 19:00:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0TI0oM3000982; Fri, 29 Jan 2010 19:00:50 +0100 Message-ID: <4B632252.3070602@gmail.com> Date: Fri, 29 Jan 2010 19:00:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: JP Vasseur References: <4B62E823.2030108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 18:00:33 -0000 Dear JP, Do you tolerate unidentified comments happening in this group? Is this serious? Alex Le 29/01/2010 18:37, JP Vasseur a écrit : > Dear Alex, > > On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: > >> JP, >> >> Thank for this note. >> >> Please help us understand _who_ is 'RAV' - the anonymous poster >> with address ietfroll@yahoo.com, who posted recently about IPR and >> ROLL. >> >> This helps better understand what's going on with IPR and RoLL. >> > > unfortunately I cannot tell you ... Just don't know. > > Thanks, > > JP. > >> Alex >> >> Le 28/01/2010 20:47, JP Vasseur a écrit : >>> Dear all, >>> >>> Some of you expressed some concerns about IPR on RPL, more >>> specifically, >>> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>> >>> >>> >> >>> >>> >>> Pascal Thubert, since you are the closest to this issue, could you >>> please shed some light on the IPR statement for that invention ? >>> >>> Thanks. >>> >>> JP. >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> > > From jvasseur@cisco.com Fri Jan 29 10:08:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C4B3A67B6 for ; Fri, 29 Jan 2010 10:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.486 X-Spam-Level: X-Spam-Status: No, score=-9.486 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGzn8nXF9GYz for ; Fri, 29 Jan 2010 10:08:11 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 25E233A659C for ; Fri, 29 Jan 2010 10:08:10 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAIOzYkuQ/uCWe2dsb2JhbACBbY1GjBUBARYkBqZ/l2KEQgQ X-IronPort-AV: E=Sophos;i="4.49,369,1262563200"; d="scan'208,217";a="56622985" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2010 18:08:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0TI8SUl009008; Fri, 29 Jan 2010 18:08:28 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 19:08:28 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 19:08:27 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4B632252.3070602@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-157-865981580 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 19:08:26 +0100 References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Jan 2010 18:08:27.0824 (UTC) FILETIME=[0E7E1B00:01CAA10E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17162.001 X-TM-AS-Result: No--15.778300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 18:08:13 -0000 --Apple-Mail-157-865981580 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Alex, On Jan 29, 2010, at 7:00 PM, Alexandru Petrescu wrote: > Dear JP, > > Do you tolerate unidentified comments happening in this group? > As pointed out in the IETF guidelines: Participation in the IETF or of its WGs is not fee-based or =20 organizationally defined, but is based upon self-identification and =20 active participation by individuals. Cheers. JP. > Is this serious? > > Alex > > Le 29/01/2010 18:37, JP Vasseur a =E9crit : >> Dear Alex, >> >> On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: >> >>> JP, >>> >>> Thank for this note. >>> >>> Please help us understand _who_ is 'RAV' - the anonymous poster >>> with address ietfroll@yahoo.com, who posted recently about IPR and >>> ROLL. >>> >>> This helps better understand what's going on with IPR and RoLL. >>> >> >> unfortunately I cannot tell you ... Just don't know. >> >> Thanks, >> >> JP. >> >>> Alex >>> >>> Le 28/01/2010 20:47, JP Vasseur a =E9crit : >>>> Dear all, >>>> >>>> Some of you expressed some concerns about IPR on RPL, more >>>> specifically, >>>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>>> >>>> >>>> >>> >>>> >>>> >>>> > Pascal Thubert, since you are the closest to this issue, could you >>>> please shed some light on the IPR statement for that invention ? >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> >> >> > > --Apple-Mail-157-865981580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

On = Jan 29, 2010, at 7:00 PM, Alexandru Petrescu wrote:

Dear = JP,

Do you tolerate unidentified comments happening in this = group?


As pointed out in = the IETF guidelines:

Participation in the IETF or = of its WGs is not fee-based or organizationally defined, but is based = upon self-identification and active participation by = individuals.

Cheers.

<= div>JP.

Is this = serious?

Alex

Le 29/01/2010 18:37, JP Vasseur a =E9crit = :
Dear Alex,

On Jan 29, = 2010, at 2:52 PM, Alexandru Petrescu wrote:

JP,

Thank for this = note.

Please help us understand _who_ = is 'RAV' - the anonymous poster
with address ietfroll@yahoo.com, who posted = recently about IPR and
= ROLL.

This helps better understand = what's going on with IPR and = RoLL.


unfortunately I = cannot tell you ... Just don't know.

Thanks,

JP.

Alex

Le 28/01/2010 20:47, JP Vasseur = a =E9crit :
Dear = all,

Some = of you expressed some concerns about IPR on RPL, = more
specifically,
http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.= html







Pascal Thubert, = since you are the closest to this issue, could you
please = shed some light on the IPR statement for that invention = ?

Thanks.

JP.

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








= = --Apple-Mail-157-865981580-- From pthubert@cisco.com Fri Jan 29 10:19:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD6F3A659C for ; Fri, 29 Jan 2010 10:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PSHEWgoOuM3 for ; Fri, 29 Jan 2010 10:19:09 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BFD6B3A6359 for ; Fri, 29 Jan 2010 10:19:08 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJ+1YktAZnwM/2dsb2JhbACPM7M2l2KEQgQ X-IronPort-AV: E=Sophos;i="4.49,370,1262563200"; d="scan'208";a="82939108" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2010 18:19:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0TIJUQ5020202; Fri, 29 Jan 2010 18:19:31 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 19:19:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 19:19:28 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01235730@XMB-AMS-107.cisco.com> In-Reply-To: <4B632252.3070602@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPR issue Thread-Index: AcqhDQm+cRIK++E+SDyRd1aMIG/m1gAANKUA References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 29 Jan 2010 18:19:30.0584 (UTC) FILETIME=[99874180:01CAA10F] Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 18:19:09 -0000 Hi Alex: This is an IETF list, it's open with the reasonable hope that people who = join wish to understand and contribute to the technology. This is not always the case but it usually works. I would not expect = from the chairs or some bigger brother to police every mail that comes = in the list. And it is perfectly acceptable to discuss IPR. You did so = in the past. Since we are at it... As an author of RFC 3963, I trust that you remember that Cisco had IPR = on NEMO too.=20 The terms that were finally used are the same as those that are proposed = here, for all I assert/remember. Since you mention it in your mail, would you think that Cisco IPR had = any counter effect on open source? Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Alexandru Petrescu Sent: vendredi 29 janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal Thubert; ROLL WG Subject: Re: [Roll] IPR issue Dear JP, Do you tolerate unidentified comments happening in this group? Is this serious? Alex Le 29/01/2010 18:37, JP Vasseur a =E9crit : > Dear Alex, > > On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: > >> JP, >> >> Thank for this note. >> >> Please help us understand _who_ is 'RAV' - the anonymous poster >> with address ietfroll@yahoo.com, who posted recently about IPR and >> ROLL. >> >> This helps better understand what's going on with IPR and RoLL. >> > > unfortunately I cannot tell you ... Just don't know. > > Thanks, > > JP. > >> Alex >> >> Le 28/01/2010 20:47, JP Vasseur a =E9crit : >>> Dear all, >>> >>> Some of you expressed some concerns about IPR on RPL, more >>> specifically, >>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>> >>> >>> >> >>> >>> >>> Pascal Thubert, since you are the closest to this issue, could you >>> please shed some light on the IPR statement for that invention ? >>> >>> Thanks. >>> >>> JP. >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jan 29 10:19:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7A03A68B4 for ; Fri, 29 Jan 2010 10:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMA+XYnbPTDa for ; Fri, 29 Jan 2010 10:19:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6BE2D3A6824 for ; Fri, 29 Jan 2010 10:19:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJ+1YktAZnwN/2dsb2JhbACPM7M2l2KEQgQ X-IronPort-AV: E=Sophos;i="4.49,370,1262563200"; d="scan'208";a="82939165" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2010 18:19:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0TIJjBQ014085; Fri, 29 Jan 2010 18:19:45 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 19:19:45 +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, 29 Jan 2010 19:19:35 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> In-Reply-To: <4B632252.3070602@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPR issue Thread-Index: AcqhDQm+cRIK++E+SDyRd1aMIG/m1gAANKUA References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 29 Jan 2010 18:19:45.0240 (UTC) FILETIME=[A2439580:01CAA10F] Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 18:19:23 -0000 Hi Alex: This is an IETF list, it's open with the reasonable hope that people who = join wish to understand and contribute to the technology. This is not always the case but it usually works. I would not expect = from the chairs or some bigger brother to police every mail that comes = in the list. And it is perfectly acceptable to discuss IPR. You did so = in the past. Since we are at it... As an author of RFC 3963, I trust that you remember that Cisco had IPR = on NEMO too.=20 The terms that were finally used are the same as those that are proposed = here, for all I assert/remember. Since you mention it in your mail, would you think that Cisco IPR had = any counter effect on open source? Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Alexandru Petrescu Sent: vendredi 29 janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal Thubert; ROLL WG Subject: Re: [Roll] IPR issue Dear JP, Do you tolerate unidentified comments happening in this group? Is this serious? Alex Le 29/01/2010 18:37, JP Vasseur a =E9crit : > Dear Alex, > > On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: > >> JP, >> >> Thank for this note. >> >> Please help us understand _who_ is 'RAV' - the anonymous poster >> with address ietfroll@yahoo.com, who posted recently about IPR and >> ROLL. >> >> This helps better understand what's going on with IPR and RoLL. >> > > unfortunately I cannot tell you ... Just don't know. > > Thanks, > > JP. > >> Alex >> >> Le 28/01/2010 20:47, JP Vasseur a =E9crit : >>> Dear all, >>> >>> Some of you expressed some concerns about IPR on RPL, more >>> specifically, >>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>> >>> >>> >> >>> >>> >>> Pascal Thubert, since you are the closest to this issue, could you >>> please shed some light on the IPR statement for that invention ? >>> >>> Thanks. >>> >>> JP. >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Jan 29 11:23:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6C23A6838 for ; Fri, 29 Jan 2010 11:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65CKkFak9kDd for ; Fri, 29 Jan 2010 11:23:15 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 283C33A67BD for ; Fri, 29 Jan 2010 11:23:13 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0C180D48156; Fri, 29 Jan 2010 20:23:31 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id B1B93D481A9; Fri, 29 Jan 2010 20:23:28 +0100 (CET) Message-ID: <4B6335AC.4090902@gmail.com> Date: Fri, 29 Jan 2010 20:23:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100129-1, 29/01/2010), Outbound message X-Antivirus-Status: Clean Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Jan 2010 19:23:16 -0000 Le 29/01/2010 19:19, Pascal Thubert (pthubert) a écrit : > Hi Alex: > > This is an IETF list, it's open with the reasonable hope that people > who join wish to understand and contribute to the technology. Yes, open, but there are rules, e.g. RFC2418 at a point: "Moderate the WG email list The Chair should attempt to ensure that the discussions on this list are relevant and that they converge to consensus agreements." > This is not always the case but it usually works. I would not expect > from the chairs or some bigger brother to police every mail that > comes in the list. Hmm, not sure. In netlmm WG there was some unidentified poster at some point who stirred waters about "netlemmings". There was Chair intervention to give guidance. It was reassuring. Regularly on the IETF list we see complaints, procedure, email rights, appeals, etc. > And it is perfectly acceptable to discuss IPR. You did so in the > past. Since we are at it... I am ready to discuss with you about IPR aspects. But the current IPR thread was provoked by we don't know what. It's difficult to continue discussing without doubting it's all bluff (as in poker: deceiving provocation). > As an author of RFC 3963, I trust that you remember that Cisco had > IPR on NEMO too. The terms that were finally used are the same as > those that are proposed here, for all I assert/remember. Since you > mention it in your mail, would you think that Cisco IPR had any > counter effect on open source? Thanks for mentioning it. YEs, we worked together on NEMO and IPR aspects. Cisco's IPR claims on NEMO were ok, but were not the only ones. Nokia's IPR were explicitely geared towards Open Source. I wonder what's the IPR count for OSPF? (how many different companies made IPR claims on it). Anyways, Alex > > Cheers, > > Pascal > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > vendredi 29 janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal > Thubert; ROLL WG Subject: Re: [Roll] IPR issue > > Dear JP, > > Do you tolerate unidentified comments happening in this group? > > Is this serious? > > Alex > > Le 29/01/2010 18:37, JP Vasseur a écrit : >> Dear Alex, >> >> On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: >> >>> JP, >>> >>> Thank for this note. >>> >>> Please help us understand _who_ is 'RAV' - the anonymous poster >>> with address ietfroll@yahoo.com, who posted recently about IPR >>> and ROLL. >>> >>> This helps better understand what's going on with IPR and RoLL. >>> >> >> unfortunately I cannot tell you ... Just don't know. >> >> Thanks, >> >> JP. >> >>> Alex >>> >>> Le 28/01/2010 20:47, JP Vasseur a écrit : >>>> Dear all, >>>> >>>> Some of you expressed some concerns about IPR on RPL, more >>>> specifically, >>>> http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>>> >>>> >>>> >>> >>>> >>>> >>>> > >>>> >>>> >>>> >>>> Pascal Thubert, since you are the closest to this issue, could you >>>> please shed some light on the IPR statement for that invention >>>> ? >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> >> >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Sat Jan 30 04:43:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5803A6853 for ; Sat, 30 Jan 2010 04:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=-3.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmcGvstP-EEq for ; Sat, 30 Jan 2010 04:43:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2BBED3A67E3 for ; Sat, 30 Jan 2010 04:43:58 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAACO4Y0uQ/uCWe2dsb2JhbACPNIwTAQEWJAakYpdCgj+CBgQ X-IronPort-AV: E=Sophos;i="4.49,374,1262563200"; d="scan'208";a="2923214" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 30 Jan 2010 12:14:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0UCiM9e000478; Sat, 30 Jan 2010 12:44:23 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 13:44:22 +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: Sat, 30 Jan 2010 13:44:18 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D012357A9@XMB-AMS-107.cisco.com> In-Reply-To: <4B6335AC.4090902@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPR issue Thread-Index: AcqhGKYj6MOqqBkDQOanvOTg6RdHdQAkLDbw References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> <4B6335AC.4090902@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Jan 2010 12:44:22.0909 (UTC) FILETIME=[F2D54AD0:01CAA1A9] Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Jan 2010 12:43:59 -0000 Hi Alex: I have no clue for OSPF but I think I follow your drift and agree with = your points.=20 Also you're perfectly correct that for NEMO, both the Nokia and the = Cisco statements did not prevent the open source implementations to = thrive, and the same goes for RPL. And finally I also agree with you this thread is really suspicious from = the start. That was the occasion to make sure that the group was well = aware of the Cisco IPR and terms, though. Maybe we can leave it at that = for the time being? Cheers, Pascal -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: vendredi 29 janvier 2010 20:23 To: Pascal Thubert (pthubert) Cc: JP Vasseur (jvasseur); Pascal Thubert; ROLL WG Subject: Re: [Roll] IPR issue Le 29/01/2010 19:19, Pascal Thubert (pthubert) a =E9crit : > Hi Alex: > > This is an IETF list, it's open with the reasonable hope that people > who join wish to understand and contribute to the technology. Yes, open, but there are rules, e.g. RFC2418 at a point: "Moderate the WG email list The Chair should attempt to ensure that the discussions on this list are relevant and that they converge to consensus = agreements." > This is not always the case but it usually works. I would not expect > from the chairs or some bigger brother to police every mail that > comes in the list. Hmm, not sure. In netlmm WG there was some unidentified poster at some point who stirred waters about "netlemmings". There was Chair intervention to give guidance. It was reassuring. Regularly on the IETF list we see complaints, procedure, email rights, appeals, etc. > And it is perfectly acceptable to discuss IPR. You did so in the > past. Since we are at it... I am ready to discuss with you about IPR aspects. But the current IPR thread was provoked by we don't know what. It's difficult to continue discussing without doubting it's all bluff (as in poker: deceiving provocation). > As an author of RFC 3963, I trust that you remember that Cisco had > IPR on NEMO too. The terms that were finally used are the same as > those that are proposed here, for all I assert/remember. Since you > mention it in your mail, would you think that Cisco IPR had any > counter effect on open source? Thanks for mentioning it. YEs, we worked together on NEMO and IPR aspects. Cisco's IPR claims on NEMO were ok, but were not the only ones. Nokia's IPR were explicitely geared towards Open Source. I wonder what's the IPR count for OSPF? (how many different companies made IPR claims on it). Anyways, Alex > > Cheers, > > Pascal > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > vendredi 29 janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal > Thubert; ROLL WG Subject: Re: [Roll] IPR issue > > Dear JP, > > Do you tolerate unidentified comments happening in this group? > > Is this serious? > > Alex > > Le 29/01/2010 18:37, JP Vasseur a =E9crit : >> Dear Alex, >> >> On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote: >> >>> JP, >>> >>> Thank for this note. >>> >>> Please help us understand _who_ is 'RAV' - the anonymous poster >>> with address ietfroll@yahoo.com, who posted recently about IPR >>> and ROLL. >>> >>> This helps better understand what's going on with IPR and RoLL. >>> >> >> unfortunately I cannot tell you ... Just don't know. >> >> Thanks, >> >> JP. >> >>> Alex >>> >>> Le 28/01/2010 20:47, JP Vasseur a =E9crit : >>>> Dear all, >>>> >>>> Some of you expressed some concerns about IPR on RPL, more >>>> specifically, >>>> = http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00167.html >>>> >>>> >>>> >>> >>>> >>>> >>>> > >>>> >>>> >>>> >>>> Pascal Thubert, since you are the closest to this issue, could you >>>> please shed some light on the IPR statement for that invention >>>> ? >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> >> >> > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From roger.alexander@ekasystems.com Sat Jan 30 05:33:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F22D3A6867 for ; Sat, 30 Jan 2010 05:33:52 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBq9H2dccrku for ; Sat, 30 Jan 2010 05:33:51 -0800 (PST) Received: from web1203.biz.mail.gq1.yahoo.com (web1203.biz.mail.gq1.yahoo.com [67.195.14.50]) by core3.amsl.com (Postfix) with SMTP id E521B3A6782 for ; Sat, 30 Jan 2010 05:33:50 -0800 (PST) Received: (qmail 7392 invoked by uid 60001); 30 Jan 2010 13:34:16 -0000 Message-ID: <389672.5062.qm@web1203.biz.mail.gq1.yahoo.com> X-YMail-OSG: X_w.0n0VM1nx7xksWDirrLrYmPXJwsixwePI.7TcdJJzNBzT7lcN1qJSR_IhBfJTHcgsjnGsWzElHdpuG3QFht5WvpLTKUTzQcWrlcCEiG.r9caQ9eeNTYA_geLVniw4H2TMDkF5zKuzdQzjjvL_2Dzg1blZvidnIxhR9EpMiIy6XPNL3LKl1ScQFhxSi6PrXGV4xiV1OW0IqLsXJLBScE6hi6dNMLjARKrYybBa9LRp5yztUevol3fYGu3AGzynFLf.XnFip1cE.4pQYI7frMMGrlQcWCCpQlFzk5KEWjcePcI2uCWCQCcCH12LKKGE9lOHiWqAROh2rNBMvE9Hfl4dJv8NmIRFqeyZlcokOcpF3dEuaaEtwNII8d0- Received: from [69.143.218.61] by web1203.biz.mail.gq1.yahoo.com via HTTP; Sat, 30 Jan 2010 05:34:16 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B62E823.2030108@gmail.com> <4B632252.3070602@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01235731@XMB-AMS-107.cisco.com> <4B6335AC.4090902@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D012357A9@XMB-AMS-107.cisco.com> Date: Sat, 30 Jan 2010 05:34:16 -0800 (PST) From: Roger Alexander To: "Pascal Thubert \(pthubert\)" , Alexandru Petrescu In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D012357A9@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pascal Thubert , ROLL WG Subject: Re: [Roll] IPR issue X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Jan 2010 13:33:52 -0000 Hi Pascal,=0A=0AI support the effort made in being open and forthright rega= rding the IPR issue and Cisco's IPR provisions as it relates to RPL. With a= ny standards development it is impossible to a priori guarantee that it doe= s not include elements of any given individual's or company's IPR. They key= therefore, particularly in an open forum like the IETF, is for the communi= ty, collectively, to be as forthright and transparent as possible where ind= ividuals or companies may have IPR or knowledge of IPR that may be related = to on-going work. In that regard, I certainly appreciate the steps already = taken.=0A=0AThanks.=0A=0ARoger=0A=0A=0A=0A=0A----- Original Message ----=0A= From: Pascal Thubert (pthubert) =0ATo: Alexandru Petres= cu =0ACc: Pascal Thubert ; ROLL WG =0ASent: Sat, January 30, 2010 7:44:18 AM=0A= Subject: Re: [Roll] IPR issue=0A=0AHi Alex:=0A=0AI have no clue for OSPF bu= t I think I follow your drift and agree with your points. =0A=0AAlso you're= perfectly correct that for NEMO, both the Nokia and the Cisco statements d= id not prevent the open source implementations to thrive, and the same goes= for RPL.=0A=0AAnd finally I also agree with you this thread is really susp= icious from the start. That was the occasion to make sure that the group wa= s well aware of the Cisco IPR and terms, though. Maybe we can leave it at t= hat for the time being?=0A=0ACheers,=0A=0APascal=0A=0A-----Original Message= -----=0AFrom: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] =0AS= ent: vendredi 29 janvier 2010 20:23=0ATo: Pascal Thubert (pthubert)=0ACc: J= P Vasseur (jvasseur); Pascal Thubert; ROLL WG=0ASubject: Re: [Roll] IPR iss= ue=0A=0ALe 29/01/2010 19:19, Pascal Thubert (pthubert) a =E9crit :=0A> Hi A= lex:=0A>=0A> This is an IETF list, it's open with the reasonable hope that = people=0A> who join wish to understand and contribute to the technology.=0A= =0AYes, open, but there are rules, e.g. RFC2418 at a point:=0A=0A"Moderate = the WG email list=0A=0A The Chair should attempt to ensure that the d= iscussions on this=0A list are relevant and that they converge to con= sensus agreements."=0A=0A> This is not always the case but it usually works= . I would not expect=0A> from the chairs or some bigger brother to police e= very mail that=0A> comes in the list.=0A=0AHmm, not sure. In netlmm WG the= re was some unidentified poster at some=0Apoint who stirred waters about "n= etlemmings". There was Chair=0Aintervention to give guidance. It was reas= suring.=0A=0ARegularly on the IETF list we see complaints, procedure, email= rights,=0Aappeals, etc.=0A=0A> And it is perfectly acceptable to discuss I= PR. You did so in the=0A> past. Since we are at it...=0A=0AI am ready to di= scuss with you about IPR aspects. But the current IPR=0Athread was provoke= d by we don't know what. It's difficult to continue=0Adiscussing without d= oubting it's all bluff (as in poker: deceiving=0Aprovocation).=0A=0A> As an= author of RFC 3963, I trust that you remember that Cisco had=0A> IPR on NE= MO too. The terms that were finally used are the same as=0A> those that are= proposed here, for all I assert/remember. Since you=0A> mention it in your= mail, would you think that Cisco IPR had any=0A> counter effect on open so= urce?=0A=0AThanks for mentioning it. YEs, we worked together on NEMO and I= PR=0Aaspects. Cisco's IPR claims on NEMO were ok, but were not the only=0A= ones. Nokia's IPR were explicitely geared towards Open Source.=0A=0AI wond= er what's the IPR count for OSPF? (how many different companies=0Amade IPR = claims on it).=0A=0AAnyways,=0A=0AAlex=0A=0A>=0A> Cheers,=0A>=0A> Pascal=0A= >=0A> -----Original Message----- From: roll-bounces@ietf.org=0A> [mailto:ro= ll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent:=0A> vendredi 29 = janvier 2010 19:01 To: JP Vasseur (jvasseur) Cc: Pascal=0A> Thubert; ROLL W= G Subject: Re: [Roll] IPR issue=0A>=0A> Dear JP,=0A>=0A> Do you tolerate un= identified comments happening in this group?=0A>=0A> Is this serious?=0A>= =0A> Alex=0A>=0A> Le 29/01/2010 18:37, JP Vasseur a =E9crit :=0A>> Dear Ale= x,=0A>>=0A>> On Jan 29, 2010, at 2:52 PM, Alexandru Petrescu wrote:=0A>>=0A= >>> JP,=0A>>>=0A>>> Thank for this note.=0A>>>=0A>>> Please help us underst= and _who_ is 'RAV' - the anonymous poster=0A>>> with address ietfroll@yahoo= .com, who posted recently about IPR=0A>>> and ROLL.=0A>>>=0A>>> This helps = better understand what's going on with IPR and RoLL.=0A>>>=0A>>=0A>> unfort= unately I cannot tell you ... Just don't know.=0A>>=0A>> Thanks,=0A>>=0A>> = JP.=0A>>=0A>>> Alex=0A>>>=0A>>> Le 28/01/2010 20:47, JP Vasseur a =E9crit := =0A>>>> Dear all,=0A>>>>=0A>>>> Some of you expressed some concerns about I= PR on RPL, more=0A>>>> specifically,=0A>>>> http://www.ietf.org/mail-archiv= e/web/ipr-announce/current/msg00167.html=0A>>>>=0A>>>>=0A>>>>=0A>>>=0A>>>>= =0A>>>>=0A>>>>=0A>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0APascal Thubert, since you = are the closest to this issue, could you=0A>>>> please shed some light on t= he IPR statement for that invention=0A>>>> ?=0A>>>>=0A>>>> Thanks.=0A>>>>= =0A>>>> JP.=0A>>>>=0A>>>> _______________________________________________ R= oll mailing=0A>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo= /roll=0A>>>>=0A>>>=0A>>>=0A>>=0A>>=0A>=0A>=0A> ____________________________= ___________________ Roll mailing list=0A> Roll@ietf.org https://www.ietf.or= g/mailman/listinfo/roll=0A>=0A=0A__________________________________________= _____=0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/li= stinfo/roll=0A From joydeep.tripathi@gmail.com Sun Jan 31 14:54:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407AB3A67EB for ; Sun, 31 Jan 2010 14:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFjU8OUDIIE8 for ; Sun, 31 Jan 2010 14:54:55 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id 1C5B53A67B6 for ; Sun, 31 Jan 2010 14:54:54 -0800 (PST) Received: by bwz24 with SMTP id 24so111051bwz.29 for ; Sun, 31 Jan 2010 14:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+QHw1HTeuig4+tDgBk1c2BTQixUfPQyDh8klSDUhAxs=; b=NVCBvdMQxwOcCCY9Wc/F5YdVVQFVLdkQuK6gYsabS4z9WwVgB7n1HRpmezygaaU/Bm TT7z31Rz4oLjHKtQSkaF0eaZgEe6pL3CPxTZUm5KN/4yZ92aDTTcSTKXq4lifiOHkBcd +oNwhtQ0besR+g46fKCr5GUiT8HivT1THXXec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XKDOV6s0XqG4A4HA5ipxbpKmlnot0uh3yZPsEEaUz7KS6EobgH5ETO7n8TueK23MNq hAALNKPncftm5cn1ZW/L+fWT+szpVpbFY0ZORyloIn0HLhsGLR+VoBZn9Q7HoLV5xKSc GFk/K/gC2DHMfqb938qiggaoED5ul967R/cjw= MIME-Version: 1.0 Received: by 10.204.32.204 with SMTP id e12mr2461351bkd.115.1264978522797; Sun, 31 Jan 2010 14:55:22 -0800 (PST) In-Reply-To: <139982.5001.qm@web110807.mail.gq1.yahoo.com> References: <139982.5001.qm@web110807.mail.gq1.yahoo.com> Date: Sun, 31 Jan 2010 17:55:22 -0500 Message-ID: From: Joydeep Tripathi To: "jerald.p.martocci" Content-Type: multipart/alternative; boundary=00032555488e7ff825047e7dc3cb Cc: ROLL WG Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2010 22:54:58 -0000 --00032555488e7ff825047e7dc3cb Content-Type: text/plain; charset=ISO-8859-1 Hi Jerry, Thanks a lot for the information you provided on simulation details, we're making excellent progress on the P2P simulation results which will be posted soon in the next revision. Could you just tell us which packet size we should be using and the average number of packets? Then we could provide with you with actual delay bound for P2P routing. Thanks, Joydeep --- On *Tue, 1/26/10, Jerald.P.Martocci@jci.com *wrote: > > > From: Jerald.P.Martocci@jci.com > Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > To: "JP Vasseur" > Cc: "ROLL WG" , "Mukul Goyal" , > roll-bounces@ietf.org > Date: Tuesday, January 26, 2010, 12:20 PM > > > Hi JP, > > My $.02 on your answers: > > 1) In a building there may 1000 devices in an LLN; hence even if Anders > does not have this requirement for a home, I do have this requirement for a > building. > > 2) My understanding is that for 6LoWPAN networks all devices are on a flat > network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence > there is no way to aggregate routes. > > 2a) Source/destination routes are completely random; hence there is no a > priori way to preselect routes. > > Regards, > > Jerry > > > > > *JP Vasseur * > Sent by: roll-bounces@ietf.org > > 01/26/2010 11:01 AM > To > Mukul Goyal > cc > ROLL WG > Subject > Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation > in the home > > > > > Hi Mukul, > > On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote: > > > JP, > > > > The obvious problem with proactive approaches, such as RPL, is the > > need to maintain reachability information for all possible > > destinations to which some source might send a packet some day. > > That's why we need source-initiated route discovery, i.e. a reactive > > approach. > > > > Several answers here: > 1) Are there such as huge number of unicast addresses in a home ? > 2) In so, this is where route aggregation/summarization can help. > > This is why I'm challenging the need for an a priori reactive > mechanism here before we prove that > reactive is not good enough. > > Makes sense ? > > ps: again acting with no co-chair hat. > > Thanks. > > JP. > > > Thanks > > Mukul > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Anders Brandt" > > Cc: "ROLL WG" > > Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada > > Central > > Subject: Re: [Roll] RPL Simulation in the home > > > > > > Copying the list to continue that discussion - see below > > > > > > > > Anders> > > > > > > > > > > > > > > > > > > > > > > > > Anyway, > > the use case is quite simple: > > > > Z - R1 - R2 - R3 - A > > > > 1) Lamp module A was recently controlled by controller Z via router > > 1 -> router 2 -> router 3 > > > > Z - R1 - R2 - R3 - A > > > > 2) Something renders the radio connection unusable from router 3 to > > lamp module A > > 3) The lamp module can however be reached via router 1 -> router 4 - > > > router 5 > > but router 5 has never been routing traffic to lamp module A > > > > Z - R1 - R2 - R3 - . > > \ > > - R4 - R5 - A > > 4) Controller Z sends another command to lamp module A via router 1 > > 5) Router 1 sends the command to router 2 which forwards the command > > to router 3 > > 6) Router 3 is unable to deliver the command > > > > What happens now? > > > > > > This is exactly why I was asking you the reason why you think that > > it should be reactive. > > What you describe is routing protocol convergence, which of course > > does not imply that the > > protocol should be reactive. This is a typical case where the > > topology is changing and RPL > > needs to adapt to it, which it does. The way to meet your time > > requirements is to adjust > > the RPL parameters to make it quicker to converge. If there is a > > link between A and R5, > > as soon as it becomes operational, A can send a DAO and R1 will > > direct the traffic to R4 > > instead of R2. > > > > > > > > > > Will the lamp go on within 250ms? > > > > > > > > So you raise the issue of convergence time, fair. It all depends on > > how you tune RPL and A > > selects R5 as a new parent. Note that you do not have to keep > > sending control traffic for > > that. If you links are extremely lossy you will have to make the DAG > > fairly reactive, which > > means more control traffic of course. If you are using a reactive > > mechanism instead of > > proactive, this is not a magic solution either since you flood your > > network and add control > > messages too. > > > > > > What I think is that by using these mechanism you can achieve a good > > level of convergence > > time with reasonable traffic in presence of lossy link w/o too much > > control traffic. We can try > > to quantify if you can provide an example topology, few stats on the > > link flaps trying few RPL > > tuning. Could you ? > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > > > > > > > > > Thanks, > > Anders > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Thursday, January 21, 2010 09:11 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote: > > > > > > > > > > Sorry JP > > > > I really have no intention of spreading FUD. > > Guess this mainly indicates that I and Jerry need education of what > > RPL is expected/able to deliver. > > > > At the most recent telecon we again touched the issue of e.g. a lamp > > module which due to rf phenomena > > cannot be reached via the recent router - and I thought we had a > > common understanding that some reactive mechanism > > would be needed. > > > > Can RPL - in its current shape - identify a new route via a router > > which did not previously forward traffic to said lamp module? > > > > > > > > Not sure of what you mean by this ? > > > > > > > > > > I would love that but I need to understand how - and I would love to > > see your evidence! > > > > > > > > Here is what I can propose: could you provide a home network > > topology that I could use to provide > > simulations results ? > > > > > > Cheers. > > > > > > JP. > > > > > > > > > > Thanks, > > Anders > > > > > > > > From: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sent: Wednesday, January 20, 2010 18:21 > > To: Anders Brandt > > Subject: Re: SV: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > > > On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote: > > > > > > > > > > > > > > Hi JP > > > >> Are you saying that RPL is not good enough for P2P in home and > >> building? > > > > Well - which incarnation of RPL? (!) > > I was of the impression that we had a common understanding that the > > ability to > > operate in a reactive fasion is critical to home & building and that > > the DAG update > > signaling currently designed will have much bigger delays than the > > 250ms real-time > > users will tolerate. > > > > > > Where does that come from ? > > > > > > > > > > > > > > > >> Since I have evidence that it is not the case. > >> Do you have data that shows different results ? > > > > I may have misunderstood the telecon conclusions, but I got it so > > that over time > > DAG routes will reconstructed, but that the current spec cannot find > > a lost target on demand (?). > > > > > >> Because as you know it is now in our charter to work on other > >> protocols. > > now? I guess you mean "not" ? (!) > > My conclusion from the Rolle interim was that we needed something > > special to find routes across the cloud. > > If the DAG can re-establish contact within 250ms to an operational > > node that was just lost in a routing table, > > I would really love it. Is that the case? > > > > > > mmm I do not think so ... happy to discuss it live with you though. > > > > > > Cheers! > > > > > > JP. > > > > > > > > > > > > > > > > Cheers, > > Anders > > > > > > Fra: JP Vasseur [ mailto:jvasseur@cisco.com ] > > Sendt: on 20-01-2010 17:02 > > Til: Anders Brandt > > Emne: Re: [Roll] RPL Simulation > > > > > > Hi Anders, > > > > > > off-line first. > > > > > > > > On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote: > > > > > > > > > > Jerry, > > > >> That was what was nice about an AODV concept, because even route > >> repair was fairly deterministic. > > > > As far as I am informed some reactive discovery mechanism is still > > needed for all the reasons that you list below. > > > > You may remember that we have the same needs in home automation. > > By utilizing the fact that source routing is already used to jump > > between RPL-capable routers AND the fact that the (time critical) > > point-to-point communication is limited to 5 hops or less, some TTL- > > aware, source-route-based AODV hybrid may not cause so > > much flooding as one could fear. > > > > > > > > Are you saying that RPL is not good enough for P2P in home and > > building ? Since I have evidence that it is not the case. > > Do you have data that shows different results ? > > Because as you know it is now in our charter to work on other > > protocols. > > > > > > Thanks. > > > > > > JP. > > > > > > > > > > > > - Anders > > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On > > Behalf Of Jerald.P.Martocci@jci.com > > Sent: Thursday, January 14, 2010 19:11 > > To: Joydeep Tripathi > > Cc: ROLL WG > > Subject: Re: [Roll] RPL Simulation > > > > > > > > Hi Joydeep, > > > > Mukul's been doing some simulations for my company for the past 3 > > years. He has a good handle on the commercial building performance > > requirements. It would be good for you to run those he notes > > below. It might be advantageous then for you two to share the > > results to better correlate the simulations. > > > > I would also look at the latency for P2P messages when the packet(s) > > need to traverse the DAG all the way up to the LBR and back down to > > the destination node. Of course, this is now a function on DAG > > depth. Also since all our messages require ACK, the additional > > latency of the ACK having to return possibly through a different set > > of nodes yet via the LBR. That would be the worst case scenario. > > If other nodes could short circuit the packets through a shorter > > path, that would on;y help. > > > > Since Building systems are real-time (smoke/fire detection, turning > > on lights, etc) latency is a big issue. Moving the packet up and > > down the DAG is reasonably deterministic and should be primarily a > > function of the DAG depth. However, what will really affect the > > system performance is 'DAG Repair'. I have no sense how long a > > packet in transit would have to wait if the DAG was under repair. > > Since we require ACKs of every message, the source node would time- > > out and retry a few times (usually 3). After that, the source node > > would have to fall into some 'failsoft' mode depending on the type > > of data it was trying to access. This is not a good situation. The > > source node can only assume that its data is inaccessible, not just > > held up in transit. The fail-soft mode will have large hysteresis > > since it can't be constantly dithering between modes. This will all > > be logged to the operator which is a bad thing!!! That was what was > > nice about an AODV concept, because even route repair was fairly > > deterministic. > > > > So... if your simulation could measure packet latency as a function > > of DAG repair severity, that would be terrific. > > > > Hope this makes sense. > > > > Jerry > > > > > > > > > > > > > > Mukul Goyal < mukul@uwm.edu > > > > > 01/13/2010 10:17 AM > > To Joydeep Tripathi < joydeep.tripathi@gmail.com > > > > > cc ROLL WG < roll@ietf.org >, Jerald P Martocci < > Jerald.P.Martocci@jci.com > > > > > > > Subject Re: [Roll] RPL Simulation > > > > > > > > > > Joydeep > > > > Here are a few suggestions for your simulations: > > > > 1. Simulate a 100 node and a 1000 node topology operating under a > > single DAG > > > > 2. Simulate both scenarios: optimal DAG routes (ie the path through > > the DAG from a source to a destination passes through their closest > > common ancestor) and DAG routes through root (all DAG paths have to > > go through the DAG root). > > > > 3. Study the stretch factor (increase in length/cost of routes over > > the DAG versus the length/cost of ideal routes) for given number of > > flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the > > number of nodes in the topology: > > a) the scenario you suggested: Choose 20% flows over 2 hop > > neighbors, 10% flows over longer paths. > > b) randomly selected source and destinations (in n*(n-1) case, from > > each possible source node to each possible destination node). > > > > 4. In addition to the stretch factor, calculate/simulate the traffic > > loads as well as packet loss/delay along the DAG links. Compare > > these values against values with ideal P2P routing. > > > > Thanks > > Mukul > > ----- Original Message ----- > > From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com > > > To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com > > > Cc: "ROLL WG" < roll@ietf.org > > > Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada > > Central > > Subject: [Roll] RPL Simulation > > > > Hi, > > > > In the next revision, we are also planning to implement a typical > > building routing scenario, where 60-70% of the P2P traffic are > > confined within 1 hop physical distance and, 20% of the P2P traffic > > are to a 2 -hop distance destination, and observe the performance of > > RPL against the ideal shortest route. Also, please let us know if > > there is any other scenario or traffic pattern you want to be > > implemented. > > > > Thanks, > > Joydeep > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > -----Inline Attachment Follows----- > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > --00032555488e7ff825047e7dc3cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Jerry,

Thanks a lot for the information you provided on simulation d= etails, we're making excellent progress on the P2P=A0si= mulation results which will be posted soon=A0in the next revision. Could yo= u just tell us which packet size we should be=A0using and the average numbe= r of packets? Then we could provide with you with actual delay bound for P2= P routing.=A0

Thanks,
Joydeep


--- On Tue, 1/26/10, Jerald.P.Martocci@jci.com= <Jera= ld.P.Martocci@jci.com> wrote:

From: Jerald.P.Martocci@jci.com <Jerald.P.Martocci@jci.com> Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation= in the home
To: "JP Vasseur" <jvasseur@cisco.com>
Cc: "ROLL WG= " <roll@ietf.org= >, "Mukul Goyal" <mukul@UWM.EDU>, roll-bounces@ietf.org
Date: Tuesday, January 26, 2010, 12:20 PM


Hi JP,

My $.02 on your answers:

1) In a building there may 1000 de= vices in an LLN; hence even if Anders does not have this requirement for a home, I do have this requirement for a building.

2) My understanding is that for 6L= oWPAN networks all devices are on a flat network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence there is no way to aggregate routes.

2a) Source/destination routes are = completely random; hence there is no a priori way to preselect routes.

Regards,

Jerry




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

01/26/2010 11:01 AM

To
Mukul Goyal <mukul@UWM.EDU>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] Reactive versus Pr= oactive approaches Re: RPL Simulation =A0 =A0 =A0 =A0in the home





Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the =A0
> need to maintain reachability information for all possible =A0
> destinations to which some source might send a packet some day. =A0 > That's why we need source-initiated route discovery, i.e. a reacti= ve =A0
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive =A0
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <jvasseur@cisco.com>
> To: "Anders Brandt" <abr@sdesigns.dk>
> Cc: "ROLL WG" <roll@ietf.org>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada =A0 > Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router =A0
> 1 -> router 2 -> router 3
>
> =A0Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to =A0
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 -
> > router 5
> =A0 =A0but router 5 has never been routing traffic to lamp module A
>
> =A0Z - R1 - R2 - R3 - .
> =A0 =A0 =A0 =A0\
> =A0 =A0 =A0 =A0 - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command =A0
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that =A0
> it should be reactive.
> What you describe is routing protocol convergence, which of course =A0
> does not imply that the
> protocol should be reactive. This is a typical case where the =A0
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time =A0
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a =A0 > link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will =A0 > direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on =A0
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep =A0
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG =A0
> fairly reactive, which
> means more control traffic of course. If you are using a reactive =A0
> mechanism instead of
> proactive, this is not a magic solution either since you flood your =A0
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good =A0
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much =A0
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the =A0
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
> =A0Anders
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what =A0
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp =A0
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a =A0 > common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router =A0
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to =A0
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network =A0
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
> =A0Anders
>
>
>
> From: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P =A0in home and =A0
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the =A0
> ability to
> operate in a reactive fasion is critical to home & building and that =A0
> the DAG update
> signaling currently designed will have much bigger delays than the =A0
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so =A0
> that over time
> DAG routes will reconstructed, but that the current spec cannot find =A0
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other =A0
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something =A0
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational =A0
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though. >
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
> =A0Anders
>
>
> Fra: JP Vasseur [ mailto:jvasseur@cisco.com ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> Jerry,
>
>> That was what was nice about an AODV concept, because even route =A0
>> repair was fairly deterministic.
>
> As far as I am informed some reactive discovery mechanism is still =A0
> needed for all the reasons that you list below.
>
> You may remember that we have the same needs in home automation.
> By utilizing the fact that source routing is already used to jump =A0
> between RPL-capable routers AND the fact that the (time critical)
> point-to-point communication is limited to 5 hops or less, some TTL-
> aware, source-route-based AODV hybrid may not cause so
> much flooding as one could fear.
>
>
>
> Are you saying that RPL is not good enough for P2P =A0in home and =A0
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other =A0
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: roll-= bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =A0
> Behalf Of Jerald.P.Martocci@jci.com
> Sent: Thursday, January 14, 2010 19:11
> To: Joydeep Tripathi
> Cc: ROLL WG
> Subject: Re: [Roll] RPL Simulation
>
>
>
> Hi Joydeep,
>
> Mukul's been doing some simulations for my company for the past 3 =A0
> years. =A0He has a good handle on the commercial building performance =A0
> requirements. =A0It would be good for you to run those he notes =A0
> below. =A0It might be advantageous then for you two to share the =A0
> results to better correlate the simulations.
>
> I would also look at the latency for P2P messages when the packet(s) =A0
> need to traverse the DAG all the way up to the LBR and back down to =A0
> the destination node. =A0Of course, this is now a function on DAG =A0
> depth. =A0Also since all our messages require ACK, the additional =A0
> latency of the ACK having to return possibly through a different set =A0
> of nodes yet via the LBR. =A0That would be the worst case scenario. =A0
> If other nodes could short circuit the packets through a shorter =A0 > path, that would on;y help.
>
> Since Building systems are real-time (smoke/fire detection, turning =A0
> on lights, etc) latency is a big issue. =A0Moving the packet up and =A0
> down the DAG is reasonably deterministic and should be primarily a =A0
> function of the DAG depth. =A0However, what will really affect the =A0
> system performance is 'DAG Repair'. =A0I have no sense how lon= g a =A0
> packet in transit would have to wait if the DAG was under repair. =A0
> Since we require ACKs of every message, the source node would time-
> out and retry a few times (usually 3). =A0After that, the source node =A0
> would have to fall into some 'failsoft' mode depending on the = type =A0
> of data it was trying to access. =A0This is not a good situation. =A0The =A0
> source node can only assume that its data is inaccessible, not just =A0
> held up in transit. =A0The fail-soft mode will have large hysteresis =A0
> since it can't be constantly dithering between modes. =A0This will all =A0
> be logged to the operator which is a bad thing!!! =A0That was what was =A0
> nice about an AODV concept, because even route repair was fairly =A0 > deterministic.
>
> So... if your simulation could measure packet latency as a function =A0
> of DAG repair severity, that would be terrific.
>
> Hope this makes sense.
>
> Jerry
>
>
>
> <ATT129641.jpg>
>
>
> Mukul Goyal < mu= kul@uwm.edu >
>
> 01/13/2010 10:17 AM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> To =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joydeep Tripathi < joydeep.tripathi@gmail.com >
>
> cc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ROLL WG < roll@iet= f.org >, Jerald P Martocci < Jerald.P.Martocci@jci.com
> =A0>
>
> Subject =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Re: [Roll] RPL Simulation
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>
>
>
> Joydeep
>
> Here are a few suggestions for your simulations:
>
> 1. Simulate a 100 node and a 1000 node topology operating under a =A0
> single DAG
>
> 2. Simulate both scenarios: optimal DAG routes (ie the path through =A0
> the DAG from a source to a destination passes through their closest =A0
> common ancestor) and DAG routes through root (all DAG paths have to =A0
> go through the DAG root).
>
> 3. Study the stretch factor (increase in length/cost of routes over =A0
> the DAG versus the length/cost of ideal routes) for given number of =A0
> flows: 100, 1000, 10000 and possibly n*(n-1) flows (where n is the =A0
> number of nodes in the topology:
> a) the scenario you suggested: Choose 20% flows over 2 hop =A0
> neighbors, 10% flows over longer paths.
> b) randomly selected source and destinations (in n*(n-1) case, from =A0
> each possible source node to each possible destination node).
>
> 4. In addition to the stretch factor, calculate/simulate the traffic =A0
> loads as well as packet loss/delay along the DAG links. Compare =A0 > these values against values with ideal P2P routing.
>
> Thanks
> Mukul
> ----- Original Message -----
> From: "Joydeep Tripathi" < joydeep.tripathi@gmail.com >
> To: "Jerald P Martocci" < Jerald.P.Martocci@jci.com >
> Cc: "ROLL WG" < roll@ietf.org >
> Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada =A0
> Central
> Subject: [Roll] RPL Simulation
>
> Hi,
>
> In the next revision, we are also planning to implement a typical
> building routing scenario, where 60-70% of the P2P traffic are
> confined within 1 hop physical distance and, 20% of the P2P traffic > are to a 2 -hop distance destination, and observe the performance of
> RPL against the ideal shortest route. Also, please let us know if
> there is any other scenario or traffic pattern you want to be
> implemented.
>
> Thanks,
> Joydeep
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll

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

-----Inline Attachment Follows-----

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


--00032555488e7ff825047e7dc3cb-- From mcr@sandelman.ca Sun Jan 31 18:02:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C213A6829 for ; Sun, 31 Jan 2010 18:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgAkXOEtbXsQ for ; Sun, 31 Jan 2010 18:02:41 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 92CDF3A6812 for ; Sun, 31 Jan 2010 18:02:41 -0800 (PST) Received: from sandelman.ottawa.on.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 29D9B34349 for ; Sun, 31 Jan 2010 20:56:30 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A49164E7E4 for ; Sun, 31 Jan 2010 21:03:12 -0500 (EST) From: Michael Richardson To: IETF ROLL X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sun, 31 Jan 2010 21:03:12 -0500 Message-ID: <6986.1264989792@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] sequence number increment and wrap X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Feb 2010 02:02:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are there any security implications in the sequence number? (I realize that the security architecture is not complete. I assume that there will be some kind of per-message authenticator (MAC) How this is keyed is really the hard part of the architectured) Typically, there is some concern if there is a replay of a lower sequence number. Such an event causes the network to return to some earlier state. The concern is that an attacker can record a previously authenticated set of messages and then play them back, intentionally causing such a time travel. One question is: is this a threat? The usual defense against that is that the sequence number must be monotonically increasing. If a nodes has been out of communication for a period of time, it may see a abrupt jump in sequence number, but that's okay --- if the authentication checks out, it advances. The problem is that we have an 8-bit field, and it isn't clear how much it may advance --- advances of 254 for instance, look like going backwards 1, and may be disallowed. The text in -05 is: Sequence Number: 8-bit unsigned integer set by the DODAG root, incremented according to a policy provisioned at the DODAG root, and propagated with no change down the DODAG. Each increment SHOULD have a value of 1 and may cause a wrap back to zero. It is good that the text tells what the DODAG should do, but we need to know what happens if there is an increment of more than 1, and how to know when there is an increment of more than 1, when it is a wrap. My first suggestion is that increments of up to 127 should be acceptable, as can unambiguously be understood to be increments (with possible wraps). Further, any increment which does not cause a wrap can be accepted as well. What I think would decide this is to understand under what conditions the sequence number can and should be incremented? - From my understanding, it's a DAG Iteration, and I think that this will happen somewhat often --- not as often as once a second, but certainly more often than once an hour. It is also my understanding that many DIO messages will be sent with the same sequence number --- it is not incremented each time the DIO is sent. I therefore suggest renaming this field to "DIO Iteration Number". - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS2Y2XoCLcPvd0N1lAQL0BwgAvyVovfNupQL7MjNOB/KDM3UaJJS0vVli yzKliEF7CvhrT8nxowLKK40XCyDp5vUNIzVMZrZOSknXcfyJdlWgFEVS7E4lcTz6 mSJJ4pyIAmSiUlBTka5p8YJqtzSDBRsEA4Egz0fRXJyhN2kdbw3kLOcTId6WeB0o +MJMnl1DjFryahQP8cuqwBy6nTgshqmPFsMUPFnf4jvUIZsK6L3Ucmp8SjUUndMI i8f4JWAsq/3/hMqfaAZYTAqmzlXBscLWh+lpzd5OOvfGS8vCf8/CZr3ewrvkDo7f 9iAqcw8DiSqNAmPUu6UT+Bf/MledzDflFCOlKSl5l0v28Y6bE3FccA== =6mQT -----END PGP SIGNATURE-----