[Roll] [roll] #98: Who decides what metrics go in the metric container inside the Measurement Request?

["roll issue tracker" <[e-mail]>]

#98: Who decides what metrics go in the metric container inside the Measurement
Request?

 Discussion:
 [Philip]
 The one major thing that seems to be missing in the document, however, is
 exactly how one populates and updates the metric container. For example,
 what metrics should a node put into the metric container? The metrics that
 the DODAG root is advertising for that RPL Instance? What happens if the
 network is using MRHOF and so ETX directly through Rank? The only text I
 can find is the last paragraph of 5.0:

 "   Next, the router MUST update the routing metric objects, contained in
   the Metric Container options inside the MO, either by updating the
   aggregated value for the routing metric or by attaching the local
   values for the metric inside the object.  After updating the routing
   metrics, the router MUST unicast the MO to the next hop."

 Is it that the metric container behavior is specified elsewhere? If not,
 then it's possible for a node meeting this document specification to do
 whatever it wants with the metric container. I can see a few options:

 1) The originator specifies the metrics of interest and nodes update this
 value as they generate responses/replies. Part of the challenge here is a
 question of whether one is measuring the forward or reverse route,
 something the document should be clearer on. This has the advantage that
 it requires less coordination and specification with respect to RPL and
 OFs. It has the disadvantage that a node could request a metric the
 network does not support.

 2) All nodes follow the metrics in DIOs. This has the advantage that the
 ability to handle these metrics is well defined by a RPL instance. It has
 the disadvantage that it requires coordinating how OFs manage metrics with
 path discovery.

 [Mukul]

 1) The originator specifies the metrics of interest and nodes update this
 value as they generate responses/replies. Part of the challenge here is a
 question of whether one is measuring the forward or reverse route,
 something the document should be clearer on. This has the advantage that
 it requires less coordination and specification with respect to RPL and
 OFs. It has the disadvantage that a node could request a metric the
 network does not support.

 This is what we have in mind. I will make it clear in the next revision of
 the draft. Also, I will clarify that the route being measured is the one
 in forward direction (from the origin to the target) and an intermediate
 router MUST drop a Measurement Request if it cannot update (or add local
 value to) a routing metric specified inside the Metric Container.

 Thanks
 Mukul

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  applicability-ami      |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/98>
roll <http://tools.ietf.org/wg/roll/>