Subject: Re: [Roll] [roll] #53: How does an OF compute rank from metric values?

From: Mukul Goyal <[email-masked]>
Date: Thu, 17 Jun 2010 01:35:33 -0500 (CDT)

Hi Yoav

I guess I did not express myself correctly. So, let me rephrase myself:

How about if we require a metric definition to provide a mapping to an
equivalent value in a common unit (lets call it CU). 

So, the definition for latency metric will provide a mapping like:
latency 1s or more => 1000 CU
latency 700ms to 1s => 500 CU
....
latency 5ms or less => 1 CU

The definition for ETX will provide a mapping like:
ETX 100 or more => 1000 CU
ETX 50 to 100 => 500 CU
....
ETX 1 to 1.2 => 1 CU

Then, the job of objective function becomes easier; it just needs to specify how to combine metric values expressed in CU's in to the rank value. E.g. we can have an OF for weighted sum: w_1*val_1 + w_2* val_2 + ....
Here, val_1 refers to the first metric in the metric container and so on.
And w_1, w_2 etc. are specified as the TLVs in a DIO option (lets call it the OF option).
So, the OF is specified in OCP field in the configuration object and the argument/parameter values for the OF are specified in an OF option.

cheers
Mukul

Thanks
Mukul

----- Original Message -----
From: "Yoav Ben-Yehezkel" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Thursday, June 17, 2010 1:10:38 AM
Subject: RE: [Roll] [roll] #53: How does an OF compute rank from metric values?

Hi Mukul,

At least my understanding of the following is that the rank should not
necessarily be a direct mapping function of the metric. If it were,
there would have been no use for two different concepts (rank and
metric). Not
just for the sake of ranges and granularities.

"
3.6.2. Rank Properties

The rank of a node is a scalar representation of the location of that
node within a DODAG version. The rank is used to avoid and detect
loops, and as such must demonstrate certain properties. The exact
calculation of the rank is left to the Objective Function, and may
depend on parents, link metrics, and the node configuration and
policies.

The rank is not a cost metric, although its value can be derived from
and influenced by metrics. The rank has properties of its own that
are not necessarily those of all metrics:

Type: The rank is an abstract decimal value.

Function: The rank is the expression of a relative position within a
DODAG version with regard to neighbors and is not necessarily
a good indication or a proper expression of a distance or a
cost to the root.
"

If we decide to go your way - I see some potential for simplification
having just one number that determines both cost and position in the
DODAG.

Thoughts?

Regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: Thursday, June 17, 2010 8:33 AM
To: [email-masked]
Subject: Re: [Roll] [roll] #53: How does an OF compute rank from metric
values?

How about if we require a metric definition to provide a mapping to an
equivalent rank value. Then, the job of objective function becomes
easier; it just needs to combine equivalent values in the desired
manner.

Why wont this scheme work??

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Thursday, June 17, 2010 12:15:30 AM
Subject: [Roll] [roll] #53: How does an OF compute rank from metric
values?

#53: How does an OF compute rank from metric values?
--------------------------------+-------------------------------------------
Reporter: jpv@… | Owner: wintert@…
Type: defect | Status: new
Priority: major | Milestone:
Component: rpl | Version:
Severity: Active WG Document | Keywords:
--------------------------------+-------------------------------------------
We have different types of metrics with different ranges. Examples:
ETX is 16 bits. Latency is 24 bits. How do we convert these numbers to
rank in an OF? Does the range of rank depend on the range and size of
the metric?

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

_______________________________________________ Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________ Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 17 Jun 2010 11:04:24 +0300

Thanks for clarifying this.

CU is a good idea, though I think different L1/2 technologies define
different mappings for the same metric.

Very fast delay metric for some technologies may be very slow for other
technologies, so it's not just a question of metric. You also need a
normalization method to accommodate for the technology (maybe by percentage
from maximum capacity or something similar).

Taking this though one step further, IP routing can be expected as a
media-agnostic bridge between different L1/2 technologies. Do you see your
suggestion working in this case as well?

