[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ROLL Working Group                                             A. Junior
Internet-Draft                                                  R. Sofia
Intended status: Informational             COPELABS, University Lusofona
Expires: July 13, 2014                                  January 10, 2014

        Energy-awareness metrics global applicability guidelines
                 draft-ajunior-roll-energy-awareness-01

Abstract

   This document describes a new set of energy-awareness metrics which
   have been devised to be applicable to any multihop routing protocol
   having in mind LLNs, including the Routing for Low Power and Lossy
   Networks (RPL) protocol.

Status of this Memo

   This Internet-Draft is submitted to IETF 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."

   This Internet-Draft will expire on July 13, 2014.

Copyright and License Notice

   Copyright (c) 2012 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.





A. Junior, R. Sofia      Expires July 13, 2014                  [Page 1]


Internet-Draft          Energy-awareness metrics        January 10, 2014


Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Energy-awareness Routing Metrics  . . . . . . . . . . . . . . .  4
     2.1. Energy Node Ranking: ENR  . . . . . . . . . . . . . . . . .  4
     2.2. Father-Son Association Ranking: Energy-awareness
          Father-Son (EFS)  . . . . . . . . . . . . . . . . . . . . .  5
     2.3. Design Aspects  . . . . . . . . . . . . . . . . . . . . . .  5
   3. Applicability of the Proposed Metrics . . . . . . . . . . . . .  5
     3.1. RPL Applicability Guidelines  . . . . . . . . . . . . . . .  5
       3.1.1. Impact in Node Energy Object  . . . . . . . . . . . . .  6
     3.2. OLSR Applicability Guidelines . . . . . . . . . . . . . . .  6
       3.2.1. Impact in HELLO Messages  . . . . . . . . . . . . . . .  7
       3.2.2. Impact in TC Messages . . . . . . . . . . . . . . . . .  7
       3.2.3. OLSR Link Tuple . . . . . . . . . . . . . . . . . . . .  8
       3.2.4 Routing Table  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.5. MPR Selection . . . . . . . . . . . . . . . . . . . . .  9
     3.3. AODV Applicability Guidelines . . . . . . . . . . . . . . .  9
       3.3.1. Route Request (RREQ) Message Format . . . . . . . . . . 10
       3.3.2. Route Reply (RREP) Message Format . . . . . . . . . . . 10
       3.3.3. HELLO Message Format  . . . . . . . . . . . . . . . . . 11
       3.3.4. Route Selection . . . . . . . . . . . . . . . . . . . . 11
       3.3.5. Routing Table . . . . . . . . . . . . . . . . . . . . . 12
   4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




















A. Junior, R. Sofia      Expires July 13, 2014                  [Page 2]


Internet-Draft          Energy-awareness metrics        January 10, 2014


1. Introduction

   Low Power and Lossy Networks (LLNs) routing requirements have been
   specified in [RFC5548], [RFC5673], [RFC5826], [RFC5867], and
   [RFC6719]. Additional aspects concerning routing metrics and also
   constrains in design are available in [RFC6551]. Path computation
   algorithms for single metrics have already been proposed and used in
   [RFC6552], and [RFC6719].

   Within the context of LLNs, we consider the specific case of User-
   centric Networks (UCNs) [ULOOP], i.e., networks partially or
   completely based on equipment that is owned and carried by regular
   Internet end-users. Concrete examples of UCNs can be Wi-Fi networks
   established on-the-fly after a disaster of some nature (e.g.,
   disaster networks); a municipality network where networking nodes are
   provided by the Internet end-user, who is willing to share network
   resources (e.g. Internet access; radio spectrum) at the exchange of
   specific incentives.

   The intention of this document is two-fold. Firstly, we describe
   energy-awareness metrics that can be applied to any multihop protocol
   currently being considered in LLNs. Secondly, we provide design
   guidelines concerning the applicability of such metrics for the
   specific case of RPL.

   The effectiveness and performance validation of the metrics described
   in this document is out of the scope of the document, but can be
   found in detail in [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3].

1.1. Terminology

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

   This document makes use of the terminology defined in [I-D.ietf-roll-
   terminology]. Moreover, this document defines the following terms, in
   accordance with [RFC5835] terminology:

   Optimal path: is defined as a path in the DAG that minimizes (or
   maximizes, respectively) the Rank value between any given pair of
   source-destination nodes, as well as its sub-paths.

   Path weight: a value representing link or/and node characteristics of
   a path. This definition coincides with "path cost" defined in
   [RFC6719]. Path weight is used by RPL to compare different paths.





A. Junior, R. Sofia      Expires July 13, 2014                  [Page 3]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   Idle mode: When a node is not receiving or transmitting, the node is
   still listening to the shared medium (overhearing) and is said to be
   in Idle mode.

   Transmission mode: When a node is transmitting information.

   Reception mode: When a node is receiving information.

   Node lifetime: Corresponds to the period of time since a node becomes
   active until the node is said to be dead, i.e., from a network
   perspective, the node ceases to exist.

   Network lifetime: Associated to the time period since a topology
   becomes active, until the topology becomes disconnected, from a
   destination reachability perspective.

   Energy cost: The cost associated to the node or to the association
   between two nodes which consider the energy parameters.

2. Energy-awareness Routing Metrics

   This section describes the routing metrics proposed, from an
   operational perspective. Conceptual aspects and validation of the
   metrics, as well as concrete performance indicators can be found in
   [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3].

2.1. Energy Node Ranking: ENR

   The Energy Node Ranking (ENR) metric is a node weight which ranks a
   node in terms of its energy consumption stability. We explore the
   fact that nodes may be in idle mode for a long time. Nodes that have
   been in idle mode for a long period of time in the past and that
   still have a reasonable large estimated lifetime are better
   candidates to be elements in an optimal path. In other words, over
   time we estimate how much of its lifetime has node i been in idle
   mode, to then provide an estimate towards the node's future energy
   expenditure, as this will for sure impact the node's lifetime.

   Hence, we consider the total period in idle time T_Idle, over the
   full lifetime expected for a specific node, which is given by the sum
   of the elapsed time period T with the estimated lifetime of the node,
   as provided in equation 1. The estimated lifetime C(i) consider the
   ratio between residual energy and drain rate which can capture the
   heterogeneous energy capability of nodes [J.J.GARCIA-LUNA-ACEVES].


               ENR(i) = (T - T_Idle)/(T * C(i))    (1)




A. Junior, R. Sofia      Expires July 13, 2014                  [Page 4]


Internet-Draft          Energy-awareness metrics        January 10, 2014


2.2. Father-Son Association Ranking: Energy-awareness Father-Son (EFS)

   Based on ENR, we consider a composition of the ENRs of both a father
   and successor nodes (association between two nodes), as specified in
   equation 2.

               EFS(i,j) = ENR(i) * ENR(j)    (2)

   EFS provides a ranking which we believe is useful to assist the
   routing algorithm to converge quickly in multipath environments, as
   the selection on which successor to consider shall be made up from,
   by the father node. The goal is, similarly to ENR, to improve the
   network lifetime without disrupting the overall network operation.
   Hence, the smaller EFS(i,j) is, the more likelihood a link has to
   become part of a path.

2.3. Design Aspects

   This section describes aspects concerning the applicability of the
   metrics, e.g. messaging aspects.

   The energy cost ranking (ENR or EFS) are recorded in reserved field
   of control messages of any routing protocol occupying 16 bits.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Energy Cost (ENR or EFS)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Applicability of the Proposed Metrics

   This section describes how the proposed metrics can be applied to the
   most popular multihop routing protocols in LLNs. We start by RPL
   applicability guidelines, to then consider OLSR (actually work in
   progress OLSRv2 [OLSRv2]) as a concrete example of Link-state
   approaches, and AODV (actually work in progress AODVv2 [AODVv2]) as a
   concrete example of distance-vector approaches.

3.1. RPL Applicability Guidelines

   In order to use the metrics described in this document on the Routing
   Protocol for Low-Power and Lossy Networks (RPL), no changes or
   adaptation to the protocol are needed. By separating the packet
   processing and forwarding processes from the routing path selection,
   RPL provides a very flexible way of using and incorporating different
   metrics.




A. Junior, R. Sofia      Expires July 13, 2014                  [Page 5]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   RPL operates upon the concept of Destination-Oriented Directed
   Acyclic Graph (DODAG), where routes are calculated from all nodes to
   a single destination in the topology (root node). Each node in the
   topology has a Rank, that is basically a value that represents its
   distance to the topology root.

   According to specific LLNs applications, such routes are calculated
   in order to achieve different objectives that may be desired (e.g.
   minimize delay, maximize throughput, minimize energy usage), so
   different Objective Functions (OF) may be defined. An OF defines how
   routing metrics, constraints and related functions are used, in order
   to define the route between the nodes towards a single destination in
   the topology. That is, an OF, in conjunction with routing metrics and
   constraints, allows for the selection of a DODAG to join (if there is
   more than one), and a number of peers in that DODAG as parents (that
   is, an ordered list of parents). The OF is also responsible to
   compute the Rank of the node.

   The [RFC6551] defines a very flexible mechanism for the advertisement
   of routing metrics and constraints used by RPL, even though no OF is
   presented. A high degree of flexibility is offered by that mechanism,
   and a set of routing metrics and constraints are also described in
   the document.

3.1.1. Impact on <object>

   In order to use the metrics described in this document, the Node
   Energy object (NE), as defined in [RFC6551], can be used without the
   need for any changes or adaptation. The NE structure is composed by a
   set of flags (8 bits), and an 8-bits field (E_E) used for carrying
   the value of the estimated energy.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags |I| T |E|  Energy Cost    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   To use the NE object with the metrics described in this document, the
   value of ENR or EFS metrics should be placed in the E_E field, and
   the flag 'E' (Estimation) should be set, indicating that a value for
   the estimated energy is provided in the E_E field. The other flags of
   the NE should be filled as defined in the standard.

3.2. OLSR Applicability Guidelines

   The applicability of the proposed metrics does not imply significant
   operation changes to OLSR standard as defined in [RFC3626]. The only



A. Junior, R. Sofia      Expires July 13, 2014                  [Page 6]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   change required is the creation of a special field or considering the
   Reserved field to hold the energy cost information of the nodes. This
   information will be used as basis to calculate the nodes routing
   tables, and must be stored in the neighbors information and in the
   routing table. This section describes a few design guidelines to
   apply the proposed metrics to OLSR.

3.2.1. Impact in <scope/context>

   In OLSR, the HELLO messages are used mainly to conduct link sensing,
   neighbor detection and MPR selection. Therefore, to inform the other
   nodes about its energy-aware cost, a node sends ENR or EFS via HELLO
   messages. The metrics can be sent in the Reserved field in the
   beginning of the HELLO message body defined in the standard.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Energy Cost (ENR or EFS)    |     Htime     |  Willingness  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the node is configured to use a node-based metric - ENR, then the
   energy cost received via HELLO messages is enough to represent the
   cost of the links towards those neighbors. If the node considers a
   Father-Son composition such as EFS then the information received is
   used to compute the final energy cost associated to the link based on
   the neighbor's energy cost and its own.

   An OLSR node uses TC messages to disseminate links between itself and
   its neighbors. This information is spread throughout all the network,
   and based on this information, each node can build its own network
   topology. Furthermore, the topology information of each node is used
   to calculate its routing table.

   TCs messages are used to spread the energy cost of nodes in order to
   compute the routing table using the Reserved field.













A. Junior, R. Sofia      Expires July 13, 2014                  [Page 7]


Internet-Draft          Energy-awareness metrics        January 10, 2014


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ANSN             | Reserved  (Energy Cost)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Advertised Neighbor Main Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Advertised Neighbor Main Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                ...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For each advertised link in the TC message, the Energy Cost can again
   be carried in the Reserved field.

3.2.3. OLSR Link Tuple

   An OLSR node stores a set of information about its neighbors. This
   set of information, named "link tuple", is defined in [RFC3626] as
   (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time,
   L_time), where L_local_iface_addr is the interface address of the
   local node, L_neighbor_iface_addr is the interface address of the
   neighbor node, L_SYM_time is the time until which the link is
   considered symmetric, L_ASYM_time is the time until which the
   neighbor interface is considered heard, and L_time specifies the time
   at which the record expires.

   In order to use the energy-aware metrics defined in this document, a
   new field should be added to the link tuple. This extra field, named
   "L_energy", stores the energy cost sent by the neighbor node in the
   HELLO messages (in case of node-based metrics) or the calculated
   energy cost related to the link towards that node (in case of
   sucessor-based metrics).

   When a node receives a HELLO message, the link set (set of link
   tuples) is updated. If the node receives a HELLO message from a
   neighbor node that does not exist in the link set, a new link tuple
   is created. In both cases, the information carried in the Energy Cost
   field of the HELLO message body must be considered. In case a link
   tuple exists, the L_energy value should be updated; if the tuple is
   created, the value of the L_energy field should be based on the
   Energy Cost field of the HELLO message received.

3.2.4 Routing Table

   Each OLSR node maintains a routing table with information which
   allows it to route packets destined to other nodes in the network. As
   defined in the OLSR standard, the routing table is composed by



A. Junior, R. Sofia      Expires July 13, 2014                  [Page 8]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   entries with the following information: R_dest_addr, R_next_addr
   R_dist, R_iface_addr, where R_dest_addr is the final destination,
   R_next_addr is the next hop towards the destination, R_dist is the
   distance in number of hops, and R_iface_addr is the address of the
   local interface through which the node is reachable.

   Using energy-aware metrics, the field R_dist no longer holds the
   distance in terms of hops, but in terms of energy cost. Therefore,
   the R_dist field holds the energy cost of the total path to reach
   that specific destination. All the other fields remain without any
   changes.

3.2.5. MPR Selection

   The MPR selection criteria is also relevant in the contest of path
   computation based on the proposed Energy Cost metrics. Therefore, one
   simple approach (of many that can be designed) for selecting the MPRs
   based on the energy cost of the neighboring nodes.

   Basically, when choosing the MPR, a node should take into
   consideration not only the number of 2-hop neighbors each of its 1-
   hop neighbors has; it should also take into consideration the energy
   cost of the neighbor nodes. Therefore, when there are more than one
   1-hop neighbors covering the same number of uncovered 2-hop
   neighbors, the one with the lowest energy cost weight to the current
   node is selected as MPR.

3.3. AODV Applicability Guidelines

   In contrast to link-state routing, distance-vector routing protocols
   work by having each node sharing its routing table with its
   neighbors. Routers using distance-vector protocol do not have
   knowledge of the entire path to a destination. Instead, distance-
   vector uses two key information: i) the direction in which or
   interface to which a packet should be forwarded; and ii) the distance
   from it to the final destination, where distance means number of
   hops.

   To use energy-aware metrics, the concept of distance based on number
   of hops must be adapted to be based on a per-hop calculated energy
   cost. Therefore, the routing table of distance-vector routing
   protocols using energy-aware metrics does not hold the distance in
   number of hops to the destination; it holds the energy cost
   calculated for all the route from it to the destination node instead.

   Energy-aware metrics can be applied to AODV without major changes. As
   the optimal path is chosen reactively based on the hop-count of
   request/reply messages, in order to use the energy cost to make a



