idnits 2.17.00 (12 Aug 2021) /tmp/idnits21526/draft-ajunior-roll-energy-awareness-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 10, 2014) is 3053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6552' is mentioned on line 88, but not defined == Unused Reference: 'I-D.ietf-roll-applicability-ami' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 620, but no explicit reference was found in the text == Outdated reference: draft-ietf-roll-applicability-ami has been published as RFC 8036 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 == Outdated reference: draft-ietf-manet-olsrv2 has been published as RFC 7181 == Outdated reference: A later version (-16) exists of draft-ietf-manet-aodvv2-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group A. Junior 3 Internet-Draft R. Sofia 4 Intended status: Informational COPELABS, University Lusofona 5 Expires: July 13, 2014 January 10, 2014 7 Energy-awareness metrics global applicability guidelines 8 draft-ajunior-roll-energy-awareness-01 10 Abstract 12 This document describes a new set of energy-awareness metrics which 13 have been devised to be applicable to any multihop routing protocol 14 having in mind LLNs, including the Routing for Low Power and Lossy 15 Networks (RPL) protocol. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 13, 2014. 34 Copyright and License Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Energy-awareness Routing Metrics . . . . . . . . . . . . . . . 4 54 2.1. Energy Node Ranking: ENR . . . . . . . . . . . . . . . . . 4 55 2.2. Father-Son Association Ranking: Energy-awareness 56 Father-Son (EFS) . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Design Aspects . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Applicability of the Proposed Metrics . . . . . . . . . . . . . 5 59 3.1. RPL Applicability Guidelines . . . . . . . . . . . . . . . 5 60 3.1.1. Impact in Node Energy Object . . . . . . . . . . . . . 6 61 3.2. OLSR Applicability Guidelines . . . . . . . . . . . . . . . 6 62 3.2.1. Impact in HELLO Messages . . . . . . . . . . . . . . . 7 63 3.2.2. Impact in TC Messages . . . . . . . . . . . . . . . . . 7 64 3.2.3. OLSR Link Tuple . . . . . . . . . . . . . . . . . . . . 8 65 3.2.4 Routing Table . . . . . . . . . . . . . . . . . . . . . 8 66 3.2.5. MPR Selection . . . . . . . . . . . . . . . . . . . . . 9 67 3.3. AODV Applicability Guidelines . . . . . . . . . . . . . . . 9 68 3.3.1. Route Request (RREQ) Message Format . . . . . . . . . . 10 69 3.3.2. Route Reply (RREP) Message Format . . . . . . . . . . . 10 70 3.3.3. HELLO Message Format . . . . . . . . . . . . . . . . . 11 71 3.3.4. Route Selection . . . . . . . . . . . . . . . . . . . . 11 72 3.3.5. Routing Table . . . . . . . . . . . . . . . . . . . . . 12 73 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Low Power and Lossy Networks (LLNs) routing requirements have been 84 specified in [RFC5548], [RFC5673], [RFC5826], [RFC5867], and 85 [RFC6719]. Additional aspects concerning routing metrics and also 86 constrains in design are available in [RFC6551]. Path computation 87 algorithms for single metrics have already been proposed and used in 88 [RFC6552], and [RFC6719]. 90 Within the context of LLNs, we consider the specific case of User- 91 centric Networks (UCNs) [ULOOP], i.e., networks partially or 92 completely based on equipment that is owned and carried by regular 93 Internet end-users. Concrete examples of UCNs can be Wi-Fi networks 94 established on-the-fly after a disaster of some nature (e.g., 95 disaster networks); a municipality network where networking nodes are 96 provided by the Internet end-user, who is willing to share network 97 resources (e.g. Internet access; radio spectrum) at the exchange of 98 specific incentives. 100 The intention of this document is two-fold. Firstly, we describe 101 energy-awareness metrics that can be applied to any multihop protocol 102 currently being considered in LLNs. Secondly, we provide design 103 guidelines concerning the applicability of such metrics for the 104 specific case of RPL. 106 The effectiveness and performance validation of the metrics described 107 in this document is out of the scope of the document, but can be 108 found in detail in [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3]. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [RFC2119]. 116 This document makes use of the terminology defined in [I-D.ietf-roll- 117 terminology]. Moreover, this document defines the following terms, in 118 accordance with [RFC5835] terminology: 120 Optimal path: is defined as a path in the DAG that minimizes (or 121 maximizes, respectively) the Rank value between any given pair of 122 source-destination nodes, as well as its sub-paths. 124 Path weight: a value representing link or/and node characteristics of 125 a path. This definition coincides with "path cost" defined in 126 [RFC6719]. Path weight is used by RPL to compare different paths. 128 Idle mode: When a node is not receiving or transmitting, the node is 129 still listening to the shared medium (overhearing) and is said to be 130 in Idle mode. 132 Transmission mode: When a node is transmitting information. 134 Reception mode: When a node is receiving information. 136 Node lifetime: Corresponds to the period of time since a node becomes 137 active until the node is said to be dead, i.e., from a network 138 perspective, the node ceases to exist. 140 Network lifetime: Associated to the time period since a topology 141 becomes active, until the topology becomes disconnected, from a 142 destination reachability perspective. 144 Energy cost: The cost associated to the node or to the association 145 between two nodes which consider the energy parameters. 147 2. Energy-awareness Routing Metrics 149 This section describes the routing metrics proposed, from an 150 operational perspective. Conceptual aspects and validation of the 151 metrics, as well as concrete performance indicators can be found in 152 [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3]. 154 2.1. Energy Node Ranking: ENR 156 The Energy Node Ranking (ENR) metric is a node weight which ranks a 157 node in terms of its energy consumption stability. We explore the 158 fact that nodes may be in idle mode for a long time. Nodes that have 159 been in idle mode for a long period of time in the past and that 160 still have a reasonable large estimated lifetime are better 161 candidates to be elements in an optimal path. In other words, over 162 time we estimate how much of its lifetime has node i been in idle 163 mode, to then provide an estimate towards the node's future energy 164 expenditure, as this will for sure impact the node's lifetime. 166 Hence, we consider the total period in idle time T_Idle, over the 167 full lifetime expected for a specific node, which is given by the sum 168 of the elapsed time period T with the estimated lifetime of the node, 169 as provided in equation 1. The estimated lifetime C(i) consider the 170 ratio between residual energy and drain rate which can capture the 171 heterogeneous energy capability of nodes [J.J.GARCIA-LUNA-ACEVES]. 173 ENR(i) = (T - T_Idle)/(T * C(i)) (1) 175 2.2. Father-Son Association Ranking: Energy-awareness Father-Son (EFS) 177 Based on ENR, we consider a composition of the ENRs of both a father 178 and successor nodes (association between two nodes), as specified in 179 equation 2. 181 EFS(i,j) = ENR(i) * ENR(j) (2) 183 EFS provides a ranking which we believe is useful to assist the 184 routing algorithm to converge quickly in multipath environments, as 185 the selection on which successor to consider shall be made up from, 186 by the father node. The goal is, similarly to ENR, to improve the 187 network lifetime without disrupting the overall network operation. 188 Hence, the smaller EFS(i,j) is, the more likelihood a link has to 189 become part of a path. 191 2.3. Design Aspects 193 This section describes aspects concerning the applicability of the 194 metrics, e.g. messaging aspects. 196 The energy cost ranking (ENR or EFS) are recorded in reserved field 197 of control messages of any routing protocol occupying 16 bits. 199 0 1 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Energy Cost (ENR or EFS) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 3. Applicability of the Proposed Metrics 207 This section describes how the proposed metrics can be applied to the 208 most popular multihop routing protocols in LLNs. We start by RPL 209 applicability guidelines, to then consider OLSR (actually work in 210 progress OLSRv2 [OLSRv2]) as a concrete example of Link-state 211 approaches, and AODV (actually work in progress AODVv2 [AODVv2]) as a 212 concrete example of distance-vector approaches. 214 3.1. RPL Applicability Guidelines 216 In order to use the metrics described in this document on the Routing 217 Protocol for Low-Power and Lossy Networks (RPL), no changes or 218 adaptation to the protocol are needed. By separating the packet 219 processing and forwarding processes from the routing path selection, 220 RPL provides a very flexible way of using and incorporating different 221 metrics. 223 RPL operates upon the concept of Destination-Oriented Directed 224 Acyclic Graph (DODAG), where routes are calculated from all nodes to 225 a single destination in the topology (root node). Each node in the 226 topology has a Rank, that is basically a value that represents its 227 distance to the topology root. 229 According to specific LLNs applications, such routes are calculated 230 in order to achieve different objectives that may be desired (e.g. 231 minimize delay, maximize throughput, minimize energy usage), so 232 different Objective Functions (OF) may be defined. An OF defines how 233 routing metrics, constraints and related functions are used, in order 234 to define the route between the nodes towards a single destination in 235 the topology. That is, an OF, in conjunction with routing metrics and 236 constraints, allows for the selection of a DODAG to join (if there is 237 more than one), and a number of peers in that DODAG as parents (that 238 is, an ordered list of parents). The OF is also responsible to 239 compute the Rank of the node. 241 The [RFC6551] defines a very flexible mechanism for the advertisement 242 of routing metrics and constraints used by RPL, even though no OF is 243 presented. A high degree of flexibility is offered by that mechanism, 244 and a set of routing metrics and constraints are also described in 245 the document. 247 3.1.1. Impact on 249 In order to use the metrics described in this document, the Node 250 Energy object (NE), as defined in [RFC6551], can be used without the 251 need for any changes or adaptation. The NE structure is composed by a 252 set of flags (8 bits), and an 8-bits field (E_E) used for carrying 253 the value of the estimated energy. 255 0 1 256 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Flags |I| T |E| Energy Cost | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 To use the NE object with the metrics described in this document, the 262 value of ENR or EFS metrics should be placed in the E_E field, and 263 the flag 'E' (Estimation) should be set, indicating that a value for 264 the estimated energy is provided in the E_E field. The other flags of 265 the NE should be filled as defined in the standard. 267 3.2. OLSR Applicability Guidelines 269 The applicability of the proposed metrics does not imply significant 270 operation changes to OLSR standard as defined in [RFC3626]. The only 271 change required is the creation of a special field or considering the 272 Reserved field to hold the energy cost information of the nodes. This 273 information will be used as basis to calculate the nodes routing 274 tables, and must be stored in the neighbors information and in the 275 routing table. This section describes a few design guidelines to 276 apply the proposed metrics to OLSR. 278 3.2.1. Impact in 280 In OLSR, the HELLO messages are used mainly to conduct link sensing, 281 neighbor detection and MPR selection. Therefore, to inform the other 282 nodes about its energy-aware cost, a node sends ENR or EFS via HELLO 283 messages. The metrics can be sent in the Reserved field in the 284 beginning of the HELLO message body defined in the standard. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Energy Cost (ENR or EFS) | Htime | Willingness | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | ... | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 If the node is configured to use a node-based metric - ENR, then the 295 energy cost received via HELLO messages is enough to represent the 296 cost of the links towards those neighbors. If the node considers a 297 Father-Son composition such as EFS then the information received is 298 used to compute the final energy cost associated to the link based on 299 the neighbor's energy cost and its own. 301 An OLSR node uses TC messages to disseminate links between itself and 302 its neighbors. This information is spread throughout all the network, 303 and based on this information, each node can build its own network 304 topology. Furthermore, the topology information of each node is used 305 to calculate its routing table. 307 TCs messages are used to spread the energy cost of nodes in order to 308 compute the routing table using the Reserved field. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | ANSN | Reserved (Energy Cost) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Advertised Neighbor Main Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Advertised Neighbor Main Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ... | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 For each advertised link in the TC message, the Energy Cost can again 323 be carried in the Reserved field. 325 3.2.3. OLSR Link Tuple 327 An OLSR node stores a set of information about its neighbors. This 328 set of information, named "link tuple", is defined in [RFC3626] as 329 (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, 330 L_time), where L_local_iface_addr is the interface address of the 331 local node, L_neighbor_iface_addr is the interface address of the 332 neighbor node, L_SYM_time is the time until which the link is 333 considered symmetric, L_ASYM_time is the time until which the 334 neighbor interface is considered heard, and L_time specifies the time 335 at which the record expires. 337 In order to use the energy-aware metrics defined in this document, a 338 new field should be added to the link tuple. This extra field, named 339 "L_energy", stores the energy cost sent by the neighbor node in the 340 HELLO messages (in case of node-based metrics) or the calculated 341 energy cost related to the link towards that node (in case of 342 sucessor-based metrics). 344 When a node receives a HELLO message, the link set (set of link 345 tuples) is updated. If the node receives a HELLO message from a 346 neighbor node that does not exist in the link set, a new link tuple 347 is created. In both cases, the information carried in the Energy Cost 348 field of the HELLO message body must be considered. In case a link 349 tuple exists, the L_energy value should be updated; if the tuple is 350 created, the value of the L_energy field should be based on the 351 Energy Cost field of the HELLO message received. 353 3.2.4 Routing Table 355 Each OLSR node maintains a routing table with information which 356 allows it to route packets destined to other nodes in the network. As 357 defined in the OLSR standard, the routing table is composed by 358 entries with the following information: R_dest_addr, R_next_addr 359 R_dist, R_iface_addr, where R_dest_addr is the final destination, 360 R_next_addr is the next hop towards the destination, R_dist is the 361 distance in number of hops, and R_iface_addr is the address of the 362 local interface through which the node is reachable. 364 Using energy-aware metrics, the field R_dist no longer holds the 365 distance in terms of hops, but in terms of energy cost. Therefore, 366 the R_dist field holds the energy cost of the total path to reach 367 that specific destination. All the other fields remain without any 368 changes. 370 3.2.5. MPR Selection 372 The MPR selection criteria is also relevant in the contest of path 373 computation based on the proposed Energy Cost metrics. Therefore, one 374 simple approach (of many that can be designed) for selecting the MPRs 375 based on the energy cost of the neighboring nodes. 377 Basically, when choosing the MPR, a node should take into 378 consideration not only the number of 2-hop neighbors each of its 1- 379 hop neighbors has; it should also take into consideration the energy 380 cost of the neighbor nodes. Therefore, when there are more than one 381 1-hop neighbors covering the same number of uncovered 2-hop 382 neighbors, the one with the lowest energy cost weight to the current 383 node is selected as MPR. 385 3.3. AODV Applicability Guidelines 387 In contrast to link-state routing, distance-vector routing protocols 388 work by having each node sharing its routing table with its 389 neighbors. Routers using distance-vector protocol do not have 390 knowledge of the entire path to a destination. Instead, distance- 391 vector uses two key information: i) the direction in which or 392 interface to which a packet should be forwarded; and ii) the distance 393 from it to the final destination, where distance means number of 394 hops. 396 To use energy-aware metrics, the concept of distance based on number 397 of hops must be adapted to be based on a per-hop calculated energy 398 cost. Therefore, the routing table of distance-vector routing 399 protocols using energy-aware metrics does not hold the distance in 400 number of hops to the destination; it holds the energy cost 401 calculated for all the route from it to the destination node instead. 403 Energy-aware metrics can be applied to AODV without major changes. As 404 the optimal path is chosen reactively based on the hop-count of 405 request/reply messages, in order to use the energy cost to make a 406 decision on the more energy efficient route from source node to 407 destination node, the calculated energy cost value must be 408 transmitted from one node to another, during the route discovery 409 procedure. 411 The calculated energy cost, transmitted from node to node when 412 searching for a route, is a cumulative value that represents the 413 energy cost calculated for the path from the source until the current 414 node. 416 3.3.1. Route Request (RREQ) Message Format 418 When a route to a new destination node is required, the source node 419 broadcasts RREQ messages to its neighbors. Those messages are 420 broadcasted to other nodes throughout the network until one of them 421 eventually reaches the destination node. For energy-aware metrics, 422 the energy cost of the route is calculated as the RREQ message is re- 423 broadcasted; this information is carried in the RREQ messages, and 424 when those messages reach the destination, they carry the energy cost 425 of the entire route, from source to destination. 427 In order to carry the energy cost value, a slight change needs to be 428 applied to the RREQ message format. The space originally used for the 429 field Hop Count will be used for carrying the cumulative energy cost 430 calculated throughout the path. The Energy Cost field will take place 431 using the 8 bits previously used for the Hop Count value, and using 8 432 bits of the Reserved field. This change does not increase the packet 433 size, not increasing the routing control overhead in the network. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type |J|R|G|D|U| Res | Energy Cost | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | RREQ ID | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Destination IP Address | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Destination Sequence Number | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Originator IP Address | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Originator Sequence Number | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 As the RREQ is broadcasted by the nodes in the network, the Energy 452 Cost field is updated with the energy of the local node. When the 453 RREQ message reaches the destination node, the Energy Cost field will 454 have the energy cost for the entire path, from source node to 455 destination node. 457 3.3.2. Route Reply (RREP) Message Format 459 RREP messages are used when an intermediate node receives an RREQ 460 message, but it already knows a route to the destination node 461 specified in that message, or when an RREP message reaches the 462 destination node. In both cases, an RREP message is created and sent 463 back to the source node. 465 In order to transmit the information about the route energy cost back 466 to the source node, the RREP message must carry a cumulative energy 467 cost value, calculated throughout the path back to the source. This 468 information is carried in the field Energy Cost, added to the RREP 469 message structure, taking place of the Hop Count field of 8 bits, and 470 taking 8 bits from the Reserved field. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type |R|A|Prefix Sz| Energy Cost | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Destination IP address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Destination Sequence Number | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Originator IP address | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Lifetime | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 As the RREP message is sent back to the node which originated the 487 RREQ message, the Energy Cost field accumulates the energy cost 488 calculated throughout the path. Thus, when the RREP message reaches 489 the originator node, the Energy Cost represents the total energy cost 490 of the path from destination back to the originator. 492 3.3.3. HELLO Message Format 494 In AODV, HELLO messages are used to offer connectivity information 495 and also for exchange the energy cost to the case of successor based 496 metric. HELLO messages are broadcasted locally having the same format 497 as RREP messages, with TTL = 1, the Hop Count field set to 0, and the 498 Destination IP Address set to its own IP address. For energy-aware 499 metrics, the HELLO message would have the format of the RREP message 500 described in subsection 3.3.2, and the Energy Cost field would carry 501 the energy cost of the node originating the message. 503 3.3.4. Route Selection 505 When a route to a new destination node is required, the source node 506 broadcasts RREQ messages to its neighbors. Those messages are usually 507 broadcasted by the neighbors to other nodes throughout the network 508 until one of them eventually reaches the destination node. When an 509 RREQ message reaches the destination (or an intermediate node that 510 has a route to the destination), the RREQ message is not broadcasted 511 anymore. Each intermediate node caches the information about the 512 source of the RREQ message, in order to route back to the originator. 514 Through this process, the originator node selects the shortest-path 515 based on energy cost field of the routing table to the desired 516 destination node. 518 3.3.5. Routing Table 520 According to [RFC3561], AODV uses the following fields with each 521 route table entry: Destination IP Address; Destination Sequence 522 Number; Valid Destination Sequence Number flag; Other state and 523 routing flags (e.g., valid, invalid, repairable, being repaired); 524 Network Interface; Hop Count (number of hops needed to reach 525 destination); Next Hop; List of Precursors; Lifetime (expiration or 526 deletion time of the route). 528 For the usage of energy-aware metrics, the field Hop Count is 529 replaced by a new field, named Energy Cost. This field holds the 530 energy cost calculated to reach the destination, through the Next Hop 531 specified. 533 4. Acknowledgments 535 This draft is supported by national fundings via Fundacao para 536 Ciencia e Tecnologia (FCT), in the context of the UCR project 537 PTDC/EEA-TEL/103637/2008. Thanks to Universidade Federal de Goias 538 (UFG/CAC) and Fundacao de Amparo a Pesquisa do Estado de Goias 539 (FAPEG). 541 5. Security Considerations 543 There are no new security implications related to this draft. 545 6. IANA Considerations 546 None. 548 7. References 550 7.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP14, RFC2119, March 1997. 556 7.2. Informative References 558 [RFC3626] Clausen, T., Jacquet, P. (Ed.), "Optimized Link State 559 Routing Protocol (OLSR)", RFC3626, October 2003. 561 [RFC3561] Perkins, C., Belding-Royer, E., Das, S., "Ad hoc On-Demand 562 Distance Vector (AODV) Routing", RFC3561, July 2003. 564 [RFC5548] M. Dohler, T. Watteyne, T. Winter, D. Barthel, "Routing 565 Requirements for Urban Low-Power and Lossy Networks", RFC 566 5548, May 2009. 568 [RFC5673] K. Pister, P. Thubert, S. Dwars, T. Phinney, "Industrial 569 Routing Requirements in Low-Power and Lossy Networks", RFC 570 5673, October 2009. 572 [RFC5826] A. Brandt, J. Buron, G. Porcu, "Home Automation Routing 573 Requirements in Low-Power and Lossy Networks", RFC 5826, 574 April 2010. 576 [RFC5867] J. Martocci, P. De Mil, N. Riou, W. Vermeylen, "Building 577 Automation Routing Requirements in Low-Power and Lossy 578 Networks", RFC 5867, June 2010. 580 [I-D.ietf-roll-applicability-ami] D. Popa, M. Gillmore, L. Toutain, 581 J. Hui, R. Ruben, K. Monden, "Applicability Statement for 582 the Routing Protocol for Low Power and Lossy Networks 583 (RPL) in AMI Networks", draft-ietf-roll-applicability-ami- 584 07, July, 2013. 586 [RFC6550] T.Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. 587 Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander, 588 "RPL: IPv6 Routing Protocol for Low-Power and Lossy 589 Networks," RFC 6550, March 2012. 591 [RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel, 592 "Routing Metrics Used for Path Calculation in Low-Power 593 and Lossy Networks", RFC 6551, March 2012. 595 [RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel, 596 "Routing Metrics Used for Path Calculation in Low-Power 597 and Lossy Networks", RFC 6551, March 2012. 599 [RFC6719] O. Gnawali, P. Levis, "The Minimum Rank with Hysteresis 600 Objective Function", RFC 6719, September 2012. 602 [ULOOP] "ULOOP: User-centric Wireless Local-Loop," EU IST FP7 Project 603 (Grant 257418). 605 [AJUNIOR1] A. Junior, R. Sofia, and A. Costa, "Energy-awareness 606 metrics for multihop wireless user-centric routing" in The 607 2012 International Conference on Wireless Networks 608 (ICWN'12), July 2012. 610 [AJUNIOR2] A. Junior, R. Sofia, and A. Costa, "Energy-efficient 611 heuristics for multihop routing in user-centric 612 environments" in 12th International Conference on Next 613 Generation Wired/Wireless Networking (NEW2AN), August 614 2012. 616 [AJUNIOR3] A. Junior, R. Sofia, and A. Costa, "Energy-awareness in 617 Multihop Routing" in 2012 IFIP Wireless Days conference 618 (WD'12), November 2012. 620 [I-D.ietf-roll-terminology] JP. Vasseur, "Terminology in Low power 621 And Lossy Networks", draft-ietf-roll-terminology-13.txt, 622 September 30, 2013. 624 [RFC5835] A. Morton, S. Van den Berghe, "Framework for Metric 625 Composition", RFC 5835, April 2010. 627 [J.J.GARCIA-LUNA-ACEVES] D. Kim, J. J. Garcia-Luna-Aceves, K. 628 Obraczka, J.-C. Cano, and P. Manzoni, "Routing mechanisms 629 for mobile ad hoc networks based on the energy drain 630 rate," IEEE Transactions on Mobile Computing, vol. 2, no. 631 2, pp. 161-173, 2003. 633 [OLSRv2] T. Clausen, C. Dearlove, P. Jacquet, U. Herberg, "The 634 Optimized Link State Routing Protocol version 2", draft- 635 ietf-manet-olsrv2-19, March 23, 2013. 637 [AODVv2] C. Perkins, S. Ratliff, J. Dowdell, "Dynamic MANET On-demand 638 (AODVv2) Routing", draft-ietf-manet-aodvv2-02, July 15, 639 2013. 641 Authors' Addresses 643 Antonio Junior 644 COPELABS, University Lusofona 645 Building U, 1st Floor 646 Campo Grande, 376 647 1749-024 Lisboa - Portugal 648 Email: antoniocojr@gmail.com 650 Rute Sofia 651 COPELABS, University Lusofona 652 Building U, 1st Floor 653 Campo Grande, 376 654 1749-024 Lisboa - Portugal 655 Email: rute.sofia@ulusofona.pt