Regards,
Yoav

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]]
Sent: Thursday, June 17, 2010 9:36 AM
To: Yoav Ben-Yehezkel
Cc: [email-masked]
Subject: Re: [Roll] [roll] #53: How does an OF compute rank from metric
values?

Hi Yoav

Then, the job of objective function becomes easier; it just needs to specify
how to combine metric values expressed in CU's in to the rank value. E.g. we
can have an OF for weighted sum: w_1*val_1 + w_2* val_2 + ....
Here, val_1 refers to the first metric in the metric container and so on.
And w_1, w_2 etc. are specified as the TLVs in a DIO option (lets call it
the OF option).
So, the OF is specified in OCP field in the configuration object and the
argument/parameter values for the OF are specified in an OF option.

cheers
Mukul

Thanks
Mukul

----- Original Message -----
From: "Yoav Ben-Yehezkel" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Thursday, June 17, 2010 1:10:38 AM
Subject: RE: [Roll] [roll] #53: How does an OF compute rank from metric
values?

Hi Mukul,

"
3.6.2. Rank Properties

Thoughts?

Regards,
Yoav

-----Original Message-----

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Thursday, June 17, 2010 12:15:30 AM
Subject: [Roll] [roll] #53: How does an OF compute rank from metric
values?

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 10:36:32 +0200

> suggestion working in this case as well?

I think so since the metric may be inherited from the L2 as you said.  
The proposed
mapping function is a conversion of the metric into a CU.

> -------------------------------- 
> +-------------------------------------------
> -------------------------------- 
> +-------------------------------------------

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 17 Jun 2010 11:50:18 +0300

I couldn't quite follow your intention on whether to standardize this
mapping of metric to CU per metric.

My impression was that the mapping itself cannot be standardized because
it depends on the underlying L2 characteristics.

What can be standardized is the concept of CU with a general statement
that each L2 should map its metrics to CU or something similar. Is this
what you have in mind?

Thanks,
Yoav

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]]
Sent: Thursday, June 17, 2010 11:37 AM
To: Yoav Ben-Yehezkel
Cc: Mukul Goyal; [email-masked]
Subject: Re: [Roll] [roll] #53: How does an OF compute rank from metric
values?

> Reporter: jpv@. | Owner: wintert@.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 10:56:43 +0200

> that each L2 should map its metrics to CU or something similar. Is  

What I meant was that:
1) we do not standardize how to map the metric and the L2  
characteristics
2) we could standardize the metric -> CU calculation to compute the rank

Agree ?

JP.

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 17 Jun 2010 08:06:43 -0400

> Date: Thu, 17 Jun 2010 01:35:33 -0500 (CDT)
> From: Mukul Goyal <[email-masked]>
>
>  [etc...]

I think that we should divide the OF into two parts, a
metric combining function and DAG management function.  The
metric combining function determines which potential parents
meet the path constraints and translates the metric value(s)
into a rank, while the DAG management function makes the
decisions about which parents to use, when to send DAOs, and
the other OF responsibilities.

Relating this to your CU idea, I am suggesting that we use
rank for CU and separate the metrics->CU function from both
the metrics themselves and from the rest of the OF
functionality.

The drafts could be broken down into something like the
following:
  - The RPL draft.
  - The metric draft.
  - A draft defining a set of metric->CU/rank functions, similar
    to the cryptographic suites used by TLS and IPsec.
    Examples are minimize RTX, maximize latency, and so
    forth.  These could be used individually or in combination.
  - A DAG management function parameterized for such things
    as size of the parent set, storing/not-storing, and so
    forth.
This would be conceptually simpler than what we have now.
The metrics draft can just describe the metrics and not
contrain how they are used.  At the same time, the
management function can be completely generic about what the
metrics are and how they are combined.

                                    -Richard Kelsey

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 17 Jun 2010 21:18:31 -0500 (CDT)

Hi Yoav

>it depends on the underlying L2 characteristics.

I agree.

>that each L2 should map its metrics to CU or something similar. Is this