A. Junior, R. Sofia      Expires July 13, 2014                  [Page 9]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   decision on the more energy efficient route from source node to
   destination node, the calculated energy cost value must be
   transmitted from one node to another, during the route discovery
   procedure.

   The calculated energy cost, transmitted from node to node when
   searching for a route, is a cumulative value that represents the
   energy cost calculated for the path from the source until the current
   node.

3.3.1. Route Request (RREQ) Message Format

   When a route to a new destination node is required, the source node
   broadcasts RREQ messages to its neighbors. Those messages are
   broadcasted to other nodes throughout the network until one of them
   eventually reaches the destination node. For energy-aware metrics,
   the energy cost of the route is calculated as the RREQ message is re-
   broadcasted; this information is carried in the RREQ messages, and
   when those messages reach the destination, they carry the energy cost
   of the entire route, from source to destination.

   In order to carry the energy cost value, a slight change needs to be
   applied to the RREQ message format. The space originally used for the
   field Hop Count will be used for carrying the cumulative energy cost
   calculated throughout the path. The Energy Cost field will take place
   using the 8 bits previously used for the Hop Count value, and using 8
   bits of the Reserved field. This change does not increase the packet
   size, not increasing the routing control overhead in the network.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |J|R|G|D|U| Res |          Energy Cost          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            RREQ ID                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination IP Address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Destination Sequence Number                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Originator IP Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Originator Sequence Number                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As the RREQ is broadcasted by the nodes in the network, the Energy
   Cost field is updated with the energy of the local node. When the
   RREQ message reaches the destination node, the Energy Cost field will



