Re: [Roll] knowing which multiple metrics matter: MRHOF related questions

Don Sturek <> Mon, 04 June 2012 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C3C821F8691 for <>; Mon, 4 Jun 2012 06:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8GP0azyNzSN4 for <>; Mon, 4 Jun 2012 06:23:18 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 0609E21F86B7 for <>; Mon, 4 Jun 2012 06:23:17 -0700 (PDT)
Received: from [] by with NNFMP; 04 Jun 2012 13:23:14 -0000
Received: from [] by with NNFMP; 04 Jun 2012 13:23:14 -0000
Received: from [] by with NNFMP; 04 Jun 2012 13:23:14 -0000
Received: from [] by with NNFMP; 04 Jun 2012 13:23:14 -0000
Received: (qmail 996 invoked from network); 4 Jun 2012 13:23:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1338816194; bh=r3iq4KIIOKT8Q7gN+D5OVb44dkSSalMeCv2BB9NKO3Y=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=cCXlDfjgVJai7WV3OtQdq118p0iQGoq11JEm8bOUmfxLhg3wk9icZlcqG5d5EsEeHTYlNkKwHX+2gqu31VfYcvvH6mHTnWLPBoIhTWCVcHD/UBlNywylMYQQCPo5BhuUzXWNoT3HnECK13ou6CtRpJcp5u7VA5IDwBRlRUFXuuU=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: iaAr41sVM1l2VTKr8SdvAanE45s1CkHA6zqf54rCyFi33EG jULU31AgAnVxAWXLI8dlo3W6vMYmrvj0kColhMkX3E4NDc2M3DyldhkBKaqn IKhpF8x0xOuu0usx2AQRevORVRUb9KDbgPie9ULhGwn88_peF92.zKNhSH1F 7WL1yqG5jglx0imXuCgH096tbV1O_9JH6s7RyBWyp_lqQWfdT7ZmtZOsJGZm JkhlL997b.oYlab8Ch7xCDz4Xqs8H32_5wg1yV4PcnnJuFnHu8T7.VDg1ETc DfP5Jd5GSWyq1pzJmcVWRwjA3kETshBkyt5hWiiVYSGKbihQXgIaGpbI0AGm MuTDxojnVjOWq25HzNZ7pVccbdm_162MUDtmJflep3aUB9lbjEJ_iZIvraph Js.hYErJq4BQ2VZQ9GtZTyq1SmbWZ2XhQ0fA-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [] (d.sturek@ with login) by with SMTP; 04 Jun 2012 06:23:13 -0700 PDT
User-Agent: Microsoft-MacOutlook/
Date: Mon, 04 Jun 2012 06:20:42 -0700
From: Don Sturek <>
To: "Pascal Thubert (pthubert)" <>, Ralph Droms <>, Michael Richardson <>
Message-ID: <>
Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "" <>
Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jun 2012 13:23:19 -0000

Hi Pascal,

Having a range of reserved well known OF's from IANA makes sense.   This
is the minimum requirement to make MrHOF work.

