idnits 2.17.00 (12 Aug 2021) /tmp/idnits22089/draft-ajunior-energy-awareness-00.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 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (October 15, 2012) is 3505 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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 621, 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 (-26) exists of draft-ietf-manet-dymo-22 Summary: 0 errors (**), 0 flaws (~~), 12 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 Expires: April 15, 2013 SITI, University Lusofona 5 October 15, 2012 7 Energy-awareness metrics global applicability guidelines 8 draft-ajunior-energy-awareness-00 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 including the Routing for Low Power and Lossy Networks (RPL) 15 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 April 15, 2012. 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 These are environments that can be considered sub-set of MANETs, but 101 where two fundamental aspects require energy efficiency: self- 102 organization, and a highly dynamic roaming behavior of the nodes that 103 compose the network. 105 The intention of this document is two-fold. Firstly, we describe 106 energy-awareness metrics that can be applied to any multihop protocol 107 currently being considered in LLNs. Secondly, we provide design 108 guidelines concerning the applicability of such metrics for the 109 specific case of RPL. 111 The effectiveness and performance validation of the metrics described 112 in this document is out of the scope of the document, but can be 113 found in detail in [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3]. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC2119 [RFC2119]. 121 This document makes use of the terminology defined in [I-D.ietf-roll- 122 terminology]. Moreover, this document defines the following terms, in 123 accordance with [RFC5835] terminology: 125 Optimal path: is defined as a path in the DAG that minimizes (or 126 maximizes, respectively) the Rank value between any given pair of 127 source-destination nodes, as well as its sub-paths. 129 Path weight: a value representing link or/and node characteristics of 130 a path. This definition coincides with "path cost" defined in 131 [RFC6719]. Path weight is used by RPL to compare different paths. 133 Idle mode: When a node is not receiving or transmitting, the node is 134 still listening to the shared medium (overhearing) and is said to be 135 in Idle mode. 137 Transmission mode: When a node is transmitting information. 139 Reception mode: When a node is receiving information. 141 Node lifetime: Corresponds to the period of time since a node becomes 142 active until the node is said to be dead, i.e., from a network 143 perspective, the node ceases to exist. 145 Network lifetime: Associated to the time period since a topology 146 becomes active, until the topology becomes disconnected, from a 147 destination reachability perspective. 149 Energy cost: The cost associated to the node or to the association 150 between two nodes which consider the energy parameters. 152 2. Energy-awareness Routing Metrics 154 This section describes the routing metrics proposed, from an 155 operational perspective. Conceptual aspects and validation of the 156 metrics, as well as concrete performance indicators can be found in 157 [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3]. 159 2.1. Energy Node Ranking: ENR 161 The Energy Node Ranking (ENR) metric is a node weight which ranks a 162 node in terms of its energy consumption stability. We explore the 163 fact that nodes may be in idle mode for a long time. Nodes that have 164 been in idle mode for a long period of time in the past and that 165 still have a reasonable large estimated lifetime are better 166 candidates to be elements in an optimal path. In other words, over 167 time we estimate how much of its lifetime has node i been in idle 168 mode, to then provide an estimate towards the node's future energy 169 expenditure, as this will for sure impact the node's lifetime. Hence, 170 we consider the total period in idle time T_Idle, over the full 171 lifetime expected for a specific node, which is given by the sum of 172 the elapsed time period T with the estimated lifetime of the node, as 173 provided in equation 1. The estimated lifetime C(i) consider the 174 ratio between residual energy and drain rate which can capture the 175 heterogeneous energy capability of nodes [J.J.GARCIA-LUNA-ACEVES]. 177 ENR(i) = (T - T_Idle)/(T * C(i)) (1) 179 2.2. Father-Son Association Ranking: Energy-awareness Father-Son (EFS) 181 Based on ENR, we consider a composition of the ENRs of both a father 182 and successor nodes (association between two nodes), as specified in 183 equation 2. 185 EFS(i,j) = ENR(i) * ENR(j) (2) 187 EFS provides a ranking which we believe is useful to assist the 188 routing algorithm to converge quickly in multipath environments, as 189 the selection on which successor to consider shall be made up from, 190 by the father node. The goal is, similarly to ENR, to improve the 191 network lifetime without disrupting the overall network operation. 192 Hence, the smaller EFS(i,j) is, the more likelihood a link has to 193 become part of a path. 195 2.3. Design Aspects 197 This section describes aspects concerning the applicability of the 198 metrics, e.g. messaging aspects. 200 The energy cost ranking (ENR or EFS) are recorded in reserved field 201 of control messages of any routing protocol occupying 16 bits. 203 0 1 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Energy Cost (ENR or EFS) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 3. Applicability of the Proposed Metrics 211 This section describes how the proposed metrics can be applied to the 212 most popular multihop routing protocols in LLNs. We start by RPL 213 applicability guidelines, to then consider OLSR (actually work in 214 progress OLSRv2 [OLSRv2]) as a concrete example of Link-state 215 approaches, and AODV (actually work in progress AODVv2 [AODVv2]) as a 216 concrete example of distance-vector approaches. 218 3.1. RPL Applicability Guidelines 220 In order to use the metrics described in this document on the Routing 221 Protocol for Low-Power and Lossy Networks (RPL), no changes or 222 adaptation to the protocol are needed. By separating the packet 223 processing and forwarding processes from the routing path selection, 224 RPL provides a very flexible way of using and incorporating different 225 metrics. 227 RPL operates upon the concept of Destination-Oriented Directed 228 Acyclic Graph (DODAG), where routes are calculated from all nodes to 229 a single destination in the topology (root node). Each node in the 230 topology has a Rank, that is basically a value that represents its 231 distance to the topology root. 233 According to specific LLNs applications, such routes are calculated 234 in order to achieve different objectives that may be desired (e.g. 235 minimize delay, maximize throughput, minimize energy usage), so 236 different Objective Functions (OF) may be defined. An OF defines how 237 routing metrics, constraints and related functions are used, in order 238 to define the route between the nodes towards a single destination in 239 the topology. That is, an OF, in conjunction with routing metrics and 240 constraints, allows for the selection of a DODAG to join (if there is 241 more than one), and a number of peers in that DODAG as parents (that 242 is, an ordered list of parents). The OF is also responsible to 243 compute the Rank of the node. 245 [RFC6551] defines a very flexible mechanism for the advertisement of 246 routing metrics and constraints used by RPL, even though no OF is 247 presented. A high degree of flexibility is offered by that mechanism, 248 and a set of routing metrics and constraints are also described in 249 the document. 251 3.1.1. Impact in Node Energy Object 253 In order to use the metrics described in this document, the Node 254 Energy object (NE), as defined in [RFC6551], can be used without the 255 need for any changes or adaptation. The NE structure is composed by a 256 set of flags (8 bits), and an 8-bits field (E_E) used for carrying 257 the value of the estimated energy. 259 0 1 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Flags |I| T |E| Energy Cost | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 To use the NE object with the metrics described in this document, the 266 value of ENR or EFS metrics should be placed in the E_E field, and 267 the flag 'E' (Estimation) should be set, indicating that a value for 268 the estimated energy is provided in the E_E field. The other flags of 269 the NE should be filled as defined in the standard. 271 3.2. OLSR Applicability Guidelines 272 The applicability of the proposed metrics does not imply significant 273 operation changes to OLSR standard as defined in [RFC3626]. The only 274 change required is the creation of a special field or considering the 275 Reserved field to hold the energy cost information of the nodes. This 276 information will be used as basis to calculate the nodes routing 277 tables, and must be stored in the neighbors information and in the 278 routing table. This section describes a few design guidelines to 279 apply the proposed metrics to OLSR. 281 3.2.1. Impact in HELLO Messages 283 In OLSR, the HELLO messages are used mainly to conduct link sensing, 284 neighbor detection and MPR selection. Therefore, to inform the other 285 nodes about its energy-aware cost, a node sends ENR or EFS via HELLO 286 messages. The metrics can be sent in the Reserved field in the 287 beginning of the HELLO message body defined in the standard. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Energy Cost (ENR or EFS) | Htime | Willingness | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | ... | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 If the node is configured to use a node-based metric - ENR, then the 298 energy cost received via HELLO messages is enough to represent the 299 cost of the links towards those neighbors. If the node considers a 300 Father-Son composition such as EFS then the information received is 301 used to compute the final energy cost associated to the link based on 302 the neighbor's energy cost and its own. 304 3.2.2. Impact in TC Messages 306 An OLSR node uses TC messages to disseminate links between itself and 307 its neighbors. This information is spread throughout all the network, 308 and based on this information, each node can build its own network 309 topology. Furthermore, the topology information of each node is used 310 to calculate its routing table. 312 TCs are used to spread the energy cost of nodes in order to compute 313 the routing table using the Reserved field. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | ANSN | Reserved (Energy Cost) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Advertised Neighbor Main Address | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Advertised Neighbor Main Address | 324 For each advertised link in the TC message, the Energy Cost can again 325 be carried in the Reserved field. 327 3.2.3. OLSR Link Tuple 329 An OLSR node stores a set of information about its neighbors. This 330 set of information, named "link tuple", is defined in [RFC3626] as 331 (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, 332 L_time), where L_local_iface_addr is the interface address of the 333 local node, L_neighbor_iface_addr is the interface address of the 334 neighbor node, L_SYM_time is the time until which the link is 335 considered symmetric, L_ASYM_time is the time until which the 336 neighbor interface is considered heard, and L_time specifies the time 337 at which the record expires. 339 In order to use the energy-aware metrics defined in this document, a 340 new field should be added to the link tuple. This extra field, named 341 "L_energy", stores the energy cost sent by the neighbor node in the 342 HELLO messages (in case of node-based metrics) or the calculated 343 energy cost related to the link towards that node (in case of 344 sucessor-based metrics). 346 When a node receives a HELLO message, the link set (set of link 347 tuples) is updated. If the node receives a HELLO message from a 348 neighbor node that does not exist in the link set, a new link tuple 349 is created. In both cases, the information carried in the Energy Cost 350 field of the HELLO message body must be considered. In case a link 351 tuple exists, the L_energy value should be updated; if the tuple is 352 created, the value of the L_energy field should be based on the 353 Energy Cost field of the HELLO message received. 355 3.2.4 Routing Table 357 Each OLSR node maintains a routing table with information which 358 allows it to route packets destined to other nodes in the network. As 359 defined in the OLSR standard, the routing table is composed by 360 entries with the following information: R_dest_addr, R_next_addr 361 R_dist, R_iface_addr, where R_dest_addr is the final destination, 362 R_next_addr is the next hop towards the destination, R_dist is the 363 distance in number of hops, and R_iface_addr is the address of the 364 local interface through which the node is reachable. 366 Using energy-aware metrics, the field R_dist no longer holds the 367 distance in terms of hops, but in terms of energy cost. Therefore, 368 the R_dist field holds the energy cost of the total path to reach 369 that specific destination. All the other fields remain without any 370 changes. 372 3.2.5. MPR Selection 374 The MPR selection criteria is also relevant in the contest of path 375 computation based on the proposed Energy Cost metrics. Therefore, one 376 simple approach (of many that can be designed) for selecting the MPRs 377 based on the energy cost of the neighboring nodes. 379 Basically, when choosing the MPR, a node should take into 380 consideration not only the number of 2-hop neighbors each of its 1- 381 hop neighbors has; it should also take into consideration the energy 382 cost of the neighbor nodes. Therefore, when there are more than one 383 1-hop neighbors covering the same number of uncovered 2-hop 384 neighbors, the one with the lowest energy cost weight to the current 385 node is selected as MPR. 387 3.3. AODV Applicability Guidelines 389 In contrast to link-state routing, distance-vector routing protocols 390 work by having each node sharing its routing table with its 391 neighbors. Routers using distance-vector protocol do not have 392 knowledge of the entire path to a destination. Instead, distance- 393 vector uses two key information: i) the direction in which or 394 interface to which a packet should be forwarded; and ii) the distance 395 from it to the final destination, where distance means number of 396 hops. 398 To use energy-aware metrics, the concept of distance based on number 399 of hops must be adapted to be based on a per-hop calculated energy 400 cost. Therefore, the routing table of distance-vector routing 401 protocols using energy-aware metrics does not hold the distance in 402 number of hops to the destination; it holds the energy cost 403 calculated for all the route from it to the destination node instead. 405 Energy-aware metrics can be applied to AODV without major changes. As 406 the optimal path is chosen reactively based on the hop-count of 407 request/reply messages, in order to use the energy cost to make a 408 decision on the more energy efficient route from source node to 409 destination node, the calculated energy cost value must be 410 transmitted from one node to another, during the route discovery 411 procedure. 413 The calculated energy cost, transmitted from node to node when 414 searching for a route, is a cumulative value that represents the 415 energy cost calculated for the path from the source until the current 416 node. 418 3.3.1. Route Request (RREQ) Message Format 420 When a route to a new destination node is required, the source node 421 broadcasts RREQ messages to its neighbors. Those messages are 422 broadcasted to other nodes throughout the network until one of them 423 eventually reaches the destination node. For energy-aware metrics, 424 the energy cost of the route is calculated as the RREQ message is re- 425 broadcasted; this information is carried in the RREQ messages, and 426 when those messages reach the destination, they carry the energy cost 427 of the entire route, from source to destination. 429 In order to carry the energy cost value, a slight change needs to be 430 applied to the RREQ message format. The space originally used for the 431 field Hop Count will be used for carrying the cumulative energy cost 432 calculated throughout the path. The Energy Cost field will take place 433 using the 8 bits previously used for the Hop Count value, and using 8 434 bits of the Reserved field. This change does not increase the packet 435 size, not increasing the routing control overhead in the network. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type |J|R|G|D|U| Res | Energy Cost | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | RREQ ID | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Destination IP Address | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Destination Sequence Number | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Originator IP Address | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Originator Sequence Number | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 As the RREQ is broadcasted by the nodes in the network, the Energy 454 Cost field is updated with the energy of the local node. When the 455 RREQ message reaches the destination node, the Energy Cost field will 456 have the energy cost for the entire path, from source node to 457 destination node. 459 3.3.2. Route Reply (RREP) Message Format 461 RREP messages are used when an intermediate node receives an RREQ 462 message, but it already knows a route to the destination node 463 specified in that message, or when an RREP message reaches the 464 destination node. In both cases, an RREP message is created and sent 465 back to the source node. 467 In order to transmit the information about the route energy cost back 468 to the source node, the RREP message must carry a cumulative energy 469 cost value, calculated throughout the path back to the source. This 470 information is carried in the field Energy Cost, added to the RREP 471 message structure, taking place of the Hop Count field of 8 bits, and 472 taking 8 bits from the Reserved field. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type |R|A|Prefix Sz| Energy Cost | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Destination IP address | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Destination Sequence Number | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Originator IP address | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Lifetime | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 As the RREP message is sent back to the node which originated the 489 RREQ message, the Energy Cost field accumulates the energy cost 490 calculated throughout the path. Thus, when the RREP message reaches 491 the originator node, the Energy Cost represents the total energy cost 492 of the path from destination back to the originator. 494 3.3.3. HELLO Message Format 496 In AODV, HELLO messages are used to offer connectivity information 497 and also for exchange the energy cost to the case of successor based 498 metric. HELLO messages are broadcasted locally having the same format 499 as RREP messages, with TTL = 1, the Hop Count field set to 0, and the 500 Destination IP Address set to its own IP address. For energy-aware 501 metrics, the HELLO message would have the format of the RREP message 502 described in subsection 3.3.2, and the Energy Cost field would carry 503 the energy cost of the node originating the message. 505 3.3.4. Route Selection 506 When a route to a new destination node is required, the source node 507 broadcasts RREQ messages to its neighbors. Those messages are usually 508 broadcasted by the neighbors to other nodes throughout the network 509 until one of them eventually reaches the destination node. When an 510 RREQ message reaches the destination (or an intermediate node that 511 has a route to the destination), the RREQ message is not broadcasted 512 anymore. Each intermediate node caches the information about the 513 source of the RREQ message, in order to have a route back to the 514 originator. 516 Through this process, the originator node selects the shortest-path 517 based on energy cost field of the routing table to the desired 518 destination node. 520 3.3.5. Routing Table 522 According to [RFC3561], AODV uses the following fields with each 523 route table entry: Destination IP Address; Destination Sequence 524 Number; Valid Destination Sequence Number flag; Other state and 525 routing flags (e.g., valid, invalid, repairable, being repaired); 526 Network Interface; Hop Count (number of hops needed to reach 527 destination); Next Hop; List of Precursors; Lifetime (expiration or 528 deletion time of the route). 530 For the usage of energy-aware metrics, the field Hop Count is 531 replaced by a new field, named Energy Cost. This field holds the 532 energy cost calculated to reach the destination, through the Next Hop 533 specified. 535 4. Acknowledgments 537 This draft is supported by national fundings via Fundacao para 538 Ciencia e Tecnologia (FCT), in the context of the UCR project 539 PTDC/EEA-TEL/103637/2008. 541 5. Security Considerations 543 There are no new security implications related to this draft. 545 6. IANA Considerations 547 None. 549 7. References 551 7.1. Normative References 553 [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, J. Jetcheva, N. Dejean, R. 581 Salazar, J. Hui, 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 06, May 1, 2012. 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 607 metrics for multihop wireless user-centric routing" in The 608 2012 International Conference on Wireless Networks 609 (ICWN'12), July 2012. 611 [AJUNIOR2] A. Junior, R. Sofia, and A. Costa, "Energy-efficient 612 heuristics for multihop routing in user-centric 613 environments" in 12th International Conference on Next 614 Generation Wired/Wireless Networking (NEW2AN), August 615 2012. 617 [AJUNIOR3] A. Junior, R. Sofia, and A. Costa, "Energy-awareness in 618 Multihop Routing" in 2012 IFIP Wireless Days conference 619 (WD'12), November 2012. 621 [I-D.ietf-roll-terminology] JP. Vasseur, "Terminology in Low power 622 And Lossy Networks", draft-ietf-roll-terminology-06.txt, 623 September 14, 2011. 625 [RFC5835] A. Morton, S. Van den Berghe, "Framework for Metric 626 Composition", RFC 5835, April 2010. 628 [J.J.GARCIA-LUNA-ACEVES] D. Kim, J. J. Garcia-Luna-Aceves, K. 629 Obraczka, J.-C. Cano, and P. Manzoni, "Routing mechanisms 630 for mobile ad hoc networks based on the energy drain 631 rate," IEEE Transactions on Mobile Computing, vol. 2, no. 632 2, pp. 161-173, 2003. 634 [OLSRv2] T. Clausen, C. Dearlove, P. Jacquet, U. Herberg, "The 635 Optimized Link State Routing Protocol version 2", draft- 636 ietf-manet-olsrv2-17, October 14, 2012. 638 [AODVv2] C. Perkins, I. Chakeres, "Dynamic MANET On-demand (AODVv2) 639 Routing", draft-ietf-manet-dymo-22, March 12, 2012. 641 Authors' Addresses 643 Antonio Junior 644 SITI, University Lusofona 645 Building U, 1st Floor 646 Campo Grande, 376 647 1749-024 Lisboa - Portugal 648 Email: antonio.junior@ulusofona.pt 649 Rute Sofia 650 SITI, University Lusofona 651 Building U, 1st Floor 652 Campo Grande, 376 653 1749-024 Lisboa - Portugal 655 Email: rute.sofia@ulusofona.pt