A. Junior, R. Sofia      Expires July 13, 2014                 [Page 10]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   have the energy cost for the entire path, from source node to
   destination node.


   3.3.2. Route Reply (RREP) Message Format

   RREP messages are used when an intermediate node receives an RREQ
   message, but it already knows a route to the destination node
   specified in that message, or when an RREP message reaches the
   destination node. In both cases, an RREP message is created and sent
   back to the source node.

   In order to transmit the information about the route energy cost back
   to the source node, the RREP message must carry a cumulative energy
   cost value, calculated throughout the path back to the source. This
   information is carried in the field Energy Cost, added to the RREP
   message structure, taking place of the Hop Count field of 8 bits, and
   taking 8 bits from the Reserved field.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |R|A|Prefix Sz|          Energy Cost            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination IP address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Originator IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As the RREP message is sent back to the node which originated the
   RREQ message, the Energy Cost field accumulates the energy cost
   calculated throughout the path. Thus, when the RREP message reaches
   the originator node, the Energy Cost represents the total energy cost
   of the path from destination back to the originator.

3.3.3. HELLO Message Format

   In AODV, HELLO messages are used to offer connectivity information
   and also for exchange the energy cost to the case of successor based
   metric. HELLO messages are broadcasted locally having the same format
   as RREP messages, with TTL = 1, the Hop Count field set to 0, and the
   Destination IP Address set to its own IP address. For energy-aware
   metrics, the HELLO message would have the format of the RREP message
   described in subsection 3.3.2, and the Energy Cost field would carry



