Subject: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

From: David Culler <[email-masked]>
Date: Thu, 16 Sep 2010 06:56:13 -0700

The routing metrics draft has now gone through 9 revisions over the past 16 months, the diffs have narrowed to essentially wording and editorial changes, and the comments are few and non-controversial.  Thus, it appears that consensus has emerged and we can LC this I-D.

This email is to announce Working Group Last Call on draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST, Sept. 30 2010.  Please read it thoroughly and forward all final comments to the authors and the WG mailing list.  

Thanks all for your good work.  We're on a ROLL.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 00:12:39 +0200

David,

Thanks for this Last Call on the RoLL routing metrics draft.

I reply now just to make sure I replied before the September 30th, 2010,
the deadline Chair set and that I consider.

I have proposed last year to have energy link metrics: how much energy
in Joules is required on a particular link to send 1280bytes as an IPv6
packet.

I have proposed this link metric also as an extension to the ripless
draft-mulligan-roll-ripless-01.

In draft-ietf-roll-routing-metrics energy _is_ used as a metric but as
node energy only, not link energy.

Link metrics _are_ considered in draft-ietf-roll-routing-metrics but
not as energy.

Private discussion pointed me unilaterally I may be wrong but I think
publicly I may be right.

I will send more comments later.

Alex

Le 16/09/2010 15:56, David Culler a écrit :
> The routing metrics draft has now gone through 9 revisions over the
> past 16 months, the diffs have narrowed to essentially wording and
> editorial changes, and the comments are few and non-controversial.
> Thus, it appears that consensus has emerged and we can LC this I-D.
>
> This email is to announce Working Group Last Call on
> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST,
> Sept. 30 2010.  Please read it thoroughly and forward all final
> comments to the authors and the WG mailing list.
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Philip Levis <[email-masked]>
Date: Sat, 18 Sep 2010 09:10:47 -0700

> I will send more comments later.

Alex,

Can you point me to an application requirements doc, or a concrete application someone is building today, where link energy is needed? Given the tremendous size and diversity of the industries around LLNs, as well as the application experience, I think our goal is to standardize current practice rather than invent new mechanisms.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 19:34:17 +0200

Le 18/09/2010 18:10, Philip Levis a écrit :
>> I reply now just to make sure I replied before the September 30th,
>>  2010, the deadline Chair set and that I consider.
>>
>> I have proposed last year to have energy link metrics: how much
>> energy in Joules is required on a particular link to send 1280bytes
>> as an IPv6 packet.
>>
>> I have proposed this link metric also as an extension to the
>> ripless draft-mulligan-roll-ripless-01.
>>
>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric but
>> as node energy only, not link energy.
>>
>> Link metrics _are_ considered in draft-ietf-roll-routing-metrics
>> but not as energy.
>>
>> Private discussion pointed me unilaterally I may be wrong but I
>> think publicly I may be right.
>>
> Can you point me to an application requirements doc, or a concrete
> application someone is building today, where link energy is needed?
> Given the tremendous size and diversity of the industries around
> LLNs, as well as the application experience, I think our goal is to
> standardize current practice rather than invent new mechanisms.

Mechanisms required by link energy are not new inventions.  The first
transatlantic wireless transmissions had a need of so much energy that
new power generators were built only for transmitting 3 dots.

These days I need to turn off my wifi on PDA if battery is too low.
Machine devices have similar energy requirements to Tx.  In these
devices there is a direct relationship between energy and Tx.

This is a difference in perspective.  Draft seems to consider only the
energy of the computing in these devices (residual energy left on the
node) because that's what intelligent LiIon batteries report.

There exist devices which don't have these intelligent LiIon batteries
but much simpler batteries.  When so, there's no need to stay bound on
what manufacturer reports as residual energy.  But there is still need
to know how much energy is needed to transmit data.  And that can be
measured offline, independent of the battery type.  It depends mainly on
the coding scheme, range, frequency.

If a metric shows the node energy is so large compared to the energy
needed to transmit data then we have a hard time using that node
metric in a routing protocol.  This is because when we analyze the
granularity of expressing that node energy we get 3: mains, battery,
scavenger (in the draft).  Only these 3 can not compare among
themselves, which is not good either (is "battery" more than
"scavenger"? which battery?  which scavenger?).

Being on "battery" does not tell a routing protocol whether transmitting
data on a node's wifi vs its bluetooth is better.  Whereas a routing
protocol chooses outgoing interfaces (based on metrics) - that's its goal.

The goal of a routing protocol is not optimize the node energy, it is to
optimize paths.

If one needs a node energy optimization protocol, or a network energy
optimization protocol - then yes, node energy metrics are paramount.

This is a requirements discussion we never had anyways but which is
pertinent.

(draft typo says "These include main-powered" - that is mains-powered).

I understand the need to stay as simple as possible between Watt, Ah, A
and other manufacturer-dependent ways of expressing node energy.  But I
think the result of a 3-value space, uncomparable values, node-energy
only, is questionable.

Alex

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 18 Sep 2010 18:37:20 +0100

Caveat emptor: I have not read the entire metrics-09 at this point, but
wanted to comment anyway.

I think the idea of "link energy" would be without much merit, of course I'm
open to being wrong. My reasoning is as follows:

1) There will not be much difference between the energy it takes to transmit
a packet within a RPL network. They will all be using similar link layers,
and much of the power of actually transmitting a packet is not related to TX
power but getting everything else up (such as CPU running & processing, PLL
being active and locked, CSMA being performed).

As an example for one specific radio, the ATMega128RFA1, the values of
current vs power output (from datasheet @ 3.0V):
RX PWR | Supply
 3dBm  | 14.5mA
 1dBm  | 10mA
-3dBm  | 9mA
-17dBm | 8mA

Converting both to mW (= mJ/s)
RX PWR | Supply
 2.00  |  43.5
 1.26  |  30
 0.50  |  27
 0.02  |  24

This is just current during active TX. There are some additional things that
are TX power independent, but I think for any reasonable length 6LoWPAN
packet they are much smaller than the values I have here. 

2) Receiving takes around the same amount of power as transmitting for most
802.15.4 nodes. For the previously used example that is around 12mA in fact.
Thus the problem is not only TX power, but RX power. How do you encapsulate
that in "link energy" accurately? If you do it in simple ways with "fudge
factors" you've probably lost enough accuracy to bother doing it at all.

3) Link energy on its own would result in selecting lowest energy paths I
assume. Low power nodes which advertise smaller link energies have probably
gone to great lengths to get low link energies, since they have low
available power. The nodes which are wall-powered won't try to get link
energy as low since they are free to transmit at highest energy and not
worry too much about power saving tricks. This would be the opposite of what
you want, so obviously you combine link energy with available energy.

Combining link energy with available energy would be incredibly complex to
get perfect. Worse if you do it wrong you end up with the exact opposite of
what you want since low-power paths are used at the expense of battery life.
At least there is some obvious connection between a simple "available
energy" value and "am I likely to be used to route a packet".

4) Transmit energy also depends on link reliability for most wireless
networks, since they have an acknowledgment system. Thus an unreliable link
may actually take much more than the expected power to transmit every frame,
since it's often doing retries. I would expect a few retransmissions to
basically nullify a lot of work selecting the "most optimum" routes from an
energy perspective.

6) My conclusion from the above points is that the entire question of RX/TX
power is too complex to bother doing perfectly in these networks. A
simplification that can at least be easily understood and specified would be
more useful to everyone in the end than something that is more complex and
might not even work. 

Using such a metric DOES require external documents to specify how the
metric is used. But requiring external specification to work out details
seems inline with the rest of RPL so shouldn't be a problem.

And if in the future I'm completely wrong and someone needs link energy, I
don't see a problem of fitting the link energy into a TLV in the "node
energy object".

Warm Regards,

  -Colin O'Flynn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: September 18, 2010 5:11 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

Alex,

Can you point me to an application requirements doc, or a concrete
application someone is building today, where link energy is needed? Given
the tremendous size and diversity of the industries around LLNs, as well as
the application experience, I think our goal is to standardize current
practice rather than invent new mechanisms.

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

---

From: Philip Levis <[email-masked]>
Date: Sat, 18 Sep 2010 10:43:45 -0700

> think the result of a 3-value space, uncomparable values, node-energy

Alex, I'm sorry, but this is all fluffy hand-waving. I'll repeat: 

  Can you point me to an application requirements doc, or a concrete LLN application someone is building today, where link energy is needed?

Phil

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 18 Sep 2010 18:44:30 +0100

Ah looks like I missed this message by a minute or two, I just sent out some
comments of my own. 

>But I

The important consideration for this group: is the default 3-value space
suggested  enough for the most basic case? I think the answer is 'yes' but
would appreciate other comments.

Additional TLVs can be proposed later to expand on node energy. But the most
basic form should surely include only the minimal required amount of
information.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: September 18, 2010 6:34 PM
To: Philip Levis
Cc: [email-masked]
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 20:15:35 +0200

> a packet within a RPL network. They will all be using similar link layers,

Take a car: all devices are on a single unique battery, yet many 
different copper, light and ether links in terms of energy needed.

(in a car - how would a "battery" value of the metric which assumes
  each IP addressable device has its own "battery" work with RPL?  All
  devices in the car are on the same unique battery, and sometimes on
  car engine electricity generator. Add to this the Electric Vehicle and
  you see.)

> power but getting everything else up (such as CPU running&  processing, PLL

That is right.  Each transmitting device has CPU chipset to compute 
wireless coding and that takes energy.  That energy is in higher orders 
of magnitude than actually transmitting.

However the energy used to actual Tx (and Rx as in GPS devices) can be 
clearly distinguished.

> This is just current during active TX.

That sounds exellent startpoint for design a link energy metric!  To 
eliminate the time paramter (mJ/s) to get to the J only  we could decide 
that we need to transmit 1280bytes of data - the IPv6 minimal MTU.

> There are some additional things that

Are we IPv6 perspective or not.  If yes IPv6 stack needs to know how 
much energy is needed 1280bytes of data, a minimally sized IPv6 packet. 
  The stack reasons in terms of packets of that or larger size.

> Thus the problem is not only TX power, but RX power.

With GPS devices it is even truer, because they only receive.

> How do you encapsulate
> that in "link energy" accurately?

Well I proposed a metric bit encoding for it - should I send again?

> If you do it in simple ways with "fudge

I don't propose fudge factors.

> you want, so obviously you combine link energy with available energy.

I would not combine.

> what you want since low-power paths are used at the expense of battery life.

What is battery life when birth and death is turning an engine on/off? 
Or when plugging the device on a docking.  Or when plugging a vehicle on 
an outlet.

> energy" value and "am I likely to be used to route a packet".

Node energy helps it that way, yes.

> networks, since they have an acknowledgment system.

Yes, retransmissions at link layer are a link layer problem, dealt with 
by power management of the link layer.  IP stack cares about TCP 
retransmissions or above.

> Thus an unreliable link

Hmmm... retransmissions may happen too for a node energy metric and that 
may nullify its effect too.

> more useful to everyone in the end than something that is more complex and

If we wish we could discuss separately the actual use of the existing 
node energy metric and I think it's not that simple either.

> don't see a problem of fitting the link energy into a TLV in the "node

I am happy to see openness to include link energy metric and I take note 
for future discussion.

But link energy is link energy not node energy.  We saw it in the above 
mAmpere discussion where you eliminated the computing power to which I 
agreed; yet it doesn't make sense conceptually to put link energy into a 
node energy container.  Link energy values are distinct from node energy 
values.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 20:17:33 +0200

> would appreciate other comments.

My comment is no.  Node energy metric assumes each node is on its own 
power, it doesn't treat more complex powering systems as in a car which 
does need LLN-kind of networks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 20:18:25 +0200

Le 18/09/2010 19:43, Philip Levis a écrit :
>> Mechanisms required by link energy are not new inventions.  The
>> first transatlantic wireless transmissions had a need of so much
>> energy that new power generators were built only for transmitting 3
>> dots.
>>
>> These days I need to turn off my wifi on PDA if battery is too
>> low. Machine devices have similar energy requirements to Tx.  In
>> these devices there is a direct relationship between energy and
>> Tx.
>>
>> This is a difference in perspective.  Draft seems to consider only
>> the energy of the computing in these devices (residual energy left
>> on the node) because that's what intelligent LiIon batteries
>> report.
>>
>> There exist devices which don't have these intelligent LiIon
>> batteries but much simpler batteries.  When so, there's no need to
>> stay bound on what manufacturer reports as residual energy.  But
>> there is still need to know how much energy is needed to transmit
>> data.  And that can be measured offline, independent of the battery
>> type.  It depends mainly on the coding scheme, range, frequency.
>>
>> If a metric shows the node energy is so large compared to the
>> energy needed to transmit data then we have a hard time using that
>> node metric in a routing protocol.  This is because when we analyze
>> the granularity of expressing that node energy we get 3: mains,
>> battery, scavenger (in the draft).  Only these 3 can not compare
>> among themselves, which is not good either (is "battery" more than
>> Being on "battery" does not tell a routing protocol whether
>> transmitting data on a node's wifi vs its bluetooth is better.
>> Whereas a routing protocol chooses outgoing interfaces (based on
>> metrics) - that's its goal.
>>
>> The goal of a routing protocol is not optimize the node energy, it
>> is to optimize paths.
>>
>> If one needs a node energy optimization protocol, or a network
>> energy optimization protocol - then yes, node energy metrics are
>> paramount.
>>
>> This is a requirements discussion we never had anyways but which
>> is pertinent.
>>
>> I understand the need to stay as simple as possible between Watt,
>> Ah, A and other manufacturer-dependent ways of expressing node
>> energy.  But I think the result of a 3-value space, uncomparable
>> values, node-energy only, is questionable.
>
> LLN application someone is building today, where link energy is
> needed?

Why do you ask?  You think I can't?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 18 Sep 2010 20:21:08 +0200

I consider I don't do fluffy handwaving.  I can send significant 
comments on the draft if you're open to them.

I just don't want to waste my time only to receive "no" comments.

Alex

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 18 Sep 2010 22:49:46 +0100

Hi Alex,

I think we have some different assumptions about the usage model. It would
be useful to clarify some of that first. I'm not claiming my assumptions are
correct or consistent with the ROLL/RPL basis, these are simply my view of
how I imagined it would all fit together:

1) A single RPL network itself does not cross multiple PHY layers. Crossing
PHY layers would complicate the decision on "best routes" partially for the
reasons you mention. My comments before showing TX power vs current was
showing that for the same PHY layer you can have a huge swing of TX power
yet minimal impact on energy required to transmit a packet (100x change in
RF energy = less than 2x change in total energy).  

2) Routing metrics are not universal, but will somewhat be
application-dependant. Thus you can change the metrics for different nodes
as required, and metrics might not make sense between different RPL networks
(this fits in with assumption #1). 

Thus my view was the metrics should be simple, as you hide any required
customization. If you want to select the outgoing interface you have some
artificial change in the metric, where the administrator has basically
forced the device to prefer interface 1 over interface 2. 

In your given example of an automotive system where they all work on a
common power source, the nodes have a specific routing metric where a
certain "fudge factor" has been worked into the different nodes. Thus all
other things being equal, the advertised metric of a node which takes a lot
of energy to transmit is made such that it is less preferred over another
node.

I think you are assuming that (1) you can have different PHYs within the RPL
network, and (2) the routing metrics are more universal, so you can compare
two different RPL networks. Is this correct?

I've included some clarifications below as well (see <CPO> </CPO>), but I
think the above two points are most important to understanding why we may
see such a wide difference of opinion.

Regards,

  -Colin

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: September 18, 2010 7:16 PM
To: Colin O'Flynn
Cc: 'Philip Levis'; [email-masked]
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

<CPO>I meant that you would then require information on both TX & RX power
if you wanted to be accurate. So you'd have to add more metrics there, and
add two values for every hop.</CPO>

<CPO>My example is 802.15.4/6LoWPAN specific, as that was just 802.15.4
packets. I just meant for any reasonable size 802.15.4 packet seen on a
6lowpan/IPv6 network you don't need to worry about CSMA time for example, as
it's fairly minimal by comparison. </CPO>

<CPO>I looked back to I think may 2009 when I saw a discussion about it, if
it was before that I probably missed it</CPO>.

I would not combine.

<CPO> Combine was a poor choice of words on my part. I meant it uses both
the link energy & node energy, and "combines" them to create a routing
solution. So if you had separate link energy & node energy, figuring out how
to use both of them would be a complex problem. </CPO>

<CPO>I don't mean retransmission of the metric, I just meant retransmissions
in general. It's a question of all this overhead exchanging metrics to
maintain a perfect route, when in the end you spent more time maintain your
route than routing data! So I think for link energy to be 'accurate', you'd
also need to keep the ETX object updated for example. </CPO>

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 19 Sep 2010 21:29:09 +0200

[my summary: it is worth clarifying (1) whether RPL runs in a single
  PHY or multiple PHY network, and (2) whether metrics for RPL should be
  understood in RPL network only or more universal like across the
  Internet.  There are also points about whether Rx link energy is as
  important as Tx link energy and its usability overall.]

Hi Colin,

It does make sense to clarify the usage model first, especially the
assumptions of whether or not RPL runs exclusively on networks made of
single PHY, or multiple PHYs.

I consider IP kind of work (do we say IPv6? 'router'?) is needed only if
we consider multiple kinds of PHYs in the same network.  Otherwise
bridges, range extenders and other L2 tools are better appropriate than
IP routers.

During RPL comments we commented whether RPL draft text should say
_only_ 802.15.4 or would it include PLC too.  I think RPL draft text
saying _only_ 802.15.4 would make subsequent metrics and security text
much easier.  However, it was insisted PLC should be there in the draft.
  So I am in that perspective now.

But does that mean that RPL runs only on a network consisting of PLC
devices, and on another network of 15.4 devices (separated by an Edge
Router)?  Or does it mean RPL runs in a network mixing 15.4 devices
with PLC devices each being an RPL router?

This was never clear.

Le 18/09/2010 23:49, Colin O'Flynn a écrit :
> Hi Alex,
>
> I think we have some different assumptions about the usage model. It
> would be useful to clarify some of that first. I'm not claiming my
> assumptions are correct or consistent with the ROLL/RPL basis, these
> are simply my view of how I imagined it would all fit together:
>
> 1) A single RPL network itself does not cross multiple PHY layers.
> Crossing PHY layers would complicate the decision on "best routes"
> partially for the reasons you mention. My comments before showing TX
> power vs current was showing that for the same PHY layer you can
> have a huge swing of TX power yet minimal impact on energy required
> to transmit a packet (100x change in RF energy = less than 2x change
> in total energy).

