From jpv@cisco.com Fri Oct 1 04:38: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 49A943A6E2D for ; Fri, 1 Oct 2010 04:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34eowXTW7xpm for ; Fri, 1 Oct 2010 04:38:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 295B93A6C7C for ; Fri, 1 Oct 2010 04:38:29 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADJlpUyrR7H+/2dsb2JhbACiNnGnXpwhhUQEijyDCIgU X-IronPort-AV: E=Sophos;i="4.57,265,1283731200"; d="scan'208";a="282336353" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Oct 2010 11:39:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o91BdFGP010031; Fri, 1 Oct 2010 11:39:17 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 13:39:14 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 13:39:13 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: JP Vasseur In-Reply-To: Date: Fri, 1 Oct 2010 13:39:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26702997-22EC-4DA1-9297-34E5315C6C66@cisco.com> References: To: ROLL WG , David Culler X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 01 Oct 2010 11:39:13.0952 (UTC) FILETIME=[45B4CA00:01CB615D] Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-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: Fri, 01 Oct 2010 11:38:30 -0000 WG LC on draft-ietf-roll-routing-metrics-09.txt has now ended. Authors = will open tickets for each issue that was raised, work on resolution and = publish the new revision. Thanks.=20 JP. On Sep 16, 2010, at 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the = past 16 months, the diffs have narrowed to essentially wording and = editorial changes, and the comments are few and non-controversial. = Thus, it appears that consensus has emerged and we can LC this I-D. >=20 > This email is to announce Working Group Last Call on = draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. = 30 2010. Please read it thoroughly and forward all final comments to = the authors and the WG mailing list. =20 >=20 > Thanks all for your good work. We're on a ROLL. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Fri Oct 1 06:03: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 B33EE3A6AD2 for ; Fri, 1 Oct 2010 06:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeC5vccEjx5V for ; Fri, 1 Oct 2010 06:03:21 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 2ED123A6EFA for ; Fri, 1 Oct 2010 06:03:03 -0700 (PDT) Received: from PCdePoste9 ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id JXE40548; Fri, 01 Oct 2010 15:03:48 +0200 Message-ID: <31F5046118C14626A11DA08AF0ED83D0@PCdePoste9> From: "Cedric Chauvenet" To: "JP Vasseur" , "ROLL WG" , "Omprakash Gnawali" References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> In-Reply-To: <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> Date: Fri, 1 Oct 2010 15:03:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01CB6179.D9859AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Cc: David Culler Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as anew ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:03:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_014B_01CB6179.D9859AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 This document provides a suitable mechanism to improve the network = stability. I don't see good reason to be opposed to its WG adoption. C=E9dric Chauvenet. ----- Original Message -----=20 From: JP Vasseur=20 To: ROLL WG ; Omprakash Gnawali=20 Cc: David Culler=20 Sent: Thursday, September 30, 2010 8:56 PM Subject: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 = as anew ROLL WG document ? Hi Omprakash, Thanks for the new revision addressing my comments. All,=20 Could you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? Thanks. JP. On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: Dear WG, I just updated the draft to address JP's comment on allowing for = leaf nodes. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Sep 21, 2010 at 2:17 PM Subject: New Version Notification for draft-gnawali-roll-minrank-hysteresis-of-02 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, = draft-gnawali-roll-minrank-hysteresis-of-02.txt has been successfully submitted by Omprakash Gnawali and posted to = the IETF repository. Filename: draft-gnawali-roll-minrank-hysteresis-of Revision: 02 Title: The Minimum Rank Objective Function with Hysteresis Creation_date: 2010-09-21 WG ID: Independent Submission Number_of_pages: 8 Abstract: Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). 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 ------=_NextPart_000_014B_01CB6179.D9859AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
This document provides a = suitable mechanism to=20 improve the network stability.
 
I don't see good reason to be opposed = to its=20 WG adoption.
 
C=E9dric Chauvenet.
----- Original Message -----
From:=20 JP Vasseur =
Sent: Thursday, September 30, = 2010 8:56=20 PM
Subject: [Roll] Adopting=20 draft-gnawali-roll-minrank-hysteresis-of-02 as anew ROLL WG document = ?

Hi Omprakash,

Thanks for the new revision addressing my=20 comments.

All, 

Could you please let us know if you are in favor/opposed of = adopting=20 draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document=20 ?

Thanks.

JP.


On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote:
Dear WG,

I just updated the draft to address JP's = comment on=20 allowing for leaf nodes.

- om_p

---------- Forwarded = message=20 ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Da= te:=20 Tue, Sep 21, 2010 at 2:17 PM
Subject: New Version Notification=20 for
draft-gnawali-roll-minrank-hysteresis-of-02
To: gnawali@cs.stanford.edu
Cc= : pal@cs.stanford.edu


A=20 new version of I-D, = draft-gnawali-roll-minrank-hysteresis-of-02.txt
has=20 been successfully submitted by Omprakash Gnawali and posted to = the
IETF=20 repository.

Filename:      =20  draft-gnawali-roll-minrank-hysteresis-of
Revision:   =  =20    02
Title:           The = Minimum=20 Rank Objective Function with Hysteresis
Creation_date:  =20 2010-09-21
WG ID:           Independent=20 Submission
Number_of_pages: 8

Abstract:
Hysteresis = delays the=20 effect of changes in link metric on parent
selection.  Such = delay=20 makes the topology stable despite jitters in
link metrics. =  The=20 Routing Protocol for Low Power and Lossy Networks
(RPL) allows = the use of=20 objective functions to construct routes that
optimize or = constrain a=20 routing metric on the paths.  This
specification describes = the=20 Minimum Rank Objective Function with
Hysteresis (MRHOF), an = objective=20 function that minimizes the node
rank in terms of a given metric, = while=20 using hysteresis to prevent
excessive rank churn.  The use = of MRHOF=20 with RPL results in nodes
selecting stable paths that minimize = the given=20 routing metric to the
roots of a Directed Acyclic Graph=20 (DAG).



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

_______________________________________________
Roll mailing = = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
------=_NextPart_000_014B_01CB6179.D9859AE0-- From coflynn@newae.com Fri Oct 1 06:43: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 EB9B33A6DB2 for ; Fri, 1 Oct 2010 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjSmx0anBk7A for ; Fri, 1 Oct 2010 06:43:16 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 047853A6F21 for ; Fri, 1 Oct 2010 06:42:50 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P1fth-0003Fq-9a for roll@ietf.org; Fri, 01 Oct 2010 09:43:37 -0400 From: "Colin O'Flynn" To: Date: Fri, 1 Oct 2010 14:43:23 +0100 Message-ID: <023c01cb616e$a06c2590$e14470b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023D_01CB6177.02308D90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActhbpuBbYTzNgPyQWaPQTAhLEHYUg== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 13:43:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_023D_01CB6177.02308D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I had the beginnings of RPL-11 dissectors for Wireshark. The patch is available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , and if anyone is able to use it I would appreciate feedback of any issues you find. I don't think it is complete yet so don't expect every feature to be present. If there is nothing critical I could see if it can be committed into Wireshark SVN, which would eventually make it part of a normal release. If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . Regards, -Colin ------=_NextPart_000_023D_01CB6177.02308D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark. The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if anyone is able to use it I would appreciate feedback of any = issues you find. I don’t think it is complete yet so don’t expect every feature to be present.

 

If there is nothing critical I could see if it can = be committed into Wireshark SVN, which would eventually make it part of a normal = release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /a> .

 

Regards,

 

  -Colin

------=_NextPart_000_023D_01CB6177.02308D90-- From alexandru.petrescu@gmail.com Fri Oct 1 07:55: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 AA7C83A6EC8 for ; Fri, 1 Oct 2010 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, 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 LyPn124ze+7L for ; Fri, 1 Oct 2010 07:55:57 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1EB9E3A6C1C for ; Fri, 1 Oct 2010 07:55:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o91EuhYv015332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Oct 2010 16:56:43 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o91EuhqQ002796 for ; Fri, 1 Oct 2010 16:56:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o91Eugv3008629 for ; Fri, 1 Oct 2010 16:56:42 +0200 Message-ID: <4CA5F6AA.2010004@gmail.com> Date: Fri, 01 Oct 2010 16:56:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <023c01cb616e$a06c2590$e14470b0$@com> In-Reply-To: <023c01cb616e$a06c2590$e14470b0$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 14:55:59 -0000 Any packet dumps to exercise the filters? (display RPL packets) Alex Le 01/10/2010 15:43, Colin O'Flynn a crit : > Hello, > > I had the beginnings of RPL-11 dissectors for Wireshark. The patch is > available at > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , and if > anyone is able to use it I would appreciate feedback of any issues > you find. I dont think it is complete yet so dont expect every > feature to be present. > > If there is nothing critical I could see if it can be committed into > Wireshark SVN, which would eventually make it part of a normal > release. > > If you require Windows builds I have one at > www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip > > . > > Regards, > > -Colin > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Fri Oct 1 08:11:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3193A6F17 for ; Fri, 1 Oct 2010 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 i4pDg8Vz2blz for ; Fri, 1 Oct 2010 08:11:48 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id CBA613A6EE0 for ; Fri, 1 Oct 2010 08:11:47 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P1hHn-0006NW-A3; Fri, 01 Oct 2010 11:12:36 -0400 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" , References: <023c01cb616e$a06c2590$e14470b0$@com> <4CA5F6AA.2010004@gmail.com> In-Reply-To: <4CA5F6AA.2010004@gmail.com> Date: Fri, 1 Oct 2010 16:12:19 +0100 Message-ID: <000c01cb617b$0da4b1c0$28ee1540$@com> 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: ActheONxhPtSluSATh2ivAsNWTOUuAAARXJA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 15:11:50 -0000 There is one attached to the bug report on Wireshark's Bugzilla.=20 I realized that patch is mostly RPL-10 and not RPL-11 so I'll fix = that... -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: October 1, 2010 3:57 PM To: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark Any packet dumps to exercise the filters? (display RPL packets) Alex Le 01/10/2010 15:43, Colin O'Flynn a =E9crit : > Hello, > > I had the beginnings of RPL-11 dissectors for Wireshark. The patch is > available at > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if > anyone is able to use it I would appreciate feedback of any issues > you find. I don=92t think it is complete yet so don=92t expect every > feature to be present. > > If there is nothing critical I could see if it can be committed into > Wireshark SVN, which would eventually make it part of a normal > release. > > If you require Windows builds I have one at > www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip > = = > . > > Regards, > > -Colin > > > > _______________________________________________ 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 Oct 1 08:17: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 54FB43A6DF7 for ; Fri, 1 Oct 2010 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 lSCJjcYb+tGI for ; Fri, 1 Oct 2010 08:17:31 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id F39ED3A6EBD for ; Fri, 1 Oct 2010 08:17:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o91FIIA0009247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Oct 2010 17:18:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o91FIILU008962; Fri, 1 Oct 2010 17:18:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o91FIHJP030592; Fri, 1 Oct 2010 17:18:18 +0200 Message-ID: <4CA5FBB9.902@gmail.com> Date: Fri, 01 Oct 2010 17:18:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Colin O'Flynn" References: <023c01cb616e$a06c2590$e14470b0$@com> <4CA5F6AA.2010004@gmail.com> <000c01cb617b$0da4b1c0$28ee1540$@com> In-Reply-To: <000c01cb617b$0da4b1c0$28ee1540$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 15:17:32 -0000 Le 01/10/2010 17:12, Colin O'Flynn a crit : > There is one attached to the bug report on Wireshark's Bugzilla. > > I realized that patch is mostly RPL-10 and not RPL-11 so I'll fix > that... That is fine don't worry. I have to look at the packets closer. What I want to know is the order: should I first patch the wireshark? If I patch the wireshark and look at the dump may I see IP packets? BEcause when I click the example capture that demonstrates the new patch (without wireshark being patched) https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5244 it shows only non-IP packets. Is it normal? If I patch then will I see IP packets? Alex > > -Colin > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > October 1, 2010 3:57 PM To: roll@ietf.org Subject: Re: [Roll] RPL > Dissectors for Wireshark > > Any packet dumps to exercise the filters? (display RPL packets) > > Alex > > Le 01/10/2010 15:43, Colin O'Flynn a crit : >> Hello, >> >> I had the beginnings of RPL-11 dissectors for Wireshark. The patch >> is available at >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , and if >> anyone is able to use it I would appreciate feedback of any issues >> you find. I dont think it is complete yet so dont expect every >> feature to be present. >> >> If there is nothing critical I could see if it can be committed >> into Wireshark SVN, which would eventually make it part of a >> normal release. >> >> If you require Windows builds I have one at >> www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip >> >> >> . >> >> Regards, >> >> -Colin >> >> >> >> _______________________________________________ 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 coflynn@newae.com Fri Oct 1 08:21: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 35D143A6EFC for ; Fri, 1 Oct 2010 08:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 UfygwoHK+aW5 for ; Fri, 1 Oct 2010 08:21:51 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 822783A6AED for ; Fri, 1 Oct 2010 08:21:51 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P1hRX-00017y-C1; Fri, 01 Oct 2010 11:22:40 -0400 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" References: <023c01cb616e$a06c2590$e14470b0$@com> <4CA5F6AA.2010004@gmail.com> <000c01cb617b$0da4b1c0$28ee1540$@com> <4CA5FBB9.902@gmail.com> In-Reply-To: <4CA5FBB9.902@gmail.com> Date: Fri, 1 Oct 2010 16:22:24 +0100 Message-ID: <000f01cb617c$75b890a0$6129b1e0$@com> 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: Acthe+Mma1fDrd0VRrSqwWdPr469jwAAAs1A Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 15:21:53 -0000 Hello, It 'should' work, assuming you've enable the special 802.15.4 'cheat' = under edit->preferences->IEEE 802.15.4 and ensure you see the line: "802.15.4 Ethertype (in hex): 809a" If you see nothing or some other value than 809a, put 809a in there. Also check under "Analyze->Enabled Protocols" for "IEEE 802.15.4" and "6lowpan" as both being enabled. If you have a very old version of Wireshark it won't have that mentioned cheat in it. If you don't have a very new version of Wireshark you might = not have proper 6lowpan support either. The best bet is a new build... Regards, -Colin -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: October 1, 2010 4:18 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark Le 01/10/2010 17:12, Colin O'Flynn a =E9crit : > There is one attached to the bug report on Wireshark's Bugzilla. > > I realized that patch is mostly RPL-10 and not RPL-11 so I'll fix > that... That is fine don't worry. I have to look at the packets closer. What I want to know is the order: should I first patch the wireshark? If I patch the wireshark and look at the dump may I see IP packets? BEcause when I click the example capture that demonstrates the new patch (without wireshark being patched) https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3D5244 it shows only non-IP packets. Is it normal? If I patch then will I see IP packets? Alex > > -Colin > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > October 1, 2010 3:57 PM To: roll@ietf.org Subject: Re: [Roll] RPL > Dissectors for Wireshark > > Any packet dumps to exercise the filters? (display RPL packets) > > Alex > > Le 01/10/2010 15:43, Colin O'Flynn a =E9crit : >> Hello, >> >> I had the beginnings of RPL-11 dissectors for Wireshark. The patch >> is available at >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if >> anyone is able to use it I would appreciate feedback of any issues >> you find. I don=92t think it is complete yet so don=92t expect every >> feature to be present. >> >> If there is nothing critical I could see if it can be committed >> into Wireshark SVN, which would eventually make it part of a >> normal release. >> >> If you require Windows builds I have one at >> www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip >> = = >> >> . >> >> Regards, >> >> -Colin >> >> >> >> _______________________________________________ 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 coflynn@newae.com Fri Oct 1 09:47: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 49BF13A6BE4 for ; Fri, 1 Oct 2010 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.430, 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 jqOCIVhJHaKS for ; Fri, 1 Oct 2010 09:47:30 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id E91703A6AED for ; Fri, 1 Oct 2010 09:47:29 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P1imP-0003Ke-Fy for roll@ietf.org; Fri, 01 Oct 2010 12:48:18 -0400 From: "Colin O'Flynn" To: References: <023c01cb616e$a06c2590$e14470b0$@com> In-Reply-To: <023c01cb616e$a06c2590$e14470b0$@com> Date: Fri, 1 Oct 2010 17:48:02 +0100 Message-ID: <001b01cb6188$6c293ec0$447bbc40$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CB6190.CDEDA6C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActhbpuBbYTzNgPyQWaPQTAhLEHYUgAGNJGg Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 16:47:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CB6190.CDEDA6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just a note the patch, example test-case, and binary at that same link have all been updated just now. -Colin From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 1, 2010 2:43 PM To: roll@ietf.org Subject: [Roll] RPL Dissectors for Wireshark Hello, I had the beginnings of RPL-11 dissectors for Wireshark. The patch is available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , and if anyone is able to use it I would appreciate feedback of any issues you find. I don't think it is complete yet so don't expect every feature to be present. If there is nothing critical I could see if it can be committed into Wireshark SVN, which would eventually make it part of a normal release. If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . Regards, -Colin ------=_NextPart_000_001C_01CB6190.CDEDA6C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a note the = patch, example test-case, and binary at that same link have all been updated just = now.

 

  = -Colin

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 2:43 PM
To: roll@ietf.org
Subject: [Roll] RPL Dissectors for = Wireshark

 

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark. The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if anyone is able to use it I would appreciate feedback of any = issues you find. I don’t think it is complete yet so don’t expect every feature to be present.

 

If there is nothing critical I could see if it can = be committed into Wireshark SVN, which would eventually make it part of a = normal release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /a> .

 

Regards,

 

  -Colin

------=_NextPart_000_001C_01CB6190.CDEDA6C0-- From cabo@tzi.org Fri Oct 1 10:16: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 70B893A6BEB; Fri, 1 Oct 2010 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clvHFMx5Oy56; Fri, 1 Oct 2010 10:16:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id CA0E03A6918; Fri, 1 Oct 2010 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o91HHS7l008442; Fri, 1 Oct 2010 19:17:28 +0200 (CEST) Received: from [192.168.217.101] (p5489FC08.dip.t-dialin.net [84.137.252.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9EAEA8BE; Fri, 1 Oct 2010 19:17:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 19:17:26 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Roll] Constrained network/node cluster at IETF 79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 17:16:49 -0000 As usual, the IETF agenda planning has just begun, so please do not make = the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained network/node = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Pearl APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Emerald IRTF HIPRG Host Identity Protocol=20= 1300-1500 Afternoon Session I Valley Ballroom B RTG roll Routing Over Low power = and Lossy networks WG 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Pearl APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF From root@core3.amsl.com Fri Oct 1 10:45:06 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 08CD03A6C2C; Fri, 1 Oct 2010 10:45:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101001174506.08CD03A6C2C@core3.amsl.com> Date: Fri, 1 Oct 2010 10:45:06 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:45:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-12.txt Pages : 142 Date : 2010-10-01 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-01103320.I-D@ietf.org> --NextPart-- From wintert@acm.org Fri Oct 1 11:09: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 0DAB93A6DDE for ; Fri, 1 Oct 2010 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN+NvpznK-Yo for ; Fri, 1 Oct 2010 11:09:35 -0700 (PDT) Received: from smtp109.prem.mail.ac4.yahoo.com (smtp109.prem.mail.ac4.yahoo.com [76.13.13.92]) by core3.amsl.com (Postfix) with SMTP id BD7CA3A6DD4 for ; Fri, 1 Oct 2010 11:09:34 -0700 (PDT) Received: (qmail 76448 invoked from network); 1 Oct 2010 18:10:15 -0000 Received: from [10.56.17.102] (wintert@71.178.253.216 with plain) by smtp109.prem.mail.ac4.yahoo.com with SMTP; 01 Oct 2010 11:10:15 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: teNNZYAVM1kIVMS6GK8jVuXUXAQUKBRI_O_nKmoo8fbNuf7 RKChMWvV8YrW7..vF8yQPs.b8Uev9y6C.UHfhAshMzxaRM3sEXsVJ3T6qCPj IDuwcre3KCx74QntPB_ZplOM6fVZ6O7AlGb13tWmRW5dZYoxbDueqdPOzbVs vyGryPY83GayrYKAOcKAiDXpXBUxJ6yv1fi3IHf9NAZjyBuZZvdcNOJvEbey eXSOX5DBT48GFU1qkHfTohwc5iz8Eq6qJaYtm9H_FYZjAtHkN1eUgX5kSlKr 2nIWjyjfbxQN3iWWytI7H05WkSb5FOqxvGl9nwpQHGgIYOxWrhHm7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CA623FC.7020706@acm.org> Date: Fri, 01 Oct 2010 14:10:04 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: roll@ietf.org References: <20101001174506.08CD03A6C2C@core3.amsl.com> In-Reply-To: <20101001174506.08CD03A6C2C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:09:36 -0000 WG, In this version we have incorporated some clarifications in response to IETF last call comments/feedback, including: http://www.ietf.org/mail-archive/web/gen-art/current/threads.html#05582 http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01414 http://www.ietf.org/mail-archive/web/secdir/current/threads.html#01978 https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ (IANA feedback in History) Regards, -Tim On 10/01/2010 01:45 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-12.txt > Pages : 142 > Date : 2010-10-01 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Fri Oct 1 11:11: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 56EBB3A6DF2 for ; Fri, 1 Oct 2010 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+3e-bRhwzVm for ; Fri, 1 Oct 2010 11:11:12 -0700 (PDT) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 524643A6DB7 for ; Fri, 1 Oct 2010 11:11:10 -0700 (PDT) Received: (qmail 46943 invoked from network); 1 Oct 2010 18:11:53 -0000 Received: from [10.56.17.102] (wintert@71.178.253.216 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 01 Oct 2010 11:11:53 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: _e3gfDcVM1lArpYt3DnGvk70rYUAXWgdMR7KZ4UfWH_bR7Z 51nDSWCLbCrWPIU2SwQpA8n82vbO1xVKTTR4OmKMSdsLg4e.RzmzzLgSBWcA kIGaOxEJhHmVTDRDLdgbZ9VVFE4OoiM9KGZJxkh5Lw9dEWiF4vcG1XwFLnGu FLCmh4jRuOzrM5GQdwBn3VnqwW98yFjTys.eM.JZHVkoBE.B4Xruhp_t.jKS pTXgLzyFAYZA4yr.BkDxQVhDMUp9_NqbbHbMnvdk0H974LBRJZ05GW1rJ4wX UzozwCSlcAHoMxy9poiKXyAN9WC69fK2QwhqIW_jnevP.CuP2DxiK X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CA62469.30102@acm.org> Date: Fri, 01 Oct 2010 14:11:53 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4C7FC929.4060301@gridmerge.com> In-Reply-To: <4C7FC929.4060301@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG , Adrian.Farrel@huawei.com Subject: Re: [Roll] AES-CCM not AES-CCM* X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 18:11:18 -0000 Hi Robert, WG, On 09/02/2010 11:56 AM, Robert Cragie wrote: > I think we should be specifying AES-CCM not AES-CCM* in the RPL > specification. There is some IPR surrounding AES-CCM* (US 2005/0154882), > plus only AES-CCM itself is referenced in FIPS 140-2. > > The only real difference between AES-CCM* and AES-CCM is the encrypt > only mode, which is illegal in AES-CCM. However, encrypt only is not > used in RPL. Authentication only can be achieved in AES-CCM by setting > the A data to the header concatenated with the payload and the payload > to be encrypted to the null string and Plen to 0 (see > http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf). > In practice, this makes no difference to the RPL specification. RPL-12 includes the following change: - update references from AES-CCM* to AES-CCM (RFC3610) - remove unnecessary reference to 802.15.4-2006 Since the two are functionally identical as used by RPL this change is not expected to have any functional impact on RPL. This change was made so that we may avoid any issues with the alleged IPR on AES-CCM* as mentioned above. Based on my understanding of the issue the technical impact of this change on RPL should be zero. If you have a concern about this change please be sure to raise it to Adrian by 7 October so that your concern may be caught in IESG evaluation. Thanks, -Tim > > Robert > -- > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Oct 1 12: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 9A37D3A6DD2 for ; Fri, 1 Oct 2010 12:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.521, 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 lEjZzCUQf7gL for ; Fri, 1 Oct 2010 12:03:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 435333A6CD1 for ; Fri, 1 Oct 2010 12:03:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id F24FE940161 for ; Fri, 1 Oct 2010 21:03:57 +0200 (CEST) Message-ID: <4CA6309C.4070801@gmail.com> Date: Fri, 01 Oct 2010 21:03:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <4C7FC929.4060301@gridmerge.com> <4CA62469.30102@acm.org> In-Reply-To: <4CA62469.30102@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101001-0, 01/10/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] AES-CCM not AES-CCM* X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Oct 2010 19:03:17 -0000 Did you get a chance to update it with respect to mutable but predictable fields (routing header), not just mutable, as discussed on the RPL WG list. Alex Le 01/10/2010 20:11, Tim Winter a crit : > Hi Robert, WG, > > On 09/02/2010 11:56 AM, Robert Cragie wrote: >> I think we should be specifying AES-CCM not AES-CCM* in the RPL >> specification. There is some IPR surrounding AES-CCM* (US 2005/0154882), >> plus only AES-CCM itself is referenced in FIPS 140-2. >> >> The only real difference between AES-CCM* and AES-CCM is the encrypt >> only mode, which is illegal in AES-CCM. However, encrypt only is not >> used in RPL. Authentication only can be achieved in AES-CCM by setting >> the A data to the header concatenated with the payload and the payload >> to be encrypted to the null string and Plen to 0 (see >> http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf). >> >> In practice, this makes no difference to the RPL specification. > > > RPL-12 includes the following change: > - update references from AES-CCM* to AES-CCM (RFC3610) > - remove unnecessary reference to 802.15.4-2006 > > Since the two are functionally identical as used by RPL this change > is not expected to have any functional impact on RPL. This change was > made so that we may avoid any issues with the alleged IPR on AES-CCM* > as mentioned above. Based on my understanding of the issue the technical > impact of this change on RPL should be zero. > > If you have a concern about this change please be sure to raise it to > Adrian by 7 October so that your concern may be caught in IESG evaluation. > > Thanks, > > -Tim > > > >> >> Robert >> -- >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 1924 910888 >> +1 415 513 0064 >> http://www.gridmerge.com >> >> >> >> _______________________________________________ >> 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 culler@cs.berkeley.edu Sun Oct 3 22:44: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 F29F43A6E0A for ; Sun, 3 Oct 2010 22:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuS3QXwsccYV for ; Sun, 3 Oct 2010 22:44:12 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id EE6FC3A6CD5 for ; Sun, 3 Oct 2010 22:44:11 -0700 (PDT) Received: from 44.31.128.10.in-addr.arpa.noptr.antlabs.com (gateway.packetfrenzy.com [70.90.94.113]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o945iXw6003220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Oct 2010 22:45:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <26702997-22EC-4DA1-9297-34E5315C6C66@cisco.com> Date: Sun, 3 Oct 2010 19:46:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1238ADBD-94DA-4EA1-A991-25297A71F1F5@cs.berkeley.edu> References: <26702997-22EC-4DA1-9297-34E5315C6C66@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: ROLL WG , David Culler Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:44:13 -0000 Correct. On Oct 1, 2010, at 4:39 AM, JP Vasseur wrote: > WG LC on draft-ietf-roll-routing-metrics-09.txt has now ended. Authors = will open tickets for each issue that was raised, work on resolution and = publish the new revision. >=20 > Thanks.=20 >=20 > JP. >=20 > On Sep 16, 2010, at 3:56 PM, David Culler wrote: >=20 >> The routing metrics draft has now gone through 9 revisions over the = past 16 months, the diffs have narrowed to essentially wording and = editorial changes, and the comments are few and non-controversial. = Thus, it appears that consensus has emerged and we can LC this I-D. >>=20 >> This email is to announce Working Group Last Call on = draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. = 30 2010. Please read it thoroughly and forward all final comments to = the authors and the WG mailing list. =20 >>=20 >> Thanks all for your good work. We're on a ROLL. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS From sdhags@gmail.com Mon Oct 4 12:55: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 3EB853A6FDE for ; Mon, 4 Oct 2010 12:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYsFI281f51R for ; Mon, 4 Oct 2010 12:54:58 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 73FD63A6E7D for ; Mon, 4 Oct 2010 12:54:58 -0700 (PDT) Received: by qwc9 with SMTP id 9so3809619qwc.31 for ; Mon, 04 Oct 2010 12:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=39EWmfRaLVmbGEXu+F7UmRv5OOTzQuTIWY17dwR+Sto=; b=WMqSeVu+3z+wHu034iUIca8kUGFNJwlNoIn5WA66uG/1a42Gc6DhBaRi2Y16LmPmNQ BEveOvdPjGHRnoTUJLNW0wUzE+G4MfQnIVGKqhVDNbCldsubZOpg+ij4q33bkf9WHDqx 6VlfAVTI3IeeDeftp1Jb+LYnrZqiBvNqaEaJA= 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:cc:content-type :content-transfer-encoding; b=YmjEFjcvFmkSuBesR+yZdroaWAyVYwFOs3rrk0GTMyCjXVSjtdIktT/5VtLMKf9W7G Y5vKRVRxkRcnYwjavj3wMnYdrIj3hsRE0HoO1vCZ67q1BOTe1uC+a5f15zhVytzrMK24 juTQkmmz1FQ5eoXsJRgPHItYlGUGw7NHrPSRQ= Received: by 10.224.60.24 with SMTP id n24mr7028974qah.95.1286222150890; Mon, 04 Oct 2010 12:55:50 -0700 (PDT) MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.229.214.82 with HTTP; Mon, 4 Oct 2010 12:55:30 -0700 (PDT) In-Reply-To: <31F5046118C14626A11DA08AF0ED83D0@PCdePoste9> References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> <31F5046118C14626A11DA08AF0ED83D0@PCdePoste9> From: Stephen Dawson-Haggerty Date: Mon, 4 Oct 2010 15:55:30 -0400 X-Google-Sender-Auth: tz9qyHK9VV3Bv_2H_ebGCniitBY Message-ID: To: Cedric Chauvenet Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG , David Culler Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as anew ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:55:00 -0000 I am also in favor. We certainly need a great link metric that will work out of the box and this seems to provide a vehicle for making one. Steve On Fri, Oct 1, 2010 at 9:03 AM, Cedric Chauvenet wrote: > Hi all, > > This document provides a suitable=C2=A0mechanism to improve the network > stability. > > I don't see good reason to be opposed to=C2=A0its WG adoption. > > C=C3=A9dric Chauvenet. > > ----- Original Message ----- > From: JP Vasseur > To: ROLL WG ; Omprakash Gnawali > Cc: David Culler > Sent: Thursday, September 30, 2010 8:56 PM > Subject: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a= new > ROLL WG document ? > Hi Omprakash, > Thanks for the new revision addressing my comments. > All, > Could you please let us know if you are in favor/opposed of adopting > draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group document= ? > Thanks. > JP. > > On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: > > Dear WG, > > I just updated the draft to address JP's comment on allowing for leaf nod= es. > > - om_p > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Tue, Sep 21, 2010 at 2:17 PM > Subject: New Version Notification for > draft-gnawali-roll-minrank-hysteresis-of-02 > To: gnawali@cs.stanford.edu > Cc: pal@cs.stanford.edu > > > > A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. > > Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gnawali-roll-minrank-hysteresi= s-of > Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A002 > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Minimum Rank Objective Func= tion with Hysteresis > Creation_date: =C2=A0 2010-09-21 > WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission > Number_of_pages: 8 > > Abstract: > Hysteresis delays the effect of changes in link metric on parent > selection. =C2=A0Such delay makes the topology stable despite jitters in > link metrics. =C2=A0The Routing Protocol for Low Power and Lossy Networks > (RPL) allows the use of objective functions to construct routes that > optimize or constrain a routing metric on the paths. =C2=A0This > specification describes the Minimum Rank Objective Function with > Hysteresis (MRHOF), an objective function that minimizes the node > rank in terms of a given metric, while using hysteresis to prevent > excessive rank churn. =C2=A0The use of MRHOF with RPL results in nodes > selecting stable paths that minimize the given routing metric to the > roots of a Directed Acyclic Graph (DAG). > > > > The IETF Secretariat. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > ________________________________ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From jeonggil.ko@gmail.com Mon Oct 4 12:59: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 3C9783A708C for ; Mon, 4 Oct 2010 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGFw7Y3Nh2UV for ; Mon, 4 Oct 2010 12:59:49 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id B535F3A7086 for ; Mon, 4 Oct 2010 12:59:49 -0700 (PDT) Received: by qyk5 with SMTP id 5so1862047qyk.10 for ; Mon, 04 Oct 2010 13:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=kckgGFB38+1Wv6v+s65X/Qqb33k1OJnpxMSYEmROGFM=; b=TDLPWfzOG1olGeh17KAQJNvBcCyQQlWs/VYs2Bnuw6h90gB+6p/cdJ6fPw4teLuj5y eItuh8ZrOgXFVoHh4OPs4MjJf3v1AJfKN68g+wwYM614mge75ozHj9X/6jM+C0oZOHr9 E91Qd1v8dQ2SKNZFghvgFbo+ndZHo8oGQpMbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CHjU3VH+dirEamKFKay0KJava5t+A2utKyCYS6JBFjazADb8yzTdiRfO0FU3FE10qx iCXpkR1rE0D4Upm9P3b7hzPqqOeSZUOMh+R7VVhEd8gdFT0ksu54ANUhu+8wCQiRh6Sx vhN95qGPUWneopg5DdeotV84AvCdav5ieLmzM= Received: by 10.229.95.66 with SMTP id c2mr7416186qcn.85.1286222445451; Mon, 04 Oct 2010 13:00:45 -0700 (PDT) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu [128.220.71.105]) by mx.google.com with ESMTPS id t18sm5939460qco.32.2010.10.04.13.00.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 13:00:44 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <1505D652-1EBE-4325-B76F-4730F25DB6AB@cs.stanford.edu> Date: Mon, 4 Oct 2010 16:00:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9298D2D0-9914-43AA-B5F7-2CF0A6653697@cs.jhu.edu> References: <1449628946.109107.1285165358794.JavaMail.root@mail02.pantherlink.uwm.edu> <1505D652-1EBE-4325-B76F-4730F25DB6AB@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1078) Cc: roll Subject: Re: [Roll] Poll for WG adoption of mrhof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Oct 2010 19:59:51 -0000 Any more updates on this poll? Or is a new poll planning to be initiated = by the chairs?=20 -John On Sep 22, 2010, at 10:36 AM, Philip Levis wrote: > Ah, ok. Clearly my memory is faulty! Thanks for the clarification. >=20 > Phil >=20 > (sent from a phone) >=20 > On Sep 22, 2010, at 9:22 AM, Mukul Goyal wrote: >=20 >> Hi Phil, >>=20 >>> Sure, sorry about that. I saw Mukul poll for the p2p draft so = thought I would do so as well. For future reference, is this an official = part of IETF process or just something you'd prefer (happy to go along)? >>=20 >> Here are the emails regarding my request for WG status for p2p draft = and the actual poll that JP initiated. Looking at the emails, one can = argue both ways whether I initiated the poll or JP did. But the truth is = that people responded only to JP's message. My message received a grand = total of zero responses. >>=20 >> :) >>=20 >> Mukul >>=20 >> ----- Forwarded Message ----- >> From: "Mukul Goyal" >> To: "roll" >> Sent: Sunday, August 8, 2010 9:32:57 PM >> Subject: [Roll] Fwd: New Version Notification for = draft-dt-roll-p2p-rpl-02 >>=20 >> Hi all, >>=20 >> Here is the new version of the P2P draft. It takes in account all the = comments received so far. >>=20 >> I would like to request WG status for the draft. >>=20 >> Comments welcome. >>=20 >> Regards >> Mukul >>=20 >>=20 >> ----- Forwarded Message ----- >> From: "JP Vasseur" >> To: "ROLL WG" >> Sent: Wednesday, August 18, 2010 2:30:09 PM >> Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working = Group document ? >>=20 >> Dear all, >>=20 >> draft-dt-roll-p2p-rpl-02.txt has been presented several times and >> discussed on the mailing list. Could you let us know whether or not >> you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a >> ROLL Working Group document (feel free to justify) ? >>=20 >> Thanks. >>=20 >> 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 >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jeonggil.ko@gmail.com Mon Oct 4 13:07: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 DCAFA3A7093 for ; Mon, 4 Oct 2010 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo8F6xjnbojf for ; Mon, 4 Oct 2010 13:07:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 53AF73A708F for ; Mon, 4 Oct 2010 13:07:10 -0700 (PDT) Received: by qyk5 with SMTP id 5so1870257qyk.10 for ; Mon, 04 Oct 2010 13:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=MNM5TkPbp76h/7buayv0gwaPJfbOnS6eP4zlN+9th94=; b=YnDhmbnceM7SAXHPxP5pXKPWTaR2N2iiUgMudwX3+zdtjo+/Nb/EukPW8qTRYpFSxi Iyqwp/c0PMzxi8tMyH0lGVmWGO+0PgGfCe4JkaezJd4lfJlJSVlj31HH65oZ+VBoANrx Uygzp5IFeHtbAybZzOS3QHXk88u71m/E5fIgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QMW3peh4i5YrYL6yNlBops6TKNCJPnH/I3jbzgBGj4JgCz1nzK6Ew7MWo+cEGonf7b mRxMjjtlVucR80ybf2lXQ+BCOXS715ZIiJrRzrcFCSQ/bNnXDuZca1jhsX7zw5HW9Uso +AxUDsm/yz5wJvlmPdCjCdZWdZhqn0/Owpc00= Received: by 10.224.3.3 with SMTP id 3mr7222826qal.181.1286222883082; Mon, 04 Oct 2010 13:08:03 -0700 (PDT) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu [128.220.71.105]) by mx.google.com with ESMTPS id x34sm5950128qci.18.2010.10.04.13.08.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 13:08:02 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: "JeongGil Ko (John)" In-Reply-To: Date: Mon, 4 Oct 2010 16:08:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> <31F5046118C14626A11DA08AF0ED83D0@PCdePoste9> To: Stephen Dawson-Haggerty X-Mailer: Apple Mail (2.1078) Cc: ROLL WG , David Culler Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as anew ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:07:12 -0000 One more in favor. It'll be great to further discuss about a working = mechanism to achieve route stability. -John On Oct 4, 2010, at 3:55 PM, Stephen Dawson-Haggerty wrote: > I am also in favor. We certainly need a great link metric that will > work out of the box and this seems to provide a vehicle for making > one. >=20 > Steve >=20 > On Fri, Oct 1, 2010 at 9:03 AM, Cedric Chauvenet > wrote: >> Hi all, >>=20 >> This document provides a suitable mechanism to improve the network >> stability. >>=20 >> I don't see good reason to be opposed to its WG adoption. >>=20 >> C=E9dric Chauvenet. >>=20 >> ----- Original Message ----- >> From: JP Vasseur >> To: ROLL WG ; Omprakash Gnawali >> Cc: David Culler >> Sent: Thursday, September 30, 2010 8:56 PM >> Subject: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 = as anew >> ROLL WG document ? >> Hi Omprakash, >> Thanks for the new revision addressing my comments. >> All, >> Could you please let us know if you are in favor/opposed of adopting >> draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? >> Thanks. >> JP. >>=20 >> On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: >>=20 >> Dear WG, >>=20 >> I just updated the draft to address JP's comment on allowing for leaf = nodes. >>=20 >> - om_p >>=20 >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: Tue, Sep 21, 2010 at 2:17 PM >> Subject: New Version Notification for >> draft-gnawali-roll-minrank-hysteresis-of-02 >> To: gnawali@cs.stanford.edu >> Cc: pal@cs.stanford.edu >>=20 >>=20 >>=20 >> A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt >> has been successfully submitted by Omprakash Gnawali and posted to = the >> IETF repository. >>=20 >> Filename: draft-gnawali-roll-minrank-hysteresis-of >> Revision: 02 >> Title: The Minimum Rank Objective Function with Hysteresis >> Creation_date: 2010-09-21 >> WG ID: Independent Submission >> Number_of_pages: 8 >>=20 >> Abstract: >> Hysteresis delays the effect of changes in link metric on parent >> selection. Such delay makes the topology stable despite jitters in >> link metrics. The Routing Protocol for Low Power and Lossy Networks >> (RPL) allows the use of objective functions to construct routes that >> optimize or constrain a routing metric on the paths. This >> specification describes the Minimum Rank Objective Function with >> Hysteresis (MRHOF), an objective function that minimizes the node >> rank in terms of a given metric, while using hysteresis to prevent >> excessive rank churn. The use of MRHOF with RPL results in nodes >> selecting stable paths that minimize the given routing metric to the >> roots of a Directed Acyclic Graph (DAG). >>=20 >>=20 >>=20 >> The IETF Secretariat. >> _______________________________________________ >> 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 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 >=20 > --=20 > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From trac@tools.ietf.org Tue Oct 5 07:44: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 207C33A6F57 for ; Tue, 5 Oct 2010 07:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Z1s4t1aV9JG8 for ; Tue, 5 Oct 2010 07:44:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 149A33A6F7A for ; Tue, 5 Oct 2010 07:44:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38lW-0005oe-6j; Tue, 05 Oct 2010 07:45:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:45:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/79 Message-ID: <055.1546a77ef724c87f2b73008cf6ae704c@tools.ietf.org> X-Trac-Ticket-ID: 79 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #79 (new): Link Energy metric: comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:44:17 -0000 #79: Link Energy metric: comment received during WG Last Call of draft-ietf- roll-routing-metrics-09.txt -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- The following captures the question raised during LC: need for link energy metric ? Original Email below (refer to the archives for the full discussion) Email sent september 18 David, Thanks for this Last Call on the RoLL routing metrics draft. I reply now just to make sure I replied before the September 30th, 2010, the deadline Chair set and that I consider. I have proposed last year to have energy link metrics: how much energy in Joules is required on a particular link to send 1280bytes as an IPv6 packet. I have proposed this link metric also as an extension to the ripless draft-mulligan-roll-ripless-01. In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as node energy only, not link energy. Link metrics _are_ considered in draft-ietf-roll-routing-metrics but not as energy. Private discussion pointed me unilaterally I may be wrong but I think publicly I may be right. I will send more comments later. Alex -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:47: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 7DD0A3A6FF5 for ; Tue, 5 Oct 2010 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, 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 RwOgbYoPcIGO for ; Tue, 5 Oct 2010 07:47:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1EFD03A6F7A for ; Tue, 5 Oct 2010 07:47:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38oa-00019s-94; Tue, 05 Oct 2010 07:48:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:48:24 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/80 Message-ID: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:47:27 -0000 #80: RPL across Multiple PHY/MAC: comment received during WG Last Call of -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Here is the original email (see archives for the details): Email sent September 19: "[my summary: it is worth clarifying (1) whether RPL runs in a single PHY or multiple PHY network, and (2) whether metrics for RPL should be understood in RPL network only or more universal like across the Internet. There are also points about whether Rx link energy is as important as Tx link energy and its usability overall.] Hi Colin, It does make sense to clarify the usage model first, especially the assumptions of whether or not RPL runs exclusively on networks made of single PHY, or multiple PHYs. I consider IP kind of work (do we say IPv6? 'router'?) is needed only if we consider multiple kinds of PHYs in the same network. Otherwise bridges, range extenders and other L2 tools are better appropriate than IP routers. During RPL comments we commented whether RPL draft text should say _only_ 802.15.4 or would it include PLC too. I think RPL draft text saying _only_ 802.15.4 would make subsequent metrics and security text much easier. However, it was insisted PLC should be there in the draft. So I am in that perspective now. But does that mean that RPL runs only on a network consisting of PLC devices, and on another network of 15.4 devices (separated by an Edge Router)? Or does it mean RPL runs in a network mixing 15.4 devices with PLC devices each being an RPL router? This was never clear. Alex Petrescu" -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:48: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 8552C3A6FB3 for ; Tue, 5 Oct 2010 07:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 4XqPR8l0pHHm for ; Tue, 5 Oct 2010 07:48:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2B8A83A6F75 for ; Tue, 5 Oct 2010 07:48:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38pO-0001AP-B4; Tue, 05 Oct 2010 07:49:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:49:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/80#comment:1 Message-ID: <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:48:17 -0000 #80: RPL across Multiple PHY/MAC: comment received during WG Last Call of -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by jpv@…): Email from Yoav Ben-Yehezkel (September 19) Thanks Alex/Colin for bringing this up for discussion. My two cents: I always saw the ability to operate at multiple media as one of the strongest points in favor of RPL (and L3 routing protocols) over specific L1/2 bridging techniques. The smart grid will most probably need to operate using both PLC or wireless media for the same utility owned networks in some cases. Consider the typical Multiple Dwelling Unit (MDU) use case where wireless meters reside outside apartments in sealed cabinets, and in-home displays are installed inside the apartments. RF cannot pass thick walls, so a selection of an L3 router via a PLC node is a natural (from the cabinet to the home). Another use case is of course to connect a wireless battery operated sensor (say on the ceiling) with a PLC device that needs the sensor inputs (such as PCTs). These smart-grid devices "belong" to the same utility network or sub-network (though using different medias sometimes)... RPL (or any L3 routing protocol as I understand it) supported by multiple PHY layers seems to me like an excellent choice for covering these use cases while inherently taking the routing metric into consideration when choosing which media is the most suitable for the next transmission to the final destination. I am seeking for WG confirmation that these use cases are covered well by RPL (as a route over media and link layer agnostic protocol). Otherwise, I think this is a significant short-coming of the protocol. The WG thoughts are very much appreciated. Best regards, Yoav -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:49: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 1FA083A6FB6 for ; Tue, 5 Oct 2010 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 46GY1FDeGASk for ; Tue, 5 Oct 2010 07:49:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EEDD53A6F8C for ; Tue, 5 Oct 2010 07:49:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38qN-0001FW-Pu; Tue, 05 Oct 2010 07:50:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:50:15 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/80#comment:2 Message-ID: <064.42fce3d4656f49118320902c4993af23@tools.ietf.org> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt (was: RPL across Multiple PHY/MAC: comment received during WG Last Call of) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:49:19 -0000 #80: RPL across Multiple PHY/MAC: comment received during WG Last Call of draft- ietf-roll-routing-metrics-09.txt -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:52:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A733A6F75 for ; Tue, 5 Oct 2010 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 TZaNci-cHtm2 for ; Tue, 5 Oct 2010 07:52:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A0E933A6C91 for ; Tue, 5 Oct 2010 07:52:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38t1-0001LC-QJ; Tue, 05 Oct 2010 07:52:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:52:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/81 Message-ID: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:52:03 -0000 #81: Comment received during WG Last Call of draft-ietf-roll-routing- metrics-09.txt --- Specifying how to combine metrics in the A field -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- email sent by Phoebus Chen on September 23 (refer to the archives for the full discussion) "I'm in the midst of making a pass through routing-metrics-09, and a question I (and others) asked earlier keeps coming up back in my head: Why are we specifying how to combine the metrics in the DAG metric container? Can't it be specified in the OF? Here was the old thread (way back in April): http://www.ietf.org/mail-archive/web/roll/current/msg03815.html JP's response: http://www.ietf.org/mail-archive/web/roll/current/msg03768.html The argument was to not have a flood of new RFCs specifying OFs for each possible new way of combining metrics. OK. But say that we do want to use a combination of add, max, min, multiplication, or some other operator to combine some of these metrics. What do we set in the "A" field of the Routing Metric/Constraint object depicted in Figure 2? I would prefer to replace "A=0x03: The routing metric is multiplicative" with "A=0x03: The routing metric is aggregated in some other fashion specified by the objective function." Or, there should be a sentence in the specification saying that the objective function can "override" and ignore this field (and MUST set A=0x00 if the OF plans for the A field to be ignored). I noticed that the text in Section 8 of routing-metrics-08 : "The use of compound metrics, such as a polynomial function of individual metric values, will be described in a future revision of this document." has been removed in routing-metrics-09. Given the rigidity of the A field, I'm not sure that we can specify compound metrics in future OFs. I'll send more comments about the rest of the document soon. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/16/10 3:56 PM, David Culler wrote: The routing metrics draft has now gone through 9 revisions over the past 16 months, the diffs have narrowed to essentially wording and editorial changes, and the comments are few and non-controversial. Thus, it appears that consensus has emerged and we can LC this I-D. This email is to announce Working Group Last Call on draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. 30 2010. Please read it thoroughly and forward all final comments to the authors and the WG mailing list. Thanks all for your good work. We're on a 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" -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:54: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 15B213A6CBE for ; Tue, 5 Oct 2010 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 wvq5ffMxcTA9 for ; Tue, 5 Oct 2010 07:54:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 650ED3A6C91 for ; Tue, 5 Oct 2010 07:54:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38vA-0001Pr-Ke; Tue, 05 Oct 2010 07:55:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: nicolas.dejean@coronis.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:55:12 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/82 Message-ID: <055.57531fd1929d809bf0bfe0a04583c0d6@tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: nicolas.dejean@coronis.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #82 (new): Comment received during WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio 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: Tue, 05 Oct 2010 14:54:17 -0000 #82: Comment received during WG Last Call on draft-ietf-roll-routing- metrics-09.txt --- Clarification on Node Fanout Ratio Object -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: nicolas.dejean@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Original Email below (refer to the archives for the full discussion) Email sent on September 23, by Phoebus Chen: "I'm a little confused about the Node Fanout Ratio (NFR) Object in Section 3.4 . Does fanout refer to outgoing links (upward, to a parents), or incoming links (downward, from children) of a node? The text says: "The Node Fanout Ratio (NFR) object is used to provide information on the nodes current forwarding load." From this, I would read fanout to mean the number of incoming links, if you are concerned with upward routing. The amount of traffic you have to forward depends on the amount of traffic coming in, which might be roughly related to the number of children. But as far as I know, RPL nodes only keep track of parents, not of children, so it cannot keep track of the number of incoming links. Or is the NFR object is used for optimizing the topology for downward routing (related to DAO fanout), to get path diversity / reliability? If this is the case, perhaps this should be explained in the metrics document." -- Ticket URL: roll From trac@tools.ietf.org Tue Oct 5 07:56:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D595C3A6CBE for ; Tue, 5 Oct 2010 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 I+U1leEOh3ho for ; Tue, 5 Oct 2010 07:56:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B89393A6C91 for ; Tue, 5 Oct 2010 07:56:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P38xD-0001Vi-LY; Tue, 05 Oct 2010 07:57:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 05 Oct 2010 14:57:19 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/83 Message-ID: <055.6f5b540c66d184e09344ac69a5f52740@tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:56:25 -0000 #83: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: dominique.barthel@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Original Email below (refer to the archives for the full discussion) Email sent on September 23, by Phoebus Chen: General Editorial Comments for the authors: 1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" into Section 2 "Object formats." It's near the end of the document, yet it says "In the rest of this document, this use of multiple DAG Metric Containers will be considered as if they were actually just one long DAG Metric Container." 2) I suggest moving Section 7 "Metric consistency" into Section 1 "Introduction". (Also, maybe the point being made in this section is obvious?) 3) I suggest moving Section 8 "Metric Usage" into a subsection of Section 2, or somewhere earlier in the document. It will shed more light when the precedence field is first discussed. Of course, the text will need to mention that the metrics mentioned in the examples will be defined in more detail in Sections 3 and 4. 4) Section 8 gives an example of how to break ties in metrics. What happens when there is a tie in the precedence field between two metrics? Is this not allowed? Is it broken in the order of the objects in the metric container (as it was before in version 8 of the document)? Or is the behavior in this case "beyond the scope of this document," and must be resolved by the Objective Function? 5) Section 9 is still incomplete... is this OK for last call? Only the NSA and Hop-count objects are described in 9.3 and 9.4 respectively. 6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static Metrics, after classifying the links according to characteristics (paragraphs 1, 3-5 after the list on pg. 5). I suggest a shorter description and deferring / moving the bulk of the discussion to Section 5 "Computation of dynamic metrics and attributes." Or at least, present this discussion after the discussion on the other classifications (which turns out to just be one sentence on link and node metrics not being exclusive), following the order of the list. 7) In many of the object formats, several of the descriptions of the flags/fields do not follow the order of the flags/fields in the object. See Figure 2 and the following description, Figure 3 and the following description, and Figure 5 and the following description. It would be a little easier to read if the orders matched. 8) In several figures, the last Byte indices above the objects are partially missing. Not a big deal, but it looks a little sloppy leaving them off. 9) There are misspelled words throughout the document... please run it through a spell checker after making the final edits. Nits below. Search for comments preceded by PC>." -- Ticket URL: roll From mcr@sandelman.ca Tue Oct 5 10:34: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 9B6FF3A701B for ; Tue, 5 Oct 2010 10:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.148, 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 hhXAEqFdnXgV for ; Tue, 5 Oct 2010 10:34:28 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8FA543A7012 for ; Tue, 5 Oct 2010 10:34:28 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 32DF434595 for ; Tue, 5 Oct 2010 13:37:15 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 821F69896E for ; Tue, 5 Oct 2010 13:35:25 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 05 Oct 2010 13:35:25 -0400 Message-ID: <8164.1286300125@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:34:29 -0000 >>>>> "roll" == roll issue tracker writes: roll> I am seeking for WG confirmation that these use cases are roll> covered well by RPL (as a route over media and link layer roll> agnostic protocol). Otherwise, I think this is a significant roll> short-coming of the protocol. As far as I'm concerned, these scenarios were always in scope. -- ] 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 jpv@cisco.com Wed Oct 6 01:41: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 36F063A6E2C for ; Wed, 6 Oct 2010 01:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqnBL7YzFuJ0 for ; Wed, 6 Oct 2010 01:41:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BCF003A6D98 for ; Wed, 6 Oct 2010 01:41:08 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0GAK7Tq0yQ/khMgWdsb2JhbAAtohIVAQEWIiKkII1bjkWFRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,289,1283731200"; d="scan'208";a="65920960" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2010 08:41:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o968foUZ013622; Wed, 6 Oct 2010 08:41:50 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 10:41:50 +0200 Received: from dhcp-144-254-57-185.cisco.com ([144.254.57.185]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 10:41:49 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <8164.1286300125@marajade.sandelman.ca> Date: Wed, 6 Oct 2010 06:05:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Oct 2010 08:41:49.0843 (UTC) FILETIME=[51636630:01CB6532] Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:41:10 -0000 On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >=20 >>>>>> "roll" =3D=3D roll issue tracker writes: > roll> I am seeking for WG confirmation that these use cases are > roll> covered well by RPL (as a route over media and link layer > roll> agnostic protocol). Otherwise, I think this is a significant > roll> short-coming of the protocol. >=20 > As far as I'm concerned, these scenarios were always in scope. They are (even in the charter !) but I wanted to close one ticket per = item raised during WG LC. We'll now close the tickets. Thanks. JP. >=20 > --=20 > ] 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.=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Wed Oct 6 01:49: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 05A0B3A6E47 for ; Wed, 6 Oct 2010 01:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By87C0sc8XFk for ; Wed, 6 Oct 2010 01:49:53 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id B57E53A6CD5 for ; Wed, 6 Oct 2010 01:49:53 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3Pi6-0001zd-QV; Wed, 06 Oct 2010 04:50:51 -0400 From: "Colin O'Flynn" To: "'JP Vasseur'" , "'Michael Richardson'" References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> In-Reply-To: Date: Wed, 6 Oct 2010 09:50:43 +0100 Message-ID: <005501cb6533$92b90e90$b82b2bb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActlMl8w4ObB+C6oQ2upbtNEHY830wAAErnw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:49:55 -0000 Hello, > As far as I'm concerned, these scenarios were always in scope. The original issue was only about if the routing metrics would work across multiple MAC/PHY. The issue was quickly blown out of context to become about RPL in general, which of course will work across multiple MAC/PHY. But it wasn't a real issue anyway, just some discussion. Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: > >>>>>> "roll" == roll issue tracker writes: > roll> I am seeking for WG confirmation that these use cases are > roll> covered well by RPL (as a route over media and link layer > roll> agnostic protocol). Otherwise, I think this is a significant > roll> short-coming of the protocol. > > As far as I'm concerned, these scenarios were always in scope. They are (even in the charter !) but I wanted to close one ticket per item raised during WG LC. We'll now close the tickets. Thanks. JP. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Wed Oct 6 01:52: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 104E03A6CD5 for ; Wed, 6 Oct 2010 01:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 F1PxNmzr+8dk for ; Wed, 6 Oct 2010 01:52:32 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 188D43A6B2A for ; Wed, 6 Oct 2010 01:52:30 -0700 (PDT) Received: from source ([209.85.215.182]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTKw5CmJO2hHaB8vwB71ai7zOTXmaUemN@postini.com; Wed, 06 Oct 2010 01:53:31 PDT Received: by eyx24 with SMTP id 24so3304329eyx.13 for ; Wed, 06 Oct 2010 01:53:29 -0700 (PDT) Received: by 10.14.47.79 with SMTP id s55mr8142746eeb.44.1286355209407; Wed, 06 Oct 2010 01:53:29 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> In-Reply-To: <005501cb6533$92b90e90$b82b2bb0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActlMl8w4ObB+C6oQ2upbtNEHY830wAAErnwAABCLlA= Date: Wed, 6 Oct 2010 10:53:27 +0200 Message-ID: To: "Colin O'Flynn" , JP Vasseur , Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:52:34 -0000 I agree with Colin This ticket misses the essence of the real issue which Colin and Alex discussed, as Colin clarified in one of his responses to my below concern. Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; 'Michael Richardson' Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of Hello, > As far as I'm concerned, these scenarios were always in scope. The original issue was only about if the routing metrics would work across multiple MAC/PHY. The issue was quickly blown out of context to become about RPL in general, which of course will work across multiple MAC/PHY. But it wasn't a real issue anyway, just some discussion. Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: > >>>>>> "roll" == roll issue tracker writes: > roll> I am seeking for WG confirmation that these use cases are > roll> covered well by RPL (as a route over media and link layer > roll> agnostic protocol). Otherwise, I think this is a significant > roll> short-coming of the protocol. > > As far as I'm concerned, these scenarios were always in scope. They are (even in the charter !) but I wanted to close one ticket per item raised during WG LC. We'll now close the tickets. Thanks. JP. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ 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 coflynn@newae.com Wed Oct 6 02:53:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2FB3A6E41 for ; Wed, 6 Oct 2010 02:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FEu6Lk7mC3+I for ; Wed, 6 Oct 2010 02:53:31 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id B4C7E3A6C55 for ; Wed, 6 Oct 2010 02:53:31 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3Qhh-0004Ca-To; Wed, 06 Oct 2010 05:54:30 -0400 From: "Colin O'Flynn" To: Date: Wed, 6 Oct 2010 10:54:23 +0100 Message-ID: <005801cb653c$76f32340$64d969c0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01CB6544.D8B78B40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActlPHL02uWeaccKS1eqXzHQSwQdSg== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Roll] metrics LC Tickets: battery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 09:53:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0059_01CB6544.D8B78B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There was no ticket opened for what I still consider an issue (I brought this up in LC) about the energy metric. The energy metric when used for battery-powered devices only has a relative measure of current power being used vs. available energy. Thus the energy metric will not differentiate between for example a coin-cell battery and a car battery connected to a node. Even if this IS the desired result I think it would be useful to clarify this. Some example solutions: #1) Make a note in the document about this, as it is desired that the energy metric only reflects the current state of the battery device, and thus the energy metric is not used for determining the best route (at least alone). I'm not sure exactly the point of the node energy metric in this case as-is. The throughput metric is used to reflect the available bandwidth, which is related to available battery power. Thus a coin-cell battery for example only advertises a much smaller available bandwidth. This isn't foolproof as other limitations could be reducing the advertised throughput. Future expansions through the use of TLVs could also fix this. #2) The energy metric has an additional field advertising the battery size. This would be of limited use since absolute measures aren't really comparable. #3) The energy metric has either an additional field indicating the incremental cost of adding a route, or only advertises the incremental cost of adding a route. This doesn't need to be very accurate, but even a rough estimate would be useful. So the metric would have the E-E field, but also have a second E-E field indicating the predicted E-E with some certain throughput. So it looks like: [E -E ] [ Predicted E - E] [Bitrate used in predicting E - E] The bitrate used could be a small selecting of available values and not an actual decimal number. But it would give you an idea of what sort of device you are talking to. If you are claiming a device can somewhat accurately calculate the E-E value, and/or can calculate the throughput field, there is no way this is any more complicated than either of those. Regards, -Colin ------=_NextPart_000_0059_01CB6544.D8B78B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

There was no ticket opened for what I still = consider an issue (I brought this up in LC) about the energy metric.


The energy metric when used for battery-powered devices only has a = relative measure of current power being used vs. available energy. Thus the = energy metric will not differentiate between for example a coin-cell battery = and a car battery connected to a node. Even if this IS the desired result I think = it would be useful to clarify this.

 

Some example solutions:

#1)

Make a note in the document about this, as it is = desired that the energy metric only reflects the current state of the battery = device, and thus the energy metric is not used for determining the best route = (at least alone). I’m not sure exactly the point of the node energy metric = in this case as-is.

 

The throughput metric is used to reflect the = available bandwidth, which is related to available battery power. Thus a coin-cell battery = for example only advertises a much smaller available bandwidth. This isn’t = foolproof as other limitations could be reducing the advertised = throughput.

 

Future expansions through the use of TLVs could = also fix this.

 

#2)

The energy metric has an additional field = advertising the battery size. This would be of limited use since absolute measures = aren’t really comparable.

 

#3)

The energy metric has either an additional field = indicating the incremental cost of adding a route, or only advertises the = incremental cost of adding a route. This doesn’t need to be very accurate, but even = a rough estimate would be useful.

 

So the metric would have the E-E field, but also = have a second E-E field indicating the predicted E-E with some certain = throughput. So it looks like:

 

[E –E ] [ Predicted E – E] [Bitrate = used in predicting E – E]

 

The bitrate used could be a small selecting of = available values and not an actual decimal number. But it would give you an idea = of what sort of device you are talking to.

 

If you are claiming a device can somewhat = accurately calculate the E-E value, and/or can calculate the throughput field, = there is no way this is any more complicated than either of those.

 

Regards,

 

  -Colin

------=_NextPart_000_0059_01CB6544.D8B78B40-- From jpv@cisco.com Wed Oct 6 03:02: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 5707C3A6EEE for ; Wed, 6 Oct 2010 03:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.4 X-Spam-Level: X-Spam-Status: No, score=-106.4 tagged_above=-999 required=5 tests=[AWL=-3.801, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwigHkCU-D1Y for ; Wed, 6 Oct 2010 03:02:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id BA5A83A6EE1 for ; Wed, 6 Oct 2010 03:02:52 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikEAPblq0yQ/khLgWdsb2JhbACiPxUBARYiIqNPjVuOQoVHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,289,1283731200"; d="scan'208";a="10732971" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Oct 2010 10:03:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o96A3mWt032230; Wed, 6 Oct 2010 10:03:48 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 12:03:47 +0200 Received: from dhcp-144-254-57-185.cisco.com ([144.254.57.185]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 12:03:47 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Wed, 6 Oct 2010 12:03:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Oct 2010 10:03:47.0349 (UTC) FILETIME=[C4734450:01CB653D] Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 10:02:54 -0000 I think that the title capture the topic. I'll update and propose a = resolution to close. Cheers. JP. On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: > I agree with Colin > This ticket misses the essence of the real issue which Colin and Alex > discussed, as Colin clarified in one of his responses to my below = concern. >=20 >=20 > Regards, > Yoav >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Colin O'Flynn > Sent: Wednesday, October 06, 2010 10:51 AM > To: 'JP Vasseur'; 'Michael Richardson' > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across = Multiple > PHY/MAC: comment received during WG Last Call of >=20 > Hello, >=20 >> As far as I'm concerned, these scenarios were always in scope. >=20 > The original issue was only about if the routing metrics would work = across > multiple MAC/PHY. The issue was quickly blown out of context to become > about > RPL in general, which of course will work across multiple MAC/PHY. >=20 > But it wasn't a real issue anyway, just some discussion. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of JP > Vasseur > Sent: October 6, 2010 5:05 AM > To: Michael Richardson > Cc: roll@ietf.org > Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across = Multiple > PHY/MAC: comment received during WG Last Call of >=20 >=20 > On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >=20 >>=20 >>>>>>> "roll" =3D=3D roll issue tracker writes: >> roll> I am seeking for WG confirmation that these use cases are >> roll> covered well by RPL (as a route over media and link layer >> roll> agnostic protocol). Otherwise, I think this is a significant >> roll> short-coming of the protocol. >>=20 >> As far as I'm concerned, these scenarios were always in scope. >=20 > They are (even in the charter !) but I wanted to close one ticket per = item > raised during WG LC. > We'll now close the tickets. >=20 > Thanks. >=20 > JP. >=20 >>=20 >> -- >> ] He who is tired of Weird Al is tired of life! | > firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device > driver[ >> Kyoto Plus: watch the video > >> then sign the petition. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Oct 6 06:30: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 12D5C3A6FBF for ; Wed, 6 Oct 2010 06:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, 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 OVaYYRzMdtZD for ; Wed, 6 Oct 2010 06:30:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E60163A6E6D for ; Wed, 6 Oct 2010 06:30:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96DV3ba004073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Oct 2010 15:31:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96DV3cZ031881 for ; Wed, 6 Oct 2010 15:31:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96DV2mh031914 for ; Wed, 6 Oct 2010 15:31:02 +0200 Message-ID: <4CAC7A16.5010202@gmail.com> Date: Wed, 06 Oct 2010 15:31:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> In-Reply-To: <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 13:30:11 -0000 Le 06/10/2010 12:03, JP Vasseur a crit : > I think that the title capture the topic. I'll update and propose a > resolution to close. JP, when closing this issue, please clarify: - every RPL message has src and dst address scoped as _link_ local, i.e. a single link, a single PHY/MAC. This contradicts the multiple PHY/MAC perspective, because a single link can't be connecting interfaces using different MAC/PHY. I am not sure I am clear... The metric part: some metrics, such as ETX and LQL, are for a single link and PHY/MAC, by their design. I may be wrong but that's how I see it. Alex > Cheers. > > JP. > > On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: > >> I agree with Colin This ticket misses the essence of the real >> issue which Colin and Alex discussed, as Colin clarified in one of >> his responses to my below concern. >> >> >> Regards, Yoav >> >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: >> Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; 'Michael >> Richardson' Cc: roll@ietf.org Subject: Re: [Roll] [roll] >> routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment >> received during WG Last Call of >> >> Hello, >> >>> As far as I'm concerned, these scenarios were always in scope. >> >> The original issue was only about if the routing metrics would >> work across multiple MAC/PHY. The issue was quickly blown out of >> context to become about RPL in general, which of course will work >> across multiple MAC/PHY. >> >> But it wasn't a real issue anyway, just some discussion. >> >> Regards, >> >> -Colin >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: >> October 6, 2010 5:05 AM To: Michael Richardson Cc: roll@ietf.org >> Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across >> Multiple PHY/MAC: comment received during WG Last Call of >> >> >> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >> >>> >>>>>>>> "roll" == roll issue tracker >>>>>>>> writes: >>> roll> I am seeking for WG confirmation that these use cases are >>> roll> covered well by RPL (as a route over media and link layer >>> roll> agnostic protocol). Otherwise, I think this is a >>> significant roll> short-coming of the protocol. >>> >>> As far as I'm concerned, these scenarios were always in scope. >> >> They are (even in the charter !) but I wanted to close one ticket >> per item raised during WG LC. We'll now close the tickets. >> >> Thanks. >> >> JP. >> >>> >>> -- ] He who is tired of Weird Al is tired of life! | >> firewalls [ >>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON >>> |net >> architect[ >>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ >>> |device >> driver[ >>> Kyoto Plus: watch the video >> >>> then sign the petition. >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ 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 alexandru.petrescu@gmail.com Wed Oct 6 08:05: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 16E4D3A70E0 for ; Wed, 6 Oct 2010 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, 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 A-PqQXe9j910 for ; Wed, 6 Oct 2010 08:05:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 091A33A6FE1 for ; Wed, 6 Oct 2010 08:05:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96F6KEF024824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Oct 2010 17:06:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96F6KUe001586 for ; Wed, 6 Oct 2010 17:06:20 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96F6Kmj010139 for ; Wed, 6 Oct 2010 17:06:20 +0200 Message-ID: <4CAC906C.1050602@gmail.com> Date: Wed, 06 Oct 2010 17:06:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <023c01cb616e$a06c2590$e14470b0$@com> <001b01cb6188$6c293ec0$447bbc40$@com> In-Reply-To: <001b01cb6188$6c293ec0$447bbc40$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 15:05:23 -0000 Wonderful, I've just downloaded the patched wireshark and saw first time RPL messages - thanks. The URLs as you say are: http://www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip Packet dumps: https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5252 https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5248 Alex Le 01/10/2010 18:48, Colin O'Flynn a crit : > Just a note the patch, example test-case, and binary at that same link > have all been updated just now. > > -Colin > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Colin O'Flynn > *Sent:* October 1, 2010 2:43 PM > *To:* roll@ietf.org > *Subject:* [Roll] RPL Dissectors for Wireshark > > Hello, > > I had the beginnings of RPL-11 dissectors for Wireshark. The patch is > available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , > and if anyone is able to use it I would appreciate feedback of any > issues you find. I dont think it is complete yet so dont expect every > feature to be present. > > If there is nothing critical I could see if it can be committed into > Wireshark SVN, which would eventually make it part of a normal release. > > If you require Windows builds I have one at > www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip > . > > Regards, > > -Colin > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Oct 6 08:52: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 BD3513A7142 for ; Wed, 6 Oct 2010 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, 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 RzLWAXklgxNO for ; Wed, 6 Oct 2010 08:52:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 081D03A70FA for ; Wed, 6 Oct 2010 08:52:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96Fr45n012295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Oct 2010 17:53:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96Fr4Df013395 for ; Wed, 6 Oct 2010 17:53:04 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96Fr37k025930 for ; Wed, 6 Oct 2010 17:53:04 +0200 Message-ID: <4CAC9B5F.3000909@gmail.com> Date: Wed, 06 Oct 2010 17:53:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Comments on RPL packets (from wireshark dumps) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 15:52:07 -0000 Comments on RPL packets (from wireshark dumps). Generally speaking I support implementations and this kind of dump to get reflected in the spec. - wireshark shows RPL packets as: "RPL Control Message (DODAG Information ...)" - Packets in wireshar-rpl-dio-prefix.pcap contain the following distinct headers: Ethernet IPv4 UDP ZigBee Encapsulation Protocol IEEE 802.15.4 Data 6LoWPAN IPHC IPv6 base header ICMPv6 (type 155 RPL control message) This means this might be an RPL emulator running above UDPv4? Hop Limit field is 255, but the RPL-12 spec does not specify a value for this field - I think the spec should specify a value for the Hop Limit field. Additionally, the RPL-12 spec specifies that the Hop Limit field must be decremented when forwarding: do we witness forwarding here or not? If not, then non decrementing the Hop Limit is ok, but we should say that this RPL is _not_ forwarding. - Packets in rpl_11.pcap show as a stacking: Ethernet II IEEE 802.15.4 Data 6LoWPAN IPHC Header IPv6 base header ICMPv6 Type 155 RPL Control message This looks less of an emulator. It is strange to see an Ethernet II header preceding the IEEE 802.15.4 Data. To see fake MAC addresses in the Ethernet II header ("af:ab:ac:ad:ae:af") and the Unknown Ethernet II Type 0x809a: it should be 0x86dd for IPv6. These doubts make think this is still an emulator(?) There is a DODAG Information Solicitation whose dst address is a link local unicast address (fe80::ff:fe00:1122); but the RPL-12 spec says that the dst address of a DODAG Info Sol is a multicast address. Who should be right? (besides, as I discover RPL-12 changed the rule of all RPL-11 messages being link-local multicast - its _only_ exception is DAO/DAOAck.) RPL-11 says the DIS (DODAG IS) message has an 8bit Flags field, but this dump doesn't seem to have this Flags field. The timeline of packets in this dump shows the packets happen very quickly, every 500ms or so; this gives an idea of time scale. There are many other aspects in this dump that I would like to comment on. Alex From coflynn@newae.com Wed Oct 6 09:24: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 637ED3A6F9B for ; Wed, 6 Oct 2010 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-RmRzH9xLWA for ; Wed, 6 Oct 2010 09:24:31 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 59F323A6F93 for ; Wed, 6 Oct 2010 09:24:31 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3Wo6-0006BX-85; Wed, 06 Oct 2010 12:25:31 -0400 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" , "'ROLL WG'" References: <4CAC9B5F.3000909@gmail.com> In-Reply-To: <4CAC9B5F.3000909@gmail.com> Date: Wed, 6 Oct 2010 17:25:13 +0100 Message-ID: <002001cb6573$15555770$40000650$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActlbpRbC+q7Q+KESWexON12u4SJ7AABAapw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] Comments on RPL packets (from wireshark dumps) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 16:24:32 -0000 Hi Alexandru, The dumps there do not reflect the true RPL-12 state, they were more just examples to demonstrate the Wireshark dissectors. So they could have been generated illegally with the sole intention of making packets which exercise the dissectors. In both cases they are true captures. The lower layer stuff is just ways of getting packets into Wireshark. So for the second example (rpl_11.pcap) the capture hardware is jamming raw 802.15.4 packets into Ethernet solely so Wireshark can pick up on them. The special ethtype is used by Wireshark to pick off these packets. The actual IPv6 stuff is reconstructed from the 6lowpan dissectors. -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: October 6, 2010 4:53 PM To: ROLL WG Subject: [Roll] Comments on RPL packets (from wireshark dumps) Comments on RPL packets (from wireshark dumps). Generally speaking I support implementations and this kind of dump to get reflected in the spec. - wireshark shows RPL packets as: "RPL Control Message (DODAG Information ...)" - Packets in wireshar-rpl-dio-prefix.pcap contain the following distinct headers: Ethernet IPv4 UDP ZigBee Encapsulation Protocol IEEE 802.15.4 Data 6LoWPAN IPHC IPv6 base header ICMPv6 (type 155 RPL control message) This means this might be an RPL emulator running above UDPv4? Hop Limit field is 255, but the RPL-12 spec does not specify a value for this field - I think the spec should specify a value for the Hop Limit field. Additionally, the RPL-12 spec specifies that the Hop Limit field must be decremented when forwarding: do we witness forwarding here or not? If not, then non decrementing the Hop Limit is ok, but we should say that this RPL is _not_ forwarding. - Packets in rpl_11.pcap show as a stacking: Ethernet II IEEE 802.15.4 Data 6LoWPAN IPHC Header IPv6 base header ICMPv6 Type 155 RPL Control message This looks less of an emulator. It is strange to see an Ethernet II header preceding the IEEE 802.15.4 Data. To see fake MAC addresses in the Ethernet II header ("af:ab:ac:ad:ae:af") and the Unknown Ethernet II Type 0x809a: it should be 0x86dd for IPv6. These doubts make think this is still an emulator(?) There is a DODAG Information Solicitation whose dst address is a link local unicast address (fe80::ff:fe00:1122); but the RPL-12 spec says that the dst address of a DODAG Info Sol is a multicast address. Who should be right? (besides, as I discover RPL-12 changed the rule of all RPL-11 messages being link-local multicast - its _only_ exception is DAO/DAOAck.) RPL-11 says the DIS (DODAG IS) message has an 8bit Flags field, but this dump doesn't seem to have this Flags field. The timeline of packets in this dump shows the packets happen very quickly, every 500ms or so; this gives an idea of time scale. There are many other aspects in this dump that I would like to comment on. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Wed Oct 6 09:25: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 952063A6F57 for ; Wed, 6 Oct 2010 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 BSAprwQTuDtv for ; Wed, 6 Oct 2010 09:25:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A9BC13A6CBE for ; Wed, 6 Oct 2010 09:25:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P3Wp6-0003Pa-Nd; Wed, 06 Oct 2010 09:26:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pister@eecs.berkeley.edu, jpv@cisco.com X-Trac-Project: roll Date: Wed, 06 Oct 2010 16:26:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/84 Message-ID: <055.bdad003363c224088ba09c963e73aad6@tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pister@eecs.berkeley.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] routing-metrics #84 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:25:36 -0000 #84: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pister@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from Colin O'flynn Hello, There was no ticket opened for what I still consider an issue (I brought this up in LC) about the energy metric. The energy metric when used for battery-powered devices only has a relative measure of current power being used vs. available energy. Thus the energy metric will not differentiate between for example a coin-cell battery and a car battery connected to a node. Even if this IS the desired result I think it would be useful to clarify this. Some example solutions: #1) Make a note in the document about this, as it is desired that the energy metric only reflects the current state of the battery device, and thus the energy metric is not used for determining the best route (at least alone). I’m not sure exactly the point of the node energy metric in this case as- is. The throughput metric is used to reflect the available bandwidth, which is related to available battery power. Thus a coin-cell battery for example only advertises a much smaller available bandwidth. This isn’t foolproof as other limitations could be reducing the advertised throughput. Future expansions through the use of TLVs could also fix this. #2) The energy metric has an additional field advertising the battery size. This would be of limited use since absolute measures aren’t really comparable. #3) The energy metric has either an additional field indicating the incremental cost of adding a route, or only advertises the incremental cost of adding a route. This doesn’t need to be very accurate, but even a rough estimate would be useful. So the metric would have the E-E field, but also have a second E-E field indicating the predicted E-E with some certain throughput. So it looks like: [E –E ] [ Predicted E – E] [Bitrate used in predicting E – E] The bitrate used could be a small selecting of available values and not an actual decimal number. But it would give you an idea of what sort of device you are talking to. If you are claiming a device can somewhat accurately calculate the E-E value, and/or can calculate the throughput field, there is no way this is any more complicated than either of those. Regards, -Colin -- Ticket URL: roll From alexandru.petrescu@gmail.com Wed Oct 6 09:42:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E529B3A70FB for ; Wed, 6 Oct 2010 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 eExj67SuAyPj for ; Wed, 6 Oct 2010 09:42:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 449813A70F3 for ; Wed, 6 Oct 2010 09:42:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96GhZ2d025192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Oct 2010 18:43:35 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96GhZrg024231; Wed, 6 Oct 2010 18:43:35 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96GhZ55004764; Wed, 6 Oct 2010 18:43:35 +0200 Message-ID: <4CACA737.2050408@gmail.com> Date: Wed, 06 Oct 2010 18:43:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Colin O'Flynn" References: <4CAC9B5F.3000909@gmail.com> <002001cb6573$15555770$40000650$@com> In-Reply-To: <002001cb6573$15555770$40000650$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'ROLL WG' Subject: Re: [Roll] Comments on RPL packets (from wireshark dumps) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 16:42:38 -0000 Le 06/10/2010 18:25, Colin O'Flynn a crit : > Hi Alexandru, > > The dumps there do not reflect the true RPL-12 state, they were more > just examples to demonstrate the Wireshark dissectors. So they could > have been generated illegally with the sole intention of making > packets which exercise the dissectors. > > In both cases they are true captures. The lower layer stuff is just > ways of getting packets into Wireshark. So for the second example > (rpl_11.pcap) the capture hardware is jamming raw 802.15.4 packets > into Ethernet solely so Wireshark can pick up on them. The special > ethtype is used by Wireshark to pick off these packets. The actual > IPv6 stuff is reconstructed from the 6lowpan dissectors. Do you mind if one sets the Hop Limit 254 in RPL packets? Spec doesn't tell what number to put there, and these dumps use 255. Alex > > -Colin > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > October 6, 2010 4:53 PM To: ROLL WG Subject: [Roll] Comments on RPL > packets (from wireshark dumps) > > Comments on RPL packets (from wireshark dumps). > > Generally speaking I support implementations and this kind of dump to > get reflected in the spec. > > - wireshark shows RPL packets as: "RPL Control Message (DODAG > Information ...)" > > - Packets in wireshar-rpl-dio-prefix.pcap contain the following > distinct headers: > > Ethernet IPv4 UDP ZigBee Encapsulation Protocol IEEE 802.15.4 Data > 6LoWPAN IPHC IPv6 base header ICMPv6 (type 155 RPL control message) > > This means this might be an RPL emulator running above UDPv4? > > Hop Limit field is 255, but the RPL-12 spec does not specify a value > for this field - I think the spec should specify a value for the Hop > Limit field. > > Additionally, the RPL-12 spec specifies that the Hop Limit field must > be decremented when forwarding: do we witness forwarding here or not? > If not, then non decrementing the Hop Limit is ok, but we should say > that this RPL is _not_ forwarding. > > > - Packets in rpl_11.pcap show as a stacking: > > Ethernet II IEEE 802.15.4 Data 6LoWPAN IPHC Header IPv6 base header > ICMPv6 Type 155 RPL Control message > > This looks less of an emulator. > > It is strange to see an Ethernet II header preceding the IEEE > 802.15.4 Data. To see fake MAC addresses in the Ethernet II header > ("af:ab:ac:ad:ae:af") and the Unknown Ethernet II Type 0x809a: it > should be 0x86dd for IPv6. These doubts make think this is still an > emulator(?) > > There is a DODAG Information Solicitation whose dst address is a link > local unicast address (fe80::ff:fe00:1122); but the RPL-12 spec says > that the dst address of a DODAG Info Sol is a multicast address. Who > should be right? > > (besides, as I discover RPL-12 changed the rule of all RPL-11 > messages being link-local multicast - its _only_ exception is > DAO/DAOAck.) > > RPL-11 says the DIS (DODAG IS) message has an 8bit Flags field, but > this dump doesn't seem to have this Flags field. > > The timeline of packets in this dump shows the packets happen very > quickly, every 500ms or so; this gives an idea of time scale. > > There are many other aspects in this dump that I would like to > comment on. > > Alex > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From jpv@cisco.com Wed Oct 6 13:15: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 648103A7259 for ; Wed, 6 Oct 2010 13:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.375 X-Spam-Level: X-Spam-Status: No, score=-110.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dShJiY1YFkC2 for ; Wed, 6 Oct 2010 13:15:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 410D73A7252 for ; Wed, 6 Oct 2010 13:15:26 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKN1rEyrR7H+/2dsb2JhbACiTXGqGo1bjmqFRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,292,1283731200"; d="scan'208";a="600161585" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2010 20:16:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96KGKMa003249; Wed, 6 Oct 2010 20:16:26 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 22:16:20 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 22:16:20 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4CAC7A16.5010202@gmail.com> Date: Wed, 6 Oct 2010 19:55:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F895C97-B539-4D6C-9EE0-028C1C3AE635@cisco.com> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> <4CAC7A16.5010202@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Oct 2010 20:16:20.0073 (UTC) FILETIME=[56C7E590:01CB6593] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17688.000 X-TM-AS-Result: No--31.345500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:15:29 -0000 Hi Alex, On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: > Le 06/10/2010 12:03, JP Vasseur a =E9crit : >> I think that the title capture the topic. I'll update and propose a >> resolution to close. >=20 > JP, when closing this issue, please clarify: >=20 > - every RPL message has src and dst address scoped as _link_ local, > i.e. a single link, a single PHY/MAC. This contradicts the multiple > PHY/MAC perspective, because a single link can't be connecting > interfaces using different MAC/PHY. >=20 > I am not sure I am clear... >=20 I am not clear about your question ... why is it different from all = other L3 routing ? > The metric part: some metrics, such as ETX and LQL, are for a single > link and PHY/MAC, by their design. >=20 No, they are not. LQL for example is also used by many deployed PLC = (proprietary) solutions, even if they use a different name. So LQL could be used for = several types of "lossy" links, it is not specific to a particular PHY/MAC. Same = reasoning applies to=20 ETX. Now, note that the metric ID does not mandate for all RPL networks = to support=20 all of the specified metrics of course. Further, one may decide to = specify a RPL metric=20 that is relevant for a specific PHY/MAC: RPL specifies what a node is = supposed to=20 do when it does not understand/support a metric (leaf node). This is a = deployment=20 issue. This is very similar to what is done with other routing = protocols. Hope that helps. JP. > I may be wrong but that's how I see it. >=20 > Alex >=20 >> Cheers. >>=20 >> JP. >>=20 >> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>=20 >>> I agree with Colin This ticket misses the essence of the real >>> issue which Colin and Alex discussed, as Colin clarified in one of >>> his responses to my below concern. >>>=20 >>>=20 >>> Regards, Yoav >>>=20 >>>=20 >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: >>> Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; 'Michael >>> Richardson' Cc: roll@ietf.org Subject: Re: [Roll] [roll] >>> routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment >>> received during WG Last Call of >>>=20 >>> Hello, >>>=20 >>>> As far as I'm concerned, these scenarios were always in scope. >>>=20 >>> The original issue was only about if the routing metrics would >>> work across multiple MAC/PHY. The issue was quickly blown out of >>> context to become about RPL in general, which of course will work >>> across multiple MAC/PHY. >>>=20 >>> But it wasn't a real issue anyway, just some discussion. >>>=20 >>> Regards, >>>=20 >>> -Colin >>>=20 >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: >>> October 6, 2010 5:05 AM To: Michael Richardson Cc: roll@ietf.org >>> Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across >>> Multiple PHY/MAC: comment received during WG Last Call of >>>=20 >>>=20 >>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>=20 >>>>=20 >>>>>>>>> "roll" =3D=3D roll issue tracker >>>>>>>>> writes: >>>> roll> I am seeking for WG confirmation that these use cases are >>>> roll> covered well by RPL (as a route over media and link layer >>>> roll> agnostic protocol). Otherwise, I think this is a >>>> significant roll> short-coming of the protocol. >>>>=20 >>>> As far as I'm concerned, these scenarios were always in scope. >>>=20 >>> They are (even in the charter !) but I wanted to close one ticket >>> per item raised during WG LC. We'll now close the tickets. >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>>=20 >>>> -- ] He who is tired of Weird Al is tired of life! | >>> firewalls [ >>>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON >>>> |net >>> architect[ >>>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ >>>> |device >>> driver[ >>>> Kyoto Plus: watch the video >>> >>>> then sign the petition. >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Oct 6 14:17:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1D33A723C for ; Wed, 6 Oct 2010 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.505, 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 9WZZYo0e8RrT for ; Wed, 6 Oct 2010 14:17:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C4F7E3A7232 for ; Wed, 6 Oct 2010 14:17:24 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0ACAF94006D; Wed, 6 Oct 2010 23:18:19 +0200 (CEST) Message-ID: <4CACE795.3010300@gmail.com> Date: Wed, 06 Oct 2010 23:18:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> <4CAC7A16.5010202@gmail.com> <3F895C97-B539-4D6C-9EE0-028C1C3AE635@cisco.com> In-Reply-To: <3F895C97-B539-4D6C-9EE0-028C1C3AE635@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:17:28 -0000 Le 06/10/2010 19:55, JP Vasseur a crit : > Hi Alex, > > On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: > >> Le 06/10/2010 12:03, JP Vasseur a crit : >>> I think that the title capture the topic. I'll update and propose >>> a resolution to close. >> >> JP, when closing this issue, please clarify: >> >> - every RPL message has src and dst address scoped as _link_ >> local, i.e. a single link, a single PHY/MAC. This contradicts the >> multiple PHY/MAC perspective, because a single link can't be >> connecting interfaces using different MAC/PHY. >> >> I am not sure I am clear... >> > > I am not clear about your question ... why is it different from all > other L3 routing ? Hi JP - I see what you mean, I remember you already said that, sorry. Yes, other routing protocosl sending their flooding messages on link-scoped multicast addresses (RIP, OSPF) are implemented on routers having multiple interfaces, thus possibly multiple PHY/MAC, originating new flooding messages with another src address topologically valid on that link. Should I understand that RPL router doing multiple PHY/MAC has at least two interfaces? Should I understand that most RPL Routers have at least two interfaces? If so, is the phrase RPL-12 "Although there may typically be only one interface in most application scenarios..." a little bit wrong? And that when receiving a DAO message on one interface RPL Router may generate another DAO with a different link-local source address on another interface? Or are the DAO messages propagated without modifying the src address? RPL-12 says "If the D flag is cleared then the source address of the IPv6 packet MUST be the DODAGID...The DODAGID in this case will be the reachable IPv6 address of node A" - sounds as if there is _only_ one address of node A? But a node with multiple interfaces has multiple link-local addresses. Or is a same link-local address assigned to multiple interfaces of an RPL router? I will have to check wireshark dumps about this. >> The metric part: some metrics, such as ETX and LQL, are for a >> single link and PHY/MAC, by their design. >> > > No, they are not. LQL for example is also used by many deployed PLC > (proprietary) solutions, even if they use a different name. So LQL > could be used for several types of "lossy" links, it is not specific > to a particular PHY/MAC. Yes, I agree, it could. > Same reasoning applies to ETX. Now, note that the metric ID does not > mandate for all RPL networks to support all of the specified metrics > of course. Further, one may decide to specify a RPL metric that is > relevant for a specific PHY/MAC: RPL specifies what a node is > supposed to do when it does not understand/support a metric (leaf > node). This is a deployment issue. This is very similar to what is > done with other routing protocols. In this sense, I think further work is needed on the common metrics to support multiple PHY/MACs. Alex > > Hope that helps. > > JP. > >> I may be wrong but that's how I see it. >> >> Alex >> >>> Cheers. >>> >>> JP. >>> >>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>> >>>> I agree with Colin This ticket misses the essence of the real >>>> issue which Colin and Alex discussed, as Colin clarified in one >>>> of his responses to my below concern. >>>> >>>> >>>> Regards, Yoav >>>> >>>> >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn >>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; >>>> 'Michael Richardson' Cc: roll@ietf.org Subject: Re: [Roll] >>>> [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: >>>> comment received during WG Last Call of >>>> >>>> Hello, >>>> >>>>> As far as I'm concerned, these scenarios were always in >>>>> scope. >>>> >>>> The original issue was only about if the routing metrics would >>>> work across multiple MAC/PHY. The issue was quickly blown out >>>> of context to become about RPL in general, which of course will >>>> work across multiple MAC/PHY. >>>> >>>> But it wasn't a real issue anyway, just some discussion. >>>> >>>> Regards, >>>> >>>> -Colin >>>> >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: >>>> October 6, 2010 5:05 AM To: Michael Richardson Cc: >>>> roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 >>>> (new): RPL across Multiple PHY/MAC: comment received during WG >>>> Last Call of >>>> >>>> >>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>> >>>>> >>>>>>>>>> "roll" == roll issue tracker >>>>>>>>>> writes: >>>>> roll> I am seeking for WG confirmation that these use >>>>> cases are roll> covered well by RPL (as a route over media >>>>> and link layer roll> agnostic protocol). Otherwise, I >>>>> think this is a significant roll> short-coming of the >>>>> protocol. >>>>> >>>>> As far as I'm concerned, these scenarios were always in >>>>> scope. >>>> >>>> They are (even in the charter !) but I wanted to close one >>>> ticket per item raised during WG LC. We'll now close the >>>> tickets. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>>> >>>>> -- ] He who is tired of Weird Al is tired of life! | >>>> firewalls [ >>>>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON >>>>> |net >>>> architect[ >>>>> ] mcr@sandelman.ottawa.on.ca >>>>> http://www.sandelman.ottawa.on.ca/ |device >>>> driver[ >>>>> Kyoto Plus: watch the video >>>> >>>>> then sign the petition. >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> _______________________________________________ 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 jpv@cisco.com Wed Oct 6 23:11: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 42ED43A704F for ; Wed, 6 Oct 2010 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv6MZzTkkfAq for ; Wed, 6 Oct 2010 23:09:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 103523A70BE for ; Wed, 6 Oct 2010 23:09:08 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAN8ArUyQ/khLgWdsb2JhbACiVBUBARYiIqc2nD6FRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,296,1283731200"; d="scan'208";a="66019165" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2010 06:08:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9768PNS011401 for ; Thu, 7 Oct 2010 06:08:25 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:08:25 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:08:25 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 7 Oct 2010 08:08:24 +0200 References: <20101006181231.D52793A6FC4@core3.amsl.com> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 06:08:25.0328 (UTC) FILETIME=[0D7B9F00:01CB65E6] Subject: [Roll] ROLL WG meeting - Requested session has been scheduled for IETF 79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:11:48 -0000 X-List-Received-Date: Thu, 07 Oct 2010 06:11:48 -0000 Dear all, here is the provisioning time slot for the ROLL WG IETF-79 > ROLL Session 1 (2 hours) > Thursday, Afternoon Session I 1300-1500 > Room Name: Valley Ballroom A > ---------------------------------------------- From jpv@cisco.com Wed Oct 6 23:24:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176563A6BDF for ; Wed, 6 Oct 2010 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.378 X-Spam-Level: X-Spam-Status: No, score=-106.378 tagged_above=-999 required=5 tests=[AWL=-3.780, BAYES_00=-2.599, HTML_MESSAGE=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 Bzy+RsCRoNf0 for ; Wed, 6 Oct 2010 23:24:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4A1953A6BAD for ; Wed, 6 Oct 2010 23:24:23 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFABMFrUyQ/khNgWdsb2JhbACBRKEOFQEBFiIipz+cPoVHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,296,1283731200"; d="scan'208,217";a="10805602" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2010 06:25:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o976PODF018003 for ; Thu, 7 Oct 2010 06:25:24 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:25:24 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:25:23 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-78-1035361676 Date: Thu, 7 Oct 2010 08:25:23 +0200 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 06:25:23.0556 (UTC) FILETIME=[6C64E240:01CB65E8] Subject: [Roll] IETF-79 - Important dates and Slot request ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:24:25 -0000 --Apple-Mail-78-1035361676 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, As a reminder please find below the important dates for the next IETF. If you would like to request a slot during the WG meeting, please let us = know. IETF 79: November 7-12, 2010, Beijing, China =20 2010-08-9 (Week of): IETF Online Registration opens. 2010-08-9 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use theIETF Meeting Session Request Tool. 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (24:00 UTC). To request a BOF, please see = instructions on Requesting a BOF. 2010-09-27 (Monday): Cutoff date for requests to schedule Working Group = meetings at 17:00 PT (24:00 UTC). To request a Working Group session, = use the IETF Meeting Session Request Tool. 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (24:00 UTC). 2010-10-06 (Wednesday): Preliminary agenda published for comment. 2010-10-11 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (24:00 UTC). 2010-10-11 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (24:00 UTC). 2010-10-15 (Friday): Final agenda to be published. 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission = Tool. 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT = (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT = (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-10-29 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (24:00 UTC). 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT = (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials = Management Tool. 2010-11-01 (Monday): Registration cancellation cut-off at 17:00 PT = (01:00 Tuesday, November 02 UTC). 2010-11-05 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local Beijing time. (02:00 PT, 09:00 UTC). 2010-11-07 - 2010-11-12: 79th IETF Meeting in Beijing, China. 2010-12-10 (Friday): Proceedings submission cutoff date by 17:00 PT = (01:00 Saturday, December 11 UTC), upload using IETF Meeting Materials = Management Tool. 2011-01-05 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (01:00 Thursday, January 6 UTC), upload using IETF Meeting = Materials Management Tool. --Apple-Mail-78-1035361676 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

As a reminder please find below the important = dates for the next IETF.

If you would = like to request a slot during the WG meeting, please let us = know.

 

  • 2010-08-9 (Week = of): IETF Online Registration opens.
  • 2010-08-9 = (Monday): Working Group and BOF scheduling begins. To request a = Working Group session, use the= IETF Meeting Session Request Tool.
  • 2010-09-13 (Monday): Cutoff = date for BOF proposal requests to Area Directors at 17:00 PT (24:00 = UTC). To request a BOF, please see instructions on Requesting a = BOF.
  • = IETF Meeting Session Request Tool.
  • 2010-09-27 (Monday): Cutoff = date for Area Directors to approve BOFs at 17:00 PT (24:00 UTC).
  • 2010-10-06 = (Wednesday): Preliminary agenda published for comment.
  • 2010-10-11 = (Monday): Cutoff date for requests to reschedule Working Group = and BOF meetings 17:00 PT (24:00 UTC).
  • 2010-10-11 (Monday): = Working Group Chair approval for initial document (Version -00) = submissions appreciated by 17:00 PT (24:00 UTC).
  • 2010-10-15 (Friday): Final = agenda to be published.
  • 2010-10-18 (Monday): Internet Draft Cut-off for = initial document (-00) submission by 17:00 PT (24:00 UTC), upload = using IETF = ID Submission Tool.
  • 2010-10-25 (Monday): Internet Draft final = submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2010-10-29 (Friday): Early = Bird registration and payment cut-off at 17:00 PT (24:00 UTC).
  • 2010-11-01 = (Monday): Revised Working Group agendas due by 17:00 PT (01:00 = Tuesday, November 02 UTC), upload using IETF = Meeting Materials Management Tool.
  • 2010-11-01 (Monday): = Registration cancellation cut-off at 17:00 PT (01:00 Tuesday, November = 02 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2011-01-05 (Wednesday): Proceedings submission = corrections cutoff date by 17:00 PT (01:00 Thursday, January 6 UTC), = upload using IETF = Meeting Materials Management = Tool.

= --Apple-Mail-78-1035361676-- From jpv@cisco.com Wed Oct 6 23:46: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 457163A70EA for ; Wed, 6 Oct 2010 23:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.353 X-Spam-Level: X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5 tests=[AWL=-3.755, BAYES_00=-2.599, HTML_MESSAGE=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 I9-NCthN9jKP for ; Wed, 6 Oct 2010 23:46:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9D2833A70D5 for ; Wed, 6 Oct 2010 23:46:48 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAM0JrUyQ/khNgWdsb2JhbACiUBUBARYiIqc6nD2FRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,296,1283731200"; d="scan'208,217";a="10807331" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2010 06:47:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o976lkQQ022292; Thu, 7 Oct 2010 06:47:46 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:47:46 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 08:47:46 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-85-1036704164 From: JP Vasseur In-Reply-To: <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> Date: Thu, 7 Oct 2010 08:47:45 +0200 Message-Id: <13A10841-3C53-4CA0-BE76-74267154C510@cisco.com> References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 06:47:46.0250 (UTC) FILETIME=[8CB3BAA0:01CB65EB] Cc: David Culler Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 06:46:54 -0000 --Apple-Mail-85-1036704164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Polling again since we got very few replies .... On Sep 30, 2010, at 8:56 PM, JP Vasseur wrote: > Hi Omprakash, >=20 > Thanks for the new revision addressing my comments. >=20 > All,=20 >=20 > Could you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? >=20 > Thanks. >=20 > JP. >=20 >=20 > On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: >=20 >> Dear WG, >>=20 >> I just updated the draft to address JP's comment on allowing for leaf = nodes. >>=20 >> - om_p >>=20 >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: Tue, Sep 21, 2010 at 2:17 PM >> Subject: New Version Notification for >> draft-gnawali-roll-minrank-hysteresis-of-02 >> To: gnawali@cs.stanford.edu >> Cc: pal@cs.stanford.edu >>=20 >>=20 >>=20 >> A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt >> has been successfully submitted by Omprakash Gnawali and posted to = the >> IETF repository. >>=20 >> Filename: draft-gnawali-roll-minrank-hysteresis-of >> Revision: 02 >> Title: The Minimum Rank Objective Function with Hysteresis >> Creation_date: 2010-09-21 >> WG ID: Independent Submission >> Number_of_pages: 8 >>=20 >> Abstract: >> Hysteresis delays the effect of changes in link metric on parent >> selection. Such delay makes the topology stable despite jitters in >> link metrics. The Routing Protocol for Low Power and Lossy Networks >> (RPL) allows the use of objective functions to construct routes that >> optimize or constrain a routing metric on the paths. This >> specification describes the Minimum Rank Objective Function with >> Hysteresis (MRHOF), an objective function that minimizes the node >> rank in terms of a given metric, while using hysteresis to prevent >> excessive rank churn. The use of MRHOF with RPL results in nodes >> selecting stable paths that minimize the given routing metric to the >> roots of a Directed Acyclic Graph (DAG). >>=20 >>=20 >>=20 >> The IETF Secretariat. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-85-1036704164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Omprakash,

Thanks for the new revision = addressing my = comments.

All, 

Could= you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document = ?

Thanks.

JP.
=

On Sep 21, 2010, at 9:18 PM, = Omprakash Gnawali wrote:

Dear = WG,

I just updated the draft to address JP's comment on allowing = for leaf nodes.

- om_p

---------- Forwarded message = ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Dat= e: Tue, Sep 21, 2010 at 2:17 PM
Subject: New Version Notification = for
draft-gnawali-roll-minrank-hysteresis-of-02
To: gnawali@cs.stanford.edu
Cc:= pal@cs.stanford.edu


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

Filename:       =  draft-gnawali-roll-minrank-hysteresis-of
Revision:   =      02
Title:           The = Minimum Rank Objective Function with Hysteresis
Creation_date:   = 2010-09-21
WG ID:           Independent = Submission
Number_of_pages: 8

Abstract:
Hysteresis delays = the effect of changes in link metric on parent
selection.  Such = delay makes the topology stable despite jitters in
link metrics. =  The Routing Protocol for Low Power and Lossy Networks
(RPL) = allows the use of objective functions to construct routes = that
optimize or constrain a routing metric on the paths. =  This
specification describes the Minimum Rank Objective = Function with
Hysteresis (MRHOF), an objective function that = minimizes the node
rank in terms of a given metric, while using = hysteresis to prevent
excessive rank churn.  The use of MRHOF = with RPL results in nodes
selecting stable paths that minimize the = given routing metric to the
roots of a Directed Acyclic Graph = (DAG).



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

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

= --Apple-Mail-85-1036704164-- From thomas@thomasclausen.org Thu Oct 7 06:53: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 91B483A7116 for ; Thu, 7 Oct 2010 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Koa1Xxi09w3K for ; Thu, 7 Oct 2010 06:53:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 4C73C3A702C for ; Thu, 7 Oct 2010 06:53:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1A4243236E4C; Thu, 7 Oct 2010 06:54:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 11F3832283CF; Thu, 7 Oct 2010 06:54:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-45-1062292565 From: Thomas Heide Clausen In-Reply-To: <13A10841-3C53-4CA0-BE76-74267154C510@cisco.com> Date: Thu, 7 Oct 2010 15:54:14 +0200 Message-Id: <01D19028-6FE6-49C4-9A21-504E3269937B@thomasclausen.org> References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> <13A10841-3C53-4CA0-BE76-74267154C510@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: ROLL WG , David Culler Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:53:15 -0000 --Apple-Mail-45-1062292565 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alright, having read the document, carefully this time around....it = seems to be a good thing for the WG to take on, so I support adopting = it. Thomas On Oct 7, 2010, at 08:47 , JP Vasseur wrote: > Polling again since we got very few replies .... >=20 > On Sep 30, 2010, at 8:56 PM, JP Vasseur wrote: >=20 >> Hi Omprakash, >>=20 >> Thanks for the new revision addressing my comments. >>=20 >> All,=20 >>=20 >> Could you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? >>=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >> On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: >>=20 >>> Dear WG, >>>=20 >>> I just updated the draft to address JP's comment on allowing for = leaf nodes. >>>=20 >>> - om_p >>>=20 >>> ---------- Forwarded message ---------- >>> From: IETF I-D Submission Tool >>> Date: Tue, Sep 21, 2010 at 2:17 PM >>> Subject: New Version Notification for >>> draft-gnawali-roll-minrank-hysteresis-of-02 >>> To: gnawali@cs.stanford.edu >>> Cc: pal@cs.stanford.edu >>>=20 >>>=20 >>>=20 >>> A new version of I-D, = draft-gnawali-roll-minrank-hysteresis-of-02.txt >>> has been successfully submitted by Omprakash Gnawali and posted to = the >>> IETF repository. >>>=20 >>> Filename: draft-gnawali-roll-minrank-hysteresis-of >>> Revision: 02 >>> Title: The Minimum Rank Objective Function with Hysteresis >>> Creation_date: 2010-09-21 >>> WG ID: Independent Submission >>> Number_of_pages: 8 >>>=20 >>> Abstract: >>> Hysteresis delays the effect of changes in link metric on parent >>> selection. Such delay makes the topology stable despite jitters in >>> link metrics. The Routing Protocol for Low Power and Lossy Networks >>> (RPL) allows the use of objective functions to construct routes that >>> optimize or constrain a routing metric on the paths. This >>> specification describes the Minimum Rank Objective Function with >>> Hysteresis (MRHOF), an objective function that minimizes the node >>> rank in terms of a given metric, while using hysteresis to prevent >>> excessive rank churn. The use of MRHOF with RPL results in nodes >>> selecting stable paths that minimize the given routing metric to the >>> roots of a Directed Acyclic Graph (DAG). >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-45-1062292565 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Polling again since we got very = few replies ....

On Sep 30, 2010, at 8:56 PM, JP = Vasseur wrote:

Hi = Omprakash,

Thanks for the new revision = addressing my = comments.

All, 

Could= you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document = ?

Thanks.

JP.
=

On Sep 21, 2010, at 9:18 PM, = Omprakash Gnawali wrote:

Dear = WG,

I just updated the draft to address JP's comment on allowing = for leaf nodes.

- om_p

---------- Forwarded message = ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Dat= e: Tue, Sep 21, 2010 at 2:17 PM
Subject: New Version Notification = for
draft-gnawali-roll-minrank-hysteresis-of-02
To: gnawali@cs.stanford.edu
Cc:= pal@cs.stanford.edu


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

Filename:       =  draft-gnawali-roll-minrank-hysteresis-of
Revision:   =      02
Title:           The = Minimum Rank Objective Function with Hysteresis
Creation_date:   = 2010-09-21
WG ID:           Independent = Submission
Number_of_pages: 8

Abstract:
Hysteresis delays = the effect of changes in link metric on parent
selection.  Such = delay makes the topology stable despite jitters in
link metrics. =  The Routing Protocol for Low Power and Lossy Networks
(RPL) = allows the use of objective functions to construct routes = that
optimize or constrain a routing metric on the paths. =  This
specification describes the Minimum Rank Objective = Function with
Hysteresis (MRHOF), an objective function that = minimizes the node
rank in terms of a given metric, while using = hysteresis to prevent
excessive rank churn.  The use of MRHOF = with RPL results in nodes
selecting stable paths that minimize the = given routing metric to the
roots of a Directed Acyclic Graph = (DAG).



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

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

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

= --Apple-Mail-45-1062292565-- From jpv@cisco.com Thu Oct 7 11:07: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 9C1783A6F35 for ; Thu, 7 Oct 2010 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.33 X-Spam-Level: X-Spam-Status: No, score=-110.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3XZLibGfOgM for ; Thu, 7 Oct 2010 11:07:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 357E13A6F75 for ; Thu, 7 Oct 2010 11:07:12 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAJuprUyQ/khMgWdsb2JhbACURY4AFQEBFiIir0WcXoVHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="66101322" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2010 18:08:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o97I8Eqd027878 for ; Thu, 7 Oct 2010 18:08:14 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:08:14 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:08:13 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: JP Vasseur In-Reply-To: <055.1546a77ef724c87f2b73008cf6ae704c@tools.ietf.org> Date: Thu, 7 Oct 2010 20:08:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.1546a77ef724c87f2b73008cf6ae704c@tools.ietf.org> To: roll@ietf.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 18:08:14.0067 (UTC) FILETIME=[9BFA3430:01CB664A] Subject: Re: [Roll] [roll] routing-metrics #79 (new): Link Energy metric: comment received during WG Last Call of draft-ietf-roll-routing-metrics-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, 07 Oct 2010 18:07:13 -0000 Dear all, The thread was started by Alex proposing to add link energy metric some = time ago. The issue has been raised again during WG LC of = draft-roll-routing-metrics-09.txt. Several WG members were not in favor = of adding such a metric for several reasons: * No clear use-case (Phil, Dominique, Jerry),=20 * So much merit (Colyn)=20 * May even lead to undesirable path optimization effect and much added = complexity (JP).=20 So the consensus is to not add link energy metric at this point. This = may be investigated in further document. Ticket will be closed with the text above. Thanks. JP. On Oct 5, 2010, at 4:45 PM, roll issue tracker wrote: > #79: Link Energy metric: comment received during WG Last Call of = draft-ietf- > roll-routing-metrics-09.txt > = -----------------------------+--------------------------------------------= -- > Reporter: jpv@=85 | Owner: jpv@=85 =20 > Type: defect | Status: new =20 > Priority: major | Milestone: =20 > Component: routing-metrics | Version: =20 > Severity: In WG Last Call | Keywords: =20 > = -----------------------------+--------------------------------------------= -- > The following captures the question raised during LC: need for link = energy > metric ? >=20 > Original Email below (refer to the archives for the full discussion) >=20 > Email sent september 18 >=20 > David, >=20 > Thanks for this Last Call on the RoLL routing metrics draft. >=20 > I reply now just to make sure I replied before the September 30th, = 2010, > the deadline Chair set and that I consider. >=20 > I have proposed last year to have energy link metrics: how much energy > in Joules is required on a particular link to send 1280bytes as an = IPv6 > packet. >=20 > I have proposed this link metric also as an extension to the ripless > draft-mulligan-roll-ripless-01. >=20 > In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as > node energy only, not link energy. >=20 > Link metrics _are_ considered in draft-ietf-roll-routing-metrics but > not as energy. >=20 > Private discussion pointed me unilaterally I may be wrong but I think > publicly I may be right. >=20 > I will send more comments later. >=20 > Alex >=20 > --=20 > Ticket URL: > roll >=20 From jpv@cisco.com Thu Oct 7 11:09:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5E93A7253 for ; Thu, 7 Oct 2010 11:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.331 X-Spam-Level: X-Spam-Status: No, score=-106.331 tagged_above=-999 required=5 tests=[AWL=-3.732, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryFArUiiIDEh for ; Thu, 7 Oct 2010 11:09:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D897F3A71B3 for ; Thu, 7 Oct 2010 11:09:22 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAE+qrUyQ/khLgWdsb2JhbACiRRUBARYiIq9NjVuPA4VHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="10873796" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2010 18:10:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o97IAPsH025036; Thu, 7 Oct 2010 18:10:25 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:10:25 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:10:24 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4CACE795.3010300@gmail.com> Date: Thu, 7 Oct 2010 20:10:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F660D44-6313-4275-8BA1-9FFE7961904D@cisco.com> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> <4CAC7A16.5010202@gmail.com> <3F895C97-B539-4D6C-9EE0-028C1C3AE635@cisco.com> <4CACE795.3010300@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 18:10:24.0490 (UTC) FILETIME=[E9B72CA0:01CB664A] Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:09:25 -0000 On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote: > Le 06/10/2010 19:55, JP Vasseur a =E9crit : >> Hi Alex, >>=20 >> On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: >>=20 >>> Le 06/10/2010 12:03, JP Vasseur a =E9crit : >>>> I think that the title capture the topic. I'll update and propose >>>> a resolution to close. >>>=20 >>> JP, when closing this issue, please clarify: >>>=20 >>> - every RPL message has src and dst address scoped as _link_ >>> local, i.e. a single link, a single PHY/MAC. This contradicts the >>> multiple PHY/MAC perspective, because a single link can't be >>> connecting interfaces using different MAC/PHY. >>>=20 >>> I am not sure I am clear... >>>=20 >>=20 >> I am not clear about your question ... why is it different from all >> other L3 routing ? >=20 > Hi JP - I see what you mean, I remember you already said that, sorry. >=20 > Yes, other routing protocosl sending their flooding messages on > link-scoped multicast addresses (RIP, OSPF) are implemented on routers > having multiple interfaces, thus possibly multiple PHY/MAC, = originating > new flooding messages with another src address topologically valid > on that link. >=20 > Should I understand that RPL router doing multiple PHY/MAC has at = least > two interfaces? =20 Yes > Should I understand that most RPL Routers have at > least two interfaces? =20 Not sure we can say "most" RPL router have at least two interfaces but = the=20 point here is that RPL can be used in networks with multiple PHY/MAC. In=20= this case, some of the routers obviously have multiple interfaces. > If so, is the phrase RPL-12 "Although there may > typically be only one interface in most application scenarios..." a > little bit wrong? >=20 > And that when receiving a DAO message on one interface RPL Router may > generate another DAO with a different link-local source address on > another interface? There is no issue there. Similar to other IPv6 routing protocols. >=20 > Or are the DAO messages propagated without modifying the src address? >=20 > RPL-12 says "If the D flag is cleared then the source address of the > IPv6 packet MUST be the DODAGID...The DODAGID in this case will be the > reachable IPv6 address of node A" - sounds as if there is _only_ one > address of node A? But a node with multiple interfaces has multiple > link-local addresses. Depends where you DAG goes ... >=20 > Or is a same link-local address assigned to multiple interfaces of an > RPL router? >=20 > I will have to check wireshark dumps about this. >=20 >>> The metric part: some metrics, such as ETX and LQL, are for a >>> single link and PHY/MAC, by their design. >>>=20 >>=20 >> No, they are not. LQL for example is also used by many deployed PLC >> (proprietary) solutions, even if they use a different name. So LQL >> could be used for several types of "lossy" links, it is not specific >> to a particular PHY/MAC. >=20 > Yes, I agree, it could. >=20 >> Same reasoning applies to ETX. Now, note that the metric ID does not >> mandate for all RPL networks to support all of the specified metrics >> of course. Further, one may decide to specify a RPL metric that is >> relevant for a specific PHY/MAC: RPL specifies what a node is >> supposed to do when it does not understand/support a metric (leaf >> node). This is a deployment issue. This is very similar to what is >> done with other routing protocols. >=20 > In this sense, I think further work is needed on the common metrics to > support multiple PHY/MACs. The statement is way too vague to help. As you can see all of the = metrics proposed can be used for various "lossy" PHY/MAC. Nothing PHY/MAC specific. Hope this helps. Thanks. JP. >=20 > Alex >=20 >>=20 >> Hope that helps. >>=20 >> JP. >>=20 >>> I may be wrong but that's how I see it. >>>=20 >>> Alex >>>=20 >>>> Cheers. >>>>=20 >>>> JP. >>>>=20 >>>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>>>=20 >>>>> I agree with Colin This ticket misses the essence of the real >>>>> issue which Colin and Alex discussed, as Colin clarified in one >>>>> of his responses to my below concern. >>>>>=20 >>>>>=20 >>>>> Regards, Yoav >>>>>=20 >>>>>=20 >>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn >>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; >>>>> 'Michael Richardson' Cc: roll@ietf.org Subject: Re: [Roll] >>>>> [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: >>>>> comment received during WG Last Call of >>>>>=20 >>>>> Hello, >>>>>=20 >>>>>> As far as I'm concerned, these scenarios were always in >>>>>> scope. >>>>>=20 >>>>> The original issue was only about if the routing metrics would >>>>> work across multiple MAC/PHY. The issue was quickly blown out >>>>> of context to become about RPL in general, which of course will >>>>> work across multiple MAC/PHY. >>>>>=20 >>>>> But it wasn't a real issue anyway, just some discussion. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> -Colin >>>>>=20 >>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: >>>>> October 6, 2010 5:05 AM To: Michael Richardson Cc: >>>>> roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 >>>>> (new): RPL across Multiple PHY/MAC: comment received during WG >>>>> Last Call of >>>>>=20 >>>>>=20 >>>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>>>=20 >>>>>>=20 >>>>>>>>>>> "roll" =3D=3D roll issue tracker >>>>>>>>>>> writes: >>>>>> roll> I am seeking for WG confirmation that these use >>>>>> cases are roll> covered well by RPL (as a route over media >>>>>> and link layer roll> agnostic protocol). Otherwise, I >>>>>> think this is a significant roll> short-coming of the >>>>>> protocol. >>>>>>=20 >>>>>> As far as I'm concerned, these scenarios were always in >>>>>> scope. >>>>>=20 >>>>> They are (even in the charter !) but I wanted to close one >>>>> ticket per item raised during WG LC. We'll now close the >>>>> tickets. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP. >>>>>=20 >>>>>>=20 >>>>>> -- ] He who is tired of Weird Al is tired of life! | >>>>> firewalls [ >>>>>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON >>>>>> |net >>>>> architect[ >>>>>> ] mcr@sandelman.ottawa.on.ca >>>>>> http://www.sandelman.ottawa.on.ca/ |device >>>>> driver[ >>>>>> Kyoto Plus: watch the video >>>>> >>>>>> then sign the petition. >>>>>> _______________________________________________ Roll mailing >>>>>> list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 From trac@tools.ietf.org Thu Oct 7 11:10: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 594CC3A7205 for ; Thu, 7 Oct 2010 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Oo4tVFw2rAwk for ; Thu, 7 Oct 2010 11:10:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 85D073A700A for ; Thu, 7 Oct 2010 11:10:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P3uwA-0000F0-Iy; Thu, 07 Oct 2010 11:11:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 07 Oct 2010 18:11:26 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/79#comment:1 Message-ID: <064.8b626aaff71e5e1a16dec9a42c489732@tools.ietf.org> References: <055.1546a77ef724c87f2b73008cf6ae704c@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <055.1546a77ef724c87f2b73008cf6ae704c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #79 (closed): Link Energy metric: comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt 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, 07 Oct 2010 18:10:36 -0000 #79: Link Energy metric: comment received during WG Last Call of draft-ietf- roll-routing-metrics-09.txt -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Dear all, The thread was started by Alex proposing to add link energy metric some time ago. The issue has been raised again during WG LC of draft-roll- routing-metrics-09.txt. Several WG members were not in favor of adding such a metric for several reasons: * No clear use-case (Phil, Dominique, Jerry), * So much merit (Colyn) * May even lead to undesirable path optimization effect and much added complexity (JP). So the consensus is to not add link energy metric at this point. This may be investigated in further document. Ticket will be closed with the text above. Thanks. JP. -- Ticket URL: roll From jpv@cisco.com Thu Oct 7 11:11: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 4A5E23A6F75 for ; Thu, 7 Oct 2010 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.308 X-Spam-Level: X-Spam-Status: No, score=-110.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6Yuo5jhmvaC for ; Thu, 7 Oct 2010 11:11:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C60B23A717D for ; Thu, 7 Oct 2010 11:11:24 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAMeqrUyQ/khMgWdsb2JhbACURY4AFQEBFiIir06cXoVHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="66101534" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2010 18:12:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o97ICJxb028366 for ; Thu, 7 Oct 2010 18:12:19 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:12:19 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:12:18 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: JP Vasseur In-Reply-To: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> Date: Thu, 7 Oct 2010 20:12:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> To: roll@ietf.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 18:12:19.0021 (UTC) FILETIME=[2DFB37D0:01CB664B] Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:11:29 -0000 Dear all, Answers have been provided to the mailing list:=20 "Summary of replies provided by JP on the list RPL is a L3 routing protocol, which by itself answers (hopefully) your first question. Further, this is clearly stated in the charter. With = regards to your second question, these metrics are RPL metrics. Answering the second question, =93How different is it from other L3 = routing protocol such as OSPF with regards to the routing metrics in a = routing domain that comprises different PHY/MAC=94. It is not. Consider = an ISIS L2 for example. As you probably know, you have routing metrics = and in most cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, = ...). You still use a metric for ISIS that reflects a link = characteristic." Metrics are applicable to all PHY/MAC. Ticket will be closed with the text above. Thanks. JP. On Oct 5, 2010, at 4:48 PM, roll issue tracker wrote: > #80: RPL across Multiple PHY/MAC: comment received during WG Last Call = of > = -----------------------------+--------------------------------------------= -- > Reporter: jpv@=85 | Owner: jpv@=85 =20 > Type: defect | Status: new =20 > Priority: major | Milestone: =20 > Component: routing-metrics | Version: =20 > Severity: In WG Last Call | Keywords: =20 > = -----------------------------+--------------------------------------------= -- > Here is the original email (see archives for the details): >=20 > Email sent September 19: >=20 >=20 > "[my summary: it is worth clarifying (1) whether RPL runs in a single > PHY or multiple PHY network, and (2) whether metrics for RPL should be > understood in RPL network only or more universal like across the > Internet. There are also points about whether Rx link energy is as > important as Tx link energy and its usability overall.] >=20 > Hi Colin, >=20 > It does make sense to clarify the usage model first, especially the > assumptions of whether or not RPL runs exclusively on networks made of > single PHY, or multiple PHYs. >=20 > I consider IP kind of work (do we say IPv6? 'router'?) is needed only = if > we consider multiple kinds of PHYs in the same network. Otherwise > bridges, range extenders and other L2 tools are better appropriate = than > IP routers. >=20 > During RPL comments we commented whether RPL draft text should say > _only_ 802.15.4 or would it include PLC too. I think RPL draft text > saying _only_ 802.15.4 would make subsequent metrics and security text > much easier. However, it was insisted PLC should be there in the = draft. > So I am in that perspective now. >=20 > But does that mean that RPL runs only on a network consisting of PLC > devices, and on another network of 15.4 devices (separated by an Edge > Router)? Or does it mean RPL runs in a network mixing 15.4 devices > with PLC devices each being an RPL router? >=20 > This was never clear. >=20 > Alex Petrescu" >=20 > --=20 > Ticket URL: > roll >=20 From trac@tools.ietf.org Thu Oct 7 11:11: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 E09B13A7176 for ; Thu, 7 Oct 2010 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 tKUFSAjm92o3 for ; Thu, 7 Oct 2010 11:11:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 33A5D3A700A for ; Thu, 7 Oct 2010 11:11:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P3uxf-00018s-B4; Thu, 07 Oct 2010 11:12:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 07 Oct 2010 18:12:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/80#comment:3 Message-ID: <064.702689a2a264ee03e2cd192c720ac007@tools.ietf.org> References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #80 (closed): RPL across Multiple PHY/MAC: comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt 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, 07 Oct 2010 18:11:59 -0000 #80: RPL across Multiple PHY/MAC: comment received during WG Last Call of draft- ietf-roll-routing-metrics-09.txt -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: "Summary of replies provided by JP on the list RPL is a L3 routing protocol, which by itself answers (hopefully) your first question. Further, this is clearly stated in the charter. With regards to your second question, these metrics are RPL metrics. Answering the second question, “How different is it from other L3 routing protocol such as OSPF with regards to the routing metrics in a routing domain that comprises different PHY/MAC”. It is not. Consider an ISIS L2 for example. As you probably know, you have routing metrics and in most cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, ...). You still use a metric for ISIS that reflects a link characteristic." Metrics are applicable to all PHY/MAC. Closes the ticket. -- Ticket URL: roll From alexandru.petrescu@gmail.com Thu Oct 7 11:41: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 A69F03A6F71 for ; Thu, 7 Oct 2010 11:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.497, 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 FKsP6w13FUyk for ; Thu, 7 Oct 2010 11:41:08 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E1B6B3A6F35 for ; Thu, 7 Oct 2010 11:41:06 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 85E1094007C; Thu, 7 Oct 2010 20:42:03 +0200 (CEST) Message-ID: <4CAE1473.7070705@gmail.com> Date: Thu, 07 Oct 2010 20:41:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JP Vasseur References: <055.b124cb26f77532ccc420c7607a2dc34c@tools.ietf.org> <064.08ff4a8755738b2ad6a34859fc33e9fc@tools.ietf.org> <8164.1286300125@marajade.sandelman.ca> <005501cb6533$92b90e90$b82b2bb0$@com> <169F5B72-D557-4DA1-93D7-A278DAF65ED7@cisco.com> <4CAC7A16.5010202@gmail.com> <3F895C97-B539-4D6C-9EE0-028C1C3AE635@cisco.com> <4CACE795.3010300@gmail.com> <6F660D44-6313-4275-8BA1-9FFE7961904D@cisco.com> In-Reply-To: <6F660D44-6313-4275-8BA1-9FFE7961904D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101007-1, 07/10/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] RPL multiple PHY/MAC and Hop Limit field (was: [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:41:09 -0000 JP - I adapt the subject line to reflect one RPL issue (not metrics): multiple PHY/MAC interfaces and the Hop Limit value. Le 07/10/2010 20:10, JP Vasseur a crit : > > On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote: > >> Le 06/10/2010 19:55, JP Vasseur a crit : >>> Hi Alex, >>> >>> On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: >>> >>>> Le 06/10/2010 12:03, JP Vasseur a crit : >>>>> I think that the title capture the topic. I'll update and >>>>> propose a resolution to close. >>>> >>>> JP, when closing this issue, please clarify: >>>> >>>> - every RPL message has src and dst address scoped as _link_ >>>> local, i.e. a single link, a single PHY/MAC. This contradicts >>>> the multiple PHY/MAC perspective, because a single link can't >>>> be connecting interfaces using different MAC/PHY. >>>> >>>> I am not sure I am clear... >>>> >>> >>> I am not clear about your question ... why is it different from >>> all other L3 routing ? >> >> Hi JP - I see what you mean, I remember you already said that, >> sorry. >> >> Yes, other routing protocosl sending their flooding messages on >> link-scoped multicast addresses (RIP, OSPF) are implemented on >> routers having multiple interfaces, thus possibly multiple >> PHY/MAC, originating new flooding messages with another src >> address topologically valid on that link. >> >> Should I understand that RPL router doing multiple PHY/MAC has at >> least two interfaces? > > Yes Ok. Then, does RPL forward an RPL packet between two interfaces? I suppose it does not, because the src address is link-local address (except DAO in non-storing mode). >> Should I understand that most RPL Routers have at least two >> interfaces? > > Not sure we can say "most" RPL router have at least two interfaces > but the point here is that RPL can be used in networks with multiple > PHY/MAC. In this case, some of the routers obviously have multiple > interfaces. YEs, I agree with this view: some of the RPL routers obviously have multiple interfaces. Those who have should say when they generate new RPL messages, what they use as src and dst address, because RPL link-scoped addressed messages wouldn't be forwarded between interfaces. >> If so, is the phrase RPL-12 "Although there may typically be only >> one interface in most application scenarios..." a little bit >> wrong? >> >> And that when receiving a DAO message on one interface RPL Router >> may generate another DAO with a different link-local source >> address on another interface? > > There is no issue there. Similar to other IPv6 routing protocols. One RPL issue here: RPL-12 does not specify the value for the Hop Limit. Other IPv6 routing protocol using link-scoped addresses as src and dst (OSPF) does not forward rt protocol packets across interfaces, and the spec explicitely requires to set the Hop Limit to 1. ND spec sets the Hop Limit to 255 and requires the receiver to check it to be 255. RPL-12 is silent about the value for the Hop Limit. It only says its value should be decremented when forwarding (which is good for a typical router, rt protocol or not); but RPL link-scoped packets aren't typically forwarded. So it should say what it does about the Hop Limit - the default value? Does the receiver do anything special when receiving a certain value of the Hop Limit? Wireshark dumps of RPL show it as 255, which may be too big knowing these packets are never forwarded. If we want it 255 then it makes sense to write down that the receiver checks it to be 255 ensuring the packet wasn't forwarded (avoid attacks). IF we want it 1 then it makes sense to require originators to set it to 1, and the well behaving intermediate routers will drop it, again avoid attacks. >> Or are the DAO messages propagated without modifying the src >> address? >> >> RPL-12 says "If the D flag is cleared then the source address of >> the IPv6 packet MUST be the DODAGID...The DODAGID in this case >> will be the reachable IPv6 address of node A" - sounds as if there >> is _only_ one address of node A? But a node with multiple >> interfaces has multiple link-local addresses. > > Depends where you DAG goes ... WEll a DAG goes several directions. Alex [...] >>> Same reasoning applies to ETX. Now, note that the metric ID does >>> not mandate for all RPL networks to support all of the specified >>> metrics of course. Further, one may decide to specify a RPL >>> metric that is relevant for a specific PHY/MAC: RPL specifies >>> what a node is supposed to do when it does not >>> understand/support a metric (leaf node). This is a deployment >>> issue. This is very similar to what is done with other routing >>> protocols. >> >> In this sense, I think further work is needed on the common >> metrics to support multiple PHY/MACs. > > The statement is way too vague to help. As you can see all of the > metrics proposed can be used for various "lossy" PHY/MAC. Nothing > PHY/MAC specific. > > Hope this helps. > > Thanks. > > JP. > >> >> Alex >> >>> >>> Hope that helps. >>> >>> JP. >>> >>>> I may be wrong but that's how I see it. >>>> >>>> Alex >>>> >>>>> Cheers. >>>>> >>>>> JP. >>>>> >>>>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>>>> >>>>>> I agree with Colin This ticket misses the essence of the >>>>>> real issue which Colin and Alex discussed, as Colin >>>>>> clarified in one of his responses to my below concern. >>>>>> >>>>>> >>>>>> Regards, Yoav >>>>>> >>>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn >>>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP >>>>>> Vasseur'; 'Michael Richardson' Cc: roll@ietf.org Subject: >>>>>> Re: [Roll] [roll] routing-metrics #80 (new): RPL across >>>>>> Multiple PHY/MAC: comment received during WG Last Call of >>>>>> >>>>>> Hello, >>>>>> >>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>> scope. >>>>>> >>>>>> The original issue was only about if the routing metrics >>>>>> would work across multiple MAC/PHY. The issue was quickly >>>>>> blown out of context to become about RPL in general, which >>>>>> of course will work across multiple MAC/PHY. >>>>>> >>>>>> But it wasn't a real issue anyway, just some discussion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> -Colin >>>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur >>>>>> Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc: >>>>>> roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics >>>>>> #80 (new): RPL across Multiple PHY/MAC: comment received >>>>>> during WG Last Call of >>>>>> >>>>>> >>>>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>>>> >>>>>>> >>>>>>>>>>>> "roll" == roll issue >>>>>>>>>>>> tracker writes: >>>>>>> roll> I am seeking for WG confirmation that these use >>>>>>> cases are roll> covered well by RPL (as a route over >>>>>>> media and link layer roll> agnostic protocol). >>>>>>> Otherwise, I think this is a significant roll> >>>>>>> short-coming of the protocol. >>>>>>> >>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>> scope. >>>>>> >>>>>> They are (even in the charter !) but I wanted to close one >>>>>> ticket per item raised during WG LC. We'll now close the >>>>>> tickets. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>>> >>>>>>> -- ] He who is tired of Weird Al is tired of life! >>>>>>> | >>>>>> firewalls [ >>>>>>> ] Michael Richardson, Sandelman Software Works, >>>>>>> Ottawa, ON |net >>>>>> architect[ >>>>>>> ] mcr@sandelman.ottawa.on.ca >>>>>>> http://www.sandelman.ottawa.on.ca/ |device >>>>>> driver[ >>>>>>> Kyoto Plus: watch the video >>>>>> >>>>>>> then sign the petition. >>>>>>> _______________________________________________ Roll >>>>>>> mailing list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> >>>>>> _______________________________________________ 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 jpv@cisco.com Thu Oct 7 11:44:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FFB3A6F3E for ; Thu, 7 Oct 2010 11:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=-3.711, BAYES_00=-2.599, HTML_MESSAGE=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 x-4RyUJn68kw for ; Thu, 7 Oct 2010 11:44:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 291AE3A6CB5 for ; Thu, 7 Oct 2010 11:44:32 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAN6wrUyQ/khNgWdsb2JhbACGE5w0FQEBFiIir06NW48AhUcEikCDCIJg X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208,217";a="10876175" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2010 18:45:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o97IjYNP008503 for ; Thu, 7 Oct 2010 18:45:34 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:45:34 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 20:45:32 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-2--1067712798 Date: Thu, 7 Oct 2010 20:45:32 +0200 References: <4CAE1473.7070705@gmail.com> To: ROLL WG Message-Id: <21A679AC-4B1A-401A-B0D4-6905173EDD0B@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Oct 2010 18:45:32.0912 (UTC) FILETIME=[D26ED700:01CB664F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17690.000 X-TM-AS-Result: No--45.944900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Correct Subject Line: Question from Alex 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, 07 Oct 2010 18:44:38 -0000 --Apple-Mail-2--1067712798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Begin forwarded message: > From: Alexandru Petrescu > Date: October 7, 2010 8:41:55 PM GMT+02:00 > To: JP Vasseur > Cc: roll@ietf.org > Subject: Re: RPL multiple PHY/MAC and Hop Limit field (was: [Roll] = [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment = received during WG Last Call of) >=20 > JP - I adapt the subject line to reflect one RPL issue (not metrics): > multiple PHY/MAC interfaces and the Hop Limit value. >=20 > Le 07/10/2010 20:10, JP Vasseur a =E9crit : >>=20 >> On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote: >>=20 >>> Le 06/10/2010 19:55, JP Vasseur a =E9crit : >>>> Hi Alex, >>>>=20 >>>> On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: >>>>=20 >>>>> Le 06/10/2010 12:03, JP Vasseur a =E9crit : >>>>>> I think that the title capture the topic. I'll update and >>>>>> propose a resolution to close. >>>>>=20 >>>>> JP, when closing this issue, please clarify: >>>>>=20 >>>>> - every RPL message has src and dst address scoped as _link_ >>>>> local, i.e. a single link, a single PHY/MAC. This contradicts >>>>> the multiple PHY/MAC perspective, because a single link can't >>>>> be connecting interfaces using different MAC/PHY. >>>>>=20 >>>>> I am not sure I am clear... >>>>>=20 >>>>=20 >>>> I am not clear about your question ... why is it different from >>>> all other L3 routing ? >>>=20 >>> Hi JP - I see what you mean, I remember you already said that, >>> sorry. >>>=20 >>> Yes, other routing protocosl sending their flooding messages on >>> link-scoped multicast addresses (RIP, OSPF) are implemented on >>> routers having multiple interfaces, thus possibly multiple >>> PHY/MAC, originating new flooding messages with another src >>> address topologically valid on that link. >>>=20 >>> Should I understand that RPL router doing multiple PHY/MAC has at >>> least two interfaces? >>=20 >> Yes >=20 > Ok. >=20 > Then, does RPL forward an RPL packet between two interfaces? >=20 > I suppose it does not, because the src address is link-local address > (except DAO in non-storing mode). >=20 >>> Should I understand that most RPL Routers have at least two >>> interfaces? >>=20 >> Not sure we can say "most" RPL router have at least two interfaces >> but the point here is that RPL can be used in networks with multiple >> PHY/MAC. In this case, some of the routers obviously have multiple >> interfaces. >=20 > YEs, I agree with this view: some of the RPL routers obviously have > multiple interfaces. Those who have should say when they generate new > RPL messages, what they use as src and dst address, because RPL > link-scoped addressed messages wouldn't be forwarded between = interfaces. >=20 >>> If so, is the phrase RPL-12 "Although there may typically be only >>> one interface in most application scenarios..." a little bit >>> wrong? >>>=20 >>> And that when receiving a DAO message on one interface RPL Router >>> may generate another DAO with a different link-local source >>> address on another interface? >>=20 >> There is no issue there. Similar to other IPv6 routing protocols. >=20 > One RPL issue here: RPL-12 does not specify the value for the Hop = Limit. >=20 > Other IPv6 routing protocol using link-scoped addresses as src and dst > (OSPF) does not forward rt protocol packets across interfaces, and the > spec explicitely requires to set the Hop Limit to 1. >=20 > ND spec sets the Hop Limit to 255 and requires the receiver to check = it > to be 255. >=20 > RPL-12 is silent about the value for the Hop Limit. It only says its > value should be decremented when forwarding (which is good for a = typical > router, rt protocol or not); but RPL link-scoped packets aren't > typically forwarded. So it should say what it does about the Hop = Limit > - the default value? Does the receiver do anything special when > receiving a certain value of the Hop Limit? >=20 > Wireshark dumps of RPL show it as 255, which may be too big knowing > these packets are never forwarded. >=20 > If we want it 255 then it makes sense to write down that the receiver > checks it to be 255 ensuring the packet wasn't forwarded (avoid = attacks). >=20 > IF we want it 1 then it makes sense to require originators to set it = to > 1, and the well behaving intermediate routers will drop it, again = avoid > attacks. >=20 >>> Or are the DAO messages propagated without modifying the src >>> address? >>>=20 >>> RPL-12 says "If the D flag is cleared then the source address of >>> the IPv6 packet MUST be the DODAGID...The DODAGID in this case >>> will be the reachable IPv6 address of node A" - sounds as if there >>> is _only_ one address of node A? But a node with multiple >>> interfaces has multiple link-local addresses. >>=20 >> Depends where you DAG goes ... >=20 > WEll a DAG goes several directions. >=20 > Alex >=20 > [...] >>>> Same reasoning applies to ETX. Now, note that the metric ID does >>>> not mandate for all RPL networks to support all of the specified >>>> metrics of course. Further, one may decide to specify a RPL >>>> metric that is relevant for a specific PHY/MAC: RPL specifies >>>> what a node is supposed to do when it does not >>>> understand/support a metric (leaf node). This is a deployment >>>> issue. This is very similar to what is done with other routing >>>> protocols. >>>=20 >>> In this sense, I think further work is needed on the common >>> metrics to support multiple PHY/MACs. >>=20 >> The statement is way too vague to help. As you can see all of the >> metrics proposed can be used for various "lossy" PHY/MAC. Nothing >> PHY/MAC specific. >>=20 >> Hope this helps. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Hope that helps. >>>>=20 >>>> JP. >>>>=20 >>>>> I may be wrong but that's how I see it. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>> Cheers. >>>>>>=20 >>>>>> JP. >>>>>>=20 >>>>>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>>>>>=20 >>>>>>> I agree with Colin This ticket misses the essence of the >>>>>>> real issue which Colin and Alex discussed, as Colin >>>>>>> clarified in one of his responses to my below concern. >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards, Yoav >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn >>>>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP >>>>>>> Vasseur'; 'Michael Richardson' Cc: roll@ietf.org Subject: >>>>>>> Re: [Roll] [roll] routing-metrics #80 (new): RPL across >>>>>>> Multiple PHY/MAC: comment received during WG Last Call of >>>>>>>=20 >>>>>>> Hello, >>>>>>>=20 >>>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>>> scope. >>>>>>>=20 >>>>>>> The original issue was only about if the routing metrics >>>>>>> would work across multiple MAC/PHY. The issue was quickly >>>>>>> blown out of context to become about RPL in general, which >>>>>>> of course will work across multiple MAC/PHY. >>>>>>>=20 >>>>>>> But it wasn't a real issue anyway, just some discussion. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> -Colin >>>>>>>=20 >>>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur >>>>>>> Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc: >>>>>>> roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics >>>>>>> #80 (new): RPL across Multiple PHY/MAC: comment received >>>>>>> during WG Last Call of >>>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>>>> "roll" =3D=3D roll issue >>>>>>>>>>>>> tracker writes: >>>>>>>> roll> I am seeking for WG confirmation that these use >>>>>>>> cases are roll> covered well by RPL (as a route over >>>>>>>> media and link layer roll> agnostic protocol). >>>>>>>> Otherwise, I think this is a significant roll> >>>>>>>> short-coming of the protocol. >>>>>>>>=20 >>>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>>> scope. >>>>>>>=20 >>>>>>> They are (even in the charter !) but I wanted to close one >>>>>>> ticket per item raised during WG LC. We'll now close the >>>>>>> tickets. >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> JP. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- ] He who is tired of Weird Al is tired of life! >>>>>>>> | >>>>>>> firewalls [ >>>>>>>> ] Michael Richardson, Sandelman Software Works, >>>>>>>> Ottawa, ON |net >>>>>>> architect[ >>>>>>>> ] mcr@sandelman.ottawa.on.ca >>>>>>>> http://www.sandelman.ottawa.on.ca/ |device >>>>>>> driver[ >>>>>>>> Kyoto Plus: watch the video >>>>>>> >>>>>>>> then sign the petition. >>>>>>>> _______________________________________________ Roll >>>>>>>> mailing list Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>=20 >>>>>>> _______________________________________________ Roll >>>>>>> mailing list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>=20 >>>>>>> _______________________________________________ Roll >>>>>>> mailing list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>> _______________________________________________ Roll mailing >>>>>> list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 --Apple-Mail-2--1067712798 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
From: Alexandru Petrescu = <alexandru.petrescu@gmail.com<= /a>>
Subject: Re: RPL multiple = PHY/MAC and Hop Limit field (was: [Roll] [roll] routing-metrics #80 = (new): RPL across Multiple PHY/MAC: comment received during WG Last Call = of)

JP - I adapt the subject line to = reflect one RPL issue (not metrics):
multiple PHY/MAC interfaces and = the Hop Limit value.

Le 07/10/2010 20:10, JP Vasseur a =E9crit = :

On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu = wrote:

Le 06/10/2010 19:55, JP Vasseur a =E9crit = :
Hi = Alex,

On Oct = 6, 2010, at 3:31 PM, Alexandru Petrescu = wrote:

Le 06/10/2010 12:03, JP Vasseur = a =E9crit = :
I = think that the title capture the topic. I'll update = and
propose = a resolution to = close.

JP, when closing this issue, = please = clarify:

- every RPL message has src and = dst address scoped as = _link_
local, i.e. a single link, a = single PHY/MAC.  This = contradicts
the multiple PHY/MAC = perspective, because a single link = can't
be connecting interfaces using = different = MAC/PHY.

I am not sure I am = clear...


I am = not clear about your question ... why is it different = from
all = other L3 routing ?

Hi JP - I see what you mean, I = remember you already said that,
sorry.

Yes, other routing protocosl = sending their flooding messages = on
link-scoped multicast addresses (RIP, OSPF) are = implemented on
routers having multiple = interfaces, thus possibly = multiple
PHY/MAC, originating new = flooding messages with another = src
address topologically valid on that = link.

Should I understand that RPL = router doing multiple PHY/MAC has = at
least two = interfaces?

Yes

Ok.

Then, does RPL forward = an RPL packet between two interfaces?

I suppose it does not, = because the src address is link-local address
(except DAO in = non-storing mode).

Should I understand that most RPL Routers have at least = two
interfaces?

Not sure we can = say "most" RPL router have at least two = interfaces
but the point here = is that RPL can be used in networks with = multiple
PHY/MAC. In this = case, some of the routers obviously have = multiple
interfaces.

YEs, I agree with this = view: some of the RPL routers obviously have
multiple interfaces. =  Those who have should say when they generate new
RPL messages, = what they use as src and dst address, because RPL
link-scoped = addressed messages wouldn't be forwarded between = interfaces.

If = so, is the phrase RPL-12 "Although there may typically be = only
one interface in most application scenarios..." a little = bit
wrong?

And that when receiving a DAO = message on one interface RPL = Router
may generate another DAO with a different link-local = source
address on another = interface?

There is no = issue there. Similar to other IPv6 routing = protocols.

One RPL issue here: RPL-12 does not = specify the value for the Hop Limit.

Other IPv6 routing protocol = using link-scoped addresses as src and dst
(OSPF) does not forward rt = protocol packets across interfaces, and the
spec explicitely requires = to set the Hop Limit to 1.

ND spec sets the Hop Limit to 255 and = requires the receiver to check it
to be 255.

RPL-12 is silent = about the value for the Hop Limit.  It only says its
value = should be decremented when forwarding (which is good for a = typical
router, rt protocol or not); but RPL link-scoped packets = aren't
typically forwarded.  So it should say what it does about = the Hop Limit
- the default value?  Does the receiver do = anything special when
receiving a certain value of the Hop = Limit?

Wireshark dumps of RPL show it as 255, which may be too = big knowing
these packets are never forwarded.

If we want it = 255 then it makes sense to write down that the receiver
checks it to = be 255 ensuring the packet wasn't forwarded (avoid attacks).

IF = we want it 1 then it makes sense to require originators to set it = to
1, and the well behaving intermediate routers will drop it, again = avoid
attacks.

Or are the DAO messages propagated without modifying the = src
address?

RPL-12 says "If the D flag is = cleared then the source address = of
the IPv6 packet MUST be the DODAGID...The DODAGID in this = case
will be the reachable IPv6 address of node A" - sounds as = if there
is _only_ one address of node A? =  But a node with multiple
interfaces has multiple = link-local addresses.

Depends where = you DAG goes ...

WEll a DAG goes several = directions.

Alex

[...]
Same = reasoning applies to ETX. Now, note that the metric ID = does
not = mandate for all RPL networks to support all of the = specified
metrics = of course. Further, one may decide to specify a = RPL
metric = that is relevant for a specific PHY/MAC: RPL = specifies
what a = node is supposed to do when it does = not
understand/support a metric (leaf node). This is a = deployment
issue. = This is very similar to what is done with other = routing
protocols.

In this sense, I think further = work is needed on the common
metrics to support multiple = PHY/MACs.

The statement = is way too vague to help. As you can see all of = the
metrics proposed can be = used for various "lossy" PHY/MAC. Nothing
PHY/MAC specific.

Hope this = helps.

Thanks.

JP.


Alex


Hope = that helps.

JP.

I may be wrong but that's how I = see = it.

Alex
=

Cheers.

JP.
<= /blockquote>

On Oct = 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel = wrote:

I agree with Colin This ticket = misses the essence of = the
real issue which Colin and Alex = discussed, as = Colin
=
clarified in one of his responses to my below = concern.


Regards,= = Yoav
<= /blockquote>


-----Original Message----- From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] = On Behalf Of Colin = O'Flynn
Sent: = Wednesday, October 06, 2010 10:51 AM To: = 'JP
Vasseur'; 'Michael Richardson' = Cc: roll@ietf.org = Subject:
Re: = [Roll] [roll] routing-metrics #80 (new): RPL = across
Multiple= PHY/MAC: comment received during WG Last Call = of

Hello,

As far as I'm concerned, these = scenarios were always = in
scope.

The = original issue was only about if the routing = metrics
would = work across multiple MAC/PHY. The issue was = quickly
blown = out of context to become about RPL in general, = which
=
of = course will work across multiple = MAC/PHY.

But it = wasn't a real issue anyway, just some = discussion.

Regards,

-Colin

-----Original Message----- From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] = On Behalf Of JP = Vasseur
Sent: = October 6, 2010 5:05 AM To: Michael Richardson = Cc:
roll@ietf.org Subject: Re: [Roll] = [roll] = routing-metrics
#80 = (new): RPL across Multiple PHY/MAC: comment = received
during = WG Last Call = of


On Oct = 5, 2010, at 7:35 PM, Michael Richardson = wrote:


"roll" = =3D=3D roll = issue
=
tracker<trac@tools.ietf.org> = writes:
roll> =     I am seeking for WG confirmation that these = use
cases are roll> =    covered well by RPL (as a route = over
<= /blockquote>
media and link layer roll> =    agnostic = protocol).
Otherwise, I think this is a = significant = roll>
short-coming of the = protocol.

As far as I'm concerned, these = scenarios were always = in
scope.

They = are (even in the charter !) but I wanted to close = one
ticket per item raised during = WG LC. We'll now close = the
tickets.

Thanks.

JP.
<= /blockquote>


-- ] =       He who is tired of Weird Al is tired = of = life!
=
|
firewalls =  [
]   Michael = Richardson, Sandelman Software = Works,
Ottawa, ON = |net
<= /blockquote>
architect[
] mcr@sandelman.ottawa.on.ca<= br>
http://www.sandelman.ottawa.on= .ca/ = |device
driver[
Kyoto Plus: watch the = video
=
<http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE>
then = sign the = petition.
_______________________________________________ = Roll
<= /blockquote>
mailing list Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

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

_______________________________________________ = Roll
<= /blockquote>
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-2--1067712798-- From alexandru.petrescu@gmail.com Thu Oct 7 11:47: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 4D54E3A6CB5 for ; Thu, 7 Oct 2010 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.493, 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 nKu3hZqSEJa4 for ; Thu, 7 Oct 2010 11:47:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEA93A6F3E for ; Thu, 7 Oct 2010 11:47:18 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8DDA6940011 for ; Thu, 7 Oct 2010 20:48:17 +0200 (CEST) Message-ID: <4CAE15E9.90405@gmail.com> Date: Thu, 07 Oct 2010 20:48:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101007-1, 07/10/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Question from Alex 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, 07 Oct 2010 18:47:23 -0000 Corrected subject line. Le 07/10/2010 20:10, JP Vasseur a crit : > > On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote: > >> Le 06/10/2010 19:55, JP Vasseur a crit : >>> Hi Alex, >>> >>> On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote: >>> >>>> Le 06/10/2010 12:03, JP Vasseur a crit : >>>>> I think that the title capture the topic. I'll update and >>>>> propose a resolution to close. >>>> >>>> JP, when closing this issue, please clarify: >>>> >>>> - every RPL message has src and dst address scoped as _link_ >>>> local, i.e. a single link, a single PHY/MAC. This contradicts >>>> the multiple PHY/MAC perspective, because a single link can't >>>> be connecting interfaces using different MAC/PHY. >>>> >>>> I am not sure I am clear... >>>> >>> >>> I am not clear about your question ... why is it different from >>> all other L3 routing ? >> >> Hi JP - I see what you mean, I remember you already said that, >> sorry. >> >> Yes, other routing protocosl sending their flooding messages on >> link-scoped multicast addresses (RIP, OSPF) are implemented on >> routers having multiple interfaces, thus possibly multiple >> PHY/MAC, originating new flooding messages with another src >> address topologically valid on that link. >> >> Should I understand that RPL router doing multiple PHY/MAC has at >> least two interfaces? > > Yes Ok. Then, does RPL forward an RPL packet between two interfaces? I suppose it does not, because the src address is link-local address (except DAO in non-storing mode). >> Should I understand that most RPL Routers have at least two >> interfaces? > > Not sure we can say "most" RPL router have at least two interfaces > but the point here is that RPL can be used in networks with multiple > PHY/MAC. In this case, some of the routers obviously have multiple > interfaces. YEs, I agree with this view: some of the RPL routers obviously have multiple interfaces. Those who have should say when they generate new RPL messages, what they use as src and dst address, because RPL link-scoped addressed messages wouldn't be forwarded between interfaces. >> If so, is the phrase RPL-12 "Although there may typically be only >> one interface in most application scenarios..." a little bit >> wrong? >> >> And that when receiving a DAO message on one interface RPL Router >> may generate another DAO with a different link-local source >> address on another interface? > > There is no issue there. Similar to other IPv6 routing protocols. One RPL issue here: RPL-12 does not specify the value for the Hop Limit. Other IPv6 routing protocol using link-scoped addresses as src and dst (OSPF) does not forward rt protocol packets across interfaces, and the spec explicitely requires to set the Hop Limit to 1. ND spec sets the Hop Limit to 255 and requires the receiver to check it to be 255. RPL-12 is silent about the value for the Hop Limit. It only says its value should be decremented when forwarding (which is good for a typical router, rt protocol or not); but RPL link-scoped packets aren't typically forwarded. So it should say what it does about the Hop Limit - the default value? Does the receiver do anything special when receiving a certain value of the Hop Limit? Wireshark dumps of RPL show it as 255, which may be too big knowing these packets are never forwarded. If we want it 255 then it makes sense to write down that the receiver checks it to be 255 ensuring the packet wasn't forwarded (avoid attacks). IF we want it 1 then it makes sense to require originators to set it to 1, and the well behaving intermediate routers will drop it, again avoid attacks. >> Or are the DAO messages propagated without modifying the src >> address? >> >> RPL-12 says "If the D flag is cleared then the source address of >> the IPv6 packet MUST be the DODAGID...The DODAGID in this case >> will be the reachable IPv6 address of node A" - sounds as if there >> is _only_ one address of node A? But a node with multiple >> interfaces has multiple link-local addresses. > > Depends where you DAG goes ... WEll a DAG goes several directions. Alex [...] >>> Same reasoning applies to ETX. Now, note that the metric ID does >>> not mandate for all RPL networks to support all of the specified >>> metrics of course. Further, one may decide to specify a RPL >>> metric that is relevant for a specific PHY/MAC: RPL specifies >>> what a node is supposed to do when it does not >>> understand/support a metric (leaf node). This is a deployment >>> issue. This is very similar to what is done with other routing >>> protocols. >> >> In this sense, I think further work is needed on the common >> metrics to support multiple PHY/MACs. > > The statement is way too vague to help. As you can see all of the > metrics proposed can be used for various "lossy" PHY/MAC. Nothing > PHY/MAC specific. > > Hope this helps. > > Thanks. > > JP. > >> >> Alex >> >>> >>> Hope that helps. >>> >>> JP. >>> >>>> I may be wrong but that's how I see it. >>>> >>>> Alex >>>> >>>>> Cheers. >>>>> >>>>> JP. >>>>> >>>>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote: >>>>> >>>>>> I agree with Colin This ticket misses the essence of the >>>>>> real issue which Colin and Alex discussed, as Colin >>>>>> clarified in one of his responses to my below concern. >>>>>> >>>>>> >>>>>> Regards, Yoav >>>>>> >>>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn >>>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP >>>>>> Vasseur'; 'Michael Richardson' Cc: roll@ietf.org Subject: >>>>>> Re: [Roll] [roll] routing-metrics #80 (new): RPL across >>>>>> Multiple PHY/MAC: comment received during WG Last Call of >>>>>> >>>>>> Hello, >>>>>> >>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>> scope. >>>>>> >>>>>> The original issue was only about if the routing metrics >>>>>> would work across multiple MAC/PHY. The issue was quickly >>>>>> blown out of context to become about RPL in general, which >>>>>> of course will work across multiple MAC/PHY. >>>>>> >>>>>> But it wasn't a real issue anyway, just some discussion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> -Colin >>>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur >>>>>> Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc: >>>>>> roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics >>>>>> #80 (new): RPL across Multiple PHY/MAC: comment received >>>>>> during WG Last Call of >>>>>> >>>>>> >>>>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote: >>>>>> >>>>>>> >>>>>>>>>>>> "roll" == roll issue >>>>>>>>>>>> tracker writes: >>>>>>> roll> I am seeking for WG confirmation that these use >>>>>>> cases are roll> covered well by RPL (as a route over >>>>>>> media and link layer roll> agnostic protocol). >>>>>>> Otherwise, I think this is a significant roll> >>>>>>> short-coming of the protocol. >>>>>>> >>>>>>> As far as I'm concerned, these scenarios were always in >>>>>>> scope. >>>>>> >>>>>> They are (even in the charter !) but I wanted to close one >>>>>> ticket per item raised during WG LC. We'll now close the >>>>>> tickets. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>>> >>>>>>> -- ] He who is tired of Weird Al is tired of life! >>>>>>> | >>>>>> firewalls [ >>>>>>> ] Michael Richardson, Sandelman Software Works, >>>>>>> Ottawa, ON |net >>>>>> architect[ >>>>>>> ] mcr@sandelman.ottawa.on.ca >>>>>>> http://www.sandelman.ottawa.on.ca/ |device >>>>>> driver[ >>>>>>> Kyoto Plus: watch the video >>>>>> >>>>>>> then sign the petition. >>>>>>> _______________________________________________ Roll >>>>>>> mailing list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> >>>>>> _______________________________________________ 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 jpv@cisco.com Thu Oct 7 23:57: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 53FA53A676A for ; Thu, 7 Oct 2010 23:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.286 X-Spam-Level: X-Spam-Status: No, score=-110.286 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+RfMbub5NPp for ; Thu, 7 Oct 2010 23:57:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CCF193A672F for ; Thu, 7 Oct 2010 23:57:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8GAF9drkyrR7H+/2dsb2JhbACaLQGBVYZAcZ4snEqFRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,301,1283731200"; d="scan'208,217";a="266340751" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Oct 2010 06:58:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o986wArj012586; Fri, 8 Oct 2010 06:58:12 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 08:58:11 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 08:58:10 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-47--1023755444 Date: Fri, 8 Oct 2010 08:58:09 +0200 References: <36DC9F5F-D776-4E68-8639-12303242C4CC@cisco.com> To: phoebus@ieee.org Message-Id: X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 08 Oct 2010 06:58:10.0806 (UTC) FILETIME=[2B612960:01CB66B6] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17690.005 X-TM-AS-Result: No--33.649200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: [Roll] Fwd: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A 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: Fri, 08 Oct 2010 06:57:11 -0000 --Apple-Mail-47--1023755444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Begin forwarded message: > From: JP Vasseur > Date: October 8, 2010 8:45:11 AM GMT+02:00 > To: phoebus@ieee.org > Subject: Fwd: [roll] routing-metrics #81 (new): Comment received = during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- = Specifying how to combine metrics in the A field >=20 > Hi Phoebus, >=20 > Thanks for your comment. See below >=20 > Begin forwarded message: >=20 >> From: "roll issue tracker" >> Date: October 5, 2010 4:52:59 PM GMT+02:00 >> To: jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [roll] routing-metrics #81 (new): Comment received during WG = Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how = to combine metrics in the A field >> Reply-To: roll@ietf.org >>=20 >> #81: Comment received during WG Last Call of draft-ietf-roll-routing- >> metrics-09.txt --- Specifying how to combine metrics in the A field >> = -----------------------------+--------------------------------------------= -- >> Reporter: jpv@=85 | Owner: jpv@=85 =20 >> Type: defect | Status: new =20 >> Priority: major | Milestone: =20 >> Component: routing-metrics | Version: =20 >> Severity: In WG Last Call | Keywords: =20 >> = -----------------------------+--------------------------------------------= -- >> email sent by Phoebus Chen on September 23 (refer to the archives for = the >> full discussion) >>=20 >> "I'm in the midst of making a pass through routing-metrics-09, and a >> question I (and others) asked earlier keeps coming up back in my = head: >>=20 >> Why are we specifying how to combine the metrics in the DAG metric >> container? Can't it be specified in the OF? >>=20 >> Here was the old thread (way back in April): >> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >> JP's response: >> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >>=20 >> The argument was to not have a flood of new RFCs specifying OFs for = each >> possible new way of combining metrics. OK. >=20 > Indeed. The OF and metrics are decoupled as specified in the text (and = agreed > on the list some time ago) >=20 > " The specification of objective functions used to compute the DAG > built by RPL is out of the scope of this document and will be > specified in other documents. Routing metrics and constraints are > decoupled from the objective function. So a generic objective > function could for example specify the rules to select the best > parents in the DAG, the number of backup parents, etc. Such > objective function can be used with any routing metrics and/or > contraints such as the ones specified in this document. > " >=20 > That being said, this should clarified in the document.=20 > How about rewording this sentence:=20 >=20 > OLD: >=20 > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. >=20 > NEW: >=20 > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. Should multiple = metrics=20 > and/or constraints be present in the DAG Metric Container, their = use > to determine the "best" path can be defined by the Objective = Function. >=20 >=20 >>=20 >> But say that we do want to use a combination of add, max, min, >> multiplication, or some other operator to combine some of these = metrics. >> What do we set in the "A" field of the Routing Metric/Constraint = object >> depicted in Figure 2? I would prefer to replace "A=3D0x03: The = routing >> metric is multiplicative" with "A=3D0x03: The routing metric is = aggregated >> in some other fashion specified by the objective function." >=20 > You are right that all values for the A field being taken, there is no = way to further > define different ways to compute aggregated metrics. We will thus = extend the A > field to 3 bits. Further document could then define a new value for A = specifying=20 > another way to compute the metric or may indicate the presence of a = TLV should > the formula to compute the metric be too complex to be summarized with = one bit. >=20 > The exact same thing could be done for the path cost computation, for = example > should you want to use a counpound metric: add a TLV in the DAG metric=20= > container specifying how multiple metrics should be "combined" to = update the=20 > path cost. >=20 > We will update the document accordingly and close the ticket. >=20 > Thanks for your comments. >=20 > JP. >=20 >> Or, there >> should be a sentence in the specification saying that the objective >> function can "override" and ignore this field (and MUST set A=3D0x00 = if the >> OF plans for the A field to be ignored). >>=20 >> I noticed that the text in Section 8 of routing-metrics-08 : >> "The use of compound metrics, such as a polynomial function of = individual >> metric values, will be described in a future revision of this = document." >> has been removed in routing-metrics-09. Given the rigidity of the A >> field, I'm not sure that we can specify compound metrics in future = OFs. >>=20 >>=20 >> I'll send more comments about the rest of the document soon. >>=20 >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >>=20 >> On 9/16/10 3:56 PM, David Culler wrote: >> The routing metrics draft has now gone through 9 revisions over the >> past 16 months, the diffs have narrowed to essentially wording and >> editorial changes, and the comments are few and non-controversial. >> Thus, it appears that consensus has emerged and we can LC this I-D. >>=20 >> This email is to announce Working Group Last Call on >> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >> Sept. 30 2010. Please read it thoroughly and forward all final >> comments to the authors and the WG mailing list. >>=20 >> Thanks all for your good work. We're on a ROLL. >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll" >>=20 >> --=20 >> Ticket URL: >> roll >>=20 >=20 --Apple-Mail-47--1023755444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: JP Vasseur <jpv@cisco.com>
Date: October 8, 2010 = 8:45:11 AM GMT+02:00
Subject: Fwd: [roll] = routing-metrics #81 (new): Comment received during WG Last Call of = draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine = metrics in the A field

Hi Phoebus,

Thanks for your = comment. See below

Begin forwarded message:

From: "roll issue = tracker" <trac@tools.ietf.org>
=
Date: October 5, 2010 = 4:52:59 PM GMT+02:00
Subject: [roll] = routing-metrics #81 (new): Comment received during WG Last Call of = draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine = metrics in the A field
Reply-To: roll@ietf.org

#= 81: Comment received during WG Last Call of = draft-ietf-roll-routing-
metrics-09.txt --- Specifying how to combine = metrics in the A = field
-----------------------------+-----------------------------------= -----------
Reporter:  jpv@=85 =            | =       Owner:  jpv@=85 =        
=     Type:  defect =           | =      Status:  new =          
Priority: =  major =            | =   Milestone: =             &n= bsp; 
Component:  routing-metrics  | =     Version: =             &n= bsp; 
Severity:  In WG Last Call  | =    Keywords: =             &n= bsp; 
-----------------------------+------------------------------= ----------------
email sent by Phoebus Chen on September 23 (refer = to the archives for the
full discussion)

"I'm in the midst = of making a pass through routing-metrics-09, and a
question I (and = others) asked earlier keeps coming up back in my head:

Why are = we specifying how to combine the metrics in the DAG metric
= container?  Can't it be specified in the OF?

Here was the = old thread (way back in April):
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03815.html
= JP's response:
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03768.html

= The argument was to not have a flood of new RFCs specifying OFs for = each
possible new way of combining metrics. =  OK.

Indeed. The OF and = metrics are decoupled as specified in the text (and agreed
on = the list some time ago)

"   The = specification of objective functions used to compute the = DAG
   built by RPL is out of the scope of this = document and will be
   specified in other = documents.  Routing metrics and constraints = are
   decoupled from the objective function. =  So a generic objective
   function could for = example specify the rules to select the best
   = parents in the DAG, the number of backup parents, etc. =  Such
   objective function can be used with = any routing metrics and/or
   contraints such as the = ones specified in this = document.
"

That being said, this = should clarified in the document. 
How about rewording = this sentence: 

OLD:

   Routing metrics and constraints are carried = within the DAG Metric
   Container object defined in = [I-D.ietf-roll-rpl].

NEW:

   Routing metrics and constraints are carried within = the DAG Metric
   Container object defined in = [I-D.ietf-roll-rpl]. Should multiple = metrics 
   and/or constraints be present = in the DAG Metric Container, their use
   to = determine the "best" path can be defined by the Objective = Function.



But say that we do want to use a combination of = add, max, min,
multiplication, or some other operator to combine = some of these metrics.
What do we set in the "A" field of the = Routing Metric/Constraint object
depicted in Figure 2?  I would = prefer to replace "A=3D0x03: The routing
metric is multiplicative" = with "A=3D0x03: The routing metric is aggregated
in some other = fashion specified by the objective function." =

You are right that all values for = the A field being taken, there is no way to further
define = different ways to compute aggregated metrics. We will thus extend the = A
field to 3 bits. Further document could then define a new = value for A specifying 
another way to compute the metric = or may indicate the presence of a TLV should
the formula to = compute the metric be too complex to be summarized with one = bit.

The exact same thing could be done for the = path cost computation, for example
should you want to use a = counpound metric: add a TLV in the DAG metric 
container = specifying how multiple metrics should be "combined" to update = the 
path cost.

We will update = the document accordingly and close the = ticket.

Thanks for your = comments.

JP.

Or, there
should be a sentence in the = specification saying that the objective
function can "override" and = ignore this field (and MUST set A=3D0x00 if the
OF plans for the A = field to be ignored).

I noticed that the text in Section 8 of = routing-metrics-08 :
"The use of compound metrics, such as a = polynomial function of individual
metric values, will be described = in a future revision of this document."
has been removed in = routing-metrics-09.  Given the rigidity of the A
field, I'm not = sure that we can specify compound metrics in future OFs.


= I'll send more comments about the rest of the document soon.

= --
Phoebus Chen
Postdoctoral Researcher
Automatic Control = Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus
On 9/16/10 3:56 PM, David Culler wrote:
The routing metrics = draft has now gone through 9 revisions over the
past 16 months, the = diffs have narrowed to essentially wording and
editorial changes, = and the comments are few and non-controversial.
Thus, it appears = that consensus has emerged and we can LC this I-D.

This email is = to announce Working Group Last Call on
= draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST,
= Sept. 30 2010.  Please read it thoroughly and forward all final
= comments to the authors and the WG mailing list.

Thanks all for = your good work.  We're on a 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"

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


= --Apple-Mail-47--1023755444-- From jpv@cisco.com Fri Oct 8 00:01: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 33D9D3A659A for ; Fri, 8 Oct 2010 00:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.288 X-Spam-Level: X-Spam-Status: No, score=-106.288 tagged_above=-999 required=5 tests=[AWL=-3.690, BAYES_00=-2.599, HTML_MESSAGE=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 LFPfER1TxcOY for ; Fri, 8 Oct 2010 00:01:17 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 57C6D3A63EB for ; Fri, 8 Oct 2010 00:01:16 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAMderkyQ/khNgWdsb2JhbACaLQGBVYZAFQEBFiIiniWcSoVHBIpAgwg X-IronPort-AV: E=Sophos;i="4.57,301,1283731200"; d="scan'208,217";a="10902752" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2010 07:02:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9872JZ5030693; Fri, 8 Oct 2010 07:02:19 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 09:02:19 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 09:02:18 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-48--1023507012 From: JP Vasseur In-Reply-To: Date: Fri, 8 Oct 2010 09:02:18 +0200 Message-Id: References: <36DC9F5F-D776-4E68-8639-12303242C4CC@cisco.com> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 08 Oct 2010 07:02:18.0865 (UTC) FILETIME=[BF3BF610:01CB66B6] Cc: ROLL WG Subject: [Roll] * correction* Re: Fwd: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A 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: Fri, 08 Oct 2010 07:01:19 -0000 --Apple-Mail-48--1023507012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Resending with the correct text this time. On Oct 8, 2010, at 8:58 AM, JP Vasseur wrote: >=20 >=20 > Begin forwarded message: >=20 >> From: JP Vasseur >> Date: October 8, 2010 8:45:11 AM GMT+02:00 >> To: phoebus@ieee.org >> Subject: Fwd: [roll] routing-metrics #81 (new): Comment received = during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- = Specifying how to combine metrics in the A field >>=20 >> Hi Phoebus, >>=20 >> Thanks for your comment. See below >>=20 >> Begin forwarded message: >>=20 >>> From: "roll issue tracker" >>> Date: October 5, 2010 4:52:59 PM GMT+02:00 >>> To: jpv@cisco.com >>> Cc: roll@ietf.org >>> Subject: [roll] routing-metrics #81 (new): Comment received during = WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying = how to combine metrics in the A field >>> Reply-To: roll@ietf.org >>>=20 >>> #81: Comment received during WG Last Call of = draft-ietf-roll-routing- >>> metrics-09.txt --- Specifying how to combine metrics in the A field >>> = -----------------------------+--------------------------------------------= -- >>> Reporter: jpv@=85 | Owner: jpv@=85 =20 >>> Type: defect | Status: new =20 >>> Priority: major | Milestone: =20 >>> Component: routing-metrics | Version: =20 >>> Severity: In WG Last Call | Keywords: =20 >>> = -----------------------------+--------------------------------------------= -- >>> email sent by Phoebus Chen on September 23 (refer to the archives = for the >>> full discussion) >>>=20 >>> "I'm in the midst of making a pass through routing-metrics-09, and a >>> question I (and others) asked earlier keeps coming up back in my = head: >>>=20 >>> Why are we specifying how to combine the metrics in the DAG metric >>> container? Can't it be specified in the OF? >>>=20 >>> Here was the old thread (way back in April): >>> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >>> JP's response: >>> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >>>=20 >>> The argument was to not have a flood of new RFCs specifying OFs for = each >>> possible new way of combining metrics. OK. >>=20 >> Indeed. The OF and metrics are decoupled as specified in the text = (and agreed >> on the list some time ago) >>=20 >> " The specification of objective functions used to compute the DAG >> built by RPL is out of the scope of this document and will be >> specified in other documents. Routing metrics and constraints are >> decoupled from the objective function. So a generic objective >> function could for example specify the rules to select the best >> parents in the DAG, the number of backup parents, etc. Such >> objective function can be used with any routing metrics and/or >> contraints such as the ones specified in this document. >> " >>=20 >> That being said, this should clarified in the document.=20 >> How about rewording this sentence:=20 >>=20 >> OLD: >>=20 >> Routing metrics and constraints are carried within the DAG Metric >> Container object defined in [I-D.ietf-roll-rpl]. >>=20 >> NEW: >>=20 >> Routing metrics and constraints are carried within the DAG Metric >> Container object defined in [I-D.ietf-roll-rpl]. Should multiple = metrics=20 >> and/or constraints be present in the DAG Metric Container, their = use >> to determine the "best" path can be defined by the Objective = Function. >>=20 NEW: Routing metrics and constraints are carried within the DAG Metric Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics=20= and/or constraints be present in the DAG Metric Container, their use to determine the "best" path can be defined by an Objective Function or a new TLV to be defined in future documents. >>=20 >>>=20 >>> But say that we do want to use a combination of add, max, min, >>> multiplication, or some other operator to combine some of these = metrics. >>> What do we set in the "A" field of the Routing Metric/Constraint = object >>> depicted in Figure 2? I would prefer to replace "A=3D0x03: The = routing >>> metric is multiplicative" with "A=3D0x03: The routing metric is = aggregated >>> in some other fashion specified by the objective function." >>=20 >> You are right that all values for the A field being taken, there is = no way to further >> define different ways to compute aggregated metrics. We will thus = extend the A >> field to 3 bits. Further document could then define a new value for A = specifying=20 >> another way to compute the metric or may indicate the presence of a = TLV should >> the formula to compute the metric be too complex to be summarized = with one bit. >>=20 >> The exact same thing could be done for the path cost computation, for = example >> should you want to use a counpound metric: add a TLV in the DAG = metric=20 >> container specifying how multiple metrics should be "combined" to = update the=20 >> path cost. >>=20 >> We will update the document accordingly and close the ticket. >>=20 >> Thanks for your comments. >>=20 >> JP. >>=20 >>> Or, there >>> should be a sentence in the specification saying that the objective >>> function can "override" and ignore this field (and MUST set A=3D0x00 = if the >>> OF plans for the A field to be ignored). >>>=20 >>> I noticed that the text in Section 8 of routing-metrics-08 : >>> "The use of compound metrics, such as a polynomial function of = individual >>> metric values, will be described in a future revision of this = document." >>> has been removed in routing-metrics-09. Given the rigidity of the A >>> field, I'm not sure that we can specify compound metrics in future = OFs. >>>=20 >>>=20 >>> I'll send more comments about the rest of the document soon. >>>=20 >>> -- >>> Phoebus Chen >>> Postdoctoral Researcher >>> Automatic Control Lab, KTH (Royal Institute of Technology) >>> http://www.ee.kth.se/~phoebus >>>=20 >>> On 9/16/10 3:56 PM, David Culler wrote: >>> The routing metrics draft has now gone through 9 revisions over the >>> past 16 months, the diffs have narrowed to essentially wording and >>> editorial changes, and the comments are few and non-controversial. >>> Thus, it appears that consensus has emerged and we can LC this I-D. >>>=20 >>> This email is to announce Working Group Last Call on >>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >>> Sept. 30 2010. Please read it thoroughly and forward all final >>> comments to the authors and the WG mailing list. >>>=20 >>> Thanks all for your good work. We're on a ROLL. >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll" >>>=20 >>> --=20 >>> Ticket URL: >>> roll >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-48--1023507012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


Begin = forwarded message:

From: JP Vasseur <jpv@cisco.com>
Date: October 8, 2010 = 8:45:11 AM GMT+02:00
Subject: Fwd: [roll] = routing-metrics #81 (new): Comment received during WG Last Call of = draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine = metrics in the A field

Hi Phoebus,

Thanks for your = comment. See below

Begin forwarded message:

From: "roll issue = tracker" <trac@tools.ietf.org>
=
Date: October 5, 2010 = 4:52:59 PM GMT+02:00
Subject: [roll] = routing-metrics #81 (new): Comment received during WG Last Call of = draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine = metrics in the A field
Reply-To: roll@ietf.org

#= 81: Comment received during WG Last Call of = draft-ietf-roll-routing-
metrics-09.txt --- Specifying how to combine = metrics in the A = field
-----------------------------+-----------------------------------= -----------
Reporter:  jpv@=85 =            | =       Owner:  jpv@=85 =        
=     Type:  defect =           | =      Status:  new =          
Priority: =  major =            | =   Milestone: =             &n= bsp; 
Component:  routing-metrics  | =     Version: =             &n= bsp; 
Severity:  In WG Last Call  | =    Keywords: =             &n= bsp; 
-----------------------------+------------------------------= ----------------
email sent by Phoebus Chen on September 23 (refer = to the archives for the
full discussion)

"I'm in the midst = of making a pass through routing-metrics-09, and a
question I (and = others) asked earlier keeps coming up back in my head:

Why are = we specifying how to combine the metrics in the DAG metric
= container?  Can't it be specified in the OF?

Here was the = old thread (way back in April):
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03815.html
= JP's response:
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg03768.html

= The argument was to not have a flood of new RFCs specifying OFs for = each
possible new way of combining metrics. =  OK.

Indeed. The OF and = metrics are decoupled as specified in the text (and agreed
on = the list some time ago)

"   The = specification of objective functions used to compute the = DAG
   built by RPL is out of the scope of this = document and will be
   specified in other = documents.  Routing metrics and constraints = are
   decoupled from the objective function. =  So a generic objective
   function could for = example specify the rules to select the best
   = parents in the DAG, the number of backup parents, etc. =  Such
   objective function can be used with = any routing metrics and/or
   contraints such as the = ones specified in this = document.
"

That being said, this = should clarified in the document. 
How about rewording = this sentence: 

OLD:

   Routing metrics and constraints are carried = within the DAG Metric
   Container object defined in = [I-D.ietf-roll-rpl].

NEW:

   Routing metrics and constraints are carried within = the DAG Metric
   Container object defined in = [I-D.ietf-roll-rpl]. Should multiple = metrics 
   and/or constraints be present = in the DAG Metric Container, their use
   to = determine the "best" path can be defined by the Objective = Function.

<= /div>

NEW:

Routin= g metrics and constraints are carried within the DAG = Metric
Container object defined in [I-D.ietf-roll-rpl]. Should = multiple metrics 
and/or constraints be present in the = DAG Metric Container, their use
to determine the "best" path = can be defined by an Objective Function
or a new TLV to be = defined in future documents.



But say that we do = want to use a combination of add, max, min,
multiplication, or some = other operator to combine some of these metrics.
What do we set in = the "A" field of the Routing Metric/Constraint object
depicted in = Figure 2?  I would prefer to replace "A=3D0x03: The routing
= metric is multiplicative" with "A=3D0x03: The routing metric is = aggregated
in some other fashion specified by the objective = function."

You are right that all = values for the A field being taken, there is no way to = further
define different ways to compute aggregated metrics. = We will thus extend the A
field to 3 bits. Further document = could then define a new value for A specifying 
another = way to compute the metric or may indicate the presence of a TLV = should
the formula to compute the metric be too complex to be = summarized with one bit.

The exact same thing = could be done for the path cost computation, for = example
should you want to use a counpound metric: add a TLV = in the DAG metric 
container specifying how multiple = metrics should be "combined" to update the 
path = cost.

We will update the document accordingly = and close the ticket.

Thanks for your = comments.

JP.

Or, there
should be a sentence in the = specification saying that the objective
function can "override" and = ignore this field (and MUST set A=3D0x00 if the
OF plans for the A = field to be ignored).

I noticed that the text in Section 8 of = routing-metrics-08 :
"The use of compound metrics, such as a = polynomial function of individual
metric values, will be described = in a future revision of this document."
has been removed in = routing-metrics-09.  Given the rigidity of the A
field, I'm not = sure that we can specify compound metrics in future OFs.


= I'll send more comments about the rest of the document soon.

= --
Phoebus Chen
Postdoctoral Researcher
Automatic Control = Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus
On 9/16/10 3:56 PM, David Culler wrote:
The routing metrics = draft has now gone through 9 revisions over the
past 16 months, the = diffs have narrowed to essentially wording and
editorial changes, = and the comments are few and non-controversial.
Thus, it appears = that consensus has emerged and we can LC this I-D.

This email is = to announce Working Group Last Call on
= draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST,
= Sept. 30 2010.  Please read it thoroughly and forward all final
= comments to the authors and the WG mailing list.

Thanks all for = your good work.  We're on a 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"

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


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

= --Apple-Mail-48--1023507012-- From phoebus@ieee.org Fri Oct 8 00: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 F1DAB3A6819 for ; Fri, 8 Oct 2010 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke01Ve8hNz9W for ; Fri, 8 Oct 2010 00:26:33 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 1AE1A3A680E for ; Fri, 8 Oct 2010 00:26:33 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 03F2214F3EA for ; Fri, 8 Oct 2010 09:27:07 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id tV8GLVLcRkCP for ; Fri, 8 Oct 2010 09:27:05 +0200 (CEST) X-KTH-Auth: phoebus [130.237.50.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-217.s3.kth.se (dhcp-50-217.s3.kth.se [130.237.50.217]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 8B1AA14F3E9 for ; Fri, 8 Oct 2010 09:27:05 +0200 (CEST) Message-ID: <4CAEC7C8.7060202@ieee.org> Date: Fri, 08 Oct 2010 09:27:04 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Fwd: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 07:26:35 -0000 Forwarding my response to JP to the list. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus -------- Original Message -------- Subject: Re: Fwd: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field Date: Fri, 8 Oct 2010 09:20:00 +0200 From: Phoebus Chen Reply-To: Organization: KTH, Royal Institute of Technology To: JP Vasseur JP, Thanks for addressing my concern about the A bit limiting how to combine the metrics. More detailed comments are inline below. Phoebus On 10/8/10 8:45 AM, JP Vasseur wrote: > Hi Phoebus, > > Thanks for your comment. See below > > Begin forwarded message: > >> *From: *"roll issue tracker" > > >> *Date: *October 5, 2010 4:52:59 PM GMT+02:00 >> *To: *jpv@cisco.com >> *Cc: *roll@ietf.org >> *Subject: **[roll] routing-metrics #81 (new): Comment received during >> WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying >> how to combine metrics in the A field* >> *Reply-To: *roll@ietf.org >> >> #81: Comment received during WG Last Call of draft-ietf-roll-routing- >> metrics-09.txt --- Specifying how to combine metrics in the A field >> -----------------------------+---------------------------------------------- >> Reporter: jpv@ | Owner: jpv@ >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: routing-metrics | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------+---------------------------------------------- >> email sent by Phoebus Chen on September 23 (refer to the archives for the >> full discussion) >> >> "I'm in the midst of making a pass through routing-metrics-09, and a >> question I (and others) asked earlier keeps coming up back in my head: >> >> Why are we specifying how to combine the metrics in the DAG metric >> container? Can't it be specified in the OF? >> >> Here was the old thread (way back in April): >> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >> JP's response: >> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >> >> The argument was to not have a flood of new RFCs specifying OFs for each >> possible new way of combining metrics. OK. > > Indeed. The OF and metrics are decoupled as specified in the text (and > agreed > on the list some time ago) > > " The specification of objective functions used to compute the DAG > built by RPL is out of the scope of this document and will be > specified in other documents. Routing metrics and constraints are > decoupled from the objective function. So a generic objective > function could for example specify the rules to select the best > parents in the DAG, the number of backup parents, etc. Such > objective function can be used with any routing metrics and/or > contraints such as the ones specified in this document. > " > > That being said, this should clarified in the document. > How about rewording this sentence: > > OLD: > > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. > > NEW: > > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics > and/or constraints be present in the DAG Metric Container, their use > to determine the "best" path can be defined by the Objective Function. > It's OK if the reader does not take the new sentence too literally, to mean that *only* when multiple metrics and/or constraints are present does the OF play a role in selecting the best path. You point this out in example 1 on page 9, for paths that avoid low quality links. There, the metrics were aggregated with the max() function, and then the objective function could select the path with the minimum aggregated metric. > >> >> But say that we do want to use a combination of add, max, min, >> multiplication, or some other operator to combine some of these metrics. >> What do we set in the "A" field of the Routing Metric/Constraint object >> depicted in Figure 2? I would prefer to replace "A=0x03: The routing >> metric is multiplicative" with "A=0x03: The routing metric is aggregated >> in some other fashion specified by the objective function." > > You are right that all values for the A field being taken, there is no > way to further > define different ways to compute aggregated metrics. We will thus extend > the A > field to 3 bits. Excellent! > Further document could then define a new value for A > specifying > another way to compute the metric or may indicate the presence of a TLV > should > the formula to compute the metric be too complex to be summarized with > one bit. > > The exact same thing could be done for the path cost computation, for > example > should you want to use a counpound metric: add a TLV in the DAG metric > container specifying how multiple metrics should be "combined" to update > the > path cost. > I think I mentioned this in a follow up email, after Joakim responded to this thread, but it might save overhead to specify how to combine the metrics for an objective function in DODAG Configuration Objects, and not DAG metric containers. I don't think the methods for combining the metrics would change that often for a given objective function (maybe changes only when the network operator reconfigures the network). You don't need to advertise it with every DIO that contains the metrics, which might change more frequently. I'm asking for more work here defining a new container in a DODAG Configuration Object... if this is too much work for last call to add such a feature, what you propose above may be good enough. It would just waste some bandwidth / overhead. Implementations will tell whether this waste is actually a problem and needs to be fixed in a future update / version of RPL. > We will update the document accordingly and close the ticket. > > Thanks for your comments. > > JP. > >> Or, there >> should be a sentence in the specification saying that the objective >> function can "override" and ignore this field (and MUST set A=0x00 if the >> OF plans for the A field to be ignored). >> >> I noticed that the text in Section 8 of routing-metrics-08 : >> "The use of compound metrics, such as a polynomial function of individual >> metric values, will be described in a future revision of this document." >> has been removed in routing-metrics-09. Given the rigidity of the A >> field, I'm not sure that we can specify compound metrics in future OFs. >> >> >> I'll send more comments about the rest of the document soon. >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> >> On 9/16/10 3:56 PM, David Culler wrote: >> The routing metrics draft has now gone through 9 revisions over the >> past 16 months, the diffs have narrowed to essentially wording and >> editorial changes, and the comments are few and non-controversial. >> Thus, it appears that consensus has emerged and we can LC this I-D. >> >> This email is to announce Working Group Last Call on >> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >> Sept. 30 2010. Please read it thoroughly and forward all final >> comments to the authors and the WG mailing list. >> >> Thanks all for your good work. We're on a 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" >> >> -- >> Ticket URL: >> roll >> > From jpv@cisco.com Fri Oct 8 05:06: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 032063A689B for ; Fri, 8 Oct 2010 05:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.266 X-Spam-Level: X-Spam-Status: No, score=-110.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpCEPX-BzGcR for ; Fri, 8 Oct 2010 05:06:39 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A7A3A3A6858 for ; Fri, 8 Oct 2010 05:06:39 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABGmrkyrR7Ht/2dsb2JhbACcA4Y7cZ1tnGSFRwSKQIMI X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="scan'208";a="266464746" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 08 Oct 2010 12:07:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o98C7cSf022286; Fri, 8 Oct 2010 12:07:43 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 14:07:43 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 14:07:42 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <4CAEC620.8000706@ieee.org> Date: Fri, 8 Oct 2010 14:07:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DBB6B15-3DED-4331-AFD5-0CDB11F97760@cisco.com> References: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> <36DC9F5F-D776-4E68-8639-12303242C4CC@cisco.com> <4CAEC620.8000706@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 08 Oct 2010 12:07:42.0737 (UTC) FILETIME=[691CF010:01CB66E1] Cc: ROLL WG Subject: Re: [Roll] [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A 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: Fri, 08 Oct 2010 12:06:42 -0000 Hi, On Oct 8, 2010, at 9:20 AM, Phoebus Chen wrote: > JP, > Thanks for addressing my concern about the A bit limiting how to = combine the metrics. =20 Sure > More detailed comments are inline below. >=20 > Phoebus >=20 > On 10/8/10 8:45 AM, JP Vasseur wrote: >> Hi Phoebus, >>=20 >> Thanks for your comment. See below >>=20 >> Begin forwarded message: >>=20 >>> *From: *"roll issue tracker" >> > >>> *Date: *October 5, 2010 4:52:59 PM GMT+02:00 >>> *To: *jpv@cisco.com >>> *Cc: *roll@ietf.org >>> *Subject: **[roll] routing-metrics #81 (new): Comment received = during >>> WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- = Specifying >>> how to combine metrics in the A field* >>> *Reply-To: *roll@ietf.org >>>=20 >>> #81: Comment received during WG Last Call of = draft-ietf-roll-routing- >>> metrics-09.txt --- Specifying how to combine metrics in the A field >>> = -----------------------------+--------------------------------------------= -- >>> Reporter: jpv@=85 | Owner: jpv@=85 >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: routing-metrics | Version: >>> Severity: In WG Last Call | Keywords: >>> = -----------------------------+--------------------------------------------= -- >>> email sent by Phoebus Chen on September 23 (refer to the archives = for the >>> full discussion) >>>=20 >>> "I'm in the midst of making a pass through routing-metrics-09, and a >>> question I (and others) asked earlier keeps coming up back in my = head: >>>=20 >>> Why are we specifying how to combine the metrics in the DAG metric >>> container? Can't it be specified in the OF? >>>=20 >>> Here was the old thread (way back in April): >>> http://www.ietf.org/mail-archive/web/roll/current/msg03815.html >>> JP's response: >>> http://www.ietf.org/mail-archive/web/roll/current/msg03768.html >>>=20 >>> The argument was to not have a flood of new RFCs specifying OFs for = each >>> possible new way of combining metrics. OK. >>=20 >> Indeed. The OF and metrics are decoupled as specified in the text = (and >> agreed >> on the list some time ago) >>=20 >> " The specification of objective functions used to compute the DAG >> built by RPL is out of the scope of this document and will be >> specified in other documents. Routing metrics and constraints are >> decoupled from the objective function. So a generic objective >> function could for example specify the rules to select the best >> parents in the DAG, the number of backup parents, etc. Such >> objective function can be used with any routing metrics and/or >> contraints such as the ones specified in this document. >> " >>=20 >> That being said, this should clarified in the document. >> How about rewording this sentence: >>=20 >> OLD: >>=20 >> Routing metrics and constraints are carried within the DAG Metric >> Container object defined in [I-D.ietf-roll-rpl]. >>=20 >> NEW: >>=20 >> Routing metrics and constraints are carried within the DAG Metric >> Container object defined in [I-D.ietf-roll-rpl]. Should multiple = metrics >> and/or constraints be present in the DAG Metric Container, their use >> to determine the "best" path can be defined by the Objective = Function. >>=20 >=20 > It's OK if the reader does not take the new sentence too literally, to = mean that *only* when multiple metrics and/or constraints are present = does the OF play a role in selecting the best path. >=20 > You point this out in example 1 on page 9, for paths that avoid low = quality links. There, the metrics were aggregated with the max() = function, and then the objective function could select the path with the = minimum aggregated metric. Correct. >=20 >=20 >>=20 >>>=20 >>> But say that we do want to use a combination of add, max, min, >>> multiplication, or some other operator to combine some of these = metrics. >>> What do we set in the "A" field of the Routing Metric/Constraint = object >>> depicted in Figure 2? I would prefer to replace "A=3D0x03: The = routing >>> metric is multiplicative" with "A=3D0x03: The routing metric is = aggregated >>> in some other fashion specified by the objective function." >>=20 >> You are right that all values for the A field being taken, there is = no >> way to further >> define different ways to compute aggregated metrics. We will thus = extend >> the A >> field to 3 bits. >=20 > Excellent! >=20 > Further document could then define a new value for A Right >> specifying >> another way to compute the metric or may indicate the presence of a = TLV >> should >> the formula to compute the metric be too complex to be summarized = with >> one bit. >>=20 >> The exact same thing could be done for the path cost computation, for >> example >> should you want to use a counpound metric: add a TLV in the DAG = metric >> container specifying how multiple metrics should be "combined" to = update >> the >> path cost. >>=20 >=20 > I think I mentioned this in a follow up email, after Joakim responded = to this thread, but it might save overhead to specify how to combine the = metrics for an objective function in DODAG Configuration Objects, and = not DAG metric containers. I don't think the methods for combining the = metrics would change that often for a given objective function (maybe = changes only when the network operator reconfigures the network). You = don't need to advertise it with every DIO that contains the metrics, = which might change more frequently. That TLV specifying how to combine the metrics could potentially be = somewhere else indeed, agree (to be defined by further document). >=20 > I'm asking for more work here defining a new container in a DODAG = Configuration Object... if this is too much work for last call to add = such a feature, what you propose above may be good enough. =20 Yes this seems to deserve a separate document indeed, if OK with you. Thanks again for the comments (we also owe you some answers about the = Edits - to be done soon). So I'll close that ticket. JP. > It would just waste some bandwidth / overhead. Implementations will = tell whether this waste is actually a problem and needs to be fixed in a = future update / version of RPL. >=20 >> We will update the document accordingly and close the ticket. >>=20 >> Thanks for your comments. >>=20 >> JP. >>=20 >>> Or, there >>> should be a sentence in the specification saying that the objective >>> function can "override" and ignore this field (and MUST set A=3D0x00 = if the >>> OF plans for the A field to be ignored). >>>=20 >>> I noticed that the text in Section 8 of routing-metrics-08 : >>> "The use of compound metrics, such as a polynomial function of = individual >>> metric values, will be described in a future revision of this = document." >>> has been removed in routing-metrics-09. Given the rigidity of the A >>> field, I'm not sure that we can specify compound metrics in future = OFs. >>>=20 >>>=20 >>> I'll send more comments about the rest of the document soon. >>>=20 >>> -- >>> Phoebus Chen >>> Postdoctoral Researcher >>> Automatic Control Lab, KTH (Royal Institute of Technology) >>> http://www.ee.kth.se/~phoebus >>>=20 >>> On 9/16/10 3:56 PM, David Culler wrote: >>> The routing metrics draft has now gone through 9 revisions over the >>> past 16 months, the diffs have narrowed to essentially wording and >>> editorial changes, and the comments are few and non-controversial. >>> Thus, it appears that consensus has emerged and we can LC this I-D. >>>=20 >>> This email is to announce Working Group Last Call on >>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >>> Sept. 30 2010. Please read it thoroughly and forward all final >>> comments to the authors and the WG mailing list. >>>=20 >>> Thanks all for your good work. We're on a ROLL. >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll" >>>=20 >>> -- >>> Ticket URL: >>> roll >>>=20 >>=20 >=20 > --=20 > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus From trac@tools.ietf.org Fri Oct 8 05:24: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 4A99B3A6884 for ; Fri, 8 Oct 2010 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 dtuBr3mYp6T0 for ; Fri, 8 Oct 2010 05:24:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 91B773A6858 for ; Fri, 8 Oct 2010 05:24:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P4C1K-0004Kc-Ig; Fri, 08 Oct 2010 05:25:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Fri, 08 Oct 2010 12:25:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/81#comment:1 Message-ID: <064.4f3c316b1e490782140247c89f3f1dbf@tools.ietf.org> References: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:24:51 -0000 #81: Comment received during WG Last Call of draft-ietf-roll-routing- metrics-09.txt --- Specifying how to combine metrics in the A field Old description: > email sent by Phoebus Chen on September 23 (refer to the archives for the > full discussion) > > "I'm in the midst of making a pass through routing-metrics-09, and a > question I (and others) asked earlier keeps coming up back in my head: > > Why are we specifying how to combine the metrics in the DAG metric > container? Can't it be specified in the OF? > > Here was the old thread (way back in April): > http://www.ietf.org/mail-archive/web/roll/current/msg03815.html > JP's response: > http://www.ietf.org/mail-archive/web/roll/current/msg03768.html > > The argument was to not have a flood of new RFCs specifying OFs for each > possible new way of combining metrics. OK. > > But say that we do want to use a combination of add, max, min, > multiplication, or some other operator to combine some of these metrics. > What do we set in the "A" field of the Routing Metric/Constraint object > depicted in Figure 2? I would prefer to replace "A=0x03: The routing > metric is multiplicative" with "A=0x03: The routing metric is aggregated > in some other fashion specified by the objective function." Or, there > should be a sentence in the specification saying that the objective > function can "override" and ignore this field (and MUST set A=0x00 if the > OF plans for the A field to be ignored). > > I noticed that the text in Section 8 of routing-metrics-08 : > "The use of compound metrics, such as a polynomial function of individual > metric values, will be described in a future revision of this document." > has been removed in routing-metrics-09. Given the rigidity of the A > field, I'm not sure that we can specify compound metrics in future OFs. > > I'll send more comments about the rest of the document soon. > > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > > On 9/16/10 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a 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" New description: email sent by Phoebus Chen on September 23 (refer to the archives for the full discussion) "I'm in the midst of making a pass through routing-metrics-09, and a question I (and others) asked earlier keeps coming up back in my head: Why are we specifying how to combine the metrics in the DAG metric container? Can't it be specified in the OF? Here was the old thread (way back in April): http://www.ietf.org/mail-archive/web/roll/current/msg03815.html JP's response: http://www.ietf.org/mail-archive/web/roll/current/msg03768.html The argument was to not have a flood of new RFCs specifying OFs for each possible new way of combining metrics. OK. But say that we do want to use a combination of add, max, min, multiplication, or some other operator to combine some of these metrics. What do we set in the "A" field of the Routing Metric/Constraint object depicted in Figure 2? I would prefer to replace "A=0x03: The routing metric is multiplicative" with "A=0x03: The routing metric is aggregated in some other fashion specified by the objective function." Or, there should be a sentence in the specification saying that the objective function can "override" and ignore this field (and MUST set A=0x00 if the OF plans for the A field to be ignored). I noticed that the text in Section 8 of routing-metrics-08 : "The use of compound metrics, such as a polynomial function of individual metric values, will be described in a future revision of this document." has been removed in routing-metrics-09. Given the rigidity of the A field, I'm not sure that we can specify compound metrics in future OFs. I'll send more comments about the rest of the document soon. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/16/10 3:56 PM, David Culler wrote: The routing metrics draft has now gone through 9 revisions over the past 16 months, the diffs have narrowed to essentially wording and editorial changes, and the comments are few and non-controversial. Thus, it appears that consensus has emerged and we can LC this I-D. This email is to announce Working Group Last Call on draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. 30 2010. Please read it thoroughly and forward all final comments to the authors and the WG mailing list. Thanks all for your good work. We're on a 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" -- Comment(by jpv@…): The document has been updated in the following fashion: Reply for JP ######### Indeed. The OF and metrics are decoupled as specified in the text (and agreed on the list some time ago) " The specification of objective functions used to compute the DAG built by RPL is out of the scope of this document and will be specified in other documents. Routing metrics and constraints are decoupled from the objective function. So a generic objective function could for example specify the rules to select the best parents in the DAG, the number of backup parents, etc. Such objective function can be used with any routing metrics and/or contraints such as the ones specified in this document. " That being said, this should clarified in the document. How about rewording this sentence: OLD: Routing metrics and constraints are carried within the DAG Metric Container object defined in [I-D.ietf-roll-rpl]. NEW: Routing metrics and constraints are carried within the DAG Metric Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics and/or constraints be present in the DAG Metric Container, their use to determine the "best" path can be defined by an Objective Function or a new TLV to be defined in future documents. other comment But say that we do want to use a combination of add, max, min, multiplication, or some other operator to combine some of these metrics. What do we set in the "A" field of the Routing Metric/Constraint object depicted in Figure 2? I would prefer to replace "A=0x03: The routing metric is multiplicative" with "A=0x03: The routing metric is aggregated in some other fashion specified by the objective function." Reply: You are right that all values for the A field being taken, there is no way to further define different ways to compute aggregated metrics. We will thus extend the A field to 3 bits. Further document could then define a new value for A specifying another way to compute the metric or may indicate the presence of a TLV should the formula to compute the metric be too complex to be summarized with one bit. The exact same thing could be done for the path cost computation, for example should you want to use a counpound metric: add a TLV in the DAG metric container specifying how multiple metrics should be "combined" to update the path cost. -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Ticket URL: roll From jpv@cisco.com Fri Oct 8 06:06:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9ACC3A68B1 for ; Fri, 8 Oct 2010 06:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.268 X-Spam-Level: X-Spam-Status: No, score=-106.268 tagged_above=-999 required=5 tests=[AWL=-3.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGUSkyHXJSYq for ; Fri, 8 Oct 2010 06:06:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D5C0A3A6851 for ; Fri, 8 Oct 2010 06:06:03 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAFK0rkyQ/khNgWdsb2JhbACURYc/hjsVAQEWIiKeT5xchUcEikCDCA X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="scan'208";a="10931257" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2010 13:07:08 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o98D78cX013614; Fri, 8 Oct 2010 13:07:08 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 15:07:08 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 15:07:07 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <4CAF0E96.6060903@ieee.org> Date: Fri, 8 Oct 2010 15:07:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1365AE-9C67-4D9B-B159-1665ACEB6F4A@cisco.com> References: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> <36DC9F5F-D776-4E68-8639-12303242C4CC@cisco.com> <4CAEC620.8000706@ieee.org> <1DBB6B15-3DED-4331-AFD5-0CDB11F97760@cisco.com> <4CAF0E96.6060903@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 08 Oct 2010 13:07:07.0588 (UTC) FILETIME=[B5EE0840:01CB66E9] Cc: ROLL WG Subject: Re: [Roll] [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A 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: Fri, 08 Oct 2010 13:06:05 -0000 Thanks. JP. On Oct 8, 2010, at 2:29 PM, Phoebus Chen wrote: > JP, >=20 > >>> I'm asking for more work here defining a new container in a DODAG = Configuration Object... if this is too much work for last call to add = such a feature, what you propose above may be good enough. >>=20 >> Yes this seems to deserve a separate document indeed, if OK with you. >=20 > Yes, it's OK with me. >=20 > --=20 > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus From trac@tools.ietf.org Fri Oct 8 06:06: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 3E83C3A68B2 for ; Fri, 8 Oct 2010 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 eL0Lkk7YDQ7F for ; Fri, 8 Oct 2010 06:06:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 91CA33A689E for ; Fri, 8 Oct 2010 06:06:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P4Cfm-0003qF-Iw; Fri, 08 Oct 2010 06:07:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Fri, 08 Oct 2010 13:07:42 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/81#comment:2 Message-ID: <064.e88f5723117bde4fce8e8f18ccbf7290@tools.ietf.org> References: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #81 (closed): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:06:42 -0000 #81: Comment received during WG Last Call of draft-ietf-roll-routing- metrics-09.txt --- Specifying how to combine metrics in the A field Changes (by jpv@…): * status: new => closed * resolution: => fixed Old description: > email sent by Phoebus Chen on September 23 (refer to the archives for the > full discussion) > > "I'm in the midst of making a pass through routing-metrics-09, and a > question I (and others) asked earlier keeps coming up back in my head: > > Why are we specifying how to combine the metrics in the DAG metric > container? Can't it be specified in the OF? > > Here was the old thread (way back in April): > http://www.ietf.org/mail-archive/web/roll/current/msg03815.html > JP's response: > http://www.ietf.org/mail-archive/web/roll/current/msg03768.html > > The argument was to not have a flood of new RFCs specifying OFs for each > possible new way of combining metrics. OK. > > But say that we do want to use a combination of add, max, min, > multiplication, or some other operator to combine some of these metrics. > What do we set in the "A" field of the Routing Metric/Constraint object > depicted in Figure 2? I would prefer to replace "A=0x03: The routing > metric is multiplicative" with "A=0x03: The routing metric is aggregated > in some other fashion specified by the objective function." Or, there > should be a sentence in the specification saying that the objective > function can "override" and ignore this field (and MUST set A=0x00 if the > OF plans for the A field to be ignored). > > I noticed that the text in Section 8 of routing-metrics-08 : > "The use of compound metrics, such as a polynomial function of individual > metric values, will be described in a future revision of this document." > has been removed in routing-metrics-09. Given the rigidity of the A > field, I'm not sure that we can specify compound metrics in future OFs. > > I'll send more comments about the rest of the document soon. > > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > > On 9/16/10 3:56 PM, David Culler wrote: > The routing metrics draft has now gone through 9 revisions over the > past 16 months, the diffs have narrowed to essentially wording and > editorial changes, and the comments are few and non-controversial. > Thus, it appears that consensus has emerged and we can LC this I-D. > > This email is to announce Working Group Last Call on > draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, > Sept. 30 2010. Please read it thoroughly and forward all final > comments to the authors and the WG mailing list. > > Thanks all for your good work. We're on a 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" New description: email sent by Phoebus Chen on September 23 (refer to the archives for the full discussion) "I'm in the midst of making a pass through routing-metrics-09, and a question I (and others) asked earlier keeps coming up back in my head: Why are we specifying how to combine the metrics in the DAG metric container? Can't it be specified in the OF? Here was the old thread (way back in April): http://www.ietf.org/mail-archive/web/roll/current/msg03815.html JP's response: http://www.ietf.org/mail-archive/web/roll/current/msg03768.html The argument was to not have a flood of new RFCs specifying OFs for each possible new way of combining metrics. OK. But say that we do want to use a combination of add, max, min, multiplication, or some other operator to combine some of these metrics. What do we set in the "A" field of the Routing Metric/Constraint object depicted in Figure 2? I would prefer to replace "A=0x03: The routing metric is multiplicative" with "A=0x03: The routing metric is aggregated in some other fashion specified by the objective function." Or, there should be a sentence in the specification saying that the objective function can "override" and ignore this field (and MUST set A=0x00 if the OF plans for the A field to be ignored). I noticed that the text in Section 8 of routing-metrics-08 : "The use of compound metrics, such as a polynomial function of individual metric values, will be described in a future revision of this document." has been removed in routing-metrics-09. Given the rigidity of the A field, I'm not sure that we can specify compound metrics in future OFs. I'll send more comments about the rest of the document soon. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 9/16/10 3:56 PM, David Culler wrote: The routing metrics draft has now gone through 9 revisions over the past 16 months, the diffs have narrowed to essentially wording and editorial changes, and the comments are few and non-controversial. Thus, it appears that consensus has emerged and we can LC this I-D. This email is to announce Working Group Last Call on draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. 30 2010. Please read it thoroughly and forward all final comments to the authors and the WG mailing list. Thanks all for your good work. We're on a 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" -- -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: roll From phoebus@ieee.org Fri Oct 8 07:09: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 413C83A68CD for ; Fri, 8 Oct 2010 07:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.749 X-Spam-Level: X-Spam-Status: No, score=-105.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV0GZkrY6EKm for ; Fri, 8 Oct 2010 07:09:18 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id B226B3A68BE for ; Fri, 8 Oct 2010 07:09:17 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 3829214F3FC for ; Fri, 8 Oct 2010 16:09:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id b9ugdJv4x8VT for ; Fri, 8 Oct 2010 16:09:46 +0200 (CEST) X-KTH-Auth: phoebus [130.237.50.217] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-217.s3.kth.se (dhcp-50-217.s3.kth.se [130.237.50.217]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C583D14F2D1 for ; Fri, 8 Oct 2010 16:09:46 +0200 (CEST) Message-ID: <4CAF262A.2030304@ieee.org> Date: Fri, 08 Oct 2010 16:09:46 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: roll@ietf.org References: <20100921191745.2814628C106@core3.amsl.com> <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> <13A10841-3C53-4CA0-BE76-74267154C510@cisco.com> In-Reply-To: <13A10841-3C53-4CA0-BE76-74267154C510@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:09:19 -0000 +1. The draft seems like a good starting point. Given the long discussion on "dynamic metrics" in the routing metrics document, it seems like having a hysteresis mechanism will be very good for routing topology stability. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 10/7/10 8:47 AM, JP Vasseur wrote: > Polling again since we got very few replies .... > > On Sep 30, 2010, at 8:56 PM, JP Vasseur wrote: > >> /Hi Omprakash,/ >> / >> / >> /Thanks for the new revision addressing my comments./ >> >> All, >> >> Could you please let us know if you are in favor/opposed of adopting >> draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group >> document ? >> >> Thanks. >> >> JP. >> >> >> On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: >> >>> Dear WG, >>> >>> I just updated the draft to address JP's comment on allowing for leaf >>> nodes. >>> >>> - om_p >>> >>> ---------- Forwarded message ---------- >>> From: IETF I-D Submission Tool >> > >>> Date: Tue, Sep 21, 2010 at 2:17 PM >>> Subject: New Version Notification for >>> draft-gnawali-roll-minrank-hysteresis-of-02 >>> To: gnawali@cs.stanford.edu >>> Cc: pal@cs.stanford.edu >>> >>> >>> >>> A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt >>> has been successfully submitted by Omprakash Gnawali and posted to the >>> IETF repository. >>> >>> Filename: draft-gnawali-roll-minrank-hysteresis-of >>> Revision: 02 >>> Title: The Minimum Rank Objective Function with Hysteresis >>> Creation_date: 2010-09-21 >>> WG ID: Independent Submission >>> Number_of_pages: 8 >>> >>> Abstract: >>> Hysteresis delays the effect of changes in link metric on parent >>> selection. Such delay makes the topology stable despite jitters in >>> link metrics. The Routing Protocol for Low Power and Lossy Networks >>> (RPL) allows the use of objective functions to construct routes that >>> optimize or constrain a routing metric on the paths. This >>> specification describes the Minimum Rank Objective Function with >>> Hysteresis (MRHOF), an objective function that minimizes the node >>> rank in terms of a given metric, while using hysteresis to prevent >>> excessive rank churn. The use of MRHOF with RPL results in nodes >>> selecting stable paths that minimize the given routing metric to the >>> roots of a Directed Acyclic Graph (DAG). >>> >>> >>> >>> The IETF Secretariat. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Fri Oct 8 07:55:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0F23A68C0 for ; Fri, 8 Oct 2010 07:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 hinntuGGQnix for ; Fri, 8 Oct 2010 07:55:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A68333A689C for ; Fri, 8 Oct 2010 07:55:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P4EMf-0000CO-UQ; Fri, 08 Oct 2010 07:56:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Fri, 08 Oct 2010 14:56:05 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/81#comment:3 Message-ID: <064.83a334f6959483d5c302c4a001e6244e@tools.ietf.org> References: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <055.edee39ecfbd031589316075a0ce87543@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #81 (closed): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:55:01 -0000 #81: Comment received during WG Last Call of draft-ietf-roll-routing- metrics-09.txt --- Specifying how to combine metrics in the A field Comment(by jpv@…): Replying to [comment:1 jpv@…]: Reply for JP should read Reply FROM JP > The document has been updated in the following fashion: > > Reply for JP > ######### > > Indeed. The OF and metrics are decoupled as specified in the text (and agreed > on the list some time ago) > > " The specification of objective functions used to compute the DAG > built by RPL is out of the scope of this document and will be > specified in other documents. Routing metrics and constraints are > decoupled from the objective function. So a generic objective > function could for example specify the rules to select the best > parents in the DAG, the number of backup parents, etc. Such > objective function can be used with any routing metrics and/or > contraints such as the ones specified in this document. > " > > That being said, this should clarified in the document. > How about rewording this sentence: > > OLD: > > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. > > NEW: > > Routing metrics and constraints are carried within the DAG Metric > Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics > and/or constraints be present in the DAG Metric Container, their use > to determine the "best" path can be defined by an Objective Function > or a new TLV to be defined in future documents. > > other comment > But say that we do want to use a combination of add, max, min, > multiplication, or some other operator to combine some of these metrics. > What do we set in the "A" field of the Routing Metric/Constraint object > depicted in Figure 2? I would prefer to replace "A=0x03: The routing > metric is multiplicative" with "A=0x03: The routing metric is aggregated > in some other fashion specified by the objective function." > > Reply: > You are right that all values for the A field being taken, there is no way to further > define different ways to compute aggregated metrics. We will thus extend the A > field to 3 bits. Further document could then define a new value for A specifying > another way to compute the metric or may indicate the presence of a TLV should > the formula to compute the metric be too complex to be summarized with one bit. > > The exact same thing could be done for the path cost computation, for example > should you want to use a counpound metric: add a TLV in the DAG metric > container specifying how multiple metrics should be "combined" to update the > path cost. > -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: roll From Adrian.Farrel@huawei.com Sat Oct 9 04:10:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1760C3A69E8 for ; Sat, 9 Oct 2010 04:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, STOX_REPLY_TYPE=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 xgcSI+RGZGn4 for ; Sat, 9 Oct 2010 04:10:29 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id ED9B13A69D9 for ; Sat, 9 Oct 2010 04:10:27 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA00058CSETAP@usaga01-in.huawei.com> for roll@ietf.org; Sat, 09 Oct 2010 04:11:17 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA0000PYSERUR@usaga01-in.huawei.com> for roll@ietf.org; Sat, 09 Oct 2010 04:11:17 -0700 (PDT) Date: Sat, 09 Oct 2010 12:09:51 +0100 From: Adrian Farrel To: draft-ietf-roll-trickle@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-trickle-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 11:10:33 -0000 I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. Thanks you for a really well-written and clear document. Excellent work! On reviewing it, there are a couple of small points I think it would be helpful to sort out to ensure complete understanding from all your readers. I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- idnits (http://tools.ietf.org/tools/idnits/) reports == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Can you fix this, plase. --- Good that you pulled "trickle communication rate" out for attention as a term. Could you also pull out "trickle transmission rate"? --- In section 3 The Trickle algorithm balances the load in such a scenario, as each node's Trickle transmission rate is 1/nth of the Trickle communication rate. Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. No issues with the facts. But this is the first mention of radio channels. Up to this point we would have been quite happy thinking of fixed-line connectivity. Can you tweak something? --- Section 4.1 o The maximum interval size is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define the maximum interval as 16. If the minimum interval is 100ms, then the maximum interval is 100ms * 65536, 6,553.6 seconds, or approximately 109 minutes. There is a slight discrepency in terminology here, and a little tidying that could be done to the expression of the example. The problem comes that you have "maximum interval sixe" as a number of doublings, but you are also trying to state the amount of time it implies. Can I suggest... o The maximum interval size is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define the maximum interval size as 16. If the minimum interval size is 100ms, then the amount of time specified by the maximum interval size of 16 is 100ms * 2^16 = 6,553.6 seconds or approximately 109 minutes. A similar terminology problem shows up in 6.2 Note that mismatched Imin values and matching Imax doubling constants will lead to mismatched Imax values. Can you go through the document and decide whether Imax is the doubling constant or the time period. --- Section 4.2 5. If Trickle hears a transmission that is "inconsistent," the Trickle timer resets. If I is greater than Imin, resetting a Trickle timer sets I to Imin and begins a new interval. If I is equal to Imin, resetting a Trickle timer does nothing. Trickle can also reset the timer in response to external "events." If "resetting a Trickle timer does nothing", how can you justify the word "reset"? Doesn't a new interval always start when the timer is reset? Or are you saying that the timer restarts, but the counter is not reset to zero? --- Section 6.1 OLD Hence, the danger of mismatched k values is uneven transmission load that can deplete the energy of some nodes. NEW Hence, the danger of mismatched k values is uneven transmission load that can deplete the energy of some nodes in a lower-power network. END ...because there is no specific limitation to apply this to low-power networks.. --- Section 6.5 having the parameter describe (k-1) Do you mean k=-1 ? --- Section 6.6 Finally, a protocol SHOULD set k and Imin such that Imin is at least two to three as long as it takes to transmit k packets. s/three as/three times as/ --- Section 9 I am worried about this section being so empty. I don't think the algorithm needs any security work, but I do think that you can give advice on the security implications for protocols that use the algorithm. For example, what would be the impact of a false positive or a false negative? Given that impact, what precautions should a protocol that uses Trickle take? For example, in Section 6 you have: It is RECOMMENDED that a protocol which uses Trickle include mechanisms to inform nodes of configuration parameters at runtime. What would happen if these mecahnisms were attacked? In short, can you add some RECOMMENDations about what protocols that use Trickle shold consider in their specifications. From jpv@cisco.com Mon Oct 11 01:15: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 AB38F3A67A3 for ; Mon, 11 Oct 2010 01:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-ZIlIMYTDRW for ; Mon, 11 Oct 2010 01:15:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0A1263A6784 for ; Mon, 11 Oct 2010 01:15:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIHAGNkskyrRN+J/2dsb2JhbAAuoV1xojybeYVIBIpBgwMGiBw X-IronPort-AV: E=Sophos;i="4.57,312,1283731200"; d="scan'208,217";a="602076291" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2010 08:16:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9B8GIJI004542; Mon, 11 Oct 2010 08:16:35 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 10:16:24 +0200 Received: from [64.103.30.128] ([64.103.30.128]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 10:16:23 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-14--774548499 Date: Mon, 11 Oct 2010 06:11:36 +0200 References: <33C30D88-2950-4FF0-AA4E-0E2127197756@cisco.com> To: ROLL WG , Omprakash Gnawali , Philip Levis Message-Id: X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 11 Oct 2010 08:16:23.0500 (UTC) FILETIME=[97AEB0C0:01CB691C] Subject: [Roll] Fwd: Adopting draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 08:15:26 -0000 --Apple-Mail-14--774548499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, We did not have that many replies to the poll, but all positive. = Authors, please resubmit the document (without changes other than titles, names, dates) as = draft-ietf-roll-minrank-hysteresis-00.txt.=20 Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: September 30, 2010 8:56:51 PM GMT+02:00 > To: ROLL WG , Omprakash Gnawali = > Cc: David Culler > Subject: [Roll] Adopting draft-gnawali-roll-minrank-hysteresis-of-02 = as a new ROLL WG document ? >=20 > Hi Omprakash, >=20 > Thanks for the new revision addressing my comments. >=20 > All,=20 >=20 > Could you please let us know if you are in favor/opposed of adopting = draft-gnawali-roll-minrank-hysteresis-of as a ROLL Working Group = document ? >=20 > Thanks. >=20 > JP. >=20 >=20 > On Sep 21, 2010, at 9:18 PM, Omprakash Gnawali wrote: >=20 >> Dear WG, >>=20 >> I just updated the draft to address JP's comment on allowing for leaf = nodes. >>=20 >> - om_p >>=20 >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: Tue, Sep 21, 2010 at 2:17 PM >> Subject: New Version Notification for >> draft-gnawali-roll-minrank-hysteresis-of-02 >> To: gnawali@cs.stanford.edu >> Cc: pal@cs.stanford.edu >>=20 >>=20 >>=20 >> A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-02.txt >> has been successfully submitted by Omprakash Gnawali and posted to = the >> IETF repository. >>=20 >> Filename: draft-gnawali-roll-minrank-hysteresis-of >> Revision: 02 >> Title: The Minimum Rank Objective Function with Hysteresis >> Creation_date: 2010-09-21 >> WG ID: Independent Submission >> Number_of_pages: 8 >>=20 >> Abstract: >> Hysteresis delays the effect of changes in link metric on parent >> selection. Such delay makes the topology stable despite jitters in >> link metrics. The Routing Protocol for Low Power and Lossy Networks >> (RPL) allows the use of objective functions to construct routes that >> optimize or constrain a routing metric on the paths. This >> specification describes the Minimum Rank Objective Function with >> Hysteresis (MRHOF), an objective function that minimizes the node >> rank in terms of a given metric, while using hysteresis to prevent >> excessive rank churn. The use of MRHOF with RPL results in nodes >> selecting stable paths that minimize the given routing metric to the >> roots of a Directed Acyclic Graph (DAG). >>=20 >>=20 >>=20 >> The IETF Secretariat. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-14--774548499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

We did not have that many replies to the poll, = but all positive. Authors, please resubmit the document (without = changes
other than titles, names, dates) as = draft-ietf-roll-minrank-hysteresis-00.txt. 

= Thanks.

JP.

Begin forwarded = message:

From: JP Vasseur <jpv@cisco.com>
Date: September 30, 2010 = 8:56:51 PM GMT+02:00
To: ROLL WG <roll@ietf.org>, Omprakash Gnawali = <gnawali@cs.stanford.edu>
Cc: David Culler <culler@eecs.berkeley.edu><= br>
Subject: [Roll] Adopting = draft-gnawali-roll-minrank-hysteresis-of-02 as a new ROLL WG document = ?

Dear = WG,

I just updated the draft to address JP's comment on allowing = for leaf nodes.

- om_p

---------- Forwarded message = ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Dat= e: Tue, Sep 21, 2010 at 2:17 PM
Subject: New Version Notification = for
draft-gnawali-roll-minrank-hysteresis-of-02
To: gnawali@cs.stanford.edu
Cc:= pal@cs.stanford.edu


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

Filename:       =  draft-gnawali-roll-minrank-hysteresis-of
Revision:   =      02
Title:           The = Minimum Rank Objective Function with Hysteresis
Creation_date:   = 2010-09-21
WG ID:           Independent = Submission
Number_of_pages: 8

Abstract:
Hysteresis delays = the effect of changes in link metric on parent
selection.  Such = delay makes the topology stable despite jitters in
link metrics. =  The Routing Protocol for Low Power and Lossy Networks
(RPL) = allows the use of objective functions to construct routes = that
optimize or constrain a routing metric on the paths. =  This
specification describes the Minimum Rank Objective = Function with
Hysteresis (MRHOF), an objective function that = minimizes the node
rank in terms of a given metric, while using = hysteresis to prevent
excessive rank churn.  The use of MRHOF = with RPL results in nodes
selecting stable paths that minimize the = given routing metric to the
roots of a Directed Acyclic Graph = (DAG).



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

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

= --Apple-Mail-14--774548499-- From jpv@cisco.com Mon Oct 11 14:30: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 CEEAB3A6B97 for ; Mon, 11 Oct 2010 14:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.223 X-Spam-Level: X-Spam-Status: No, score=-110.223 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ5L9Lst17wk for ; Mon, 11 Oct 2010 14:30:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 17E133A6B90 for ; Mon, 11 Oct 2010 14:30:13 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIHAGsfs0yrR7Ht/2dsb2JhbAAuoV1xp0mcbYVIBIpBgwk X-IronPort-AV: E=Sophos;i="4.57,316,1283731200"; d="scan'208";a="242200744" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2010 21:31:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9BLVFXI020373; Mon, 11 Oct 2010 21:31:15 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 23:31:14 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 23:31:14 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <20100930214502.430A23A6C7E@core3.amsl.com> Date: Mon, 11 Oct 2010 20:20:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EF81D0D-7D43-4D0A-90FC-7CFF33BFD5DD@cisco.com> References: <20100930214502.430A23A6C7E@core3.amsl.com> To: Tzeta Tsao , Roger Alexander X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 11 Oct 2010 21:31:14.0416 (UTC) FILETIME=[A1AEF700:01CB698B] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-security-framework-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 21:30:31 -0000 Dear authors, Thank (ticket#79). Thanks for having addressed my comments. Ticket can = be closed. JP. On Sep 30, 2010, at 11:45 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : A Security Framework for Routing over Low = Power and Lossy Networks > Author(s) : T. Tsao, et al. > Filename : draft-ietf-roll-security-framework-01.txt > Pages : 44 > Date : 2010-09-30 >=20 > This document presents a security framework for routing over low > power and lossy networks (LLN). The development builds upon previous > work on routing security and adapts the assessments to the issues and > constraints specific to low power and lossy networks. A systematic > approach is used in defining and evaluating the security threats and > identifying applicable countermeasures. These assessments provide > the basis of the security recommendations for incorporation into low > power, lossy network routing protocols. As an illustration, this > framework is applied to IPv6 Routing Protocol for Low Power and Lossy > Networks (RPL). >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-01.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From root@core3.amsl.com Mon Oct 11 14: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 CC4043A6B8C; Mon, 11 Oct 2010 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101011214501.CC4043A6B8C@core3.amsl.com> Date: Mon, 11 Oct 2010 14:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-minrank-hysteresis-of-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 21: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 : The Minimum Rank Objective Function with Hysteresis Author(s) : O. Gnawali, P. Levis Filename : draft-ietf-roll-minrank-hysteresis-of-00.txt Pages : 8 Date : 2010-10-11 Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-00.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-minrank-hysteresis-of-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11144334.I-D@ietf.org> --NextPart-- From gnawali@cs.stanford.edu Mon Oct 11 14:47: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 52FA13A6BB3 for ; Mon, 11 Oct 2010 14:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.353, 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 bO9z86Vo6vcr for ; Mon, 11 Oct 2010 14:47:12 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id AB8033A6BA9 for ; Mon, 11 Oct 2010 14:47:03 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1P5QDv-0001Vl-Tx for roll@ietf.org; Mon, 11 Oct 2010 14:48:00 -0700 Received: by iwn6 with SMTP id 6so15588iwn.19 for ; Mon, 11 Oct 2010 14:47:38 -0700 (PDT) Received: by 10.231.184.71 with SMTP id cj7mr4981082ibb.159.1286833658847; Mon, 11 Oct 2010 14:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.146.195 with HTTP; Mon, 11 Oct 2010 14:47:18 -0700 (PDT) In-Reply-To: <20101011214335.5AC9C3A6B9C@core3.amsl.com> References: <20101011214335.5AC9C3A6B9C@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 11 Oct 2010 17:47:18 -0400 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 21:47:15 -0000 ROLL WG, Here is the MRHOF document with changes in the name and title to indicate that it is now a WG document. I look forward to your input to improve the document. Thanks. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Oct 11, 2010 at 5:43 PM Subject: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-00 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-00.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-roll-minrank-hysteresis-of Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2010-10-11 WG ID: =A0 =A0 =A0 =A0 =A0 roll Number_of_pages: 8 Abstract: Hysteresis delays the effect of changes in link metric on parent selection. =A0Such delay makes the topology stable despite jitters in link metrics. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. =A0The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). The IETF Secretariat. From nicolas.dejean.ietf@googlemail.com Tue Oct 12 00:17:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B397D3A68E9 for ; Tue, 12 Oct 2010 00:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ3bQfU-bOJR for ; Tue, 12 Oct 2010 00:17:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8DD6B3A6405 for ; Tue, 12 Oct 2010 00:17:09 -0700 (PDT) Received: by wwj40 with SMTP id 40so3141733wwj.13 for ; Tue, 12 Oct 2010 00:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=846i/rrZBP3PmH7SdjF8fFWJc1nIvlntjJqpeSCoS+Y=; b=atJTTS1BE1+h6kFMUNzYP/LAlquAU1RhcRUOA5ZeocvSCQ3593NINOO3m11BJZEeBJ wyiayYjJtNEeVJw8FJT2hB6iyxwuXzO4fBNuSnNC6bVvs935rroOfdx9XELZknnKU5t2 jPLkex9BxhsmawgwiFfxQ8A+KvyMWgBhDQo4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BZ6hjKrAXIdFz+/ihGyNgC/m2aNLIQ7fhhqvV5T2YgDL1CVhN8H+WTArnIEXHsddO/ V423/Ccq8EsH9QPZYDiN/4yEVmkJjwgz8pXxKrLW7YD12VfOs3RI6mFlm2dTwTVS1FJT gCtEQbtDxQgfesd95BBMdez0sLDW+9u5Liwks= MIME-Version: 1.0 Received: by 10.227.144.2 with SMTP id x2mr6412122wbu.76.1286867902643; Tue, 12 Oct 2010 00:18:22 -0700 (PDT) Received: by 10.227.135.132 with HTTP; Tue, 12 Oct 2010 00:18:22 -0700 (PDT) In-Reply-To: <4C9B3037.4090209@ieee.org> References: <4C9B3037.4090209@ieee.org> Date: Tue, 12 Oct 2010 09:18:22 +0200 Message-ID: From: Nicolas DEJEAN To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio Object X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 07:17:13 -0000 Hello Phoebus, 2010/9/23 Phoebus Chen : > I'm a little confused about the Node Fanout Ratio (NFR) Object in Section > 3.4 . =A0Does fanout refer to outgoing links (upward, to a parents), or > incoming links (downward, from children) of a node? > The idea is that this metric refers to the incoming links. > The text says: > "The Node Fanout Ratio (NFR) object is used to provide information on > the nodes current forwarding load." > > From this, I would read fanout to mean the number of incoming links, if y= ou > are concerned with upward routing. =A0The amount of traffic you have to > forward depends on the amount of traffic coming in, which might be roughl= y > related to the number of children. You are right. > =A0But as far as I know, RPL nodes only > keep track of parents, not of children, so it cannot keep track of the > number of incoming links. > Unfortunately, you are right again. Good point. > Or is the NFR object is used for optimizing the topology for downward > routing (related to DAO fanout), to get path diversity / reliability? If > this is the case, perhaps this should be explained in the metrics documen= t. > This is absolutely not the idea. As a conclusion, maybe we could find some specific cases (based on storing/non storing mode and DAO usage for instance) that could allow using this metric but in all cases, this is much more complicated than expected at start. My proposal is to remove this metric from the draft. It might be reintroduced later in a separate ID. Nicolas. > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > > > On 9/16/10 3:56 PM, David Culler wrote: >> >> The routing metrics draft has now gone through 9 revisions over the >> past 16 months, the diffs have narrowed to essentially wording and >> editorial changes, and the comments are few and non-controversial. >> Thus, it appears that consensus has emerged and we can LC this I-D. >> >> This email is to announce Working Group Last Call on >> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >> Sept. 30 2010. =A0Please read it thoroughly and forward all final >> comments to the authors and the WG mailing list. >> >> Thanks all for your good work. =A0We're on a ROLL. >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Tue Oct 12 05:21:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6B63A6948 for ; Tue, 12 Oct 2010 05:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.247 X-Spam-Level: X-Spam-Status: No, score=-110.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdZooF2pw31F for ; Tue, 12 Oct 2010 05:21:51 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E8CC13A692B for ; Tue, 12 Oct 2010 05:21:51 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="199404075" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 12 Oct 2010 12:23:06 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9CCMuJu023691; Tue, 12 Oct 2010 12:23:05 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 14:23:04 +0200 Received: from [156.106.244.82] ([10.55.81.191]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 14:23:03 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <0EF81D0D-7D43-4D0A-90FC-7CFF33BFD5DD@cisco.com> Date: Tue, 12 Oct 2010 14:23:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100930214502.430A23A6C7E@core3.amsl.com> <0EF81D0D-7D43-4D0A-90FC-7CFF33BFD5DD@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 12 Oct 2010 12:23:03.0324 (UTC) FILETIME=[377A5DC0:01CB6A08] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-security-framework-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:21:53 -0000 Sorry I meant Ticket 77. On Oct 11, 2010, at 8:20 PM, JP Vasseur wrote: > Dear authors, >=20 > Thank (ticket#79). Thanks for having addressed my comments. Ticket = can be closed. >=20 > JP. >=20 > On Sep 30, 2010, at 11:45 PM, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >>=20 >>=20 >> Title : A Security Framework for Routing over Low = Power and Lossy Networks >> Author(s) : T. Tsao, et al. >> Filename : draft-ietf-roll-security-framework-01.txt >> Pages : 44 >> Date : 2010-09-30 >>=20 >> This document presents a security framework for routing over low >> power and lossy networks (LLN). The development builds upon previous >> work on routing security and adapts the assessments to the issues and >> constraints specific to low power and lossy networks. A systematic >> approach is used in defining and evaluating the security threats and >> identifying applicable countermeasures. These assessments provide >> the basis of the security recommendations for incorporation into low >> power, lossy network routing protocols. As an illustration, this >> framework is applied to IPv6 Routing Protocol for Low Power and Lossy >> Networks (RPL). >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-01.= txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Tue Oct 12 05:21:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9563A6916 for ; Tue, 12 Oct 2010 05:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.123 X-Spam-Level: X-Spam-Status: No, score=-100.123 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_50=0.001, MANGLED_WANT=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxOiWMuLfEPZ for ; Tue, 12 Oct 2010 05:21:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BB11F3A67D3 for ; Tue, 12 Oct 2010 05:21:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5dsT-00025A-3B; Tue, 12 Oct 2010 05:22:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: roger.alexander@ekasystems.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 12 Oct 2010 12:22:45 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/77#comment:1 Message-ID: <064.d48664ced0430951ed2799a984a47e63@tools.ietf.org> References: <055.670184ba815b637b18e2d9ec4c4599d6@tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <055.670184ba815b637b18e2d9ec4c4599d6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: roger.alexander@ekasystems.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 12 Oct 2010 05:27:37 -0700 Cc: roll@ietf.org Subject: Re: [Roll] [roll] security-framework #77 (closed): Comments during Security FW Last Call X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:21:45 -0000 #77: Comments during Security FW Last Call Changes (by jpv@…): * status: new => closed * resolution: => fixed Old description: > Hi, > > Please find below some detailed comments - Overall well-written document. > In addition to the comments in-line (search for JP>), I would welcome a > few > diagrams especially when you describe the different types of attacks. > Furthermore, > as you will see in the comments, be careful not to make the assumption of > wireles > links (there are many LLNs with wireless links of course) but this is not > the only > type of links. Same comment for the node type (they are not all battery > operated). > Thanks ! I will open a ticket capturing all of the comments below. > > JP> > > Starting with ID nits: > > Checking references for intended status: Informational > ---------------------------------------------------------------------------- > > == Outdated reference: draft-ietf-roll-building-routing-reqs has been > published as RFC 5867 > > == Outdated reference: draft-ietf-roll-home-routing-reqs has been > published > as RFC 5826 > > == Outdated reference: A later version (-11) exists of > draft-ietf-roll-rpl-07 > > Networking Working Group T. Tsao, Ed. > Internet-Draft R. Alexander, Ed. > Intended status: Informational Eka Systems > Expires: October 1, 2010 M. Dohler, Ed. > CTTC > V. Daza, Ed. > A. Lozano, Ed. > Universitat Pompeu Fabra > March 30, 2010 > > A Security Framework for Routing over Low Power and Lossy Networks > draft-ietf-roll-security-framework-00 > > Abstract > > This document presents a security framework for routing over low > power and lossy networks. > JP> Add acronym (LLN) > The development builds upon previous work > on routing security and adapts the assessments to the issues and > constraints specific to low power and lossy networks. A systematic > approach is used in defining and evaluating the security threats and > identifying applicable countermeasures. These assessments provide > the basis of the security recommendations for incorporation into low > power, lossy network routing protocols. As an illustration, this > framework is applied to RPL. > JP> Expand acronym when first used (LLN here). > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in RFC > 2119 [RFC2119]. > > 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." > > > Tsao, et al. Expires October 1, 2010 [Page 1] > > Internet-Draft Security Framework for ROLL March 2010 > > 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 October 1, 2010. > > Copyright Notice > > Copyright (c) 2010 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. > > > > > > > > > > > > > > > > Tsao, et al. Expires October 1, 2010 [Page 2] > > Internet-Draft Security Framework for ROLL March 2010 > > Table of Contents > > 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 > 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 > 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 > 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 > 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 11 > 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 > 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 > 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 > 4.1.2. Routing Information (Routes and Network Topology) > Exposure . . . . . . . . . . . . . . . . . . . . . . . 13 > 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 > 4.2.1. Routing Information Manipulation . . . . . . . . . . . 14 > 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 14 > 4.3. Threats and Attacks on Availability . . . . . . . . . . . 15 > 4.3.1. Routing Exchange Interference or Disruption . . . . . 15 > 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 15 > 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 > 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 16 > 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 > 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 17 > 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 17 > 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 > 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 19 > 5.1.4. Countering Physical Device Compromise . . . . . . . . 19 > 5.1.5. Countering Remote Device Access Attacks . . . . . . . 21 > 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 21 > 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 22 > 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 > 5.2.3. Countering Identity (including Sybil) Attacks . . . . 22 > 5.2.4. Countering Routing Information Replay Attacks . . . . 23 > 5.2.5. Countering Byzantine Routing Information Attacks . . . 23 > 5.3. Availability Attack Countermeasures . . . . . . . . . . . 24 > 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing > Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 > 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 > 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 > 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 27 > 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 > 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28 > 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 29 > 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 30 > 6.3. Availability Features . . . . . . . . . . . . . . . . . . 31 > 6.4. Additional Related Features . . . . . . . . . . . . . . . 31 > 6.5. Consideration on Matching Application Domain Needs . . . . 31 > > > Tsao, et al. Expires October 1, 2010 [Page 3] > > Internet-Draft Security Framework for ROLL March 2010 > > 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 > 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 34 > 7. Application of ROLL Security Framework to RPL . . . . . . . . 36 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 > 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 > 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 > > > > > > > > > > > > > > > > > > > > > > Tsao, et al. Expires October 1, 2010 [Page 4] > > Internet-Draft Security Framework for ROLL March 2010 > > 1. Terminology > > This document conforms to the terminology defined in > [I-D.ietf-roll-terminology]. > > JP> There are other terms used in the document that could be added here > (see below). > > > 2. Introduction > > In recent times, networked wireless devices have found an increasing > number of applications in various fields. Yet, for reasons ranging > from operational application to economics, these wireless devices > JP> This does not apply only to wireless links (e.g. PLC) > are > often supplied with minimum physical resources, e.g., limited power > reserve, slow speed or low capability computation, or small memory > size. As a consequence, the resulting networks are more prone to > loss of traffic and other vulnerabilities. The proliferation of > these low power and lossy networks (LLNs), however, are drawing > efforts to examine and address their potential networking challenges. > > This document presents a framework for securing routing over low > power and lossy networks (ROLL) > JP> s/ROLL/LLN > through an analysis that starts from > the routing basics. The objective is two-fold. First, the framework > will be used to identify pertinent security issues. Second, it will > facilitate both the assessment of a protocol's security threats and > the identification of the necessary features for development of > secure protocols for ROLL. > JP> s/ROLL/The ROLL Working Group. > > The approach adopted in this effort proceeds in four steps, to > examine ROLL security issues, to analyze threats and attacks, to > consider the countermeasures, and then to make recommendations for > securing ROLL. > JP> Could you just replace "ROLL" by the "the routing protocol developed > by the ROLL Working Group" or Define ROLL as Routing Over Low power > and Lossy networks. > The basis is found on identifying the assets and > points of access of routing and evaluating their security needs based > on the Confidentiality, Integrity, and Availability (CIA) model in > the context of LLN. The utility of this framework is demonstrated > with an application to RPL [I-D.ietf-roll-rpl]. > > 3. Considerations on ROLL Security > > This section sets the stage for the development of the framework by > applying the systematic approach proposed in [Myagmar2005] to the > routing security problem, while also drawing references from other > reviews and assessments found in the literature, particularly, > [RFC4593] and [Karlof2003]. The subsequent subsections begin with a > focus on the elements of a generic routing process that is used to > establish routing assets and points of access of the routing > functionality. Next, the CIA security model is briefly described. > Then, consideration is given to issues specific to or amplified in > LLNs. This section concludes with the formulation of a set of > > > Tsao, et al. Expires October 1, 2010 [Page 5] > > Internet-Draft Security Framework for ROLL March 2010 > > security objectives for ROLL. > > 3.1. Routing Assets and Points of Access > > An asset implies important system component (including information, > process, or physical resource), the access to, corruption or loss of > which adversely affects the system. In network routing, assets lie > in the routing information, routing process, and node's physical > resources. That is, the access to, corruption, or loss of these > elements adversely affects system routing. In network routing, a > point of access refers to the point of entry facilitating > communication with or other interaction with a system component in > order to use system resources to either manipulate information or > gain knowledge of the information contained within the system. > Security of the routing protocol must be focused on the assets of the > routing nodes and the points of access of the information exchanges > and information storage that may permit routing compromise. The > identification of routing assets and points of access hence provides > a basis for the identification of associated threats and attacks. > > This subsection identifies assets and points of access of a generic > routing process with a level-0 > JP> Explain what you mean by "level-0" > data flow diagram. The use of the > data flow diagram allows for a clear, concise model of the routing > functionality; it also has the benefit of showing the manner in which > nodes participate in the routing process, thus providing context when > later threats and attacks are considered. The goal of the model is > to be as detailed as possible so that corresponding components and > mechanisms in an individual routing protocol can be readily > identified, but also to be as general as possible to maximize the > relevancy of this effort for the various existing and future > protocols. Nevertheless, there may be discrepancies, likely in the > form of additional elements, when the model is applied to some > protocols. For such cases, the analysis approach laid out in this > document should still provide a valid and illustrative path for their > security assessment. > > Figure 1 shows that nodes participating in the routing process > transmit messages to determine their neighbors (neighbor discovery). > Using the neighboring relationships, routing protocols may exchange > network topology (including link-specific information) to generate > routes or may exchange routes directly as part of a routing exchange; > nodes which do not directly participate in the process with a given > node will get the route/topology information relayed from others. > JP> You can remove the previous sentence (no need to make assumption in > in a framework on the mode of operation of the routing protocol). > It > is likely that a node will store some or all of the routes and > topology information according to tradeoffs of node resources and > latency associated with the particular routing protocol. > JP> Why tradeoff with latency ? > The nodes > use the derived routes for making forwarding decisions. > > > Tsao, et al. Expires October 1, 2010 [Page 6] > > Internet-Draft Security Framework for ROLL March 2010 > > ................................................... > : : > : _________________ : > |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology : > : -------+--------- : > : | : > |Node_j|<------->(Route/Topology +--------+ : > : Exchange) | : > : | V ______ : > : +---->(Route Generation)--->Routes : > : ---+-- : > : | : > : Routing on a Node Node_k | : > ................................................... > | > |Forwarding | > On Node_l|<-------------------------------------------+ > > Notation: > > (Proc) A process Proc > > ________ > DataBase A data storage DataBase > -------- > > |Node_n| An external entity Node_n > > -------> Data flow > > Figure 1: Data Flow Diagram of a Generic Routing Process > > It is seen from Figure 1 that > > o Assets include > > * routing and/or topology information; > > * communication channel resources (bandwidth); > > * node resources (computing capacity, memory, and remaining > energy); > > * node identifiers (including node identity and ascribed > attributes such as relative or absolute node location). > > > Tsao, et al. Expires October 1, 2010 [Page 7] > > Internet-Draft Security Framework for ROLL March 2010 > > o Points of access include > > * neighbor discovery; > > * route/topology exchange; > > * node physical interfaces (including access to data storage). > > A focus on the above list of assets and points of access enables a > more directed assessment of routing security. Indeed, the intention > is to be comprehensive; nonetheless, the discussions to follow on > physical related issues are not related to routing protocol design > but provided for reference since they do have direct consequences on > the security of routing. > > 3.2. The CIA Security Reference Model > > At the conceptual level, security within an information system in > general and applied to ROLL in particular is concerned with the > primary issues of confidentiality, integrity, and availability. In > the context of ROLL: > > Confidentiality > Confidentiality involves the protection of routing information > as well as routing neighbor maintenance exchanges so that only > authorized and intended network entities may view or access it. > JP> By "neighbor" just mention that we're referring to routing neighbor > in the > context on this document. > Because of the wireless, > JP> Not always wireless ! Just make sure to make it clear even if the > comment > below applies to wireless links. > and sometimes ad hoc, nature of the > network, confidentiality also extends to the neighbor state and > database information within the routing device since the > deployment of the network creates the potential for > unauthorized access to the physical devices themselves. > > Integrity > Integrity, as a security principle, entails the protection of > routing information and routing neighbor maintenance exchanges, > as well as derived information maintained in the database, from > misuse or unauthorized and improper modification. In addition, > integrity also requires > JP> Is it really integrity that requires authenticity ? > the authenticity of claimed identity in > the origin and destination of a message, access and removal of > data, execution of the routing process, and use of computing > and energy resources. > > Availability > Availability ensures that routing information exchanges and > forwarding services need to be available when they are required > for the functioning of the serving network. Availability will > apply to maintaining efficient and correct operation of routing > and neighbor discovery exchanges (including needed information) > > > Tsao, et al. Expires October 1, 2010 [Page 8] > > Internet-Draft Security Framework for ROLL March 2010 > > and forwarding services so as not to impair or limit the > network's central traffic flow function. > > It is noted that, besides those captured in the CIA model, non- > repudiation is a security interest under certain circumstances. With > respect to routing, non-repudiation will involve providing some > ability to allow traceability or network management review of > participants of the routing process including the ability to > determine the events and actions leading to a particular routing > state. Non-repudiation implies after the fact and thus relies on the > logging or other capture of on-going routing exchanges. Given the > limited resources of a node and potentially the communication > channel, and considering the operating mode associated with LLNs, > routing transaction logging or auditing process communication > overhead will not be practical; as such, non-repudiation is not > further considered as a relevant ROLL security issue. > JP> May be one sentence to define "non-repudiation" would be helpful > > 3.3. Issues Specific to or Amplified in LLNs > > The work [RFC5548] and [RFC5673], as well as two other ongoing > efforts, [I-D.ietf-roll-home-routing-reqs] and > [I-D.ietf-roll-building-routing-reqs], > JP> Update the draft-ietf references. They are all RFC (5826 and 5867 > respectively). > have identified ROLL > JP> "ROLL specific" -> "routing requirement specific to LLNs" > specific > requirements and constraints for the urban, industrial, home > automation, and building automation application domains, > respectively. The following is a list of observations and evaluation > of their impact on routing security considerations. > > Limited energy reserve > JP> s/reserve/resources/ > , memory, and processing resources > JP> s/processing resources/processing nodes resources/ > > As a consequence of these constraints, there is an even more > critical need than usual for a careful trade study on which and > what level of security services are to be afforded during the > system design process. In addition, the choices of security > mechanisms are more stringent. Synchronization of security > states with sleepy nodes is yet another issues. > JP>s/issues/issue > > Large scale of rolled out network > JP> You can mention "from a few dozens to several (hundreds) of thousands > of nodes" > The possibly numerous nodes to be deployed, as well as the > general level of expertise of the installers, make manual on- > site configuration unlikely. Prolonged rollout and delayed > addition of nodes, which may be from old inventory, over the > lifetime of the network, also complicate the operations of key > management. > > Autonomous operations > Self-forming and self-organizing are commonly prescribed > requirements of ROLL > JP> s/ROLL/LLNs > . In other words, a ROLL protocol > JP> A Routing protocol designed for LLNs > needs to > contain elements of ad hoc networking and cannot > JP> (in most cases) > rely on manual > configuration for initialization or local filtering rules. > > > Tsao, et al. Expires October 1, 2010 [Page 9] > > Internet-Draft Security Framework for ROLL March 2010 > > Network topology/ownership changes, partitioning or merging, as > well as node replacement, can all contribute to key management > issues. > > Highly directional traffic > Some types of LLNs see a high percentage of their total traffic > traverse between the nodes and the gateways > JP> Use "LBR" as defined in http://datatracker.ietf.org/doc/draft-ietf- > roll-terminology/ instead > of gateway > where the LLNs > connect to wired networks. > JP> s/wired networks/to non LLN network (since wired links may be present > in LLNs) > The special routing status of and > the greater volume of traffic near the gateways/sinks > JP> Same comment use only the LBR terminology throughout the document. > have > routing security consequences. > JP> You can mention that when P2MP and MP2P traffic represents a majority > of the traffic > routing attacks consisting of advertising low route cost may cause > serious damages. > > Unattended locations and limited physical security > Many applications have the nodes deployed in unattended or > remote locations; furthermore, the nodes themselves are often > built with minimal physical protection. These constraints > lower the barrier of accessing the data or security material > stored on the nodes through physical means. > > Support for mobility > On the one hand, only a number of applications require the > support of mobile nodes, e.g., a home LLN that includes nodes > on wearable health care devices or an industry LLN that > includes nodes on cranes and vehicles. On the other hand, if a > routing protocol is indeed used in such applications, it will > clearly need to have corresponding security mechanisms. > > Support for multicast and anycast > Support for multicast and anycast is called out chiefly for > large-scale networks. As these are relatively new routing > technologies, > JP> Heu ... Multicast is not really new > there has been an ongoing effort devoted to their > security mechanisms, e.g., from the IETF Multicast Security > working group. However, inclusion of such mechanisms in a > routing protocol, and consequently their security analysis, are > still areas not fully developed or their impact entirely > understood, whether in a more traditional wired or wireless > network, or LLN. > > The above list considers how a LLN's physical constraints, size, > operations, and varieties of application areas may impact security. > It is noted here also that LLNs commonly have the majority, if not > all, of their nodes equipped to route. > JP> I would suppress the previous sentence, since in this document we are > only considering nodes acting as routers. > One of the consequences is > that the distinction between the link and network layers become > artificial in some respects. Similarly, the distinction between a > host and a router is blurred, especially when the set of applications > running on a node is small. > JP> Same thing for the previous sentence, which may be misleading. > The continued evolution of ROLL and its > security functionality requirements need close attention. > JP> s/ROLL/routing protocol designed by the ROLL WG > > > > Tsao, et al. Expires October 1, 2010 [Page 10] > > Internet-Draft Security Framework for ROLL March 2010 > > 3.4. ROLL Security Objectives > > This subsection applies the CIA model to the routing assets and > access points, taking into account the LLN issues, to develop a set > of ROLL security objectives. > > Since the fundament function of a routing protocol is to build routes > for forwarding packets, it is essential to ensure that > > o routing/topology information is not tampered during transfer and > in storage; > > o routing/topology information is not misappropriated; > > o routing/topology information is available when needed. > > In conjunction, it is necessary to be assured of > > o the authenticity and legitimacy of the participants of the > JP> routing neighbor > neighbor discovery process; > > o the routing/topology information received was faithfully generated > according to the protocol design. > > However, when trust cannot be fully vested through authentication of > the principals alone, i.e., concerns of insider attack, assurance of > the truthfulness and timeliness of the received routing/topology > information is necessary. With regard to confidentiality, protecting > the routing/topology information from eavesdropping or unauthorized > exposure is in itself less pertinent in general to the routing > function. > > One of the main problems of synchronizing security states of sleepy > nodes, as listed in the last subsection, lies in difficulties in > authentication; these nodes may not have received in time the most > recent update of security material. Similarly, the issues of minimal > manual configuration, prolonged rollout and delayed addition of > nodes, and network topology changes also complicate key management. > Hence, ROLL > JP> Change ROLL for routing in LLN > > needs to bootstrap the authentication process and allow > for flexible expiration scheme of authentication credentials. > > The vulnerability brought forth by some special-function nodes, e.g., > gateways/sinks > JP> Change for LBR > requires the assurance, particularly, > > o of the availability of communication channels and node resources; > > JP> but how to ensure and the unavailable of the channels is due to a > security > attack as opposed to simply being not operational? > o that the neighbor discovery process operates without undermining > routing availability. > > > Tsao, et al. Expires October 1, 2010 [Page 11] > > Internet-Draft Security Framework for ROLL March 2010 > > There are other factors which are not part of a ROLL protocol but > directly affecting its function. These factors include weaker > barrier of accessing the data or security material stored on the > nodes through physical means; therefore, the internal and external > interfaces of a node need to be adequate for guarding the integrity, > and possibly the confidentiality, of stored information, as well as > the integrity of routing and route generation processes. > > Each individual system's use and environment will dictate how the > above objectives are applied, including the choices of security > services as well as the strengths of the mechanisms that must be > implemented. The next two sections give a closer look at how the > ROLL security objectives may be compromised and countered, > respectively. > > 4. Threats and Attacks > > This section outlines general categories of threats under the CIA > model and highlights the specific attacks in each of these categories > for ROLL. As defined in [RFC4949], a threat is "a potential for > violation of security, which exists when there is a circumstance, > capability, action, or event that could breach security and cause > harm." An attack is "an assault on system security that derives from > an intelligent threat, i.e., an intelligent act that is a deliberate > attempt (especially in the sense of a method or technique) to evade > security services and violate the security policy of a system." > > The subsequent subsections consider the threats and their realizing > attacks that can cause security breaches under the CIA model to the > assets identified in Section 3.1. The analysis steps through the > security concerns of each routing asset and looks at the attacks that > can exploit points of access. The manifestation of the attacks is > assumed to be from either inside or outside attackers, whose > capabilities may be limited to node-equivalent or more sophisticated > computing platforms. > > 4.1. Threats and Attacks on Confidentiality > > The assessment in Section 3.2 indicates that information assets are > exposed to confidentiality threats from all points of access. > > 4.1.1. Routing Exchange Exposure > > Routing exchanges include both routing information as well as > information associated with the establishment and maintenance of > neighbor state information. > > > Tsao, et al. Expires October 1, 2010 [Page 12] > > Internet-Draft Security Framework for ROLL March 2010 > > The exposure of routing information exchanged will allow unauthorized > sources to gain access to the content of the exchanges between > communicating nodes. The exposure of neighbor state information will > allow unauthorized sources to gain knowledge of communication links > between routing nodes that are necessary to maintain routing > information exchanges. > > The forms of attack that allow unauthorized access or exposure of > routing exchange information, as reported in the literature, include > > o Deliberate exposure; > > o Sniffing; > > o Traffic analysis. > > 4.1.2. Routing Information (Routes and Network Topology) Exposure > > Routes and neighbor topology information are the products of the > routing process that are stored within the node device databases. > > The exposure of this information will allow unauthorized sources to > gain direct access to the configuration and connectivity of the > network thereby exposing routing to targeted attacks on key nodes or > links. Since routes and neighbor topology information is stored > within the node device, threats or attacks on the confidentiality of > the information will apply to the physical device including specified > and unspecified internal and external interfaces. > > The forms of attack that allow unauthorized access or exposure of the > routing information (other than occurring through explicit node > exchanges) will include > > o Physical device compromise; > > o Remote device access attacks (including those occurring through > remote network management or software/field upgrade interfaces). > > More detailed descriptions of the exposure attacks on routing > exchange and information will be given in Section 5 together with the > corresponding countermeasures. > > 4.2. Threats and Attacks on Integrity > > The assessment in Section 3.2 indicates that information and identity > assets are exposed to integrity threats from all points of access. > > > > Tsao, et al. Expires October 1, 2010 [Page 13] > > Internet-Draft Security Framework for ROLL March 2010 > > 4.2.1. Routing Information Manipulation > > Manipulation of routing information will allow unauthorized sources > to influence the operation and convergence of the routing protocols > and ultimately impact the forwarding decisions made in the network. > Manipulation of neighbor state (topology) > JP> topology and reachability information > information will allow > unauthorized sources to influence the nodes with which routing > information is exchanged and updated. The consequence of > manipulating routing exchanges can thus lead to sub-optimality and > fragmentation or partitioning of the network by restricting the > universe of routers with which associations can be established and > maintained. > > JP> Can also lead to attract traffic, black-holes, ... > The forms of attack that allow manipulation to compromise the content > and validity of routing information include > > o Falsification, including overclaiming and misclaiming; > > o Routing information replay; > > o Byzantine (internal) attacks that permit corruption of routing > information in the node even where the node continues to be a > validated entity within the network; > > o Physical device compromise. > > 4.2.2. Node Identity Misappropriation > > Falsification or misappropriation of node identity between routing > participants opens the door for other attacks; it can also cause > incorrect routing relationships to form and/or topologies to emerge. > Routing attacks may also be mounted through less sophisticated node > identity misappropriation in which the valid information broadcast or > exchanged by a node is replayed without modification. The receipt of > seemingly valid information that is however no longer current can > result in routing disruption, and instability (including failure to > converge). Without measures to authenticate the routing participants > and to ensure the freshness and validity of the received information > the protocol operation can be compromised. The forms of attack that > misuse node identity include > > o Identity (including Sybil) attacks; > > o Routing information replay. > > > > > Tsao, et al. Expires October 1, 2010 [Page 14] > > Internet-Draft Security Framework for ROLL March 2010 > > 4.3. Threats and Attacks on Availability > > The assessment in Section 3.2 indicates that the process and > resources assets are exposed to availability threats; attacks of this > category may exploit directly or indirectly information exchange or > forwarding. > > 4.3.1. Routing Exchange Interference or Disruption > > Interference or disruption of routing information exchanges will > allow unauthorized sources to influence the operation and convergence > of the routing protocols by impeding the regularity of routing > information exchange. > > The forms of attack that allow interference or disruption of routing > exchange include > > o Routing information replay; > > o HELLO flood attacks and ACK spoofing; > > o Overload attacks. > > 4.3.2. Network Traffic Forwarding Disruption > > The disruption of the network traffic forwarding capability of the > network will undermine the central function of network routers and > the ability to handle user traffic. This threat and the associated > attacks affect the availability of the network because of the > potential to impair the primary capability of the network. > > The forms of attack that allows disruption of network traffic > forwarding include > > o Selective forwarding attacks; > > o Sinkhole attacks; > > o Wormhole attacks. > JP> Can you add reference to sinkhole and wormhole attacks? > 4.3.3. Communications Resource Disruption > > Attacks mounted against the communication channel resource assets > needed by the routing protocol can be used as a means of disrupting > its operation. However, while various forms of Denial of Service > (DoS) attacks on the underlying transport subsystem will affect > routing protocol exchanges and operation (for example physical layer > RF jamming in a wireless network or link layer attacks), these > > > Tsao, et al. Expires October 1, 2010 [Page 15] > > Internet-Draft Security Framework for ROLL March 2010 > > attacks cannot be countered by the routing protocol. As such, the > threats to the underlying transport network that supports routing is > considered beyond the scope of the current document. Nonetheless, > attacks on the subsystem will affect routing operation and so must be > directly addressed within the underlying subsystem and its > implemented protocol layers. > > 4.3.4. Node Resource Exhaustion > > A potential security threat to routing can arise from attempts to > exhaust the node resource asset by initiating exchanges that can lead > to the undue utilization of exhaustion of processing, memory or > energy resources. The establishment and maintenance of routing > neighbors opens the routing process to engagement and potential > acceptance of multiple neighboring peers. Association information > must be stored for each peer entity and for the wireless network > operation provisions made to periodically update and reassess the > associations. An introduced proliferation of apparent routing peers > can therefore have a negative impact on node resources. > > Node resources may also be unduly consumed by the attackers > attempting uncontrolled topology peering or routing exchanges, > routing replays, or the generating of other data traffic floods. > Beyond the disruption of communications channel resources, these > threats may be able to exhaust node resources only where the > engagements are able to proceed with the peer routing entities. > Routing operation and network forwarding functions can thus be > adversely impacted by node resources exhaustion that stems from > attacks that include > > o Identity (including Sybil) attacks; > > o Routing information replay attacks; > > o HELLO flood attacks and ACK spoofing; > > o Overload attacks. > > 5. Countermeasures > > By recognizing the characteristics of LLNs that may impact routing > and identifying potential countermeasures, this framework provides > the basis for developing capabilities within ROLL protocols to deter > the identified attacks and mitigate the threats. The following > subsections consider such countermeasures by grouping the attacks > according to the classification of the CIA model so that associations > with the necessary security services are more readily visible. > > > Tsao, et al. Expires October 1, 2010 [Page 16] > > Internet-Draft Security Framework for ROLL March 2010 > > However, the considerations here are more systematic than confined to > means available only within routing; the next section will then > distill and make recommendations appropriate for a secured ROLL > protocol. > > 5.1. Confidentiality Attack Countermeasures > > Attacks on confidentiality may be mounted at the level of the routing > information assets, at the points of access associated with routing > exchanges between nodes, or through device interface access. To gain > access to routing/topology information, the attacker may rely on a > compromised node that deliberately exposes the information during the > routing exchange process, may rely on passive sniffing or analysis of > routing traffic, or may attempt access through a component or device > interface of a tampered routing node. > > 5.1.1. Countering Deliberate Exposure Attacks > > A deliberate exposure attack is one in which an entity that is party > to the routing process or topology exchange allows the routing/ > topology information or generated route information to be exposed to > an unauthorized entity during the exchange. > > A prerequisite to countering this type of confidentiality attacks > associated with the routing/topology exchange is to ensure that the > communicating nodes are authenticated prior to data encryption > applied in the routing exchange. Authentication ensures that the > nodes are who they claim to be even though it does not provide an > indication of whether the node has been compromised. > > To prevent deliberate exposure, the process that communicating nodes > use for establishing communication session keys must be symmetric at > each node so that neither node can independently weaken the > confidentiality of the exchange without the knowledge of its > communicating peer. A deliberate exposure attack will therefore > require more overt and independent action on the part of the > offending node. > > Note that the same measures which apply to securing routing/topology > exchanges between operational nodes must also extend to field tools > and other devices used in a deployed network where such devices can > be configured to participate in routing exchanges. > > 5.1.2. Countering Sniffing Attacks > > A sniffing attack seeks to breach routing confidentiality through > passive, direct analysis and processing of the information exchanges > between nodes. A sniffing attack in an LLN that is not based on a > > > Tsao, et al. Expires October 1, 2010 [Page 17] > > Internet-Draft Security Framework for ROLL March 2010 > > physical device compromise will rely on the attacker attempting to > directly derive information from the over-the-air routing/topology > communication exchange (neighbor discovery exchanges may of necessity > be conducted in the clear thus limiting the extent to which the > information can be kept confidential). > > Sniffing attacks can be directly countered through the use of data > encryption for all routing exchanges. Only when a validated and > authenticated node association is completed will routing exchange be > allowed to proceed using established session confidentiality keys and > an agreed confidentiality algorithm. > JP> Id security is "turned on". Could you specify that the routing > protocol > will include security features according to this framework but some > scenario > may not require their use, should they be provide by other means or not > needed in a specific environment. > The level of security applied > in providing confidentiality will determine the minimum requirement > for an attacker mounting this passive security attack. Because of > the resource constraints of LLN devices, symmetric (private) key > session security will provide the best tradeoff in terms of node and > channel resource overhead and the level of security achieved. This > will of course not preclude the use of asymmetric (public) key > encryption during the session key establishment phase. > > As with the key establishment process, data encryption must include > an authentication prerequisite to ensure that each node is > implementing a level of security that prevents deliberate or > inadvertent exposure. The authenticated key establishment will > ensure that confidentiality is not compromised by providing the > information to an unauthorized entity (see also [Huang2003]). > > Based on the current state of the art, a minimum 128-bit key length > should be applied where robust confidentiality is demanded for > routing protection. This session key shall be applied in conjunction > with an encryption algorithm that has been publicly vetted and where > applicable approved for the level of security desired. Algorithms > such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted > by the 3GPP 3rd generation wireless mobile consortium) > JP> Could you please ad references ? > are examples > of symmetric-key algorithms capable of ensuring robust > confidentiality for routing exchanges. The key length, algorithm and > mode of operation will be selected as part of the overall security > tradeoff that also achieves a balance with the level of > confidentiality afforded by the physical device in protecting the > routing assets (see Section 5.1.4 below). > > As with any encryption algorithm, the use of ciphering > synchronization parameters and limitations to the usage duration of > established keys should be part of the security specification to > reduce the potential for brute force analysis. > > > > > Tsao, et al. Expires October 1, 2010 [Page 18] > > Internet-Draft Security Framework for ROLL March 2010 > > 5.1.3. Countering Traffic Analysis > > Traffic analysis provides an indirect means of subverting > confidentiality and gaining access to routing information by allowing > an attacker to indirectly map the connectivity or flow patterns > (including link-load) > JP> Aren't you making the assumption that LLNs only comprise radio > link layers ? ** Please make sure that throughout the document you > are not making any assumption on the link layer (see other comments > above along the same lines). > of the network from which other attacks can be > mounted. The traffic analysis attack on a LLN may be passive and > relying on the ability to read the immutable source/destination > routing information that must remain unencrypted to permit network > routing. Alternatively, attacks can be active through the injection > of unauthorized discovery traffic into the network. By implementing > authentication measures between communicating nodes, active traffic > analysis attacks can be prevented within the LLN thereby reducing > confidentiality vulnerabilities to those associated with passive > analysis. > > One way in which passive traffic analysis attacks can be muted is > through the support of load balancing that allows traffic to a given > destination to be sent along diverse routing paths. Where the > routing protocol supports load balancing along multiple links at each > node, the number of routing permutations in a wide area network > surges thus increasing the cost of traffic analysis. Network > analysis through this passive attack will require a wider array of > analysis points and additional processing on the part of the > attacker. In LLNs, the diverse radio connectivity and dynamic links > (including potential frequency hopping) will help to further mitigate > traffic analysis attacks when load balancing is implemented. > JP> Please indicate that this is trued if the link layer is wireless. > > The only means of fully countering a traffic analysis attack is > through the use of tunneling (encapsulation) where encryption is > applied across the entirety of the original packet source/destination > addresses. With tunneling there is a further requirement that the > encapsulating intermediate nodes apply an additional layer of routing > so that traffic arrives at the destination through dynamic routes. > For LLNs, memory and processing constraints as well as the > limitations of the communication channel will preclude both the > additional routing traffic overhead > JP> But tunneling may be used and is actually used in several cases > (e.g. this is the situation for example with RPL when an additional > header > used for example for loop detection is added to the HbP header for > traffic > from outside of the LLN to a node inside the LLN). > and the node implementation > required for tunneling countermeasures to traffic analysis. > > 5.1.4. Countering Physical Device Compromise > > Given the distributed nature of LLNs, confidentiality of routing > assets and points of access will rely heavily on the security of the > routing devices. One means of precluding attacks on the physical > device is to prevent physical access to the node through other > external security means. However, given the environment in which > LLNs operate, preventing unauthorized access to the physical device > cannot be assured. > JP> "in some cases" - for example in a Smart Grid environment the > substation > has secured access. > Countermeasures must therefore be employed at the > > > Tsao, et al. Expires October 1, 2010 [Page 19] > > Internet-Draft Security Framework for ROLL March 2010 > > device and component level so that routing/topology or neighbor > information and stored route information cannot be accessed even if > physical access to the node is obtained. > > With the physical device in the possession of an attacker, > unauthorized information access can be attempted by probing internal > interfaces or device components. Device security must therefore move > to preventing the reading of device processor code or memory > locations without the appropriate security keys and in preventing the > access to any information exchanges occurring between individual > components. Information access will then be restricted to external > interfaces in which confidentiality, integrity and authentication > measures can be applied. > JP> True but you may want to mention that this is not 'routing security' > specific. > To prevent component information access, deployed routing devices > must ensure that their implementation avoids address or data buses > being connected to external general purpose input/output (GPIO) pins. > Beyond this measure, an important component interface to be protected > against attack is the Joint Test Action Group (JTAG) interface used > for component and populated circuit board testing after manufacture. > To provide security on the routing devices, components should be > employed that allow fuses on the JTAG interfaces to be blown to > disable access. This will raise the bar on unauthorized component > information access within a captured device. > > At the device level a key component information exchange is between > the microprocessor and it associated external memory. While > encryption can be implemented to secure data bus exchanges, the use > of integrated physical packaging which avoids inter-component > exchanges (other than secure external device exchanges) will increase > routing security against a physical device interface attack. With an > integrated package and disabled internal component interfaces, the > level of physical device security can be controlled by managing the > degree to which the device packaging is protected against expert > physical decomposition and analysis. > > The device package should be hardened such that attempts to remove > the integrated components will result in damage to access interfaces, > ports or pins that prevent retrieval of code or stored information. > The degree of VLSI or PCB > JP> Could you please expand acronyms when first used ? > package security through manufacture can be > selected as a tradeoff or desired security consistent with the level > of security achieved by measures applied for other routing assets and > points of access. With package hardening and restricted component > access countermeasures, the security level will be raised to that > provided by measures employed at the external communications > interfaces. > > Another area of node interface vulnerability is that associated with > > > Tsao, et al. Expires October 1, 2010 [Page 20] > > Internet-Draft Security Framework for ROLL March 2010 > > interfaces provided for remote software or firmware upgrades. This > may impact both routing information and routing/topology exchange > security where it leads to unauthorized upgrade or change to the > routing protocol running on a given node as this type of attack can > allow for the execution of compromised or intentionally malicious > routing code on multiple nodes. Countermeasures to this device > interface confidentiality attack needs to be addressed in the larger > context of node remote access security. This will ensure not only > the authenticity of the provided code (including routing protocol) > but that the process is initiated by an authorized (authenticated) > entity. > > The above identified countermeasures against attacks on routing > information confidentiality through internal device interface > compromise must be part of the larger LLN system security as they > cannot be addressed within the routing protocol itself. Similarly, > the use of field tools or other devices that allow explicit access to > node information must implement security mechanisms to ensure that > routing information can be protected against unauthorized access. > These protections will also be external to the routing protocol and > hence not part of ROLL. > > 5.1.5. Countering Remote Device Access Attacks > > Where LLN nodes are deployed in the field, measures are introduced to > allow for remote retrieval of routing data and for software or field > upgrades. These paths create the potential for a device to be > remotely accessed across the network or through a provided field > tool. In the case of network management a node can be directly > requested to provide routing tables and neighbor information. > > To ensure confidentiality of the node routing information against > attacks through remote access, any device local or remote requesting > routing information must be authenticated to ensure authorized > access. Since remote access is not invoked as part of a routing > protocol security of routing information stored on the node against > remote access will not be addressable as part of the routing > protocol. > > 5.2. Integrity Attack Countermeasures > > Integrity attack countermeasures address routing information > manipulation, as well as node identity and routing information > misuse. Manipulation can occur in the form of falsification attack > and physical compromise. To be effective, the following development > considers the two aspects of falsification, namely, the tampering > actions and the overclaiming and misclaiming content. The countering > of physical compromise was considered in the previous section and is > > > Tsao, et al. Expires October 1, 2010 [Page 21] > > Internet-Draft Security Framework for ROLL March 2010 > > not repeated here. With regard to misuse, there are two types of > attacks to be deterred, identity attacks and replay attacks. > > 5.2.1. Countering Tampering Attacks > > Tampering may occur in the form of altering the message being > transferred or the data stored. Therefore, it is necessary to ensure > that only authorized nodes can change the portion of the information > that is allowed to be mutable, while the integrity of the rest of the > information is protected, e.g., through well-studied cryptographic > mechanisms. > > Tampering may also occur in the form of insertion or deletion of > messages during protocol changes. Therefore, the protocol needs to > ensure the integrity of the sequence of the exchange sequence. > > The countermeasure to tampering needs to > > o implement access control on storage; > > o provide data integrity service to transferred messages and stored > data; > > o include sequence number under integrity protection. > > 5.2.2. Countering Overclaiming and Misclaiming Attacks > > Both overclaiming and misclaiming aim to introduce false routes or > topology that would not be generated by the network otherwise, while > there is not necessarily tampering. The requisite for a counter is > the capability to determine unreasonable routes or topology. > > The counter to overclaiming and misclaiming may employ > > o comparison with historical routing/topology data; > > o designs which restrict realizable network topologies. > > 5.2.3. Countering Identity (including Sybil) Attacks > > Identity attacks, sometimes simply called spoofing, seek to gain or > damage assets whose access is controlled through identity. In > routing, an identity attacker can illegitimately participate in > routing exchanges, distribute false routing information, or cause an > invalid outcome of a routing process. > > A perpetrator of Sybil attacks assumes multiple identities. The > result is not only an amplification of the damage to routing, but > > > Tsao, et al. Expires October 1, 2010 [Page 22] > > Internet-Draft Security Framework for ROLL March 2010 > > extension to new areas, e.g., where geographic distribution is > explicit or implicit an asset to an application running on the LLN. > > JP> You could mentioned that this is a particular concern in LLN where > the traffic > flow is mostly P2MP and MP2P. > The counter of identity attacks need to ensure the authenticity and > liveliness of the parties of a message exchange; the measure may use > shared key or public key based authentication scheme. On the one > hand, the large-scale nature of the LLNs makes the network-wide > shared key scheme undesirable from a security perspective; on the > other hand, public-key based approaches generally require more > computational resources. > JP> Could elaborate a little bit more on the CPU impact when using > public-key? > Each system will need to make trade-off > decisions based on its security requirements. > > 5.2.4. Countering Routing Information Replay Attacks > > In routing, message replay can result in false topology and/or > routes. The counter of replay attacks need to ensure the freshness > of the message. On the one hand, there are a number of mechanisms > commonly used for countering replay. > JP> Want to add some references? > On the other hand, the choice > should take into account how a particular mechanism is made available > in a LLN. For example, many LLNs have a central source of time and > have it distributed by relaying, such that secured time distribution > becomes a prerequisite of using timestamping to counter replay. > JP> Which means to support clocks, ... > > 5.2.5. Countering Byzantine Routing Information Attacks > > Where a node is captured or compromized but continues to operate for > a period with valid network security credentials, the potential > exists for routing information to be manipulated. This compromise of > the routing information could thus exist in spite of security > countermeasures that operate between the peer routing devices. > > Consistent with the end-to-end principle of communications, such an > attack can only be fully addressed through measures operating > directly between the routing entities themselves or by means of > external entities able to access and independently analyze the > routing information. Verification of the authenticity and liveliness > of the routing principals can therefore only provide a limited > counter against internal (Byzantine) node attacks. > JP> Agree but this is not particularly tied to the end-to-end principle. > > For link state routing protocols where information is flooded > JP> add "with area (OSPF) or levels (ISIS) > countermeasures can be directly applied by the routing entities > through the processing and comparison of link state information > received from different peers. By comparing the link information > from multiple sources decisions can be made by a routing node or > external entity with regard to routing information validity. > > For distance vector protocols where information is aggregated at each > routing node it is not possible for nodes to directly detect > > > Tsao, et al. Expires October 1, 2010 [Page 23] > > Internet-Draft Security Framework for ROLL March 2010 > > Byzantine information manipulation attacks from the routing > information exchange. In such cases, the routing protocol must > include and support indirect communications exchanges between non- > adjacent routing peers to provide a secondary channel for performing > routing information validation. S-RIP [Wan2004] is an example of the > implementation of this type of dedicated routing protocol security > where the correctness of aggregate distance vector information can > only be validated by initiating confirmation exchanges directly > between nodes that are not routing neighbors. > > Alternatively, an entity external to the routing protocol would be > required to collect and audit routing information exchanges to detect > the Byzantine attack. In the context of the current security > framework, any protection against Byzantine routing information > attacks will need to be directly included within the mechanisms of > the ROLL routing protocol. This can be implemented where such an > attack is considered relevant even within the physical device > protections discussed in Section 5.1.4 > > 5.3. Availability Attack Countermeasures > > As alluded to before, availability requires that routing information > exchanges and forwarding mechanisms be available when needed so as to > guarantee a proper functioning of the network. This may, e.g., > include the correct operation of routing information and neighbor > state information exchanges, among others. We will highlight the key > features of the security threats along with typical countermeasures > to prevent or at least mitigate them. We will also note that an > availability attack may be facilitated by an identity attack as well > as a replay attack, as was addressed in Section 5.2.3 and > Section 5.2.4, respectively. > > 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks > > HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing > attacks are different but highly related forms of attacking a LLN. > They essentially lead nodes to believe that suitable routes are > available even though they are not and hence constitute a serious > availability attack. > > The origin of facilitating a HELLO flood attack lies in the fact that > many wireless routing protocols > JP> Please do not use the terms "wireless routing protocols" since by > definition of a layered architecture, the routing protocol is not tied to > a particular link layer. Furthermore this also applies to routing > protocols > used in non wireless environments. > require nodes to send HELLO packets > either upon joining or in regular intervals so as to announce or > confirm their existence to the network. Those nodes that receive the > HELLO packet assume > JP> If they receive the packet they *are* in the radio range (again the > link > may not be wireless). > that they are within radio range of the > transmitter by means of a bidirectional communication link. > > With this in mind, a malicious node can send or replay HELLO packets > > > Tsao, et al. Expires October 1, 2010 [Page 24] > > Internet-Draft Security Framework for ROLL March 2010 > > using a higher transmission power. That creates the false illusion > of being a neighbor to an increased number of nodes in the network, > thereby effectively increasing its unidirectional neighborhood > cardinality. The high quality of the falsely advertised link may > coerce nodes to route data via the malicious node. However, those > affected nodes, for which the malicious node is out of radio range, > never succeed in their delivery and the packets are effectively > dropped. > JP> Mention "if the link layer is wireless". Not that in PLC, this can > happen too. > The symptoms are hence similar to those of a sinkhole, > wormhole and selective forwarding attack. > > A malicious HELLO flood attack clearly distorts the network topology. > It thus affects protocols building and maintaining the network > topology as well as routing protocols as such, since the attack is > primarily targeted on protocols that require sharing of information > for topology maintenance or flow control. > > To counter HELLO flood attacks, several mutually non-exclusive > methods are feasible: > > o restricting neighborhood cardinality; > > o facilitating multipath routing; > > o verifying bidirectionality. > > Restricting the neighborhood cardinality prevents malicious nodes > from having an extended set of neighbors beyond some tolerated > threshold and thereby preventing topologies to be built where > malicious nodes have an extended neighborhood set. > JP> But thai may artificially reduce the number of "valid" neighbors too. > Furthermore, as > shown in [I-D.suhopark-hello-wsn], if the routing protocol supports > multiple paths from a sensing node towards several gateways then > HELLO flood attacks can also be diminished; however, the energy- > efficiency of such approach is clearly sub-optimal. Finally, > verifying that the link is truly bidirectional by means of, e.g., an > ACK handshake and appropriate security measures ensures that a > communication link is only established if not only the affected node > is within range of the malicious node but also vice versa. Whilst > this does not really eliminate the problem of HELLO flooding, it > greatly reduces the number of affected nodes and the probability of > such an attack succeeding. > JP> Even if there is bi-directinality, the attacked node may thus send > traffic > to the attackers that claims to have "good" routes though. > As for the latter, the adversary may spoof the ACK messages to > convince the affected node that the link is truly bidirectional and > thereupon drop, tunnel or selectively forward messages. Such ACK > spoofing attack is possible if the malicious node has a receiver > which is significantly more sensitive than that of a normal node, > thereby effectively extending its range. Since an ACK spoofing > attack facilitates a HELLO flood attack, similar countermeasure are > > > Tsao, et al. Expires October 1, 2010 [Page 25] > > Internet-Draft Security Framework for ROLL March 2010 > > applicable here. Viable counter and security measures for both > attacks have been exposed in [I-D.suhopark-hello-wsn]. > > 5.3.2. Countering Overload Attacks > > Overload attacks are a form of DoS attack in that a malicious node > overloads the network with irrelevant traffic, thereby draining the > nodes' energy budget quicker. > JP> Energy indeed (a real issue if node are battery operated or using > energy scavengers) but also inject loads and creates congestions. > It thus significantly shortens the > network lifetime > JP> If the LLNs is made of battery-operated nodes. > and hence constitutes another serious availability > attack. > > With energy being one of the most precious assets of LLNs, targeting > its availability is a fairly obvious attack. Another way of > depleting the energy of a LLN node is to have the malicious node > overload the network with irrelevant traffic. This impacts > availability since certain routes get congested which > > o renders them useless for affected nodes and data can hence not be > delivered; > > o makes routes longer as shortest path algorithms work with the > congested network; > JP> Not sure what you meant above > o depletes nodes quicker and thus shortens the network's > availability at large. > JP> Again if nodes are battery operated. > > Overload attacks can be countered by deploying a series of mutually > non-exclusive security measures: > > o introduce quotas on the traffic rate each node is allowed to send; > JP> Also referred to as "traffic shaping" but only possible in some > networks. > o isolate nodes which send traffic above a certain threshold; > JP> If "Valid" nodes that may attract lots of traffic do no exist in the > network. > o allow only trusted data to be received and forwarded. > > As for the first one, a simple approach to minimize the harmful > impact of an overload attack is to introduce traffic quotas. This > prevents a malicious node from injecting a large amount of traffic > into the network, even though it does not prevent said node from > injecting irrelevant traffic at all. Another method is to isolate > JP> If you have a wireless link, how do you "isolate" the node ? It can > still sends traffic (at least with some MACs). > nodes from the network once it has been detected that more traffic is > injected into the network than allowed by a prior set or dynamically > adjusted threshold. Finally, if communication is sufficiently > secured, only trusted nodes can receive and forward traffic which > also lowers the risk of an overload attack. > > > > Tsao, et al. Expires October 1, 2010 [Page 26] > > Internet-Draft Security Framework for ROLL March 2010 > > 5.3.3. Countering Selective Forwarding Attacks > > Selective forwarding attacks are another form of DoS attack which > impacts the routing path availability. > > An insider malicious node basically blends neatly in with the network > but then may decide to forward and/or manipulate certain packets. If > all packets are dropped, then this attacker is also often referred to > as a "black hole". Such a form of attack is particularly dangerous > if coupled with sinkhole attacks since inherently a large amount of > traffic is attracted to the malicious node and thereby causing > significant damage. An outside malicious node would selectively jam > overheard data flows, where the thus caused collisions > JP> Again is the MAC is a shared media. > incur > selective forwarding. > > Selective Forwarding attacks can be countered by deploying a series > of mutually non-exclusive security measures: > > o multipath routing of the same message over disjoint paths; > > o dynamically select the next hop from a set of candidates. > > The first measure basically guarantees that if a message gets lost on > a particular routing path due to a malicious selective forwarding > attack, there will be another route which successfully delivers the > data. Such method is inherently suboptimal from an energy > consumption point of view. The second method basically involves a > constantly changing routing topology in that next-hop routers are > chosen from a dynamic set in the hope that the number of malicious > nodes in this set is negligible. > JP> If the routing protocol allows for disjoint routing paths, this is > even more > attractive. > 5.3.4. Countering Sinkhole Attacks > > In sinkhole attacks, the malicious node manages to attract a lot of > traffic mainly by advertising the availability of high-quality links > even though there are none. It hence constitutes a serious attack on > availability. > > The malicious node creates a sinkhole by attracting a large amount > of, if not all, traffic from surrounding neighbors by advertising in > and outwards links of superior quality. Affected nodes hence eagerly > route their traffic via the malicious node which, if coupled with > other attacks such as selective forwarding, may lead to serious > availability and security breaches. Such an attack can only be > executed by an inside malicious node and is generally very difficult > to detect. An ongoing attack has a profound impact on the network > topology and essentially becomes a problem of flow control. > > > Tsao, et al. Expires October 1, 2010 [Page 27] > > Internet-Draft Security Framework for ROLL March 2010 > > Sinkhole attacks can be countered by deploying a series of mutually > non-exclusive security measures: > > o use geographical insights for flow control; > > o isolate nodes which receive traffic above a certain threshold; > > o dynamically pick up next hop from set of candidates; > > o allow only trusted data to be received and forwarded. > > Whilst most of these countermeasures have been discussed before, the > use of geographical information deserves further attention. > Essentially, if geographic positions of nodes are available, then the > network can assure that data is actually routed towards the sink(s) > and not elsewhere. > JP> Yes but it may be wise to route all traffic via a node that is not > closer to > the sink but supports interesting capabilities such as aggregation. > On the other hand, geographic position is a > sensitive information that may have security and/or privacy > consequences. > > 5.3.5. Countering Wormhole Attacks > > In wormhole attacks at least two malicious nodes shortcut or divert > the usual routing path by means of a low-latency out-of-band channel. > This changes the availability of certain routing paths and hence > constitutes a serious security breach. > > Essentially, two malicious insider nodes use another, more powerful, > radio > JP> Once again, if the link in use is wireless. > to communicate with each other and thereby distort the would- > be-agreed routing path. This distortion could involve shortcutting > and hence paralyzing a large part of the network; it could also > involve tunneling the information to another region of the network > where there are, e.g., more malicious nodes available to aid the > intrusion or where messages are replayed, etc. In conjunction with > selective forwarding, wormhole attacks can create race conditions > which impact topology maintenance, routing protocols as well as any > security suits built on "time of check" and "time of use". > > Wormhole attacks are very difficult to detect in general but can be > mitigated using similar strategies as already outlined above in the > context of sinkhole attacks. > > 6. ROLL Security Features > > The assessments and analysis in Section 4 examined all areas of > threats and attacks that could impact routing, and the > countermeasures presented in Section 5 were reached without confining > the consideration to means only available to routing. This section > > > Tsao, et al. Expires October 1, 2010 [Page 28] > > Internet-Draft Security Framework for ROLL March 2010 > > puts the results into perspective and provides a framework for > addressing the derived set of security objectives that must be met by > the ROLL protocol. > JP> s/ROLL protocol/Routing protocol specified by the ROLL Working Group. > It bears emphasizing that the target here is a > generic ROLL protocol and the normative keywords are mainly to convey > the relative level of urgency of the features specified. > > The first part of this section, Section 6.1 to Section 6.3, is a > prescription of ROLL security features of measures that can be > addressed as part of the routing protocol itself. As routing is one > component of a LLN system, the actual strength of the security > services afforded to it should be made to conform to each system's > security policy; how a design may address the needs of the urban, > industrial, home automation, and building automation application > domains also needs to be considered. The second part of this > section, Section 6.4 and Section 6.5, discusses system security > aspects that may impact routing but that also require considerations > beyond the routing protocol, as well as potential approaches. > > 6.1. Confidentiality Features > > With regard to confidentiality, protecting the routing/topology > information from eavesdropping or unauthorized exposure is not > directly essential to maintaining the routing function. Breaches of > confidentiality may lead to other attacks or the focusing of an > attacker's resources (see Section 4.1) but does not of itself > directly undermine the operation of the routing function. However, > to protect against, and improve vulnerability against other more > direct attacks, routing information confidentiality should be > protected. Thus, a secured ROLL protocol > > o SHOULD provide payload encryption; > > o MAY provide tunneling; > > o MAY provide load balancing; > JP> You can add a note and point to the requirement RFCs, where this is > listed as a requirement. > o SHOULD provide privacy, e.g., when geographic information is used. > > Where confidentiality is incorporated into the routing exchanges, > encryption algorithms and key lengths need to be specified in > accordance of the level of protection dictated by the routing > protocol and the associated application domain transport network. In > terms of the life time of the keys, the opportunity to periodically > change the encryption key increases the offered level of security for > any given implementation. However, where strong cryptography is > employed, physical, procedural, and logical data access protection > considerations may have more significant impact on cryptoperiod > selection than algorithm and key size factors. Nevertheless, in > > > Tsao, et al. Expires October 1, 2010 [Page 29] > > Internet-Draft Security Framework for ROLL March 2010 > > general, shorter cryptoperiods, during which a single key is applied, > will enhance security. > > Given the mandatory protocol requirement to implement routing node > authentication as part of routing integrity (see Section 6.2), key > exchanges may be coordinated as part of the integrity verification > process. This provides an opportunity to increase the frequency of > key exchange and shorten the cryptoperiod as a compliment to the key > length and encryption algorithm required for a given application > domain. For LLNs, the coordination of confidentiality key management > with the implementation of node device authentication can thus reduce > the overhead associated with supporting data confidentiality. A new > ciphering key may therefore be concurrently generated or updated in > conjunction with the mandatory authentication exchange occurring with > each routing peer association. > > 6.2. Integrity Features > > The integrity of routing information provides the basis for ensuring > that the function of the routing protocol is achieved and maintained. > To protect integrity, a secured ROLL protocol > > o MUST verify message integrity; > > o MUST verify the authenticity and liveliness of both principals of > a connection; > > o MUST verify message sequence. > > Depending on the nature of the routing protocol, e.g., distance > vector or link state, additional measures may be necessary when the > validity of the routing information is of concern. Specifically, > verification of routing peer authenticity and liveliness can be used > to build a "chain of trust" along the path the routing information > flows, such that network-wide information is validated through the > concatenation of trust established at each individual routing peer > exchange. This is particularly important in the case of distance > vector-based routing protocols, where information is updated at > intermediate nodes, In such cases, there are no direct means within > routing for a receiver to verify the validity of the routing > information beyond the current exchange; as such, nodes would need to > be able to communicate and request information from non-adjacent > peers (see [Wan2004]) to provide information integrity assurances. > With link state-based protocols, on the other hand, routing > information can be signed at the source thus providing a means for > validating information that originates beyond a routing peer. > Therefore, where necessary, a secured ROLL protocol > JP> You can remove the "o" below since there is no other ones. > > > Tsao, et al. Expires October 1, 2010 [Page 30] > > Internet-Draft Security Framework for ROLL March 2010 > > o MAY use security auditing mechanisms that are external to routing > to verify the validity of the routing information content > exchanged among routing peers. > > 6.3. Availability Features > > Availability of routing information is linked to system and network > availability which in the case of LLNs require a broader security > view beyond the requirements of the routing entities (see > Section 6.5). Where availability of the network is compromised, > routing information availability will be accordingly affected. > However, to specifically assist in protecting routing availability > > o MAY restrict neighborhood cardinality; > > o MAY use multiple paths; > > o MAY use multiple destinations; > > o MAY choose randomly if multiple paths are available; > > o MAY set quotas to limit transmit or receive volume; > > o MAY use geographic insights for flow control. > > 6.4. Additional Related Features > > If a LLN employs multicast and/or anycast, it MUST secure these > protocols > JP> "protocols" ? > with the services listed in this sections. Furthermore, > the nodes MUST provide adequate physical tamper resistance to ensure > the integrity of stored routing information. > > The functioning of the security services requires keys and > credentials. Therefore, even though not directly a ROLL security > requirement, a LLN must include a process for key and credential > distribution; a LLN is encouraged to have procedures for their > revocation and replacement. > > 6.5. Consideration on Matching Application Domain Needs > > As routing is one component of a LLN system, the actual strength of > the security services afforded to it should be made to conform to > each system's security policy; how a design may address the needs of > the urban, industrial, home automation, and building automation > application domains is considered as part of the security > architecture in Section 6.5.1. > > The development so far takes into account collectively the impacts of > > > Tsao, et al. Expires October 1, 2010 [Page 31] > > Internet-Draft Security Framework for ROLL March 2010 > > the issues gathered from [RFC5548], [RFC5673], > [I-D.ietf-roll-home-routing-reqs], and > [I-D.ietf-roll-building-routing-reqs]. > JP> Update the reference (all RFcs now). > The following two subsections > first consider from an architectural perspective how the security > design of a ROLL protocol may be made to adapt to the four > application domains, and then examine mechanism and protocol > operations issues. > > 6.5.1. Security Architecture > > The first challenge for a ROLL protocol security design is to have an > architecture that can adequately address a set of very diversified > needs. It is mainly a consequence of the fact that there are both > common and non-overlapping requirements from the four application > domains, while, conceivably, each individual application will present > yet its own unique constraints. > > For a ROLL protocol, the security requirements defined in Section 6.1 > to Section 6.4 can be addressed at two levels: 1) through measures > implemented directly within the routing protocol itself and initiated > and controlled by the routing protocol entities; or 2) through > measures invoked on behalf of the routing protocol entities but > implemented within the transport network > JP> Be accurate when you used "transport network": you mean "link layer" > ? > over which the protocol > exchanges occur. > > Where security is directly implemented as part of the routing > protocol the security requirements configured by the user (system > administrator) will operate independent of the underlying transport > network > JP>s/transport network/link layer > . OSPFv2 [RFC2328] is an example of such an approach in which > security parameters are exchanged and assessed within the routing > protocol messages. In this case, the mechanism may be, e.g., a > header containing security material of configurable security > primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec > [RFC4301] is employed to secure the network, the included protocol- > specific (OSPF or RIP) security elements are in addition to and > independent of those at the network layer. In the case of LLNs or > other networks where system security mandates protective mechanisms > at other lower layers of the transport network, > JP> "lower layers of the transport network" is ambiguous. > security measures > implemented as part of the routing protocol will be redundant to > security measures implemented elsewhere as part of the transport > network. > JP> Please replace "transport network" with appropriate terminology where > needed. > Thanks. > Security mechanisms built into the routing protocol can ensure that > all desired countermeasures can be directly addressed by the protocol > all the way to the endpoint of the routing exchange. In particular, > routing protocol Byzantine attacks by a compromised node that retains > valid network security credentials can only be detected at the level > of the information exchanged within the routing protocol. Such > > > Tsao, et al. Expires October 1, 2010 [Page 32] > > Internet-Draft Security Framework for ROLL March 2010 > > attacks aimed the manipulation of the routing information can only be > fully addressed through measures operating directly between the > routing entities themselves or external entities able to access and > analyze the routing information (see discussion in Section 5.2.5). > > On the other hand, it is more desirable from a LLN device perspective > that the ROLL protocol is integrated into the framework of an overall > system architecture where the security facility may be shared by > different applications and/or across layers for efficiency, and where > security policy and configurations can be consistently specified. > See, for example, considerations made in RIPng [RFC2080] or the > approach presented in [Messerges2003]. > > Where the routing protocol is able to rely on security measures > configured with the transport network > JP> Same comment. What do you mean by "transport network"? > , greater system efficiency can > be realized by avoiding potentially redundant security. Relying on > an open trust model [Messerges2003], the security requirements of the > routing protocol can be more flexibly met at different layers of the > transport network; measures that must be applied to protect the > communications network are concurrently able to provide the needed > routing protocol protection. > > In addition, in the context of the different application domains, it > allows the level of security applied for routing to be consistent > with that needed for protecting the network itself. For example, > where AES-128 > JP> Expand terms when first used + add reference > is deemed the appropriate standard for network > confidentiality of data exchanges at the link layer, that level of > security is automatically afforded to routing protocol exchanges. > Similarly, where SHA-1 > JP> Same comment > is stipulated as the standard required for > authenticating routing protocol peers, the use of SHA-1 at the > network layer between communicating routing devices automatically > meets the routing protocol security requirement within the context of > open trust across layers within the device. > > A ROLL protocol MUST be made flexible by a design that offers the > configuration facility so that the user (network administrator) can > choose the security settings that match the application's needs. > Furthermore, in the case of LLNs that flexibility should extend to > allowing the routing protocol security requirements to be met by > measures applied at different protocol layers, provided the > identified requirements are collectively met. > > Since Byzantine attacks that can affect the validity of the > information content exchanged between routing entities can only be > directly countered at the routing protocol level, the ROLL protocol > may support mechanisms for verifying routing data validity that > extends beyond the chain of trust created through device > authentication. This protocol-specific security mechanism should be > > > Tsao, et al. Expires October 1, 2010 [Page 33] > > Internet-Draft Security Framework for ROLL March 2010 > > made optional within the protocol allowing it to be invoked according > to the given routing protocol and application domain and as selected > by the system user. All other ROLL security mechanisms needed to > meet the above identified routing security requirements should be > flexibly implemented within the transport network (at the IP network > layer or higher or lower protocol layers(s)) according to the > particular application domain and user network configuration. > > Based on device capabilities and the spectrum of operating > environments it would be difficult for a single fixed security design > to be applied to address the diversified needs of the four ROLL > application domains > JP> Please list them again (urban, industrial, home/building) + indicate > that this is also > true for other application domains. > without forcing a very low common denominator set > of requirements. On the other hand, providing four individual domain > designs that attempt to a priori match each individual domain is also > very likely to provide a suitable answer given the degree of network > variability even within a given domain. > JP> The type of link layers in use within each domain also influences the > overall security. > Instead, the framework > implementation approach recommended for optional, routing protocol- > specific measures together with flexible transport network mechanisms > can be the most effective. This approach allows countermeasures > against internal attacks to be applied in environments where > applicable threats exist. At the same time, it allows routing > protocol security to be configured through measures implemented > within the transport network that is commensurate and consistent with > the level and strength applied in the particular application domain > networks. > > 6.5.2. Mechanisms and Operations > > With an architecture allowing different configurations to meet the > application domain needs, the task is then to find suitable > mechanisms. For example, one of the main problems of synchronizing > security states of sleepy nodes, as listed in the last subsection, > lies in difficulties in authentication; these nodes may not have > received in time the most recent update of security material. > Similarly, the issues of minimal manual configuration, prolonged > rollout and delayed addition of nodes, and network topology changes > also complicate security management. In such case the ROLL protocol > may need to bootstrap the authentication process and allow for > flexible expiration scheme of authentication credentials. This > exemplifies the need for the coordination and interoperation between > the requirements of the ROLL routing protocol and that of the system > security elements. > > Similarly, the vulnerability brought forth by some special-function > nodes, e.g., gateways/sinks requires the assurance, particularly, of > the availability of communication channels and node resources, or > that the neighbor discovery process operates without undermining > routing availability. > > > Tsao, et al. Expires October 1, 2010 [Page 34] > > Internet-Draft Security Framework for ROLL March 2010 > > There and other factors which are not part of a ROLL routing protocol > can still affect its operation. This includes elements such as > weaker barrier to accessing the data or security material stored on > the nodes through physical means; therefore, the internal and > external interfaces of a node need to be adequate for guarding the > integrity, and possibly the confidentiality, of stored information, > as well as the integrity of routing and route generation processes. > > Figure 2 provides an overview of the larger context of system > security and the relationship between ROLL requirements and measures > and those that relate to the LLN system. > > > > > > > > > > > > > > > > > > > > > Tsao, et al. Expires October 1, 2010 [Page 35] > > Internet-Draft Security Framework for ROLL March 2010 > > Security Services for > ROLL-Addressable > Security Requirements > | | > +---+ +---+ > Node_i | | Node_j > _____v___ ___v_____ > Specify Security / \ / \ Specify Security > Requirements | Routing | | Routing | Requirements > +---------| Protocol| | Protocol|---------+ > | | Entity | | Entity | | > | \_________/ \_________/ | > | | | | > |ROLL-Specified | | ROLL-Specified| > ---Interface | | Interface--- > | ...................................... | > | : | | : | > | : +-----+----+ +----+-----+ : | > | : |Transport/| |Transport/| : | > ____v___ : +>|Network | |Network |<+ : ___v____ > / \ : | +-----+----+ +----+-----+ | : / \ > | |-:-+ | | +-:-| | > |Security| : +-----+----+ +----+-----+ : |Security| > +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ > | |Entity | : +-----+----+ +----+-----+ : |Entity | | > | | |-:-+ | | +-:-| | | > | \________/ : | +-----+----+ +----+-----+ | : \________/ | > | : +>| Physical | | Physical |<+ : | > Application : +-----+----+ +----+-----+ : Application > Domain User : | | : Domain User > Configuration : |__Comm. Channel_| : Configuration > : : > ...Transport Network.................. > > Figure 2: LLN Device Security Model > JP> Great figure. Just clarify "transport/network" > > > 7. Application of ROLL Security Framework to RPL > JP> Expand acronym when first used (RPL) > > This section applies the assessments given in Section 6 to RPL > JP> Ad reference (draft-ietf-roll-rpl) > as an > illustration of the application of the LLN security framework. > > Specializing the approach used in Section 3.1, Figure 3 gives a > level-1 data flow diagram representation of RPL to show the routing > "assets" and "points of access" that may be vulnerable and need to be > protected. > > > Tsao, et al. Expires October 1, 2010 [Page 36] > > Internet-Draft Security Framework for ROLL March 2010 > > ............................................ > : : > |Link-Local : : > Multicast : : > or Node_i|<----->(DIO/DIS/DAO)<--------------+ : > : ^ | : > : | ______V______ : > : | Candidate : > : V Neighbor List : > : (RPL Control incl. ------+------ : > : Trickle Timer, | : > : Loop Avoidance) V : > : ^ (Route Generation) : > : | | : > : | ______V______ : > : +------+ Routing Table : > : | ------+------ : > : | | : > : RPL on Node_j | | : > ..................|.............|........... > | | > |Forwarding V | > To/From Node_k|<-------->(Read/Write | > Flow Label)<-------+ > > Figure 3: Data Flow Diagram of RPL > > From Figure 3, it is seen that threats to the proper operation of RPL > are realized through attacks on its DIO, DIS, and DAO messages, as > well as on the information the protocol places on the IPv6 Flow > Labels. > JP> Please update since information is now carried in the Hop-by-hop > header > with the RPL option (draft in 6man). > As set forth in Section 6.1 to Section 6.4, the base > security requirements concern message integrity, authenticity and > liveliness of the principals of a connection, and protection against > message replay; message encryption may be desirable. The security > objectives for RPL are therefore to ensure that > > 1. participants of the DIO, DIS, and DAO message exchanges are > authentic; > > 2. the received DIO, DIS, and DAO messages are not modified during > transportation; > > 3. the received DIO, DIS, and DAO messages are not retransmissions > of previous messages; > > 4. the content of the DIO, DIS, and DAO messages may be made legible > to only authorized entities. > > > Tsao, et al. Expires October 1, 2010 [Page 37] > > Internet-Draft Security Framework for ROLL March 2010 > > In meeting the above objectives, RPL also needs to provide tunable > mechanisms both to allow matching the security afforded to the > application domain requirements and to enable efficient use of system > resources, as discussed in Section 6.5.1 and Section 6.5.2. > > The functions of the different RPL messages and information placed > within the user data plane Flow Labels > JP> s/"user data plane"/"user data plane (RPL option TLV carried in the > IPv6 Hop-by-hop header) > are factors that can be taken > into account when deciding the optional security features and levels > of strength to be afforded. For example, the DIO messages build > routes to roots while the DAO messages support the building of > downward routes to leaf nodes. Consequently, there may be > application environments in which the directions of the routes have > different importance and thus warrant the use of different security > features and/or strength. In other words, it may be desirable to > have an RPL security design that extends the tunability of the > security features and strengths to message types. The use of a per- > message security specification will allow flexibility in permitting > application-domain security choices as well as overall tunability. > > 8. IANA Considerations > > This memo includes no request to IANA. > > 9. Security Considerations > > The framework presented in this document provides security analysis > and design guidelines with a scope limited to ROLL. Security > services are identified as requirements for securing ROLL. The > results are applied to RPL, with consequent recommendations. > > 10. Acknowledgments > > The authors would like to acknowledge the review and comments from > Rene Struik. > > 11. References > > 11.1. Normative References > > [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, > January 1997. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > Tsao, et al. Expires October 1, 2010 [Page 38] > > Internet-Draft Security Framework for ROLL March 2010 > > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > > [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, > November 1998. > > [RFC4301] Kent, S. and K. Seo, "Security Architecture for the > Internet Protocol", RFC 4301, December 2005. > > 11.2. Informative References > > [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. > > [I-D.ietf-roll-building-routing-reqs] > Martocci, J., Riou, N., Mil, P., and W. Vermeylen, > "Building Automation Routing Requirements in Low Power and > Lossy Networks", draft-ietf-roll-building-routing-reqs-09 > (work in progress), January 2010. > > [I-D.ietf-roll-home-routing-reqs] > Brandt, A. and J. Buron, "Home Automation Routing > Requirements in Low Power and Lossy Networks", > draft-ietf-roll-home-routing-reqs-11 (work in progress), > January 2010. > > JP> Update the two references above. > [I-D.ietf-roll-rpl] > Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing > Protocol for Low power and Lossy Networks", > draft-ietf-roll-rpl-07 (work in progress), March 2010. > > [I-D.ietf-roll-terminology] > Vasseur, J., "Terminology in Low power And Lossy > Networks", draft-ietf-roll-terminology-03 (work in > progress), March 2010. > > [I-D.suhopark-hello-wsn] > Park, S., "Routing Security in Sensor Network: HELLO Flood > Attack and Defense", draft-suhopark-hello-wsn-00 (work in > progress), December 2005. > > [Karlof2003] > Karlof, C. and D. Wagner, "Secure routing in wireless > sensor networks: attacks and countermeasures", Elsevier > > > Tsao, et al. Expires October 1, 2010 [Page 39] > > Internet-Draft Security Framework for ROLL March 2010 > > AdHoc Networks Journal, Special Issue on Sensor Network > Applications and Protocols, 1(2):293-315, September 2003. > > [Messerges2003] > Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, > R., and E. Callaway, "Low-Power Security for Wireless > Sensor Networks", in Proceedings of the 1st ACM Workshop > on Security of Ad Hoc and Sensor Networks, Fairfax, VA, > USA, pp. 1-11, Oct. 31 2003. > > [Myagmar2005] > Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as > a Basis for Security Requirements", in Proceedings of the > Symposium on Requirements Engineering for Information > Security (SREIS'05), Paris, France, pp. 94-102, Aug > 29, 2005. > > [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to > Routing Protocols", RFC 4593, October 2006. > > [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", > RFC 4949, August 2007. > > [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, > "Routing Requirements for Urban Low-Power and Lossy > Networks", RFC 5548, May 2009. > > [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, > "Industrial Routing Requirements in Low-Power and Lossy > Networks", RFC 5673, October 2009. > > [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A > Secure Distance Vector Routing Protocol", in Proceedings > of the 2nd International Conference on Applied > Cryptography and Network Security, Yellow Mountain, China, > pp. 103-119, Jun. 8-11 2004. > > Authors' Addresses > > Tzeta Tsao (editor) > Eka Systems > 20201 Century Blvd. Suite 250 > Germantown, Maryland 20874 > USA > > Email: tzeta.tsao@ekasystems.com > > > Tsao, et al. Expires October 1, 2010 [Page 40] > > Internet-Draft Security Framework for ROLL March 2010 > > Roger K. Alexander (editor) > Eka Systems > 20201 Century Blvd. Suite 250 > Germantown, Maryland 20874 > USA > > Email: roger.alexander@ekasystems.com > > Mischa Dohler (editor) > CTTC > Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N > Castelldefels, Barcelona 08860 > Spain > > Email: mischa.dohler@cttc.es > > Vanesa Daza (editor) > Universitat Pompeu Fabra > P/ Circumval.lacio 8, Oficina 308 > Barcelona 08003 > Spain > > Email: vanesa.daza@upf.edu > > Angel Lozano (editor) > Universitat Pompeu Fabra > P/ Circumval.lacio 8, Oficina 309 > Barcelona 08003 > Spain > > Email: angel.lozano@upf.edu > > JP> Are you all editors ? if so, remove the term "Editors" > > > > > > > > > > Tsao, et al. Expires October 1, 2010 [Page 41] New description: Hi, Please find below some detailed comments - Overall well-written document. In addition to the comments in-line (search for JP>), I would welcome a few diagrams especially when you describe the different types of attacks. Furthermore, as you will see in the comments, be careful not to make the assumption of wireles links (there are many LLNs with wireless links of course) but this is not the only type of links. Same comment for the node type (they are not all battery operated). Thanks ! I will open a ticket capturing all of the comments below. JP> Starting with ID nits: Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: A later version (-11) exists of draft-ietf-roll-rpl-07 Networking Working Group T. Tsao, Ed. Internet-Draft R. Alexander, Ed. Intended status: Informational Eka Systems Expires: October 1, 2010 M. Dohler, Ed. CTTC V. Daza, Ed. A. Lozano, Ed. Universitat Pompeu Fabra March 30, 2010 A Security Framework for Routing over Low Power and Lossy Networks draft-ietf-roll-security-framework-00 Abstract This document presents a security framework for routing over low power and lossy networks. JP> Add acronym (LLN) The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. JP> Expand acronym when first used (LLN here). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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." Tsao, et al. Expires October 1, 2010 [Page 1] Internet-Draft Security Framework for ROLL March 2010 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 October 1, 2010. Copyright Notice Copyright (c) 2010 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. Tsao, et al. Expires October 1, 2010 [Page 2] Internet-Draft Security Framework for ROLL March 2010 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 11 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 4.1.2. Routing Information (Routes and Network Topology) Exposure . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 4.2.1. Routing Information Manipulation . . . . . . . . . . . 14 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 14 4.3. Threats and Attacks on Availability . . . . . . . . . . . 15 4.3.1. Routing Exchange Interference or Disruption . . . . . 15 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 15 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 16 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 17 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 17 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 19 5.1.4. Countering Physical Device Compromise . . . . . . . . 19 5.1.5. Countering Remote Device Access Attacks . . . . . . . 21 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 21 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 22 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 5.2.3. Countering Identity (including Sybil) Attacks . . . . 22 5.2.4. Countering Routing Information Replay Attacks . . . . 23 5.2.5. Countering Byzantine Routing Information Attacks . . . 23 5.3. Availability Attack Countermeasures . . . . . . . . . . . 24 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 27 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 29 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 30 6.3. Availability Features . . . . . . . . . . . . . . . . . . 31 6.4. Additional Related Features . . . . . . . . . . . . . . . 31 6.5. Consideration on Matching Application Domain Needs . . . . 31 Tsao, et al. Expires October 1, 2010 [Page 3] Internet-Draft Security Framework for ROLL March 2010 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 34 7. Application of ROLL Security Framework to RPL . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Tsao, et al. Expires October 1, 2010 [Page 4] Internet-Draft Security Framework for ROLL March 2010 1. Terminology This document conforms to the terminology defined in [I-D.ietf-roll-terminology]. JP> There are other terms used in the document that could be added here (see below). 2. Introduction In recent times, networked wireless devices have found an increasing number of applications in various fields. Yet, for reasons ranging from operational application to economics, these wireless devices JP> This does not apply only to wireless links (e.g. PLC) are often supplied with minimum physical resources, e.g., limited power reserve, slow speed or low capability computation, or small memory size. As a consequence, the resulting networks are more prone to loss of traffic and other vulnerabilities. The proliferation of these low power and lossy networks (LLNs), however, are drawing efforts to examine and address their potential networking challenges. This document presents a framework for securing routing over low power and lossy networks (ROLL) JP> s/ROLL/LLN through an analysis that starts from the routing basics. The objective is two-fold. First, the framework will be used to identify pertinent security issues. Second, it will facilitate both the assessment of a protocol's security threats and the identification of the necessary features for development of secure protocols for ROLL. JP> s/ROLL/The ROLL Working Group. The approach adopted in this effort proceeds in four steps, to examine ROLL security issues, to analyze threats and attacks, to consider the countermeasures, and then to make recommendations for securing ROLL. JP> Could you just replace "ROLL" by the "the routing protocol developed by the ROLL Working Group" or Define ROLL as Routing Over Low power and Lossy networks. The basis is found on identifying the assets and points of access of routing and evaluating their security needs based on the Confidentiality, Integrity, and Availability (CIA) model in the context of LLN. The utility of this framework is demonstrated with an application to RPL [I-D.ietf-roll-rpl]. 3. Considerations on ROLL Security This section sets the stage for the development of the framework by applying the systematic approach proposed in [Myagmar2005] to the routing security problem, while also drawing references from other reviews and assessments found in the literature, particularly, [RFC4593] and [Karlof2003]. The subsequent subsections begin with a focus on the elements of a generic routing process that is used to establish routing assets and points of access of the routing functionality. Next, the CIA security model is briefly described. Then, consideration is given to issues specific to or amplified in LLNs. This section concludes with the formulation of a set of Tsao, et al. Expires October 1, 2010 [Page 5] Internet-Draft Security Framework for ROLL March 2010 security objectives for ROLL. 3.1. Routing Assets and Points of Access An asset implies important system component (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In network routing, assets lie in the routing information, routing process, and node's physical resources. That is, the access to, corruption, or loss of these elements adversely affects system routing. In network routing, a point of access refers to the point of entry facilitating communication with or other interaction with a system component in order to use system resources to either manipulate information or gain knowledge of the information contained within the system. Security of the routing protocol must be focused on the assets of the routing nodes and the points of access of the information exchanges and information storage that may permit routing compromise. The identification of routing assets and points of access hence provides a basis for the identification of associated threats and attacks. This subsection identifies assets and points of access of a generic routing process with a level-0 JP> Explain what you mean by "level-0" data flow diagram. The use of the data flow diagram allows for a clear, concise model of the routing functionality; it also has the benefit of showing the manner in which nodes participate in the routing process, thus providing context when later threats and attacks are considered. The goal of the model is to be as detailed as possible so that corresponding components and mechanisms in an individual routing protocol can be readily identified, but also to be as general as possible to maximize the relevancy of this effort for the various existing and future protocols. Nevertheless, there may be discrepancies, likely in the form of additional elements, when the model is applied to some protocols. For such cases, the analysis approach laid out in this document should still provide a valid and illustrative path for their security assessment. Figure 1 shows that nodes participating in the routing process transmit messages to determine their neighbors (neighbor discovery). Using the neighboring relationships, routing protocols may exchange network topology (including link-specific information) to generate routes or may exchange routes directly as part of a routing exchange; nodes which do not directly participate in the process with a given node will get the route/topology information relayed from others. JP> You can remove the previous sentence (no need to make assumption in in a framework on the mode of operation of the routing protocol). It is likely that a node will store some or all of the routes and topology information according to tradeoffs of node resources and latency associated with the particular routing protocol. JP> Why tradeoff with latency ? The nodes use the derived routes for making forwarding decisions. Tsao, et al. Expires October 1, 2010 [Page 6] Internet-Draft Security Framework for ROLL March 2010 ................................................... : : : _________________ : |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology : : -------+--------- : : | : |Node_j|<------->(Route/Topology +--------+ : : Exchange) | : : | V ______ : : +---->(Route Generation)--->Routes : : ---+-- : : | : : Routing on a Node Node_k | : ................................................... | |Forwarding | On Node_l|<-------------------------------------------+ Notation: (Proc) A process Proc ________ DataBase A data storage DataBase -------- |Node_n| An external entity Node_n -------> Data flow Figure 1: Data Flow Diagram of a Generic Routing Process It is seen from Figure 1 that o Assets include * routing and/or topology information; * communication channel resources (bandwidth); * node resources (computing capacity, memory, and remaining energy); * node identifiers (including node identity and ascribed attributes such as relative or absolute node location). Tsao, et al. Expires October 1, 2010 [Page 7] Internet-Draft Security Framework for ROLL March 2010 o Points of access include * neighbor discovery; * route/topology exchange; * node physical interfaces (including access to data storage). A focus on the above list of assets and points of access enables a more directed assessment of routing security. Indeed, the intention is to be comprehensive; nonetheless, the discussions to follow on physical related issues are not related to routing protocol design but provided for reference since they do have direct consequences on the security of routing. 3.2. The CIA Security Reference Model At the conceptual level, security within an information system in general and applied to ROLL in particular is concerned with the primary issues of confidentiality, integrity, and availability. In the context of ROLL: Confidentiality Confidentiality involves the protection of routing information as well as routing neighbor maintenance exchanges so that only authorized and intended network entities may view or access it. JP> By "neighbor" just mention that we're referring to routing neighbor in the context on this document. Because of the wireless, JP> Not always wireless ! Just make sure to make it clear even if the comment below applies to wireless links. and sometimes ad hoc, nature of the network, confidentiality also extends to the neighbor state and database information within the routing device since the deployment of the network creates the potential for unauthorized access to the physical devices themselves. Integrity Integrity, as a security principle, entails the protection of routing information and routing neighbor maintenance exchanges, as well as derived information maintained in the database, from misuse or unauthorized and improper modification. In addition, integrity also requires JP> Is it really integrity that requires authenticity ? the authenticity of claimed identity in the origin and destination of a message, access and removal of data, execution of the routing process, and use of computing and energy resources. Availability Availability ensures that routing information exchanges and forwarding services need to be available when they are required for the functioning of the serving network. Availability will apply to maintaining efficient and correct operation of routing and neighbor discovery exchanges (including needed information) Tsao, et al. Expires October 1, 2010 [Page 8] Internet-Draft Security Framework for ROLL March 2010 and forwarding services so as not to impair or limit the network's central traffic flow function. It is noted that, besides those captured in the CIA model, non- repudiation is a security interest under certain circumstances. With respect to routing, non-repudiation will involve providing some ability to allow traceability or network management review of participants of the routing process including the ability to determine the events and actions leading to a particular routing state. Non-repudiation implies after the fact and thus relies on the logging or other capture of on-going routing exchanges. Given the limited resources of a node and potentially the communication channel, and considering the operating mode associated with LLNs, routing transaction logging or auditing process communication overhead will not be practical; as such, non-repudiation is not further considered as a relevant ROLL security issue. JP> May be one sentence to define "non-repudiation" would be helpful 3.3. Issues Specific to or Amplified in LLNs The work [RFC5548] and [RFC5673], as well as two other ongoing efforts, [I-D.ietf-roll-home-routing-reqs] and [I-D.ietf-roll-building-routing-reqs], JP> Update the draft-ietf references. They are all RFC (5826 and 5867 respectively). have identified ROLL JP> "ROLL specific" -> "routing requirement specific to LLNs" specific requirements and constraints for the urban, industrial, home automation, and building automation application domains, respectively. The following is a list of observations and evaluation of their impact on routing security considerations. Limited energy reserve JP> s/reserve/resources/ , memory, and processing resources JP> s/processing resources/processing nodes resources/ As a consequence of these constraints, there is an even more critical need than usual for a careful trade study on which and what level of security services are to be afforded during the system design process. In addition, the choices of security mechanisms are more stringent. Synchronization of security states with sleepy nodes is yet another issues. JP>s/issues/issue Large scale of rolled out network JP> You can mention "from a few dozens to several (hundreds) of thousands of nodes" The possibly numerous nodes to be deployed, as well as the general level of expertise of the installers, make manual on- site configuration unlikely. Prolonged rollout and delayed addition of nodes, which may be from old inventory, over the lifetime of the network, also complicate the operations of key management. Autonomous operations Self-forming and self-organizing are commonly prescribed requirements of ROLL JP> s/ROLL/LLNs . In other words, a ROLL protocol JP> A Routing protocol designed for LLNs needs to contain elements of ad hoc networking and cannot JP> (in most cases) rely on manual configuration for initialization or local filtering rules. Tsao, et al. Expires October 1, 2010 [Page 9] Internet-Draft Security Framework for ROLL March 2010 Network topology/ownership changes, partitioning or merging, as well as node replacement, can all contribute to key management issues. Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the gateways JP> Use "LBR" as defined in http://datatracker.ietf.org/doc/draft-ietf- roll-terminology/ instead of gateway where the LLNs connect to wired networks. JP> s/wired networks/to non LLN network (since wired links may be present in LLNs) The special routing status of and the greater volume of traffic near the gateways/sinks JP> Same comment use only the LBR terminology throughout the document. have routing security consequences. JP> You can mention that when P2MP and MP2P traffic represents a majority of the traffic routing attacks consisting of advertising low route cost may cause serious damages. Unattended locations and limited physical security Many applications have the nodes deployed in unattended or remote locations; furthermore, the nodes themselves are often built with minimal physical protection. These constraints lower the barrier of accessing the data or security material stored on the nodes through physical means. Support for mobility On the one hand, only a number of applications require the support of mobile nodes, e.g., a home LLN that includes nodes on wearable health care devices or an industry LLN that includes nodes on cranes and vehicles. On the other hand, if a routing protocol is indeed used in such applications, it will clearly need to have corresponding security mechanisms. Support for multicast and anycast Support for multicast and anycast is called out chiefly for large-scale networks. As these are relatively new routing technologies, JP> Heu ... Multicast is not really new there has been an ongoing effort devoted to their security mechanisms, e.g., from the IETF Multicast Security working group. However, inclusion of such mechanisms in a routing protocol, and consequently their security analysis, are still areas not fully developed or their impact entirely understood, whether in a more traditional wired or wireless network, or LLN. The above list considers how a LLN's physical constraints, size, operations, and varieties of application areas may impact security. It is noted here also that LLNs commonly have the majority, if not all, of their nodes equipped to route. JP> I would suppress the previous sentence, since in this document we are only considering nodes acting as routers. One of the consequences is that the distinction between the link and network layers become artificial in some respects. Similarly, the distinction between a host and a router is blurred, especially when the set of applications running on a node is small. JP> Same thing for the previous sentence, which may be misleading. The continued evolution of ROLL and its security functionality requirements need close attention. JP> s/ROLL/routing protocol designed by the ROLL WG Tsao, et al. Expires October 1, 2010 [Page 10] Internet-Draft Security Framework for ROLL March 2010 3.4. ROLL Security Objectives This subsection applies the CIA model to the routing assets and access points, taking into account the LLN issues, to develop a set of ROLL security objectives. Since the fundament function of a routing protocol is to build routes for forwarding packets, it is essential to ensure that o routing/topology information is not tampered during transfer and in storage; o routing/topology information is not misappropriated; o routing/topology information is available when needed. In conjunction, it is necessary to be assured of o the authenticity and legitimacy of the participants of the JP> routing neighbor neighbor discovery process; o the routing/topology information received was faithfully generated according to the protocol design. However, when trust cannot be fully vested through authentication of the principals alone, i.e., concerns of insider attack, assurance of the truthfulness and timeliness of the received routing/topology information is necessary. With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is in itself less pertinent in general to the routing function. One of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate key management. Hence, ROLL JP> Change ROLL for routing in LLN needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. The vulnerability brought forth by some special-function nodes, e.g., gateways/sinks JP> Change for LBR requires the assurance, particularly, o of the availability of communication channels and node resources; JP> but how to ensure and the unavailable of the channels is due to a security attack as opposed to simply being not operational? o that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 11] Internet-Draft Security Framework for ROLL March 2010 There are other factors which are not part of a ROLL protocol but directly affecting its function. These factors include weaker barrier of accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Each individual system's use and environment will dictate how the above objectives are applied, including the choices of security services as well as the strengths of the mechanisms that must be implemented. The next two sections give a closer look at how the ROLL security objectives may be compromised and countered, respectively. 4. Threats and Attacks This section outlines general categories of threats under the CIA model and highlights the specific attacks in each of these categories for ROLL. As defined in [RFC4949], a threat is "a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm." An attack is "an assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system." The subsequent subsections consider the threats and their realizing attacks that can cause security breaches under the CIA model to the assets identified in Section 3.1. The analysis steps through the security concerns of each routing asset and looks at the attacks that can exploit points of access. The manifestation of the attacks is assumed to be from either inside or outside attackers, whose capabilities may be limited to node-equivalent or more sophisticated computing platforms. 4.1. Threats and Attacks on Confidentiality The assessment in Section 3.2 indicates that information assets are exposed to confidentiality threats from all points of access. 4.1.1. Routing Exchange Exposure Routing exchanges include both routing information as well as information associated with the establishment and maintenance of neighbor state information. Tsao, et al. Expires October 1, 2010 [Page 12] Internet-Draft Security Framework for ROLL March 2010 The exposure of routing information exchanged will allow unauthorized sources to gain access to the content of the exchanges between communicating nodes. The exposure of neighbor state information will allow unauthorized sources to gain knowledge of communication links between routing nodes that are necessary to maintain routing information exchanges. The forms of attack that allow unauthorized access or exposure of routing exchange information, as reported in the literature, include o Deliberate exposure; o Sniffing; o Traffic analysis. 4.1.2. Routing Information (Routes and Network Topology) Exposure Routes and neighbor topology information are the products of the routing process that are stored within the node device databases. The exposure of this information will allow unauthorized sources to gain direct access to the configuration and connectivity of the network thereby exposing routing to targeted attacks on key nodes or links. Since routes and neighbor topology information is stored within the node device, threats or attacks on the confidentiality of the information will apply to the physical device including specified and unspecified internal and external interfaces. The forms of attack that allow unauthorized access or exposure of the routing information (other than occurring through explicit node exchanges) will include o Physical device compromise; o Remote device access attacks (including those occurring through remote network management or software/field upgrade interfaces). More detailed descriptions of the exposure attacks on routing exchange and information will be given in Section 5 together with the corresponding countermeasures. 4.2. Threats and Attacks on Integrity The assessment in Section 3.2 indicates that information and identity assets are exposed to integrity threats from all points of access. Tsao, et al. Expires October 1, 2010 [Page 13] Internet-Draft Security Framework for ROLL March 2010 4.2.1. Routing Information Manipulation Manipulation of routing information will allow unauthorized sources to influence the operation and convergence of the routing protocols and ultimately impact the forwarding decisions made in the network. Manipulation of neighbor state (topology) JP> topology and reachability information information will allow unauthorized sources to influence the nodes with which routing information is exchanged and updated. The consequence of manipulating routing exchanges can thus lead to sub-optimality and fragmentation or partitioning of the network by restricting the universe of routers with which associations can be established and maintained. JP> Can also lead to attract traffic, black-holes, ... The forms of attack that allow manipulation to compromise the content and validity of routing information include o Falsification, including overclaiming and misclaiming; o Routing information replay; o Byzantine (internal) attacks that permit corruption of routing information in the node even where the node continues to be a validated entity within the network; o Physical device compromise. 4.2.2. Node Identity Misappropriation Falsification or misappropriation of node identity between routing participants opens the door for other attacks; it can also cause incorrect routing relationships to form and/or topologies to emerge. Routing attacks may also be mounted through less sophisticated node identity misappropriation in which the valid information broadcast or exchanged by a node is replayed without modification. The receipt of seemingly valid information that is however no longer current can result in routing disruption, and instability (including failure to converge). Without measures to authenticate the routing participants and to ensure the freshness and validity of the received information the protocol operation can be compromised. The forms of attack that misuse node identity include o Identity (including Sybil) attacks; o Routing information replay. Tsao, et al. Expires October 1, 2010 [Page 14] Internet-Draft Security Framework for ROLL March 2010 4.3. Threats and Attacks on Availability The assessment in Section 3.2 indicates that the process and resources assets are exposed to availability threats; attacks of this category may exploit directly or indirectly information exchange or forwarding. 4.3.1. Routing Exchange Interference or Disruption Interference or disruption of routing information exchanges will allow unauthorized sources to influence the operation and convergence of the routing protocols by impeding the regularity of routing information exchange. The forms of attack that allow interference or disruption of routing exchange include o Routing information replay; o HELLO flood attacks and ACK spoofing; o Overload attacks. 4.3.2. Network Traffic Forwarding Disruption The disruption of the network traffic forwarding capability of the network will undermine the central function of network routers and the ability to handle user traffic. This threat and the associated attacks affect the availability of the network because of the potential to impair the primary capability of the network. The forms of attack that allows disruption of network traffic forwarding include o Selective forwarding attacks; o Sinkhole attacks; o Wormhole attacks. JP> Can you add reference to sinkhole and wormhole attacks? 4.3.3. Communications Resource Disruption Attacks mounted against the communication channel resource assets needed by the routing protocol can be used as a means of disrupting its operation. However, while various forms of Denial of Service (DoS) attacks on the underlying transport subsystem will affect routing protocol exchanges and operation (for example physical layer RF jamming in a wireless network or link layer attacks), these Tsao, et al. Expires October 1, 2010 [Page 15] Internet-Draft Security Framework for ROLL March 2010 attacks cannot be countered by the routing protocol. As such, the threats to the underlying transport network that supports routing is considered beyond the scope of the current document. Nonetheless, attacks on the subsystem will affect routing operation and so must be directly addressed within the underlying subsystem and its implemented protocol layers. 4.3.4. Node Resource Exhaustion A potential security threat to routing can arise from attempts to exhaust the node resource asset by initiating exchanges that can lead to the undue utilization of exhaustion of processing, memory or energy resources. The establishment and maintenance of routing neighbors opens the routing process to engagement and potential acceptance of multiple neighboring peers. Association information must be stored for each peer entity and for the wireless network operation provisions made to periodically update and reassess the associations. An introduced proliferation of apparent routing peers can therefore have a negative impact on node resources. Node resources may also be unduly consumed by the attackers attempting uncontrolled topology peering or routing exchanges, routing replays, or the generating of other data traffic floods. Beyond the disruption of communications channel resources, these threats may be able to exhaust node resources only where the engagements are able to proceed with the peer routing entities. Routing operation and network forwarding functions can thus be adversely impacted by node resources exhaustion that stems from attacks that include o Identity (including Sybil) attacks; o Routing information replay attacks; o HELLO flood attacks and ACK spoofing; o Overload attacks. 5. Countermeasures By recognizing the characteristics of LLNs that may impact routing and identifying potential countermeasures, this framework provides the basis for developing capabilities within ROLL protocols to deter the identified attacks and mitigate the threats. The following subsections consider such countermeasures by grouping the attacks according to the classification of the CIA model so that associations with the necessary security services are more readily visible. Tsao, et al. Expires October 1, 2010 [Page 16] Internet-Draft Security Framework for ROLL March 2010 However, the considerations here are more systematic than confined to means available only within routing; the next section will then distill and make recommendations appropriate for a secured ROLL protocol. 5.1. Confidentiality Attack Countermeasures Attacks on confidentiality may be mounted at the level of the routing information assets, at the points of access associated with routing exchanges between nodes, or through device interface access. To gain access to routing/topology information, the attacker may rely on a compromised node that deliberately exposes the information during the routing exchange process, may rely on passive sniffing or analysis of routing traffic, or may attempt access through a component or device interface of a tampered routing node. 5.1.1. Countering Deliberate Exposure Attacks A deliberate exposure attack is one in which an entity that is party to the routing process or topology exchange allows the routing/ topology information or generated route information to be exposed to an unauthorized entity during the exchange. A prerequisite to countering this type of confidentiality attacks associated with the routing/topology exchange is to ensure that the communicating nodes are authenticated prior to data encryption applied in the routing exchange. Authentication ensures that the nodes are who they claim to be even though it does not provide an indication of whether the node has been compromised. To prevent deliberate exposure, the process that communicating nodes use for establishing communication session keys must be symmetric at each node so that neither node can independently weaken the confidentiality of the exchange without the knowledge of its communicating peer. A deliberate exposure attack will therefore require more overt and independent action on the part of the offending node. Note that the same measures which apply to securing routing/topology exchanges between operational nodes must also extend to field tools and other devices used in a deployed network where such devices can be configured to participate in routing exchanges. 5.1.2. Countering Sniffing Attacks A sniffing attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges between nodes. A sniffing attack in an LLN that is not based on a Tsao, et al. Expires October 1, 2010 [Page 17] Internet-Draft Security Framework for ROLL March 2010 physical device compromise will rely on the attacker attempting to directly derive information from the over-the-air routing/topology communication exchange (neighbor discovery exchanges may of necessity be conducted in the clear thus limiting the extent to which the information can be kept confidential). Sniffing attacks can be directly countered through the use of data encryption for all routing exchanges. Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session confidentiality keys and an agreed confidentiality algorithm. JP> Id security is "turned on". Could you specify that the routing protocol will include security features according to this framework but some scenario may not require their use, should they be provide by other means or not needed in a specific environment. The level of security applied in providing confidentiality will determine the minimum requirement for an attacker mounting this passive security attack. Because of the resource constraints of LLN devices, symmetric (private) key session security will provide the best tradeoff in terms of node and channel resource overhead and the level of security achieved. This will of course not preclude the use of asymmetric (public) key encryption during the session key establishment phase. As with the key establishment process, data encryption must include an authentication prerequisite to ensure that each node is implementing a level of security that prevents deliberate or inadvertent exposure. The authenticated key establishment will ensure that confidentiality is not compromised by providing the information to an unauthorized entity (see also [Huang2003]). Based on the current state of the art, a minimum 128-bit key length should be applied where robust confidentiality is demanded for routing protection. This session key shall be applied in conjunction with an encryption algorithm that has been publicly vetted and where applicable approved for the level of security desired. Algorithms such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted by the 3GPP 3rd generation wireless mobile consortium) JP> Could you please ad references ? are examples of symmetric-key algorithms capable of ensuring robust confidentiality for routing exchanges. The key length, algorithm and mode of operation will be selected as part of the overall security tradeoff that also achieves a balance with the level of confidentiality afforded by the physical device in protecting the routing assets (see Section 5.1.4 below). As with any encryption algorithm, the use of ciphering synchronization parameters and limitations to the usage duration of established keys should be part of the security specification to reduce the potential for brute force analysis. Tsao, et al. Expires October 1, 2010 [Page 18] Internet-Draft Security Framework for ROLL March 2010 5.1.3. Countering Traffic Analysis Traffic analysis provides an indirect means of subverting confidentiality and gaining access to routing information by allowing an attacker to indirectly map the connectivity or flow patterns (including link-load) JP> Aren't you making the assumption that LLNs only comprise radio link layers ? ** Please make sure that throughout the document you are not making any assumption on the link layer (see other comments above along the same lines). of the network from which other attacks can be mounted. The traffic analysis attack on a LLN may be passive and relying on the ability to read the immutable source/destination routing information that must remain unencrypted to permit network routing. Alternatively, attacks can be active through the injection of unauthorized discovery traffic into the network. By implementing authentication measures between communicating nodes, active traffic analysis attacks can be prevented within the LLN thereby reducing confidentiality vulnerabilities to those associated with passive analysis. One way in which passive traffic analysis attacks can be muted is through the support of load balancing that allows traffic to a given destination to be sent along diverse routing paths. Where the routing protocol supports load balancing along multiple links at each node, the number of routing permutations in a wide area network surges thus increasing the cost of traffic analysis. Network analysis through this passive attack will require a wider array of analysis points and additional processing on the part of the attacker. In LLNs, the diverse radio connectivity and dynamic links (including potential frequency hopping) will help to further mitigate traffic analysis attacks when load balancing is implemented. JP> Please indicate that this is trued if the link layer is wireless. The only means of fully countering a traffic analysis attack is through the use of tunneling (encapsulation) where encryption is applied across the entirety of the original packet source/destination addresses. With tunneling there is a further requirement that the encapsulating intermediate nodes apply an additional layer of routing so that traffic arrives at the destination through dynamic routes. For LLNs, memory and processing constraints as well as the limitations of the communication channel will preclude both the additional routing traffic overhead JP> But tunneling may be used and is actually used in several cases (e.g. this is the situation for example with RPL when an additional header used for example for loop detection is added to the HbP header for traffic from outside of the LLN to a node inside the LLN). and the node implementation required for tunneling countermeasures to traffic analysis. 5.1.4. Countering Physical Device Compromise Given the distributed nature of LLNs, confidentiality of routing assets and points of access will rely heavily on the security of the routing devices. One means of precluding attacks on the physical device is to prevent physical access to the node through other external security means. However, given the environment in which LLNs operate, preventing unauthorized access to the physical device cannot be assured. JP> "in some cases" - for example in a Smart Grid environment the substation has secured access. Countermeasures must therefore be employed at the Tsao, et al. Expires October 1, 2010 [Page 19] Internet-Draft Security Framework for ROLL March 2010 device and component level so that routing/topology or neighbor information and stored route information cannot be accessed even if physical access to the node is obtained. With the physical device in the possession of an attacker, unauthorized information access can be attempted by probing internal interfaces or device components. Device security must therefore move to preventing the reading of device processor code or memory locations without the appropriate security keys and in preventing the access to any information exchanges occurring between individual components. Information access will then be restricted to external interfaces in which confidentiality, integrity and authentication measures can be applied. JP> True but you may want to mention that this is not 'routing security' specific. To prevent component information access, deployed routing devices must ensure that their implementation avoids address or data buses being connected to external general purpose input/output (GPIO) pins. Beyond this measure, an important component interface to be protected against attack is the Joint Test Action Group (JTAG) interface used for component and populated circuit board testing after manufacture. To provide security on the routing devices, components should be employed that allow fuses on the JTAG interfaces to be blown to disable access. This will raise the bar on unauthorized component information access within a captured device. At the device level a key component information exchange is between the microprocessor and it associated external memory. While encryption can be implemented to secure data bus exchanges, the use of integrated physical packaging which avoids inter-component exchanges (other than secure external device exchanges) will increase routing security against a physical device interface attack. With an integrated package and disabled internal component interfaces, the level of physical device security can be controlled by managing the degree to which the device packaging is protected against expert physical decomposition and analysis. The device package should be hardened such that attempts to remove the integrated components will result in damage to access interfaces, ports or pins that prevent retrieval of code or stored information. The degree of VLSI or PCB JP> Could you please expand acronyms when first used ? package security through manufacture can be selected as a tradeoff or desired security consistent with the level of security achieved by measures applied for other routing assets and points of access. With package hardening and restricted component access countermeasures, the security level will be raised to that provided by measures employed at the external communications interfaces. Another area of node interface vulnerability is that associated with Tsao, et al. Expires October 1, 2010 [Page 20] Internet-Draft Security Framework for ROLL March 2010 interfaces provided for remote software or firmware upgrades. This may impact both routing information and routing/topology exchange security where it leads to unauthorized upgrade or change to the routing protocol running on a given node as this type of attack can allow for the execution of compromised or intentionally malicious routing code on multiple nodes. Countermeasures to this device interface confidentiality attack needs to be addressed in the larger context of node remote access security. This will ensure not only the authenticity of the provided code (including routing protocol) but that the process is initiated by an authorized (authenticated) entity. The above identified countermeasures against attacks on routing information confidentiality through internal device interface compromise must be part of the larger LLN system security as they cannot be addressed within the routing protocol itself. Similarly, the use of field tools or other devices that allow explicit access to node information must implement security mechanisms to ensure that routing information can be protected against unauthorized access. These protections will also be external to the routing protocol and hence not part of ROLL. 5.1.5. Countering Remote Device Access Attacks Where LLN nodes are deployed in the field, measures are introduced to allow for remote retrieval of routing data and for software or field upgrades. These paths create the potential for a device to be remotely accessed across the network or through a provided field tool. In the case of network management a node can be directly requested to provide routing tables and neighbor information. To ensure confidentiality of the node routing information against attacks through remote access, any device local or remote requesting routing information must be authenticated to ensure authorized access. Since remote access is not invoked as part of a routing protocol security of routing information stored on the node against remote access will not be addressable as part of the routing protocol. 5.2. Integrity Attack Countermeasures Integrity attack countermeasures address routing information manipulation, as well as node identity and routing information misuse. Manipulation can occur in the form of falsification attack and physical compromise. To be effective, the following development considers the two aspects of falsification, namely, the tampering actions and the overclaiming and misclaiming content. The countering of physical compromise was considered in the previous section and is Tsao, et al. Expires October 1, 2010 [Page 21] Internet-Draft Security Framework for ROLL March 2010 not repeated here. With regard to misuse, there are two types of attacks to be deterred, identity attacks and replay attacks. 5.2.1. Countering Tampering Attacks Tampering may occur in the form of altering the message being transferred or the data stored. Therefore, it is necessary to ensure that only authorized nodes can change the portion of the information that is allowed to be mutable, while the integrity of the rest of the information is protected, e.g., through well-studied cryptographic mechanisms. Tampering may also occur in the form of insertion or deletion of messages during protocol changes. Therefore, the protocol needs to ensure the integrity of the sequence of the exchange sequence. The countermeasure to tampering needs to o implement access control on storage; o provide data integrity service to transferred messages and stored data; o include sequence number under integrity protection. 5.2.2. Countering Overclaiming and Misclaiming Attacks Both overclaiming and misclaiming aim to introduce false routes or topology that would not be generated by the network otherwise, while there is not necessarily tampering. The requisite for a counter is the capability to determine unreasonable routes or topology. The counter to overclaiming and misclaiming may employ o comparison with historical routing/topology data; o designs which restrict realizable network topologies. 5.2.3. Countering Identity (including Sybil) Attacks Identity attacks, sometimes simply called spoofing, seek to gain or damage assets whose access is controlled through identity. In routing, an identity attacker can illegitimately participate in routing exchanges, distribute false routing information, or cause an invalid outcome of a routing process. A perpetrator of Sybil attacks assumes multiple identities. The result is not only an amplification of the damage to routing, but Tsao, et al. Expires October 1, 2010 [Page 22] Internet-Draft Security Framework for ROLL March 2010 extension to new areas, e.g., where geographic distribution is explicit or implicit an asset to an application running on the LLN. JP> You could mentioned that this is a particular concern in LLN where the traffic flow is mostly P2MP and MP2P. The counter of identity attacks need to ensure the authenticity and liveliness of the parties of a message exchange; the measure may use shared key or public key based authentication scheme. On the one hand, the large-scale nature of the LLNs makes the network-wide shared key scheme undesirable from a security perspective; on the other hand, public-key based approaches generally require more computational resources. JP> Could elaborate a little bit more on the CPU impact when using public-key? Each system will need to make trade-off decisions based on its security requirements. 5.2.4. Countering Routing Information Replay Attacks In routing, message replay can result in false topology and/or routes. The counter of replay attacks need to ensure the freshness of the message. On the one hand, there are a number of mechanisms commonly used for countering replay. JP> Want to add some references? On the other hand, the choice should take into account how a particular mechanism is made available in a LLN. For example, many LLNs have a central source of time and have it distributed by relaying, such that secured time distribution becomes a prerequisite of using timestamping to counter replay. JP> Which means to support clocks, ... 5.2.5. Countering Byzantine Routing Information Attacks Where a node is captured or compromized but continues to operate for a period with valid network security credentials, the potential exists for routing information to be manipulated. This compromise of the routing information could thus exist in spite of security countermeasures that operate between the peer routing devices. Consistent with the end-to-end principle of communications, such an attack can only be fully addressed through measures operating directly between the routing entities themselves or by means of external entities able to access and independently analyze the routing information. Verification of the authenticity and liveliness of the routing principals can therefore only provide a limited counter against internal (Byzantine) node attacks. JP> Agree but this is not particularly tied to the end-to-end principle. For link state routing protocols where information is flooded JP> add "with area (OSPF) or levels (ISIS) countermeasures can be directly applied by the routing entities through the processing and comparison of link state information received from different peers. By comparing the link information from multiple sources decisions can be made by a routing node or external entity with regard to routing information validity. For distance vector protocols where information is aggregated at each routing node it is not possible for nodes to directly detect Tsao, et al. Expires October 1, 2010 [Page 23] Internet-Draft Security Framework for ROLL March 2010 Byzantine information manipulation attacks from the routing information exchange. In such cases, the routing protocol must include and support indirect communications exchanges between non- adjacent routing peers to provide a secondary channel for performing routing information validation. S-RIP [Wan2004] is an example of the implementation of this type of dedicated routing protocol security where the correctness of aggregate distance vector information can only be validated by initiating confirmation exchanges directly between nodes that are not routing neighbors. Alternatively, an entity external to the routing protocol would be required to collect and audit routing information exchanges to detect the Byzantine attack. In the context of the current security framework, any protection against Byzantine routing information attacks will need to be directly included within the mechanisms of the ROLL routing protocol. This can be implemented where such an attack is considered relevant even within the physical device protections discussed in Section 5.1.4 5.3. Availability Attack Countermeasures As alluded to before, availability requires that routing information exchanges and forwarding mechanisms be available when needed so as to guarantee a proper functioning of the network. This may, e.g., include the correct operation of routing information and neighbor state information exchanges, among others. We will highlight the key features of the security threats along with typical countermeasures to prevent or at least mitigate them. We will also note that an availability attack may be facilitated by an identity attack as well as a replay attack, as was addressed in Section 5.2.3 and Section 5.2.4, respectively. 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing attacks are different but highly related forms of attacking a LLN. They essentially lead nodes to believe that suitable routes are available even though they are not and hence constitute a serious availability attack. The origin of facilitating a HELLO flood attack lies in the fact that many wireless routing protocols JP> Please do not use the terms "wireless routing protocols" since by definition of a layered architecture, the routing protocol is not tied to a particular link layer. Furthermore this also applies to routing protocols used in non wireless environments. require nodes to send HELLO packets either upon joining or in regular intervals so as to announce or confirm their existence to the network. Those nodes that receive the HELLO packet assume JP> If they receive the packet they *are* in the radio range (again the link may not be wireless). that they are within radio range of the transmitter by means of a bidirectional communication link. With this in mind, a malicious node can send or replay HELLO packets Tsao, et al. Expires October 1, 2010 [Page 24] Internet-Draft Security Framework for ROLL March 2010 using a higher transmission power. That creates the false illusion of being a neighbor to an increased number of nodes in the network, thereby effectively increasing its unidirectional neighborhood cardinality. The high quality of the falsely advertised link may coerce nodes to route data via the malicious node. However, those affected nodes, for which the malicious node is out of radio range, never succeed in their delivery and the packets are effectively dropped. JP> Mention "if the link layer is wireless". Not that in PLC, this can happen too. The symptoms are hence similar to those of a sinkhole, wormhole and selective forwarding attack. A malicious HELLO flood attack clearly distorts the network topology. It thus affects protocols building and maintaining the network topology as well as routing protocols as such, since the attack is primarily targeted on protocols that require sharing of information for topology maintenance or flow control. To counter HELLO flood attacks, several mutually non-exclusive methods are feasible: o restricting neighborhood cardinality; o facilitating multipath routing; o verifying bidirectionality. Restricting the neighborhood cardinality prevents malicious nodes from having an extended set of neighbors beyond some tolerated threshold and thereby preventing topologies to be built where malicious nodes have an extended neighborhood set. JP> But thai may artificially reduce the number of "valid" neighbors too. Furthermore, as shown in [I-D.suhopark-hello-wsn], if the routing protocol supports multiple paths from a sensing node towards several gateways then HELLO flood attacks can also be diminished; however, the energy- efficiency of such approach is clearly sub-optimal. Finally, verifying that the link is truly bidirectional by means of, e.g., an ACK handshake and appropriate security measures ensures that a communication link is only established if not only the affected node is within range of the malicious node but also vice versa. Whilst this does not really eliminate the problem of HELLO flooding, it greatly reduces the number of affected nodes and the probability of such an attack succeeding. JP> Even if there is bi-directinality, the attacked node may thus send traffic to the attackers that claims to have "good" routes though. As for the latter, the adversary may spoof the ACK messages to convince the affected node that the link is truly bidirectional and thereupon drop, tunnel or selectively forward messages. Such ACK spoofing attack is possible if the malicious node has a receiver which is significantly more sensitive than that of a normal node, thereby effectively extending its range. Since an ACK spoofing attack facilitates a HELLO flood attack, similar countermeasure are Tsao, et al. Expires October 1, 2010 [Page 25] Internet-Draft Security Framework for ROLL March 2010 applicable here. Viable counter and security measures for both attacks have been exposed in [I-D.suhopark-hello-wsn]. 5.3.2. Countering Overload Attacks Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy budget quicker. JP> Energy indeed (a real issue if node are battery operated or using energy scavengers) but also inject loads and creates congestions. It thus significantly shortens the network lifetime JP> If the LLNs is made of battery-operated nodes. and hence constitutes another serious availability attack. With energy being one of the most precious assets of LLNs, targeting its availability is a fairly obvious attack. Another way of depleting the energy of a LLN node is to have the malicious node overload the network with irrelevant traffic. This impacts availability since certain routes get congested which o renders them useless for affected nodes and data can hence not be delivered; o makes routes longer as shortest path algorithms work with the congested network; JP> Not sure what you meant above o depletes nodes quicker and thus shortens the network's availability at large. JP> Again if nodes are battery operated. Overload attacks can be countered by deploying a series of mutually non-exclusive security measures: o introduce quotas on the traffic rate each node is allowed to send; JP> Also referred to as "traffic shaping" but only possible in some networks. o isolate nodes which send traffic above a certain threshold; JP> If "Valid" nodes that may attract lots of traffic do no exist in the network. o allow only trusted data to be received and forwarded. As for the first one, a simple approach to minimize the harmful impact of an overload attack is to introduce traffic quotas. This prevents a malicious node from injecting a large amount of traffic into the network, even though it does not prevent said node from injecting irrelevant traffic at all. Another method is to isolate JP> If you have a wireless link, how do you "isolate" the node ? It can still sends traffic (at least with some MACs). nodes from the network once it has been detected that more traffic is injected into the network than allowed by a prior set or dynamically adjusted threshold. Finally, if communication is sufficiently secured, only trusted nodes can receive and forward traffic which also lowers the risk of an overload attack. Tsao, et al. Expires October 1, 2010 [Page 26] Internet-Draft Security Framework for ROLL March 2010 5.3.3. Countering Selective Forwarding Attacks Selective forwarding attacks are another form of DoS attack which impacts the routing path availability. An insider malicious node basically blends neatly in with the network but then may decide to forward and/or manipulate certain packets. If all packets are dropped, then this attacker is also often referred to as a "black hole". Such a form of attack is particularly dangerous if coupled with sinkhole attacks since inherently a large amount of traffic is attracted to the malicious node and thereby causing significant damage. An outside malicious node would selectively jam overheard data flows, where the thus caused collisions JP> Again is the MAC is a shared media. incur selective forwarding. Selective Forwarding attacks can be countered by deploying a series of mutually non-exclusive security measures: o multipath routing of the same message over disjoint paths; o dynamically select the next hop from a set of candidates. The first measure basically guarantees that if a message gets lost on a particular routing path due to a malicious selective forwarding attack, there will be another route which successfully delivers the data. Such method is inherently suboptimal from an energy consumption point of view. The second method basically involves a constantly changing routing topology in that next-hop routers are chosen from a dynamic set in the hope that the number of malicious nodes in this set is negligible. JP> If the routing protocol allows for disjoint routing paths, this is even more attractive. 5.3.4. Countering Sinkhole Attacks In sinkhole attacks, the malicious node manages to attract a lot of traffic mainly by advertising the availability of high-quality links even though there are none. It hence constitutes a serious attack on availability. The malicious node creates a sinkhole by attracting a large amount of, if not all, traffic from surrounding neighbors by advertising in and outwards links of superior quality. Affected nodes hence eagerly route their traffic via the malicious node which, if coupled with other attacks such as selective forwarding, may lead to serious availability and security breaches. Such an attack can only be executed by an inside malicious node and is generally very difficult to detect. An ongoing attack has a profound impact on the network topology and essentially becomes a problem of flow control. Tsao, et al. Expires October 1, 2010 [Page 27] Internet-Draft Security Framework for ROLL March 2010 Sinkhole attacks can be countered by deploying a series of mutually non-exclusive security measures: o use geographical insights for flow control; o isolate nodes which receive traffic above a certain threshold; o dynamically pick up next hop from set of candidates; o allow only trusted data to be received and forwarded. Whilst most of these countermeasures have been discussed before, the use of geographical information deserves further attention. Essentially, if geographic positions of nodes are available, then the network can assure that data is actually routed towards the sink(s) and not elsewhere. JP> Yes but it may be wise to route all traffic via a node that is not closer to the sink but supports interesting capabilities such as aggregation. On the other hand, geographic position is a sensitive information that may have security and/or privacy consequences. 5.3.5. Countering Wormhole Attacks In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel. This changes the availability of certain routing paths and hence constitutes a serious security breach. Essentially, two malicious insider nodes use another, more powerful, radio JP> Once again, if the link in use is wireless. to communicate with each other and thereby distort the would- be-agreed routing path. This distortion could involve shortcutting and hence paralyzing a large part of the network; it could also involve tunneling the information to another region of the network where there are, e.g., more malicious nodes available to aid the intrusion or where messages are replayed, etc. In conjunction with selective forwarding, wormhole attacks can create race conditions which impact topology maintenance, routing protocols as well as any security suits built on "time of check" and "time of use". Wormhole attacks are very difficult to detect in general but can be mitigated using similar strategies as already outlined above in the context of sinkhole attacks. 6. ROLL Security Features The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing. This section Tsao, et al. Expires October 1, 2010 [Page 28] Internet-Draft Security Framework for ROLL March 2010 puts the results into perspective and provides a framework for addressing the derived set of security objectives that must be met by the ROLL protocol. JP> s/ROLL protocol/Routing protocol specified by the ROLL Working Group. It bears emphasizing that the target here is a generic ROLL protocol and the normative keywords are mainly to convey the relative level of urgency of the features specified. The first part of this section, Section 6.1 to Section 6.3, is a prescription of ROLL security features of measures that can be addressed as part of the routing protocol itself. As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains also needs to be considered. The second part of this section, Section 6.4 and Section 6.5, discusses system security aspects that may impact routing but that also require considerations beyond the routing protocol, as well as potential approaches. 6.1. Confidentiality Features With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure is not directly essential to maintaining the routing function. Breaches of confidentiality may lead to other attacks or the focusing of an attacker's resources (see Section 4.1) but does not of itself directly undermine the operation of the routing function. However, to protect against, and improve vulnerability against other more direct attacks, routing information confidentiality should be protected. Thus, a secured ROLL protocol o SHOULD provide payload encryption; o MAY provide tunneling; o MAY provide load balancing; JP> You can add a note and point to the requirement RFCs, where this is listed as a requirement. o SHOULD provide privacy, e.g., when geographic information is used. Where confidentiality is incorporated into the routing exchanges, encryption algorithms and key lengths need to be specified in accordance of the level of protection dictated by the routing protocol and the associated application domain transport network. In terms of the life time of the keys, the opportunity to periodically change the encryption key increases the offered level of security for any given implementation. However, where strong cryptography is employed, physical, procedural, and logical data access protection considerations may have more significant impact on cryptoperiod selection than algorithm and key size factors. Nevertheless, in Tsao, et al. Expires October 1, 2010 [Page 29] Internet-Draft Security Framework for ROLL March 2010 general, shorter cryptoperiods, during which a single key is applied, will enhance security. Given the mandatory protocol requirement to implement routing node authentication as part of routing integrity (see Section 6.2), key exchanges may be coordinated as part of the integrity verification process. This provides an opportunity to increase the frequency of key exchange and shorten the cryptoperiod as a compliment to the key length and encryption algorithm required for a given application domain. For LLNs, the coordination of confidentiality key management with the implementation of node device authentication can thus reduce the overhead associated with supporting data confidentiality. A new ciphering key may therefore be concurrently generated or updated in conjunction with the mandatory authentication exchange occurring with each routing peer association. 6.2. Integrity Features The integrity of routing information provides the basis for ensuring that the function of the routing protocol is achieved and maintained. To protect integrity, a secured ROLL protocol o MUST verify message integrity; o MUST verify the authenticity and liveliness of both principals of a connection; o MUST verify message sequence. Depending on the nature of the routing protocol, e.g., distance vector or link state, additional measures may be necessary when the validity of the routing information is of concern. Specifically, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange. This is particularly important in the case of distance vector-based routing protocols, where information is updated at intermediate nodes, In such cases, there are no direct means within routing for a receiver to verify the validity of the routing information beyond the current exchange; as such, nodes would need to be able to communicate and request information from non-adjacent peers (see [Wan2004]) to provide information integrity assurances. With link state-based protocols, on the other hand, routing information can be signed at the source thus providing a means for validating information that originates beyond a routing peer. Therefore, where necessary, a secured ROLL protocol JP> You can remove the "o" below since there is no other ones. Tsao, et al. Expires October 1, 2010 [Page 30] Internet-Draft Security Framework for ROLL March 2010 o MAY use security auditing mechanisms that are external to routing to verify the validity of the routing information content exchanged among routing peers. 6.3. Availability Features Availability of routing information is linked to system and network availability which in the case of LLNs require a broader security view beyond the requirements of the routing entities (see Section 6.5). Where availability of the network is compromised, routing information availability will be accordingly affected. However, to specifically assist in protecting routing availability o MAY restrict neighborhood cardinality; o MAY use multiple paths; o MAY use multiple destinations; o MAY choose randomly if multiple paths are available; o MAY set quotas to limit transmit or receive volume; o MAY use geographic insights for flow control. 6.4. Additional Related Features If a LLN employs multicast and/or anycast, it MUST secure these protocols JP> "protocols" ? with the services listed in this sections. Furthermore, the nodes MUST provide adequate physical tamper resistance to ensure the integrity of stored routing information. The functioning of the security services requires keys and credentials. Therefore, even though not directly a ROLL security requirement, a LLN must include a process for key and credential distribution; a LLN is encouraged to have procedures for their revocation and replacement. 6.5. Consideration on Matching Application Domain Needs As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains is considered as part of the security architecture in Section 6.5.1. The development so far takes into account collectively the impacts of Tsao, et al. Expires October 1, 2010 [Page 31] Internet-Draft Security Framework for ROLL March 2010 the issues gathered from [RFC5548], [RFC5673], [I-D.ietf-roll-home-routing-reqs], and [I-D.ietf-roll-building-routing-reqs]. JP> Update the reference (all RFcs now). The following two subsections first consider from an architectural perspective how the security design of a ROLL protocol may be made to adapt to the four application domains, and then examine mechanism and protocol operations issues. 6.5.1. Security Architecture The first challenge for a ROLL protocol security design is to have an architecture that can adequately address a set of very diversified needs. It is mainly a consequence of the fact that there are both common and non-overlapping requirements from the four application domains, while, conceivably, each individual application will present yet its own unique constraints. For a ROLL protocol, the security requirements defined in Section 6.1 to Section 6.4 can be addressed at two levels: 1) through measures implemented directly within the routing protocol itself and initiated and controlled by the routing protocol entities; or 2) through measures invoked on behalf of the routing protocol entities but implemented within the transport network JP> Be accurate when you used "transport network": you mean "link layer" ? over which the protocol exchanges occur. Where security is directly implemented as part of the routing protocol the security requirements configured by the user (system administrator) will operate independent of the underlying transport network JP>s/transport network/link layer . OSPFv2 [RFC2328] is an example of such an approach in which security parameters are exchanged and assessed within the routing protocol messages. In this case, the mechanism may be, e.g., a header containing security material of configurable security primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is employed to secure the network, the included protocol- specific (OSPF or RIP) security elements are in addition to and independent of those at the network layer. In the case of LLNs or other networks where system security mandates protective mechanisms at other lower layers of the transport network, JP> "lower layers of the transport network" is ambiguous. security measures implemented as part of the routing protocol will be redundant to security measures implemented elsewhere as part of the transport network. JP> Please replace "transport network" with appropriate terminology where needed. Thanks. Security mechanisms built into the routing protocol can ensure that all desired countermeasures can be directly addressed by the protocol all the way to the endpoint of the routing exchange. In particular, routing protocol Byzantine attacks by a compromised node that retains valid network security credentials can only be detected at the level of the information exchanged within the routing protocol. Such Tsao, et al. Expires October 1, 2010 [Page 32] Internet-Draft Security Framework for ROLL March 2010 attacks aimed the manipulation of the routing information can only be fully addressed through measures operating directly between the routing entities themselves or external entities able to access and analyze the routing information (see discussion in Section 5.2.5). On the other hand, it is more desirable from a LLN device perspective that the ROLL protocol is integrated into the framework of an overall system architecture where the security facility may be shared by different applications and/or across layers for efficiency, and where security policy and configurations can be consistently specified. See, for example, considerations made in RIPng [RFC2080] or the approach presented in [Messerges2003]. Where the routing protocol is able to rely on security measures configured with the transport network JP> Same comment. What do you mean by "transport network"? , greater system efficiency can be realized by avoiding potentially redundant security. Relying on an open trust model [Messerges2003], the security requirements of the routing protocol can be more flexibly met at different layers of the transport network; measures that must be applied to protect the communications network are concurrently able to provide the needed routing protocol protection. In addition, in the context of the different application domains, it allows the level of security applied for routing to be consistent with that needed for protecting the network itself. For example, where AES-128 JP> Expand terms when first used + add reference is deemed the appropriate standard for network confidentiality of data exchanges at the link layer, that level of security is automatically afforded to routing protocol exchanges. Similarly, where SHA-1 JP> Same comment is stipulated as the standard required for authenticating routing protocol peers, the use of SHA-1 at the network layer between communicating routing devices automatically meets the routing protocol security requirement within the context of open trust across layers within the device. A ROLL protocol MUST be made flexible by a design that offers the configuration facility so that the user (network administrator) can choose the security settings that match the application's needs. Furthermore, in the case of LLNs that flexibility should extend to allowing the routing protocol security requirements to be met by measures applied at different protocol layers, provided the identified requirements are collectively met. Since Byzantine attacks that can affect the validity of the information content exchanged between routing entities can only be directly countered at the routing protocol level, the ROLL protocol may support mechanisms for verifying routing data validity that extends beyond the chain of trust created through device authentication. This protocol-specific security mechanism should be Tsao, et al. Expires October 1, 2010 [Page 33] Internet-Draft Security Framework for ROLL March 2010 made optional within the protocol allowing it to be invoked according to the given routing protocol and application domain and as selected by the system user. All other ROLL security mechanisms needed to meet the above identified routing security requirements should be flexibly implemented within the transport network (at the IP network layer or higher or lower protocol layers(s)) according to the particular application domain and user network configuration. Based on device capabilities and the spectrum of operating environments it would be difficult for a single fixed security design to be applied to address the diversified needs of the four ROLL application domains JP> Please list them again (urban, industrial, home/building) + indicate that this is also true for other application domains. without forcing a very low common denominator set of requirements. On the other hand, providing four individual domain designs that attempt to a priori match each individual domain is also very likely to provide a suitable answer given the degree of network variability even within a given domain. JP> The type of link layers in use within each domain also influences the overall security. Instead, the framework implementation approach recommended for optional, routing protocol- specific measures together with flexible transport network mechanisms can be the most effective. This approach allows countermeasures against internal attacks to be applied in environments where applicable threats exist. At the same time, it allows routing protocol security to be configured through measures implemented within the transport network that is commensurate and consistent with the level and strength applied in the particular application domain networks. 6.5.2. Mechanisms and Operations With an architecture allowing different configurations to meet the application domain needs, the task is then to find suitable mechanisms. For example, one of the main problems of synchronizing security states of sleepy nodes, as listed in the last subsection, lies in difficulties in authentication; these nodes may not have received in time the most recent update of security material. Similarly, the issues of minimal manual configuration, prolonged rollout and delayed addition of nodes, and network topology changes also complicate security management. In such case the ROLL protocol may need to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials. This exemplifies the need for the coordination and interoperation between the requirements of the ROLL routing protocol and that of the system security elements. Similarly, the vulnerability brought forth by some special-function nodes, e.g., gateways/sinks requires the assurance, particularly, of the availability of communication channels and node resources, or that the neighbor discovery process operates without undermining routing availability. Tsao, et al. Expires October 1, 2010 [Page 34] Internet-Draft Security Framework for ROLL March 2010 There and other factors which are not part of a ROLL routing protocol can still affect its operation. This includes elements such as weaker barrier to accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. Figure 2 provides an overview of the larger context of system security and the relationship between ROLL requirements and measures and those that relate to the LLN system. Tsao, et al. Expires October 1, 2010 [Page 35] Internet-Draft Security Framework for ROLL March 2010 Security Services for ROLL-Addressable Security Requirements | | +---+ +---+ Node_i | | Node_j _____v___ ___v_____ Specify Security / \ / \ Specify Security Requirements | Routing | | Routing | Requirements +---------| Protocol| | Protocol|---------+ | | Entity | | Entity | | | \_________/ \_________/ | | | | | |ROLL-Specified | | ROLL-Specified| ---Interface | | Interface--- | ...................................... | | : | | : | | : +-----+----+ +----+-----+ : | | : |Transport/| |Transport/| : | ____v___ : +>|Network | |Network |<+ : ___v____ / \ : | +-----+----+ +----+-----+ | : / \ | |-:-+ | | +-:-| | |Security| : +-----+----+ +----+-----+ : |Security| +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ | |Entity | : +-----+----+ +----+-----+ : |Entity | | | | |-:-+ | | +-:-| | | | \________/ : | +-----+----+ +----+-----+ | : \________/ | | : +>| Physical | | Physical |<+ : | Application : +-----+----+ +----+-----+ : Application Domain User : | | : Domain User Configuration : |__Comm. Channel_| : Configuration : : ...Transport Network.................. Figure 2: LLN Device Security Model JP> Great figure. Just clarify "transport/network" 7. Application of ROLL Security Framework to RPL JP> Expand acronym when first used (RPL) This section applies the assessments given in Section 6 to RPL JP> Ad reference (draft-ietf-roll-rpl) as an illustration of the application of the LLN security framework. Specializing the approach used in Section 3.1, Figure 3 gives a level-1 data flow diagram representation of RPL to show the routing "assets" and "points of access" that may be vulnerable and need to be protected. Tsao, et al. Expires October 1, 2010 [Page 36] Internet-Draft Security Framework for ROLL March 2010 ............................................ : : |Link-Local : : Multicast : : or Node_i|<----->(DIO/DIS/DAO)<--------------+ : : ^ | : : | ______V______ : : | Candidate : : V Neighbor List : : (RPL Control incl. ------+------ : : Trickle Timer, | : : Loop Avoidance) V : : ^ (Route Generation) : : | | : : | ______V______ : : +------+ Routing Table : : | ------+------ : : | | : : RPL on Node_j | | : ..................|.............|........... | | |Forwarding V | To/From Node_k|<-------->(Read/Write | Flow Label)<-------+ Figure 3: Data Flow Diagram of RPL From Figure 3, it is seen that threats to the proper operation of RPL are realized through attacks on its DIO, DIS, and DAO messages, as well as on the information the protocol places on the IPv6 Flow Labels. JP> Please update since information is now carried in the Hop-by-hop header with the RPL option (draft in 6man). As set forth in Section 6.1 to Section 6.4, the base security requirements concern message integrity, authenticity and liveliness of the principals of a connection, and protection against message replay; message encryption may be desirable. The security objectives for RPL are therefore to ensure that 1. participants of the DIO, DIS, and DAO message exchanges are authentic; 2. the received DIO, DIS, and DAO messages are not modified during transportation; 3. the received DIO, DIS, and DAO messages are not retransmissions of previous messages; 4. the content of the DIO, DIS, and DAO messages may be made legible to only authorized entities. Tsao, et al. Expires October 1, 2010 [Page 37] Internet-Draft Security Framework for ROLL March 2010 In meeting the above objectives, RPL also needs to provide tunable mechanisms both to allow matching the security afforded to the application domain requirements and to enable efficient use of system resources, as discussed in Section 6.5.1 and Section 6.5.2. The functions of the different RPL messages and information placed within the user data plane Flow Labels JP> s/"user data plane"/"user data plane (RPL option TLV carried in the IPv6 Hop-by-hop header) are factors that can be taken into account when deciding the optional security features and levels of strength to be afforded. For example, the DIO messages build routes to roots while the DAO messages support the building of downward routes to leaf nodes. Consequently, there may be application environments in which the directions of the routes have different importance and thus warrant the use of different security features and/or strength. In other words, it may be desirable to have an RPL security design that extends the tunability of the security features and strengths to message types. The use of a per- message security specification will allow flexibility in permitting application-domain security choices as well as overall tunability. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations The framework presented in this document provides security analysis and design guidelines with a scope limited to ROLL. Security services are identified as requirements for securing ROLL. The results are applied to RPL, with consequent recommendations. 10. Acknowledgments The authors would like to acknowledge the review and comments from Rene Struik. 11. References 11.1. Normative References [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsao, et al. Expires October 1, 2010 [Page 38] Internet-Draft Security Framework for ROLL March 2010 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 11.2. Informative References [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. [I-D.ietf-roll-building-routing-reqs] Martocci, J., Riou, N., Mil, P., and W. Vermeylen, "Building Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-building-routing-reqs-09 (work in progress), January 2010. [I-D.ietf-roll-home-routing-reqs] Brandt, A. and J. Buron, "Home Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-home-routing-reqs-11 (work in progress), January 2010. JP> Update the two references above. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-07 (work in progress), March 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-03 (work in progress), March 2010. [I-D.suhopark-hello-wsn] Park, S., "Routing Security in Sensor Network: HELLO Flood Attack and Defense", draft-suhopark-hello-wsn-00 (work in progress), December 2005. [Karlof2003] Karlof, C. and D. Wagner, "Secure routing in wireless sensor networks: attacks and countermeasures", Elsevier Tsao, et al. Expires October 1, 2010 [Page 39] Internet-Draft Security Framework for ROLL March 2010 AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, 1(2):293-315, September 2003. [Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, R., and E. Callaway, "Low-Power Security for Wireless Sensor Networks", in Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, Fairfax, VA, USA, pp. 1-11, Oct. 31 2003. [Myagmar2005] Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as a Basis for Security Requirements", in Proceedings of the Symposium on Requirements Engineering for Information Security (SREIS'05), Paris, France, pp. 94-102, Aug 29, 2005. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A Secure Distance Vector Routing Protocol", in Proceedings of the 2nd International Conference on Applied Cryptography and Network Security, Yellow Mountain, China, pp. 103-119, Jun. 8-11 2004. Authors' Addresses Tzeta Tsao (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: tzeta.tsao@ekasystems.com Tsao, et al. Expires October 1, 2010 [Page 40] Internet-Draft Security Framework for ROLL March 2010 Roger K. Alexander (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, Maryland 20874 USA Email: roger.alexander@ekasystems.com Mischa Dohler (editor) CTTC Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N Castelldefels, Barcelona 08860 Spain Email: mischa.dohler@cttc.es Vanesa Daza (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 308 Barcelona 08003 Spain Email: vanesa.daza@upf.edu Angel Lozano (editor) Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 309 Barcelona 08003 Spain Email: angel.lozano@upf.edu JP> Are you all editors ? if so, remove the term "Editors" Tsao, et al. Expires October 1, 2010 [Page 41] -- Comment: Dear authors, Thanks (ticket#77). Thanks for having addressed my comments. Ticket can be closed. JP. -- --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: tzeta.tsao@… Type: defect | Status: closed Priority: major | Milestone: Component: security-framework | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: roll From phoebus@ieee.org Tue Oct 12 05:33: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 858B13A695A for ; Tue, 12 Oct 2010 05:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRro9NkFgQYi for ; Tue, 12 Oct 2010 05:33:04 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 3F4123A67D3 for ; Tue, 12 Oct 2010 05:33:04 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3EDD3157A9C; Tue, 12 Oct 2010 14:33:47 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id WFdXwgTo8xRc; Tue, 12 Oct 2010 14:33:45 +0200 (CEST) X-KTH-Auth: phoebus [130.237.50.58] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-58.s3.kth.se (dhcp-50-58.s3.kth.se [130.237.50.58]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 392471579A1; Tue, 12 Oct 2010 14:33:45 +0200 (CEST) Message-ID: <4CB455A7.2070904@ieee.org> Date: Tue, 12 Oct 2010 14:33:43 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Nicolas DEJEAN References: <4C9B3037.4090209@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio Object X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:33:07 -0000 Response below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 10/12/10 9:18 AM, Nicolas DEJEAN wrote: > Hello Phoebus, > > 2010/9/23 Phoebus Chen: >> I'm a little confused about the Node Fanout Ratio (NFR) Object in Section >> 3.4 . Does fanout refer to outgoing links (upward, to a parents), or >> incoming links (downward, from children) of a node? >> > > The idea is that this metric refers to the incoming links. > >> The text says: >> "The Node Fanout Ratio (NFR) object is used to provide information on >> the nodes current forwarding load." >> >> From this, I would read fanout to mean the number of incoming links, if you >> are concerned with upward routing. The amount of traffic you have to >> forward depends on the amount of traffic coming in, which might be roughly >> related to the number of children. > > You are right. > >> But as far as I know, RPL nodes only >> keep track of parents, not of children, so it cannot keep track of the >> number of incoming links. >> > > Unfortunately, you are right again. Good point. > >> Or is the NFR object is used for optimizing the topology for downward >> routing (related to DAO fanout), to get path diversity / reliability? If >> this is the case, perhaps this should be explained in the metrics document. >> > > This is absolutely not the idea. > As a conclusion, maybe we could find some specific cases (based on > storing/non storing mode and DAO usage for instance) that could allow > using this metric but in all cases, this is much more complicated than > expected at start. > > My proposal is to remove this metric from the draft. It might be > reintroduced later in a separate ID. That's fine by me. > > Nicolas. > >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> >> >> On 9/16/10 3:56 PM, David Culler wrote: >>> >>> The routing metrics draft has now gone through 9 revisions over the >>> past 16 months, the diffs have narrowed to essentially wording and >>> editorial changes, and the comments are few and non-controversial. >>> Thus, it appears that consensus has emerged and we can LC this I-D. >>> >>> This email is to announce Working Group Last Call on >>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, >>> Sept. 30 2010. Please read it thoroughly and forward all final >>> comments to the authors and the WG mailing list. >>> >>> Thanks all for your good work. We're on a ROLL. >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> From trac@tools.ietf.org Tue Oct 12 10:33:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07443A6867 for ; Tue, 12 Oct 2010 10:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 Nzd9wtviQSgm for ; Tue, 12 Oct 2010 10:33:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5453E3A6782 for ; Tue, 12 Oct 2010 10:33:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5ikW-0005tl-7G; Tue, 12 Oct 2010 10:34:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: nicolas.dejean@coronis.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 12 Oct 2010 17:34:52 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/82#comment:1 Message-ID: <064.47a1c65bfd03050e389a66767a8a9b5b@tools.ietf.org> References: <055.57531fd1929d809bf0bfe0a04583c0d6@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <055.57531fd1929d809bf0bfe0a04583c0d6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: nicolas.dejean@coronis.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #82 (new): Comment received during WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio 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: Tue, 12 Oct 2010 17:33:40 -0000 #82: Comment received during WG Last Call on draft-ietf-roll-routing- metrics-09.txt --- Clarification on Node Fanout Ratio Object Comment(by jpv@…): Email from Nicolas Dejean - October 12 Response below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 10/12/10 9:18 AM, Nicolas DEJEAN wrote: Hello Phoebus, 2010/9/23 Phoebus Chen: I'm a little confused about the Node Fanout Ratio (NFR) Object in Section 3.4 . Does fanout refer to outgoing links (upward, to a parents), or incoming links (downward, from children) of a node? The idea is that this metric refers to the incoming links. The text says: "The Node Fanout Ratio (NFR) object is used to provide information on the nodes current forwarding load." From this, I would read fanout to mean the number of incoming links, if you are concerned with upward routing. The amount of traffic you have to forward depends on the amount of traffic coming in, which might be roughly related to the number of children. You are right. But as far as I know, RPL nodes only keep track of parents, not of children, so it cannot keep track of the number of incoming links. Unfortunately, you are right again. Good point. Or is the NFR object is used for optimizing the topology for downward routing (related to DAO fanout), to get path diversity / reliability? If this is the case, perhaps this should be explained in the metrics document. This is absolutely not the idea. As a conclusion, maybe we could find some specific cases (based on storing/non storing mode and DAO usage for instance) that could allow using this metric but in all cases, this is much more complicated than expected at start. My proposal is to remove this metric from the draft. It might be reintroduced later in a separate ID. That's fine by me. Nicolas. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: nicolas.dejean@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Ticket URL: roll From trac@tools.ietf.org Wed Oct 13 01:33: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 C03663A692B for ; Wed, 13 Oct 2010 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 WX9VkebXFGQL for ; Wed, 13 Oct 2010 01:33:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 97DDE3A6807 for ; Wed, 13 Oct 2010 01:33:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5wnj-0005JO-5e; Wed, 13 Oct 2010 01:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: nicolas.dejean@coronis.com, jpv@cisco.com X-Trac-Project: roll Date: Wed, 13 Oct 2010 08:35:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/82#comment:2 Message-ID: <064.d9384f4a3badf4be6a9809e36db1dff8@tools.ietf.org> References: <055.57531fd1929d809bf0bfe0a04583c0d6@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <055.57531fd1929d809bf0bfe0a04583c0d6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: nicolas.dejean@coronis.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #82 (closed): Comment received during WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Clarification on Node Fanout Ratio 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: Wed, 13 Oct 2010 08:33:56 -0000 #82: Comment received during WG Last Call on draft-ietf-roll-routing- metrics-09.txt --- Clarification on Node Fanout Ratio Object Changes (by jpv@…): * status: new => closed * resolution: => fixed -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: nicolas.dejean@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: roll From Gerald.Paprocki@us.elster.com Wed Oct 13 12:06: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 266A73A6A2C for ; Wed, 13 Oct 2010 12:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=1.037, 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 zmTdHqCcbEvS for ; Wed, 13 Oct 2010 12:06:46 -0700 (PDT) Received: from mail199.messagelabs.com (mail199.messagelabs.com [216.82.254.179]) by core3.amsl.com (Postfix) with SMTP id 2F56A3A691F for ; Wed, 13 Oct 2010 12:06:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-11.tower-199.messagelabs.com!1286996879!66535777!8 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 26613 invoked from network); 13 Oct 2010 19:08:03 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-11.tower-199.messagelabs.com with SMTP; 13 Oct 2010 19:08:03 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: roll@ietf.org Message-ID: Date: Wed, 13 Oct 2010 15:07:59 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 10/13/2010 03:02:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Gerald Paprocki is out of the office (returning 10/18/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: Wed, 13 Oct 2010 19:06:47 -0000 I am out of the office until 10/18/2010. I will be out of the office starting Wednesday 10/13 and returning to the office Monday 10/18. While I am away I will not have access to my email or phone messages. If you need immediate assistance please contact: Dana Merrill at 919-250-5484 or by e-mail at Dana.Merrill@us.elster.com. Note: This is an automated response to your message "Roll Digest, Vol 33, Issue 21" sent on 10/13/2010 3:00:27 PM. This is the only notification you will receive while this person is away. From dominique.barthel@orange-ftgroup.com Wed Oct 13 22:58: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 926633A68D1 for ; Wed, 13 Oct 2010 22:58:53 -0700 (PDT) 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=[AWL=0.000, 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 5JwQy9psXRJG for ; Wed, 13 Oct 2010 22:58:45 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 545293A68A9 for ; Wed, 13 Oct 2010 22:58:38 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AFEA26C000D; Thu, 14 Oct 2010 08:00:15 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A25B26C0003; Thu, 14 Oct 2010 08:00:15 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 07:59:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 07:59:04 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF01B30F1A@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments Thread-Index: ActknZ4+6Md1LHPJSsOvu6RiDbCUkgGUCWawAB2zq2A= From: To: , X-OriginalArrivalTime: 14 Oct 2010 05:59:54.0000 (UTC) FILETIME=[05996900:01CB6B65] Subject: Re: [Roll] [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 05:58:57 -0000 Hello Phoebus,=20 Thanks for your thorough review. Please find inlined the account of my = processing of each of your comments. Best regards, Dominique -----Message d'origine----- De : roll issue tracker [mailto:trac@tools.ietf.org] Envoy=E9 : mardi 5 = octobre 2010 16:57 =C0 : BARTHEL Dominique RD-TECH-GRE; jpv@cisco.com Cc = : roll@ietf.org Objet : [roll] routing-metrics #83 (new): Comment = received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- = Editorial Comments #83: Comment received WG Last Call on = draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments -----------------------------+------------------------------------------ -----------------------------+---- Reporter: jpv@... | Owner: dominique.barthel@... = =20 Type: defect | Status: new = =20 Priority: major | Milestone: = =20 Component: routing-metrics | Version: = =20 Severity: In WG Last Call | Keywords: = =20 -----------------------------+------------------------------------------ -----------------------------+---- Original Email below (refer to the archives for the full discussion) Email sent on September 23, by Phoebus Chen: General Editorial Comments for the authors: 1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" into Section 2 "Object formats." It's near the end of the document, = yet it says "In the rest of this document, this use of multiple DAG = Metric Containers will be considered as if they were actually just one = long DAG Metric Container." [DB: done as suggested] 2) I suggest moving Section 7 "Metric consistency" into Section 1 = "Introduction". (Also, maybe the point being made in this section is obvious?) [DB: done as suggested] 3) I suggest moving Section 8 "Metric Usage" into a subsection of = Section 2, or somewhere earlier in the document. It will shed more = light when the precedence field is first discussed. Of course, the = text will need to mention that the metrics mentioned in the examples = will be defined in more detail in Sections 3 and 4. [DB: done as suggested] 4) Section 8 gives an example of how to break ties in metrics. What = happens when there is a tie in the precedence field between two metrics? Is this not allowed? Is it broken in the order of the objects in the = metric container (as it was before in version 8 of the document)? Or is = the behavior in this case "beyond the scope of this document," and must = be resolved by the Objective Function? [DB: specified that this is implementation dependant] 5) Section 9 is still incomplete... is this OK for last call? Only the = NSA and Hop-count objects are described in 9.3 and 9.4 respectively. [DB: Only incomplete flag fields and numerical field should be managed = by IANA. NSA and Hop-count are the only two of that type.] 6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static = Metrics, after classifying the links according to characteristics = (paragraphs 1, 3-5 after the list on pg. 5). I suggest a shorter = description and deferring / moving the bulk of the discussion to Section = 5 "Computation of dynamic metrics and attributes." Or at least, = present this discussion after the discussion on the other = classifications (which turns out to just be one sentence on link and = node metrics not being exclusive), following the order of the list. [DB: reshuffled the text somewhat to align with list. However, kept the = dynamic metrics discussion up-front because of its sensitive nature.] 7) In many of the object formats, several of the descriptions of the = flags/fields do not follow the order of the flags/fields in the object. See Figure 2 and the following description, Figure 3 and the following = description, and Figure 5 and the following description. It would be a = little easier to read if the orders matched. [DB: done as suggested in all cases, but the P flag of DMC which would = be harder to understand if introduced first] 8) In several figures, the last Byte indices above the objects are = partially missing. Not a big deal, but it looks a little sloppy leaving = them off. [DB: done as suggested] 9) There are misspelled words throughout the document... please run it = through a spell checker after making the final edits. [DB: done] Nits below. Search for comments preceded by PC>." [DB: thanks for this thorough work! Examined them one by one, and fixed = most, unless disagreement in interpretation, such as the explanation of = ETX update] -- Ticket URL: roll From phoebus@ieee.org Thu Oct 14 00:39: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 0550C3A681E for ; Thu, 14 Oct 2010 00:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.892 X-Spam-Level: X-Spam-Status: No, score=-105.892 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRS2++XX2An0 for ; Thu, 14 Oct 2010 00:39:43 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 5303D3A68C5 for ; Thu, 14 Oct 2010 00:39:43 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 849F3157A06; Thu, 14 Oct 2010 09:40:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id SkevUisiPHtD; Thu, 14 Oct 2010 09:40:25 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-233.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id F2375157A03; Thu, 14 Oct 2010 09:40:24 +0200 (CEST) Message-ID: <4CB6B3E7.7050100@ieee.org> Date: Thu, 14 Oct 2010 09:40:23 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dominique.barthel@orange-ftgroup.com References: <8E09C72DBC577D489F13A71228C0B7BF01B30F1A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF01B30F1A@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.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, 14 Oct 2010 07:39:45 -0000 Dominique, Thanks for taking my comments into consideration. Please see inline below for responses. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 10/14/10 7:59 AM, dominique.barthel@orange-ftgroup.com wrote: > Hello Phoebus, > > Thanks for your thorough review. Please find inlined the account of my processing of each of your comments. > Best regards, > > Dominique > > -----Message d'origine----- > De : roll issue tracker [mailto:trac@tools.ietf.org] Envoy : mardi 5 octobre 2010 16:57 : BARTHEL Dominique RD-TECH-GRE; jpv@cisco.com Cc : roll@ietf.org Objet : [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments > > #83: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments > -----------------------------+------------------------------------------ > -----------------------------+---- > Reporter: jpv@... | Owner: dominique.barthel@... > Type: defect | Status: new > Priority: major | Milestone: > Component: routing-metrics | Version: > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------------------------ > -----------------------------+---- > Original Email below (refer to the archives for the full discussion) > > Email sent on September 23, by Phoebus Chen: > > > General Editorial Comments for the authors: > > 1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" > into Section 2 "Object formats." It's near the end of the document, yet it says "In the rest of this document, this use of multiple DAG Metric Containers will be considered as if they were actually just one long DAG Metric Container." > [DB: done as suggested] > > 2) I suggest moving Section 7 "Metric consistency" into Section 1 "Introduction". (Also, maybe the point being made in this section is > obvious?) > [DB: done as suggested] > > 3) I suggest moving Section 8 "Metric Usage" into a subsection of Section 2, or somewhere earlier in the document. It will shed more light when the precedence field is first discussed. Of course, the text will need to mention that the metrics mentioned in the examples will be defined in more detail in Sections 3 and 4. > [DB: done as suggested] > > 4) Section 8 gives an example of how to break ties in metrics. What happens when there is a tie in the precedence field between two metrics? > Is this not allowed? Is it broken in the order of the objects in the metric container (as it was before in version 8 of the document)? Or is the behavior in this case "beyond the scope of this document," and must be resolved by the Objective Function? > [DB: specified that this is implementation dependant] OK. > > 5) Section 9 is still incomplete... is this OK for last call? Only the NSA and Hop-count objects are described in 9.3 and 9.4 respectively. > [DB: Only incomplete flag fields and numerical field should be managed by IANA. NSA and Hop-count are the only two of that type.] OK, thanks for the clarification. Just to be sure, the flags in sub-objects do not need to be managed? (NE sub-object in Figure 5 and LC Type 2 sub-object in Figure 19) > > 6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static Metrics, after classifying the links according to characteristics (paragraphs 1, 3-5 after the list on pg. 5). I suggest a shorter description and deferring / moving the bulk of the discussion to Section 5 "Computation of dynamic metrics and attributes." Or at least, present this discussion after the discussion on the other classifications (which turns out to just be one sentence on link and node metrics not being exclusive), following the order of the list. > [DB: reshuffled the text somewhat to align with list. However, kept the dynamic metrics discussion up-front because of its sensitive nature.] OK. > > 7) In many of the object formats, several of the descriptions of the flags/fields do not follow the order of the flags/fields in the object. > See Figure 2 and the following description, Figure 3 and the following description, and Figure 5 and the following description. It would be a little easier to read if the orders matched. > [DB: done as suggested in all cases, but the P flag of DMC which would be harder to understand if introduced first] OK. > > 8) In several figures, the last Byte indices above the objects are partially missing. Not a big deal, but it looks a little sloppy leaving them off. > [DB: done as suggested] > > 9) There are misspelled words throughout the document... please run it through a spell checker after making the final edits. > [DB: done] > > > Nits below. Search for comments preceded by PC>." > [DB: thanks for this thorough work! Examined them one by one, and fixed most, unless disagreement in interpretation, such as the explanation of ETX update] Great! I believe you're referring to the ETX example in section 2 on pg. 9. Looking back, I didn't give a good suggestion on how to change the sentence. > -- > Ticket URL: > roll > From trac@tools.ietf.org Fri Oct 15 07:58: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 D02F23A6AAD for ; Fri, 15 Oct 2010 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 NZRjd3gC0drT for ; Fri, 15 Oct 2010 07:58:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B48493A6C96 for ; Fri, 15 Oct 2010 07:58:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P6ll7-00023M-09; Fri, 15 Oct 2010 07:59:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 15 Oct 2010 14:59:48 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/83#comment:1 Message-ID: <064.d24e9efcfafa511afab005cecff05969@tools.ietf.org> References: <055.6f5b540c66d184e09344ac69a5f52740@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <055.6f5b540c66d184e09344ac69a5f52740@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #83 (closed): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 14:58:33 -0000 #83: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Answer from dominique barthel - Oct 14 Hello Phoebus, Thanks for your thorough review. Please find inlined the account of my processing of each of your comments. Best regards, Dominique -----Message d'origine----- De : roll issue tracker [mailto:trac@tools.ietf.org] Envoyé : mardi 5 octobre 2010 16:57 À : BARTHEL Dominique RD-TECH-GRE; jpv@cisco.com Cc : roll@ietf.org Objet : [roll] routing-metrics #83 (new): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments #83: Comment received WG Last Call on draft-ietf-roll-routing- metrics-09.txt --- Editorial Comments -----------------------------+------------------------------------------ -----------------------------+---- Reporter: jpv@... | Owner: dominique.barthel@... Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------------ -----------------------------+---- Original Email below (refer to the archives for the full discussion) Email sent on September 23, by Phoebus Chen: General Editorial Comments for the authors: 1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" into Section 2 "Object formats." It's near the end of the document, yet it says "In the rest of this document, this use of multiple DAG Metric Containers will be considered as if they were actually just one long DAG Metric Container." [DB: done as suggested] 2) I suggest moving Section 7 "Metric consistency" into Section 1 "Introduction". (Also, maybe the point being made in this section is obvious?) [DB: done as suggested] 3) I suggest moving Section 8 "Metric Usage" into a subsection of Section 2, or somewhere earlier in the document. It will shed more light when the precedence field is first discussed. Of course, the text will need to mention that the metrics mentioned in the examples will be defined in more detail in Sections 3 and 4. [DB: done as suggested] 4) Section 8 gives an example of how to break ties in metrics. What happens when there is a tie in the precedence field between two metrics? Is this not allowed? Is it broken in the order of the objects in the metric container (as it was before in version 8 of the document)? Or is the behavior in this case "beyond the scope of this document," and must be resolved by the Objective Function? [DB: specified that this is implementation dependant] 5) Section 9 is still incomplete... is this OK for last call? Only the NSA and Hop-count objects are described in 9.3 and 9.4 respectively. [DB: Only incomplete flag fields and numerical field should be managed by IANA. NSA and Hop-count are the only two of that type.] 6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static Metrics, after classifying the links according to characteristics (paragraphs 1, 3-5 after the list on pg. 5). I suggest a shorter description and deferring / moving the bulk of the discussion to Section 5 "Computation of dynamic metrics and attributes." Or at least, present this discussion after the discussion on the other classifications (which turns out to just be one sentence on link and node metrics not being exclusive), following the order of the list. [DB: reshuffled the text somewhat to align with list. However, kept the dynamic metrics discussion up-front because of its sensitive nature.] 7) In many of the object formats, several of the descriptions of the flags/fields do not follow the order of the flags/fields in the object. See Figure 2 and the following description, Figure 3 and the following description, and Figure 5 and the following description. It would be a little easier to read if the orders matched. [DB: done as suggested in all cases, but the P flag of DMC which would be harder to understand if introduced first] 8) In several figures, the last Byte indices above the objects are partially missing. Not a big deal, but it looks a little sloppy leaving them off. [DB: done as suggested] 9) There are misspelled words throughout the document... please run it through a spell checker after making the final edits. [DB: done] Nits below. Search for comments preceded by PC>." [DB: thanks for this thorough work! Examined them one by one, and fixed most, unless disagreement in interpretation, such as the explanation of ETX update] -- Ticket URL: roll -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: dominique.barthel@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: roll From Matthew.Anderson@us.elster.com Fri Oct 15 08:08: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 70FA33A6CAB for ; Fri, 15 Oct 2010 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 195u8N96I1cz for ; Fri, 15 Oct 2010 08:08:16 -0700 (PDT) Received: from mail198.messagelabs.com (mail198.messagelabs.com [216.82.254.163]) by core3.amsl.com (Postfix) with SMTP id 725D33A6A4C for ; Fri, 15 Oct 2010 08:08:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-9.tower-198.messagelabs.com!1287155374!36949686!4 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 19063 invoked from network); 15 Oct 2010 15:09:37 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-9.tower-198.messagelabs.com with SMTP; 15 Oct 2010 15:09:37 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: roll@ietf.org Message-ID: Date: Fri, 15 Oct 2010 11:09:17 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 10/15/2010 11:03:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Matthew Anderson is out of the office (returning 10/25/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: Fri, 15 Oct 2010 15:08:17 -0000 I am out of the office until 10/25/2010. I am out of the office on vacation. Any critical matters related to the EARG project should be sent to Gerald Paprocki. I will occasionally check my email, but make no promises of a prompt reply. Also - please make sure you have the correct Matt Anderson on your email if you are surprised by this out of office. Note: This is an automated response to your message "Re: [Roll] [roll] routing-metrics #83 (closed): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Editorial Comments" sent on 10/15/2010 10:59:48 AM. This is the only notification you will receive while this person is away. From cabo@tzi.org Fri Oct 15 22:32: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 642D33A6A98; Fri, 15 Oct 2010 22:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.167 X-Spam-Level: X-Spam-Status: No, score=-106.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-85fBSlHTkU; Fri, 15 Oct 2010 22:32:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 92F233A69EE; Fri, 15 Oct 2010 22:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9G5XZcp022925; Sat, 16 Oct 2010 07:33:35 +0200 (CEST) Received: from [192.168.217.101] (p5489FB26.dip.t-dialin.net [84.137.251.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F28E5948; Sat, 16 Oct 2010 07:33:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sat, 16 Oct 2010 07:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG X-Mailer: Apple Mail (2.1081) Subject: [Roll] (Update:) Constrained node/network cluster at IETF 79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Oct 2010 05:32:46 -0000 The "final" agenda for IETF79 has been posted. Note that ROLL has moved to Thursday. As usual, even "final" IETF agenda may still change, so please do not = make the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained node/network = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Emerald APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Garden Ballroom 1 IRTF HIPRG Host Identity Protocol=20= 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Emerald APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF * THURSDAY, November 11, 2010 1300-1500 Afternoon Session I Valley Ballroom A RTG roll Routing Over Low power = and Lossy networks WG From jpv@cisco.com Sun Oct 17 22:43: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 83B383A6A8E for ; Sun, 17 Oct 2010 22:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.204 X-Spam-Level: X-Spam-Status: No, score=-110.204 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1NDjBjrblNj for ; Sun, 17 Oct 2010 22:43:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 724E63A6A87 for ; Sun, 17 Oct 2010 22:43:37 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAPZ7u0yQ/khMgWdsb2JhbACBRZkohjsVAQEWIiKfKptihUkEikqDCw X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208,217";a="66873173" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2010 05:45:04 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9I5j4hB013984 for ; Mon, 18 Oct 2010 05:45:04 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 07:45:04 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 07:45:04 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-3--164141991 Date: Mon, 18 Oct 2010 07:45:03 +0200 References: To: ROLL WG Message-Id: <3C9104BF-6409-4750-BB17-BE2DD363C31F@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Oct 2010 05:45:04.0097 (UTC) FILETIME=[9CD3FD10:01CB6E87] Subject: [Roll] ** Resending ** Fwd: IETF-79 - Important dates and Slot request ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 05:43:41 -0000 --Apple-Mail-3--164141991 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Please let us know as soon as possible if you would like a slot at the = IETF-79 ROLL WG meeting. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: October 7, 2010 8:25:23 AM GMT+02:00 > To: ROLL WG > Subject: [Roll] IETF-79 - Important dates and Slot request ? >=20 > Dear all, >=20 > As a reminder please find below the important dates for the next IETF. >=20 > If you would like to request a slot during the WG meeting, please let = us know. >=20 > IETF 79: November 7-12, 2010, Beijing, China > =20 > 2010-08-9 (Week of): IETF Online Registration opens. > 2010-08-9 (Monday): Working Group and BOF scheduling begins. To = request a Working Group session, use theIETF Meeting Session Request = Tool. > 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (24:00 UTC). To request a BOF, please see = instructions on Requesting a BOF. > 2010-09-27 (Monday): Cutoff date for requests to schedule Working = Group meetings at 17:00 PT (24:00 UTC). To request a Working Group = session, use the IETF Meeting Session Request Tool. > 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (24:00 UTC). > 2010-10-06 (Wednesday): Preliminary agenda published for comment. > 2010-10-11 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (24:00 UTC). > 2010-10-11 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (24:00 UTC). > 2010-10-15 (Friday): Final agenda to be published. > 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission = Tool. > 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 = PT (24:00 UTC), upload using IETF ID Submission Tool. > 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT = (24:00 UTC), upload using IETF Meeting Materials Management Tool. > 2010-10-29 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (24:00 UTC). > 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT = (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials = Management Tool. > 2010-11-01 (Monday): Registration cancellation cut-off at 17:00 PT = (01:00 Tuesday, November 02 UTC). > 2010-11-05 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local Beijing time. (02:00 PT, 09:00 UTC). > 2010-11-07 - 2010-11-12: 79th IETF Meeting in Beijing, China. > 2010-12-10 (Friday): Proceedings submission cutoff date by 17:00 PT = (01:00 Saturday, December 11 UTC), upload using IETF Meeting Materials = Management Tool. > 2011-01-05 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (01:00 Thursday, January 6 UTC), upload using IETF Meeting = Materials Management Tool. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-3--164141991 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

Please let us know as soon as possible if you = would like a slot at the IETF-79 ROLL WG = meeting.

Thanks.

JP.
=

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Date: October 7, 2010 = 8:25:23 AM GMT+02:00
To: ROLL WG <roll@ietf.org>
Subject: [Roll] IETF-79 - = Important dates and Slot request ?

Dear all,

As = a reminder please find below the important dates for the next = IETF.

If you would like to request a slot = during the WG meeting, please let us = know.

 

  • 2010-08-9 (Week = of): IETF Online Registration opens.
  • 2010-08-9 = (Monday): Working Group and BOF scheduling begins. To request a = Working Group session, use the= IETF Meeting Session Request Tool.
  • 2010-09-13 (Monday): Cutoff = date for BOF proposal requests to Area Directors at 17:00 PT (24:00 = UTC). To request a BOF, please see instructions on Requesting a = BOF.
  • = IETF Meeting Session Request Tool.
  • 2010-09-27 (Monday): Cutoff = date for Area Directors to approve BOFs at 17:00 PT (24:00 UTC).
  • 2010-10-06 = (Wednesday): Preliminary agenda published for comment.
  • 2010-10-11 = (Monday): Cutoff date for requests to reschedule Working Group = and BOF meetings 17:00 PT (24:00 UTC).
  • 2010-10-11 (Monday): = Working Group Chair approval for initial document (Version -00) = submissions appreciated by 17:00 PT (24:00 UTC).
  • 2010-10-15 (Friday): Final = agenda to be published.
  • 2010-10-18 (Monday): Internet Draft Cut-off for = initial document (-00) submission by 17:00 PT (24:00 UTC), upload = using IETF = ID Submission Tool.
  • 2010-10-25 (Monday): Internet Draft final = submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2010-10-29 (Friday): Early = Bird registration and payment cut-off at 17:00 PT (24:00 UTC).
  • 2010-11-01 = (Monday): Revised Working Group agendas due by 17:00 PT (01:00 = Tuesday, November 02 UTC), upload using IETF = Meeting Materials Management Tool.
  • 2010-11-01 (Monday): = Registration cancellation cut-off at 17:00 PT (01:00 Tuesday, November = 02 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2011-01-05 (Wednesday): Proceedings submission = corrections cutoff date by 17:00 PT (01:00 Thursday, January 6 UTC), = upload using IETF = Meeting Materials Management = Tool.

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

= --Apple-Mail-3--164141991-- From jpv@cisco.com Sun Oct 17 23:55: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 3C3D93A6C86 for ; Sun, 17 Oct 2010 23:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.206 X-Spam-Level: X-Spam-Status: No, score=-110.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEl5MiPk779D for ; Sun, 17 Oct 2010 23:55:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D45103A6814 for ; Sun, 17 Oct 2010 23:55:32 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAJuMu0yrR7H+/2dsb2JhbACBRZ9jcZ5/m2qFSQSKSoML X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208,217";a="285222630" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2010 06:57:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9I6usNW026358; Mon, 18 Oct 2010 06:57:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 08:56:56 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 08:56:55 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-5--159830325 From: JP Vasseur In-Reply-To: <005801cb653c$76f32340$64d969c0$@com> Date: Mon, 18 Oct 2010 08:56:54 +0200 Message-Id: <51D35230-A55C-4AE3-AF69-B81C5FA7A41B@cisco.com> References: <005801cb653c$76f32340$64d969c0$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Oct 2010 06:56:56.0001 (UTC) FILETIME=[A6EC5310:01CB6E91] Cc: roll@ietf.org Subject: Re: [Roll] metrics LC Tickets: battery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:55:34 -0000 --Apple-Mail-5--159830325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Colin, Let's try to close on this last ticket (#84) - See below. On Oct 6, 2010, at 11:54 AM, Colin O'Flynn wrote: > Hello, > =20 > There was no ticket opened for what I still consider an issue (I = brought this up in LC) about the energy metric. >=20 > The energy metric when used for battery-powered devices only has a = relative measure of current power being used vs. available energy. Thus = the energy metric will not differentiate between for example a coin-cell = battery and a car battery connected to a node. Even if this IS the = desired result I think it would be useful to clarify this. This is indeed the objective and I agree with you that we could come up = with more complicated/exhaustive node energy metric in the future (note = that there are available flags and the object can carry optional = sub-TLVs too). For the time being, I propose to add the following text: "Note that the estimated percentage of remaining energy indicated in the = E-E field may not be useful in the presence of nodes powered by battery = or energy scavengers when the amount of energy accumulated by the device = significantly differ. Indeed, X% of remaining energy on a node that can = store a large amount of energy cannot be easily compared to the same = percentage of remaining energy on a node powered by a tiny source of = energy. That being said, in networks where nodes have relatively close = energy storage, such a percentage of remaining energy is useful. Other = documents may define more complex/detailed mechanisms to represent these = metric." Let me know if that addresses your concern. Thanks. JP. > =20 > Some example solutions: > #1) > Make a note in the document about this, as it is desired that the = energy metric only reflects the current state of the battery device, and = thus the energy metric is not used for determining the best route (at = least alone). I=92m not sure exactly the point of the node energy metric = in this case as-is. > =20 > The throughput metric is used to reflect the available bandwidth, = which is related to available battery power. Thus a coin-cell battery = for example only advertises a much smaller available bandwidth. This = isn=92t foolproof as other limitations could be reducing the advertised = throughput. > =20 > Future expansions through the use of TLVs could also fix this. > =20 > #2) > The energy metric has an additional field advertising the battery = size. This would be of limited use since absolute measures aren=92t = really comparable. > =20 > #3) > The energy metric has either an additional field indicating the = incremental cost of adding a route, or only advertises the incremental = cost of adding a route. This doesn=92t need to be very accurate, but = even a rough estimate would be useful. > =20 > So the metric would have the E-E field, but also have a second E-E = field indicating the predicted E-E with some certain throughput. So it = looks like: > =20 > [E =96E ] [ Predicted E =96 E] [Bitrate used in predicting E =96 E] > =20 > The bitrate used could be a small selecting of available values and = not an actual decimal number. But it would give you an idea of what sort = of device you are talking to. > =20 > If you are claiming a device can somewhat accurately calculate the E-E = value, and/or can calculate the throughput field, there is no way this = is any more complicated than either of those. > =20 > Regards, > =20 > -Colin --Apple-Mail-5--159830325 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Colin,

Let's try to close on = this last ticket (#84) - See below.

On Oct 6, = 2010, at 11:54 AM, Colin O'Flynn wrote:

Hello,
There was no ticket opened for what = I still consider an issue (I brought this up in LC) about the energy = metric.

The energy metric when used for = battery-powered devices only has a relative measure of current power = being used vs. available energy. Thus the energy metric will not = differentiate between for example a coin-cell battery and a car battery = connected to a node. Even if this IS the desired result I think it would = be useful to clarify this.

Let me know if that addresses your = concern.

Thanks.

JP.
 
#1)
 
 
 
The energy metric has an additional field = advertising the battery size. This would be of limited use since = absolute measures aren=92t really comparable.
#3)
So the metric would have the E-E = field, but also have a second E-E field indicating the predicted E-E = with some certain throughput. So it looks like:
[E =96E ] [ Predicted E =96 E] = [Bitrate used in predicting E =96 E]
The bitrate used could be a small = selecting of available values and not an actual decimal number. But it = would give you an idea of what sort of device you are talking = to.
 
If you are claiming = a device can somewhat accurately calculate the E-E value, and/or can = calculate the throughput field, there is no way this is any more = complicated than either of those.
Regards,
  = -Colin

= --Apple-Mail-5--159830325-- From coflynn@newae.com Mon Oct 18 08:48: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 5EB183A6D7E for ; Mon, 18 Oct 2010 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.408, 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 cf+a-5jbkQ6R for ; Mon, 18 Oct 2010 08:48:15 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 1052E3A6CCF for ; Mon, 18 Oct 2010 08:48:14 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P7rxz-0003gX-56; Mon, 18 Oct 2010 11:49:40 -0400 From: "Colin O'Flynn" To: "'JP Vasseur'" References: <005801cb653c$76f32340$64d969c0$@com> <51D35230-A55C-4AE3-AF69-B81C5FA7A41B@cisco.com> In-Reply-To: <51D35230-A55C-4AE3-AF69-B81C5FA7A41B@cisco.com> Date: Mon, 18 Oct 2010 16:49:03 +0100 Message-ID: <008301cb6edb$ff3c0d90$fdb428b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CB6EE4.61007590" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActukaziFXkxRTFBQZ+bDxkiM41GAAASTSzQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] metrics LC Tickets: battery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 15:48:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0084_01CB6EE4.61007590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, Alright, if this is the objective I think that text makes it very clear and addresses my concern. It might be worthwhile mentioning that other metrics can be used for the purpose of determining 'available power' , so someone reading it can immediately refer to that section of the document (e.g. the throughput metric). Thus it's not a total oversight, just that what the person is looking to be done with the energy metric should actually be done with a different metric. However I understand the point of the metrics draft is more to give the building blocks & describe each one, whereas the OF would discuss how to use them. So I would understand if it wasn't desirable to reference the throughput metric from that point, so whichever makes more sense for the authors would be fine. Warm Regards, -Colin From: JP Vasseur [mailto:jpv@cisco.com] Sent: October 18, 2010 7:57 AM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: metrics LC Tickets: battery Hi Colin, Let's try to close on this last ticket (#84) - See below. On Oct 6, 2010, at 11:54 AM, Colin O'Flynn wrote: Hello, There was no ticket opened for what I still consider an issue (I brought this up in LC) about the energy metric. The energy metric when used for battery-powered devices only has a relative measure of current power being used vs. available energy. Thus the energy metric will not differentiate between for example a coin-cell battery and a car battery connected to a node. Even if this IS the desired result I think it would be useful to clarify this. This is indeed the objective and I agree with you that we could come up with more complicated/exhaustive node energy metric in the future (note that there are available flags and the object can carry optional sub-TLVs too). For the time being, I propose to add the following text: "Note that the estimated percentage of remaining energy indicated in the E-E field may not be useful in the presence of nodes powered by battery or energy scavengers when the amount of energy accumulated by the device significantly differ. Indeed, X% of remaining energy on a node that can store a large amount of energy cannot be easily compared to the same percentage of remaining energy on a node powered by a tiny source of energy. That being said, in networks where nodes have relatively close energy storage, such a percentage of remaining energy is useful. Other documents may define more complex/detailed mechanisms to represent these metric." Let me know if that addresses your concern. Thanks. JP. Some example solutions: #1) Make a note in the document about this, as it is desired that the energy metric only reflects the current state of the battery device, and thus the energy metric is not used for determining the best route (at least alone). I'm not sure exactly the point of the node energy metric in this case as-is. The throughput metric is used to reflect the available bandwidth, which is related to available battery power. Thus a coin-cell battery for example only advertises a much smaller available bandwidth. This isn't foolproof as other limitations could be reducing the advertised throughput. Future expansions through the use of TLVs could also fix this. #2) The energy metric has an additional field advertising the battery size. This would be of limited use since absolute measures aren't really comparable. #3) The energy metric has either an additional field indicating the incremental cost of adding a route, or only advertises the incremental cost of adding a route. This doesn't need to be very accurate, but even a rough estimate would be useful. So the metric would have the E-E field, but also have a second E-E field indicating the predicted E-E with some certain throughput. So it looks like: [E -E ] [ Predicted E - E] [Bitrate used in predicting E - E] The bitrate used could be a small selecting of available values and not an actual decimal number. But it would give you an idea of what sort of device you are talking to. If you are claiming a device can somewhat accurately calculate the E-E value, and/or can calculate the throughput field, there is no way this is any more complicated than either of those. Regards, -Colin ------=_NextPart_000_0084_01CB6EE4.61007590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

Alright, if this is the objective I think that text makes = it very clear and addresses my concern.

 

It might be worthwhile mentioning that other metrics can = be used for the purpose of determining ‘available power’ , so = someone reading it can immediately refer to that section of the document (e.g. = the throughput metric). Thus it’s not a total oversight, just that = what the person is looking to be done with the energy metric should actually be = done with a different metric.

 

However I understand the point of the metrics draft is = more to give the building blocks & describe each one, whereas the OF would = discuss how to use them. So I would understand if it wasn’t desirable to reference the throughput metric from that point, so whichever makes more = sense for the authors would be fine.

 

Warm Regards,

 

  -Colin

 

From:= JP Vasseur [mailto:jpv@cisco.com]
Sent: October 18, 2010 7:57 AM
To: Colin O'Flynn
Cc: roll@ietf.org
Subject: Re: metrics LC Tickets: battery

 

Hi Colin,

 

Let's try to close on this last ticket (#84) - See = below.

 

On Oct 6, 2010, at 11:54 AM, Colin O'Flynn = wrote:



Hello,=

 =

There was no ticket opened for what I still consider an issue (I brought this = up in LC) about the energy metric.


The energy metric when used for battery-powered devices only has a = relative measure of current power being used vs. available energy. Thus the = energy metric will not differentiate between for example a coin-cell battery = and a car battery connected to a node. Even if this IS the desired result I think = it would be useful to clarify this.

 

This is indeed the objective and I agree with you = that we could come up with more complicated/exhaustive node energy metric in the = future (note that there are available flags and the object can carry optional = sub-TLVs too). For the time being, I propose to add the following text:

 

"Note that the estimated percentage of = remaining energy indicated in the E-E field may not be useful in the presence of nodes = powered by battery or energy scavengers when the amount of energy accumulated by = the device significantly differ. Indeed, X% of remaining energy on a node = that can store a large amount of energy cannot be easily compared to the same = percentage of remaining energy on a node powered by a tiny source of energy. That = being said, in networks where nodes have relatively close energy storage, such = a percentage of remaining energy is useful. Other documents may define = more complex/detailed mechanisms to represent these = metric."

 

Let me know if that addresses your = concern.

 

Thanks.

 

JP.



 =

Some example solutions:

#1)

Make a note in the document about this, as it is desired that the energy = metric only reflects the current state of the battery device, and thus the energy = metric is not used for determining the best route (at least alone). I’m not = sure exactly the point of the node energy metric in this case = as-is.

 =

The throughput metric is used to reflect the available bandwidth, which is = related to available battery power. Thus a coin-cell battery for example only advertises a much smaller available bandwidth. This isn’t = foolproof as other limitations could be reducing the advertised = throughput.

 =

Future expansions through the use of TLVs could also fix = this.

 =

#2)

The energy metric has an additional field advertising the battery size. This = would be of limited use since absolute measures aren’t really = comparable.

 =

#3)

The energy metric has either an additional field indicating the incremental = cost of adding a route, or only advertises the incremental cost of adding a = route. This doesn’t need to be very accurate, but even a rough estimate would = be useful.

 =

So the metric would have the E-E field, but also have a second E-E field indicating the predicted E-E with some certain throughput. So it looks = like:

 =

[E –E ] [ Predicted E – E] [Bitrate used in predicting E = – E]

 =

The bitrate used could be a small selecting of available values and not an = actual decimal number. But it would give you an idea of what sort of device you = are talking to.

 =

If you are claiming a device can somewhat accurately calculate the E-E = value, and/or can calculate the throughput field, there is no way this is any = more complicated than either of those.

 =

Regards,

 =

  -Colin

 

------=_NextPart_000_0084_01CB6EE4.61007590-- From jpv@cisco.com Mon Oct 18 09:17: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 EDACA3A6BDB for ; Mon, 18 Oct 2010 09:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.188 X-Spam-Level: X-Spam-Status: No, score=-110.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytq2d0t3FX+J for ; Mon, 18 Oct 2010 09:17:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 546FC3A6ABA for ; Mon, 18 Oct 2010 09:17:27 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMoQvEyQ/khNgWdsb2JhbACBRJ9oFQEBFiIiomacQIVJBIpKgws X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208,217";a="66932009" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2010 16:18:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9IGItl1024494; Mon, 18 Oct 2010 16:18:55 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 18:18:55 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 18:18:54 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-74--126111398 From: JP Vasseur In-Reply-To: <008301cb6edb$ff3c0d90$fdb428b0$@com> Date: Mon, 18 Oct 2010 18:18:53 +0200 Message-Id: <47D30FDC-87EA-462B-90F8-B442645DC79C@cisco.com> References: <005801cb653c$76f32340$64d969c0$@com> <51D35230-A55C-4AE3-AF69-B81C5FA7A41B@cisco.com> <008301cb6edb$ff3c0d90$fdb428b0$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Oct 2010 16:18:54.0869 (UTC) FILETIME=[28EF4450:01CB6EE0] Cc: roll@ietf.org Subject: Re: [Roll] metrics LC Tickets: battery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 16:17:31 -0000 --Apple-Mail-74--126111398 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your prompt reply. We'll update the draft accordingly and = close the ticket. Thanks. JP. On Oct 18, 2010, at 5:49 PM, Colin O'Flynn wrote: > Hi JP, > =20 > Alright, if this is the objective I think that text makes it very = clear and addresses my concern. > =20 > It might be worthwhile mentioning that other metrics can be used for = the purpose of determining =91available power=92 , so someone reading it = can immediately refer to that section of the document (e.g. the = throughput metric). Thus it=92s not a total oversight, just that what = the person is looking to be done with the energy metric should actually = be done with a different metric. > =20 > However I understand the point of the metrics draft is more to give = the building blocks & describe each one, whereas the OF would discuss = how to use them. So I would understand if it wasn=92t desirable to = reference the throughput metric from that point, so whichever makes more = sense for the authors would be fine. > =20 > Warm Regards, > =20 > -Colin > =20 > From: JP Vasseur [mailto:jpv@cisco.com]=20 > Sent: October 18, 2010 7:57 AM > To: Colin O'Flynn > Cc: roll@ietf.org > Subject: Re: metrics LC Tickets: battery > =20 > Hi Colin, > =20 > Let's try to close on this last ticket (#84) - See below. > =20 > On Oct 6, 2010, at 11:54 AM, Colin O'Flynn wrote: >=20 >=20 > Hello, > =20 > There was no ticket opened for what I still consider an issue (I = brought this up in LC) about the energy metric. >=20 > The energy metric when used for battery-powered devices only has a = relative measure of current power being used vs. available energy. Thus = the energy metric will not differentiate between for example a coin-cell = battery and a car battery connected to a node. Even if this IS the = desired result I think it would be useful to clarify this. > =20 > This is indeed the objective and I agree with you that we could come = up with more complicated/exhaustive node energy metric in the future = (note that there are available flags and the object can carry optional = sub-TLVs too). For the time being, I propose to add the following text: > =20 > "Note that the estimated percentage of remaining energy indicated in = the E-E field may not be useful in the presence of nodes powered by = battery or energy scavengers when the amount of energy accumulated by = the device significantly differ. Indeed, X% of remaining energy on a = node that can store a large amount of energy cannot be easily compared = to the same percentage of remaining energy on a node powered by a tiny = source of energy. That being said, in networks where nodes have = relatively close energy storage, such a percentage of remaining energy = is useful. Other documents may define more complex/detailed mechanisms = to represent these metric." > =20 > Let me know if that addresses your concern. > =20 > Thanks. > =20 > JP. >=20 >=20 > =20 > Some example solutions: > #1) > Make a note in the document about this, as it is desired that the = energy metric only reflects the current state of the battery device, and = thus the energy metric is not used for determining the best route (at = least alone). I=92m not sure exactly the point of the node energy metric = in this case as-is. > =20 > The throughput metric is used to reflect the available bandwidth, = which is related to available battery power. Thus a coin-cell battery = for example only advertises a much smaller available bandwidth. This = isn=92t foolproof as other limitations could be reducing the advertised = throughput. > =20 > Future expansions through the use of TLVs could also fix this. > =20 > #2) > The energy metric has an additional field advertising the battery = size. This would be of limited use since absolute measures aren=92t = really comparable. > =20 > #3) > The energy metric has either an additional field indicating the = incremental cost of adding a route, or only advertises the incremental = cost of adding a route. This doesn=92t need to be very accurate, but = even a rough estimate would be useful. > =20 > So the metric would have the E-E field, but also have a second E-E = field indicating the predicted E-E with some certain throughput. So it = looks like: > =20 > [E =96E ] [ Predicted E =96 E] [Bitrate used in predicting E =96 E] > =20 > The bitrate used could be a small selecting of available values and = not an actual decimal number. But it would give you an idea of what sort = of device you are talking to. > =20 > If you are claiming a device can somewhat accurately calculate the E-E = value, and/or can calculate the throughput field, there is no way this = is any more complicated than either of those. > =20 > Regards, > =20 > -Colin > =20 --Apple-Mail-74--126111398 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks for your prompt reply. We'll update the = draft accordingly and close the = ticket.

Thanks.

JP.
=
On Oct 18, 2010, at 5:49 PM, Colin O'Flynn wrote:

Hi = JP,
It = might be worthwhile mentioning that other metrics can be used for the = purpose of determining =91available power=92 , so someone reading it can = immediately refer to that section of the document (e.g. the throughput = metric). Thus it=92s not a total oversight, just that what the person is = looking to be done with the energy metric should actually be done with a = different metric.
Warm = Regards,
From: JP Vasseur = [mailto:jpv@cisco.com] 
Sent: October 18, 2010 7:57 = AM
To: Colin = O'Flynn
Cc: roll@ietf.org
Subject: Re: metrics LC Tickets: = battery
Hi = Colin,
Let's try to close on = this last ticket (#84) - See below.
 
On Oct 6, 2010, at 11:54 = AM, Colin O'Flynn wrote:
There was = no ticket opened for what I still consider an issue (I brought this up = in LC) about the energy metric.

The energy metric when used for battery-powered = devices only has a relative measure of current power being used vs. = available energy. Thus the energy metric will not differentiate between = for example a coin-cell battery and a car battery connected to a node. = Even if this IS the desired result I think it would be useful to clarify = this.
This is indeed the = objective and I agree with you that we could come up with more = complicated/exhaustive node energy metric in the future (note that there = are available flags and the object can carry optional sub-TLVs too). For = the time being, I propose to add the following = text:
"Note that the estimated = percentage of remaining energy indicated in the E-E field may not be = useful in the presence of nodes powered by battery or energy scavengers = when the amount of energy accumulated by the device significantly = differ. Indeed, X% of remaining energy on a node that can store a large = amount of energy cannot be easily compared to the same percentage of = remaining energy on a node powered by a tiny source of energy. That = being said, in networks where nodes have relatively close energy = storage, such a percentage of remaining energy is useful. Other = documents may define more complex/detailed mechanisms to represent these = metric."
Let me know if that = addresses your concern.
 
Some = example solutions:
#1)
Make a note in the document about this, as it is desired = that the energy metric only reflects the current state of the battery = device, and thus the energy metric is not used for determining the best = route (at least alone). I=92m not sure exactly the point of the node = energy metric in this case as-is.
 
The throughput metric is used to reflect the available = bandwidth, which is related to available battery power. Thus a coin-cell = battery for example only advertises a much smaller available bandwidth. = This isn=92t foolproof as other limitations could be reducing the = advertised throughput.
 
Future expansions through the use of TLVs could also fix = this.
The energy metric has an = additional field advertising the battery size. This would be of limited = use since absolute measures aren=92t really = comparable.
The energy metric has either = an additional field indicating the incremental cost of adding a route, = or only advertises the incremental cost of adding a route. This doesn=92t = need to be very accurate, but even a rough estimate would be = useful.
So the = metric would have the E-E field, but also have a second E-E field = indicating the predicted E-E with some certain throughput. So it looks = like:
[E =96E ] = [ Predicted E =96 E] [Bitrate used in predicting E =96 = E]
The = bitrate used could be a small selecting of available values and not an = actual decimal number. But it would give you an idea of what sort of = device you are talking to.
 
If you are claiming a device can somewhat accurately = calculate the E-E value, and/or can calculate the throughput field, = there is no way this is any more complicated than either of = those.
  = -Colin
X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pister@eecs.berkeley.edu, jpv@cisco.com X-Trac-Project: roll Date: Mon, 18 Oct 2010 16:19:41 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/roll/trac/ticket/84#comment:1 Message-ID: <064.1f76bb64793eb91ee4c171ff3b3295cd@tools.ietf.org> References: <055.bdad003363c224088ba09c963e73aad6@tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <055.bdad003363c224088ba09c963e73aad6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pister@eecs.berkeley.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] routing-metrics #84 (closed): Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:18:14 -0000 #84: Comment received WG Last Call on draft-ietf-roll-routing-metrics-09.txt --- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Answer from Colin: Hi JP, Alright, if this is the objective I think that text makes it very clear and addresses my concern. It might be worthwhile mentioning that other metrics can be used for the purpose of determining ‘available power’ , so someone reading it can immediately refer to that section of the document (e.g. the throughput metric). Thus it’s not a total oversight, just that what the person is looking to be done with the energy metric should actually be done with a different metric. However I understand the point of the metrics draft is more to give the building blocks & describe each one, whereas the OF would discuss how to use them. So I would understand if it wasn’t desirable to reference the throughput metric from that point, so whichever makes more sense for the authors would be fine. Warm Regards, -Colin -- -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pister@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: roll From Daniel.Popa@itron.com Tue Oct 19 07:25: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 9F6723A6809 for ; Tue, 19 Oct 2010 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ9DFHcoXsQH for ; Tue, 19 Oct 2010 07:25:46 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by core3.amsl.com (Postfix) with ESMTP id 935673A683A for ; Tue, 19 Oct 2010 07:25:45 -0700 (PDT) Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.110]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 19 Oct 2010 07:27:16 -0700 From: "Popa, Daniel" To: ROLL WG Date: Tue, 19 Oct 2010 07:27:14 -0700 Thread-Topic: Request for clarifications on RPL draft Thread-Index: ActvmbnhxzvF75rmSv+0Oi+nNUUs3A== Message-ID: <83027ECE5ECDC04E9BA5350B756A88E159886DF63A@ITR-EXMBXVS-1.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] Request for clarifications on RPL draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 14:25:47 -0000 Dear ROLLers,=20 I would like asking for some clarifications on "Section 14. Guidelines for = Objective Functions"=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D First clarification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The text in Subsection 14.1 "Objective Function behavior", bullet 4, says:= =20 An OF computes rank of a node for comparison by adding to the rank of the c= andidate (neighbor?) a value representing the relative locations of the nod= e and the candidate (neighbor?) in the DODAG Version. * The increase in rank must be at least MinHopRankIncrease. * .... * Candidate neighbors that would cause the rank of the node to increase ar= e not considered for parent selection. I find the statements under "*" in contradiction. I am wondering if the las= t "*" should not be something like: "In all situations but the first time a node joins a DODAG, candidate neigh= bors that would cause the rank of the node to increase are not considered f= or parent selection." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Second clarification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bullets 7 says=20 "As it scans all the candidate neighbors, the OF keeps the current best par= ent and compares its capabilities with the current candidate neighbor. The = OF defines a number of tests that are critical to reach the objective. A te= st between the routers determines an order relation."=20 Then the text summarizes some tests between routers. I do not find details= about the critical tests a node has to run when electing between several n= on-router neighbors. Can somebody guide me to the place where I can find th= ese details? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks.=20 Regards,=20 Daniel From jpv@cisco.com Tue Oct 19 21:18:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1E53A69AA for ; Tue, 19 Oct 2010 21:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.193 X-Spam-Level: X-Spam-Status: No, score=-110.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN8Q1H-Hi0mC for ; Tue, 19 Oct 2010 21:18:49 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D20263A699F for ; Tue, 19 Oct 2010 21:18:49 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKAKvkyrRN+K/2dsb2JhbAChWHGlRZwzhUoEikuDBAY X-IronPort-AV: E=Sophos;i="4.57,354,1283731200"; d="scan'208";a="203529728" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2010 04:20:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9K4KLxw014007 for ; Wed, 20 Oct 2010 04:20:21 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 06:20:20 +0200 Received: from [10.111.139.10] ([10.55.94.214]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 06:20:20 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 06:20:19 +0200 Message-Id: <11D53CD9-66FA-46A3-99AF-C3D0A3C310A8@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Oct 2010 04:20:20.0747 (UTC) FILETIME=[1BBDD5B0:01CB700E] Subject: [Roll] Draft Agenda ROLL WG Meeting IETF-79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 04:18:50 -0000 Dear all, The draft agenda has been published: = http://www.ietf.org/proceedings/79/agenda/roll.txt Let us know if you would like a "slot". Thanks. JP.= From root@core3.amsl.com Tue Oct 19 23:30:04 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 6CF303A69D1; Tue, 19 Oct 2010 23:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101020063003.6CF303A69D1@core3.amsl.com> Date: Tue, 19 Oct 2010 23:30:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-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, 20 Oct 2010 06:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-10.txt Pages : 31 Date : 2010-10-19 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-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-routing-metrics-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-19232603.I-D@ietf.org> --NextPart-- From jpv@cisco.com Tue Oct 19 23:33: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 034C73A69BA for ; Tue, 19 Oct 2010 23:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=-3.597, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 BsZCbtIsdttP for ; Tue, 19 Oct 2010 23:33:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 26A6F3A69B9 for ; Tue, 19 Oct 2010 23:33:17 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGADcqvkyQ/khLgWdsb2JhbACZbYcXVRUBARYiIqQUnDCFSgSKS4MEBg X-IronPort-AV: E=Sophos;i="4.57,354,1283731200"; d="scan'208,217";a="11648102" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Oct 2010 06:34:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9K6Ynbx005286; Wed, 20 Oct 2010 06:34:50 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 08:34:49 +0200 Received: from [172.18.19.126] ([10.61.70.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 08:34:46 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-38-11631874 Date: Wed, 20 Oct 2010 08:34:37 +0200 References: <20101020063003.6CF303A69D1@core3.amsl.com> To: ROLL WG Message-Id: <00065046-64FC-4437-B2FE-86B67E9D33F9@cisco.com> X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Oct 2010 06:34:47.0112 (UTC) FILETIME=[E3AB7480:01CB7020] Cc: =?iso-8859-1?Q?D=E9jean_Nicolas?= Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-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, 20 Oct 2010 06:33:20 -0000 --Apple-Mail-38-11631874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Here is the latest revision of the metric ID that incorporates all the = comments raised during WG LC (all tickets closed). Thanks. JP and all. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 20, 2010 8:30:02 AM GMT+02:00 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-routing-metrics-10.txt=20 > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : Routing Metrics used for Path Calculation in = Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-10.txt > Pages : 31 > Date : 2010-10-19 >=20 > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-10.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-38-11631874 Content-Type: multipart/mixed; boundary=Apple-Mail-39-11631874 --Apple-Mail-39-11631874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

Here is the latest revision of the metric ID = that incorporates all the comments raised during WG LC (all tickets = closed).

Thanks.

JP = and all.

Begin forwarded message:

Date: October 20, 2010 8:30:02 AM = GMT+02:00
Subject: I-D = Action:draft-ietf-roll-routing-metrics-10.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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


= Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, et = al.
= Filename        : = draft-ietf-roll-routing-metrics-10.txt
Pages =           : = 31
= Date =            : = 2010-10-19

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

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

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

--Apple-Mail-39-11631874-- --Apple-Mail-38-11631874-- From coflynn@newae.com Wed Oct 20 02:04: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 58AF83A6887 for ; Wed, 20 Oct 2010 02:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_20=-0.74, 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 bhAdak6vrUdJ for ; Wed, 20 Oct 2010 02:04:48 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 4DF773A67DA for ; Wed, 20 Oct 2010 02:04:48 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P8Ucl-0006VO-8b for roll@ietf.org; Wed, 20 Oct 2010 05:06:20 -0400 From: "Colin O'Flynn" To: References: <023c01cb616e$a06c2590$e14470b0$@com> <001b01cb6188$6c293ec0$447bbc40$@com> In-Reply-To: <001b01cb6188$6c293ec0$447bbc40$@com> Date: Wed, 20 Oct 2010 10:06:10 +0100 Message-ID: <006101cb7036$0bf854c0$23e8fe40$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01CB703E.6DBCBCC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActhbpuBbYTzNgPyQWaPQTAhLEHYUgAGNJGgA6tucZA= Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 09:04:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0062_01CB703E.6DBCBCC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, The RPL dissectors have now been committed to Wireshark SVN (revision 34579). If you want RPL dissectors you now need to just get version 34759 or later from http://www.wireshark.org/download/automated . Eventually this will thus become part of the standard Wireshark release. The dissectors currently support the following: Messages: *DIO Messages *DIS Messages *DAO Messages *DAO-ACK Messages Options: *Pad1 *PadN *Routing Information *DODAG Config *RPL Target *Transit Information *Solicited Information *Prefix Information *RPL Target Descriptor Thanks to Owen Kirby for his help in getting these started & finished. Regards, -Colin O'Flynn From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 1, 2010 5:48 PM To: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark Just a note the patch, example test-case, and binary at that same link have all been updated just now. -Colin From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 1, 2010 2:43 PM To: roll@ietf.org Subject: [Roll] RPL Dissectors for Wireshark Hello, I had the beginnings of RPL-11 dissectors for Wireshark. The patch is available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5266 , and if anyone is able to use it I would appreciate feedback of any issues you find. I don't think it is complete yet so don't expect every feature to be present. If there is nothing critical I could see if it can be committed into Wireshark SVN, which would eventually make it part of a normal release. If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . Regards, -Colin ------=_NextPart_000_0062_01CB703E.6DBCBCC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The RPL dissectors = have now been committed to Wireshark SVN (revision 34579). If you want RPL dissectors = you now need to just get version 34759 or later from http://www.wireshark= .org/download/automated . Eventually this will thus become part of the standard Wireshark = release.

 

The dissectors = currently support the following:

 

Messages:

*DIO Messages

*DIS Messages

*DAO Messages

*DAO-ACK Messages

 

Options:

        &= nbsp;       *Pad1

        &= nbsp;       *PadN

        &= nbsp;       *Routing Information

        &= nbsp;       *DODAG Config

        &= nbsp;       *RPL Target

        &= nbsp;       *Transit Information

        &= nbsp;       *Solicited Information

        &= nbsp;       *Prefix Information

        &= nbsp;       *RPL Target Descriptor

 

Thanks to Owen Kirby = for his help in getting these started & finished.

 

Regards,

 

  -Colin = O’Flynn

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 5:48 PM
To: roll@ietf.org
Subject: Re: [Roll] RPL Dissectors for = Wireshark

 

Just a note the = patch, example test-case, and binary at that same link have all been updated just = now.

 

  = -Colin

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 2:43 PM
To: roll@ietf.org
Subject: [Roll] RPL Dissectors for = Wireshark

 

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark. The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if anyone is able to use it I would appreciate feedback of any = issues you find. I don’t think it is complete yet so don’t expect every feature to be present.

 

If there is nothing critical I could see if it can = be committed into Wireshark SVN, which would eventually make it part of a = normal release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /a> .

 

Regards,

 

  -Colin

------=_NextPart_000_0062_01CB703E.6DBCBCC0-- From c.chauvenet@watteco.com Wed Oct 20 05:23: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 608C13A67A6 for ; Wed, 20 Oct 2010 05:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoE9cwKZn7wA for ; Wed, 20 Oct 2010 05:23:34 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 05C353A6768 for ; Wed, 20 Oct 2010 05:23:33 -0700 (PDT) Received: from PCdePoste9 ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id CWT70303; Wed, 20 Oct 2010 14:25:03 +0200 Message-ID: <2BBB5BE3AD3744F4A096C0E65903D3EA@PCdePoste9> From: "Cedric Chauvenet" To: "Colin O'Flynn" , References: <023c01cb616e$a06c2590$e14470b0$@com><001b01cb6188$6c293ec0$447bbc40$@com> <006101cb7036$0bf854c0$23e8fe40$@com> In-Reply-To: <006101cb7036$0bf854c0$23e8fe40$@com> Date: Wed, 20 Oct 2010 14:25:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01CB7062.A20EB590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 12:23:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01CB7062.A20EB590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Colin,=20 That's an excellent piece of work ! I noticed that all RPL Control Message Option where implemented, except = the "Metric Container" option (Section 6.7.4 of RPL draft-11). Any reason for that ? Plan to add it ? Thank's again for this achievment. Regards, C=E9dric.=20 ----- Original Message -----=20 From: Colin O'Flynn=20 To: roll@ietf.org=20 Sent: Wednesday, October 20, 2010 11:06 AM Subject: Re: [Roll] RPL Dissectors for Wireshark Hello, =20 The RPL dissectors have now been committed to Wireshark SVN (revision = 34579). If you want RPL dissectors you now need to just get version = 34759 or later from http://www.wireshark.org/download/automated . = Eventually this will thus become part of the standard Wireshark release. =20 The dissectors currently support the following: =20 Messages: *DIO Messages *DIS Messages *DAO Messages *DAO-ACK Messages =20 Options: *Pad1 *PadN *Routing Information *DODAG Config *RPL Target *Transit Information *Solicited Information *Prefix Information *RPL Target Descriptor =20 Thanks to Owen Kirby for his help in getting these started & finished. =20 Regards, =20 -Colin O'Flynn =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: October 1, 2010 5:48 PM To: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Just a note the patch, example test-case, and binary at that same link = have all been updated just now. =20 -Colin =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: October 1, 2010 2:43 PM To: roll@ietf.org Subject: [Roll] RPL Dissectors for Wireshark =20 Hello, =20 I had the beginnings of RPL-11 dissectors for Wireshark. The patch is = available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 = , and if anyone is able to use it I would appreciate feedback of any = issues you find. I don't think it is complete yet so don't expect every = feature to be present. =20 If there is nothing critical I could see if it can be committed into = Wireshark SVN, which would eventually make it part of a normal release. =20 If you require Windows builds I have one at = www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . =20 Regards, =20 -Colin -------------------------------------------------------------------------= ----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00DA_01CB7062.A20EB590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Colin,
 
That's an excellent piece of work = !
 
I noticed that all RPL Control Message = Option where=20 implemented, except the "Metric Container" option (Section 6.7.4 of RPL=20 draft-11).
 
Any reason for that ? = Plan to add it=20 ?
 
Thank's again for this = achievment.
 
Regards,
C=E9dric. 
 
----- Original Message -----
From:=20 Colin O'Flynn
Sent: Wednesday, October 20, = 2010 11:06=20 AM
Subject: Re: [Roll] RPL = Dissectors for=20 Wireshark

Hello,

 

The RPL dissectors = have now=20 been committed to Wireshark SVN (revision 34579). If you want RPL = dissectors=20 you now need to just get version 34759 or later from http://www.wireshark= .org/download/automated=20 . Eventually this will thus become part of the standard Wireshark=20 release.

 

The dissectors = currently=20 support the following:

 

Messages:

*DIO=20 Messages

*DIS=20 Messages

*DAO=20 Messages

*DAO-ACK Messages

 

Options:

          &nbs= p;    =20 *Pad1

          &nbs= p;    =20 *PadN

          &nbs= p;    =20 *Routing Information

          &nbs= p;    =20 *DODAG Config

          &nbs= p;    =20 *RPL Target

          &nbs= p;    =20 *Transit Information

          &nbs= p;    =20 *Solicited Information

          &nbs= p;    =20 *Prefix Information

          &nbs= p;    =20 *RPL Target Descriptor

 

Thanks to Owen = Kirby for his=20 help in getting these started & finished.

 

Regards,

 

  -Colin=20 O=92Flynn

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin=20 O'Flynn
Sent: October 1, 2010 5:48 PM
To:=20 roll@ietf.org
Subject: Re: [Roll] RPL Dissectors for=20 Wireshark

 

Just a note the = patch, example=20 test-case, and binary at that same link have all been updated just=20 now.

 

 =20 -Colin

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin=20 O'Flynn
Sent: October 1, 2010 2:43 PM
To:=20 roll@ietf.org
Subject: [Roll] RPL Dissectors for=20 Wireshark

 

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark.=20 The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266=20 , and if anyone is able to use it I would appreciate feedback of any = issues=20 you find. I don=92t think it is complete yet so don=92t expect every = feature to be=20 present.

 

If there is nothing critical I could see if it = can be=20 committed into Wireshark SVN, which would eventually make it part of a = normal=20 release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /A>=20 .

 

Regards,

 

  -Colin

_______________________________________________
Roll mailing = = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
------=_NextPart_000_00DA_01CB7062.A20EB590-- From coflynn@newae.com Wed Oct 20 05:36: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 1657C3A67EE for ; Wed, 20 Oct 2010 05:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.410, 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 BzTJZdqG-x6r for ; Wed, 20 Oct 2010 05:36:19 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 524F23A6931 for ; Wed, 20 Oct 2010 05:35:51 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P8Xv0-0004qW-Sq; Wed, 20 Oct 2010 08:37:23 -0400 From: "Colin O'Flynn" To: "'Cedric Chauvenet'" , References: <023c01cb616e$a06c2590$e14470b0$@com><001b01cb6188$6c293ec0$447bbc40$@com> <006101cb7036$0bf854c0$23e8fe40$@com> <2BBB5BE3AD3744F4A096C0E65903D3EA@PCdePoste9> In-Reply-To: <2BBB5BE3AD3744F4A096C0E65903D3EA@PCdePoste9> Date: Wed, 20 Oct 2010 13:37:17 +0100 Message-ID: <000c01cb7053$8a3f93d0$9ebebb70$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CB705B.EC03FBD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActwUdWxEWJg4pUIRtyk1jvLn8YnHAAAVedw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 12:36:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CB705B.EC03FBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cedric, =20 The metric container really doesn=92t have anything in it according to = RPL-12, so there=92s nothing to decode. I think the dissectors will actually = display the metric container as a =93Metric Container=94 option, but don=92t = decode it any further. =20 Eventually the containers from the metrics ID could be added to give you useful information. =20 -Colin =20 From: Cedric Chauvenet [mailto:c.chauvenet@watteco.com]=20 Sent: October 20, 2010 1:25 PM To: Colin O'Flynn; roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Hi Colin,=20 =20 That's an excellent piece of work ! =20 I noticed that all RPL Control Message Option where implemented, except = the "Metric Container" option (Section 6.7.4 of RPL draft-11). =20 Any reason for that ? Plan to add it ? =20 Thank's again for this achievment. =20 Regards, C=E9dric.=20 =20 ----- Original Message -----=20 From: Colin O'Flynn=20 To: roll@ietf.org=20 Sent: Wednesday, October 20, 2010 11:06 AM Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Hello, =20 The RPL dissectors have now been committed to Wireshark SVN (revision 34579). If you want RPL dissectors you now need to just get version = 34759 or later from http://www.wireshark.org/download/automated . Eventually this will thus become part of the standard Wireshark release. =20 The dissectors currently support the following: =20 Messages: *DIO Messages *DIS Messages *DAO Messages *DAO-ACK Messages =20 Options: *Pad1 *PadN *Routing Information *DODAG Config *RPL Target *Transit Information *Solicited Information *Prefix Information *RPL Target Descriptor =20 Thanks to Owen Kirby for his help in getting these started & finished. =20 Regards, =20 -Colin O=92Flynn =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 1, 2010 5:48 PM To: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Just a note the patch, example test-case, and binary at that same link = have all been updated just now. =20 -Colin =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 1, 2010 2:43 PM To: roll@ietf.org Subject: [Roll] RPL Dissectors for Wireshark =20 Hello, =20 I had the beginnings of RPL-11 dissectors for Wireshark. The patch is available at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 = , and if anyone is able to use it I would appreciate feedback of any issues = you find. I don=92t think it is complete yet so don=92t expect every feature = to be present. =20 If there is nothing critical I could see if it can be committed into Wireshark SVN, which would eventually make it part of a normal release. =20 If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . =20 Regards, =20 -Colin _____ =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_000D_01CB705B.EC03FBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Cedric,

 

The metric container = really doesn’t have anything in it according to RPL-12, so there’s = nothing to decode. I think the dissectors will actually display the metric container as a = “Metric Container” option, but don’t decode it any = further.

 

Eventually the = containers from the metrics ID could be added to give you useful = information.

 

=A0 = -Colin

 

From:= Cedric = Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: October 20, 2010 1:25 PM
To: Colin O'Flynn; roll@ietf.org
Subject: Re: [Roll] RPL Dissectors for = Wireshark

 

Hi Colin,

 

That's an excellent piece of work !

 

I noticed that all RPL Control Message Option where implemented, except = the "Metric Container" option (Section 6.7.4 of RPL = draft-11).

 

Any reas= on for that ? Plan to add it ?

 

Thank's again for this achievment.

 

Regards,

C=E9dric. 

 

----- Original Message -----

From: Colin = O'Flynn

Sent:<= /b> Wednesday, = October 20, 2010 11:06 AM

Subject: Re: [Roll] = RPL Dissectors for Wireshark

 

Hello,

 

The RPL dissectors = have now been committed to Wireshark SVN (revision 34579). If you want RPL dissectors = you now need to just get version 34759 or later from http://www.wireshark= .org/download/automated . Eventually this will thus become part of the standard Wireshark = release.

 

The dissectors = currently support the following:

 

Messages:

*DIO Messages

*DIS Messages

*DAO Messages

*DAO-ACK Messages

 

Options:

        &= nbsp;       *Pad1

        &= nbsp;       *PadN

        &= nbsp;       *Routing Information

        &= nbsp;       *DODAG Config

        &= nbsp;       *RPL Target

        &= nbsp;       *Transit Information

        &= nbsp;       *Solicited Information

        &= nbsp;       *Prefix Information

        &= nbsp;       *RPL Target Descriptor

 

Thanks to Owen Kirby = for his help in getting these started & finished.

 

Regards,

 

  -Colin = O’Flynn

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 5:48 PM
To: roll@ietf.org
Subject: Re: [Roll] RPL Dissectors for = Wireshark

 

Just a note the = patch, example test-case, and binary at that same link have all been updated just = now.

 

  = -Colin

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 2:43 PM
To: roll@ietf.org
Subject: [Roll] RPL Dissectors for = Wireshark

 

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark. The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if anyone is able to use it I would appreciate feedback of any = issues you find. I don’t think it is complete yet so don’t expect every = feature to be present.

 

If there is nothing critical I could see if it can = be committed into Wireshark SVN, which would eventually make it part of a = normal release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /a> .

 

Regards,

 

  -Colin

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

------=_NextPart_000_000D_01CB705B.EC03FBD0-- From c.chauvenet@watteco.com Thu Oct 21 01:16: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 DB9923A69DD for ; Thu, 21 Oct 2010 01:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zj349GV+NPl for ; Thu, 21 Oct 2010 01:16:49 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 404243A6A04 for ; Thu, 21 Oct 2010 01:16:41 -0700 (PDT) Received: from PCdePoste9 ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id DSN87513; Thu, 21 Oct 2010 10:18:13 +0200 Message-ID: From: "Cedric Chauvenet" To: "Colin O'Flynn" , References: <023c01cb616e$a06c2590$e14470b0$@com><001b01cb6188$6c293ec0$447bbc40$@com> <006101cb7036$0bf854c0$23e8fe40$@com> <2BBB5BE3AD3744F4A096C0E65903D3EA@PCdePoste9> <000c01cb7053$8a3f93d0$9ebebb70$@com> In-Reply-To: <000c01cb7053$8a3f93d0$9ebebb70$@com> Date: Thu, 21 Oct 2010 10:18:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CB7109.532D1960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 Subject: Re: [Roll] RPL Dissectors for Wireshark X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 08:16:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01CB7109.532D1960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Colin, You're right, the Metric Container option is just a classic TLV option, = and the relevancy of it is mostly related to the routing-metrics draft, = rather than rpl. Was just a comment. C=E9dric ----- Original Message -----=20 From: Colin O'Flynn=20 To: 'Cedric Chauvenet' ; roll@ietf.org=20 Sent: Wednesday, October 20, 2010 2:37 PM Subject: RE: [Roll] RPL Dissectors for Wireshark Hi Cedric, =20 The metric container really doesn't have anything in it according to = RPL-12, so there's nothing to decode. I think the dissectors will = actually display the metric container as a "Metric Container" option, = but don't decode it any further. =20 Eventually the containers from the metrics ID could be added to give = you useful information. =20 -Colin =20 From: Cedric Chauvenet [mailto:c.chauvenet@watteco.com]=20 Sent: October 20, 2010 1:25 PM To: Colin O'Flynn; roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Hi Colin,=20 =20 That's an excellent piece of work ! =20 I noticed that all RPL Control Message Option where implemented, = except the "Metric Container" option (Section 6.7.4 of RPL draft-11). =20 Any reason for that ? Plan to add it ? =20 Thank's again for this achievment. =20 Regards, C=E9dric.=20 =20 ----- Original Message -----=20 From: Colin O'Flynn=20 To: roll@ietf.org=20 Sent: Wednesday, October 20, 2010 11:06 AM Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Hello, =20 The RPL dissectors have now been committed to Wireshark SVN = (revision 34579). If you want RPL dissectors you now need to just get = version 34759 or later from http://www.wireshark.org/download/automated = . Eventually this will thus become part of the standard Wireshark = release. =20 The dissectors currently support the following: =20 Messages: *DIO Messages *DIS Messages *DAO Messages *DAO-ACK Messages =20 Options: *Pad1 *PadN *Routing Information *DODAG Config *RPL Target *Transit Information *Solicited Information *Prefix Information *RPL Target Descriptor =20 Thanks to Owen Kirby for his help in getting these started & = finished. =20 Regards, =20 -Colin O'Flynn =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: October 1, 2010 5:48 PM To: roll@ietf.org Subject: Re: [Roll] RPL Dissectors for Wireshark =20 Just a note the patch, example test-case, and binary at that same = link have all been updated just now. =20 -Colin =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: October 1, 2010 2:43 PM To: roll@ietf.org Subject: [Roll] RPL Dissectors for Wireshark =20 Hello, =20 I had the beginnings of RPL-11 dissectors for Wireshark. The patch = is available at = https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266 , and if = anyone is able to use it I would appreciate feedback of any issues you = find. I don't think it is complete yet so don't expect every feature to = be present. =20 If there is nothing critical I could see if it can be committed into = Wireshark SVN, which would eventually make it part of a normal release. =20 If you require Windows builds I have one at = www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip . =20 Regards, =20 -Colin -------------------------------------------------------------------------= --- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_006F_01CB7109.532D1960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Colin,
 
You're right, the Metric Container = option is=20 just a classic TLV option, and the relevancy of it is = mostly=20 related to the routing-metrics draft, rather than rpl.
 
Was just a comment.
 
C=E9dric
----- Original Message -----
From:=20 Colin = O'Flynn=20
To: 'Cedric Chauvenet' ; roll@ietf.org =
Sent: Wednesday, October 20, = 2010 2:37=20 PM
Subject: RE: [Roll] RPL = Dissectors for=20 Wireshark

Hi=20 Cedric,

 

The metric = container really=20 doesn=92t have anything in it according to RPL-12, so there=92s = nothing to decode.=20 I think the dissectors will actually display the metric container as a = =93Metric=20 Container=94 option, but don=92t decode it any = further.

 

Eventually the = containers from=20 the metrics ID could be added to give you useful=20 information.

 

 =20 -Colin

 

From: Cedric = Chauvenet=20 [mailto:c.chauvenet@watteco.com]
Sent: October 20, 2010 = 1:25=20 PM
To: Colin O'Flynn; roll@ietf.org
Subject: Re: = [Roll]=20 RPL Dissectors for Wireshark

 

Hi Colin, =

 

That's an = excellent=20 piece of work !

 

I noticed = that all=20 RPL Control Message Option where implemented, except the "Metric = Container"=20 option (Section 6.7.4 of RPL draft-11).

 

Any reason for=20 that ? Plan to add it ?

 

Thank's = again for=20 this achievment.

 

Regards,

C=E9dric. 

 

----- = Original=20 Message -----

From: Colin O'Flynn =

To: roll@ietf.org=20

Sent: = Wednesday,=20 October 20, 2010 11:06 AM

Subject: Re: = [Roll] RPL=20 Dissectors for Wireshark

 

Hello,

 

The RPL = dissectors have now=20 been committed to Wireshark SVN (revision 34579). If you want RPL = dissectors=20 you now need to just get version 34759 or later from http://www.wireshark= .org/download/automated=20 . Eventually this will thus become part of the standard Wireshark=20 release.

 

The dissectors = currently=20 support the following:

 

Messages:

*DIO Messages

*DIS Messages

*DAO Messages

*DAO-ACK Messages

 

Options:

          &nbs= p;    =20 *Pad1

          &nbs= p;    =20 *PadN

          &nbs= p;    =20 *Routing Information

          &nbs= p;    =20 *DODAG Config

          &nbs= p;    =20 *RPL Target

          &nbs= p;    =20 *Transit Information

          &nbs= p;    =20 *Solicited Information

          &nbs= p;    =20 *Prefix Information

          &nbs= p;    =20 *RPL Target Descriptor

 

Thanks to Owen = Kirby for his=20 help in getting these started & finished.

 

Regards,

 

  -Colin=20 O=92Flynn

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 5:48 = PM
To:=20 roll@ietf.org
Subject: Re: [Roll] RPL Dissectors for=20 Wireshark

 

Just a note the = patch,=20 example test-case, and binary at that same link have all been = updated just=20 now.

 

 =20 -Colin

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Colin O'Flynn
Sent: October 1, 2010 2:43 = PM
To:=20 roll@ietf.org
Subject: [Roll] RPL Dissectors for=20 Wireshark

 

Hello,

 

I had the beginnings of RPL-11 dissectors for = Wireshark.=20 The patch is available at https= ://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5266=20 , and if anyone is able to use it I would appreciate feedback of any = issues=20 you find. I don=92t think it is complete yet so don=92t expect every = feature to=20 be present.

 

If there is nothing critical I could see if it = can be=20 committed into Wireshark SVN, which would eventually make it part of = a=20 normal release.

 

If you require Windows builds I have one at www.newae.com/15dot4tools/wireshark-win32-1.5.0-OFLYNN-P5266.zip<= /A>=20 .

 

Regards,

 

  -Colin

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

------=_NextPart_000_006F_01CB7109.532D1960-- From rdroms.ietf@gmail.com Thu Oct 21 07:53: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 D4F7E3A6A38; Thu, 21 Oct 2010 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUkOR2Y-Ug2V; Thu, 21 Oct 2010 07:53:40 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id A29653A67B7; Thu, 21 Oct 2010 07:53:40 -0700 (PDT) Received: by pxi9 with SMTP id 9so1070738pxi.31 for ; Thu, 21 Oct 2010 07:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=iXhppsNUs8NIv5GsnRcC9BUPuY54NEdZEtwJ4VqTHt8=; b=JLcW0DcX3rpeqe1Ab8t/8s2+3YDfRfv8vQsBH4/QVIql99mOCUaqIVFpwW0rj2BAtl 5mLb750xjloXaMhEGGbi9rWDA34CSxWy00ou9jJRfIlXsD3k5SDco3b+D7zUZnEo2bDt 10vzgEVIQ8ck4GfIN1Veg8ugcb6TdYF2jJgdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SGC8VsshGZ+/WZlJ9QgMliRBjmPebBd3lZYFzWKm+hnfN7unIWM/1jjiuOmHhra0Ux nVdd5z8PFVOjxceR+XBVfsPGqg/9sw2qYicXnkgCYSTGxkvCKUA7+n8KPgrdgdfR4ohV AJfvAQD16w51gu9qZuCGlDvq70MrKGTxDHCsM= Received: by 10.142.142.18 with SMTP id p18mr733561wfd.398.1287672916272; Thu, 21 Oct 2010 07:55:16 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id s12sm877909vbp.14.2010.10.21.07.55.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 07:55:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 21 Oct 2010 10:55:12 -0400 Content-Transfer-Encoding: 7bit Message-Id: <31FD58B9-BD19-436F-8700-99CDA7409659@gmail.com> References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1081) Cc: ipdir@ietf.org, Jari Arkko , roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 14:53:43 -0000 Thanks, Margaret, for your thorough and helpful review. - Ralph From root@core3.amsl.com Fri Oct 22 09: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 8D7F03A6935; Fri, 22 Oct 2010 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101022164501.8D7F03A6935@core3.amsl.com> Date: Fri, 22 Oct 2010 09:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 16: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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-13.txt Pages : 142 Date : 2010-10-22 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-22093009.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Fri Oct 22 11:18: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 9B45E3A694D for ; Fri, 22 Oct 2010 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRbxQKQpLCEo for ; Fri, 22 Oct 2010 11:18:03 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1BA3A68FB for ; Fri, 22 Oct 2010 11:18:01 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 208BF9400F9 for ; Fri, 22 Oct 2010 20:19:34 +0200 (CEST) Message-ID: <4CC1D5B5.4050207@gmail.com> Date: Fri, 22 Oct 2010 20:19:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 CC: roll@ietf.org References: <20101022164501.8D7F03A6935@core3.amsl.com> In-Reply-To: <20101022164501.8D7F03A6935@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101022-1, 22/10/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:18:05 -0000 Hello to WG, Thinking aloud, I see new versions of the RPL draft which seem subsequent to IESG comments. I look at the History tab at: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ Alex Le 22/10/2010 18:45, Internet-Drafts@ietf.org a crit : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-13.txt > Pages : 142 > Date : 2010-10-22 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-13.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. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From margaretw42@gmail.com Thu Oct 21 07:47: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 0BC2E3A6A27; Thu, 21 Oct 2010 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 6aX-qQwmdHs9; Thu, 21 Oct 2010 07:46:47 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1ED323A6A22; Thu, 21 Oct 2010 07:46:46 -0700 (PDT) Received: by qwc9 with SMTP id 9so3685159qwc.31 for ; Thu, 21 Oct 2010 07:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=uuu3HQj7Whou8nKxWmr6eskoqHT8GWY7wwBBw1ZoM4E=; b=w/KBSvG9ydauC/F7JtoXlKqqqdTLNv9/iah0TM+ynbWpqXKXPYu54qacqQpF0vGDe2 gZ5qIZNq6TuPc9XxGl6RH4Qi3dlkTkAMg93xD9WD/bSf5ThV6iJCMbiN+HX8r8jWkt7D aVYX1TorC3kR6ut3GNZwiKuLqc+0vgBnsXn40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=j+IKJ1OZEAfzIT7j8Ql62Y/e8hxD2Mcn/XTIrGmKLr9CsDqpb80VOPWKwhvlesHeKy /mkz0qVyMm7ZP933yT76xMqtEBsL5DElV1964NdEHHe23hTBC4ZONeEDmaJT2YJjxhPW 1hvMSsYD432P2BOxwmj0fWAKzT3UOxZzqTs88= Received: by 10.224.53.200 with SMTP id n8mr906569qag.157.1287672502311; Thu, 21 Oct 2010 07:48:22 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id nb14sm1484760qcb.0.2010.10.21.07.48.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 07:48:20 -0700 (PDT) Message-Id: From: Margaret Wasserman To: Ralph Droms , Jari Arkko 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, 21 Oct 2010 10:48:17 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sat, 23 Oct 2010 17:21:45 -0700 Cc: ipdir@ietf.org, roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 14:47:15 -0000 Hi Ralph, Jari and others, As a member of the IP directorate, I was encouraged to review draft-ietf-roll-rpl-12.txt. In general, I support the RPL effort, and I think that the IETF should publish the RPL protocol as a standards track RFC. This protocol has already been adopted by a couple of industry standards bodies for inclusion in their "profiles", and it is likely to be widely deployed in the future. However, I have several concerns about approving version -12 of this specification, at this time. Here are my concerns, roughly in descending order of importance: (0) The specification of RPL is, IMO, substantially incomplete without the corresponding specifications from the 6man group: draft-ietf-6man-rpl-option-00.txt and draft-ietf-6man-rpl-routing-header-00. The 6man-rpl-option draft has only recently been adopted by the 6man WG (July 2010), and both 6mand drafts still need more work before they will be ready for publication, IMO. Given that the RPL draft normatively references the 6man drafts, RPL cannot be published as an RFC until the 6man drafts are also approved for publication as RFCs. Since the three drafts are very tightly coupled, I don't think it makes sense to approve the RPL specification now (thus making it difficult to change) before the 6man drafts are also ready for publication. (1) IMO, there are a couple of important technical issues with this specification that should be addressed before it is approved. (a) Section 11.2.2.1 of the document current says: "A RPL router that forwards a packet in the RPL network MUST check if the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL Option contains RPL Packet Information (Figure 32). If not, then the RPL router MUST insert a RPL Option with RPL Packet Information as specified in [I-D.ietf-6man-rpl-option]. If the router is an ingress router that injects the packet into the RPL network, the router MUST set the RPLInstanceID field in the RPL Packet Information. The details of how that router determines the mapping to a RPLInstanceID are out of scope for this specification and left to future specification. "A router that forwards a packet to outside the RPL network MUST remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]." There are at least two significant issues with this description: - When the RPL header is added to the packet, there is no guarantee that there will already be a hop-by-hop options header in the packet. If not, it will need to be inserted, too. Depending on how this is done, it could cause the next header field to change in the IPv6 header, thus invalidating the pseudo-header checksum on packets that are received from outside of the RPL instance and are destined to somewhere inside the RPL instance. - Removing an option from a packet may, depending on how it is done, have similar issues. Could this result in sending an empty hop-by-hop option header? Or would the hop-by-hop header be removed if it is now empty? - Inserting a header into a packet increases the size of the packet, and could result in MTU/fragmentation issues. I realize that the 6man draft talks about tunneling these packets, which would resolve the checksum issues listed above. The MTU/fragmentation issues still apply, though. The 6man draft currently addresses the MTU issues by saying that you should use a link with a high-enough MTU but there are issues with that, as well: (1) 6lowpan, which is the only link type I know of that RPL has been run over to date, has an MTU of 1280, not 1280+++ as required by the 6lowpan spec, and (2) there is no explanation of what RPL routers should do if adding the RPL header results in a packet that won't fit -- presumably send a "packet too big" error, but with what MTU size indicated? At the very least, this section of the RPL draft is incompatible with the 6man draft. Since these options are essential to RPL operation, this is one of the reasons I don't think we should approve this document before the 6man draft is finished -- because we've left some very hard problems for the 6man spec to solve, and I'm not convinced they can be solved without changes to the RPL spec. (b) The draft indicates that a RPL node can forward a packet upwards within a particular DAG, by sending it to a lower- ranked node within that DAG. It also indicates that a particular RPL node may be in more than one DAG. The RPL option doesn't contain a DAG ID... So, I am wondering: So, if RPL Node A, who happens to be in two DAGs (DAG 1 and DAG 2) wants to forward a packet out on to the Internet using the border router for DAG 1, but it can't reach that border router directly, it forwards the packet to a lower-ranked node in DAG 1, right? Let's call this node Node B. What if Node B is _also_ in DAG 1 and DAG 2? How does Node B know that the packet should be forwarded in DAG 1 and not DAG 2? (2) It is my understanding that the Routing area requires multiple interoperable implementations of a specification in order to publish the specification, and I don't think that RPL currently meets that requirement. RPL has two major, non-interoperable operating modes -- storing node and non-storing node, and a lot of functionality that is only applicable in cases where the RPL network is connected to a non-RPL network, or there is more than one active DAG within a single RPL instance. While there are two groups (that I am aware of) who have begun interoperability testing of RPL, it is my understanding that one of those groups last tested version -06 or -07 of the RPL spec, which was quite different from the current version, and that they only tested storing mode. The other group has only tested non-storing mode, and has only tested in a single-DAG environment, with no routing outside the RPL instance. This second group just started testing the -12 version earlier this month, and has not fully tested even the non-storing mode, single DAG functionality. Also, to my knowledge, no information about the coverage or results of this testing is publicly available. (3) There are also a couple of minor technical issues with the specification that should be addressed before it is published. (a) The description of the Pad1 option (section 6.7.2) says both that it is used for inserting one or two octets or padding, and that if more than octet of padding is needed, the PadN option should be used. (b) The description of the RPL option is unclear to me. In section 6.7.1, Figure 19 shows the "RPL Option Generic Format". There are then several types of RPL options describe. However, in section 11.2, Figure 32, there is a RPL option defined that doesn't appear to contain a type. Furthermore, there is a RPL option defined draft-ietf-6man-rpl-option that shows an option with a type (RPL) length, and a set of sub-TLVs. The option in Figure 32 doesn't have a TLV format, and it isn't clear to me whether a single RPL option (as decribed in the 6man draft) can contain many of the RPL options described in the RPL spec, or only one. Am I missing something here? (4) I also wonder why it is necessary to list 10 authors on this specification. I haven't been able to find any justification for why this document should be an exception to the "5 authors or less" rule. In similar cases in the past, WGs have chosen to list no more than a few people as editors on the first page, and to include a list of authors later in the draft in an "Authors" or "Contributors" section, and I think that should probably be done in this case. Thanks, Margaret From margaretw42@gmail.com Sat Oct 23 05:52:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF98B3A68A9; Sat, 23 Oct 2010 05:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 xF1X1+bfhQGS; Sat, 23 Oct 2010 05:52:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9982F3A6866; Sat, 23 Oct 2010 05:52:37 -0700 (PDT) Received: by gya6 with SMTP id 6so1376554gya.31 for ; Sat, 23 Oct 2010 05:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=bSAov16gAg+5JdTDUTCOVbt7LFZ2X4a4Y3L3m/yjmTU=; b=ExiREDj/66AVTqdkAi9kpzIOzhLYdTrLBd0qQtjnYYOuqMGZsGmCFxbSybQXYJtArG yFbEcc+mIzWZxBltgKKxNB4Ur5OhfNDAywPFEJESxbRPeU20RX6CplTiiBAvP7sC3LPJ VEX+Cj3LL9Z7ZYX4k9jBQ53d2dGbYV33LOdU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=IF+sEAoup+3Xta7D19fmEeDlXN0BvWdTgUFMnlKUG7zx97JOC5MvTZhSJULwEJEGiC ZtXmA5pbYX64n/9vbCmRzf1uKKVhkYipvvRL3GhnrKU2axHaQO7olvu3zp62MkgLz88Z pfs6NbZGz38zC5XnlTmBDMutxNtHW05KbTrhA= Received: by 10.42.222.137 with SMTP id ig9mr3235640icb.297.1287838457546; Sat, 23 Oct 2010 05:54:17 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id s26sm1235577vcr.37.2010.10.23.05.54.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Oct 2010 05:54:16 -0700 (PDT) Message-Id: From: Margaret Wasserman To: Jari Arkko In-Reply-To: <4CC129BD.4040004@piuha.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: Sat, 23 Oct 2010 08:54:14 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sat, 23 Oct 2010 17:21:45 -0700 Cc: ipdir@ietf.org, roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 12:52:39 -0000 Hi Jari, You're welcome. Please let me know when the problems I discussed are fixed. Some parts of this draft need some substantial changes, and after they are made, I would like to make sure that the solution they come up with really works WRT MTU/fragmentation issues, checksum-related issues, and fitting into the current IP conceptual model well enough not to violate any basic principles. It isn't possible to do a detailed review at this point, because of the state of the specification now (various conflicting statements between multiple documents). I think someone (and by that I guess I am volunteering myself) should also review the RPL and 6lowpan ND stuff as a whole and understand how it relates to regular ND and whether it will work. I am not sure that the things that RPL says about 6lowpan ND are even true. For instance, I don't think 6lowpan ND provides neighbor unreachability detection, but I could be wrong... There are some ways in which 6lowpan/RPL nodes will be quite different than regular IPv6 nodes, and I think we need to make sure that those differences are both sound technically, and justified by the environmental expectations. I worry that some of the differences may unnecessary. Thanks, Margaret On Oct 22, 2010, at 2:05 AM, Jari Arkko wrote: > Thanks for your review, Margaret. > > Jari > From jari.arkko@piuha.net Thu Oct 21 23:04: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 56B633A6895; Thu, 21 Oct 2010 23:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pvPtzZusapm; Thu, 21 Oct 2010 23:04:14 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DBF3E3A6867; Thu, 21 Oct 2010 23:04:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 378422CC32; Fri, 22 Oct 2010 09:05:50 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcUAivjkMWbL; Fri, 22 Oct 2010 09:05:49 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id ACFCC2CC2F; Fri, 22 Oct 2010 09:05:49 +0300 (EEST) Message-ID: <4CC129BD.4040004@piuha.net> Date: Fri, 22 Oct 2010 09:05:49 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Margaret Wasserman References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Oct 2010 17:21:57 -0700 Cc: ipdir@ietf.org, roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:04:15 -0000 Thanks for your review, Margaret. Jari From cabo@tzi.org Sat Oct 23 23:13: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 8C3663A6830; Sat, 23 Oct 2010 23:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTA2TTN8W4Ba; Sat, 23 Oct 2010 23:13:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 851E43A67BD; Sat, 23 Oct 2010 23:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9O6EPO0019323; Sun, 24 Oct 2010 08:14:25 +0200 (CEST) Received: from [192.168.217.101] (p5489EEAB.dip.t-dialin.net [84.137.238.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E83D7EA; Sun, 24 Oct 2010 08:14:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 24 Oct 2010 08:14:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3052D8C4-5DB3-4230-AE9E-A29129D82B46@tzi.org> References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> To: Margaret Wasserman X-Mailer: Apple Mail (2.1081) Cc: ipdir@ietf.org, Jari Arkko , roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Oct 2010 06:13:12 -0000 Hi Margaret, I also would like to thank you for your thoughtful review; that was very = useful. Picking up on the interaction between 6LoWPAN-ND and RPL: On Oct 23, 2010, at 14:54, Margaret Wasserman wrote: > I think someone (and by that I guess I am volunteering myself) should = also review the RPL and 6lowpan ND stuff as a whole and understand how = it relates to regular ND and whether it will work. =20 While I think we are reasonably covered with respect to the relationship = between 4861 and 6LoWPAN-ND, the interaction between the latter and RPL = is indeed interesting. > For instance, I don't think 6lowpan ND provides neighbor = unreachability detection, but I could be wrong... Actually, the proper support for NUD was one of the considerations that = went into 6LoWPAN-ND's makeover early this year. But still, the mutual = expectations need to be checked. In particular, RPL appears to assume = hosts take part in the routing protocol, and 6LoWPAN-ND supports hosts = that don't. I'd be certainly interested in an effort to look at the = entire system of protocols between 6LoWPAN, 6man, and RPL. Gruesse, Carsten From cabo@tzi.org Sat Oct 23 23:29: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 3A8623A67C3; Sat, 23 Oct 2010 23:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZwV1dCpt72; Sat, 23 Oct 2010 23:29:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E5AED3A67BD; Sat, 23 Oct 2010 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9O6V1Tt025988; Sun, 24 Oct 2010 08:31:01 +0200 (CEST) Received: from [192.168.217.101] (p5489EEAB.dip.t-dialin.net [84.137.238.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D046BEC; Sun, 24 Oct 2010 08:31:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 24 Oct 2010 08:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1081) Cc: ipdir@ietf.org, 6lowpan 6lowpan <6lowpan@ietf.org>, ROLL WG , IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Oct 2010 06:29:29 -0000 On Oct 21, 2010, at 16:48, Margaret Wasserman wrote: [in her RPL review about RPL's various forms of encapsulation:] > (1) 6lowpan, > which is the only link type I know of that RPL has been > run over to date, has an MTU of 1280, not 1280+++ as > required by the 6lowpan spec, (I think you meant 6man/RPL spec at the end.) Indeed. However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we have = to piece L3 packets together out of ~100 byte L2 fragments anyway. The = actual adaptation layer format is fine with any MTU up to 2047; we just = chose the lowest MTU possible*) in IPv6 as a concession for constrained = nodes (and 1280 still is quite heavy for some of them). So it is not unconceivable that 6LoWPAN could help RPL routers by adding = a mode that extends the MTU somewhat. Of course, the details of such an extension would need to be defined, = preferably in conjunction with the rest of the 6man/RPL stack. Gruesse, Carsten *) The assumption was that, as a stub network, a 6LoWPAN would not need = to support tunneling. That assumption may have been wrong. From root@core3.amsl.com Sun Oct 24 13:00: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 DC3A23A68FA; Sun, 24 Oct 2010 13:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101024200002.DC3A23A68FA@core3.amsl.com> Date: Sun, 24 Oct 2010 13:00:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-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: Sun, 24 Oct 2010 20:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-11.txt Pages : 30 Date : 2010-10-24 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-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-routing-metrics-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-24125408.I-D@ietf.org> --NextPart-- From jpv@cisco.com Sun Oct 24 15:45: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 09B6C3A6910 for ; Sun, 24 Oct 2010 15:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItpdfJqQ49D for ; Sun, 24 Oct 2010 15:45:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E96973A6904 for ; Sun, 24 Oct 2010 15:45:31 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI9TxEyrRN+K/2dsb2JhbAChXnGef5s1hUgEhFSFeYMGBg X-IronPort-AV: E=Sophos;i="4.58,233,1286150400"; d="scan'208";a="205904357" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Oct 2010 22:47:15 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9OMlFE2005162 for ; Sun, 24 Oct 2010 22:47:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 15:47:15 -0700 Received: from [10.2.13.0] ([10.21.80.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 15:47:15 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: JP Vasseur In-Reply-To: <11D53CD9-66FA-46A3-99AF-C3D0A3C310A8@cisco.com> Date: Sun, 24 Oct 2010 15:47:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11D53CD9-66FA-46A3-99AF-C3D0A3C310A8@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 24 Oct 2010 22:47:15.0161 (UTC) FILETIME=[67782C90:01CB73CD] Subject: Re: [Roll] Draft Agenda ROLL WG Meeting IETF-79 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Oct 2010 22:45:33 -0000 Agenda confirmed. JP. On Oct 19, 2010, at 9:20 PM, JP Vasseur wrote: > Dear all, >=20 > The draft agenda has been published: = http://www.ietf.org/proceedings/79/agenda/roll.txt >=20 > Let us know if you would like a "slot". >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Oct 24 15:47: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 9A0203A6768 for ; Sun, 24 Oct 2010 15:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRY-yFfbhxAb for ; Sun, 24 Oct 2010 15:47:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 864A73A6452 for ; Sun, 24 Oct 2010 15:47:03 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEGAENUxEyrR7Hu/2dsb2JhbACZcocWVnGedJs1hUgEhFSFeYMGBg X-IronPort-AV: E=Sophos;i="4.58,233,1286150400"; d="scan'208,217";a="609154021" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2010 22:48:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9OMmlO2027750; Sun, 24 Oct 2010 22:48:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 15:48:47 -0700 Received: from [10.2.13.0] ([10.21.80.208]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 15:48:46 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-291-415681161 Date: Sun, 24 Oct 2010 15:48:46 -0700 References: <20101024200002.DC3A23A68FA@core3.amsl.com> To: ROLL WG Message-Id: X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 24 Oct 2010 22:48:46.0676 (UTC) FILETIME=[9E044140:01CB73CD] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-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: Sun, 24 Oct 2010 22:47:04 -0000 --Apple-Mail-291-415681161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, New revision incorporating editorial changes in reply to comments sent = by David before publication request. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 24, 2010 1:00:02 PM PDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-11.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : Routing Metrics used for Path Calculation in = Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-11.txt > Pages : 30 > Date : 2010-10-24 >=20 > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-11.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-291-415681161 Content-Type: multipart/mixed; boundary=Apple-Mail-292-415681162 --Apple-Mail-292-415681162 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

New revision incorporating editorial changes in = reply to comments sent by David before publication = request.

Thanks.

JP.
=

Begin forwarded message:

Date: October 24, 2010 1:00:02 PM PDT
Subject: [Roll] I-D = Action:draft-ietf-roll-routing-metrics-11.txt

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


Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, et = al.
= Filename        : = draft-ietf-roll-routing-metrics-11.txt
Pages =           : = 30
= Date =            : = 2010-10-24

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

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-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.
= --Apple-Mail-292-415681162 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain<BR>Content-ID: &lt;2010-10-24125408.I-D@ietf.org&gt;<BR><BR> --Apple-Mail-292-415681162 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-292-415681162-- --Apple-Mail-291-415681161-- From margaretw42@gmail.com Sun Oct 24 18:59: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 74BBE3A6934; Sun, 24 Oct 2010 18:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 NJWh2n0Ox5sK; Sun, 24 Oct 2010 18:59:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 34ADE3A6935; Sun, 24 Oct 2010 18:59:29 -0700 (PDT) Received: by ywp6 with SMTP id 6so1244109ywp.31 for ; Sun, 24 Oct 2010 19:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=tyrndKaqGYGRts6ApsxbvlsmDBUHyCE08OuCRo0F6EE=; b=eLCM/8pgM5SJHX4zimcMlPAovdLde0j4ilnAVbars+m5HsIboYJa+oGeNSZx4zx6ON ggLnQCUvGGOWuQ4pmNmbPwbFwuGoeycMIxZnFXHP/11oDDqEe/8pS0o/9P5ulPlLoF2n 09PSrXXfh/ilqpZXgjaS1iR/3tiS/Hnk3w/WM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=eVdAFEDxGOdMSHqETX8buv2Po4yHr122CeweNfKYYKoRw+nVNiwWwion7+4TyF0Kso 411k79p5vqMHdXGEIu585PNOpwJSFRGvYyhY9eLIWjG0Fz+4LOhxxo6tO8hlSO8t9XNm qlnH0iMd/lNnEMJkjJ6qP6hPn4L4uFC+5YWBM= Received: by 10.42.11.69 with SMTP id t5mr4177716ict.405.1287972072769; Sun, 24 Oct 2010 19:01:12 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id y21sm2933411vbx.6.2010.10.24.19.01.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 19:01:11 -0700 (PDT) Message-Id: <7A05FAEA-5B96-40D3-84B7-537FE8E00313@gmail.com> From: Margaret Wasserman To: Carsten Bormann 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: Sun, 24 Oct 2010 22:01:09 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sun, 24 Oct 2010 23:26:21 -0700 Cc: ipdir@ietf.org, 6lowpan 6lowpan <6lowpan@ietf.org>, ROLL WG , IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 01:59:30 -0000 On Oct 24, 2010, at 2:30 AM, Carsten Bormann wrote: > On Oct 21, 2010, at 16:48, Margaret Wasserman wrote: > [in her RPL review about RPL's various forms of encapsulation:] > >> (1) 6lowpan, >> which is the only link type I know of that RPL has been >> run over to date, has an MTU of 1280, not 1280+++ as >> required by the 6lowpan spec, > > (I think you meant 6man/RPL spec at the end.) Yes, I did. The 6man/RPL spec says it will only work on networks that have an MTO of 1280+40-something+128+something unspecified. And, 6lowpan currently specifies an MTU of 1280 (which is fine). > However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we > have to piece L3 packets together out of ~100 byte L2 fragments > anyway. The actual adaptation layer format is fine with any MTU up > to 2047; we just chose the lowest MTU possible*) in IPv6 as a > concession for constrained nodes (and 1280 still is quite heavy for > some of them). Even if the number _were_ 2047, you would still need to do something special with the MTU to make this work. For instance the tunnel encapsulator (in this case the border router) would want to present a lower MTU (presumably 1280) for this network on interfaces outside the RPL instance, while presenting the full size MTU on internal interfaces. This isn't a huge technical problem to resolve, but the expected behaviour would need to be properly specified, IMO. > So it is not unconceivable that 6LoWPAN could help RPL routers by > adding a mode that extends the MTU somewhat. > Of course, the details of such an extension would need to be > defined, preferably in conjunction with the rest of the 6man/RPL > stack. Exactly. Thanks for the feedback! Margaret From margaretw42@gmail.com Sun Oct 24 19:03: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 3BAA83A692B; Sun, 24 Oct 2010 19:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ph8MyKitqHHh; Sun, 24 Oct 2010 19:03:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 00C463A63D3; Sun, 24 Oct 2010 19:03:46 -0700 (PDT) Received: by yxp4 with SMTP id 4so1970668yxp.31 for ; Sun, 24 Oct 2010 19:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=XZ8giiOza3z+5avkCj3DnSDlZIBoTiLS4qJIEnc+1Uo=; b=UbfTSmn+GwUbCiyp0vHbd2+D4GdoVwGwubvPaPBWglV+GrJD0tnBvXBPcc1Ne5PW96 /kO/Q0EulurGQ/guMMlXVQY4LmdL83tKZvtXsIxcPcDsEXP/iG37HlDrU23vc8R9iRwn NmHECxSrxGRraFmpW6LG5BjBXfb75LJAJolqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=AISHdmUJuoHU6c9nNQoltMMWeZNcrSagw2wbbkgAQeuWZaIvsIW55LRVyfUwBZJ1mn Nqtc5hfo+aeSr+LgpGZMQYkkDTCbM0CfbA4ukmz9H5CpqXmhg2OdqAbvli2d706KTrJh T3tP+QdnTBcrPZXfarRpY0ZfbEvyfNqPv9m2E= Received: by 10.150.216.5 with SMTP id o5mr12232386ybg.37.1287972330715; Sun, 24 Oct 2010 19:05:30 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id s12sm2935046vbp.14.2010.10.24.19.05.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 19:05:30 -0700 (PDT) Message-Id: <079A50A9-9A3E-417D-8BA1-CBD81116E551@gmail.com> From: Margaret Wasserman To: Carsten Bormann In-Reply-To: <3052D8C4-5DB3-4230-AE9E-A29129D82B46@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 24 Oct 2010 22:05:28 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <3052D8C4-5DB3-4230-AE9E-A29129D82B46@tzi.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sun, 24 Oct 2010 23:26:21 -0700 Cc: ipdir@ietf.org, Jari Arkko , roll@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 02:03:48 -0000 On Oct 24, 2010, at 2:14 AM, Carsten Bormann wrote: >> I think someone (and by that I guess I am volunteering myself) >> should also review the RPL and 6lowpan ND stuff as a whole and >> understand how it relates to regular ND and whether it will work. > > While I think we are reasonably covered with respect to the > relationship between 4861 and 6LoWPAN-ND, the interaction between > the latter and RPL is indeed interesting. I'm not saying that I know of any specific problems in this area, but I'd like to make sure we do a good cross-document review of ND will work in the RPL/6lowpan environment, in addition to how RPL itself works, before the RPL documents are published as RFCs. Given their interdependence, it probably makes sense to review the model now and make sure we understand how it will work before approving any of the documents. > >> For instance, I don't think 6lowpan ND provides neighbor >> unreachability detection, but I could be wrong... > > Actually, the proper support for NUD was one of the considerations > that went into 6LoWPAN-ND's makeover early this year. But still, > the mutual expectations need to be checked. In particular, RPL > appears to assume hosts take part in the routing protocol, and > 6LoWPAN-ND supports hosts that don't. I'd be certainly interested > in an effort to look at the entire system of protocols between > 6LoWPAN, 6man, and RPL. Thanks for the correction. There have been enough changes in this area (6lowpan and RPL) over he past year that, even though I am working on a product that implements these specs, I have had trouble keeping up. Margaret From jpv@cisco.com Sun Oct 24 23:29: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 AD2F73A6956; Sun, 24 Oct 2010 23:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.812 X-Spam-Level: X-Spam-Status: No, score=-110.812 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpEyLZX+EaJi; Sun, 24 Oct 2010 23:29:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E8053A6936; Sun, 24 Oct 2010 23:29:29 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD7BxEyrRN+J/2dsb2JhbAChXXGfC5tPhUgEhFSFeYMGBg X-IronPort-AV: E=Sophos;i="4.58,235,1286150400"; d="scan'208";a="609243269" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2010 06:31:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9P6VD4Q011925; Mon, 25 Oct 2010 06:31:13 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 23:31:13 -0700 Received: from [10.2.13.0] ([10.21.70.123]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 23:31:12 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <079A50A9-9A3E-417D-8BA1-CBD81116E551@gmail.com> Date: Sun, 24 Oct 2010 23:31:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <959DBF5C-C20D-43B5-8F71-6B67CE902ED3@cisco.com> References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <3052D8C4-5DB3-4230-AE9E-A29129D82B46@tzi.org> <079A50A9-9A3E-417D-8BA1-CBD81116E551@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 25 Oct 2010 06:31:12.0951 (UTC) FILETIME=[3815D470:01CB740E] Cc: roll@ietf.org, Jari Arkko , ipdir@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:29:32 -0000 On Oct 24, 2010, at 7:05 PM, Margaret Wasserman wrote: >=20 > On Oct 24, 2010, at 2:14 AM, Carsten Bormann wrote: >>> I think someone (and by that I guess I am volunteering myself) = should also review the RPL and 6lowpan ND stuff as a whole and = understand how it relates to regular ND and whether it will work. >>=20 >> While I think we are reasonably covered with respect to the = relationship between 4861 and 6LoWPAN-ND, the interaction between the = latter and RPL is indeed interesting. >=20 > I'm not saying that I know of any specific problems in this area, but = I'd like to make sure we do a good cross-document review of ND will work = in the RPL/6lowpan environment, in addition to how RPL itself works, = before the RPL documents are published as RFCs. Given their = interdependence, Let me just make sure that this point is clear though. There is no = dependence between 6lowpan and RPL. It turns out that several 6lowpan networks (in particular HC) will use of RPL but = there are also several other networks without=20 6lowpan at all, and we need to make sure that this is no dependency at = all. > it probably makes sense to review the model now and make sure we = understand how it will work before approving any of the documents. >=20 >>=20 >>> For instance, I don't think 6lowpan ND provides neighbor = unreachability detection, but I could be wrong... >>=20 >> Actually, the proper support for NUD was one of the considerations = that went into 6LoWPAN-ND's makeover early this year. But still, the = mutual expectations need to be checked. In particular, RPL appears to = assume hosts take part in the routing protocol, and 6LoWPAN-ND supports = hosts that don't. I'd be certainly interested in an effort to look at = the entire system of protocols between 6LoWPAN, 6man, and RPL. >=20 > Thanks for the correction. There have been enough changes in this = area (6lowpan and RPL) over he past year that, even though I am working = on a product that implements these specs, I have had trouble keeping up. >=20 > Margaret >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From margaretw42@gmail.com Mon Oct 25 09:11: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 C54B83A6AA2; Mon, 25 Oct 2010 09:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 8n2eHZC8Q-kr; Mon, 25 Oct 2010 09:11:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B339A3A6AA9; Mon, 25 Oct 2010 09:10:30 -0700 (PDT) Received: by wyb28 with SMTP id 28so3492221wyb.31 for ; Mon, 25 Oct 2010 09:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=n0C3vbmePbleR8rUd0jd3ZVgmuzPFmqFYV245RgJWoM=; b=lu/1h76hNybJ4rE06DXJFhR0xVdxyFHvp996uhztrSm23JhmjMLXiX9WaB/qJEzV6o TgS6Vm/Tohmo4U9tWUEJrHeTdp8rwJTzsgcNMbsXGdpIAyk2cOzc5+sNhoJiS1BLRbNa YCyt1gxcF1dIO4/bih0bE8wqW2fWwo1tM9DkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=hKrXfomNynECSAhgQ5QLBoxHh9OpNHYl4sCzmn/IaKl53Qq2XwvaICIOJvm/Li791i YUfE21QIFxCK6tuORD2FFUAwBu6gM3VmNgQSuhqLiMPgdVSu2Agh+EosfWXdMtVs2K5t IUCdhhsZM9iWIEblyYJi104tQjVdsTOUefgfk= Received: by 10.216.185.203 with SMTP id u53mr2797213wem.86.1288023125731; Mon, 25 Oct 2010 09:12:05 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id o17sm3259029vbi.12.2010.10.25.09.12.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 09:12:04 -0700 (PDT) Message-Id: From: Margaret Wasserman To: JP Vasseur In-Reply-To: <959DBF5C-C20D-43B5-8F71-6B67CE902ED3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Oct 2010 12:12:02 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <3052D8C4-5DB3-4230-AE9E-A29129D82B46@tzi.org> <079A50A9-9A3E-417D-8BA1-CBD81116E551@gmail.com> <959DBF5C-C20D-43B5-8F71-6B67CE902ED3@cisco.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org, Jari Arkko , ipdir@ietf.org, IESG IESG Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 16:11:19 -0000 On Oct 25, 2010, at 2:31 AM, JP Vasseur wrote: > Let me just make sure that this point is clear though. There is no > dependence between 6lowpan and RPL. It turns out > that several 6lowpan networks (in particular HC) will use of RPL but > there are also several other networks without > 6lowpan at all, and we need to make sure that this is no dependency > at all. Good point. We do need to make sure, though, that RPLs use of ND is consistent both with "generic" IPv6 ND and 6lowpan ND, though, right? In my opinion, we should also do a full review of the RPL drafts and the 2 or 3 related 6man drafts, once they have been updated to be more consistent, to make sure that the whole system is properly specified and will function properly (as far as we can tell). BTW, I am not trying/expecting to hold up the publication of RPL as an RFC by suggesting that we do a review of the full set of circularly referenced documents (RPL and the 2 or 3 related 6man drafts) for consistency/correctness before the IESG approves any of them. RPL can't be published as an RFC until all of the documents it normatively references are approved for publication, anyway. Margaret From trac@tools.ietf.org Mon Oct 25 15:08: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 471B83A67B1 for ; Mon, 25 Oct 2010 15:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 rxkrCAQk1qQg for ; Mon, 25 Oct 2010 15:08:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7C36F3A67AD for ; Mon, 25 Oct 2010 15:08:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PAVF1-0004P6-6G; Mon, 25 Oct 2010 15:10:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 25 Oct 2010 22:10:06 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/78#comment:1 Message-ID: <064.3103422b8f30b0e289aaa2eae2a454ba@tools.ietf.org> References: <055.56dba789f46f1dc24b6ca59bb855f138@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <055.56dba789f46f1dc24b6ca59bb855f138@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] security-framework #78 (closed): Comments from R. Struik during WG LC of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:08:22 -0000 #78: Comments from R. Struik during WG LC of draft-ietf-roll-security-framework Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Email from Rene Struik on October 25: Dear colleagues: I reviewed how draft-ietf-roll-security-framework-01 addressed my comments on the previous draft (please see below). Based on this review, I have no problems closing the outstanding ticket and moving this draft forward. More specifically, I will leave it to the authors to consider whether they feel they wish to still change text. I am in favor of moving this forward, so will not comment if they decide not to make further changes. I would update the two references though (cf. below). My apologies for having had this on the backburner for a little while. Best regards, Rene -- --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: tzeta.tsao@… Type: defect | Status: closed Priority: major | Milestone: Component: security-framework | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: roll From prvs=9072122f1=mukul@uwm.edu Mon Oct 25 15:08: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 F1AA03A6887 for ; Mon, 25 Oct 2010 15:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 PCXdMb7Kb7fc for ; Mon, 25 Oct 2010 15:08:52 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 939C93A680F for ; Mon, 25 Oct 2010 15:08:52 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 25 Oct 2010 17:10:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7C6AD2B3F05; Mon, 25 Oct 2010 17:09:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKQbg-QLWdtU; Mon, 25 Oct 2010 17:09:27 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 1E0942B3F06; Mon, 25 Oct 2010 17:09:27 -0500 (CDT) Date: Mon, 25 Oct 2010 17:10:37 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <2093922521.800520.1288044637827.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20101025220113.67E6F3A6B27@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: charliep Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-p2p-rpl-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:08:54 -0000 This version is just a refresh. Thanks Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Monday, October 25, 2010 5:01:12 PM Subject: New Version Notification for draft-ietf-roll-p2p-rpl-01 A new version of I-D, draft-ietf-roll-p2p-rpl-01.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-ietf-roll-p2p-rpl Revision: 01 Title: Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Creation_date: 2010-10-26 WG ID: roll Number_of_pages: 22 Abstract: Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria. The IETF Secretariat. From root@core3.amsl.com Mon Oct 25 15:15:23 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 5F0A43A68A2; Mon, 25 Oct 2010 15:15:22 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025221523.5F0A43A68A2@core3.amsl.com> Date: Mon, 25 Oct 2010 15:15:23 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-p2p-rpl-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:15:23 -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 : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : M. Goyal, E. Baccelli Filename : draft-ietf-roll-p2p-rpl-01.txt Pages : 22 Date : 2010-10-25 Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-01.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-p2p-rpl-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25150112.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 15:15:36 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 DAF423A6899; Mon, 25 Oct 2010 15:15:23 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025221534.DAF423A6899@core3.amsl.com> Date: Mon, 25 Oct 2010 15:15:23 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-14.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:15:36 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-14.txt Pages : 141 Date : 2010-10-25 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25150954.I-D@ietf.org> --NextPart-- From wintert@acm.org Mon Oct 25 15:20: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 200CA3A6959 for ; Mon, 25 Oct 2010 15:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coLqcUIa5-c1 for ; Mon, 25 Oct 2010 15:20:51 -0700 (PDT) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id 9D7C03A68E0 for ; Mon, 25 Oct 2010 15:20:51 -0700 (PDT) Received: (qmail 81323 invoked from network); 25 Oct 2010 22:22:34 -0000 Received: from [10.56.17.102] (wintert@71.178.253.216 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 25 Oct 2010 15:22:34 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: eUNJDQwVM1naePpidifFq9ygbcSYjxC2fjm4nVS0PhE55eQ 6JbOS0NWNhpxK3gDYIEnZ4ofRTkyz7pHbE.mAJS0NNL4HWIttLP1QWfxdUhT ymIDqEOr9UeS3hpDBNG2AgCcfa8Vdh5ag0EExgOKw8naDUBPG2y3LsHR4Hss 4wGti4ZfaOlONM1lhOgyUEzzkHtW.p9UFgiybZS32YzfOkp.yncLELVbbUjd BgH.kANTbFI3DWfLoBG3peWjXVU6aqcC1FyUdo2RHxXSRIoXEM3zMxmPlMdy Pm69z18DEPqCY6nPOafleP_R9CUWNNqxw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC6032A.4000005@acm.org> Date: Mon, 25 Oct 2010 18:22:34 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: roll@ietf.org References: <20101025221534.DAF423A6899@core3.amsl.com> In-Reply-To: <20101025221534.DAF423A6899@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-14.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:20:53 -0000 WG, This version (as well as the prior version RPL-13) incorporates changes to address concerns brought up in IESG evaluation (https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/)) Regards, -Tim On 10/25/2010 06:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-14.txt > Pages : 141 > Date : 2010-10-25 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-14.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=9072122f1=mukul@uwm.edu Mon Oct 25 15:28: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 7F54D3A6A1C for ; Mon, 25 Oct 2010 15:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 sl39tofylDy1 for ; Mon, 25 Oct 2010 15:28:30 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 9232A3A68E8 for ; Mon, 25 Oct 2010 15:28:30 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip2mta.uwm.edu with ESMTP; 25 Oct 2010 17:30:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 722941FD03B; Mon, 25 Oct 2010 17:30:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLdxAwL0NFzQ; Mon, 25 Oct 2010 17:30:16 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 090BB1FD039; Mon, 25 Oct 2010 17:30:16 -0500 (CDT) Date: Mon, 25 Oct 2010 17:30:16 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <596323754.801272.1288045815965.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20101025222656.0884E3A68E8@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: charliep Subject: [Roll] Fwd: New Version Notification for draft-goyal-roll-p2p-measurement-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:28:31 -0000 Just a refresh. Thanks Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Monday, October 25, 2010 5:26:55 PM Subject: New Version Notification for draft-goyal-roll-p2p-measurement-01 A new version of I-D, draft-goyal-roll-p2p-measurement-01.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-p2p-measurement Revision: 01 Title: A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Creation_date: 2010-10-26 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document specifies a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node in a low power and lossy network, thereby allowing the node to decide if it wants to initiate the discovery of a more optimal route. The IETF Secretariat. From pierre.colle@fr.schneider-electric.com Mon Oct 25 19:04: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 831533A691B for ; Mon, 25 Oct 2010 19:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI027TNofykn for ; Mon, 25 Oct 2010 19:04:25 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id 76F183A68A8 for ; Mon, 25 Oct 2010 19:04:25 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2010102603481541-1045 ; Tue, 26 Oct 2010 03:48:15 +0200 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Tue, 26 Oct 2010 04:06:07 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 26/10/2010 04:06:06, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 26/10/2010 03:48:15, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 26/10/2010 03:48:16, Serialize complete at 26/10/2010 03:48:16 Content-type: multipart/alternative; Boundary="0__=4EBBFD5BDF980D4D8f9e8a93df938690918c4EBBFD5BDF980D4D" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 02:04:26 -0000 --0__=4EBBFD5BDF980D4D8f9e8a93df938690918c4EBBFD5BDF980D4D Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 25/10/2010 de retour le 02/11/2010. I am currently out of office. Best regards, Pierre = --0__=4EBBFD5BDF980D4D8f9e8a93df938690918c4EBBFD5BDF980D4D Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 25/10/2010 de retour le 02/11/201= 0.

I am currently out of office.

Best regards,

Pierre

= --0__=4EBBFD5BDF980D4D8f9e8a93df938690918c4EBBFD5BDF980D4D-- From abr@sdesigns.dk Mon Oct 25 23:24: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 61B343A6819 for ; Mon, 25 Oct 2010 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=1.330, 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 6MbjgLYxS26p for ; Mon, 25 Oct 2010 23:24:19 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 2D0033A67F1 for ; Mon, 25 Oct 2010 23:24:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 08:26:04 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4C1@zensys17.zensys.local> In-Reply-To: <596323754.801272.1288045815965.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-goyal-roll-p2p-measurement-01 Thread-Index: Act0lDPifFuDSRmZScCovlhkUKlLFQAQi5Cw References: <20101025222656.0884E3A68E8@core3.amsl.com> <596323754.801272.1288045815965.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "roll" Cc: charliep Subject: Re: [Roll] New Version Notification fordraft-goyal-roll-p2p-measurement-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: Tue, 26 Oct 2010 06:24:20 -0000 Great, Mukul I intend to read it before end of this week. Please let me and Emmanuel know if you have any particular details we should focus on in Beijing. Who else is attending the Beijing meeting? Cheers, Anders -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu]=20 Sent: 26. oktober 2010 00:30 To: roll Cc: Emmanuel Baccelli; Jerald P Martocci; Anders Brandt; robert cragie; charliep Subject: Fwd: New Version Notification fordraft-goyal-roll-p2p-measurement-01 Just a refresh. Thanks Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Monday, October 25, 2010 5:26:55 PM Subject: New Version Notification for draft-goyal-roll-p2p-measurement-01=20 A new version of I-D, draft-goyal-roll-p2p-measurement-01.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-p2p-measurement Revision: 01 Title: A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Creation_date: 2010-10-26 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document specifies a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node in a low power and lossy network, thereby allowing the node to decide if it wants to initiate the discovery of a more optimal route. =20 The IETF Secretariat. From samitac@ipinfusion.com Mon Oct 25 23:44:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935C13A68E6 for ; Mon, 25 Oct 2010 23:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EffdyaU82UpL for ; Mon, 25 Oct 2010 23:44:00 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by core3.amsl.com (Postfix) with SMTP id 6C7A53A67F1 for ; Mon, 25 Oct 2010 23:44:00 -0700 (PDT) Received: from [98.138.90.51] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 06:45:44 -0000 Received: from [98.138.87.12] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 06:45:44 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 06:45:44 -0000 X-Yahoo-Newman-Id: 153491.38789.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 80315 invoked from network); 26 Oct 2010 06:45:44 -0000 Received: from samitacD630 (samitac@71.141.114.242 with login) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 25 Oct 2010 23:45:43 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 19Ak2MQVM1n3IMYgy5TUHP_FOOgnf84XWx9O7u80VZNW_6d z.JaFpWgeS1s9kJ1WwjC3JciuQAMUou7ABbRMtnO3Lznn0lzyymvPlBHqNyY ggRMSCxQCSjHYu1Ew64si00xI50uznNIP9xQU1XTByHbTxrH5ByrJnrExfXz 4Sjqs4m6uhNrcs8sy.pe_QgBReuoSCgSkdCALW8HnMrvglc3gEghVqqV0uyc _PnD5CoLwJmO5fzKt0JqpQ9PPD05QvDsWHhstmSCRI.6sAYq.ibFQUotHvnu BSVBxpzOBrw-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Margaret Wasserman'" , "'Jari Arkko'" References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> In-Reply-To: Date: Mon, 25 Oct 2010 23:45:41 -0700 Message-ID: <101401cb74d9$6911ca90$3b355fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActzEUBD9sihXlhQTx6/Mg5FyhYEnABxH3KQ Content-Language: en-us Cc: ipdir@ietf.org, roll@ietf.org, 'IESG IESG' Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:44:01 -0000 Hi Margaret, Thanks for the comments. Here are a few things regarding 6lowpan-nd NUD. > 6lowpan ND provides neighbor unreachability detection, but I could be > wrong... [SC>] 6lowpan-nd hosts do perform NUD through registration and refreshing the registration. NUD can be implicitly performed by data communication using upper layer protocols as suggested in rfc 4861. And when a node wakes up from sleep, it does NUD in order to make sure its default router is still reachable. The routers (6LR and 6LBR) also perform NUD on hosts for unreachability detection. [ section 6 of http://www.ietf.org/id/draft-ietf-6lowpan-nd-14.txt] > > There are some ways in which 6lowpan/RPL nodes will be quite different than regular IPv6 nodes [SC>] In regular IPv6, there is a router and a host - in 6lowpan-nd, there is a third entity which is 6LR. [SC>] One major difference between 6lowpan and RPL LLN are that RPL assumes that all nodes are routers/forwarders while 6lowpan-nd assumes the network is composed of hosts and routers. 6lowpan-nd assumes that the 6LRs first come up as hosts during the startup and are capable of registering themselves with their neighboring routers and autoconfiguring addresses before turning themselves into routers when a routing protocol is run on them. 6lowpan-nd also expects that the 6LR will inject neighbor attachment/detachment information into the routing protocol. Similarly, it assumes that the routing protocol is capable of deleting an NCE should it finds out that one of its registered node has moved away without de-registering. Also 6lowpan-nd is not dependent on any particular routing protocol running on the router. Hope it clarifies a little bit. We are working on some more cleanup/polishing on the ND document for clarity. -Samita From margaretw42@gmail.com Tue Oct 26 11:06: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 D61A03A6965; Tue, 26 Oct 2010 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-XOcjElJ8Wj; Tue, 26 Oct 2010 11:06:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 595023A68EC; Tue, 26 Oct 2010 11:06:12 -0700 (PDT) Received: by pwi6 with SMTP id 6so996292pwi.31 for ; Tue, 26 Oct 2010 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=IOzFI1H+/zcfgK0uyJZkeJAABdEzlESgitx87gER7ko=; b=p/slEdDTgYjyE/8n41wgC9D7YGYetrJOpwjmSPhQtq/3u0gfIEXdfwJ8ZKv3xqpFnq iheZkzCptbVcsE4KOBtlTy8P+KZ2rj3mktC1tfPgnu3QZ+uddYcQF7LW0UG08bQKAGmx k9sY+KjM+VRUJ7/iMfwpD+ia/Qekf3E9EjC9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=YDQQb50eELhrNDUkUuJqk6aFxdzc6iF7uHHU4FGPV2xinViXowQi+ZRNjYh6ydy6NG gMtHdxRlCc3IUYYeDQpsFFiSpRkztAHmfLJZ+t6dPQB6cL2xuT+HsDKKiDTeMBgaUglR 3GKuJ3OGve9SK7AKuDkRqLyezrzGFUzi7sMHo= Received: by 10.42.166.197 with SMTP id p5mr822100icy.162.1288116479626; Tue, 26 Oct 2010 11:07:59 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id y21sm3989861vbx.16.2010.10.26.11.07.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Oct 2010 11:07:57 -0700 (PDT) Message-Id: From: Margaret Wasserman To: Samita Chakrabarti In-Reply-To: <101401cb74d9$6911ca90$3b355fb0$@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 Oct 2010 14:07:56 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <101401cb74d9$6911ca90$3b355fb0$@com> X-Mailer: Apple Mail (2.936) Cc: ipdir@ietf.org, 'Jari Arkko' , roll@ietf.org, 'IESG IESG' Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 18:06:18 -0000 Hi Samita, On Oct 26, 2010, at 2:45 AM, Samita Chakrabarti wrote: > Hope it clarifies a little bit. We are working on some more > cleanup/polishing on the ND document for clarity. Thanks for the explanation. It definitely helped. I'm still trying to figure out a model in my head for how all of these things fit together... Margaret From alexandru.petrescu@gmail.com Tue Oct 26 23:33: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 1E9233A67F6 for ; Tue, 26 Oct 2010 23:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, 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 JhLOQk61HSIY for ; Tue, 26 Oct 2010 23:33:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 6670F3A67D1 for ; Tue, 26 Oct 2010 23:33:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o9R6Z0xQ019062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Oct 2010 08:35:01 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o9R6Z0gG019020 for ; Wed, 27 Oct 2010 08:35:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o9R6Z0I7021335 for ; Wed, 27 Oct 2010 08:35:00 +0200 Message-ID: <4CC7C814.5080900@gmail.com> Date: Wed, 27 Oct 2010 08:35:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: roll@ietf.org References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <101401cb74d9$6911ca90$3b355fb0$@com> In-Reply-To: <101401cb74d9$6911ca90$3b355fb0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 06:33:17 -0000 Le 26/10/2010 08:45, Samita Chakrabarti a crit : [discussion around RPL and 6LoWPAN] > [SC>] One major difference between 6lowpan and RPL LLN are that RPL > assumes that all nodes are routers/forwarders while 6lowpan-nd > assumes the network is composed of hosts and routers. I have a humble opinion on this topic. In RPL, the assumption that a node is an IP router/forwarder with a single interface and a unique subnet prefix - is very hard to grasp conceptually to me. I am afraid there may be a big misunderstanding and may stem from a misunderstanding of the underlying link layer. One such misunderstanding is the common assumption that a single-interfaced machine forwarding a packet will not disturb the originator. This may lead to trying to solve imaginary link layer problems with IP forwarding. This problem is not new. I have seen it with 802.11s mesh ancestors to run RIP at link layer. This one-interface-forwarder work may signify inspiration to some one-interface link layer designs, but it is pointless to IP. Finally, only if we talk multiple interfaces on a router/forwarder, eventually of different types, and multiple subnet prefixes, then the problem becomes relevant to IP routing. Unfortunately RPL makes no distinction between these two situations. IMHO, Alex > 6lowpan-nd assumes that the 6LRs first come up as hosts during the > startup and are capable of registering themselves with their > neighboring routers and autoconfiguring addresses before turning > themselves into routers when a routing protocol is run on them. > 6lowpan-nd also expects that the 6LR will inject neighbor > attachment/detachment information into the routing protocol. > Similarly, it assumes that the routing protocol is capable of > deleting an NCE should it finds out that one of its registered node > has moved away without de-registering. Also 6lowpan-nd is not > dependent on any particular routing protocol running on the router. > > Hope it clarifies a little bit. We are working on some more > cleanup/polishing on the ND document for clarity. > > -Samita > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Wed Oct 27 02:06:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2803A69BA for ; Wed, 27 Oct 2010 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzVWW5J1LdX4 for ; Wed, 27 Oct 2010 02:06:04 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E33AA3A67E1 for ; Wed, 27 Oct 2010 02:06:04 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+Hx0yrR7Hu/2dsb2JhbAChWHGgZ5wXhUgEilODCAY X-IronPort-AV: E=Sophos;i="4.58,245,1286150400"; d="scan'208";a="276452935" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2010 09:07:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9R97iOA006547 for ; Wed, 27 Oct 2010 09:07:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 02:07:43 -0700 Received: from [172.16.0.147] ([10.21.146.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 02:07:43 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Oct 2010 05:07:43 -0400 Message-Id: <9743589B-3C8C-4108-8DED-32612FC1B61D@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 27 Oct 2010 09:07:43.0755 (UTC) FILETIME=[6A444DB0:01CB75B6] Subject: [Roll] Final Agenda has been updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 09:06:06 -0000 http://www.ietf.org/proceedings/79/agenda/roll.txt From qiuying@i2r.a-star.edu.sg Wed Oct 27 03:17: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 A5F193A685B; Wed, 27 Oct 2010 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 0Uf-HpQuVnVv; Wed, 27 Oct 2010 03:17:08 -0700 (PDT) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by core3.amsl.com (Postfix) with ESMTP id 7492A3A68F8; Wed, 27 Oct 2010 03:17:07 -0700 (PDT) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw2.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id o9RAIsqJ021701; Wed, 27 Oct 2010 18:18:54 +0800 Received: from Win7PC ([10.217.141.168]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 18:18:29 +0800 From: "QIU Ying" To: <6lowpan@ietf.org>, Date: Wed, 27 Oct 2010 18:22:06 +0800 Message-ID: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act0kywnvyKnr3RISNmn4NNwF0XxWQBKoFfw Content-Language: en-sg X-OriginalArrivalTime: 27 Oct 2010 10:18:29.0498 (UTC) FILETIME=[4CED45A0:01CB75C0] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-27_04:2010-10-27, 2010-10-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=55 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010270026 Subject: [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-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: Wed, 27 Oct 2010 10:17:10 -0000 http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt The title of the draft had been changed to "Lightweight Key Establishment a= nd Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Light= weight Secure Router Protocol" in order to make the work more clearly. It w= ill be presented at ROLL WG. Any comments are appreciated. Regards QIU Ying -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, October 26, 2010 6:22 AM To: qiuying@i2r.a-star.edu.sg Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01=20 A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been succe= ssfully submitted by QIU Ying and posted to the IETF repository. Filename: draft-qiu-6lowpan-secure-router Revision: 01 Title: Lightweight Key Establishment and Management Protocol in Dymanmic = Sensor Networks (KEMP) Creation_date: 2010-10-26 WG ID: Independent Submission Number_of_pages: 17 Abstract: When a sensor node roams within a very large and distributed wireless sensor network, which consists of numerous sensor nodes, its routing path and neighborhood keep changing. In order to provide a high level of security in this environment, the moving sensor node needs to be authenticated to new neighboring nodes as well as to establish a key for secure communication. The document proposes an efficient and scalable protocol to establish and update the secure key in a dynamic wireless sensor network environment. The protocol guarantees that two sensor nodes share at least one key with probability 1 (100%) with less memory and energy cost, while not causing considerable communication overhead. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The IETF Secretariat. Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t and notify us immediately. Please do not copy or use it for any purpose, = or disclose its contents to any other person. Thank you." From rstruik.ext@gmail.com Wed Oct 27 06:16: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 428BD3A6A18; Wed, 27 Oct 2010 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-0.391, 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 A1WQMO7er+dg; Wed, 27 Oct 2010 06:16:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E0DE63A67FB; Wed, 27 Oct 2010 06:16:11 -0700 (PDT) Received: by gxk7 with SMTP id 7so378071gxk.31 for ; Wed, 27 Oct 2010 06:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NL2ukcfgO2YvsdZ4ZXPmg9eh3DphVq9nXi7QXrO+uNw=; b=H1jP/EsRnCD33sxwx8Ph96DoqxxY2JW7gvh7O2YhWrUEfPd7l7rv4Ofn/yEcrfg57V 000XdLTMlb32HOyXHS8gBMCIqO1zEmIBa/2k200SJ75x27OZQbRx2yUTTpjD6OfFiXMd ZBw4r/GK49NujYNpi2SzUfa+brwsDklnJ3d8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qLWX/v6th+jYlm6pReBshDsoObRT9zVWPUawDHMvz/KeBwVMcTjeyJcpV6XJXjWCND 2xlY62Jjdx3pvb9S43rKu7B6bVl+8x7LlhTjLJSxL8seTA2U3DW/H1IgW5ctU3sGgTYS Fjr+jYiIRTVnhEZRlkKtXMb+kme3l3I6vbpBw= Received: by 10.42.219.69 with SMTP id ht5mr7954983icb.354.1288185481146; Wed, 27 Oct 2010 06:18:01 -0700 (PDT) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id fs21sm4500436vbb.0.2010.10.27.06.18.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 06:18:00 -0700 (PDT) Message-ID: <4CC82682.4070003@gmail.com> Date: Wed, 27 Oct 2010 09:17:54 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: QIU Ying References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> In-Reply-To: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-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: Wed, 27 Oct 2010 13:16:15 -0000 Hi Qiu: Thanks for your draft. Your draft seems to suggest a single trust domain, where each node shares a secret key with the base station. What about the scenario where one has multiple trust domains (e.g., when one procures sensors from different vendors)? Doesn't the security fall apart if a router gets compromised? What prevents an adversary from replaying past (sensor node, request) pairs and triggering traffic flows and key updates with routers this way? Do you have a paper that provides a more formal analysis of the security properties provided by the protocol you suggest? Best regards, Rene On 27/10/2010 6:22 AM, QIU Ying wrote: > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG. > > Any comments are appreciated. > > Regards > QIU Ying > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, October 26, 2010 6:22 AM > To: qiuying@i2r.a-star.edu.sg > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01 > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been successfully submitted by QIU Ying and posted to the IETF repository. > > Filename: draft-qiu-6lowpan-secure-router > Revision: 01 > Title: Lightweight Key Establishment and Management Protocol in Dymanmic Sensor Networks (KEMP) > Creation_date: 2010-10-26 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > When a sensor node roams within a very large and distributed wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. > > > > The IETF Secretariat. > > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From mcr@sandelman.ca Wed Oct 27 07:42: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 74F653A6A4B for ; Wed, 27 Oct 2010 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.199, 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 le-U77RVPQSI for ; Wed, 27 Oct 2010 07:42:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 59F9C3A6A4A for ; Wed, 27 Oct 2010 07:42:50 -0700 (PDT) Received: from marajade.sandelman.ca (ptp-diablo-tech.storm.ca [209.87.253.70]) by relay.sandelman.ca (Postfix) with ESMTPS id 18F6F34445; Wed, 27 Oct 2010 10:48:03 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6A28198AD2; Wed, 27 Oct 2010 10:44:38 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4CC7C814.5080900@gmail.com> References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> <4CC129BD.4040004@piuha.net> <101401cb74d9$6911ca90$3b355fb0$@com> <4CC7C814.5080900@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 27 Oct 2010 10:44:38 -0400 Message-ID: <29283.1288190678@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 14:42:51 -0000 >>>>> "Alexandru" == Alexandru Petrescu writes: Alexandru> In RPL, the assumption that a node is an IP router/forwarder with a Alexandru> single interface and a unique subnet prefix - is very hard to grasp Alexandru> conceptually to me. I am afraid there may be a big misunderstanding and Alexandru> may stem from a misunderstanding of the underlying link layer. One such Alexandru> misunderstanding is the common assumption that a single-interfaced Alexandru> machine forwarding a packet will not disturb the originator. This may Alexandru> lead to trying to solve imaginary link layer problems Alexandru> with IP forwarding. Are you saying that administrative types might try to solve problems using their wired-LAN experience of a single broadcast domain? RPL builds what is essentially a kind of NBMA network, only it has limited broadcasts. Maybe the wireless experts on the list can tell me the technical term for a broadcast media where not all nodes can hear all others... maybe the word is "radio" :-) -- ] 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 STEVE.CHILDRESS@saic.com Wed Oct 27 13:10: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 B6DEB3A69AF; Wed, 27 Oct 2010 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1lsEKnMfMdh; Wed, 27 Oct 2010 13:10:36 -0700 (PDT) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by core3.amsl.com (Postfix) with ESMTP id 2A25A3A69A0; Wed, 27 Oct 2010 13:10:36 -0700 (PDT) Received: from 0599-its-sbg03.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-4780741; Wed, 27 Oct 2010 13:12:14 -0700 X-AuditID: 8b79132a-b7c43ae000001261-8a-4cc8879ec382 Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg03.saic.com (Symantec Brightmail Gateway) with SMTP id 13.E6.04705.E9788CC4; Wed, 27 Oct 2010 13:12:14 -0700 (PDT) Received: from 0461-its-exmb01.us.saic.com ([10.8.67.21]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:12:14 -0700 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, 27 Oct 2010 13:12:14 -0700 Message-Id: <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> In-Reply-To: <4CC82682.4070003@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 Thread-Index: Act12X+JoF15ezSWTc2B0TydayOyLAAOlsTg References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> <4CC82682.4070003@gmail.com> From: "Childress, Steve" To: "Rene Struik" , "QIU Ying" X-OriginalArrivalTime: 27 Oct 2010 20:12:14.0207 (UTC) FILETIME=[3EE878F0:01CB7613] X-Brightmail-Tracker: AAAAAA== Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-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: Wed, 27 Oct 2010 20:10:40 -0000 On: "What about the scenario where one has multiple trust domains (e.g., when one procures sensors from=20 different vendors)?" This is the nature of our current project and implementation, using 802.15.4 sans full NWK layer.=20 Steve Childress -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik Sent: Wednesday, October 27, 2010 6:18 AM To: QIU Ying Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 Hi Qiu: Thanks for your draft. Your draft seems to suggest a single trust domain, where each node=20 shares a secret key with the base station. What about the scenario where one has multiple trust domains (e.g., when one procures sensors from=20 different vendors)? Doesn't the security fall apart if a router gets=20 compromised? What prevents an adversary from replaying past (sensor=20 node, request) pairs and triggering traffic flows and key updates with=20 routers this way? Do you have a paper that provides a more formal analysis of the security properties provided by the protocol you suggest? Best regards, Rene On 27/10/2010 6:22 AM, QIU Ying wrote: > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG. > > Any comments are appreciated. > > Regards > QIU Ying > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, October 26, 2010 6:22 AM > To: qiuying@i2r.a-star.edu.sg > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01 > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been successfully submitted by QIU Ying and posted to the IETF repository. > > Filename: draft-qiu-6lowpan-secure-router > Revision: 01 > Title: Lightweight Key Establishment and Management Protocol in Dymanmic Sensor Networks (KEMP) > Creation_date: 2010-10-26 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > When a sensor node roams within a very large and distributed wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. > > > > The IETF Secretariat. > > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From qiuying@i2r.a-star.edu.sg Thu Oct 28 04:41: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 4F9973A68A7; Thu, 28 Oct 2010 04:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 8uXUjwhTrPBr; Thu, 28 Oct 2010 04:41:18 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id EE3663A6875; Thu, 28 Oct 2010 04:41:17 -0700 (PDT) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw1.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id o9SBh2RX006227; Thu, 28 Oct 2010 19:43:02 +0800 Received: from Win7PC ([10.217.141.168]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Oct 2010 19:42:36 +0800 From: "QIU Ying" To: "'Childress, Steve'" , "'Rene Struik'" References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> <4CC82682.4070003@gmail.com> <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> In-Reply-To: <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> Date: Thu, 28 Oct 2010 19:46:15 +0800 Message-ID: <004c01cb7695$ba2172b0$2e645810$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act12X+JoF15ezSWTc2B0TydayOyLAAOlsTgAByDqIA= Content-Language: en-sg X-OriginalArrivalTime: 28 Oct 2010 11:42:36.0206 (UTC) FILETIME=[37698CE0:01CB7695] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-28_05:2010-10-28, 2010-10-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010280027 Cc: roll@ietf.org, 6lowpan@ietf.org, 'Bao Feng' , 'Zhou Jianying' Subject: Re: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-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, 28 Oct 2010 11:41:20 -0000 Hi, Rene and Steve Thanks for your comments. First of all, one thing needs to clarify: each node shares a secret key with its neighbour as well as the base station, respectively. You are right that the current version does not describe the issue of multiple trust domains. If these multiple domains are managed by one base station (key centre), the proposed protocol can simplify be employed on this scenario. If these multiple domains have their own base station, there are 2 sub-scenarios: 1) if the sensor node know its destination base station, the current protocol can be use without any change, but extend the node's cache table to store the secret between node and these base stations. 2) if the sensor node cannot decide which base station is its destination, we need to modify the req message. One possible solution could let the req message carry a catenation of all of MACs with generated by the secret between the node and the basestaion, respectively. But I do not think it is a good solution because the req message would be longer and cost much more transit energy. Since the node has different keys with its neighbours respectively, one compromised router would not affect the entire system but its neighbour nodes. In the section 5, we briefed the security analysis. In fact, the protocol is similar with the well-known Kerberos protocol. Our protocol tries to reduce the handshake messages. Steve, could you please provide more information on your project? Regards and Thanks Qiu Ying > -----Original Message----- > From: Childress, Steve [mailto:STEVE.CHILDRESS@saic.com] > Sent: Thursday, October 28, 2010 4:12 AM > To: Rene Struik; QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan- > secure-router-01 > > On: "What about the scenario where one has multiple trust domains (e.g., > when one procures sensors from > different vendors)?" > > This is the nature of our current project and implementation, using > 802.15.4 sans full NWK layer. > > Steve Childress > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Rene Struik > Sent: Wednesday, October 27, 2010 6:18 AM > To: QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] FW: New Version Notification > fordraft-qiu-6lowpan-secure-router-01 > > Hi Qiu: > > Thanks for your draft. > > Your draft seems to suggest a single trust domain, where each node > shares a secret key with the base station. What about the scenario where > > one has multiple trust domains (e.g., when one procures sensors from > different vendors)? Doesn't the security fall apart if a router gets > compromised? What prevents an adversary from replaying past (sensor > node, request) pairs and triggering traffic flows and key updates with > routers this way? > > Do you have a paper that provides a more formal analysis of the security > > properties provided by the protocol you suggest? > > Best regards, Rene > > On 27/10/2010 6:22 AM, QIU Ying wrote: > > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > > > The title of the draft had been changed to "Lightweight Key > Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" > instead of "Lightweight Secure Router Protocol" in order to make the > work more clearly. It will be presented at ROLL WG. > > > > > Any comments are appreciated. > > > > Regards > > QIU Ying > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Tuesday, October 26, 2010 6:22 AM > > To: qiuying@i2r.a-star.edu.sg > > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > > Subject: New Version Notification for > draft-qiu-6lowpan-secure-router-01 > > > > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been > successfully submitted by QIU Ying and posted to the IETF repository. > > > > Filename: draft-qiu-6lowpan-secure-router > > Revision: 01 > > Title: Lightweight Key Establishment and Management > Protocol in Dymanmic Sensor Networks (KEMP) > > Creation_date: 2010-10-26 > > WG ID: Independent Submission > > Number_of_pages: 17 > > > > Abstract: > > When a sensor node roams within a very large and distributed wireless > > sensor network, which consists of numerous sensor nodes, its routing > > path and neighborhood keep changing. In order to provide a high > > level of security in this environment, the moving sensor node needs > > to be authenticated to new neighboring nodes as well as to establish > > a key for secure communication. The document proposes an efficient > > and scalable protocol to establish and update the secure key in a > > dynamic wireless sensor network environment. The protocol guarantees > > that two sensor nodes share at least one key with probability 1 > > (100%) with less memory and energy cost, while not causing > > considerable communication overhead. > > > > > > > > The IETF Secretariat. > > > > > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From azdvir@gmail.com Thu Oct 28 06:20: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 48B7E3A67F6 for ; Thu, 28 Oct 2010 06:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_34=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 aiEQibaHWcpA for ; Thu, 28 Oct 2010 06:20:05 -0700 (PDT) Received: from shamir.crysys.hit.bme.hu (shamir.crysys.hit.bme.hu [152.66.249.135]) by core3.amsl.com (Postfix) with ESMTP id 2BAF93A67E3 for ; Thu, 28 Oct 2010 06:20:03 -0700 (PDT) Received: from ip10-105-55.ebizlab.hit.bme.hu ([10.105.1.55] helo=localhost ident=amavis) by shamir.crysys.hit.bme.hu with esmtp (Exim 4.69) (envelope-from ) id 1PBSQU-0007qJ-SB for roll@ietf.org; Thu, 28 Oct 2010 15:21:54 +0200 X-Virus-Scanned: by amavis-dc Received: from shamir.crysys.hit.bme.hu ([10.105.1.254]) by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023) with ESMTP id kZxx9kaqnjm4 for ; Thu, 28 Oct 2010 15:21:49 +0200 (CEST) Received: from ip146.crysys.hit.bme.hu ([152.66.249.146] helo=amitPC) by shamir.crysys.hit.bme.hu with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1PBSQP-0007qE-6g for roll@ietf.org; Thu, 28 Oct 2010 15:21:49 +0200 From: "amit dvir" To: References: In-Reply-To: Date: Thu, 28 Oct 2010 15:21:55 +0200 Message-ID: <022b01cb76a3$1ae1bee0$50a53ca0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act2ovqFz1SqlHGAShyflBP7VBm4pAAABZWw Content-Language: he Subject: Re: [Roll] Welcome to the "Roll" mailing list X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Oct 2010 13:21:52 -0000 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of roll-request@ietf.org Sent: Thursday, October 28, 2010 3:19 PM To: azdvir@gmail.com Subject: Welcome to the "Roll" mailing list Welcome to the Roll@ietf.org mailing list! To post to this list, send your email to: roll@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/roll If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/roll/azdvir%40gmail.com You can also make such adjustments via email by sending a message to: Roll-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: oyh0oTqn Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From h.kermajani9@gmail.com Fri Oct 29 07:48: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 2DBF13A689D for ; Fri, 29 Oct 2010 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bme4s3jMbsiC for ; Fri, 29 Oct 2010 07:48:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D967B3A6A51 for ; Fri, 29 Oct 2010 07:48:14 -0700 (PDT) Received: by gya6 with SMTP id 6so2161151gya.31 for ; Fri, 29 Oct 2010 07:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=yXVW0URKld11rWnNISg4FCgbTfINDOPZ9DfnStpeR+Q=; b=rQ1AJpVaelxi3glcMsPXsjleJghvQy72usKL1tAAB1OzvuOKkOzgq57g2BS7/gRwMr edFlZZGEV2yjmwbaqsEJmDZb58iHV/NCLMohqht8Evha0Wu5+RvACNazg9lxizguGelV tkrr1td9/6e+71vFnG/Hv+ZlTn9NEv2u4whNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CDqvm4iX/IihNx7gCg9MKToM4udZHVCreT3BPZRhOK1wHoCpomALbP76uPUIJRoRE7 zCJK7WfQ50rBaS8zKeAzLjPtKwesUeaAh1aHtccJL2o2LujulaME3Dd5MvKd2D6TbLRa Q+nBClVHi+6AgtwYvw4JZMc3/Nbasmh2REjjI= MIME-Version: 1.0 Received: by 10.42.170.197 with SMTP id g5mr9853077icz.347.1288363808400; Fri, 29 Oct 2010 07:50:08 -0700 (PDT) Received: by 10.220.200.203 with HTTP; Fri, 29 Oct 2010 07:50:05 -0700 (PDT) Date: Fri, 29 Oct 2010 16:50:05 +0200 Message-ID: From: Hamidreza Kermajani To: roll@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8964243f790493c29345 Subject: [Roll] Question about non-storing mode in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:48:20 -0000 --90e6ba6e8964243f790493c29345 Content-Type: text/plain; charset=ISO-8859-1 Hi all, According to RPL (v.14) that says : " 9.5. Triggering DAO Messages Nodes can trigger their sub-DODAG to send DAO messages. Each node maintains a DAO Trigger Sequence Number (DTSN), which it communicates through DIO messages. 1. If a node hears one of its DAO parents increment its DTSN, the node MUST schedule a DAO message transmission using rules in Section 9.3 and Section 9.4. 2. In non-storing mode, if a node hears one of its DAO parents increment its DTSN, the node MUST increment its own DTSN. " 1 - Is the first rule for both mode of operation? or only for storing mode? As far as I understand, when a node adds a new parent to its DAO parent set it must to send a DAO message to root, to inform the root about this case, that's why in each time the root node has a route to other DODAG nodes. Now my question is : 2 - When a non-storing node must send its DAO message to the DODAG root, while sending packet to root ,Why should it send the packets to root via its preferred parent( first to its preferred parent), not directly to the root ? What's the reason? Best Regards, Hamidreza. --90e6ba6e8964243f790493c29345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

According to RPL (v.14) that says :
"
9.5. Trigg= ering DAO Messages
Nodes can trigger their sub-DODAG to send DAO message= s. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it co= mmunicates
through DIO messages.
1. If a node hears one of its DAO parents incremen= t its DTSN, the
node MUST schedule a DAO message transmission using rule= s in
Section 9.3 and Section 9.4.
2. In non-storing mode, if a node h= ears one of its DAO parents
increment its DTSN, the node MUST increment its own DTSN.
"

= 1 - Is the first rule for both mode of operation? or only for storing mode?=


As far as I understand, when a node adds a new parent to its DA= O parent set it must to send a DAO message to root, to inform the root=20 about this case, that's why in each time the root node has a route to= =20 other DODAG nodes.

Now my question is :=A0

2 - When a non-st= oring node must send its DAO message to the DODAG root, while sending packe= t to root ,Why should it send the packets to root via its preferred parent(= first to its preferred parent), not directly to the root ? What's the = reason?



Best Regards,
Hamidreza.
--90e6ba6e8964243f790493c29345-- From Matteo.Paris@ember.com Fri Oct 29 08:47: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 7F7883A68AE for ; Fri, 29 Oct 2010 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 HE1AyX+IejL5 for ; Fri, 29 Oct 2010 08:47:37 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BE3483A684A for ; Fri, 29 Oct 2010 08:47:36 -0700 (PDT) Received: from [192.168.81.55] ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 11:49:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 29 Oct 2010 11:49:27 -0400 To: Hamidreza Kermajani , roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 29 Oct 2010 15:49:26.0244 (UTC) FILETIME=[DD4BC240:01CB7780] Subject: Re: [Roll] Question about non-storing mode in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:47:40 -0000 Hi Hamidreza, The first rule applies to both modes, the second only to non-storing mode. Note that in non-storing mode, the DTSN is controlled by the root. This is discussed in the 5th paragraph of section 9.5. For your second question, see section 9.7 Non-storing Mode. There it says "DAOs are sent directly to the root along a default route installed as part of the parent selection." DAOs do not need to be sent via a particular parent in non-storing mode, since the IP destination of the DAO is the root. Matteo At 4:50 PM +0200 10/29/10, Hamidreza Kermajani wrote: >Hi all, > >According to RPL (v.14) that says : >" >9.5. Triggering DAO Messages >Nodes can trigger their sub-DODAG to send DAO messages. Each node >maintains a DAO Trigger Sequence Number (DTSN), which it communicates >through DIO messages. >1. If a node hears one of its DAO parents increment its DTSN, the >node MUST schedule a DAO message transmission using rules in >Section 9.3 and Section 9.4. >2. In non-storing mode, if a node hears one of its DAO parents >increment its DTSN, the node MUST increment its own DTSN. >" > >1 - Is the first rule for both mode of operation? or only for storing mode? > > >As far as I understand, when a node adds a new parent to its DAO >parent set it must to send a DAO message to root, to inform the root >about this case, that's why in each time the root node has a route >to other DODAG nodes. > >Now my question is : > >2 - When a non-storing node must send its DAO message to the DODAG >root, while sending packet to root ,Why should it send the packets >to root via its preferred parent( first to its preferred parent), >not directly to the root ? What's the reason? > > > >Best Regards, >Hamidreza. > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From h.kermajani9@gmail.com Fri Oct 29 09:31:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE883A67A1 for ; Fri, 29 Oct 2010 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miqAZjdPbJXI for ; Fri, 29 Oct 2010 09:31:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id AED9A3A6405 for ; Fri, 29 Oct 2010 09:31:06 -0700 (PDT) Received: by pzk37 with SMTP id 37so144825pzk.31 for ; Fri, 29 Oct 2010 09:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yvZ8Yty91NSWoPAqdnxHgNP6VVGqy49eolZXceR360k=; b=YS2q5waQCTlKBUGQ+5aU/nlg+y2mLspXIhCp5NY+2FRX617KiF8PgQOOvbSHI2LU1v HQJvWntN8YH2uTwTgnpL1NMsz0OghsZmYg+uxyIs3eNzuw2g7TJqiMk/LapllgkFiSp/ uh96tpt8N/CceJtuDUwPzD9Brx544urIjUum8= 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=ltLBB2lTBUq3a5AN4tpojdrLicp6gYjhV1IH3AquiA/8ofr2KvP0pUmmTZ8w+a6tDB dKdqzuDjET72bzqScIKMy2tAUM9IuHChETN/mdQf873How8hFhdNEJM1LjtMCvDUWG86 mjJLsiLeZsX4gxxu4E+ZYSXa1cmwF2rul3tTw= MIME-Version: 1.0 Received: by 10.142.155.10 with SMTP id c10mr1540176wfe.241.1288369981575; Fri, 29 Oct 2010 09:33:01 -0700 (PDT) Received: by 10.220.200.203 with HTTP; Fri, 29 Oct 2010 09:33:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 18:33:01 +0200 Message-ID: From: Hamidreza Kermajani To: Matteo Paris Content-Type: multipart/alternative; boundary=000e0cd328fc1756760493c4037f Cc: roll@ietf.org Subject: Re: [Roll] Question about non-storing mode in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:31:07 -0000 --000e0cd328fc1756760493c4037f Content-Type: text/plain; charset=ISO-8859-1 Hi Matteo, First thanks for answer. regarding my second question, I know that all non-root nodes in non-storing mode send their DAO messages to the root. my question is about data transmission, because according to Dario Tedeschi's email (in 19th August) under title "[Roll] Question on path to grand children in non-storing mode "He said that to data transmission, first, a node must to send its data to its parent, and other people have confirmed it. That's why I asked this question. If it's true, what's the reason. Best Regard, hamidreza. --000e0cd328fc1756760493c4037f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Matteo,

First thanks for answer.

regarding my second ques= tion, I know that all non-root nodes in non-storing mode send their DAO mes= sages to the root. my question is about data transmission, because accordin= g to Dario Tedeschi's email (in 19th August) under title

"[Roll] Question on path to grand children in n= on-storing mode "

He said that to data transmission,= first, a node must to send its data to its parent, and other people have c= onfirmed it.
That's why I asked this question. If it's true, what's the reas= on.=A0

Best Regard,
hamidreza.

--000e0cd328fc1756760493c4037f-- From Matteo.Paris@ember.com Fri Oct 29 11:09: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 BD9FA3A689A for ; Fri, 29 Oct 2010 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdh65JJbAkEn for ; Fri, 29 Oct 2010 11:09:58 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 467613A69C7 for ; Fri, 29 Oct 2010 11:09:58 -0700 (PDT) Received: from [192.168.81.55] ([192.168.81.54]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 14:11:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 29 Oct 2010 14:11:48 -0400 To: Hamidreza Kermajani From: Matteo Paris Content-Type: multipart/alternative; boundary="============_-923746586==_ma============" X-OriginalArrivalTime: 29 Oct 2010 18:11:47.0838 (UTC) FILETIME=[C07B91E0:01CB7794] Cc: roll@ietf.org Subject: Re: [Roll] Question about non-storing mode in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:09:59 -0000 --============_-923746586==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Hamidreza, For a non-root router in a non-storing DODAG, the only next hops in its routing table are its parents. All data traffic, to any destination, will necessarily be routed to one of the node's parents as the next hop. (Exceptions: If the IP destination is a one-hop neighbor, the node may send the packet directly. Or, the node may support additional routing mechanisms such as http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-01.) The email you refer to, http://www.ietf.org/mail-archive/web/roll/current/msg05292.html illustrates this fact in the special case of a linear topology. The only next hop in C's routing table is B, so it has no choice of next hop for the data packet to E. In general in a non-storing network, for any two routers, the root is their only common ancestor with downward routing information, so all point-to-point traffic flows through the root. See section 4.3 Point-to-Point Traffic for further clarification. Matteo At 6:33 PM +0200 10/29/10, Hamidreza Kermajani wrote: >Hi Matteo, > >First thanks for answer. > >regarding my second question, I know that all non-root nodes in >non-storing mode send their DAO messages to the root. my question is >about data transmission, because according to Dario Tedeschi's email >(in 19th August) under title > >"[Roll] Question on path to grand children in non-storing mode " > >He said that to data transmission, first, a node must to send its >data to its parent, and other people have confirmed it. >That's why I asked this question. If it's true, what's the reason. > >Best Regard, >hamidreza. --============_-923746586==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Roll] Question about non-storing mode in RPL

Hi Hamidreza,

For a non-root router in a non-storing DODAG, the only next hops in its routing table are its parents.  All data traffic, to any destination, will necessarily be routed to one of the node's parents as the next hop.

(Exceptions: If the IP destination is a one-hop neighbor, the node may send the packet directly.  Or, the node may support additional routing mechanisms such as http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-01.)

The email you refer to, http://www.ietf.org/mail-archive/web/roll/current/msg05292.html
illustrates this fact in the special case of a linear topology.  The only next hop in C's routing table is B, so it has no choice of next hop for the data packet to E.  In general in a non-storing network, for any two routers, the root is their only common ancestor with downward routing information, so all point-to-point traffic flows through the root.

See section 4.3 Point-to-Point Traffic for further clarification.

Matteo

At 6:33 PM +0200 10/29/10, Hamidreza Kermajani wrote:
Hi Matteo,

First thanks for answer.

regarding my second question, I know that all non-root nodes in non-storing mode send their DAO messages to the root. my question is about data transmission, because according to Dario Tedeschi's email (in 19th August) under title
"[Roll] Question on path to grand children in non-storing mode "
He said that to data transmission, first, a node must to send its data to its parent, and other people have confirmed it.
That's why I asked this question. If it's true, what's the reason. 

Best Regard,
hamidreza.

--============_-923746586==_ma============-- From dat@exegin.com Fri Oct 29 15:44: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 2514C3A682B; Fri, 29 Oct 2010 15:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.493, 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 FqPTUuqbd1KL; Fri, 29 Oct 2010 15:44:07 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8643F3A6403; Fri, 29 Oct 2010 15:44:07 -0700 (PDT) Received: by qwb7 with SMTP id 7so3718135qwb.31 for ; Fri, 29 Oct 2010 15:46:02 -0700 (PDT) Received: by 10.229.96.72 with SMTP id g8mr12077268qcn.190.1288392362688; Fri, 29 Oct 2010 15:46:02 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id y14sm1064291vch.28.2010.10.29.15.46.01 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 15:46:02 -0700 (PDT) Message-ID: <4CCB4EA9.8040204@exegin.com> Date: Fri, 29 Oct 2010 15:46:01 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20101025221534.DAF423A6899@core3.amsl.com> In-Reply-To: <20101025221534.DAF423A6899@core3.amsl.com> Content-Type: multipart/alternative; boundary="------------060206010105080904050602" Cc: roll@ietf.org, i-d-announce@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-14.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 22:44:09 -0000 This is a multi-part message in MIME format. --------------060206010105080904050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some questions and comments: #1. I'm confused by the following text in section 9.7: ... ... Therefore, in non-storing mode, a node can send a single DAO, although it might choose to send more than one DAO message to each of multiple DAO parents. What would be the purpose of sending DAOs to multiple parents in a non-storing network? Is it for some kind of neighbor discovery? I'm assuming the "single DAO" is only ever sent to the Root node using its routable address. #2. In non-storing mode, where does a node get the Root's routable address? In past interops it's been assumed to come from the DODAGID, but this is not explicitly stated in the RPL draft. #3. In non-storing mode, a node needs to add the routable address of its parent to the Transit Information Option. Again, it's been assumed that the Prefix Information Option from a parent would contain it's routable address. It would be helpful if the RPL draft was more explicit about this. #4. To be more consistent with DIO messages, can the SenderRank (in the the RPL Hop-by-Hop option) be changed to the raw rank value and not DAGRank(rank)? Dario On 25/10/2010 3:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-14.txt > Pages : 141 > Date : 2010-10-25 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-14.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------060206010105080904050602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Some questions and comments:

#1.
I'm confused by the following text in section 9.7:
   ...                                    ... Therefore, in non-storing
   mode, a node can send a single DAO, although it might choose to send
   more than one DAO message to each of multiple DAO parents.
What would be the purpose of sending DAOs to multiple parents in a non-storing network? Is it for some kind of neighbor discovery? I'm assuming the "single DAO" is only ever sent to the Root node using its routable address.

#2.
In non-storing mode, where does a node get the Root's routable address? In past interops it's been assumed to come from the DODAGID, but this is not explicitly stated in the RPL draft.

#3.
In non-storing mode, a node needs to add the routable address of its parent to the Transit Information Option. Again, it's been assumed that the Prefix Information Option from a parent would contain it's routable address. It would be helpful if the RPL draft was more explicit about this.

#4.
To be more consistent with DIO messages, can the SenderRank (in the the RPL Hop-by-Hop option) be changed to the raw rank value and not DAGRank(rank)?

Dario

On 25/10/2010 3:15 PM, Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.


	Title           : RPL: IPv6 Routing Protocol for Low power and Lossy Networks
	Author(s)       : T. Winter, et al.
	Filename        : draft-ietf-roll-rpl-14.txt
	Pages           : 141
	Date            : 2010-10-25

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-14.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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

--------------060206010105080904050602-- From emmanuel.baccelli@gmail.com Sat Oct 30 03:39: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 982873A63CB for ; Sat, 30 Oct 2010 03:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.308, 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 Xu4pkGS-Aeh3 for ; Sat, 30 Oct 2010 03:39:24 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BB6333A683A for ; Sat, 30 Oct 2010 03:39:11 -0700 (PDT) Received: by fxm9 with SMTP id 9so4054157fxm.31 for ; Sat, 30 Oct 2010 03:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=CXBAf1A70ghOVNNvvcw7zCb3vlHuKmC2X56hu7Nz/Oo=; b=NVshmJ7eRw6iGiM7sO1kR4dY7NujSofCqu72jzIoq5lLgx6izwserhocOiNi4GCXWx kljEm0qCuO0MCnYq7vCLLpJ6D0NJrEMY8ao16blD/9p39ct6bcYAN3HqURFNuG65FOBy dNwgnZRaqtuQMei55QU5bwYE1u5LSntni/TWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=HzXZ5LhjVSqqhiHBSfpS66vGC+8dcDCUbJBT8cBXRgfyO4FlMD70KG1B3/eOBwmt04 dm557as16Mgi+ngyWDCAoJ8PlQTRGKNdLdsdjU4Ot5NxrQvoGN+SSd62Eocroy7dAiDB ghcHiWqBfLwCR9GEKKK/uteWrpNxdPxRSqVSE= Received: by 10.223.83.13 with SMTP id d13mr89302fal.56.1288435266188; Sat, 30 Oct 2010 03:41:06 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.223.103.132 with HTTP; Sat, 30 Oct 2010 03:40:46 -0700 (PDT) From: Emmanuel Baccelli Date: Sat, 30 Oct 2010 12:40:46 +0200 X-Google-Sender-Auth: fhktcG488yMiji0PB5DsijsUmUM Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=20cf30433fa05b74b60493d336c5 Subject: [Roll] Feedback on p2p X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 10:39:27 -0000 --20cf30433fa05b74b60493d336c5 Content-Type: text/plain; charset=ISO-8859-1 Dear ROLLers, we solicit you for feedback on the p2p draft. Please review the document and shoot any questions or comments you may have. Moreover, we are also interested in knowing whether you have (or plan) an implementation. http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl In parallel, do take a look at the companion document providing a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node. Any feedback on that too would be greatly appreciated! http://tools.ietf.org/html/draft-goyal-roll-p2p-measurement see you all soon in Beijing, Emmanuel --20cf30433fa05b74b60493d336c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear ROLLers,

we solicit you for feedback on the p2p dra= ft. Please review the document and shoot any questions or comments you may = have. Moreover, we are also interested in knowing whether you have (or plan= ) an implementation.

In parallel, do take a look at the companion document providin= g a mechanism that enables an RPL node to measure the quality of an existin= g route to/from another RPL node. Any feedback on that too would be greatly= appreciated!



see you all soon in Bei= jing,


Emmanuel


--20cf30433fa05b74b60493d336c5-- From h.kermajani9@gmail.com Sat Oct 30 16:55: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 D190E3A69CF for ; Sat, 30 Oct 2010 16:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbjXT0B0d5uL for ; Sat, 30 Oct 2010 16:55:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A47753A66B4 for ; Sat, 30 Oct 2010 16:55:03 -0700 (PDT) Received: by vws3 with SMTP id 3so1690783vws.31 for ; Sat, 30 Oct 2010 16:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7DqadhZPJXTi/Z8ygjZ5Pi/Q04cxrID0H7I1qSB5QNE=; b=Uy7CVJ4s+6TmfBKXojGzx6tZpbZ14YLXKaRwOHMGP6+WefzvtvwYm+ixiRCOv28USp sQoLpESAGp0UdAFv9Ed3FQyDgjrwmsfV/w686JNj9OUIqlNiOnK5RdvecRRtPU5ka8K3 tU0QpGk/mzTrchRxNo8StmoAKFIFbldMRYtsE= 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=dms+HQvzAnCsLOVSB8+2XzUXz0vxfsOuggLguhWTo2vcBouGr2Zq6qt1r5Z1+u0Mil l5N3Vpcf4atO8kn9K3jXD/UW//FMlY3fMLkU42BnZwNqJVzOeKTYgi4AQ1BPUvKQ40qV Ty2o6XDqOP7tgISh1EiZgrr5RT1ltEmsk7oBI= MIME-Version: 1.0 Received: by 10.224.137.131 with SMTP id w3mr6489073qat.88.1288483021174; Sat, 30 Oct 2010 16:57:01 -0700 (PDT) Received: by 10.220.200.203 with HTTP; Sat, 30 Oct 2010 16:57:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Oct 2010 01:57:01 +0200 Message-ID: From: Hamidreza Kermajani To: Emmanuel Baccelli Content-Type: multipart/alternative; boundary=002215046e2fc6ba9c0493de54f3 Cc: ROLL WG Subject: Re: [Roll] Feedback on p2p X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 23:55:05 -0000 --002215046e2fc6ba9c0493de54f3 Content-Type: text/plain; charset=ISO-8859-1 Hi Emmanuel, Which node will operate as a temporary DAG's root? The origin node? Best Regards, Hamidreza. --002215046e2fc6ba9c0493de54f3 Content-Type: text/html; charset=ISO-8859-1 Hi Emmanuel,

Which node will operate as a temporary DAG's root? The origin node?

Best Regards,
Hamidreza.
--002215046e2fc6ba9c0493de54f3--