ROLL Working Group A. Junior Internet-Draft R. Sofia Intended status: Informational SITILabs, University Lusofona Expires: January 12, 2014 July 11, 2013 Energy-awareness metrics global applicability guidelines draft-ajunior-roll-energy-awareness-00 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 January 12, 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 January 12, 2014 [Page 1] Internet-Draft Energy-awareness metrics July 11, 2013 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 January 12, 2014 [Page 2] Internet-Draft Energy-awareness metrics July 11, 2013 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. Idle mode: When a node is not receiving or transmitting, the node is A. Junior, R. Sofia Expires January 12, 2014 [Page 3] Internet-Draft Energy-awareness metrics July 11, 2013 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) 2.2. Father-Son Association Ranking: Energy-awareness Father-Son (EFS) A. Junior, R. Sofia Expires January 12, 2014 [Page 4] Internet-Draft Energy-awareness metrics July 11, 2013 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. Using Energy Aware Metric with RPL 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. RPL have a metric container to hold the values, hence the metric is a provisioned parameter which does not need to be signaled in the protocol anywhere. A. Junior, R. Sofia Expires January 12, 2014 [Page 5] Internet-Draft Energy-awareness metrics July 11, 2013 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. [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 in Node Energy 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. Using Energy Aware Metric with OLSR 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 January 12, 2014 [Page 6] Internet-Draft Energy-awareness metrics July 11, 2013 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 HELLO Messages 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. 3.2.2. Impact in TC Messages 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 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 January 12, 2014 [Page 7] Internet-Draft Energy-awareness metrics July 11, 2013 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 entries with the following information: R_dest_addr, R_next_addr R_dist, R_iface_addr, where R_dest_addr is the final destination, A. Junior, R. Sofia Expires January 12, 2014 [Page 8] Internet-Draft Energy-awareness metrics July 11, 2013 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. Using Energy Aware Metric with AODV 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 decision on the more energy efficient route from source node to destination node, the calculated energy cost value must be A. Junior, R. Sofia Expires January 12, 2014 [Page 9] Internet-Draft Energy-awareness metrics July 11, 2013 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 have the energy cost for the entire path, from source node to destination node. A. Junior, R. Sofia Expires January 12, 2014 [Page 10] Internet-Draft Energy-awareness metrics July 11, 2013 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 the energy cost of the node originating the message. 3.3.4. Route Selection A. Junior, R. Sofia Expires January 12, 2014 [Page 11] Internet-Draft Energy-awareness metrics July 11, 2013 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 have a 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. 5. Security Considerations There are no new security implications related to this draft. 6. IANA Considerations None. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate A. Junior, R. Sofia Expires January 12, 2014 [Page 12] Internet-Draft Energy-awareness metrics July 11, 2013 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, J. Jetcheva, N. Dejean, R. Salazar, J. Hui, K. Monden, "Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks", draft-ietf-roll-applicability-ami- 06, May 1, 2012. [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 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. A. Junior, R. Sofia Expires January 12, 2014 [Page 13] Internet-Draft Energy-awareness metrics July 11, 2013 [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-12.txt, March 11, 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-00, March 12, 2013. Authors' Addresses Antonio Junior SITILabs, University Lusofona Building U, 1st Floor Campo Grande, 376 1749-024 Lisboa - Portugal Email: antoniocojr@gmail.com A. Junior, R. Sofia Expires January 12, 2014 [Page 14] Internet-Draft Energy-awareness metrics July 11, 2013 Rute Sofia SITILabs, University Lusofona Building U, 1st Floor Campo Grande, 376 1749-024 Lisboa - Portugal Email: rute.sofia@ulusofona.pt A. Junior, R. Sofia Expires January 12, 2014 [Page 15]