(The energy used for transmission is the one measured by setting a 
highres ampermeter serially with the transmitting device, its battery 
and a shunt, make it send an IPv6 packet (type ping).  That shows the 
energy used for transmission.  This is just a rough view, but basically 
that is.  There are related measurement tools like antena placed near 
emitter (the ones used to measure the DAS of mobile phones W/Kg).)

> application-dependant. Thus you can change the metrics for different
> nodes as required, and metrics might not make sense between
> different RPL networks (this fits in with assumption #1).
>
> Thus my view was the metrics should be simple, as you hide any
> required customization. If you want to select the outgoing interface
> you have some artificial change in the metric, where the
> administrator has basically forced the device to prefer interface 1
> over interface 2.

Yes, the metric should be simple.  The simplest relates much to what 
exists in terms of how IP routers select their output interface without 
artificial human intervention.

> In your given example of an automotive system where they all work on
> a common power source, the nodes have a specific routing metric
> where a certain "fudge factor" has been worked into the different
> nodes. Thus all other things being equal, the advertised metric of a
> node which takes a lot of energy to transmit is made such that it is
> less preferred over another node.
>
> I think you are assuming that (1) you can have different PHYs within
> the RPL network, and (2) the routing metrics are more universal, so
> you can compare two different RPL networks. Is this correct?

Yes, right, that is my assumption: different PHYs within an RPL network
and routing metrics more universal - they'd work within the RPL network
and across the Internet (like the simple hopcount metric), and one could
also compare different RPL networks.

Do we want metrics that work _only_ within an RPL network?  Or more 
universal like across the Internet?  Or both?  This is also a 
requirement discussion which is worth clarifying.

> I've included some clarifications below as well (see<CPO>  </CPO>),
> but I think the above two points are most important to understanding
> why we may see such a wide difference of opinion.

YEs, the above points about RPL running in a single PHY or multiple PHY 
network, and metric only worth in RPL or across the Internet, are 
important to clarify.

> Regards,
>
> -Colin
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: September 18, 2010 7:16
> PM To: Colin O'Flynn Cc: 'Philip Levis'; [email-masked] Subject: Re:
> [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt
>
>> Caveat emptor: I have not read the entire metrics-09 at this
>> point, but wanted to comment anyway.
>>
>> I think the idea of "link energy" would be without much merit, of
>> course
> I'm
>> 1) There will not be much difference between the energy it takes
>> to
> transmit
>  car engine electricity generator. Add to this the Electric Vehicle
> and you see.)
>
>> and much of the power of actually transmitting a packet is not
>> related to
> TX
>> power but getting everything else up (such as CPU running&
>> processing,
> PLL
> wireless coding and that takes energy.  That energy is in higher
> orders of magnitude than actually transmitting.
>
> However the energy used to actual Tx (and Rx as in GPS devices) can
> be clearly distinguished.
>
> <CPO>I meant that you would then require information on both TX&  RX
> power if you wanted to be accurate. So you'd have to add more
> metrics there, and add two values for every hop.</CPO>

Hmmm... that sounds right.  To be better accurate about link energy
metrics one would have to do both Tx metric and Rx metric.  This could
be done.  I was thinking that presenting first the Tx link energy metric
it would be easier to understand and then add the Rx metric too, naturally.

>> As an example for one specific radio, the ATMega128RFA1, the
>> values of current vs power output (from datasheet @ 3.0V): RX PWR
>> | Supply 3dBm  | 14.5mA 1dBm  | 10mA -3dBm  | 9mA -17dBm | 8mA
>>
>> Converting both to mW (= mJ/s) RX PWR | Supply 2.00  |  43.5 1.26 |
>> 30 0.50  |  27 0.02  |  24
>>
>  eliminate the time paramter (mJ/s) to get to the J only  we could
> decide that we need to transmit 1280bytes of data - the IPv6 minimal
> MTU.
>
>> There are some additional things that are TX power independent,
>> but I think for any reasonable length 6LoWPAN packet they are much
>> smaller than the values I have here.
>
>  much energy is needed 1280bytes of data, a minimally sized IPv6
> packet. The stack reasons in terms of packets of that or larger
> size.
>
> <CPO>My example is 802.15.4/6LoWPAN specific, as that was just
> 802.15.4 packets. I just meant for any reasonable size 802.15.4
> packet seen on a 6lowpan/IPv6 network you don't need to worry about
> CSMA time for example, as it's fairly minimal by comparison.</CPO>

Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6 MTU
1280bytes.  I am not sure I understand why should IPv6 stack worry about
smaller data-link packets but I have to dig this, e.g. see whether the
linux stack does consider smaller than 1280bytes or not.

>> 2) Receiving takes around the same amount of power as transmitting
>> for
> most
>> 802.15.4 nodes. For the previously used example that is around
>> 12mA in
> fact.
>> How do you encapsulate that in "link energy" accurately?
>
> <CPO>I looked back to I think may 2009 when I saw a discussion about
> it, if it was before that I probably missed it</CPO>.

Ok, I will resend tomorrow an an example of encoding energy link metric
for RA (it's on my office desktop).

>> If you do it in simple ways with "fudge factors" you've probably
>> lost enough accuracy to bother doing it at all.
>
>> 3) Link energy on its own would result in selecting lowest energy
>> paths I assume. Low power nodes which advertise smaller link
>> energies have
> probably
>> available power. The nodes which are wall-powered won't try to get
>> link energy as low since they are free to transmit at highest
>> energy and not worry too much about power saving tricks. This
>> would be the opposite of
> what
> <CPO>  Combine was a poor choice of words on my part. I meant it
> uses both the link energy&  node energy, and "combines" them to
> create a routing solution. So if you had separate link energy&  node
> energy, figuring out how to use both of them would be a complex
> problem.</CPO>

I agree using both node and link energy in a single metric would make it
more complex.

>> Combining link energy with available energy would be incredibly
>> complex to get perfect. Worse if you do it wrong you end up with
>> the exact opposite
> of
>> what you want since low-power paths are used at the expense of
>> battery
> life.
>
> What is battery life when birth and death is turning an engine
> on/off? Or when plugging the device on a docking.  Or when plugging
> a vehicle on an outlet.
>
>> At least there is some obvious connection between a simple
>> "available energy" value and "am I likely to be used to route a
>> packet".
>
>> 4) Transmit energy also depends on link reliability for most
>> wireless networks, since they have an acknowledgment system.
>
> Yes, retransmissions at link layer are a link layer problem, dealt
> with by power management of the link layer.  IP stack cares about TCP
>> Thus an unreliable link may actually take much more than the
>> expected power to transmit every
> frame,
>> since it's often doing retries. I would expect a few
>> retransmissions to basically nullify a lot of work selecting the
>> "most optimum" routes from
> an
>> energy perspective.
>
> Hmmm... retransmissions may happen too for a node energy metric and
> that may nullify its effect too.
>
> <CPO>I don't mean retransmission of the metric, I just meant
> retransmissions in general. It's a question of all this overhead
> exchanging metrics to maintain a perfect route, when in the end you
> spent more time maintain your route than routing data! So I think
> for link energy to be 'accurate', you'd also need to keep the ETX
> object updated for example.</CPO>

ETX has been so largely published and apparently implemented that I
can't disagree with it.  However, I see it as a different metric than
the link energy metric.  I guess one could use it differently than using
an IP link energy metric.

I think ETX is good when considering particular wireless MAC layer, but
wouldn't be useful to qualify other links in the Internet like fiber,
for example.  It is very relevant for the MACs considered by LLNs, I think.

Alex

>
>> 6) My conclusion from the above points is that the entire question
>> of
> RX/TX
>> simplification that can at least be easily understood and specified
>> would
> be
>> more useful to everyone in the end than something that is more
>> complex and might not even work.
>
>> Using such a metric DOES require external documents to specify how
>> the metric is used. But requiring external specification to work
>> out details seems inline with the rest of RPL so shouldn't be a
>> problem.
>>
>> And if in the future I'm completely wrong and someone needs link
>> energy, I don't see a problem of fitting the link energy into a
>> TLV in the "node energy object".
>
> I am happy to see openness to include link energy metric and I take
> note for future discussion.
>
> But link energy is link energy not node energy.  We saw it in the
> above mAmpere discussion where you eliminated the computing power to
> which I agreed; yet it doesn't make sense conceptually to put link
> energy into a node energy container.  Link energy values are
> distinct from node energy values.
>
> Alex
>
>>
>> Warm Regards,
>>
>> -Colin O'Flynn
>>
>>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Philip Levis Sent:
>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc: [email-masked]
>>> I reply now just to make sure I replied before the September
>>> 30th, 2010, the deadline Chair set and that I consider.
>>>
>>> energy in Joules is required on a particular link to send
>>> 1280bytes as an IPv6 packet.
>>>
>>> In draft-ietf-roll-routing-metrics energy _is_ used as a metric
>>> but as node energy only, not link energy.
>>>
>>  application someone is building today, where link energy is
>> needed? Given the tremendous size and diversity of the industries
>> around LLNs, as well
> as
>> the application experience, I think our goal is to standardize
>> current practice rather than invent new mechanisms.
>>
>> Phil _______________________________________________ Roll mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
>
>

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Sun, 19 Sep 2010 22:11:03 +0200

Thanks Alex/Colin for bringing this up for discussion.

My two cents:

I always saw the ability to operate at multiple media as one of the
strongest points in favor of RPL (and L3 routing protocols) over specific
L1/2 bridging techniques.

The smart grid will most probably need to operate using both PLC or
wireless media for the same utility owned networks in some cases.

Consider the typical Multiple Dwelling Unit (MDU) use case where wireless
meters reside outside apartments in sealed cabinets, and in-home displays
are installed inside the apartments.  RF cannot pass thick walls, so a
selection of an L3 router via a PLC node is a natural (from the cabinet to
the home).

Another use case is of course to connect a wireless battery operated
sensor (say on the ceiling) with a PLC device that needs the sensor inputs
(such as PCTs).

These smart-grid devices "belong" to the same utility network or
sub-network (though using different medias sometimes)...

RPL (or any L3 routing protocol as I understand it) supported by multiple
PHY layers seems to me like an excellent choice for covering these use
cases while inherently taking the routing metric into consideration when
choosing which media is the most suitable for the next transmission to the
final destination.

I am seeking for WG confirmation that these use cases are covered well by
RPL (as a route over media and link layer agnostic protocol). Otherwise, I
think this is a significant short-coming of the protocol.

The WG thoughts are very much appreciated.

Best regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Sunday, September 19, 2010 9:29 PM
To: Colin O'Flynn
Cc: [email-masked]
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

Hi Colin,

This was never clear.

Hmmm... that sounds right.  To be better accurate about link energy
metrics one would have to do both Tx metric and Rx metric.  This could
be done.  I was thinking that presenting first the Tx link energy metric
it would be easier to understand and then add the Rx metric too,
naturally.

I think ETX is good when considering particular wireless MAC layer, but
wouldn't be useful to qualify other links in the Internet like fiber,
for example.  It is very relevant for the MACs considered by LLNs, I
think.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 20 Sep 2010 09:21:34 +0200

Hold-on ... RPL is a L3 routing protocol, which by itself answers (hopefully) your
first question. Further, this is clearly stated in the charter. With regards to your 
second question, these metrics are RPL metrics.

On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote:

> (The energy used for transmission is the one measured by setting a highres ampermeter serially with the transmitting device, its battery and a shunt, make it send an IPv6 packet (type ping).  That shows the energy used for transmission.  This is just a rough view, but basically that is.  There are related measurement tools like antena placed near emitter (the ones used to measure the DAS of mobile phones W/Kg).)
> 
> Yes, the metric should be simple.  The simplest relates much to what exists in terms of how IP routers select their output interface without artificial human intervention.
> 
> Do we want metrics that work _only_ within an RPL network?  Or more universal like across the Internet?  Or both?  This is also a requirement discussion which is worth clarifying.
> 
> YEs, the above points about RPL running in a single PHY or multiple PHY network, and metric only worth in RPL or across the Internet, are important to clarify.
> 
>> Regards,
>> 
>> -Colin
>>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 20 Sep 2010 10:37:32 +0100

Hi JP,

I think the problem was around the routing metrics themselves somehow being
L2 dependant. Let me see if I can summarize:

Thus while there is nothing to stop RPL working between multiple PHY layers,
as any L3 routing protocol would, there is a question around how the metrics
reflect different L2 hops. 

Say you had a network with WiFi, 802.15.4, and PLC nodes, with some of the
nodes having one interface, some having two or more. Does RPL run a *single*
RPLInstance across the entire network?

Alex's concern is that the routing metric only tells you information about
how much energy a node has available, not the cost of routing on that link
when you have vastly different L2 technologies.

Thus for example a battery powered 802.15.4 node and a battery powered
cellular node are both reachable and possible paths to a destination. The
802.15.4 node may advertise itself as having a certain amount of energy to
spare, and a cellular node may advertise itself as having less energy to
spare (smaller E-E value). However this does not reflect the fact the
802.15.4 node is currently handling no routes, and the cellular node is
handling ten. The incremental cost of adding a single route to the 802.15.4
is higher than for cellular. In this case you need to somehow advertise not
only how much energy you have or are using, but how much energy you would
have after carrying a packet. In my example you may end up oscillating, as
once the 802.15.4 node starts carrying traffic it advertises itself as
having much less available energy and tries to dump the route. Have I
summarized this correctly Alex?

Perhaps it does make sense to adjust the 'node energy' metric to advertise
not the currently available power/lifetime as is worded in the draft, but
somehow work in the power it would take to carry a route/packet relative to
your available power. So the estimate in E-E is not the current value, but
the expected value after sending some defined number of packets. This would
at least let you know if you have a node with a tiny battery that just
happens to have no other draw, or a node connected to a car battery that can
handle your extra packets.

Regards,

  -Colin

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: September 20, 2010 8:22 AM
To: Alexandru Petrescu
Cc: Colin O'Flynn; [email-masked]
Subject: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on
draft-ietf-roll-routing-metrics-09.txt

Hold-on ... RPL is a L3 routing protocol, which by itself answers
(hopefully) your
first question. Further, this is clearly stated in the charter. With regards
to your 
second question, these metrics are RPL metrics.

On Sep 19, 2010, at 9:29 PM, Alexandru Petrescu wrote:

> (The energy used for transmission is the one measured by setting a highres
ampermeter serially with the transmitting device, its battery and a shunt,
make it send an IPv6 packet (type ping).  That shows the energy used for
transmission.  This is just a rough view, but basically that is.  There are
related measurement tools like antena placed near emitter (the ones used to
measure the DAS of mobile phones W/Kg).)
> Do we want metrics that work _only_ within an RPL network?  Or more
universal like across the Internet?  Or both?  This is also a requirement
discussion which is worth clarifying.
> YEs, the above points about RPL running in a single PHY or multiple PHY
network, and metric only worth in RPL or across the Internet, are important
to clarify.
naturally.
think.

---

From: "Cedric Chauvenet" <[email-masked]>
Date: Mon, 20 Sep 2010 12:16:29 +0200

Hi all,

I fully support PHY diversity in RPL networks.
I also think it is pretty clear in WG drafts that we are not relying on 
particular PHY/MAC, so this diversity has been apporved by ROLL.

Yoav pointed out very concrete usecases where Media diversity is needed.
We can also think about Wireless nodes that would rely on a PLC backbone in 
a smart Home Context, to minimize Wireless hops and indeed the global energy 
consumption.
PLC could also provide a suitable solution to cross Wireless barriers suh as 
metal.

RPL PHY diversity has already been demonstrated during the first IPSO 
interop in march 2010, where a RPL network has been builded over 3 different 
media (802.15.4 RF, Ethernet and Low Power PLC).

Regards,
Cédric

----- Original Message ----- 
From: "Yoav Ben-Yehezkel" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>; "Colin O'Flynn" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, September 19, 2010 10:11 PM
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

My two cents:

Best regards,
Yoav

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

Hi Colin,

This was never clear.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 20 Sep 2010 17:05:10 +0200

Yes I do not even know why the topic was brought up.
RPL is a L3 protocol.

JP.

On Sep 20, 2010, at 12:16 PM, Cedric Chauvenet wrote:

> I also think it is pretty clear in WG drafts that we are not relying on particular PHY/MAC, so this diversity has been apporved by ROLL.
> 
> We can also think about Wireless nodes that would rely on a PLC backbone in a smart Home Context, to minimize Wireless hops and indeed the global energy consumption.
> PLC could also provide a suitable solution to cross Wireless barriers suh as metal.
> 
> RPL PHY diversity has already been demonstrated during the first IPSO interop in march 2010, where a RPL network has been builded over 3 different media (802.15.4 RF, Ethernet and Low Power PLC).
> 
> Regards,
> Cédric
> 
> ----- Original Message ----- From: "Yoav Ben-Yehezkel" <[email-masked]>
> To: "Alexandru Petrescu" <[email-masked]>; "Colin O'Flynn" <[email-masked]>
> Cc: <[email-masked]>

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 20 Sep 2010 19:10:41 +0200