If we do intend to support flexibility in deployment (eg industry groups
which may define their own OF's) then we would want a way to define on
demand OF's.


On 6/3/12 11:38 PM, "Pascal Thubert (pthubert)" <> wrote:

>I agree with Ralph that there is a choice to be made whether this OF is
>one OF or a generic OF that is instantiated by metric (a toolbox).
>If it is a specific OF, it is fair to require from IANA a specific OF
>number (1 in the IANA section) but then we can expect that all
>implementations of this OF will behave the same.
>Here, the behavior will vary quite dramatically with some implementation
>decisions (see the unresolved issue in the attached mail) and metric
>choices (Ralph's point here).
>As it goes, we could figure that MrHof is not one but many OFs.  If
>that's so then the OF number for the local variation should be assigned
>consistently for a deployment as opposed to globally significant. There
>could in fact be multiple MrHof in a same deployment.
>My point is somewhat analogous to the UDP ports. Should we have a range
>for IANA reserved well known OFs, and then a range that would be assigned
>on demand? 
>-----Original Message-----
>From: Ralph Droms []
>Sent: vendredi 1 juin 2012 21:47
>To: Michael Richardson
>Cc:; Pascal Thubert (pthubert)
>Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related
>On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote:
>> Hi Michael:
>> I think RPL does not want to take party there. The OF is a piece of
>>logic to tie metrics and policies together.
>> As such, there could be multiple metrics as long as there is good logic
>>to tie them in. for instance one would look at optimizing metric A
>>within contraints as expressed by metric B and the OF model will allow
>> OTOH, it a flows requires a certain optimization (say per one metric)
>>and another requires something different, then certainly you want two
>> So ... it depends!
>> Pascal
>> -----Original Message-----
>> From: [] On Behalf
>> Of Michael Richardson
>> Sent: vendredi 25 mai 2012 16:54
>> To:
>> Subject: [Roll] knowing which multiple metrics matter: MRHOF related
>> questions
>> Ralph asked some questions a few days ago.
>> His originally DISCUSS is at:
>> ballot/
>> This was my reply.    I am particularly interested in replies from
>> Pascal, Anders and Mukul about my assertion about how we would never
>>pick RPL instances by metrics; that they would in fact be seperate RPL
>>Instance numbers and DODAG values, and that these things would
>>provisioned by the network installer.
>> ====
>> I'm going to reply to your comments in a different order than you asked
>>them, because I think question #3 is most important, and the rest fall
>>out of it.
>>>>>>> "Ralph" == Ralph Droms <> writes:
>>    Ralph> 3. Based on (1) and (2), would configuration and selection
>>    Ralph> issues be ameliorated if the five candidate selected metrics
>>    Ralph> were each asssigned a separate objective function?  Use of a
>>    Ralph> separate OF code point for each of the five possible selected
>>    Ralph> metrics would allow multiple RPL instances.
>> I think that it's important to understand that ROLL has a whole palette
>>of things that need to be provisioned by the "network operator".
>> In contrast to the situation of ISPs and customers, where the ISP is
>> the network operator, ROLL networks are more like highly orchestrated
>> Enterprises: "all your host belong to us"
>> so, when we write something like:
>>    "The metric chosen by the network operator to use for path
>>    selection."
>> in section 2, we really mean:
>>    "The metric chosen by the network operator and provisioned into
>>    the node when the firmware was flashed to use for path selection."
>OK, so I get that the model is that MRHOF is a toolbox, where the
>specific tools are chosen when the device is flashed.  In that case, I
>think some additional review might be needed to ensure that the MRHOF
>spec is internally consistent with that point of view.
>As one example, I think the "selected metric" should be called out
>explicitly somewhere in section 5 and included in the list of configured
>parameters in section 6.1.
>As another example, I read this text from section 3:
>   Rank is undefined for these node/link metrics: node state and
>   attributes, throughput, and link color.  If the rank is undefined,
>   the node must join one of the neighbors as a RPL Leaf node according
>   to [RFC6550].
>to mean that if the selected metric is one of the metrics for which rank
>is undefined, the node joins as a lead node.  But, how can that happen if
>the selected metric is chosen by the network operator?
>> Ralph> 1.  Why is one objective function defined for several potential
>> Ralph> metrics?  The details of MRHOF seem to preclude the
>> Ralph> establishment of several RPL instances in an LLN, each of which
>> Ralph> uses MRHOF with a different selected metric.
>> If one had many different RPL Instances, then we would have different
>> RPL Instance numbers in the RPL header.   There can be many different
>> DODAG ("destinations") created within that instance.  The instances
>>share a common set of (provisioned) parameters.
>How does a node know which RPL Instance number maps to which selected
>One way would be to specify that a node advertise ONLY the selected
>metric for the RPL Instance in a DIO.
>> (To put it into DHCP terms: if we have multiple DHCP servers on a link,
>> then one would expect them to all offer IP addresses in the same subnet.
>> If one wanted to have addresses in different subnets, and let the host
>> pick between them, then, one would need different layer-2s: different
>> VLANs or ESSIDs, or... )
>> If you feel that RPL is rather schizo about provisioning vs
>>configuration, then I agree.  It's not always clear to me why some
>>things are advertised while others are provisioned.
>> In BGPv4, we calculate metrics by adding AS entries in the path.
>> (It's always additive), and we add at least one AS entry to the path.
>> One can AS-stuff and add more, but proper operation of BGP does not
>>depend upon the exact algorithm used.
>> Finally, my impression is that how the various metrics are used
>>(singly, or in some combination) to calculate Rank Increase is a
>>question of further research, experimentation, and trade secret.
>Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear
>to me there is one selected metric that is used across all nodes as a
>strictly additive path cost computation.
>> So long as the Rank increases, and a node does not flap between
>>parents, the exact details do not matter.  Each node can do it's parent
>>selection based upon the available metrics on it's own.  It advertises
>>the metrics it has.
>> I hope the authors will correct me if I'm completely off here.
>I read the spec to require a single selected metric across the entire RPL
>- Ralph
>> _______________________________________________
>> Roll mailing list
>Roll mailing list