Internet DRAFT - draft-ajunior-roll-energy-awareness
draft-ajunior-roll-energy-awareness
ROLL Working Group A. Junior
Internet-Draft R. Sofia
Intended status: Informational COPELABS, University Lusofona
Expires: July 13, 2014 January 10, 2014
Energy-awareness metrics global applicability guidelines
draft-ajunior-roll-energy-awareness-01
Abstract
This document describes a new set of energy-awareness metrics which
have been devised to be applicable to any multihop routing protocol
having in mind LLNs, including the Routing for Low Power and Lossy
Networks (RPL) protocol.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2014.
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
A. Junior, R. Sofia Expires July 13, 2014 [Page 1]
Internet-Draft Energy-awareness metrics January 10, 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Energy-awareness Routing Metrics . . . . . . . . . . . . . . . 4
2.1. Energy Node Ranking: ENR . . . . . . . . . . . . . . . . . 4
2.2. Father-Son Association Ranking: Energy-awareness
Father-Son (EFS) . . . . . . . . . . . . . . . . . . . . . 5
2.3. Design Aspects . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of the Proposed Metrics . . . . . . . . . . . . . 5
3.1. RPL Applicability Guidelines . . . . . . . . . . . . . . . 5
3.1.1. Impact in Node Energy Object . . . . . . . . . . . . . 6
3.2. OLSR Applicability Guidelines . . . . . . . . . . . . . . . 6
3.2.1. Impact in HELLO Messages . . . . . . . . . . . . . . . 7
3.2.2. Impact in TC Messages . . . . . . . . . . . . . . . . . 7
3.2.3. OLSR Link Tuple . . . . . . . . . . . . . . . . . . . . 8
3.2.4 Routing Table . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. MPR Selection . . . . . . . . . . . . . . . . . . . . . 9
3.3. AODV Applicability Guidelines . . . . . . . . . . . . . . . 9
3.3.1. Route Request (RREQ) Message Format . . . . . . . . . . 10
3.3.2. Route Reply (RREP) Message Format . . . . . . . . . . . 10
3.3.3. HELLO Message Format . . . . . . . . . . . . . . . . . 11
3.3.4. Route Selection . . . . . . . . . . . . . . . . . . . . 11
3.3.5. Routing Table . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
A. Junior, R. Sofia Expires July 13, 2014 [Page 2]
Internet-Draft Energy-awareness metrics January 10, 2014
1. Introduction
Low Power and Lossy Networks (LLNs) routing requirements have been
specified in [RFC5548], [RFC5673], [RFC5826], [RFC5867], and
[RFC6719]. Additional aspects concerning routing metrics and also
constrains in design are available in [RFC6551]. Path computation
algorithms for single metrics have already been proposed and used in
[RFC6552], and [RFC6719].
Within the context of LLNs, we consider the specific case of User-
centric Networks (UCNs) [ULOOP], i.e., networks partially or
completely based on equipment that is owned and carried by regular
Internet end-users. Concrete examples of UCNs can be Wi-Fi networks
established on-the-fly after a disaster of some nature (e.g.,
disaster networks); a municipality network where networking nodes are
provided by the Internet end-user, who is willing to share network
resources (e.g. Internet access; radio spectrum) at the exchange of
specific incentives.
The intention of this document is two-fold. Firstly, we describe
energy-awareness metrics that can be applied to any multihop protocol
currently being considered in LLNs. Secondly, we provide design
guidelines concerning the applicability of such metrics for the
specific case of RPL.
The effectiveness and performance validation of the metrics described
in this document is out of the scope of the document, but can be
found in detail in [AJUNIOR1], [AJUNIOR2] and [AJUNIOR3].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
This document makes use of the terminology defined in [I-D.ietf-roll-
terminology]. Moreover, this document defines the following terms, in
accordance with [RFC5835] terminology:
Optimal path: is defined as a path in the DAG that minimizes (or
maximizes, respectively) the Rank value between any given pair of
source-destination nodes, as well as its sub-paths.
Path weight: a value representing link or/and node characteristics of
a path. This definition coincides with "path cost" defined in
[RFC6719]. Path weight is used by RPL to compare different paths.
A. Junior, R. Sofia Expires July 13, 2014 [Page 3]
Internet-Draft Energy-awareness metrics January 10, 2014
Idle mode: When a node is not receiving or transmitting, the node is
still listening to the shared medium (overhearing) and is said to be
in Idle mode.
Transmission mode: When a node is transmitting information.
Reception mode: When a node is receiving information.
Node lifetime: Corresponds to the period of time since a node becomes
active until the node is said to be dead, i.e., from a network
perspective, the node ceases to exist.
Network lifetime: Associated to the time period since a topology
becomes active, until the topology becomes disconnected, from a
destination reachability perspective.
Energy cost: The cost associated to the node or to the association
between two nodes which consider the energy parameters.
2. Energy-awareness Routing Metrics
This section describes the routing metrics proposed, from an
operational perspective. Conceptual aspects and validation of the
metrics, as well as concrete performance indicators can be found in
[AJUNIOR1], [AJUNIOR2] and [AJUNIOR3].
2.1. Energy Node Ranking: ENR
The Energy Node Ranking (ENR) metric is a node weight which ranks a
node in terms of its energy consumption stability. We explore the
fact that nodes may be in idle mode for a long time. Nodes that have
been in idle mode for a long period of time in the past and that
still have a reasonable large estimated lifetime are better
candidates to be elements in an optimal path. In other words, over
time we estimate how much of its lifetime has node i been in idle
mode, to then provide an estimate towards the node's future energy
expenditure, as this will for sure impact the node's lifetime.
Hence, we consider the total period in idle time T_Idle, over the
full lifetime expected for a specific node, which is given by the sum
of the elapsed time period T with the estimated lifetime of the node,
as provided in equation 1. The estimated lifetime C(i) consider the
ratio between residual energy and drain rate which can capture the
heterogeneous energy capability of nodes [J.J.GARCIA-LUNA-ACEVES].
ENR(i) = (T - T_Idle)/(T * C(i)) (1)
A. Junior, R. Sofia Expires July 13, 2014 [Page 4]
Internet-Draft Energy-awareness metrics January 10, 2014
2.2. Father-Son Association Ranking: Energy-awareness Father-Son (EFS)
Based on ENR, we consider a composition of the ENRs of both a father
and successor nodes (association between two nodes), as specified in
equation 2.
EFS(i,j) = ENR(i) * ENR(j) (2)
EFS provides a ranking which we believe is useful to assist the
routing algorithm to converge quickly in multipath environments, as
the selection on which successor to consider shall be made up from,
by the father node. The goal is, similarly to ENR, to improve the
network lifetime without disrupting the overall network operation.
Hence, the smaller EFS(i,j) is, the more likelihood a link has to
become part of a path.
2.3. Design Aspects
This section describes aspects concerning the applicability of the
metrics, e.g. messaging aspects.
The energy cost ranking (ENR or EFS) are recorded in reserved field
of control messages of any routing protocol occupying 16 bits.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy Cost (ENR or EFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. Applicability of the Proposed Metrics
This section describes how the proposed metrics can be applied to the
most popular multihop routing protocols in LLNs. We start by RPL
applicability guidelines, to then consider OLSR (actually work in
progress OLSRv2 [OLSRv2]) as a concrete example of Link-state
approaches, and AODV (actually work in progress AODVv2 [AODVv2]) as a
concrete example of distance-vector approaches.
3.1. RPL Applicability Guidelines
In order to use the metrics described in this document on the Routing
Protocol for Low-Power and Lossy Networks (RPL), no changes or
adaptation to the protocol are needed. By separating the packet
processing and forwarding processes from the routing path selection,
RPL provides a very flexible way of using and incorporating different
metrics.
A. Junior, R. Sofia Expires July 13, 2014 [Page 5]
Internet-Draft Energy-awareness metrics January 10, 2014
RPL operates upon the concept of Destination-Oriented Directed
Acyclic Graph (DODAG), where routes are calculated from all nodes to
a single destination in the topology (root node). Each node in the
topology has a Rank, that is basically a value that represents its
distance to the topology root.
According to specific LLNs applications, such routes are calculated
in order to achieve different objectives that may be desired (e.g.
minimize delay, maximize throughput, minimize energy usage), so
different Objective Functions (OF) may be defined. An OF defines how
routing metrics, constraints and related functions are used, in order
to define the route between the nodes towards a single destination in
the topology. That is, an OF, in conjunction with routing metrics and
constraints, allows for the selection of a DODAG to join (if there is
more than one), and a number of peers in that DODAG as parents (that
is, an ordered list of parents). The OF is also responsible to
compute the Rank of the node.
The [RFC6551] defines a very flexible mechanism for the advertisement
of routing metrics and constraints used by RPL, even though no OF is
presented. A high degree of flexibility is offered by that mechanism,
and a set of routing metrics and constraints are also described in
the document.
3.1.1. Impact on <object>
In order to use the metrics described in this document, the Node
Energy object (NE), as defined in [RFC6551], can be used without the
need for any changes or adaptation. The NE structure is composed by a
set of flags (8 bits), and an 8-bits field (E_E) used for carrying
the value of the estimated energy.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I| T |E| Energy Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To use the NE object with the metrics described in this document, the
value of ENR or EFS metrics should be placed in the E_E field, and
the flag 'E' (Estimation) should be set, indicating that a value for
the estimated energy is provided in the E_E field. The other flags of
the NE should be filled as defined in the standard.
3.2. OLSR Applicability Guidelines
The applicability of the proposed metrics does not imply significant
operation changes to OLSR standard as defined in [RFC3626]. The only
A. Junior, R. Sofia Expires July 13, 2014 [Page 6]
Internet-Draft Energy-awareness metrics January 10, 2014
change required is the creation of a special field or considering the
Reserved field to hold the energy cost information of the nodes. This
information will be used as basis to calculate the nodes routing
tables, and must be stored in the neighbors information and in the
routing table. This section describes a few design guidelines to
apply the proposed metrics to OLSR.
3.2.1. Impact in <scope/context>
In OLSR, the HELLO messages are used mainly to conduct link sensing,
neighbor detection and MPR selection. Therefore, to inform the other
nodes about its energy-aware cost, a node sends ENR or EFS via HELLO
messages. The metrics can be sent in the Reserved field in the
beginning of the HELLO message body defined in the standard.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy Cost (ENR or EFS) | Htime | Willingness |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the node is configured to use a node-based metric - ENR, then the
energy cost received via HELLO messages is enough to represent the
cost of the links towards those neighbors. If the node considers a
Father-Son composition such as EFS then the information received is
used to compute the final energy cost associated to the link based on
the neighbor's energy cost and its own.
An OLSR node uses TC messages to disseminate links between itself and
its neighbors. This information is spread throughout all the network,
and based on this information, each node can build its own network
topology. Furthermore, the topology information of each node is used
to calculate its routing table.
TCs messages are used to spread the energy cost of nodes in order to
compute the routing table using the Reserved field.
A. Junior, R. Sofia Expires July 13, 2014 [Page 7]
Internet-Draft Energy-awareness metrics January 10, 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANSN | Reserved (Energy Cost) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For each advertised link in the TC message, the Energy Cost can again
be carried in the Reserved field.
3.2.3. OLSR Link Tuple
An OLSR node stores a set of information about its neighbors. This
set of information, named "link tuple", is defined in [RFC3626] as
(L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time,
L_time), where L_local_iface_addr is the interface address of the
local node, L_neighbor_iface_addr is the interface address of the
neighbor node, L_SYM_time is the time until which the link is
considered symmetric, L_ASYM_time is the time until which the
neighbor interface is considered heard, and L_time specifies the time
at which the record expires.
In order to use the energy-aware metrics defined in this document, a
new field should be added to the link tuple. This extra field, named
"L_energy", stores the energy cost sent by the neighbor node in the
HELLO messages (in case of node-based metrics) or the calculated
energy cost related to the link towards that node (in case of
sucessor-based metrics).
When a node receives a HELLO message, the link set (set of link
tuples) is updated. If the node receives a HELLO message from a
neighbor node that does not exist in the link set, a new link tuple
is created. In both cases, the information carried in the Energy Cost
field of the HELLO message body must be considered. In case a link
tuple exists, the L_energy value should be updated; if the tuple is
created, the value of the L_energy field should be based on the
Energy Cost field of the HELLO message received.
3.2.4 Routing Table
Each OLSR node maintains a routing table with information which
allows it to route packets destined to other nodes in the network. As
defined in the OLSR standard, the routing table is composed by
A. Junior, R. Sofia Expires July 13, 2014 [Page 8]
Internet-Draft Energy-awareness metrics January 10, 2014
entries with the following information: R_dest_addr, R_next_addr
R_dist, R_iface_addr, where R_dest_addr is the final destination,
R_next_addr is the next hop towards the destination, R_dist is the
distance in number of hops, and R_iface_addr is the address of the
local interface through which the node is reachable.
Using energy-aware metrics, the field R_dist no longer holds the
distance in terms of hops, but in terms of energy cost. Therefore,
the R_dist field holds the energy cost of the total path to reach
that specific destination. All the other fields remain without any
changes.
3.2.5. MPR Selection
The MPR selection criteria is also relevant in the contest of path
computation based on the proposed Energy Cost metrics. Therefore, one
simple approach (of many that can be designed) for selecting the MPRs
based on the energy cost of the neighboring nodes.
Basically, when choosing the MPR, a node should take into
consideration not only the number of 2-hop neighbors each of its 1-
hop neighbors has; it should also take into consideration the energy
cost of the neighbor nodes. Therefore, when there are more than one
1-hop neighbors covering the same number of uncovered 2-hop
neighbors, the one with the lowest energy cost weight to the current
node is selected as MPR.
3.3. AODV Applicability Guidelines
In contrast to link-state routing, distance-vector routing protocols
work by having each node sharing its routing table with its
neighbors. Routers using distance-vector protocol do not have
knowledge of the entire path to a destination. Instead, distance-
vector uses two key information: i) the direction in which or
interface to which a packet should be forwarded; and ii) the distance
from it to the final destination, where distance means number of
hops.
To use energy-aware metrics, the concept of distance based on number
of hops must be adapted to be based on a per-hop calculated energy
cost. Therefore, the routing table of distance-vector routing
protocols using energy-aware metrics does not hold the distance in
number of hops to the destination; it holds the energy cost
calculated for all the route from it to the destination node instead.
Energy-aware metrics can be applied to AODV without major changes. As
the optimal path is chosen reactively based on the hop-count of
request/reply messages, in order to use the energy cost to make a
A. Junior, R. Sofia Expires July 13, 2014 [Page 9]
Internet-Draft Energy-awareness metrics January 10, 2014
decision on the more energy efficient route from source node to
destination node, the calculated energy cost value must be
transmitted from one node to another, during the route discovery
procedure.
The calculated energy cost, transmitted from node to node when
searching for a route, is a cumulative value that represents the
energy cost calculated for the path from the source until the current
node.
3.3.1. Route Request (RREQ) Message Format
When a route to a new destination node is required, the source node
broadcasts RREQ messages to its neighbors. Those messages are
broadcasted to other nodes throughout the network until one of them
eventually reaches the destination node. For energy-aware metrics,
the energy cost of the route is calculated as the RREQ message is re-
broadcasted; this information is carried in the RREQ messages, and
when those messages reach the destination, they carry the energy cost
of the entire route, from source to destination.
In order to carry the energy cost value, a slight change needs to be
applied to the RREQ message format. The space originally used for the
field Hop Count will be used for carrying the cumulative energy cost
calculated throughout the path. The Energy Cost field will take place
using the 8 bits previously used for the Hop Count value, and using 8
bits of the Reserved field. This change does not increase the packet
size, not increasing the routing control overhead in the network.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Res | Energy Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As the RREQ is broadcasted by the nodes in the network, the Energy
Cost field is updated with the energy of the local node. When the
RREQ message reaches the destination node, the Energy Cost field will
A. Junior, R. Sofia Expires July 13, 2014 [Page 10]
Internet-Draft Energy-awareness metrics January 10, 2014
have the energy cost for the entire path, from source node to
destination node.
3.3.2. Route Reply (RREP) Message Format
RREP messages are used when an intermediate node receives an RREQ
message, but it already knows a route to the destination node
specified in that message, or when an RREP message reaches the
destination node. In both cases, an RREP message is created and sent
back to the source node.
In order to transmit the information about the route energy cost back
to the source node, the RREP message must carry a cumulative energy
cost value, calculated throughout the path back to the source. This
information is carried in the field Energy Cost, added to the RREP
message structure, taking place of the Hop Count field of 8 bits, and
taking 8 bits from the Reserved field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A|Prefix Sz| Energy Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As the RREP message is sent back to the node which originated the
RREQ message, the Energy Cost field accumulates the energy cost
calculated throughout the path. Thus, when the RREP message reaches
the originator node, the Energy Cost represents the total energy cost
of the path from destination back to the originator.
3.3.3. HELLO Message Format
In AODV, HELLO messages are used to offer connectivity information
and also for exchange the energy cost to the case of successor based
metric. HELLO messages are broadcasted locally having the same format
as RREP messages, with TTL = 1, the Hop Count field set to 0, and the
Destination IP Address set to its own IP address. For energy-aware
metrics, the HELLO message would have the format of the RREP message
described in subsection 3.3.2, and the Energy Cost field would carry
A. Junior, R. Sofia Expires July 13, 2014 [Page 11]
Internet-Draft Energy-awareness metrics January 10, 2014
the energy cost of the node originating the message.
3.3.4. Route Selection
When a route to a new destination node is required, the source node
broadcasts RREQ messages to its neighbors. Those messages are usually
broadcasted by the neighbors to other nodes throughout the network
until one of them eventually reaches the destination node. When an
RREQ message reaches the destination (or an intermediate node that
has a route to the destination), the RREQ message is not broadcasted
anymore. Each intermediate node caches the information about the
source of the RREQ message, in order to route back to the originator.
Through this process, the originator node selects the shortest-path
based on energy cost field of the routing table to the desired
destination node.
3.3.5. Routing Table
According to [RFC3561], AODV uses the following fields with each
route table entry: Destination IP Address; Destination Sequence
Number; Valid Destination Sequence Number flag; Other state and
routing flags (e.g., valid, invalid, repairable, being repaired);
Network Interface; Hop Count (number of hops needed to reach
destination); Next Hop; List of Precursors; Lifetime (expiration or
deletion time of the route).
For the usage of energy-aware metrics, the field Hop Count is
replaced by a new field, named Energy Cost. This field holds the
energy cost calculated to reach the destination, through the Next Hop
specified.
4. Acknowledgments
This draft is supported by national fundings via Fundacao para
Ciencia e Tecnologia (FCT), in the context of the UCR project
PTDC/EEA-TEL/103637/2008. Thanks to Universidade Federal de Goias
(UFG/CAC) and Fundacao de Amparo a Pesquisa do Estado de Goias
(FAPEG).
5. Security Considerations
There are no new security implications related to this draft.
6. IANA Considerations
A. Junior, R. Sofia Expires July 13, 2014 [Page 12]
Internet-Draft Energy-awareness metrics January 10, 2014
None.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC2119, March 1997.
7.2. Informative References
[RFC3626] Clausen, T., Jacquet, P. (Ed.), "Optimized Link State
Routing Protocol (OLSR)", RFC3626, October 2003.
[RFC3561] Perkins, C., Belding-Royer, E., Das, S., "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC3561, July 2003.
[RFC5548] M. Dohler, T. Watteyne, T. Winter, D. Barthel, "Routing
Requirements for Urban Low-Power and Lossy Networks", RFC
5548, May 2009.
[RFC5673] K. Pister, P. Thubert, S. Dwars, T. Phinney, "Industrial
Routing Requirements in Low-Power and Lossy Networks", RFC
5673, October 2009.
[RFC5826] A. Brandt, J. Buron, G. Porcu, "Home Automation Routing
Requirements in Low-Power and Lossy Networks", RFC 5826,
April 2010.
[RFC5867] J. Martocci, P. De Mil, N. Riou, W. Vermeylen, "Building
Automation Routing Requirements in Low-Power and Lossy
Networks", RFC 5867, June 2010.
[I-D.ietf-roll-applicability-ami] D. Popa, M. Gillmore, L. Toutain,
J. Hui, R. Ruben, K. Monden, "Applicability Statement for
the Routing Protocol for Low Power and Lossy Networks
(RPL) in AMI Networks", draft-ietf-roll-applicability-ami-
07, July, 2013.
[RFC6550] T.Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P.
Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander,
"RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks," RFC 6550, March 2012.
[RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel,
"Routing Metrics Used for Path Calculation in Low-Power
A. Junior, R. Sofia Expires July 13, 2014 [Page 13]
Internet-Draft Energy-awareness metrics January 10, 2014
and Lossy Networks", RFC 6551, March 2012.
[RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel,
"Routing Metrics Used for Path Calculation in Low-Power
and Lossy Networks", RFC 6551, March 2012.
[RFC6719] O. Gnawali, P. Levis, "The Minimum Rank with Hysteresis
Objective Function", RFC 6719, September 2012.
[ULOOP] "ULOOP: User-centric Wireless Local-Loop," EU IST FP7 Project
(Grant 257418).
[AJUNIOR1] A. Junior, R. Sofia, and A. Costa, "Energy-awareness
metrics for multihop wireless user-centric routing" in The
2012 International Conference on Wireless Networks
(ICWN'12), July 2012.
[AJUNIOR2] A. Junior, R. Sofia, and A. Costa, "Energy-efficient
heuristics for multihop routing in user-centric
environments" in 12th International Conference on Next
Generation Wired/Wireless Networking (NEW2AN), August
2012.
[AJUNIOR3] A. Junior, R. Sofia, and A. Costa, "Energy-awareness in
Multihop Routing" in 2012 IFIP Wireless Days conference
(WD'12), November 2012.
[I-D.ietf-roll-terminology] JP. Vasseur, "Terminology in Low power
And Lossy Networks", draft-ietf-roll-terminology-13.txt,
September 30, 2013.
[RFC5835] A. Morton, S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010.
[J.J.GARCIA-LUNA-ACEVES] D. Kim, J. J. Garcia-Luna-Aceves, K.
Obraczka, J.-C. Cano, and P. Manzoni, "Routing mechanisms
for mobile ad hoc networks based on the energy drain
rate," IEEE Transactions on Mobile Computing, vol. 2, no.
2, pp. 161-173, 2003.
[OLSRv2] T. Clausen, C. Dearlove, P. Jacquet, U. Herberg, "The
Optimized Link State Routing Protocol version 2", draft-
ietf-manet-olsrv2-19, March 23, 2013.
[AODVv2] C. Perkins, S. Ratliff, J. Dowdell, "Dynamic MANET On-demand
(AODVv2) Routing", draft-ietf-manet-aodvv2-02, July 15,
2013.
A. Junior, R. Sofia Expires July 13, 2014 [Page 14]
Internet-Draft Energy-awareness metrics January 10, 2014
Authors' Addresses
Antonio Junior
COPELABS, University Lusofona
Building U, 1st Floor
Campo Grande, 376
1749-024 Lisboa - Portugal
Email: antoniocojr@gmail.com
Rute Sofia
COPELABS, University Lusofona
Building U, 1st Floor
Campo Grande, 376
1749-024 Lisboa - Portugal
Email: rute.sofia@ulusofona.pt
A. Junior, R. Sofia Expires July 13, 2014 [Page 15]