JP,

Have a look at the earlier email from Colin, he's raising an interesting
point.
It's not about PHY diversity, it's about energy metrics in the cases of
multiple media.

Thanks,
Yoav

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]]
Sent: Monday, September 20, 2010 5:05 PM
To: Cedric Chauvenet
Cc: Yoav Ben-Yehezkel; Alexandru Petrescu; Colin O'Flynn; [email-masked]
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

JP.

> We can also think about Wireless nodes that would rely on a PLC backbone
in a smart Home Context, to minimize Wireless hops and indeed the global
energy consumption.
> RPL PHY diversity has already been demonstrated during the first IPSO
interop in march 2010, where a RPL network has been builded over 3
different media (802.15.4 RF, Ethernet and Low Power PLC).
<[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Sep 2010 21:30:02 +0200

Le 20/09/2010 09:21, JP Vasseur a écrit :
> (hopefully) your first question. Further, this is clearly stated in
> the charter.

JP - I agree with this point: L3, multiple PHY/MAC, Charter.  It reads
good.  However, let me summarize a few points questioning this
multiple PHY/MAC assumption in RPL draft and metrics draft:

- every RPL Control Message (pretty much everything in RPL) has src and
   dst scoped link-locally: src is a link-local unicast address and dst
   is a link-local scope multicast address... so all RPL messages are
   sent on a single link -  but it's impossible to have several PHY/MACs
   on a single link.

   So, in order to have several PHY/MACs we need several links: does RPL
   router forward link-locally addressed messages?  does it change src
   address with that of another interface when forwarding over it?

   ("link" is from rfc4861, which says nodes communicate on a link at
    the link-layer - two different link-layers are two different links).

- the pictures in RPL draft show nodes like this:

                  /
                (C)
                /

   Does it mean (C) has two interfaces (on two links)?  I don't think
   so, because all such "/" links in all pictures link actually _only_
   two nodes.  It would make no sense at all to run multicast on every
   one of those node-to-node links, or use link-local multicast
   addresses.  That makes me think there's actually one single link (one
   PHY/MAC) linking the nodes together.

   There are more things in the draft making think there's only one
   link: the absence of specification of which interface belongs a
   link-local address when that address is used, for example.

- some link metrics in the metrics draft (ETX, LQL) seem particular to
   one PHY/MAC which is WiFi, by their historical references.  Are these
   comparable to other MAC/PHYs?  For example, is ETX 2 on WiFi bigger
   than ETX 1 on ANT+?  Is each metric individually sufficient to cover
   several PHY/MACs such that to, for example, use the least possible
   transmitting power?  I don't think so.

Just three cents worth,

Alex

> With regards to your second question, these metrics are RPL metrics.
>
>> [my summary: it is worth clarifying (1) whether RPL runs in a
>> single PHY or multiple PHY network, and (2) whether metrics for RPL
>> should be understood in RPL network only or more universal like
>> across the Internet.  There are also points about whether Rx link
>> energy is as important as Tx link energy and its usability
>> overall.]
>>
>> Hi Colin,
>>
>> It does make sense to clarify the usage model first, especially
>> the assumptions of whether or not RPL runs exclusively on networks
>> made of single PHY, or multiple PHYs.
>>
>> I consider IP kind of work (do we say IPv6? 'router'?) is needed
>> only if we consider multiple kinds of PHYs in the same network.
>> Otherwise bridges, range extenders and other L2 tools are better
>> appropriate than IP routers.
>>
>> _only_ 802.15.4 or would it include PLC too.  I think RPL draft
>> text saying _only_ 802.15.4 would make subsequent metrics and
>> security text much easier.  However, it was insisted PLC should be
>>  there in the draft. So I am in that perspective now.
>>
>> But does that mean that RPL runs only on a network consisting of
>> PLC devices, and on another network of 15.4 devices (separated by
>> an Edge Router)?  Or does it mean RPL runs in a network mixing 15.4
>> devices with PLC devices each being an RPL router?
>>
>> This was never clear.
>>
>>> I think we have some different assumptions about the usage model.
>>> It would be useful to clarify some of that first. I'm not
>>> claiming my assumptions are correct or consistent with the
>>> ROLL/RPL basis, these are simply my view of how I imagined it
>>> would all fit together:
>>>
>>> 1) A single RPL network itself does not cross multiple PHY
>>> layers. Crossing PHY layers would complicate the decision on
>>> "best routes" partially for the reasons you mention. My comments
>>>  before showing TX power vs current was showing that for the same
>>>  PHY layer you can have a huge swing of TX power yet minimal
>>> impact on energy required to transmit a packet (100x change in RF
>>> energy = less than 2x change in total energy).
>>
>>  highres ampermeter serially with the transmitting device, its
>> battery and a shunt, make it send an IPv6 packet (type ping). That
>>  shows the energy used for transmission.  This is just a rough
>> view, but basically that is.  There are related measurement tools
>> like antena placed near emitter (the ones used to measure the DAS
>> of mobile phones W/Kg).)
>>
>>> application-dependant. Thus you can change the metrics for
>>> different nodes as required, and metrics might not make sense
>>> between different RPL networks (this fits in with assumption
>>> #1).
>>>
>>> required customization. If you want to select the outgoing
>>> interface you have some artificial change in the metric, where
>>> the administrator has basically forced the device to prefer
>>> interface 1 over interface 2.
>>
>> Yes, the metric should be simple.  The simplest relates much to
>> what exists in terms of how IP routers select their output
>> interface without artificial human intervention.
>>
>>> In your given example of an automotive system where they all work
>>> on a common power source, the nodes have a specific routing
>>> metric where a certain "fudge factor" has been worked into the
>>> different nodes. Thus all other things being equal, the
>>> advertised metric of a node which takes a lot of energy to
>>> transmit is made such that it is less preferred over another
>>> node.
>>>
>>> I think you are assuming that (1) you can have different PHYs
>>> within the RPL network, and (2) the routing metrics are more
>>> universal, so you can compare two different RPL networks. Is this
>>> correct?
>>
>> Yes, right, that is my assumption: different PHYs within an RPL
>> network and routing metrics more universal - they'd work within the
>> RPL network and across the Internet (like the simple hopcount
>> metric), and one could also compare different RPL networks.
>>
>>> I've included some clarifications below as well (see<CPO>
>>> </CPO>), but I think the above two points are most important to
>>> understanding why we may see such a wide difference of opinion.
>>
>> YEs, the above points about RPL running in a single PHY or multiple
>> PHY network, and metric only worth in RPL or across the Internet,
>> are important to clarify.
>>
>>> Regards,
>>>
>>> -Colin
>>>
>>> [mailto:[email-masked]] Sent: September 18, 2010
>>> 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis'; [email-masked]
>>>> I think the idea of "link energy" would be without much merit,
>>>>  of course
>>> I'm
>>>> 1) There will not be much difference between the energy it
>>>> takes to
>>> transmit
>>> (in a car - how would a "battery" value of the metric which
>>> assumes each IP addressable device has its own "battery" work
>>> with RPL?  All devices in the car are on the same unique battery,
>>> and sometimes on car engine electricity generator. Add to this
>>> the Electric Vehicle and you see.)
>>>
>>> That is right.  Each transmitting device has CPU chipset to
>>> compute wireless coding and that takes energy.  That energy is in
>>> higher orders of magnitude than actually transmitting.
>>>
>>> However the energy used to actual Tx (and Rx as in GPS devices)
>>> can be clearly distinguished.
>>>
>>> <CPO>I meant that you would then require information on both TX&
>>>  RX power if you wanted to be accurate. So you'd have to add
>>> more metrics there, and add two values for every hop.</CPO>
>>
>> Hmmm... that sounds right.  To be better accurate about link
>> energy metrics one would have to do both Tx metric and Rx metric.
>> This could be done.  I was thinking that presenting first the Tx
>> link energy metric it would be easier to understand and then add
>> the Rx metric too, naturally.
>>
>>>> values of current vs power output (from datasheet @ 3.0V): RX
>>>> PWR | Supply 3dBm  | 14.5mA 1dBm  | 10mA -3dBm  | 9mA -17dBm |
>>>>  8mA
>>>>
>>>> Converting both to mW (= mJ/s) RX PWR | Supply 2.00  |  43.5
>>>> 1.26 | 30 0.50  |  27 0.02  |  24
>>>>
>>> That sounds exellent startpoint for design a link energy metric!
>>>  To eliminate the time paramter (mJ/s) to get to the J only  we
>>> could decide that we need to transmit 1280bytes of data - the
>>> IPv6 minimal MTU.
>>>
>>>> There are some additional things that are TX power
>>>> independent, but I think for any reasonable length 6LoWPAN
>>> Are we IPv6 perspective or not.  If yes IPv6 stack needs to know
>>>  how much energy is needed 1280bytes of data, a minimally sized
>>> IPv6 packet. The stack reasons in terms of packets of that or
>>> larger size.
>>>
>>> packet seen on a 6lowpan/IPv6 network you don't need to worry
>>> about CSMA time for example, as it's fairly minimal by
>>> comparison.</CPO>
>>
>> 1280bytes.  I am not sure I understand why should IPv6 stack worry
>>  about smaller data-link packets but I have to dig this, e.g. see
>> whether the linux stack does consider smaller than 1280bytes or
>> not.
>>
>>>> 2) Receiving takes around the same amount of power as
>>>> transmitting for
>>> most
>>> <CPO>I looked back to I think may 2009 when I saw a discussion
>>> about it, if it was before that I probably missed it</CPO>.
>>
>> Ok, I will resend tomorrow an an example of encoding energy link
>> metric for RA (it's on my office desktop).
>>
>>>> If you do it in simple ways with "fudge factors" you've
>>>> probably lost enough accuracy to bother doing it at all.
>>>
>>>> 3) Link energy on its own would result in selecting lowest
>>>> energy paths I assume. Low power nodes which advertise smaller
>>>>  link energies have
>>> probably
>>>> gone to great lengths to get low link energies, since they have
>>>> low available power. The nodes which are wall-powered won't try
>>>> to get link energy as low since they are free to transmit at
>>>> highest energy and not worry too much about power saving
>>>> tricks. This would be the opposite of
>>> what
>>> <CPO>   Combine was a poor choice of words on my part. I meant
>>> it uses both the link energy&   node energy, and "combines" them
>>> to create a routing solution. So if you had separate link energy&
>>>  node energy, figuring out how to use both of them would be a
>>> complex problem.</CPO>
>>
>> I agree using both node and link energy in a single metric would
>> make it more complex.
>>
>>>> Combining link energy with available energy would be
>>>> incredibly complex to get perfect. Worse if you do it wrong you
>>>> end up with the exact opposite
>>> of
>>> on/off? Or when plugging the device on a docking.  Or when
>>> plugging a vehicle on an outlet.
>>>
>>>> "available energy" value and "am I likely to be used to route
>>>> a packet".
>>>
>>> Yes, retransmissions at link layer are a link layer problem,
>>> dealt with by power management of the link layer.  IP stack cares
>>> about TCP retransmissions or above.
>>>
>>>> retransmissions to basically nullify a lot of work selecting
>>>> the "most optimum" routes from
>>> an
>>>> energy perspective.
>>>
>>> Hmmm... retransmissions may happen too for a node energy metric
>>> and that may nullify its effect too.
>>>
>>> exchanging metrics to maintain a perfect route, when in the end
>>> you spent more time maintain your route than routing data! So I
>>> think for link energy to be 'accurate', you'd also need to keep
>>> the ETX object updated for example.</CPO>
>>
>> ETX has been so largely published and apparently implemented that
>> I can't disagree with it.  However, I see it as a different metric
>>  than the link energy metric.  I guess one could use it differently
>>  than using an IP link energy metric.
>>
>> I think ETX is good when considering particular wireless MAC layer,
>> but wouldn't be useful to qualify other links in the Internet like
>> fiber, for example.  It is very relevant for the MACs considered by
>> LLNs, I think.
>>
>> Alex
>>
>>
>>>
>>>> 6) My conclusion from the above points is that the entire
>>>> question of
>>> RX/TX
>>>> power is too complex to bother doing perfectly in these
>>>> networks. A simplification that can at least be easily
>>>> understood and specified would
>>> be
>>> If we wish we could discuss separately the actual use of the
>>> existing node energy metric and I think it's not that simple
>>> either.
>>>
>>>> Using such a metric DOES require external documents to specify
>>>>  how the metric is used. But requiring external specification
>>>> to work out details seems inline with the rest of RPL so
>>>> shouldn't be a problem.
>>>>
>>>> And if in the future I'm completely wrong and someone needs
>>>> link energy, I don't see a problem of fitting the link energy
>>>> into a TLV in the "node energy object".
>>>
>>> I am happy to see openness to include link energy metric and I
>>> take note for future discussion.
>>>
>>> But link energy is link energy not node energy.  We saw it in
>>> the above mAmpere discussion where you eliminated the computing
>>> power to which I agreed; yet it doesn't make sense conceptually
>>> to put link energy into a node energy container.  Link energy
>>> values are distinct from node energy values.
>>>
>>> Alex
>>>
>>>>
>>>> Warm Regards,
>>>>
>>>> -Colin O'Flynn
>>>>
>>>>
>>>> September 18, 2010 5:11 PM To: Alexandru Petrescu Cc:
>>>> [email-masked] Subject: Re: [Roll] WG Last Call on
>>>>> I have proposed last year to have energy link metrics: how
>>>>> much energy in Joules is required on a particular link to
>>>>> send 1280bytes as an IPv6 packet.
>>>>>
>>>>> In draft-ietf-roll-routing-metrics energy _is_ used as a
>>>>> metric but as node energy only, not link energy.
>>>>>
>>>>> Link metrics _are_ considered in
>>>>> draft-ietf-roll-routing-metrics but not as energy.
>>>>>
>>>>> Private discussion pointed me unilaterally I may be wrong but
>>>>> I think publicly I may be right.
>>>>>
>>>> Can you point me to an application requirements doc, or a
>>>> concrete application someone is building today, where link
>>>> energy is needed? Given the tremendous size and diversity of
>>>> the industries around LLNs, as well
>>> as
>>>> Phil _______________________________________________ Roll
>>>> mailing list [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Tue, 21 Sep 2010 03:51:46 +0200

Simple answer. How different is it from other L3 routing protocol such as OSPF
with regards to the routing metrics in a routing domain that comprises different
PHY/MAC. It is not. Consider an ISIS L2 for example. As you probably know, 
you have routing metrics and in most cases a number of PHY/MAC (SDH, optical,
Ethernet, ATM, ...). You still use a metric for ISIS that reflects a link characteristic.

Hope that helps.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 21 Sep 2010 04:13:08 +0200

Hi,

* co-chair hat off *

> in Joules is required on a particular link to send 1280bytes as an IPv6

First of all, this document specifies a set of link/node routing metrics/constraint
along with various mechanisms to manipulate these metrics and constraint and
needless to say that additional metrics could be defined in the future.

I do remember that discussion indeed. The reason for taking into account 
the node energy as a metric and/or constraint is obvious. Now the question
that I asked you was: "why would you want to optimize path against link 
energy ?". Trying to avoid nodes that are running out of energy or compute
paths so that energy consumption is even distributed thanks to load balancing
is well understood. But I fail to see how link energy metrics should be used ?
Say that you have n paths and their path cost reflects the amount of energy
required along each of them. Would you choose the least cost path ? If so,
what if you choose a path traversing a set of battery operated nodes, instead
of a path that may consume more energy but would traverse nodes for which
energy is not a limited factor ? Could you describe a use case of link energy
metric ?

> draft-mulligan-roll-ripless-01.

This document defines routing metrics for RPL.

> Private discussion pointed me unilaterally I may be wrong but I think

Not sure what you meant here.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Sep 2010 08:35:02 +0200

Le 21/09/2010 03:51, JP Vasseur a écrit :
> Simple answer. How different is it from other L3 routing protocol
> such as OSPF with regards to the routing metrics in a routing domain
> that comprises different PHY/MAC. It is not. Consider an ISIS L2 for
> example. As you probably know, you have routing metrics and in most
> cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, ...). You
> still use a metric for ISIS that reflects a link characteristic.
>
> Hope that helps.

Ok, that about metrics in OSPF.  I have to go look for a link
characteristics metric for OSPF (not ISIS) and see whether it covers
several PHY/MACs, see whether they're used simultaneously.

But how about RPL being a single link?  RPL document says it runs a
single link (src, dst are link-local).   One couldn't fit several
PHY/MACs on a single link.

Alex

