Subject: [Roll] Routing Metrics spec v4: Clarifying how metrics are computed or aggregated in RPL

From: Phoebus Chen <[email-masked]>
Date: Tue, 09 Mar 2010 16:48:18 +0100

Dear Authors of RPL Routing Metrics Document,

I finished reading draft-ietf-roll-routing-metrics-04 and found it very 
informative. I liked the classification of metrics by characteristics on 
pg. 5. (By the way, should "local versus global" be placed in the list?)

One characteristic shared by all the metrics used by RPL is that they 
all must be computable and optimizable using one pass outward from the 
destination (root) to the source (nodes in the network).  This should be 
mentioned in the document to put the reader into the right frame of 
reference.

What types of metrics would not fit this description?  Well, a metric 
that measures the amount of leftover upwards bandwidth available at a 
node after it has been allocated to forwarding the packets of the node's 
children.  This type of metric might be useful for load balancing a 
network... for a node to signal to other nodes through its metric 
whether too many other children have already joined.  But this type of 
metric should not be allowed if you wish for the metric to track the 
rank, since the rank should not change (too much) within a DODAG 
iteration.  I'm referring to (draft-ietf-roll-rpl-07, pg. 60, Sec. 10):
"To keep loop avoidance and metric optimization in alignment,
the increase in rank should reflect any increase in the metric
value."

I recall an earlier discussion in the mailing list that OFs may combine 
several different types of metrics (throughput, latency, delay) to 
compute a node's own metric.  This might be done by taking a weighted 
linear combination of the various metrics, or by other means.  Is this 
the purpose of the TLVs in (draft-ietf-roll-routing-metrics-04, pg. 24, 
Fig. 19)?  As I understand, such metrics specific to an Objective 
Function do not deserve their own object format.  The metrics in 
Sections 3 and 4, such as Node Energy and ETX, are expected to be used 
by several objective functions, and hence are given their own object 
formats.  Is that correct?

In (draft-ietf-roll-routing-metrics-04, pg. 7, Fig. 2), there is an A 
field indicating how a node or link metric is aggregated.  I thought the 
objective function decides how to aggregate the metric.  Is the A field 
placed here instead of in the TLVs for the OCP to save space?  Does it 
make sense to make A=0x03 represent "other," telling the node to look at 
the TLVs for the OCP to specify how to aggregate the metric?  For 
instance the metric computed from an OCP might be a polynomial function 
of the metrics a node has heard from the neighbors.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus