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

[Ralph Droms <[e-mail]>]

On May 26, 2012, at 1:26 AM 5/26/12, Mukul Goyal wrote:

> Hi Michael
> 
> This would be my response to the questions Ralph asked.
> 
> Thanks
> Mukul

Mukul - thanks for responding to my questions...

> [Ralph]
> 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.
> 
> [Mukul]
> 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.

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.

> [Ralph]
> 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.
> 
> [Mukul]
> 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. 

As I wrote above, my understanding is that a particular RPL instance that specifies MRHOF will use one metric as the selected metric across the entire RPL instance.  Is it the case that a node includes only the metric object for the selected metric in a DIO (or no metric object in the case of ETX as the selected metric)?  Does a receiving node infer the selected metric for the RPL instance from the existence of a single metric in the DIO or does a node need to be explicitly provisioned to know the selected metric for each RPL instance?  Are these details specified in draft-ietf-roll-minrank-hysteresis-of-10?

Or, am I confused about the binding between a DIO and a RPL instance?

> [Ralph]
> 
> 3. Based on (1) and (2), would configuration and selection issues be
> ameliorated if the five candidate selected metrics were each assigned
> a separate objective function?  Use of a separate OF code point for
> each of the five possible selected metrics would allow multiple RPL
> instances.
> 
> [Mukul]
> 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.

OK, but if multiple RPL instances use MRHOF, there is no way for a node to determine which metric is the selected metric for the various RPL instances.

> [Ralph]
> 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
> metric?
> 
> [Mukul]
> 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.

You refer to "routing metrics".  Isn't it the case that a specific RPL instance uses only one metric as the selected metric across all nodes in the RPL instance?

Are the nodes configured in the "installer provisioning" (section 6.1) or do nodes infer the selected metric from the metric included in the DIO?

> [Ralph]
> 5. In section 3.2.2:
> 
>   a
>   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?"
> 
> [Mukul]
> That makes sense to me.

OK.

> [Ralph]
> 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.
> 
> [Mukul]
> That particular statement indeed sounds redundant to me. I think every RPL implementation MUST understand the DODAG Configuration Option.

OK.

- Ralph