>>> (hopefully) your first question. Further, this is clearly stated
>>> in the charter.
>>
>> JP - I agree with this point: L3, multiple PHY/MAC, Charter.  It
>> reads good.  However, let me summarize a few points questioning
>> this multiple PHY/MAC assumption in RPL draft and metrics draft:
>>
>> - every RPL Control Message (pretty much everything in RPL) has
>> src and dst scoped link-locally: src is a link-local unicast
>> address and dst is a link-local scope multicast address... so all
>> RPL messages are sent on a single link -  but it's impossible to
>> have several PHY/MACs on a single link.
>>
>> So, in order to have several PHY/MACs we need several links: does
>> RPL router forward link-locally addressed messages?  does it
>> change src address with that of another interface when forwarding
>> over it?
>>
>> / (C) /
>>  so, because all such "/" links in all pictures link actually
>> _only_ two nodes.  It would make no sense at all to run multicast
>> on every one of those node-to-node links, or use link-local
>> multicast addresses.  That makes me think there's actually one
>> single link (one PHY/MAC) linking the nodes together.
>>
>> - some link metrics in the metrics draft (ETX, LQL) seem
>> particular to one PHY/MAC which is WiFi, by their historical
>> references.  Are these comparable to other MAC/PHYs?  For example,
>> is ETX 2 on WiFi bigger than ETX 1 on ANT+?  Is each metric
>> individually sufficient to cover several PHY/MACs such that to, for
>> example, use the least possible transmitting power?  I don't think
>> so.
>>
>> Just three cents worth,
>>
>> Alex
>>
>>>> single PHY or multiple PHY network, and (2) whether metrics
>>>> for RPL should be understood in RPL network only or more
>>>> universal like across the Internet.  There are also points
>>>> about whether Rx link energy is as important as Tx link energy
>>>> and its usability overall.]
>>>>
>>>> Hi Colin,
>>>>
>>>> the assumptions of whether or not RPL runs exclusively on
>>>> networks made of single PHY, or multiple PHYs.
>>>>
>>>> I consider IP kind of work (do we say IPv6? 'router'?) is
>>>> needed only if we consider multiple kinds of PHYs in the same
>>>> network. Otherwise bridges, range extenders and other L2 tools
>>>> are better appropriate than IP routers.
>>>>
>>>> During RPL comments we commented whether RPL draft text should
>>>> say _only_ 802.15.4 or would it include PLC too.  I think RPL
>>>> draft text saying _only_ 802.15.4 would make subsequent
>>>> metrics and security text much easier.  However, it was
>>>> insisted PLC should be there in the draft. So I am in that
>>>> perspective now.
>>>>
>>>> But does that mean that RPL runs only on a network consisting
>>>> of PLC devices, and on another network of 15.4 devices
>>>> (separated by an Edge Router)?  Or does it mean RPL runs in a
>>>> network mixing 15.4 devices with PLC devices each being an RPL
>>>> router?
>>>>
>>>> This was never clear.
>>>>
>>>>> I think we have some different assumptions about the usage
>>>>> model. It would be useful to clarify some of that first. I'm
>>>>> not claiming my assumptions are correct or consistent with
>>>>> the ROLL/RPL basis, these are simply my view of how I
>>>>> imagined it would all fit together:
>>>>>
>>>>>  "best routes" partially for the reasons you mention. My
>>>>> comments before showing TX power vs current was showing that
>>>>> for the same PHY layer you can have a huge swing of TX power
>>>>> yet minimal impact on energy required to transmit a packet
>>>>> (100x change in RF energy = less than 2x change in total
>>>>> energy).
>>>>
>>>> (The energy used for transmission is the one measured by
>>>> setting a highres ampermeter serially with the transmitting
>>>> device, its battery and a shunt, make it send an IPv6 packet
>>>> (type ping). That shows the energy used for transmission.
>>>> This is just a rough view, but basically that is.  There are
>>>> related measurement tools like antena placed near emitter (the
>>>> ones used to measure the DAS of mobile phones W/Kg).)
>>>>
>>>>> Thus my view was the metrics should be simple, as you hide
>>>>> any required customization. If you want to select the
>>>>> outgoing interface you have some artificial change in the
>>>>> metric, where the administrator has basically forced the
>>>>> device to prefer interface 1 over interface 2.
>>>>
>>>>> In your given example of an automotive system where they all
>>>>> work on a common power source, the nodes have a specific
>>>>> routing metric where a certain "fudge factor" has been
>>>>> worked into the different nodes. Thus all other things being
>>>>> equal, the advertised metric of a node which takes a lot of
>>>>> energy to transmit is made such that it is less preferred
>>>>> over another node.
>>>>>
>>>>> universal, so you can compare two different RPL networks. Is
>>>>> this correct?
>>>>
>>>> network and routing metrics more universal - they'd work within
>>>> the RPL network and across the Internet (like the simple
>>>> hopcount metric), and one could also compare different RPL
>>>> networks.
>>>>
>>>> Do we want metrics that work _only_ within an RPL network?  Or
>>>> more universal like across the Internet?  Or both?  This is
>>>> also a requirement discussion which is worth clarifying.
>>>>
>>>>> </CPO>), but I think the above two points are most important
>>>>> to understanding why we may see such a wide difference of
>>>>> opinion.
>>>>
>>>> YEs, the above points about RPL running in a single PHY or
>>>> multiple PHY network, and metric only worth in RPL or across
>>>> the Internet, are important to clarify.
>>>>
>>>>> Regards,
>>>>>
>>>>> -Colin
>>>>>
>>>>> [mailto:[email-masked]] Sent: September 18,
>>>>> 2010 7:16 PM To: Colin O'Flynn Cc: 'Philip Levis';
>>>>>> Caveat emptor: I have not read the entire metrics-09 at
>>>>>> this point, but wanted to comment anyway.
>>>>>>
>>>>>> I think the idea of "link energy" would be without much
>>>>>> merit, of course
>>>>> I'm
>>>>> Take a car: all devices are on a single unique battery, yet
>>>>> many different copper, light and ether links in terms of
>>>>> energy needed.
>>>>>
>>>>> with RPL?  All devices in the car are on the same unique
>>>>> battery, and sometimes on car engine electricity generator.
>>>>> Add to this the Electric Vehicle and you see.)
>>>>>
>>>>>> and much of the power of actually transmitting a packet is
>>>>>> not related to
>>>>> TX
>>>>> compute wireless coding and that takes energy.  That energy
>>>>> is in higher orders of magnitude than actually transmitting.
>>>>>
>>>>> However the energy used to actual Tx (and Rx as in GPS
>>>>> devices) can be clearly distinguished.
>>>>>
>>>>> <CPO>I meant that you would then require information on both
>>>>> TX& RX power if you wanted to be accurate. So you'd have to
>>>>> add more metrics there, and add two values for every
>>>>> hop.</CPO>
>>>>
>>>> energy metrics one would have to do both Tx metric and Rx
>>>> metric. This could be done.  I was thinking that presenting
>>>> first the Tx link energy metric it would be easier to
>>>> understand and then add the Rx metric too, naturally.
>>>>
>>>>>> As an example for one specific radio, the ATMega128RFA1,
>>>>>> the values of current vs power output (from datasheet @
>>>>>> 3.0V): RX PWR | Supply 3dBm  | 14.5mA 1dBm  | 10mA -3dBm
>>>>>> | 9mA -17dBm | 8mA
>>>>>>
>>>>> That sounds exellent startpoint for design a link energy
>>>>> metric! To eliminate the time paramter (mJ/s) to get to the
>>>>> J only  we could decide that we need to transmit 1280bytes
>>>>> of data - the IPv6 minimal MTU.
>>>>>
>>>>> Are we IPv6 perspective or not.  If yes IPv6 stack needs to
>>>>> know how much energy is needed 1280bytes of data, a
>>>>> minimally sized IPv6 packet. The stack reasons in terms of
>>>>> packets of that or larger size.
>>>>>
>>>>> <CPO>My example is 802.15.4/6LoWPAN specific, as that was
>>>>> just 802.15.4 packets. I just meant for any reasonable size
>>>>> 802.15.4 packet seen on a 6lowpan/IPv6 network you don't
>>>>> need to worry about CSMA time for example, as it's fairly
>>>>> minimal by comparison.</CPO>
>>>>
>>>> Well, IPv6 for 802.15.4 RFC says clearly this is minimal IPv6
>>>> MTU 1280bytes.  I am not sure I understand why should IPv6
>>>> stack worry about smaller data-link packets but I have to dig
>>>> this, e.g. see whether the linux stack does consider smaller
>>>> than 1280bytes or not.
>>>>
>>>>>> 802.15.4 nodes. For the previously used example that is
>>>>>> around 12mA in
>>>>> fact.
>>>>> <CPO>I looked back to I think may 2009 when I saw a
>>>>> discussion about it, if it was before that I probably missed
>>>>> it</CPO>.
>>>>
>>>> Ok, I will resend tomorrow an an example of encoding energy
>>>> link metric for RA (it's on my office desktop).
>>>>
>>>>>>  energy paths I assume. Low power nodes which advertise
>>>>>> smaller link energies have
>>>>> probably
>>>>>> gone to great lengths to get low link energies, since they
>>>>>> have low available power. The nodes which are wall-powered
>>>>>> won't try to get link energy as low since they are free to
>>>>>> transmit at highest energy and not worry too much about
>>>>>> power saving tricks. This would be the opposite of
>>>>> what
>>>>> <CPO>    Combine was a poor choice of words on my part. I
>>>>> meant it uses both the link energy&    node energy, and
>>>>> "combines" them to create a routing solution. So if you had
>>>>> separate link energy& node energy, figuring out how to use
>>>>> both of them would be a complex problem.</CPO>
>>>>
>>>> I agree using both node and link energy in a single metric
>>>> would make it more complex.
>>>>
>>>>>> incredibly complex to get perfect. Worse if you do it
>>>>>> wrong you end up with the exact opposite
>>>>> of
>>>>>> what you want since low-power paths are used at the
>>>>>> expense of battery
>>>>> life.
>>>>>
>>>>> What is battery life when birth and death is turning an
>>>>> engine on/off? Or when plugging the device on a docking.  Or
>>>>> when plugging a vehicle on an outlet.
>>>>>
>>>>>>  "available energy" value and "am I likely to be used to
>>>>>> route a packet".
>>>>>
>>>>>> 4) Transmit energy also depends on link reliability for
>>>>>> most wireless networks, since they have an acknowledgment
>>>>>> system.
>>>>>
>>>>>  dealt with by power management of the link layer.  IP stack
>>>>> cares about TCP retransmissions or above.
>>>>>
>>>>>> Thus an unreliable link may actually take much more than
>>>>>> the expected power to transmit every
>>>>> frame,
>>>>>> retransmissions to basically nullify a lot of work
>>>>>> selecting the "most optimum" routes from
>>>>> an
>>>>>> energy perspective.
>>>>>
>>>>> Hmmm... retransmissions may happen too for a node energy
>>>>> metric and that may nullify its effect too.
>>>>>
>>>>>  retransmissions in general. It's a question of all this
>>>>> overhead exchanging metrics to maintain a perfect route,
>>>>> when in the end you spent more time maintain your route than
>>>>> routing data! So I think for link energy to be 'accurate',
>>>>> you'd also need to keep the ETX object updated for
>>>>> example.</CPO>
>>>>
>>>> ETX has been so largely published and apparently implemented
>>>> that I can't disagree with it.  However, I see it as a
>>>> different metric than the link energy metric.  I guess one
>>>> could use it differently than using an IP link energy metric.
>>>>
>>>> I think ETX is good when considering particular wireless MAC
>>>> layer, but wouldn't be useful to qualify other links in the
>>>> Internet like fiber, for example.  It is very relevant for the
>>>> MACs considered by LLNs, I think.
>>>>
>>>> Alex
>>>>
>>>>
>>>>>
>>>>>> more useful to everyone in the end than something that is
>>>>>> more complex and might not even work.
>>>>>
>>>>>> Using such a metric DOES require external documents to
>>>>>> specify how the metric is used. But requiring external
>>>>>> specification to work out details seems inline with the
>>>>>> rest of RPL so shouldn't be a problem.
>>>>>>
>>>>>> link energy, I don't see a problem of fitting the link
>>>>>> energy into a TLV in the "node energy object".
>>>>>
>>>>> I am happy to see openness to include link energy metric and
>>>>> I take note for future discussion.
>>>>>
>>>>> the above mAmpere discussion where you eliminated the
>>>>> computing power to which I agreed; yet it doesn't make sense
>>>>> conceptually to put link energy into a node energy
>>>>> container. Link energy values are distinct from node energy
>>>>> values.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> Warm Regards,
>>>>>>
>>>>>> -Colin O'Flynn
>>>>>>
>>>>>>
>>>>>> [mailto:[email-masked]] On Behalf Of Philip Levis
>>>>>> Sent: September 18, 2010 5:11 PM To: Alexandru Petrescu Cc:
>>>>>>> I reply now just to make sure I replied before the
>>>>>>> September 30th, 2010, the deadline Chair set and that I
>>>>>>> consider.
>>>>>>>
>>>>>>> I have proposed last year to have energy link metrics:
>>>>>>> how much energy in Joules is required on a particular
>>>>>>> link to send 1280bytes as an IPv6 packet.
>>>>>>>
>>>>>>> I have proposed this link metric also as an extension to
>>>>>>> the ripless draft-mulligan-roll-ripless-01.
>>>>>>>
>>>>>>> Private discussion pointed me unilaterally I may be
>>>>>>> wrong but I think publicly I may be right.
>>>>>>>
>>>>>>  energy is needed? Given the tremendous size and diversity
>>>>>> of the industries around LLNs, as well
>>>>> as
>>>>>> the application experience, I think our goal is to
>>>> _______________________________________________ Roll mailing

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Sep 2010 08:48:10 +0200

Le 21/09/2010 04:13, JP Vasseur a écrit :
> First of all, this document specifies a set of link/node routing
> metrics/constraint along with various mechanisms to manipulate these
> metrics and constraint and needless to say that additional metrics
> could be defined in the future.
>
> I do remember that discussion indeed. The reason for taking into
> account the node energy as a metric and/or constraint is obvious.
> Now the question that I asked you was: "why would you want to
> optimize path against link energy ?". Trying to avoid nodes that are
> running out of energy or compute paths so that energy consumption is
> even distributed thanks to load balancing is well understood. But I
> fail to see how link energy metrics should be used ? Say that you
> have n paths and their path cost reflects the amount of energy
> required along each of them. Would you choose the least cost path ?

YEs.

> If so, what if you choose a path traversing a set of battery operated
> nodes, instead of a path that may consume more energy but would
> traverse nodes for which energy is not a limited factor ?

Well, I'd say that if one needs to build a path both low energy emission
_and_ consuming least energy on nodes then one would need to use both
metrics: link energy and node energy, which could indeed be complex.

> Could you describe a use case of link energy metric ?

YEs, here's a very simple pictorial:

              Topology                        Routing Table of R1

      ----       A1----           ---- P3   Dst | Next Hop |Hops | Energy
     | R1 |-------| R2 |---------| R3 |--   -----------------------------
      ----   E1    ----   E2      ----       P3 |   A1     | 2   | E1+E2

     Legend
     R1: Router1
     E1: Energy value for this link
     A1: Address of one of R2's interfaces
     P3: prefix valid on interface

In this picture R1 knows not only it takes 2 hops to reach R3 but also
it takes energy E1+E2.  I hope it is illustrative.  Other examples
available upon request.

> This document defines routing metrics for RPL.

Well, sometimes it is hard to decide in certain contexts whether RPL,
RA, RIP or OSPF is more appropriate.  But a good metric should work with
all of them.  It would also be good to exercise the RPL metrics with
other routing protocols like RIP, or simple RA of ND.

> Not sure what you meant here.

That is private :-)  I meant to say that I was let understand, in
private, this link energy metric may not be appropriate for the RPL
metrics draft.

Alex

>>> The routing metrics draft has now gone through 9 revisions over
>>> the past 16 months, the diffs have narrowed to essentially
>>> wording and editorial changes, and the comments are few and
>>> non-controversial. Thus, it appears that consensus has emerged
>>> and we can LC this I-D.
>>>
>>> draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon
>>> PST, Sept. 30 2010.  Please read it thoroughly and forward all
>>> final comments to the authors and the WG mailing list.
>>>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 21 Sep 2010 08:30:22 +0200

Hi,

> RPLInstance across the entire network?

Colin, do you agree that this is no different than any other routing protocol. Take the
example of OSPF and a set of links: Ethernet, SDH, Optical, ATM.

> when you have vastly different L2 technologies.

I understand the point and actually (as seconded by Phil) I still do not see the 
application ?

> summarized this correctly Alex?

But in you case, that would not help. Indeed, even if you knew about of your energy
is needed to send 1bit across a link L, that would not tell you which path is preferable.
Indeed, you may choose a "green" path but going through node with little energy as
battery operated. Thus you would need two values: before and after routing the packet
that the sending node would need to compute by the way, which makes data processing
practically not implementable (or at what cost ???). One could come up with an algorithm
for average # of packets, ... etc but this would be quite complicated and you may end up
consuming more energy that you might saved.

> your available power.

Packet of which size ? See previous comment.

> So the estimate in E-E is not the current value, but

This is why we used the estimated % of remaining energy in order to load balance the 
traffic in an attempt to prolong the network life duration.

Thanks.

JP.

---

From: <[email-masked]>
Date: Tue, 21 Sep 2010 11:36:34 +0200

Hello all,

As part of our research activity, we published "academic" papers about protocols that minimize the total path energy expenditure (sum of link energies), in a grand vision of saving Energy and our Planet. Many others did, I can point at publications over 10 years ago, long before ours.
As a co-author of this draft, I pondered on introducing the link energy metric.
As part of an industrial ecosystem, I must say no LLN equipment vendor today said it needs/wants link energy metric. If there's any such vendor on this list, please speak up now and state your market/application characteristics.

