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

[Mukul Goyal <[e-mail]>]

Hi Ralph

******************************************************************************
[Ralph1]
> 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.
> 
[Mukul1]
> 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.

[Ralph2]
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.

[Mukul2]
An OF is a function and hence is supposed to be independent of the variables (the metrics) on which it operates. If we were to link an OF with a particular metric, we would end up with a very large number of OFs.

****************************************************************************************************

[Ralph1]
> 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.
> 
[Mukul1]
> 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. 

[Ralph2]
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)?

[Mukul2]
Yes. Only the "metric object" corresponding to the selected metric should be included in the metric container. What purpose would any other "metric object" serve? The metric container can still contain other "constraint" objects. If the MRHOF draft does not say so, it should. If the metric container were to contain multiple "metric objects", a node implementing MRHOF would not know which metric is the "selected" one.

[Ralph2]
  Does a receiving node infer the selected metric for the RPL instance from the existence of a single metric in the DIO

[Mukul2]
Yes that is how it should work in my opinion.

[Ralph2]
 or does a node need to be explicitly provisioned to know the selected metric for each RPL instance? 

[Mukul2]
Requiring explicit provisioning of the selected metric does not make sense when the alternative is so easy - just require the meric container to carry one metric object, the one for the selected metric.

[Ralph2]
 Are these details specified in draft-ietf-roll-minrank-hysteresis-of-10?

[Mukul2]
No. They should be.

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

[Mukul2]
I think you are not confused. MRHOF spec should be clear in this respect.

***********************************************************************************
[Ralph1]
> 
> 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.
> 
[Mukul1]
> 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.

[Ralph2]
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.

[Mukul2]
I think the selected metric can easily be identified by requiring it to be the only metric in the metric container. Linking an OF to a particular metric does not seem like a good idea because it would mean exponential increase in the number of OFs as more "rank calculation rules" and more metrics come in use.

*********************************************************************************

[Ralph1]
> 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?
> 

[Mukul1]
> 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.

[Ralph2]
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?

[Mukul2]
When I said "routing metrics", I was referring to how, in general, the routing metrics in use in a particular instance are identified. You are right, MRHOF works with one selected metric and not multiple metrics. You are also right that Section 6 should say some thing about managing the selected metric. Even if the selected metric is to be identified as the only metric in the metric container, the Manageability section should still say some thing to the effect that all nodes that are supposed to join a particular instance using a particular selected metric must have inbuilt support for that metric.  

***************************************************************************************************

Thanks
Mukul


> [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