I agree with the first part (that the concept of CU can be standardized, i.e. the OF definition can assume that a mapping to CU exists for each metric) but not the second part (that each L2 should map its metrics to CU). Consider a situation where L2 technology A maps latency 1s to 1 CU and L2 technology B maps latency 1s to 1000 CU. Now, in an LLN consisting of both L2 technologies, we have destroyed the mapping: latency value 1000 CU no longer has any meaning.

At the moment, it seems to me that the best option is to make this mapping DAG specific. The DAG root advertizes the mapping for the metrics in use as DIO options. So, the LLN administrator just has to configure the DAG root and the mapping takes effect throughout the LLN.
 
Thanks,
Mukul

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]]
Sent: Thursday, June 17, 2010 11:37 AM
To: Yoav Ben-Yehezkel
Cc: Mukul Goyal; [email-masked]
Subject: Re: [Roll] [roll] #53: How does an OF compute rank from metric
values?

On Jun 17, 2010, at 10:04 AM, Yoav Ben-Yehezkel wrote:

> Very fast delay metric for some technologies may be very slow for
> other technologies, so it's not just a question of metric. You also
> need a
> normalization method to accommodate for the technology (maybe by
> percentage from maximum capacity or something similar).
>

> Subject: Re: [Roll] [roll] #53: How does an OF compute rank from
> metric values?
>
> Hi Yoav
>
> .... latency 5ms or less => 1 CU
>
> .... ETX 1 to 1.2 => 1 CU
>
> Then, the job of objective function becomes easier; it just needs to
> specify how to combine metric values expressed in CU's in to the rank
> value. E.g. we
> So, the OF is specified in OCP field in the configuration object and
> the argument/parameter values for the OF are specified in an OF
> option.
>
> cheers
> Mukul
>
>
>
> Thanks
> Mukul
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mukul Goyal
> Subject: Re: [Roll] [roll] #53: How does an OF compute rank from
> metric values?
>

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 17 Jun 2010 21:30:37 -0500 (CDT)

Hi Richard

>the metrics themselves and from the rest of the OF

That makes absolute sense.

>following: - The RPL draft.
>- The metric draft.

I guess there is a problem with hard-coding a CU value for a particular metric value. The mapping really depends on the context. We should simply allow a DAG root to advertize a particular mapping for a particular metric to all the nodes in the DAG. The DAG root can choose the mapping based on the context.

Thanks
Mukul

>forth. This would be conceptually simpler than what we have now.

-Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Thu, 17 Jun 2010 19:44:32 -0700

On Jun 17, 2010, at 7:30 PM, Mukul Goyal wrote:

> I guess there is a problem with hard-coding a CU value for a  
> particular metric value. The mapping really depends on the context.  
> We should simply allow a DAG root to advertize a particular mapping  
> for a particular metric to all the nodes in the DAG. The DAG root  
> can choose the mapping based on the context.
>
> Thanks
> Mukul

This seems to be getting kind of complex: a DAG specifies an  
objective function, as well as a metric->rank conversion function, as  
well as the metrics that the objective function uses?

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 17 Jun 2010 21:52:47 -0500 (CDT)

>well as the metrics that the objective function uses?

So, what is the alternative?? How would you pick a metric=>CU mapping that works in all contexts?

Thanks
Mukul

---

From: Omprakash Gnawali <[email-masked]>
Date: Thu, 17 Jun 2010 21:13:55 -0700

> So, what is the alternative?? How would you pick a metric=>CU mapping that works in all contexts?

It is not knowing what how to do this conversion that led me to ask
this question during the meeting. We seem to be on the same page that
we don't know the best way to do this.

Are there examples of general purpose OF or entities similar to OF in
use elsewhere? Maybe we can learn from them.

- om_p

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 18 Jun 2010 10:58:58 -0400

> From: Philip Levis <[email-masked]>
> Date: Thu, 17 Jun 2010 19:44:32 -0700
> 

It certainly can be complex, but it doesn't have to be.  We
want to cover the full spectrum, from just minimizing ETX to
using a weighted set of metrics that can be tuned
dynamically.  The goal is to allow for the second without
burdening simpler devices.