Now getting technical:
Routing purely along minimal energy pathes is nice and saves the Planet, but it introduces the risk of over-using the same lower energy links, therefore the same few nodes, which can be energy limited, leading to shorter node lifetimes. Some nodes die early.
Another interesting metric is Max(Min(Remaining_Energy), which routes around energy-depleted nodes. However, it may use more energy for the overall path than the above, so all nodes die at the same time but maybe a little earlier than necessary.
In research papers by others and also by my team, hybrid metrics have been proposed that combine the above two. When nodes have plenty of energy (eg brand new battery-powered nodes), the network routes along minimal energy pathes, while when nodes start aging and becoming energy-depleted, the Max(Min(Remaining_Energy) gradually kicks in to take the forwarding burden off of the energy-depleted nodes and save their energy for sensing.
I would have loved introducing this hybrid metrics into RPL, but I resisted for lack of a clearly identified industrial need.
I made sure there is nothing that prevents them from being introduced later, should the need arise.

Finally:
A major difficulty with link energy in wireless is its inaccuracy. Even though you can quote joules for your own transmission and for your own reception, and although you can probably also account for the number of expected retransmissions, overhearing is a big problem. If you have 100 nodes in your radio vicinity, the energy cost you should account for for transmitting on this "link" (from this node) is 100 times higher than what you thought (assuming L2 broadcast or even L2 unicast and not-so-smart receivers).

My 3.5 c

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alexandru Petrescu
Envoyé : mardi 21 septembre 2010 08:48
À : JP Vasseur
Cc : [email-masked]
Objet : Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

Le 21/09/2010 04:13, JP Vasseur a écrit :
> Now the question that I asked you was: "why would you want to optimize 
> path against link energy ?". Trying to avoid nodes that are running 
> out of energy or compute paths so that energy consumption is even 
> distributed thanks to load balancing is well understood. But I fail to 
> see how link energy metrics should be used ? Say that you have n paths 
> and their path cost reflects the amount of energy required along each 
> of them. Would you choose the least cost path ?

YEs.

> traverse nodes for which energy is not a limited factor ?

Well, I'd say that if one needs to build a path both low energy emission _and_ consuming least energy on nodes then one would need to use both
metrics: link energy and node energy, which could indeed be complex.

     Legend
     R1: Router1

In this picture R1 knows not only it takes 2 hops to reach R3 but also it takes energy E1+E2.  I hope it is illustrative.  Other examples available upon request.

> This document defines routing metrics for RPL.

Well, sometimes it is hard to decide in certain contexts whether RPL, RA, RIP or OSPF is more appropriate.  But a good metric should work with all of them.  It would also be good to exercise the RPL metrics with other routing protocols like RIP, or simple RA of ND.

> Not sure what you meant here.

That is private :-)  I meant to say that I was let understand, in private, this link energy metric may not be appropriate for the RPL metrics draft.

Alex

---

From: Philip Levis <[email-masked]>
Date: Tue, 21 Sep 2010 09:20:02 -0700

> As part of an industrial ecosystem, I must say no LLN equipment vendor today said it needs/wants link energy metric. If there's any such vendor on this list, please speak up now and state your mark…

Agreed -- does a single one of the huge number of real applications out there need it?

Phil

---

From: [email-masked]
Date: Tue, 21 Sep 2010 14:23:29 -0500

Don't see a need in the commercial building
market.  We have battery powered hosts (e.g. temperature sensors),
but all our routing devices are powered.

From:

Philip Levis <[email-masked]>

To:

<[email-masked]>
<[email-masked]>

Cc:

[email-masked]

Date:

09/21/2010 11:21 AM

Subject:

Re: [Roll] WG Last Call on draft-ietf-roll-routing-metrics-09.txt

On Sep 21, 2010, at 2:36 AM, <[email-masked]>
<[email-masked]> wrote:

> As part of an industrial ecosystem, I must say no LLN equipment vendor
today said it needs/wants link energy metric. If there's any such vendor
on this list, please speak up now and state your market/application characteristics.

Agreed -- does a single one of the huge number of real applications out
there need it?

Phil

Roll mailing list

[email-masked]

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 22 Sep 2010 13:35:14 +0200

> traffic in an attempt to prolong the network life duration.

Yes but it's pointless as I've said. You could have 80% of a car battery
left, or 100% of a button-cell coin battery. By those metrics the
button-cell battery will then carry the traffic until it has 80% left at
which point it's optimal to switch.

The actual metrics at least used desired lifetime, which will result in this
scenario working itself out quicker. But you still waste the energy of
discovering that the coin cell battery doesn't like carrying traffic,
because once it starts carrying traffic it starts bitching.

You should be advertising how much carrying a generic route will affect the
power source. It won't be perfect but it's better IMO. 

Regards,

  -Colin

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: September 21, 2010 8:30 AM
To: Colin O'Flynn
Cc: [email-masked]; 'Alexandru Petrescu'
Subject: Re: ** Multiple PHY/MAC ** Re: [Roll] WG Last Call on

Hi,

> RPLInstance across the entire network?

Colin, do you agree that this is no different than any other routing
protocol. Take the
example of OSPF and a set of links: Ethernet, SDH, Optical, ATM.

> when you have vastly different L2 technologies.

I understand the point and actually (as seconded by Phil) I still do not see
the 
application ?

> summarized this correctly Alex?

But in you case, that would not help. Indeed, even if you knew about of your
energy
is needed to send 1bit across a link L, that would not tell you which path
is preferable.
Indeed, you may choose a "green" path but going through node with little
energy as
battery operated. Thus you would need two values: before and after routing
the packet
that the sending node would need to compute by the way, which makes data
processing
practically not implementable (or at what cost ???). One could come up with
an algorithm
for average # of packets, ... etc but this would be quite complicated and
you may end up
consuming more energy that you might saved.

> handle your extra packets.

This is why we used the estimated % of remaining energy in order to load
balance the 
traffic in an attempt to prolong the network life duration.

Thanks.

JP.

>> (The energy used for transmission is the one measured by setting a
highres
> network, and metric only worth in RPL or across the Internet, are
important

---

From: JP Vasseur <[email-masked]>
Date: Wed, 22 Sep 2010 13:58:10 +0200

> power source. It won't be perfect but it's better IMO. 

Just turned out to be impractical. Look at the other email.

---

From: Phoebus Chen <[email-masked]>
Date: Thu, 23 Sep 2010 09:44:22 +0200

I'm in the midst of making a pass through routing-metrics-09, and a 
question I (and others) asked earlier keeps coming up back in my head:

Why are we specifying how to combine the metrics in the DAG metric 
container?  Can't it be specified in the OF?

Here was the old thread (way back in April):
http://www.ietf.org/mail-archive/web/roll/current/msg03815.html
JP's response:
http://www.ietf.org/mail-archive/web/roll/current/msg03768.html

The argument was to not have a flood of new RFCs specifying OFs for each 
possible new way of combining metrics.  OK.

But say that we do want to use a combination of add, max, min, 
multiplication, or some other operator to combine some of these metrics. 
  What do we set in the "A" field of the Routing Metric/Constraint 
object depicted in Figure 2?  I would prefer to replace "A=0x03: The 
routing metric is multiplicative" with "A=0x03: The routing metric is 
aggregated in some other fashion specified by the objective function." 
Or, there should be a sentence in the specification saying that the 
objective function can "override" and ignore this field (and MUST set 
A=0x00 if the OF plans for the A field to be ignored).

I noticed that the text in Section 8 of routing-metrics-08 :
"The use of compound metrics, such as a polynomial function of 
individual metric values, will be described in a future revision of this 
document."
has been removed in routing-metrics-09.  Given the rigidity of the A 
field, I'm not sure that we can specify compound metrics in future OFs.

I'll send more comments about the rest of the document soon.

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

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 23 Sep 2010 10:27:35 +0200

I agree with this!

It would be much easier to add some type of OF specific 
"metrics-container" that could carry descriptions on how to combine the 
metrics.

If we have that any future OF could use that OF-configuration container
and use the information in that container (in whatever format that 
specific OF defines). Then we could define OF-Generic1 that handles
additive and multiplicative metrics, and that has some very simple
configuration container that describe how to handle the metrics.
Later we can add the OF-Generic2 that handles constraints, and
more advanced combinations of metrics - this without forcing all
other OFs to be almost-generic.

Best regards,
-- Joakim Eriksson, SICS

Phoebus Chen skrev 2010-09-23 09:44:
> What do we set in the "A" field of the Routing Metric/Constraint object
> depicted in Figure 2? I would prefer to replace "A=0x03: The routing
> metric is multiplicative" with "A=0x03: The routing metric is aggregated
> in some other fashion specified by the objective function." Or, there
> should be a sentence in the specification saying that the objective
> function can "override" and ignore this field (and MUST set A=0x00 if
> the OF plans for the A field to be ignored).
>

-- 
-- Joakim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Sep 2010 10:31:12 +0200

Le 23/09/2010 10:27, Joakim Eriksson a écrit :
> "metrics-container" that could carry descriptions on how to combine
> the metrics.

I agree with an idea of "metrics container".

One would try metrics in practice first with another routing protocol
than RPL, to make sure the metrics themselves are ok.  Independent
testing of metrics (independend of RPL) reassures the metrics themselves
are fine.

It would be good to suggest metric encodings (containers) working with
the widely available RA, RIP and OSPF and then to RPL which is under
development.

Alex

>
> If we have that any future OF could use that OF-configuration
> container and use the information in that container (in whatever
> format that specific OF defines). Then we could define OF-Generic1
> that handles additive and multiplicative metrics, and that has some
> very simple configuration container that describe how to handle the
> metrics. Later we can add the OF-Generic2 that handles constraints,
> and more advanced combinations of metrics - this without forcing all
> Best regards, -- Joakim Eriksson, SICS
>
>
>> I'm in the midst of making a pass through routing-metrics-09, and
>> a question I (and others) asked earlier keeps coming up back in my
>> head:
>>
>> The argument was to not have a flood of new RFCs specifying OFs for
>> each possible new way of combining metrics. OK.
>>
>> multiplication, or some other operator to combine some of these
>> metrics. What do we set in the "A" field of the Routing
>> Metric/Constraint object depicted in Figure 2? I would prefer to
>> replace "A=0x03: The routing metric is multiplicative" with
>> "A=0x03: The routing metric is aggregated in some other fashion
>> specified by the objective function." Or, there should be a
>> sentence in the specification saying that the objective function
>> can "override" and ignore this field (and MUST set A=0x00 if the OF
>> plans for the A field to be ignored).
>>
>> I noticed that the text in Section 8 of routing-metrics-08 : "The
>> use of compound metrics, such as a polynomial function of
>> individual metric values, will be described in a future revision of
>> this document." has been removed in routing-metrics-09. Given the
>> rigidity of the A field, I'm not sure that we can specify compound
>> metrics in future OFs.
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Sep 2010 10:47:10 +0200

Le 21/09/2010 18:20, Philip Levis a écrit :
>
> On Sep 21, 2010, at 2:36 AM,<[email-masked]>
>> As part of an industrial ecosystem, I must say no LLN equipment
>> vendor today said it needs/wants link energy metric. If there's
>> any such vendor on this list, please speak up now and state your
>> market/application characteristics.
>

I wanted to leave a silence space and answer now.

The real applications in this space are so numerous that it looks hard
to avoid some of them actually using link energy metrics.

Independently of node vs link we're clear energy metrics are required.
The metrics draft offers a node energy metric as 3 distinctive values:
"powered", "battery", "scavenger".  I am not sure how to fit this metric
in a vehicle where all devices are on the same battery - (1) they all
should use the same value hence can't make any distinction
powered-battery-scavenger, (2) is that value "powered" or "battery"?

For that vehicular and other reasons I believe node energy metrics are
not sufficient and link metrics are necessary: in a vehicle where each
link has a distinctive link energy metric we can have a routing protocol
make decisions based on link energy metrics (rather than the unique
battery value).

As for the vendor question: which LLN equipment vendor needs this?  This
is something which may be exhibited here or not, now or later.  For now
I think of link energy metrics as a technical issue worth taking into
account.

If technically it makes sense then a richer menu of options may tempt
vendors more to choose among ways to make money out of it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Sep 2010 11:14:10 +0200

Le 21/09/2010 11:36, [email-masked] a écrit :
> Hello all,
>
> As part of our research activity, we published "academic" papers
> about protocols that minimize the total path energy expenditure (sum
>  of link energies), in a grand vision of saving Energy and our
> Planet. Many others did, I can point at publications over 10 years
> ago, long before ours. As a co-author of this draft, I pondered on
> introducing the link energy metric. As part of an industrial
> ecosystem, I must say no LLN equipment vendor today said it
> needs/wants link energy metric.

Well depends who one talks to.  I think any base station manufacturer
facing court against "robin des toits" has given much thought about how
much energy their links put in the air.

> If there's any such vendor on this list, please speak up now and
> state your market/application characteristics.
>
> Now getting technical: Routing purely along minimal energy pathes is
>  nice and saves the Planet, but it introduces the risk of over-using
>  the same lower energy links, therefore the same few nodes, which can
>  be energy limited, leading to shorter node lifetimes. Some nodes die
>  early.

Hmm... it depends.  I agree with you that in some networks if node local
energy is not considered then routing according only to link energy
metrics may overlook some nodes dying loosing their energy.

> Another interesting metric is Max(Min(Remaining_Energy), which
> routes around energy-depleted nodes.

Interesting, yes.

> However, it may use more energy for the overall path than the above,
>  so all nodes die at the same time but maybe a little earlier than
> necessary.

Interesting.

> In research papers by others and also by my team, hybrid metrics

Research papers: yes there are several such papers talking link
energy metrics, "energy consumed per packet transferred", "power
required to transmit a signal", "energy-based link costs".

I will have to go look the research papers you mention about hybrid
metrics too.

> have been proposed that combine the above two. When nodes have plenty
> of energy (eg brand new battery-powered nodes), the network routes
> along minimal energy pathes, while when nodes start aging and
> becoming energy-depleted, the Max(Min(Remaining_Energy) gradually
> kicks in to take the forwarding burden off of the energy-depleted
> nodes and save their energy for sensing. I would have loved
> introducing this hybrid metrics into RPL, but I resisted for lack of
>  a clearly identified industrial need. I made sure there is nothing
> that prevents them from being introduced later, should the need
> arise.

Well, would the hybrid concept be able to hybridize node and link energy
metrics?  If yes then I am interested.

> Finally: A major difficulty with link energy in wireless is its
> inaccuracy. Even though you can quote joules for your own
> transmission and for your own reception, and although you can
> probably also account for the number of expected retransmissions,
> overhearing is a big problem.

Yes, overhearing and interference and fading are big problems.  They all
affect the way current metrics are designed anyways, in unexpected manners.

> If you have 100 nodes in your radio vicinity, the energy cost you
> should account for for transmitting on this "link" (from this node)
> is 100 times higher than what you thought (assuming L2 broadcast or
> even L2 unicast and not-so-smart receivers).

Well yes, your phrase sounds ok to me, provided we talk PHY level.
Maybe at IP level we don't worry less about overhearing, interference
and fading.

In comparison: I don't see how node energy metrics are not affected by
same uncertainty factors too: "battery" working is often influenced by
ambiant temperature, age.

Alex

>
> My 3.5 c
>
> Dominique
>
>
> -----Message d'origine----- De : [email-masked]
> [mailto:[email-masked]] De la part de Alexandru Petrescu
> Envoyé : mardi 21 septembre 2010 08:48 À : JP Vasseur Cc :
> [email-masked] Objet : Re: [Roll] WG Last Call on
>> metrics/constraint along with various mechanisms to manipulate
>> these metrics and constraint and needless to say that additional
>> metrics could be defined in the future.
>>
>> optimize path against link energy ?". Trying to avoid nodes that
>> are running out of energy or compute paths so that energy
>> consumption is even distributed thanks to load balancing is well
>> understood. But I fail to see how link energy metrics should be
>> used ? Say that you have n paths and their path cost reflects the
>> amount of energy required along each of them. Would you choose the
>>  least cost path ?
>
> YEs.
>
>> If so, what if you choose a path traversing a set of battery
>> operated nodes, instead of a path that may consume more energy but
>>  would traverse nodes for which energy is not a limited factor ?
>
> Well, I'd say that if one needs to build a path both low energy
> emission _and_ consuming least energy on nodes then one would need to
> use both metrics: link energy and node energy, which could indeed be
> complex.
>
> ----       A1----           ---- P3   Dst | Next Hop |Hops | Energy |
> R1 |-------| R2 |---------| R3 |--   -----------------------------
> Legend R1: Router1 E1: Energy value for this link A1: Address of one
>  of R2's interfaces P3: prefix valid on interface
>
> In this picture R1 knows not only it takes 2 hops to reach R3 but
> also it takes energy E1+E2.  I hope it is illustrative.  Other
> examples available upon request.
>
>
> RA, RIP or OSPF is more appropriate.  But a good metric should work
> with all of them.  It would also be good to exercise the RPL metrics
> with other routing protocols like RIP, or simple RA of ND.
>

---

From: Phoebus Chen <[email-masked]>
Date: Thu, 23 Sep 2010 12:47:19 +0200

I'm a little confused about the Node Fanout Ratio (NFR) Object in 
Section 3.4 .  Does fanout refer to outgoing links (upward, to a 
parents), or incoming links (downward, from children) of a node?

The text says:
"The Node Fanout Ratio (NFR) object is used to provide information on
the nodes current forwarding load."

 From this, I would read fanout to mean the number of incoming links, if 
you are concerned with upward routing.  The amount of traffic you have 
to forward depends on the amount of traffic coming in, which might be 
roughly related to the number of children.  But as far as I know, RPL 
nodes only keep track of parents, not of children, so it cannot keep 
track of the number of incoming links.

Or is the NFR object is used for optimizing the topology for downward 
routing (related to DAO fanout), to get path diversity / reliability? 
If this is the case, perhaps this should be explained in the metrics 
document.

---

From: Phoebus Chen <[email-masked]>
Date: Thu, 23 Sep 2010 15:37:51 +0200

General Editorial Comments for the authors:

1) I suggest moving Section 6 on "Use of multiple DAG Metric Container" 
into Section 2 "Object formats."  It's near the end of the document, yet 
it says
"In the rest of this document, this use of multiple DAG Metric
  Containers will be considered as if they were actually just one long
  DAG Metric Container."

2) I suggest moving Section 7 "Metric consistency" into Section 1 
"Introduction".  (Also, maybe the point being made in this section is 
obvious?)

3) I suggest moving Section 8 "Metric Usage" into a subsection of 
Section 2, or somewhere earlier in the document.  It will shed more 
light when the precedence field is first discussed.  Of course, the text 
will need to mention that the metrics mentioned in the examples will be 
defined in more detail in Sections 3 and 4.

4) Section 8 gives an example of how to break ties in metrics.  What 
happens when there is a tie in the precedence field between two metrics? 
  Is this not allowed?  Is it broken in the order of the objects in the 
