[Roll] Ralph's DISCUSS on MRHOF spec

Mukul Goyal <mukul@uwm.edu> Sat, 26 May 2012 05:26 UTC

Return-Path: <prvs=486a8a597=mukul@uwm.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E121F851C for <roll@ietfa.amsl.com>; Fri, 25 May 2012 22:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.297
X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X8wytaV5WCiR for <roll@ietfa.amsl.com>; Fri, 25 May 2012 22:26:23 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu []) by ietfa.amsl.com (Postfix) with ESMTP id A19F521F851A for <roll@ietf.org>; Fri, 25 May 2012 22:26:23 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAC5owE9/AAAB/2dsb2JhbABEhTazBiNWKQwCDRkCWQaIHqYliSiJBIEkjguBEgOIP4xXj3CCfg
Received: from localhost (localhost.localdomain []) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D97FD12E3BB; Sat, 26 May 2012 00:26:22 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([]) by localhost (mta02.pantherlink.uwm.edu []) (amavisd-new, port 10024) with ESMTP id Rs43AiX6OezO; Sat, 26 May 2012 00:26:22 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu []) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9BEF712E3BA; Sat, 26 May 2012 00:26:22 -0500 (CDT)
Date: Sat, 26 May 2012 00:26:22 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Michael Richardson <mcr@sandelman.ca>
Message-ID: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <566085064.521293.1338006033112.JavaMail.root@mail17.pantherlink.uwm.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll <roll@ietf.org>
Subject: [Roll] Ralph's DISCUSS on MRHOF spec
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 May 2012 05:26:24 -0000

Hi Michael

This would be my response to the questions Ralph asked.


1.  Why is one objective function defined for several potential
metrics?  The details of MRHOF seem to preclude the establishment of
several RPL instances in an LLN, each of which uses MRHOF with a
different selected metric.

It is certainly possible to establish multiple RPL Instances in an LLN with MRHOF (or any other OF) as the OF. These RPL Instances may or may not use different routing metrics. An RPL Instance is associated with one particular OF as per RFC 6550. The OF converts the aggregated routing metric values to a rank value. Whether a particular OF could work with a particular metric depends on the OF. E.g. MRHOF specification says that MRHOF only works with additive metrics. So, the choice of routing metrics to be used in a particular DODAG (identified by the DODAGID) inside a particular RPL Instance may depend on the particular OF being used but, in general, the choice of OF and the choice of routing metrics are separate/independent issues.

2. How are the nodes in the RPL instance informed about the selected
metric?  My understanding of RPL is that only the objective function
is included in the DIO received as an advertisement for a particular
RPL instance, which means a node can't know the selected metric for
that RPL instance and can't meaningfully decide among multiple RPL
instances all using MRHOF as the objective function.

As a followup to (1), if there were a way to encode the selected
metric for a RPL instance in the DAO, a node would be able to select
which RPL instance to use for a particular type of traffic.

The root of a DODAG includes the selected metric objects in the Metric Container Option(s) inside its DIO. The nodes that join this DODAG include the same metric objects in their DIOs and so on. Thats how the nodes come to know which routing metrics are in use in a particular DODAG in a particular RPL Instance. 


3. Based on (1) and (2), would configuration and selection issues be
ameliorated if the five candidate selected metrics were each asssigned
a separate objective function?  Use of a separate OF code point for
each of the five possible selected metrics would allow multiple RPL

Multiple RPL instances with same OF are already allowed. The whole idea behind OF is to separate the rank selection logic from the routing metrics.

4. Related to the above, I don't see anything in section 6 about
managing the selected metric.  Don't all of the nodes that join a RPL
instance using MRHOF have to be configured to use the same selected

Yes. As mentioned above, the root of a DODAG selects which routing metrics would be used and includes these metric objects inside the Metric Container inside the DIO. A node can join this DAG only if it supports the routin metrics being used.

5. In section 3.2.2:

   node MAY use a different objective function to select which of these
   neighbors should be considered to have the lowest cost.

seems to contradict the statement in the Introduction that "all nodes
in a network use a common OF."  Should "different objective function"
be replaced with "some other selection criteria?"

That makes sense to me.

6. In section 5, are the RECOMMENDED values appropriate for all
selected metrics or just for ETX?  Are there any references that might
be cited that would give background on the working group experience
with ETX and the development of the recommended values?

7. In section 6.1, why not "MUST support the DODAG Configuration
option?"  I don't see any RFC 2119 requirements on the implementation
of the DODAG Configuration option (which would appera to be an
oversight), but I don't understand how a node can operate in a RPL
instance without, for example, being able to determine the Objective
Function used by that instance.

That particular statement indeed sounds redundant to me. I think every RPL implementation MUST understand the DODAG Configuration Option.