A. Junior, R. Sofia      Expires July 13, 2014                 [Page 11]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   the energy cost of the node originating the message.



3.3.4. Route Selection


   When a route to a new destination node is required, the source node
   broadcasts RREQ messages to its neighbors. Those messages are usually
   broadcasted by the neighbors to other nodes throughout the network
   until one of them eventually reaches the destination node. When an
   RREQ message reaches the destination (or an intermediate node that
   has a route to the destination), the RREQ message is not broadcasted
   anymore. Each intermediate node caches the information about the
   source of the RREQ message, in order to route back to the originator.

   Through this process, the originator node selects the shortest-path
   based on energy cost field of the routing table to the desired
   destination node.

3.3.5. Routing Table

   According to [RFC3561], AODV uses the following fields with each
   route table entry: Destination IP Address; Destination Sequence
   Number; Valid Destination Sequence Number flag; Other state and
   routing flags (e.g., valid, invalid, repairable, being repaired);
   Network Interface; Hop Count (number of hops needed to reach
   destination); Next Hop; List of Precursors; Lifetime (expiration or
   deletion time of the route).

   For the usage of energy-aware metrics, the field Hop Count is
   replaced by a new field, named Energy Cost. This field holds the
   energy cost calculated to reach the destination, through the Next Hop
   specified.

