Re: [Roll] Ralph's DISCUSS on MRHOF spec

Panos Trakadas <> Fri, 29 June 2012 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19F5621F8639 for <>; Fri, 29 Jun 2012 10:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0cxgMT33le9e for <>; Fri, 29 Jun 2012 10:43:27 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id A806321F87E0 for <>; Fri, 29 Jun 2012 10:43:26 -0700 (PDT)
Received: from [] by with NNFMP; 29 Jun 2012 17:43:22 -0000
Received: from [] by with NNFMP; 29 Jun 2012 17:43:22 -0000
Received: from [] by with NNFMP; 29 Jun 2012 17:43:22 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 81484 invoked by uid 60001); 29 Jun 2012 17:43:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1340991802; bh=Y48cNBO0yvIxImYfhQ1RMiqB4teed64bqzt4kr9dsd4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=v9zSpjKeDncWw+wMRBPoTDNPSh1prVHyUa8uZCsEhdr0eH0sovVzN70w/mWXQQnvwFa02/fa+ApavrWr1h7IAoXMgMm0kGHj1qxpg8YE5l96VuNjwAKgbJ7hAnKZJUGoDi01/HrZjJmPIuu2OHMoLUK860IZwAjHjOHCT1iopFs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=3XVEwWv6BS+kDiVapUth/EhhSV/+whFBTBLBNqI4C0RvYh/Ey2sbcEIVcTkyxGd6ObqgBXhbmhqVADSJEIfNQIWTDHpAVPWE08tXn91hGfjDdQCWH7qhZB5gWoUdCLyyqvtQOI5F6AGBk1bE37VVSyiEyip6iDRCz+Fxaf9gCrg=;
X-YMail-OSG: BwE2jygVM1lPS640tnCsamS99wlhBNDhwS3IlWt_6Yf5C23 ATzV6JIaeOfOuttGriawC0qwjePS.Uqw5P3hw_xciFgyrYJYr1wfKW_0RmLk oPFVrUGRPXil9nh5pZC89jiaUBR4EYS9k6_2ClwAf0JMb3rEwT91VbBPEeiX yl4KxPZP0Cw5_cUPYqh0dC1zHTe1k9Cv2lugeTZDznbaU207F82AbqMsm4ti P4jv7LDR34apV3A8BDGwQdtTBmhiZadA0d6rAizi6ZBph.9dfOEYIaaKvcjU 7p5t6_sTSwbPNaP_UncrtALCqThwreAkVCBTv0F66G0P_BtYFUl2zufdCqRF wBfH2eZEaqa3PNWywgNGWRPsngUWmhypXsSon2eq6Sy14ve0NZiqGhwdNi_. GC77ddUMwjki.o9iyc_uTGRNRPiiKqKT2k88-
Received: from [] by via HTTP; Fri, 29 Jun 2012 18:43:22 BST
X-Mailer: YahooMailWebService/
Message-ID: <>
Date: Fri, 29 Jun 2012 18:43:22 +0100
From: Panos Trakadas <>
To: Omprakash Gnawali <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-557664637-497515277-1340991802=:79739"
Cc: Stiemerling Martin <>, Brian Haberman <>, roll <>, Michael Richardson <>
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Panos Trakadas <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2012 17:43:28 -0000

Well, IMO it depends on the specific user requirements set by the root node. 
It could be a nice idea to investigate the metrics (and techniques like hysteresis or composition) that would commonly be used in each one of the application areas that RPL is targeting (more as a proposition/guideline for the developers). 
To be honest, we have already started reading the respective RFCs and the AMI draft to figure out the appropriate metrics per application domain in order to include them in the next version of metrics-composition draft.

On 29 Jun 2012, at 19:21, Omprakash Gnawali <> wrote:

Do we have a resolution on this topic - how to select OF+metric to be used?

- om_p

On Mon, Jun 11, 2012 at 1:27 PM, Don Sturek <> wrote:
Hi Brian,

From our experience implementing RPL and MrHOF, all devices in a RPL
instance MUST implement the same OF.

I think this is why there is so much discussion on the reflector on how to
convey the OF to the prospective joining devices.


On 6/7/12 4:22 PM, "Brian Haberman" <> wrote:

On 6/7/12 6:12 PM, Omprakash Gnawali wrote:
On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert)
<>  wrote:

On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote:

Responses inline.

On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote:

My question here is why a single objective function "MRHOF" is
defined to use several different metrics.  My understanding is
that any specific RPL instance will use one metric as its
"selected metric" for MRHOF.  Another way to organize the
objective functions would be to define a different OF number
for each metric, binding the OF number to the selected metric.

This was a design decision made early in RPL. There were two
options: OFs are metric-specific, or OFs can be general with
respect to metrics. The design team concluded the second approach
was better, as the former would lead to a possibly huge number of
OFs that would be hard to manage.

Now that a real OF has actually been designed and specified,
perhaps this would be a good time to reconfirm that design

Given that MRHOF is a pretty general objective function, and works
over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty
of code points for metric-specific OFs.

A bigger issue, I think, is expressing the semantics or behavior of
an OF in its OCP.  I read section 18.6 of RFC 6550 to indicate that
a node will use information including the OF (as indicated by the
OCP) to compare against the node's policy for joining a DODAG.  As
an aside, is there a reason why a node would choose to join a
specific DODAG within a RPL Instance and on what basis would it
make that choice?  Anyway, wouldn't the selected metric  used by
MRHOF in a particular RPL Instance be a useful parameter for the
policy rules?  For example, I can imagine a node preferring to join
a RPL Instance providing minimal latency over one providing best
ETX.  If the OCP is metric-specific, that selected metric will be
immediately available for the policy rules.

[Pascal] I agree with Ralph here. I fail to be convinced that there
will an explosion of OCPs if we fail to factorize the metrics. But
I see how the device implementation can be simplified if the OCP
says it all. Also, we do not want to force a device that implements
MRHOF to have to implement all metrics in the I-D. Conversely, say
we extend MrHof to other metrics with further work, wouldn't it
become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current
and future MrHof metric variations.

Just one clarification - MRHOF does not require the devices to
support all the metrics listed in the I-D. All it says is it must
implement at least one metric.

Excuse the pedantic question, but won't there be an issue if half the
devices in an RPL instance implement one metric and the other half
implement a different metric?  This would seem to force users to select
all their devices based on which metric they want to use.


Roll mailing list

Roll mailing list