A DAG would specify an objective function and a metric->rank
conversion function, with the latter including which metrics
are used as inputs.  For an ETX-only DAG, the metric->rank
function can be the identity function and no metric
container is needed.  Other single metrics, such as latency,
might require metric->rank to do some scaling, in which case
a metric container is still needed.

I think that specifying the metric->rank conversion
independently of the OF and the metric values will be
simpler in the long run, as it allows us to simplify the OF
and the metric values while still supporting complex metric
calculations for those that want them.

                                 -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 19:58:14 +0200

> use elsewhere? Maybe we can learn from them.

Yes :-) in other routing protocols. The way metrics are computed is a  
local decision (from
network administrators, from an API between the MAC and IP, ...). We  
do standardize how
to convey the metric (METRIC ID), each node knows which metric to use  
(local policy) and
use it to select the best parents and propagate a DIO with the updated  
metric. The OF
indicates the set of rules for the DAG formation.

---

From: Philip Levis <[email-masked]>
Date: Mon, 21 Jun 2010 09:09:53 -0700

> calculations for those that want them.

Sure, but I hope you can understand my concern. 

The common and simple base case (ETX) is becoming rather complex.  We've gone from having multiple objective functions (OF), to having abstract objective functions whose computation is implicitly defined by metric container contents (OF + container), to abstract objective functions with metric containers and metric conversion functions (OF + container + conversion). I understand that we want to support complex use cases, but the burden on basic use cases is becoming pretty significant. 

I personally think the "abstract OF" proposal is one that seems good in theory, but is going to cause a lot of trouble in practice, in particular due to Rank. Many LLNs are deeply embedded networks: while in wired routers you can have an admin log in and debug a problem, in LLNs you often can't even observe what's happening within the network.

I don't mean to suggest that I think OF's *can't* work. I just think that right now the idea is half-baked and the concrete engineering concerns that arise haven't been seriously considered or examined. If we actually think this through (rather than hand-wave), we can understand the problem better and define OFs in a way that gives us the desired flexibility yet does not have engineering problems.

I'll return to the refrain: we're trying to standardize current practice. There are some cases where we want to add a new tweak for compelling reasons, but when we do so we should be sure we actually understand the implications.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Jun 2010 14:34:11 -0400

> Date: Mon, 21 Jun 2010 09:09:53 -0700
> 

Absolutely.  I do think that separating the metric->rank
calculation from both the metrics and the objective
function makes the whole thing simpler in the end.

> The common and simple base case (ETX) is becoming rather complex.
> We've gone from having multiple objective functions (OF), to having
> abstract objective functions whose computation is implicitly defined
> by metric container contents (OF + container), to abstract objective
> functions with metric containers and metric conversion functions (OF +
> container + conversion). I understand that we want to support complex
> use cases, but the burden on basic use cases is becoming pretty
> significant.

This is where I disagree.  The simple base case (ETX) gets
simpler if we have a separate metric->rank conversion, not
more complex.  The metric->rank conversion for ETX is trivial,
and by having a separate metric->rank conversion both the OF
and the ETX metric itself can be simplified.

> I personally think the "abstract OF" proposal is one that seems good
> in theory, but is going to cause a lot of trouble in practice, in
> particular due to Rank. Many LLNs are deeply embedded networks: while
> in wired routers you can have an admin log in and debug a problem, in
> LLNs you often can't even observe what's happening within the network.

Absolutely.  For deeply embedded networks it isn't enough to
just implement RFCs.  A lot more needs to get nailed down
than is normally done in an RFC.  In administered networks
sysadmins do the tweaking necessary to get everything
running well together, but embedded devices don't have that
luxury.  For them the tweaking will have to be standardized.
That isn't going to happen in the core RFCs.  The core RFCs
have to allow for both administered networks (the norm for
IP) and deeply embedded networks (the norm for LLNs).

> I'll return to the refrain: we're trying to standardize current
> practice. There are some cases where we want to add a new tweak for
> compelling reasons, but when we do so we should be sure we actually
> understand the implications.

The problem is that we have two different communities with
different standard practices.  Both need to be accomodated.

                                   -Richard Kelsey

---

