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

Omprakash Gnawali <> Fri, 29 June 2012 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 766D121F882E for <>; Fri, 29 Jun 2012 10:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.077
X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cn9lMndliRFu for <>; Fri, 29 Jun 2012 10:54:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 882C921F8817 for <>; Fri, 29 Jun 2012 10:54:29 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 2ACB823CAAA for <>; Fri, 29 Jun 2012 12:54:26 -0500 (CDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h8ezq5XzPeuF for <>; Fri, 29 Jun 2012 12:54:26 -0500 (CDT)
Received: from ( []) by (Postfix) with ESMTP id 638D723CAAD for <>; Fri, 29 Jun 2012 12:54:23 -0500 (CDT)
Received: from ( []) by (Postfix) with ESMTP id CE6092A280CE for <>; Fri, 29 Jun 2012 12:53:35 -0500 (CDT)
Received: by pbcwy7 with SMTP id wy7so5022588pbc.31 for <>; Fri, 29 Jun 2012 10:54:25 -0700 (PDT)
Received: by with SMTP id o2mr2277161pax.36.1340992465393; Fri, 29 Jun 2012 10:54:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 29 Jun 2012 10:54:05 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Omprakash Gnawali <>
Date: Fri, 29 Jun 2012 10:54:05 -0700
Message-ID: <>
To: Panos Trakadas <>
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: quoted-printable
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
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:54:30 -0000

Sorry, I should have been clearer. I was asking if we have a consensus
that it is the combination of:

1. metric in the DIO, and
2. OCP

that will tell us which metric+OF we have decided to use.

Most thought that this is the case but there were some with the
opinion that it might be clearer to use  separate OCP for each
metric,OF combination.

It is clear that we will benefit by explicitly stating how to tell
what metric+OF is used in the network. Unless there is any objection,
I will will proceed with the explanation that metric selection is
indicated by the presence of the metric in the container and OF
selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and
ETX will be in the metric container.

There was a separate discussion on allocating some OCP for
proprietary/private OFs that people might want to have but that is a
separate discussion.

- om_p

On Fri, Jun 29, 2012 at 10:43 AM, Panos Trakadas <> wrote:
> 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.
> Panos
> 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.
> Don
> 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
> decision.
> 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.
> Regards,
> Brian
> _______________________________________________
> Roll mailing list
> _______________________________________________
> Roll mailing list