From coflynn@newae.com Wed Dec 1 05:01: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 15F4028C513 for ; Wed, 1 Dec 2010 05:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 9zmmtCW1mtT5 for ; Wed, 1 Dec 2010 05:01:38 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 450E128C1BA for ; Wed, 1 Dec 2010 05:00:58 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=laptop.localnet) by s034.panelboxmanager.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PNmK1-0005QK-8m; Wed, 01 Dec 2010 08:02:09 -0500 From: "Colin O'Flynn" To: Philip Levis Date: Wed, 1 Dec 2010 09:01:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32.23-170.fc12.x86_64; KDE/4.4.5; x86_64; ; ) References: <20101122163512.4979.96571.idtracker@localhost> <88B51503-1B15-4F5A-8139-2BBA6B81A4AD@cs.stanford.edu> In-Reply-To: <88B51503-1B15-4F5A-8139-2BBA6B81A4AD@cs.stanford.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012010901.46353.coflynn@newae.com> 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] Last Call: (The Trickle Algorithm) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Dec 2010 13:01:39 -0000 Hi Phil, I agree with you that simply saying "variable" doesn't give a good point of resource usage. However trickle itself doesn't define anything about the variable sizes either. Hence the number of bytes used will really depend on both the network requirements (time accuracy & interval length) along with your implementation. So I think Ulrich's concern was mainly that the introduction uses a fixed number of bytes for resource requirements without specifying the constraints they are valid for (correct me if I'm wrong Ulrich). To me both ways would make sense, and it's a simple matter either way for someone to read down to section 4.1 where they understand the exact storage requirements anyway. It's good to keep the intro simple to highlight the features, so if the text as written seems more concise that works for me! Warm Regards, -Colin On Tuesday, November 30, 2010 03:09:54 pm Philip Levis wrote: > On Nov 23, 2010, at 2:27 AM, Ulrich Herberg wrote: > > Colin, > > > > On Tue, Nov 23, 2010 at 11:16 AM, Colin O'Flynn wrote: > >>> - introduction: "current implementations use 4-11 bytes...". I wonder > >>> whether that is wise to put into the draft, since it once it will be > >>> published, "current" implementations may need more or less (at that > >>> future time) > >> > >> I think it is reasonable to keep such a statement. It could be > >> simplified to just explain what those bytes are, but I think the point > >> is if you pick up the draft you know right away what sort of resource > >> requirements the draft carries. > >> > >> So something saying "Trickle requires at minimum three variables". The > >> size of the variables would depend on your network & processor > >> architecture. Such a statement would remain valid even when we move to > >> 128-bit processors & a single variable is typically 16 bytes ;-) > > > > Yes, I can agree to that. > > Hm -- let me explain the reasoning for why the text says "4-11 bytes" > rather than "x variables." Basically, bytes is more precise. Even if an > architecture has 16-byte words (I guess by "typical variable" you mean "C > int type"), there are still one-byte and two-byte variables. If you care > about data size, you can use these smaller types, and that's what leads to > having 4-11 bytes. > > Saying "three variables" could mean "3 large arrays" or "3 bytes." It > doesn't provide a lot of insight. I could implement Trickle with a single > long long, where I pack things like c, t, and the current interval size > into those 8 bytes. "Variables" isn't really a statement of the resource > requirements, while the number of bytes can be. > > Does that make sense? > > Phil From ulrich@herberg.name Wed Dec 1 05:20: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 4440F28C267 for ; Wed, 1 Dec 2010 05:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzU4FUeCnli7 for ; Wed, 1 Dec 2010 05:20:46 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 5630728C242 for ; Wed, 1 Dec 2010 05:20:45 -0800 (PST) Received: by qyk34 with SMTP id 34so2537452qyk.10 for ; Wed, 01 Dec 2010 05:21:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.179.131 with SMTP id bq3mr1725560qab.81.1291209718583; Wed, 01 Dec 2010 05:21:58 -0800 (PST) Received: by 10.220.185.196 with HTTP; Wed, 1 Dec 2010 05:21:58 -0800 (PST) In-Reply-To: <201012010901.46353.coflynn@newae.com> References: <20101122163512.4979.96571.idtracker@localhost> <88B51503-1B15-4F5A-8139-2BBA6B81A4AD@cs.stanford.edu> <201012010901.46353.coflynn@newae.com> Date: Wed, 1 Dec 2010 14:21:58 +0100 Message-ID: From: Ulrich Herberg To: "Colin O'Flynn" Content-Type: multipart/alternative; boundary=20cf302ef9849b507d0496593040 Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Dec 2010 13:20:51 -0000 --20cf302ef9849b507d0496593040 Content-Type: text/plain; charset=ISO-8859-1 Colin, Phil, On Wed, Dec 1, 2010 at 2:01 PM, Colin O'Flynn wrote: > Hi Phil, > > I agree with you that simply saying "variable" doesn't give a good point of > resource usage. However trickle itself doesn't define anything about the > variable sizes either. > > Hence the number of bytes used will really depend on both the network > requirements (time accuracy & interval length) along with your > implementation. > So I think Ulrich's concern was mainly that the introduction uses a fixed > number of bytes for resource requirements without specifying the > constraints > they are valid for (correct me if I'm wrong Ulrich). > Yes, indeed. > > To me both ways would make sense, and it's a simple matter either way for > someone to read down to section 4.1 where they understand the exact storage > requirements anyway. It's good to keep the intro simple to highlight the > features, so if the text as written seems more concise that works for me! > Yes, I can agree to that. Regards Ulrich > > Warm Regards, > > -Colin > > On Tuesday, November 30, 2010 03:09:54 pm Philip Levis wrote: > > On Nov 23, 2010, at 2:27 AM, Ulrich Herberg wrote: > > > Colin, > > > > > > On Tue, Nov 23, 2010 at 11:16 AM, Colin O'Flynn > wrote: > > >>> - introduction: "current implementations use 4-11 bytes...". I wonder > > >>> whether that is wise to put into the draft, since it once it will be > > >>> published, "current" implementations may need more or less (at that > > >>> future time) > > >> > > >> I think it is reasonable to keep such a statement. It could be > > >> simplified to just explain what those bytes are, but I think the point > > >> is if you pick up the draft you know right away what sort of resource > > >> requirements the draft carries. > > >> > > >> So something saying "Trickle requires at minimum three variables". The > > >> size of the variables would depend on your network & processor > > >> architecture. Such a statement would remain valid even when we move to > > >> 128-bit processors & a single variable is typically 16 bytes ;-) > > > > > > Yes, I can agree to that. > > > > Hm -- let me explain the reasoning for why the text says "4-11 bytes" > > rather than "x variables." Basically, bytes is more precise. Even if an > > architecture has 16-byte words (I guess by "typical variable" you mean "C > > int type"), there are still one-byte and two-byte variables. If you care > > about data size, you can use these smaller types, and that's what leads > to > > having 4-11 bytes. > > > > Saying "three variables" could mean "3 large arrays" or "3 bytes." It > > doesn't provide a lot of insight. I could implement Trickle with a single > > long long, where I pack things like c, t, and the current interval size > > into those 8 bytes. "Variables" isn't really a statement of the resource > > requirements, while the number of bytes can be. > > > > Does that make sense? > > > > Phil > --20cf302ef9849b507d0496593040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Colin, Phil,

On Wed, Dec 1, 2010 at 2:01 = PM, Colin O'Flynn <coflynn@newae.com> wrote:
Hi Phil,

I agree with you that simply saying "variable" doesn't give a= good point of
resource usage. However trickle itself doesn't define anything about th= e
variable sizes either.

Hence the number of bytes used will really depend on both the network
requirements (time accuracy & interval length) along with your implemen= tation.
So I think Ulrich's concern was mainly that the introduction uses a fix= ed
number of bytes for resource requirements without specifying the constraint= s
they are valid for (correct me if I'm wrong Ulrich).

Yes, indeed.
=A0

To me both ways would make sense, and it's a simple matter either way f= or
someone to read down to section 4.1 where they understand the exact storage=
requirements anyway. It's good to keep the intro simple to highlight th= e
features, so if the text as written seems more concise that works for me!

Yes, I can agree to that.

Regards
Ulrich =

=A0

Warm Regards,

=A0-Colin

On Tuesday, November 30, 2010 03:09:54 pm Philip Levis wrote:
> On Nov 23, 2010, at 2:27 AM, Ulrich Herberg wrote:
> > Colin,
> >
> > On Tue, Nov 23, 2010 at 11:16 AM, Colin O'Flynn <coflynn@newae.com> wrote:
> >>> - introduction: "current implementations use 4-11 by= tes...". I wonder
> >>> whether that is wise to put into the draft, since it once= it will be
> >>> published, "current" implementations may need m= ore or less (at that
> >>> future time)
> >>
> >> I think it is reasonable to keep such a statement. It could b= e
> >> simplified to just explain what those bytes are, but I think = the point
> >> is if you pick up the draft you know right away what sort of = resource
> >> requirements the draft carries.
> >>
> >> So something saying "Trickle requires at minimum three v= ariables". The
> >> size of the variables would depend on your network & proc= essor
> >> architecture. Such a statement would remain valid even when w= e move to
> >> 128-bit processors & a single variable is typically 16 by= tes ;-)
> >
> > Yes, I can agree to that.
>
> Hm -- let me explain the reasoning for why the text says "4-11 by= tes"
> rather than "x variables." Basically, bytes is more precise.= Even if an
> architecture has 16-byte words (I guess by "typical variable"= ; you mean "C
> int type"), there are still one-byte and two-byte variables. If y= ou care
> about data size, you can use these smaller types, and that's what = leads to
> having 4-11 bytes.
>
> Saying "three variables" could mean "3 large arrays&quo= t; or "3 bytes." It
> doesn't provide a lot of insight. I could implement Trickle with a= single
> long long, where I pack things like c, t, and the current interval siz= e
> into those 8 bytes. "Variables" isn't really a statement= of the resource
> requirements, while the number of bytes can be.
>
> Does that make sense?
>
> Phil

--20cf302ef9849b507d0496593040-- From rmarchap@cisco.com Wed Dec 1 17:37:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C60E3A6826 for ; Wed, 1 Dec 2010 17:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylfYtvkrYAQp for ; Wed, 1 Dec 2010 17:37:43 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CAB593A686A for ; Wed, 1 Dec 2010 17:37:23 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8EAM+G9kyrR7Hu/2dsb2JhbACUUY5QcagHmwSCcYJWBIReiR6IBg X-IronPort-AV: E=Sophos;i="4.59,285,1288569600"; d="scan'208";a="296023756" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2010 01:38:28 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oB21cJEO004825; Thu, 2 Dec 2010 01:38:28 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Dec 2010 17:38:27 -0800 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, 1 Dec 2010 17:38:23 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900C0A74C6@xmb-sjc-21b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuQWpeRp87ju3ZGQY+za61HgoK3aABYzHUA References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 02 Dec 2010 01:38:27.0192 (UTC) FILETIME=[9DC63780:01CB91C1] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2010 01:37:56 -0000 Sorry for the late reply, was down with viral. Summary so far: - There's a configuration error if *any* of the configuration values differ between the two nodes. Should all of them be in the DIO? Example DIOIntDoubl. Set to 0. - "LBR2 sends DIO with config option, Node fails to match OCP and rejects DIO" Where in the specification does it say that a node rejects the DIO in this case and discards it? - What if the two roots in your example include different routing metrics in the Metric Container? I guess the metrics in use also characterize the dag just like OCP. Perhaps, one can identify other parameters that characterize a dag but are not there in the DIO base object. All good points. There are 2 types of misconfigurations - node specific and network wide. - misconfigs of configuration values like DIOIntDoubl can be easily detected and blocked at a node (root of DODAG). This is a node specific misconfig. Lets take a look at different config options in DIO: - DIOIntDoubl./DIOIntMin./DIORedun./MaxRankIncrease/MinHopRankIncrease/Def . Lifetime/Lifetime Unit - controlled at root, nodes just use the value sent by root. Implementations can easily block incorrect values. - OCP - configured at root and nodes. Implementations can easily block incorrect value configs (node specific misconfig). But valid OCP per node but incorrect network wide cannot be detected and blocked at root. - Section 17.2.3 says every node should be configured with instance id, ocp, and few other parameters, which implies a node should reject a DIO if it fails to match OCP. - Two roots including different routing metrics is a very good considerations and a issue related to the current one being discussed. A given OCP can have multiple metrics, for example OCP1 can have etx and latency metrics, without this info how does a node make a decision whether to join a DAG or not? OCP is a 16-bit field, do we really need to further divide it based on metrics? Can't we have one OCP value per metric? Cheers, Rajesh > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, November 30, 2010 12:18 PM > To: Rajesh Marchappanavar (rmarchap) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make > DODAGconfiguration mandatory for all DIOs >=20 >=20 > On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: > >> > > > > [RM:] That is because OCP differentiates dags, it's not just a > > 'configuration option'. A node can join 2 dags of different OCP, > > instance-id, and dag-id. Which means OCP is a dag characteristic and > not > > just one of the configuration option. The fact that two nodes > advertise > > same instance-id, dag-id, and different OCP is a mis-configuration. > They > > should be advertising different instance-id, dag-id, and ocp. That > said, > > nodes need to deal with such configuration errors. >=20 > This statement is technically incorrect. An OCP does not differentiate > DAGs. An OCP is associated with a DAG. There is a one-to-one mapping > between OCPs and DAGs. The draft is quite clear on this. Different OCPs > on the same DAG is a (serious) configuration error: while it's > important that RPL can detect this, I'd argue it's outside the scope of > the protocol (or any routing protocol) to proactively deal with such > problems. The resulting complexity of dealing with all of the possible > configuration errors is just too great. >=20 > Phil From jpv@cisco.com Thu Dec 2 02:48: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 9F7C428B797 for ; Thu, 2 Dec 2010 02:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.986 X-Spam-Level: X-Spam-Status: No, score=-109.986 tagged_above=-999 required=5 tests=[AWL=0.613, 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 NjBtzepFRFBi for ; Thu, 2 Dec 2010 02:48:45 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 45D943A6903 for ; Thu, 2 Dec 2010 02:48:45 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOMI90yrR7H+/2dsb2JhbACjIHGma5sChUcEimaDFw X-IronPort-AV: E=Sophos;i="4.59,287,1288569600"; d="scan'208";a="296250621" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2010 10:50: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 oB2Anh8b022293 for ; Thu, 2 Dec 2010 10:50: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); Thu, 2 Dec 2010 11:49:54 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Dec 2010 11:49:54 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 2 Dec 2010 11:49:53 +0100 Message-Id: <17D04581-4974-4796-A143-AAB48ADCCEB1@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Dec 2010 10:49:54.0388 (UTC) FILETIME=[A747A940:01CB920E] Subject: [Roll] IETF-79 WG Meeting Minutes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2010 10:48:46 -0000 have been uploaded: http://www.ietf.org/proceedings/79/minutes/roll.txt THANKS to Dan for having taken the minutes. Please review and let us know before Dec 10 if you have any comment. Thanks. JP. From jpv@cisco.com Thu Dec 2 02:57:43 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 6BAB428B797 for ; Thu, 2 Dec 2010 02:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.03 X-Spam-Level: X-Spam-Status: No, score=-110.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 nCHGhoPpdGxo for ; Thu, 2 Dec 2010 02:57:42 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EE3C228C0E1 for ; Thu, 2 Dec 2010 02:57:29 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMMK90yrR7Ht/2dsb2JhbACjIHGmcZp/gnKCVQSKZoMX X-IronPort-AV: E=Sophos;i="4.59,287,1288569600"; d="scan'208";a="226475000" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2010 10:58:45 +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 oB2AwWBP001269; Thu, 2 Dec 2010 10:58:45 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); Thu, 2 Dec 2010 11:58:37 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Dec 2010 11:58:37 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> Date: Thu, 2 Dec 2010 11:58:36 +0100 Content-Transfer-Encoding: 7bit Message-Id: <65D305AC-64AB-4ECE-BFF6-17FDB4360DE2@cisco.com> References: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> To: Tzeta Tsao X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Dec 2010 10:58:37.0257 (UTC) FILETIME=[DEEF2390:01CB920F] Cc: draft-ietf-roll-security-framework@tools.ietf.org, ROLL WG , Adrian Farrel Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2010 10:57:43 -0000 Hi Do you want to look at the comments and get back to Adrian ? Thanks. JP. On Nov 23, 2010, at 11:38 AM, Adrian Farrel wrote: > Hi, > > 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 for a very thorough survey of the landscape, and a well written > document. > > Most of my comments are pretty trivial, but a couple have more meat > on them and 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 gives two warnings about references: > > == Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on lines > 1786, but no explicit reference was found in the text > > == Outdated reference: A later version (-14) exists of > draft-ietf-roll-rpl-11 > > --- > > I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative > reference. You may want to look at this to decide whether you can avoid > or dilute the reference so that you are not blocked in the RFC Editor > Queue. > > --- > > The RFC Editor usually likes the first section in the document to be > the Introduction. I think you can safely swap the Terminology section > with the Introduction. > > --- > > Section 3.2 > > Because LLNs are most commonly found on publicly accessible > shared medium, e.g., air or wiring in a building, and sometimes > > s/on/on a/ > > --- > > Section 3.2 > > 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. > > I'm not comfortable with "misuse" in the context of integrity. The term > suggests to me that the information might be used for illicit purposes > which I would think ties in with "confidentiality" not "integrity". Am I > missing something? > > --- > > Section 3.2 > > In addition, > integrity also requires 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. > > I'm curious that you tie authenticity to the *message* source and > destination rather than to the *information*. This has been a debate in > routing security for some time. Consider an IGP where one could > authenticate the message exchanges between protocol peers, or one could > authenticate the link state information that is being distributed. > Clearly there are implications for the solution, and the chain-of-trust > model of the former may achieve the latter. However, I think that the > asset is the information not the message, and it is the asset that must > be authenticated. > > --- > > Section 3.2 > > It is noted that, besides those captured in the CIA model, assurance > > "those" what? > > Suggest... > > It is noted that, besides those security issues captured in the CIA > model, assurance > > --- > > Section 3.2 > > Non-repudiation > > Reading this section, it seems to me that you have identified non- > repudiation as a viable threat to ROLL. You have also recognised that > the traditional mechanisms for discovering it are hard or impossible to > apply in a LLN. > > That analysis is fine. > > But then you go on to say "it is hard, so we won't talk about it"! This > doesn't seem to be right. At the very least you should provide an > analysis of the risks and impact of non-repudiation in ROLL. You can > then also quantify the issues with applying traditional techniques, and > this might motivate people to derive new techniques (or to determine > that it is not a significant problem in ROLL). > > --- > > Section 3.3 > > As a consequence of these constraints, there is an even more > critical need than usual for a careful trade study on which and > > "trade study"? > Do you mean "study of trade-offs"? Or just "study"? > > --- > > Section 3.3 > > Highly directional traffic > Some types of LLNs see a high percentage of their total traffic > traverse between the nodes and the Lln Border Routers (LBRs) > > s/Lln/LLN/ > > --- > > Section 3.3 > > I'm not sure, but I think you should add some emphasis on the ease with > which nodes can attach to some LLNs (especially wireless ones). To some > extent this might be covered by the "ad hoc" elements in > Autonomous operations > and by the bullet item > Unattended locations and limited physical security > but I think you should draw this out specifically as it is one of the > greater security issues that I have heard voiced. > > --- > > I think that the discussion of key management is a bit weak. The issue > is identified in Sections 3.3 and 3,4 as something that can be made > more complicated in the LLN environment, but then very little is made > of the topic in the document. > > I think you should have a look at RFC 4107, which should probably one of > your references, and then see whether there is anything you can add, > possibly to Sections 6 and 7. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=9452f29ee=Tzeta.Tsao@cooperindustries.com Thu Dec 2 06:51:43 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 B08DB28C103 for ; Thu, 2 Dec 2010 06:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlrqNO-CB+nh for ; Thu, 2 Dec 2010 06:51:42 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 7C54A28C0CE for ; Thu, 2 Dec 2010 06:51:40 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,288,1288584000"; d="scan'208";a="79179595" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 02 Dec 2010 09:52:56 -0500 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Dec 2010 09:52:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Dec 2010 09:52:02 -0500 Message-ID: <9BB070DB2D281946859EA89837931EEE39861E@EVS4.nam.ci.root> In-Reply-To: <65D305AC-64AB-4ECE-BFF6-17FDB4360DE2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] AD review of draft-ietf-roll-security-framework Thread-Index: AcuSD+U3XXWp6qYnQ6eIFn5FspeYQgAICcDg References: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> <65D305AC-64AB-4ECE-BFF6-17FDB4360DE2@cisco.com> From: "Tsao, Tzeta" To: "JP Vasseur" X-OriginalArrivalTime: 02 Dec 2010 14:52:55.0109 (UTC) FILETIME=[9A111F50:01CB9230] Cc: draft-ietf-roll-security-framework@tools.ietf.org, ROLL WG , Adrian Farrel Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2010 14:51:43 -0000 Hi, The authors appreciate the input and will put out a revision as soon as possible. Thanks, Tzeta -----Original Message----- From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Thursday, December 02, 2010 5:59 AM To: Tsao, Tzeta Cc: Adrian Farrel; draft-ietf-roll-security-framework@tools.ietf.org; ROLL WG Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework Hi Do you want to look at the comments and get back to Adrian ? Thanks. JP. On Nov 23, 2010, at 11:38 AM, Adrian Farrel wrote: > Hi, >=20 > I have performed an AD review of your draft. >=20 > Don't panic! >=20 > 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=20 > 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. >=20 > Thanks for a very thorough survey of the landscape, and a well written > document. >=20 > Most of my comments are pretty trivial, but a couple have more meat > on them and 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. >=20 > Of course, all of my issues are up for discussion. >=20 > Thanks for the work, > Adrian >=20 > --- >=20 > idnits gives two warnings about references: >=20 > =3D=3D Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on = lines > 1786, but no explicit reference was found in the text >=20 > =3D=3D Outdated reference: A later version (-14) exists of > draft-ietf-roll-rpl-11 >=20 > --- >=20 > I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative > reference. You may want to look at this to decide whether you can avoid > or dilute the reference so that you are not blocked in the RFC Editor=20 > Queue. >=20 > --- >=20 > The RFC Editor usually likes the first section in the document to be > the Introduction. I think you can safely swap the Terminology section > with the Introduction. >=20 > --- >=20 > Section 3.2 >=20 > Because LLNs are most commonly found on publicly accessible > shared medium, e.g., air or wiring in a building, and sometimes >=20 > s/on/on a/ >=20 > --- >=20 > Section 3.2 >=20 > 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. >=20 > I'm not comfortable with "misuse" in the context of integrity. The term > suggests to me that the information might be used for illicit purposes > which I would think ties in with "confidentiality" not "integrity". Am I > missing something? >=20 > --- >=20 > Section 3.2 >=20 > In addition, > integrity also requires 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. >=20 > I'm curious that you tie authenticity to the *message* source and=20 > destination rather than to the *information*. This has been a debate in > routing security for some time. Consider an IGP where one could > authenticate the message exchanges between protocol peers, or one could > authenticate the link state information that is being distributed. > Clearly there are implications for the solution, and the chain-of-trust > model of the former may achieve the latter. However, I think that the > asset is the information not the message, and it is the asset that must > be authenticated. >=20 > --- >=20 > Section 3.2 >=20 > It is noted that, besides those captured in the CIA model, assurance >=20 > "those" what? >=20 > Suggest... >=20 > It is noted that, besides those security issues captured in the CIA > model, assurance >=20 > --- >=20 > Section 3.2 >=20 > Non-repudiation >=20 > Reading this section, it seems to me that you have identified non- > repudiation as a viable threat to ROLL. You have also recognised that=20 > the traditional mechanisms for discovering it are hard or impossible to > apply in a LLN.=20 >=20 > That analysis is fine. >=20 > But then you go on to say "it is hard, so we won't talk about it"! This > doesn't seem to be right. At the very least you should provide an > analysis of the risks and impact of non-repudiation in ROLL. You can > then also quantify the issues with applying traditional techniques, and > this might motivate people to derive new techniques (or to determine > that it is not a significant problem in ROLL). >=20 > --- >=20 > Section 3.3 >=20 > As a consequence of these constraints, there is an even more > critical need than usual for a careful trade study on which and >=20 > "trade study"? > Do you mean "study of trade-offs"? Or just "study"? >=20 > --- >=20 > Section 3.3 >=20 > Highly directional traffic > Some types of LLNs see a high percentage of their total traffic > traverse between the nodes and the Lln Border Routers (LBRs) >=20 > s/Lln/LLN/ >=20 > --- >=20 > Section 3.3 >=20 > I'm not sure, but I think you should add some emphasis on the ease with > which nodes can attach to some LLNs (especially wireless ones). To some > extent this might be covered by the "ad hoc" elements in > Autonomous operations > and by the bullet item > Unattended locations and limited physical security > but I think you should draw this out specifically as it is one of the > greater security issues that I have heard voiced. >=20 > --- >=20 > I think that the discussion of key management is a bit weak. The issue > is identified in Sections 3.3 and 3,4 as something that can be made > more complicated in the LLN environment, but then very little is made > of the topic in the document. >=20 > I think you should have a look at RFC 4107, which should probably one of=20 > your references, and then see whether there is anything you can add, > possibly to Sections 6 and 7. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu Dec 2 06:53: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 6D39928C14D for ; Thu, 2 Dec 2010 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.101 X-Spam-Level: X-Spam-Status: No, score=-110.101 tagged_above=-999 required=5 tests=[AWL=0.498, 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 XEPl9qbMTwWl for ; Thu, 2 Dec 2010 06:53:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8114428C141 for ; Thu, 2 Dec 2010 06:53:43 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAItC90yQ/khNgWdsb2JhbACjIRUBARYiIqdMmw6CcoJVBIpmgxc X-IronPort-AV: E=Sophos;i="4.59,288,1288569600"; d="scan'208";a="70641627" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2010 14:54:53 +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 oB2EsrO6024442; Thu, 2 Dec 2010 14:54:53 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, 2 Dec 2010 15:54:53 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Dec 2010 15:54:52 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <9BB070DB2D281946859EA89837931EEE39861E@EVS4.nam.ci.root> Date: Thu, 2 Dec 2010 15:54:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> <65D305AC-64AB-4ECE-BFF6-17FDB4360DE2@cisco.com> <9BB070DB2D281946859EA89837931EEE39861E@EVS4.nam.ci.root> To: "Tsao, Tzeta" X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Dec 2010 14:54:52.0590 (UTC) FILETIME=[E0174CE0:01CB9230] Cc: draft-ietf-roll-security-framework@tools.ietf.org, ROLL WG , Adrian Farrel Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2010 14:53:45 -0000 Thanks Tzeta and all co-authors. JP. On Dec 2, 2010, at 3:52 PM, Tsao, Tzeta wrote: > Hi, > > The authors appreciate the input and will put out a revision as soon as > possible. > > Thanks, > Tzeta > > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Thursday, December 02, 2010 5:59 AM > To: Tsao, Tzeta > Cc: Adrian Farrel; draft-ietf-roll-security-framework@tools.ietf.org; > ROLL WG > Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework > > Hi > > Do you want to look at the comments and get back to Adrian ? > > Thanks. > > JP. > > On Nov 23, 2010, at 11:38 AM, Adrian Farrel wrote: > >> Hi, >> >> 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 for a very thorough survey of the landscape, and a well written >> document. >> >> Most of my comments are pretty trivial, but a couple have more meat >> on them and 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 gives two warnings about references: >> >> == Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on lines >> 1786, but no explicit reference was found in the text >> >> == Outdated reference: A later version (-14) exists of >> draft-ietf-roll-rpl-11 >> >> --- >> >> I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative >> reference. You may want to look at this to decide whether you can > avoid >> or dilute the reference so that you are not blocked in the RFC Editor >> Queue. >> >> --- >> >> The RFC Editor usually likes the first section in the document to be >> the Introduction. I think you can safely swap the Terminology section >> with the Introduction. >> >> --- >> >> Section 3.2 >> >> Because LLNs are most commonly found on publicly accessible >> shared medium, e.g., air or wiring in a building, and sometimes >> >> s/on/on a/ >> >> --- >> >> Section 3.2 >> >> 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. >> >> I'm not comfortable with "misuse" in the context of integrity. The > term >> suggests to me that the information might be used for illicit purposes >> which I would think ties in with "confidentiality" not "integrity". Am > I >> missing something? >> >> --- >> >> Section 3.2 >> >> In addition, >> integrity also requires 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. >> >> I'm curious that you tie authenticity to the *message* source and >> destination rather than to the *information*. This has been a debate > in >> routing security for some time. Consider an IGP where one could >> authenticate the message exchanges between protocol peers, or one > could >> authenticate the link state information that is being distributed. >> Clearly there are implications for the solution, and the > chain-of-trust >> model of the former may achieve the latter. However, I think that the >> asset is the information not the message, and it is the asset that > must >> be authenticated. >> >> --- >> >> Section 3.2 >> >> It is noted that, besides those captured in the CIA model, assurance >> >> "those" what? >> >> Suggest... >> >> It is noted that, besides those security issues captured in the CIA >> model, assurance >> >> --- >> >> Section 3.2 >> >> Non-repudiation >> >> Reading this section, it seems to me that you have identified non- >> repudiation as a viable threat to ROLL. You have also recognised that >> the traditional mechanisms for discovering it are hard or impossible > to >> apply in a LLN. >> >> That analysis is fine. >> >> But then you go on to say "it is hard, so we won't talk about it"! > This >> doesn't seem to be right. At the very least you should provide an >> analysis of the risks and impact of non-repudiation in ROLL. You can >> then also quantify the issues with applying traditional techniques, > and >> this might motivate people to derive new techniques (or to determine >> that it is not a significant problem in ROLL). >> >> --- >> >> Section 3.3 >> >> As a consequence of these constraints, there is an even more >> critical need than usual for a careful trade study on which and >> >> "trade study"? >> Do you mean "study of trade-offs"? Or just "study"? >> >> --- >> >> Section 3.3 >> >> Highly directional traffic >> Some types of LLNs see a high percentage of their total traffic >> traverse between the nodes and the Lln Border Routers (LBRs) >> >> s/Lln/LLN/ >> >> --- >> >> Section 3.3 >> >> I'm not sure, but I think you should add some emphasis on the ease > with >> which nodes can attach to some LLNs (especially wireless ones). To > some >> extent this might be covered by the "ad hoc" elements in >> Autonomous operations >> and by the bullet item >> Unattended locations and limited physical security >> but I think you should draw this out specifically as it is one of the >> greater security issues that I have heard voiced. >> >> --- >> >> I think that the discussion of key management is a bit weak. The issue >> is identified in Sections 3.3 and 3,4 as something that can be made >> more complicated in the LLN environment, but then very little is made >> of the topic in the document. >> >> I think you should have a look at RFC 4107, which should probably one > of >> your references, and then see whether there is anything you can add, >> possibly to Sections 6 and 7. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Mon Dec 6 08:39: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 5CBB43A6828; Mon, 6 Dec 2010 08:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.13 X-Spam-Level: X-Spam-Status: No, score=-110.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 qkHOtYW8MaRY; Mon, 6 Dec 2010 08:39:02 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A353C3A6838; Mon, 6 Dec 2010 08:38:53 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,305,1288569600"; d="scan'208";a="250595491" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2010 16:40:12 +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 oB6GdbYs025677; Mon, 6 Dec 2010 16:40:12 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, 6 Dec 2010 17:40:11 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Dec 2010 17:40:10 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <20101122163512.4979.96571.idtracker@localhost> Date: Mon, 6 Dec 2010 17:40:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101122163512.4979.96571.idtracker@localhost> To: Philip Levis , Thomas Heide Clausen , Jonathan Hui , Omprakash Gnawali X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 06 Dec 2010 16:40:10.0521 (UTC) FILETIME=[3F861090:01CB9564] Cc: ROLL WG , The IESG , IETF-Announce Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 16:39:06 -0000 Dear Co-authors, Since the IETF Last Call has ended, would you mind updating the document = according to the comments received on the mailing list and post the new revision ? Thanks. JP. On Nov 22, 2010, at 5:35 PM, The IESG wrote: >=20 > The IESG has received a request from the Routing Over Low power and = Lossy > networks WG (roll) to consider the following document: > - 'The Trickle Algorithm' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-12-06. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From pal@cs.stanford.edu Mon Dec 6 09:54: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 ACD2C3A686A for ; Mon, 6 Dec 2010 09:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHgCEvbIjJmQ for ; Mon, 6 Dec 2010 09:54:11 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 79C5C3A685E for ; Mon, 6 Dec 2010 09:54:10 -0800 (PST) Received: from dn0a2101ae.sunet ([10.33.1.174]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PPfHi-0002pY-Bs; Mon, 06 Dec 2010 09:55:34 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 6 Dec 2010 09:55:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101122163512.4979.96571.idtracker@localhost> To: JP Vasseur X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Dec 2010 17:54:15 -0000 On Dec 6, 2010, at 8:40 AM, JP Vasseur wrote: > Dear Co-authors, >=20 > Since the IETF Last Call has ended, would you mind updating the = document according to > the comments received on the mailing list and post the new revision ? >=20 > Thanks. Done. Phil= From jpv@cisco.com Mon Dec 6 23:31: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 2B4F13A691F for ; Mon, 6 Dec 2010 23:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.156 X-Spam-Level: X-Spam-Status: No, score=-110.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 duttVhtLLfwe for ; Mon, 6 Dec 2010 23:31:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 607923A691C for ; Mon, 6 Dec 2010 23:31:46 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,310,1288569600"; d="scan'208";a="388416935" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2010 07:33:10 +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 oB77X208025940; Tue, 7 Dec 2010 07:33:10 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, 7 Dec 2010 08:32:54 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Dec 2010 08:32:53 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Tue, 7 Dec 2010 08:32:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101122163512.4979.96571.idtracker@localhost> To: Philip Levis X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 07 Dec 2010 07:32:53.0665 (UTC) FILETIME=[F5A53910:01CB95E0] Cc: ROLL WG , Thomas Heide Clausen Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2010 07:31:47 -0000 Thanks Phil ... but I do not see the rev 06 ? Thanks. JP. On Dec 6, 2010, at 6:55 PM, Philip Levis wrote: >=20 > On Dec 6, 2010, at 8:40 AM, JP Vasseur wrote: >=20 >> Dear Co-authors, >>=20 >> Since the IETF Last Call has ended, would you mind updating the = document according to >> the comments received on the mailing list and post the new revision ? >>=20 >> Thanks. >=20 > Done. >=20 > Phil From jpv@cisco.com Mon Dec 6 23:51: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 ED20B3A6926 for ; Mon, 6 Dec 2010 23:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPKrGLfc-SEY for ; Mon, 6 Dec 2010 23:51:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 374B33A6923 for ; Mon, 6 Dec 2010 23:51:28 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Diff-metrics-12-13.webarchive, draft-ietf-roll-routing-metrics-13.txt : 313397, 66483 X-IronPort-AV: E=Sophos;i="4.59,310,1288569600"; d="txt'?scan'208,217";a="189795243" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2010 07:52:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id oB77qcI3012326; Tue, 7 Dec 2010 07:52:49 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); Tue, 7 Dec 2010 08:52:45 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Dec 2010 08:52:40 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-165--131453421 From: JP Vasseur In-Reply-To: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> Date: Tue, 7 Dec 2010 08:52:39 +0100 Message-Id: References: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> To: Adrian.Farrel@huawei.com X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 07 Dec 2010 07:52:40.0160 (UTC) FILETIME=[B8D9FE00:01CB95E3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17814.005 X-TM-AS-Result: No--25.397000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Mon, 06 Dec 2010 23:53:06 -0800 Cc: roll@ietf.org, draft-ietf-roll-routing-metric@tools.ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2010 07:51:35 -0000 --Apple-Mail-165--131453421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrian, On Nov 26, 2010, at 9:29 AM, Adrian Farrel wrote: > Hi, >=20 > I have performed an AD review of your draft. >=20 Thanks ! > Don't panic! >=20 Ah ok ;-) > 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. >=20 > Thanks for an important component of the RPL family. >=20 > Most of my comments are pretty trivial, but a couple have more meat > on them and 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. >=20 Perfect - see below (skipping all issues that have been addressed in the = new revision) > Of course, all of my issues are up for discussion. >=20 > Thanks for the work, > Adrian >=20 > --- >=20 > I am slightly worried about the complexity inherent in this spec. > Although individual implementations and deployments might choose to = use > a very limited subset of the available (and flexible) options, it = seems > that an implementation must support a much wider subset of options, > metrics, and constraints in order to be deployable into a wide range = of > networks. >=20 > Does this flexibility impact simplicity of implementation? >=20 JP> We do do not think so. Actually in most cases, implementations will = implementation a very small subset of the metrics/constraints. We have a number of = choices and options here, to address the requirements spelled out in the requirement RFCs = but again it is neither expected NOR required for an implementation to implement them all but = certainly each of=20 the metric/constraint/feature is justified by a specific = requirement.That being said, I have=20 been told that some implementations did implement them all. > Section 1 >=20 > It must be noted that the use of dynamic metrics is not new and has > been experimented in ARPANET 2. The use of dynamic metrics is not > trivial and great care must be given to the use of dynamic metrics > since it may lead to potential routing instabilities. That being > said, lots of experience has been gained over the years on the use = of > dynamic routing metrics, which have been deployed in a number of = (non > IP) networks. >=20 > Can you add a couple of references? One for ARPANET 2 experimentation, Added: [Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of=20 the Revised Routing Metric for ARPANET and MILNET.=20 Submitted to MILCOM 89, March 1989 > and one for the "lots of experience gained". >=20 A bit more difficult ... people skills in the art would know but ... = most are deployed proprietary systems ... > --- >=20 > Use of RFC 2119 language. >=20 > The first use (SHOULD) shows up late in Section 1 after a number of > lower case "must". I think that the best way to smooth this out is to > not use any 2119 language in the Introduction. >=20 Indeed, good catch, thanks. > Figure 1 >=20 > This is a copy of figure 22 in draft-ietf-roll-rpl. > I strongly recommend that you do not duplicate protocol bit/byte > definitions as this can lead to accidental discrepancies. Why not > replace this figure with a reference? >=20 > --- >=20 > Bit numberings in fields. Please align the numbers so that we > count bits in base 10. >=20 JP> IF ok with you, I'd rather leave it here, since the RPL document is = fairly large, this is to avoid too much work jumping between the two documents. > Section 2.1 >=20 > I think the A flag needs a little more constraint. Not only is it only > valid when C=3D1 (as stated), but it is only valid when R=3D0. >=20 > Also > OLD > and MUST be written to 0x00. > NEW > and MUST be set to 0x00 and MUST be ignored on receipt. > END >=20 JP> Yes, thanks. > --- >=20 > Section 2.1 >=20 > Unrecognized TLVs MUST be ignored. >=20 > Do you want to clarify that "ignoring" includes leaving the TLVs in > place in the object when it is forwarded along the DAG? >=20 JP> Clarified. > --- >=20 > Section 2.2 >=20 > Have you considered the case that the recording of metrics causes the > Routing Metric/Constraint object to overflow? >=20 JP> Yes, this is clarified in the RPL spec, allowing for multiple DAG = Metric container. Still I added few words. > -- >=20 > Section 3.1 >=20 > The NSA object MAY be present in the DAG Metric Container. There > MUST be no more than one NSA object as a constraint per DAG Metric > Container, and no more than one NSA object as a metric per DAG = Metric > Container. >=20 > This is fine, but you will need to define somewhere what happens when > a formatting error is detected. This can either be done on a case-by- > case basis, or can be a general statement in Section 3. JP> I added some text, thanks (Section 3): "The sections 3. and 4. = specify several=20 link and node metric/constraint objects. In some cases it is stated that = there must not=20 be more than one object of a specific type. In that case, if an RPL = implementation=20 receives more than one objet of that type, the second objet MUST = silently be ignored. " >=20 > See also, Section 3.2 >=20 > The NE object MAY be present in the DAG Metric Container. There = MUST > be no more than one NE object as a constraint per DAG Metric > Container, and no more than one NE object as a metric per DAG Metric > Container. >=20 > etc., etc. >=20 > Incidentally, it might be more graceful to use "MUST NOT" instead of > "MUST". For example: >=20 > OLD > The HP object MAY be present in the DAG Metric Container. There = MUST > be no more than one HP object as a constraint per DAG Metric > Container, and no more than one HP object as a metric per DAG Metric > Container. > NEW > The HP object MAY be present in the DAG Metric Container. There = MUST > NOT be more one HP object as a constraint per DAG Metric Container, > and there MUST NOT be more than one HP object as a metric per DAG > Metric Container. > END All fixed. >=20 > Section 3.1 >=20 > Is IANA expected to track the flags in the NSA object? Yes this is in Section 6.3. >=20 > Are the Type values for the TLVs chosen from a common registry across > all objects, or is there a separate registry for each object? >=20 Good catch ! Section added in IANA for a *common* registry for all TLVs. > --- >=20 > Section 3.2 >=20 > Whenever possible, a node with low residual energy should not be > selected as a router >=20 > Do you have a reference for this? JP> I reworded the text, since such decision will either be OF specific = or driven by local policy. Thanks. >=20 > --- >=20 > Section 3.2 >=20 > Given the complexity of trying to address such a broad collection of > constraints, this document defines three levels of fidelity in the > solution. >=20 > I only find two levels defined in the section: > - The simplest solution relies on a 2-bit field > - The mid-complexity solution is a single parameter >=20 > Did I miss one, or did you? We used to work on 3, and lead to two ... Forgot to update the text, = done, thanks. >=20 > --- >=20 > Section 3.2 >=20 > For scavenging nodes, the 8 bit quantity is the power > provided by the scavenger divided by the power consumed by the > application, H=3DP_in/P_out, in units of percent. >=20 > and >=20 > For > battery powered devices, H is the current expected lifetime divided > by the desired minimum lifetime. >=20 > Is the second case also expressed as a percentage? Yes (added), thanks. >=20 > --- >=20 > Section 3.2 >=20 > I'm slightly confused by the difference (or not) between the term 'H' > and the term 'E-E'. Firstly, E-E looks like an arithmetic expression. > But, more to the point, I *think* you put the value of H in the field > E-E, so why have two names for the same thing? >=20 JP> Indeed, using one term: E-E > --- >=20 > Objects, sub-objects, and TLVs >=20 > I think you have some inconsistency in naming. >=20 > At the top level we have "Routing Metric/Constraint object" > The "object body" of this object is defined as: > The object body carries one or more sub-objects defined later in = this > document. > So I expect everything that follows in Sections 3 and 4 to be termed > sub-objects. Not always, for example, when there is one header followed by the main = body,=20 it is called an object. When there might be more than one (for example = when=20 recording several link ETX, we may have multiple sub-objects after the = header). > But you have also termed these things as "objects". >=20 > Some of the objects/sub-objects in Sections 3 and 4 can, themselves = have > sub-objects, while others launch straight into contained TLVs. >=20 > This is all a bit confusing (although there is nothing technically > wrong) and it would be really nice to achieve some consistency of > terminology. >=20 > --- >=20 > Section 3.2 >=20 > The format of the NE sub-object body is as follows: >=20 > And what Type value does this sub-object use? >=20 The NE object Type is to be assigned by IANA (recommended value=3D2) > --- >=20 > Section 3.2 >=20 > o T (node Type): 2-bit field indicating the node type. E=3D0x00 > designates a mains-powered node, E=3D0x01 a battery-powered node = and > E=3D0x02 a node powered by an energy scavenger. >=20 > Do you mean T=3D0x00 etc.? >=20 JP> indeed ! Thanks. > -- >=20 > =20 > --- >=20 > Section 3.3 >=20 > The HP object may be used as a constraint or a metric. When used as > a constraint, the DAG root indicates the maximum number of hops that > a path may traverse. When that number is reached, no other node can > join that path. When used as a metric, each visited node simply > increments the Hop Count field. >=20 > Are you counting nodes or hops? > Does the first node send the Hop Count as one or zero? >=20 Text added to include the first node. > --- >=20 > Section 3.3 >=20 > It looks to me that if the object is used as a constraint, it MUST = also > be present as a metric. This seems to be different from the burble at > the top of the section. (and obviously, we can think of more optimal > ways of signaling this - such as decrementing the hop count at each > hop). JP> Not sure why ... you could use it as a constraint (say to avoid too = much of delays if you know that the number of traversed hop may be an issue) = and still want to optimize against another metric such as the bandwidth ? >=20 > --- >=20 > Section 4.1 >=20 > For the deeply duty-cycled links > found in many LLNs >=20 > Will this term be clear to the reader? >=20 JP> Yes I do think so.=20 > --- >=20 > Section 4.1 >=20 > With special reference to my comment (above) about objects, = sub-objects, > and TLVs, it is really not helpful to have an object (which is = actually > a sub-object) and a sub-object of that object both called Throughput! >=20 > --- >=20 > Section 4.1 >=20 > Figure 9: Throughput sub-object format >=20 > And what Type value does this sub-object use? > But, I might ask why you need sub-objects when the content is = well-known > to be 32-bit values, and the parent object has a length field. >=20 > --- >=20 > Section 4.1 >=20 > Throughput: 32 bits. The Throughput is encoded in 32 bits in > unsigned integer format, expressed in bytes per second. >=20 > Are you sure this is enough? Yes, it seems like it today. How future- > proof is this? JP> 2^32 is huge ? >=20 > --- > Section 4.2 >=20 > Ditto object and sub-object names. > Ditto sub-object Type value. >=20 JP> XXXX > --- >=20 > Section 4.2 >=20 > Again, it looks like the use of this object as a constraint is only > possible if it is also used as a metric. JP> Same comment as for the hop-count. It does not have to be used as a = metric when also used as a constraint. > So (again) it looks like the > rules for object presence are broken. >=20 > But that depends how it is used as a constraint! It might be used to > mean that no link with unsatisfactory latency may be added to the DAG, > or it might mean that the cumulative latency must not grow beyond the > the constrained limit. >=20 > You need to clarify meaning and usage. >=20 > --- >=20 > Section 4.3 >=20 > Note that an RPL implementation MAY either use the LQL, the ETX or > both. >=20 > This immediately makes me worry about interoperability. JP> But we have different object ... the reason being that depending on = the deployment, we may either use the LQL or the ETX .... >=20 > --- >=20 > Section 4.3.1 >=20 > By contrast, the LQL link metric may be > aggregated, in which case the sum of all LQLs may be reported > (additive metric) >=20 > How can this possibly be useful? Unless you know how many hops are > traversed, the aggregate is meaningless! >=20 JP> This is correct. That being said, we wanted to leave it there, since it could be useful in some specific scenario (for example, you may use two values, 0 (good) 1 (bad), in which cases it provides you the number of bad links traversed, a metric that you could use to select your = path). > --- >=20 > Section 4.3.1 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > | Res | LQL sub-object > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >=20 > The Res field does not appear to be described. >=20 JP> Added (elsewhere too). > --- >=20 > Section 4.3.1 >=20 > It seems to me that a type 0x02 aggregation is not very helpful = because > "unknown" will hide the otherwise 'best' link quality. >=20 > But maybe this doesn't matter because 'worst' link quality is more > interesting. JP> Correct this is one of the cases where this is useful indeed. >=20 > --- >=20 > Section 4.4.1 >=20 > Ditto Res field >=20 JP> Added. > --- >=20 > Section 4.4.1 >=20 > How come the LC field in the two sub-objects have different sizes? >=20 JP> Oops ! Fixed. Thanks. > --- >=20 > Section 4.4.1 >=20 > The use of the LC object is outside the scope of this document. >=20 > It seems to me you have gone off half cocked :-( >=20 JP> Poorly worded ... It should read "it is left to the implementer to = define the meaning of each bit of the 10-bit Link Color Flag field". The use itself is = clearly defined. Thanks. Text added. > There is some description at the top of the section that implies a > little about how LC is used. It seems closer to a color (a la ToS) = than > to a bit array (a la resource affinities). JP> You're right and this is aimed at being used as a flag field, a la = resource affinities. I clarified the text. >=20 > If you are determined that this is out of scope for your document, I > wonder why the object is defined, and I wonder why the section has > preamble on the use of the meaning of LC. And I really wonder about = the > presence of section 4.4.2. >=20 > --- >=20 > Section 6 >=20 > There doesn't seem to be any tracking of sub-object Type values. As proposed earlier, let's have a common directory for all = constraints/metrics object. And cal them object if if the case where they are carried in other = object. Same reasoning applies to the TLV case (not that in the case of OSPF and ISIS we also = have discrepancies, some protocols called sub-TLV, a TLV carried within a TLV, other = protocol using the same=20 term regardless on whether or not the TLV is carried within another TLV = or not. This way, no need to add another registry, we can use the one defined in = Section 6.1. I added a common registry for the TLV in Section 6.2. >=20 > --- >=20 > Section 7 >=20 > You really need a reference to draft-ietf-roll-security-framework. >=20 > I think that you made a key security comment in a previous section = where > you said that it is recommended that the algorithms used do not cause > excess information flapping. A significant security attack might be > mounted by periodically attacking the quality of a link resulting in = the > routing protocol flapping. This would cause wider damage than simply > the disruption to the local link. Excellent point. I did not explicitly point to the security framework = since it does not explicitly cover the routing metrics but I propose adding the following = text: "Another=20 attack may consist of making intermitment attacks on a link in an = attempt to constantly=20 modify the link quality and consequently the associated routing metric, = thus leading to=20 potential fluctuation in the DAG. It is thus RECOMMENDED for a RPL = implementation=20 to put in place mechanism so as to stop advertising routing metrics for = highly unstable=20 links that may be subject to attacks." Let me know if that's OK. Thanks again for the detailed review. Cheers. JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-165--131453421 Content-Type: multipart/mixed; boundary=Apple-Mail-166--131453421 --Apple-Mail-166--131453421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Adrian,

On Nov 26, 2010, at 9:29 AM, Adrian Farrel = wrote:

Hi,

I have performed an AD review of your = draft.


Thanks = !

Don't = panic!


Ah ok = ;-)

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 = for an important component of the RPL family.

Most of my comments = are pretty trivial, but a couple have more meat
on them and 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.


Perfect - see = below (skipping all issues that have been addressed in the new = revision)

Of course, all of my = issues are up for discussion.

Thanks for the = work,
Adrian

---

I am slightly worried about the = complexity inherent in this spec.
Although individual implementations = and deployments might choose to use
a very limited subset of the = available (and flexible) options, it seems
that an implementation = must support a much wider subset of options,
metrics, and constraints = in order to be deployable into a wide range of
networks.

Does = this flexibility impact simplicity of = implementation?


JP> We = do do not think so. Actually in most cases, implementations will = implementation
a very small subset of the metrics/constraints. = We have a number of choices and options
here, to address the = requirements spelled out in the requirement RFCs but again it is = neither
expected NOR required for an implementation to = implement them all but certainly each of 
the = metric/constraint/feature is justified by a specific requirement.That = being said, I have 
been told that some implementations = did implement them all.

Section = 1

  It must be noted that the use of dynamic metrics = is not new and has
  been experimented in ARPANET 2. =  The use of dynamic metrics is not
  trivial and = great care must be given to the use of dynamic metrics
=   since it may lead to potential routing instabilities. =  That being
  said, lots of experience has been = gained over the years on the use of
  dynamic routing = metrics, which have been deployed in a number of (non
=   IP) networks.

Can you add a couple of references? One = for ARPANET 2 = experimentation,

Added:

[Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. = "Performance of 
           =      the Revised Routing Metric for ARPANET and = MILNET. 
             =    Submitted to MILCOM 89, March = 1989


and = one for the "lots of experience = gained".


A bit more = difficult ... people skills in the art would know but ... most are = deployed proprietary
systems ...

---

Use of RFC 2119 language.

The first = use (SHOULD) shows up late in Section 1 after a number of
lower case = "must". I think that the best way to smooth this out is to
not use = any 2119 language in the = Introduction.


Indeed, good = catch, thanks.

Figure = 1

This is a copy of figure 22 in draft-ietf-roll-rpl.
I = strongly recommend that you do not duplicate protocol = bit/byte
definitions as this can lead to accidental discrepancies. = Why not
replace this figure with a reference?

---

Bit = numberings in fields. Please align the numbers so that we
count bits = in base 10.


JP> IF ok = with you, I'd rather leave it here, since the RPL document is = fairly
large, this is to avoid too much work jumping between = the two documents.

Section = 2.1

I think the A flag needs a little more constraint. Not only = is it only
valid when C=3D1 (as stated), but it is only valid when = R=3D0.

Also
OLD
     and MUST be = written to 0x00.
NEW
     and MUST be = set to 0x00 and MUST be ignored on = receipt.
END


JP> = Yes, thanks.

---

Section = 2.1

  Unrecognized TLVs MUST be ignored.

Do you = want to clarify that "ignoring" includes leaving the TLVs in
place in = the object when it is forwarded along the = DAG?


JP> = Clarified.

---

Section = 2.2

Have you considered the case that the recording of metrics = causes the
Routing Metric/Constraint object to = overflow?


JP> Yes, this = is clarified in the RPL spec, allowing for multiple DAG Metric = container.
Still I added few words.

--

Section 3.1

  The NSA = object MAY be present in the DAG Metric Container.  There
=   MUST be no more than one NSA object as a constraint per DAG = Metric
  Container, and no more than one NSA object as a = metric per DAG Metric
  Container.

This is fine, = but you will need to define somewhere what happens when
a formatting = error is detected. This can either be done on a case-by-
case basis, = or can be a general statement in Section = 3.

JP> I added some text, = thanks (Section 3): "The sections 3. and 4. specify = several 
link and node metric/constraint objects. = In some cases it is stated that there must not 
be = more than one object of a specific type. In that case, if an RPL = implementation 
receives more than one objet of = that type, the second objet MUST silently be ignored. = "


See also, Section = 3.2

  The NE object MAY be present in the DAG Metric = Container.  There MUST
  be no more than one NE = object as a constraint per DAG Metric
  Container, and no = more than one NE object as a metric per DAG Metric
=   Container.

etc., etc.

Incidentally, it might = be more graceful to use "MUST NOT" instead of
"MUST". For = example:

OLD
  The HP object MAY be present in the = DAG Metric Container.  There MUST
  be no more than = one HP object as a constraint per DAG Metric
  Container, = and no more than one HP object as a metric per DAG Metric
=   Container.
NEW
  The HP object MAY be = present in the DAG Metric Container.  There MUST
=   NOT be more one HP object as a constraint per DAG Metric = Container,
  and there MUST NOT be more than one HP object = as a metric per DAG
  Metric = Container.
END

All = fixed.


Section 3.1

Is = IANA expected to track the flags in the NSA = object?

Yes this is in Section = 6.3.


Are the Type values for = the TLVs chosen from a common registry across
all objects, or is = there a separate registry for each = object?


Good catch ! = Section added in IANA for a *common* registry for all = TLVs.

---

Section = 3.2

  Whenever possible, a node with low residual = energy should not be
  selected as a router

Do you = have a reference for = this?

JP> I reworded the = text, since such decision will either be OF specific or driven by = local policy. Thanks.


---

Section 3.2

  Given = the complexity of trying to address such a broad collection of
=   constraints, this document defines three levels of fidelity = in the
  solution.

I only find two levels defined = in the section:
- The simplest solution relies on a 2-bit field
- = The mid-complexity solution is a single parameter

Did I miss one, = or did you?

We used to work on = 3, and lead to two ... Forgot to update the text, done, = thanks.


---

Section = 3.2

  For scavenging nodes, the 8 bit quantity is the = power
  provided by the scavenger divided by the power = consumed by the
  application, H=3DP_in/P_out, in units of = percent.

and

  For
  battery = powered devices, H is the current expected lifetime divided
=   by the desired minimum lifetime.

Is the second case = also expressed as a = percentage?

Yes (added), = thanks.


---

Section = 3.2

I'm slightly confused by the difference (or not) between the = term 'H'
and the term 'E-E'. Firstly, E-E looks like an arithmetic = expression.
But, more to the point, I *think* you put the value of H = in the field
E-E, so why have two names for the same = thing?


JP> Indeed, = using one term: E-E

---

Objects, sub-objects, and TLVs

I = think you have some inconsistency in naming.

At the top level we = have "Routing Metric/Constraint object"
The "object body" of this = object is defined as:
  The object body carries one or = more sub-objects defined later in this
  document.
So I = expect everything that follows in Sections 3 and 4 to be = termed
sub-objects.

Not = always, for example, when there is one header followed by the main = body, 
it is called an object. When there might be more = than one (for example when 
recording several link ETX, = we may have multiple sub-objects after the header).

But you have also termed these things as = "objects".

Some of the objects/sub-objects in Sections 3 and 4 = can, themselves have
sub-objects, while others launch straight into = contained TLVs.

This is all a bit confusing (although there is = nothing technically
wrong) and it would be really nice to achieve = some consistency = of
terminology.

---

Section 3.2

  The format = of the NE sub-object body is as follows:

And what Type value does = this sub-object use?


The = NE object Type is to be assigned by IANA (recommended = value=3D2)

---

Section = 3.2

  o  T (node Type): 2-bit field indicating = the node type.  E=3D0x00
=      designates a mains-powered node, E=3D0x01 = a battery-powered node and
     E=3D0x02 a = node powered by an energy scavenger.

Do you mean T=3D0x00 = etc.?


JP> indeed ! = Thanks.

--

 
---

Section 3.3

=   The HP object may be used as a constraint or a metric. =  When used as
  a constraint, the DAG root indicates = the maximum number of hops that
  a path may traverse. =  When that number is reached, no other node can
=   join that path.  When used as a metric, each visited = node simply
  increments the Hop Count field.

Are = you counting nodes or hops?
Does the first node send the Hop Count as = one or zero?


Text added to = include the first node.

---

Section 3.3

It looks to me that if = the object is used as a constraint, it MUST also
be present as a = metric. This seems to be different from the burble at
the top of the = section. (and obviously, we can think of more optimal
ways of = signaling this - such as decrementing the hop count at = each
hop).

JP> Not sure = why ... you could use it as a constraint (say to avoid too = much
of delays if you know that the number of traversed hop = may be an issue) and
still want to optimize against another = metric such as the bandwidth ?


---

Section 4.1

  For = the deeply duty-cycled links
  found in many = LLNs

Will this term be clear to the = reader?


JP> Yes I do = think so. 

---

Section= 4.1

With special reference to my comment (above) about objects, = sub-objects,
and TLVs, it is really not helpful to have an object = (which is actually
a sub-object) and a sub-object of that object both = called Throughput!

---

Section 4.1

  Figure 9: = Throughput sub-object format

And what Type value does this = sub-object use?
But, I might ask why you need sub-objects when the = content is well-known
to be 32-bit values, and the parent object has = a length field.

---

Section 4.1

=   Throughput: 32 bits.  The Throughput is encoded in 32 = bits in
  unsigned integer format, expressed in bytes per = second.

Are you sure this is enough? Yes, it seems like it today. = How future-
proof is = this?

JP> 2^32 is huge = ?


---
Section = 4.2

Ditto object and sub-object names.
Ditto sub-object Type = value.


JP> = XXXX

---

Section = 4.2

Again, it looks like the use of this object as a constraint = is only
possible if it is also used as a metric. =

JP> Same comment as for the = hop-count. It does not have to be used as a metric
when also = used as a constraint.

So (again) = it looks like the
rules for object presence are broken.

But = that depends how it is used as a constraint! It might be used to
mean = that no link with unsatisfactory latency may be added to the DAG,
or = it might mean that the cumulative latency must not grow beyond = the
the constrained limit.

You need to clarify meaning and = usage.

---

Section 4.3

  Note that an = RPL implementation MAY either use the LQL, the ETX or
=   both.

This immediately makes me worry about = interoperability.

JP> But = we have different object ... the reason being that depending on the = deployment,
we may either use the LQL or the ETX = ....


---

Section = 4.3.1

  By contrast, the LQL link metric may be
=   aggregated, in which case the sum of all LQLs may be = reported
  (additive metric)

How can this possibly = be useful? Unless you know how many hops are
traversed, the aggregate = is meaningless!


JP> = This is correct. That being said, we wanted to leave it there, = since
it could be useful in some specific scenario (for = example, you may use
two values, 0 (good) 1 (bad), in which = cases it provides you the number
of bad links traversed, a = metric that you could use to select your path).

---

Section 4.3.1

=     0 =             &n= bsp; 1 =             &n= bsp; 2 =             &n= bsp; 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4
=    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ...
   |       Res =     | LQL sub-object
=    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ...

The Res field does not appear to be = described.


JP> Added = (elsewhere too).

---

Section 4.3.1

It seems to me that a = type 0x02 aggregation is not very helpful because
"unknown" will hide = the otherwise 'best' link quality.

But maybe this doesn't matter = because 'worst' link quality is = more
interesting.

JP> = Correct this is one of the cases where this is useful = indeed.


---

Section = 4.4.1

Ditto Res = field


JP> = Added.

---

Section = 4.4.1

How come the LC field in the two sub-objects have different = sizes?


JP> Oops ! = Fixed. Thanks.

---

Section = 4.4.1

  The use of the LC object is outside the scope = of this document.

It seems to me you have gone off half cocked = :-(


JP> Poorly worded = ... It should read "it is left to the implementer to define the = meaning
of each bit of the 10-bit Link Color Flag field". The = use itself is clearly defined. Thanks.
Text = added.

There is some description = at the top of the section that implies a
little about how LC is used. = It seems closer to a color (a la ToS) than
to a bit array (a la = resource affinities).

JP> = You're right and this is aimed at being used as a flag field, a la = resource affinities.
I clarified the = text.


If you are determined = that this is out of scope for your document, I
wonder why the object = is defined, and I wonder why the section has
preamble on the use of = the meaning of LC. And I really wonder about the
presence of section = 4.4.2.

---

Section 6

There doesn't seem to be any = tracking of sub-object Type = values.

As proposed earlier, = let's have a common directory for all constraints/metrics = object.
And cal them object if if the case where they are = carried in other object. Same reasoning
applies to the TLV = case (not that in the case of OSPF and ISIS we also have = discrepancies,
some protocols called sub-TLV, a TLV carried = within a TLV, other protocol using the same 
term = regardless on whether or not the TLV is carried within another TLV or = not.

This way, no need to add another registry, = we can use the one defined in Section 6.1.
I added a common = registry for the TLV in Section 6.2.


---

Section 7

You really need a = reference to draft-ietf-roll-security-framework.

I think that you = made a key security comment in a previous section where
you said that = it is recommended that the algorithms used do not cause
excess = information flapping. A significant security attack might be
mounted = by periodically attacking the quality of a link resulting in = the
routing protocol flapping. This would cause wider damage than = simply
the disruption to the local = link.

Excellent point. I did = not explicitly point to the security framework since it does = not
explicitly cover the routing metrics but I propose adding = the following text: "Another 
attack may = consist of making intermitment attacks on a link in an attempt to = constantly 
modify the link quality and = consequently the associated routing metric, thus leading = to 
potential fluctuation in the DAG. It is thus = RECOMMENDED for a RPL implementation 
to put in = place mechanism so as to stop advertising routing metrics for highly = unstable 
links that may be subject to = attacks."

Let me know if that's = OK.

Thanks again for the detailed = review.

= --Apple-Mail-166--131453421 Content-Disposition: attachment; filename=Diff-metrics-12-13.webarchive Content-Type: application/x-webarchive; name="Diff-metrics-12-13.webarchive" Content-Transfer-Encoding: quoted-printable bplist00=D2=01=02=03=0D_=10=0FWebSubresources_=10=0FWebMainResource=A1=04=D4= =05=06=07=08=09=0A=0B=0C= _=10=0FWebResourceData_=10=13WebResourceMIMEType_=10=13WebResourceResponse= ^WebResourceURLO=11=036BM6=03=00=00=00=00=00=006=00=00=00(=00=00=00=10=00=00= =00=10=00=00=00=01=00=18=00=00=00=00=00=00=03=00=00a=0F=00=00a=0F=00=00=00= =00=00=00=00=00=00=00=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=A0=A0=A0=FF=FF=FF=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=00=00=00=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0E=D9=FFE=D9=FFE=D9=FFE=D9=FFE=D9= =FFE=D9=FFE=D9=FFE=D9=FF=00=00=00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0E=D9=FFE=D9=FF=FF=FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=00=00=00=00=00=00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0E=D9=FF= E=D9=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=FF=FF=FFE=D9=FF=00=00=00=A0=A0=A0=A0=A0=A0E=D9=FFE=D9=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=FF=FF=FF=FF=FF=FF= =A0=A0=A0E=D9=FF=00=00=00E=D9=FFE=D9=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=A0= =A0=A0E=D9=FFE=D9=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=A0=A0=A0=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF\image/x-iconO=11=02=14bplist00=D4=01=02= =03=04=05=0656X$versionX$objectsY$archiverT$top=12=00=01=86=A0=AB=07=08=1F= %&-=1E./01U$null=DB=09=0A=0B=0C=0D= =0E=0F=10=11=12=13=14=15=16=17=18=19=1A=1B=1C=18=1ER$6R$2R$7R$3R$8V$classR= $4R$9R$0R$5R$1=80=07=10=07=80=08=80=02=80=06=80=0A=80=05=80=09=10=08=80=06= =10=00=D3=0E=20= !"#$[NS.relativeWNS.base=80=04=80=03=80=00_=10!http://tools.ietf.org/favic= on.ico=D2'()*Z$classnameX$classesUNSURL=A2+,UNSURLXNSObject#A=B2=AE=1F=0B= >=9C=CB\image/x-iconP#=7F=EF=FF=FF=FF=FF=FF=FF=D2'(23]NSURLResponse=A24,]N= SURLResponse_=10=0FNSKeyedArchiver=D178_=10=13WebResourceResponse=80=01=00= =08=00=11=00=1A=00#=00-=002=007=00C=00I=00`=00c=00f=00i=00l=00o=00v=00y=00= |=00=7F=00=82=00=85=00=87=00=89=00=8B=00=8D=00=8F=00=91=00=93=00=95=00=97=00= =99=00=9B=00=A2=00=AE=00=B6=00=B8=00=BA=00=BC=00=E0=00=E5=00=F0=00=F9=00=FF= =01=02=01=08=01=11=01=1A=01'=01(=011=016=01D=01G=01U=01g=01j=01=80=00=00=00= =00=00=00=02=01=00=00=00=00=00=00=009=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=01=82_=10!http://tools.ietf.org/favicon.ico=D5=0E=0F=05=06=08=10=11=12= =13=14_=10=14WebResourceFrameName_=10=1BWebResourceTextEncodingNamePUUTF-8= O=12=00=04=C1>=20=0A=20=20=20=0A=20=20=20=0A=20=20= Diff:=20draft-ietf-roll-routing-metrics-12.txt=20-=20= draft-ietf-roll-routing-metrics-13.txt=20=0A=20=20=20=0A=20=20=20=20body=20=20=20=20{=20margin:=200.4ex;=20= margin-right:=20auto;=20}=20=0A=20=20=20=20tr=20=20=20=20=20=20{=20}=20=0A= =20=20=20=20td=20=20=20=20=20=20{=20white-space:=20pre;=20font-family:=20= monospace;=20vertical-align:=20top;=20font-size:=200.86em;}=20=0A=20=20=20= =20th=20=20=20=20=20=20{=20font-size:=200.86em;=20}=20=0A=20=20=20=20= .small=20=20{=20font-size:=200.6em;=20font-style:=20italic;=20= font-family:=20Verdana,=20Helvetica,=20sans-serif;=20}=20=0A=20=20=20=20= .left=20=20=20{=20background-color:=20#EEE;=20}=20=0A=20=20=20=20.right=20= =20{=20background-color:=20#FFF;=20}=20=0A=20=20=20=20.diff=20=20=20{=20= background-color:=20#CCF;=20}=20=0A=20=20=20=20.lblock=20{=20= background-color:=20#BFB;=20}=20=0A=20=20=20=20.rblock=20{=20= background-color:=20#FF8;=20}=20=0A=20=20=20=20.insert=20{=20= background-color:=20#8FF;=20}=20=0A=20=20=20=20.delete=20{=20= background-color:=20#ACF;=20}=20=0A=20=20=20=20.void=20=20=20{=20= background-color:=20#FFB;=20}=20=0A=20=20=20=20.cont=20=20=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.linebr=20{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.lineno=20{=20color:=20= red;=20background-color:=20#FFF;=20font-size:=200.7em;=20text-align:=20= right;=20padding:=200=202px;=20}=20=0A=20=20=20=20.elipsis{=20= background-color:=20#AAA;=20}=20=0A=20=20=20=20.left=20.cont=20{=20= background-color:=20#DDD;=20}=20=0A=20=20=20=20.right=20.cont=20{=20= background-color:=20#EEE;=20}=20=0A=20=20=20=20.lblock=20.cont=20{=20= background-color:=20#9D9;=20}=20=0A=20=20=20=20.rblock=20.cont=20{=20= background-color:=20#DD6;=20}=20=0A=20=20=20=20.insert=20.cont=20{=20= background-color:=20#0DD;=20}=20=0A=20=20=20=20.delete=20.cont=20{=20= background-color:=20#8AD;=20}=20=0A=20=20=20=20.stats,=20.stats=20td,=20= .stats=20th=20{=20background-color:=20#EEE;=20padding:=202px=200;=20}=20=0A= =20=20=20=0A=20=0A=20=20=20=0A=20=20< draft-ietf-roll-routing-metrics-12.txt = =20 draft-ietf-roll-routing-metrics-13.txt >=20=0A=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20Networking=20= Working=20Group=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=20JP.=20Vasseur,=20Ed.=20= Networking=20Working=20Group=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= =20JP.=20Vasseur,=20Ed.=0A=20=20=20=20=20=20Internet-Draft=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=20Cisco=20Systems,=20Inc=20Internet-Draft=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= Cisco=20Systems,=20Inc=0A=20=20=20=20=20=20Intended=20status:=20Standards=20= Track=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=20M.=20Kim,=20Ed.=20Intended=20status:=20Standards=20Track=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=20M.=20= Kim,=20Ed.=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20Expires:=20May=2012,=20= 2011=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Corporate=20Technology=20Group,=20KT=20Expires:=20June=205,=20= 2011=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Corporate=20Technology=20Group,=20KT=0A=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=20K.=20Pister=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=20K.=20Pister=0A=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= Dust=20Networks=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=20Dust=20Networks=0A=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=20N.=20Dejean=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=20N.=20Dejean=0A=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= Coronis=20SAS=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=20Coronis=20SAS=0A=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= =20D.=20Barthel=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=20D.=20Barthel=0A=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=20France=20Telecom=20= Orange=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=20France=20Telecom=20= Orange=0A=20=20=20= =20=20=20=0A=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=20November=208,=20= 2010=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=20December=206,=202010=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20Routing=20Metrics=20used=20for=20Path=20= Calculation=20in=20Low=20Power=20and=20Lossy=20=20=20=20=20Routing=20Metrics=20used=20for=20Path=20= Calculation=20in=20Low=20Power=20and=20Lossy=0A=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= Networks=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= Networks=0A=20=20=20= =20=20=20=0A=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= draft-ietf-roll-routing-metrics-12=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= draft-ietf-roll-routing-metrics-13=0A=20=20=20=20=20=20= =20=0A=20=20=20=20=20=20Abstract=20Abstract=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Low=20power=20and=20Lossy=20Networks=20(LLNs)=20= have=20unique=20characteristics=20=20= =20=20Low=20power=20and=20Lossy=20Networks=20(LLNs)=20have=20unique=20= characteristics=0A= =20=20=20=20=20=20=20=20=20compared=20with=20traditional=20wired=20and=20= ad-hoc=20networks=20that=20require=20the=20=20=20=20compared=20with=20traditional=20wired=20and=20= ad-hoc=20networks=20that=20require=20the=0A=20=20=20=20=20=20=20=20=20specification=20of=20= new=20routing=20metrics=20and=20constraints.=20=20By=20contrast=20= =20=20=20specification=20of=20new=20routing=20= metrics=20and=20constraints.=20=20By=20contrast=0A=20=20=20=20=20=20=20=20=20= with=20typical=20Interior=20Gateway=20Protocol=20(IGP)=20routing=20= metrics=20using=20=20=20=20with=20= typical=20Interior=20Gateway=20Protocol=20(IGP)=20routing=20metrics=20= using=0A=20=20=20=20= =20=20=20=20=20hop=20counts=20or=20link=20metrics,=20this=20= document=20specifies=20a=20set=20of=20link=20and=20=20=20=20hop=20counts=20or=20link=20metrics,=20this=20= document=20specifies=20a=20set=20of=20link=20and=0A=20=20=20=20=20=20=20=20=20= node=20routing=20metrics=20and=20constraints=20suitable=20to=20LLNs=20to=20= be=20used=20by=20=20=20=20node=20= routing=20metrics=20and=20constraints=20suitable=20to=20LLNs=20to=20be=20= used=20by=0A=20=20= =20=20=20=20=20=20=20the=20Routing=20for=20Low=20Power=20and=20lossy=20= networks=20(RPL)=20routing=20protocol.=20=20=20=20the=20Routing=20for=20Low=20Power=20and=20lossy=20= networks=20(RPL)=20routing=20protocol.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=202,=20line=204=20= skipping=20to=20change=20= at=20page=202,=20line=204=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=20=20=20=20= Internet-Drafts=20are=20working=20documents=20of=20the=20Internet=20= Engineering=0A=20=20= =20=20=20=20=20=20=20Task=20Force=20(IETF).=20=20Note=20that=20other=20= groups=20may=20also=20distribute=20=20= =20=20Task=20Force=20(IETF).=20=20Note=20that=20other=20groups=20may=20= also=20distribute=0A= =20=20=20=20=20=20=20=20=20working=20documents=20as=20Internet-Drafts.=20=20= The=20list=20of=20current=20Internet-=20=20=20=20working=20documents=20as=20Internet-Drafts.=20=20= The=20list=20of=20current=20Internet-=0A=20=20=20=20=20=20=20=20=20Drafts=20is=20at=20= http://datatracker.ietf.org/drafts/current/.=20=20=20=20Drafts=20is=20at=20= http://datatracker.ietf.org/drafts/current/.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Internet-Drafts=20are=20draft=20documents=20= valid=20for=20a=20maximum=20of=20six=20months=20=20=20=20Internet-Drafts=20are=20draft=20documents=20= valid=20for=20a=20maximum=20of=20six=20months=0A=20=20=20=20=20=20=20=20=20and=20may=20be=20= updated,=20replaced,=20or=20obsoleted=20by=20other=20documents=20at=20= any=20=20=20=20and=20may=20be=20= updated,=20replaced,=20or=20obsoleted=20by=20other=20documents=20at=20= any=0A=20=20=20=20= =20=20=20=20=20time.=20=20It=20is=20inappropriate=20to=20use=20= Internet-Drafts=20as=20reference=20=20= =20=20time.=20=20It=20is=20inappropriate=20to=20use=20Internet-Drafts=20= as=20reference=0A=20= =20=20=20=20=20=20=20=20material=20or=20to=20cite=20them=20other=20than=20= as=20"work=20in=20progress."=20=20=20= =20material=20or=20to=20cite=20them=20other=20than=20as=20"work=20in=20= progress."=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= May=2012,=202011.=20=20=20=20This=20Internet-Draft=20will=20expire=20on=20= June=205,=202011.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20Copyright=20Notice=20= Copyright=20Notice=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Copyright=20(c)=202010=20IETF=20Trust=20and=20= the=20persons=20identified=20as=20the=20=20=20=20Copyright=20(c)=202010=20IETF=20Trust=20and=20= the=20persons=20identified=20as=20the=0A=20=20=20=20=20=20=20=20=20document=20authors.=20=20= All=20rights=20reserved.=20=20=20=20= document=20authors.=20=20All=20rights=20reserved.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20This=20document=20is=20= subject=20to=20BCP=2078=20and=20the=20IETF=20Trust's=20Legal=20= =20=20=20This=20document=20is=20subject=20to=20= BCP=2078=20and=20the=20IETF=20Trust's=20Legal=0A=20=20=20=20=20=20=20=20=20Provisions=20Relating=20= to=20IETF=20Documents=20=20=20=20= Provisions=20Relating=20to=20IETF=20Documents=0A=20=20=20=20=20=20=20=20=20= (http://trustee.ietf.org/license-info)=20in=20effect=20on=20the=20date=20= of=20=20=20=20= (http://trustee.ietf.org/license-info)=20in=20effect=20on=20the=20date=20= of=0A=20=20=20=20=20= =20=20= =20=20publication=20of=20this=20document.=20=20Please=20review=20these=20= documents=20=20=20=20publication=20= of=20this=20document.=20=20Please=20review=20these=20documents=0A=20=20=20=20=20=20=20=20=20= carefully,=20as=20they=20describe=20your=20rights=20and=20restrictions=20= with=20respect=20=20=20=20carefully,=20= as=20they=20describe=20your=20rights=20and=20restrictions=20with=20= respect=0A=20=20=20= =20=20=20=20=20=20to=20this=20document.=20=20Code=20Components=20= extracted=20from=20this=20document=20must=20=20=20=20to=20this=20document.=20=20Code=20Components=20= extracted=20from=20this=20document=20must=0A=20=20=20=20=20=20=20=20=20include=20Simplified=20= BSD=20License=20text=20as=20described=20in=20Section=204.e=20of=20= =20=20=20include=20Simplified=20BSD=20License=20= text=20as=20described=20in=20Section=204.e=20of=0A=20=20=20=20=20=20=20=20=20the=20= Trust=20Legal=20Provisions=20and=20are=20provided=20without=20warranty=20= as=20=20=20=20the=20Trust=20Legal=20= Provisions=20and=20are=20provided=20without=20warranty=20as=0A=20=20=20=20=20=20=20=20=20= described=20in=20the=20Simplified=20BSD=20License.=20=20=20=20described=20in=20the=20Simplified=20BSD=20= License.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20Table=20of=20= Contents=20Table=20of=20= Contents=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=201.=20= =20Introduction=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=204=20=20=20=201.=20=20Introduction=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=204=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=202.=20=20Object=20formats=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=207=20=20=20=202.=20= =20Object=20Formats=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=207=0A=20=20=20= =20=20=20=20=20=20=20=202.1.=20=20DAG=20Metric=20Container=20= format=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=207=20=20=20=20=20=202.1.=20=20DAG=20Metric=20Container=20= Format=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=207=0A=20=20=20=20=20=20=20=20=20=20=202.2.=20=20Use=20= of=20multiple=20DAG=20Metric=20= Containers=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2010=20= =20=20=20=20=202.2.=20=20Use=20of=20Multiple=20DAG=20Metric=20Containers=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2010=0A=20=20=20=20=20=20=20=20=20=20=202.3.=20=20= Metric=20usage=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 10=20=20=20=20=20=202.3.=20=20= Metric=20Usage=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 10=0A=20=20=20=20=20= =20=20=20=203.=20=20Node=20Metric/Constraint=20objects=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2011=20=20=20=20= 3.=20=20Node=20Metric/Constraint=20Objects= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 11=0A=20=20=20=20=20= =20=20=20=20=20=203.1.=20=20Node=20State=20and=20= Attributes=20object=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2011=20= =20=20=20=20=203.1.=20=20Node=20State=20and=20Attributes=20Object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2011=0A=20= =20=20=20=20=20=20=20=20=20=203.2.=20=20Node=20Energy=20object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2012=20=20=20=20= =20=203.2.=20=20Node=20Energy=20Object=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2013=0A=20=20=20=20=20=20=20=20=20=20=203.3.=20=20= Hop-Count=20object=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 16=20=20=20=20=20=203.3.=20=20= Hop-Count=20Object=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 16=0A=20=20=20=20=20= =20=20=20=204.=20=20Link=20Metric/Constraint=20objects=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2016=20= =20=20=204.=20=20Link=20Metric/Constraint=20= Objects=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2017=0A=20=20=20=20=20=20= =20= =20=20=20=204.1.=20=20Throughput=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2017=20= =20=20=20=20=204.1.=20=20Throughput=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2017=0A= =20=20=20=20=20=20=20=20=20=20=204.2.=20=20Latency=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.=2018=20=20=20=20=20=204.2.=20=20= Latency=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.=2018=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =204.3.=20=20Link=20reliability=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2019=20=20=20=20=20=204.3.=20=20= Link=20Reliability=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 19=0A=20=20=20=20=20= =20=20=20=20=20=20=20=204.3.1.=20=20The=20Link=20Quality=20= Level=20reliability=20metric=20=20.=20.=20= .=20.=20.=20.=2020=20=20=20=20=20=20= =20=204.3.1.=20=20The=20Link=20Quality=20Level=20Reliability=20Metric=20=20.=20.=20.=20.=20.=20.=20= 20=0A=20=20=20=20=20= =20=20= =20=20=20=20=20=204.3.2.=20=20The=20Expected=20Transmission=20Count=20= (ETX)=20reliability=20=20=20=20=20=20= =20=204.3.2.=20=20The=20Expected=20Transmission=20Count=20(ETX)=20= reliability=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20object=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2021=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20object=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= 21=0A=20=20=20=20=20= =20=0A=20=20=20=20=20=20= =20= =20=20=20=204.4.=20=20Link=20Color=20object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2023=20=20=20=20=20=204.4.=20=20Link=20Color=20Object=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2023=0A=20=20=20=20=20=20=20=20=20=20=20=20=204.4.1.=20= =20Link=20Color=20object=20description=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2023=20= =20=20=20=20=20=20=204.4.1.=20=20Link=20= Color=20Object=20Description=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2023=0A=20=20=20=20=20=20=20=20=20=20=20=20=204.4.2.=20= =20Mode=20of=20operation=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2024=20= =20=20=20=20=20=20=204.4.2.=20=20Mode=20of=20= operation=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2025=0A=20=20=20=20=20=20=20=20=205.=20=20Computation=20= of=20dynamic=20metrics=20and=20attributes=20=20.=20.=20.=20.=20.=20.=20.=20.=20= 25=20=20=20=205.=20=20Computation=20= of=20Dynamic=20Metrics=20and=20Attributes=20=20.=20.=20.=20.=20.=20.=20.=20.=20= 25=0A=20=20=20=20=20= =20=20= =20=206.=20=20IANA=20Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2025=20= =20=20=206.=20=20IANA=20Considerations=20=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2025=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20=20=206.1.=20=20Routing=20Metric/Constraint=20= type=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2026=20=20=20=20=20= =206.1.=20=20Routing=20Metric/Constraint=20Type=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2026=0A=20= =20=20=20=20=20=20=20=20=20=206.2.=20=20Routing=20Metric/Constraint=20= common=20header=20=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2026=20=20=20=20=20=20= 6.2.=20=20Routing=20Metric/Constraint=20TLV=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 26=0A=20=20=20=20=20= =20=20=20=20=20=206.3.=20=20NSA=20object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2027=20= =20=20=20=20=206.3.=20=20Routing=20Metric/Constraint=20Common=20Header=20=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2026=0A=20=20=20=20=20=20=20=20=20=20=206.4.=20=20Hop-Count=20object=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2027=20=20=20=20=20=206.4.=20=20= NSA=20Object=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= 27=0A=20=20=20=20=20= =20=20=20=207.=20=20Security=20considerations=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2028=20=20=20=20=20=206.5.=20=20= Hop-Count=20Object=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 27=0A=20=20=20=20=20= =20=20=20=20=207.=20=20= Security=20Considerations=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 28=0A=20=20=20=20=20= =20=20= =20=208.=20=20Acknowledgements=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2028=20= =20=20=208.=20=20Acknowledgements=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2028=0A=20=20= =20=20=20=20=20=20=209.=20=20References=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= .=2028=20=20=20=209.=20=20References=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.=2028=0A=20=20=20=20=20=20=20=20=20=20=209.1.=20=20= Normative=20references=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2028=20=20=20= =20=20=209.1.=20=20Normative=20references=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2028=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=209.2.=20=20Informative=20references=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2028=20=20=20=20= =20=209.2.=20=20Informative=20references=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2029=0A=20=20=20=20=20=20=20=20=20Authors'=20Addresses=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2029=20=20=20=20= Authors'=20Addresses=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2029=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=201.=20=20Introduction=201.=20=20Introduction=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20This=20document=20makes=20use=20of=20the=20= terminology=20defined=20in=20=20=20=20= This=20document=20makes=20use=20of=20the=20terminology=20defined=20= in=0A=20=20=20=20=20= =20=20= =20=20[I-D.ietf-roll-terminology].=20=20= =20=20[I-D.ietf-roll-terminology].=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Low=20power=20and=20Lossy=20Networks=20(LLNs)=20= have=20specific=20routing=20=20=20=20= Low=20power=20and=20Lossy=20Networks=20(LLNs)=20have=20specific=20= routing=0A=20=20=20= =20=20=20=20=20=20characteristics=20compared=20with=20traditional=20= wired=20or=20ad-hoc=20networks=20=20=20= =20characteristics=20compared=20with=20traditional=20wired=20or=20ad-hoc=20= networks=0A=20=20=20= =20=20=20=20=20=20that=20have=20been=20spelled=20out=20in=20= [RFC5548],=20[RFC5673],=20[RFC5826]=20and=20=20=20=20that=20have=20been=20spelled=20out=20in=20= [RFC5548],=20[RFC5673],=20[RFC5826]=20and=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=204,=20line=2027=20= skipping=20to=20change=20= at=20page=204,=20line=2027=0A=20=20= =20=20=20=20=20=20=20Multiprotocol=20Label=20Switching=20(MPLS)=20= Traffic=20Engineering=20(TE)=20(see=20= =20=20=20Multiprotocol=20Label=20Switching=20(MPLS)=20Traffic=20= Engineering=20(TE)=20(see=0A=20=20=20=20=20=20=20=20=20[RFC2702]=20and=20= [RFC3209])=20make=20use=20of=20other=20link=20attributes=20such=20= as=20=20=20=20[RFC2702]=20and=20= [RFC3209])=20make=20use=20of=20other=20link=20attributes=20such=20= as=0A=20=20=20=20=20= =20=20= =20=20the=20available=20reserved=20bandwidth=20(dynamic)=20or=20link=20= affinities=20(most=20=20=20=20the=20= available=20reserved=20bandwidth=20(dynamic)=20or=20link=20affinities=20= (most=0A=20=20=20=20= =20=20=20=20=20of=20the=20time=20static)=20to=20compute=20= constrained=20shortest=20paths=20for=20Traffic=20=20=20=20of=20the=20time=20static)=20to=20compute=20= constrained=20shortest=20paths=20for=20Traffic=0A=20=20=20=20=20=20=20=20=20Engineering=20Label=20= Switched=20Paths=20(TE=20LSPs).=20=20= =20=20Engineering=20Label=20Switched=20Paths=20(TE=20LSPs).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20This=20document=20= specifies=20routing=20metrics=20and=20constraints=20to=20be=20used=20= in=20=20=20=20This=20document=20= specifies=20routing=20metrics=20and=20constraints=20to=20be=20used=20= in=0A=20=20=20=20=20= =20=20= =20=20path=20calculation=20by=20the=20Routing=20Protocol=20for=20Low=20= Power=20and=20Lossy=20=20=20=20path=20= calculation=20by=20the=20Routing=20Protocol=20for=20Low=20Power=20and=20= Lossy=0A=20=20=20=20= =20=20=20=20=20Networks=20(RPL)=20specified=20in=20= [I-D.ietf-roll-rpl].=20=20=20=20= Networks=20(RPL)=20specified=20in=20[I-D.ietf-roll-rpl].=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= One=20of=20the=20prime=20objectives=20of=20this=20document=20is=20to=20= propose=20a=20flexible=20= =20=20=20One=20of=20the=20prime=20objectives=20= of=20this=20document=20is=20to=20define=20= a=20flexible=0A=20= =20=20=20=20=20=20=20=20mechanism=20for=20the=20advertisement=20of=20= routing=20metrics=20and=20constraints=20=20=20=20mechanism=20for=20the=20advertisement=20of=20= routing=20metrics=20and=20constraints=0A=20=20=20=20=20=20=20=20=20used=20by=20RPL.=20=20= Some=20RPL=20implementations=20may=20elect=20to=20adopt=20an=20= =20=20=20used=20by=20RPL.=20=20Some=20RPL=20= implementations=20may=20elect=20to=20adopt=20an=0A=20=20=20=20=20=20=20=20=20= extremely=20simple=20approach=20based=20on=20the=20use=20of=20a=20single=20= metric=20with=20no=20=20=20=20= extremely=20simple=20approach=20based=20on=20the=20use=20of=20a=20single=20= metric=20with=20no=0A= =20=20=20=20=20=20=20=20=20constraint=20whereas=20other=20implementations=20= may=20use=20a=20larger=20set=20of=20link=20=20=20=20constraint=20whereas=20other=20implementations=20= may=20use=20a=20larger=20set=20of=20link=0A=20=20=20=20=20=20=20=20=20and=20node=20routing=20= metrics=20and=20constraints.=20=20This=20specification=20= =20=20=20and=20node=20routing=20metrics=20and=20= constraints.=20=20This=20specification=0A=20=20=20=20=20=20=20=20=20provides=20a=20high=20= degree=20of=20flexibility=20and=20a=20set=20of=20routing=20= metrics=20=20=20=20provides=20a=20= high=20degree=20of=20flexibility=20and=20a=20set=20of=20routing=20= metrics=0A=20=20=20= =20=20=20=20=20=20and=20constraints.=20=20New=20routing=20metrics=20= and=20constraints=20could=20be=20=20=20= =20and=20constraints.=20=20New=20routing=20metrics=20and=20constraints=20= could=20be=0A=20=20= =20=20=20=20=20=20=20defined=20in=20the=20future,=20as=20= needed.=20=20=20=20defined=20in=20= the=20future,=20as=20needed.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20RPL=20is=20a=20distance=20vector=20routing=20= protocol=20variant=20that=20builds=20=20= =20=20RPL=20is=20a=20distance=20vector=20routing=20protocol=20variant=20= that=20builds=0A=20= =20=20=20=20=20=20=20=20Directed=20Acyclic=20Graphs=20(DAGs)=20based=20= on=20routing=20metrics=20and=20=20=20= =20Directed=20Acyclic=20Graphs=20(DAGs)=20based=20on=20routing=20metrics=20= and=0A=20=20=20=20= =20=20=20=20=20constraints.=20=20DAG=20formation=20rules=20are=20= defined=20in=20[I-D.ietf-roll-rpl]:=20= =20=20=20constraints.=20=20DAG=20formation=20rules=20are=20defined=20in=20= [I-D.ietf-roll-rpl]:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20o=20=20The=20DODAG=20root=20as=20defined=20in=20= [I-D.ietf-roll-rpl]=20may=20advertise=20a=20=20=20=20o=20=20The=20Destination=20Oriented=20Directed=20Acyclic=20Graph=20= (DODAG)=20root=20as=0A=20=20=20=20=20=20=20=20=20=20=20=20routing=20= constraint=20used=20as=20a=20"filter"=20to=20prune=20links=20and=20= nodes=20=20=20=20=20=20=20defined=20= in=20[I-D.ietf-roll-rpl]=20may=20advertise=20a=20routing=20= constraint=0A=20=20= =20=20=20=20=20=20=20=20=20=20that=20do=20not=20satisfy=20specific=20= properties.=20=20For=20example,=20it=20may=20be=20=20=20=20=20=20=20used=20as=20a=20"filter"=20to=20prune=20= links=20and=20nodes=20that=20do=20not=20satisfy=0A=20=20=20=20=20=20=20=20=20=20= =20=20required=20for=20the=20path=20to=20only=20traverse=20nodes=20that=20= are=20mains=20=20=20=20=20=20=20= specific=20properties.=20=20For=20example,=20it=20may=20be=20required=20= for=20the=20path=0A= =20=20=20=20=20=20=20=20=20=20=20=20powered=20or=20links=20that=20have=20= at=20least=20a=20minimum=20reliability=20or=20a=20=20=20=20=20=20=20to=20only=20traverse=20nodes=20that=20= are=20mains=20powered=20or=20links=20that=20have=0A=20=20=20=20=20=20=20=20=20=20= =20=20specific=20"color"=20reflecting=20a=20user=20defined=20link=20= characteristic=20=20=20=20=20=20=20= at=20least=20a=20minimum=20reliability=20or=20a=20specific=20"color"=20= reflecting=20a=0A=20= =20=20=20=20=20=20=20=20=20=20=20(e.g=20the=20link=20layer=20supports=20= encryption).=20=20=20=20=20=20=20= user=20defined=20link=20characteristic=20(e.g=20the=20link=20layer=20= supports=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20= encryption).=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20A=20routing=20metric=20is=20a=20quantitative=20value=20that=20is=20= used=20to=20evaluate=20=20=20=20o=20=20= A=20routing=20metric=20is=20a=20quantitative=20value=20that=20is=20used=20= to=20evaluate=0A=20= =20=20=20=20=20=20=20=20=20=20=20the=20path=20cost.=20=20Link=20and=20= node=20metrics=20are=20usually=20(but=20not=20always)=20= =20=20=20=20=20=20the=20path=20cost.=20=20= Link=20and=20node=20metrics=20are=20usually=20(but=20not=20= always)=0A=20=20=20= =20=20=20=20=20=20=20=20=20additive.=20=20=20=20=20=20=20additive.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20The=20best=20path=20is=20the=20path=20with=20the=20lowest=20cost=20with=20respect=20to=20= some=20=20=20=20The=20best=20path=20= is=20the=20path=20that=20satisfies=20all=20= supplied=20constraints=20(if=0A=20=20=20=20=20=20=20=20=20metrics=20that=20satisfies=20all=20constraints=20(if=20= any).=20=20It=20is=20also=20called=20=20=20=20any)=20and=20that=20= has=20the=20lowest=20cost=20with=20respect=20to=20some=20specified=0A=20=20=20=20=20=20=20=20=20the=20shortest=20= constrained=20path=20(in=20the=20presence=20of=20constraints).=20= =20=20=20= metrics.=20=20It=20is=20also=20called=20the=20shortest=20= constrained=20path=20(in=20the=0A=20=20=20=20=20=20=20=20=20=20presence=20of=20constraints).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Routing=20metrics=20falls=20into=20the=20= following=20sets=20of=20= characteristics:=20=20=20=20Routing=20= metrics=20may=20be=20categorized=20according=20= to=20the=20following=0A=20=20=20=20=20=20=20=20=20=20characteristics:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20o=20=20Link=20versus=20Node=20metrics=20= =20=20=20o=20=20Link=20versus=20Node=20= metrics=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20Qualitative=20versus=20quantitative=20=20=20=20o=20=20Qualitative=20versus=20= quantitative=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20Dynamic=20versus=20static=20=20=20= =20o=20=20Dynamic=20versus=20static=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Routing=20requirements=20documents=20(see=20= [RFC5673],=20[RFC5826]=20[RFC5548]=20=20= =20=20Routing=20requirements=20documents=20(see=20[RFC5673],=20[RFC5826]=20= [RFC5548]=0A=20=20= =20=20=20=20=20=20=20and=20[RFC5867])=20observe=20that=20it=20must=20= be=20possible=20to=20take=20into=20account=20=20=20=20and=20[RFC5867])=20observe=20that=20it=20must=20= be=20possible=20to=20take=20into=20account=0A=20=20=20=20=20=20=20=20=20a=20variety=20of=20= node=20constraints/metrics=20during=20path=20computation.=20= =20=20=20a=20variety=20of=20node=20= constraints/metrics=20during=20path=20computation.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Some=20link=20or=20node=20characteristics=20(e.g.=20link=20reliability=20flag,=20=20=20=20Some=20link=20or=20node=20characteristics=20= (e.g.=20link=20reliability,=20= remaining=0A=20=20= =20=20=20=20=20=20=20remaining=20energy=20on=20the=20node)=20may=20= either=20be=20used=20by=20RPL=20either=20= as=20=20=20=20energy=20on=20the=20= node)=20may=20be=20used=20by=20RPL=20either=20as=20routing=20= constraints=0A=20=20= =20=20=20=20=20=20=20routing=20constraints=20or=20metrics.=20=20For=20= example,=20the=20path=20may=20be=20=20= =20=20or=20as=20metrics.=20=20For=20= example,=20the=20path=20may=20be=20computed=20to=20avoid=20links=0A=20=20=20=20=20=20=20=20=20= computed=20to=20avoid=20links=20that=20do=20not=20provide=20a=20= sufficient=20level=20of=20=20=20=20= that=20do=20not=20provide=20a=20sufficient=20level=20of=20reliability=20= (use=20as=20a=0A=20= =20=20=20=20=20=20=20=20reliability=20(use=20as=20a=20constraint)=20or=20= as=20the=20path=20offering=20most=20links=20=20=20=20constraint)=20or=20as=20the=20path=20offering=20= most=20links=20with=20a=20specified=0A=20=20=20=20=20=20=20=20=20with=20a=20specified=20= reliability=20level=20(use=20as=20a=20metric).=20=20This=20= document=20=20=20=20reliability=20= level=20(use=20as=20a=20metric).=20=20This=20document=20provides=20= the=0A=20=20=20=20= =20=20=20=20=20provides=20the=20flexibility=20to=20use=20link=20= and=20node=20characterisics=20either=20=20=20=20flexibility=20to=20use=20link=20and=20node=20= characterisics=20either=20as=20constraints=0A=20=20=20=20=20=20=20=20=20as=20constraints=20= and/or=20metrics.=20=20=20=20and/or=20= metrics.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= use=20of=20link=20and=20node=20routing=20metrics=20and=20constraints=20= is=20not=20=20=20=20The=20use=20of=20= link=20and=20node=20routing=20metrics=20and=20constraints=20is=20= not=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20exclusive=20(e.g.=20it=20is=20for=20= example=20possible=20to=20advertise=20a=20"hop=20count"=20= =20=20=20exclusive=20(e.g.=20it=20is=20= possible=20to=20advertise=20a=20"hop=20count"=20both=20as=20a=0A=20=20=20=20=20=20=20=20=20= both=20as=20a=20metric=20to=20optimize=20the=20computed=20path=20and=20= as=20a=20constraint=20=20=20=20= metric=20to=20optimize=20the=20computed=20path=20and=20as=20a=20= constraint=20(e.g.=20=20"Path=0A=20=20=20=20=20=20=20=20=20(e.g.=20=20"Path=20= should=20not=20exceed=20n=20hops")).=20=20=20=20should=20not=20exceed=20n=20hops")).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Links=20in=20LLN=20= commonly=20have=20rapidly=20changing=20node=20and=20link=20= =20=20=20Links=20in=20LLN=20commonly=20have=20= rapidly=20changing=20node=20and=20link=0A=20=20=20=20=20=20=20=20=20characteristics:=20= thus=20routing=20metrics=20must=20be=20dynamic=20and=20= techniques=20=20=20=20= characteristics:=20thus=20routing=20metrics=20must=20be=20dynamic=20and=20= techniques=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20must=20be=20used=20to=20smooth=20out=20the=20= dynimicity=20of=20these=20metrics=20so=20= as=20to=20=20=20=20must=20be=20used=20= to=20smooth=20out=20the=20dynamicity=20= of=20these=20metrics=20so=20as=20to=0A=20=20=20=20=20=20=20=20=20avoid=20routing=20= oscillations.=20=20For=20instance,=20in=20addition=20to=20the=20= dynamic=20=20=20=20avoid=20routing=20= oscillations.=20=20For=20instance,=20in=20addition=20to=20the=20= dynamic=0A=20=20=20= =20=20=20=20=20=20nature=20of=20some=20links=20(e.g.=20wireless=20= but=20also=20Powerline=20Communication=20=20=20=20nature=20of=20some=20links=20(e.g.=20wireless=20= but=20also=20Powerline=20Communication=0A=20=20=20=20=20=20=20=20=20(PLC)=20links),=20= nodes'=20resources=20such=20as=20residual=20energy=20are=20= changing=20=20=20=20(PLC)=20links),=20= nodes'=20resources=20such=20as=20residual=20energy=20are=20= changing=0A=20=20=20= =20=20=20=20=20=20continuously=20and=20may=20have=20to=20be=20= taken=20into=20account=20during=20the=20path=20=20=20=20continuously=20and=20may=20have=20to=20be=20= taken=20into=20account=20during=20the=20path=0A=20=20=20=20=20=20=20=20=20computation.=20= =20=20=20computation.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20It=20must=20be=20noted=20= that=20the=20use=20of=20dynamic=20metrics=20is=20not=20new=20and=20= has=20=20=20=20It=20must=20be=20= noted=20that=20the=20use=20of=20dynamic=20metrics=20is=20not=20new=20and=20= has=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20been=20experimented=20in=20ARPANET=202.=20=20The=20use=20of=20dynamic=20metrics=20is=20= not=20=20=20=20been=20experimented=20= in=20ARPANET=202=20(see=20= [[Khanna1989J]).=20=20The=20use=20of=0A=20=20=20=20=20=20=20=20=20trivial=20and=20= great=20care=20must=20be=20given=20to=20the=20use=20of=20dynamic=20= metrics=20=20=20=20dynamic=20= metrics=20is=20not=20trivial=20and=20great=20care=20must=20be=20given=20= to=20the=0A=20=20=20= =20=20=20=20=20=20since=20it=20may=20lead=20to=20potential=20= routing=20instabilities.=20=20That=20being=20=20=20=20use=20of=20dynamic=20metrics=20since=20it=20= may=20lead=20to=20potential=20routing=0A=20=20=20=20=20=20=20=20=20said,=20lots=20of=20= experience=20has=20been=20gained=20over=20the=20years=20on=20the=20use=20= of=20=20=20=20instabilities.=20=20= That=20being=20said,=20lots=20of=20experience=20has=20been=20= gained=0A=20=20=20= =20=20=20=20=20=20dynamic=20routing=20metrics,=20which=20have=20= been=20deployed=20in=20a=20number=20of=20(non=20=20=20=20over=20the=20years=20on=20the=20use=20of=20= dynamic=20routing=20metrics,=20which=20have=20been=0A=20=20=20=20=20=20=20=20=20= IP)=20networks.=20=20=20=20deployed=20= in=20a=20number=20of=20(non=20IP)=20networks.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Very=20careful=20attention=20must=20be=20given=20= to=20the=20pace=20at=20which=20routing=20=20=20=20Very=20careful=20attention=20must=20be=20given=20= to=20the=20pace=20at=20which=20routing=0A=20=20=20=20=20=20=20=20=20metrics=20and=20= attributes=20values=20change=20in=20order=20to=20preserve=20= routing=20=20=20=20metrics=20and=20= attributes=20values=20change=20in=20order=20to=20preserve=20= routing=0A=20=20=20= =20=20=20=20=20=20stability.=20=20When=20using=20a=20dynamic=20= routing=20metric,=20a=20RPL=20implementation=20=20=20=20stability.=20=20When=20using=20a=20dynamic=20= routing=20metric,=20a=20RPL=20implementation=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= SHOULD=20make=20use=20of=20a=20= multi-threshold=20scheme=20rather=20than=20fine=20granular=20= =20=20=20should=20make=20use=20of=20a=20multi-threshold=20= scheme=20rather=20than=20fine=20granular=0A=20=20=20=20=20=20=20=20=20metric=20updates=20= reflecting=20each=20individual=20change=20to=20avoid=20spurious=20= =20=20=20metric=20updates=20reflecting=20each=20= individual=20change=20to=20avoid=20spurious=0A=20=20=20=20=20=20=20=20=20and=20unneccessary=20= routing=20changes.=20=20=20=20and=20= unneccessary=20routing=20changes.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20requirements=20on=20reporting=20frequency=20= may=20differ=20among=20metrics,=20=20= =20=20The=20requirements=20on=20reporting=20frequency=20may=20differ=20= among=20metrics,=0A= =20=20=20=20=20=20=20=20=20thus=20different=20reporting=20rates=20may=20be=20= used=20for=20each=20metric.=20=20=20=20= thus=20different=20reporting=20rates=20may=20be=20used=20for=20each=20= metric.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= set=20of=20routing=20metrics=20and=20constraints=20used=20by=20an=20RPL=20= deployment=20=20=20=20The=20set=20of=20= routing=20metrics=20and=20constraints=20used=20by=20an=20RPL=20= deployment=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20is=20signaled=20along=20the=20Directed=20Acyclic=20Graph=20(DAG)=20that=20is=20= built=20=20=20=20is=20signaled=20= along=20the=20DAG=20that=20is=20built=20= according=20to=20the=20Objective=0A=20=20=20=20=20=20=20=20=20according=20to=20the=20= Objective=20Function=20(rules=20governing=20how=20to=20build=20= a=20=20=20=20Function=20(rules=20= governing=20how=20to=20build=20a=20DAG)=20and=20the=20routing=20= metrics=0A=20=20=20= =20=20=20=20=20=20DAG)=20and=20the=20routing=20metrics=20and=20= constraints=20are=20advertised=20in=20the=20=20=20=20and=20constraints=20are=20advertised=20in=20= the=20DAG=20Information=20Option=20(DIO)=0A=20=20=20=20=20=20=20=20=20DAG=20Information=20= Option=20(DIO)=20message=20specified=20in=20=20=20=20message=20specified=20in=20= [I-D.ietf-roll-rpl].=20=20RPL=20may=20be=20used=20to=20build=0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-roll-rpl].=20=20RPL=20may=20be=20used=20to=20build=20DAGs=20= with=20different=20=20=20=20DAGs=20= with=20different=20characteristics.=20=20For=20example,=20it=20may=20= be=0A=20=20=20=20=20= =20=20=20=20characteristics.=20=20For=20example,=20it=20= may=20be=20desirable=20to=20build=20a=20DAG=20=20=20=20desirable=20to=20build=20a=20DAG=20with=20the=20= goal=20to=20maximize=20reliability=20by=0A=20=20=20=20=20=20=20=20=20with=20the=20goal=20= to=20maximize=20reliability=20by=20using=20the=20link=20= reliability=20=20=20=20using=20the=20= link=20reliability=20metric=20to=20compute=20the=20"best"=20= path.=0A=20=20=20=20= =20=20=20=20=20metric=20to=20compute=20the=20"best"=20path.=20= =20Another=20example=20might=20be=20to=20use=20=20=20=20Another=20example=20might=20be=20to=20use=20= the=20energy=20node=20characteristic=20(e.g.=0A=20=20=20=20=20=20=20=20=20the=20energy=20node=20= characteristic=20(e.g.=20mains=20powered=20versus=20battery=20= =20=20=20mains=20powered=20versus=20battery=20= operated)=20as=20a=20node=20constraint=20when=0A=20=20=20=20=20=20=20=20=20operated)=20as=20a=20= node=20constraint=20when=20building=20the=20DAG=20so=20as=20to=20= avoid=20=20=20=20building=20the=20= DAG=20so=20as=20to=20avoid=20battery=20powered=20nodes=20in=20the=20= DAG=0A=20=20=20=20= =20=20=20=20=20battery=20powered=20nodes=20in=20the=20DAG=20= while=20optimizing=20the=20link=20=20= =20=20while=20optimizing=20the=20link=20throughput.=0A=20=20=20=20=20=20=20=20=20= throughput.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20specification=20= of=20objective=20functions=20used=20to=20compute=20the=20DAG=20= =20=20=20The=20specification=20of=20objective=20= functions=20used=20to=20compute=20the=20DAG=0A=20=20=20=20=20=20=20=20=20built=20by=20RPL=20is=20= out=20of=20the=20scope=20of=20this=20document.=20=20This=20= document=20=20=20=20built=20by=20RPL=20= is=20out=20of=20the=20scope=20of=20this=20document.=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20defines=20routing=20metrics=20and=20constraints=20= that=20are=20decoupled=20from=20the=20= =20=20=20defines=20routing=20metrics=20and=20constraints=20that=20are=20= decoupled=20from=20the=0A=20=20=20=20=20=20=20=20=20objective=20function.=20= =20So=20a=20generic=20objective=20function=20could=20for=20= =20=20=20objective=20function.=20=20So=20a=20= generic=20objective=20function=20could=20for=0A=20=20=20=20=20=20=20=20=20example=20specify=20= the=20rules=20to=20select=20the=20best=20parents=20in=20the=20DAG,=20= the=20=20=20=20example=20specify=20= the=20rules=20to=20select=20the=20best=20parents=20in=20the=20DAG,=20= the=0A=20=20=20=20= =20=20=20=20=20number=20of=20backup=20parents,=20etc=20and=20= could=20be=20used=20with=20any=20routing=20=20=20=20number=20of=20backup=20parents,=20etc=20and=20= could=20be=20used=20with=20any=20routing=0A=20=20=20=20=20=20=20=20=20metrics=20and/or=20= constraints=20such=20as=20the=20ones=20specified=20in=20this=20= =20=20=20metrics=20and/or=20constraints=20= such=20as=20the=20ones=20specified=20in=20this=0A=20=20=20=20=20=20=20=20=20document.=20= =20=20=20document.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20to=20= change=20at=20page=207,=20line=2011=20= skipping=20to=20change=20= at=20page=207,=20line=2011=0A=20=20= =20=20=20=20=20=20=20of=20parents,=20a=20node=20might=20decide=20= according=20to=20the=20OF=20and=20local=20policy=20=20=20=20of=20parents,=20a=20node=20might=20decide=20= according=20to=20the=20OF=20and=20local=20policy=0A=20=20=20=20=20=20=20=20=20= which=20node=20to=20choose=20as=20a=20parent=20based=20on=20the=20= maximum=20number=20of=20links=20=20=20= =20which=20node=20to=20choose=20as=20a=20parent=20based=20on=20the=20= maximum=20number=20of=20links=0A=20=20=20=20=20=20=20=20=20with=20a=20specific=20= link=20reliability=20level,=20for=20example.=20=20=20=20with=20a=20specific=20link=20reliability=20= level,=20for=20example.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Note=20that=20the=20routing=20metrics=20and=20= constraints=20specified=20in=20this=20= =20=20=20Note=20that=20the=20routing=20metrics=20and=20constraints=20= specified=20in=20this=0A=20=20=20=20=20=20=20=20=20document=20are=20not=20= specific=20to=20any=20particular=20link=20layer.=20=20An=20= internal=20=20=20=20document=20are=20= not=20specific=20to=20any=20particular=20link=20layer.=20=20An=20= internal=0A=20=20=20= =20=20=20=20=20=20API=20between=20the=20MAC=20layer=20and=20RPL=20= may=20be=20used=20to=20accurately=20reflect=20=20=20=20API=20between=20the=20MAC=20layer=20and=20RPL=20= may=20be=20used=20to=20accurately=20reflect=0A=20=20=20=20=20=20=20=20=20the=20metrics=20values=20= of=20the=20link=20(wireless,=20wired,=20PLC).=20=20=20=20the=20metrics=20values=20of=20the=20link=20= (wireless,=20wired,=20PLC).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Since=20a=20set=20of=20metrics=20and=20= constraints=20will=20be=20used=20for=20links=20and=20=20=20=20Since=20a=20set=20of=20metrics=20and=20= constraints=20will=20be=20used=20for=20links=20and=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20nodes=20in=20LLN,=20it=20is=20particularly=20critical=20to=20ensure=20the=20= use=20of=20=20=20=20nodes=20in=20= LLN,=20it=20is=20critical=20to=20ensure=20the=20use=20of=20consistent=20= metric=0A=20=20=20= =20=20=20=20=20=20consistent=20metric=20calculation=20mechanisms=20= for=20all=20links=20and=20nodes=20in=20=20=20=20calculation=20mechanisms=20for=20all=20links=20= and=20nodes=20in=20the=20network,=0A=20=20=20=20=20=20=20=20=20the=20network,=20= similarly=20to=20the=20case=20of=20inter-domain=20IP=20routing.=20= =20=20=20similarly=20to=20the=20case=20of=20= inter-domain=20IP=20routing.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=202.=20=20Object=20formats=202.=20= =20Object=20Formats=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=202.1.=20=20= DAG=20Metric=20Container=20format= =202.1.=20=20DAG=20Metric=20Container=20= Format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Routing=20metrics=20and=20constraints=20are=20= carried=20within=20the=20DAG=20Metric=20=20=20=20Routing=20metrics=20and=20constraints=20are=20= carried=20within=20the=20DAG=20Metric=0A=20=20=20=20=20=20=20=20=20Container=20object=20= defined=20in=20[I-D.ietf-roll-rpl].=20=20Should=20multiple=20= =20=20=20Container=20object=20defined=20in=20= [I-D.ietf-roll-rpl].=20=20Should=20multiple=0A=20=20=20=20=20=20=20=20=20metrics=20and/or=20= constraints=20be=20present=20in=20the=20DAG=20Metric=20= Container,=20=20=20=20metrics=20= and/or=20constraints=20be=20present=20in=20the=20DAG=20Metric=20= Container,=0A=20=20= =20=20=20=20=20=20=20their=20use=20to=20determine=20the=20"best"=20= path=20can=20be=20defined=20by=20an=20Objective=20=20=20=20their=20use=20to=20determine=20the=20"best"=20= path=20can=20be=20defined=20by=20an=20Objective=0A=20=20=20=20=20=20=20=20=20= Function.=20=20=20=20= Function.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 3=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=203=0A=20=20=20= =20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=0A=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-...=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...=0A=20=20=20=20=20= =20=20|=20=20=20=20=20Type=3D2=20=20=20=20|=20=20Option=20= Len=20=20=20|Routing=20Metric/Constraint=20objects=20=20=20=20|=20=20=20=20=20Type=3D2=20=20=20=20|=20=20= Option=20Len=20=20=20|Routing=20Metric/Constraint=20objects=0A=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-...=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-...= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Figure=201:=20DAG=20Metric=20Container=20format=20= =20=20=20=20=20=20=20=20=20=20Figure=201:=20= DAG=20Metric=20Container=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Routing=20Metric/Constraint=20objects=20= represent=20a=20metric=20or=20a=20=20= =20=20The=20Routing=20Metric/Constraint=20objects=20represent=20a=20= metric=20or=20a=0A= =20=20=20=20=20=20=20=20=20constraint=20of=20a=20particular=20type.=20=20= They=20may=20appear=20in=20any=20order=20in=20the=20=20=20=20constraint=20of=20a=20particular=20type.=20=20= They=20may=20appear=20in=20any=20order=20in=20the=0A=20=20=20=20=20=20=20=20=20DAG=20= Metric=20Container.=20=20They=20have=20a=20common=20format=20consisting=20= of=20one=20or=20=20=20=20DAG=20= Metric=20Container.=20=20They=20have=20a=20common=20format=20consisting=20= of=20one=20or=0A=20= =20=20=20=20=20=20=20=20more=20bytes=20with=20a=20common=20= header:=20=20=20=20more=20bytes=20= with=20a=20common=20header:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=203=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=20=20= =20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20= |Routing-MC-Type|=20=20Flags=20=20|P|C|O|R|=20A=20=20=20|=20=20Prec=20|=20= Length=20(bytes)|=20=20=20=20= |Routing-MC-Type|=20=20Flags=20=20|P|C|O|R|=20A=20=20=20|=20=20Prec=20|=20= Length=20(bytes)|=0A= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=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=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= |=0A=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(object=20body)=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= (object=20body)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20//=0A=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=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|=0A= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20Figure=202:=20= Routing=20Metric/Constraint=20object=20generic=20format=20= =20=20=20=20Figure=202:=20Routing=20= Metric/Constraint=20object=20generic=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20object=20body=20carries=20one=20or=20more=20= sub-objects=20defined=20later=20in=20this=20=20=20=20The=20object=20body=20carries=20one=20or=20more=20= sub-objects=20defined=20later=20in=20this=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= document.=20=20=20=20document.=20=20= Note=20that=20an=20object=20may=20carry=20TLV,=20= which=20may=20itself=0A=20=20=20=20=20=20=20=20=20=20comprise=20other=20= TLVs.=20=20A=20TLV=20carried=20within=20a=20TLV=20is=20called=20a=20TLV=20= in=0A=20=20= =20=20=20=20=20=20=20=20this=20specification.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Routing-MC-Type=20= (Routing=20Metric/Constraint=20Type=20-=208=20bits):=20the=20= =20=20=20Routing-MC-Type=20(Routing=20= Metric/Constraint=20Type=20-=208=20bits):=20the=0A=20=20=20=20=20=20=20=20=20= Routing=20Metric/Constraint=20Type=20field=20uniquely=20identifies=20= each=20Routing=20=20=20=20Routing=20= Metric/Constraint=20Type=20field=20uniquely=20identifies=20each=20= Routing=0A=20=20=20= =20=20=20=20=20=20Metric/Constraint=20object=20and=20is=20managed=20= by=20IANA.=20=20=20=20= Metric/Constraint=20object=20and=20is=20managed=20by=20IANA.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Length:=20this=20field=20= defines=20the=20length=20of=20the=20object=20body,=20in=20= bytes.=20=20=20=20Length:=20this=20= field=20defines=20the=20length=20of=20the=20object=20body,=20in=20= bytes.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20The=20Flag=20field=20of=20the=20= Routing=20Metric/Constraint=20object=20= is=20managed=20by=20=20=20=20Flag=20field=20of=20the=20Routing=20= Metric/Constraint=20object:=0A=20=20=20=20=20=20=20=20=20= IANA.=20=20Unassigned=20bits=20are=20considered=20= as=20reserved.=20=20They=20MUST=20be=20set=20=0A=20=20=20=20=20=20=20=20=20to=20zero=20on=20transmission=20and=20MUST=20= be=20ignored=20on=20receipt.=20=20=20=20o=20=20P=20flag:=20= the=20P=20field=20is=20only=20used=20for=20= recorded=20metrics.=20=20When=0A=20=20=20=20=20=20=20=20=20=20=20=20=20cleared,=20= all=20nodes=20along=20the=20path=20successfully=20recorded=20= the=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20corresponding=20metric.=20=20When=20= set,=20this=20indicates=20than=20one=20or=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= several=20nodes=20along=20the=20path=20could=20not=20record=20the=20= metric=20of=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20interest=20(either=20because=20of=20= lack=20of=20knowledge=20or=20because=20this=20was=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= prevented=20by=20policy).=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20o=20=20C=20Flag.=20=20= When=20set,=20this=20indicates=20that=20the=20Routing=20Metric/=20= =20=20=20o=20=20C=20Flag.=20=20When=20set,=20= this=20indicates=20that=20the=20Routing=20Metric/=0A=20=20=20=20=20=20=20=20=20=20=20= =20Constraint=20object=20refers=20to=20a=20routing=20constraint.=20=20= When=20cleared,=20=20=20=20=20=20=20= Constraint=20object=20refers=20to=20a=20routing=20constraint.=20=20When=20= cleared,=0A=20=20=20= =20=20=20=20=20=20=20=20=20the=20routing=20object=20refers=20to=20= a=20routing=20metric.=20=20=20=20=20=20= =20the=20routing=20object=20refers=20to=20a=20routing=20metric.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20o=20=20O=20Flag:=20The=20= O=20flag=20is=20used=20exclusively=20for=20routing=20constraints=20= (C=20=20=20=20o=20=20O=20Flag:=20The=20= O=20flag=20is=20used=20exclusively=20for=20routing=20constraints=20= (C=0A=20=20=20=20=20= =20=20= =20=20=20=20=20flag=20is=20set).=20=20When=20set,=20this=20indicates=20= that=20the=20constraint=20=20=20=20=20= =20=20flag=20is=20set).=20=20When=20set,=20this=20indicates=20that=20the=20= constraint=0A=20=20= =20=20=20=20=20=20=20=20=20=20specified=20in=20the=20body=20of=20the=20= object=20is=20optional.=20=20When=20cleared,=20=20=20=20=20=20=20specified=20in=20the=20body=20of=20the=20= object=20is=20optional.=20=20When=20cleared,=0A=20=20=20=20=20=20=20=20=20=20=20=20the=20= constraint=20is=20mandatory.=20=20If=20the=20C=20flag=20is=20zero,=20the=20= O=20flag=20=20=20=20=20=20=20the=20= constraint=20is=20mandatory.=20=20If=20the=20C=20flag=20is=20zero,=20the=20= O=20flag=0A=20=20=20= =20=20=20=20=20=20=20=20=20MUST=20be=20set=20to=20zero=20on=20= transmission=20and=20ignored=20on=20reception.=20=20=20=20=20=20=20MUST=20be=20set=20to=20zero=20on=20= transmission=20and=20ignored=20on=20reception.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20o=20=20R=20Flag:=20The=20R=20Flag=20is=20only=20= relevant=20for=20routing=20metric=20(C=3D0)=20and=20=20=20=20o=20=20R=20Flag:=20The=20R=20Flag=20is=20only=20= relevant=20for=20routing=20metric=20(C=3D0)=20and=0A=20=20=20=20=20=20=20=20=20=20=20= =20MUST=20be=20cleared=20for=20C=3D1.=20=20When=20set,=20this=20= indicates=20that=20the=20=20=20=20=20= =20=20MUST=20be=20cleared=20for=20C=3D1.=20=20When=20set,=20this=20= indicates=20that=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20routing=20= metric=20is=20recorded=20along=20the=20path.=20=20Conversely,=20= when=20=20=20=20=20=20=20routing=20= metric=20is=20recorded=20along=20the=20path.=20=20Conversely,=20= when=0A=20=20=20=20= =20=20=20=20=20=20=20=20cleared,=20the=20routing=20metric=20is=20= aggregated.=20=20=20=20=20=20=20= cleared,=20the=20routing=20metric=20is=20aggregated.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= o=20=20A=20Field:=20The=20A=20field=20is=20only=20= relevant=20for=20metrics=20and=20is=20used=20to=20= =20=20=20The=20Flag=20field=20of=20= the=20Routing=20Metric/Constraint=20= object=20is=20managed=20= by=0A=20=20= =20=20=20=20=20=20=20=20=20=20indicate=20= whether=20the=20aggregated=20routing=20= metric=20is=20additive,=20= =20=20=20IANA.=20=20= Unassigned=20bits=20are=20considered=20as=20reserved.=20=20They=20MUST=20= be=20set=0A= =20=20=20=20=20=20=20=20=20=20=20=20= multiplicative,=20reports=20a=20maximum=20or=20a=20= minimum.=20=20=20=20to=20zero=20on=20transmission=20and=20MUST=20= be=20ignored=20on=20receipt.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=20=20*=20=20= A=3D0x00:=20The=20routing=20metric=20is=20additive=20=20= =20=20A=20Field:=20The=20A=20field=20is=20only=20relevant=20for=20metrics=20and=20= is=20used=20to=0A=20=20=20=20=20=20=20=20=20=20indicate=20whether=20= the=20aggregated=20routing=20metric=20is=20additive,=0A=20=20=20=20=20=20=20=20=20=20multiplicative,=20= reports=20a=20maximum=20or=20a=20minimum.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20*=20=20A=3D0x01:=20The=20routing=20= metric=20reports=20a=20maximum=20= =20=20=20o=20=20= A=3D0x00:=20The=20routing=20metric=20is=20= additive=0A= =20=20=20=20=20=20=20=20=20=20=20=20*=20=20= A=3D0x02:=20The=20routing=20metric=20reports=20a=20= minimum=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20*=20=20A=3D0x03:=20The=20routing=20= metric=20is=20multiplicative=20=20=20=20o=20=20A=3D0x01:=20= The=20routing=20metric=20reports=20a=20maximum=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20The=20A=20field=20has=20no=20meaning=20= when=20the=20C=20Flag=20is=20set=20(i.e.=20when=20the=20= =20=20=20o=20=20= A=3D0x02:=20The=20routing=20metric=20= reports=20a=20minimum=0A=20=20=20=20=20=20=20=20= =20=20=20=20Routing=20Metric/Constraint=20object=20refers=20to=20= a=20routing=20constraint)=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20and=20MUST=20be=20written=20to=200x00.=20= =0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20o=20=20Prec=20= field:=20The=20Prec=20field=20indicates=20= the=20precedence=20of=20this=20=20=20=20o=20=20A=3D0x03:= =20The=20routing=20metric=20is=20multiplicative=0A=20=20=20=20=20=20=20=20= =20=20=20=20Routing=20Metric/Constraint=20object=20relative=20to=20other=20= objects=20in=20the=20=0A=20=20=20=20=20=20=20=20=20=20=20=20container.=20=20This=20is=20= useful=20when=20a=20DAG=20Metric=20Container=20= contains=20=0A=20=20=20=20=20=20=20=20=20=20=20=20several=20Routing=20Metric=20objects.=20= =20The=20value=200=20means=20the=20highest=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20= precedence.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= o=20=20P=20field:=20the=20P=20field=20is=20= only=20used=20for=20recorded=20metrics.=20=20= When=20=20=20=20The=20A=20field=20has=20= no=20meaning=20when=20the=20C=20Flag=20is=20set=20(i.e.=20when=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20cleared,=20all=20nodes=20along=20the=20= path=20successfully=20recorded=20the=20=20=20=20Routing=20= Metric/Constraint=20object=20refers=20to=20a=20routing=20constraint)=20= and=0A=20=20= =20=20=20=20=20=20=20=20=20=20= corresponding=20metric.=20=20When=20set,=20this=20indicates=20than=20one=20= or=20= =20=20=20he=20only=20valid=20when=20= the=20R=20bit=20is=20cleared.=20=20= Otherwise,=20the=20A=20field=20= MUST=0A=20=20= =20=20=20=20=20=20=20=20=20=20several=20= nodes=20along=20the=20path=20could=20not=20= record=20the=20metric=20= of=20= =20=20=20be=20set=20to=200x00=20and=20MUST=20be=20ignored=20on=20= receipt.=0A= =20=20=20=20=20=20=20=20=20=20=20=20interest=20= (either=20because=20of=20lack=20of=20knowledge=20or=20because=20this=20was=20=0A=20=20=20=20=20=20=20=20= =20=20=20=20prevented=20by=20policy).=20=20=20=20Prec=20field:=20The=20= Prec=20field=20indicates=20the=20precedence=20of=20this=20Routing=0A=20=20=20=20=20=20=20=20=20=20Metric/Constraint=20= object=20relative=20to=20other=20objects=20in=20the=20= container.=0A= =20=20=20=20=20=20=20=20=20=20This=20is=20useful=20when=20a=20DAG=20Metric=20= Container=20contains=20several=20Routing=0A=20=20=20=20=20=20=20= =20=20=20Metric=20= objects.=20=20The=20value=200=20means=20the=20highest=20= precedence.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Example=201:=20A=20DAG=20formed=20by=20RPL=20where=20all=20nodes=20must=20= be=20mains-powered=20=20=20=20= Example=201:=20A=20DAG=20formed=20by=20RPL=20where=20all=20nodes=20must=20= be=20mains-powered=0A= =20=20=20=20=20=20=20=20=20and=20the=20best=20path=20is=20the=20one=20with=20= lower=20aggregated=20ETX.=20=20In=20this=20case=20=20=20=20and=20the=20best=20path=20is=20the=20one=20with=20= lower=20aggregated=20ETX.=20=20In=20this=20case=0A=20=20=20=20=20=20=20=20=20the=20= DAG=20Metric=20container=20carries=20two=20Routing=20= Metric/Constraint=20=20=20=20the=20= DAG=20Metric=20container=20carries=20two=20Routing=20= Metric/Constraint=0A= =20=20=20=20=20=20=20=20=20objects:=20one=20is=20an=20ETX=20metric=20object=20= with=20header=20(C=3D0,=20O=3D0,=20A=3D00,=20=20=20=20objects:=20one=20is=20an=20ETX=20metric=20= object=20with=20header=20(C=3D0,=20O=3D0,=20A=3D00,=0A=20=20=20=20=20=20=20=20=20= R=3D0)=20and=20the=20second=20one=20is=20a=20Node=20Energy=20constraint=20= object=20with=20=20=20=20R=3D0)=20= and=20the=20second=20one=20is=20a=20Node=20Energy=20constraint=20object=20= with=0A=20=20=20=20= =20=20=20=20=20header=20(C=3D1,=20O=3D0,=20A=3D00,=20R=3D0).=20=20= Note=20that=20a=20RPL=20instance=20may=20use=20the=20=20=20=20header=20(C=3D1,=20O=3D0,=20A=3D00,=20R=3D0).=20= =20Note=20that=20a=20RPL=20instance=20may=20use=20the=0A=20=20=20=20=20=20=20=20=20= metric=20object=20to=20report=20a=20maximum=20(A=3D0x01)=20or=20a=20= minimum=20(A=3D0x02).=20=20=20=20= metric=20object=20to=20report=20a=20maximum=20(A=3D0x01)=20or=20a=20= minimum=20(A=3D0x02).=0A=20=20=20=20=20=20=20=20=20If,=20for=20example,=20= the=20best=20path=20is=20characterized=20by=20the=20path=20= avoiding=20=20=20=20If,=20for=20= example,=20the=20best=20path=20is=20characterized=20by=20the=20path=20= avoiding=0A=20=20=20= =20=20=20=20=20=20low=20quality=20links,=20then=20the=20path=20= metric=20reports=20a=20maximum=20(A=3D0x01)=20=20=20=20low=20quality=20links,=20then=20the=20path=20= metric=20reports=20a=20maximum=20(A=3D0x01)=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2010,=20line=2013=20= skipping=20to=20change=20= at=20page=2010,=20line=2017=0A=20= =20=20=20=20=20=20=20=20Metric/Constraint=20TLV=20has=20the=20same=20= structure:=20=20=20=20= Metric/Constraint=20TLV=20has=20the=20same=20structure:=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Type:=201=20= byte=20=20=20=20Type:=201=20= byte=0A=20=20=20=20= =20=20=20=20=20Length:=201=20byte=20=20=20=20Length:=201=20byte=0A=20=20=20=20=20=20=20=20=20Value:=20= variable=20=20=20=20Value:=20= variable=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= Routing=20Metric/Constraint=20TLV=20is=20comprised=20of=201=20byte=20for=20= the=20type,=20=20=20=20A=20Routing=20= Metric/Constraint=20TLV=20is=20comprised=20of=201=20byte=20for=20the=20= type,=0A=20=20=20=20= =20=20=20=20=201=20byte=20specifying=20the=20TLV=20length,=20= and=20a=20value=20field.=20=20The=20TLV=20length=20=20=20=201=20byte=20specifying=20the=20TLV=20length,=20= and=20a=20value=20field.=20=20The=20TLV=20length=0A=20=20=20=20=20=20=20=20=20= field=20defines=20the=20length=20of=20the=20value=20field=20in=20= bytes.=20=20=20=20field=20defines=20= the=20length=20of=20the=20value=20field=20in=20bytes.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Unrecognized=20TLVs=20MUST=20be=20ignored.=20=20= =20=20Unrecognized=20TLVs=20MUST=20be=20silently=20= ignored=20while=20still=20being=0A=20=20=20=20=20=20=20=20=20=20propagated=20in=20DIO=20= generated=20by=20receiving=20node.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20= manages=20the=20codepoints=20for=20all=20TLV=20carried=20in=20= routing=0A=20= =20=20=20=20=20=20=20=20=20constraint/metric=20objects.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20IANA=20management=20of=20= the=20Routing=20Metric/Constraint=20objects=20identifier=20= =20=20=20IANA=20management=20of=20the=20= Routing=20Metric/Constraint=20objects=20identifier=0A=20=20=20=20=20=20=20=20=20= codespace=20is=20described=20in=20Section=206.=20=20=20=20codespace=20is=20described=20in=20Section=20= 6.=0A=20=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 2.2.=20=20Use=20of=20multiple=20DAG=20Metric=20Containers=20= 2.2.=20=20Use=20of=20Multiple=20DAG=20Metric=20Containers=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Since=20the=20length=20= of=20RPL=20options=20is=20encoded=20using=201=20octet,=20they=20= cannot=20=20=20=20Since=20the=20= length=20of=20RPL=20options=20is=20encoded=20using=201=20octet,=20they=20= cannot=0A=20=20=20= =20=20=20=20=20=20exceed=20255=20bytes,=20which=20also=20applies=20= to=20the=20DAG=20Metric=20Container.=20=20In=20=20=20=20exceed=20255=20bytes,=20which=20also=20applies=20= to=20the=20DAG=20Metric=20Container.=20=20In=0A=20=20=20=20=20=20=20=20=20the=20vast=20majority=20= of=20cases,=20the=20advertised=20routing=20metrics=20and=20= =20=20=20the=20vast=20majority=20of=20cases,=20= the=20advertised=20routing=20metrics=20and=0A=20=20=20=20=20=20=20=20=20constraints=20will=20= not=20require=20that=20much=20space.=20=20However,=20there=20= might=20=20=20=20constraints=20will=20= not=20require=20that=20much=20space.=20=20However,=20there=20= might=0A=20=20=20=20= =20=20=20=20=20be=20circumstances=20where=20larger=20space=20is=20= required,=20should=20for=20example=20a=20=20=20=20be=20circumstances=20where=20larger=20space=20= is=20required,=20should=20for=20example=20a=0A=20=20=20=20=20=20=20=20=20set=20of=20routing=20= metrics=20be=20recorded=20along=20a=20long=20path.=20=20In=20this=20= case,=20=20=20=20set=20of=20routing=20= metrics=20be=20recorded=20along=20a=20long=20path.=20=20In=20this=20= case,=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20as=20specified=20in=20[I-D.ietf-roll-rpl],=20routing=20metrics=20= will=20be=20carried=20=20=20=20= in=20order=20to=20avoid=20overflow,=20as=20= specified=20in=20[I-D.ietf-roll-rpl],=0A=20=20=20=20=20=20=20=20=20using=20multiple=20= DAG=20Metric=20Containers=20objects.=20=20=20=20routing=20metrics=20will=20be=20carried=20= using=20multiple=20DAG=20Metric=20Containers=0A=20=20=20=20=20=20=20=20=20=20objects.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20In=20the=20rest=20of=20this=20document,=20this=20= use=20of=20multiple=20DAG=20Metric=20=20= =20=20In=20the=20rest=20of=20this=20document,=20this=20use=20of=20= multiple=20DAG=20Metric=0A=20=20=20=20=20=20=20=20=20Containers=20objects=20= will=20be=20considered=20as=20if=20they=20were=20actually=20= just=20=20=20=20Containers=20objects=20= will=20be=20considered=20as=20if=20they=20were=20actually=20just=0A=20=20=20=20=20=20=20=20=20one=20= long=20DAG=20Metric=20Container=20object.=20=20=20=20one=20long=20DAG=20Metric=20Container=20= object.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 2.3.=20=20Metric=20usage=202.3.=20= =20Metric=20Usage=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20When=20the=20DAG=20= Metric=20Container=20contains=20a=20single=20aggregated=20= metric=20=20=20=20When=20the=20DAG=20= Metric=20Container=20contains=20a=20single=20aggregated=20metric=0A=20=20=20=20=20=20=20=20=20= (scalar=20value),=20the=20order=20relation=20to=20select=20the=20best=20= path=20is=20=20=20=20(scalar=20= value),=20the=20order=20relation=20to=20select=20the=20best=20path=20= is=0A=20=20=20=20=20= =20=20= =20=20implicitly=20derived=20from=20the=20metric=20type.=20=20For=20= example,=20lower=20is=20=20=20=20= implicitly=20derived=20from=20the=20metric=20type.=20=20For=20example,=20= lower=20is=0A=20=20= =20=20=20=20=20=20=20better=20for=20Hop=20Count,=20Link=20Latency=20= and=20ETX.=20=20Conversely,=20for=20Node=20=20=20=20better=20for=20Hop=20Count,=20Link=20Latency=20= and=20ETX.=20=20Conversely,=20for=20Node=0A=20=20=20=20=20=20=20=20=20Energy=20or=20= Throughput,=20higher=20is=20better.=20= =20=20=20Energy=20or=20Throughput,=20higher=20is=20better.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20An=20example=20of=20= using=20such=20a=20single=20aggregated=20metric=20is=20= optimizing=20=20=20=20An=20example=20= of=20using=20such=20a=20single=20aggregated=20metric=20is=20= optimizing=0A=20=20= =20=20=20=20=20=20=20routing=20for=20node=20energy.=20=20The=20Node=20= Energy=20metric=20(E-E=20field)=20defined=20=20=20=20routing=20for=20node=20energy.=20=20The=20Node=20= Energy=20metric=20(E-E=20field)=20defined=0A=20=20=20=20=20=20=20=20=20in=20Section=203.2=20= is=20aggregated=20along=20paths=20with=20an=20explicit=20min=20= =20=20=20in=20Section=203.2=20is=20aggregated=20= along=20paths=20with=20an=20explicit=20min=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2011,=20line=2012=20= skipping=20to=20change=20= at=20page=2011,=20line=2021=0A=20= =20=20=20=20=20=20=20=20An=20example=20of=20such=20use=20of=20multiple=20= aggregated=20metrics=20is=20the=20=20= =20=20An=20example=20of=20such=20use=20of=20multiple=20aggregated=20= metrics=20is=20the=0A= =20=20=20=20=20=20=20=20=20following:=20Hop-Count=20as=20the=20primary=20= criterion,=20LQL=20as=20the=20secondary=20=20=20=20following:=20Hop-Count=20as=20the=20primary=20= criterion,=20LQL=20as=20the=20secondary=0A=20=20=20=20=20=20=20=20=20criterion=20and=20Node=20= Energy=20as=20the=20ultimate=20tie-breaker.=20=20In=20such=20a=20= =20=20=20criterion=20and=20Node=20Energy=20as=20= the=20ultimate=20tie-breaker.=20=20In=20such=20a=0A=20=20=20=20=20=20=20=20=20= case,=20the=20Hop-Count,=20LQL=20and=20Node=20Energy=20metric=20objects'=20= Prec=20fields=20=20=20=20case,=20the=20= Hop-Count,=20LQL=20and=20Node=20Energy=20metric=20objects'=20Prec=20= fields=0A=20=20=20= =20=20=20=20=20=20should=20bear=20strictly=20increasing=20values=20= such=20as=200,=201=20and=202,=20=20=20= =20should=20bear=20strictly=20increasing=20values=20such=20as=200,=201=20= and=202,=0A=20=20=20= =20=20=20=20=20=20respectively.=20=20=20=20respectively.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20If=20several=20aggregated=20metrics=20happen=20= to=20bear=20the=20same=20Prec=20value,=20the=20=20=20=20If=20several=20aggregated=20metrics=20happen=20= to=20bear=20the=20same=20Prec=20value,=20the=0A=20=20=20=20=20=20=20=20=20behavior=20is=20= implementation-dependant.=20=20=20=20= behavior=20is=20implementation-dependant.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=203.=20=20Node=20Metric/Constraint=20objects=203.=20= =20Node=20Metric/Constraint=20Objects=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=203.1.=20=20Node=20State=20and=20Attributes=20object=20=20= =20=20The=20sections=203.=20and=204.=20specify=20= several=20link=20and=20node=20metric/=0A=20=20=20=20=20=20=20=20=20=20constraint=20objects.=20= =20In=20some=20cases=20it=20is=20stated=20that=20there=20must=20= not=0A=20=20= =20=20=20=20=20=20=20=20be=20more=20than=20one=20object=20of=20a=20= specific=20type.=20=20In=20that=20case,=20if=20an=20RPL=0A=20=20=20=20=20=20=20= =20=20=20= implementation=20receives=20more=20than=20one=20objet=20of=20that=20= type,=20the=20second=0A=20=20=20=20=20=20=20=20=20=20objet=20MUST=20= silently=20be=20ignored.=0A=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=0A=20= =20=20=20=20=20=203.1.=20=20Node=20= State=20and=20Attributes=20Object=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Node=20State=20= and=20Attribute=20(NSA)=20object=20is=20used=20to=20provide=20= =20=20=20The=20Node=20State=20and=20Attribute=20= (NSA)=20object=20is=20used=20to=20provide=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= information=20on=20node's=20= characteristics.=20=20=20=20= information=20on=20node=20characteristics.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20NSA=20object=20MAY=20be=20present=20in=20= the=20DAG=20Metric=20Container.=20=20There=20=20=20=20The=20NSA=20object=20MAY=20be=20present=20in=20= the=20DAG=20Metric=20Container.=20=20There=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= MUST=20be=20no=20more=20than=20one=20NSA=20= object=20as=20a=20constraint=20per=20DAG=20Metric=20=20=20=20MUST=20NOT=20= be=20more=20than=20one=20NSA=20object=20as=20a=20constraint=20per=20DAG=20= Metric=0A=20=20=20= =20=20=20=20=20=20Container,=20and=20no=20more=20than=20one=20NSA=20object=20as=20a=20= metric=20per=20DAG=20Metric=20=20=20= =20Container,=20and=20there=20MUST=20NOT=20= be=20more=20than=20one=20NSA=20object=20as=20a=20metric=0A=20=20=20=20=20=20=20=20=20= Container.=20=20=20=20per=20DAG=20= Metric=20Container.= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= NSA=20object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20= convey=20various=20=20=20=20The=20= NSA=20object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20= convey=20various=0A= =20=20=20=20=20=20=20=20=20node=20characteristics.=20=20No=20TLV=20is=20= currently=20defined.=20=20=20=20node=20= characteristics.=20=20No=20TLV=20is=20currently=20defined.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20NSA=20Routing=20= Metric/Constraint=20Type=20is=20to=20be=20assigned=20by=20IANA=20= =20=20=20The=20NSA=20Routing=20= Metric/Constraint=20Type=20is=20to=20be=20assigned=20by=20IANA=0A=20=20=20=20=20=20=20=20=20= (recommended=20value=3D1).=20=20=20=20= (recommended=20value=3D1).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20format=20of=20the=20NSA=20object=20body=20= is=20as=20follows:=20=20=20=20The=20= format=20of=20the=20NSA=20object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=203=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20=20Res=20=20=20=20=20=20=20|=20=20Flags=20=20=20=20|A|O|=20=20= Optional=20TLVs=20=20=20=20=20|=20=20= =20=20=20Res=20=20=20=20=20=20=20|=20=20Flags=20=20=20=20|A|O|=20=20= Optional=20TLVs=0A= =20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Figure=203:=20NSA=20object=20= format=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Figure=203:=20NSA=20object=20body=20format=0A=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=0A= =20=20=20=20=20=20=20=20=20'O'=20flag:=20node=20= workload=20may=20be=20hard=20to=20determine=20and=20express=20in=20= some=20=0A=20=20=20=20=20=20=20=20=20scalar=20form.=20=20However,=20node=20workload=20= could=20be=20a=20useful=20metric=20to=20=0A= =20=20=20=20=20=20=20=20=20consider=20during=20= path=20calculation,=20in=20particular=20when=20queuing=20= delays=20=0A=20=20=20=20=20=20=20=20=20must=20be=20minimized=20for=20highly=20= sensitive=20traffic=20considering=20Medium=20=0A= =20=20=20=20=20=20=20=20=20Access=20Control=20= (MAC)=20layer=20delay.=20=20Node=20workload=20MAY=20be=20set=20upon=20= CPU=20=0A=20=20=20=20=20=20=20=20=20overload,=20lack=20of=20memory=20or=20any=20= other=20node=20related=20conditions.=20=20Using=20= =0A=20=20=20=20=20=20=20=20= =20a=20simple=201-bit=20flag=20to=20characterize=20the=20node=20workload=20= provides=20a=20=0A=20=20=20=20=20=20=20=20=20sufficient=20level=20of=20granularity,=20= similarly=20to=20the=20"overload"=20bit=20used=20= =0A=20=20=20=20=20=20=20=20= =20in=20routing=20protocols=20such=20as=20IS-IS.=20=20Algorithms=20used=20= to=20set=20the=20=0A=20=20=20=20=20=20=20=20=20overload=20bit=20and=20to=20compute=20paths=20= to=20potentially=20avoid=20nodes=20with=20=0A= =20=20=20=20=20=20=20=20=20their=20overload=20= bit=20set=20are=20outside=20the=20scope=20of=20this=20document,=20but=20= it=20=0A=20=20=20=20=20=20=20=20=20is=20RECOMMENDED=20to=20avoid=20frequent=20= changes=20of=20this=20bit=20to=20avoid=20routing=20= =0A=20=20=20=20=20=20=20=20= =20oscillations.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= 'A'=20flag:=20data=20Aggregation=20Attribute:=20= data=20fusion=20involves=20more=20=20=20=20Res=20flags=20(8=20= bits):=20Reserved=20field.=20=20This=20field=20MUST=20be=20set=20to=20zero=0A=20=20=20=20=20=20=20=20= =20complicated=20processing=20to=20improve=20the=20accuracy=20of=20the=20= output=20data,=20=20=20=20on=20= transmission=20and=20MUST=20be=20ignored=20= on=20receipt.=0A=20=20=20=20=20=20=20=20= =20while=20data=20aggregation=20mostly=20aims=20at=20reducing=20the=20= amount=20of=20data.=20=0A=20=20=20=20=20=20= =20= =20=20This=20is=20listed=20as=20a=20requirement=20= in=20Section=206.2=20of=20[RFC5548].=20=20Some=20= =0A=20=20=20=20=20=20=20=20= =20applications=20may=20make=20use=20of=20the=20aggregation=20node=20= attribute=20in=20their=20=0A= =20=20=20=20=20=20=20=20=20routing=20decision=20= so=20as=20to=20minimize=20the=20amount=20= of=20traffic=20on=20the=20= =0A=20=20=20=20=20=20=20=20= =20network,=20thus=20potentially=20increasing=20its=20lifetime=20in=20= battery=20operated=20=0A=20=20=20=20=20=20=20=20=20environments.=20=20Applications=20where=20= highly=20directional=20data=20flow=20is=20=0A= =20=20=20=20=20=20=20=20=20expected=20on=20= a=20regular=20basis=20may=20take=20advantage=20= of=20data=20aggregation=20=0A= =20=20=20=20=20=20=20=20=20supported=20= routing.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20following=20two=20= bits=20of=20the=20NSA=20object=20are=20currently=20defined:=20= =20=20=20The=20following=20two=20bits=20of=20= the=20NSA=20object=20are=20currently=20defined:=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20A=20Flag:=20When=20set,=20this=20indicates=20that=20the=20node=20can=20= act=20as=20a=20=20=20=20o=20=20A=20= Flag:=20data=20Aggregation=20Attribute.=20=20= Data=20fusion=20involves=20more=0A=20=20=20=20=20=20=20=20=20=20=20=20traffic=20= aggregator.=20=20An=20implementation=20MAY=20decide=20to=20add=20= optional=20=20= =20=20=20=20=20complicated=20processing=20to=20improve=20the=20accuracy=20= of=20the=20output=20data,=0A=20=20=20=20=20=20=20=20=20=20=20=20TLVs=20(not=20= currently=20defined)=20to=20further=20describe=20the=20node=20= traffic=20=20= =20=20=20=20=20while=20data=20aggregation=20mostly=20aims=20at=20= reducing=20the=20amount=20of=20data.=0A=20=20=20=20=20=20=20=20=20=20=20=20aggregator=20= functionality.=20=20=20=20=20=20=20This=20is=20listed=20as=20a=20= requirement=20in=20Section=206.2=20of=20[RFC5548].=20=20= Some=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20applications=20may=20make=20use=20of=20= the=20aggregation=20node=20attribute=20in=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= their=20routing=20decision=20so=20as=20to=20minimize=20the=20amount=20of=20= traffic=20on= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20the=20network,=20thus=20potentially=20= increasing=20its=20lifetime=20in=20battery=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= operated=20environments.=20=20Applications=20where=20highly=20= directional=20data=0A=20=20=20=20=20=20=20=20=20=20=20=20=20flow=20is=20= expected=20on=20a=20regular=20basis=20may=20take=20advantage=20of=20= data=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20aggregation=20supported=20= routing.=20=20When=20set,=20this=20indicates=20that=20the=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20node=20can=20act=20as=20a=20= traffic=20aggregator.=20=20An=20implementation=20MAY=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20decide=20to=20add=20= optional=20TLVs=20(not=20currently=20defined)=20to=20further=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20describe=20the=20node=20= traffic=20aggregator=20functionality.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20o=20=20O=20Flag:=20When=20set,=20this=20= indicates=20that=20the=20node=20is=20overloaded=20and=20= =20=20=20o=20=20O=20Flag:=20node=20workload=20may=20be=20hard=20to=20determine=20= and=20express=20in=20some=0A=20=20=20=20=20=20=20=20=20=20=20=20may=20not=20= be=20able=20to=20process=20traffic.=20=20=20=20=20=20=20scalar=20= form.=20=20However,=20node=20workload=20could=20be=20a=20useful=20metric=20= to=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20consider=20during=20path=20= calculation,=20in=20particular=20when=20queuing=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= delays=20must=20be=20minimized=20for=20highly=20sensitive=20traffic=20= considering=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20Medium=20Access=20Control=20(MAC)=20= layer=20delay.=20=20Node=20workload=20MAY=20be=20set=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= upon=20CPU=20overload,=20lack=20of=20memory=20or=20any=20other=20node=20= related=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20conditions.=20=20Using=20a=20simple=20= 1-bit=20flag=20to=20characterize=20the=20node=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= workload=20provides=20a=20sufficient=20level=20of=20granularity,=20= similarly=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= "overload"=20bit=20used=20in=20routing=20protocols=20such=20as=20= IS-IS.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20Algorithms=20used=20to=20set=20the=20= overload=20bit=20and=20to=20compute=20paths=20to=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= potentially=20avoid=20nodes=20with=20their=20overload=20bit=20set=20are=20= outside=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20the=20scope=20of=20this=20document,=20= but=20it=20is=20RECOMMENDED=20to=20avoid=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20= frequent=20changes=20of=20this=20bit=20to=20avoid=20routing=20= oscillations.=20=20When=0A=20=20=20=20=20=20=20=20=20=20=20=20=20set,=20this=20indicates=20that=20the=20= node=20is=20overloaded=20and=20may=20not=20be=0A=20=20=20=20=20=20=20=20=20=20=20=20=20able=20to=20process=20= traffic.=0A=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=0A=20=20=20=20=20=20=20= =20=20=20They=20= MUST=20be=20set=20to=20zero=20on=20transmission=20and=20MUST=20be=20= ignored=20on= =0A=20=20=20=20=20=20=20=20=20=20receipt.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Flag=20field=20of=20the=20NSA=20Routing=20= Metric/Constraint=20object=20is=20managed=20=20=20=20The=20Flag=20field=20of=20the=20NSA=20Routing=20= Metric/Constraint=20object=20is=20managed=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= by=20IANA.=20=20Unassigned=20bits=20are=20considered=20as=20reserved.=20=20= They=20MUST=20be=20=20=20=20by=20IANA.=20=20Unassigned=20bits=20are=20= considered=20as=20reserved.=0A=20=20=20=20=20=20=20=20= =20set=20to=20zero=20on=20transmission=20and=20MUST=20be=20ignored=20on=20= receipt.=20=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=203.2.=20=20= Node=20Energy=20object=20= 3.2.=20=20Node=20Energy=20Object=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20Whenever=20= possible,=20a=20node=20with=20low=20residual=20energy=20should=20not=20be=20=20=20=20It=20may=20sometimes=20= be=20desirable=20to=20avoid=20selecting=20a=20node=20with=20= low=0A=20=20=20=20= =20=20=20=20=20selected=20as=20= a=20router,=20thus=20the=20support=20for=20constraint-based=20= routing=20=20=20=20residual=20= energy=20as=20a=20router,=20thus=20the=20support=20for=20= constraint-based=0A= =20=20=20=20=20=20=20=20=20is=20needed.=20=20In=20such=20cases,=20the=20= routing=20protocol=20engine=20may=20compute=20a=20=20=20=20routing=20is=20needed.=20=20In=20such=20cases,=20= the=20routing=20protocol=20engine=20may=0A=20=20=20=20=20=20=20=20=20longer=20path=20= (constraint=20based)=20for=20some=20traffic=20in=20order=20to=20= increase=20=20=20=20compute=20a=20= longer=20path=20(constraint=20based)=20for=20some=20traffic=20in=20order=20= to=0A=20=20=20=20=20= =20=20=20=20the=20network=20life=20duration.=20= =20=20=20increase=20the=20network=20life=20= duration.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Power=20and=20energy=20are=20clearly=20critical=20resources=20in=20most=20= LLNs.=20=20As=20yet=20=20=20=20Power=20= and=20energy=20are=20clearly=20critical=20resources=20in=20most=20LLNs.=20= =20As=20yet=0A=20=20= =20=20=20=20=20=20=20there=20is=20no=20simple=20abstraction=20which=20= adequately=20covers=20the=20broad=20=20= =20=20there=20is=20no=20simple=20abstraction=20which=20adequately=20= covers=20the=20broad=0A=20=20=20=20=20=20=20=20=20range=20of=20power=20= sources=20and=20energy=20storage=20devices=20used=20in=20= existing=20=20=20=20range=20of=20= power=20sources=20and=20energy=20storage=20devices=20used=20in=20= existing=0A=20=20=20= =20=20=20=20=20=20LLN=20nodes.=20=20These=20include=20= mains-powered,=20primary=20batteries,=20energy=20=20=20=20LLN=20nodes.=20=20These=20include=20= mains-powered,=20primary=20batteries,=20energy=0A=20=20=20=20=20=20=20=20=20scavengers,=20and=20a=20= variety=20of=20secondary=20storage=20mechanisms.=20=20=20=20scavengers,=20and=20a=20variety=20of=20= secondary=20storage=20mechanisms.=0A=20=20=20=20=20=20=20=20=20Scavengers=20may=20= provide=20a=20reliable=20low=20level=20of=20power,=20such=20as=20= might=20=20=20=20Scavengers=20may=20= provide=20a=20reliable=20low=20level=20of=20power,=20such=20as=20= might=0A=20=20=20=20= =20=20=20=20=20be=20available=20from=20a=204-20mA=20loop;=20a=20= reliable=20but=20periodic=20stream=20of=20=20=20=20be=20available=20from=20a=204-20mA=20loop;=20a=20= reliable=20but=20periodic=20stream=20of=0A=20=20=20=20=20=20=20=20=20power,=20such=20as=20= provided=20by=20a=20well-positioned=20solar=20cell;=20or=20= =20=20=20power,=20such=20as=20provided=20by=20= a=20well-positioned=20solar=20cell;=20or=0A=20=20=20=20=20=20=20=20=20unpredictable=20power,=20= such=20as=20might=20be=20provided=20by=20a=20vibrational=20= =20=20=20unpredictable=20power,=20such=20as=20= might=20be=20provided=20by=20a=20vibrational=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2013,=20line=2028=20= skipping=20to=20change=20= at=20page=2013,=20line=2052=0A=20= =20=20=20=20=20=20=20=20milliseconds,=20seconds,=20and=20= hours/years.=20=20=20=20= milliseconds,=20seconds,=20and=20hours/years.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Raw=20power=20and=20energy=20values=20are=20= meaningless=20without=20knowledge=20of=20the=20=20=20=20Raw=20power=20and=20energy=20values=20are=20= meaningless=20without=20knowledge=20of=20the=0A=20=20=20=20=20=20=20=20=20energy=20cost=20of=20= sending=20and=20receiving=20packets,=20and=20lifetime=20= estimates=20=20=20=20energy=20cost=20= of=20sending=20and=20receiving=20packets,=20and=20lifetime=20= estimates=0A=20=20= =20=20=20=20=20=20=20have=20no=20value=20without=20some=20= higher-level=20constraint=20on=20the=20lifetime=20=20=20=20have=20no=20value=20without=20some=20= higher-level=20constraint=20on=20the=20lifetime=0A=20=20=20=20=20=20=20=20=20= required=20of=20a=20device.=20=20In=20some=20cases=20the=20path=20that=20= exhausts=20the=20=20=20=20required=20= of=20a=20device.=20=20In=20some=20cases=20the=20path=20that=20exhausts=20= the=0A=20=20=20=20= =20=20=20=20=20battery=20of=20a=20node=20on=20the=20bed=20table=20= in=20a=20month=20may=20be=20preferable=20to=20a=20=20=20=20battery=20of=20a=20node=20on=20the=20bed=20= table=20in=20a=20month=20may=20be=20preferable=20to=20a=0A=20=20=20=20=20=20=20=20=20= route=20that=20reduces=20the=20lifetime=20of=20a=20node=20in=20the=20= wall=20to=20a=20decade.=20=20=20=20= route=20that=20reduces=20the=20lifetime=20of=20a=20node=20in=20the=20= wall=20to=20a=20decade.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Given=20the=20complexity=20of=20trying=20to=20= address=20such=20a=20broad=20collection=20of=20=20=20=20Given=20the=20complexity=20of=20trying=20to=20= address=20such=20a=20broad=20collection=20of=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= constraints,=20this=20document=20defines=20three=20levels=20of=20fidelity=20in=20= the=20=20=20=20constraints,=20this=20= document=20defines=20two=20levels=20of=20= fidelity=20in=20the= =0A=20=20=20=20=20=20=20=20=20solution.=20=20= =20=20solution.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= simplest=20solution=20relies=20on=20a=202-bit=20field=20encoding=20three=20= types=20of=20=20=20=20The=20simplest=20= solution=20relies=20on=20a=202-bit=20field=20encoding=20three=20types=20= of=0A=20=20=20=20=20= =20=20= =20=20power=20sources:=20"powered",=20"battery",=20"scavenger".=20=20= This=20simple=20=20=20=20power=20= sources:=20"powered",=20"battery",=20"scavenger".=20=20This=20= simple=0A=20=20=20= =20=20=20=20=20=20approach=20may=20be=20sufficient=20for=20many=20= applications.=20=20=20=20approach=20= may=20be=20sufficient=20for=20many=20applications.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20mid-complexity=20= solution=20is=20a=20single=20parameter=20that=20can=20be=20used=20= to=20=20=20=20The=20mid-complexity=20= solution=20is=20a=20single=20parameter=20that=20can=20be=20used=20= to=0A=20=20=20=20=20= =20=20= =20=20encode=20the=20energetic=20happiness=20of=20both=20battery=20= powered=20and=20scavenging=20=20=20=20= encode=20the=20energetic=20happiness=20of=20both=20battery=20powered=20= and=20scavenging=0A= =20=20=20=20=20=20=20=20=20nodes.=20=20For=20scavenging=20nodes,=20the=208=20= bit=20quantity=20is=20the=20power=20=20= =20=20nodes.=20=20For=20scavenging=20nodes,=20the=208=20bit=20quantity=20= is=20the=20power=0A= =20=20=20=20=20=20=20=20=20provided=20by=20the=20scavenger=20divided=20by=20= the=20power=20consumed=20by=20the=20=20= =20=20provided=20by=20the=20scavenger=20divided=20by=20the=20power=20= consumed=20by=20the= =0A=20=20=20=20=20=20=0A=20=20= =20=20=20=20=20=20=20application,=20H=3DP_in/P_out,=20in=20units=20of=20percent.=20=20= Nodes=20which=20are=20=20=20=20= application,=20E-E=3DP_in/P_out,=20in=20= units=20of=20percent.=20=20Nodes=20which=20are=0A=20=20=20=20=20=20=20=20=20scavenging=20more=20= power=20than=20they=20are=20consuming=20will=20register=20above=20= =20=20=20scavenging=20more=20power=20than=20= they=20are=20consuming=20will=20register=20above=0A=20=20=20=20=20=20=20=20=20= 100.=20=20A=20good=20time=20period=20for=20averaging=20power=20in=20this=20= calculation=20may=20=20=20=20100.=20=20= A=20good=20time=20period=20for=20averaging=20power=20in=20this=20= calculation=20may=0A= =20=20=20=20=20=20=20=20=20be=20related=20to=20the=20discharge=20time=20of=20= the=20energy=20storage=20device=20on=20the=20=20=20=20be=20related=20to=20the=20discharge=20time=20of=20= the=20energy=20storage=20device=20on=20the=0A=20=20=20=20=20=20=20=20=20node,=20but=20= specifying=20this=20is=20out=20of=20the=20scope=20of=20this=20document.=20= =20For=20=20=20=20node,=20but=20= specifying=20this=20is=20out=20of=20the=20scope=20of=20this=20document.=20= =20For=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20battery=20powered=20devices,=20H=20= is=20the=20current=20expected=20lifetime=20divided=20=20=20=20battery=20powered=20devices,=20E-E=20is=20the=20current=20expected=20lifetime=20= divided=0A=20=20=20= =20=20=20=20=20=20by=20the=20desired=20minimum=20lifetime.=20=20The=20estimation=20of=20remaining=20= battery=20=20=20=20by=20the=20= desired=20minimum=20lifetime,=20in=20units=20of=20= percent.=20=20The=20estimation=0A=20=20=20=20=20=20=20=20=20energy=20and=20= actual=20power=20consumption=20can=20be=20difficult,=20and=20= the=20=20=20=20of=20remaining=20= battery=20energy=20and=20actual=20power=20consumption=20can=20be=0A=20=20=20=20=20=20=20=20=20= specifics=20of=20this=20calculation=20are=20out=20of=20scope=20of=20this=20= document,=20but=20=20=20=20= difficult,=20and=20the=20specifics=20of=20this=20calculation=20are=20out=20= of=20scope=20of=0A= =20=20=20=20=20=20=20=20=20two=20examples=20are=20presented.=20=20If=20= the=20node=20can=20measure=20its=20average=20=20=20=20this=20document,=20but=20two=20examples=20are=20= presented.=20=20If=20the=20node=20can=0A=20=20=20=20=20=20=20=20=20power=20consumption,=20= then=20H=20can=20be=20calculated=20as=20the=20ratio=20of=20= desired=20=20=20=20measure=20its=20= average=20power=20consumption,=20then=20H=20can=20be=20calculated=20= as=0A=20=20=20=20=20= =20=20=20=20max=20power=20(initial=20energy=20E_0=20= divided=20by=20desired=20lifetime=20T)=20to=20=20=20=20the=20ratio=20of=20desired=20max=20power=20= (initial=20energy=20E_0=20divided=20by=20desired=0A=20=20=20=20=20=20=20=20=20= actual=20power,=20H=3DP_max/P_now.=20=20= Alternatively,=20if=20the=20energy=20in=20the=20=20=20=20lifetime=20T)=20to=20actual=20power,=20E-E=3DP_max/P_now.=20=20Alternatively,=20if=20= the=0A=20=20=20=20= =20=20=20=20=20battery=20E_bat=20can=20be=20estimated,=20and=20= the=20total=20elapsed=20lifetime,=20t,=20is=20=20=20=20energy=20in=20the=20battery=20E_bat=20can=20be=20= estimated,=20and=20the=20total=20elapsed=0A=20=20=20=20=20=20=20=20=20available,=20then=20= H=20can=20be=20calculated=20as=20the=20total=20stored=20energy=20= =20=20=20lifetime,=20t,=20is=20available,=20= then=20H=20can=20be=20calculated=20as=20the=20total=0A=20=20=20=20=20=20=20=20=20= remaining=20versus=20the=20target=20energy=20remaining:=20H=3D=20E_bat=20/=20[E_0=20=20=20=20stored=20energy=20remaining=20versus=20the=20= target=20energy=20remaining:=20E-E=3D=0A=20=20=20=20=20=20=20=20=20(T-t)/T].=20= =20=20=20E_bat=20/=20[E_0=20= (T-t)/T].=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20An=20= example=20of=20optimized=20route=20is=20max(min(H))=20for=20all=20= battery=20operated=20=20=20=20An=20= example=20of=20optimized=20route=20is=20max(min(H))=20for=20all=20= battery=20operated=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20nodes=20along=20the=20route,=20subject=20to=20= the=20constraint=20that=20H>=3D100=20= for=20all=20=20=20=20nodes=20along=20= the=20route,=20subject=20to=20the=20constraint=20that=20E-E>=3D100=20for=0A=20=20=20=20=20=20=20=20=20scavengers=20along=20= the=20route.=20=20=20=20all=20= scavengers=20along=20the=20route.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Note=20that=20the=20estimated=20percentage=20of=20= remaining=20energy=20indicated=20in=20= =20=20=20Note=20that=20the=20estimated=20percentage=20of=20remaining=20= energy=20indicated=20in=0A=20=20=20=20=20=20=20=20=20the=20E-E=20field=20= may=20not=20be=20useful=20in=20the=20presence=20of=20nodes=20powered=20= by=20=20=20=20the=20E-E=20field=20= may=20not=20be=20useful=20in=20the=20presence=20of=20nodes=20powered=20= by=0A=20=20=20=20=20= =20=20= =20=20battery=20or=20energy=20scavengers=20when=20the=20amount=20of=20= energy=20accumulated=20by=20=20=20=20= battery=20or=20energy=20scavengers=20when=20the=20amount=20of=20energy=20= accumulated=20by=0A= =20=20=20=20=20=20=20=20=20the=20device=20significantly=20differ.=20=20= Indeed,=20X%=20of=20remaining=20energy=20on=20a=20=20=20=20the=20device=20significantly=20differ.=20=20= Indeed,=20X%=20of=20remaining=20energy=20on=20a=0A=20=20=20=20=20=20=20=20=20= node=20that=20can=20store=20a=20large=20amount=20of=20energy=20cannot=20= be=20easily=20=20=20=20node=20that=20= can=20store=20a=20large=20amount=20of=20energy=20cannot=20be=20= easily=0A=20=20=20= =20=20=20=20=20=20compared=20to=20the=20same=20percentage=20of=20= remaining=20energy=20on=20a=20node=20powered=20=20=20=20compared=20to=20the=20same=20percentage=20of=20= remaining=20energy=20on=20a=20node=20powered=0A=20=20=20=20=20=20=20=20=20by=20a=20tiny=20source=20= of=20energy.=20=20That=20being=20said,=20in=20networks=20where=20= nodes=20=20=20=20by=20a=20tiny=20= source=20of=20energy.=20=20That=20being=20said,=20in=20networks=20where=20= nodes=0A=20=20=20=20= =20=20=20=20=20have=20relatively=20close=20energy=20storage,=20= such=20a=20percentage=20of=20remaining=20=20=20=20have=20relatively=20close=20energy=20storage,=20= such=20a=20percentage=20of=20remaining=0A=20=20=20=20=20=20=20=20=20energy=20is=20= useful.=20=20=20=20energy=20is=20= useful.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= Node=20Energy=20(NE)=20object=20is=20used=20to=20provide=20information=20= related=20to=20=20=20=20The=20Node=20= Energy=20(NE)=20object=20is=20used=20to=20provide=20information=20= related=20to=0A=20= =20=20=20=20=20=20=20=20node=20energy=20and=20may=20be=20used=20as=20a=20= metric=20or=20as=20constraint.=20=20=20= =20node=20energy=20and=20may=20be=20used=20as=20a=20metric=20or=20as=20= constraint.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= NE=20object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20= =20There=20MUST=20=20=20=20The=20NE=20= object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=20MUST=0A=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20be=20no=20more=20= than=20one=20NE=20object=20as=20a=20constraint=20per=20DAG=20= Metric=20=20=20=20NOT=20be=20more=20than=20one=20NE=20object=20as=20= a=20constraint=20per=20DAG=20Metric=0A=20=20=20=20=20=20=20=20=20Container,=20and=20= no=20more=20than=20one=20NE=20object=20= as=20a=20metric=20per=20DAG=20Metric=20=20=20=20Container,=20and=20there=20MUST=20NOT=20be=20more=20than=20one=20NE=20= object=20as=20a=20metric=0A=20=20=20=20=20=20=20=20=20Container.=20= =20=20=20per=20DAG=20Metric=20= Container.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= NE=20object=20Type=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D2).=20=20=20=20The=20NE=20= object=20Type=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D2).=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20NE=20object=20body=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20NE=20= object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=203=20= =20=20=20=20=200=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20=20NE=20Sub-objects=20=20= =20=20=20|=20=20=20=20=20NE=20Sub-objects=0A=20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20Figure=204:=20NE=20object=20format=20=20=20=20=20=20=20Figure=204:=20NE=20sub-object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20format=20of=20the=20NE=20sub-object=20body=20= is=20as=20follows:=20=20=20=20The=20= format=20of=20the=20NE=20sub-object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=203=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20Flags=20|I|=20T=20|E|=20=20=20=20=20=20E-E=20=20=20=20=20=20|=20=20=20= Optional=20TLVs=20=20=20=20=20|=20= Flags=20|I|=20T=20|E|=20=20=20=20=20=20E-E=20=20=20=20=20=20|=20=20=20= Optional=20TLVs=0A= =20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Figure=205:=20NE=20sub-object=20format=20=20=20=20=20=20=20=20=20=20=20=20=20Figure=205:=20NE=20= sub-object=20format= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= NE=20sub-object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20= convey=20=20=20=20The=20NE=20= sub-object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20= convey=0A=20=20=20= =20=20=20=20=20=20various=20nodes'=20characteristics.=20= =20=20=20various=20nodes'=20= characteristics.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2015,=20line=2029=20= skipping=20to=20change=20= at=20page=2015,=20line=2042=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20I=20(Included):=20the=20I=20bit=20is=20only=20relevant=20when=20the=20= node=20type=20is=20=20=20=20o=20=20I=20= (Included):=20the=20I=20bit=20is=20only=20relevant=20when=20the=20node=20= type=20is=0A=20=20= =20=20=20=20=20=20=20=20=20=20used=20as=20a=20constraint.=20=20For=20= example,=20the=20path=20must=20only=20traverse=20=20=20=20=20=20=20used=20as=20a=20constraint.=20=20For=20= example,=20the=20path=20must=20only=20traverse=0A=20=20=20=20=20=20=20=20=20=20=20=20mains-powered=20= nodes.=20=20Conversely,=20battery=20operated=20nodes=20must=20= be=20=20=20=20=20=20=20mains-powered=20= nodes.=20=20Conversely,=20battery=20operated=20nodes=20must=20be=0A=20=20=20=20=20=20=20=20=20=20=20= =20excluded.=20=20The=20I=20bit=20is=20used=20to=20stipulate=20inclusion=20= versus=20=20=20=20=20=20=20excluded.=20= =20The=20I=20bit=20is=20used=20to=20stipulate=20inclusion=20= versus=0A=20=20=20= =20=20=20=20=20=20=20=20=20exclusion.=20=20When=20set,=20this=20= indicates=20that=20nodes=20of=20the=20type=20=20=20=20=20=20=20exclusion.=20=20When=20set,=20this=20= indicates=20that=20nodes=20of=20the=20type=0A=20=20=20=20=20=20=20=20=20=20=20=20specified=20= in=20the=20node=20type=20field=20MUST=20be=20included.=20=20= Conversely,=20=20=20=20=20=20=20= specified=20in=20the=20node=20type=20field=20MUST=20be=20included.=20=20= Conversely,=0A=20=20= =20=20=20=20=20=20=20=20=20=20when=20cleared,=20this=20indicates=20= that=20nodes=20of=20type=20specified=20in=20the=20=20=20=20=20=20=20when=20cleared,=20this=20indicates=20= that=20nodes=20of=20type=20specified=20in=20the=0A=20=20=20=20=20=20=20=20=20=20=20= =20node=20type=20field=20MUST=20be=20excluded.=20=20=20=20=20=20=20node=20type=20field=20MUST=20be=20= excluded.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20o=20=20T=20(node=20Type):=202-bit=20field=20indicating=20the=20= node=20type.=20=20E=3D0x00=20= =20=20=20o=20=20T=20(node=20Type):=202-bit=20= field=20indicating=20the=20node=20type.=20=20T=3D0x00=0A=20=20=20=20=20=20=20=20=20=20=20=20designates=20= a=20mains-powered=20node,=20E=3D0x01=20a=20= battery-powered=20node=20and=20=20=20= =20=20=20=20designates=20a=20mains-powered=20node,=20T=3D0x01=20a=20battery-powered=20node=20= and=0A=20=20=20=20= =20=20=20=20=20=20=20=20E=3D0x02=20a=20node=20powered=20by=20an=20energy=20scavenger.=20= =20=20=20=20=20=20T=3D0x02=20a=20node=20powered=20by=20an=20energy=20= scavenger.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20E=20(Estimation):=20when=20the=20E=20bit=20is=20set=20for=20a=20= metric,=20the=20estimated=20=20=20=20= o=20=20E=20(Estimation):=20when=20the=20E=20bit=20is=20set=20for=20a=20= metric,=20the=20estimated=0A=20=20=20=20=20=20=20=20=20=20=20=20percentage=20= of=20remaining=20energy=20on=20the=20node=20is=20indicated=20in=20the=20= E-E=20=20=20=20=20=20=20percentage=20= of=20remaining=20energy=20on=20the=20node=20is=20indicated=20in=20the=20= E-E=0A=20=20=20=20= =20=20=20=20=20=20=20=208-bit=20field.=20=20When=20cleared,=20= the=20estimated=20percentage=20of=20remaining=20=20=20=20=20=20=208-bit=20field.=20=20When=20cleared,=20= the=20estimated=20percentage=20of=20remaining=0A=20=20=20=20=20=20=20=20=20=20=20=20energy=20is=20= not=20provided.=20=20When=20the=20E=20bit=20is=20set=20for=20a=20= constraint,=20=20=20=20=20=20=20= energy=20is=20not=20provided.=20=20When=20the=20E=20bit=20is=20set=20for=20= a=20constraint,=0A= =20=20=20=20=20=20=20=20=20=20=20=20the=20E-E=20field=20defines=20a=20= threshold=20for=20the=20inclusion/exclusion:=20if=20=20=20=20=20=20=20the=20E-E=20field=20defines=20a=20= threshold=20for=20the=20inclusion/exclusion:=20if=0A=20=20=20=20=20=20=20=20=20=20=20= =20an=20inclusion,=20nodes=20with=20values=20higher=20than=20the=20= threshold=20are=20to=20=20=20=20=20=20= =20an=20inclusion,=20nodes=20with=20values=20higher=20than=20the=20= threshold=20are=20to=0A=20=20=20=20=20=20=20=20=20=20=20=20be=20= included;=20if=20an=20exclusion,=20nodes=20with=20values=20lower=20than=20= the=20=20=20=20=20=20=20be=20= included;=20if=20an=20exclusion,=20nodes=20with=20values=20lower=20than=20= the=0A=20=20=20=20= =20=20=20=20=20=20=20=20threshold=20are=20to=20be=20= excluded.=20=20=20=20=20=20=20= threshold=20are=20to=20be=20excluded.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20E-E=20(Estimated-Energy):=208-bit=20unsigned=20= integer=20field=20indicating=20an=20=20= =20=20E-E=20(Estimated-Energy):=208-bit=20unsigned=20integer=20field=20= indicating=20an=0A= =20=20=20=20=20=20=20=20=20estimated=20percentage=20of=20remaining=20= energy.=20=20The=20E-E=20field=20is=20only=20=20=20=20estimated=20percentage=20of=20remaining=20= energy.=20=20The=20E-E=20field=20is=20only=0A=20=20=20=20=20=20=20=20=20relevant=20when=20the=20= E=20flag=20is=20set,=20and=20MUST=20be=20set=20to=200=20when=20the=20E=20= flag=20=20=20=20relevant=20when=20= the=20E=20flag=20is=20set,=20and=20MUST=20be=20set=20to=200=20when=20the=20= E=20flag=0A=20=20=20= =20=20=20=20=20=20is=20cleared.=20=20=20=20is=20cleared.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20If=20the=20NE=20object=20comprises=20several=20= sub-objects=20when=20used=20as=20a=20=20= =20=20If=20the=20NE=20object=20comprises=20several=20sub-objects=20when=20= used=20as=20a=0A=20= =20=20=20=20=20=20=20=20constraint,=20each=20sub-object=20adds=20or=20= subtracts=20node=20subsets=20as=20the=20=20=20=20constraint,=20each=20sub-object=20adds=20or=20= subtracts=20node=20subsets=20as=20the=0A=20=20=20=20=20=20=20=20=20sub-objects=20are=20= parsed=20in=20order.=20=20The=20initial=20set=20(full=20or=20empty)=20= is=20=20=20=20sub-objects=20are=20= parsed=20in=20order.=20=20The=20initial=20set=20(full=20or=20empty)=20= is=0A=20=20=20=20=20= =20=20= =20=20defined=20by=20the=20I=20bit=20of=20the=20first=20sub-object:=20= full=20if=20that=20I=20bit=20is=20=20= =20=20defined=20by=20the=20I=20bit=20of=20the=20first=20sub-object:=20= full=20if=20that=20I=20bit=20is=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= an=20exclusion,=20empty=20is=20that=20I=20= bit=20is=20an=20inclusion.=20=20=20=20= an=20exclusion,=20empty=20if=20that=20I=20= bit=20is=20an=20inclusion.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20No=20TLV=20is=20currently=20defined.=20= =20=20=20No=20TLV=20is=20currently=20= defined.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20Future=20addenda=20to=20this=20= document=20may=20include=20more=20= complex=20solutions=20=20=20=20= Future=20documents=20may=20define=20more=20complex=20solutions=20involving=20= TLV=0A=20=20=20=20= =20=20=20=20=20involving=20a=20half=20= dozen=20TLV=20parameters=20representing=20energy=20= storage,=20=20=20=20parameters=20= representing=20energy=20storage,=20consumption,=20and=20= generation=0A=20=20= =20=20=20=20=20=20=20consumption,=20and=20generation=20capabilities=20= of=20the=20node,=20as=20well=20as=20=20= =20=20capabilities=20of=20the=20node,=20as=20well=20as=20desired=20= lifetime.=0A=20=20= =20=20=20=20=20=20=20desired=20lifetime.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 3.3.=20=20Hop-Count=20object=203.3.= =20=20Hop-Count=20Object=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20HoP-Count=20(HP)=20= object=20is=20used=20to=20report=20the=20number=20of=20= traversed=20=20=20=20The=20HoP-Count=20= (HP)=20object=20is=20used=20to=20report=20the=20number=20of=20= traversed=0A=20=20= =20=20=20=20=20=20=20nodes=20along=20the=20path.=20=20=20=20nodes=20along=20the=20path.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20HP=20object=20= MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20There=20= MUST=20=20=20=20The=20HP=20object=20= MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20There=20= MUST=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20be=20no=20more=20than=20one=20HP=20= object=20as=20a=20constraint=20per=20DAG=20Metric=20=20=20=20NOT=20be=20= more=20than=20one=20HP=20object=20as=20a=20constraint=20per=20DAG=20= Metric=0A=20=20=20= =20=20=20=20=20=20Container,=20and=20no=20more=20than=20one=20HP=20object=20as=20a=20= metric=20per=20DAG=20Metric=20=20=20= =20Container,=20and=20there=20MUST=20NOT=20= be=20more=20than=20one=20HP=20object=20as=20a=20metric=0A=20=20=20=20=20=20=20=20=20= Container.=20=20=20=20per=20DAG=20= Metric=20Container.= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= HP=20object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20= convey=20various=20=20=20=20The=20HP=20= object=20may=20also=20contain=20a=20set=20of=20TLVs=20used=20to=20convey=20= various=0A=20=20=20= =20=20=20=20=20=20node=20characteristics.=20=20No=20TLV=20is=20= currently=20defined.=20=20=20=20node=20= characteristics.=20=20No=20TLV=20is=20currently=20defined.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20HP=20routing=20= metric=20object=20Type=20is=20to=20be=20assigned=20by=20IANA=20= =20=20=20The=20HP=20routing=20metric=20object=20= Type=20is=20to=20be=20assigned=20by=20IANA=0A=20=20=20=20=20=20=20=20=20(recommended=20= value=3D3)=20=20=20=20(recommended=20= value=3D3)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20Hop=20Count=20object=20body=20is=20as=20= follows:=20=20=20=20The=20format=20= of=20the=20Hop=20Count=20object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=203=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20=20Res=20=20|=20Flags=20|=20=20=20Hop=20Count=20=20=20|=20=20= Optional=20TLVs=20=20=20=20=20|=20=20= Res=20=20|=20Flags=20|=20=20=20Hop=20Count=20=20=20|=20=20Optional=20= TLVs=0A=20=20=20=20= =20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20Figure=206:=20= Hop=20Count=20object=20format=20=20=20=20=20=20=20=20=20=20=20=20Figure=206:=20Hop=20Count=20object=20body=20= format=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20No=20Flag=20is=20currently=20defined.=20=20=20=20Res=20flags=20(4=20= bits):=20Reserved=20field.=20=20This=20field=20MUST=20be=20set=20to=20= zero=0A=20=20= =20=20=20=20=20=20=20=20on=20transmission=20and=20MUST=20be=20ignored=20= on=20receipt.=0A=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=0A=20= =20=20=20=20=20=20=20=20=20No=20= Flag=20is=20currently=20defined.=20=20Unassigned=20= bits=20are=20considered=20as=0A=20=20=20=20=20=20=20=20=20=20reserved.=20=20They=20= MUST=20be=20set=20to=20zero=20on=20transmission=20and=20MUST=20= be=0A=20=20= =20=20=20=20=20=20=20=20ignored=20on=20receipt.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20HP=20object=20= may=20be=20used=20as=20a=20constraint=20or=20a=20metric.=20=20When=20= used=20as=20=20=20=20The=20HP=20= object=20may=20be=20used=20as=20a=20constraint=20or=20a=20metric.=20=20= When=20used=20as=0A= =20=20=20=20=20=20=20=20=20a=20constraint,=20the=20DAG=20root=20indicates=20= the=20maximum=20number=20of=20hops=20that=20=20=20=20a=20constraint,=20the=20DAG=20root=20indicates=20= the=20maximum=20number=20of=20hops=20that=0A=20=20=20=20=20=20=20=20=20a=20path=20may=20= traverse.=20=20When=20that=20number=20is=20reached,=20no=20other=20node=20= can=20=20=20=20a=20path=20may=20= traverse.=20=20When=20that=20number=20is=20reached,=20no=20other=20node=20= can=0A=20=20=20=20= =20=20=20=20=20join=20that=20path.=20=20When=20used=20as=20a=20= metric,=20each=20visited=20node=20simply=20=20=20=20join=20that=20path.=20=20When=20used=20as=20a=20= metric,=20each=20visited=20node=20simply=0A=20=20=20=20=20=20=20=20=20increments=20the=20Hop=20= Count=20field.=20=20=20=20increments=20= the=20Hop=20Count=20field.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=204.=20=20Link=20Metric/Constraint=20objects=20=20= =20=20Note=20that=20the=20first=20node=20along=20= a=20path=20inserting=20a=20Hop-count=20object=0A=20=20=20=20=20=20=20= =20=20=20MUST=20set=20= the=20Hop=20Count=20field=20value=20to=201.=0A=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=0A=20=20=20=20=20=20=204.=20=20Link=20Metric/Constraint=20Objects=0A=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=0A=20= =20=20=20=20=204.1.=20=20Throughput=204.1.=20=20Throughput=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Many=20LLNs=20support=20a=20wide=20range=20of=20= throughputs.=20=20For=20some=20links,=20this=20=20=20=20Many=20LLNs=20support=20a=20wide=20range=20of=20= throughputs.=20=20For=20some=20links,=20this=0A=20=20=20=20=20=20=20=20=20may=20be=20due=20to=20= variable=20coding.=20=20For=20the=20deeply=20duty-cycled=20= links=20=20=20=20may=20be=20due=20to=20= variable=20coding.=20=20For=20the=20deeply=20duty-cycled=20links=0A=20=20=20=20=20=20=20=20=20= found=20in=20many=20LLNs,=20the=20variability=20comes=20as=20a=20result=20= of=20trading=20=20=20=20found=20in=20= many=20LLNs,=20the=20variability=20comes=20as=20a=20result=20of=20= trading=0A=20=20=20= =20=20=20=20=20=20power=20consumption=20for=20bit=20rate.=20=20= There=20are=20several=20MAC=20layer=20= =20=20=20power=20consumption=20for=20bit=20rate.=20=20There=20are=20= several=20MAC=20layer=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= protocols=20which=20allow=20for=20the=20effective=20bit=20rate=20and=20power=20=20=20=20protocols=20which=20allow=20for=20the=20= effective=20bit=20rate=20of=20a=20link=20to=20vary=0A=20=20=20=20=20=20=20=20=20consumption=20of=20a=20link=20to=20vary=20= over=20more=20than=20three=20orders=20of=20=20=20=20over=20more=20than=20three=20orders=20of=20= magnitude=20with=20a=20corresponding=20= change=0A=20=20=20= =20=20=20=20=20=20magnitude,=20= with=20a=20corresponding=20change=20in=20power=20consumption.=20=20= For=20=20=20=20in=20power=20= consumption.=20=20For=20efficient=20operation,=20it=20may=20be=20= desirable=0A=20=20= =20=20=20=20=20=20=20efficient=20operation,=20it=20may=20be=20= desirable=20for=20nodes=20to=20report=20the=20=20=20=20for=20nodes=20to=20report=20the=20range=20of=20= throughput=20that=20their=20links=20can=0A=20=20=20=20=20=20=20=20=20range=20of=20= throughput=20that=20their=20links=20can=20handle=20in=20addition=20to=20= the=20=20=20=20handle=20in=20= addition=20to=20the=20currently=20available=20throughput.=0A=20=20=20=20=20=20=20=20=20= currently=20available=20throughput.=20=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= Throughput=20object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20= Container.=20=20=20=20The=20= Throughput=20object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20= Container.=0A=20=20= =20=20=20=20=0A=20=20=20=20=20= =20=20=20=20There=20MUST=20be=20no=20more=20than=20one=20Throughput=20object=20= as=20a=20constraint=20per=20=20=20=20= There=20MUST=20NOT=20be=20more=20than=20= one=20Throughput=20object=20as=20a=20constraint=20per=0A=20=20=20=20=20=20=20=20=20= DAG=20Metric=20Container,=20and=20no=20= more=20than=20one=20Throughput=20object=20as=20a=20=20=20=20DAG=20Metric=20Container,=20and=20there=20MUST=20NOT=20be=20more=20than=20one=20= Throughput=0A=20=20= =20=20=20=20=20=20=20metric=20per=20DAG=20Metric=20= Container.=20=20=20=20object=20as=20= a=20metric=20per=20DAG=20Metric=20Container.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Throughput=20object=20is=20made=20of=20= throughput=20sub-objects=20and=20MUST=20at=20=20=20=20The=20Throughput=20object=20is=20made=20of=20= throughput=20sub-objects=20and=20MUST=20at=0A=20=20=20=20=20=20=20=20=20least=20comprise=20one=20= Throughput=20sub-object.=20=20The=20first=20Throughput=20sub-=20= =20=20=20least=20comprise=20one=20Throughput=20= sub-object.=20=20The=20first=20Throughput=20sub-=0A=20=20=20=20=20=20=20=20=20= object=20MUST=20be=20the=20most=20recently=20estimated=20actual=20= throughput.=20=20The=20=20=20=20= object=20MUST=20be=20the=20most=20recently=20estimated=20actual=20= throughput.=20=20The=0A=20=20=20=20=20=20=20=20=20actual=20estimation=20= of=20the=20throughput=20is=20outside=20the=20scope=20of=20this=20= =20=20=20actual=20estimation=20of=20the=20= throughput=20is=20outside=20the=20scope=20of=20this=0A=20=20=20=20=20=20=20=20=20= document.=20=20=20=20= document.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Each=20Throughput=20sub-object=20has=20a=20fixed=20length=20of=204=20= bytes.=20=20=20=20Each=20Throughput=20= sub-object=20has=20a=20fixed=20length=20of=204=20bytes.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Throughput=20= object=20does=20not=20contain=20any=20additional=20TLV.=20= =20=20=20The=20Throughput=20object=20does=20= not=20contain=20any=20additional=20TLV.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Throughput=20object=20Type=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20= =20=20=20The=20Throughput=20object=20Type=20is=20to=20be=20assigned=20by=20= IANA=20(recommended= =0A=20=20=20=20=20=20=20=20=20value=3D4)=20=20= =20=20value=3D4)=0A= =20=20=20=20=20=20=20=20=20The=20format=20of=20the=20Throughput=20object=20= body=20is=20as=20follows:=20=20=20=20= The=20format=20of=20the=20Throughput=20object=20body=20is=20as=20= follows:=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=20=20= 0=201=202=203=204=205=206=207=208=209=200=201=202=203=20= =20=20=20=200=201=202=203=204=205=206=207=208=20= 9=200=201=202=203=0A= =20=20=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20=20(sub-object)=20= .....=20=20=20=20|=20=20(sub-object)=20= .....=0A=20=20=20=20= =20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Figure=208:=20Throughput=20object=20body=20= format=20=20=20=20Figure=208:=20= Throughput=20object=20body=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=203=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=20=20= =20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=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= Throughput=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= Throughput=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|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Figure=209:=20= Throughput=20sub-object=20format=20=20= =20=20Figure=209:=20Throughput=20sub-object=20format=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Throughput:=2032=20= bits.=20=20The=20Throughput=20is=20encoded=20in=2032=20bits=20= in=20=20=20=20Throughput:=2032=20= bits.=20=20The=20Throughput=20is=20encoded=20in=2032=20bits=20in=0A=20=20=20=20=20=20=20=20=20= unsigned=20integer=20format,=20expressed=20in=20bytes=20per=20= second.=20=20=20=20unsigned=20= integer=20format,=20expressed=20in=20bytes=20per=20second.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=204.2.=20=20Latency=20= 4.2.=20=20Latency=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Similarly=20to=20throughput,=20the=20latency=20= of=20many=20LLN=20MAC=20sub-layers=20can=20=20=20=20Similarly=20to=20throughput,=20the=20latency=20= of=20many=20LLN=20MAC=20sub-layers=20can=0A=20=20=20=20=20=20=20=20=20vary=20over=20many=20= orders=20of=20magnitude,=20again=20with=20a=20corresponding=20= change=20=20=20=20vary=20over=20many=20= orders=20of=20magnitude,=20again=20with=20a=20corresponding=20= change=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20in=20current=20consumption.=20=20= Some=20LLN=20MAC=20link=20layers=20will=20allow=20the=20= =20=20=20in=20power=20consumption.=20=20Some=20LLN=20MAC=20= link=20layers=20will=20allow=20the=0A=20=20=20=20=20=20=20=20=20latency=20to=20be=20= adjusted=20globally=20on=20the=20subnet,=20on=20a=20= link-by-link=20=20=20=20latency=20to=20= be=20adjusted=20globally=20on=20the=20subnet,=20on=20a=20= link-by-link=0A=20= =20=20=20=20=20=20=20=20basis,=20or=20not=20at=20all.=20=20Some=20will=20= insist=20that=20it=20be=20fixed=20for=20a=20given=20=20=20=20basis,=20or=20not=20at=20all.=20=20Some=20will=20= insist=20that=20it=20be=20fixed=20for=20a=20given=0A=20=20=20=20=20=20=20=20=20= link,=20but=20allow=20it=20to=20be=20variable=20from=20link=20to=20= link.=20=20=20=20link,=20but=20allow=20= it=20to=20be=20variable=20from=20link=20to=20link.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Latency=20object=20= MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=20=20=20=20The=20Latency=20= object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20MUST=20be=20no=20more=20than=20one=20= Latency=20object=20as=20a=20constraint=20per=20DAG=20=20=20=20MUST=20NOT=20= be=20more=20than=20one=20Latency=20object=20as=20a=20constraint=20per=20= DAG=0A=20=20=20=20= =20=20=20=20=20Metric=20Container,=20and=20no=20more=20than=20one=20Latency=20object=20as=20= a=20metric=20per=20=20=20=20Metric=20= Container,=20and=20there=20MUST=20NOT=20= be=20more=20than=20one=20Latency=20object=0A=20=20=20=20=20=20=20=20=20= DAG=20Metric=20Container.=20=20=20=20= as=20a=20metric=20per=20DAG=20Metric=20Container.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Latency=20object=20= is=20made=20of=20Latency=20sub-objects=20and=20MUST=20at=20= least=20=20=20=20The=20Latency=20= object=20is=20made=20of=20Latency=20sub-objects=20and=20MUST=20at=20= least=0A=20=20=20=20= =20=20=20=20=20comprise=20one=20Latency=20sub-object.=20=20Each=20= Latency=20sub-object=20has=20a=20fixed=20=20=20=20comprise=20one=20Latency=20sub-object.=20=20= Each=20Latency=20sub-object=20has=20a=20fixed=0A=20=20=20=20=20=20=20=20=20length=20of=204=20= bytes.=20=20=20=20length=20of=204=20= bytes.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= Latency=20object=20does=20not=20contain=20any=20additional=20= TLV.=20=20=20=20The=20Latency=20= object=20does=20not=20contain=20any=20additional=20TLV.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Latency=20object=20= Type=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= =20=20=20The=20Latency=20object=20Type=20is=20= to=20be=20assigned=20by=20IANA=20(recommended=0A=20=20=20=20=20=20=20=20=20value=3D5)=20= =20=20=20value=3D5)=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Latency=20object=20is=20a=20metric=20or=20= constraint.=20=20=20=20The=20Latency=20= object=20is=20a=20metric=20or=20constraint.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20format=20of=20the=20Latency=20object=20= body=20is=20as=20follows:=20=20=20=20= The=20format=20of=20the=20Latency=20object=20body=20is=20as=20= follows:=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=20=20= 0=201=202=203=204=205=206=207=208=209=200=201=202=203=20= =20=20=20=200=201=202=203=204=205=206=207=208=20= 9=200=201=202=203=0A= =20=20=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20=20(sub-object)=20= .....=20=20=20=20|=20=20(sub-object)=20= .....=0A=20=20=20=20= =20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Figure=2010:=20Latency=20object=20body=20= format=20=20=20=20Figure=2010:=20= Latency=20object=20body=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=203=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=202=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=203=0A=20=20=20=20=20=20=20=20=20=200=201=202=203=204=20= 5=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=202=20= 3=204=205=206=207=208=209=200=201=20=20= =20=20=200=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= 6=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=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= Latency=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=20Latency=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|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Figure=2011:=20Latency=20= sub-object=20format=20=20=20=20= Figure=2011:=20Latency=20sub-object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Latency:=2032=20bits.=20=20The=20Latency=20is=20= encoded=20in=2032=20bits=20in=20unsigned=20=20=20=20Latency:=2032=20bits.=20=20The=20Latency=20is=20= encoded=20in=2032=20bits=20in=20unsigned=0A=20=20=20=20=20=20=20=20=20integer=20format,=20= expressed=20in=20microseconds.=20=20=20= =20integer=20format,=20expressed=20in=20microseconds.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20Latency=20object=20= may=20be=20used=20as=20a=20constraint=20or=20a=20path=20metric.=20=20= For=20=20=20=20The=20Latency=20= object=20may=20be=20used=20as=20a=20constraint=20or=20a=20path=20metric.=20= =20For=0A=20=20=20= =20=20=20=20=20=20example,=20one=20may=20want=20the=20latency=20= not=20to=20exceed=20some=20value.=20=20In=20this=20=20=20=20example,=20one=20may=20want=20the=20latency=20= not=20to=20exceed=20some=20value.=20=20In=20this=0A=20=20=20=20=20=20=20=20=20= case,=20the=20Latency=20object=20common=20header=20indicates=20that=20= the=20provided=20=20=20=20case,=20= the=20Latency=20object=20common=20header=20indicates=20that=20the=20= provided=0A=20=20=20= =20=20=20=20=20=20value=20relates=20to=20a=20constraint.=20=20In=20= another=20example,=20the=20Latency=20=20= =20=20value=20relates=20to=20a=20constraint.=20=20In=20another=20= example,=20the=20Latency=0A=20=20=20=20=20=20=20=20=20object=20may=20be=20= used=20as=20an=20aggregated=20additive=20metric=20where=20the=20= value=20=20=20=20object=20may=20be=20= used=20as=20an=20aggregated=20additive=20metric=20where=20the=20= value=0A=20=20=20=20= =20=20=20=20=20is=20updated=20along=20the=20path=20to=20reflect=20= the=20path=20latency.=20=20=20=20is=20= updated=20along=20the=20path=20to=20reflect=20the=20path=20= latency.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 4.3.=20=20Link=20reliability=204.3.=20=20Link=20Reliability=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20In=20LLNs,=20link=20reliability=20is=20degraded=20= by=20external=20interference=20and=20=20= =20=20In=20LLNs,=20link=20reliability=20is=20degraded=20by=20external=20= interference=20and=0A= =20=20=20=20=20=20=20=20=20multi-path=20interference=20(wireless=20links).=20= =20Multipath=20typically=20=20=20=20= multi-path=20interference=20(wireless=20links).=20=20Multipath=20= typically=0A=20=20= =20=20=20=20=20=20=20affects=20both=20directions=20on=20the=20link=20= equally,=20whereas=20external=20=20=20= =20affects=20both=20directions=20on=20the=20link=20equally,=20whereas=20= external=0A=20=20=20= =20=20=20=20=20=20interference=20is=20sometimes=20unidirectional.=20= =20Time=20scales=20vary=20from=20=20=20= =20interference=20is=20sometimes=20unidirectional.=20=20Time=20scales=20= vary=20from=0A=20=20= =20=20=20=20=20=20=20milliseconds=20to=20days,=20and=20are=20often=20= periodic=20and=20linked=20to=20human=20=20=20=20milliseconds=20to=20days,=20and=20are=20often=20= periodic=20and=20linked=20to=20human=0A=20=20=20=20=20=20=20=20=20activity.=20=20Packet=20= error=20rates=20can=20generally=20be=20measured=20directly,=20= and=20=20=20=20activity.=20=20Packet=20= error=20rates=20can=20generally=20be=20measured=20directly,=20= and=0A=20=20=20=20= =20=20=20=20=20other=20metrics=20(e.g.=20bit=20error=20rate,=20= mean=20time=20between=20failures)=20are=20=20=20=20other=20metrics=20(e.g.=20bit=20error=20rate,=20= mean=20time=20between=20failures)=20are=0A=20=20=20=20=20=20=20=20=20typically=20derived=20= from=20that.=20=20Note=20that=20such=20variability=20is=20not=20= =20=20=20typically=20derived=20from=20that.=20= =20Note=20that=20such=20variability=20is=20not=0A=20=20=20=20=20=20=20=20=20specific=20to=20= wireless=20link=20but=20also=20applies=20to=20PLC=20links.=20= =20=20=20specific=20to=20wireless=20link=20= but=20also=20applies=20to=20PLC=20links.=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping=20= to=20change=20at=20page=2020,=20line=208=20= skipping=20to=20change=20= at=20page=2020,=20line=208=0A=20=20= =20=20=20=20=20=20=20quality=20may=20be=20taken=20into=20account=20as=20= a=20critical=20routing=20metric.=20=20= =20=20quality=20may=20be=20taken=20into=20account=20as=20a=20critical=20= routing=20metric.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20A=20= number=20of=20link=20reliability=20metrics=20could=20be=20defined=20= reflecting=20=20=20=20A=20number=20= of=20link=20reliability=20metrics=20could=20be=20defined=20= reflecting=0A=20=20= =20=20=20=20=20=20=20several=20reliability=20aspects.=20=20Two=20link=20= reliability=20metrics=20are=20=20=20=20= several=20reliability=20aspects.=20=20Two=20link=20reliability=20metrics=20= are=0A=20=20=20=20= =20=20=20=20=20defined=20in=20this=20document:=20the=20Link=20= Quality=20Level=20(LQL)=20and=20the=20= =20=20=20defined=20in=20this=20document:=20the=20Link=20Quality=20Level=20= (LQL)=20and=20the=0A= =20=20=20=20=20=20=20=20=20Expected=20Transmission=20count=20Metric=20= (ETX).=20=20=20=20Expected=20= Transmission=20count=20Metric=20(ETX).=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Note=20that=20an=20RPL=20implementation=20MAY=20= either=20use=20the=20LQL,=20the=20ETX=20or=20=20=20=20Note=20that=20an=20RPL=20implementation=20MAY=20= either=20use=20the=20LQL,=20the=20ETX=20or=0A=20=20=20=20=20=20=20=20=20both.=20= =20=20=20both.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=204.3.1.=20=20The=20Link=20Quality=20Level=20reliability=20metric=204.3.1.=20=20The=20Link=20Quality=20Level=20Reliability=20Metric=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Link=20Quality=20Level=20(LQL)=20object=20= is=20used=20to=20quantify=20the=20link=20=20=20=20The=20Link=20Quality=20Level=20(LQL)=20object=20= is=20used=20to=20quantify=20the=20link=0A=20=20=20=20=20=20=20=20=20reliability=20using=20= a=20discrete=20value,=20from=200=20to=207=20where=200=20= indicates=20=20=20=20reliability=20= using=20a=20discrete=20value,=20from=200=20to=207=20where=200=20= indicates=0A=20=20= =20=20=20=20=20=20=20that=20the=20link=20quality=20level=20is=20= unknown=20and=201=20reports=20the=20highest=20link=20=20=20=20that=20the=20link=20quality=20level=20is=20= unknown=20and=201=20reports=20the=20highest=20link=0A=20=20=20=20=20=20=20=20=20= quality=20level.=20=20The=20mechanisms=20and=20algorithms=20used=20to=20= compute=20the=20LQL=20=20=20=20= quality=20level.=20=20The=20mechanisms=20and=20algorithms=20used=20to=20= compute=20the=20LQL= =0A=20=20=20=20=20=20=20=20=20are=20implementation=20specific=20and=20outside=20= of=20the=20scope=20of=20this=20=20=20= =20are=20implementation=20specific=20and=20outside=20of=20the=20scope=20= of=20this=0A=20=20= =20=20=20=20=20=20=20document.=20=20= =20=20document.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= LQL=20can=20either=20be=20used=20as=20a=20metric=20or=20a=20constraint.=20= =20When=20used=20as=20=20=20=20The=20= LQL=20can=20either=20be=20used=20as=20a=20metric=20or=20a=20constraint.=20= =20When=20used=20as= =0A=20=20=20=20=20=20=20=20=20a=20metric,=20the=20LQL=20metric=20can=20be=20= recorded=20or=20aggregated.=20=20For=20example,=20=20=20=20a=20metric,=20the=20LQL=20metric=20can=20be=20= recorded=20or=20aggregated.=20=20For=20example,=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2020,=20line=20= 33=20skipping=20= to=20change=20at=20page=2020,=20line=20= 33=0A=20=20=20=20=20=20=20=20=20a=20= LQL=20value=20of=203=20or=20less").=20=20By=20contrast,=20the=20LQL=20= link=20metric=20may=20be=20=20=20=20= a=20LQL=20value=20of=203=20or=20less").=20=20By=20contrast,=20the=20LQL=20= link=20metric=20may=20be=0A=20=20=20=20=20=20=20=20=20aggregated,=20in=20= which=20case=20the=20sum=20of=20all=20LQLs=20may=20be=20= reported=20=20=20=20aggregated,=20in=20= which=20case=20the=20sum=20of=20all=20LQLs=20may=20be=20reported=0A=20=20=20=20=20=20=20=20=20= (additive=20metric)=20or=20the=20minimum=20value=20may=20be=20reported=20= along=20the=20=20=20=20(additive=20= metric)=20or=20the=20minimum=20value=20may=20be=20reported=20along=20= the=0A=20=20=20=20= =20=20=20=20=20path.=20=20=20= =20path.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20= When=20used=20as=20a=20recorded=20metric,=20counters=20are=20used=20to=20= compress=20the=20=20=20=20When=20= used=20as=20a=20recorded=20metric,=20counters=20are=20used=20to=20= compress=20the=0A=20= =20=20=20=20=20=20=20=20information:=20for=20each=20encountered=20LQL=20= value,=20only=20the=20number=20of=20=20= =20=20information:=20for=20each=20encountered=20LQL=20value,=20only=20= the=20number=20of=0A= =20=20=20=20=20=20=20=20=20matching=20links=20is=20reported.=20= =20=20=20matching=20links=20is=20= reported.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= LQL=20object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20= =20There=20=20=20=20The=20LQL=20= object=20MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20MUST=20be=20no=20more=20than=20one=20= LQL=20object=20as=20a=20constraint=20per=20DAG=20Metric=20= =20=20=20MUST=20NOT=20be=20more=20than=20one=20LQL=20object=20as=20= a=20constraint=20per=20DAG=20Metric=0A=20=20=20=20=20=20=20=20=20Container,=20and=20= no=20more=20than=20one=20LQL=20object=20= as=20a=20metric=20per=20DAG=20Metric=20=20=20=20Container,=20and=20there=20MUST=20NOT=20be=20more=20than=20one=20= LQL=20object=20as=20a=20metric=0A=20=20=20=20=20=20=20=20=20Container.=20= =20=20=20per=20DAG=20Metric=20= Container.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= LQL=20object=20MUST=20contain=20one=20or=20more=20sub-object=20used=20to=20= report=20the=20=20=20=20The=20LQL=20= object=20MUST=20contain=20one=20or=20more=20sub-object=20used=20to=20= report=20the=0A=20= =20=20=20=20=20=20=20=20number=20of=20links=20along=20with=20their=20= LQL.=20=20=20=20number=20of=20links=20= along=20with=20their=20LQL.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20LQL=20object=20Type=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D6)=20=20=20=20The=20LQL=20object=20Type=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D6)=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20format=20of=20= the=20LQL=20object=20body=20is=20as=20follows:=20=20=20=20The=20format=20of=20the=20LQL=20object=20body=20= is=20as=20follows:=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=202=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=203=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20=20=20=20Res=20=20=20=20=20|=20LQL=20sub-object=20= =20=20=20=20|=20=20=20=20=20=20=20Res=20=20=20= =20=20|=20LQL=20sub-object=0A=20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20Figure=2012:=20LQL=20object=20format=20=20=20=20=20=20=20Figure=2012:=20LQL=20object=20body=20format=0A=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=0A=20= =20=20=20=20=20=20=20=20=20Res=20flags=20(8=20bits):=20Reserved=20field.=20=20This=20= field=20MUST=20be=20set=20to=20zero=0A=20=20=20=20=20=20=20=20=20=20on=20transmission=20= and=20MUST=20be=20ignored=20on=20receipt.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20When=20the=20LQL=20= metric=20is=20recorded,=20the=20LQL=20object=20body=20comprises=20one=20= or=20=20=20=20When=20the=20LQL=20= metric=20is=20recorded,=20the=20LQL=20object=20body=20comprises=20one=20= or=0A=20=20=20=20=20= =20=20= =20=20more=20LQL=20Type=201=20sub-object.=20=20=20=20more=20LQL=20Type=201=20sub-object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20format=20of=20= the=20LQL=20Type=201=20sub-object=20is=20as=20follows=20= =20=20=20The=20format=20of=20the=20LQL=20Type=20= 1=20sub-object=20is=20as=20follows=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=200=20=20= =20=20=20=200=0A=20= =20=20=20=20=20=20=20=20=20=200=201=202=203=204=205=206=207=20= =20=20=20=20=200=201=202=203=204=205=206=20= 7=0A=20=20=20=20=20= =20=20= =20=20=20+-+-+-+-+-+-+-+-+=20=20=20=20= =20+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20=20|=20Val=20|=20= Counter=20|=20=20=20=20=20|=20Val=20= |=20Counter=20|=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20skipping=20= to=20change=20at=20page=2021,=20line=2026=20= skipping=20to=20change=20= at=20page=2021,=20line=2029=0A=20= =20=20=20=20=20=20=20=20Val:=20LQL=20value=20from=200=20to=207=20where=20= 0=20means=20undetermined=20and=201=20indicates=20=20=20=20Val:=20LQL=20value=20from=200=20to=207=20where=20= 0=20means=20undetermined=20and=201=20indicates=0A=20=20=20=20=20=20=20=20=20the=20highest=20link=20= quality.=20=20=20=20the=20highest=20= link=20quality.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Counter:=20number=20of=20links=20with=20that=20value.=20= =20=20=20Counter:=20number=20of=20links=20= with=20that=20value.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20When=20the=20LQL=20metric=20is=20aggregated,=20= the=20LQL=20object=20body=20comprises=20one=20=20=20=20When=20the=20LQL=20metric=20is=20aggregated,=20= the=20LQL=20object=20body=20comprises=20one=0A=20=20=20=20=20=20=20=20=20LQL=20Type=202=20= sub-object:=20=20=20=20LQL=20Type=20= 2=20sub-object:=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20LQL=20Type=202=20sub-object=20is=20as=20= follows=20=20=20=20The=20format=20of=20= the=20LQL=20Type=202=20sub-object=20is=20as=20follows=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=201=0A=20=20=20=20=20=20=20=20=20=20=20= 0=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= =20=20=20=20=200=201=202=203=204=205=206=207=20= 8=209=200=201=202=203=204=205=0A=20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20= Aggregated=20LQL=20Value=20=20=20=20=20|=20=20=20=20=20|=20=20=20=20=20=20Aggregated=20LQL=20Value=20= =20=20=20=20|=0A=20= =20=20=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20Figure=2014:=20LQL=20Type=202=20sub-object=20= format=20=20=20=20=20Figure=2014:=20= LQL=20Type=202=20sub-object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Aggregated=20LQL=20Value:=20when=20used=20as=20= an=20additive=20metric=20(A=3D0x00),=20the=20=20=20=20Aggregated=20LQL=20Value:=20when=20used=20as=20= an=20additive=20metric=20(A=3D0x00),=20the=0A=20=20=20=20=20=20=20=20=20aggregated=20LQL=20= value=20reports=20the=20sum=20of=20all=20the=20LQL=20values=20for=20= all=20=20=20=20aggregated=20LQL=20= value=20reports=20the=20sum=20of=20all=20the=20LQL=20values=20for=20= all=0A=20=20=20=20= =20=20=20=20=20links=20along=20the=20path.=20=20When=20used=20= to=20report=20a=20minimum=20(A=3D0x02),=20the=20=20=20=20links=20along=20the=20path.=20=20When=20used=20= to=20report=20a=20minimum=20(A=3D0x02),=20the=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2022,=20line=20= 11=20skipping=20= to=20change=20at=20page=2022,=20line=20= 14=0A=20=20=20=20=20=20=20=20=20= successfully=20deliver=20a=20packet.=20=20In=20contrast=20with=20the=20= LQL=20routing=20=20=20=20= successfully=20deliver=20a=20packet.=20=20In=20contrast=20with=20the=20= LQL=20routing=0A=20= =20=20=20=20=20=20=20=20metric,=20the=20ETX=20provides=20a=20discrete=20= value=20(wich=20may=20not=20be=20an=20= =20=20=20metric,=20the=20ETX=20provides=20a=20discrete=20value=20(wich=20= may=20not=20be=20an= =0A=20=20=20=20=20=20=20=20=20integer)=20computed=20according=20to=20a=20= specific=20formula:=20for=20example,=20an=20=20=20=20integer)=20computed=20according=20to=20a=20= specific=20formula:=20for=20example,=20an=0A=20=20=20=20=20=20=20=20=20implementation=20may=20= use=20the=20following=20formula:=20ETX=3D=201=20/=20(Df=20*=20= Dr)=20=20=20=20implementation=20may=20= use=20the=20following=20formula:=20ETX=3D=201=20/=20(Df=20*=20= Dr)=0A=20=20=20=20= =20=20=20=20=20where=20Df=20is=20the=20measured=20probability=20= that=20a=20packet=20is=20received=20by=20the=20=20=20=20where=20Df=20is=20the=20measured=20probability=20= that=20a=20packet=20is=20received=20by=20the=0A=20=20=20=20=20=20=20=20=20neighbor=20and=20Dr=20= is=20the=20measured=20probability=20that=20the=20acknowledgment=20= =20=20=20neighbor=20and=20Dr=20is=20the=20= measured=20probability=20that=20the=20acknowledgment=0A=20=20=20=20=20=20=20=20=20= packet=20is=20successfully=20received.=20=20This=20document=20does=20not=20= mandate=20the=20=20=20=20packet=20is=20= successfully=20received.=20=20This=20document=20does=20not=20mandate=20= the=0A=20=20=20=20= =20=20=20=20=20use=20of=20a=20specific=20formula=20to=20compute=20= the=20ETX=20value.=20=20=20=20use=20= of=20a=20specific=20formula=20to=20compute=20the=20ETX=20value.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20ETX=20object=20= MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=20=20=20=20The=20ETX=20object=20= MAY=20be=20present=20in=20the=20DAG=20Metric=20Container.=20=20= There=0A=20=20=20=20= =20=20=0A=20=20=20=20=20=20= =20= =20=20MUST=20be=20no=20more=20than=20one=20= ETX=20object=20as=20a=20constraint=20per=20DAG=20Metric=20= =20=20=20MUST=20NOT=20be=20more=20than=20one=20ETX=20object=20as=20= a=20constraint=20per=20DAG=20Metric=0A=20=20=20=20=20=20=20=20=20Container,=20and=20= no=20more=20than=20one=20ETX=20object=20= as=20a=20metric=20per=20DAG=20Metric=20=20=20=20Container,=20and=20there=20MUST=20NOT=20be=20more=20than=20one=20= ETX=20object=20as=20a=20metric=0A=20=20=20=20=20=20=20=20=20Container.=20= =20=20=20per=20DAG=20Metric=20= Container.=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= ETX=20object=20is=20made=20of=20ETX=20sub-objects=20and=20MUST=20at=20= least=20comprise=20=20=20=20The=20= ETX=20object=20is=20made=20of=20ETX=20sub-objects=20and=20MUST=20at=20= least=20comprise=0A= =20=20=20=20=20=20=20=20=20one=20ETX=20sub-object.=20=20Each=20ETX=20= sub-object=20has=20a=20fixed=20length=20of=208=20=20=20=20one=20ETX=20sub-object.=20=20Each=20ETX=20= sub-object=20has=20a=20fixed=20length=20of=208=0A=20=20=20=20=20=20=20=20=20bits.=20= =20=20=20bits.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20ETX=20object=20does=20not=20contain=20any=20= additional=20TLV.=20=20=20=20The=20= ETX=20object=20does=20not=20contain=20any=20additional=20TLV.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20The=20ETX=20object=20= Type=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D7)=20=20=20=20The=20ETX=20= object=20Type=20is=20to=20be=20assigned=20by=20IANA=20(recommended=20= value=3D7)=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20ETX=20object=20body=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20ETX=20= object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20= 1=0A=20=20=20= =20=20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20=20= =20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20=20(sub-object)=20= .....=20=20=20=20|=20=20(sub-object)=20= .....=0A=20=20=20=20= =20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Figure=2015:=20ETX=20object=20body=20= format=20=20=20=20Figure=2015:=20ETX=20= object=20body=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20= 1=0A=20=20=20= =20=20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=20=20=20=20=200=201=20= 2=203=204=205=206=207=208=209=200=201=202=203=204=205=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20ETX=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=20ETX=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Figure=2016:=20ETX=20sub-object=20= format=20=20=20=20Figure=2016:=20ETX=20= sub-object=20format= =0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= ETX:=2016=20bits.=20=20The=20ETX=20*=20128=20is=20encoded=20using=2016=20= bits=20in=20unsigned=20=20=20=20ETX:=20= 16=20bits.=20=20The=20ETX=20*=20128=20is=20encoded=20using=2016=20bits=20= in=20unsigned=0A=20= =20=20=20=20=20=20=20=20integer=20format,=20rounded=20off=20to=20the=20= nearest=20whole=20number.=20=20For=20=20= =20=20integer=20format,=20rounded=20off=20to=20the=20nearest=20whole=20= number.=20=20For=0A= =20=20=20=20=20=20=20=20=20example,=20if=20ETX=20=3D=203.569,=20the=20= object=20value=20will=20be=20457.=20=20If=20ETX=20>=20= =20=20=20example,=20if=20ETX=20=3D=203.569,=20= the=20object=20value=20will=20be=20457.=20=20If=20ETX=20>=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2023,=20line=20= 13=20skipping=20= to=20change=20at=20page=2023,=20line=20= 16=0A=20=20=20=20=20=20=20=20=20= example,=20the=20ETX=20object=20may=20be=20used=20as=20an=20aggregated=20= additive=20metric=20=20=20=20= example,=20the=20ETX=20object=20may=20be=20used=20as=20an=20aggregated=20= additive=20metric=0A= =20=20=20=20=20=20=20=20=20where=20the=20value=20is=20updated=20along=20the=20= path=20to=20reflect=20the=20path=20=20= =20=20where=20the=20value=20is=20updated=20along=20the=20path=20to=20= reflect=20the=20path=0A=20=20=20=20=20=20=20=20=20quality:=20when=20a=20= node=20receives=20the=20aggregated=20additive=20ETX=20value=20= of=20=20=20=20quality:=20when=20a=20= node=20receives=20the=20aggregated=20additive=20ETX=20value=20of=0A=20=20=20=20=20=20=20=20=20the=20= path=20(cummulative=20path=20ETX=20calculated=20as=20the=20sum=20of=20= the=20link=20ETX=20=20=20=20the=20= path=20(cummulative=20path=20ETX=20calculated=20as=20the=20sum=20of=20= the=20link=20ETX=0A= =20=20=20=20=20=20=20=20=20of=20all=20of=20the=20traversed=20links=20from=20= the=20advertising=20node=20to=20the=20DAG=20=20=20=20of=20all=20of=20the=20traversed=20links=20from=20= the=20advertising=20node=20to=20the=20DAG=0A=20=20=20=20=20=20=20=20=20root),=20if=20it=20= selects=20that=20node=20as=20its=20preferred=20parent,=20the=20= node=20=20=20=20root),=20if=20it=20= selects=20that=20node=20as=20its=20preferred=20parent,=20the=20= node=0A=20=20=20=20= =20=20=20=20=20updates=20the=20path=20ETX=20by=20adding=20the=20= ETX=20of=20the=20local=20link=20between=20=20=20=20updates=20the=20path=20ETX=20by=20adding=20the=20= ETX=20of=20the=20local=20link=20between=0A=20=20=20=20=20=20=20=20=20itself=20and=20the=20= preferred=20parent=20to=20the=20received=20path=20cost=20(path=20= ETX)=20=20=20=20itself=20and=20the=20= preferred=20parent=20to=20the=20received=20path=20cost=20(path=20= ETX)=0A=20=20=20=20= =20=20=20=20=20before=20potentially=20advertising=20itself=20= the=20new=20path=20ETX.=20=20=20=20= before=20potentially=20advertising=20itself=20the=20new=20path=20= ETX.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 4.4.=20=20Link=20Color=20object=204.4.= =20=20Link=20Color=20Object=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=204.4.1.=20=20= Link=20Color=20object=20= description=204.4.1.=20=20= Link=20Color=20Object=20= Description=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= Link=20Color=20(LC)=20object=20is=20an=20administrative=2010-bit=20= link=20=20=20=20The=20Link=20Color=20= (LC)=20object=20is=20an=20administrative=2010-bit=20link=0A=20=20=20=20=20=20=20=20=20= constraint=20(which=20may=20either=20be=20static=20or=20dynamically=20= adjusted)=20used=20=20=20=20= constraint=20(which=20may=20either=20be=20static=20or=20dynamically=20= adjusted)=20used=0A= =20=20=20=20=20=20=20=20=20to=20avoid=20or=20attract=20specific=20links=20= for=20specific=20traffic=20types.=20=20= =20=20to=20avoid=20or=20attract=20specific=20links=20for=20specific=20= traffic=20types.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= LC=20object=20can=20either=20be=20used=20as=20a=20metric=20or=20as=20a=20= constraint.=20=20=20=20The=20LC=20= object=20can=20either=20be=20used=20as=20a=20metric=20or=20as=20a=20= constraint.=0A=20=20= =20=20=20=20=20=20=20When=20used=20as=20a=20metric,=20the=20LC=20= metric=20can=20only=20be=20recorded.=20=20For=20=20=20=20When=20used=20as=20a=20metric,=20the=20LC=20= metric=20can=20only=20be=20recorded.=20=20For=0A=20=20=20=20=20=20=20=20=20example,=20the=20DAG=20= may=20require=20recording=20the=20link=20colors=20for=20all=20= =20=20=20example,=20the=20DAG=20may=20require=20= recording=20the=20link=20colors=20for=20all=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= traversed=20links.=20=20Each=20node=20can=20then=20use=20the=20LC=20to=20= select=20the=20parent=20=20=20=20= traversed=20links.=20=20A=20color=20is=20= defined=20as=20a=20specific=20set=20of=20bit=20values:=0A=20=20=20=20=20=20=20=20=20= based=20on=20user=20defined=20rules=20(e.g.=20"select=20the=20path=20= with=20the=20maximum=20=20=20=20in=20other=20words,=20that=2010-bit=20field=20= is=20a=20flag=20field,=20and=20not=20a=20scalar=0A=20=20=20=20=20=20=20=20=20= number=20of=20links=20having=20their=20first=20bit=20set=201=20(e.g.=20= encrypted=20= =20=20=20value.=20=20Each=20node=20can=20then=20use=20the=20LC=20= to=20select=20the=20parent=20based=20on=0A=20=20=20=20=20=20=20=20=20links)").=20=20The=20= LC=20object=20may=20also=20be=20used=20as=20a=20constraint.=20= =20=20=20user=20defined=20rules=20(e.g.=20= "select=20the=20path=20with=20the=20maximum=20number=20of=0A=20=20=20=20=20=20=20= =20=20=20links=20having=20their=20first=20= bit=20set=201=20(e.g.=20encrypted=20links)").=20=20The=20LC=0A=20=20=20=20=20=20=20= =20=20=20object=20may=20also=20be=20used=20= as=20a=20constraint.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20When=20used=20as=20a=20recorded=20metric,=20a=20= counter=20is=20used=20to=20compress=20the=20=20=20=20When=20used=20as=20a=20recorded=20metric,=20a=20= counter=20is=20used=20to=20compress=20the=0A=20=20=20=20=20=20=20=20=20information=20where=20= the=20number=20of=20links=20for=20each=20Link=20Color=20is=20= =20=20=20information=20where=20the=20number=20= of=20links=20for=20each=20Link=20Color=20is=0A=20=20=20=20=20=20=20=20=20reported.=20= =20=20=20reported.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20Link=20Color=20(LC)=20object=20MAY=20be=20= present=20in=20the=20DAG=20Metric=20=20= =20=20The=20Link=20Color=20(LC)=20object=20MAY=20be=20present=20in=20the=20= DAG=20Metric=0A=20= =20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20Container.=20=20There=20MUST=20be=20no=20more=20than=20one=20LC=20object=20as=20a=20= constraint=20=20=20=20Container.=20=20= There=20MUST=20NOT=20be=20more=20than=20= one=20LC=20object=20as=20a=20constraint=0A=20=20=20=20=20=20=20=20=20per=20DAG=20Metric=20= Container,=20and=20no=20more=20than=20= one=20LC=20object=20as=20a=20metric=20=20=20=20per=20DAG=20Metric=20Container,=20and=20there=20MUST=20NOT=20be=20more=20than=20one=20= LC=0A=20=20=20=20=20= =20=20=20=20per=20DAG=20Metric=20Container.=20= =20=20=20object=20as=20a=20metric=20per=20= DAG=20Metric=20Container.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20There=20MUST=20be=20a=20at=20least=20one=20LC=20= sub-object=20per=20LC=20object.=20=20= =20=20There=20MUST=20be=20a=20at=20least=20one=20LC=20sub-object=20per=20= LC=20object.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= LC=20object=20does=20not=20contain=20any=20additional=20TLV.=20= =20=20=20The=20LC=20object=20does=20not=20= contain=20any=20additional=20TLV.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20LC=20object=20Type=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D8)=20=20=20=20The=20LC=20object=20Type=20is=20to=20be=20= assigned=20by=20IANA=20(recommended=20value=3D8)=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20LC=20object=20body=20is=20as=20follows:=20= =20=20=20The=20format=20of=20the=20LC=20= object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =201=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=203=20= =20=20=20=20=200=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=201=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=202=0A=20=20=20=20=20=20=20=20=20=20=200=201=202=203=20= 4=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=20=20=20=20=20=200=201=202=20= 3=204=205=206=207=208=209=200=201=202=203=204=205=206=207=208=209=200=20= 1=202=203=204=0A=20= =20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20=20=20=20= |=20=20=20=20=20=20Res=20=20=20=20=20=20|=20LC=20sub-objects=20= =20=20=20=20|=20=20=20=20=20=20Res=20=20=20=20= =20=20|=20LC=20sub-objects=0A=20=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=20= =20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20...=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20=20=20=20Figure=2017:=20= LC=20object=20format=20=20=20=20=20=20= =20Figure=2017:=20LC=20object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Res=20flags=20(8=20bits):=20Reserved=20field.=20=20This=20= field=20MUST=20be=20set=20to=20zero=0A=20=20=20=20=20=20=20=20=20=20on=20transmission=20= and=20MUST=20be=20ignored=20on=20receipt.=0A=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=0A=20=20=20=20=20=20=20=20=20When=20the=20LC=20= object=20is=20used=20as=20a=20recorded=20metric,=20the=20LC=20object=20= body=20=20=20=20When=20the=20LC=20= object=20is=20used=20as=20a=20recorded=20metric,=20the=20LC=20object=20= body=0A=20=20=20=20= =20=20=20=20=20comprises=20one=20or=20more=20LC=20Type=201=20= sub-objects.=20=20=20=20comprises=20= one=20or=20more=20LC=20Type=201=20sub-objects.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20format=20of=20the=20LC=20Type=201=20= sub-object=20body=20is=20as=20follows:=20=20=20=20The=20format=20of=20the=20LC=20Type=201=20= sub-object=20body=20is=20as=20follows:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= 1=20=20=20=20=200=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20= 1=0A=20=20=20= =20=20=20=20=20=20=200=201=202=203=204=205=206=207=208=209=200=201=20= 2=203=204=205=20=20=20=20=200=201=20= 2=203=204=205=206=207=208=209=200=201=202=203=204=205=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20Link=20= Color=20=20=20=20=20|=20=20Counter=20=20|=20=20=20=20|=20=20=20=20Link=20Color=20=20=20=20=20|=20=20= Counter=20=20|=0A=20= =20=20=20=20=20=20=20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= =20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20Figure=2018:=20LC=20Type=201=20sub-object=20= format=20=20=20=20=20=20Figure=2018:=20= LC=20Type=201=20sub-object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20When=20the=20LC=20object=20is=20used=20as=20a=20= constraint,=20the=20LC=20object=20body=20=20=20=20When=20the=20LC=20object=20is=20used=20as=20a=20= constraint,=20the=20LC=20object=20body=0A=20=20=20=20=20=20=20=20=20comprises=20one=20or=20= more=20LC=20Type=202=20sub-objects.=20= =20=20=20comprises=20one=20or=20more=20LC=20Type=202=20= sub-objects.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= format=20of=20the=20LC=20Type=202=20sub-object=20body=20is=20as=20= follows:=20=20=20=20The=20format=20= of=20the=20LC=20Type=202=20sub-object=20body=20is=20as=20= follows:=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20= =20=20=200=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201=20= =20=20=20=200=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=201=0A=20=20=20=20=20=20=20=20=20=20= 0=201=202=203=204=205=206=207=208=209=200=201=202=203=204=205=20= =20=20=20=200=201=202=203=204=205=206=207=208=20= 9=200=201=202=203=204=205=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20|=20= =20=20=20=20=20=20=20=20=20=20Link=20Color=20=20= =20=20=20=20=20=20|I|=20=20=20= =20|=20=20=20=20=20Link=20Color=20=20=20=20= |Reserved=20|I|=0A=20=20=20=20=20=20=20=20=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20=20= =20=20+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20Figure=2019:=20LC=20Type=202=20sub-object=20= format=20=20=20=20=20=20Figure=2019:=20= LC=20Type=202=20sub-object=20format=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20Res=20flags=20(7=20bits):=20Reserved=20field.=20=20This=20= field=20MUST=20be=20set=20to=20zero=0A=20=20=20=20=20=20=20=20=20=20on=20transmission=20= and=20MUST=20be=20ignored=20on=20receipt.=0A=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=0A=20=20=20=20=20=20=20=20=20I=20Bit:=20The=20I=20= bit=20is=20only=20relevant=20when=20the=20Link=20Color=20is=20used=20as=20= a=20=20=20=20I=20Bit:=20The=20I=20= bit=20is=20only=20relevant=20when=20the=20Link=20Color=20is=20used=20as=20= a=0A=20=20=20=20=20= =20=20= =20=20constraint.=20=20When=20cleared,=20this=20indicates=20that=20links=20= with=20the=20=20=20=20constraint.=20=20= When=20cleared,=20this=20indicates=20that=20links=20with=20the=0A=20=20=20=20=20=20=20=20=20= specified=20color=20must=20be=20included.=20=20When=20set,=20this=20= indicates=20that=20=20=20=20= specified=20color=20must=20be=20included.=20=20When=20set,=20this=20= indicates=20that=0A= =20=20=20=20=20=20=20=20=20links=20with=20the=20specified=20color=20must=20= be=20excluded.=20=20=20=20links=20= with=20the=20specified=20color=20must=20be=20excluded.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= The=20use=20of=20the=20LC=20object=20is=20= outside=20the=20scope=20of=20this=20= document.=20=20=20=20It=20is=20left=20to=20= the=20implementer=20to=20define=20the=20meaning=20of=20each=20= bit=20of=0A= =20=20=20=20=20=20=20=20=20=20the=2010-bit=20Link=20Color=20Flag=20= field.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=204.4.2.=20=20= Mode=20of=20operation=204.4.2.=20=20= Mode=20of=20operation=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20link=20color=20may=20be=20used=20as=20a=20= constraint=20or=20a=20metric.=20=20=20= =20The=20link=20color=20may=20be=20used=20as=20a=20constraint=20or=20a=20= metric.=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20When=20used=20as=20constraint,=20the=20LC=20object=20may=20be=20= inserted=20in=20the=20DAG=20=20=20=20= o=20=20When=20used=20as=20constraint,=20the=20LC=20object=20may=20be=20= inserted=20in=20the=20DAG=0A=20=20=20=20=20=20=20=20=20=20=20=20Metric=20= Container=20to=20indicate=20that=20links=20with=20a=20specific=20= color=20=20=20=20=20=20=20Metric=20= Container=20to=20indicate=20that=20links=20with=20a=20specific=20= color=0A=20=20=20=20= =20=20=20=20=20=20=20=20should=20be=20included=20or=20excluded=20= from=20the=20computed=20path.=20=20=20= =20=20=20=20should=20be=20included=20or=20excluded=20from=20the=20= computed=20path.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20When=20used=20as=20recorded=20metric,=20each=20node=20along=20the=20= path=20may=20insert=20=20=20=20o=20=20= When=20used=20as=20recorded=20metric,=20each=20node=20along=20the=20path=20= may=20insert=0A=20= =20=20=20=20=20=20=20=20=20=20=20a=20LC=20object=20in=20the=20DAG=20= Metric=20Container=20to=20report=20the=20color=20of=20the=20= =20=20=20=20=20=20a=20LC=20object=20in=20the=20= DAG=20Metric=20Container=20to=20report=20the=20color=20of=20the=0A=20=20=20=20=20=20=20=20=20=20=20= =20local=20link.=20=20If=20there=20is=20already=20a=20LC=20object=20= reporting=20a=20similar=20=20=20=20=20= =20=20local=20link.=20=20If=20there=20is=20already=20a=20LC=20object=20= reporting=20a=20similar=0A=20=20=20=20=20=20=20=20=20=20=20=20color,=20the=20= node=20MUST=20NOT=20add=20another=20identical=20LC=20sub-object=20= and=20=20=20=20=20=20=20color,=20the=20= node=20MUST=20NOT=20add=20another=20identical=20LC=20sub-object=20= and=0A=20=20=20=20= =20=20=20=20=20=20=20=20MUST=20increment=20the=20counter=20= field.=20=20=20=20=20=20=20MUST=20= increment=20the=20counter=20field.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=205.=20=20Computation=20of=20dynamic=20metrics=20and=20attributes=20= 5.=20=20Computation=20of=20Dynamic=20Metrics=20and=20Attributes=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20As=20already=20pointed=20= out,=20dynamically=20calculated=20metrics=20are=20of=20the=20= =20=20=20As=20already=20pointed=20out,=20= dynamically=20calculated=20metrics=20are=20of=20the=0A=20=20=20=20=20=20=20=20=20= utmost=20importance=20in=20many=20circumstances=20in=20LLNs.=20=20This=20= is=20mainly=20=20=20=20utmost=20= importance=20in=20many=20circumstances=20in=20LLNs.=20=20This=20is=20= mainly=0A=20=20=20= =20=20=20=20=20=20because=20a=20variety=20of=20metrics=20change=20= on=20a=20frequent=20basis,=20thus=20=20= =20=20because=20a=20variety=20of=20metrics=20change=20on=20a=20frequent=20= basis,=20thus=0A=20= =20=20=20=20=20=20=20=20implying=20the=20need=20to=20adapt=20the=20= routing=20decisions.=20=20That=20being=20said,=20=20=20=20implying=20the=20need=20to=20adapt=20the=20= routing=20decisions.=20=20That=20being=20said,=0A=20=20=20=20=20=20=20=20=20care=20must=20be=20= given=20to=20the=20pace=20at=20which=20changes=20are=20reported=20in=20= the=20=20=20=20care=20must=20be=20= given=20to=20the=20pace=20at=20which=20changes=20are=20reported=20in=20= the=0A=20=20=20=20= =20=20=20=20=20network.=20=20The=20attributes=20will=20change=20= according=20to=20their=20own=20time=20= =20=20=20network.=20=20The=20attributes=20will=20change=20according=20to=20= their=20own=20time=0A= =20=20=20=20=20=20=20=20=20scales.=20=20RPL=20controls=20the=20reporting=20= rate.=20=20=20=20scales.=20=20RPL=20= controls=20the=20reporting=20rate.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20To=20minimize=20metric=20updates,=20= multi-threshold=20algorithms=20MAY=20be=20used=20to=20=20=20=20To=20minimize=20metric=20updates,=20= multi-threshold=20algorithms=20MAY=20be=20used=20to=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2026,=20line=20= 6=20skipping=20= to=20change=20at=20page=2026,=20line=20= 12=0A=20=20=20=20=20=20=20=20=20= IANA=20is=20requested=20to=20establish=20a=20new=20top-level=20registry=20= to=20contain=20=20=20=20IANA=20is=20= requested=20to=20establish=20a=20new=20top-level=20registry=20to=20= contain=0A=20=20=20= =20=20=20=20=20=20all=20Routing=20Metric/Constraint=20objects=20= codepoints=20and=20sub-registries.=20=20= =20=20all=20Routing=20Metric/Constraint=20objects=20codepoints=20and=20= sub-registries.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20The=20= allocation=20policy=20for=20each=20new=20registry=20is=20by=20IETF=20= Consensus:=20new=20=20=20=20The=20= allocation=20policy=20for=20each=20new=20registry=20is=20by=20IETF=20= Consensus:=20new=0A= =20=20=20=20=20=20=20=20=20values=20are=20assigned=20through=20the=20IETF=20= consensus=20process=20(see=20=20=20=20= values=20are=20assigned=20through=20the=20IETF=20consensus=20process=20= (see=0A=20=20=20=20= =20=20=20=20=20[RFC5226]).=20=20Specifically,=20new=20= assignments=20are=20made=20via=20RFCs=20approved=20=20=20=20[RFC5226]).=20=20Specifically,=20new=20= assignments=20are=20made=20via=20RFCs=20approved=0A=20=20=20=20=20=20=20=20=20by=20= the=20IESG.=20=20Typically,=20the=20IESG=20will=20seek=20input=20on=20= prospective=20=20=20=20by=20the=20= IESG.=20=20Typically,=20the=20IESG=20will=20seek=20input=20on=20= prospective=0A=20=20= =20=20=20=20=20=20=20assignments=20from=20appropriate=20persons=20= (e.g.,=20a=20relevant=20Working=20Group=20=20=20=20assignments=20from=20appropriate=20persons=20= (e.g.,=20a=20relevant=20Working=20Group=0A=20=20=20=20=20=20=20=20=20if=20one=20= exists).=20=20=20=20if=20one=20= exists).=0A=20=20=20= =20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 6.1.=20=20Routing=20Metric/Constraint=20type=206.1.=20= =20Routing=20Metric/Constraint=20Type=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20for=20Routing=20Metric/Constraint=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20for=20Routing=20Metric/Constraint=0A=20=20=20=20=20=20=20=20=20objects.=20=20Each=20= Routing=20Metric/Constraint=20object=20has=20a=20type=20value.=20= =20=20=20objects.=20=20Each=20Routing=20= Metric/Constraint=20object=20has=20a=20type=20value.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Value=20=20=20=20=20= Meaning=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=20Reference=20=20=20=20= Value=20=20=20=20=20Meaning=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=20Reference=0A=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20=20=20= =20Node=20State=20and=20Attribute=20=20=20=20=20=20This=20= document=20=20=20=20=20=201=20=20=20=20= =20=20=20Node=20State=20and=20Attribute=20=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=202=20=20=20=20=20=20=20Node=20Energy=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=20= =20=20=20=20=202=20=20=20=20=20=20=20Node=20= Energy=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=203=20=20=20=20=20=20=20Hop=20Count=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=20=20=20=20=20=203=20=20=20=20= =20=20=20Hop=20Count=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=204=20=20=20=20=20=20= =20Link=20Throughput=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=20=20=20=20=20=204=20=20=20=20= =20=20=20Link=20Throughput=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= This=20document=0A= =20=20=20=20=20=20=20=20=20=20=205=20=20=20=20=20=20=20Link=20Latency=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20document=20= =20=20=20=20=205=20=20=20=20=20=20=20Link=20= Latency=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=206=20=20=20=20=20=20=20Link=20Quality=20= Level=20=20=20=20=20=20=20=20=20=20=20=20This=20document=20= =20=20=20=20=206=20=20=20=20=20=20=20Link=20= Quality=20Level=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=207=20=20=20=20=20=20=20Link=20ETX=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20This=20= document=20=20=20=20=20=207=20=20=20=20= =20=20=20Link=20ETX=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=208=20=20=20=20=20=20= =20Link=20Color=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= This=20document=20=20=20=20=20=208=20= =20=20=20=20=20=20Link=20Color=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=206.2.=20=20Routing=20Metric/Constraint=20common=20header=206.2.=20=20Routing=20Metric/Constraint=20TLV=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20= =20=20=20IANA=20is=20= requested=20to=20create=20a=20registry=20used=20for=20all=20TLVs=20= carried=0A=20= =20=20=20=20=20=20=20=20=20within=20Routing=20Metric/Constraint=20= objects.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=206.3.=20=20Routing=20= Metric/Constraint=20Common=20Header=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20to=20manage=20the=20codespace=20of=20the=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20to=20manage=20the=20codespace=20of=20the=0A=20=20=20=20=20=20=20=20=20A=20= field=20of=20the=20Routing=20Metric/Constraint=20common=20= header.=20=20=20=20A=20field=20of=20= the=20Routing=20Metric/Constraint=20common=20header.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Codespace=20of=20the=20= A=20field=20(Routing=20Metric/Constraint=20common=20header)=20= =20=20=20Codespace=20of=20the=20A=20field=20= (Routing=20Metric/Constraint=20common=20header)=0A=20=20=20=20=20=20=20=20=20=20= Value=20=20Meaning=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=20Reference=20=20=20=20=20Value=20=20Meaning=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= Reference=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20=20= =200=20=20=20=20Routing=20metric=20is=20additive=20=20=20=20=20=20=20=20=20= =20=20This=20document=20=20=20=20=20=20= =200=20=20=20=20Routing=20metric=20is=20additive=20=20=20=20=20=20=20=20=20= =20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20=201=20=20=20=20= Routing=20metric=20reports=20a=20maximum=20=20=20=20=20This=20= document=20=20=20=20=20=20=201=20=20=20= =20Routing=20metric=20reports=20a=20maximum=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=20=202=20=20=20=20Routing=20metric=20reports=20= a=20minimum=20=20=20=20=20This=20document=20=20=20=20=20=20=202=20=20=20=20Routing=20metric=20= reports=20a=20minimum=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2027,=20line=20= 9=20skipping=20= to=20change=20at=20page=2027,=20line=20= 15=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20o=20=20Defining=20= RFC=20=20=20=20o=20=20Defining=20= RFC=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= Several=20bits=20are=20defined=20for=20the=20Routing=20Metric/Constraint=20= common=20=20=20=20Several=20bits=20= are=20defined=20for=20the=20Routing=20Metric/Constraint=20common=0A=20=20=20=20=20=20=20=20=20= header=20in=20this=20document.=20=20The=20following=20values=20have=20= been=20assigned:=20=20=20=20header=20= in=20this=20document.=20=20The=20following=20values=20have=20been=20= assigned:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Codespace=20of=20the=20Flag=20field=20(Routing=20Metric/Constraint=20= common=20header)=20=20=20=20= Codespace=20of=20the=20Flag=20field=20(Routing=20Metric/Constraint=20= common=20header)=0A= =20=20=20=20=20=20=20=20=20=20=20Bit=20=20=20=20=20=20Description=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Reference=20=20=20=20=20=20Bit=20=20=20=20=20=20Description=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Reference=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=2012-15=20=20=20Precedence=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20This=20document=20=20=20=20=20=20=2012-15=20=20=20Precedence=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20=20= =20=209-11=20=20=20Additive/Max/Min/Multi=20=20=20This=20= document=20=20=20=20=20=20=209-11=20= =20=20=20Additive/Max/Min/Multi=20=20=20= This=20document=0A= =20=20=20=20=20=20=20=20=20=20=20=208=20=20=20=20=20=20=20= Recorded/Aggregated=20=20=20=20=20=20This=20document=20=20=20=20=20=20=208=20=20=20=20=20=20=20= Recorded/Aggregated=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20= =207=20=20=20=20=20=20=20Optional=20Constraint=20=20=20=20=20=20This=20= document=20=20=20=20=20=20=207=20=20=20= =20=20=20=20Optional=20Constraint=20=20=20=20=20=20This=20= document=0A=20=20=20= =20=20=20=20=20=20=20=20=206=20=20=20=20=20=20=20Constraint/Metric=20= =20=20=20=20=20=20=20This=20document=20=20=20=20=20=20=206=20=20=20=20=20=20=20= Constraint/Metric=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20= =205=20=20=20=20=20=20=20P=20(Partial)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20This=20document=20=20=20=20=20=20= =205=20=20=20=20=20=20=20P=20(Partial)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20This=20document=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=206.3.=20=20NSA=20= object=206.4.=20=20NSA=20Object=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20to=20manage=20the=20codespace=20of=20the=20=20=20=20IANA=20is=20requested=20to=20create=20a=20= registry=20to=20manage=20the=20codespace=20of=20the=0A=20=20=20=20=20=20=20=20=20= Flag=20field=20of=20the=20NSA=20object.=20=20=20=20Flag=20field=20of=20the=20NSA=20object.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20New=20bit=20numbers=20= may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=20=20=20=20New=20bit=20= numbers=20may=20be=20allocated=20only=20by=20an=20IETF=20Consensus=20= action.=0A=20=20=20= =20=20=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20the=20= following=20qualities:=20=20=20=20= Each=20bit=20should=20be=20tracked=20with=20the=20following=20= qualities:=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20Bit=20number=20=20=20=20o=20=20= Bit=20number=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20Capability=20Description=20=20=20=20= o=20=20Capability=20Description=0A=20=20=20=20=20=20=20=0A=20=20=20=20=20=20= skipping= =20to=20change=20at=20page=2027,=20line=20= 38=20skipping=20= to=20change=20at=20page=2027,=20line=20= 44=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20Several=20bits=20are=20= defined=20for=20the=20NSA=20object=20flag=20field=20in=20this=20= =20=20=20Several=20bits=20are=20defined=20for=20= the=20NSA=20object=20flag=20field=20in=20this=0A=20=20=20=20=20=20=20=20=20document.=20=20The=20= following=20values=20have=20been=20assigned:=20=20=20=20document.=20=20The=20following=20values=20have=20= been=20assigned:=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= Codespace=20of=20the=20Flag=20field=20(NSA=20object)=20=20=20=20Codespace=20of=20the=20Flag=20field=20(NSA=20= object)=0A=20=20=20= =20=20=20=20=20=20=20=20Bit=20=20=20=20=20=20Description=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Reference=20=20=20=20=20=20Bit=20=20=20=20=20=20Description=20=20=20=20= =20=20=20=20=20=20=20=20=20=20Reference=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20=20=20=2014=20=20=20=20=20=20Aggregator=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20This=20document=20=20=20=20=20=20=2014=20=20=20=20=20=20Aggregator=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20This=20document=0A=20=20=20=20=20=20=20=20=20=20=20= =2015=20=20=20=20=20=20Overloaded=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20This=20document=20=20=20=20=20=20=20= 15=20=20=20=20=20=20Overloaded=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= This=20document=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= 6.4.=20=20Hop-Count=20= object=206.5.=20=20Hop-Count=20Object=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20IANA=20is=20requested=20= to=20create=20a=20registry=20to=20manage=20the=20codespace=20of=20= the=20=20=20=20IANA=20is=20requested=20= to=20create=20a=20registry=20to=20manage=20the=20codespace=20of=20= the=0A=20=20=20=20= =20=20=20=20=20Flag=20field=20of=20the=20Hop-count=20= object.=20=20=20=20Flag=20field=20of=20= the=20Hop-count=20object.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20New=20bit=20numbers=20may=20be=20allocated=20= only=20by=20an=20IETF=20Consensus=20action.=20=20=20=20New=20bit=20numbers=20may=20be=20allocated=20= only=20by=20an=20IETF=20Consensus=20action.=0A=20=20=20=20=20=20=20=20=20Each=20bit=20should=20= be=20tracked=20with=20the=20following=20qualities:=20=20=20=20Each=20bit=20should=20be=20tracked=20with=20the=20= following=20qualities:=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20o=20=20Bit=20number=20=20=20=20o=20=20Bit=20number=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20o=20=20Capability=20Description=20= =20=20=20o=20=20Capability=20= Description=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20o=20= =20Defining=20RFC=20=20=20=20o=20=20= Defining=20RFC=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20No=20= Flag=20is=20currently=20defined.=20=20= =20=20No=20Flag=20is=20currently=20defined.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=207.=20=20Security=20considerations=207.=20=20Security=20Considerations=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Routing=20metrics=20should=20be=20handled=20in=20= a=20secure=20and=20trustful=20manner.=20=20=20=20Routing=20metrics=20should=20be=20handled=20in=20= a=20secure=20and=20trustful=20manner.=0A=20=20=20=20=20=20=20=20=20For=20instance,=20RPL=20= should=20not=20allow=20a=20malicious=20node=20to=20falsely=20= =20=20=20For=20instance,=20RPL=20should=20not=20= allow=20a=20malicious=20node=20to=20falsely=0A=20=20=20=20=20=20=20=20=20advertise=20that=20it=20= has=20good=20metrics=20for=20routing,=20be=20added=20as=20a=20= router=20=20=20=20advertise=20that=20= it=20has=20good=20metrics=20for=20routing,=20be=20added=20as=20a=20= router=0A=20=20=20= =20=20=20=0A=20=20=20=20=20=20= =20= =20=20for=20other=20nodes'=20traffic=20and=20intercept=20packets.=20=20= Since=20the=20routing=20=20=20=20= for=20other=20nodes'=20traffic=20and=20intercept=20packets.=20=20Another=20attack=20may=0A=20=20=20=20=20=20=20=20=20metrics/constraints=20= are=20carried=20within=20RPL=20message,=20the=20security=20= =20=20=20consist=20= of=20making=20intermitment=20attacks=20on=20a=20link=20in=20an=20attempt=20= to=0A=20=20= =20=20=20=20=20=20=20routing=20mechanisms=20defined=20in=20= [I-D.ietf-roll-rpl]=20applies=20here.=20=20=20=20constantly=20modify=20= the=20link=20quality=20and=20consequently=20the=20= associated=0A= =20=20=20=20=20=20=20=20=20=20routing=20metric,=20thus=20leading=20to=20= potential=20fluctuation=20in=20the=20DAG.=20=20It=0A=20=20=20=20=20=20=20= =20=20=20is=20thus=20= RECOMMENDED=20for=20a=20RPL=20implementation=20to=20put=20in=20= place=0A=20= =20=20=20=20=20=20=20=20=20mechanism=20so=20as=20to=20stop=20advertising=20= routing=20metrics=20for=20highly=0A=20=20=20=20=20=20=20=20=20=20unstable=20links=20= that=20may=20be=20subject=20to=20attacks.=0A=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=0A=20=20=20=20=20=20=20=20=20=20Since=20the=20routing=20metrics/constraints=20= are=20carried=20within=20RPL=20message,=0A=20=20=20=20=20=20=20=20=20=20the=20security=20routing=20mechanisms=20= defined=20in=20[I-D.ietf-roll-rpl]=0A=20=20=20=20=20=20=20=20=20=20applies=20here.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=208.=20=20Acknowledgements=208.=20=20Acknowledgements=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20The=20authors=20would=20like=20to=20acknowledge=20= the=20contributions=20of=20Young=20Jae=20=20=20=20The=20authors=20would=20like=20to=20acknowledge=20= the=20contributions=20of=20Young=20Jae=0A=20=20=20=20=20=20=20=20=20Kim,=20Hakjin=20Chong,=20= David=20Meyer,=20Mischa=20Dohler,=20Anders=20Brandt,=20Philip=20= =20=20=20Kim,=20Hakjin=20Chong,=20David=20= Meyer,=20Mischa=20Dohler,=20Anders=20Brandt,=20Philip=0A=20=20=20=20=20=20=20=20=20= Levis,=20Pascal=20Thubert,=20Richard=20Kelsey,=20Jonathan=20Hui,=20= Alexandru=20=20=20=20Levis,=20Pascal=20= Thubert,=20Richard=20Kelsey,=20Jonathan=20Hui,=20Alexandru=0A=20=20=20=20=20=20=20=20=20= Petrescu,=20Richard=20Kelsey,=20Mathilde=20Durvy,=20Phoebus=20Chen,=20= Tim=20Winter,=20=20=20=20Petrescu,=20= Richard=20Kelsey,=20Mathilde=20Durvy,=20Phoebus=20Chen,=20Tim=20= Winter,=0A=20=20=20= =20=20=20=20=20=20Mukul=20Goyal,=20Yoav=20Ben-Yehezkel,=20Matteo=20= Paris,=20Omprakash=20Gnawali,=20Mads=20=20=20=20Mukul=20Goyal,=20Yoav=20Ben-Yehezkel,=20Matteo=20= Paris,=20Omprakash=20Gnawali,=20Mads=0A=20=20=20=20=20=20=20=20=20Westergreen,=20Mukul=20= Goyal=20and=20David=20Culler=20for=20their=20review=20and=20= =20=20=20Westergreen,=20Mukul=20Goyal=20and=20= David=20Culler=20for=20their=20review=20and=0A=20=20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20= valuable=20comments.=20=20=20=20= valuable=20comments.=20=20Special=20thank=20to=20= Adrian=20Farrel=20for=20his=20thourough=0A=20=20=20=20=20=20=20=20=20=20= review.=0A=20= =20=20=20=20=20=20=0A=20=20=20=20=20=209.=20=20= References=209.=20=20= References=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=209.1.=20=20= Normative=20references=209.1.=20=20= Normative=20references=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20=20[I-D.ietf-roll-rpl]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Winter,=20T.,=20Thubert,=20P.,=20Brandt,=20A.,=20Clausen,=20T.,=20= Hui,=20J.,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Kelsey,=20R.,=20= Levis,=20P.,=20Pister,=20K.,=20Struik,=20R.,=20and=20J.=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20= =20=20=20=20=20=20=20Vasseur,=20"RPL:=20IPv6=20Routing=20Protocol=20for=20= Low=20power=20and=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Lossy=20Networks",=20draft-ietf-roll-rpl-15=20(work=20= in=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20progress),=20= November=202010.=0A=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=0A=20= =20=20=20=20=20=20=20=20[RFC2119]=20=20Bradner,=20S.,=20"Key=20words=20= for=20use=20in=20RFCs=20to=20Indicate=20=20=20=20[RFC2119]=20=20Bradner,=20S.,=20"Key=20words=20= for=20use=20in=20RFCs=20to=20Indicate=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Requirement=20Levels",=20BCP=2014,=20RFC=202119,=20March=20= 1997.=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Requirement=20Levels",=20BCP=2014,=20RFC=202119,=20March=20= 1997.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= [RFC5226]=20=20Narten,=20T.=20and=20H.=20Alvestrand,=20"Guidelines=20for=20= Writing=20an=20=20=20=20[RFC5226]=20=20= Narten,=20T.=20and=20H.=20Alvestrand,=20"Guidelines=20for=20Writing=20= an=0A=20=20=20=20=20= =20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20IANA=20Considerations=20Section=20= in=20RFCs",=20BCP=2026,=20RFC=205226,=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20IANA=20= Considerations=20Section=20in=20RFCs",=20BCP=2026,=20RFC=205226,=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20May=202008.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20May=20= 2008.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=209.2.=20=20= Informative=20references=209.2.=20=20= Informative=20references=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20[I-D.ietf-roll-rpl]=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Winter,=20T.,=20Thubert,=20P.,=20Brandt,=20A.,=20Clausen,=20T.,=20= Hui,=20J.,=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Kelsey,=20R.,=20= Levis,=20P.,=20Networks,=20D.,=20Struik,=20R.,=20and=20= J.=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Vasseur,=20= "RPL:=20IPv6=20Routing=20Protocol=20for=20Low=20power=20= and=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Lossy=20= Networks",=20draft-ietf-roll-rpl-14=20(work=20in=20= =0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20progress),=20October=20= 2010.=20=0A=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= =0A=20=20=20=20=20=20=20=20=20= [I-D.ietf-roll-terminology]=20=20=20=20= [I-D.ietf-roll-terminology]=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Vasseur,=20J.,=20"Terminology=20in=20Low=20power=20And=20= Lossy=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Vasseur,=20J.,=20"Terminology=20in=20Low=20power=20And=20= Lossy=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Networks",=20= draft-ietf-roll-terminology-04=20(work=20in=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Networks",=20= draft-ietf-roll-terminology-04=20(work=20in=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20progress),=20September=202010.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20progress),=20= September=202010.=0A= =20=20=20=20=20=20=20=0A=20=20=20=20=20=20= =0A=20=20=20=20=20=20= =20=20=20=20[Khanna1989J=20A.=20Zinky,=20A.=20Khanna,=20and=20G.=20= Vichniac.=20"Performance=20of=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20the=20Revised=20Routing=20Metric=20for=20ARPANET=20and=20= MILNET.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Submitted=20to=20MILCOM=2089,=20March=201989=0A=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=0A=20=20=20=20=20=20=20=20=20[RFC1195]=20=20Callon,=20= R.,=20"Use=20of=20OSI=20IS-IS=20for=20routing=20in=20TCP/IP=20= and=20=20=20=20[RFC1195]=20=20= Callon,=20R.,=20"Use=20of=20OSI=20IS-IS=20for=20routing=20in=20TCP/IP=20= and=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20dual=20= environments",=20RFC=201195,=20December=201990.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20dual=20= environments",=20RFC=201195,=20December=201990.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC2328]=20=20Moy,=20= J.,=20"OSPF=20Version=202",=20STD=2054,=20RFC=202328,=20April=20= 1998.=20=20=20=20[RFC2328]=20=20Moy,=20= J.,=20"OSPF=20Version=202",=20STD=2054,=20RFC=202328,=20April=20= 1998.=0A=20=20=20=20= =20=20=20=0A=20=20=20=20=20=20=20=20=20= [RFC2702]=20=20Awduche,=20D.,=20Malcolm,=20J.,=20Agogbua,=20J.,=20= O'Dell,=20M.,=20and=20J.=20=20=20=20= [RFC2702]=20=20Awduche,=20D.,=20Malcolm,=20J.,=20Agogbua,=20J.,=20= O'Dell,=20M.,=20and=20J.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20McManus,=20"Requirements=20for=20Traffic=20Engineering=20Over=20= MPLS",=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20McManus,=20"Requirements=20for=20Traffic=20Engineering=20= Over=20MPLS",=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20RFC=202702,=20= September=201999.=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20RFC=202702,=20September=201999.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC3209]=20=20= Awduche,=20D.,=20Berger,=20L.,=20Gan,=20D.,=20Li,=20T.,=20Srinivasan,=20= V.,=20=20=20=20[RFC3209]=20=20= Awduche,=20D.,=20Berger,=20L.,=20Gan,=20D.,=20Li,=20T.,=20Srinivasan,=20= V.,=0A=20=20=20=20= =20=20=20= =0A=20=20= =20=20=20=20skipping=20to=20change=20at=20page=20= 29,=20line=2031=20skipping=20to=20change=20at=20page=20= 30,=20line=205=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Networks",=20RFC=205673,=20October=20= 2009.=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Networks",=20RFC=205673,=20October=202009.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC5826]=20=20Brandt,=20= A.,=20Buron,=20J.,=20and=20G.=20Porcu,=20"Home=20Automation=20= =20=20=20[RFC5826]=20=20Brandt,=20A.,=20= Buron,=20J.,=20and=20G.=20Porcu,=20"Home=20Automation=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Routing=20Requirements=20in=20Low-Power=20and=20= Lossy=20Networks",=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20Routing=20Requirements=20in=20Low-Power=20and=20= Lossy=20Networks",=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20RFC=205826,=20= April=202010.=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20RFC=205826,=20April=202010.=0A=20=20=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20[RFC5867]=20=20= Martocci,=20J.,=20De=20Mil,=20P.,=20Riou,=20N.,=20and=20W.=20= Vermeylen,=20=20=20=20[RFC5867]=20=20= Martocci,=20J.,=20De=20Mil,=20P.,=20Riou,=20N.,=20and=20W.=20= Vermeylen,=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"Building=20= Automation=20Routing=20Requirements=20in=20Low-Power=20and=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= "Building=20Automation=20Routing=20Requirements=20in=20Low-Power=20= and=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Lossy=20= Networks",=20RFC=205867,=20June=202010.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Lossy=20= Networks",=20RFC=205867,=20June=202010.=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=0A=20=20=20= =20=20=20=20=20=20[Khanna1989J=20A.=20= Zinky,=20A.=20Khanna,=20and=20G.=20Vichniac.=20"Performance=20= of=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20= Revised=20Routing=20Metric=20for=20ARPANET=20and=20= MILNET.=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Submitted=20to=20MILCOM=2089,=20March=201989=20=0A= =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=0A=20=20=20=20=20=20Authors'=20= Addresses=20Authors'=20= Addresses=0A=20=20= =20=20=20=20=20=0A=20=20=20=20=20=20=20=20=20JP=20= Vasseur=20(editor)=20=20=20=20JP=20= Vasseur=20(editor)=0A= =20=20=20=20=20=20=20=20=20Cisco=20Systems,=20Inc=20=20=20=20Cisco=20Systems,=20Inc=0A=20=20=20=20=20=20=20=20=2011,=20= Rue=20Camille=20Desmoulins=20=20=20=20= 11,=20Rue=20Camille=20Desmoulins=0A=20=20=20=20=20=20=20=20=20Issy=20Les=20= Moulineaux,=20=20=2092782=20=20=20=20= Issy=20Les=20Moulineaux,=20=20=2092782=0A=20=20=20=20=20=20=20=20=20France=20= =20=20=20France=0A=20=20=20=20=20=20=20=0A= =20=20=20=20=20=20=20=20=20Email:=20jpv@cisco.com=20=20=20=20Email:=20jpv@cisco.com=0A=20=20=20=20=20=20=20= =0A=0A=20=20=20=20=20=20=0A= =20=20=20=20=20 End=20of=20changes.=20107=20= change=20blocks. =0A=20=20=20=20=20259=20lines=20changed=20or=20= deleted=20313=20lines=20changed=20or=20= added=0A=20=20=20=20=20
This=20html=20diff=20was=20= produced=20by=20rfcdiff=201.40.=20The=20latest=20version=20is=20= available=20from=20http://tools.ietf.org/to= ols/rfcdiff/=20=0A=20=20=20=0A=20=20=20=0A=20= =20=20=0AYtext/html_=10=1Dhttp://tools.ietf.org/rfcdiff=00=00= =00=08=00=00=00=0D=00=00=00=1F=00=00=001=00=00=003=00=00=00<=00=00=00N=00=00= =00d=00=00=00z=00=00=00=89=00=00=03=C3=00=00=03=D0=00=00=05=E8=00=00=06=0C= =00=00=06=17=00=00=06.=00=00=06L=00=00=06M=00=00=06S=00=04=C7=97=00=04=C7=A1= =00=00=00=00=00=00=04=01=00=00=00=00=00=00=00=15=00=00=00=00=00=00=00=00=00= =00=00=00=00=04=C7=C1= --Apple-Mail-166--131453421 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail-166--131453421 Content-Disposition: attachment; filename=draft-ietf-roll-routing-metrics-13.txt Content-Type: text/plain; name="draft-ietf-roll-routing-metrics-13.txt" Content-Transfer-Encoding: quoted-printable Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track M. Kim, Ed. Expires: June 5, 2011 Corporate Technology Group, KT K. Pister Dust Networks N. Dejean Coronis SAS D. Barthel France Telecom Orange December 6, 2010 Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-ietf-roll-routing-metrics-13 Abstract 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. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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 in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Vasseur, et al. Expires June 5, 2011 [Page 1] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 This Internet-Draft will expire on June 5, 2011. 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 Simplified BSD License. Vasseur, et al. Expires June 5, 2011 [Page 2] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. DAG Metric Container Format . . . . . . . . . . . . . . . 7 2.2. Use of Multiple DAG Metric Containers . . . . . . . . . . 10 2.3. Metric Usage . . . . . . . . . . . . . . . . . . . . . . . 10 3. Node Metric/Constraint Objects . . . . . . . . . . . . . . . . 11 3.1. Node State and Attributes Object . . . . . . . . . . . . . 11 3.2. Node Energy Object . . . . . . . . . . . . . . . . . . . . 13 3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 16 4. Link Metric/Constraint Objects . . . . . . . . . . . . . . . . 17 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Link Reliability . . . . . . . . . . . . . . . . . . . . . 19 4.3.1. The Link Quality Level Reliability Metric . . . . . . 20 4.3.2. The Expected Transmission Count (ETX) reliability object . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 23 4.4.1. Link Color Object Description . . . . . . . . . . . . 23 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 25 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 26 6.2. Routing Metric/Constraint TLV . . . . . . . . . . . . . . 26 6.3. Routing Metric/Constraint Common Header . . . . . . . . . 26 6.4. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Vasseur, et al. Expires June 5, 2011 [Page 3] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 1. Introduction This document makes use of the terminology defined in [I-D.ietf-roll-terminology]. Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]) make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. One of the prime objectives of this document is to define a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints. New routing metrics and constraints could be defined in the future, as needed. RPL is a distance vector routing protocol variant that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: o The Destination Oriented Directed Acyclic Graph (DODAG) root as defined in [I-D.ietf-roll-rpl] may advertise a routing constraint used as a "filter" to prune links and nodes that do not satisfy specific properties. For example, it may be required for the path to only traverse nodes that are mains powered or links that have at least a minimum reliability or a specific "color" reflecting a user defined link characteristic (e.g the link layer supports encryption). o A routing metric is a quantitative value that is used to evaluate the path cost. Link and node metrics are usually (but not always) additive. Vasseur, et al. Expires June 5, 2011 [Page 4] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The best path is the path that satisfies all supplied constraints (if any) and that has the lowest cost with respect to some specified metrics. It is also called the shortest constrained path (in the presence of constraints). Routing metrics may be categorized according to the following characteristics: o Link versus Node metrics o Qualitative versus quantitative o Dynamic versus static Routing requirements documents (see [RFC5673], [RFC5826] [RFC5548] and [RFC5867]) observe that it must be possible to take into account a variety of node constraints/metrics during path computation. Some link or node characteristics (e.g. link reliability, remaining energy on the node) may be used by RPL either as routing constraints or as metrics. For example, the path may be computed to avoid links that do not provide a sufficient level of reliability (use as a constraint) or as the path offering most links with a specified reliability level (use as a metric). This document provides the flexibility to use link and node characterisics either as constraints and/or metrics. The use of link and node routing metrics and constraints is not exclusive (e.g. it is possible to advertise a "hop count" both as a metric to optimize the computed path and as a constraint (e.g. "Path should not exceed n hops")). Links in LLN commonly have rapidly changing node and link characteristics: thus routing metrics must be dynamic and techniques must be used to smooth out the dynamicity of these metrics so as to avoid routing oscillations. For instance, in addition to the dynamic nature of some links (e.g. wireless but also Powerline Communication (PLC) links), nodes' resources such as residual energy are changing continuously and may have to be taken into account during the path computation. It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2 (see [[Khanna1989J]). The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, lots of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non IP) networks. Vasseur, et al. Expires June 5, 2011 [Page 5] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 Very careful attention must be given to the pace at which routing metrics and attributes values change in order to preserve routing stability. When using a dynamic routing metric, a RPL implementation should make use of a multi-threshold scheme rather than fine granular metric updates reflecting each individual change to avoid spurious and unneccessary routing changes. The requirements on reporting frequency may differ among metrics, thus different reporting rates may be used for each metric. The set of routing metrics and constraints used by an RPL deployment is signaled along the DAG that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DAG Information Option (DIO) message specified in [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different characteristics. For example, it may be desirable to build a DAG with the goal to maximize reliability by using the link reliability metric to compute the "best" path. Another example might be to use the energy node characteristic (e.g. mains powered versus battery operated) as a node constraint when building the DAG so as to avoid battery powered nodes in the DAG while optimizing the link throughput. The specification of objective functions used to compute the DAG built by RPL is out of the scope of this document. This document defines routing metrics and constraints that 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 and could be used with any routing metrics and/or constraints such as the ones specified in this document. Some metrics are either aggregated or recorded. An aggregated metric is adjusted as the DIO message travels along the DAG. For example, if the metric is the number of hops, each node updates the path cost that reflects the number of traversed hops along the DAG. By contrast, for a recorded metric, each node adds a sub-object reflecting the local valuation of the metric. For example, it might be desirable to record the link quality level along a path. In this case, each visited node adds a sub-object recording the local link quality level. In order to limit the number of sub-objects, the use of a counter may be desirable (e.g. record the number of links with a certain link quality level), thus compressing the information to reduce the message length. Upon receiving the DIO message from a set of parents, a node might decide according to the OF and local policy which node to choose as a parent based on the maximum number of links with a specific link reliability level, for example. Vasseur, et al. Expires June 5, 2011 [Page 6] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 Note that the routing metrics and constraints specified in this document are not specific to any particular link layer. An internal API between the MAC layer and RPL may be used to accurately reflect the metrics values of the link (wireless, wired, PLC). Since a set of metrics and constraints will be used for links and nodes in LLN, it is critical to ensure the use of consistent metric calculation mechanisms for all links and nodes in the network, similarly to the case of inter-domain IP routing. 2. Object Formats 2.1. DAG Metric Container Format 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Type=3D2 | Option Len |Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Figure 1: DAG Metric Container format The Routing Metric/Constraint objects represent a metric or a constraint of a particular type. They may appear in any order in the DAG Metric Container. They have a common format consisting of one or more bytes with a common header: Vasseur, et al. Expires June 5, 2011 [Page 7] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Routing Metric/Constraint object generic format The object body carries one or more sub-objects defined later in this document. Note that an object may carry TLV, which may itself comprise other TLVs. A TLV carried within a TLV is called a TLV in this specification. Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing Metric/Constraint Type field uniquely identifies each Routing Metric/Constraint object and is managed by IANA. Length: this field defines the length of the object body, in bytes. Flag field of the Routing Metric/Constraint object: o P flag: the P field is only used for recorded metrics. When cleared, all nodes along the path successfully recorded the corresponding metric. When set, this indicates than one or several nodes along the path could not record the metric of interest (either because of lack of knowledge or because this was prevented by policy). o C Flag. When set, this indicates that the Routing Metric/ Constraint object refers to a routing constraint. When cleared, the routing object refers to a routing metric. o O Flag: The O flag is used exclusively for routing constraints (C flag is set). When set, this indicates that the constraint specified in the body of the object is optional. When cleared, the constraint is mandatory. If the C flag is zero, the O flag MUST be set to zero on transmission and ignored on reception. o R Flag: The R Flag is only relevant for routing metric (C=3D0) and MUST be cleared for C=3D1. When set, this indicates that the routing metric is recorded along the path. Conversely, when cleared, the routing metric is aggregated. The Flag field of the Routing Metric/Constraint object is managed by Vasseur, et al. Expires June 5, 2011 [Page 8] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. A Field: The A field is only relevant for metrics and is used to indicate whether the aggregated routing metric is additive, multiplicative, reports a maximum or a minimum. o A=3D0x00: The routing metric is additive o A=3D0x01: The routing metric reports a maximum o A=3D0x02: The routing metric reports a minimum o A=3D0x03: The routing metric is multiplicative The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and he only valid when the R bit is cleared. Otherwise, the A field MUST be set to 0x00 and MUST be ignored on receipt. Prec field: The Prec field indicates the precedence of this Routing Metric/Constraint object relative to other objects in the container. This is useful when a DAG Metric Container contains several Routing Metric objects. The value 0 means the highest precedence. Example 1: A DAG formed by RPL where all nodes must be mains-powered and the best path is the one with lower aggregated ETX. In this case the DAG Metric container carries two Routing Metric/Constraint objects: one is an ETX metric object with header (C=3D0, O=3D0, A=3D00,= R=3D0) and the second one is a Node Energy constraint object with header (C=3D1, O=3D0, A=3D00, R=3D0). Note that a RPL instance may = use the metric object to report a maximum (A=3D0x01) or a minimum (A=3D0x02). If, for example, the best path is characterized by the path avoiding low quality links, then the path metric reports a maximum (A=3D0x01) (the higher is the ETX the lower link quality is): when the DIO message reporting link quality metric (ETX) is processed by a node, each node selecting the advertising node as a parent updates the value carried in the metric object by replacing it with its local link ETX value if and only if the latter is higher. As far as the constraint is concerned, if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message. Example 2: A DAG formed by RPL where the link metric is the link quality level (defined in Section 4) and link quality levels must be recorded along the path. In this case, the DAG Metric Container carries a Routing Metric/Constraint object: link quality level metric (C=3D0, O=3D0, A=3D00, R=3D1) containing multiple sub-objects. Vasseur, et al. Expires June 5, 2011 [Page 9] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 A Routing Metric/Constraint object may also include one or more additional type-length-value (TLV) encoded data sets. Each Routing Metric/Constraint TLV has the same structure: Type: 1 byte Length: 1 byte Value: variable A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 1 byte specifying the TLV length, and a value field. The TLV length field defines the length of the value field in bytes. Unrecognized TLVs MUST be silently ignored while still being propagated in DIO generated by receiving node. IANA manages the codepoints for all TLV carried in routing constraint/metric objects. IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 6. 2.2. Use of Multiple DAG Metric Containers Since the length of RPL options is encoded using 1 octet, they cannot exceed 255 bytes, which also applies to the DAG Metric Container. In the vast majority of cases, the advertised routing metrics and constraints will not require that much space. However, there might be circumstances where larger space is required, should for example a set of routing metrics be recorded along a long path. In this case, in order to avoid overflow, as specified in [I-D.ietf-roll-rpl], routing metrics will be carried using multiple DAG Metric Containers objects. In the rest of this document, this use of multiple DAG Metric Containers objects will be considered as if they were actually just one long DAG Metric Container object. 2.3. Metric Usage When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitly derived from the metric type. For example, lower is better for Hop Count, Link Latency and ETX. Conversely, for Node Energy or Throughput, higher is better. An example of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E-E field) defined in Section 3.2 is aggregated along paths with an explicit min Vasseur, et al. Expires June 5, 2011 [Page 10] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 function (A field), and the best path is selected through an implied Max function because the metric is Energy. When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-breakers according to their precedence defined by their Prec field values. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criterion, LQL as the secondary criterion and Node Energy as the ultimate tie-breaker. In such a case, the Hop-Count, LQL and Node Energy metric objects' Prec fields should bear strictly increasing values such as 0, 1 and 2, respectively. If several aggregated metrics happen to bear the same Prec value, the behavior is implementation-dependant. 3. Node Metric/Constraint Objects The sections 3. and 4. specify several link and node metric/ constraint objects. In some cases it is stated that there must not be more than one object of a specific type. In that case, if an RPL implementation receives more than one objet of that type, the second objet MUST silently be ignored. 3.1. Node State and Attributes Object The Node State and Attribute (NSA) object is used to provide information on node characteristics. The NSA object MAY be present in the DAG Metric Container. There MUST NOT be more than one NSA object as a constraint per DAG Metric Container, and there MUST NOT be more than one NSA object as a metric per DAG Metric Container. The NSA object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The NSA Routing Metric/Constraint Type is to be assigned by IANA (recommended value=3D1). Vasseur, et al. Expires June 5, 2011 [Page 11] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The format of the NSA object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags |A|O| Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 3: NSA object body format Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt. The following two bits of the NSA object are currently defined: o A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data. This is listed as a requirement in Section 6.2 of [RFC5548]. Some applications may make use of the aggregation node attribute in their routing decision so as to minimize the amount of traffic on the network, thus potentially increasing its lifetime in battery operated environments. Applications where highly directional data flow is expected on a regular basis may take advantage of data aggregation supported routing. When set, this indicates that the node can act as a traffic aggregator. An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality. o O Flag: node workload may be hard to determine and express in some scalar form. However, node workload could be a useful metric to consider during path calculation, in particular when queuing delays must be minimized for highly sensitive traffic considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory or any other node related conditions. Using a simple 1-bit flag to characterize the node workload provides a sufficient level of granularity, similarly to the "overload" bit used in routing protocols such as IS-IS. Algorithms used to set the overload bit and to compute paths to potentially avoid nodes with their overload bit set are outside the scope of this document, but it is RECOMMENDED to avoid frequent changes of this bit to avoid routing oscillations. When set, this indicates that the node is overloaded and may not be able to process traffic. They MUST be set to zero on transmission and MUST be ignored on receipt. Vasseur, et al. Expires June 5, 2011 [Page 12] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The Flag field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved. 3.2. Node Energy Object It may sometimes be desirable to avoid selecting a node with low residual energy as a router, thus the support for constraint-based routing is needed. In such cases, the routing protocol engine may compute a longer path (constraint based) for some traffic in order to increase the network life duration. Power and energy are clearly critical resources in most LLNs. As yet there is no simple abstraction which adequately covers the broad range of power sources and energy storage devices used in existing LLN nodes. These include mains-powered, primary batteries, energy scavengers, and a variety of secondary storage mechanisms. Scavengers may provide a reliable low level of power, such as might be available from a 4-20mA loop; a reliable but periodic stream of power, such as provided by a well-positioned solar cell; or unpredictable power, such as might be provided by a vibrational energy scavenger on an intermittently powered pump. Routes which are viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a network. Storage systems like rechargeable batteries often suffer substantial degradation if regularly used to full discharge, leading to different residual energy numbers for regular versus emergency operation. A route for emergency traffic may have a different optimum than one for regular reporting. Batteries used in LLNs often degrade substantially if their average current consumption exceeds a small fraction of the peak current that they can deliver. It is not uncommon for self-supporting nodes to have a combination of primary storage, energy scavenging, and secondary storage, leading to three different values for acceptable average current depending on the time frame being considered, e.g. milliseconds, seconds, and hours/years. Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets, and lifetime estimates have no value without some higher-level constraint on the lifetime required of a device. In some cases the path that exhausts the battery of a node on the bed table in a month may be preferable to a route that reduces the lifetime of a node in the wall to a decade. Given the complexity of trying to address such a broad collection of constraints, this document defines two levels of fidelity in the Vasseur, et al. Expires June 5, 2011 [Page 13] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 solution. The simplest solution relies on a 2-bit field encoding three types of power sources: "powered", "battery", "scavenger". This simple approach may be sufficient for many applications. The mid-complexity solution is a single parameter that can be used to encode the energetic happiness of both battery powered and scavenging nodes. For scavenging nodes, the 8 bit quantity is the power provided by the scavenger divided by the power consumed by the application, E-E=3DP_in/P_out, in units of percent. Nodes which are scavenging more power than they are consuming will register above 100. A good time period for averaging power in this calculation may be related to the discharge time of the energy storage device on the node, but specifying this is out of the scope of this document. For battery powered devices, E-E is the current expected lifetime divided by the desired minimum lifetime, in units of percent. The estimation of remaining battery energy and actual power consumption can be difficult, and the specifics of this calculation are out of scope of this document, but two examples are presented. If the node can measure its average power consumption, then H can be calculated as the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power, E-E=3DP_max/P_now. Alternatively, if = the energy in the battery E_bat can be estimated, and the total elapsed lifetime, t, is available, then H can be calculated as the total stored energy remaining versus the target energy remaining: E-E=3D E_bat / [E_0 (T-t)/T]. An example of optimized route is max(min(H)) for all battery operated nodes along the route, subject to the constraint that E-E>=3D100 for all scavengers along the route. 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. The Node Energy (NE) object is used to provide information related to node energy and may be used as a metric or as constraint. The NE object MAY be present in the DAG Metric Container. There MUST NOT be more than one NE object as a constraint per DAG Metric Container, and there MUST NOT be more than one NE object as a metric Vasseur, et al. Expires June 5, 2011 [Page 14] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 per DAG Metric Container. The NE object Type is to be assigned by IANA (recommended value=3D2). The format of the NE object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | NE Sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 4: NE sub-object format The format of the NE sub-object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Flags |I| T |E| E-E | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 5: NE sub-object format The NE sub-object may also contain a set of TLVs used to convey various nodes' characteristics. The following flags are currently defined: o I (Included): the I bit is only relevant when the node type is used as a constraint. For example, the path must only traverse mains-powered nodes. Conversely, battery operated nodes must be excluded. The I bit is used to stipulate inclusion versus exclusion. When set, this indicates that nodes of the type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded. o T (node Type): 2-bit field indicating the node type. T=3D0x00 designates a mains-powered node, T=3D0x01 a battery-powered node = and T=3D0x02 a node powered by an energy scavenger. o E (Estimation): when the E bit is set for a metric, the estimated percentage of remaining energy on the node is indicated in the E-E 8-bit field. When cleared, the estimated percentage of remaining energy is not provided. When the E bit is set for a constraint, the E-E field defines a threshold for the inclusion/exclusion: if an inclusion, nodes with values higher than the threshold are to Vasseur, et al. Expires June 5, 2011 [Page 15] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 be included; if an exclusion, nodes with values lower than the threshold are to be excluded. E-E (Estimated-Energy): 8-bit unsigned integer field indicating an estimated percentage of remaining energy. The E-E field is only relevant when the E flag is set, and MUST be set to 0 when the E flag is cleared. If the NE object comprises several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty if that I bit is an inclusion. No TLV is currently defined. Future documents may define more complex solutions involving TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. 3.3. Hop-Count Object The HoP-Count (HP) object is used to report the number of traversed nodes along the path. The HP object MAY be present in the DAG Metric Container. There MUST NOT be more than one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container. The HP object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The HP routing metric object Type is to be assigned by IANA (recommended value=3D3) The format of the Hop Count object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags | Hop Count | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 6: Hop Count object body format Res flags (4 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt. Vasseur, et al. Expires June 5, 2011 [Page 16] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 No Flag is currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field. Note that the first node along a path inserting a Hop-count object MUST set the Hop Count field value to 1. 4. Link Metric/Constraint Objects 4.1. Throughput Many LLNs support a wide range of throughputs. For some links, this may be due to variable coding. For the deeply duty-cycled links found in many LLNs, the variability comes as a result of trading power consumption for bit rate. There are several MAC layer protocols which allow for the effective bit rate of a link to vary over more than three orders of magnitude with a corresponding change in power consumption. For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput. The Throughput object MAY be present in the DAG Metric Container. There MUST NOT be more than one Throughput object as a constraint per DAG Metric Container, and there MUST NOT be more than one Throughput object as a metric per DAG Metric Container. The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub- object MUST be the most recently estimated actual throughput. The actual estimation of the throughput is outside the scope of this document. Each Throughput sub-object has a fixed length of 4 bytes. The Throughput object does not contain any additional TLV. The Throughput object Type is to be assigned by IANA (recommended value=3D4) Vasseur, et al. Expires June 5, 2011 [Page 17] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The format of the Throughput object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Throughput object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Throughput sub-object format Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second. 4.2. Latency Similarly to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in power consumption. Some LLN MAC link layers will allow the latency to be adjusted globally on the subnet, on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. The Latency object MAY be present in the DAG Metric Container. There MUST NOT be more than one Latency object as a constraint per DAG Metric Container, and there MUST NOT be more than one Latency object as a metric per DAG Metric Container. The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes. The Latency object does not contain any additional TLV. The Latency object Type is to be assigned by IANA (recommended value=3D5) The Latency object is a metric or constraint. Vasseur, et al. Expires June 5, 2011 [Page 18] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The format of the Latency object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Latency object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Latency sub-object format Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds. The Latency object may be used as a constraint or a path metric. For example, one may want the latency not to exceed some value. In this case, the Latency object common header indicates that the provided value relates to a constraint. In another example, the Latency object may be used as an aggregated additive metric where the value is updated along the path to reflect the path latency. 4.3. Link Reliability In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes unidirectional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rates can generally be measured directly, and other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. Note that such variability is not specific to wireless link but also applies to PLC links. A change in link quality can affect network connectivity, thus, link quality may be taken into account as a critical routing metric. A number of link reliability metrics could be defined reflecting several reliability aspects. Two link reliability metrics are defined in this document: the Link Quality Level (LQL) and the Expected Transmission count Metric (ETX). Vasseur, et al. Expires June 5, 2011 [Page 19] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 Note that an RPL implementation MAY either use the LQL, the ETX or both. 4.3.1. The Link Quality Level Reliability Metric The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document. The LQL can either be used as a metric or a constraint. When used as a metric, the LQL metric can be recorded or aggregated. For example, the DAG Metric object may request all traversed nodes to record the LQL of their incoming link into the LQL object. Each node can then use the LQL record to select its parent based on some user defined rules (e.g. something like "select the path with most links reporting a LQL value of 3 or less"). By contrast, the LQL link metric may be aggregated, in which case the sum of all LQLs may be reported (additive metric) or the minimum value may be reported along the path. When used as a recorded metric, counters are used to compress the information: for each encountered LQL value, only the number of matching links is reported. The LQL object MAY be present in the DAG Metric Container. There MUST NOT be more than one LQL object as a constraint per DAG Metric Container, and there MUST NOT be more than one LQL object as a metric per DAG Metric Container. The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL. The LQL object Type is to be assigned by IANA (recommended value=3D6) The format of the LQL object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LQL sub-object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 12: LQL object body format Res flags (8 bits): Reserved field. This field MUST be set to zero Vasseur, et al. Expires June 5, 2011 [Page 20] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 on transmission and MUST be ignored on receipt. When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object. The format of the LQL Type 1 sub-object is as follows 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Val | Counter | +-+-+-+-+-+-+-+-+ Figure 13: LQL Type 1 sub-object format Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality. Counter: number of links with that value. When the LQL metric is aggregated, the LQL object body comprises one LQL Type 2 sub-object: The format of the LQL Type 2 sub-object is as follows 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregated LQL Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: LQL Type 2 sub-object format Aggregated LQL Value: when used as an additive metric (A=3D0x00), the aggregated LQL value reports the sum of all the LQL values for all links along the path. When used to report a minimum (A=3D0x02), the field reports the minimum LQL value of all links along the path, ignoring undetermined LQLs (Aggregated LQL Value =3D 0). When used = to report a maximum (A=3D0x01), the field reports the maximum LQL value = of all links along the path. When used to report a multiplication (A=3D0x03), and the LQL field of one of the links along the path is undetermined (LQL=3D0), the undetermined LQL will be ignored and not = be aggregated (i.e. no reset to Aggregated LQL Value field). 4.3.2. The Expected Transmission Count (ETX) reliability object The Expected Transmission Count (ETX) metric is the number of transmissions a node expects to make to a destination in order to Vasseur, et al. Expires June 5, 2011 [Page 21] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 successfully deliver a packet. In contrast with the LQL routing metric, the ETX provides a discrete value (wich may not be an integer) computed according to a specific formula: for example, an implementation may use the following formula: ETX=3D 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value. The ETX object MAY be present in the DAG Metric Container. There MUST NOT be more than one ETX object as a constraint per DAG Metric Container, and there MUST NOT be more than one ETX object as a metric per DAG Metric Container. The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 8 bits. The ETX object does not contain any additional TLV. The ETX object Type is to be assigned by IANA (recommended value=3D7) The format of the ETX object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: ETX object body format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: ETX sub-object format ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX =3D 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum which is 65535. The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some Vasseur, et al. Expires June 5, 2011 [Page 22] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 specified value. In this case, the ETX object common header indicates that the value relates to a constraint. In another example, the ETX object may be used as an aggregated additive metric where the value is updated along the path to reflect the path quality: when a node receives the aggregated additive ETX value of the path (cummulative path ETX calculated as the sum of the link ETX of all of the traversed links from the advertising node to the DAG root), if it selects that node as its preferred parent, the node updates the path ETX by adding the ETX of the local link between itself and the preferred parent to the received path cost (path ETX) before potentially advertising itself the new path ETX. 4.4. Link Color Object 4.4.1. Link Color Object Description The Link Color (LC) object is an administrative 10-bit link constraint (which may either be static or dynamically adjusted) used to avoid or attract specific links for specific traffic types. The LC object can either be used as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. A color is defined as a specific set of bit values: in other words, that 10-bit field is a flag field, and not a scalar value. Each node can then use the LC to select the parent based on user defined rules (e.g. "select the path with the maximum number of links having their first bit set 1 (e.g. encrypted links)"). The LC object may also be used as a constraint. When used as a recorded metric, a counter is used to compress the information where the number of links for each Link Color is reported. The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST NOT be more than one LC object as a constraint per DAG Metric Container, and there MUST NOT be more than one LC object as a metric per DAG Metric Container. There MUST be a at least one LC sub-object per LC object. The LC object does not contain any additional TLV. The LC object Type is to be assigned by IANA (recommended value=3D8) Vasseur, et al. Expires June 5, 2011 [Page 23] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The format of the LC object body is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LC sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 17: LC object format Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt. When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects. The format of the LC Type 1 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: LC Type 1 sub-object format When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects. The format of the LC Type 2 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color |Reserved |I| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: LC Type 2 sub-object format Res flags (7 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt. I Bit: The I bit is only relevant when the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded. It is left to the implementer to define the meaning of each bit of Vasseur, et al. Expires June 5, 2011 [Page 24] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 the 10-bit Link Color Flag field. 4.4.2. Mode of operation The link color may be used as a constraint or a metric. o When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path. o When used as recorded metric, each node along the path may insert a LC object in the DAG Metric Container to report the color of the local link. If there is already a LC object reporting a similar color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field. 5. Computation of Dynamic Metrics and Attributes As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, thus implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales. RPL controls the reporting rate. To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics are out the scope of this document, it is RECOMMENDED to carefully design the route optimization algorithm to avoid too frequent computation of new routes upon metric values changes. Controlled adaptation of the routing metrics and rate at which paths are computed are critical to avoid undesirable routing instabilities resulting in increased latencies and packet loss because of temporary micro-loops. Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus potentially impacting its scalability. 6. IANA Considerations IANA is requested to establish a new top-level registry to contain all Routing Metric/Constraint objects codepoints and sub-registries. Vasseur, et al. Expires June 5, 2011 [Page 25] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 The allocation policy for each new registry is by IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). 6.1. Routing Metric/Constraint Type IANA is requested to create a registry for Routing Metric/Constraint objects. Each Routing Metric/Constraint object has a type value. Value Meaning Reference 1 Node State and Attribute This document 2 Node Energy This document 3 Hop Count This document 4 Link Throughput This document 5 Link Latency This document 6 Link Quality Level This document 7 Link ETX This document 8 Link Color This document 6.2. Routing Metric/Constraint TLV IANA is requested to create a registry used for all TLVs carried within Routing Metric/Constraint objects. 6.3. Routing Metric/Constraint Common Header IANA is requested to create a registry to manage the codespace of the A field of the Routing Metric/Constraint common header. Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference 0 Routing metric is additive This document 1 Routing metric reports a maximum This document 2 Routing metric reports a minimum This document 3 Routing metric is multiplicative This document IANA is requested to create a registry to manage the Flag field of the Routing Metric/Constraint common header. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number Vasseur, et al. Expires June 5, 2011 [Page 26] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 o Capability Description o Defining RFC Several bits are defined for the Routing Metric/Constraint common header in this document. The following values have been assigned: Codespace of the Flag field (Routing Metric/Constraint common header) Bit Description Reference 12-15 Precedence This document 9-11 Additive/Max/Min/Multi This document 8 Recorded/Aggregated This document 7 Optional Constraint This document 6 Constraint/Metric This document 5 P (Partial) This document 6.4. NSA Object IANA is requested to create a registry to manage the codespace of the Flag field of the NSA object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC Several bits are defined for the NSA object flag field in this document. The following values have been assigned: Codespace of the Flag field (NSA object) Bit Description Reference 14 Aggregator This document 15 Overloaded This document 6.5. Hop-Count Object IANA is requested to create a registry to manage the codespace of the Flag field of the Hop-count object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: Vasseur, et al. Expires June 5, 2011 [Page 27] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 o Bit number o Capability Description o Defining RFC No Flag is currently defined. 7. Security Considerations Routing metrics should be handled in a secure and trustful manner. For instance, RPL should not allow a malicious node to falsely advertise that it has good metrics for routing, be added as a router for other nodes' traffic and intercept packets. Another attack may consist of making intermitment attacks on a link in an attempt to constantly modify the link quality and consequently the associated routing metric, thus leading to potential fluctuation in the DAG. It is thus RECOMMENDED for a RPL implementation to put in place mechanism so as to stop advertising routing metrics for highly unstable links that may be subject to attacks. Since the routing metrics/constraints are carried within RPL message, the security routing mechanisms defined in [I-D.ietf-roll-rpl] applies here. 8. Acknowledgements The authors would like to acknowledge the contributions of Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal and David Culler for their review and valuable comments. Special thank to Adrian Farrel for his thourough review. 9. References 9.1. Normative references [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-15 (work in Vasseur, et al. Expires June 5, 2011 [Page 28] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 progress), November 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative references [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. [Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of=20 the Revised Routing Metric for ARPANET and MILNET.=20 Submitted to MILCOM 89, March 1989 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [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. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. Vasseur, et al. Expires June 5, 2011 [Page 29] =0C Internet-Draft draft-ietf-roll-routing-metrics-13 December 2010 Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 Korea Email: mjkim@kt.com Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA Email: kpister@dustnetworks.com Nicolas Dejean Coronis SAS Espace Concorde, 120 impasse JB Say Perols, 34470 France Email: nicolas.dejean@coronis.com Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan, 38243 France Email: dominique.barthel@orange-ftgroup.com Vasseur, et al. Expires June 5, 2011 [Page 30] =0C --Apple-Mail-166--131453421 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Cheers.

JP.


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

--Apple-Mail-166--131453421-- --Apple-Mail-165--131453421-- From Internet-Drafts@ietf.org Tue Dec 7 00:00:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BD03A6932; Tue, 7 Dec 2010 00:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 BwTZh8o2vSTR; Tue, 7 Dec 2010 00:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198183A68F5; Tue, 7 Dec 2010 00:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101207080002.18339.29466.idtracker@localhost> Date: Tue, 07 Dec 2010 00:00:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-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: Tue, 07 Dec 2010 08:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-13.txt Pages : 30 Date : 2010-12-06 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-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-routing-metrics-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-06234831.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Dec 7 09:00:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A190D3A6813; Tue, 7 Dec 2010 09:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 p83rZ9cuS351; Tue, 7 Dec 2010 09:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49EB3A6823; Tue, 7 Dec 2010 09:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101207170001.14637.18348.idtracker@localhost> Date: Tue, 07 Dec 2010 09:00:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-06.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, 07 Dec 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-06.txt Pages : 13 Date : 2010-12-06 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-trickle-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-07085119.I-D@ietf.org> --NextPart-- From culler@cs.berkeley.edu Tue Dec 7 10:21: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 EB09F3A6874 for ; Tue, 7 Dec 2010 10:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlXt9eztFSDG for ; Tue, 7 Dec 2010 10:21:28 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0BB2D3A6863 for ; Tue, 7 Dec 2010 10:21:28 -0800 (PST) Received: from [10.0.7.161] (nocatgw.cs.washington.edu [128.208.7.11]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id oB7IMIYu004163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Dec 2010 10:22:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-24--93674245 From: David Culler In-Reply-To: Date: Tue, 7 Dec 2010 10:22:18 -0800 Message-Id: <52EC1B39-677E-49A4-98AB-C69895EBE993@cs.berkeley.edu> References: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> To: JP Vasseur X-Mailer: Apple Mail (2.1082) Cc: roll@ietf.org, draft-ietf-roll-routing-metric@tools.ietf.org, Adrian.Farrel@huawei.com Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2010 18:21:31 -0000 --Apple-Mail-24--93674245 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adrian, Thanks very much for your efforts here. It looks like the responses = address the specific issues, but I'd like to know if you feel that they = address the larger issue of unnecessary complexity. This has been a = pervasive concern with this particular piece of work. We have managed = to contain it a good bit and we have eliminated the fluff of earlier = versions. D. On Dec 6, 2010, at 11:52 PM, JP Vasseur wrote: > Hi Adrian, >=20 > On Nov 26, 2010, at 9:29 AM, Adrian Farrel wrote: >=20 >> Hi, >>=20 >> I have performed an AD review of your draft. >>=20 >=20 > Thanks ! >=20 >> Don't panic! >>=20 >=20 > Ah ok ;-) >=20 >> 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. >>=20 >> Thanks for an important component of the RPL family. >>=20 >> Most of my comments are pretty trivial, but a couple have more meat >> on them and 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. >>=20 >=20 > Perfect - see below (skipping all issues that have been addressed in = the new revision) >=20 >> Of course, all of my issues are up for discussion. >>=20 >> Thanks for the work, >> Adrian >>=20 >> --- >>=20 >> I am slightly worried about the complexity inherent in this spec. >> Although individual implementations and deployments might choose to = use >> a very limited subset of the available (and flexible) options, it = seems >> that an implementation must support a much wider subset of options, >> metrics, and constraints in order to be deployable into a wide range = of >> networks. >>=20 >> Does this flexibility impact simplicity of implementation? >>=20 >=20 > JP> We do do not think so. Actually in most cases, implementations = will implementation > a very small subset of the metrics/constraints. We have a number of = choices and options > here, to address the requirements spelled out in the requirement RFCs = but again it is neither > expected NOR required for an implementation to implement them all but = certainly each of=20 > the metric/constraint/feature is justified by a specific = requirement.That being said, I have=20 > been told that some implementations did implement them all. >=20 >> Section 1 >>=20 >> It must be noted that the use of dynamic metrics is not new and has >> been experimented in ARPANET 2. The use of dynamic metrics is not >> trivial and great care must be given to the use of dynamic metrics >> since it may lead to potential routing instabilities. That being >> said, lots of experience has been gained over the years on the use = of >> dynamic routing metrics, which have been deployed in a number of = (non >> IP) networks. >>=20 >> Can you add a couple of references? One for ARPANET 2 = experimentation, >=20 > Added: >=20 > [Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of=20 > the Revised Routing Metric for ARPANET and MILNET.=20 > Submitted to MILCOM 89, March 1989 >=20 >=20 >> and one for the "lots of experience gained". >>=20 >=20 > A bit more difficult ... people skills in the art would know but ... = most are deployed proprietary > systems ... >=20 >> --- >>=20 >> Use of RFC 2119 language. >>=20 >> The first use (SHOULD) shows up late in Section 1 after a number of >> lower case "must". I think that the best way to smooth this out is to >> not use any 2119 language in the Introduction. >>=20 >=20 > Indeed, good catch, thanks. >=20 >> Figure 1 >>=20 >> This is a copy of figure 22 in draft-ietf-roll-rpl. >> I strongly recommend that you do not duplicate protocol bit/byte >> definitions as this can lead to accidental discrepancies. Why not >> replace this figure with a reference? >>=20 >> --- >>=20 >> Bit numberings in fields. Please align the numbers so that we >> count bits in base 10. >>=20 >=20 > JP> IF ok with you, I'd rather leave it here, since the RPL document = is fairly > large, this is to avoid too much work jumping between the two = documents. >=20 >> Section 2.1 >>=20 >> I think the A flag needs a little more constraint. Not only is it = only >> valid when C=3D1 (as stated), but it is only valid when R=3D0. >>=20 >> Also >> OLD >> and MUST be written to 0x00. >> NEW >> and MUST be set to 0x00 and MUST be ignored on receipt. >> END >>=20 >=20 > JP> Yes, thanks. >=20 >> --- >>=20 >> Section 2.1 >>=20 >> Unrecognized TLVs MUST be ignored. >>=20 >> Do you want to clarify that "ignoring" includes leaving the TLVs in >> place in the object when it is forwarded along the DAG? >>=20 >=20 > JP> Clarified. >=20 >> --- >>=20 >> Section 2.2 >>=20 >> Have you considered the case that the recording of metrics causes the >> Routing Metric/Constraint object to overflow? >>=20 >=20 > JP> Yes, this is clarified in the RPL spec, allowing for multiple DAG = Metric container. > Still I added few words. >=20 >> -- >>=20 >> Section 3.1 >>=20 >> The NSA object MAY be present in the DAG Metric Container. There >> MUST be no more than one NSA object as a constraint per DAG Metric >> Container, and no more than one NSA object as a metric per DAG = Metric >> Container. >>=20 >> This is fine, but you will need to define somewhere what happens when >> a formatting error is detected. This can either be done on a case-by- >> case basis, or can be a general statement in Section 3. >=20 > JP> I added some text, thanks (Section 3): "The sections 3. and 4. = specify several=20 > link and node metric/constraint objects. In some cases it is stated = that there must not=20 > be more than one object of a specific type. In that case, if an RPL = implementation=20 > receives more than one objet of that type, the second objet MUST = silently be ignored. " >=20 >>=20 >> See also, Section 3.2 >>=20 >> The NE object MAY be present in the DAG Metric Container. There = MUST >> be no more than one NE object as a constraint per DAG Metric >> Container, and no more than one NE object as a metric per DAG = Metric >> Container. >>=20 >> etc., etc. >>=20 >> Incidentally, it might be more graceful to use "MUST NOT" instead of >> "MUST". For example: >>=20 >> OLD >> The HP object MAY be present in the DAG Metric Container. There = MUST >> be no more than one HP object as a constraint per DAG Metric >> Container, and no more than one HP object as a metric per DAG = Metric >> Container. >> NEW >> The HP object MAY be present in the DAG Metric Container. There = MUST >> NOT be more one HP object as a constraint per DAG Metric Container, >> and there MUST NOT be more than one HP object as a metric per DAG >> Metric Container. >> END >=20 > All fixed. >=20 >>=20 >> Section 3.1 >>=20 >> Is IANA expected to track the flags in the NSA object? >=20 > Yes this is in Section 6.3. >=20 >>=20 >> Are the Type values for the TLVs chosen from a common registry across >> all objects, or is there a separate registry for each object? >>=20 >=20 > Good catch ! Section added in IANA for a *common* registry for all = TLVs. >=20 >> --- >>=20 >> Section 3.2 >>=20 >> Whenever possible, a node with low residual energy should not be >> selected as a router >>=20 >> Do you have a reference for this? >=20 > JP> I reworded the text, since such decision will either be OF = specific or driven by local policy. Thanks. >=20 >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> Given the complexity of trying to address such a broad collection = of >> constraints, this document defines three levels of fidelity in the >> solution. >>=20 >> I only find two levels defined in the section: >> - The simplest solution relies on a 2-bit field >> - The mid-complexity solution is a single parameter >>=20 >> Did I miss one, or did you? >=20 > We used to work on 3, and lead to two ... Forgot to update the text, = done, thanks. >=20 >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> For scavenging nodes, the 8 bit quantity is the power >> provided by the scavenger divided by the power consumed by the >> application, H=3DP_in/P_out, in units of percent. >>=20 >> and >>=20 >> For >> battery powered devices, H is the current expected lifetime divided >> by the desired minimum lifetime. >>=20 >> Is the second case also expressed as a percentage? >=20 > Yes (added), thanks. >=20 >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> I'm slightly confused by the difference (or not) between the term 'H' >> and the term 'E-E'. Firstly, E-E looks like an arithmetic expression. >> But, more to the point, I *think* you put the value of H in the field >> E-E, so why have two names for the same thing? >>=20 >=20 > JP> Indeed, using one term: E-E >=20 >> --- >>=20 >> Objects, sub-objects, and TLVs >>=20 >> I think you have some inconsistency in naming. >>=20 >> At the top level we have "Routing Metric/Constraint object" >> The "object body" of this object is defined as: >> The object body carries one or more sub-objects defined later in = this >> document. >> So I expect everything that follows in Sections 3 and 4 to be termed >> sub-objects. >=20 > Not always, for example, when there is one header followed by the main = body,=20 > it is called an object. When there might be more than one (for example = when=20 > recording several link ETX, we may have multiple sub-objects after the = header). >=20 >> But you have also termed these things as "objects". >>=20 >> Some of the objects/sub-objects in Sections 3 and 4 can, themselves = have >> sub-objects, while others launch straight into contained TLVs. >>=20 >> This is all a bit confusing (although there is nothing technically >> wrong) and it would be really nice to achieve some consistency of >> terminology. >>=20 >> --- >>=20 >> Section 3.2 >>=20 >> The format of the NE sub-object body is as follows: >>=20 >> And what Type value does this sub-object use? >>=20 >=20 > The NE object Type is to be assigned by IANA (recommended value=3D2) >=20 >> --- >>=20 >> Section 3.2 >>=20 >> o T (node Type): 2-bit field indicating the node type. E=3D0x00 >> designates a mains-powered node, E=3D0x01 a battery-powered node = and >> E=3D0x02 a node powered by an energy scavenger. >>=20 >> Do you mean T=3D0x00 etc.? >>=20 >=20 > JP> indeed ! Thanks. >=20 >> -- >>=20 >> =20 >> --- >>=20 >> Section 3.3 >>=20 >> The HP object may be used as a constraint or a metric. When used = as >> a constraint, the DAG root indicates the maximum number of hops = that >> a path may traverse. When that number is reached, no other node = can >> join that path. When used as a metric, each visited node simply >> increments the Hop Count field. >>=20 >> Are you counting nodes or hops? >> Does the first node send the Hop Count as one or zero? >>=20 >=20 > Text added to include the first node. >=20 >> --- >>=20 >> Section 3.3 >>=20 >> It looks to me that if the object is used as a constraint, it MUST = also >> be present as a metric. This seems to be different from the burble at >> the top of the section. (and obviously, we can think of more optimal >> ways of signaling this - such as decrementing the hop count at each >> hop). >=20 > JP> Not sure why ... you could use it as a constraint (say to avoid = too much > of delays if you know that the number of traversed hop may be an = issue) and > still want to optimize against another metric such as the bandwidth ? >=20 >>=20 >> --- >>=20 >> Section 4.1 >>=20 >> For the deeply duty-cycled links >> found in many LLNs >>=20 >> Will this term be clear to the reader? >>=20 >=20 > JP> Yes I do think so.=20 >=20 >> --- >>=20 >> Section 4.1 >>=20 >> With special reference to my comment (above) about objects, = sub-objects, >> and TLVs, it is really not helpful to have an object (which is = actually >> a sub-object) and a sub-object of that object both called Throughput! >>=20 >> --- >>=20 >> Section 4.1 >>=20 >> Figure 9: Throughput sub-object format >>=20 >> And what Type value does this sub-object use? >> But, I might ask why you need sub-objects when the content is = well-known >> to be 32-bit values, and the parent object has a length field. >>=20 >> --- >>=20 >> Section 4.1 >>=20 >> Throughput: 32 bits. The Throughput is encoded in 32 bits in >> unsigned integer format, expressed in bytes per second. >>=20 >> Are you sure this is enough? Yes, it seems like it today. How future- >> proof is this? >=20 > JP> 2^32 is huge ? >=20 >>=20 >> --- >> Section 4.2 >>=20 >> Ditto object and sub-object names. >> Ditto sub-object Type value. >>=20 >=20 > JP> XXXX >=20 >> --- >>=20 >> Section 4.2 >>=20 >> Again, it looks like the use of this object as a constraint is only >> possible if it is also used as a metric. >=20 > JP> Same comment as for the hop-count. It does not have to be used as = a metric > when also used as a constraint. >=20 >> So (again) it looks like the >> rules for object presence are broken. >>=20 >> But that depends how it is used as a constraint! It might be used to >> mean that no link with unsatisfactory latency may be added to the = DAG, >> or it might mean that the cumulative latency must not grow beyond the >> the constrained limit. >>=20 >> You need to clarify meaning and usage. >>=20 >> --- >>=20 >> Section 4.3 >>=20 >> Note that an RPL implementation MAY either use the LQL, the ETX or >> both. >>=20 >> This immediately makes me worry about interoperability. >=20 > JP> But we have different object ... the reason being that depending = on the deployment, > we may either use the LQL or the ETX .... >=20 >>=20 >> --- >>=20 >> Section 4.3.1 >>=20 >> By contrast, the LQL link metric may be >> aggregated, in which case the sum of all LQLs may be reported >> (additive metric) >>=20 >> How can this possibly be useful? Unless you know how many hops are >> traversed, the aggregate is meaningless! >>=20 >=20 > JP> This is correct. That being said, we wanted to leave it there, = since > it could be useful in some specific scenario (for example, you may use > two values, 0 (good) 1 (bad), in which cases it provides you the = number > of bad links traversed, a metric that you could use to select your = path). >=20 >> --- >>=20 >> Section 4.3.1 >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >> | Res | LQL sub-object >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >>=20 >> The Res field does not appear to be described. >>=20 >=20 > JP> Added (elsewhere too). >=20 >> --- >>=20 >> Section 4.3.1 >>=20 >> It seems to me that a type 0x02 aggregation is not very helpful = because >> "unknown" will hide the otherwise 'best' link quality. >>=20 >> But maybe this doesn't matter because 'worst' link quality is more >> interesting. >=20 > JP> Correct this is one of the cases where this is useful indeed. >=20 >>=20 >> --- >>=20 >> Section 4.4.1 >>=20 >> Ditto Res field >>=20 >=20 > JP> Added. >=20 >> --- >>=20 >> Section 4.4.1 >>=20 >> How come the LC field in the two sub-objects have different sizes? >>=20 >=20 > JP> Oops ! Fixed. Thanks. >=20 >> --- >>=20 >> Section 4.4.1 >>=20 >> The use of the LC object is outside the scope of this document. >>=20 >> It seems to me you have gone off half cocked :-( >>=20 >=20 > JP> Poorly worded ... It should read "it is left to the implementer to = define the meaning > of each bit of the 10-bit Link Color Flag field". The use itself is = clearly defined. Thanks. > Text added. >=20 >> There is some description at the top of the section that implies a >> little about how LC is used. It seems closer to a color (a la ToS) = than >> to a bit array (a la resource affinities). >=20 > JP> You're right and this is aimed at being used as a flag field, a la = resource affinities. > I clarified the text. >=20 >>=20 >> If you are determined that this is out of scope for your document, I >> wonder why the object is defined, and I wonder why the section has >> preamble on the use of the meaning of LC. And I really wonder about = the >> presence of section 4.4.2. >>=20 >> --- >>=20 >> Section 6 >>=20 >> There doesn't seem to be any tracking of sub-object Type values. >=20 > As proposed earlier, let's have a common directory for all = constraints/metrics object. > And cal them object if if the case where they are carried in other = object. Same reasoning > applies to the TLV case (not that in the case of OSPF and ISIS we also = have discrepancies, > some protocols called sub-TLV, a TLV carried within a TLV, other = protocol using the same=20 > term regardless on whether or not the TLV is carried within another = TLV or not. >=20 > This way, no need to add another registry, we can use the one defined = in Section 6.1. > I added a common registry for the TLV in Section 6.2. >=20 >>=20 >> --- >>=20 >> Section 7 >>=20 >> You really need a reference to draft-ietf-roll-security-framework. >>=20 >> I think that you made a key security comment in a previous section = where >> you said that it is recommended that the algorithms used do not cause >> excess information flapping. A significant security attack might be >> mounted by periodically attacking the quality of a link resulting in = the >> routing protocol flapping. This would cause wider damage than simply >> the disruption to the local link. >=20 > Excellent point. I did not explicitly point to the security framework = since it does not > explicitly cover the routing metrics but I propose adding the = following text: "Another=20 > attack may consist of making intermitment attacks on a link in an = attempt to constantly=20 > modify the link quality and consequently the associated routing = metric, thus leading to=20 > potential fluctuation in the DAG. It is thus RECOMMENDED for a RPL = implementation=20 > to put in place mechanism so as to stop advertising routing metrics = for highly unstable=20 > links that may be subject to attacks." >=20 > Let me know if that's OK. >=20 > Thanks again for the detailed review. >=20 > > >=20 > Cheers. >=20 > JP. >=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 David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS --Apple-Mail-24--93674245 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Adrian,

On = Nov 26, 2010, at 9:29 AM, Adrian Farrel wrote:

Hi,

I have performed an AD review of your = draft.


Thanks = !

Don't = panic!


Ah ok = ;-)

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 = for an important component of the RPL family.

Most of my comments = are pretty trivial, but a couple have more meat
on them and 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.


Perfect - see = below (skipping all issues that have been addressed in the new = revision)

Of course, all of my = issues are up for discussion.

Thanks for the = work,
Adrian

---

I am slightly worried about the = complexity inherent in this spec.
Although individual implementations = and deployments might choose to use
a very limited subset of the = available (and flexible) options, it seems
that an implementation = must support a much wider subset of options,
metrics, and constraints = in order to be deployable into a wide range of
networks.

Does = this flexibility impact simplicity of = implementation?


JP> We = do do not think so. Actually in most cases, implementations will = implementation
a very small subset of the metrics/constraints. = We have a number of choices and options
here, to address the = requirements spelled out in the requirement RFCs but again it is = neither
expected NOR required for an implementation to = implement them all but certainly each of 
the = metric/constraint/feature is justified by a specific requirement.That = being said, I have 
been told that some implementations = did implement them all.

Section = 1

  It must be noted that the use of dynamic metrics = is not new and has
  been experimented in ARPANET 2. =  The use of dynamic metrics is not
  trivial and = great care must be given to the use of dynamic metrics
=   since it may lead to potential routing instabilities. =  That being
  said, lots of experience has been = gained over the years on the use of
  dynamic routing = metrics, which have been deployed in a number of (non
=   IP) networks.

Can you add a couple of references? One = for ARPANET 2 = experimentation,

Added:

[Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. = "Performance of 
           =      the Revised Routing Metric for ARPANET and = MILNET. 
             =    Submitted to MILCOM 89, March = 1989


and = one for the "lots of experience = gained".


A bit more = difficult ... people skills in the art would know but ... most are = deployed proprietary
systems ...

---

Use of RFC 2119 language.

The first = use (SHOULD) shows up late in Section 1 after a number of
lower case = "must". I think that the best way to smooth this out is to
not use = any 2119 language in the = Introduction.


Indeed, good = catch, thanks.

Figure = 1

This is a copy of figure 22 in draft-ietf-roll-rpl.
I = strongly recommend that you do not duplicate protocol = bit/byte
definitions as this can lead to accidental discrepancies. = Why not
replace this figure with a reference?

---

Bit = numberings in fields. Please align the numbers so that we
count bits = in base 10.


JP> IF ok = with you, I'd rather leave it here, since the RPL document is = fairly
large, this is to avoid too much work jumping between = the two documents.

Section = 2.1

I think the A flag needs a little more constraint. Not only = is it only
valid when C=3D1 (as stated), but it is only valid when = R=3D0.

Also
OLD
     and MUST be = written to 0x00.
NEW
     and MUST be = set to 0x00 and MUST be ignored on = receipt.
END


JP> = Yes, thanks.

---

Section = 2.1

  Unrecognized TLVs MUST be ignored.

Do you = want to clarify that "ignoring" includes leaving the TLVs in
place in = the object when it is forwarded along the = DAG?


JP> = Clarified.

---

Section = 2.2

Have you considered the case that the recording of metrics = causes the
Routing Metric/Constraint object to = overflow?


JP> Yes, this = is clarified in the RPL spec, allowing for multiple DAG Metric = container.
Still I added few words.

--

Section 3.1

  The NSA = object MAY be present in the DAG Metric Container.  There
=   MUST be no more than one NSA object as a constraint per DAG = Metric
  Container, and no more than one NSA object as a = metric per DAG Metric
  Container.

This is fine, = but you will need to define somewhere what happens when
a formatting = error is detected. This can either be done on a case-by-
case basis, = or can be a general statement in Section = 3.

JP> I added some text, = thanks (Section 3): "The sections 3. and 4. specify = several 
link and node metric/constraint objects. = In some cases it is stated that there must not 
be = more than one object of a specific type. In that case, if an RPL = implementation 
receives more than one objet of = that type, the second objet MUST silently be ignored. = "


See also, Section = 3.2

  The NE object MAY be present in the DAG Metric = Container.  There MUST
  be no more than one NE = object as a constraint per DAG Metric
  Container, and no = more than one NE object as a metric per DAG Metric
=   Container.

etc., etc.

Incidentally, it might = be more graceful to use "MUST NOT" instead of
"MUST". For = example:

OLD
  The HP object MAY be present in the = DAG Metric Container.  There MUST
  be no more than = one HP object as a constraint per DAG Metric
  Container, = and no more than one HP object as a metric per DAG Metric
=   Container.
NEW
  The HP object MAY be = present in the DAG Metric Container.  There MUST
=   NOT be more one HP object as a constraint per DAG Metric = Container,
  and there MUST NOT be more than one HP object = as a metric per DAG
  Metric = Container.
END

All = fixed.


Section 3.1

Is = IANA expected to track the flags in the NSA = object?

Yes this is in Section = 6.3.


Are the Type values for = the TLVs chosen from a common registry across
all objects, or is = there a separate registry for each = object?


Good catch ! = Section added in IANA for a *common* registry for all = TLVs.

---

Section = 3.2

  Whenever possible, a node with low residual = energy should not be
  selected as a router

Do you = have a reference for = this?

JP> I reworded the = text, since such decision will either be OF specific or driven by = local policy. Thanks.


---

Section 3.2

  Given = the complexity of trying to address such a broad collection of
=   constraints, this document defines three levels of fidelity = in the
  solution.

I only find two levels defined = in the section:
- The simplest solution relies on a 2-bit field
- = The mid-complexity solution is a single parameter

Did I miss one, = or did you?

We used to work on = 3, and lead to two ... Forgot to update the text, done, = thanks.


---

Section = 3.2

  For scavenging nodes, the 8 bit quantity is the = power
  provided by the scavenger divided by the power = consumed by the
  application, H=3DP_in/P_out, in units of = percent.

and

  For
  battery = powered devices, H is the current expected lifetime divided
=   by the desired minimum lifetime.

Is the second case = also expressed as a = percentage?

Yes (added), = thanks.


---

Section = 3.2

I'm slightly confused by the difference (or not) between the = term 'H'
and the term 'E-E'. Firstly, E-E looks like an arithmetic = expression.
But, more to the point, I *think* you put the value of H = in the field
E-E, so why have two names for the same = thing?


JP> Indeed, = using one term: E-E

---

Objects, sub-objects, and TLVs

I = think you have some inconsistency in naming.

At the top level we = have "Routing Metric/Constraint object"
The "object body" of this = object is defined as:
  The object body carries one or = more sub-objects defined later in this
  document.
So I = expect everything that follows in Sections 3 and 4 to be = termed
sub-objects.

Not = always, for example, when there is one header followed by the main = body, 
it is called an object. When there might be more = than one (for example when 
recording several link ETX, = we may have multiple sub-objects after the header).

But you have also termed these things as = "objects".

Some of the objects/sub-objects in Sections 3 and 4 = can, themselves have
sub-objects, while others launch straight into = contained TLVs.

This is all a bit confusing (although there is = nothing technically
wrong) and it would be really nice to achieve = some consistency = of
terminology.

---

Section 3.2

  The format = of the NE sub-object body is as follows:

And what Type value does = this sub-object use?


The = NE object Type is to be assigned by IANA (recommended = value=3D2)

---

Section = 3.2

  o  T (node Type): 2-bit field indicating = the node type.  E=3D0x00
=      designates a mains-powered node, E=3D0x01 = a battery-powered node and
     E=3D0x02 a = node powered by an energy scavenger.

Do you mean T=3D0x00 = etc.?


JP> indeed ! = Thanks.

--

 
---

Section 3.3

=   The HP object may be used as a constraint or a metric. =  When used as
  a constraint, the DAG root indicates = the maximum number of hops that
  a path may traverse. =  When that number is reached, no other node can
=   join that path.  When used as a metric, each visited = node simply
  increments the Hop Count field.

Are = you counting nodes or hops?
Does the first node send the Hop Count as = one or zero?


Text added to = include the first node.

---

Section 3.3

It looks to me that if = the object is used as a constraint, it MUST also
be present as a = metric. This seems to be different from the burble at
the top of the = section. (and obviously, we can think of more optimal
ways of = signaling this - such as decrementing the hop count at = each
hop).

JP> Not sure = why ... you could use it as a constraint (say to avoid too = much
of delays if you know that the number of traversed hop = may be an issue) and
still want to optimize against another = metric such as the bandwidth ?


---

Section 4.1

  For = the deeply duty-cycled links
  found in many = LLNs

Will this term be clear to the = reader?


JP> Yes I do = think so. 

---

Section= 4.1

With special reference to my comment (above) about objects, = sub-objects,
and TLVs, it is really not helpful to have an object = (which is actually
a sub-object) and a sub-object of that object both = called Throughput!

---

Section 4.1

  Figure 9: = Throughput sub-object format

And what Type value does this = sub-object use?
But, I might ask why you need sub-objects when the = content is well-known
to be 32-bit values, and the parent object has = a length field.

---

Section 4.1

=   Throughput: 32 bits.  The Throughput is encoded in 32 = bits in
  unsigned integer format, expressed in bytes per = second.

Are you sure this is enough? Yes, it seems like it today. = How future-
proof is = this?

JP> 2^32 is huge = ?


---
Section = 4.2

Ditto object and sub-object names.
Ditto sub-object Type = value.


JP> = XXXX

---

Section = 4.2

Again, it looks like the use of this object as a constraint = is only
possible if it is also used as a metric. =

JP> Same comment as for the = hop-count. It does not have to be used as a metric
when also = used as a constraint.

So (again) = it looks like the
rules for object presence are broken.

But = that depends how it is used as a constraint! It might be used to
mean = that no link with unsatisfactory latency may be added to the DAG,
or = it might mean that the cumulative latency must not grow beyond = the
the constrained limit.

You need to clarify meaning and = usage.

---

Section 4.3

  Note that an = RPL implementation MAY either use the LQL, the ETX or
=   both.

This immediately makes me worry about = interoperability.

JP> But = we have different object ... the reason being that depending on the = deployment,
we may either use the LQL or the ETX = ....


---

Section = 4.3.1

  By contrast, the LQL link metric may be
=   aggregated, in which case the sum of all LQLs may be = reported
  (additive metric)

How can this possibly = be useful? Unless you know how many hops are
traversed, the aggregate = is meaningless!


JP> = This is correct. That being said, we wanted to leave it there, = since
it could be useful in some specific scenario (for = example, you may use
two values, 0 (good) 1 (bad), in which = cases it provides you the number
of bad links traversed, a = metric that you could use to select your path).

---

Section 4.3.1

=     0 =             &n= bsp; 1 =             &n= bsp; 2 =             &n= bsp; 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4
=    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ...
   |       Res =     | LQL sub-object
=    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ...

The Res field does not appear to be = described.


JP> Added = (elsewhere too).

---

Section 4.3.1

It seems to me that a = type 0x02 aggregation is not very helpful because
"unknown" will hide = the otherwise 'best' link quality.

But maybe this doesn't matter = because 'worst' link quality is = more
interesting.

JP> = Correct this is one of the cases where this is useful = indeed.


---

Section = 4.4.1

Ditto Res = field


JP> = Added.

---

Section = 4.4.1

How come the LC field in the two sub-objects have different = sizes?


JP> Oops ! = Fixed. Thanks.

---

Section = 4.4.1

  The use of the LC object is outside the scope = of this document.

It seems to me you have gone off half cocked = :-(


JP> Poorly worded = ... It should read "it is left to the implementer to define the = meaning
of each bit of the 10-bit Link Color Flag field". The = use itself is clearly defined. Thanks.
Text = added.

There is some description = at the top of the section that implies a
little about how LC is used. = It seems closer to a color (a la ToS) than
to a bit array (a la = resource affinities).

JP> = You're right and this is aimed at being used as a flag field, a la = resource affinities.
I clarified the = text.


If you are determined = that this is out of scope for your document, I
wonder why the object = is defined, and I wonder why the section has
preamble on the use of = the meaning of LC. And I really wonder about the
presence of section = 4.4.2.

---

Section 6

There doesn't seem to be any = tracking of sub-object Type = values.

As proposed earlier, = let's have a common directory for all constraints/metrics = object.
And cal them object if if the case where they are = carried in other object. Same reasoning
applies to the TLV = case (not that in the case of OSPF and ISIS we also have = discrepancies,
some protocols called sub-TLV, a TLV carried = within a TLV, other protocol using the same 
term = regardless on whether or not the TLV is carried within another TLV or = not.

This way, no need to add another registry, = we can use the one defined in Section 6.1.
I added a common = registry for the TLV in Section 6.2.


---

Section 7

You really need a = reference to draft-ietf-roll-security-framework.

I think that you = made a key security comment in a previous section where
you said that = it is recommended that the algorithms used do not cause
excess = information flapping. A significant security attack might be
mounted = by periodically attacking the quality of a link resulting in = the
routing protocol flapping. This would cause wider damage than = simply
the disruption to the local = link.

Excellent point. I did = not explicitly point to the security framework since it does = not
explicitly cover the routing metrics but I propose adding = the following text: "Another 
attack may = consist of making intermitment attacks on a link in an attempt to = constantly 
modify the link quality and = consequently the associated routing metric, thus leading = to 
potential fluctuation in the DAG. It is thus = RECOMMENDED for a RPL implementation 
to put in = place mechanism so as to stop advertising routing metrics for highly = unstable 
links that may be subject to = attacks."

Let me know if that's = OK.

Thanks again for the detailed = review.

<Diff-me= trics-12-13.webarchive>

_______________________________________________
= 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

David = Culler
Chair Computer Science
Associate Chair = EECS



= --Apple-Mail-24--93674245-- From Internet-Drafts@ietf.org Wed Dec 8 03:00:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB723A6892; Wed, 8 Dec 2010 03:00:02 -0800 (PST) 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.030, 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 hXugI3Rcp4Xk; Wed, 8 Dec 2010 03:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930093A68F5; Wed, 8 Dec 2010 03:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101208110001.23189.39421.idtracker@localhost> Date: Wed, 08 Dec 2010 03:00:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 11:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-04.txt Pages : 9 Date : 2010-12-08 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages to maximize connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-of0-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-08025548.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Wed Dec 8 03:47: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 8C69C3A6907 for ; Wed, 8 Dec 2010 03:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY+OMXTDs-GI for ; Wed, 8 Dec 2010 03:47:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 65E573A6915 for ; Wed, 8 Dec 2010 03:47:19 -0800 (PST) Received: by wwa36 with SMTP id 36so1057689wwa.13 for ; Wed, 08 Dec 2010 03:48:46 -0800 (PST) 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:subject:content-type :content-transfer-encoding; bh=CSO6BLLW7BE+iPMayDU/Bbajzl3Hfs1aE55TYxxbiTg=; b=sJgXVyV1vByFUi2LuD9KlPlIX0aUSUaBcCIX9zp0+L6maXDtOu3K4G9WFNMeCeLfMj ynQveT8UqOoGsbbc/ZHtnO64/Qkp2nDF85sxw+cBrV52WKK6fpEKVCqnThQCUiJlHmHU PILagk35XLPpP1AbnKgtKYyj4rOk69pnAwEyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=oKZCYTKSiAGyGCMYcPTWs3/Rihhr77ZhyuKRb/sWTI+oY8OR8M7R9Uhmyanfg7+dJ5 5VrTeJgIGF3iZn3+7uDzKxy2FB8CFov003Di1xCr88PpwAbeRZsGge+bP49bUZ9FCq6B 4D9XE1Lw2O4RaQ++IqZHPbcIvyjPRDfNw5wBo= Received: by 10.216.24.134 with SMTP id x6mr1685684wex.34.1291808926042; Wed, 08 Dec 2010 03:48:46 -0800 (PST) Received: from [192.168.250.231] ([193.54.192.97]) by mx.google.com with ESMTPS id n1sm212566weq.31.2010.12.08.03.48.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Dec 2010 03:48:45 -0800 (PST) Message-ID: <4CFF70B1.9000205@gmail.com> Date: Wed, 08 Dec 2010 12:49:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Still not described: MAC over dst when RH4 present (dst mutable but predictable) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Dec 2010 11:47:20 -0000 Dear RoLL, It seems to me that the authenticating MAC calculation over the mutable but predictable fields (dst in base header, when RH4 present) is still not described. I searched the following documents: rfc4302 draft-ietf-6man-rpl-routing-header-01 draft-ietf-roll-rpl-15 I suggest text in RPL draft-15 as follows, in this zone: OLD > Message authentication codes (MAC) and signatures are calculated > over the entire unsecured IPv6 packet. When computing MACs and > signatures, mutable IPv6 fields are considered to be filled with > zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec > Authenticated Header). MAC and signature calculations are performed > before any compression that lower layers may apply. NEW: Message authentication codes (MAC) and signatures are calculated over the entire unsecured IPv6 packet. When computing MACs and signatures, mutable IPv6 fields are considered to be filled with zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec Authenticated Header). The mutable but predictable fields (e.g. the dst address field in the base header when RH5 is present) is treated similraly when RH0 is used, as section A.2 of rfc4302 describes. MAC and signature calculations are performed before any compression that lower layers may apply. It may be that you'd like this description in the RH4 draft instead of the RPL draft. It may be that you'd want described it in more detail, as one poster posted in this WG detaliing an algorithm detailing how RH5 would be protected by MAC calculation. I support this as well. ("entire" unsecure packet is wrong too, it should say "most of it", not "entire"). Alex From rmarchap@cisco.com Wed Dec 8 09:57: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 642463A6968 for ; Wed, 8 Dec 2010 09:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4E4CLMEa+BX for ; Wed, 8 Dec 2010 09:57:21 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 54F7A3A6967 for ; Wed, 8 Dec 2010 09:57:21 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApICADJW/0yrR7H+/2dsb2JhbACUfY5jeKR6m0eCcoJXBIRiiSmICQ X-IronPort-AV: E=Sophos;i="4.59,316,1288569600"; d="scan'208";a="296548804" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2010 17:58:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB8Hwnr8018522; Wed, 8 Dec 2010 17:58:49 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Dec 2010 09:58:48 -0800 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, 8 Dec 2010 09:58:45 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900C138BF8@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <7B822F730F822147977ED5B684ACE4900C0A74C6@xmb-sjc-21b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or makeDODAGconfiguration mandatory for all DIOs Thread-Index: AcuQWpeRp87ju3ZGQY+za61HgoK3aABYzHUAAVDh8oA= References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com><31691.1291041283@marajade.sandelman.ca><7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com><80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900C0A74C6@xmb-sjc-21b.amer.cisco.com> From: "Rajesh Marchappanavar (rmarchap)" To: "Rajesh Marchappanavar (rmarchap)" , "Philip Levis" X-OriginalArrivalTime: 08 Dec 2010 17:58:48.0755 (UTC) FILETIME=[90A2F030:01CB9701] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or makeDODAGconfiguration mandatory for all DIOs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Dec 2010 17:57:22 -0000 Should I conclude that this will not be handled at protocol level... Cheers, Rajesh > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Rajesh Marchappanavar (rmarchap) > Sent: Thursday, December 02, 2010 7:08 AM > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or > makeDODAGconfiguration mandatory for all DIOs >=20 >=20 > Sorry for the late reply, was down with viral. > Summary so far: > - There's a configuration error if *any* of the configuration values > differ between the two nodes. Should all of them be in the DIO? Example > DIOIntDoubl. Set to 0. > - "LBR2 sends DIO with config option, Node fails to match OCP and > rejects DIO" > Where in the specification does it say that a node rejects the DIO in > this case and discards it? > - What if the two roots in your example include different routing > metrics in the Metric Container? I guess the metrics in use also > characterize the dag just like OCP. Perhaps, one can identify other > parameters that characterize a dag but are not there in the DIO base > object. >=20 > All good points. There are 2 types of misconfigurations - node specific > and network wide. > - misconfigs of configuration values like DIOIntDoubl can be easily > detected and blocked at a node (root of DODAG). This is a node specific > misconfig. Lets take a look at different config options in DIO: > - > DIOIntDoubl./DIOIntMin./DIORedun./MaxRankIncrease/MinHopRankIncrease/De > f > . Lifetime/Lifetime Unit - controlled at root, nodes just use the value > sent by root. Implementations can easily block incorrect values. > - OCP - configured at root and nodes. Implementations can easily > block > incorrect value configs (node specific misconfig). But valid OCP per > node but incorrect network wide cannot be detected and blocked at root. > - Section 17.2.3 says every node should be configured with instance id, > ocp, and few other parameters, which implies a node should reject a DIO > if it fails to match OCP. > - Two roots including different routing metrics is a very good > considerations and a issue related to the current one being discussed. > A > given OCP can have multiple metrics, for example OCP1 can have etx and > latency metrics, without this info how does a node make a decision > whether to join a DAG or not? OCP is a 16-bit field, do we really need > to further divide it based on metrics? Can't we have one OCP value per > metric? >=20 > Cheers, > Rajesh >=20 >=20 >=20 > > -----Original Message----- > > From: Philip Levis [mailto:pal@cs.stanford.edu] > > Sent: Tuesday, November 30, 2010 12:18 PM > > To: Rajesh Marchappanavar (rmarchap) > > Cc: Michael Richardson; roll@ietf.org > > Subject: Re: [Roll] Make OCP part of DIO base object or make > > DODAGconfiguration mandatory for all DIOs > > > > > > On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: > > >> > > > > > > [RM:] That is because OCP differentiates dags, it's not just a > > > 'configuration option'. A node can join 2 dags of different OCP, > > > instance-id, and dag-id. Which means OCP is a dag characteristic > and > > not > > > just one of the configuration option. The fact that two nodes > > advertise > > > same instance-id, dag-id, and different OCP is a mis-configuration. > > They > > > should be advertising different instance-id, dag-id, and ocp. That > > said, > > > nodes need to deal with such configuration errors. > > > > This statement is technically incorrect. An OCP does not > differentiate > > DAGs. An OCP is associated with a DAG. There is a one-to-one mapping > > between OCPs and DAGs. The draft is quite clear on this. Different > OCPs > > on the same DAG is a (serious) configuration error: while it's > > important that RPL can detect this, I'd argue it's outside the scope > of > > the protocol (or any routing protocol) to proactively deal with such > > problems. The resulting complexity of dealing with all of the > possible > > configuration errors is just too great. > > > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Adrian.Farrel@huawei.com Wed Dec 8 12:03: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 21E3B3A6870 for ; Wed, 8 Dec 2010 12:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=-0.918, 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 wGUyAavDhbrM for ; Wed, 8 Dec 2010 12:03:06 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D09723A69A1 for ; Wed, 8 Dec 2010 12:03:05 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD400E3WL3KPJ@usaga01-in.huawei.com> for roll@ietf.org; Wed, 08 Dec 2010 12:04:33 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD400NM9L3E0L@usaga01-in.huawei.com> for roll@ietf.org; Wed, 08 Dec 2010 12:04:32 -0800 (PST) Date: Wed, 08 Dec 2010 20:04:25 +0000 From: Adrian Farrel To: 'David Culler' , 'JP Vasseur' Message-id: <041701cb9713$203e07a0$60ba16e0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8D2xvcc6BOZMo5I3wA6Ekg)" Content-language: en-gb Thread-index: AcuXErXbzeKHbf8+Q2eA5qcNC1R0Vw== Cc: roll@ietf.org, draft-ietf-roll-routing-metric@tools.ietf.org Subject: [Roll] Complexity [Was: AD review of draft-ietf-roll-routing-metric] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 20:03:07 -0000 This is a multipart message in MIME format. --Boundary_(ID_8D2xvcc6BOZMo5I3wA6Ekg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi David, My concern was with the complexity introduced by optionality, not by the complexity of the features per se (although I did identify a couple of flavors of LQL I don't believe have any benefit). It seems to me that the draft does not provide an unnaturally large number of metrics/constraints. It is really up to the WG to decide whether they want those metrics available, and that is probably a function of the type of network that is being built (compare SPF with TE constrained in MPLS). A compromise solution might be (as I suggest in my other email) to provide "profiles" that are common subsets so that people know what they are implementing/buying/deploying. This is the approach taken in the MIB world where "compliance statements" tell people what functions to expect from a particular claim of compliance. Cheers, Adrian From: David Culler [mailto:culler@cs.berkeley.edu] Sent: 07 December 2010 18:22 To: JP Vasseur Cc: Adrian.Farrel@huawei.com; roll@ietf.org; draft-ietf-roll-routing-metric@tools.ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric Adrian, Thanks very much for your efforts here. It looks like the responses address the specific issues, but I'd like to know if you feel that they address the larger issue of unnecessary complexity. This has been a pervasive concern with this particular piece of work. We have managed to contain it a good bit and we have eliminated the fluff of earlier versions. --Boundary_(ID_8D2xvcc6BOZMo5I3wA6Ekg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi David,

 

My concern was with the complexity introduced by optionality, not by the complexity of the features per se (although I did identify a couple of flavors of LQL I don't believe have any benefit).

 

It seems to me that the draft does not provide an unnaturally large number of metrics/constraints. It is really up to the WG to decide whether they want those metrics available, and that is probably a function of the type of network that is being built (compare SPF with TE constrained in MPLS).

 

A compromise solution might be (as I suggest in my other email) to provide "profiles" that are common subsets so that people know what they are implementing/buying/deploying. This is the approach taken in the MIB world where "compliance statements" ; tell p xpect from a particular claim of compliance.

 

Cheers,

Adrian

 

From: David Culler [mailto:culler@cs.berkeley.edu]
Sent: 07 December 2010 18:22
To: JP Vasseur
Cc: Adrian.Farrel@huawei.com; roll@ietf.org; draft-ietf-roll-routing-metric@tools.ietf.org
Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric

 

Adrian,

   Thanks very much for your efforts here.  It looks like the responses address the specific issues, but I'd like to know if you feel that they address the larger issue of unnecessary complexity.  This has been a pervas ive conc piece of work.  We have managed to contain it a good bit and we have eliminated the fluff of earlier versions.

--Boundary_(ID_8D2xvcc6BOZMo5I3wA6Ekg)-- From Adrian.Farrel@huawei.com Wed Dec 8 12:03: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 C6E5D3A698F for ; Wed, 8 Dec 2010 12:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.993 X-Spam-Level: X-Spam-Status: No, score=-100.993 tagged_above=-999 required=5 tests=[AWL=-3.393, BAYES_00=-2.599, GB_SUMOF=5, 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 ph5+Uu5BQX+q for ; Wed, 8 Dec 2010 12:03:06 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 71B613A686A for ; Wed, 8 Dec 2010 12:03:06 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD400E4FL3MPJ@usaga01-in.huawei.com> for roll@ietf.org; Wed, 08 Dec 2010 12:04:34 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD400NM9L3E0L@usaga01-in.huawei.com> for roll@ietf.org; Wed, 08 Dec 2010 12:04:34 -0800 (PST) Date: Wed, 08 Dec 2010 20:04:25 +0000 From: Adrian Farrel In-reply-to: To: 'JP Vasseur' Message-id: <042401cb9713$21fb9620$65f2c260$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-gb Content-transfer-encoding: quoted-printable Thread-index: AQGSSZv5nemt8BmzVlVGvsQ/EBZGXgKPPQPXk/T/93A= References: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> Cc: roll@ietf.org, draft-ietf-roll-routing-metric@tools.ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 20:03:07 -0000 Hi JP, Thanks for the excellent progress. I have whittled down to just a couple of discussion points. >> I am slightly worried about the complexity inherent in=20 >> this spec. Although individual implementations and >> deployments might choose to use a very limited subset >> of the available (and flexible) options, it seems that an >> implementation must support a much wider subset of >> options, metrics, and constraints in order to be=20 >> deployable into a wide range of networks. >> >> Does this flexibility impact simplicity of implementation? > > JP> We do not think so. Actually in most cases, > implementations will implementation a very small subset > of the metrics/constraints. We have a number of choices > and options here, to address the requirements spelled out > in the requirement RFCs but again it is neither expected > NOR required for an implementation to implement them > all but certainly each of=A0the metric/constraint/feature is > justified by a specific requirement. That being said, I have=A0 > been told that some implementations did implement them > all. So, my only concern in the complexity is what happens when two = implementations implement a different subset. Can those two implementations be deployed = in the same network. I think the answer is "yes", but that in this case only = the intersection of the two subsets can be used. I *think* the protocol can dynamically handle these cases, but that the result may be that the = desired service cannot be provided. The implication here is that each device must list the set of functions = it supports, and the operator must buy devices with a suitable function = set. This is OK if the intention is to document "profiles". For example, the = "deploy in an office" profile includes metrics x, y, and z, and constraints p = and q. Then the implementer can build to a profile and market accordingly. Otherwise, the implementer is left wondering which subset to include and = will (as your correspondents inform you) end up implementing the lot. If = implementing the full set is the right solution, then why not make them all = mandatory? >> Can you add a couple of references?... >>=20 >> ...and one for the "lots of experience gained". > > A bit more difficult ... people skills in the art would know > but ... most are deployed proprietary systems ... Well, this text That being said, lots of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non IP) networks. sits as an unsubstantiated assertion. I don't like them. If you really can't give a reference, can you consider whether the text = is necessary? >> Figure 1 >> >> This is a copy of figure 22 in draft-ietf-roll-rpl. >> I strongly recommend that you do not duplicate protocol >> bit/byte definitions as this can lead to accidental >> discrepancies. Why not replace this figure with a >> reference? > > JP> IF ok with you, I'd rather leave it here, since the RPL > document is fairly large, this is to avoid too much work jumping > between the two documents. Well, you know my concern: if you have a duplicate definition then you = risk having contradicting definitions. So, if you believe that this figure is helpful for the reader can you = include... Figure 1 is copied from Figure 22 in [I-D.ietf-roll-rpl] and is provided = here for information only. The definition of the DAG Metric Container format = in [I-D.ietf-roll-rpl] is normative. >> Section 3.3 >> >> It looks to me that if the object is used as a constraint, it MUST >> also be present as a metric. This seems to be different from the >>burble at the top of the section.=20 > > JP> Not sure why ... you could use it as a constraint (say to avoid > too much of delays if you know that the number of traversed hop > may be an issue) and still want to optimize against another metric=20 > such as the bandwidth ? Well, the text says... The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path.=20 But, if the object states how many hops are allowed (i.e. is a = constraint) then how will you know how many hops have actually been traversed? For that = you need the metric. Actually, this would apply to the use of all metric-based constraints. = E.g., if you set a constraint that the path cost must not be greater than x, you = can include this in a constraint variant of the object, but you also need to = record the metric as you go. See my comment on Section 4.2... >>Section 4.2 >> >> Again, it looks like the use of this object as a constraint is only >> possible if it is also used as a metric.=20 >> > JP> Same comment as for the hop-count. It does not have to be > used as a metric when also used as a constraint. >> Section 4.3 >> >>=A0=A0 Note that an RPL implementation MAY either use the LQL,=20 >> the ETX or=A0both. >> >> This immediately makes me worry about interoperability. > > JP> But we have different object ... the reason being that depending > on the deployment, we may either use the LQL or the ETX .... My point is that if this is an implementation choice, you may find some implementations use only LQL, and some that only use ETX. That would = meant that you cannot deploy either mechanism because you don't have end-to-end = support for either. Perhaps you do not mean that this is an implementation choice, but = really a deployment choice? >> Section 4.3.1 >> >>=A0=A0By contrast, the LQL link metric may be >>=A0=A0aggregated, in which case the sum of all LQLs may be reported >>=A0=A0(additive metric) >> >> How can this possibly be useful? Unless you know how many >> hops are traversed, the aggregate is meaningless! > > JP> This is correct. That being said, we wanted to leave it there,=20 > since it could be useful in some specific scenario (for example, > you may use two values, 0 (good) 1 (bad), in which cases it > provides you the number of bad links traversed, a metric that > you could use to select your path). I'm not going to buy this because the values for quality levels have = been defined as 1 through 7 (not 0 or 1) with the highest value being the = highest quality (not with 0 being the good quality). So, what is the purpose of an aggregate LQL? >> Section 4.3.1 >>=20 >> It seems to me that a type 0x02 aggregation is not very=20 >> helpful because "unknown" will hide the otherwise 'best' >> link quality. >> >> But maybe this doesn't matter because 'worst' link quality is >> more interesting. > > JP> Correct this is one of the cases where this is useful indeed. So you are agreeing that, while A=3D0x01 is useful, A=3D0x02 is probably = not useful (certainly in the presence of unknown LQL). I wonder if anyone even = actually wants to know the best LQL on a path: what would it be used for? Thanks, Adrian From Internet-Drafts@ietf.org Thu Dec 9 01:45: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 225533A6AA1; Thu, 9 Dec 2010 01:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 yHANYK+VXKP9; Thu, 9 Dec 2010 01:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4743A6A38; Thu, 9 Dec 2010 01:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101209094502.14702.58958.idtracker@localhost> Date: Thu, 09 Dec 2010 01:45:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-16.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 09: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-16.txt Pages : 159 Date : 2010-12-09 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-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-09013443.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Thu Dec 9 09:55: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 10F4528C134 for ; Thu, 9 Dec 2010 09:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5gnUw9Wr8Su for ; Thu, 9 Dec 2010 09:55:37 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 63F303A6B9E for ; Thu, 9 Dec 2010 09:55:37 -0800 (PST) Received: from dn0a21024c.sunet ([10.33.2.76]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PQkjr-0002KV-C6; Thu, 09 Dec 2010 09:57:07 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <20101208110001.23189.39421.idtracker@localhost> Date: Thu, 9 Dec 2010 09:57:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101208110001.23189.39421.idtracker@localhost> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 17:55:39 -0000 On Dec 8, 2010, at 3:00 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : RPL Objective Function 0 > Author(s) : P. Thubert > Filename : draft-ietf-roll-of0-04.txt > Pages : 9 > Date : 2010-12-08 >=20 > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a > generic Distance Vector protocol for Low Power and Lossy Networks > (LLNs). RPL is instantiated to honor a particular routing objective/ > constraint by the adding a specific Objective Function (OF) that is > designed to solve that problem. This specification defines a basic > OF, OF0, that uses only the abstract properties exposed in RPL > messages to maximize connectivity. Pascal, Is this intended to be the version that responds to all of the comments = given in last call? Phil= From pthubert@cisco.com Fri Dec 10 01:39: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 5E15F3A6C83 for ; Fri, 10 Dec 2010 01:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.325 X-Spam-Level: X-Spam-Status: No, score=-10.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM6SpytFSOhk for ; Fri, 10 Dec 2010 01:39:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 04B5B3A6C8E for ; Fri, 10 Dec 2010 01:39:32 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAPOEAU2Q/khNgWdsb2JhbACkABUBARYiKaQjmx2FSgSOE4gK X-IronPort-AV: E=Sophos;i="4.59,323,1288569600"; d="scan'208";a="71349258" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2010 09:40:51 +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 oBA9epDv011023; Fri, 10 Dec 2010 09:40:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Dec 2010 10:40:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2010 10:40:43 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuXypKW0vLoVYonS3qFY1lL5Dn3UgAg43JA References: <20101208110001.23189.39421.idtracker@localhost> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 10 Dec 2010 09:40:51.0685 (UTC) FILETIME=[55575950:01CB984E] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 09:39:34 -0000 Hi Phil: This answers all the comments I've received so far.=20 I have not seen that the last call was complete but I thought I owed the group this refresher. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Thursday, December 09, 2010 6:57 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > On Dec 8, 2010, at 3:00 AM, 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. > > > > > > Title : RPL Objective Function 0 > > Author(s) : P. Thubert > > Filename : draft-ietf-roll-of0-04.txt > > Pages : 9 > > Date : 2010-12-08 > > > > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a > > generic Distance Vector protocol for Low Power and Lossy Networks > > (LLNs). RPL is instantiated to honor a particular routing objective/ > > constraint by the adding a specific Objective Function (OF) that is > > designed to solve that problem. This specification defines a basic > > OF, OF0, that uses only the abstract properties exposed in RPL > > messages to maximize connectivity. >=20 > Pascal, >=20 > Is this intended to be the version that responds to all of the comments given > in last call? >=20 > Phil From Internet-Drafts@ietf.org Fri Dec 10 11:15:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D071028C0E5; Fri, 10 Dec 2010 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 jvljszhfUkdi; Fri, 10 Dec 2010 11:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0946C3A6CB8; Fri, 10 Dec 2010 11:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101210191502.28041.20508.idtracker@localhost> Date: Fri, 10 Dec 2010 11:15:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-03.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, 10 Dec 2010 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-03.txt Pages : 45 Date : 2010-12-10 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-security-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-10111045.I-D@ietf.org> --NextPart-- From prvs=953fc711b=Tzeta.Tsao@cooperindustries.com Fri Dec 10 11:18: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 8D8D828C10C for ; Fri, 10 Dec 2010 11:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BU+21J2KM2V for ; Fri, 10 Dec 2010 11:18:38 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id A8CDB3A67B2 for ; Fri, 10 Dec 2010 11:18:37 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,325,1288584000"; d="scan'208";a="80272937" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 10 Dec 2010 14:20:09 -0500 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Dec 2010 14:20:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2010 14:19:41 -0500 Message-ID: <9BB070DB2D281946859EA89837931EEE3D6FF0@EVS4.nam.ci.root> In-Reply-To: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-roll-security-framework Thread-Index: AcuK+eHOEv2t2978RrKkYTgEyUv14gNpFugg References: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> From: "Tsao, Tzeta" To: , X-OriginalArrivalTime: 10 Dec 2010 19:20:08.0995 (UTC) FILETIME=[424FF730:01CB989F] Cc: roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Dec 2010 19:18:40 -0000 WG, We have posted draft-ietf-roll-security-framework-03, which should be available from the repository shortly. The main changes are to address AD's comments. New texts are added to better explain the integrity principle under consideration, as well as some discussions on key management. Thanks, Tzeta -----Original Message----- From: Adrian Farrel [mailto:Adrian.Farrel@huawei.com]=20 Sent: Tuesday, November 23, 2010 5:38 AM To: draft-ietf-roll-security-framework@tools.ietf.org Cc: roll@ietf.org Subject: AD review of draft-ietf-roll-security-framework Hi, 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=20 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 for a very thorough survey of the landscape, and a well written document. Most of my comments are pretty trivial, but a couple have more meat on them and 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 gives two warnings about references: =3D=3D Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on = lines 1786, but no explicit reference was found in the text =3D=3D Outdated reference: A later version (-14) exists of draft-ietf-roll-rpl-11 --- I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative reference. You may want to look at this to decide whether you can avoid or dilute the reference so that you are not blocked in the RFC Editor=20 Queue. --- The RFC Editor usually likes the first section in the document to be the Introduction. I think you can safely swap the Terminology section with the Introduction. --- Section 3.2 Because LLNs are most commonly found on publicly accessible shared medium, e.g., air or wiring in a building, and sometimes s/on/on a/ --- Section 3.2 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. I'm not comfortable with "misuse" in the context of integrity. The term suggests to me that the information might be used for illicit purposes which I would think ties in with "confidentiality" not "integrity". Am I missing something? --- Section 3.2 In addition, integrity also requires 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. I'm curious that you tie authenticity to the *message* source and=20 destination rather than to the *information*. This has been a debate in routing security for some time. Consider an IGP where one could authenticate the message exchanges between protocol peers, or one could authenticate the link state information that is being distributed. Clearly there are implications for the solution, and the chain-of-trust model of the former may achieve the latter. However, I think that the asset is the information not the message, and it is the asset that must be authenticated. --- Section 3.2 It is noted that, besides those captured in the CIA model, assurance "those" what? Suggest... It is noted that, besides those security issues captured in the CIA model, assurance --- Section 3.2 Non-repudiation Reading this section, it seems to me that you have identified non- repudiation as a viable threat to ROLL. You have also recognised that=20 the traditional mechanisms for discovering it are hard or impossible to apply in a LLN.=20 That analysis is fine. But then you go on to say "it is hard, so we won't talk about it"! This doesn't seem to be right. At the very least you should provide an analysis of the risks and impact of non-repudiation in ROLL. You can then also quantify the issues with applying traditional techniques, and this might motivate people to derive new techniques (or to determine that it is not a significant problem in ROLL). --- Section 3.3 As a consequence of these constraints, there is an even more critical need than usual for a careful trade study on which and "trade study"? Do you mean "study of trade-offs"? Or just "study"? --- Section 3.3 Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the Lln Border Routers (LBRs) s/Lln/LLN/ --- Section 3.3 I'm not sure, but I think you should add some emphasis on the ease with which nodes can attach to some LLNs (especially wireless ones). To some extent this might be covered by the "ad hoc" elements in Autonomous operations and by the bullet item Unattended locations and limited physical security but I think you should draw this out specifically as it is one of the greater security issues that I have heard voiced. --- I think that the discussion of key management is a bit weak. The issue is identified in Sections 3.3 and 3,4 as something that can be made more complicated in the LLN environment, but then very little is made of the topic in the document. I think you should have a look at RFC 4107, which should probably one of your references, and then see whether there is anything you can add, possibly to Sections 6 and 7. From pal@cs.stanford.edu Fri Dec 10 11:48: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 25C9D28C136 for ; Fri, 10 Dec 2010 11:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0vI5PbVkOxh for ; Fri, 10 Dec 2010 11:48:26 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 6BDAE28C100 for ; Fri, 10 Dec 2010 11:48:26 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.100]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PR8yc-0003Lg-HD; Fri, 10 Dec 2010 11:49:58 -0800 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 10 Dec 2010 11:49:50 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 19:48:27 -0000 On Dec 10, 2010, at 1:40 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > This answers all the comments I've received so far. > I have not seen that the last call was complete but I thought I > owed the > group this refresher. Can you describe how it addresses my comments? I don't feel it does, but I may just be missing it. Phil From iesg-secretary@ietf.org Fri Dec 10 13:25: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 2C74928C165; Fri, 10 Dec 2010 13:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 dQvdIyphVFKY; Fri, 10 Dec 2010 13:25:50 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C523A6BB3; Fri, 10 Dec 2010 13:25:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101210212550.25490.35706.idtracker@localhost> Date: Fri, 10 Dec 2010 13:25:50 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (A Security Framework for Routing over Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 21:25:55 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'A Security Framework for Routing over Low Power and Lossy Networks' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ No IPR declarations have been submitted directly on this I-D. From pthubert@cisco.com Mon Dec 13 00:17:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3C93A6D2D for ; Mon, 13 Dec 2010 00:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1-aP8K-lA4Z for ; Mon, 13 Dec 2010 00:17:31 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C8F6D3A6900 for ; Mon, 13 Dec 2010 00:17:29 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEplBU2rR7H+/2dsb2JhbACjfXimTJo8hUoEjhOICg X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="301307309" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2010 08:19:05 +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 oBD8Iwna021485; Mon, 13 Dec 2010 08:19:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 09:18:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 09:18:47 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> In-Reply-To: <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuYo29ZlCYFTq88QwOkBGY/42VJ6QB+WdSA References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 13 Dec 2010 08:18:49.0509 (UTC) FILETIME=[5EBC2550:01CB9A9E] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 08:17:39 -0000 Hi Phil: Apparently I missed a mail. OF 04 fails to address your concerns. So I digged into the WG list and found this: " My major concern with OF0 is actually quite different: it does not say how to compute Rank from metrics. Back in the discussions on MRHOF, this emerged as a requirement for an OF, when we separated OFs from metrics. Right now, it seems like I could have an OF0 that computes Rank from latency, or throughput. Since the computation of Rank is very poorly defined, it seems very easy to have two incompatible OF0 implementations that work at cross purposes. For OF0 to be ready to be an RFC, it must actually provide some details on how metrics are converted to Rank. Take a look at the April discussion entitled "Decoupling Metrics and OF." " OF0 does not use say how to metrics. It is a weighted hop count for use in wire and wire emulation. I agree that the weight could be static or dynamic, but the design point is specifically not to discuss the computation of dynamic weights in OF0. This would be opening the Pandora box of the general RPL metrics and OF discussion, which is addressed elsewhere and in lot more text than needed here. So if we take the weight as a given, hopefully stable enough scalar, then the rank computation is the most classical addition of weighted hops. Could you please be more specific in what you'd add to the spec? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Friday, December 10, 2010 8:50 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 10, 2010, at 1:40 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > This answers all the comments I've received so far. > > I have not seen that the last call was complete but I thought I owed > > the group this refresher. >=20 > Can you describe how it addresses my comments? I don't feel it does, but I > may just be missing it. >=20 > Phil From Internet-Drafts@ietf.org Mon Dec 13 06:30: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 1630D3A6EA5; Mon, 13 Dec 2010 06:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 aSxVyNkBj3zm; Mon, 13 Dec 2010 06:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176F63A6DC1; Mon, 13 Dec 2010 06:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101213143002.21486.32753.idtracker@localhost> Date: Mon, 13 Dec 2010 06:30:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-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, 13 Dec 2010 14:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-14.txt Pages : 30 Date : 2010-12-13 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-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-routing-metrics-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-13062138.I-D@ietf.org> --NextPart-- From jpv@cisco.com Mon Dec 13 06:43: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 E2C693A6EA9 for ; Mon, 13 Dec 2010 06:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.22 X-Spam-Level: X-Spam-Status: No, score=-110.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 V1n75kzeS0Gj for ; Mon, 13 Dec 2010 06:43:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DAE853A6EA8 for ; Mon, 13 Dec 2010 06:43:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD/ABU2rR7H+/2dsb2JhbACkAninIpsAhUoEinmDGg X-IronPort-AV: E=Sophos;i="4.59,336,1288569600"; d="scan'208";a="231726336" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 13 Dec 2010 14:45:05 +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 oBDEj4Ja009015; Mon, 13 Dec 2010 14:45:04 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 15:45:03 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Dec 2010 15:45:02 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <20101213143002.21486.2006.idtracker@localhost> Date: Mon, 13 Dec 2010 15:45:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93BF6A1E-7085-4003-8F31-35813092522E@cisco.com> References: <20101213143002.21486.2006.idtracker@localhost> To: ROLL WG X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 13 Dec 2010 14:45:02.0996 (UTC) FILETIME=[5335A540:01CB9AD4] Cc: draft-ietf-roll-routing-metrics@tools.ietf.org, adrian.farrel@huawei.com, roll-chairs@tools.ietf.org Subject: Re: [Roll] New Version Notification - draft-ietf-roll-routing-metrics-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, 13 Dec 2010 14:43:28 -0000 This new revision addresses our AD's comment (thanks Adrian). JP. On Dec 13, 2010, at 3:30 PM, Internet-Draft@ietf.org wrote: > New version (-14) has been submitted for = draft-ietf-roll-routing-metrics-14.txt. > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-14.txt= > Sub state has been changed to AD Follow up from New Id Needed >=20 > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-routing-metrics-14 >=20 > IETF Secretariat. From iesg-secretary@ietf.org Mon Dec 13 09:24: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 0CCB928C107; Mon, 13 Dec 2010 09:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 MxhF1GF2h8wM; Mon, 13 Dec 2010 09:24:21 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589C83A6EB9; Mon, 13 Dec 2010 09:24:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101213172421.16435.97118.idtracker@localhost> Date: Mon, 13 Dec 2010 09:24:21 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (Routing Metrics used for Path Calculation in Low Power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 13 Dec 2010 17:24:22 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Routing Metrics used for Path Calculation in Low Power and Lossy Networks' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ No IPR declarations have been submitted directly on this I-D. From gm.lee@it-sudparis.eu Mon Dec 13 21:45: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 9935F3A6E48 for ; Mon, 13 Dec 2010 21:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIt8b8iZdMen for ; Mon, 13 Dec 2010 21:44:57 -0800 (PST) Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 53FC128C0CF for ; Mon, 13 Dec 2010 21:44:57 -0800 (PST) Received: from smtp2.it-sudparis.eu (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 929E0FE028F; Tue, 14 Dec 2010 06:46:36 +0100 (CET) Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.it-sudparis.eu (Postfix) with ESMTP id 5E4BDF4003B; Tue, 14 Dec 2010 06:46:33 +0100 (CET) Received: from gmleenote (unknown [113.160.248.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 1AA672C18534; Tue, 14 Dec 2010 06:46:30 +0100 (CET) From: "Gyu Myoung Lee" To: References: In-Reply-To: Date: Tue, 14 Dec 2010 06:46:27 +0100 Message-ID: <001701cb9b52$42d267a0$c87736e0$@lee@it-sudparis.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01CB9B5A.A496CFA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuHtV0KDhGmLVFKTxSSmElIQ/C+DwQjUsRwAMOU5BAAADWUAAAABp+wAAAGQ9AAAAwIUA== Content-Language: ko X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner-ID: 5E4BDF4003B.A6E80 X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: gm.lee@it-sudparis.eu X-Mailman-Approved-At: Mon, 13 Dec 2010 22:24:07 -0800 Cc: 'Bruce Nordman' Subject: [Roll] Call for proposal on the IoT X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Dec 2010 05:45:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01CB9B5A.A496CFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All Sorry for cross-posting. Based on meeting results of last IoT Bar BoF in Beijing, we have decided to call for a short proposal on the IoT after discussing with Bruce and Ning. The aim is to identify problems and key issues for establishing a new group on the IoT in IRTF. Please see the details as follows. The submission deadline: 7th January 2011 (Friday) Scope: All related future research topics for the IoT within the IETF/IRTF Proposal submission: iot-irtf-discussion@googlegroups.com The template of proposal (1-2 pages) [based on Bruce's]: -Title -Summary -Problem statement -Research approach -Expected results -Interested people -Relationship to the IETF/IRTF working groups After receiving all proposals, we will prepare a formal BoF by the end of January. - Have an audio conference for reviewing proposals with key members - Update the PS document (editors) - Request an I-D for a good proposal (contributors) - Prepare a draft charter for IoT RG - Submit a BoF proposal If you have any question, feel free to contact me. In addition, please circulate this e-mail to your colleagues for promoting this activity. Looking forward to receiving valuable inputs from you. Best Regards, Gyu Myoung Lee ------=_NextPart_000_0018_01CB9B5A.A496CFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All

 

Sorry for cross-posting.

 

Based on meeting results of last IoT Bar BoF in Beijing, we = have decided to call for a short proposal on the IoT after discussing = with Bruce and Ning.

The = aim is to identify problems and key issues for establishing a new group = on the IoT in IRTF.

 

Please see the details as follows.

The submission = deadline: 7th January 2011 = (Friday)

Scope: All = related future research topics for the IoT within the IETF/IRTF =

Proposal = submission: iot-irtf-discussion@googlegroups.com  

The template of = proposal (1-2 pages) [based on Bruce’s]:

-Title

-Summary

-Problem = statement

-Research = approach

-Expected = results

-Interested = people

-Relationship to = the IETF/IRTF working groups

After receiving = all proposals, we will prepare a formal BoF by the end of = January.

-       = Have an audio = conference for reviewing proposals with key = members

-       = Update the PS = document (editors)

-       = Request an I-D = for a good proposal (contributors)

-       = Prepare a draft = charter for IoT RG

-       = Submit a BoF = proposal

 

If = you have any question, feel free to contact me. In addition, please = circulate this e-mail to your colleagues for promoting this = activity.

Looking forward = to receiving valuable inputs from you.

 

Best = Regards,

Gyu Myoung = Lee

------=_NextPart_000_0018_01CB9B5A.A496CFA0-- From qiuying@i2r.a-star.edu.sg Tue Dec 14 03:49: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 F0D5F3A6F98 for ; Tue, 14 Dec 2010 03:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.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 amXnD40qLp5L for ; Tue, 14 Dec 2010 03:49:35 -0800 (PST) Received: from gw3.scei.a-star.edu.sg (gw3.scei.a-star.edu.sg [192.122.140.12]) by core3.amsl.com (Postfix) with ESMTP id 89E9E3A6CE7 for ; Tue, 14 Dec 2010 03:49:33 -0800 (PST) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw3.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id oBEBp3vv001605; Tue, 14 Dec 2010 19:51:03 +0800 Received: from Win7PC ([10.217.141.120]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Dec 2010 19:50:29 +0800 From: "QIU Ying" To: "'Greg Zaverucha'" , Date: Tue, 14 Dec 2010 19:54:56 +0800 Message-ID: <006501cb9b85$ba236ab0$2e6a4010$@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: AcubhbnGZ/57HNuQSQOWHxyKSiSyUw== Content-Language: en-sg X-OriginalArrivalTime: 14 Dec 2010 11:50:29.0063 (UTC) FILETIME=[1AAC0D70:01CB9B85] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-14_07:2010-12-14, 2010-12-14, 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-1010190000 definitions=main-1012140029 Cc: baofeng@i2r.a-star.edu.sg, jyzhou@i2r.a-star.edu.sg Subject: Re: [Roll] Comments on 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: Tue, 14 Dec 2010 11:49:36 -0000 Hi, Greg Thank Greg for review and comment this draft. Please see my response inline. >Author: Greg Zaverucha (gzaverucha@rim.com) >Date: 2010-11-26 >----------------------------------------------------------------------- >Summary of the draft > The Qiu et al. draft gives a protocol for sensor nodes to authenticate and >establish a shared key. The network topology is a mesh, allowing >node-to-node communication. In addition to sensor nodes there are routers and >base stations. Sensors have a pre-shared key with each base-station and routers >share a key with the base-station as well. Routers and base stations assist >nodes to establish a shared key and authenticate. The sensor nodes contact the >base station (which acts like a CA) to request a shared key with a router or >other node. The response from the base station is sent via a router who Please note where the said via ROUTER is the new router that the sensor node wants to attach. >processes the reponse before sending it to the node. After the base station >response is sent to the sensor node, both the node and router have a shared key > (which is also known by the base station). >----------------------------------------------------------------------- >General comments > >- Section two should be expanded: describe what types of devices are in the > network (sensors, routers, basesstations), what their capabilities are in >terms of communication and computation, if they are mobile, etc.. Adding some >details from RFC 4919 might be appropriate. OK. Will be maturated in new version. >- In the introduction or Section 2 it might help to describe some typical > attacks that this proposal is trying to prevent, and maybe describe some of >the adversary's capabilites. OK. >- Two nodes must be in range of router or basestation to establish a key. Using public key-techniques this limitation is not present. I am not sure whether we need to consider this scenario in sensor networking. IMHO, the job of a sensor is to collect the information and send to base station to analysis and process, or performs the commands from the base station. The capability of communicating directly between any two nodes (neighbour or long distance) should be the scope of mobile networks. Any comments? >- On management of the table of shared keys: the Qiu et al. draft suggests that > the oldest key in the table should be expunged if additional space is >required. This is undesirable: instead an LRU (least recently used) type of >algorithm should be used (or other page replacement algorithm which gives >better performance given the access patterns of this application). Such an >algorithm will require a small amount of overhead, but this cost will be offset >by a reduced number of key agreements. Good comments. Will be revised in new version. >- In the notice message, is it really necessary for R0 to be sent back to the node? >The node already knows this value, and it must be used to check the MAC. Yes, the R0 cannot be ignored because the sensor node might send out many request messages with various R0 if it cannot receive the notice message in time. Hence, the sensor node must know which R0 is used in the notice message. >- You should give some possible choices for the encryption and MAC algorithms > used in the protocol, and what properties they should have. For example, in >the appv message encryption is used, but I think it should be >authenticated encryption. The primitives in Suite E >(http://tools.ietf.org/html/draft-campagna-suitee-00) would probably be >suitable. OK. >- No guidance is given on key management issues. How do new sensors establish > shared keys with all routers and base stations? What about adding new >routers, how do all existing sensors get re-keyed? >- The document gives no recommendations for parameter sizes More details will appear in new version. Regards and Thanks Qiu Ying 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 pal@cs.stanford.edu Tue Dec 14 10:32: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 A0CAE28C0E4 for ; Tue, 14 Dec 2010 10:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNFlbX05H7O7 for ; Tue, 14 Dec 2010 10:32:32 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id CAFE728C0E0 for ; Tue, 14 Dec 2010 10:32:32 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PSZhV-0000bh-D7; Tue, 14 Dec 2010 10:34:13 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> Date: Tue, 14 Dec 2010 10:34:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 18:32:33 -0000 On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 > Apparently I missed a mail. OF 04 fails to address your concerns. So I > digged into the WG list and found this: >=20 > " > My major concern with OF0 is actually quite different: it does not say > how to compute Rank from metrics. Back in the discussions on MRHOF, = this > emerged as a requirement for an OF, when we separated OFs from = metrics. > Right now, it seems like I could have an OF0 that computes Rank from > latency, or throughput. Since the computation of Rank is very poorly > defined, it seems very easy to have two incompatible OF0 = implementations > that work at cross purposes. >=20 > For OF0 to be ready to be an RFC, it must actually provide some = details > on how metrics are converted to Rank. Take a look at the April > discussion entitled "Decoupling Metrics and OF." > " >=20 > OF0 does not use say how to metrics. It is a weighted hop count for = use > in wire and wire emulation. I agree that the weight could be static or > dynamic, but the design point is specifically not to discuss the > computation of dynamic weights in OF0. This would be opening the = Pandora > box of the general RPL metrics and OF discussion, which is addressed > elsewhere and in lot more text than needed here. So if we take the > weight as a given, hopefully stable enough scalar, then the rank > computation is the most classical addition of weighted hops. But the consensus, when discussing MRHOF, is that an objective function = specification needs to say how to handle and use metrics. It seems = strange that OF0 doesn't. Or does OF0 have a special status, that it = does not have to follow the requirements laid out for objective function = specifications? Otherwise you can have independent implementations which are = incompatible and cause problems: this was due to JP's insistence that = objective functions remain metric-independent. What worries me about = this is that it seems to just blindly repeat mistakes that LLN protocols = have learned from. E.g., modern OLSR deployments do not adhere to the = OLSR specification because it requires hopcount and hopcount does not = work very well. You're right, there's lots of experience using hopcount = as a metric. In the context of LLNs, however, that experience has been = negative. > Could you please be more specific in what you'd add to the spec? I would add a specification of how OF0 translates metrics into Rank. = E.g., an ETX between 1 and 3 adds 1 to Rank, etc. Phil= From pthubert@cisco.com Wed Dec 15 03:04: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 56D3D3A690D for ; Wed, 15 Dec 2010 03:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO26rJRJGGKh for ; Wed, 15 Dec 2010 03:04:22 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 490DC3A6841 for ; Wed, 15 Dec 2010 03:04:22 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG8vCE2Q/khMgWdsb2JhbACkJRYBFiIkphabQ4VKBI4XiAs X-IronPort-AV: E=Sophos;i="4.59,347,1288569600"; d="scan'208";a="71689096" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2010 11:06:03 +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 oBFB63sJ005519; Wed, 15 Dec 2010 11:06:03 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 12:06:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2010 12:06:00 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcubvZAX/02D6R+3QjuTq6vcMdDb0wAeaTLw References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 15 Dec 2010 11:06:03.0359 (UTC) FILETIME=[1033A6F0:01CB9C48] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 11:04:24 -0000 Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI.=20 This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. =20 I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. >=20 > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? >=20 > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. >=20 > > Could you please be more specific in what you'd add to the spec? >=20 > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > Phil From d.sturek@att.net Wed Dec 15 08:51: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 5F8843A6FA7 for ; Wed, 15 Dec 2010 08:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc6c5yu3vMl6 for ; Wed, 15 Dec 2010 08:51:45 -0800 (PST) Received: from web81401.mail.mud.yahoo.com (web81401.mail.mud.yahoo.com [68.142.199.129]) by core3.amsl.com (Postfix) with SMTP id 7EF5F3A6FA8 for ; Wed, 15 Dec 2010 08:51:45 -0800 (PST) Received: (qmail 96699 invoked by uid 60001); 15 Dec 2010 16:53:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292432002; bh=/Q8e8kKTCd9DezMOKX85fYUC4sDtrCAmxMrCoPHURzw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vG+AyfCLJlmz3FGtc6Mty4lrmj+pkxkIp9DGyQR4MjiKImzxRuWSLbLqe/bmlV93wXls80zMJcWZAr0FiR69t1iw7F9PDuQWxHBy0MwSgeQX+au618W7kKYbt12Ml0XGjUkg9TW6YgU59AMyjoy5vKl87d2TikhVHxi+DuzZIAE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bRGqsA/RjiOoVhGuqsFg8TswBUQNeQrpJVPWlXQHiw2guDQfWAyw1AxHZ0A0Ve4QLYShGnD5wwTn1E5/DMDofXPVBWZ7Synq2qp5FbH85DvMsqkCZ1yr6F7tyHYUPrC5MUlX2OhkPwuzYMnU/yVY8Q6nY8BNN0A1MyJAhrhZBOY=; Message-ID: <801711.79377.qm@web81401.mail.mud.yahoo.com> X-YMail-OSG: 5jADif4VM1lp6EqMXFDOHLwsboNoy_CyvJwMvWwmoY6UabF EkPwZf10..lOWPf9uESAivPC_2MXj3Zf1wEOkTygWbXC7gwUagU3fByaqfio f.rBHPesnqYxC1kzsNuq2T4bPo.v_n7t6RH0yjXf25xB63SMNBuvzBDnxMfv AsIXbBvASDTrsAmdt5hnmTfxxQ338vYkeGhhgbtCRcV3lXXGL44RqwxZXCoX 7JNQuq3aca4KTruxsG8F5RKtMjsTQOhIVgrWnJ2CtZY9EjAHyvZG_Kn8wPLi h3O.7CcK9IhQNEYjvX8vitfqutMSD.EOmlh0Y2mwMzC5A8DYUG8yM9OvAs9V bnYn70MGoL.oEsoMaEcgqRapGrEtpkBEgUw-- Received: from [173.200.121.113] by web81401.mail.mud.yahoo.com via HTTP; Wed, 15 Dec 2010 08:53:22 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> Date: Wed, 15 Dec 2010 08:53:22 -0800 (PST) From: Don Sturek To: "Pascal Thubert \(pthubert\)" , Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1705408621-1292432002=:79377" Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:51:47 -0000 --0-1705408621-1292432002=:79377 Content-Type: text/plain; charset=us-ascii I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don ________________________________ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI. This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. > > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? > > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. > > > Could you please be more specific in what you'd add to the spec? > > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --0-1705408621-1292432002=:79377 Content-Type: text/html; charset=us-ascii
I have never quite understood the use for RPL in wired networks.  All of the PLC solutions I have looked at would not benefit at all by RPL.  The main use case is wireless where asymmetric links are a major problem.  It is difficult to understand the logic below in light of this inconsistency.

Don


From: Pascal Thubert (pthubert) <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Phil:


> learned from. E.g., modern OLSR deployments do not adhere to the OLSR
> specification because it requires hopcount and hopcount does not work
very
> well. You're right, there's lots of experience using hopcount as a
metric. In
> the context of LLNs, however, that experience has been negative.

We're in a loop here. This need that you describe mostly comes from
propagation issues encountered in wireless networks.
The whole point is that not all LLNs are wireless. Administrative cost
is both usual and proven on wires.

Also there are wireless emulations around that provide an acceptable
service and heavily deployed service, both P2P like military and
satellite radios and transit, the most common being WIFI.
This is clearly not your world, but the fact is that we have had happy
customers  for over 10 years, using Spanning Tree or similar over
wireless bridges.

I'd assert that RPL provides a lot more than STP, if only because:
- we have the IPv6 hop limit and the RPL reactive loop detection thus no
risk of meltdown
- we build DAGs as opposed to trees

If we can't converge on that, let's keep the discussion at wired links
for a minute. In that case, RPL can often be used the way any other IGP
is used today, can't it?
Then again, we can derive from RPL's properties that it can actually be
preferable over existing protocols at least for certain applications,
because it can be both simpler and faster to set up.
Such applications include:

- corporate VPN (with branch and SOHO, typical recursive )
- ad hoc networks (quickly deployable ad hoc base camps)
- dynamic overlays (meshes of tunnels serving small groups with short
term purposes)

> I would add a specification of how OF0 translates metrics into Rank.
E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the expected metric is an administrative cost that is trivially
added up along a path; the most usual thing.
OF 0 was designed to be that simple.  This said, I can see 2 ways for
moving forward with your suggestion:

1) We describe that the metric is a static (admin) cost range 1..16 and
that it is placed in the most significant octet of the rank.

2) We decide to add support for a dynamic metric. In that case, we enter
the discussion on stability, statistical dampening, and hysteresis.

And obviously option 3 being both.

I can easily accommodate 1) and republish. Text on 2) would have to be
very vague, like a set of recommendation. 

I do not mind either way, both are probably useful. What does the group
think?

On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd
rather expose the statistical aspect of  a metric than resort to
hysteresis.
For all I know, this is also something that was successfully tried on
OLSR, but that is not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/


> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> > Hi Phil:
> >
> > Apparently I missed a mail. OF 04 fails to address your concerns. So
I
> > digged into the WG list and found this:
> >
> > "
> > My major concern with OF0 is actually quite different: it does not
say
> > how to compute Rank from metrics. Back in the discussions on MRHOF,
> > this emerged as a requirement for an OF, when we separated OFs from
> metrics.
> > Right now, it seems like I could have an OF0 that computes Rank from
> > latency, or throughput. Since the computation of Rank is very poorly
> > defined, it seems very easy to have two incompatible OF0
> > implementations that work at cross purposes.
> >
> > For OF0 to be ready to be an RFC, it must actually provide some
> > details on how metrics are converted to Rank. Take a look at the
April
> > discussion entitled "Decoupling Metrics and OF."
> > "
> >
> > OF0 does not use say how to metrics. It is a weighted hop count for
> > use in wire and wire emulation. I agree that the weight could be
> > static or dynamic, but the design point is specifically not to
discuss
> > the computation of dynamic weights in OF0. This would be opening the
> > Pandora box of the general RPL metrics and OF discussion, which is
> > addressed elsewhere and in lot more text than needed here. So if we
> > take the weight as a given, hopefully stable enough scalar, then the
> > rank computation is the most classical addition of weighted hops.
>
> But the consensus, when discussing MRHOF, is that an objective
function
> specification needs to say how to handle and use metrics. It seems
strange
> that OF0 doesn't. Or does OF0 have a special status, that it does not
have to
> follow the requirements laid out for objective function
specifications?
>
> Otherwise you can have independent implementations which are
> incompatible and cause problems: this was due to JP's insistence that
> objective functions remain metric-independent. What worries me about
this
> is that it seems to just blindly repeat mistakes that LLN protocols
have
> learned from. E.g., modern OLSR deployments do not adhere to the OLSR
> specification because it requires hopcount and hopcount does not work
very
> well. You're right, there's lots of experience using hopcount as a
metric. In
> the context of LLNs, however, that experience has been negative.
>
> > Could you please be more specific in what you'd add to the spec?
>
> I would add a specification of how OF0 translates metrics into Rank.
E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.
>
> Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--0-1705408621-1292432002=:79377-- From Internet-Drafts@ietf.org Wed Dec 15 15:00: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 189B628C0E1; Wed, 15 Dec 2010 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 vq5LasLcwv4N; Wed, 15 Dec 2010 15:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BCC28C117; Wed, 15 Dec 2010 15:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101215230001.30256.8767.idtracker@localhost> Date: Wed, 15 Dec 2010 15:00:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 23: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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-17.txt Pages : 159 Date : 2010-12-15 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-15145851.I-D@ietf.org> --NextPart-- From wintert@acm.org Wed Dec 15 15:06: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 C34A228C10D for ; Wed, 15 Dec 2010 15:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BeSJ+2KRKIg for ; Wed, 15 Dec 2010 15:06:51 -0800 (PST) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id BFB5728C0E7 for ; Wed, 15 Dec 2010 15:06:50 -0800 (PST) Received: (qmail 3605 invoked from network); 15 Dec 2010 23:08:31 -0000 Received: from [10.56.17.102] (wintert@71.178.253.216 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 15 Dec 2010 15:08:31 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: hoEzRBYVM1mjJLwvdl02G8VLuSJyAdbYWQbNEyfbYt4H6qN E4zoMGIY1O3XlhZEAvzP2bpYpX1knCHmZFdM.3j_9DAAS._mNzc357PT6I0L EPJWkOs2X9Hi00CvEJPKRxrMMGBdObUWjBsEoEHZLu2DQIalAiFgLNyJdwnp B98sk0K4zA.careHcbUNqq7QUEvQe9MMjriug9bcl3sdC78zuWHhht2zwJYy Tr4cWmjTchGZcwGZaLVO8dmxQ2lBPVg3rjJVR0mlWjgqvXjgzVA_aZsHeC7F sa2B_C9wfMQoKMDmHMp.Abven.kU07ZLyHaqCWVGJ3etCoN4Na._GsfjVl51 mbNOQwr9s1HF.mmTzgTJOPsWvWDUhGNn2S9IH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D094A6F.6060102@acm.org> Date: Wed, 15 Dec 2010 18:08:31 -0500 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20101215230001.30256.8767.idtracker@localhost> In-Reply-To: <20101215230001.30256.8767.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 23:06:51 -0000 WG, With this revision we continue to address concerns brought up in IESG evaluation (https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/) Regards, -Tim On 12/15/2010 06:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-17.txt > Pages : 159 > Date : 2010-12-15 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Dec 16 06:52: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 9867A3A67D7 for ; Thu, 16 Dec 2010 06:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.714 X-Spam-Level: X-Spam-Status: No, score=-9.714 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tPUA5gmh8EX for ; Thu, 16 Dec 2010 06:52:03 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A667D3A67D4 for ; Thu, 16 Dec 2010 06:52:03 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACO2CU2rRN+J/2dsb2JhbACCF6Ifc6Ydm1uFSgSOGogM X-IronPort-AV: E=Sophos;i="4.59,355,1288569600"; d="scan'208,217";a="233672565" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Dec 2010 14:53:48 +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 oBGErjbT013681; Thu, 16 Dec 2010 14:53:47 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Dec 2010 15:53:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9D30.FC8D43A1" Date: Thu, 16 Dec 2010 15:53:21 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> In-Reply-To: <801711.79377.qm@web81401.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YA References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> From: "Pascal Thubert (pthubert)" To: "Don Sturek" , "Philip Levis" X-OriginalArrivalTime: 16 Dec 2010 14:53:23.0251 (UTC) FILETIME=[FC9FC030:01CB9D30] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 14:52:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9D30.FC8D43A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don: =20 I listed a number of examples and none of them is PLC actually.=20 RPL is a routing protocol. There is no point in preventing its usage on wired lines. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don =20 ________________________________ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI.=20 This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. =20 I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. >=20 > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? >=20 > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. >=20 > > Could you please be more specific in what you'd add to the spec? >=20 > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CB9D30.FC8D43A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CB9D30.FC8D43A1-- From d.sturek@att.net Thu Dec 16 06:55: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 0078B3A67FC for ; Thu, 16 Dec 2010 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_LWSHORTT=1.24, 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 8CBJmrNrNa0v for ; Thu, 16 Dec 2010 06:55:03 -0800 (PST) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by core3.amsl.com (Postfix) with SMTP id 2D9EA3A67F7 for ; Thu, 16 Dec 2010 06:55:03 -0800 (PST) Received: from [98.139.91.63] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 16 Dec 2010 14:56:45 -0000 Received: from [98.139.91.20] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 16 Dec 2010 14:56:45 -0000 Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 16 Dec 2010 14:56:45 -0000 X-Yahoo-Newman-Id: 534110.89083.bm@omp1020.mail.sp2.yahoo.com Received: (qmail 67497 invoked from network); 16 Dec 2010 14:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292511405; bh=JdkdR8w4XkjaxrxT/jQLoS/rU05HzaVTOmektDf/2bI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=K4o6NNSGzKFrio3XYqLHPSvtwzIhU3nKb2vXobzRuPLNfmJG9MWY2EiY8nWpyaEAaEH9V0VCZCPZk+T0xr5Py7DVqlvTBGePwA9VicBMZx6WbBVXUa2vVPDxxiNUPY99aPYvEI15guw8f0YPP8WqEN8ujM82pGMcqCozWvsT9Yw= Received: from Studio (d.sturek@69.105.138.114 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 16 Dec 2010 06:56:41 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: CLZTWvQVM1mTGQ82riedCw6j31ioqoZIURCo2lYxArx.let FjllvJ6t5ILwyFANgrIhA02kE5fv9BMT2JaSH.9ry2DT8hmzm2SyocPYpJXC anmqBZQFXZ.bgYS9MPwR0iSX6nDfV1RWHX43YfTXrcs9dVFwkeNSe4D9Twin _xAMpxZy8i_B8OEesis9fVq4X9_YI22ZZG.IDwLqvvPfFV7avZDZO41EWvad kbvbiMrSB69arPGGSrwWR3hSebO8JhKdwW1V30Tw50xNJCil2Y5kYHB3J5A- - X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , "'Philip Levis'" References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> Date: Thu, 16 Dec 2010 06:56:37 -0800 Message-ID: <008d01cb9d31$70655ac0$51301040$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01CB9CEE.62421AC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GA= Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 14:55:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008E_01CB9CEE.62421AC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Pascal, Correct, there is no point in preventing the use of RPL in wired networks. That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I listed a number of examples and none of them is PLC actually. RPL is a routing protocol. There is no point in preventing its usage on wired lines. Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don _____ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI. This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. > > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? > > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. > > > Could you please be more specific in what you'd add to the spec? > > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_008E_01CB9CEE.62421AC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_008E_01CB9CEE.62421AC0-- From pthubert@cisco.com Thu Dec 16 07:03: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 D640F3A6853 for ; Thu, 16 Dec 2010 07:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.698 X-Spam-Level: X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l11Ka9PqF4gm for ; Thu, 16 Dec 2010 07:03:36 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B4CF03A67AC for ; Thu, 16 Dec 2010 07:03:35 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcEAC+5CU2Q/khLgWdsb2JhbACCF6IgFQEBFiIkpg2bWoVKBI4aiAw X-IronPort-AV: E=Sophos;i="4.59,355,1288569600"; d="scan'208,217";a="15376024" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 Dec 2010 15:05:19 +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 oBGF5JpV009439; Thu, 16 Dec 2010 15:05:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Dec 2010 16:05:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9D32.A72597E0" Date: Thu, 16 Dec 2010 16:05:15 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> In-Reply-To: <008d01cb9d31$70655ac0$51301040$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAA== References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Philip Levis" X-OriginalArrivalTime: 16 Dec 2010 15:05:19.0023 (UTC) FILETIME=[A741E3F0:01CB9D32] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:03:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9D32.A72597E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don: =20 I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that's why OF 0 was split from RPL at some point. Please let us know if there's any claim (left?) that OF0 is the default OF for RPL... =20 I'll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I'll just try my best to make sure that it can be used where it's needed. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Thursday, December 16, 2010 3:57 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Hi Pascal, =20 Correct, there is no point in preventing the use of RPL in wired networks. =20 That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Don: =20 I listed a number of examples and none of them is PLC actually.=20 RPL is a routing protocol. There is no point in preventing its usage on wired lines. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don =20 ________________________________ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI.=20 This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. =20 I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. >=20 > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? >=20 > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. >=20 > > Could you please be more specific in what you'd add to the spec? >=20 > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CB9D32.A72597E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don:

 

I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that’s why OF 0 was split from RPL at some point. Please let us = know if there’s any claim (left?) that OF0 is the default OF for = RPL…

 

I’ll abstain to make any prediction as of where RPL will be = most used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I’ll just try my best to make sure = that it can be used where it’s needed.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CB9D32.A72597E0-- From d.sturek@att.net Thu Dec 16 07:39: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 4416E3A68ED for ; Thu, 16 Dec 2010 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_LWSHORTT=1.24, 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 wbVyZym+4pP5 for ; Thu, 16 Dec 2010 07:39:03 -0800 (PST) Received: from nm23-vm0.bullet.mail.ac4.yahoo.com (nm23-vm0.bullet.mail.ac4.yahoo.com [98.139.53.220]) by core3.amsl.com (Postfix) with SMTP id 051123A6863 for ; Thu, 16 Dec 2010 07:39:02 -0800 (PST) Received: from [98.139.52.196] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 15:40:45 -0000 Received: from [98.139.52.132] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 15:40:45 -0000 Received: from [127.0.0.1] by omp1015.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 15:40:45 -0000 X-Yahoo-Newman-Id: 246296.91179.bm@omp1015.mail.ac4.yahoo.com Received: (qmail 56481 invoked from network); 16 Dec 2010 15:40:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292514045; bh=33CUQ15Mw29hTffEV+EFVk1ERUKT6HOOz0b7+DNAG5M=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=goCQW2S0ZiVewQOfmrUv4CMjneQoR8W9jXEY+8scfodUynvlOFZ66gB7+aDsLFqwUc6by51jddPvO5hGsTYYYFb65lv6ZGaxl7Cq/I2EGG29s2jNjmG2J9qZ3DpSmp+WAgs25RPGfcQB6wyNA75evFdanVb/SvV+uWCTIZK25B0= Received: from Studio (d.sturek@69.105.138.114 with login) by smtp101.sbc.mail.ac4.yahoo.com with SMTP; 16 Dec 2010 07:40:40 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: PfyE2qAVM1m4.Uc74tWStXO1XAtbILoiWiDZ6a9QIP39icx usL1UdPwN5jcxEAons1vfQhRSoC6n50F5_r5c.UcZmtPb6HWJu7tKETdylfV PX27hCpQOgdF_QoODLXpYfdW0XkXjnIcHskyg_TJBAMvC60r3koAoAj6dJEk dyWWIh6qBDgmQ0Lh5iVAWYJwHxPwEcwmVCPU.lRg8HnFb51C4CxDuza2IRxX J7Gk0nWLOg6fOB_uoouEnhKpJlN4B0K7bWYu1uXBXvConHwATIhd0owr9.AM upfNXEe0G.uzvXB41t9XYBcVqDM7rpnsFifR0ubC6XSIxe.noXwPEYR.RV4g .98lGKHhGMXN63AqqI10pdYNv8_4CLxlkXUYZZVs- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , "'Philip Levis'" References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> Date: Thu, 16 Dec 2010 07:40:35 -0800 Message-ID: <00c401cb9d37$95618730$c0249590$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01CB9CF4.873E4730" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAAABZB0g Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:39:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01CB9CF4.873E4730 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think we are missing something other than OF0 to use. Maybe we just need a draft on this. Let me see if we can't generate something in our ZigBee IP testing. For sure we won't be using OF0 and we need to specify something anyway. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 7:05 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that's why OF 0 was split from RPL at some point. Please let us know if there's any claim (left?) that OF0 is the default OF for RPL. I'll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I'll just try my best to make sure that it can be used where it's needed. Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, December 16, 2010 3:57 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Pascal, Correct, there is no point in preventing the use of RPL in wired networks. That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I listed a number of examples and none of them is PLC actually. RPL is a routing protocol. There is no point in preventing its usage on wired lines. Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don _____ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI. This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. > > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? > > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. > > > Could you please be more specific in what you'd add to the spec? > > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00C5_01CB9CF4.873E4730 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think we are missing something other than OF0 to use.  Maybe = we just need a draft on this.

 

Let me see if we can’t generate something in our ZigBee IP = testing.  For sure we won’t be using OF0 and we need to = specify something anyway.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 7:05 AM
To: d.sturek@att.net; = Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that’s why OF 0 was split from RPL at some point. Please let us = know if there’s any claim (left?) that OF0 is the default OF for = RPL…

 

I’ll abstain to make any prediction as of where RPL will be = most used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I’ll just try my best to make sure = that it can be used where it’s needed.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_00C5_01CB9CF4.873E4730-- From pthubert@cisco.com Thu Dec 16 07:49: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 840B73A68F0 for ; Thu, 16 Dec 2010 07:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.683 X-Spam-Level: X-Spam-Status: No, score=-9.683 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJUdXHbt8WaB for ; Thu, 16 Dec 2010 07:48:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 63A4B3A68DB for ; Thu, 16 Dec 2010 07:48:55 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcEALrDCU2Q/khNgWdsb2JhbACCF6IhFQEBFiIkphGbW4VKBI4aiAw X-IronPort-AV: E=Sophos;i="4.59,355,1288569600"; d="scan'208,217";a="71805532" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2010 15:50:39 +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 oBGFodtT015875; Thu, 16 Dec 2010 15:50:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Dec 2010 16:50:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9D38.FBF01A1A" Date: Thu, 16 Dec 2010 16:50:36 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> In-Reply-To: <00c401cb9d37$95618730$c0249590$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAAABZB0gAABd+rA= References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> <00c401cb9d37$95618730$c0249590$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Philip Levis" X-OriginalArrivalTime: 16 Dec 2010 15:50:38.0347 (UTC) FILETIME=[FC19CDB0:01CB9D38] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:49:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9D38.FBF01A1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Did you consider draft-ietf-roll-minrank-hysteresis-of ? =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Thursday, December 16, 2010 4:41 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I think we are missing something other than OF0 to use. Maybe we just need a draft on this. =20 Let me see if we can't generate something in our ZigBee IP testing. For sure we won't be using OF0 and we need to specify something anyway. Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 7:05 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Don: =20 I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that's why OF 0 was split from RPL at some point. Please let us know if there's any claim (left?) that OF0 is the default OF for RPL... =20 I'll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I'll just try my best to make sure that it can be used where it's needed. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Thursday, December 16, 2010 3:57 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Hi Pascal, =20 Correct, there is no point in preventing the use of RPL in wired networks. =20 That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Don: =20 I listed a number of examples and none of them is PLC actually.=20 RPL is a routing protocol. There is no point in preventing its usage on wired lines. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don =20 ________________________________ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI.=20 This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. =20 I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. >=20 > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? >=20 > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. >=20 > > Could you please be more specific in what you'd add to the spec? >=20 > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CB9D38.FBF01A1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Did you consider draft-ietf-roll-minrank-hysteresis-of = ?

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 4:41 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I think we are missing something other than OF0 to use.  Maybe = we just need a draft on this.

 

Let me see if we can’t generate something in our ZigBee IP = testing.  For sure we won’t be using OF0 and we need to = specify something anyway.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 7:05 AM
To: d.sturek@att.net; = Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that’s why OF 0 was split from RPL at some point. Please let us = know if there’s any claim (left?) that OF0 is the default OF for = RPL…

 

I’ll abstain to make any prediction as of where RPL will be = most used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I’ll just try my best to make sure = that it can be used where it’s needed.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CB9D38.FBF01A1A-- From d.sturek@att.net Thu Dec 16 07:59:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06C03A67EB for ; Thu, 16 Dec 2010 07:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_LWSHORTT=1.24, 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 Evfow609S1o7 for ; Thu, 16 Dec 2010 07:59:07 -0800 (PST) Received: from nm30-vm0.bullet.mail.ac4.yahoo.com (nm30-vm0.bullet.mail.ac4.yahoo.com [98.139.52.250]) by core3.amsl.com (Postfix) with SMTP id 442913A67A3 for ; Thu, 16 Dec 2010 07:59:07 -0800 (PST) Received: from [98.139.52.196] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 16:00:49 -0000 Received: from [98.139.52.145] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 16:00:49 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 16 Dec 2010 16:00:49 -0000 X-Yahoo-Newman-Id: 647451.18674.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 15282 invoked from network); 16 Dec 2010 16:00:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292515249; bh=BZiZHusC6wACHK1rKCk96e1AJD/r8sjJUI5oBBoUXj8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=NbMXeE8C7o07NbLyjqilajw2OgHbOfxEuhGizqrf8BDeKA2eitbiJbsU4/n43bvQfFstxRsTuwUiE2GtBPWgpNrN0jowX9iP20bb7JIwQ1x2Wptkg+IW6Y4Tnxu97Qwn81TgmwdEsFXFjY7SrNMgZOjxEgBKXQAxbBKNwR3cFYo= Received: from Studio (d.sturek@69.105.138.114 with login) by smtp101.sbc.mail.re3.yahoo.com with SMTP; 16 Dec 2010 08:00:45 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 6NTY0GgVM1mX8gR5eLgP2VCQsrLgb9H_vwPOqUJJUjckrFB AlMD1OFEG34qqgHW6L6pBIezLof6iXgs.4fZVbuJU6V3MK11QPY0AKEEbA7r pZJQqcFEHzKjxbsCzDpjj_WastZiChnCz_kmbshLnvt1rfs1pASAG6d9qQj9 ASgO4fzCFj3ACLskJ.t3pQUlvhFKSM9tnRQ53RVy_dcmanZzYlLFyjS0es1_ z24fHCljS9bOBbDZB.ZevdOJj4RFwoyg- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , "'Philip Levis'" References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> <00c401cb9d37$95618730$c0249590$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> Date: Thu, 16 Dec 2010 08:00:40 -0800 Message-ID: <00ea01cb9d3a$63c68650$2b5392f0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01CB9CF7.55A34650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAAABZB0gAABd+rAAAFea0A== Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:59:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00EB_01CB9CF7.55A34650 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think we are looking at how to handle asymmetric links. We had a way to do this in previous deployments so will likely contribute a new OF that covers that function. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 7:51 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Did you consider draft-ietf-roll-minrank-hysteresis-of ? Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, December 16, 2010 4:41 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I think we are missing something other than OF0 to use. Maybe we just need a draft on this. Let me see if we can't generate something in our ZigBee IP testing. For sure we won't be using OF0 and we need to specify something anyway. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 7:05 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that's why OF 0 was split from RPL at some point. Please let us know if there's any claim (left?) that OF0 is the default OF for RPL. I'll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I'll just try my best to make sure that it can be used where it's needed. Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, December 16, 2010 3:57 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Pascal, Correct, there is no point in preventing the use of RPL in wired networks. That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I listed a number of examples and none of them is PLC actually. RPL is a routing protocol. There is no point in preventing its usage on wired lines. Pascal http://www.xtranormal.com/watch/7011357/ From: Don Sturek [mailto:d.sturek@att.net] Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don _____ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI. This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. > > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? > > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. > > > Could you please be more specific in what you'd add to the spec? > > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00EB_01CB9CF7.55A34650 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think we are looking at how to handle asymmetric links.  We = had a way to do this in previous deployments so will likely contribute a = new OF that covers that function.

 

Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 7:51 AM
To: d.sturek@att.net; = Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Did you consider draft-ietf-roll-minrank-hysteresis-of = ?

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 4:41 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I think we are missing something other than OF0 to use.  Maybe = we just need a draft on this.

 

Let me see if we can’t generate something in our ZigBee IP = testing.  For sure we won’t be using OF0 and we need to = specify something anyway.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 7:05 AM
To: d.sturek@att.net; = Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that’s why OF 0 was split from RPL at some point. Please let us = know if there’s any claim (left?) that OF0 is the default OF for = RPL…

 

I’ll abstain to make any prediction as of where RPL will be = most used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I’ll just try my best to make sure = that it can be used where it’s needed.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Thursday, December = 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip = Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Wednesday, = December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: = Philip Levis <pal@cs.stanford.edu>
Cc: ROLL WG = <roll@ietf.org>
Sent: Wed, December 15, 2010 3:06:00 = AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_00EB_01CB9CF7.55A34650-- From yoav@yitran.com Thu Dec 16 08:46: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 F104C3A693D for ; Thu, 16 Dec 2010 08:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMAZvWGB+7O7 for ; Thu, 16 Dec 2010 08:46:51 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 4AE883A6916 for ; Thu, 16 Dec 2010 08:46:51 -0800 (PST) Received: from source ([209.85.214.46]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTQpC5DuCVV2h6XZZoA7jVoEyozBKZIaV@postini.com; Thu, 16 Dec 2010 08:48:36 PST Received: by mail-bw0-f46.google.com with SMTP id 15so3912915bwz.5 for ; Thu, 16 Dec 2010 08:48:36 -0800 (PST) Received: by 10.204.80.73 with SMTP id s9mr907128bkk.148.1292518115831; Thu, 16 Dec 2010 08:48:35 -0800 (PST) From: Yoav Ben-Yehezkel References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> <00c401cb9d37$95618730$c0249590$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> <00ea01cb9d3a$63c68650$2b5392f0$@sturek@att.net> In-Reply-To: <00ea01cb9d3a$63c68650$2b5392f0$@sturek@att.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAAABZB0gAABd+rAAAFea0AABLkvQ Date: Thu, 16 Dec 2010 18:46:56 +0200 Message-ID: To: d.sturek@att.net, "Pascal Thubert (pthubert)" , Philip Levis Content-Type: multipart/alternative; boundary=0016e6d7e59828f1e5049789d305 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 16:46:55 -0000 --0016e6d7e59828f1e5049789d305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, For the record - let me shed some light on the PLC case from our experience= . PLC links can definitely be asymmetric. This is due to the fact that the main factors affecting reception are noise at the Rx side (different at bot= h ends), and load at Tx side (again different at both ends). So from both ends, there can easily be asymmetry. Without getting into the details of how this is done, I agree that RPL must provide mechanism(s) enabling to cope with asymmetric links as a non-rare case (isn=92t it one of the requirements of RPL?) Now getting into the details =96 can the WG at least provide some feedback = on whether such mechanisms are supported by RPL in all major modes and topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)? Best regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *Don Sturek *Sent:* Thursday, December 16, 2010 6:01 PM *To:* 'Pascal Thubert (pthubert)'; 'Philip Levis' *Cc:* 'ROLL WG' *Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I think we are looking at how to handle asymmetric links. We had a way to do this in previous deployments so will likely contribute a new OF that covers that function. Don *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] *Sent:* Thursday, December 16, 2010 7:51 AM *To:* d.sturek@att.net; Philip Levis *Cc:* ROLL WG *Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Did you consider draft-ietf-roll-minrank-hysteresis-of ? Pascal http://www.xtranormal.com/watch/7011357/ *From:* Don Sturek [mailto:d.sturek@att.net] *Sent:* Thursday, December 16, 2010 4:41 PM *To:* Pascal Thubert (pthubert); 'Philip Levis' *Cc:* 'ROLL WG' *Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I think we are missing something other than OF0 to use. Maybe we just need a draft on this. Let me see if we can=92t generate something in our ZigBee IP testing. For sure we won=92t be using OF0 and we need to specify something anyway. Don *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] *Sent:* Thursday, December 16, 2010 7:05 AM *To:* d.sturek@att.net; Philip Levis *Cc:* ROLL WG *Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that=92s wh= y OF 0 was split from RPL at some point. Please let us know if there=92s any claim (left?) that OF0 is the default OF for RPL=85 I=92ll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I=92ll just try my best to make sure that it can be used where it=92= s needed. Pascal http://www.xtranormal.com/watch/7011357/ *From:* Don Sturek [mailto:d.sturek@att.net] *Sent:* Thursday, December 16, 2010 3:57 PM *To:* Pascal Thubert (pthubert); 'Philip Levis' *Cc:* 'ROLL WG' *Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Pascal, Correct, there is no point in preventing the use of RPL in wired networks. That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] *Sent:* Thursday, December 16, 2010 6:53 AM *To:* Don Sturek; Philip Levis *Cc:* ROLL WG *Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Don: I listed a number of examples and none of them is PLC actually. RPL is a routing protocol. There is no point in preventing its usage on wired lines. Pascal http://www.xtranormal.com/watch/7011357/ *From:* Don Sturek [mailto:d.sturek@att.net] *Sent:* Wednesday, December 15, 2010 5:53 PM *To:* Pascal Thubert (pthubert); Philip Levis *Cc:* ROLL WG *Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt I have never quite understood the use for RPL in wired networks. All of th= e PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don ------------------------------ *From:* Pascal Thubert (pthubert) *To:* Philip Levis *Cc:* ROLL WG *Sent:* Wed, December 15, 2010 3:06:00 AM *Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI. This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. > > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? > > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. > > > Could you please be more specific in what you'd add to the spec? > > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --0016e6d7e59828f1e5049789d305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi all,

=A0

For the record - let me shed some light on the PLC case from= our experience.

=A0

PLC links can definitely be asymmetric. This is due to the fact that the main factors affecting reception are noise at the Rx side (di= fferent at both ends), and load at Tx side (again different at both ends). <= /p>

So from both ends, there can easily be asymmetry.

=A0

Without getting into the details of how this is done, I agree that RPL must provide mechanism(s) enabling to cope with asymmetric l= inks as a non-rare case (isn=92t it one of the requirements of RPL?)

=A0

Now getting into the details =96 can the WG at least provide= some feedback on whether such mechanisms are supported by RPL in all major modes= and topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)?

=A0

Best regards,

Yoav

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of Don Sturek
Sent: Thursday, December 16, 2010 6:01 PM
To: 'Pascal Thubert (pthubert)'; 'Philip Levis'
Cc: 'ROLL WG'
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

I think we are looking at how to handle asymmetric links.=A0 We had a way to do this in previous deployments so will likely contribute a= new OF that covers that function.

=A0

Don

=A0

=A0

From: Pascal T= hubert (pthubert) [mailto:pthubert@cisco.com= ]
Sent: Thursday, December 16, 2010 7:51 AM
To: d.sturek@att.net; Philip= Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

Did you consider draft-ietf-roll-minrank-hysteresis-of ?

=A0

=A0

From: Don Stur= ek [mailto:d.sturek@att.net]
Sent: Thursday, December 16, 2010 4:41 PM
To: Pascal Thubert (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

I think we are missing something other than OF0 to use.=A0 Maybe we just need a draft on this.

=A0

Let me see if we can=92t generate something in our ZigBee IP testing.=A0 For sure we won=92t be using OF0 and we need to specify somethi= ng anyway.


Don

=A0

=A0

From: Pascal T= hubert (pthubert) [mailto:pthubert@cisco.com= ]
Sent: Thursday, December 16, 2010 7:05 AM
To: d.sturek@att.net; Philip= Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

Don:

=A0

I think that the disconnect is your assumption that OF 0 is = the default. There is no default OF in RPL. That was discussed at length and th= at=92s why OF 0 was split from RPL at some point. Please let us know if there=92s = any claim (left?) that OF0 is the default OF for RPL=85

=A0

I=92ll abstain to make any prediction as of where RPL will b= e most used (or useful). We got rid of having to make that assumption by allowing = OF to extend the base protocol in the first place. This was actually a key des= ign point. I=92ll just try my best to make sure that it can be used where it=92= s needed.

=A0

=A0

From: Don Stur= ek [mailto:d.sturek@att.net]
Sent: Thursday, December 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

Hi Pascal,

=A0

Correct, there=A0 is no point in preventing the use of RPL i= n wired networks.

=A0

That said, when the default OF uses a metric that is known n= ot to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause.


Don

=A0

=A0

From: Pascal T= hubert (pthubert) [mailto:pthubert@cisco.com= ]
Sent: Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

Don:

=A0

I listed a number of examples and none of them is PLC actual= ly.

RPL is a routing protocol. There is no point in preventing i= ts usage on wired lines.

=A0

=A0

From: Don Stur= ek [mailto:d.sturek@att.net]
Sent: Wednesday, December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

=A0

I have never quite un= derstood the use for RPL in wired networks.=A0 All of the PLC solutions I have looke= d at would not benefit at all by RPL.=A0 The main use case is wireless where asymmetric links are a major problem.=A0 It is difficult to understand the logic below in light of this inconsistency.

Don

=A0

From: Pascal T= hubert (pthubert) <pthubert@cisco.com= >
To: Philip Levis <pal@cs.s= tanford.edu>
Cc: ROLL WG <roll@ietf.org&g= t;
Sent: Wed, December 15, 2010 3:06:00 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Phil:


> learned from. E.g., modern OLSR deployments do not adhere to the OLSR<= br> > specification because it requires hopcount and hopcount does not work<= br> very
> well. You're right, there's lots of experience using hopcount = as a
metric. In
> the context of LLNs, however, that experience has been negative.

We're in a loop here. This need that you describe mostly comes from
propagation issues encountered in wireless networks.
The whole point is that not all LLNs are wireless. Administrative cost
is both usual and proven on wires.

Also there are wireless emulations around that provide an acceptable
service and heavily deployed service, both P2P like military and
satellite radios and transit, the most common being WIFI.
This is clearly not your world, but the fact is that we have had happy
customers=A0 for over 10 years, using Spanning Tree or similar over
wireless bridges.

I'd assert that RPL provides a lot more than STP, if only because:
- we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown
- we build DAGs as opposed to trees

If we can't converge on that, let's keep the discussion at wired li= nks
for a minute. In that case, RPL can often be used the way any other IGP
is used today, can't it?
Then again, we can derive from RPL's properties that it can actually be=
preferable over existing protocols at least for certain applications,
because it can be both simpler and faster to set up.
Such applications include:

- corporate VPN (with branch and SOHO, typical recursive )
- ad hoc networks (quickly deployable ad hoc base camps)
- dynamic overlays (meshes of tunnels serving small groups with short
term purposes)

> I would add a specification of how OF0 translates metrics into Rank. E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing.
OF 0 was designed to be that simple.=A0 This said, I can see 2 ways for
moving forward with your suggestion:

1) We describe that the metric is a static (admin) cost range 1..16 and
that it is placed in the most significant octet of the rank.

2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis.

And obviously option 3 being both.

I can easily accommodate 1) and republish. Text on 2) would have to be
very vague, like a set of recommendation.=A0

I do not mind either way, both are probably useful. What does the group
think?

On the side, if you dig patent 7,567,577 at USPTO, you'll find that I&#= 39;d
rather expose the statistical aspect of=A0 a metric than resort to
hysteresis.
For all I know, this is also something that was successfully tried on
OLSR, but that is not available in the RPL metrics draft.

:=A0 )
Pascal
http= ://www.xtranormal.com/watch/7011357/


> -----Original Message-----
> From: Philip Levis [mailto:pal@= cs.stanford.edu]
> Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> > Hi Phil:
> >
> > Apparently I missed a mail. OF 04 fails to address your concerns.= So
I
> > digged into the WG list and found this:
> >
> > "
> > My major concern with OF0 is actually quite different: it does no= t
say
> > how to compute Rank from metrics. Back in the discussions on MRHO= F,
> > this emerged as a requirement for an OF, when we separated OFs fr= om
> metrics.
> > Right now, it seems like I could have an OF0 that computes Rank f= rom
> > latency, or throughput. Since the computation of Rank is very poo= rly
> > defined, it seems very easy to have two incompatible OF0
> > implementations that work at cross purposes.
> >
> > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the<= br> April
> > discussion entitled "Decoupling Metrics and OF."
> > "
> >
> > OF0 does not use say how to metrics. It is a weighted hop count f= or
> > use in wire and wire emulation. I agree that the weight could be<= br> > > static or dynamic, but the design point is specifically not to discuss
> > the computation of dynamic weights in OF0. This would be opening = the
> > Pandora box of the general RPL metrics and OF discussion, which i= s
> > addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough scalar, then = the
> > rank computation is the most classical addition of weighted hops.=
>
> But the consensus, when discussing MRHOF, is that an objective
function
> specification needs to say how to handle and use metrics. It seems
strange
> that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective function
specifications?
>
> Otherwise you can have independent implementations which are
> incompatible and cause problems: this was due to JP's insistence t= hat
> objective functions remain metric-independent. What worries me about this
> is that it seems to just blindly repeat mistakes that LLN protocols have
> learned from. E.g., modern OLSR deployments do not adhere to the OLSR<= br> > specification because it requires hopcount and hopcount does not work<= br> very
> well. You're right, there's lots of experience using hopcount = as a
metric. In
> the context of LLNs, however, that experience has been negative.
>
> > Could you please be more specific in what you'd add to the sp= ec?
>
> I would add a specification of how OF0 translates metrics into Rank. E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.
>
> Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0016e6d7e59828f1e5049789d305-- From pthubert@cisco.com Fri Dec 17 01:46: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 C318C3A6926 for ; Fri, 17 Dec 2010 01:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw7ZJhaG9D9l for ; Fri, 17 Dec 2010 01:46:36 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F02413A67FC for ; Fri, 17 Dec 2010 01:46:34 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIEABfBCk2Q/khLgWdsb2JhbACCF6ImFQEBFiIkqDKbN4VKBI4diA4 X-IronPort-AV: E=Sophos;i="4.59,360,1288569600"; d="scan'208,217";a="15454039" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Dec 2010 09:48:20 +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 oBH9mKYM001081; Fri, 17 Dec 2010 09:48:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Dec 2010 10:48:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9DCF.890A3848" Date: Fri, 17 Dec 2010 10:48:17 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D037042FD@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcuceJmDmXkcVW1wRFOZl9CcXqVguwAuB0YAAAAd3GAAAC4iAAABZB0gAABd+rAAAFea0AABLkvQACP8xUA= References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com><4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com><801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com><008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com><00c401cb9d37$95618730$c0249590$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> <00ea01cb9d3a$63c68650$2b5392f0$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , , "Philip Levis" X-OriginalArrivalTime: 17 Dec 2010 09:48:19.0698 (UTC) FILETIME=[8944F520:01CB9DCF] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 09:46:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9DCF.890A3848 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav. =20 Most certainly. This was actually debated at length on the very ML. =20 For what I remember, there were 2 options: - Make RPL more complex to handle a different set of parents for up and down. This includes metrics descriptor that qualify a metric as UP or DOWN - Use 2 instances, one for traffic up (no need for DAO) and one for traffic down. =20 My intuition is that the latter is the simpler. If by definition an OF is an UP OF, then it will process and relay metrics that cover the UP diecrtion. =20 What do you think? =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com]=20 Sent: Thursday, December 16, 2010 5:47 PM To: d.sturek@att.net; Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Hi all, =20 For the record - let me shed some light on the PLC case from our experience. =20 PLC links can definitely be asymmetric. This is due to the fact that the main factors affecting reception are noise at the Rx side (different at both ends), and load at Tx side (again different at both ends).=20 So from both ends, there can easily be asymmetry. =20 Without getting into the details of how this is done, I agree that RPL must provide mechanism(s) enabling to cope with asymmetric links as a non-rare case (isn't it one of the requirements of RPL?) =20 Now getting into the details - can the WG at least provide some feedback on whether such mechanisms are supported by RPL in all major modes and topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)? =20 Best regards, Yoav =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: Thursday, December 16, 2010 6:01 PM To: 'Pascal Thubert (pthubert)'; 'Philip Levis' Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I think we are looking at how to handle asymmetric links. We had a way to do this in previous deployments so will likely contribute a new OF that covers that function. =20 Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 7:51 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Did you consider draft-ietf-roll-minrank-hysteresis-of ? =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Thursday, December 16, 2010 4:41 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I think we are missing something other than OF0 to use. Maybe we just need a draft on this. =20 Let me see if we can't generate something in our ZigBee IP testing. For sure we won't be using OF0 and we need to specify something anyway. Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 7:05 AM To: d.sturek@att.net; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Don: =20 I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that's why OF 0 was split from RPL at some point. Please let us know if there's any claim (left?) that OF0 is the default OF for RPL... =20 I'll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I'll just try my best to make sure that it can be used where it's needed. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Thursday, December 16, 2010 3:57 PM To: Pascal Thubert (pthubert); 'Philip Levis' Cc: 'ROLL WG' Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Hi Pascal, =20 Correct, there is no point in preventing the use of RPL in wired networks. =20 That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause. Don =20 =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, December 16, 2010 6:53 AM To: Don Sturek; Philip Levis Cc: ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 Don: =20 I listed a number of examples and none of them is PLC actually.=20 RPL is a routing protocol. There is no point in preventing its usage on wired lines. =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Wednesday, December 15, 2010 5:53 PM To: Pascal Thubert (pthubert); Philip Levis Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt =20 I have never quite understood the use for RPL in wired networks. All of the PLC solutions I have looked at would not benefit at all by RPL. The main use case is wireless where asymmetric links are a major problem. It is difficult to understand the logic below in light of this inconsistency. Don =20 ________________________________ From: Pascal Thubert (pthubert) To: Philip Levis Cc: ROLL WG Sent: Wed, December 15, 2010 3:06:00 AM Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Phil: > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. We're in a loop here. This need that you describe mostly comes from propagation issues encountered in wireless networks. The whole point is that not all LLNs are wireless. Administrative cost is both usual and proven on wires. Also there are wireless emulations around that provide an acceptable service and heavily deployed service, both P2P like military and satellite radios and transit, the most common being WIFI.=20 This is clearly not your world, but the fact is that we have had happy customers for over 10 years, using Spanning Tree or similar over wireless bridges. I'd assert that RPL provides a lot more than STP, if only because: - we have the IPv6 hop limit and the RPL reactive loop detection thus no risk of meltdown - we build DAGs as opposed to trees If we can't converge on that, let's keep the discussion at wired links for a minute. In that case, RPL can often be used the way any other IGP is used today, can't it? Then again, we can derive from RPL's properties that it can actually be preferable over existing protocols at least for certain applications, because it can be both simpler and faster to set up. Such applications include: - corporate VPN (with branch and SOHO, typical recursive ) - ad hoc networks (quickly deployable ad hoc base camps) - dynamic overlays (meshes of tunnels serving small groups with short term purposes) > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. For OF0, the expected metric is an administrative cost that is trivially added up along a path; the most usual thing. OF 0 was designed to be that simple. This said, I can see 2 ways for moving forward with your suggestion: 1) We describe that the metric is a static (admin) cost range 1..16 and that it is placed in the most significant octet of the rank. 2) We decide to add support for a dynamic metric. In that case, we enter the discussion on stability, statistical dampening, and hysteresis. And obviously option 3 being both. I can easily accommodate 1) and republish. Text on 2) would have to be very vague, like a set of recommendation. =20 I do not mind either way, both are probably useful. What does the group think? On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd rather expose the statistical aspect of a metric than resort to hysteresis. For all I know, this is also something that was successfully tried on OLSR, but that is not available in the RPL metrics draft. : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, December 14, 2010 7:34 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > Apparently I missed a mail. OF 04 fails to address your concerns. So I > > digged into the WG list and found this: > > > > " > > My major concern with OF0 is actually quite different: it does not say > > how to compute Rank from metrics. Back in the discussions on MRHOF, > > this emerged as a requirement for an OF, when we separated OFs from > metrics. > > Right now, it seems like I could have an OF0 that computes Rank from > > latency, or throughput. Since the computation of Rank is very poorly > > defined, it seems very easy to have two incompatible OF0 > > implementations that work at cross purposes. > > > > For OF0 to be ready to be an RFC, it must actually provide some > > details on how metrics are converted to Rank. Take a look at the April > > discussion entitled "Decoupling Metrics and OF." > > " > > > > OF0 does not use say how to metrics. It is a weighted hop count for > > use in wire and wire emulation. I agree that the weight could be > > static or dynamic, but the design point is specifically not to discuss > > the computation of dynamic weights in OF0. This would be opening the > > Pandora box of the general RPL metrics and OF discussion, which is > > addressed elsewhere and in lot more text than needed here. So if we > > take the weight as a given, hopefully stable enough scalar, then the > > rank computation is the most classical addition of weighted hops. >=20 > But the consensus, when discussing MRHOF, is that an objective function > specification needs to say how to handle and use metrics. It seems strange > that OF0 doesn't. Or does OF0 have a special status, that it does not have to > follow the requirements laid out for objective function specifications? >=20 > Otherwise you can have independent implementations which are > incompatible and cause problems: this was due to JP's insistence that > objective functions remain metric-independent. What worries me about this > is that it seems to just blindly repeat mistakes that LLN protocols have > learned from. E.g., modern OLSR deployments do not adhere to the OLSR > specification because it requires hopcount and hopcount does not work very > well. You're right, there's lots of experience using hopcount as a metric. In > the context of LLNs, however, that experience has been negative. >=20 > > Could you please be more specific in what you'd add to the spec? >=20 > I would add a specification of how OF0 translates metrics into Rank. E.g., an > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CB9DCF.890A3848 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav.

 

Most certainly. This was actually debated at length on the very = ML.

 

For what I remember, there were 2 options:

-          = Make RPL more complex to handle a different set of parents for up and = down. This includes metrics descriptor that qualify a metric as UP or = DOWN

-          = Use 2 instances, one for traffic up (no need for DAO) and one for = traffic down.

 

My intuition is that the latter is the simpler. If by definition an = OF is an UP OF, then it will process and relay metrics that cover the UP = diecrtion.

 

What do you think?

 

 

From:= = Yoav Ben-Yehezkel [mailto:yoav@yitran.com]
Sent: Thursday, = December 16, 2010 5:47 PM
To: d.sturek@att.net; Pascal Thubert = (pthubert); Philip Levis
Cc: ROLL WG
Subject: RE: = [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi all,

 

For the record - let me shed some light on the PLC case from our = experience.

 

PLC links can definitely be asymmetric. This is due to the fact that = the main factors affecting reception are noise at the Rx side (different = at both ends), and load at Tx side (again different at both ends). =

So from both ends, there can easily be = asymmetry.

 

Without getting into the details of how this is done, I agree that = RPL must provide mechanism(s) enabling to cope with asymmetric links as = a non-rare case (isn’t it one of the requirements of = RPL?)

 

Now getting into the details – can the WG at least provide some = feedback on whether such mechanisms are supported by RPL in all major = modes and topologies (i.e. storing/non storing modes and P2MP/MP2P = topologies)?

 

Best regards,

Yoav

 

 

From:= = roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On = Behalf Of Don Sturek
Sent: Thursday, December 16, 2010 = 6:01 PM
To: 'Pascal Thubert (pthubert)'; 'Philip = Levis'
Cc: 'ROLL WG'
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I think we are looking at how to handle asymmetric links.  We = had a way to do this in previous deployments so will likely contribute a = new OF that covers that function.

 

Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Thursday, December 16, 2010 7:51 AM
To: d.sturek@att.net; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Did you consider draft-ietf-roll-minrank-hysteresis-of = ?

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: = Thursday, December 16, 2010 4:41 PM
To: Pascal Thubert = (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: = RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I think we are missing something other than OF0 to use.  Maybe = we just need a draft on this.

 

Let me see if we can’t generate something in our ZigBee IP = testing.  For sure we won’t be using OF0 and we need to = specify something anyway.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Thursday, December 16, 2010 7:05 AM
To: d.sturek@att.net; Philip = Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that’s why OF 0 was split from RPL at some point. Please let us = know if there’s any claim (left?) that OF0 is the default OF for = RPL…

 

I’ll abstain to make any prediction as of where RPL will be = most used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I’ll just try my best to make sure = that it can be used where it’s needed.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: = Thursday, December 16, 2010 3:57 PM
To: Pascal Thubert = (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: = RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi Pascal,

 

Correct, there  is no point in preventing the use of RPL in = wired networks.

 

That said, when the default OF uses a metric that is known not to = work in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause.


Don

 

 

From:= = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Thursday, December 16, 2010 6:53 AM
To: Don = Sturek; Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] = I-D = Action:draft-ietf-roll-of0-04.txt

 

Don:

 

I listed a number of examples and none of them is PLC actually. =

RPL is a routing protocol. There is no point in preventing its usage = on wired lines.

 

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: = Wednesday, December 15, 2010 5:53 PM
To: Pascal Thubert = (pthubert); Philip Levis
Cc: ROLL WG
Subject: Re: = [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for = RPL in wired networks.  All of the PLC solutions I have looked at = would not benefit at all by RPL.  The main use case is wireless = where asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

From:= = Pascal Thubert (pthubert) <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>
Cc:= ROLL WG <roll@ietf.org>
Sent: Wed, = December 15, 2010 3:06:00 AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi = Phil:


> learned from. E.g., modern OLSR deployments do not = adhere to the OLSR
> specification because it requires hopcount = and hopcount does not work
very
> well. You're right, there's = lots of experience using hopcount as a
metric. In
> the context = of LLNs, however, that experience has been negative.

We're in a = loop here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI.
This is clearly not your world, but the fact is that we have = had happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  =

I do not mind either way, both are probably useful. What does = the group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> = Sent: Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
>
>
> On Dec 13, = 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote:
>
> = > Hi Phil:
> >
> > Apparently I missed a mail. OF = 04 fails to address your concerns. So
I
> > digged into the = WG list and found this:
> >
> > "
> > My = major concern with OF0 is actually quite different: it does = not
say
> > how to compute Rank from metrics. Back in the = discussions on MRHOF,
> > this emerged as a requirement for an = OF, when we separated OFs from
> metrics.
> > Right now, = it seems like I could have an OF0 that computes Rank from
> > = latency, or throughput. Since the computation of Rank is very = poorly
> > defined, it seems very easy to have two incompatible = OF0
> > implementations that work at cross purposes.
> = >
> > For OF0 to be ready to be an RFC, it must actually = provide some
> > details on how metrics are converted to Rank. = Take a look at the
April
> > discussion entitled = "Decoupling Metrics and OF."
> > "
> = >
> > OF0 does not use say how to metrics. It is a weighted = hop count for
> > use in wire and wire emulation. I agree that = the weight could be
> > static or dynamic, but the design point = is specifically not to
discuss
> > the computation of = dynamic weights in OF0. This would be opening the
> > Pandora = box of the general RPL metrics and OF discussion, which is
> > = addressed elsewhere and in lot more text than needed here. So if = we
> > take the weight as a given, hopefully stable enough = scalar, then the
> > rank computation is the most classical = addition of weighted hops.
>
> But the consensus, when = discussing MRHOF, is that an objective
function
> specification = needs to say how to handle and use metrics. It seems
strange
> = that OF0 doesn't. Or does OF0 have a special status, that it does = not
have to
> follow the requirements laid out for objective = function
specifications?
>
> Otherwise you can have = independent implementations which are
> incompatible and cause = problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
>
> > Could you please be more specific in = what you'd add to the spec?
>
> I would add a specification = of how OF0 translates metrics into Rank.
E.g., an
> ETX between = 1 and 3 adds 1 to Rank, etc.
>
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CB9DCF.890A3848-- From pal@cs.stanford.edu Fri Dec 17 13:29: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 E59473A6C2A for ; Fri, 17 Dec 2010 13:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C-esqfCqhPY for ; Fri, 17 Dec 2010 13:29:07 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0F3923A6C1D for ; Fri, 17 Dec 2010 13:29:07 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PTht8-0004qb-Ix; Fri, 17 Dec 2010 13:30:54 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> Date: Fri, 17 Dec 2010 13:30:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:29:08 -0000 On Dec 15, 2010, at 3:06 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 >=20 >> learned from. E.g., modern OLSR deployments do not adhere to the OLSR >> specification because it requires hopcount and hopcount does not work > very >> well. You're right, there's lots of experience using hopcount as a > metric. In >> the context of LLNs, however, that experience has been negative. >=20 > We're in a loop here. This need that you describe mostly comes from > propagation issues encountered in wireless networks. > The whole point is that not all LLNs are wireless. Administrative cost > is both usual and proven on wires. I'm confused -- ROLL is chartered to work on low-power and lossy = networks. What you're describing seems to be outside that scope? > Also there are wireless emulations around that provide an acceptable > service and heavily deployed service, both P2P like military and > satellite radios and transit, the most common being WIFI.=20 Wait -- are you asserting that WiFi has reliability and behavior = equivalent to a wired network? > This is clearly not your world, but the fact is that we have had happy > customers for over 10 years, using Spanning Tree or similar over > wireless bridges. Can you point me at some concrete examples? I'm not sure I understand = the logic: because hopcount has been OK for wireless bridges, we can = ignore the fact that it's been a problem in LLNs? I thought RPL is for = LLNs. >=20 >> I would add a specification of how OF0 translates metrics into Rank. > E.g., an >> ETX between 1 and 3 adds 1 to Rank, etc. >=20 > For OF0, the expected metric is an administrative cost that is = trivially > added up along a path; the most usual thing. > OF 0 was designed to be that simple. This said, I can see 2 ways for > moving forward with your suggestion: >=20 > 1) We describe that the metric is a static (admin) cost range 1..16 = and > that it is placed in the most significant octet of the rank. >=20 > 2) We decide to add support for a dynamic metric. In that case, we = enter > the discussion on stability, statistical dampening, and hysteresis. >=20 > And obviously option 3 being both. >=20 > I can easily accommodate 1) and republish. Text on 2) would have to be > very vague, like a set of recommendation. =20 >=20 > I do not mind either way, both are probably useful. What does the = group > think? I feel like you're ignoring the original comment. Let's try to separate = my two concerns. The first is that the OF0 draft does not follow the = guidelines the WG agreed on for objective functions: this is a process = issue. The second is what I believe is a technical issue, that OF0 seems = like it does not meet a standard of technical excellence. For the first issue -- when MRHOF came up for discussion, we (as a WG) = agreed that objective functions should be metric-independent. To ensure = interoperability of different OF implementations, this means an OF needs = to specify with reasonable (but not complete) detail how it processes a = metric container. It sounds like your answer is that OF0 ignores a = metric container. This seems like a completely reasonable specification = in terms of process, given the expectations laid out for OFs.=20 The second issue I guess we can disagree on. Maybe it would be helpful = if you could sketch a concrete RPL scenario -- maybe from one of the = application drafts -- where OF0 would be a good solution? That might = help ground this discussion. Phil= From pal@cs.stanford.edu Fri Dec 17 13:30: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 C6FB23A6C2A for ; Fri, 17 Dec 2010 13:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OMdynnYwSjJ for ; Fri, 17 Dec 2010 13:30:26 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 26B3C3A6C1D for ; Fri, 17 Dec 2010 13:30:26 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PThuP-0004tK-Pz; Fri, 17 Dec 2010 13:32:14 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> Date: Fri, 17 Dec 2010 13:32:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:30:26 -0000 On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: > Don: > =20 > I listed a number of examples and none of them is PLC actually. > RPL is a routing protocol. There is no point in preventing its usage = on wired lines. >=20 https://datatracker.ietf.org/wg/roll/charter/: The Working Group is focused on routing issues for LLN. Can you give me an example of a wired network that's an LLN where OF0 is = useful? Phil= From dat@exegin.com Fri Dec 17 14:38: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 BC7DC3A6911; Fri, 17 Dec 2010 14:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGouiXXJOK88; Fri, 17 Dec 2010 14:38:43 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BBA053A69B8; Fri, 17 Dec 2010 14:38:42 -0800 (PST) Received: by qwg5 with SMTP id 5so1223649qwg.31 for ; Fri, 17 Dec 2010 14:40:30 -0800 (PST) Received: by 10.224.11.79 with SMTP id s15mr1386294qas.2.1292625630161; Fri, 17 Dec 2010 14:40:30 -0800 (PST) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id m14sm473333qcu.32.2010.12.17.14.40.28 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 14:40:29 -0800 (PST) Message-ID: <4D0BE6D8.1020301@exegin.com> Date: Fri, 17 Dec 2010 14:40:24 -0800 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20101215230001.30256.8767.idtracker@localhost> In-Reply-To: <20101215230001.30256.8767.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------070008050702020002060609" Cc: roll@ietf.org, i-d-announce@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 22:38:46 -0000 This is a multi-part message in MIME format. --------------070008050702020002060609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There seems to be a discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01: The following pseudo code in the RPL RH draft: else if i< n and Address[i] is not on-link { send an ICMP Destination Unreachable, Code 7, message to <--*** the Source Address and discard the packet } else { swap the IPv6 Destination Address and Address[i] <--*** if the IPv6 Hop Limit is less than or equal to 1 { send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet } does not correlate with the following wording in the RPL draft (section 11.2.2.3): .... .... The "Error in Source Routing Header" message has the same format as the "Destination Unreachable Message" as specified in [RFC4443]. The portion of the invoking packet that is sent back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node so that the destination in the IPv6 header is the next hop that this node could <--*** not reach. Dario On 15/12/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-17.txt > Pages : 159 > Date : 2010-12-15 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------070008050702020002060609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There seems to be a discrepancy between draft-ietf-roll-rpl-17 and draft-ietf-6man-rpl-routing-header-01:

The following pseudo code in the RPL RH draft:

          else if i < n and Address[i] is not on-link {
             send an ICMP Destination Unreachable, Code 7, message to	<--***
             the Source Address and discard the packet
          }
          else {
             swap the IPv6 Destination Address and Address[i]	<--***

             if the IPv6 Hop Limit is less than or equal to 1 {
                send an ICMP Time Exceeded -- Hop Limit Exceeded in
                Transit message to the Source Address and discard the
                packet
             }

does not correlate with the following wording in the RPL draft (section 11.2.2.3):

 ....                 .... The "Error in Source Routing Header" message has the
same format as the "Destination Unreachable Message" as specified in
[RFC4443].  The portion of the invoking packet that is sent back in
the ICMP message should record at least up to the routing header, and
the routing header should be consumed by this node so that the
destination in the IPv6 header is the next hop that this node could  <--***
not reach.


Dario


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


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

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

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

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

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


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

--------------070008050702020002060609-- From c.chauvenet@watteco.com Fri Dec 17 14:40: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 39D2F3A69ED for ; Fri, 17 Dec 2010 14:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkii7pnDzoUO for ; Fri, 17 Dec 2010 14:40:56 -0800 (PST) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 0E99D3A69B8 for ; Fri, 17 Dec 2010 14:40:55 -0800 (PST) Received: from [192.168.0.6] ([78.232.65.23]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id ZIH89139; Fri, 17 Dec 2010 23:42:39 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-737178372 From: =?iso-8859-1?Q?Chauvenet_C=E9dric?= In-Reply-To: Date: Fri, 17 Dec 2010 10:09:50 +0100 Message-Id: <70BC70DF-359D-49F5-9C7C-B7E07B67607D@watteco.com> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <008d01cb9d31$70655ac0$51301040$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704037@XMB-AMS-107.cisco.com> <00c401cb9d37$95618730$c0249590$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D03704089@XMB-AMS-107.cisco.com> <00ea01cb9d3a$63c68650$2b5392f0$@sturek@att.net> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1082) Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 22:40:59 -0000 --Apple-Mail-4-737178372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all,=20 Our PLC experience also highlight the nature of asymmetric links in PLC = networks. PLC in general cannot be considered as a broadcast media like ethernet. RPL enable to face routing challenges for LLNs, which are not a wireless = monoploly, and asymmetric links are definitely a part of it. I remember a previous mail thread about this topic on this ML, but can't = find back if there were a conclusion on it. Best, C=E9dric Le 16 d=E9c. 2010 =E0 17:46, Yoav Ben-Yehezkel a =E9crit : > Hi all, > =20 > For the record - let me shed some light on the PLC case from our = experience. > =20 > PLC links can definitely be asymmetric. This is due to the fact that = the main factors affecting reception are noise at the Rx side (different = at both ends), and load at Tx side (again different at both ends). > So from both ends, there can easily be asymmetry. > =20 > Without getting into the details of how this is done, I agree that RPL = must provide mechanism(s) enabling to cope with asymmetric links as a = non-rare case (isn=92t it one of the requirements of RPL?) > =20 > Now getting into the details =96 can the WG at least provide some = feedback on whether such mechanisms are supported by RPL in all major = modes and topologies (i.e. storing/non storing modes and P2MP/MP2P = topologies)? > =20 > Best regards, > Yoav > =20 > =20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Don Sturek > Sent: Thursday, December 16, 2010 6:01 PM > To: 'Pascal Thubert (pthubert)'; 'Philip Levis' > Cc: 'ROLL WG' > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > I think we are looking at how to handle asymmetric links. We had a = way to do this in previous deployments so will likely contribute a new = OF that covers that function. > =20 > Don > =20 > =20 > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Thursday, December 16, 2010 7:51 AM > To: d.sturek@att.net; Philip Levis > Cc: ROLL WG > Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > Did you consider draft-ietf-roll-minrank-hysteresis-of ? > =20 > Pascal > http://www.xtranormal.com/watch/7011357/ > =20 > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Thursday, December 16, 2010 4:41 PM > To: Pascal Thubert (pthubert); 'Philip Levis' > Cc: 'ROLL WG' > Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > I think we are missing something other than OF0 to use. Maybe we just = need a draft on this. > =20 > Let me see if we can=92t generate something in our ZigBee IP testing. = For sure we won=92t be using OF0 and we need to specify something = anyway. >=20 > Don > =20 > =20 > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Thursday, December 16, 2010 7:05 AM > To: d.sturek@att.net; Philip Levis > Cc: ROLL WG > Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > Don: > =20 > I think that the disconnect is your assumption that OF 0 is the = default. There is no default OF in RPL. That was discussed at length and = that=92s why OF 0 was split from RPL at some point. Please let us know = if there=92s any claim (left?) that OF0 is the default OF for RPL=85 > =20 > I=92ll abstain to make any prediction as of where RPL will be most = used (or useful). We got rid of having to make that assumption by = allowing OF to extend the base protocol in the first place. This was = actually a key design point. I=92ll just try my best to make sure that = it can be used where it=92s needed. > =20 > Pascal > http://www.xtranormal.com/watch/7011357/ > =20 > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Thursday, December 16, 2010 3:57 PM > To: Pascal Thubert (pthubert); 'Philip Levis' > Cc: 'ROLL WG' > Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > Hi Pascal, > =20 > Correct, there is no point in preventing the use of RPL in wired = networks. > =20 > That said, when the default OF uses a metric that is known not to work = in wireless networks (where I will claim RPL is more likely to be = deployed) then citing the successful deployment of the same OF in wired = networks does not help the cause. >=20 > Don > =20 > =20 > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Thursday, December 16, 2010 6:53 AM > To: Don Sturek; Philip Levis > Cc: ROLL WG > Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > Don: > =20 > I listed a number of examples and none of them is PLC actually. > RPL is a routing protocol. There is no point in preventing its usage = on wired lines. > =20 > Pascal > http://www.xtranormal.com/watch/7011357/ > =20 > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Wednesday, December 15, 2010 5:53 PM > To: Pascal Thubert (pthubert); Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > =20 > I have never quite understood the use for RPL in wired networks. All = of the PLC solutions I have looked at would not benefit at all by RPL. = The main use case is wireless where asymmetric links are a major = problem. It is difficult to understand the logic below in light of this = inconsistency. >=20 > Don >=20 > =20 > From: Pascal Thubert (pthubert) > To: Philip Levis > Cc: ROLL WG > Sent: Wed, December 15, 2010 3:06:00 AM > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > Hi Phil: >=20 >=20 > > learned from. E.g., modern OLSR deployments do not adhere to the = OLSR > > specification because it requires hopcount and hopcount does not = work > very > > well. You're right, there's lots of experience using hopcount as a > metric. In > > the context of LLNs, however, that experience has been negative. >=20 > We're in a loop here. This need that you describe mostly comes from > propagation issues encountered in wireless networks. > The whole point is that not all LLNs are wireless. Administrative cost > is both usual and proven on wires. >=20 > Also there are wireless emulations around that provide an acceptable > service and heavily deployed service, both P2P like military and > satellite radios and transit, the most common being WIFI.=20 > This is clearly not your world, but the fact is that we have had happy > customers for over 10 years, using Spanning Tree or similar over > wireless bridges. >=20 > I'd assert that RPL provides a lot more than STP, if only because: > - we have the IPv6 hop limit and the RPL reactive loop detection thus = no > risk of meltdown > - we build DAGs as opposed to trees >=20 > If we can't converge on that, let's keep the discussion at wired links > for a minute. In that case, RPL can often be used the way any other = IGP > is used today, can't it? > Then again, we can derive from RPL's properties that it can actually = be > preferable over existing protocols at least for certain applications, > because it can be both simpler and faster to set up. > Such applications include: >=20 > - corporate VPN (with branch and SOHO, typical recursive ) > - ad hoc networks (quickly deployable ad hoc base camps) > - dynamic overlays (meshes of tunnels serving small groups with short > term purposes) >=20 > > I would add a specification of how OF0 translates metrics into Rank. > E.g., an > > ETX between 1 and 3 adds 1 to Rank, etc. >=20 > For OF0, the expected metric is an administrative cost that is = trivially > added up along a path; the most usual thing. > OF 0 was designed to be that simple. This said, I can see 2 ways for > moving forward with your suggestion: >=20 > 1) We describe that the metric is a static (admin) cost range 1..16 = and > that it is placed in the most significant octet of the rank. >=20 > 2) We decide to add support for a dynamic metric. In that case, we = enter > the discussion on stability, statistical dampening, and hysteresis. >=20 > And obviously option 3 being both. >=20 > I can easily accommodate 1) and republish. Text on 2) would have to be > very vague, like a set of recommendation. =20 >=20 > I do not mind either way, both are probably useful. What does the = group > think? >=20 > On the side, if you dig patent 7,567,577 at USPTO, you'll find that = I'd > rather expose the statistical aspect of a metric than resort to > hysteresis. > For all I know, this is also something that was successfully tried on > OLSR, but that is not available in the RPL metrics draft. >=20 > : ) > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > > -----Original Message----- > > From: Philip Levis [mailto:pal@cs.stanford.edu] > > Sent: Tuesday, December 14, 2010 7:34 PM > > To: Pascal Thubert (pthubert) > > Cc: ROLL WG > > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >=20 > >=20 > > On Dec 13, 2010, at 12:18 AM, Pascal Thubert (pthubert) wrote: > >=20 > > > Hi Phil: > > > > > > Apparently I missed a mail. OF 04 fails to address your concerns. = So > I > > > digged into the WG list and found this: > > > > > > " > > > My major concern with OF0 is actually quite different: it does not > say > > > how to compute Rank from metrics. Back in the discussions on = MRHOF, > > > this emerged as a requirement for an OF, when we separated OFs = from > > metrics. > > > Right now, it seems like I could have an OF0 that computes Rank = from > > > latency, or throughput. Since the computation of Rank is very = poorly > > > defined, it seems very easy to have two incompatible OF0 > > > implementations that work at cross purposes. > > > > > > For OF0 to be ready to be an RFC, it must actually provide some > > > details on how metrics are converted to Rank. Take a look at the > April > > > discussion entitled "Decoupling Metrics and OF." > > > " > > > > > > OF0 does not use say how to metrics. It is a weighted hop count = for > > > use in wire and wire emulation. I agree that the weight could be > > > static or dynamic, but the design point is specifically not to > discuss > > > the computation of dynamic weights in OF0. This would be opening = the > > > Pandora box of the general RPL metrics and OF discussion, which is > > > addressed elsewhere and in lot more text than needed here. So if = we > > > take the weight as a given, hopefully stable enough scalar, then = the > > > rank computation is the most classical addition of weighted hops. > >=20 > > But the consensus, when discussing MRHOF, is that an objective > function > > specification needs to say how to handle and use metrics. It seems > strange > > that OF0 doesn't. Or does OF0 have a special status, that it does = not > have to > > follow the requirements laid out for objective function > specifications? > >=20 > > Otherwise you can have independent implementations which are > > incompatible and cause problems: this was due to JP's insistence = that > > objective functions remain metric-independent. What worries me about > this > > is that it seems to just blindly repeat mistakes that LLN protocols > have > > learned from. E.g., modern OLSR deployments do not adhere to the = OLSR > > specification because it requires hopcount and hopcount does not = work > very > > well. You're right, there's lots of experience using hopcount as a > metric. In > > the context of LLNs, however, that experience has been negative. > >=20 > > > Could you please be more specific in what you'd add to the spec? > >=20 > > I would add a specification of how OF0 translates metrics into Rank. > E.g., an > > ETX between 1 and 3 adds 1 to Rank, etc. > >=20 > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-4-737178372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi all, 

Our PLC experience = also highlight the nature of asymmetric links in PLC = networks.

PLC in general cannot be considered = as a broadcast media like ethernet.

RPL enable = to face routing challenges for LLNs, which are not a wireless monoploly, = and asymmetric links are definitely a part of = it.

I remember a previous mail thread about = this topic on this ML, but can't find back if there were a conclusion on = it.

Best,
C=E9dric

<= div>Le 16 d=E9c. 2010 =E0 17:46, Yoav Ben-Yehezkel a =E9crit :

Hi = all,

For the record - let me = shed some light on the PLC case from our experience.

 

PLC links can definitely be = asymmetric. This is due to the fact that the main factors affecting reception = are noise at the Rx side (different at both ends), and load at Tx side = (again different at both ends).
So from both ends, there can easily be = asymmetry.

Without getting into the = details of how this is done, I agree that RPL must provide mechanism(s) enabling = to cope with asymmetric links as a non-rare case (isn=92t it one of the = requirements of RPL?)

 

Now getting into the details =96 = can the WG at least provide some feedback on whether such mechanisms are = supported by RPL in all major modes and topologies (i.e. storing/non = storing modes and P2MP/MP2P topologies)?

 

Best regards,
Yoav

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don = Sturek
Sent: Thursday, December 16, 2010 = 6:01 PM
To: 'Pascal Thubert = (pthubert)'; 'Philip Levis'
Cc: 'ROLL = WG'
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I = think we are looking at how to handle asymmetric links.  We had a = way to do this in previous deployments so will likely contribute a new = OF that covers that function.

 

Don

 

From: Pascal Thubert (pthubert) = [mailto:pthubert@cisco.com] 
Sent: Thursday, December 16, 2010 = 7:51 AM
To: d.sturek@att.net; Philip Levis
Cc: ROLL = WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Did = you consider draft-ietf-roll-minrank-hysteresis-of ?

 

From: Don Sturek [mailto:d.sturek@att.net] 
Sent: Thursday, December 16, 2010 = 4:41 PM
To: Pascal Thubert (pthubert); = 'Philip Levis'
Cc: 'ROLL = WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I = think we are missing something other than OF0 to use.  Maybe we = just need a draft on this.

 

Let me see if we can=92t generate = something in our ZigBee IP testing.  For sure we won=92t be using = OF0 and we need to specify something anyway.

Don

 

From: Pascal Thubert (pthubert) = [mailto:pthubert@cisco.com] 
Sent: Thursday, December 16, 2010 = 7:05 AM
To: d.sturek@att.net; Philip Levis
Cc: ROLL = WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I think that the = disconnect is your assumption that OF 0 is the default. There is no = default OF in RPL. That was discussed at length and that=92s why OF 0 = was split from RPL at some point. Please let us know if there=92s any = claim (left?) that OF0 is the default OF for RPL=85

 

I=92ll abstain to make any = prediction as of where RPL will be most used (or useful). We got rid of = having to make that assumption by allowing OF to extend the base = protocol in the first place. This was actually a key design point. I=92ll = just try my best to make sure that it can be used where it=92s = needed.

 

From: Don Sturek [mailto:d.sturek@att.net] 
Sent: Thursday, December 16, 2010 = 3:57 PM
To: Pascal Thubert (pthubert); = 'Philip Levis'
Cc: 'ROLL = WG'
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

Hi = Pascal,

Correct, there  is = no point in preventing the use of RPL in wired networks.

 

That said, when the default OF = uses a metric that is known not to work in wireless networks (where I = will claim RPL is more likely to be deployed) then citing the successful = deployment of the same OF in wired networks does not help the = cause.

Don

 

From: Pascal Thubert (pthubert) = [mailto:pthubert@cisco.com] 
Sent: Thursday, December 16, 2010 = 6:53 AM
To: Don Sturek; Philip = Levis
Cc: ROLL= WG
Subject: RE: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I listed a number of = examples and none of them is PLC actually.
RPL is a routing protocol. There = is no point in preventing its usage on wired lines.

 

From: Don Sturek [mailto:d.sturek@att.net] 
Sent: Wednesday, December 15, = 2010 5:53 PM
To: Pascal Thubert (pthubert); = Philip Levis
Cc: ROLL = WG
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

 

I have never quite understood the use for RPL in wired = networks.  All of the PLC solutions I have looked at would not = benefit at all by RPL.  The main use case is wireless where = asymmetric links are a major problem.  It is difficult to = understand the logic below in light of this = inconsistency.

Don

 

 Pascal = Thubert (pthubert) < Philip Levis < ROLL WG <roll@ietf.org>
Sent: Wed, December 15, 2010 = 3:06:00 AM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt

Hi Phil:


> = learned from. E.g., modern OLSR deployments do not adhere to the = OLSR
> specification because it requires hopcount and hopcount = does not work
very
> well. You're right, there's lots of = experience using hopcount as a
metric. In
> the context of = LLNs, however, that experience has been negative.

We're in a loop = here. This need that you describe mostly comes from
propagation = issues encountered in wireless networks.
The whole point is that not = all LLNs are wireless. Administrative cost
is both usual and proven = on wires.

Also there are wireless emulations around that provide = an acceptable
service and heavily deployed service, both P2P like = military and
satellite radios and transit, the most common being = WIFI. 
This is = clearly not your world, but the fact is that we have had = happy
customers  for over 10 years, using Spanning Tree or = similar over
wireless bridges.

I'd assert that RPL provides a = lot more than STP, if only because:
- we have the IPv6 hop limit and = the RPL reactive loop detection thus no
risk of meltdown
- we = build DAGs as opposed to trees

If we can't converge on that, = let's keep the discussion at wired links
for a minute. In that case, = RPL can often be used the way any other IGP
is used today, can't = it?
Then again, we can derive from RPL's properties that it can = actually be
preferable over existing protocols at least for certain = applications,
because it can be both simpler and faster to set = up.
Such applications include:

- corporate VPN (with branch = and SOHO, typical recursive )
- ad hoc networks (quickly deployable = ad hoc base camps)
- dynamic overlays (meshes of tunnels serving = small groups with short
term purposes)

> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the = expected metric is an administrative cost that is trivially
added up = along a path; the most usual thing.
OF 0 was designed to be that = simple.  This said, I can see 2 ways for
moving forward with = your suggestion:

1) We describe that the metric is a static = (admin) cost range 1..16 and
that it is placed in the most = significant octet of the rank.

2) We decide to add support for a = dynamic metric. In that case, we enter
the discussion on stability, = statistical dampening, and hysteresis.

And obviously option 3 = being both.

I can easily accommodate 1) and republish. Text on 2) = would have to be
very vague, like a set of recommendation.  

I do not mind = either way, both are probably useful. What does the = group
think?

On the side, if you dig patent 7,567,577 at = USPTO, you'll find that I'd
rather expose the statistical aspect = of  a metric than resort to
hysteresis.
For all I know, this = is also something that was successfully tried on
OLSR, but that is = not available in the RPL metrics draft.

:  )
Pascal
pal@cs.stanford.edu]
> Sent: = Tuesday, December 14, 2010 7:34 PM
> To: Pascal Thubert = (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D = Action:draft-ietf-roll-of0-04.txt
> 
> 
> On Dec 13, 2010, = at 12:18 AM, Pascal Thubert (pthubert) wrote:
> 
> > Hi = Phil:
> >
> > Apparently I missed a mail. OF 04 fails = to address your concerns. So
I
> > digged into the WG list = and found this:
> >
> > "
> > My major = concern with OF0 is actually quite different: it does not
say
> = > how to compute Rank from metrics. Back in the discussions on = MRHOF,
> > this emerged as a requirement for an OF, when we = separated OFs from
> metrics.
> > Right now, it seems = like I could have an OF0 that computes Rank from
> > latency, = or throughput. Since the computation of Rank is very poorly
> > = defined, it seems very easy to have two incompatible OF0
> > = implementations that work at cross purposes.
> >
> > = For OF0 to be ready to be an RFC, it must actually provide some
> = > details on how metrics are converted to Rank. Take a look at = the
April
> > discussion entitled "Decoupling Metrics and = OF."
> > "
> >
> > OF0 does not use say how = to metrics. It is a weighted hop count for
> > use in wire and = wire emulation. I agree that the weight could be
> > static or = dynamic, but the design point is specifically not to
discuss
> = > the computation of dynamic weights in OF0. This would be opening = the
> > Pandora box of the general RPL metrics and OF = discussion, which is
> > addressed elsewhere and in lot more = text than needed here. So if we
> > take the weight as a given, = hopefully stable enough scalar, then the
> > rank computation = is the most classical addition of weighted hops.
> 
> But the consensus, = when discussing MRHOF, is that an objective
function
> = specification needs to say how to handle and use metrics. It = seems
strange
> that OF0 doesn't. Or does OF0 have a special = status, that it does not
have to
> follow the requirements laid = out for objective function
specifications?
> 
> Otherwise you can = have independent implementations which are
> incompatible and = cause problems: this was due to JP's insistence that
> objective = functions remain metric-independent. What worries me = about
this
> is that it seems to just blindly repeat mistakes = that LLN protocols
have
> learned from. E.g., modern OLSR = deployments do not adhere to the OLSR
> specification because it = requires hopcount and hopcount does not work
very
> well. = You're right, there's lots of experience using hopcount as a
metric. = In
> the context of LLNs, however, that experience has been = negative.
> 
> > Could you = please be more specific in what you'd add to the spec?
> 
> I would add a = specification of how OF0 translates metrics into Rank.
E.g., = an
> ETX between 1 and 3 adds 1 to Rank, etc.
> 
> = Phil
_______________________________________________
Roll mailing = list
Roll@ietf.org
In-Reply-To: <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueMeC8wCMe61D+RFK/AmhrcMzl/gAfE+CA References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 18 Dec 2010 12:38:55.0160 (UTC) FILETIME=[887E4380:01CB9EB0] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 12:37:09 -0000 Again you've got your logic reversed. RPL was designed for LLNs, does not mean that it has to be limited to anything as long as it works fine there too.=20 Second you'll find more and more low power / constrained devices in both wired and wireless space, because as a trend we are controlling more and wasting less. Third, RPL by construction is a good routing protocol for certain topologies that are inherently based on hub and spoke. I listed a number in this thread already. Think dynamic overlays like VPNs for one. Finally, OF0 may apply to asymmetric links if people are willing to run 2 DAGs, one for the traffic up and one for the traffic down. Mixing problems is a source of confusion. =20 Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Friday, December 17, 2010 10:32 PM > To: Pascal Thubert (pthubert) > Cc: Don Sturek; ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 >=20 > On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >=20 > > Don: > > > > I listed a number of examples and none of them is PLC actually. > > RPL is a routing protocol. There is no point in preventing its usage on wired > lines. > > >=20 > https://datatracker.ietf.org/wg/roll/charter/: >=20 > The Working Group is focused on routing issues for LLN. >=20 > Can you give me an example of a wired network that's an LLN where OF0 is > useful? >=20 > Phil From jvasseur@cisco.com Sat Dec 18 05:02: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 1A32C3A69FF for ; Sat, 18 Dec 2010 05:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.858 X-Spam-Level: X-Spam-Status: No, score=-8.858 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chUBh+4kttbO for ; Sat, 18 Dec 2010 05:02:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C4FD43A69FE for ; Sat, 18 Dec 2010 05:02:44 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFABhADE2tJV2b/2dsb2JhbACCF4FNn3Bgc6F0ikuQOIRWdASEZYk5 X-IronPort-AV: E=Sophos;i="4.60,193,1291593600"; d="scan'208,217";a="194622898" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2010 13:04:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBID4W6V001459; Sat, 18 Dec 2010 13:04:32 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Dec 2010 07:04:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9EB4.1C6E2FA0" Date: Sat, 18 Dec 2010 07:04:31 -0600 Message-ID: In-Reply-To: <70BC70DF-359D-49F5-9C7C-B7E07B67607D@watteco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueO9YoLCC6rJx7T66oTlzEh6fJ4QAeEYmZ From: "JP Vasseur (jvasseur)" To: X-OriginalArrivalTime: 18 Dec 2010 13:04:32.0299 (UTC) FILETIME=[1CB30FB0:01CB9EB4] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 13:02:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9EB4.1C6E2FA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QWxsLCBpZiB5b3UgdGhpbmsgb2YgYSBwb3RlbnRpYWwgbmV3IFdHIGl0ZW0sIGxldCcgZGlzY3Vz IGl0IGR1cmluZyBvdXIgaW50ZXJpbSBXRyBtZWV0aW5nIG9uIE1vbmRheS4gSlAgDQpTZW50IGZy b20gU21hcnQgUGhvbmUgDQoNCkpQIFZhc3NldXIgLSBDaXNjbw0KIA0KDQpGcm9tOiBDaGF1dmVu ZXQgQ8OpZHJpYyBbbWFpbHRvOmMuY2hhdXZlbmV0QHdhdHRlY28uY29tXSANClNlbnQ6IEZyaWRh eSwgRGVjZW1iZXIgMTcsIDIwMTAgMDM6MDkgQU0NClRvOiBZb2F2IEJlbi1ZZWhlemtlbCA8eW9h dkB5aXRyYW4uY29tPiANCkNjOiBST0xMIFdHIDxyb2xsQGlldGYub3JnPiANClN1YmplY3Q6IFJl OiBbUm9sbF0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXJvbGwtb2YwLTA0LnR4dCANCiANCg0KSGkg YWxsLCANCg0KT3VyIFBMQyBleHBlcmllbmNlIGFsc28gaGlnaGxpZ2h0IHRoZSBuYXR1cmUgb2Yg YXN5bW1ldHJpYyBsaW5rcyBpbiBQTEMgbmV0d29ya3MuDQoNClBMQyBpbiBnZW5lcmFsIGNhbm5v dCBiZSBjb25zaWRlcmVkIGFzIGEgYnJvYWRjYXN0IG1lZGlhIGxpa2UgZXRoZXJuZXQuDQoNClJQ TCBlbmFibGUgdG8gZmFjZSByb3V0aW5nIGNoYWxsZW5nZXMgZm9yIExMTnMsIHdoaWNoIGFyZSBu b3QgYSB3aXJlbGVzcyBtb25vcGxvbHksIGFuZCBhc3ltbWV0cmljIGxpbmtzIGFyZSBkZWZpbml0 ZWx5IGEgcGFydCBvZiBpdC4NCg0KSSByZW1lbWJlciBhIHByZXZpb3VzIG1haWwgdGhyZWFkIGFi b3V0IHRoaXMgdG9waWMgb24gdGhpcyBNTCwgYnV0IGNhbid0IGZpbmQgYmFjayBpZiB0aGVyZSB3 ZXJlIGEgY29uY2x1c2lvbiBvbiBpdC4NCg0KQmVzdCwNCkPDqWRyaWMNCg0KTGUgMTYgZMOpYy4g MjAxMCDDoCAxNzo0NiwgWW9hdiBCZW4tWWVoZXprZWwgYSDDqWNyaXQgOg0KDQoNCgkNCglIaSBh bGwsDQoNCgkgDQoNCglGb3IgdGhlIHJlY29yZCAtIGxldCBtZSBzaGVkIHNvbWUgbGlnaHQgb24g dGhlIFBMQyBjYXNlIGZyb20gb3VyIGV4cGVyaWVuY2UuDQoNCgkgDQoNCglQTEMgbGlua3MgY2Fu IGRlZmluaXRlbHkgYmUgYXN5bW1ldHJpYy4gVGhpcyBpcyBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0 aGUgbWFpbiBmYWN0b3JzIGFmZmVjdGluZyByZWNlcHRpb24gYXJlIG5vaXNlIGF0IHRoZSBSeCBz aWRlIChkaWZmZXJlbnQgYXQgYm90aCBlbmRzKSwgYW5kIGxvYWQgYXQgVHggc2lkZSAoYWdhaW4g ZGlmZmVyZW50IGF0IGJvdGggZW5kcykuDQoJU28gZnJvbSBib3RoIGVuZHMsIHRoZXJlIGNhbiBl YXNpbHkgYmUgYXN5bW1ldHJ5Lg0KDQoJIA0KDQoJV2l0aG91dCBnZXR0aW5nIGludG8gdGhlIGRl dGFpbHMgb2YgaG93IHRoaXMgaXMgZG9uZSwgSSBhZ3JlZSB0aGF0IFJQTCBtdXN0IHByb3ZpZGUg bWVjaGFuaXNtKHMpIGVuYWJsaW5nIHRvIGNvcGUgd2l0aCBhc3ltbWV0cmljIGxpbmtzIGFzIGEg bm9uLXJhcmUgY2FzZSAoaXNuwpJ0IGl0IG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9mIFJQTD8p DQoNCgkgDQoNCglOb3cgZ2V0dGluZyBpbnRvIHRoZSBkZXRhaWxzIMKWIGNhbiB0aGUgV0cgYXQg bGVhc3QgcHJvdmlkZSBzb21lIGZlZWRiYWNrIG9uIHdoZXRoZXIgc3VjaCBtZWNoYW5pc21zIGFy ZSBzdXBwb3J0ZWQgYnkgUlBMIGluIGFsbCBtYWpvciBtb2RlcyBhbmQgdG9wb2xvZ2llcyAoaS5l LiBzdG9yaW5nL25vbiBzdG9yaW5nIG1vZGVzIGFuZCBQMk1QL01QMlAgdG9wb2xvZ2llcyk/DQoN CgkgDQoNCglCZXN0IHJlZ2FyZHMsDQoJWW9hdg0KDQoJIA0KDQoJIA0KDQoJRnJvbTogcm9sbC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRG9uIFN0dXJlaw0KCVNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNiwgMjAxMCA2OjAxIFBN DQoJVG86ICdQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpJzsgJ1BoaWxpcCBMZXZpcycNCglDYzog J1JPTEwgV0cnDQoJU3ViamVjdDogUmU6IFtSb2xsXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtcm9s bC1vZjAtMDQudHh0DQoNCgkgDQoNCglJIHRoaW5rIHdlIGFyZSBsb29raW5nIGF0IGhvdyB0byBo YW5kbGUgYXN5bW1ldHJpYyBsaW5rcy4gIFdlIGhhZCBhIHdheSB0byBkbyB0aGlzIGluIHByZXZp b3VzIGRlcGxveW1lbnRzIHNvIHdpbGwgbGlrZWx5IGNvbnRyaWJ1dGUgYSBuZXcgT0YgdGhhdCBj b3ZlcnMgdGhhdCBmdW5jdGlvbi4NCg0KCSANCg0KCURvbg0KDQoJIA0KDQoJIA0KDQoJRnJvbTog UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSBbbWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbV0gDQoJ U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE2LCAyMDEwIDc6NTEgQU0NCglUbzogZC5zdHVyZWtA YXR0Lm5ldDsgUGhpbGlwIExldmlzDQoJQ2M6IFJPTEwgV0cNCglTdWJqZWN0OiBSRTogW1JvbGxd IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQNCg0KCSANCg0KCURpZCB5b3Ug Y29uc2lkZXIgZHJhZnQtaWV0Zi1yb2xsLW1pbnJhbmstaHlzdGVyZXNpcy1vZiA/DQoNCgkgDQoN CglQYXNjYWwNCglodHRwOi8vd3d3Lnh0cmFub3JtYWwuY29tL3dhdGNoLzcwMTEzNTcvDQoNCgkg DQoNCglGcm9tOiBEb24gU3R1cmVrIFttYWlsdG86ZC5zdHVyZWtAYXR0Lm5ldF0gDQoJU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDE2LCAyMDEwIDQ6NDEgUE0NCglUbzogUGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KTsgJ1BoaWxpcCBMZXZpcycNCglDYzogJ1JPTEwgV0cnDQoJU3ViamVjdDogUkU6 IFtSb2xsXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0DQoNCgkgDQoNCglJ IHRoaW5rIHdlIGFyZSBtaXNzaW5nIHNvbWV0aGluZyBvdGhlciB0aGFuIE9GMCB0byB1c2UuICBN YXliZSB3ZSBqdXN0IG5lZWQgYSBkcmFmdCBvbiB0aGlzLg0KDQoJIA0KDQoJTGV0IG1lIHNlZSBp ZiB3ZSBjYW7CknQgZ2VuZXJhdGUgc29tZXRoaW5nIGluIG91ciBaaWdCZWUgSVAgdGVzdGluZy4g IEZvciBzdXJlIHdlIHdvbsKSdCBiZSB1c2luZyBPRjAgYW5kIHdlIG5lZWQgdG8gc3BlY2lmeSBz b21ldGhpbmcgYW55d2F5Lg0KCQ0KCURvbg0KDQoJIA0KDQoJIA0KDQoJRnJvbTogUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KSBbbWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbV0gDQoJU2VudDogVGh1 cnNkYXksIERlY2VtYmVyIDE2LCAyMDEwIDc6MDUgQU0NCglUbzogZC5zdHVyZWtAYXR0Lm5ldDsg UGhpbGlwIExldmlzDQoJQ2M6IFJPTEwgV0cNCglTdWJqZWN0OiBSRTogW1JvbGxdIEktRCBBY3Rp b246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQNCg0KCSANCg0KCURvbjoNCg0KCSANCg0KCUkg dGhpbmsgdGhhdCB0aGUgZGlzY29ubmVjdCBpcyB5b3VyIGFzc3VtcHRpb24gdGhhdCBPRiAwIGlz IHRoZSBkZWZhdWx0LiBUaGVyZSBpcyBubyBkZWZhdWx0IE9GIGluIFJQTC4gVGhhdCB3YXMgZGlz Y3Vzc2VkIGF0IGxlbmd0aCBhbmQgdGhhdMKScyB3aHkgT0YgMCB3YXMgc3BsaXQgZnJvbSBSUEwg YXQgc29tZSBwb2ludC4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlwpJzIGFueSBjbGFpbSAo bGVmdD8pIHRoYXQgT0YwIGlzIHRoZSBkZWZhdWx0IE9GIGZvciBSUEzChQ0KDQoJIA0KDQoJScKS bGwgYWJzdGFpbiB0byBtYWtlIGFueSBwcmVkaWN0aW9uIGFzIG9mIHdoZXJlIFJQTCB3aWxsIGJl IG1vc3QgdXNlZCAob3IgdXNlZnVsKS4gV2UgZ290IHJpZCBvZiBoYXZpbmcgdG8gbWFrZSB0aGF0 IGFzc3VtcHRpb24gYnkgYWxsb3dpbmcgT0YgdG8gZXh0ZW5kIHRoZSBiYXNlIHByb3RvY29sIGlu IHRoZSBmaXJzdCBwbGFjZS4gVGhpcyB3YXMgYWN0dWFsbHkgYSBrZXkgZGVzaWduIHBvaW50LiBJ wpJsbCBqdXN0IHRyeSBteSBiZXN0IHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGNhbiBiZSB1c2VkIHdo ZXJlIGl0wpJzIG5lZWRlZC4NCg0KCSANCg0KCVBhc2NhbA0KCWh0dHA6Ly93d3cueHRyYW5vcm1h bC5jb20vd2F0Y2gvNzAxMTM1Ny8NCg0KCSANCg0KCUZyb206IERvbiBTdHVyZWsgW21haWx0bzpk LnN0dXJla0BhdHQubmV0XSANCglTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTYsIDIwMTAgMzo1 NyBQTQ0KCVRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyAnUGhpbGlwIExldmlzJw0KCUNj OiAnUk9MTCBXRycNCglTdWJqZWN0OiBSRTogW1JvbGxdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1y b2xsLW9mMC0wNC50eHQNCg0KCSANCg0KCUhpIFBhc2NhbCwNCg0KCSANCg0KCUNvcnJlY3QsIHRo ZXJlICBpcyBubyBwb2ludCBpbiBwcmV2ZW50aW5nIHRoZSB1c2Ugb2YgUlBMIGluIHdpcmVkIG5l dHdvcmtzLg0KDQoJIA0KDQoJVGhhdCBzYWlkLCB3aGVuIHRoZSBkZWZhdWx0IE9GIHVzZXMgYSBt ZXRyaWMgdGhhdCBpcyBrbm93biBub3QgdG8gd29yayBpbiB3aXJlbGVzcyBuZXR3b3JrcyAod2hl cmUgSSB3aWxsIGNsYWltIFJQTCBpcyBtb3JlIGxpa2VseSB0byBiZSBkZXBsb3llZCkgdGhlbiBj aXRpbmcgdGhlIHN1Y2Nlc3NmdWwgZGVwbG95bWVudCBvZiB0aGUgc2FtZSBPRiBpbiB3aXJlZCBu ZXR3b3JrcyBkb2VzIG5vdCBoZWxwIHRoZSBjYXVzZS4NCgkNCglEb24NCg0KCSANCg0KCSANCg0K CUZyb206IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgW21haWx0bzpwdGh1YmVydEBjaXNjby5j b21dIA0KCVNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNiwgMjAxMCA2OjUzIEFNDQoJVG86IERv biBTdHVyZWs7IFBoaWxpcCBMZXZpcw0KCUNjOiBST0xMIFdHDQoJU3ViamVjdDogUkU6IFtSb2xs XSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0DQoNCgkgDQoNCglEb246DQoN CgkgDQoNCglJIGxpc3RlZCBhIG51bWJlciBvZiBleGFtcGxlcyBhbmQgbm9uZSBvZiB0aGVtIGlz IFBMQyBhY3R1YWxseS4NCglSUEwgaXMgYSByb3V0aW5nIHByb3RvY29sLiBUaGVyZSBpcyBubyBw b2ludCBpbiBwcmV2ZW50aW5nIGl0cyB1c2FnZSBvbiB3aXJlZCBsaW5lcy4NCg0KCSANCg0KCVBh c2NhbA0KCWh0dHA6Ly93d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny8NCg0KCSANCg0K CUZyb206IERvbiBTdHVyZWsgW21haWx0bzpkLnN0dXJla0BhdHQubmV0XSANCglTZW50OiBXZWRu ZXNkYXksIERlY2VtYmVyIDE1LCAyMDEwIDU6NTMgUE0NCglUbzogUGFzY2FsIFRodWJlcnQgKHB0 aHViZXJ0KTsgUGhpbGlwIExldmlzDQoJQ2M6IFJPTEwgV0cNCglTdWJqZWN0OiBSZTogW1JvbGxd IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQNCg0KCSANCg0KCUkgaGF2ZSBu ZXZlciBxdWl0ZSB1bmRlcnN0b29kIHRoZSB1c2UgZm9yIFJQTCBpbiB3aXJlZCBuZXR3b3Jrcy4g IEFsbCBvZiB0aGUgUExDIHNvbHV0aW9ucyBJIGhhdmUgbG9va2VkIGF0IHdvdWxkIG5vdCBiZW5l Zml0IGF0IGFsbCBieSBSUEwuICBUaGUgbWFpbiB1c2UgY2FzZSBpcyB3aXJlbGVzcyB3aGVyZSBh c3ltbWV0cmljIGxpbmtzIGFyZSBhIG1ham9yIHByb2JsZW0uICBJdCBpcyBkaWZmaWN1bHQgdG8g dW5kZXJzdGFuZCB0aGUgbG9naWMgYmVsb3cgaW4gbGlnaHQgb2YgdGhpcyBpbmNvbnNpc3RlbmN5 Lg0KCQ0KCURvbg0KDQoJIA0KDQoJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQoJRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0K CVRvOiBQaGlsaXAgTGV2aXMgPHBhbEBjcy5zdGFuZm9yZC5lZHU+DQoJQ2M6IFJPTEwgV0cgPHJv bGxAaWV0Zi5vcmc+DQoJU2VudDogV2VkLCBEZWNlbWJlciAxNSwgMjAxMCAzOjA2OjAwIEFNDQoJ U3ViamVjdDogUmU6IFtSb2xsXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0 DQoJDQoJSGkgUGhpbDoNCgkNCgkNCgk+IGxlYXJuZWQgZnJvbS4gRS5nLiwgbW9kZXJuIE9MU1Ig ZGVwbG95bWVudHMgZG8gbm90IGFkaGVyZSB0byB0aGUgT0xTUg0KCT4gc3BlY2lmaWNhdGlvbiBi ZWNhdXNlIGl0IHJlcXVpcmVzIGhvcGNvdW50IGFuZCBob3Bjb3VudCBkb2VzIG5vdCB3b3JrDQoJ dmVyeQ0KCT4gd2VsbC4gWW91J3JlIHJpZ2h0LCB0aGVyZSdzIGxvdHMgb2YgZXhwZXJpZW5jZSB1 c2luZyBob3Bjb3VudCBhcyBhDQoJbWV0cmljLiBJbg0KCT4gdGhlIGNvbnRleHQgb2YgTExOcywg aG93ZXZlciwgdGhhdCBleHBlcmllbmNlIGhhcyBiZWVuIG5lZ2F0aXZlLg0KCQ0KCVdlJ3JlIGlu IGEgbG9vcCBoZXJlLiBUaGlzIG5lZWQgdGhhdCB5b3UgZGVzY3JpYmUgbW9zdGx5IGNvbWVzIGZy b20NCglwcm9wYWdhdGlvbiBpc3N1ZXMgZW5jb3VudGVyZWQgaW4gd2lyZWxlc3MgbmV0d29ya3Mu DQoJVGhlIHdob2xlIHBvaW50IGlzIHRoYXQgbm90IGFsbCBMTE5zIGFyZSB3aXJlbGVzcy4gQWRt aW5pc3RyYXRpdmUgY29zdA0KCWlzIGJvdGggdXN1YWwgYW5kIHByb3ZlbiBvbiB3aXJlcy4NCgkN CglBbHNvIHRoZXJlIGFyZSB3aXJlbGVzcyBlbXVsYXRpb25zIGFyb3VuZCB0aGF0IHByb3ZpZGUg YW4gYWNjZXB0YWJsZQ0KCXNlcnZpY2UgYW5kIGhlYXZpbHkgZGVwbG95ZWQgc2VydmljZSwgYm90 aCBQMlAgbGlrZSBtaWxpdGFyeSBhbmQNCglzYXRlbGxpdGUgcmFkaW9zIGFuZCB0cmFuc2l0LCB0 aGUgbW9zdCBjb21tb24gYmVpbmcgV0lGSS4gDQoJVGhpcyBpcyBjbGVhcmx5IG5vdCB5b3VyIHdv cmxkLCBidXQgdGhlIGZhY3QgaXMgdGhhdCB3ZSBoYXZlIGhhZCBoYXBweQ0KCWN1c3RvbWVycyAg Zm9yIG92ZXIgMTAgeWVhcnMsIHVzaW5nIFNwYW5uaW5nIFRyZWUgb3Igc2ltaWxhciBvdmVyDQoJ d2lyZWxlc3MgYnJpZGdlcy4NCgkNCglJJ2QgYXNzZXJ0IHRoYXQgUlBMIHByb3ZpZGVzIGEgbG90 IG1vcmUgdGhhbiBTVFAsIGlmIG9ubHkgYmVjYXVzZToNCgktIHdlIGhhdmUgdGhlIElQdjYgaG9w IGxpbWl0IGFuZCB0aGUgUlBMIHJlYWN0aXZlIGxvb3AgZGV0ZWN0aW9uIHRodXMgbm8NCglyaXNr IG9mIG1lbHRkb3duDQoJLSB3ZSBidWlsZCBEQUdzIGFzIG9wcG9zZWQgdG8gdHJlZXMNCgkNCglJ ZiB3ZSBjYW4ndCBjb252ZXJnZSBvbiB0aGF0LCBsZXQncyBrZWVwIHRoZSBkaXNjdXNzaW9uIGF0 IHdpcmVkIGxpbmtzDQoJZm9yIGEgbWludXRlLiBJbiB0aGF0IGNhc2UsIFJQTCBjYW4gb2Z0ZW4g YmUgdXNlZCB0aGUgd2F5IGFueSBvdGhlciBJR1ANCglpcyB1c2VkIHRvZGF5LCBjYW4ndCBpdD8N CglUaGVuIGFnYWluLCB3ZSBjYW4gZGVyaXZlIGZyb20gUlBMJ3MgcHJvcGVydGllcyB0aGF0IGl0 IGNhbiBhY3R1YWxseSBiZQ0KCXByZWZlcmFibGUgb3ZlciBleGlzdGluZyBwcm90b2NvbHMgYXQg bGVhc3QgZm9yIGNlcnRhaW4gYXBwbGljYXRpb25zLA0KCWJlY2F1c2UgaXQgY2FuIGJlIGJvdGgg c2ltcGxlciBhbmQgZmFzdGVyIHRvIHNldCB1cC4NCglTdWNoIGFwcGxpY2F0aW9ucyBpbmNsdWRl Og0KCQ0KCS0gY29ycG9yYXRlIFZQTiAod2l0aCBicmFuY2ggYW5kIFNPSE8sIHR5cGljYWwgcmVj dXJzaXZlICkNCgktIGFkIGhvYyBuZXR3b3JrcyAocXVpY2tseSBkZXBsb3lhYmxlIGFkIGhvYyBi YXNlIGNhbXBzKQ0KCS0gZHluYW1pYyBvdmVybGF5cyAobWVzaGVzIG9mIHR1bm5lbHMgc2Vydmlu ZyBzbWFsbCBncm91cHMgd2l0aCBzaG9ydA0KCXRlcm0gcHVycG9zZXMpDQoJDQoJPiBJIHdvdWxk IGFkZCBhIHNwZWNpZmljYXRpb24gb2YgaG93IE9GMCB0cmFuc2xhdGVzIG1ldHJpY3MgaW50byBS YW5rLg0KCUUuZy4sIGFuDQoJPiBFVFggYmV0d2VlbiAxIGFuZCAzIGFkZHMgMSB0byBSYW5rLCBl dGMuDQoJDQoJRm9yIE9GMCwgdGhlIGV4cGVjdGVkIG1ldHJpYyBpcyBhbiBhZG1pbmlzdHJhdGl2 ZSBjb3N0IHRoYXQgaXMgdHJpdmlhbGx5DQoJYWRkZWQgdXAgYWxvbmcgYSBwYXRoOyB0aGUgbW9z dCB1c3VhbCB0aGluZy4NCglPRiAwIHdhcyBkZXNpZ25lZCB0byBiZSB0aGF0IHNpbXBsZS4gIFRo aXMgc2FpZCwgSSBjYW4gc2VlIDIgd2F5cyBmb3INCgltb3ZpbmcgZm9yd2FyZCB3aXRoIHlvdXIg c3VnZ2VzdGlvbjoNCgkNCgkxKSBXZSBkZXNjcmliZSB0aGF0IHRoZSBtZXRyaWMgaXMgYSBzdGF0 aWMgKGFkbWluKSBjb3N0IHJhbmdlIDEuLjE2IGFuZA0KCXRoYXQgaXQgaXMgcGxhY2VkIGluIHRo ZSBtb3N0IHNpZ25pZmljYW50IG9jdGV0IG9mIHRoZSByYW5rLg0KCQ0KCTIpIFdlIGRlY2lkZSB0 byBhZGQgc3VwcG9ydCBmb3IgYSBkeW5hbWljIG1ldHJpYy4gSW4gdGhhdCBjYXNlLCB3ZSBlbnRl cg0KCXRoZSBkaXNjdXNzaW9uIG9uIHN0YWJpbGl0eSwgc3RhdGlzdGljYWwgZGFtcGVuaW5nLCBh bmQgaHlzdGVyZXNpcy4NCgkNCglBbmQgb2J2aW91c2x5IG9wdGlvbiAzIGJlaW5nIGJvdGguDQoJ DQoJSSBjYW4gZWFzaWx5IGFjY29tbW9kYXRlIDEpIGFuZCByZXB1Ymxpc2guIFRleHQgb24gMikg d291bGQgaGF2ZSB0byBiZQ0KCXZlcnkgdmFndWUsIGxpa2UgYSBzZXQgb2YgcmVjb21tZW5kYXRp b24uICANCgkNCglJIGRvIG5vdCBtaW5kIGVpdGhlciB3YXksIGJvdGggYXJlIHByb2JhYmx5IHVz ZWZ1bC4gV2hhdCBkb2VzIHRoZSBncm91cA0KCXRoaW5rPw0KCQ0KCU9uIHRoZSBzaWRlLCBpZiB5 b3UgZGlnIHBhdGVudCA3LDU2Nyw1NzcgYXQgVVNQVE8sIHlvdSdsbCBmaW5kIHRoYXQgSSdkDQoJ cmF0aGVyIGV4cG9zZSB0aGUgc3RhdGlzdGljYWwgYXNwZWN0IG9mICBhIG1ldHJpYyB0aGFuIHJl c29ydCB0bw0KCWh5c3RlcmVzaXMuDQoJRm9yIGFsbCBJIGtub3csIHRoaXMgaXMgYWxzbyBzb21l dGhpbmcgdGhhdCB3YXMgc3VjY2Vzc2Z1bGx5IHRyaWVkIG9uDQoJT0xTUiwgYnV0IHRoYXQgaXMg bm90IGF2YWlsYWJsZSBpbiB0aGUgUlBMIG1ldHJpY3MgZHJhZnQuDQoJDQoJOiAgKQ0KCVBhc2Nh bA0KCWh0dHA6Ly93d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny8NCgkNCgkNCgk+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBQaGlsaXAgTGV2aXMgW21haWx0bzpw YWxAY3Muc3RhbmZvcmQuZWR1XQ0KCT4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTQsIDIwMTAg NzozNCBQTQ0KCT4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCgk+IENjOiBST0xMIFdH DQoJPiBTdWJqZWN0OiBSZTogW1JvbGxdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0w NC50eHQNCgk+IA0KCT4gDQoJPiBPbiBEZWMgMTMsIDIwMTAsIGF0IDEyOjE4IEFNLCBQYXNjYWwg VGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KCT4gDQoJPiA+IEhpIFBoaWw6DQoJPiA+DQoJPiA+ IEFwcGFyZW50bHkgSSBtaXNzZWQgYSBtYWlsLiBPRiAwNCBmYWlscyB0byBhZGRyZXNzIHlvdXIg Y29uY2VybnMuIFNvDQoJSQ0KCT4gPiBkaWdnZWQgaW50byB0aGUgV0cgbGlzdCBhbmQgZm91bmQg dGhpczoNCgk+ID4NCgk+ID4gIg0KCT4gPiBNeSBtYWpvciBjb25jZXJuIHdpdGggT0YwIGlzIGFj dHVhbGx5IHF1aXRlIGRpZmZlcmVudDogaXQgZG9lcyBub3QNCglzYXkNCgk+ID4gaG93IHRvIGNv bXB1dGUgUmFuayBmcm9tIG1ldHJpY3MuIEJhY2sgaW4gdGhlIGRpc2N1c3Npb25zIG9uIE1SSE9G LA0KCT4gPiB0aGlzIGVtZXJnZWQgYXMgYSByZXF1aXJlbWVudCBmb3IgYW4gT0YsIHdoZW4gd2Ug c2VwYXJhdGVkIE9GcyBmcm9tDQoJPiBtZXRyaWNzLg0KCT4gPiBSaWdodCBub3csIGl0IHNlZW1z IGxpa2UgSSBjb3VsZCBoYXZlIGFuIE9GMCB0aGF0IGNvbXB1dGVzIFJhbmsgZnJvbQ0KCT4gPiBs YXRlbmN5LCBvciB0aHJvdWdocHV0LiBTaW5jZSB0aGUgY29tcHV0YXRpb24gb2YgUmFuayBpcyB2 ZXJ5IHBvb3JseQ0KCT4gPiBkZWZpbmVkLCBpdCBzZWVtcyB2ZXJ5IGVhc3kgdG8gaGF2ZSB0d28g aW5jb21wYXRpYmxlIE9GMA0KCT4gPiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3b3JrIGF0IGNyb3Nz IHB1cnBvc2VzLg0KCT4gPg0KCT4gPiBGb3IgT0YwIHRvIGJlIHJlYWR5IHRvIGJlIGFuIFJGQywg aXQgbXVzdCBhY3R1YWxseSBwcm92aWRlIHNvbWUNCgk+ID4gZGV0YWlscyBvbiBob3cgbWV0cmlj cyBhcmUgY29udmVydGVkIHRvIFJhbmsuIFRha2UgYSBsb29rIGF0IHRoZQ0KCUFwcmlsDQoJPiA+ IGRpc2N1c3Npb24gZW50aXRsZWQgIkRlY291cGxpbmcgTWV0cmljcyBhbmQgT0YuIg0KCT4gPiAi DQoJPiA+DQoJPiA+IE9GMCBkb2VzIG5vdCB1c2Ugc2F5IGhvdyB0byBtZXRyaWNzLiBJdCBpcyBh IHdlaWdodGVkIGhvcCBjb3VudCBmb3INCgk+ID4gdXNlIGluIHdpcmUgYW5kIHdpcmUgZW11bGF0 aW9uLiBJIGFncmVlIHRoYXQgdGhlIHdlaWdodCBjb3VsZCBiZQ0KCT4gPiBzdGF0aWMgb3IgZHlu YW1pYywgYnV0IHRoZSBkZXNpZ24gcG9pbnQgaXMgc3BlY2lmaWNhbGx5IG5vdCB0bw0KCWRpc2N1 c3MNCgk+ID4gdGhlIGNvbXB1dGF0aW9uIG9mIGR5bmFtaWMgd2VpZ2h0cyBpbiBPRjAuIFRoaXMg d291bGQgYmUgb3BlbmluZyB0aGUNCgk+ID4gUGFuZG9yYSBib3ggb2YgdGhlIGdlbmVyYWwgUlBM IG1ldHJpY3MgYW5kIE9GIGRpc2N1c3Npb24sIHdoaWNoIGlzDQoJPiA+IGFkZHJlc3NlZCBlbHNl d2hlcmUgYW5kIGluIGxvdCBtb3JlIHRleHQgdGhhbiBuZWVkZWQgaGVyZS4gU28gaWYgd2UNCgk+ ID4gdGFrZSB0aGUgd2VpZ2h0IGFzIGEgZ2l2ZW4sIGhvcGVmdWxseSBzdGFibGUgZW5vdWdoIHNj YWxhciwgdGhlbiB0aGUNCgk+ID4gcmFuayBjb21wdXRhdGlvbiBpcyB0aGUgbW9zdCBjbGFzc2lj YWwgYWRkaXRpb24gb2Ygd2VpZ2h0ZWQgaG9wcy4NCgk+IA0KCT4gQnV0IHRoZSBjb25zZW5zdXMs IHdoZW4gZGlzY3Vzc2luZyBNUkhPRiwgaXMgdGhhdCBhbiBvYmplY3RpdmUNCglmdW5jdGlvbg0K CT4gc3BlY2lmaWNhdGlvbiBuZWVkcyB0byBzYXkgaG93IHRvIGhhbmRsZSBhbmQgdXNlIG1ldHJp Y3MuIEl0IHNlZW1zDQoJc3RyYW5nZQ0KCT4gdGhhdCBPRjAgZG9lc24ndC4gT3IgZG9lcyBPRjAg aGF2ZSBhIHNwZWNpYWwgc3RhdHVzLCB0aGF0IGl0IGRvZXMgbm90DQoJaGF2ZSB0bw0KCT4gZm9s bG93IHRoZSByZXF1aXJlbWVudHMgbGFpZCBvdXQgZm9yIG9iamVjdGl2ZSBmdW5jdGlvbg0KCXNw ZWNpZmljYXRpb25zPw0KCT4gDQoJPiBPdGhlcndpc2UgeW91IGNhbiBoYXZlIGluZGVwZW5kZW50 IGltcGxlbWVudGF0aW9ucyB3aGljaCBhcmUNCgk+IGluY29tcGF0aWJsZSBhbmQgY2F1c2UgcHJv YmxlbXM6IHRoaXMgd2FzIGR1ZSB0byBKUCdzIGluc2lzdGVuY2UgdGhhdA0KCT4gb2JqZWN0aXZl IGZ1bmN0aW9ucyByZW1haW4gbWV0cmljLWluZGVwZW5kZW50LiBXaGF0IHdvcnJpZXMgbWUgYWJv dXQNCgl0aGlzDQoJPiBpcyB0aGF0IGl0IHNlZW1zIHRvIGp1c3QgYmxpbmRseSByZXBlYXQgbWlz dGFrZXMgdGhhdCBMTE4gcHJvdG9jb2xzDQoJaGF2ZQ0KCT4gbGVhcm5lZCBmcm9tLiBFLmcuLCBt b2Rlcm4gT0xTUiBkZXBsb3ltZW50cyBkbyBub3QgYWRoZXJlIHRvIHRoZSBPTFNSDQoJPiBzcGVj aWZpY2F0aW9uIGJlY2F1c2UgaXQgcmVxdWlyZXMgaG9wY291bnQgYW5kIGhvcGNvdW50IGRvZXMg bm90IHdvcmsNCgl2ZXJ5DQoJPiB3ZWxsLiBZb3UncmUgcmlnaHQsIHRoZXJlJ3MgbG90cyBvZiBl eHBlcmllbmNlIHVzaW5nIGhvcGNvdW50IGFzIGENCgltZXRyaWMuIEluDQoJPiB0aGUgY29udGV4 dCBvZiBMTE5zLCBob3dldmVyLCB0aGF0IGV4cGVyaWVuY2UgaGFzIGJlZW4gbmVnYXRpdmUuDQoJ PiANCgk+ID4gQ291bGQgeW91IHBsZWFzZSBiZSBtb3JlIHNwZWNpZmljIGluIHdoYXQgeW91J2Qg YWRkIHRvIHRoZSBzcGVjPw0KCT4gDQoJPiBJIHdvdWxkIGFkZCBhIHNwZWNpZmljYXRpb24gb2Yg aG93IE9GMCB0cmFuc2xhdGVzIG1ldHJpY3MgaW50byBSYW5rLg0KCUUuZy4sIGFuDQoJPiBFVFgg YmV0d2VlbiAxIGFuZCAzIGFkZHMgMSB0byBSYW5rLCBldGMuDQoJPiANCgk+IFBoaWwNCglfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVJvbGwgbWFpbGlu ZyBsaXN0DQoJUm9sbEBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJUm9sbCBtYWlsaW5nIGxpc3QNCglSb2xsQGlldGYub3JnDQoJaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoJDQoNCg0K ------_=_NextPart_001_01CB9EB4.1C6E2FA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PGJhc2UgaHJlZj0ieC1tc2c6Ly8xMy8iPjwvaGVhZD48Ym9keSBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KQWxsLCBpZiB5b3UgdGhpbmsgb2YgYSBwb3RlbnRpYWwgbmV3 IFdHIGl0ZW0sIGxldCcgZGlzY3VzIGl0IGR1cmluZyBvdXIgaW50ZXJpbSBXRyBtZWV0aW5nIG9u IE1vbmRheS4gSlANPGJyPlNlbnQgZnJvbSBTbWFydCBQaG9uZQ08YnI+DTxicj5KUCBWYXNzZXVy IC0gQ2lzY288L2ZvbnQ+PGJyPiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N Cjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxiPkZyb208L2I+OiBDaGF1dmVuZXQgQ8Op ZHJpYyBbbWFpbHRvOmMuY2hhdXZlbmV0QHdhdHRlY28uY29tXQ08YnI+PGI+U2VudDwvYj46IEZy aWRheSwgRGVjZW1iZXIgMTcsIDIwMTAgMDM6MDkgQU08YnI+PGI+VG88L2I+OiBZb2F2IEJlbi1Z ZWhlemtlbCAmbHQ7eW9hdkB5aXRyYW4uY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBST0xMIFdHICZs dDtyb2xsQGlldGYub3JnJmd0Ow08YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbUm9sbF0gSS1EIEFj dGlvbjpkcmFmdC1pZXRmLXJvbGwtb2YwLTA0LnR4dA08YnI+PC9mb250PiZuYnNwOzxicj48L2Rp dj4NCkhpIGFsbCwmbmJzcDs8ZGl2Pjxicj48L2Rpdj48ZGl2Pk91ciBQTEMgZXhwZXJpZW5jZSBh bHNvIGhpZ2hsaWdodCB0aGUgbmF0dXJlIG9mIGFzeW1tZXRyaWMgbGlua3MgaW4gUExDIG5ldHdv cmtzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+UExDIGluIGdlbmVyYWwgY2Fubm90IGJlIGNv bnNpZGVyZWQgYXMgYSBicm9hZGNhc3QgbWVkaWEgbGlrZSBldGhlcm5ldC48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PlJQTCBlbmFibGUgdG8gZmFjZSByb3V0aW5nIGNoYWxsZW5nZXMgZm9yIExM TnMsIHdoaWNoIGFyZSBub3QgYSB3aXJlbGVzcyBtb25vcGxvbHksIGFuZCBhc3ltbWV0cmljIGxp bmtzIGFyZSBkZWZpbml0ZWx5IGEgcGFydCBvZiBpdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PkkgcmVtZW1iZXIgYSBwcmV2aW91cyBtYWlsIHRocmVhZCBhYm91dCB0aGlzIHRvcGljIG9uIHRo aXMgTUwsIGJ1dCBjYW4ndCBmaW5kIGJhY2sgaWYgdGhlcmUgd2VyZSBhIGNvbmNsdXNpb24gb24g aXQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0LDwvZGl2PjxkaXY+Q8OpZHJpYzwvZGl2 PjxkaXY+PGJyPjxkaXY+PGRpdj5MZSAxNiBkw6ljLiAyMDEwIMOgIDE3OjQ2LCBZb2F2IEJlbi1Z ZWhlemtlbCBhIMOpY3JpdCA6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3Bh biIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRl ci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg Zm9udC1zaXplOiBtZWRpdW07ICI+PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+PGRpdiBjbGFzcz0iU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBTZWN0aW9uMTsgIj48 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgIj5IaSBhbGwsPC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Ij4mbmJzcDs8L3NwYW4+PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkZvciB0aGUgcmVjb3JkIC0gbGV0IG1lIHNo ZWQgc29tZSBsaWdodCBvbiB0aGUgUExDIGNhc2UgZnJvbSBvdXIgZXhwZXJpZW5jZS48L3NwYW4+ PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPiZuYnNwOzwvc3Bhbj48L3A+PGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7ICI+UExDIGxpbmtzIGNhbiBkZWZpbml0ZWx5IGJlIGFzeW1tZXRyaWMuIFRoaXMgaXMgZHVl IHRvPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+dGhlIGZhY3QgdGhhdCB0aGUgbWFp biBmYWN0b3JzIGFmZmVjdGluZyByZWNlcHRpb24gYXJlIG5vaXNlIGF0IHRoZSBSeCBzaWRlIChk aWZmZXJlbnQgYXQgYm90aCBlbmRzKSwgYW5kIGxvYWQgYXQgVHggc2lkZSAoYWdhaW4gZGlmZmVy ZW50IGF0IGJvdGggZW5kcykuPC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVm dDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPlNvIGZyb20gYm90aCBl bmRzLCB0aGVyZSBjYW4gZWFzaWx5IGJlIGFzeW1tZXRyeS48L3NwYW4+PC9kaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyAiPiZuYnNwOzwvc3Bhbj48L3A+PGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+V2l0aG91dCBn ZXR0aW5nIGludG8gdGhlIGRldGFpbHMgb2YgaG93IHRoaXMgaXMgZG9uZSw8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgIj5JIGFncmVlIHRoYXQgUlBMIG11c3QgcHJvdmlkZSBtZWNoYW5p c20ocykgZW5hYmxpbmcgdG8gY29wZSB3aXRoIGFzeW1tZXRyaWMgbGlua3MgYXMgYSBub24tcmFy ZSBjYXNlIChpc27CknQgaXQgb25lIG9mIHRoZSByZXF1aXJlbWVudHMgb2YgUlBMPyk8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5Ob3cgZ2V0dGlu ZyBpbnRvIHRoZSBkZXRhaWxzIMKWIGNhbiB0aGUgV0cgYXQgbGVhc3QgcHJvdmlkZSBzb21lIGZl ZWRiYWNrIG9uIHdoZXRoZXIgc3VjaCBtZWNoYW5pc21zIGFyZSBzdXBwb3J0ZWQgYnkgUlBMIGlu IGFsbCBtYWpvciBtb2RlcyBhbmQgdG9wb2xvZ2llcyAoaS5lLiBzdG9yaW5nL25vbiBzdG9yaW5n IG1vZGVzIGFuZCBQMk1QL01QMlAgdG9wb2xvZ2llcyk/PC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj4mbmJzcDs8L3NwYW4+PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkJlc3QgcmVnYXJk cyw8L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+WW9hdjwvc3Bhbj48L2Rpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 ICI+Jm5ic3A7PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTog bm9uZTsgYm9yZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7 IGJvcmRlci13aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9w LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3Jk ZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsg cGFkZGluZy1ib3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFy Z2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W21haWx0bzo8YSBocmVmPSJt YWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RG9uIFN0 dXJlazxicj48Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGh1cnNkYXksIERlY2VtYmVyIDE2LCAyMDEwIDY6MDEgUE08YnI+PGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4nUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSc7ICdQaGlsaXAgTGV2aXMnPGJyPjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+J1JPTEwgV0cnPGJy PjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW1JvbGxdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQ8 L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7ICI+Jm5ic3A7PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkkgdGhpbmsgd2UgYXJlIGxv b2tpbmcgYXQgaG93IHRvIGhhbmRsZSBhc3ltbWV0cmljIGxpbmtzLiZuYnNwOyBXZSBoYWQgYSB3 YXkgdG8gZG8gdGhpcyBpbiBwcmV2aW91cyBkZXBsb3ltZW50cyBzbyB3aWxsIGxpa2VseSBjb250 cmlidXRlIGEgbmV3IE9GIHRoYXQgY292ZXJzIHRoYXQgZnVuY3Rpb24uPC9zcGFuPjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJzcDs8L3NwYW4+PC9wPjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkRv bjwvc3Bhbj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0 OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwvcD48ZGl2PjxkaXYg c3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsgYm9yZGVyLWJvdHRvbS1zdHlsZTogbm9u ZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDogaW5pdGlhbDsgYm9yZGVy LWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsgYm9yZGVyLXRvcC1jb2xv cjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmctdG9w OiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1ib3R0b206IDBpbjsgcGFkZGluZy1s ZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5QYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj5wdGh1YmVydEBjaXNjby5jb208L2E+XTxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBE ZWNlbWJlciAxNiwgMjAxMCA3OjUxIEFNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmQuc3R1cmVrQGF0 dC5uZXQiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ ZC5zdHVyZWtAYXR0Lm5ldDwvYT47IFBoaWxpcCBMZXZpczxicj48Yj5DYzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJPTEwgV0c8YnI+PGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJFOiBbUm9sbF0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXJvbGwtb2YwLTA0LnR4dDwvc3Bhbj48 L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgIj4mbmJzcDs8L3A+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+RGlkIHlvdSBjb25zaWRlciBkcmFmdC1p ZXRmLXJvbGwtbWlucmFuay1oeXN0ZXJlc2lzLW9mID88L3NwYW4+PC9kaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyAiPiZuYnNwOzwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5QYXNjYWw8 L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+PGEgaHJlZj0iaHR0cDovL3d3dy54dHJhbm9ybWFsLmNv bS93YXRjaC83MDExMzU3LyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsgIj5odHRwOi8vd3d3Lnh0cmFub3JtYWwuY29tL3dhdGNoLzcwMTEzNTcvPC9hPjwv c3Bhbj48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFu PjwvcD48ZGl2IHN0eWxlPSJib3JkZXItdG9wLXN0eWxlOiBub25lOyBib3JkZXItYm90dG9tLXN0 eWxlOiBub25lOyBib3JkZXItbGVmdC1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiBpbml0aWFs OyBib3JkZXItY29sb3I6IGluaXRpYWw7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRl ci1yaWdodC1jb2xvcjogYmx1ZTsgYm9yZGVyLXJpZ2h0LXdpZHRoOiAxLjVwdDsgcGFkZGluZy10 b3A6IDBpbjsgcGFkZGluZy1yaWdodDogMGluOyBwYWRkaW5nLWJvdHRvbTogMGluOyBwYWRkaW5n LWxlZnQ6IDRwdDsgIj48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsg Ym9yZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRl ci13aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxl OiBzb2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9w LXdpZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGlu Zy1ib3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogVGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Eb24gU3R1cmVrIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmQuc3R1cmVrQGF0dC5uZXQiIHN0eWxlPSJjb2xvcjogYmx1ZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ZC5zdHVyZWtAYXR0Lm5ldDwvYT5dPHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNk YXksIERlY2VtYmVyIDE2LCAyMDEwIDQ6NDEgUE08YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QYXNjYWwgVGh1YmVydCAocHRodWJl cnQpOyAnUGhpbGlwIExldmlzJzxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPidST0xMIFdHJzxicj48Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtSb2xsXSBJ LUQgQWN0aW9uOmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0PC9zcGFuPjwvZGl2PjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPiZu YnNwOzwvcD48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgIj5JIHRoaW5rIHdlIGFyZSBtaXNzaW5nIHNvbWV0aGluZyBvdGhl ciB0aGFuIE9GMCB0byB1c2UuJm5ic3A7IE1heWJlIHdlIGp1c3QgbmVlZCBhIGRyYWZ0IG9uIHRo aXMuPC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJzcDs8L3NwYW4+ PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyAiPkxldCBtZSBzZWUgaWYgd2UgY2FuwpJ0IGdlbmVyYXRlIHNvbWV0aGlu ZyBpbiBvdXIgWmlnQmVlIElQIHRlc3RpbmcuJm5ic3A7IEZvciBzdXJlIHdlIHdvbsKSdCBiZSB1 c2luZyBPRjAgYW5kIHdlIG5lZWQgdG8gc3BlY2lmeSBzb21ldGhpbmcgYW55d2F5Ljwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj48YnI+RG9uPC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgIj4mbmJzcDs8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJz cDs8L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXN0eWxlOiBub25lOyBi b3JkZXItYm90dG9tLXN0eWxlOiBub25lOyBib3JkZXItbGVmdC1zdHlsZTogbm9uZTsgYm9yZGVy LXdpZHRoOiBpbml0aWFsOyBib3JkZXItY29sb3I6IGluaXRpYWw7IGJvcmRlci10b3Atc3R5bGU6 IHNvbGlkOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci10b3At d2lkdGg6IDFwdDsgcGFkZGluZy10b3A6IDNwdDsgcGFkZGluZy1yaWdodDogMGluOyBwYWRkaW5n LWJvdHRvbTogMGluOyBwYWRkaW5nLWxlZnQ6IDBpbjsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyAiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiBzdHls ZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnB0aHViZXJ0QGNp c2NvLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj48Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGh1cnNkYXksIERlY2VtYmVyIDE2LCAyMDEwIDc6MDUgQU08YnI+PGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZC5zdHVyZWtAYXR0Lm5ldCIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj5kLnN0dXJla0BhdHQubmV0PC9hPjsgUGhpbGlwIExldmlz PGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+Uk9MTCBXRzxicj48Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtSb2xsXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYt cm9sbC1vZjAtMDQudHh0PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPiZuYnNwOzwvcD48ZGl2IHN0eWxlPSJt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5E b246PC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJzcDs8L3NwYW4+ PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyAiPkkgdGhpbmsgdGhhdCB0aGUgZGlzY29ubmVjdCBpcyB5b3VyIGFzc3Vt cHRpb24gdGhhdCBPRiAwIGlzIHRoZSBkZWZhdWx0LiBUaGVyZSBpcyBubyBkZWZhdWx0IE9GIGlu IFJQTC4gVGhhdCB3YXMgZGlzY3Vzc2VkIGF0IGxlbmd0aCBhbmQgdGhhdMKScyB3aHkgT0YgMCB3 YXMgc3BsaXQgZnJvbSBSUEwgYXQgc29tZSBwb2ludC4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHRo ZXJlwpJzIGFueSBjbGFpbSAobGVmdD8pIHRoYXQgT0YwIGlzIHRoZSBkZWZhdWx0IE9GIGZvciBS UEzChTwvc3Bhbj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFu PjwvcD48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj5JwpJsbCBhYnN0YWluIHRvIG1ha2UgYW55IHByZWRpY3Rpb24gYXMg b2Ygd2hlcmUgUlBMIHdpbGwgYmUgbW9zdCB1c2VkIChvciB1c2VmdWwpLiBXZSBnb3QgcmlkIG9m IGhhdmluZyB0byBtYWtlIHRoYXQgYXNzdW1wdGlvbiBieSBhbGxvd2luZyBPRiB0byBleHRlbmQg dGhlIGJhc2UgcHJvdG9jb2wgaW4gdGhlIGZpcnN0IHBsYWNlLiBUaGlzIHdhcyBhY3R1YWxseSBh IGtleSBkZXNpZ24gcG9pbnQuIEnCkmxsIGp1c3QgdHJ5IG15IGJlc3QgdG8gbWFrZSBzdXJlIHRo YXQgaXQgY2FuIGJlIHVzZWQgd2hlcmUgaXTCknMgbmVlZGVkLjwvc3Bhbj48L2Rpdj48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPlBh c2NhbDwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48YSBocmVmPSJodHRwOi8vd3d3Lnh0cmFub3Jt YWwuY29tL3dhdGNoLzcwMTEzNTcvIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyAiPmh0dHA6Ly93d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny88 L2E+PC9zcGFuPjwvZGl2PjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJzcDs8 L3NwYW4+PC9wPjxkaXYgc3R5bGU9ImJvcmRlci10b3Atc3R5bGU6IG5vbmU7IGJvcmRlci1ib3R0 b20tc3R5bGU6IG5vbmU7IGJvcmRlci1sZWZ0LXN0eWxlOiBub25lOyBib3JkZXItd2lkdGg6IGlu aXRpYWw7IGJvcmRlci1jb2xvcjogaW5pdGlhbDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsg Ym9yZGVyLXJpZ2h0LWNvbG9yOiBibHVlOyBib3JkZXItcmlnaHQtd2lkdGg6IDEuNXB0OyBwYWRk aW5nLXRvcDogMGluOyBwYWRkaW5nLXJpZ2h0OiAwaW47IHBhZGRpbmctYm90dG9tOiAwaW47IHBh ZGRpbmctbGVmdDogNHB0OyAiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXN0eWxlOiBu b25lOyBib3JkZXItYm90dG9tLXN0eWxlOiBub25lOyBib3JkZXItbGVmdC1zdHlsZTogbm9uZTsg Ym9yZGVyLXdpZHRoOiBpbml0aWFsOyBib3JkZXItY29sb3I6IGluaXRpYWw7IGJvcmRlci10b3At c3R5bGU6IHNvbGlkOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRl ci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZy10b3A6IDNwdDsgcGFkZGluZy1yaWdodDogMGluOyBw YWRkaW5nLWJvdHRvbTogMGluOyBwYWRkaW5nLWxlZnQ6IDBpbjsgIj48ZGl2IHN0eWxlPSJtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyAiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRvbiBTdHVyZWsg W21haWx0bzo8YSBocmVmPSJtYWlsdG86ZC5zdHVyZWtAYXR0Lm5ldCIgc3R5bGU9ImNvbG9yOiBi bHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5kLnN0dXJla0BhdHQubmV0PC9hPl08 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPjxiPlNl bnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5U aHVyc2RheSwgRGVjZW1iZXIgMTYsIDIwMTAgMzo1NyBQTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCk7ICdQaGlsaXAgTGV2aXMnPGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+J1JPTEwgV0cnPGJyPjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW1Jv bGxdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQ8L3NwYW4+PC9kaXY+PC9k aXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 ICI+Jm5ic3A7PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkhpIFBhc2NhbCw8L3NwYW4+PC9kaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyAiPiZuYnNwOzwvc3Bhbj48L3A+PGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Q29ycmVjdCwg dGhlcmUmbmJzcDsgaXMgbm8gcG9pbnQgaW4gcHJldmVudGluZyB0aGUgdXNlIG9mIFJQTCBpbiB3 aXJlZCBuZXR3b3Jrcy48L3NwYW4+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPiZu YnNwOzwvc3Bhbj48L3A+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+VGhhdCBzYWlkLCB3aGVuIHRoZSBkZWZhdWx0IE9G IHVzZXMgYSBtZXRyaWMgdGhhdCBpcyBrbm93biBub3QgdG8gd29yayBpbiB3aXJlbGVzcyBuZXR3 b3JrcyAod2hlcmUgSSB3aWxsIGNsYWltIFJQTCBpcyBtb3JlIGxpa2VseSB0byBiZSBkZXBsb3ll ZCkgdGhlbiBjaXRpbmcgdGhlIHN1Y2Nlc3NmdWwgZGVwbG95bWVudCBvZiB0aGUgc2FtZSBPRiBp biB3aXJlZCBuZXR3b3JrcyBkb2VzIG5vdCBoZWxwIHRoZSBjYXVzZS48L3NwYW4+PC9kaXY+PGRp diBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7ICI+PGJyPkRvbjwvc3Bhbj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+ Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsgYm9yZGVyLWJv dHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDog aW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAx cHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1ib3R0b206 IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21h LCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QYXNjYWwgVGh1YmVydCAocHRodWJlcnQp IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9y OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5wdGh1YmVydEBjaXNjby5jb208 L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlRodXJzZGF5LCBEZWNlbWJlciAxNiwgMjAxMCA2OjUzIEFNPGJyPjxiPlRvOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RG9uIFN0dXJlazsg UGhpbGlwIExldmlzPGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Uk9MTCBXRzxicj48Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtSb2xsXSBJLUQgQWN0aW9u OmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPiZuYnNwOzwvcD48 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgIj5Eb246PC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4m bmJzcDs8L3NwYW4+PC9wPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPkkgbGlzdGVkIGEgbnVtYmVyIG9mIGV4YW1wbGVz IGFuZCBub25lIG9mIHRoZW0gaXMgUExDIGFjdHVhbGx5Ljwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Ij5SUEwgaXMgYSByb3V0aW5nIHByb3RvY29sLiBUaGVyZSBpcyBubyBwb2ludCBpbiBwcmV2ZW50 aW5nIGl0cyB1c2FnZSBvbiB3aXJlZCBsaW5lcy48L3NwYW4+PC9kaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyAiPiZuYnNwOzwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5QYXNjYWw8L3Nw YW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7ICI+PGEgaHJlZj0iaHR0cDovL3d3dy54dHJhbm9ybWFsLmNvbS93 YXRjaC83MDExMzU3LyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsgIj5odHRwOi8vd3d3Lnh0cmFub3JtYWwuY29tL3dhdGNoLzcwMTEzNTcvPC9hPjwvc3Bh bj48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1sZWZ0 OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+Jm5ic3A7PC9zcGFuPjwv cD48ZGl2IHN0eWxlPSJib3JkZXItdG9wLXN0eWxlOiBub25lOyBib3JkZXItYm90dG9tLXN0eWxl OiBub25lOyBib3JkZXItbGVmdC1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiBpbml0aWFsOyBi b3JkZXItY29sb3I6IGluaXRpYWw7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1y aWdodC1jb2xvcjogYmx1ZTsgYm9yZGVyLXJpZ2h0LXdpZHRoOiAxLjVwdDsgcGFkZGluZy10b3A6 IDBpbjsgcGFkZGluZy1yaWdodDogMGluOyBwYWRkaW5nLWJvdHRvbTogMGluOyBwYWRkaW5nLWxl ZnQ6IDRwdDsgIj48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsgYm9y ZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRlci13 aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxlOiBz b2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdp ZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1i b3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Eb24gU3R1cmVrIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmQuc3R1cmVrQGF0dC5uZXQiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ZC5zdHVyZWtAYXR0Lm5ldDwvYT5dPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5 LCBEZWNlbWJlciAxNSwgMjAxMCA1OjUzIFBNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KTsgUGhpbGlwIExldmlzPGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Uk9MTCBXRzxicj48Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtSb2xsXSBJLUQgQWN0 aW9uOmRyYWZ0LWlldGYtcm9sbC1vZjAtMDQudHh0PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPiZuYnNwOzwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDEycHQ7IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg Ij5JIGhhdmUgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCB0aGUgdXNlIGZvciBSUEwgaW4gd2lyZWQg bmV0d29ya3MuJm5ic3A7IEFsbCBvZiB0aGUgUExDIHNvbHV0aW9ucyBJIGhhdmUgbG9va2VkIGF0 IHdvdWxkIG5vdCBiZW5lZml0IGF0IGFsbCBieSBSUEwuJm5ic3A7IFRoZSBtYWluIHVzZSBjYXNl IGlzIHdpcmVsZXNzIHdoZXJlIGFzeW1tZXRyaWMgbGlua3MgYXJlIGEgbWFqb3IgcHJvYmxlbS4m bmJzcDsgSXQgaXMgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQgdGhlIGxvZ2ljIGJlbG93IGluIGxp Z2h0IG9mIHRoaXMgaW5jb25zaXN0ZW5jeS48YnI+PGJyPkRvbjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPiZuYnNwOzwvcD48 ZGl2PjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IHRleHQtYWxpZ246IGNlbnRlcjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxociBzaXplPSIxIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7ICI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIgc3R5 bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5wdGh1YmVydEBj aXNjby5jb208L2E+Jmd0Ozxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWxpcCBMZXZpcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBh bEBjcy5zdGFuZm9yZC5lZHUiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7ICI+cGFsQGNzLnN0YW5mb3JkLmVkdTwvYT4mZ3Q7PGJyPjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Uk9MTCBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWQs IERlY2VtYmVyIDE1LCAyMDEwIDM6MDY6MDAgQU08YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbUm9sbF0gSS1EIEFj dGlvbjpkcmFmdC1pZXRmLXJvbGwtb2YwLTA0LnR4dDxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPjxicj5IaSBQ aGlsOjxicj48YnI+PGJyPiZndDsgbGVhcm5lZCBmcm9tLiBFLmcuLCBtb2Rlcm4gT0xTUiBkZXBs b3ltZW50cyBkbyBub3QgYWRoZXJlIHRvIHRoZSBPTFNSPGJyPiZndDsgc3BlY2lmaWNhdGlvbiBi ZWNhdXNlIGl0IHJlcXVpcmVzIGhvcGNvdW50IGFuZCBob3Bjb3VudCBkb2VzIG5vdCB3b3JrPGJy PnZlcnk8YnI+Jmd0OyB3ZWxsLiBZb3UncmUgcmlnaHQsIHRoZXJlJ3MgbG90cyBvZiBleHBlcmll bmNlIHVzaW5nIGhvcGNvdW50IGFzIGE8YnI+bWV0cmljLiBJbjxicj4mZ3Q7IHRoZSBjb250ZXh0 IG9mIExMTnMsIGhvd2V2ZXIsIHRoYXQgZXhwZXJpZW5jZSBoYXMgYmVlbiBuZWdhdGl2ZS48YnI+ PGJyPldlJ3JlIGluIGEgbG9vcCBoZXJlLiBUaGlzIG5lZWQgdGhhdCB5b3UgZGVzY3JpYmUgbW9z dGx5IGNvbWVzIGZyb208YnI+cHJvcGFnYXRpb24gaXNzdWVzIGVuY291bnRlcmVkIGluIHdpcmVs ZXNzIG5ldHdvcmtzLjxicj5UaGUgd2hvbGUgcG9pbnQgaXMgdGhhdCBub3QgYWxsIExMTnMgYXJl IHdpcmVsZXNzLiBBZG1pbmlzdHJhdGl2ZSBjb3N0PGJyPmlzIGJvdGggdXN1YWwgYW5kIHByb3Zl biBvbiB3aXJlcy48YnI+PGJyPkFsc28gdGhlcmUgYXJlIHdpcmVsZXNzIGVtdWxhdGlvbnMgYXJv dW5kIHRoYXQgcHJvdmlkZSBhbiBhY2NlcHRhYmxlPGJyPnNlcnZpY2UgYW5kIGhlYXZpbHkgZGVw bG95ZWQgc2VydmljZSwgYm90aCBQMlAgbGlrZSBtaWxpdGFyeSBhbmQ8YnI+c2F0ZWxsaXRlIHJh ZGlvcyBhbmQgdHJhbnNpdCwgdGhlIG1vc3QgY29tbW9uIGJlaW5nIFdJRkkuPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj5UaGlzIGlzIGNsZWFybHkg bm90IHlvdXIgd29ybGQsIGJ1dCB0aGUgZmFjdCBpcyB0aGF0IHdlIGhhdmUgaGFkIGhhcHB5PGJy PmN1c3RvbWVycyZuYnNwOyBmb3Igb3ZlciAxMCB5ZWFycywgdXNpbmcgU3Bhbm5pbmcgVHJlZSBv ciBzaW1pbGFyIG92ZXI8YnI+d2lyZWxlc3MgYnJpZGdlcy48YnI+PGJyPkknZCBhc3NlcnQgdGhh dCBSUEwgcHJvdmlkZXMgYSBsb3QgbW9yZSB0aGFuIFNUUCwgaWYgb25seSBiZWNhdXNlOjxicj4t IHdlIGhhdmUgdGhlIElQdjYgaG9wIGxpbWl0IGFuZCB0aGUgUlBMIHJlYWN0aXZlIGxvb3AgZGV0 ZWN0aW9uIHRodXMgbm88YnI+cmlzayBvZiBtZWx0ZG93bjxicj4tIHdlIGJ1aWxkIERBR3MgYXMg b3Bwb3NlZCB0byB0cmVlczxicj48YnI+SWYgd2UgY2FuJ3QgY29udmVyZ2Ugb24gdGhhdCwgbGV0 J3Mga2VlcCB0aGUgZGlzY3Vzc2lvbiBhdCB3aXJlZCBsaW5rczxicj5mb3IgYSBtaW51dGUuIElu IHRoYXQgY2FzZSwgUlBMIGNhbiBvZnRlbiBiZSB1c2VkIHRoZSB3YXkgYW55IG90aGVyIElHUDxi cj5pcyB1c2VkIHRvZGF5LCBjYW4ndCBpdD88YnI+VGhlbiBhZ2Fpbiwgd2UgY2FuIGRlcml2ZSBm cm9tIFJQTCdzIHByb3BlcnRpZXMgdGhhdCBpdCBjYW4gYWN0dWFsbHkgYmU8YnI+cHJlZmVyYWJs ZSBvdmVyIGV4aXN0aW5nIHByb3RvY29scyBhdCBsZWFzdCBmb3IgY2VydGFpbiBhcHBsaWNhdGlv bnMsPGJyPmJlY2F1c2UgaXQgY2FuIGJlIGJvdGggc2ltcGxlciBhbmQgZmFzdGVyIHRvIHNldCB1 cC48YnI+U3VjaCBhcHBsaWNhdGlvbnMgaW5jbHVkZTo8YnI+PGJyPi0gY29ycG9yYXRlIFZQTiAo d2l0aCBicmFuY2ggYW5kIFNPSE8sIHR5cGljYWwgcmVjdXJzaXZlICk8YnI+LSBhZCBob2MgbmV0 d29ya3MgKHF1aWNrbHkgZGVwbG95YWJsZSBhZCBob2MgYmFzZSBjYW1wcyk8YnI+LSBkeW5hbWlj IG92ZXJsYXlzIChtZXNoZXMgb2YgdHVubmVscyBzZXJ2aW5nIHNtYWxsIGdyb3VwcyB3aXRoIHNo b3J0PGJyPnRlcm0gcHVycG9zZXMpPGJyPjxicj4mZ3Q7IEkgd291bGQgYWRkIGEgc3BlY2lmaWNh dGlvbiBvZiBob3cgT0YwIHRyYW5zbGF0ZXMgbWV0cmljcyBpbnRvIFJhbmsuPGJyPkUuZy4sIGFu PGJyPiZndDsgRVRYIGJldHdlZW4gMSBhbmQgMyBhZGRzIDEgdG8gUmFuaywgZXRjLjxicj48YnI+ Rm9yIE9GMCwgdGhlIGV4cGVjdGVkIG1ldHJpYyBpcyBhbiBhZG1pbmlzdHJhdGl2ZSBjb3N0IHRo YXQgaXMgdHJpdmlhbGx5PGJyPmFkZGVkIHVwIGFsb25nIGEgcGF0aDsgdGhlIG1vc3QgdXN1YWwg dGhpbmcuPGJyPk9GIDAgd2FzIGRlc2lnbmVkIHRvIGJlIHRoYXQgc2ltcGxlLiZuYnNwOyBUaGlz IHNhaWQsIEkgY2FuIHNlZSAyIHdheXMgZm9yPGJyPm1vdmluZyBmb3J3YXJkIHdpdGggeW91ciBz dWdnZXN0aW9uOjxicj48YnI+MSkgV2UgZGVzY3JpYmUgdGhhdCB0aGUgbWV0cmljIGlzIGEgc3Rh dGljIChhZG1pbikgY29zdCByYW5nZSAxLi4xNiBhbmQ8YnI+dGhhdCBpdCBpcyBwbGFjZWQgaW4g dGhlIG1vc3Qgc2lnbmlmaWNhbnQgb2N0ZXQgb2YgdGhlIHJhbmsuPGJyPjxicj4yKSBXZSBkZWNp ZGUgdG8gYWRkIHN1cHBvcnQgZm9yIGEgZHluYW1pYyBtZXRyaWMuIEluIHRoYXQgY2FzZSwgd2Ug ZW50ZXI8YnI+dGhlIGRpc2N1c3Npb24gb24gc3RhYmlsaXR5LCBzdGF0aXN0aWNhbCBkYW1wZW5p bmcsIGFuZCBoeXN0ZXJlc2lzLjxicj48YnI+QW5kIG9idmlvdXNseSBvcHRpb24gMyBiZWluZyBi b3RoLjxicj48YnI+SSBjYW4gZWFzaWx5IGFjY29tbW9kYXRlIDEpIGFuZCByZXB1Ymxpc2guIFRl eHQgb24gMikgd291bGQgaGF2ZSB0byBiZTxicj52ZXJ5IHZhZ3VlLCBsaWtlIGEgc2V0IG9mIHJl Y29tbWVuZGF0aW9uLiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnI+PGJyPkkgZG8gbm90IG1pbmQgZWl0aGVyIHdheSwgYm90aCBhcmUgcHJv YmFibHkgdXNlZnVsLiBXaGF0IGRvZXMgdGhlIGdyb3VwPGJyPnRoaW5rPzxicj48YnI+T24gdGhl IHNpZGUsIGlmIHlvdSBkaWcgcGF0ZW50IDcsNTY3LDU3NyBhdCBVU1BUTywgeW91J2xsIGZpbmQg dGhhdCBJJ2Q8YnI+cmF0aGVyIGV4cG9zZSB0aGUgc3RhdGlzdGljYWwgYXNwZWN0IG9mJm5ic3A7 IGEgbWV0cmljIHRoYW4gcmVzb3J0IHRvPGJyPmh5c3RlcmVzaXMuPGJyPkZvciBhbGwgSSBrbm93 LCB0aGlzIGlzIGFsc28gc29tZXRoaW5nIHRoYXQgd2FzIHN1Y2Nlc3NmdWxseSB0cmllZCBvbjxi cj5PTFNSLCBidXQgdGhhdCBpcyBub3QgYXZhaWxhYmxlIGluIHRoZSBSUEwgbWV0cmljcyBkcmFm dC48YnI+PGJyPjombmJzcDsgKTxicj5QYXNjYWw8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy54dHJh bm9ybWFsLmNvbS93YXRjaC83MDExMzU3LyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+aHR0cDovL3d3dy54dHJhbm9ybWFs LmNvbS93YXRjaC83MDExMzU3LzwvYT48YnI+PGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPiZndDsgRnJvbTogUGhpbGlwIExldmlzIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnBhbEBjcy5zdGFuZm9yZC5lZHUiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7ICI+cGFsQGNzLnN0YW5mb3JkLmVkdTwvYT5dPGJyPiZndDsgU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTQsIDIwMTAgNzozNCBQTTxicj4mZ3Q7IFRvOiBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpPGJyPiZndDsgQ2M6IFJPTEwgV0c8YnI+Jmd0OyBTdWJqZWN0OiBSZTog W1JvbGxdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1yb2xsLW9mMC0wNC50eHQ8YnI+Jmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+Jmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+Jmd0OyBPbiBE ZWMgMTMsIDIwMTAsIGF0IDEyOjE4IEFNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3Rl Ojxicj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4mZ3Q7ICZndDsgSGkgUGhpbDo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBBcHBhcmVu dGx5IEkgbWlzc2VkIGEgbWFpbC4gT0YgMDQgZmFpbHMgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5z LiBTbzxicj5JPGJyPiZndDsgJmd0OyBkaWdnZWQgaW50byB0aGUgV0cgbGlzdCBhbmQgZm91bmQg dGhpczo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAiPGJyPiZndDsgJmd0OyBNeSBtYWpvciBj b25jZXJuIHdpdGggT0YwIGlzIGFjdHVhbGx5IHF1aXRlIGRpZmZlcmVudDogaXQgZG9lcyBub3Q8 YnI+c2F5PGJyPiZndDsgJmd0OyBob3cgdG8gY29tcHV0ZSBSYW5rIGZyb20gbWV0cmljcy4gQmFj ayBpbiB0aGUgZGlzY3Vzc2lvbnMgb24gTVJIT0YsPGJyPiZndDsgJmd0OyB0aGlzIGVtZXJnZWQg YXMgYSByZXF1aXJlbWVudCBmb3IgYW4gT0YsIHdoZW4gd2Ugc2VwYXJhdGVkIE9GcyBmcm9tPGJy PiZndDsgbWV0cmljcy48YnI+Jmd0OyAmZ3Q7IFJpZ2h0IG5vdywgaXQgc2VlbXMgbGlrZSBJIGNv dWxkIGhhdmUgYW4gT0YwIHRoYXQgY29tcHV0ZXMgUmFuayBmcm9tPGJyPiZndDsgJmd0OyBsYXRl bmN5LCBvciB0aHJvdWdocHV0LiBTaW5jZSB0aGUgY29tcHV0YXRpb24gb2YgUmFuayBpcyB2ZXJ5 IHBvb3JseTxicj4mZ3Q7ICZndDsgZGVmaW5lZCwgaXQgc2VlbXMgdmVyeSBlYXN5IHRvIGhhdmUg dHdvIGluY29tcGF0aWJsZSBPRjA8YnI+Jmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9ucyB0aGF0IHdv cmsgYXQgY3Jvc3MgcHVycG9zZXMuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgRm9yIE9GMCB0 byBiZSByZWFkeSB0byBiZSBhbiBSRkMsIGl0IG11c3QgYWN0dWFsbHkgcHJvdmlkZSBzb21lPGJy PiZndDsgJmd0OyBkZXRhaWxzIG9uIGhvdyBtZXRyaWNzIGFyZSBjb252ZXJ0ZWQgdG8gUmFuay4g VGFrZSBhIGxvb2sgYXQgdGhlPGJyPkFwcmlsPGJyPiZndDsgJmd0OyBkaXNjdXNzaW9uIGVudGl0 bGVkICJEZWNvdXBsaW5nIE1ldHJpY3MgYW5kIE9GLiI8YnI+Jmd0OyAmZ3Q7ICI8YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBPRjAgZG9lcyBub3QgdXNlIHNheSBob3cgdG8gbWV0cmljcy4gSXQg aXMgYSB3ZWlnaHRlZCBob3AgY291bnQgZm9yPGJyPiZndDsgJmd0OyB1c2UgaW4gd2lyZSBhbmQg d2lyZSBlbXVsYXRpb24uIEkgYWdyZWUgdGhhdCB0aGUgd2VpZ2h0IGNvdWxkIGJlPGJyPiZndDsg Jmd0OyBzdGF0aWMgb3IgZHluYW1pYywgYnV0IHRoZSBkZXNpZ24gcG9pbnQgaXMgc3BlY2lmaWNh bGx5IG5vdCB0bzxicj5kaXNjdXNzPGJyPiZndDsgJmd0OyB0aGUgY29tcHV0YXRpb24gb2YgZHlu YW1pYyB3ZWlnaHRzIGluIE9GMC4gVGhpcyB3b3VsZCBiZSBvcGVuaW5nIHRoZTxicj4mZ3Q7ICZn dDsgUGFuZG9yYSBib3ggb2YgdGhlIGdlbmVyYWwgUlBMIG1ldHJpY3MgYW5kIE9GIGRpc2N1c3Np b24sIHdoaWNoIGlzPGJyPiZndDsgJmd0OyBhZGRyZXNzZWQgZWxzZXdoZXJlIGFuZCBpbiBsb3Qg bW9yZSB0ZXh0IHRoYW4gbmVlZGVkIGhlcmUuIFNvIGlmIHdlPGJyPiZndDsgJmd0OyB0YWtlIHRo ZSB3ZWlnaHQgYXMgYSBnaXZlbiwgaG9wZWZ1bGx5IHN0YWJsZSBlbm91Z2ggc2NhbGFyLCB0aGVu IHRoZTxicj4mZ3Q7ICZndDsgcmFuayBjb21wdXRhdGlvbiBpcyB0aGUgbW9zdCBjbGFzc2ljYWwg YWRkaXRpb24gb2Ygd2VpZ2h0ZWQgaG9wcy48YnI+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+Jmd0OyBCdXQgdGhlIGNvbnNlbnN1cywgd2hl biBkaXNjdXNzaW5nIE1SSE9GLCBpcyB0aGF0IGFuIG9iamVjdGl2ZTxicj5mdW5jdGlvbjxicj4m Z3Q7IHNwZWNpZmljYXRpb24gbmVlZHMgdG8gc2F5IGhvdyB0byBoYW5kbGUgYW5kIHVzZSBtZXRy aWNzLiBJdCBzZWVtczxicj5zdHJhbmdlPGJyPiZndDsgdGhhdCBPRjAgZG9lc24ndC4gT3IgZG9l cyBPRjAgaGF2ZSBhIHNwZWNpYWwgc3RhdHVzLCB0aGF0IGl0IGRvZXMgbm90PGJyPmhhdmUgdG88 YnI+Jmd0OyBmb2xsb3cgdGhlIHJlcXVpcmVtZW50cyBsYWlkIG91dCBmb3Igb2JqZWN0aXZlIGZ1 bmN0aW9uPGJyPnNwZWNpZmljYXRpb25zPzxicj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4mZ3Q7IE90aGVyd2lzZSB5b3UgY2FuIGhhdmUg aW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHdoaWNoIGFyZTxicj4mZ3Q7IGluY29tcGF0aWJs ZSBhbmQgY2F1c2UgcHJvYmxlbXM6IHRoaXMgd2FzIGR1ZSB0byBKUCdzIGluc2lzdGVuY2UgdGhh dDxicj4mZ3Q7IG9iamVjdGl2ZSBmdW5jdGlvbnMgcmVtYWluIG1ldHJpYy1pbmRlcGVuZGVudC4g V2hhdCB3b3JyaWVzIG1lIGFib3V0PGJyPnRoaXM8YnI+Jmd0OyBpcyB0aGF0IGl0IHNlZW1zIHRv IGp1c3QgYmxpbmRseSByZXBlYXQgbWlzdGFrZXMgdGhhdCBMTE4gcHJvdG9jb2xzPGJyPmhhdmU8 YnI+Jmd0OyBsZWFybmVkIGZyb20uIEUuZy4sIG1vZGVybiBPTFNSIGRlcGxveW1lbnRzIGRvIG5v dCBhZGhlcmUgdG8gdGhlIE9MU1I8YnI+Jmd0OyBzcGVjaWZpY2F0aW9uIGJlY2F1c2UgaXQgcmVx dWlyZXMgaG9wY291bnQgYW5kIGhvcGNvdW50IGRvZXMgbm90IHdvcms8YnI+dmVyeTxicj4mZ3Q7 IHdlbGwuIFlvdSdyZSByaWdodCwgdGhlcmUncyBsb3RzIG9mIGV4cGVyaWVuY2UgdXNpbmcgaG9w Y291bnQgYXMgYTxicj5tZXRyaWMuIEluPGJyPiZndDsgdGhlIGNvbnRleHQgb2YgTExOcywgaG93 ZXZlciwgdGhhdCBleHBlcmllbmNlIGhhcyBiZWVuIG5lZ2F0aXZlLjxicj4mZ3Q7PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4mZ3Q7ICZndDsgQ291 bGQgeW91IHBsZWFzZSBiZSBtb3JlIHNwZWNpZmljIGluIHdoYXQgeW91J2QgYWRkIHRvIHRoZSBz cGVjPzxicj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4mZ3Q7IEkgd291bGQgYWRkIGEgc3BlY2lmaWNhdGlvbiBvZiBob3cgT0YwIHRyYW5z bGF0ZXMgbWV0cmljcyBpbnRvIFJhbmsuPGJyPkUuZy4sIGFuPGJyPiZndDsgRVRYIGJldHdlZW4g MSBhbmQgMyBhZGRzIDEgdG8gUmFuaywgZXRjLjxicj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4mZ3Q7IFBoaWw8YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Um9sbCBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+Um9sbEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFu ayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PC9zcGFuPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlJvbGwgbWFpbGluZyBsaXN0PGJyPjxh IGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPlJvbGxAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgc3R5bGU9ImNvbG9yOiBibHVl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGw8L2E+PGJyPjwvZGl2Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9kaXY+ PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CB9EB4.1C6E2FA0-- From pthubert@cisco.com Sat Dec 18 05:23: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 57C963A6A00 for ; Sat, 18 Dec 2010 05:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.29 X-Spam-Level: X-Spam-Status: No, score=-10.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0J3YyAO2IJq for ; Sat, 18 Dec 2010 05:23:32 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 62C7C3A69FF for ; Sat, 18 Dec 2010 05:23:32 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADZFDE2rRDoJ/2dsb2JhbACkNHOhcZp7hUoEjh6IDw X-IronPort-AV: E=Sophos;i="4.60,193,1291593600"; d="scan'208";a="234766375" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2010 13:25:21 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBIDPKvh026140; Sat, 18 Dec 2010 13:25:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Dec 2010 14:25:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Dec 2010 14:24:54 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03704658@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueMbV3Rj59hfFXSdCc5pzG7KV9cAAftbDw References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 18 Dec 2010 13:25:19.0375 (UTC) FILETIME=[0403C1F0:01CB9EB7] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 13:23:33 -0000 > > Also there are wireless emulations around that provide an acceptable > > service and heavily deployed service, both P2P like military and > > satellite radios and transit, the most common being WIFI. >=20 > Wait -- are you asserting that WiFi has reliability and behavior equivalent to a > wired network? >=20 [Pascal]=20 802.11 infrastructure mode is inherently an emulation of Ethernet.=20 The service must be good enough considering its degree of adoption. Please refrain for rewording my sentences.=20 > > This is clearly not your world, but the fact is that we have had happy > > customers for over 10 years, using Spanning Tree or similar over > > wireless bridges. >=20 > Can you point me at some concrete examples? I'm not sure I understand the > logic: because hopcount has been OK for wireless bridges, we can ignore the > fact that it's been a problem in LLNs? I thought RPL is for LLNs. [Pascal]=20 RPL is more economical and will converge faster than spanning tree, because in the first it does not have to prevent meltdown at all cost. At some point, route over may supplant mesh under in a number of applications, including the most classical switching world. Now that we have RPL on the works, the main issue is not the lack of routing protocol but the lack of a vlan-equivalent tagging in the IPv6 header. > > > >> I would add a specification of how OF0 translates metrics into Rank. > > E.g., an > >> ETX between 1 and 3 adds 1 to Rank, etc. > > > > For OF0, the expected metric is an administrative cost that is > > trivially added up along a path; the most usual thing. > > OF 0 was designed to be that simple. This said, I can see 2 ways for > > moving forward with your suggestion: > > > > 1) We describe that the metric is a static (admin) cost range 1..16 > > and that it is placed in the most significant octet of the rank. > > > > 2) We decide to add support for a dynamic metric. In that case, we > > enter the discussion on stability, statistical dampening, and hysteresis. > > > > And obviously option 3 being both. > > > > I can easily accommodate 1) and republish. Text on 2) would have to be > > very vague, like a set of recommendation. > > > > I do not mind either way, both are probably useful. What does the > > group think? >=20 > I feel like you're ignoring the original comment. Let's try to separate my two > concerns. The first is that the OF0 draft does not follow the guidelines the > WG agreed on for objective functions: this is a process issue. The second is > what I believe is a technical issue, that OF0 seems like it does not meet a > standard of technical excellence. >=20 > For the first issue -- when MRHOF came up for discussion, we (as a WG) > agreed that objective functions should be metric-independent. To ensure > interoperability of different OF implementations, this means an OF needs to > specify with reasonable (but not complete) detail how it processes a metric > container. It sounds like your answer is that OF0 ignores a metric container. > This seems like a completely reasonable specification in terms of process, > given the expectations laid out for OFs. >=20 [Pascal] I'll propose some words along this line. Your summary is good. OF0 does not expect a metric container, and if there is one, it will ignore it. The result is that OF0 works when the link metric we care is additive and for can be transformed in a scalar 1..16. The simplest example is an administrative cost. The question to the group is whether we want to enter the discussion about dynamic metrics hysteresis and so on, or if we leave it at an assumption that the link metric is rather stable. > The second issue I guess we can disagree on. Maybe it would be helpful if > you could sketch a concrete RPL scenario -- maybe from one of the > application drafts -- where OF0 would be a good solution? That might help > ground this discussion. >=20 [Pascal] This is probably an interesting discussion. Then again, RPL does not have to be limited to what it was envisioned for. By design, OF0 leave a lot of liberty to the deployment as to which information is turn into the scalar hop cost, thus opens a wide scope of applications, not all in typical LLN environments. An example could be found in industrial, where we have the concept of a backbone, such as being studied at ISA100.15. The most common approaches for solve the backbone problem is a WIFI (.11a usually) mesh. At the moment, the WIFI mesh is by force 'mesh under' and the end-to-end path will suffer unless we teach RPL to the Mesh APs at the same time as we connect the RPL network to the mesh backbone. Pascal From d.sturek@att.net Sat Dec 18 06:15: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 70CF33A6A94 for ; Sat, 18 Dec 2010 06:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jREw+5TxlQV2 for ; Sat, 18 Dec 2010 06:15:00 -0800 (PST) Received: from smtp103-mob.biz.mail.ne1.yahoo.com (smtp103-mob.biz.mail.ne1.yahoo.com [98.138.88.240]) by core3.amsl.com (Postfix) with SMTP id 5AFC23A6A91 for ; Sat, 18 Dec 2010 06:15:00 -0800 (PST) Received: (qmail 42816 invoked from network); 18 Dec 2010 14:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292681806; bh=Qo2H03lAJbNdnvjydJju9XeMDU9WhNVGOU4McW7wEtw=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:References:Mime-Version:In-Reply-To:X-Apple-Yahoo-Original-Message-Folder:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:X-Apple-Yahoo-Replied-Msgid:Subject:Date:To; b=u1XzQWFfONX42S6Mg8zQo/NRyuvh+6QblkjLxpjiZrA+H4qtqauEa2IHhxCVLFhfEq875z8srs7XcPVO2vWKAgXdfjWbHQTDRptnkgdBHubiq+qXVun+843iG/uFsJwazMCWu/8xsVd228X/WJHoEcCSerJiKhvxzLb1qIB1lWU= Received: from [192.168.0.197] (d.sturek@69.224.190.151 with xymcookie) by smtp103-mob.biz.mail.ne1.yahoo.com with SMTP; 18 Dec 2010 06:16:42 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 3B98h7EVM1kZLK.4UbfwbQiIbz0irIObW3rEKGOuv0CJ3jg Eztsj8oayKGQHYjwcteg65jPuTKLQ.DvcAUEMFvnPD62q__CRjZNtzjyyAbk .ks7IboAu08EDSTQcu1FDyJ0PP88f9aUUcU6dt7mPnxuYb1E0t4lVSLedOCl l51c4Kv3N91ZgmHetnWsyl3x6y1X0LXIbLXx7Q2h8kBba.VRNxCX3ocL5Lpf 7kMj_Ys8Q4fsWT59D2GI0O._2xFhinKkSrg3ZO0ksOpNagxHQ5Cq6xDum1Ph mJjoAcmh803K5mDpUKv0RqcO8PVrXwflsuIzXmN8ISXSqPXpgufOstgnXI3P k4ydq X-Yahoo-Newman-Property: ymail-3 References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (iPad Mail 8C148) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> X-Mailer: iPad Mail (8C148) From: Don Sturek X-Apple-Yahoo-Replied-Msgid: 1_317570_AIPHjkQAAFsoTQyrYQ4o1nYw6ZI Date: Sat, 18 Dec 2010 06:18:48 -0800 To: "Pascal Thubert \(pthubert\)" Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 14:15:01 -0000 Hi pascal, What you wrote below in the last paragraph is wrong. In fact, it is not 2 D= ags that must be created but an order n number of Dags to cover any of the r= eturn paths to any of the nodes which could have generated a request. Don Sent from my iPad On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" wrote: > Again you've got your logic reversed. RPL was designed for LLNs, does > not mean that it has to be limited to anything as long as it works fine > there too.=20 >=20 > Second you'll find more and more low power / constrained devices in > both wired and wireless space, because as a trend we are controlling > more and wasting less. >=20 > Third, RPL by construction is a good routing protocol for certain > topologies that are inherently based on hub and spoke. I listed a number > in this thread already. Think dynamic overlays like VPNs for one. >=20 > Finally, OF0 may apply to asymmetric links if people are willing to run > 2 DAGs, one for the traffic up and one for the traffic down. Mixing > problems is a source of confusion. >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: Friday, December 17, 2010 10:32 PM >> To: Pascal Thubert (pthubert) >> Cc: Don Sturek; ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>=20 >>=20 >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> Don: >>>=20 >>> I listed a number of examples and none of them is PLC actually. >>> RPL is a routing protocol. There is no point in preventing its usage > on wired >> lines. >>>=20 >>=20 >> https://datatracker.ietf.org/wg/roll/charter/: >>=20 >> The Working Group is focused on routing issues for LLN. >>=20 >> Can you give me an example of a wired network that's an LLN where OF0 > is >> useful? >>=20 >> Phil From yoav@yitran.com Sat Dec 18 06:25: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 13E573A6AC5 for ; Sat, 18 Dec 2010 06:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.207, 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 vSgGypg5DOlQ for ; Sat, 18 Dec 2010 06:25:21 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 70E333A6AC3 for ; Sat, 18 Dec 2010 06:25:21 -0800 (PST) Received: from source ([209.85.214.45]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTQzEvgwC2RQ3O5eFJGzGqCKBTF1ao6JH@postini.com; Sat, 18 Dec 2010 06:27:11 PST Received: by bwz16 with SMTP id 16so2036112bwz.32 for ; Sat, 18 Dec 2010 06:27:09 -0800 (PST) Received: by 10.204.80.161 with SMTP id t33mr1755251bkk.121.1292682428859; Sat, 18 Dec 2010 06:27:08 -0800 (PST) From: Yoav Ben-Yehezkel References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> In-Reply-To: <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuevjm/pILXOo6gT0KQzqJiEyrBoQAAHDiw Date: Sat, 18 Dec 2010 16:25:54 +0200 Message-ID: <891346ff88ea9a4185d1eb896759dd49@mail.gmail.com> To: Don Sturek , "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 14:25:23 -0000 My understanding WRT a solution to the asymmetric links was that that RPL can settle with just one DAG by use of DAO messages that allows a bi-directional downwards route creation. Can that be considered a legit solution to asymmetric links a well? Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: Saturday, December 18, 2010 4:19 PM To: Pascal Thubert (pthubert) Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi pascal, What you wrote below in the last paragraph is wrong. In fact, it is not 2 Dags that must be created but an order n number of Dags to cover any of the return paths to any of the nodes which could have generated a request. Don Sent from my iPad On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" wrote: > Again you've got your logic reversed. RPL was designed for LLNs, does > not mean that it has to be limited to anything as long as it works fine > there too. > > Second you'll find more and more low power / constrained devices in > both wired and wireless space, because as a trend we are controlling > more and wasting less. > > Third, RPL by construction is a good routing protocol for certain > topologies that are inherently based on hub and spoke. I listed a number > in this thread already. Think dynamic overlays like VPNs for one. > > Finally, OF0 may apply to asymmetric links if people are willing to run > 2 DAGs, one for the traffic up and one for the traffic down. Mixing > problems is a source of confusion. > > Pascal > http://www.xtranormal.com/watch/7011357/ > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: Friday, December 17, 2010 10:32 PM >> To: Pascal Thubert (pthubert) >> Cc: Don Sturek; ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >> >>> Don: >>> >>> I listed a number of examples and none of them is PLC actually. >>> RPL is a routing protocol. There is no point in preventing its usage > on wired >> lines. >>> >> >> https://datatracker.ietf.org/wg/roll/charter/: >> >> The Working Group is focused on routing issues for LLN. >> >> Can you give me an example of a wired network that's an LLN where OF0 > is >> useful? >> >> Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Sat Dec 18 07:43: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 673703A6B04 for ; Sat, 18 Dec 2010 07:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQZct1EllvJZ for ; Sat, 18 Dec 2010 07:43:05 -0800 (PST) Received: from smtp112-mob.biz.mail.ac4.yahoo.com (smtp112-mob.biz.mail.ac4.yahoo.com [76.13.13.233]) by core3.amsl.com (Postfix) with SMTP id 2D5153A6B03 for ; Sat, 18 Dec 2010 07:43:05 -0800 (PST) Received: (qmail 91264 invoked from network); 18 Dec 2010 15:44:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1292687089; bh=U3YD+xtx4KNjhlLLjM7z8lPsEzC5A2xb7xUxTbiaT1M=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:References:Mime-Version:In-Reply-To:X-Apple-Yahoo-Original-Message-Folder:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:X-Apple-Yahoo-Replied-Msgid:Subject:Date:To; b=Dotp9aMeSms+I3eYp/3clwTmV7UCdf2i14Gz7vTj4C3spTTWgfZMqv2nk75U1E9wOq+5nVxS8ivoDUuuZym1Z/7o4wwsFzZ4fmprcM/f1YzAGzTYcGkRc0T0VuKLkrpuPoSl3+2FNah6YCfYN0rLHepPTtEqyBU8KWy69ThsQuA= Received: from [192.168.0.197] (d.sturek@69.226.24.162 with xymcookie) by smtp112-mob.biz.mail.ac4.yahoo.com with SMTP; 18 Dec 2010 07:44:45 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Tlc1tdMVM1mTAIiwP.zRE27N1YCrmFsqGTKhrxy1K06.IXu n0i_EaTil0OIhjE3J36wBHgcvu0o7B1Q7NQRB9MQuyktXi9wJvv3HzXbKnoC CBxX6yKF42RweC1upIBr22rap0Etln4jX7IRcOjk_BUO0DTHIktheMdoLK88 JWU3ezWSfsUEzq4vccguwMZRj5IYzoNvc8vt_GgyzqskMnYfVmbgxgl8590M tXDxVitr98t6x0NZ92hptXx9EXRjGQdiB5vZL1YIiESQc.FbM7Oe4QBJ_DpV xp7XRjeuQokfv4N8RR7k3i0CxVEreySIu9uRL1oIEvN1o_WsTxjd1sIhWIMQ CfmJhA5zN9tNtHniDvsdAzjnPiQCvlVQzknGtRuY- X-Yahoo-Newman-Property: ymail-3 References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <891346ff88ea9a4185d1eb896759dd49@mail.gmail.com> Mime-Version: 1.0 (iPad Mail 8C148) In-Reply-To: <891346ff88ea9a4185d1eb896759dd49@mail.gmail.com> X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3A3B828C-3A4C-42F2-8B9E-5BA69B8525CE@att.net> X-Mailer: iPad Mail (8C148) From: Don Sturek X-Apple-Yahoo-Replied-Msgid: 1_322394_AIjHjkQAALC7TQzEwQfVlhfPSK4 Date: Sat, 18 Dec 2010 07:46:51 -0800 To: Yoav Ben-Yehezkel Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 15:43:06 -0000 Hi yoav, True, however then you need some OF to handle asymmetric links. I think pa= scal proposes separate DAGs to handle that. Don Sent from my iPad On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel wrote: > My understanding WRT a solution to the asymmetric links was that that RPL > can settle with just one DAG by use of DAO messages that allows a > bi-directional downwards route creation. >=20 > Can that be considered a legit solution to asymmetric links a well? >=20 > Regards, > Yoav >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Don Sturek > Sent: Saturday, December 18, 2010 4:19 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > Hi pascal, >=20 > What you wrote below in the last paragraph is wrong. In fact, it is not 2= > Dags that must be created but an order n number of Dags to cover any of > the return paths to any of the nodes which could have generated a request.= >=20 > Don >=20 >=20 > Sent from my iPad >=20 > On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" > wrote: >=20 >> Again you've got your logic reversed. RPL was designed for LLNs, does >> not mean that it has to be limited to anything as long as it works fine >> there too. >>=20 >> Second you'll find more and more low power / constrained devices in >> both wired and wireless space, because as a trend we are controlling >> more and wasting less. >>=20 >> Third, RPL by construction is a good routing protocol for certain >> topologies that are inherently based on hub and spoke. I listed a number >> in this thread already. Think dynamic overlays like VPNs for one. >>=20 >> Finally, OF0 may apply to asymmetric links if people are willing to run >> 2 DAGs, one for the traffic up and one for the traffic down. Mixing >> problems is a source of confusion. >>=20 >> Pascal >> http://www.xtranormal.com/watch/7011357/ >>=20 >>> -----Original Message----- >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: Friday, December 17, 2010 10:32 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Don Sturek; ROLL WG >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>>=20 >>>=20 >>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >>>=20 >>>> Don: >>>>=20 >>>> I listed a number of examples and none of them is PLC actually. >>>> RPL is a routing protocol. There is no point in preventing its usage >> on wired >>> lines. >>>>=20 >>>=20 >>> https://datatracker.ietf.org/wg/roll/charter/: >>>=20 >>> The Working Group is focused on routing issues for LLN. >>>=20 >>> Can you give me an example of a wired network that's an LLN where OF0 >> is >>> useful? >>>=20 >>> Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Sat Dec 18 10: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 9784F3A6B6E for ; Sat, 18 Dec 2010 10:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=1.160, 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 4voh9NTi55u6 for ; Sat, 18 Dec 2010 10:11:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8C6AC3A6B77 for ; Sat, 18 Dec 2010 10:11:32 -0800 (PST) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id A5BED344AB; Sat, 18 Dec 2010 13:20:32 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D1AFB98561; Sat, 18 Dec 2010 13:13:21 -0500 (EST) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sat, 18 Dec 2010 13:13:21 -0500 Message-ID: <32104.1292696001@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 18:11:48 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> Third, RPL by construction is a good routing protocol for Pascal> certain topologies that are inherently based on hub and Pascal> spoke. I listed a number in this thread already. Think Pascal> dynamic overlays like VPNs for one. And let me tell you... VPNs are often really lossy, because they often break... -- ] 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 ntyangiri2@yahoo.com Sun Dec 19 18:14:08 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 7C7673A69B2 for ; Sun, 19 Dec 2010 18:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUCnUP6VEs11 for ; Sun, 19 Dec 2010 18:14:07 -0800 (PST) Received: from web37007.mail.mud.yahoo.com (web37007.mail.mud.yahoo.com [209.191.85.92]) by core3.amsl.com (Postfix) with SMTP id F3D9E3A69A8 for ; Sun, 19 Dec 2010 18:14:06 -0800 (PST) Received: (qmail 44602 invoked by uid 60001); 20 Dec 2010 02:15:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1292811356; bh=ny7+4NXhk27qoPP9U1CDUjxQV96L5HUE5Qql4KYt07c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ieu1ecl82/orrtAFEFLTO8iw+Eyj/tO34tYhXfVVKL9k6pvPhUOPqg7UY7EPMqj7S+GlbwHL6Sv620CYreVmVTAqhWQe2BRmPDNUuK2UqcVQ/T2kcPiNNuqxmQh4eLZBy3DTosky/IqLI5jadLtP4cL9Q19dGQikDjef5zMFA7w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Fi6MEBugTjkRSexA4+XJxWTcffbp1Wd5C/oQS219i7cyDAv0Slox5xDcVTEzI7Zb9HgHK0e/K+UghUvNj0MxEPu4vG7/TrEl3Pw4HPjo2VZ6LZB1t3NZ47CQgt+gvQ1q4qaD+J7AJXchLbmNe456nYic5qjgGGhla91WPm9Z+fs=; Message-ID: <638323.44590.qm@web37007.mail.mud.yahoo.com> X-YMail-OSG: BLALfmwVM1l5b8WSTtsUbUwo3JB4ayYXbCEQSHC9dupV_gh TlX5CBVbDCgE1TFi9kOfjDEUfcFvVucKrbAGD1DJYYwBxCP9JqnKHDyji1xq vBJw73L4BBUqsia1oSFMZjMPqGWYUl9jKAW.ClL3WadIGsZ4.rmCHPOG5N2l BtKMz6l1X6vehwH7yRQcsKtjNRKlv_Q06k2kQPnsx_g6aLRDfSA.cbgnt3qg thIBuOdnIXZIE7RLHlvxX9_sUWB7wHCBVpCP1APNtQtL5hZ9mbC4dXFlqpSi JcMdVTKwOC9tqkXLfLuxeaiOHC9spOyayyPtCkOpiltpg.MFrDLPKPk4ApoT 6CfeUHgmnYUJVr2vEICJw.RStfUHjv87RF.6G2hSstsKlq_86dmnjwphV8ge xmDOPHSjI2Ynt Received: from [221.186.82.163] by web37007.mail.mud.yahoo.com via HTTP; Sun, 19 Dec 2010 18:15:56 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <20101215230001.30256.8767.idtracker@localhost> <4D094A6F.6060102@acm.org> Date: Sun, 19 Dec 2010 18:15:56 -0800 (PST) From: Christopher Ntyangiri To: roll@ietf.org In-Reply-To: <4D094A6F.6060102@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-923204517-1292811356=:44590" Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 02:14:08 -0000 --0-923204517-1292811356=:44590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tim,=0A=0AI have=C2=A0a question regarding how to send=C2=A0PIO in RPL.=0A= =0AFrom "6.7.10.=C2=A0 Prefix Information" it has been clearly stated that= =0A=C2=A0=C2=A0 "The root of a DODAG is authoritative for setting that info= rmation.=0A=C2=A0=C2=A0 The information is propagated down the DODAG unchan= ged, with the=0A=C2=A0=C2=A0 exception that a RPL router may update (extend= ) the prefix by=0A=C2=A0=C2=A0 appending it's own suffix."=0A=C2=A0=0ANow, = in the appendix:=0AA.2. Example Operation in Storing Mode With Node-owned P= refixes=0AA.2.1. DIO messages and PIO=0ANode A, for example, will send DIO = messages with a PIO as follows:=0A=E2=80=99A=E2=80=99 flag: Set=0A=E2=80=99= L=E2=80=99 flag: Set=0A=E2=80=99R=E2=80=99 flag: Clear=0APrefix Length: 64= =0APrefix: A::=0A=0ANode B, for example, will send DIO messages with a PIO = as follows:=0A=E2=80=99A=E2=80=99 flag: Set=0A=E2=80=99L=E2=80=99 flag: Set= =0A=E2=80=99R=E2=80=99 flag: Set=0APrefix Length: 64=0APrefix: B::B=0A...= =0A=0AHere, Node B has completely changed the Prefix received from the Root= .=0AIs there something I don't understand?=0A=0AThanks in advance.=0A=0AChr= is.=0A=0A=0A=0A=0A________________________________=0AFrom: Tim Winter =0ATo: roll@ietf.org=0ASent: Thu, December 16, 2010 8:08:31 AM= =0ASubject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt=0A=0AWG,=0A=0A= With this revision we continue to address concerns brought up in IESG evalu= ation =0A=0A(https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/)=0A=0ARe= gards,=0A=0A-Tim=0A=0A=0AOn 12/15/2010 06:00 PM, Internet-Drafts@ietf.org w= rote:=0A> A New Internet-Draft is available from the on-line Internet-Draft= s =0Adirectories.=0A> This draft is a work item of the Routing Over Low pow= er and Lossy networks =0A>Working Group of the IETF.=0A>=0A>=0A> =C2=A0=C2= =A0=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : RPL: IPv6 Routing Proto= col for Low power and Lossy =0A>Networks=0A> =C2=A0=C2=A0=C2=A0 Author(s)= =C2=A0 =C2=A0 =C2=A0 : T. Winter, et al.=0A> =C2=A0=C2=A0=C2=A0 Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-roll-rpl-17.txt=0A> =C2=A0=C2=A0=C2= =A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 159=0A> =C2=A0=C2=A0=C2=A0 Da= te=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2010-12-15=0A>=0A> Low power = and Lossy Networks (LLNs) are a class of network in which=0A> both the rout= ers and their interconnect are constrained.=C2=A0 LLN routers=0A> typically= operate with constraints on processing power, memory, and=0A> energy (batt= ery power).=C2=A0 Their interconnects are characterized by=0A> high loss ra= tes, low data rates, and instability.=C2=A0 LLNs are comprised=0A> of anyth= ing from a few dozen and up to thousands of routers.=0A> Supported traffic = flows include point-to-point (between devices=0A> inside the LLN), point-to= -multipoint (from a central control point to=0A> a subset of devices inside= the LLN), and multipoint-to-point (from=0A> devices inside the LLN towards= a central control point).=C2=A0 This=0A> document specifies the IPv6 Routi= ng Protocol for LLNs (RPL), which=0A> provides a mechanism whereby multipoi= nt-to-point traffic from devices=0A> inside the LLN towards a central contr= ol point, as well as point-to-=0A> multipoint traffic from the central cont= rol point to the devices=0A> inside the LLN, is supported.=C2=A0 Support fo= r point-to-point traffic is=0A> also available.=0A>=0A> A URL for this Inte= rnet-Draft is:=0A> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-= 17.txt=0A>=0A> Internet-Drafts are also available by anonymous FTP at:=0A> = ftp://ftp.ietf.org/internet-drafts/=0A>=0A> Below is the data which will en= able a MIME compliant mail reader=0A> implementation to automatically retri= eve the ASCII version of the=0A> Internet-Draft.=0A>=0A>=0A>=0A> __________= _____________________________________=0A> Roll mailing list=0A> Roll@ietf.o= rg=0A> https://www.ietf.org/mailman/listinfo/roll=0A_______________________= ________________________=0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/roll=0A=0A=0A=0A --0-923204517-1292811356=:44590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Tim,
=0A
 
=0A
I have a qu= estion regarding how to send PIO in RPL.
=0A
 
=0A<= DIV>
=0A
   "The root of a DODAG is authoritative = for setting that information.
   The information is propagated= down the DODAG unchanged, with the
   exception that a RPL ro= uter may update (extend) the prefix by
   appending it's own s= uffix."
=0A

 

=0A

Now, in the appendix:

=0A
A.2. Example Operat= ion in Storing Mode With Node-owned Prefixes
=0A
A.2.1. DIO messag= es and PIO
=0A
Node A, for example, will send DIO messages with a = PIO as follows:
=E2=80=99A=E2=80=99 flag: Set
=E2=80=99L=E2=80=99 fla= g: Set
=E2=80=99R=E2=80=99 flag: Clear
Prefix Length: 64
Prefix: A= ::
=0A

Node B, for example, will send DIO messages with a PIO = as follows:
=E2=80=99A=E2=80=99 flag: Set
=E2=80=99L=E2=80=99 flag: S= et
=E2=80=99R=E2=80=99 flag: Set
Prefix Length: 64
Prefix: B::B=0A
=0A
...
=0A
 
=0A<= DIV>Here, Node B has completely changed the Prefix received from the Root.<= /DIV>=0A
Is there something I don't understand?
=0A
 =0A
Thanks in advance.
=0A
 
=0A
Chris.
=0A

=0A
=0A
=0AFrom: Tim Winter <wintert@acm= .org>
To: roll@ietf.o= rg
Sent: Thu, December 1= 6, 2010 8:08:31 AM
Subject:<= /B> Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

WG,
<= BR>With this revision we continue to address concerns brought up in IESG ev= aluation
(https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/<= /A>)

Regards,

-Tim


On 12/15/2010 06:00 PM, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is a= vailable from the on-line Internet-Drafts directories.
> This draft i= s a work item of the Routing Over Low power and Lossy networks Working Grou= p of the IETF.
>
>
>     Title    &n= bsp;     : RPL: IPv6 Routing Protocol for Low power and Lossy Net= works
>     Author(s)      : T. Winter,= et al.
>     Filename        : dr= aft-ietf-roll-rpl-17.txt
>     Pages    &nbs= p;     : 159
>     Date      =       : 2010-12-15
>
> Low power and Lossy Netwo= rks (LLNs) are a class of network in which
> both the routers and the= ir interconnect are constrained.  LLN routers
> typically operat= e with constraints on processing power, memory, and
> energy (battery= power).  Their interconnects are characterized by
> high loss r= ates, 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
> in= side 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 i= s:
> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt>
> Internet-Drafts are also available by anonymous FTP at:
&= gt; ftp://ftp.ietf.org/internet-drafts/
>
> Be= low is the data which will enable a MIME compliant mail reader
> impl= ementation to automatically retrieve the ASCII version of the
> Inter= net-Draft.
>
>
>
> ________________________________= _______________
> Roll mailing list
> Roll@ietf.org
> https://www= .ietf.org/mailman/listinfo/roll
____________________________________= ___________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/li= stinfo/roll

=0A=0A=0A=0A=0A=0A=0A=0A --0-923204517-1292811356=:44590-- From ntyangiri2@yahoo.com Sun Dec 19 19:14: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 E0FA23A69AA for ; Sun, 19 Dec 2010 19:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O1fd4Db0kTV for ; Sun, 19 Dec 2010 19:14:50 -0800 (PST) Received: from web37001.mail.mud.yahoo.com (web37001.mail.mud.yahoo.com [209.191.85.86]) by core3.amsl.com (Postfix) with SMTP id BA81F3A6931 for ; Sun, 19 Dec 2010 19:14:49 -0800 (PST) Received: (qmail 56450 invoked by uid 60001); 20 Dec 2010 03:16:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1292814997; bh=nyJdkGtBzH+MhDYS9owyo90RSF2JstntXrTQn8tkSWo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=D7z2lMVvPZomOIP200qI7Stl0zNeIEhxBoqM76nXORiw2dO6XxicCYXz7AadnWbTszGqqRsZce5LahcHyy2ejfAi3sdfFy+H00Wfp8gDJPJDX90eDRXB7yuugwNKs+z16x7ImApAFcLp3/dCbhkL8RlSZnoDH+/DuxOoys0YlWM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tjdyrI2US842TKggdEepp4hHzY7sm5INkDDdFqrYkUpDacZ3IKEAlEzp5TdosVhS3sjkHKDjz82ap9wVVZni2KNIGTfn/ykyoptASw3XRHelOFSR2RUWJuq00Rb2ACffmJd5tiymbavC4pQzgIKBRJUL7+W+yxvd7ehkVo0GKyI=; Message-ID: <909236.41392.qm@web37001.mail.mud.yahoo.com> X-YMail-OSG: ViJ4UyYVM1m5U3wWQ7mNVnIVDAxg3p_mcT8JCYGUfhUO9UA ygaBy86sIO8qvXZk7mTDarYLnfoA_UGi5Z.9Ba1CAkucKqkOulvlKCdC0b2z Ovvd7WXmNDo_b3g5v2YdgjWKotoHjnUEr4_ZbOEWfw8p8rR6cF.dW.YoBtsv 0Zu2AH9vxqV6aSEt5OY3vPUhc9OQpj_JLILJbz.5ZzHxhudRBWnmzsjyBAl1 7zUgXWXTL5gHoDKggZ5xjBGSCXqfHqYbjaHOcm.LjXUw8NvPviRn8gv5k6wH .6P6r4BDkD1.ZpTwI.7wglaIyYppbdY4brlPrtOkio6QMLkosOID1FcLl0QK q7Ri4nPGnjGll80zS9Ol74HEkaXJ5QiEQwjG4NpgWzc.Z6T_lsaLn8OrMTnl jcwPuhosE4Cer Received: from [221.186.82.163] by web37001.mail.mud.yahoo.com via HTTP; Sun, 19 Dec 2010 19:16:37 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <20101215230001.30256.8767.idtracker@localhost> <4D094A6F.6060102@acm.org> <638323.44590.qm@web37007.mail.mud.yahoo.com> Date: Sun, 19 Dec 2010 19:16:37 -0800 (PST) From: Christopher Ntyangiri To: roll@ietf.org In-Reply-To: <638323.44590.qm@web37007.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1540602698-1292814997=:41392" Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 03:14:52 -0000 --0-1540602698-1292814997=:41392 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To elaborate more.=0AI can see there is an exception when the PIO's =C2=A0L= flag is set.=0AThat is the "L" flag distinguish between <1> Subnet-wide Pr= efix=0Aand <2>Node-owned Prefixes.=0A=0AWouldn't it be better to elaborate = this as another exception in =0A"6.7.10.=C2=A0 Prefix Information". Or add = the words "For Subnet-wide Prefix "=0Aas below.=0A=C2=A0=0AFrom "6.7.10.=C2= =A0 Prefix Information" it has been clearly stated that=0A=C2=A0=C2=A0 "For= Subnet-wide Prefix the root of a DODAG is authoritative for setting that = =0Ainformation.=0A=C2=A0=C2=A0 The information is propagated down the DODAG= unchanged, with the=0A=C2=A0=C2=A0 exception that a RPL router may update = (extend) the prefix by=0A=C2=A0=C2=A0 appending it's own suffix."=0A=C2=A0= =0A=C2=A0=0AChris.=0A=0A=0A=0A=0A________________________________=0AFrom: C= hristopher Ntyangiri =0ATo: roll@ietf.org=0ASent: Mon= , December 20, 2010 11:15:56 AM=0ASubject: Re: [Roll] I-D Action:draft-ietf= -roll-rpl-17.txt=0A=0A=0ATim,=0A=0AI have=C2=A0a question regarding how to = send=C2=A0PIO in RPL.=0A=0AFrom "6.7.10.=C2=A0 Prefix Information" it has b= een clearly stated that=0A=C2=A0=C2=A0 "The root of a DODAG is authoritativ= e for setting that information.=0A=C2=A0=C2=A0 The information is propagate= d down the DODAG unchanged, with the=0A=C2=A0=C2=A0 exception that a RPL ro= uter may update (extend) the prefix by=0A=C2=A0=C2=A0 appending it's own su= ffix."=0A=C2=A0=0ANow, in the appendix:=0AA.2. Example Operation in Storing= Mode With Node-owned Prefixes=0AA.2.1. DIO messages and PIO=0ANode A, for = example, will send DIO messages with a PIO as follows:=0A=E2=80=99A=E2=80= =99 flag: Set=0A=E2=80=99L=E2=80=99 flag: Set=0A=E2=80=99R=E2=80=99 flag: C= lear=0APrefix Length: 64=0APrefix: A::=0A=0ANode B, for example, will send = DIO messages with a PIO as follows:=0A=E2=80=99A=E2=80=99 flag: Set=0A=E2= =80=99L=E2=80=99 flag: Set=0A=E2=80=99R=E2=80=99 flag: Set=0APrefix Length:= 64=0APrefix: B::B=0A...=0A=0AHere, Node B has completely changed the Prefi= x received from the Root.=0AIs there something I don't understand?=0A=0ATha= nks in advance.=0A=0AChris.=0A=0A=0A=0A=0A________________________________= =0AFrom: Tim Winter =0ATo: roll@ietf.org=0ASent: Thu, Dece= mber 16, 2010 8:08:31 AM=0ASubject: Re: [Roll] I-D Action:draft-ietf-roll-r= pl-17.txt=0A=0AWG,=0A=0AWith this revision we continue to address concerns = brought up in IESG evaluation =0A=0A(https://datatracker.ietf.org/doc/draft= -ietf-roll-rpl/)=0A=0ARegards,=0A=0A-Tim=0A=0A=0AOn 12/15/2010 06:00 PM, In= ternet-Drafts@ietf.org wrote:=0A> A New Internet-Draft is available from th= e on-line Internet-Drafts =0Adirectories.=0A> This draft is a work item of = the Routing Over Low power and Lossy networks =0A>Working Group of the IETF= .=0A>=0A>=0A> =C2=A0=C2=A0=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = RPL: IPv6 Routing Protocol for Low power and Lossy =0A>Networks=0A> =C2=A0= =C2=A0=C2=A0 Author(s)=C2=A0 =C2=A0 =C2=A0 : T. Winter, et al.=0A> =C2=A0= =C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-roll-rpl-17.t= xt=0A> =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 159=0A>= =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2010-12= -15=0A>=0A> Low power and Lossy Networks (LLNs) are a class of network in w= hich=0A> both the routers and their interconnect are constrained.=C2=A0 LLN= routers=0A> typically operate with constraints on processing power, memory= , and=0A> energy (battery power).=C2=A0 Their interconnects are characteriz= ed by=0A> high loss rates, low data rates, and instability.=C2=A0 LLNs are = comprised=0A> of anything from a few dozen and up to thousands of routers.= =0A> Supported traffic flows include point-to-point (between devices=0A> in= side the LLN), point-to-multipoint (from a central control point to=0A> a s= ubset of devices inside the LLN), and multipoint-to-point (from=0A> devices= inside the LLN towards a central control point).=C2=A0 This=0A> document s= pecifies the IPv6 Routing Protocol for LLNs (RPL), which=0A> provides a mec= hanism whereby multipoint-to-point traffic from devices=0A> inside the LLN = towards a central control point, as well as point-to-=0A> multipoint traffi= c from the central control point to the devices=0A> inside the LLN, is supp= orted.=C2=A0 Support for point-to-point traffic is=0A> also available.=0A>= =0A> A URL for this Internet-Draft is:=0A> http://www.ietf.org/internet-dra= fts/draft-ietf-roll-rpl-17.txt=0A>=0A> Internet-Drafts are also available b= y anonymous FTP at:=0A> ftp://ftp.ietf.org/internet-drafts/=0A>=0A> Below i= s the data which will enable a MIME compliant mail reader=0A> implementatio= n to automatically retrieve the ASCII version of the=0A> Internet-Draft.=0A= >=0A>=0A>=0A> _______________________________________________=0A> Roll mail= ing list=0A> Roll@ietf.org=0A> https://www.ietf.org/mailman/listinfo/roll= =0A_______________________________________________=0ARoll mailing list=0ARo= ll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A=0A=0A --0-1540602698-1292814997=:41392 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
= --Apple-Mail-13-1014493128-- From pal@cs.stanford.edu Mon Dec 20 08:20: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 AB9B93A6801 for ; Mon, 20 Dec 2010 08:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3MGqmGHz2h3 for ; Mon, 20 Dec 2010 08:19:59 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A75CF3A67F9 for ; Mon, 20 Dec 2010 08:19:59 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PUiUj-0002rt-E1; Mon, 20 Dec 2010 08:21:53 -0800 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03704658@XMB-AMS-107.cisco.com> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03704658@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45702464-26A4-4E63-85B6-30A577157875@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 20 Dec 2010 08:21:32 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 56af2f4f3392d0c6288551f912431bb1 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 16:20:00 -0000 On Dec 18, 2010, at 5:24 AM, Pascal Thubert (pthubert) wrote: > >>> Also there are wireless emulations around that provide an acceptable >>> service and heavily deployed service, both P2P like military and >>> satellite radios and transit, the most common being WIFI. >> >> Wait -- are you asserting that WiFi has reliability and behavior > equivalent to a >> wired network? >> > > [Pascal] > 802.11 infrastructure mode is inherently an emulation of Ethernet. > The service must be good enough considering its degree of adoption. > Please refrain for rewording my sentences. I apologize if I reworded; I was trying to understand what you were saying. When you say "wireless emulations that provide an acceptable service," what do you mean? It's well understood that a multihop wireless network and a single-hop wireless access network behave very differently. It's also well understood that wireless networks in unlicensed spectra (e.g., WiFi) behave very differently than those in licensed spectra (satellite, military). > >>> This is clearly not your world, but the fact is that we have had > happy >>> customers for over 10 years, using Spanning Tree or similar over >>> wireless bridges. >> >> Can you point me at some concrete examples? I'm not sure I understand > the >> logic: because hopcount has been OK for wireless bridges, we can > ignore the >> fact that it's been a problem in LLNs? I thought RPL is for LLNs. > > [Pascal] > RPL is more economical and will converge faster than spanning tree, > because in the first it does not have to prevent meltdown at all cost. > At some point, route over may supplant mesh under in a number of > applications, including the most classical switching world. > Now that we have RPL on the works, the main issue is not the lack of > routing protocol but the lack of a vlan-equivalent tagging in the IPv6 > header. I'm sorry, I again still don't understand. I was asking for references for technologies that build spanning trees over wireless bridges. I was assuming by "wireless bridge" you mean "repeater?" Given standard WiFi association algorithms, building a spanning tree that includes wireless APs is not particularly difficult, nor does it encounter the challenges of wireless. > >>> >>>> I would add a specification of how OF0 translates metrics into > Rank. >>> E.g., an >>>> ETX between 1 and 3 adds 1 to Rank, etc. >>> >>> For OF0, the expected metric is an administrative cost that is >>> trivially added up along a path; the most usual thing. >>> OF 0 was designed to be that simple. This said, I can see 2 ways > for >>> moving forward with your suggestion: >>> >>> 1) We describe that the metric is a static (admin) cost range 1..16 >>> and that it is placed in the most significant octet of the rank. >>> >>> 2) We decide to add support for a dynamic metric. In that case, we >>> enter the discussion on stability, statistical dampening, and > hysteresis. >>> >>> And obviously option 3 being both. >>> >>> I can easily accommodate 1) and republish. Text on 2) would have to > be >>> very vague, like a set of recommendation. >>> >>> I do not mind either way, both are probably useful. What does the >>> group think? >> >> I feel like you're ignoring the original comment. Let's try to > separate my two >> concerns. The first is that the OF0 draft does not follow the > guidelines the >> WG agreed on for objective functions: this is a process issue. The > second is >> what I believe is a technical issue, that OF0 seems like it does not > meet a >> standard of technical excellence. >> >> For the first issue -- when MRHOF came up for discussion, we (as a >> WG) >> agreed that objective functions should be metric-independent. To > ensure >> interoperability of different OF implementations, this means an OF > needs to >> specify with reasonable (but not complete) detail how it processes a > metric >> container. It sounds like your answer is that OF0 ignores a metric > container. >> This seems like a completely reasonable specification in terms of > process, >> given the expectations laid out for OFs. >> > [Pascal] I'll propose some words along this line. Your summary is > good. > OF0 does not expect a metric container, and if there is one, it will > ignore it. > The result is that OF0 works when the link metric we care is additive > and for can be transformed in a scalar 1..16. The simplest example > is an > administrative cost. > The question to the group is whether we want to enter the discussion > about dynamic metrics hysteresis and so on, or if we leave it at an > assumption that the link metric is rather stable. I feel like we've come around full circle. I originally argued against the Rank/Metric distinction (as did many others), feeling like one of the two was sufficient for >90% of uses. You argued strongly that having both was critical. But now you're proposing an objective function that ignores metrics? > >> The second issue I guess we can disagree on. Maybe it would be >> helpful > if >> you could sketch a concrete RPL scenario -- maybe from one of the >> application drafts -- where OF0 would be a good solution? That might > help >> ground this discussion. >> > [Pascal] This is probably an interesting discussion. Then again, RPL > does not have to be limited to what it was envisioned for. Correct. But *we* are limited to what we're chartered for. Given that OF0, as described, seems like it is not useful in LLNs, I don't understand why it's being discussed. To repeat my question -- can you please sketch a concrete RPL scenario, from one of the application drafts, where one would use OF0? Otherwise this seems like we're getting way ahead of ourselves: the first objective function is one that's useless for the domain RPL was designed for. One more concrete suggestion: given the confusion over whether OF0 is the "default" objective function, I suggest that it have a different name, such as OFNM, for Objective Function No Metrics. Phil From stoleru@cse.tamu.edu Mon Dec 20 23:21: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 86D5A3A69BC for ; Mon, 20 Dec 2010 23:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdQhOZg7-LaJ for ; Mon, 20 Dec 2010 23:21:23 -0800 (PST) Received: from smtp.cs.tamu.edu (postal.cs.tamu.edu [128.194.138.107]) by core3.amsl.com (Postfix) with ESMTP id 649D43A69A6 for ; Mon, 20 Dec 2010 23:21:23 -0800 (PST) Received: from [128.194.143.227] (radu-pc.cs.tamu.edu [128.194.143.227]) by smtp.cs.tamu.edu (Postfix) with ESMTP id D58ED1905F0 for ; Tue, 21 Dec 2010 01:23:18 -0600 (CST) Message-ID: <4D1055EB.9040003@cse.tamu.edu> Date: Tue, 21 Dec 2010 01:23:23 -0600 From: Radu Stoleru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] ACM Conference on Embedded Networked Sensor Systems (SenSys) 2012 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2010 07:21:23 -0000 Dear Sensys Community: Sensys 2012 will be held in North America. We are now soliciting formal proposals for hosting the event. Please include the following in any submitted proposal. - Details of the proposed venue - exact location - Size and configuration of main auditorium for the conference itself. Pictures are helpful. - Size and configuration of demo/poster area. Since the demo/poster session is a major feature of this conference, it is important to ensure that we will be able to get a good space for this, with power, WiFi, etc. Pictures are helpful. - We anticipate having about 3 collocated workshops with SenSys, either immediately before or after the event, with around 60 participants each. Information on where these would be held would be helpful. - Accommodation information and estimated price range. If accommodation is not local to the conference itself, how local transportation would be handled. - Travel information: Air connections to major cities, approximate airfare from major cities on US East Coast, West Coast, Europe, and Asia. Any other expected travel expenses from the airport to the conference site. - Details on proposed banquet/other meals and any other activities - Information on who would handle local arrangements - Any other information to make the case, why it's a good venue, local interest, etc. - We do not need a detailed budget at this time, though it may be good to estimate costs for the venue so we can consider how it will impact the overall conference budget. Please send completed proposals to stankovic@cs.virginia.edu The proposals should be received no later than Feb 15, 2011 Jack Stankovic Chair, Steering Committee From pthubert@cisco.com Wed Dec 22 04:02: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 1381A3A6B61 for ; Wed, 22 Dec 2010 04:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fm1NOMQlkdl for ; Wed, 22 Dec 2010 04:02:12 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6B7D33A6AC1 for ; Wed, 22 Dec 2010 04:02:12 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAl4EU2Q/khNgWdsb2JhbACkFRYBFiIkpymbU4VJBI4n X-IronPort-AV: E=Sophos;i="4.60,212,1291593600"; d="scan'208";a="15741663" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Dec 2010 12:04:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBMC49jk025995; Wed, 22 Dec 2010 12:04:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 13:04:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Dec 2010 13:04:09 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> In-Reply-To: <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: Acuevjjg9wVbct/GSs2J62KCUBtfHwCel/Rw References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> From: "Pascal Thubert (pthubert)" To: "Don Sturek" X-OriginalArrivalTime: 22 Dec 2010 12:04:09.0619 (UTC) FILETIME=[5710F630:01CBA1D0] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:02:14 -0000 Hi Don: You lost me. What is n? Why do you need many DAGs? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: Saturday, December 18, 2010 3:19 PM > To: Pascal Thubert (pthubert) > Cc: Philip Levis; ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > Hi pascal, >=20 > What you wrote below in the last paragraph is wrong. In fact, it is not 2 Dags > that must be created but an order n number of Dags to cover any of the > return paths to any of the nodes which could have generated a request. >=20 > Don >=20 >=20 > Sent from my iPad >=20 > On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" > wrote: >=20 > > Again you've got your logic reversed. RPL was designed for LLNs, does > > not mean that it has to be limited to anything as long as it works > > fine there too. > > > > Second you'll find more and more low power / constrained devices in > > both wired and wireless space, because as a trend we are controlling > > more and wasting less. > > > > Third, RPL by construction is a good routing protocol for certain > > topologies that are inherently based on hub and spoke. I listed a > > number in this thread already. Think dynamic overlays like VPNs for one. > > > > Finally, OF0 may apply to asymmetric links if people are willing to > > run > > 2 DAGs, one for the traffic up and one for the traffic down. Mixing > > problems is a source of confusion. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > >> -----Original Message----- > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > >> Sent: Friday, December 17, 2010 10:32 PM > >> To: Pascal Thubert (pthubert) > >> Cc: Don Sturek; ROLL WG > >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >> > >> > >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: > >> > >>> Don: > >>> > >>> I listed a number of examples and none of them is PLC actually. > >>> RPL is a routing protocol. There is no point in preventing its usage > > on wired > >> lines. > >>> > >> > >> https://datatracker.ietf.org/wg/roll/charter/: > >> > >> The Working Group is focused on routing issues for LLN. > >> > >> Can you give me an example of a wired network that's an LLN where OF0 > > is > >> useful? > >> > >> Phil From pthubert@cisco.com Wed Dec 22 04:37:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BA63A69DB for ; Wed, 22 Dec 2010 04:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbFrocllAUyD for ; Wed, 22 Dec 2010 04:37:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 974163A6843 for ; Wed, 22 Dec 2010 04:37:36 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOAEU2tJV2Y/2dsb2JhbACkFXOnOJtJhUkEjieIDw X-IronPort-AV: E=Sophos;i="4.60,212,1291593600"; d="scan'208";a="195923810" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 22 Dec 2010 12:39:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id oBMCdWIC020308; Wed, 22 Dec 2010 12:39:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 13:39:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Dec 2010 13:39:26 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D037A6D27@XMB-AMS-107.cisco.com> In-Reply-To: <45702464-26A4-4E63-85B6-30A577157875@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcugYglL9MR/L70CTh6LC12lYAslzABbz3Ig References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03704658@XMB-AMS-107.cisco.com> <45702464-26A4-4E63-85B6-30A577157875@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 22 Dec 2010 12:39:31.0796 (UTC) FILETIME=[47FB7940:01CBA1D5] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:37:38 -0000 > > [Pascal] > > 802.11 infrastructure mode is inherently an emulation of Ethernet. > > The service must be good enough considering its degree of adoption. > > Please refrain for rewording my sentences. >=20 > I apologize if I reworded; I was trying to understand what you were saying. > When you say "wireless emulations that provide an acceptable service," > what do you mean? It's well understood that a multihop wireless network > and a single-hop wireless access network behave very differently. It's also > well understood that wireless networks in unlicensed spectra (e.g., WiFi) > behave very differently than those in licensed spectra (satellite, military). >=20 >=20 [Pascal] I think we agree there.=20 This discussion has wandered in the field of RPL's applicability. Maybe that piece should be separated from the finalization of the OF0 draft. I am trying to attract your attention on the mixed wireless and wired backbone networks, on which spanning tree is being utilized. I think that RPL could be an interesting alternate in a number of cases. >=20 > > > >>> This is clearly not your world, but the fact is that we have had > > happy > >>> customers for over 10 years, using Spanning Tree or similar over > >>> wireless bridges. > >> > >> Can you point me at some concrete examples? I'm not sure I understand > > the > >> logic: because hopcount has been OK for wireless bridges, we can > > ignore the > >> fact that it's been a problem in LLNs? I thought RPL is for LLNs. > > > > [Pascal] > > RPL is more economical and will converge faster than spanning tree, > > because in the first it does not have to prevent meltdown at all cost. > > At some point, route over may supplant mesh under in a number of > > applications, including the most classical switching world. > > Now that we have RPL on the works, the main issue is not the lack of > > routing protocol but the lack of a vlan-equivalent tagging in the IPv6 > > header. >=20 > I'm sorry, I again still don't understand. I was asking for references for > technologies that build spanning trees over wireless bridges. I was assuming > by "wireless bridge" you mean "repeater?" [Pascal]=20 [Pascal] Hum, no. Google would be your friend here. A wireless bridge is actually a split bridge using wireless to connect 2 wired segments. Like a good old aironet 350. But then again we're straying. The point I want to make is that there are some real and deployed networks were a radio is designed to connect to another radio.=20 In such an network, the end points are positioned optimally to obtain an acceptable service. For a network administrator, this link is equivalent to a wire. > Given standard WiFi association algorithms, building a spanning tree that > includes wireless APs is not particularly difficult, nor does it encounter the > challenges of wireless. >=20 >=20 =20 > I feel like we've come around full circle. I originally argued against the > Rank/Metric distinction (as did many others), feeling like one of the two was > sufficient for >90% of uses. You argued strongly that having both was critical. > But now you're proposing an objective function that ignores metrics? >=20 [Pascal] Fun isn't it. But no we have NOT switched sides : ) I still think that separating the metrics and the rank is a fundamental design point in RPL and I'll defend it to the end. At the same time, people (including you) came asking for something simpler: - What if I do not have metrics that my various implementations all understand? - What if propagating all those metrics is too costly? - What if my case is so simple that propagating those metrics is overkill (eg wire) OF 0 serves that need. It will work if the hop metric can be changed in a stable additive integer between 1 and 16. > >> > > [Pascal] This is probably an interesting discussion. Then again, RPL > > does not have to be limited to what it was envisioned for. >=20 > Correct. But *we* are limited to what we're chartered for. Given that OF0, as > described, seems like it is not useful in LLNs, I don't understand why it's being > discussed. To repeat my question -- can you please sketch a concrete RPL > scenario, from one of the application drafts, where one would use OF0? > Otherwise this seems like we're getting way ahead of ourselves: the first > objective function is one that's useless for the domain RPL was designed for. >=20 > One more concrete suggestion: given the confusion over whether OF0 is the > "default" objective function, I suggest that it have a different name, such as > OFNM, for Objective Function No Metrics. >=20 [Pascal]=20 OF 0 is not the default OF (there none). But is it the last resort, when nothing else is either available or needed. The 0 indicates the absolute minimalistic aspect of that OF. Like a 0 in a soda name as opposed to a default. I'll glad to add words from this discussion and be very specific about this. Now, people have been used to that name and changing might increase the confusion, wouldn't you think? Let's see what other people say. If we decide to change, I tend to favor LROF (Last Resort OF). Pascal > Phil From d.sturek@att.net Wed Dec 22 05:25: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 8B44F3A6B61 for ; Wed, 22 Dec 2010 05:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYyL7LFI1PCs for ; Wed, 22 Dec 2010 05:25:06 -0800 (PST) Received: from nm24-vm0.bullet.mail.ne1.yahoo.com (nm24-vm0.bullet.mail.ne1.yahoo.com [98.138.90.34]) by core3.amsl.com (Postfix) with SMTP id 0B4CC3A6B68 for ; Wed, 22 Dec 2010 05:25:06 -0800 (PST) Received: from [98.138.90.49] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 22 Dec 2010 13:27:01 -0000 Received: from [98.138.89.172] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 22 Dec 2010 13:27:01 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 22 Dec 2010 13:27:01 -0000 X-Yahoo-Newman-Id: 214596.77268.bm@omp1028.mail.ne1.yahoo.com Received: (qmail 95088 invoked from network); 22 Dec 2010 13:27:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1293024421; bh=y6fGVkWb/5JZ1X+brzJZZlHC2axFLYDBwV3qbqvxyk4=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=XQo4Nopc3EIPszw5D2OiH5n0SE8WHMH51sXsla1IBIn3+LSSYd86clOgvuq0KomwWMA664PnvVwn6DM3IVPWXKtL6+1G4ai5aHXj5uK4ACjURTsqc5Ej1NHbvr07S++vwVDRP1Pci45bcVr7oAOnzERq7ptHk6Lzcf19M8/Y55c= Received: from Studio (d.sturek@69.224.190.29 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 22 Dec 2010 05:26:57 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: w5NfvysVM1lYNplkGCn5u315gnDlaC1Wch5YWOWoyZnbfGe 7NG.nqaa5Wi0v7KhT9WAfVZjJp4Q71_3YenERUSNP5BKhuvQRN5fqafQkL7A hOzMZgkwUT_.o751CexAunsFpmHCook1W5lwxXT6GFDAzD0rXOqZwufoJxBa hhBZjfNPx5sxgNhxJ_1j56DaT4ay2F3ixWmwzcReb39.tnhl7IwudVWYuTE5 w8Z1vyL_P5RLYjOTFrywKX6yaLHyrlzVJhWOlEGrgF0TOk44Vv67suLkSQ16 .n7.MD3MMLOabZTM_7p_3a89PtF3SobQw1XgP3oRW7_mreOOeWMLlvd.Hvea xLUtW X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> Date: Wed, 22 Dec 2010 05:26:55 -0800 Message-ID: <007501cba1db$e7795770$b66c0650$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuevjjg9wVbct/GSs2J62KCUBtfHwCel/RwACjF4EA= Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 13:25:07 -0000 Hi Pascal, I think my point below is we cannot set up separate DAGs to overcome the issue of not having a way of dealing with asymmetric links (which will occur). I believe we need a meaningful OF to deal with filtering out asymmetric links within a single DAG. Don -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, December 22, 2010 4:04 AM To: Don Sturek Cc: Philip Levis; ROLL WG Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Don: You lost me. What is n? Why do you need many DAGs? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: Saturday, December 18, 2010 3:19 PM > To: Pascal Thubert (pthubert) > Cc: Philip Levis; ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > Hi pascal, > > What you wrote below in the last paragraph is wrong. In fact, it is not 2 Dags > that must be created but an order n number of Dags to cover any of the > return paths to any of the nodes which could have generated a request. > > Don > > > Sent from my iPad > > On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" > wrote: > > > Again you've got your logic reversed. RPL was designed for LLNs, does > > not mean that it has to be limited to anything as long as it works > > fine there too. > > > > Second you'll find more and more low power / constrained devices in > > both wired and wireless space, because as a trend we are controlling > > more and wasting less. > > > > Third, RPL by construction is a good routing protocol for certain > > topologies that are inherently based on hub and spoke. I listed a > > number in this thread already. Think dynamic overlays like VPNs for one. > > > > Finally, OF0 may apply to asymmetric links if people are willing to > > run > > 2 DAGs, one for the traffic up and one for the traffic down. Mixing > > problems is a source of confusion. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > >> -----Original Message----- > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > >> Sent: Friday, December 17, 2010 10:32 PM > >> To: Pascal Thubert (pthubert) > >> Cc: Don Sturek; ROLL WG > >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >> > >> > >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: > >> > >>> Don: > >>> > >>> I listed a number of examples and none of them is PLC actually. > >>> RPL is a routing protocol. There is no point in preventing its usage > > on wired > >> lines. > >>> > >> > >> https://datatracker.ietf.org/wg/roll/charter/: > >> > >> The Working Group is focused on routing issues for LLN. > >> > >> Can you give me an example of a wired network that's an LLN where OF0 > > is > >> useful? > >> > >> Phil From Matteo.Paris@ember.com Wed Dec 22 08:12:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE463A6B83 for ; Wed, 22 Dec 2010 08:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIqVFKEVo7SH for ; Wed, 22 Dec 2010 08:12:35 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4E3613A6ACA for ; Wed, 22 Dec 2010 08:12:35 -0800 (PST) Received: from [192.168.81.108] ([192.168.81.108]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 11:14:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <007501cba1db$e7795770$b66c0650$@sturek@att.net> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> <007501cba1db$e7795770$b66c0650$@sturek@att.net> Date: Wed, 22 Dec 2010 11:14:31 -0500 To: d.sturek@att.net, "'Pascal Thubert \(pthubert\)'" From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 22 Dec 2010 16:14:33.0229 (UTC) FILETIME=[51D5EBD0:01CBA1F3] Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:12:36 -0000 Hi Don and Pascal, As RPL is currently designed, asymmetric links are a link layer issue, not a RPL issue. Any DIO received on a unidirectional link should be dropped and not processed further by the OF. If a link is highly asymmetric (one direction is poor), then that link will provide poor performance regardless of which direction traffic is flowing. The link layer will take this into account by assigning it a poor metric value. The OF doesn't need to take any special action. Whether a link has a poor metric value because it is asymmetric or because it is a bad link in both directions, the result is the same and the metric will see to it that it is avoided if there are better routes available. There is no other existing mechanism in RPL for handling asymmetric links. It can't be done by building multiple DAGs and it can't be done by the OF. Matteo At 5:26 AM -0800 12/22/10, Don Sturek wrote: >Hi Pascal, > >I think my point below is we cannot set up separate DAGs to overcome the >issue of not having a way of dealing with asymmetric links (which will >occur). I believe we need a meaningful OF to deal with filtering out >asymmetric links within a single DAG. > >Don > > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Wednesday, December 22, 2010 4:04 AM >To: Don Sturek >Cc: Philip Levis; ROLL WG >Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >Hi Don: > >You lost me. What is n? Why do you need many DAGs? > >Pascal >http://www.xtranormal.com/watch/7011357/ > >> -----Original Message----- >> From: Don Sturek [mailto:d.sturek@att.net] >> Sent: Saturday, December 18, 2010 3:19 PM >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> Hi pascal, >> >> What you wrote below in the last paragraph is wrong. In fact, it is >not 2 Dags >> that must be created but an order n number of Dags to cover any of the >> return paths to any of the nodes which could have generated a request. >> >> Don >> >> >> Sent from my iPad >> >> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" >> wrote: >> >> > Again you've got your logic reversed. RPL was designed for LLNs, >does >> > not mean that it has to be limited to anything as long as it works >> > fine there too. >> > >> > Second you'll find more and more low power / constrained devices in >> > both wired and wireless space, because as a trend we are controlling >> > more and wasting less. >> > >> > Third, RPL by construction is a good routing protocol for certain >> > topologies that are inherently based on hub and spoke. I listed a >> > number in this thread already. Think dynamic overlays like VPNs for >one. >> > >> > Finally, OF0 may apply to asymmetric links if people are willing to >> > run >> > 2 DAGs, one for the traffic up and one for the traffic down. Mixing >> > problems is a source of confusion. >> > >> > Pascal >> > http://www.xtranormal.com/watch/7011357/ >> > >> >> -----Original Message----- >> >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> >> Sent: Friday, December 17, 2010 10:32 PM >> >> To: Pascal Thubert (pthubert) >> >> Cc: Don Sturek; ROLL WG >> >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> >> >> >> >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >> >> >> >>> Don: >> >>> >> >>> I listed a number of examples and none of them is PLC actually. >> >>> RPL is a routing protocol. There is no point in preventing its >usage >> > on wired >> >> lines. >> >>> >> >> >> >> https://datatracker.ietf.org/wg/roll/charter/: >> >> >> >> The Working Group is focused on routing issues for LLN. >> >> >> >> Can you give me an example of a wired network that's an LLN where >OF0 >> > is >> >> useful? >> >> >> >> Phil > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Wed Dec 22 08:25: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 B60B83A6B12 for ; Wed, 22 Dec 2010 08:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM0UIZpZjkPV for ; Wed, 22 Dec 2010 08:25:05 -0800 (PST) Received: from nm7-vm0.bullet.mail.sp2.yahoo.com (nm7-vm0.bullet.mail.sp2.yahoo.com [98.139.91.192]) by core3.amsl.com (Postfix) with SMTP id EF4F83A6B0F for ; Wed, 22 Dec 2010 08:25:04 -0800 (PST) Received: from [98.139.91.62] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:27:00 -0000 Received: from [98.139.91.12] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:27:00 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 22 Dec 2010 16:27:00 -0000 X-Yahoo-Newman-Id: 727562.81663.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 20177 invoked from network); 22 Dec 2010 16:27:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1293035220; bh=us4MRaIt+vuDLEZiOq/DzfHv8w/hgPTwQ+qOe0bk3z0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=B5F9fM1ZDWv28AQt3kkCTg+M6UuCADRyW8x8/ZwAMXdK/6V45wh/LIFQ/RO0ZlM4vYWFIR5UrgV7LDmIHtwrnCdLvklhSm9lxfXBgSxtFgixGB066zKXtuEUt8Ne/tTaeP/MvF1xTOobO2bSHxzDYnotoQS4eoWoxcCM28PI3CE= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 22 Dec 2010 08:26:56 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Xj4uVF4VM1kSTKwHKc9V3MTLZ63v16EAd7RE3O4Q4wCxgzW z6TDKe2Lvm8d921Z4Tm73Qaa28miqH3_piTaFf_p21dnsq0JgJ10XrOe7LOZ RqmyEfsbZQjLEGqWtnlQv9mo3bliKF186RB5y.0ESBrxD3tNJLe0CZwpOkfl 0DIATpqb6OYkSPL5rB32MgRM7kHOQRzPoIiU5.N3tSJz0t651ggdWjD0bO31 6Rhh6A_quBj1rRYjdoAhrh2VwBzoWuJLipZuhJdV.jPPDr7bR4ddKfXqoHN3 qzv52U90jajqmfCy2A1LrwzxRhIWDbAY7WkjNnfh1SB.OP5J6e1piE0DISFE _0BPZHJ9okNpx1MlKXPaWu.I0XblO16EomSUu_XM- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Matteo Paris'" , "'Pascal Thubert \(pthubert\)'" References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> <007501cba1db$e7795770$b66c0650$@sturek@att.net> In-Reply-To: Date: Wed, 22 Dec 2010 08:26:54 -0800 Message-ID: <005b01cba1f5$0c541e90$24fc5bb0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuh81JLhKJwNow5RHujuSaYjxl1/AAAVScw Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:25:06 -0000 Hi Matteo, I think OF0 needs to be beefed up to use something more than just hop count. I agree that the exchange of hop metrics is lower layer than RPL but there is no reason that other IETF protocols cannot be used to establish the hop metrics (MANET NHDP for example, NS/NA, etc.). I don't think there is any activity in IEEE 802.15.4 (task group 4e) to deal with hop metrics. Don -----Original Message----- From: Matteo Paris [mailto:matteo@ember.com] Sent: Wednesday, December 22, 2010 8:15 AM To: d.sturek@att.net; 'Pascal Thubert (pthubert)' Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Hi Don and Pascal, As RPL is currently designed, asymmetric links are a link layer issue, not a RPL issue. Any DIO received on a unidirectional link should be dropped and not processed further by the OF. If a link is highly asymmetric (one direction is poor), then that link will provide poor performance regardless of which direction traffic is flowing. The link layer will take this into account by assigning it a poor metric value. The OF doesn't need to take any special action. Whether a link has a poor metric value because it is asymmetric or because it is a bad link in both directions, the result is the same and the metric will see to it that it is avoided if there are better routes available. There is no other existing mechanism in RPL for handling asymmetric links. It can't be done by building multiple DAGs and it can't be done by the OF. Matteo At 5:26 AM -0800 12/22/10, Don Sturek wrote: >Hi Pascal, > >I think my point below is we cannot set up separate DAGs to overcome the >issue of not having a way of dealing with asymmetric links (which will >occur). I believe we need a meaningful OF to deal with filtering out >asymmetric links within a single DAG. > >Don > > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Wednesday, December 22, 2010 4:04 AM >To: Don Sturek >Cc: Philip Levis; ROLL WG >Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >Hi Don: > >You lost me. What is n? Why do you need many DAGs? > >Pascal >http://www.xtranormal.com/watch/7011357/ > >> -----Original Message----- >> From: Don Sturek [mailto:d.sturek@att.net] >> Sent: Saturday, December 18, 2010 3:19 PM >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> Hi pascal, >> >> What you wrote below in the last paragraph is wrong. In fact, it is >not 2 Dags >> that must be created but an order n number of Dags to cover any of the >> return paths to any of the nodes which could have generated a request. >> >> Don >> >> >> Sent from my iPad >> >> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" >> wrote: >> >> > Again you've got your logic reversed. RPL was designed for LLNs, >does >> > not mean that it has to be limited to anything as long as it works >> > fine there too. >> > >> > Second you'll find more and more low power / constrained devices in >> > both wired and wireless space, because as a trend we are controlling >> > more and wasting less. >> > >> > Third, RPL by construction is a good routing protocol for certain >> > topologies that are inherently based on hub and spoke. I listed a >> > number in this thread already. Think dynamic overlays like VPNs for >one. >> > >> > Finally, OF0 may apply to asymmetric links if people are willing to >> > run >> > 2 DAGs, one for the traffic up and one for the traffic down. Mixing >> > problems is a source of confusion. >> > >> > Pascal >> > http://www.xtranormal.com/watch/7011357/ >> > >> >> -----Original Message----- >> >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> >> Sent: Friday, December 17, 2010 10:32 PM >> >> To: Pascal Thubert (pthubert) >> >> Cc: Don Sturek; ROLL WG >> >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> >> >> >> >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >> >> >> >>> Don: >> >>> >> >>> I listed a number of examples and none of them is PLC actually. >> >>> RPL is a routing protocol. There is no point in preventing its >usage >> > on wired >> >> lines. >> >>> >> >> >> >> https://datatracker.ietf.org/wg/roll/charter/: >> >> >> >> The Working Group is focused on routing issues for LLN. >> >> >> >> Can you give me an example of a wired network that's an LLN where >OF0 >> > is >> >> useful? >> >> >> >> Phil > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Matteo.Paris@ember.com Wed Dec 22 08:58: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 385583A6A37 for ; Wed, 22 Dec 2010 08:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqhv3kcCkfRj for ; Wed, 22 Dec 2010 08:58:15 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6C0523A6A20 for ; Wed, 22 Dec 2010 08:58:15 -0800 (PST) Received: from [192.168.81.108] ([192.168.81.108]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 12:00:12 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <005b01cba1f5$0c541e90$24fc5bb0$@sturek@att.net> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <6A2A459175DABE4BB11DE2026AA50A5D037A6CF9@XMB-AMS-107.cisco.com> <007501cba1db$e7795770$b66c0650$@sturek@att.net> <005b01cba1f5$0c541e90$24fc5bb0$@sturek@att.net> Date: Wed, 22 Dec 2010 12:00:11 -0500 To: , "'Pascal Thubert \(pthubert\)'" From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 22 Dec 2010 17:00:12.0873 (UTC) FILETIME=[B2CA6B90:01CBA1F9] Cc: 'ROLL WG' Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:58:17 -0000 Hi Don, we're in agreement then. But rather than trying to beef up the "Last Resort OF" OF0, why not just start with MRHOF, which does not assume hop count and is much more suitable for use over 802.15.4? Matteo At 8:26 AM -0800 12/22/10, Don Sturek wrote: >Hi Matteo, > >I think OF0 needs to be beefed up to use something more than just hop count. >I agree that the exchange of hop metrics is lower layer than RPL but there >is no reason that other IETF protocols cannot be used to establish the hop >metrics (MANET NHDP for example, NS/NA, etc.). > >I don't think there is any activity in IEEE 802.15.4 (task group 4e) to deal >with hop metrics. > >Don > > >-----Original Message----- >From: Matteo Paris [mailto:matteo@ember.com] >Sent: Wednesday, December 22, 2010 8:15 AM >To: d.sturek@att.net; 'Pascal Thubert (pthubert)' >Cc: 'ROLL WG' >Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > >Hi Don and Pascal, > >As RPL is currently designed, asymmetric links are a link layer >issue, not a RPL issue. > >Any DIO received on a unidirectional link should be dropped and not >processed further by the OF. If a link is highly asymmetric (one >direction is poor), then that link will provide poor performance >regardless of which direction traffic is flowing. The link layer >will take this into account by assigning it a poor metric value. The >OF doesn't need to take any special action. Whether a link has a >poor metric value because it is asymmetric or because it is a bad >link in both directions, the result is the same and the metric will >see to it that it is avoided if there are better routes available. > >There is no other existing mechanism in RPL for handling asymmetric >links. It can't be done by building multiple DAGs and it can't be >done by the OF. > >Matteo > > >At 5:26 AM -0800 12/22/10, Don Sturek wrote: >>Hi Pascal, >> >>I think my point below is we cannot set up separate DAGs to overcome the >>issue of not having a way of dealing with asymmetric links (which will >>occur). I believe we need a meaningful OF to deal with filtering out >>asymmetric links within a single DAG. >> >>Don >> >> >>-----Original Message----- >>From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>Sent: Wednesday, December 22, 2010 4:04 AM >>To: Don Sturek >>Cc: Philip Levis; ROLL WG >>Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >>Hi Don: >> >>You lost me. What is n? Why do you need many DAGs? >> >>Pascal >>http://www.xtranormal.com/watch/7011357/ >> >>> -----Original Message----- >>> From: Don Sturek [mailto:d.sturek@att.net] >>> Sent: Saturday, December 18, 2010 3:19 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Philip Levis; ROLL WG >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>> >>> Hi pascal, >>> >>> What you wrote below in the last paragraph is wrong. In fact, it is >>not 2 Dags >>> that must be created but an order n number of Dags to cover any of the >>> return paths to any of the nodes which could have generated a request. >>> >>> Don >>> >>> >>> Sent from my iPad >>> >>> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" >>> wrote: >>> >>> > Again you've got your logic reversed. RPL was designed for LLNs, >>does >>> > not mean that it has to be limited to anything as long as it works >>> > fine there too. >>> > >>> > Second you'll find more and more low power / constrained devices in >>> > both wired and wireless space, because as a trend we are controlling >>> > more and wasting less. >>> > >>> > Third, RPL by construction is a good routing protocol for certain >>> > topologies that are inherently based on hub and spoke. I listed a >>> > number in this thread already. Think dynamic overlays like VPNs for >>one. >>> > >>> > Finally, OF0 may apply to asymmetric links if people are willing to >>> > run >>> > 2 DAGs, one for the traffic up and one for the traffic down. Mixing >>> > problems is a source of confusion. > >> > >>> > Pascal >>> > http://www.xtranormal.com/watch/7011357/ >>> > >>> >> -----Original Message----- >>> >> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> >> Sent: Friday, December 17, 2010 10:32 PM >>> >> To: Pascal Thubert (pthubert) >>> >> Cc: Don Sturek; ROLL WG >>> >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>> >> >>> >> >>> >> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >>> >> >>> >>> Don: >>> >>> >>> >>> I listed a number of examples and none of them is PLC actually. >>> >>> RPL is a routing protocol. There is no point in preventing its >>usage >>> > on wired >>> >> lines. >>> >>> >>> >> >>> >> https://datatracker.ietf.org/wg/roll/charter/: >>> >> >>> >> The Working Group is focused on routing issues for LLN. >>> >> >>> >> Can you give me an example of a wired network that's an LLN where >>OF0 >>> > is >>> >> useful? >>> >> >>> >> Phil >> >>_______________________________________________ >>Roll mailing list >>Roll@ietf.org >>https://www.ietf.org/mailman/listinfo/roll From stoleru@cse.tamu.edu Mon Dec 20 23:19: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 69BCE3A69CB for ; Mon, 20 Dec 2010 23:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyiLFrAt4VWg for ; Mon, 20 Dec 2010 23:19:31 -0800 (PST) Received: from smtp.cs.tamu.edu (mailhost.cs.tamu.edu [128.194.138.107]) by core3.amsl.com (Postfix) with ESMTP id 4996F3A69BC for ; Mon, 20 Dec 2010 23:19:31 -0800 (PST) Received: from [128.194.143.227] (radu-pc.cs.tamu.edu [128.194.143.227]) by smtp.cs.tamu.edu (Postfix) with ESMTP id BF3421905F0 for ; Tue, 21 Dec 2010 01:21:26 -0600 (CST) Message-ID: <4D10557B.4050902@cse.tamu.edu> Date: Tue, 21 Dec 2010 01:21:31 -0600 From: Radu Stoleru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Dec 2010 09:12:18 -0800 Subject: [Roll] ACM Conference on Embedded Networked Sensor Systems (SenSys) 2012 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2010 07:19:31 -0000 Dear Sensys Community: Sensys 2012 will be held in North America. We are now soliciting formal proposals for hosting the event. Please include the following in any submitted proposal. - Details of the proposed venue - exact location - Size and configuration of main auditorium for the conference itself. Pictures are helpful. - Size and configuration of demo/poster area. Since the demo/poster session is a major feature of this conference, it is important to ensure that we will be able to get a good space for this, with power, WiFi, etc. Pictures are helpful. - We anticipate having about 3 collocated workshops with SenSys, either immediately before or after the event, with around 60 participants each. Information on where these would be held would be helpful. - Accommodation information and estimated price range. If accommodation is not local to the conference itself, how local transportation would be handled. - Travel information: Air connections to major cities, approximate airfare from major cities on US East Coast, West Coast, Europe, and Asia. Any other expected travel expenses from the airport to the conference site. - Details on proposed banquet/other meals and any other activities - Information on who would handle local arrangements - Any other information to make the case, why it's a good venue, local interest, etc. - We do not need a detailed budget at this time, though it may be good to estimate costs for the venue so we can consider how it will impact the overall conference budget. Please send completed proposals to stankovic@cs.virginia.edu The proposals should be received no later than Feb 15, 2011 Jack Stankovic Chair, Steering Committee From Martin.Stiemerling@neclab.eu Thu Dec 23 02:49: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 8DA7B3A6C02; Thu, 23 Dec 2010 02:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 JNo9UYSX7kVi; Thu, 23 Dec 2010 02:49:15 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9AF983A6B20; Thu, 23 Dec 2010 02:49:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F091B2C00040B; Thu, 23 Dec 2010 11:52:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdQs6INSsrKg; Thu, 23 Dec 2010 11:52:51 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id CE46C2C0001AF; Thu, 23 Dec 2010 11:52:31 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.232]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 23 Dec 2010 11:50:55 +0100 From: Martin Stiemerling To: "tsv-dir@ietf.org Dir" , "roll@ietf.org" , "iesg@ietf.org" , "draft-ietf-roll-trickle@tools.ietf.org" Thread-Topic: TSV-DIR Review of draft-ietf-roll-trickle-05.txt Thread-Index: Acuij0URiH8EhdnEQ/OCotR5IosGKw== Date: Thu, 23 Dec 2010 10:50:54 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 23 Dec 2010 09:12:18 -0800 Subject: [Roll] TSV-DIR Review of draft-ietf-roll-trickle-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 10:49:16 -0000 Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary This draft describes the trickle algorithm which allows to exchange informa= tion between nodes connected to a lossy shared medium. It defines no protoc= ol usage of the algorithm, but let this to other drafts (e.g., roll-rpl). The draft itself is well-written, including an easy to understand algorithm= description, description of parameters, and description of limitations of = the algorithm. Transport Issues - Section 4.2 How is the very initial value for I chosen? - Section 5, 1st bullet: it correctly says "the default value of Imin is 4 = times the worst case link layer latency". Should the protocol doc also indi= cate what the authors believe to be the worst case link layer latency? Othe= rwise the text might also be not that clear. - Section 5, step 5 vs. step 3: step 3 says "transmits if" , but step 5 doe= s never says in the text that something is transmitted if a "inconsistence"= state is received.=20 Others (nits) - Section 4.1, 2nd bullet: the formula (log(max/min)) and the parameters ca= n be improved in terms of saying what is actually what: There is no Imax/Im= in in the formula. Imin is in time units, while Imax is a number without a = unit? I guess the described value of 16 is actually not Imax, but the resul= t of log(Imax/Imin). The text is somewhat confusing to me, even though I do= understand the meaning of the text. - Section 4.1, 3rd bullet: s/constant/constant k/ to be consistent with the= other bullets - Section 5, 1st bullet, last sentence "Worst case...", I can hardly read t= his sentence. Can you rephrase it? With best regards Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From pthubert@cisco.com Fri Dec 24 04:13: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 16A4A3A679F for ; Fri, 24 Dec 2010 04:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl8wPVxoamb3 for ; Fri, 24 Dec 2010 04:13:08 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DF5183A6783 for ; Fri, 24 Dec 2010 04:13:08 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAseFE2rR7Ht/2dsb2JhbACkLXOlJJsshUoEjic X-IronPort-AV: E=Sophos;i="4.60,223,1291593600"; d="scan'208";a="237346290" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 24 Dec 2010 12:15:01 +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 oBOCEiDK005889; Fri, 24 Dec 2010 12:15:00 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Dec 2010 13:14:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Dec 2010 13:14:56 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D037A7283@XMB-AMS-107.cisco.com> In-Reply-To: <3A3B828C-3A4C-42F2-8B9E-5BA69B8525CE@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueyoLKJOy0wc4FT5Kc5nBhyylQqwEmOeAQ References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <891346ff88ea9a4185d1eb896759dd49@mail.gmail.com> <3A3B828C-3A4C-42F2-8B9E-5BA69B8525CE@att.net> From: "Pascal Thubert (pthubert)" To: "Don Sturek" , "Yoav Ben-Yehezkel" X-OriginalArrivalTime: 24 Dec 2010 12:14:58.0902 (UTC) FILETIME=[2EE52F60:01CBA364] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 12:13:10 -0000 Hi Don: My proposal is 2 set up 2 DAGS, one DIO only for upward traffic, and one DIO+DAO for downward traffic.=20 The first DAG would be established using metrics that describe the upward direction of the link, while the other would be established with downwards metrics. The resulting topology is roughly equivalent to having a single DAG with an OF that could read metrics for both directions. In any case, you end up with 2 sets of parents. >From your response, it is quite probable that you misunderstood that proposal, and quite probable that you interpreted my words as a DAG per destination. If so, please reconsider... Merry Xmas yall! Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: Saturday, December 18, 2010 4:47 PM > To: Yoav Ben-Yehezkel > Cc: Pascal Thubert (pthubert); ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >=20 > Hi yoav, >=20 > True, however then you need some OF to handle asymmetric links. I think > pascal proposes separate DAGs to handle that. >=20 > Don >=20 > Sent from my iPad >=20 > On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel wrote: >=20 > > My understanding WRT a solution to the asymmetric links was that that > > RPL can settle with just one DAG by use of DAO messages that allows a > > bi-directional downwards route creation. > > > > Can that be considered a legit solution to asymmetric links a well? > > > > Regards, > > Yoav > > > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Don Sturek > > Sent: Saturday, December 18, 2010 4:19 PM > > To: Pascal Thubert (pthubert) > > Cc: ROLL WG > > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > > > > Hi pascal, > > > > What you wrote below in the last paragraph is wrong. In fact, it is > > not 2 Dags that must be created but an order n number of Dags to cover > > any of the return paths to any of the nodes which could have generated a > request. > > > > Don > > > > > > Sent from my iPad > > > > On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" > > wrote: > > > >> Again you've got your logic reversed. RPL was designed for LLNs, does > >> not mean that it has to be limited to anything as long as it works > >> fine there too. > >> > >> Second you'll find more and more low power / constrained devices in > >> both wired and wireless space, because as a trend we are controlling > >> more and wasting less. > >> > >> Third, RPL by construction is a good routing protocol for certain > >> topologies that are inherently based on hub and spoke. I listed a > >> number in this thread already. Think dynamic overlays like VPNs for one. > >> > >> Finally, OF0 may apply to asymmetric links if people are willing to > >> run > >> 2 DAGs, one for the traffic up and one for the traffic down. Mixing > >> problems is a source of confusion. > >> > >> Pascal > >> http://www.xtranormal.com/watch/7011357/ > >> > >>> -----Original Message----- > >>> From: Philip Levis [mailto:pal@cs.stanford.edu] > >>> Sent: Friday, December 17, 2010 10:32 PM > >>> To: Pascal Thubert (pthubert) > >>> Cc: Don Sturek; ROLL WG > >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt > >>> > >>> > >>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: > >>> > >>>> Don: > >>>> > >>>> I listed a number of examples and none of them is PLC actually. > >>>> RPL is a routing protocol. There is no point in preventing its > >>>> usage > >> on wired > >>> lines. > >>>> > >>> > >>> https://datatracker.ietf.org/wg/roll/charter/: > >>> > >>> The Working Group is focused on routing issues for LLN. > >>> > >>> Can you give me an example of a wired network that's an LLN where > >>> OF0 > >> is > >>> useful? > >>> > >>> Phil > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From skip.ashton@ember.com Fri Dec 24 19:09: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 547E83A69B7 for ; Fri, 24 Dec 2010 19:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 wN+JyMYrZ0U7 for ; Fri, 24 Dec 2010 19:09:51 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 82AB03A69B6 for ; Fri, 24 Dec 2010 19:09:48 -0800 (PST) Received: from 173.48.176.105 ([173.48.176.105]) by EMPIRE.hq.ember.com ([192.168.80.108]) with Microsoft Exchange Server HTTP-DAV ; Sat, 25 Dec 2010 03:11:51 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Fri, 24 Dec 2010 22:11:50 -0500 From: Skip Ashton To: "Pascal Thubert (pthubert)" , Don Sturek , Yoav Ben-Yehezkel Message-ID: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-04.txt Thread-Index: AcueyoLKJOy0wc4FT5Kc5nBhyylQqwEmOeAQAB+DoZo= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D037A7283@XMB-AMS-107.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 03:09:53 -0000 We have discussed this before and it does not work properly. The DAG represents the metric back to the root and in this case we need to know the link quality between two adjacent devices. Knowing the aggregate cost to the root does not give you enough information on if this link is suitable. Skip On 12/24/10 7:14 AM, "Pascal Thubert (pthubert)" wrote: > Hi Don: > > My proposal is 2 set up 2 DAGS, one DIO only for upward traffic, and one > DIO+DAO for downward traffic. > The first DAG would be established using metrics that describe the > upward direction of the link, while the other would be established with > downwards metrics. > The resulting topology is roughly equivalent to having a single DAG with > an OF that could read metrics for both directions. In any case, you end > up with 2 sets of parents. > > From your response, it is quite probable that you misunderstood that > proposal, and quite probable that you interpreted my words as a DAG per > destination. > If so, please reconsider... > > Merry Xmas yall! > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: Don Sturek [mailto:d.sturek@att.net] >> Sent: Saturday, December 18, 2010 4:47 PM >> To: Yoav Ben-Yehezkel >> Cc: Pascal Thubert (pthubert); ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> Hi yoav, >> >> True, however then you need some OF to handle asymmetric links. I > think >> pascal proposes separate DAGs to handle that. >> >> Don >> >> Sent from my iPad >> >> On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel > wrote: >> >>> My understanding WRT a solution to the asymmetric links was that > that >>> RPL can settle with just one DAG by use of DAO messages that allows > a >>> bi-directional downwards route creation. >>> >>> Can that be considered a legit solution to asymmetric links a well? >>> >>> Regards, >>> Yoav >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of Don Sturek >>> Sent: Saturday, December 18, 2010 4:19 PM >>> To: Pascal Thubert (pthubert) >>> Cc: ROLL WG >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>> >>> Hi pascal, >>> >>> What you wrote below in the last paragraph is wrong. In fact, it is >>> not 2 Dags that must be created but an order n number of Dags to > cover >>> any of the return paths to any of the nodes which could have > generated a >> request. >>> >>> Don >>> >>> >>> Sent from my iPad >>> >>> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" >>> wrote: >>> >>>> Again you've got your logic reversed. RPL was designed for LLNs, > does >>>> not mean that it has to be limited to anything as long as it works >>>> fine there too. >>>> >>>> Second you'll find more and more low power / constrained devices > in >>>> both wired and wireless space, because as a trend we are > controlling >>>> more and wasting less. >>>> >>>> Third, RPL by construction is a good routing protocol for certain >>>> topologies that are inherently based on hub and spoke. I listed a >>>> number in this thread already. Think dynamic overlays like VPNs > for one. >>>> >>>> Finally, OF0 may apply to asymmetric links if people are willing to >>>> run >>>> 2 DAGs, one for the traffic up and one for the traffic down. Mixing >>>> problems is a source of confusion. >>>> >>>> Pascal >>>> http://www.xtranormal.com/watch/7011357/ >>>> >>>>> -----Original Message----- >>>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>>> Sent: Friday, December 17, 2010 10:32 PM >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Don Sturek; ROLL WG >>>>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>>>> >>>>> >>>>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Don: >>>>>> >>>>>> I listed a number of examples and none of them is PLC actually. >>>>>> RPL is a routing protocol. There is no point in preventing its >>>>>> usage >>>> on wired >>>>> lines. >>>>>> >>>>> >>>>> https://datatracker.ietf.org/wg/roll/charter/: >>>>> >>>>> The Working Group is focused on routing issues for LLN. >>>>> >>>>> Can you give me an example of a wired network that's an LLN where >>>>> OF0 >>>> is >>>>> useful? >>>>> >>>>> Phil >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
=0A
To elaborate more.
=0A
I can see ther= e is an exception when the PIO's  L flag is set.
=0A
That is = the "L" flag distinguish between <1> Subnet-wide Prefix
=0A
= and <2>Node-owned Prefixes.
=0A
 
=0A
Wouldn't= it be better to elaborate this as another exception in
=0A
"6.7.= 10.  Prefix Information". Or add the words "For = Subnet-wide Prefix "
=0A
as below.
=0A
 
=0A
From "6.7.10.  Prefix Information" it has been clea= rly stated that
=0A
=0A
   "For Subnet-wide Prefix the root of a DODAG is authoritati= ve for setting that information.
   The information is propaga= ted down the DODAG unchanged, with the
   exception that a RPL= router may update (extend) the prefix by
   appending it's ow= n suffix."
=0A
 
=0A
=  
=0A
Chris.

=0A

=0A
=0A
=0AFrom: Christopher Ntyangiri <= ntyangiri2@yahoo.com>
To:= roll@ietf.org
Sent:= Mon, December 20, 2010 11:15:56 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

=0A
=0A
Tim,
=0A
 
=0A
I have&= nbsp;a question regarding how to send PIO in RPL.
=0A
 <= /DIV>=0A
From "6.7.10.  Prefix Information" it has been clearly stat= ed that
=0A
   "The root of a DODAG is autho= ritative for setting that information.
   The information is p= ropagated down the DODAG unchanged, with the
   exception that= a RPL router may update (extend) the prefix by
   appending i= t's own suffix."
=0A

 

=0A

Now, in the appendix:

=0A
A.2. Examp= le Operation in Storing Mode With Node-owned Prefixes
=0A
A.2.1. D= IO messages and PIO
=0A
Node A, for example, will send DIO message= s with a PIO as follows:
=E2=80=99A=E2=80=99 flag: Set
=E2=80=99L=E2= =80=99 flag: Set
=E2=80=99R=E2=80=99 flag: Clear
Prefix Length: 64Prefix: A::
=0A

Node B, for example, will send DIO messages w= ith a PIO as follows:
=E2=80=99A=E2=80=99 flag: Set
=E2=80=99L=E2=80= =99 flag: Set
=E2=80=99R=E2=80=99 flag: Set
Prefix Length: 64
Pref= ix: B::B
=0A
=0A
...
=0A
 
=0A
Here, Node B has completely changed the Prefix received from= the Root.
=0A
Is there something I don't understand?
=0A 
=0A
Thanks in advance.
=0A
 
=0A
Ch= ris.
=0A

=0A
=0A
=0AFrom: Tim Winter &l= t;wintert@acm.org>
To: roll@ietf.org
Sent: Th= u, December 16, 2010 8:08:31 AM
Sub= ject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

WG,

With this revision we continue to address concerns brought = up in IESG evaluation
(https://datatracker.ietf.o= rg/doc/draft-ietf-roll-rpl/)

Regards,

-Tim


On = 12/15/2010 06:00 PM, Internet-D= rafts@ietf.org wrote:
> A New Internet-Draft is available from th= e 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 Ro= uting Protocol for Low power and Lossy Networks
>     = Author(s)      : T. Winter, et al.
>    = ; Filename        : draft-ietf-roll-rpl-17.txt
> =     Pages          : 159
> &n= bsp;   Date            : 2010-12-15=
>
> Low power and Lossy Networks (LLNs) are a class of network= in which
> both the routers and their interconnect are constrained.&= nbsp; LLN routers
> typically operate with constraints on processing = power, memory, and
> energy (battery power).  Their interconnect= s are characterized by
> high loss rates, low data rates, and instabi= lity.  LLNs are comprised
> of anything from a few dozen and up to thousands of routers.
> Supported traffic flows include po= int-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 c= entral control point).  This
> document specifies the IPv6 Routi= ng Protocol for LLNs (RPL), which
> provides a mechanism whereby mult= ipoint-to-point traffic from devices
> inside the LLN towards a centr= al control point, as well as point-to-
> multipoint traffic from the = central control point to the devices
> inside the LLN, is supported.&= nbsp; Support for point-to-point traffic is
> also available.
>=
> A URL for this Internet-Draft is:
> http://www.ietf.org/inte= rnet-drafts/draft-ietf-roll-rpl-17.txt
>
> Internet-Drafts are = also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data= which will enable a MIME compliant mail reader
> implementation to a= utomatically retrieve the ASCII version of the
> Internet-Draft.
&= gt;
>
>
> _______________________________________________=
> Roll mailing list
> Roll@ietf.org=
> https://www.ietf.org/mailman/listinfo/roll
_____= __________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


=0A=0A --0-1540602698-1292814997=:41392-- From Matteo.Paris@ember.com Sun Dec 19 20:43: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 CEDE43A69CC for ; Sun, 19 Dec 2010 20:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhayqTmZiX3q for ; Sun, 19 Dec 2010 20:43:48 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 508C53A69D1 for ; Sun, 19 Dec 2010 20:43:48 -0800 (PST) Received: from [192.168.1.101] ([192.168.90.98]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Dec 2010 23:45:37 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <3A3B828C-3A4C-42F2-8B9E-5BA69B8525CE@att.net> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <801711.79377.qm@web81401.mail.mud.yahoo.com> <6A2A459175DABE4BB11DE2026AA50A5D03704024@XMB-AMS-107.cisco.com> <62CCCA7B-B1EE-46E3-AA2A-5B42EE04A85E@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03704656@XMB-AMS-107.cisco.com> <5776A0D3-B281-4BB6-9D90-D9237F785AD2@att.net> <891346ff88ea9a4185d1eb896759dd49@mail.gmail.com> <3A3B828C-3A4C-42F2-8B9E-5BA69B8525CE@att.net> Date: Sun, 19 Dec 2010 23:45:38 -0500 To: ROLL WG From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 20 Dec 2010 04:45:37.0308 (UTC) FILETIME=[BEE16DC0:01CBA000] Subject: [Roll] Asymmetric links (was: I-D Action:draft-ietf-roll-of0-04.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 04:43:49 -0000 My understanding is that asymmetric links have to be detected by the link layer. Then the asymmetry can be reflected in the routing metric. Any OF that uses a bidirectional metric (like ETX) will do. If the link layer does not detect unidirectional links, and metric values are based on one-way information only (eg, receipt of DIOs), it is easy for RPL to get wedged. No number of upward or downward DAGs will help. Matteo At 7:46 AM -0800 12/18/10, Don Sturek wrote: >Hi yoav, > >True, however then you need some OF to handle asymmetric links. I >think pascal proposes separate DAGs to handle that. > >Don > >Sent from my iPad > >On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel wrote: > >> My understanding WRT a solution to the asymmetric links was that that RPL >> can settle with just one DAG by use of DAO messages that allows a >> bi-directional downwards route creation. >> >> Can that be considered a legit solution to asymmetric links a well? >> >> Regards, >> Yoav >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Don Sturek >> Sent: Saturday, December 18, 2010 4:19 PM >> To: Pascal Thubert (pthubert) >> Cc: ROLL WG >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >> >> Hi pascal, >> >> What you wrote below in the last paragraph is wrong. In fact, it is not 2 >> Dags that must be created but an order n number of Dags to cover any of >> the return paths to any of the nodes which could have generated a request. >> >> Don >> >> >> Sent from my iPad >> >> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)" >> wrote: >> >>> Again you've got your logic reversed. RPL was designed for LLNs, does >>> not mean that it has to be limited to anything as long as it works fine >>> there too. >>> >>> Second you'll find more and more low power / constrained devices in >>> both wired and wireless space, because as a trend we are controlling >>> more and wasting less. >>> >>> Third, RPL by construction is a good routing protocol for certain >>> topologies that are inherently based on hub and spoke. I listed a number >>> in this thread already. Think dynamic overlays like VPNs for one. >>> >>> Finally, OF0 may apply to asymmetric links if people are willing to run >>> 2 DAGs, one for the traffic up and one for the traffic down. Mixing >>> problems is a source of confusion. >>> >>> Pascal >>> http://www.xtranormal.com/watch/7011357/ >>> >>>> -----Original Message----- >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: Friday, December 17, 2010 10:32 PM >>>> To: Pascal Thubert (pthubert) >>>> Cc: Don Sturek; ROLL WG >>>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt >>>> >>>> >>>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Don: >>>>> >>>>> I listed a number of examples and none of them is PLC actually. >>>>> RPL is a routing protocol. There is no point in preventing its usage >>> on wired >>>> lines. >>>>> >>>> >>>> https://datatracker.ietf.org/wg/roll/charter/: >>>> >>>> The Working Group is focused on routing issues for LLN. >>>> >>>> Can you give me an example of a wired network that's an LLN where OF0 >>> is >>>> useful? >>>> >>>> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Dec 20 05:25:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C103A6891 for ; Mon, 20 Dec 2010 05:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.292 X-Spam-Level: X-Spam-Status: No, score=-110.292 tagged_above=-999 required=5 tests=[AWL=0.306, 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 XMFIloEOPtnk for ; Mon, 20 Dec 2010 05:25:01 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 533BB3A687D for ; Mon, 20 Dec 2010 05:25:01 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADboDk2rR7H+/2dsb2JhbACkI3OIL5pHmmaCfBAGgjgEiwGDHYgC X-IronPort-AV: E=Sophos;i="4.60,202,1291593600"; d="scan'208,217";a="299072490" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Dec 2010 13:26:54 +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 oBKDQeGv003116 for ; Mon, 20 Dec 2010 13:26:54 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, 20 Dec 2010 14:26:51 +0100 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Dec 2010 14:26:50 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-1011799721 From: JP Vasseur X-Priority: 3 In-Reply-To: <4E84436B-E5E0-4BF6-BFB1-A5874D473F74@cisco.com> Date: Mon, 20 Dec 2010 14:26:52 +0100 Message-Id: <87945234-02B6-41F2-9D40-742507D37FBE@cisco.com> References: <226723849.1290165458629.JavaMail.nobody@jsj6wl006.webex.com> <4E84436B-E5E0-4BF6-BFB1-A5874D473F74@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 20 Dec 2010 13:26:50.0799 (UTC) FILETIME=[8F5573F0:01CBA049] Subject: [Roll] ** Reminder Interim ROLL WG Meeting Today ** Re: Details (webex) for the Interim ROLL Working Group Meeting - Dec 20 at 8:00am PST - 11:00am ET - 5pm CET X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Dec 2010 13:25:02 -0000 --Apple-Mail-4-1011799721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 8:47 AM, JP Vasseur wrote: > Dear all, >=20 > This is to announce a (virtual) ROLL Working Group meeting that will = take place on Dec 20 - details below. >=20 > There will also be an official announcement. >=20 > The objective is to continue our discussion on the re-chartering = process according to the timeframe that we discussed during the ROLL WG = meeting in Beijing. >=20 > Date: December 20 > Time: 8:00am PST =3D Noon ET =3D 6pm CET > Duration =3D 90mn > Agenda: Discussion on ROLL WG re-chartering process > Location: This will be a Webex to be announced on the ROLL Mailing = List (let me know if you need the details). >=20 > If you have an item that you would like to discuss, feel free to send = slide(s) to the chairs and we will put them together. >=20 > If you do not mind, please send a short unicast ACK to chairs if you = plan to attend. >=20 > Thanks >=20 > JP. >=20 >> Hello ,=20 >>=20 >> Jean Philippe Vasseur invites you to attend this online meeting.=20 >>=20 >> Topic: Meeting Center MPV=20 >> Date: Monday, December 20, 2010=20 >> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 >> Meeting Number: 205 313 548=20 >> Meeting Password: ROLLWG=20 >>=20 >>=20 >> -------------------------------------------------------=20 >> To join the online meeting (Now from the Apple iPhone (R) and other = smartphones!)=20 >> -------------------------------------------------------=20 >> 1. Go to = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&RT=3DMiM0=20 >> 2. Enter your name and email address.=20 >> 3. Enter the meeting password: ROLLWG=20 >> 4. Click "Join Now".=20 >>=20 >> To view in other time zones or languages, please click the link:=20 >> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&ORT=3DMiM0=20 >>=20 >> ----------------------------------------------------------------=20 >> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 >> ----------------------------------------------------------------=20 >>=20 >> The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >>=20 >> Please dial the local access number for your area from the list = below:=20 >> - San Jose/Milpitas (408) area: 525-6800=20 >> - RTP (919) area: 392-3330=20 >>=20 >> -------------------------------------------------------=20 >> To join the teleconference only=20 >> -------------------------------------------------------=20 >> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 >> http://cisco.com/en/US/about/doing_business/conferencing/index.html=20= >> 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >>=20 >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >>=20 >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >>=20 >> India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >>=20 >> Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 >>=20 >> -------------------------------------------------------=20 >> For assistance=20 >> -------------------------------------------------------=20 >> 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 >> 2. On the left navigation bar, click "Support".=20 >>=20 >> You can contact me at:=20 >> jvasseur@cisco.com=20 >> 33-15-804 3494=20 >>=20 >> To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 >> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DWDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac= =3D&RT=3DMiM0=20 >>=20 >> The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to = https://ciscosales.webex.com/ciscosales/systemdiagnosis.php=20 >>=20 >> Sign up for a free trial of WebEx=20 >> http://www.webex.com/go/mcemfreetrial=20 >>=20 >> http://www.webex.com=20 >>=20 >> CCP:+14085256800x205313548#=20 >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-4-1011799721 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = all,

This is to announce a (virtual) ROLL Working = Group meeting that will take place on Dec 20 - details = below.

There will also be an official = announcement.

The objective is to continue our = discussion on the re-chartering process according to the timeframe that = we discussed during the ROLL WG meeting in = Beijing.

Date: December = 20
Time: 8:00am PST =3D Noon ET =3D 6pm = CET
Duration =3D 90mn
Agenda: = Discussion on ROLL WG re-chartering process
Location: = This will be a Webex to be announced on the ROLL Mailing List (let me = know if you need the details).

If you have an item that = you would like to discuss, feel free to send slide(s) to the chairs and = we will put them together.

If you do not mind, = please send a short unicast ACK to chairs if you plan to = attend.

Thanks

JP.<= /div>

Hello ,

Jean = Philippe Vasseur invites you to attend this online meeting.

= Topic: Meeting Center MPV
Date: Monday, December 20, 2010
= Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
= Meeting Number: 205 313 548
Meeting Password: ROLLWG


= -------------------------------------------------------
To join the = online meeting (Now from the Apple iPhone (R) and other smartphones!) =
-------------------------------------------------------
1. Go = to https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&RT=3DMiM0
2. Enter = your name and email address.
3. Enter the meeting password: ROLLWG =
4. Click "Join Now".

To view in other time zones or = languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&ORT=3DMiM0

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

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

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

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

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

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666

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

You can contact = me at:
jvasseur@cisco.com =
33-15-804 3494

To add this meeting to your calendar = program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= WDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac=3D&RT=3DMiM0
=
The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.= php

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

http://www.webex.com =

CCP:+14085256800x205313548#

IMPORTANT NOTICE: This = WebEx service includes a feature that allows audio and any documents and = other materials exchanged or viewed during the session to be recorded. = By joining this session, you automatically consent to such recordings. = If you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation.
=

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

= --Apple-Mail-4-1011799721-- From jpv@cisco.com Mon Dec 20 06:09: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 24CE73A68CB for ; Mon, 20 Dec 2010 06:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.303 X-Spam-Level: X-Spam-Status: No, score=-110.303 tagged_above=-999 required=5 tests=[AWL=0.295, 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 jNFA5SfsmAIE for ; Mon, 20 Dec 2010 06:09:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id AE0B33A6998 for ; Mon, 20 Dec 2010 06:09:51 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkEAEryDk2Q/khLgWdsb2JhbACkJBUBARYiJIgvmkuab4J8EAaCOASLAYMdiAI X-IronPort-AV: E=Sophos;i="4.60,202,1291593600"; d="scan'208,217";a="15602631" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Dec 2010 14:11:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBKEBiOr013295 for ; Mon, 20 Dec 2010 14:11:44 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, 20 Dec 2010 15:11:44 +0100 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Dec 2010 15:11:44 +0100 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-13-1014493128 Date: Mon, 20 Dec 2010 15:11:45 +0100 X-Priority: 3 References: <87945234-02B6-41F2-9D40-742507D37FBE@cisco.com> To: ROLL WG Message-Id: <7390E0D7-AADA-401D-898A-6040056EB9A2@cisco.com> X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 20 Dec 2010 14:11:44.0034 (UTC) FILETIME=[D4A08020:01CBA04F] Subject: [Roll] Fwd: ** Reminder Interim ROLL WG Meeting Today ** Re: Details (webex) for the Interim ROLL Working Group Meeting - Dec 20 at 8:00am PST - 11:00am ET - 5pm CET X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Dec 2010 14:09:54 -0000 --Apple-Mail-13-1014493128 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just to make of no misunderstanding (since there was originally a typo), = the meeting is at 8:00 PST=3D11:00am ET=3D5pm CET Begin forwarded message: > From: JP Vasseur > Date: December 20, 2010 2:26:52 PM GMT+01:00 > To: ROLL WG > Subject: ** Reminder Interim ROLL WG Meeting Today ** Re: [Roll] = Details (webex) for the Interim ROLL Working Group Meeting - Dec 20 at = 8:00am PST - 11:00am ET - 5pm CET >=20 >=20 > On Nov 22, 2010, at 8:47 AM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> This is to announce a (virtual) ROLL Working Group meeting that will = take place on Dec 20 - details below. >>=20 >> There will also be an official announcement. >>=20 >> The objective is to continue our discussion on the re-chartering = process according to the timeframe that we discussed during the ROLL WG = meeting in Beijing. >>=20 >> Date: December 20 >> Time: 8:00am PST =3D 11:00 ET =3D 6pm CET >> Duration =3D 90mn >> Agenda: Discussion on ROLL WG re-chartering process >> Location: This will be a Webex to be announced on the ROLL Mailing = List (let me know if you need the details). >>=20 >> If you have an item that you would like to discuss, feel free to send = slide(s) to the chairs and we will put them together. >>=20 >> If you do not mind, please send a short unicast ACK to chairs if you = plan to attend. >>=20 >> Thanks >>=20 >> JP. >>=20 >>> Hello ,=20 >>>=20 >>> Jean Philippe Vasseur invites you to attend this online meeting.=20 >>>=20 >>> Topic: Meeting Center MPV=20 >>> Date: Monday, December 20, 2010=20 >>> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 >>> Meeting Number: 205 313 548=20 >>> Meeting Password: ROLLWG=20 >>>=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the online meeting (Now from the Apple iPhone (R) and other = smartphones!)=20 >>> -------------------------------------------------------=20 >>> 1. Go to = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&RT=3DMiM0=20 >>> 2. Enter your name and email address.=20 >>> 3. Enter the meeting password: ROLLWG=20 >>> 4. Click "Join Now".=20 >>>=20 >>> To view in other time zones or languages, please click the link:=20 >>> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&ORT=3DMiM0=20 >>>=20 >>> ----------------------------------------------------------------=20 >>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 >>> ----------------------------------------------------------------=20 >>>=20 >>> The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >>>=20 >>> Please dial the local access number for your area from the list = below:=20 >>> - San Jose/Milpitas (408) area: 525-6800=20 >>> - RTP (919) area: 392-3330=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the teleconference only=20 >>> -------------------------------------------------------=20 >>> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 >>> http://cisco.com/en/US/about/doing_business/conferencing/index.html=20= >>> 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >>>=20 >>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >>>=20 >>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >>>=20 >>> India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >>>=20 >>> Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 >>>=20 >>> -------------------------------------------------------=20 >>> For assistance=20 >>> -------------------------------------------------------=20 >>> 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 >>> 2. On the left navigation bar, click "Support".=20 >>>=20 >>> You can contact me at:=20 >>> jvasseur@cisco.com=20 >>> 33-15-804 3494=20 >>>=20 >>> To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 >>> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DWDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac= =3D&RT=3DMiM0=20 >>>=20 >>> The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to = https://ciscosales.webex.com/ciscosales/systemdiagnosis.php=20 >>>=20 >>> Sign up for a free trial of WebEx=20 >>> http://www.webex.com/go/mcemfreetrial=20 >>>=20 >>> http://www.webex.com=20 >>>=20 >>> CCP:+14085256800x205313548#=20 >>>=20 >>> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail-13-1014493128 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: JP Vasseur <jpv@cisco.com>
Date: December 20, 2010 = 2:26:52 PM GMT+01:00
To: ROLL WG <roll@ietf.org>
Subject: ** Reminder = Interim ROLL WG Meeting Today ** Re: [Roll] Details (webex) for the = Interim ROLL Working Group Meeting - Dec 20 at 8:00am PST - 11:00am ET - = 5pm CET

Dear = all,

This is to announce a (virtual) ROLL Working = Group meeting that will take place on Dec 20 - details = below.

There will also be an official = announcement.

The objective is to continue our = discussion on the re-chartering process according to the timeframe that = we discussed during the ROLL WG meeting in = Beijing.

Date: December = 20
Time: 8:00am PST =3D 11:00 ET =3D 6pm = CET
Duration =3D 90mn
Agenda: = Discussion on ROLL WG re-chartering process
Location: = This will be a Webex to be announced on the ROLL Mailing List (let me = know if you need the details).

If you have an item that = you would like to discuss, feel free to send slide(s) to the chairs and = we will put them together.

If you do not mind, = please send a short unicast ACK to chairs if you plan to = attend.

Thanks

JP.<= /div>

Hello ,

Jean = Philippe Vasseur invites you to attend this online meeting.

= Topic: Meeting Center MPV
Date: Monday, December 20, 2010
= Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
= Meeting Number: 205 313 548
Meeting Password: ROLLWG


= -------------------------------------------------------
To join the = online meeting (Now from the Apple iPhone (R) and other smartphones!) =
-------------------------------------------------------
1. Go = to https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&RT=3DMiM0
2. Enter = your name and email address.
3. Enter the meeting password: ROLLWG =
4. Click "Join Now".

To view in other time zones or = languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&ORT=3DMiM0

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

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

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

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

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

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666

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

You can contact = me at:
jvasseur@cisco.com =
33-15-804 3494

To add this meeting to your calendar = program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= WDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac=3D&RT=3DMiM0
=
The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.= php

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

http://www.webex.com =

CCP:+14085256800x205313548#

IMPORTANT NOTICE: This = WebEx service includes a feature that allows audio and any documents and = other materials exchanged or viewed during the session to be recorded. = By joining this session, you automatically consent to such recordings. = If you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation.
=

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