From: [email-masked]
Date: Mon, 21 Jun 2010 13:45:52 -0500

Richard,

The need to wholly specify embedded
networks is a very salient point.  These devices have to boot strap
themselves, sniff the environment and self-configure themselves.  There
may not be a Sys Admin even allowed to enter the building for many months!

+1

Jerry

From:

Richard Kelsey <[email-masked]>

To:

Philip Levis <[email-masked]>

Cc:

[email-masked]

Date:

06/21/2010 01:31 PM

Subject:

Re: [Roll] [roll] #53: How does an OF
compute rank from metric        values?

-Richard Kelsey

_______________________________________________

Roll mailing list

[email-masked]

---

From: Philip Levis <[email-masked]>
Date: Mon, 21 Jun 2010 11:50:49 -0700

On Jun 21, 2010, at 11:45 AM, [email-masked] wrote:

> 
> 
> Richard, 
> 
> The need to wholly specify embedded networks is a very salient point.  These devices have to boot strap themselves, sniff the environment and self-configure themselves.  There may not be a Sys Admin even allowed to enter the building for many months! 
> 
> +1 
> 
> 
> Jerry 

Right -- this is why I worry whether the proposed approach of making all OFs abstract is just creating another problem. At the interim meeting I suggested that perhaps we want an OFs which is abstract and generic, for the managed cases, but also have 1-2 very specific OFs, for the unmanaged ones. Leaving ubiquitous computing/PAN technologies in the lurch because smart meters need flexibility seems like a bad decision to me.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Jun 2010 17:07:46 -0400

> Date: Mon, 21 Jun 2010 11:50:49 -0700
>
> > The need to wholly specify embedded networks is a very salient
> > point.  These devices have to boot strap themselves, sniff the
> > environment and self-configure themselves.  There may not be a Sys
> > Admin even allowed to enter the building for many months!
>
> Right -- this is why I worry whether the proposed approach of making
> all OFs abstract is just creating another problem. At the interim
> meeting I suggested that perhaps we want an OFs which is abstract and
> generic, for the managed cases, but also have 1-2 very specific OFs,
> for the unmanaged ones. Leaving ubiquitous computing/PAN technologies
> in the lurch because smart meters need flexibility seems like a bad
> decision to me.

I have been assuming that any concrete OF would be derived
from a generic OF by filling in various blanks.  That seems
organizationally simpler than creating disjoint generic and
specific OFs.

We may be thinking of two different kinds of generic OFs.
What I had in mind was a parameterized OF where the method
of setting the parameters was out of scope.  Any protocol
for specifying parameters would go in a separate document.

This would make for a minimum of three documents:
  (A) a generic OF
  (B) (A) specialized for basic ETX
  (C) a protocol for specializing (A) at runtime
A benefit of doing it this way is that it allows many
different directions for (C).  It's one thing to want to
adjust the number of DAO parents at runtime, its another to
push out a new metrics->rank function.  Both have their
uses.

                            -Richard Kelsey

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 22 Jun 2010 23:51:58 -0700

> push out a new metrics->rank function.  Both have their

Besides ETX, latency is a candidate routing metric that might be
widely used in these networks. Before we generalize OFs, it will be
great to understand how to use latency as routing metric in the
networks. Once that is done, we can examine how OF for latency is
different or similar to the OF for ETX. That comparison will tell us
if OF generalization makes sense.

Is anyone using metric such as latency with RPL yet?

- om_p

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 20:23:38 +0200

> [snip]

> for ETX is trivial,

One comment though: this is where the applicability ID comes into play.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 20:29:34 +0200

On Jun 21, 2010, at 11:07 PM, Richard Kelsey wrote:

>> for the unmanaged ones.

This does not have to be so complex, with notion such as generic and
specific OFs. In most cases, LLNs should be able to use a very small set
of OF (most of the time, just 1), with the appropriate set of metrics,  
that's it.

>> Leaving ubiquitous computing/PAN technologies

Agreed.

> for specifying parameters would go in a separate document.

Absolutely. Back to the previous comment, this is the aim of the  
applicability
IDs.