metric container (as it was before in version 8 of the document)?  Or is 
the behavior in this case "beyond the scope of this document," and must 
be resolved by the Objective Function?

5) Section 9 is still incomplete... is this OK for last call?  Only the 
NSA and Hop-count objects are described in 9.3 and 9.4 respectively.

6) Section 1 "Introduction" has a long discussion on Dynamic vs. Static 
Metrics, after classifying the links according to characteristics 
(paragraphs 1, 3-5 after the list on pg. 5).  I suggest a shorter 
description and deferring / moving the bulk of the discussion to Section 
5 "Computation of dynamic metrics and attributes."  Or at least, present 
this discussion after the discussion on the other classifications (which 
turns out to just be one sentence on link and node metrics not being 
exclusive), following the order of the list.

7) In many of the object formats, several of the descriptions of the 
flags/fields do not follow the order of the flags/fields in the object. 
  See Figure 2 and the following description, Figure 3 and the following 
description, and Figure 5 and the following description.  It would be a 
little easier to read if the orders matched.

8) In several figures, the last Byte indices above the objects are 
partially missing.  Not a big deal, but it looks a little sloppy leaving 
them off.

9) There are misspelled words throughout the document... please run it 
through a spell checker after making the final edits.

Nits below.  Search for comments preceded by PC>.

Networking Working Group                                JP. Vasseur, Ed.
Internet-Draft                                        Cisco Systems, Inc
Intended status: Standards Track                             M. Kim, Ed.
Expires: March 9, 2011                    Corporate Technology Group, KT
                                                                K. Pister
                                                            Dust Networks
                                                                N. Dejean
                                                              Coronis SAS
                                                               D. Barthel
                                                    France Telecom Orange
                                                        September 5, 2010

Routing Metrics used for Path Calculation in Low Power and Lossy

Networks

draft-ietf-roll-routing-metrics-09

Abstract

    Low power and Lossy Networks (LLNs) have unique characteristics
    compared with traditional wired and ad-hoc networks that require the
    specification of new routing metrics and constraints.  By contrast
    with typical Interior Gateway Protocol (IGP) routing metrics using
    hop counts or link metrics, this document specifies a set of link and
    node routing metrics and constraints suitable to LLNs to be used by
    the Routing for Low Power and lossy networks (RPL) routing protocol.

Requirements Language

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

Vasseur, et al.           Expires March 9, 2011                 [Page 1]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    This Internet-Draft will expire on March 9, 2011.

Copyright Notice

    Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Vasseur, et al.           Expires March 9, 2011                 [Page 2]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    2.  Object formats . . . . . . . . . . . . . . . . . . . . . . . .  7
    3.  Node Metric/Constraint objects . . . . . . . . . . . . . . . .  9
      3.1.  Node State and Attributes object . . . . . . . . . . . . . 10
      3.2.  Node Energy object . . . . . . . . . . . . . . . . . . . . 11
      3.3.  Hop-Count object . . . . . . . . . . . . . . . . . . . . . 14
      3.4.  Node Fanout Ratio object . . . . . . . . . . . . . . . . . 15
    4.  Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16
      4.1.  Throughput . . . . . . . . . . . . . . . . . . . . . . . . 16
      4.2.  Latency  . . . . . . . . . . . . . . . . . . . . . . . . . 17
      4.3.  Link reliability . . . . . . . . . . . . . . . . . . . . . 18
        4.3.1.  The Link Quality Level reliability metric  . . . . . . 19
        4.3.2.  The Expected Transmission Count (ETX) reliability
                object . . . . . . . . . . . . . . . . . . . . . . . . 21
      4.4.  Link Color object  . . . . . . . . . . . . . . . . . . . . 22
        4.4.1.  Link Color object description  . . . . . . . . . . . . 22
        4.4.2.  Mode of operation  . . . . . . . . . . . . . . . . . . 24
    5.  Computation of dynamic metrics and attributes  . . . . . . . . 24
    6.  Use of multiple DAG Metric Container . . . . . . . . . . . . . 25
    7.  Metric consistency . . . . . . . . . . . . . . . . . . . . . . 25
    8.  Metric usage . . . . . . . . . . . . . . . . . . . . . . . . . 25
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
      9.1.  Routing Metric/Constraint type . . . . . . . . . . . . . . 26
      9.2.  Routing Metric/Constraint common header  . . . . . . . . . 27
      9.3.  NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27
      9.4.  Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28
    10. Security considerations  . . . . . . . . . . . . . . . . . . . 28
    11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
      12.1. Normative references . . . . . . . . . . . . . . . . . . . 29
      12.2. Informative references . . . . . . . . . . . . . . . . . . 29
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

Vasseur, et al.           Expires March 9, 2011                 [Page 3]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

1. Introduction

    This document makes use of the terminology defined in
    [I-D.ietf-roll-terminology].

    Low power and Lossy Networks (LLNs) have specific routing
    characteristics compared with traditional wired or ad-hoc networks
    that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and
    [RFC5867].

    Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have
    used quantitative static link metrics.  Other mechanisms such as
    Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see
    [RFC2702] and [RFC3209]) make use of other link attributes such as
    the available reserved bandwidth (dynamic) or link affinities (most
    of the time static) to compute constrained shortest paths for Traffic
    Engineering Label Switched Paths (TE LSPs).

    This document specifies routing metrics and constraints to be used in
    path calculation by the Routing Protocol for Low Power and Lossy
    Networks (RPL) specified in [I-D.ietf-roll-rpl].

    One of the prime objectives of this document is to propose a flexible
    mechanism for the advertisement of routing metrics and constraints
    used by RPL.  Some RPL implementations may elect to adopt an
    extremely simple approach based on the use of a single metric with no
    constraint whereas other implementations may use a larger set of link
    and node routing metrics and constraints.  This specification
    provides a high degree of flexibility and a set of routing metrics
    and constraints.  New routing metrics and constraints could be
    defined in the future, as needed.

    RPL is a distance vector routing protocol that builds Directed
    Acyclic Graphs (DAGs) based on routing metrics and constraints.  DAG
    formation rules are defined in [I-D.ietf-roll-rpl]:

    o  The DAG root may advertise a routing constraint used as a "filter"
       to prune links and nodes that do not satisfy specific properties.
       For example, it may be required for the path to only traverse
       nodes that are mains powered or links that have at least a minimum
       reliability or a specific "color" reflecting a user defined link
       characteristic (e.g the link layer supports encryption).

    o  A routing metric is a quantitative value that is used to evaluate
       the path cost.  Link and nodes metrics are usually (but not
       always) additive.

    The best path is the path with the lowest cost with respect to some