4. Acknowledgments

   This draft is supported by national fundings via Fundacao para
   Ciencia e Tecnologia (FCT), in the context of the UCR project
   PTDC/EEA-TEL/103637/2008. Thanks to Universidade Federal de Goias
   (UFG/CAC) and Fundacao de Amparo a Pesquisa do Estado de Goias
   (FAPEG).

5. Security Considerations

   There are no new security implications related to this draft.

6. IANA Considerations



A. Junior, R. Sofia      Expires July 13, 2014                 [Page 12]


Internet-Draft          Energy-awareness metrics        January 10, 2014


   None.

7.  References

7.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

              Requirement Levels", BCP14, RFC2119, March 1997.

7.2.  Informative References


   [RFC3626] Clausen, T., Jacquet, P. (Ed.), "Optimized Link State
              Routing Protocol (OLSR)", RFC3626, October 2003.

   [RFC3561] Perkins, C., Belding-Royer, E., Das, S., "Ad hoc On-Demand
              Distance Vector (AODV) Routing", RFC3561, July 2003.

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

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

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

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

   [I-D.ietf-roll-applicability-ami] D. Popa, M. Gillmore, L. Toutain,
              J. Hui, R. Ruben, K. Monden, "Applicability Statement for
              the Routing Protocol for Low Power and Lossy Networks
              (RPL) in AMI Networks", draft-ietf-roll-applicability-ami-
              07, July, 2013.

   [RFC6550] T.Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P.
              Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander,
              "RPL: IPv6 Routing Protocol for Low-Power and Lossy
              Networks," RFC 6550, March 2012.

   [RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel,
              "Routing Metrics Used for Path Calculation in Low-Power



A. Junior, R. Sofia      Expires July 13, 2014                 [Page 13]


Internet-Draft          Energy-awareness metrics        January 10, 2014


              and Lossy Networks", RFC 6551, March 2012.

   [RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel,
              "Routing Metrics Used for Path Calculation in Low-Power
              and Lossy Networks", RFC 6551, March 2012.

   [RFC6719] O. Gnawali, P. Levis, "The Minimum Rank with Hysteresis
              Objective Function", RFC 6719, September 2012.

   [ULOOP] "ULOOP: User-centric Wireless Local-Loop," EU IST FP7 Project
              (Grant 257418).

   [AJUNIOR1] A. Junior, R. Sofia, and A. Costa, "Energy-awareness
              metrics for multihop wireless user-centric routing" in The
              2012 International Conference on Wireless Networks
              (ICWN'12), July 2012.

   [AJUNIOR2] A. Junior, R. Sofia, and A. Costa, "Energy-efficient
              heuristics for multihop routing in user-centric
              environments" in 12th International Conference on Next
              Generation Wired/Wireless Networking (NEW2AN), August
              2012.

   [AJUNIOR3] A. Junior, R. Sofia, and A. Costa, "Energy-awareness in
              Multihop Routing" in 2012 IFIP Wireless Days conference
              (WD'12), November 2012.

   [I-D.ietf-roll-terminology] JP. Vasseur, "Terminology in Low power
              And Lossy Networks", draft-ietf-roll-terminology-13.txt,
              September 30, 2013.

   [RFC5835] A. Morton, S. Van den Berghe, "Framework for Metric
              Composition", RFC 5835, April 2010.

   [J.J.GARCIA-LUNA-ACEVES] D. Kim, J. J. Garcia-Luna-Aceves, K.
              Obraczka, J.-C. Cano, and P. Manzoni, "Routing mechanisms
              for mobile ad hoc networks based on the energy drain
              rate," IEEE Transactions on Mobile Computing, vol. 2, no.
              2, pp. 161-173, 2003.

   [OLSRv2] T. Clausen, C. Dearlove, P. Jacquet, U. Herberg, "The
              Optimized Link State Routing Protocol version 2", draft-
              ietf-manet-olsrv2-19, March 23, 2013.

   [AODVv2] C. Perkins, S. Ratliff, J. Dowdell, "Dynamic MANET On-demand
              (AODVv2) Routing", draft-ietf-manet-aodvv2-02, July 15,
              2013.




A. Junior, R. Sofia      Expires July 13, 2014                 [Page 14]


Internet-Draft          Energy-awareness metrics        January 10, 2014


Authors' Addresses

              Antonio Junior
              COPELABS, University Lusofona
              Building U, 1st Floor
              Campo Grande, 376
              1749-024 Lisboa - Portugal
              Email: antoniocojr@gmail.com


              Rute Sofia
              COPELABS, University Lusofona
              Building U, 1st Floor
              Campo Grande, 376
              1749-024 Lisboa - Portugal
              Email: rute.sofia@ulusofona.pt



































A. Junior, R. Sofia      Expires July 13, 2014                 [Page 15]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/