>  (B) (A) specialized for basic ETX

You do not even need (B). Just use the generic OF and use the ETX as the
metric. If another application wants to use another metric (e.g. hop  
counts or
latency) then it may very well use the same generic OF, but just use a  
different
metric.

> different directions for (C).

Yes. (C) would be the applicability statement.

> It's one thing to want to

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 20:31:50 +0200

On Jun 23, 2010, at 8:51 AM, Omprakash Gnawali wrote:

> networks.

As you know latency is already defined but I guess that you refer to
actual deployments here. That said, latency is one of these examples
where we can "easily" figure out how to use it since this is an additive
metric (used in other non-LLN IP networks).

> Once that is done, we can examine how OF for latency is

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 23 Jun 2010 16:58:50 -0400

> From: JP Vasseur <[email-masked]>
> Date: Wed, 23 Jun 2010 20:29:34 +0200
> 
> Absolutely. Back to the previous comment, this is the aim
> of the applicability IDs.

I am not so sure.  I took a look at some applicability
drafts and RFCs and they all discuss applicability, and
not things like "parameter X MUST have value Y".

> You do not even need (B). Just use the generic OF and use
> the ETX as the metric.

That assumes that the generic OF has just one knob, the
metric.  That is not at all what I was thinking of.

> Yes. (C) would be the applicability statement.

(C) is an actual protocol that distributes OF parameters,
such as the number of desired DAO parents, which metrics
to use and how to combine them, and so on, throughout a
DODAG at runtime.  That doesn't sound like an applicability
statement to me.
                                  -Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Wed, 23 Jun 2010 14:08:59 -0700

On Jun 23, 2010, at 11:29 AM, JP Vasseur wrote:

> of OF (most of the time, just 1), with the appropriate set of metrics, that's it.

I'll get back to my original concern. Simply put, I want to see how one would correctly implement an abstract OF with different metric values. I.e., a working implementation. Does anyone have one?

Om brought up one point, about metric->rank mapping. This has to be something the DODAG Root specifies in the network, unless it's just part of the metric and in the metric draft, otherwise you can have conflicting mappings. So how does RPL specify the metric->Rank mapping? If we don't resolve this, we're digging a bigger hole than the one we climbed out of.

I repeat, I'm not against abstract OFs. But I think the arguments for them haven't actually resolved the issues, and we should not assume they will be the case until we resolve these issues.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Thu, 24 Jun 2010 08:43:15 +0200

> not things like "parameter X MUST have value Y".

That depends, some do .... this is our call.

> DODAG at runtime.  That doesn't sound like an applicability

Ah yes, I was thinking of something different. This is an alternative  
approach:
distribute all of these parameters via RPL (hopefully not another  
protocol !)
but this seems like an overkill to me. Don't you think that taking  
OF0, adding
a few lines on a "generic" metric, rank<->metric computation (possibly  
in a
different ID), and distribute the metric in the DAG container (as of  
today)
would be sufficient ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 24 Jun 2010 08:52:37 +0200

Hi Phil,

On Jun 23, 2010, at 11:08 PM, Philip Levis wrote:

> I'll get back to my original concern. Simply put, I want to see how  
> one would correctly implement an abstract OF with different metric  
> values. I.e., a working implementation. Does anyone have one?
>
> Om brought up one point, about metric->rank mapping. This has to be  
> something the DODAG Root specifies in the network, unless it's just  
> part of the metric and in the metric draft, otherwise you can have  
> conflicting mappings.

Yes this is ticket #53 (but orthogonal to the use of abstract OF though)

> So how does RPL specify the metric->Rank mapping? If we don't  
> resolve this, we're digging a bigger hole than the one we climbed  
> out of.
>
> I repeat, I'm not against abstract OFs. But I think the arguments  
> for them haven't actually resolved the issues, and we should not  
> assume they will be the case until we resolve these issues.

The good news is that this does not prevent us from moving forward on  
the RPL front :-)

Let me find an hour and come back with some text, showing how this  
could be done.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 24 Jun 2010 08:54:42 +0200

Hi Phil,

Cheers.

JP.