Vasseur, et al.           Expires March 9, 2011                 [Page 4]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    metrics that satisfies all constraints (if any) and is also called
    the shortest constrained path (in the presence of constraints).

    Routing metrics can be classified according to the following set of
    characteristics:

    o  Link versus Node metrics

    o  Qualitative versus quantitative

    o  Dynamic versus static

    It must be noted that the use of dynamic metrics is not new and has
    been experimented in ARPANET 2 [Khanna1989], with moderate success.
    The use of dynamic metrics is not trivial and great care must be
    given to the use of dynamic metrics since it may lead to potential
    routing instabilities. it must be noted that the use of dynamic
    metrics has been largely experimented and deployed in a number of
    (non IP) networks in the past decade.

    As pointed out in various routing requirements documents (see
    [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to
    take into account a variety of node constraints/metrics during path
    computation.

    It is also worth mentioning that it is fairly common for links in
    LLNs to have fast changing node and link characteristics, which must
    be taken into account when specifying routing metrics.  For instance,
    in addition to the dynamic nature of some links (e.g. wireless but
    also Poweline Communication (PLC) links, nodes' resources such as
    residual energy and other link's charatacteristics such as the
    throughput are changing continuously and may have to be taken into
    account during the path computation.  Similarly, link attributes
    including throughput and reliability may drastically change over time
    due to multi-path interference.

    Very careful attention must be given when using dynamic metrics and
    attributes that affect routing decisions in order to preserve routing
    stability.  Routing metrics and constraints may either be static or
    dynamic.  When dynamic, a RPL implementation SHOULD make use of a
    multi-threshold scheme rather than fine granular metric updates so as
    to avoid constant routing changes.

    Furthermore, it is a time and energy consuming process to update
    dynamic metrics and recompute the routing tables on a frequent basis.
    Therefore, it may be desirable to use a set of discrete values to
    reduce computational overhead and bandwidth utilization.  Of course,
    this comes with a cost, namely, reduced metric accuracy.  In other

Vasseur, et al.           Expires March 9, 2011                 [Page 5]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    cases, a set of flags may be defined to reflect a node state without
    having to define discrete values.

    Some link or node characteristics (e.g. link reliability flag,
    remaining energy on the node) may either be used by RPL as routing
    constraints or metric.  For example, the path may be computed to

PC> s/metric/metrics/

    avoid links that do not provide a sufficient level of reliability
    (use as a constraint) or as the path offering the maximum number of
    links with a specified reliability level (use as a metric).   The

PC> path offering the maximum fraction / proportion of links with a 
specified reliability level?  Paths with more good links might be longer.

    document provides the flexibility to use link and node charaterisics
    either as constraints and/or metrics.

    The set of routing metrics and constraints used by an RPL
    implementation is signalled along the Directed Acyclic Graph (DAG)
    that is built according to the Objective Function (rules governing
    how to build a DAG) and the routing metrics and constraints are
    advertised in the DAG Information Option (DIO) message specified in
    [I-D.ietf-roll-rpl].  RPL may be used to build DAGs with different
    characteristics.  For example, it may be desirable to build a DAG
    with the goal to maximize reliability by using the link reliability
    metric to compute the "best" path.  Another example might be to use
    the energy node characteristic (e.g. mains powered versus battery
    operated) as a node constraint when building the DAG so as to avoid
    battery powered nodes in the DAG while optimizing the link
    throughput.

    Links and nodes routing metrics and constraints are not exclusive.

PC> s/Links and nodes/ Link and node/
Since they are being used as adjectives here.

    The requirements on reporting frequency may differ among metrics,
    thus different reporting rates may be used for each category and are
    consequently implementatin-specific.

    The specification of objective functions used to compute the DAG
    built by RPL is out of the scope of this document.  Routing metrics
    and constraints are decoupled from the objective function.  So a
    generic objective function could for example specify the rules to
    select the best parents in the DAG, the number of backup parents,
    etc.  Such objective function can be used with any routing metrics
    and/or contraints such as the ones specified in this document.

    Some metrics are either aggregated or recorded.  In the former case,
    the metric is adjusted as the DIO message travels along the DAG.  For
    example, if the metric is the link latency, each node updates the
    latency metric along the DAG.  By contrast, a metric may be recorded
    in which case each node adds a sub-object reflecting the local
    metric.  For example, it might be desirable to record the link
    quality level along the path.  In this case, each visited node adds a
    sub-object reporting the local link quality level.  In order to limit

Vasseur, et al.           Expires March 9, 2011                 [Page 6]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    the number of sub-objects, the use of a counter may be desirable
    (e.g. record the number of links with a certain link quality level),
    thus compressing the information to reduce the message lenght.  Upon
    receiving the DIO message from a set of parents, a node can decide
    accoding to the OF and local policy which node to choose as a parent
    based on the maximum number of links with a specific link reliability
    level for example.

PC> level, for example.

    Note that the routing metrics are constrained specified in this

PC> s/are constrained/and constraints/

    document are not specific to any link layer.  Internal API between

PC> An internal API...

    the MAC layer and RPL may advantageously be used to accurately

PC> remove "advantageously"

    reflect the metrics values of the link (wireless, wired, PLC).

2. Object formats

    Routing metrics and constraints are carried within the DAG Metric
    Container object defined in [I-D.ietf-roll-rpl].

   0               1               2               3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
  |     Type=2    |  Option Len   |  Routing Metric/Constraint objects
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

         Figure 1: DAG Metric Container format

    The Routing Metric/Contraints objects have a common format consisting

PC> s/Contraints/Constraint/

    of one or more 8-bit words with a common header:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Routing-MC-Type|  Flags    |P|C|0|R| A |  Prec | Length (bytes)|

PC>   |Routing-MC-Type|   Res    |P|C|O|R| A |  Prec | Length (bytes)|

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                        (object body)                        //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2: Routing Metric/Constraint object generic format

    The object body carries one or more sub-objects.

    Note that the Routing Metric/Constraint objects defined in this
    document can appear in any order in the DAG Metric Container.

Vasseur, et al.           Expires March 9, 2011                 [Page 7]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    Routing-MC-Type (Routing Metric/Contraint Type - 8 bits): the Routing
    Metric/Constraint Type field uniquely identifies each Routing Metric/
    Constraint object and is managed by IANA.

    Length: this field defines the length of the object body, in bytes.

    The Flag field of the Routing Metric/Constraint object is managed by
    IANA.  Unassigned bits are considered as reserved.  They MUST be set
    to zero on transmission and MUST be ignored on receipt.

    o  C Flag.  When set, this indicates that the Routing Metric/
       Constraint object refers to a routing constraint.  When cleared,
       the routing object refers to a routing metric.

    o  O Flag: The O flag is used exclusively for routing constraints (C
       flag is set).  When set, this indicates that the constraint is
       optional.  When cleared, the constraint is mandatory.  If the C
       flag is zero, the O flag MUST be set to zero on transmission and
       ignored on reception.

    o  R Flag: The R Flag is only relevant for routing metric (C=0) and
       MUST be cleared for C=1.  When set, this indicates that the
       routing metric is recorded along the path.  Conversely, when
       cleared, the routing metric is aggregated.

    o  A Field: The A field is used to indicate whether an aggregated
       routing metric is additive, multiplicative, reports a maximum or a
       minimum.

       *  A=0x00: The routing metric is additive

       *  A=0x01: The routing metric reports a maximum

       *  A=0x02: The routing metric reports a minimum

       *  A=0x03: The routing metric is multiplicative

       The A field has no meaning when the C Flag is set (i.e. when the
       Routing Metric/Constraint object refers to a routing constraint)
       and MUST be written to 0x00.

    o  Prec field: The P field indicates the precedence of this Routing
       Metric/Constraint object.  This is useful when a DAG Metric
       Container contains several Routing Metric objects.  The value 0
       means the highest precedence.  The precedence field can be used as
       a tie-breaker in the presence of the multiple metrics advertising
       the same value.

Vasseur, et al.           Expires March 9, 2011                 [Page 8]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    o  P field: the P field is only used for recorded metric.  When

PC> s/metric/metrics/

       cleared, all nodes along the path managed to recorded the

PC> s/recorded/record/

       corresponding link metric.  When set, this indicates than one of

PC> remove "link"; s/of/or/

       more nodes along the path could not record the metric of interest
       (either because of lack of knowledge or because this was prevented
       by policy).

    Example 1: A DAG formed by RPL where all nodes must be main-powered

PC> mains-powered

    and the best path is the one with lower aggregated ETX.  In this case
    the DAG Metric container carries two Routing Metric/Constraint
    objects: one is an ETX metric object with header (C=0, O=0, A=00,
    R=0) and the second one is a Node Energy constraint with header (C=1,

PC> s/constraint/constraint object/

    O=0, A=00, R=0).  Note that a RPL instance may use the metric object
    to report a maximum (A=0x01) or a minimum (A=0x02).  If the best path
    is characterized by the path avoiding low quality links for example,

PC> Replace with "If, for example, the best path is characterized by the 
path avoiding low quality links,"

    then the path metric reports a maximum (A=0x01) (note that higher
    values mean lower link quality): when the link quality metric (ETX)
    is processed along a path, each node updates its value if the current

PC> s/current/node's current/;  There is some implicit assumption that 
the reader understands that "its value" refers to the node's ETX, which 
corresponds to the ETX of the best path to the root it knows thus far. 
And that the "node's current link ETX" is for the link to its parent. 
Not sure how to easily fix the sentence so it's clearer.

    link ETX value is higher than the value carried by the metric object.

    Example 2: A DAG formed by RPL where the link metric is the link
    quality level and link quality levels must be recorded along the
    path.  In this case, the DAG Metric Container carries a Routing
    Metric/Constraint object: link quality level metric (C=0, O=0, A=00,
    R=1) containing multiple sub-objects.

    A Routing Metric/Constraint object may also include one or more type-
    length-value (TLV) encoded data sets.  Each Routing Metric/Constraint
    TLV has the same structure:

    Type: 1 byte
    Length: 1 byte
    Value: variable

    A Routing Metric/Constraint TLV is comprised of 1 byte for the type,
    1 byte specifying the TLV length, and a value field.  The TLV length
    field defines the length of the value field in bytes.

    Unrecognized TLVs MUST be ignored.

    IANA management of the Routing Metric/Constraint objects identifier
    codespace is described in Section 9.

3. Node Metric/Constraint objects

    It is fairly common for LLNs to be made of nodes with heterogeneous
    attributes and capabilities (e.g. nodes being battery operated or

Vasseur, et al.           Expires March 9, 2011                 [Page 9]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    not, amount of memory, etc).  More capable and stable nodes may
    assist the most constrained ones for routing packets, which results
    in extension of network lifetime and efficient network operations.
    This is a typical (but non exclusive) use of constraint-based routing

PC> s/non exclusive/non-exclusive/; s/routing/routing,/

    where the computed path may not be the shortest path according to
    some specified metrics.  Another use is to find the shortest path
    according to a pre-defined metric while avoiding link with a specific

PC> s/link/links/

    color (for example "non secured link").

PC> s/non secured/non-secured/

3.1. Node State and Attributes object

    The Node State and Attribute (NSA) object is used to provide
    information on the nodes characteristics.

    The NSA object MAY be present in the DAG Metric Container.  There
    MUST be no more than one NSA object as a constraint per DAG Metric
    Container, and no more than one NSA object as a metric per DAG Metric
    Container.

    The NSA object may also contain a set of TLVs used to convey various
    node characteristics.  No TLV is currently defined.

    The NSA Routing Metric/Constraint Type is to be assigned by IANA
    (recommended value=1).

    The format of the NSA object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |     Res       |  Flags    |A|O|  Optional TLVs
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

                 Figure 3: NSA object format

    Node workload may be hard to determine and expressed in some scalar
    form.  However, node workload could be a useful metric to consider
    during path calculation, in particular when queuing delays must be
    minimized for highly sensitive traffic considering Medium Access
    Control (MAC) layer delay.  Node workload MAY be set upon CPU
    overload, lack of memory or any other node related conditions.  Using
    a simple 1-bit flag to characterize the node workload provides a
    sufficient level of granularity, similarly to the "overload" bit used
    in routing protocols such as IS-IS.  Algorithms used to set the
    overload bit and to compute path to potentially avoid node with their

PC> s/path/paths/; s/node/nodes/

    overload bit set are outside the scope of this document but it is

PC> s/document/document,/

    RECOMMENDED to avoid too frequent changes of that bit to avoid

PC> remove "too", s/that/this/

    routing oscillations.

Vasseur, et al.           Expires March 9, 2011                [Page 10]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    Data Aggregation Attribute: data fusion involves more complicated
    processing to improve accuracy of the output data while data

PC> processing to improve the accuracy of the output data, while data

    aggregation mostly aims at reducing the amount of data.  This is
    listed as a requirement in Section 6.2 of [RFC5548].  Some
    applications may make use of the aggregation node attribute in their
    routing decision so as to minimize the amount of traffic on the
    network, thus potentially increasing its life time in battery

PC> s/life time/lifetime/

    operated environments.  Applications where high directional data flow

PC> s/high/highly/

    is expected on a regular basis may take advantage of data aggregation
    supported routing.

    The following two bits of the NSA object are currently defined:

    o  O Flag: When set, this indicates that the node is overloaded and
       may not be able to process traffic.

    o  A Flag: When set, this indicates that the node can act as a
       traffic aggregator.  An implementation MAY decide to add optional
       TLVs (not currently defined) to further describe the node traffic
       aggregator functionality.

    The Flag field of the NSA Routing Metric/Constraint object is managed
    by IANA.  Unassigned bits are considered as reserved.  They MUST be
    set to zero on transmission and MUST be ignored on receipt.

3.2. Node Energy object

    Whenever possible, a node with low residual energy should not be
    selected as a router, thus the support for constraint-based routing
    is needed.  In such cases, the routing protocol engine may compute a
    longer path (constraint based) for some traffic in order to increase
    the network life duration.

    The routing engine may prefer a "longer" path that traverses mains-
    powered nodes in particular for low-critical traffic or nodes
    equipped with energy scavenging, rather than a "shorter" path through

PC> "powered nodes, in particular for less critical traffic, rather than"
Remove the phrase on energy scavenging since it didn't make sense in the 
sentence.

    battery operated nodes.

    Power and energy are clearly critical resources in most LLNs.  As yet
    there is no simple abstraction which adequately covers the broad
    range of power sources and energy storage devices used in existing
    LLN nodes.  These include main-powered, primary batteries, energy-

PC> s/main-powered/mains-powered/; s/energy-/energy/

    scavengers, and a variety of secondary storage mechanisms.
    Scavengers may provide a reliable low level of power, such as might
    be available from a 4-20mA loop; a reliable but periodic stream of
    power, such as provided by a well-positioned solar cell; or
    unpredictable power, such as might be provided by a vibrational
    energy scavenger on an intermittently powered pump.  Routes which are

Vasseur, et al.           Expires March 9, 2011                [Page 11]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    viable when the sun is shining may disappear at night.  A pump
    turning on may connect two previously disconnected sections of a
    network.

    Storage systems like rechargeable batteries often suffer substantial
    degradation if regularly used to full discharge, leading to different
    residual energy numbers for regular versus emergency operation.  A
    route for emergency traffic may have a different optimum than one for
    regular reporting.

    Batteries used in LLNs often degrade substantially if their average
    current consumption exceeds a small fraction of the peak current that
    they can deliver.  It is not uncommon for battery-operated nodes to
    have a combination of primary storage, energy scavenging, and
    secondary storage, leading to three different values for acceptable
    average current depending on the time frame being considered, e.g.
    milliseconds, seconds, and hours/years.

    Raw power and energy values are meaningless without knowledge of the
    energy cost of sending and receiving packets, and lifetime estimates
    have no value without some higher-level constraint on the lifetime
    required of a device.  In some cases the path that exhausts the
    battery of a node on the bed table in a month may be preferable to a
    route that reduces the lifetime of a node in the wall to a decade.

    Given the complexity of trying to address such a broad collection of
    constraints, this document defines three levels of fidelity in the
    solution.

    The simplest solution relies on a 2-bit field encoding three types of
    power sources: "powered", "battery", "scavenger".  This simple
    approach may be sufficient for many applications.

    The mid-complexity solution is a single parameter that can be used to
    encode the energetic happiness of both battery powered and scavenging
    nodes.  For scavenging nodes, the 8 bit quantity is the power
    provided by the scavenger divided by the power consumed by the
    application, H=P_in/P_out, in units of percent.  Nodes which are
    scavenging more power than they are consuming will register above
    100.  The time period for averaging power in this calculation is out
    of the scope of this document but something related to the discharge
    time of the energy storage device on the node is probably
    appropriate.

PC> The time period for averaging power in this calculation may be 
related to the discharge time of the energy storage device on the node, 
but specifying this time period is out of the scope of this document.

    For battery powered devices, H is the current expected
    lifetime divided by the desired minimum lifetime.  The estimation of
    remaining battery energy and actual power consumption can be
    difficult, and the specifics of this calculation are out of scope of
    this document, but two examples are presented.  If the node can
    measure its average power consumption, then H can be calculated as

Vasseur, et al.           Expires March 9, 2011                [Page 12]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    the ratio of desired max power (initial energy E_0 divided by desired
    lifetime T) to actual power H=P_max/P_now.  Alternatively, if the

PC> s/power/power,/

    energy in the battery E_bat can be estimated, and the total elapsed
    lifetime, t, is available, then H can be calculated as the total
    stored energy remaining versus the target energy remaining: H= E_bat
    / [E_0 (T-t)/T].

    An example of optimized route is max(min(H)) for all battery operated
    nodes along the route, subject to the constraint that H>=100 for all
    scavengers along the route.

    The Node Energy (NE) object is used to provide information related to
    node energy and may be used as a metric or as constraint.

    The NE object MAY be present in the DAG Metric Container.  There MUST
    be no more than one NE object as a constraint per DAG Metric
    Container, and no more than one NE object as a metric per DAG Metric
    Container.

    The NE object Type is to be assigned by IANA (recommended value=2).

    The format of the NE object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |     NE Sub-objects
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

       Figure 4: NE object format

    The format of the NE sub-object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     | Flags |I| T |E|      E-E      |   Optional TLVs
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

             Figure 5: NE sub-object format

    The NE sub-object may also contain a set of TLVs used to convey
    various nodes' characteristics.

    The following flags are currently defined:

Vasseur, et al.           Expires March 9, 2011                [Page 13]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    o  T (node Type): 2-bit field indicating the node type.  When E=0x00,
       the node is mains powered.  When E=0x01 is battery powered.  When
       E=0x02 the node is powered by a scavenger.

PC> When E=0x01, the node is battery powered.  When E=0x02, the node is 
powered by an energy scavenger.

    o  I (Included): the I bit is only relevant when the node type is
       used as a constraint.  For example, the path must only traverse
       mains powered node.  Conversely, battery operated node must be

PC> s/mains powered node/mains-powered nodes/; s/battery operated 
node/battery operated nodes/

       excluded.  The I bit is used to stipulate inclusion versus
       exclusion.  When set, this indicates that nodes of type specified

PC> s/of type/of the type/

       in the node type field MUST be included.  Conversely, when
       cleared, this indicates that nodes of type specified in the node

PC> s/of type/of the type/

       type field MUST be excluded.

    o  E (Estimation): when the E bit is set for a metric, the estimated
       percentage of remaining energy on the node is indicated in the E-E
       8-bit field.  When cleared, the estimated percentage of remaining
       energy is not provided.  When the E bit is set for a constraint,
       the E-E field defines a threshold for the inclusion/exclusion: if
       an inclusion, nodes with values higher than the threshold are to
       be included; if an exclusion, nodes with values lower than the
       threshold are to be excluded.

    E-E (Estimated-Energy): 8-bit unsigned integer field indicating an
    estimated percentage of remaining energy.  The E-E field is only
    relevant when the E flag is set, and MUST be set to 0 when the E flag
    is cleared.

    If the NE object comprises several sub-objects when used as a
    constraint, each sub-object adds or subtracts node subsets as the
    sub-objects are parsed in order.  The initial set (full or empty) is
    defined by the I bit of the first sub-object: full if that I bit is
    an exclusion, empty is that I bit is an inclusion.

    No TLV is currently defined.

    The most complex solution involves a half dozen TLV parameters
    representing energy storage, consumption, and generation capabilities
    of the node, as well as desired lifetime, and will appear in a future
    version of this document.

PC> "and will appear in a future version of this document." should not 
appear in a Last Called document.

3.3. Hop-Count object

    The HoP-Count (HP) object is used to report the number of traversed
    nodes along the path.

    The HP object MAY be present in the DAG Metric Container.  There MUST
    be no more than one HP object as a constraint per DAG Metric
    Container, and no more than one HP object as a metric per DAG Metric

Vasseur, et al.           Expires March 9, 2011                [Page 14]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    Container.

    The HP object may also contain a set of TLVs used to convey various
    node characteristics.  No TLV is currently defined.

    The HP routing metric object Type is to be assigned by IANA
    (recommended value=3)

    The format of the Hop Count object body is as follows:

      0               1               2               3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |  Res  | Flags |   Hop Count   |  Optional TLVs
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

                Figure 6: Hop Count object format

    No Flag is currently defined.

    The HP object may be used as a constraint or a metric.  When used as
    a constraint, the DAG root indicates the maximum number of hops that
    a path may traverse.  When that number is reached, no other node can
    join that path.  When used as a metric each visited node simply

PC> s/metric/metric,/

    increments the Hop Count field.

3.4. Node Fanout Ratio object

    The Node Fanout Ratio (NFR) object is used to provide information on
    the nodes current forwarding load.

PC> s/nodes/node's/

    The NFR object MAY be present in the DAG Metric Container.  There
    MUST be no more than one NFR object as a constraint per DAG Metric
    Container, and no more than one NFR object as a metric per DAG Metric
    Container.

    The NFR object may also contain a set of TLVs used to convey various
    forwarding load characteristics.  No TLV is currently defined.

    The NFR object Type is to be assigned by IANA (recommended value=9).

Vasseur, et al.           Expires March 9, 2011                [Page 15]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The format of the NFR object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |     Flags               |  F R  |  Optional TLVs

PC> close gap between "F R"

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

                 Figure 7: NFR object format

    When the data traffic of the application supported by the network is
    known a priori, energy depletion in the network can be equalized
    simply by controlling the fanout ratio of router nodes.

    Algorithms describing how to compute the FR value and how to use it
    are outside the scope of this document.

    The following field of the NFR object is defined:

    o  FR Field: a 4-bit unsigned integer that indicates a relative
       fanout of the node.  A value of 15 indicates a node that is very
       close to, or at its maximum supported fanout capability.  A value
       of 0 indicates a very small fanout.

    Unassigned bits are considered as reserved.  They MUST be set to zero
    on transmission and MUST be ignored on receipt.

4. Link Metric/Constraint objects

4.1. Throughput

    Many LLNs support a wide range of throughputs.  For some links, this
    may be due to variable coding.  For the deeply duty-cycled links
    found in many LLNs, the variability comes as a result of trading
    power consumption for bit rate.  There are several MAC layer
    protocols which allow for the effective bit rate and power
    consumption of a link to vary over more than three orders of
    magnitude, with a corresponding change in power consumption.  For
    efficient operation, it may be desirable for nodes to report the
    range of throughput that their links can handle in addition to the
    currently available throughput.

    The Throughput object MAY be present in the DAG Metric Container.
    There MUST be no more than one Throughput object as a constraint per
    DAG Metric Container, and no more than one Throughput object as a
    metric per DAG Metric Container.

Vasseur, et al.           Expires March 9, 2011                [Page 16]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The Throughput object is made of throughput sub-objects and MUST at
    least comprise one Throughput sub-object.  The first Throughput sub-
    object MUST be the most recently estimated actual throughput.  The
    actual evaluation of the throughput is outside of this document.

PC> s/evaluation/estimation/; s/outside of this document/outside the 
scope of this document/

    Each Throughput sub-object has a fixed length of 4 bytes.

    The Throughput object does not contain any additional TLV.

    The Throughput object Type is to be assigned by IANA (recommended
    value=4)

    The format of the Throughput object body is as follows:

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  (sub-object) .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 8: Throughput object body format

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Throughput                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 9: Throughput sub-object format

    Throughput: 32 bits.  The Throughput is encoded in 32 bits in
    unsigned integer format, expressed in bytes per second.

4.2. Latency

    Similarly to throughput, the latency of many LLN MAC sub-layers can
    vary over many orders of magnitude, again with a corresponding change
    in current consumption.  Some LLN MAC link layers will allow the
    latency to be adjusted globally on the subnet, or on a link-by-link

PC> s/subnet, or on a link-by-link/subnet, on a link-by-link/

    basis, or not at all.  Some will insist that it be fixed for a given
    link, but allow it to be variable from link to link.

    The Latency object MAY be present in the DAG Metric Container.  There
    MUST be no more than one Latency object as a constraint per DAG
    Metric Container, and no more than one Latency object as a metric per
    DAG Metric Container.

Vasseur, et al.           Expires March 9, 2011                [Page 17]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The Latency object is made of Latency sub-objects and MUST at least
    comprise one Latency sub-object.  Each Latency sub-object has a fixed
    length of 4 bytes.

    The Latency object does not contain any additional TLV.

    The Latency object Type is to be assigned by IANA (recommended
    value=5)

    The Latency object is a metric or constraint.

    The format of the Latency object body is as follows:

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  (sub-object) .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 10: Latency object body format

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Latency                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11: Latency sub-object format

    Latency: 32 bits.  The Latency is encoded in 32 bits in unsigned
    integer format, expressed in microseconds.

    The Latency object may be used as a constraint or a path metric.  For
    example, one may want the latency not to exceed some value.  In this
    case, the Latency object common header indicates that the provided
    value relates to a constraint.  In another example, the Latency
    object may be used as an aggregated additive metric where the value
    is updated along the path to reflect the path latency.

4.3. Link reliability

    In LLNs, link reliability is degraded by external interference and
    multi-path interference (wireless links).  Multipath typically
    affects both directions on the link equally, whereas external
    interference is sometimes uni-directional.  Time scales vary from
    milliseconds to days, and are often periodic and linked to human
    activity.  Packet error rates can generally be measured directly, and

Vasseur, et al.           Expires March 9, 2011                [Page 18]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    other metrics (e.g. bit error rate, mean time between failures) are
    typically derived from that.  Note that such variability is not
    specific to wireless link but also applies to PLC links.

    A change in link quality can affect network connectivity, thus, link
    quality may be taken into account as a critical routing metric.  Link
    quality metric should be applied to each directional link unless bi-
    directionality is one of routing metrics.

PC> The previous sentence, saying "...unless bi-directionality is one of 
routing metrics" is confusing because bi-directionality is never 
mentioned in the document as a routing metric or constraint.  This might 
be a link state attribute to add in the future (I know there was a long 
discussion on link bi-directionality on the mailing list).

    A number of link reliability metrics could be defined reflecting
    several reliability aspects.  Two link reliability metrics are
    defined in this document: the Link Quality Level (LQL) and the
    Expected Transmission count Metric (ETX).

    Note that an RPL implementation MAY either use the LQL, the ETX or
    both.

4.3.1. The Link Quality Level reliability metric

    The Link Quality Level (LQL) object is used to quantify the link
    reliability using a discrete value, from 0 to 7 where 0 indicates
    that the link quality level is unknown and 1 reports the highest link
    quality level.  The mechanisms and algorithms used to compute the LQL
    is implementation specific and outside of the scope of this document.

    The LQL can either be used as a metric or a constraint.  When used as
    a metric, the LQL metric can be recorded or aggregated.  For example,
    the DAG may require to record the LQL for all traversed links.  Each

PC> s/DAG may require/OF may require/ (?);  Also, who is recording the 
LQL (subject missing)?

    node can then use the LQL to select the parent based on user defined
    rules (e.g. "select the path with the maximum number of links

PC> s/maximum number of links/maximum proportion of links/   (or some 
other better wording than this... see previous comment)

    reporting a LQL value of 3 or less").  By contrast the LQL link
    metric may be aggregated, in which case the sum of all LQLs may be
    reported (additive metric) or the minimum value may be reported along
    the path.

    When used as a recorded metric, a counter is used to compress the
    information where the number of links for each LQL is reported.

PC> When used as a recorded metric, a counter records the number of 
links at each LQL level in order to compress the data.

    The LQL object MAY be present in the DAG Metric Container.  There
    MUST be no more than one LQL object as a constraint per DAG Metric
    Container, and no more than one LQL object as a metric per DAG Metric
    Container.

    The LQL object MUST contain one or more sub-object used to report the
    number of links along with their LQL.

    The LQL object Type is to be assigned by IANA (recommended value=6)

Vasseur, et al.           Expires March 9, 2011                [Page 19]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The format of the LQL object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |       Res     | LQL sub-object
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

       Figure 12: LQL object format

    When the LQL metric is recorded, the LQL object body comprises one or
    more LQL Type 1 sub-object.

    The format of the LQL Type 1 sub-object is as follows

      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     | Val | Counter |
     +-+-+-+-+-+-+-+-+

     Figure 13: LQL Type 1 sub-object format

    Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates
    the highest link quality.

    Counter: number of links with that value.

    When the LQL metric is aggregated, the LQL object body comprises one
    LQL Type 2 sub-object:

    The format of the LQL Type 2 sub-object is as follows

      0               1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Aggregated LQL Value     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 14: LQL Type 2 sub-object format

    Aggregated LQL Value: when used as an additive metric (A=0x00), the
    aggregated LQL value reports the sum of all the LQL values for all
    links along the path.  When used to report a minimum (A=0x02), the
    field reports the minimum LQL value of all links along the path

PC> s/path/path,/

    ignoring undetermined LQLs (Aggregated LQL Value = 0).  When used to

PC> s/Aggregated LQL Value = 0/ LQL=0/

    report a maximum (A=0x01), the field reports the maximum LQL value of
    all links along the path.  When used to report a multiplication
    (A=0x03), and the LQL field of one of the links along the path is

Vasseur, et al.           Expires March 9, 2011                [Page 20]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    undetermined (LQL=0), the undetermined LQL will be ignored and not be
    aggregated (i.e. no reset to Aggregated LQL Value field).

PC> s/no reset/no change/

4.3.2. The Expected Transmission Count (ETX) reliability object

    The Expected Transmission Count (ETX) metric is the number of
    transmissions a node expects to make to a destination in order to
    successfully deliver a packet.

    For example, an implementation may use the following formula: ETX= 1
    / (Df * Dr) where Df is the measured probability that a packet is
    received by the neighbor and Dr is the measured probability that the
    acknowledgment packet is successfully received.  This document does
    not mandate the use of a specific formula to compute the ETX value.

    The ETX object MAY be present in the DAG Metric Container.  There
    MUST be no more than one ETX object as a constraint per DAG Metric
    Container, and no more than one ETX object as a metric per DAG Metric
    Container.

    The ETX object is made of ETX sub-objects and MUST at least comprise
    one ETX sub-object.  Each ETX sub-object has a fixed length of 8
    bits.

    The ETX object does not contain any additional TLV.

    The ETX object Type is to be assigned by IANA (recommended value=7)

Vasseur, et al.           Expires March 9, 2011                [Page 21]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The format of the ETX object body is as follows:

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  (sub-object) .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 15: ETX object body format

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ETX              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 16: ETX sub-object format

    ETX: 16 bits.  The ETX * 128 is encoded using 16 bits in unsigned
    integer format, rounded off to the nearest whole number.  For
    example, if ETX = 3.569, the object value will be 457.  If ETX >
    511.9921875, the object value will be the maximum which is 65535.

    The ETX object may be used as a constraint or a path metric.  For
    example, it may be required that the ETX must not exceed some
    specified value.  In this case, the ETX object common header
    indicates that the value relates to a constraint .  In another
    example, the ETX object may be used as an aggregated additive metric
    where the value is updated along the path to reflect to path quality.

4.4. Link Color object

4.4.1. Link Color object description

    The Link Color (LC) object is an administrative 10-bit link
    constraint (which may either be static or dynamically adjusted) used
    to avoid or attract specific links for specific traffic types.

    The LC object can either be used as a metric or as a constraint.
    When used as a metric, the LC metric can only be recorded.  For
    example, the DAG may require recording the link colors for all
    traversed links.  Each node can then use the LC to select the parent
    based on user defined rules (e.g. "select the path with the maximum
    number of links having their first bit set 1 (e.g. encrypted
    links)").  The LC object may also be used as a constraint.

    When used as a recorded metric, a counter is used to compress the

Vasseur, et al.           Expires March 9, 2011                [Page 22]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    information where the number of links for each Link Color is
    reported.

    The Link Color (LC) object MAY be present in the DAG Metric
    Container.  There MUST be no more than one LC object as a constraint
    per DAG Metric Container, and no more than one LC object as a metric
    per DAG Metric Container.

    There MUST be a at least one LC sub-object per LC object.

    The LC object does not contain any additional TLV.

    The LC object Type is to be assigned by IANA (recommended value=8)

    The format of the LC object body is as follows:

      0               1               2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
     |      Res      | LC sub-objects
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

       Figure 17: LC object format

    When the LC object is used as a recorded metric, the LC object body
    comprises one or more LC Type 1 sub-objects.

    The format of the LC Type 1 sub-object body is as follows:

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Link Color     |  Counter  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 18: LC Type 1 sub-object format

    When the LC object is used as a constraint, the LC object body
    comprises one or more LC Type 2 sub-objects.

Vasseur, et al.           Expires March 9, 2011                [Page 23]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    The format of the LC Type 2 sub-object body is as follows:

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Link Color        |I|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 19: LC Type 2 sub-object format

    I Bit: The I bits is only relevant when the Link Color is used as a
    constraint.  When cleared, this indicates that links with the
    specified color must be included.  When set, this indicates that
    links with the specified color must be excluded.

    The use of the LC object is outside the scope of this document.

4.4.2. Mode of operation

PC> This breaks with the format of the other metrics section.  Is it 
necessary to have a "Mode of operation" subsection here?  Can we just 
remove the section heading (include it in 4.4)?

    The link color may be used as a constraint or a metric.

    o  When used as constraint, the LC object may be inserted in the DAG
       Metric Container to indicate that links with a specific color
       should be included or excluded from the computed path.

    o  When used as recorded metric, each node along the path may insert
       a LC object in the DAG Metric Container to report the color of the
       local link.  If there is already a LC object reported a similar

PC> s/reported/reporting/

       color, the node MUST NOT add another identical LC sub-object and
       MUST increment the counter field.

5. Computation of dynamic metrics and attributes

    As already pointed out, dynamically calculated metrics are of the
    utmost importance in many circumstances in LLNs.  This is mainly
    because a variety of metrics change on a frequent basis, thus
    implying the need to adapt the routing decisions.  That being said,
    care must be given to the pace at which changes are reported in the
    network.  The attributes will change according to their own time
    scales.  RPL controls the reporting rate.

    To minimize metric updates, multi-threshold algorithms MAY be used to
    determine when updates should be sent.  When practical, low-pass
    filtering and/or hysteresis should be used to avoid rapid
    fluctuations of these values.  Finally, although the specification of
    path computation algorithms using dynamic metrics are out the scope
    of this document, it is RECOMMENDED to carefully design the route

Vasseur, et al.           Expires March 9, 2011                [Page 24]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    optimization algorithm to avoid too frequent computation of new
    routes upon metric values changes.

    Controlled adaptation of the routing metrics and rate at which paths
    are computed are critical to avoid undesirable routing instabilities
    resulting in increased latencies and packet loss because of temporary
    micro-loops.  Furthermore, excessive route changes will adversely
    impact the traffic and power consumption in the network, thus
    potentially impacting its scalability.

6. Use of multiple DAG Metric Container

    Since RPL options length are coded using 1 octet, their length cannot
    exceed 256 bytes, which also applies to the DAG Metric Container.
    Although in the vast majority of cases, the advertised routing
    metrics and constraints will not require that much space, there might
    be circumstances where larger space will be required, should for
    example a set of routing metrics be recorded along a long path.  In
    this case, as specified in [I-D.ietf-roll-rpl], routing metrics will
    be carried using multiple DAG Metric Containers.

    In the rest of this document, this use of multiple DAG Metric
    Containers will be considered as if they were actually just one long
    DAG Metric Container.

7. Metric consistency

    Since a set of metrics and constraints will be used for links and
    nodes in LLN, it is particularly critical to ensure the use of
    consistent metric calculation mechanisms for all links and nodes in
    the network, similarly to the case of inter-domain IP routing.

8. Metric usage

    This section describes how metrics carried in the DAG Metric
    Container shall be used.

    When the DAG Metric Container contains a single aggregated metric
    (scalar value), the order relation to select the best path is
    implicitly derived from the metric type.  For example, lower is
    better for Hop Count, Link Latency, ETX and Fanout Ratio.  For Node
    Energy or Throughput, higher is better.

    An example of using such a single aggregated metric is optimizing
    routing for node energy.  The Node Energy metric (E-E field) is

Vasseur, et al.           Expires March 9, 2011                [Page 25]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    aggregated along paths with an explicit min function (A field), and
    the best path is selected through an implied Max function because the
    metric is Energy.

    When the DAG Metric Container contains several aggregated metrics,
    they are to be used as tie-breakers according to their precedence
    defined by their Prec field values.

    An example of such use of multiple aggregated metrics is the
    following: Hop-Count as the primary criteria, LQL as the secondary
    criteria and Fanout Ratio as the ultimate tie-breaker.  In such a
    case, the Hop-Count, LQL and Fanout Ratio metric objects' Prec fields
    should bear strictly increasing values such as 0, 1 and 2,
    respectively.

9. IANA Considerations

    IANA is requested to establish a new top-level registry to contain
    all Routing Metric/Constraint objects codepoints and sub-registries.

    The allocation policy for each new registry is by IETF Consensus: new
    values are assigned through the IETF consensus process (see
    [RFC5226]).  Specifically, new assignments are made via RFCs approved
    by the IESG.  Typically, the IESG will seek input on prospective
    assignments from appropriate persons (e.g., a relevant Working Group
    if one exists).

9.1. Routing Metric/Constraint type

    IANA is requested to create a registry for Routing Metric/Constraint
    objects.  Each Routing Metric/Constraint object has a type value.

    Value     Meaning                          Reference
      1       Node State and Attribute      This document
      2       Node Energy                   This document
      3       Hop Count                     This document
      4       Link Throughput               This document
      5       Link Latency                  This document
      6       Link Quality Level            This document
      7       Link ETX                      This document
      8       Link Color                    This document
      9       Node Fanout Ratio             This document

Vasseur, et al.           Expires March 9, 2011                [Page 26]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

9.2. Routing Metric/Constraint common header

    IANA is requested to create a registry to manage the codespace of A

PC> s/A/the A/

    field of the Routing Metric/Constraint common header.

    Codespace of the A field (Routing Metric/Constraint common header)
     Value  Meaning                              Reference

       0    Routing metric is additive           This document
       1    Routing metric reports a maximum     This document
       2    Routing metric reports a minimum     This document
       3    Routing metric is multiplicative     This document

    IANA is requested to create a registry to manage the Flag field of
    the Routing Metric/Constraint common header.

    New bit numbers may be allocated only by an IETF Consensus action.
    Each bit should be tracked with the following qualities:

    o  Bit number

    o  Capability Description

    o  Defining RFC

    Several bits are defined for the Routing Metric/Constraint common
    header in this document.  The following values have been assigned:

    Codespace of the Flag field (Routing Metric/Constraint common header)
      Bit      Description              Reference

       12-15   Precedence               This document
       10-11   Additive/Max/Min/Multi   This document
       9       Recorded/Aggregated      This document
       8       Optional Constraint      This document
       7       Constraint/metric        This document

PC> s/metric/Metric

       6       P (Partial)              This document

9.3. NSA object

    IANA is requested to create a registry to manage the codespace of the
    Flag field of the NSA object.

    New bit numbers may be allocated only by an IETF Consensus action.
    Each bit should be tracked with the following qualities:

    o  Bit number

Vasseur, et al.           Expires March 9, 2011                [Page 27]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    o  Capability Description

    o  Defining RFC

    Several bits are defined for the NSA object flag field in this
    document.  The following values have been assigned:

    Codespace of the Flag field (NSA object)
      Bit      Description              Reference

       14      Aggregator               This document
       15      Overloaded               This document

9.4. Hop-Count object

    IANA is requested to create a registry to manage the codespace of the
    Flag field of the Hop-count object.

    New bit numbers may be allocated only by an IETF Consensus action.
    Each bit should be tracked with the following qualities:

    o  Bit number

    o  Capability Description

    o  Defining RFC

    No Flag is currently defined.

10. Security considerations

    Routing metrics should be handled in a secure and trustful manner.
    For instance, a malicious node can not advertise falsely that it has
    good metrics for routing and belong to the established path to have a
    chance to intercept packets.  Since the routing metrics/constraints

PC> For instance, RPL should not allow a malicious node to falsely 
advertise that it has good metrics for routing, be added as a router for 
other nodes' traffic, and intercept packets.

    are carried within RPL message, the security routing mechanisms
    defined in [I-D.ietf-roll-rpl] applies here.

11. Acknowledgements

    The authors would like to acknowledge the contributions of Young Jae
    Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip
    Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru
    Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter,
    Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads
    Westergreen and Mukul Goyal for their review and valuable comments.

Vasseur, et al.           Expires March 9, 2011                [Page 28]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

12. References

12.1. Normative references

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

12.2. Informative references

    [I-D.ietf-roll-rpl]
               Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
               Protocol for Low power and Lossy Networks",
               draft-ietf-roll-rpl-11 (work in progress), July 2010.

    [I-D.ietf-roll-terminology]
               Vasseur, J., "Terminology in Low power And Lossy
               Networks", draft-ietf-roll-terminology-03 (work in
               progress), March 2010.

    [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
               dual environments", RFC 1195, December 1990.

    [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

    [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
               McManus, "Requirements for Traffic Engineering Over MPLS",
               RFC 2702, September 1999.

    [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

    [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
               (GMPLS) Signaling Functional Description", RFC 3471,
               January 2003.

    [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
               "Routing Requirements for Urban Low-Power and Lossy
               Networks", RFC 5548, May 2009.

    [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
               "Industrial Routing Requirements in Low-Power and Lossy
               Networks", RFC 5673, October 2009.

Vasseur, et al.           Expires March 9, 2011                [Page 29]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
               Routing Requirements in Low-Power and Lossy Networks",
               RFC 5826, April 2010.

    [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
               "Building Automation Routing Requirements in Low-Power and
               Lossy Networks", RFC 5867, June 2010.

Authors' Addresses

    JP Vasseur (editor)
    Cisco Systems, Inc
    11, Rue Camille Desmoulins
    Issy Les Moulineaux,   92782
    France

    Email: [email-masked]

    Mijeom Kim (editor)
    Corporate Technology Group, KT
    17 Woomyeon-dong, Seocho-gu
    Seoul,   137-792
    Korea

    Email: [email-masked]

    Kris Pister
    Dust Networks
    30695 Huntwood Ave.
    Hayward, CA  95544
    USA

    Email: [email-masked]

    Nicolas Dejean
    Coronis SAS
    Espace Concorde, 120 impasse JB Say
    Perols,   34470
    France

    Email: [email-masked]

Vasseur, et al.           Expires March 9, 2011                [Page 30]

Internet-Draft     draft-ietf-roll-routing-metrics-09     September 2010

    Dominique Barthel
    France Telecom Orange
    28 chemin du Vieux Chene, BP 98
    Meylan,   38243
    France

    Email: [email-masked]

Vasseur, et al.           Expires March 9, 2011                [Page 31]

Html markup produced by rfcmarkup 1.90, available from 
http://tools.ietf.org/tools/rfcmarkup/

---

From: Phoebus Chen <[email-masked]>
Date: Thu, 23 Sep 2010 15:56:26 +0200

I like this suggestion.  Specifying how to combine metrics in a separate 
container allows us to also advertise it within the DODAG configuration 
object when a node needs to know it, not every time a DIO with a DAG 
Metric Container is sent.  The way to combine metrics should change much 
more slowly (if ever) than the metrics, so there really isn't a need to 
send it each time.  This is particularly useful if we wish to introduce 
"weights" (or some other constants) when we combine different metrics... 
these weights will probably not change unless the network operator 
reconfigures them.

We just need to make sure the order of the metrics in the DAG Metric 
Container used by an Objective Function is fixed/known by all nodes 
joining an RPL Instance, so they can be combined correctly.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Sep 2010 10:57:33 +0200

On Sep 23, 2010, at 10:27, Joakim Eriksson wrote:

> metrics-container

... and do something like RFC 3320 to send around the mobile code that then combines the metrics :-)

Gruesse, Carsten

---

From: Joakim Eriksson <[email-masked]>
Date: Fri, 24 Sep 2010 17:37:31 +0200

Yes, well. Not mainly to enable mobile code, but a variety of
ways of specifying configurations. From very simplistic (just some
flags or so) to very sophisticated (such as mobile code).

Best regards,
-- Joakim Eriksson, SICS