One document matched: draft-ietf-manet-dymo-24.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
<!-- TODO:
== Consider enabling multiple routes to same destination
== Add processing for arbitrary metrics
== Need for 'D' flag on RREQ: where to put it?
== Sequence number; should allow '0' to be a useful sequence number
++ Check on uses of Route.Prefix
++ Make packet formats
++ Insert data structure for blacklisted nodes?
++ Route.Dist or Node.Dist is unknown or zero (what is the difference?)
++ Fix erroneous statements about aggregation
++ Check on Route.Broken flag
++ Propose removal of Route.Forwarding flag; same as "not" Route.Broken
++ Comments from Abdussalam
++ Comments from Ulrich
++ Comments from Clausen
-->
<rfc category="std" docName="draft-ietf-manet-dymo-24" ipr="trust200902">
<front>
<title abbrev="AODVv2">Dynamic MANET On-demand (AODVv2) Routing</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-5305</phone>
<email>charliep@computer.org</email>
</address>
</author>
<author fullname="Ian D Chakeres" initials="I.D." surname="Chakeres">
<organization>CenGen</organization>
<address>
<postal>
<street>9250 Bendix Road North</street>
<city>Columbia</city>
<region>Maryland</region>
<code>21045</code>
<country>USA</country>
</postal>
<email>ian.chakeres@gmail.com</email>
<uri>http://www.ianchak.com/</uri>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>Mobile Ad hoc Networks Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>reactive protocol</keyword>
<abstract>
<t>The Dynamic MANET On-demand (AODVv2) routing protocol is
intended for use by mobile routers in wireless, multihop
networks. AODVv2 determines unicast routes among AODVv2 routers
within the network in an on-demand fashion, offering on-demand
convergence in dynamic topologies.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>The Dynamic MANET On-demand (AODVv2) routing protocol
[formerly named DYMO] enables
on-demand, multihop unicast routing among AODVv2
routers in mobile ad hod networks [MANETs]<xref target="RFC2501" />.
The basic operations of the AODVv2 protocol are route
discovery and route maintenance. Route discovery is performed when
an AODVv2 router must transmit a packet
towards a destination for which it does not have a route.
Route maintenance is performed to avoid prematurely expunging routes
from the route table, and to avoid dropping packets when a route being
used to forward packets from the source to a destination breaks.</t>
<t>During route discovery, an AODVv2 router
multicasts a Route Request message (RREQ)
to find a route toward a particular destination, via the
AODVv2 router responsible for this destination. Using a
hop-by-hop retransmission algorithm, each intermediate AODVv2 router
receiving the RREQ message records a route toward the originator.
When the target's AODVv2 router (TargRtr) receives the RREQ, it records a
route toward the originator and responds with a Route Reply (RREP) unicast
hop-by-hop toward the originating AODVv2 router. Each intermediate
AODVv2 router that receives the RREP creates a route toward the
target, and unicasts the RREP hop-by-hop toward the
originator. When the originator's AODVv2 router receives the RREP,
routes have then been established between the originating AODVv2
router and the target AODVv2 router in both directions.</t>
<t>Route maintenance consists of two operations. In order to
preserve active routes, AODVv2 routers extend route lifetimes upon
successfully forwarding a packet. When a data packet is received
for forwarding and there is no valid route for the destination,
then the AODVv2 router of the source of the packet is notified via
a Route Error (RERR) message. Each upstream router that receives
the RERR marks the route as broken. Before such an upstream AODVv2
router could forward a packet to the same destination, it would have
to perform route discovery again for that destination.</t>
<t>AODVv2 uses sequence numbers to assure loop freedom
<xref target="Perkins99" />, similarly to AODV. Sequence numbers
enable AODVv2 routers to determine the temporal order of AODVv2 route
discovery messages, thereby avoiding use of stale routing information.
Unlike AODV, AODVv2 uses RFC 5444 message and TLV formats.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119" />.</t>
<t>This document also uses some terminology from <xref
target="RFC5444" />.</t>
<t>This document defines the following terminology:</t>
<t><list style="hanging">
<t hangText="Adjacency"><vspace /> A bi-directional relationship between
neighboring routers for the purpose of
exchanging routing information. Not every pair of neighboring
routers will necessarily form an adjacency. Neighboring routers may
form an adjacency based on various information or other
protocols; for example, exchange of AODVv2 routing messages,
other protocols (e.g. NDP <xref target="RFC4861" /> or NHDP
<xref target="RFC6130" />), or manual
configuration. Loss of a routing adjacency may also
be based upon similar information; monitoring of
adjacencies where packets are being forwarded is required (see
<xref target="link_breaks" />).</t>
<t hangText="AODVv2 Router"><vspace />An IP addressable device in the
ad-hoc network that performs the AODVv2 protocol operations
specified in this document.</t>
<t hangText="AODVv2 Sequence Number (SeqNum)"><vspace />An AODVv2
Sequence Number is an unsigned integer maintained by each AODVv2
router. This sequence number guarantees the temporal order
of routing information to maintain loop-free routes.
The value zero (0) is reserved to indicate that the SeqNum
for a destination address is unknown.</t>
<t hangText="Current_Time"><vspace />The current time as maintained by
the AODVv2 router. <!-- from which RFC?? CEP -->
</t>
<t hangText="disregard"><vspace />Ignore for further processing
(see <xref target="MsgStruct"/>), and delete unless it is
required to keep the message in the packet for purposes
of authentication.
</t>
<t hangText="Handling Router (HandlingRtr)"><vspace /> HandlingRtr denotes
the AODVv2 router handling an AODVv2 message.</t>
<t hangText="Incoming Link"><vspace />A link over which an AODVv2 has received
a message from one of its adjacent routers.</t>
<t hangText="MANET"><vspace /> A Mobile Ad Hoc Network as defined in
<xref target="RFC2501" />.</t>
<t hangText="node"><vspace />An IP addressable device in the ad-hoc network.
A node may be an AODVv2 router, or it may be a device in the
network that does not perform any AODVv2 protocol operations.
All nodes in this document are either AODVv2 Routers or
else Router Clients.</t>
<t hangText="Originating Node (OrigNode)"><vspace/>
The Originating Node is the node that launched the application
requiring communication with the Target Node. If OrigNode is not
itself an AODVv2 router, its AODVv2 router (OrigRtr) has the
responsibility to generate a AODVv2 RREQ message on behalf of
OrigNode when necessary to multicast a route discovery message.</t>
<t hangText="Originating Router (OrigRtr)"><vspace/>
The Originating Router is the AODVv2 router that serves OrigNode.
OrigRtr generates the RREQ message to discover a route for TargNode.
</t>
<t hangText="reactive"><vspace /> A protocol operation is said to be
"reactive" if it is performed only in reaction to specific
events. As used in this document, "reactive"
is essentially synonymous with "on-demand". </t>
<t hangText="Routable Unicast IP Address"><vspace/>
A routable unicast IP address is a unicast IP
address that when put into the
IP.DestinationAddress field is scoped sufficiently to be
forwarded by a router. Globally-scoped unicast IP addresses
and Unique Local Addresses (ULAs) <xref target="RFC6549" />
are examples of routable unicast IP addresses.</t>
<!-- Can a node determine whether an address is multihop-capable? [CEP] -->
<t hangText="Route Error (RERR)"><vspace />
A RERR message is used to indicate that an AODVv2 router does not
have a route toward one or more particular destinations.</t>
<t hangText="Route Reply (RREP)"><vspace />
A RREP message is used to establish a route between the RREQ
TargetNode and OrigNode, at all the AODVv2 routers between them.</t>
<t hangText="Route Request (RREQ)"><vspace />
An AODVv2 router uses a RREQ message to discover a valid route
to a particular destination address, called the RREQ TargetNode.
An AODVv2 router processing a RREQ receives routing information for
the RREQ OrigNode.</t>
<t hangText="Router Client"><vspace />An AODVv2 router may
be configured with a list of other IP addresses and networks
which correspond to other non-router nodes which require
the services of the AODVv2 router for route discovery and
maintenance. An AODVv2 is always its own client, so that
the list of client IP addresses is never empty.</t>
<t hangText="Sequence Number (SeqNum)"><vspace />
Same as AODVv2 Sequence Number.
</t>
<t hangText="Target Node (TargNode)"><vspace />
The Target Node denotes the node for which a route is needed.</t>
<t hangText="Target Router (TargRtr)"><vspace />
The TargetRtr denotes the AODVv2 router which serves TargNode.</t>
<t hangText="Type-Length-Value structure (TLV)"><vspace />
A generic way to represent information as specified
in <xref target="RFC5444" />.</t>
<t hangText="Unreachable Node (UnreachableNode)"><vspace /> An
UnreachableNode is a node for which a forwarding route is unknown.</t>
<t hangText="valid route"><vspace /> A route that can be used for
forwarding; in other words a route that is not Broken or Expired.</t>
</list></t>
<t><vspace blankLines="15" /></t>
</section>
<section anchor="notation" title="Notational Conventions">
<t>This document uses the conventions found in
<xref target="notational-conventions"/> to describe information
in the fields from <xref target="RFC5444" />.</t>
<texttable anchor="notational-conventions">
<ttcol align="center">Notation</ttcol>
<ttcol align="center">Information Location and/or Meaning</ttcol>
<!--
<c>IP header</c> <c>IP.</c>
-->
<c>Route[DestAddr]</c> <c>A route table entry towards DestAddr</c>
<c>Route[Addr]{field}</c> <c>A field in a route table entry</c>
<c> -- </c> <!-- Message field Types --> <c> -- </c>
<c>RREQ.{field}</c> <c>Field in RREQ</c>
<c>RREP.{field}</c> <c>Field in RREP</c>
<c>RERR.{field}</c> <c>Field in RERR</c>
<c> -- </c> <!-- MsgHdr fields--> <c> -- </c>
<c>MsgHdr</c> <c>the RFC5444 Message Header</c>
<c>MsgTLV</c> <c>an RFC5444 Message TLV</c>
<c>MetricTypeTLV</c> <c>MetricType MsgTLV for Metric AddrTLV</c>
<c>MAL</c> <c>MsgHdr.<msg-addr-length></c>
<c> -- </c> <!-- Address Block fields and notation--> <c> -- </c>
<c>AddrBlk</c> <c>an RFC5444 address block</c>
<c>AddrBlk[1]</c> <c>The first address slot in AddrBlk</c>
<c>AddrBlk[N]</c> <c>The Nth address slot in AddrBlk</c>
<c>AddrBlk[OrigNode]</c> <c>AddrBlk[1]</c>
<c>AddrBlk[TargNode]</c> <c>AddrBlk[2]</c>
<c>AddrTLV</c> <c>an RFC5444 address block TLV</c>
<c>AddrTLV[1]</c> <c>the first item in AddrTLV</c>
<c>AddrTLV[N]</c> <c>the Nth item in AddrTLV</c>
<c>AddrTLV[OrigNode]</c> <c>AddrTLV[1]</c>
<c>AddrTLV[TargNode]</c> <c>AddrTLV[2]</c>
<c>HopCountTLV</c> <c>Metric8 AddrTLV when MetricTypeTLV=3</c>
<c>Metric8TLV</c> <c>Metric8 AddrTLV</c>
<c>SeqNumTLV</c> <c>Sequence Number TLV for AddrBlk addresses</c>
<c>RteAddrBlk</c> <c>the main address block in a RteMsg</c>
<c>RteSeqNumTLV</c> <c>Sequence Numbers for RteAddrBlk addresses</c>
<c>UnreachAddrBlk</c> <c>Unreachable Node AddrBlk in RERR</c>
<c> -- </c> <!-- Types of Nodes --> <c> -- </c>
<c>OrigRtr</c> <c>RREQ Originating Router</c>
<c>OrigNode</c> <c>Originating Node</c>
<c>RREQ_Gen</c> <c>AODVv2 router originating an RREQ</c>
<c>RREP_Gen</c> <c>AODVv2 router responding to an RREQ</c>
<c>RteMsg</c> <c>either RREQ or RREP</c>
<c>RteMsg_Orig</c> <c>Originator of a RteMsg</c>
<c>HandlingRtr</c> <c>Handling Router</c>
<c>TargRtr</c> <c>Target Router</c>
<c>TargNode</c> <c>Target Node</c>
<c>UnreachableNode</c> <c>Unreachable Node</c>
</texttable>
</section>
<section title="Applicability Statement">
<t>The AODVv2 routing protocol is designed for stub (i.e., non-transit) or
disconnected (i.e., from the Internet) mobile ad hoc networks (MANETs).
AODVv2 handles a
wide variety of mobility patterns by determining
routes on-demand. AODVv2 also handles a wide variety of traffic
patterns. In networks with a large number of routers, AODVv2 is
best suited for relatively sparse traffic scenarios where any
particular router forwards packets to only a small percentage of
the AODVv2 routers in the network, due
to the on-demand nature of route discovery and route maintenance.
<!--
The nets do not have to be mobile, and AODVv2 may be applicable
in low power lossy sensor networks.
-->
</t>
<t>Although AODVv2 is closely related to AODV
<xref target="RFC3561" />, and has some of the features of DSR
<xref target="RFC4728" />, AODVv2 is not interoperable with
either of those other two protocols.</t>
<t>AODVv2 is applicable to memory constrained devices, since
little routing state is maintained in each AODVv2 router. Only
routing information related to routes between active sources and
destinations
is maintained, in contrast to proactive routing protocols
that require routing information to all routers within the
MANET be maintained.</t>
<t>AODVv2 supports routers with multiple interfaces, as long
as each interface has its own IP address.
In addition to routing for their local processes, AODVv2 routers can
also route on behalf of other non-routing nodes (i.e., "hosts", or,
in this document, "clients"), reachable via those interfaces.
Any such node which is not itself an AODVv2 router SHOULD NOT
be served by more than one AODVv2 router.</t>
<t>Multi-homing is difficult unless the sequence number is expanded to
include the IP address as well as OwnSeqNum. Otherwise, comparing
sequence numbers would not work to evaluate freshness. Even when the
IP address is included, there isn't a good way to compare sequence
numbers from different IP addresses, but at least a handling node can
determine whether the two given sequence numbers are comparable. If the
route table can store multiple routes for the same destination, then
multi-homing can work with sequence numbers augmented by IP addresses.</t>
<t>AODVv2 routers perform route discovery to find a route toward a
particular destination. Therefore, AODVv2 routers MUST must be
configured to respond to RREQs for a certain set of addresses.
When AODVv2 is the only protocol interacting with the forwarding
table, AODVv2 MAY be configured to perform route discovery for
all unknown unicast destinations.</t>
<t>At all times within an AODVv2 MANET, only one AODVv2 router
SHOULD be serve any particular routing client. The coordination
among multiple AODVv2 routers to distribute
routing information correctly for a shared address (i.e. an address
that is advertised and can be reached via multiple AODVv2 routers) is
not described in this document. The AODVv2 router operation of shifting
responsibility for a routing client from one AODVv2 router to
another is mentioned in <xref target="change_address_location" />.
Each AODVv2 router, if serving router clients other than itself,
is configured with information about the IP addresses of its clients.
No AODVv2 router is required to have information about
the relationship between any other AODVv2 router and its router clients.
Address assignment procedures are entirely out of scope for AODVv2.</t>
<t>AODVv2 only utilizes bidirectional links. In the case of
possible unidirectional links, either blacklists (see <xref
target="blacklists" />) or other means (e.g. adjacency establishment
with only neighboring routers that have bidirectional
communication as indicated by NHDP <xref target="RFC6130" />) of
assuring and monitoring bi-directionality is recommended.
Otherwise, persistent packet loss or persistent protocol
failures could occur. The Cost(L) of bidirectional link L may
depend upon the direction across the link for which the cost is
measured.
</t>
<!-- CEP : this can be deleted -->
<t>The routing algorithm in AODVv2 may be operated at layers other
than the network layer, using layer-appropriate addresses.
The routing algorithm makes of some persistent state; if there
is no persistent storage available for this state, recovery can
impose a performance penalty in case of AODVv2 router reboots.</t>
</section>
<!-- ============================================================= -->
<section title="Data Structures">
<section anchor="rte" title="Route Table Entry">
<t>The route table entry is a conceptual data structure.
Implementations may use any internal representation so long as
it provides access to the same information as specified below.</t>
<t>Conceptually, a route table entry has the following fields:
<list style="hanging">
<t hangText="Route.Address"><vspace />The (host or network)
destination address of the node(s) associated with the routing
table entry</t>
<t hangText="Route.PfxLen"><vspace />
The value is the length of the netmask/prefix. If the value
of the Route.PfxLen is nonzero and different than the length
of addresses in the address family used by the AODVv2 routers,
the associated address is a routing prefix, rather than a
host address. </t>
<t hangText="Route.SeqNum"><vspace />The AODVv2 SeqNum
associated with a route table entry</t>
<t hangText="Route.NextHopAddress"><vspace />An IP
address of the adjacent AODVv2 router on the path toward the
Route.Address</t>
<t hangText="Route.NextHopInterface"><vspace />The
interface used to send packets toward the
Route.Address</t>
<t hangText="Route.LastUsed"><vspace />The time that this
route was last used</t>
<t hangText="Route.ExpirationTime"><vspace />The time
at which this route must expire</t>
<t hangText="Route.Broken"><vspace />A flag indicating
whether this Route is broken. This flag is set to true if
the next-hop becomes unreachable or in response to
processing to a RERR (see <xref target="rerr_hand" />)</t>
<t hangText="Route.MetricType"><vspace />The type of the metric
for the route towards Route.Address</t>
<t hangText="Route.Metric"><vspace />The cost of the route
towards Route.Address</t>
</list></t>
<t>A route table entry (i.e., a route) may be in one of the
following states:
<list style="hanging">
<t hangText="Active"><vspace /> An Active route is in current
use for forwarding packets</t>
<t hangText="Idle"><vspace /> An Idle route can be used for
forwarding packets, even though it is not in current use</t>
<t hangText="Expired"><vspace /> After a route has been idle for
too long, it expires, and may no longer be used for
forwarding packets</t>
<t hangText="Broken"><vspace /> A route marked as Broken cannot be
used for forwarding packets but still has valid destination
sequence number information.</t>
<t hangText="Timed"><vspace /> The expiration of a Timed route
is controlled by the Route.ExpirationTime time of the
route table entry, not MAX_IDLETIME. Until that time,
a Timed route can be used for forwarding packets.
Afterwards, the route must be Expired (or expunged).</t>
</list> </t>
<t>The route's state determines the operations that can be performed
on the route table entry. During use, an Active route is
maintained continuously by AODVv2 and is considered to remain
active as long as it is used at least once during every
ACTIVE_INTERVAL. When a route is no longer Active, it
becomes an Idle route. After a route remains Idle for
MAX_IDLETIME, it becomes an Expired route; after that,
the route is not used for forwarding, but the sequence
number information can be maintained until the destination
sequence number has had no updates for MAX_SEQNUM_LIFETIME.
After MAX_SEQNUM_LIFETIME, old sequence number information
is considered no longer valuable and the route is expunged.</t>
<t>MAX_SEQNUM_LIFETIME is the time after a reboot during which an
AODVv2 router MUST NOT transmit any routing messages. Thus,
if all other AODVv2 routers expunge routes to the rebooted
router after that time interval, the rebooted AODVv2 router's
sequence number will not be considered stale by any other
AODVv2 router in the MANET.</t>
<t>When the link to a route's next hop is broken, the route is marked
as being Broken, and the route may no longer be used.</t>
</section>
<section anchor="blacklists"
title="Bidirectional Connectivity During Route Discovery and Blacklists">
<t>To avoid repeated failure of Route Discovery, an AODVv2 router
(HandlingRtr) handling a RREP message MAY attempt to verify
connectivity to the next upstream router towards AODVv2
router originating an RREQ message, by including the Unicast
Response Request message TLV (see <xref target="msgtlvtypes"/>)
in the RREP. Any unicast packet will satisfy the Response
Request, for example an ICMP REPLY message. If the verification
fails, HandlingRtr SHOULD put the upstream neighbor in a
blacklist. RREQs received from a blacklisted node SHOULD NOT
be retransmitted by HandlingRtr.
However, the upstream neighbor should not be permanently
blacklisted; after a certain time (MAX_BLACKLIST_TIME),
it should once again be considered as a viable upstream
neighbor for route discovery operations.
</t>
<t>For this purpose, a list of blacklisted nodes along with
their time of removal should be maintained:
<list style="hanging">
<t hangText="BlacklistNode"><vspace />The IP address of the
node that did not verify bidirectional connectivity. </t>
<t hangText="BlacklistRmTime"><vspace />The time at which
BlacklistNode will be removed from the blacklist. </t>
</list>
</t>
</section>
<section anchor="clients" title="Router Clients and Client Networks">
<t>An AODVv2 router may offer routing services to other nodes that
are not AODVv2 routers. The AODVv2 Sequence Number
is (by definition) the same for the AODVv2 router and each of
its clients.
</t>
<t>For this purpose, a list of IP addresses nodes along with
relevant prefixes must be configured on each AODVv2:
<list style="hanging">
<t hangText="Client IP address"><vspace />The IP address of the
node that requires routing service from the AODVv2 router.</t>
<t hangText="Client Prefix Length"><vspace />The length of the
routing prefix associated with the client IP address.
</t>
</list>
</t>
<t>If the Client Prefix Length is not the full length of the
Client IP address, then the prefix defines a Client
Network. If an AODVv2 router is configured to serve
a Client Network, then the AODVv2 router MUST serve
every node that has an address within the range defined
by the routing prefix of the Client Network. The list
of Routing Clients for an AODVv2 router is never empty,
since an AODVv2 router is always its own client as well.
</t>
</section>
<section anchor="MsgStruct"
title="AODVv2 Packet Header Fields and Information Elements">
<t> In its default mode of operation, AODVv2 uses the UDP port
269 <xref target="RFC5498" /> to carry protocol packets.
In addition, IP Protocol Number 138
has been reserved for MANET protocols <xref target="RFC5498" />.
Most AODVv2 messages are sent with the IP destination address
set to the link-local multicast address LL-MANET-Routers
<xref target="RFC5498" /> unless otherwise specified. Therefore,
all AODVv2 routers
MUST <!-- MUST [CEP] -->
subscribe to LL-MANET-Routers <xref target="RFC5498" /> to
receiving AODVv2 messages.
In order to reduce multicast overhead, retransmitting multicast
packets in MANETs SHOULD be done according to
methods specified in <xref target="RFC6621" />. AODVv2 does
not specify which method should be used to restrict the
set of AODVv2 routers that have the responsibility to
retransmit multicast packets. Note that multicast packets MAY be sent
via unicast. For example, this may occur for certain link-types
(non-broadcast media), for manually configured router adjacencies,
or in order to improve robustness.
</t>
<t>The IPv4 TTL (IPv6 Hop Limit) field for all packets
containing AODVv2 messages is set to 255. If a packet is
received with a value other than 255, any AODVv2 message
contained in the packet MUST be disregarded by AODVv2.
This mechanism, known as "The Generalized TTL Security Mechanism"
(GTSM) <xref target="RFC5082" /> helps to assure that packets
have not traversed any intermediate routers.</t>
<t>IP packets containing AODVv2 protocol messages SHOULD be
given priority queuing and channel access.</t>
<t>AODVv2 messages are transmitted in packets that conform to the
packet and message format described in <xref target="RFC5444" />.
Here is a brief description of the format.
<list style="hanging">
<t> A packet formatted according to RFC5444
contains zero or more messages. </t>
<t> A message contains a message header,
message TLV block, and zero or more address blocks.</t>
<t> Each address block may also have
associated TLV blocks.</t>
</list>
If a packet contains only a single AODVv2 message and no
packet TLVs, it need not include a packet-header <xref
target="RFC5444" />.
The length of an address (32 bits for IPv4 and 128 bits
for IPv6) inside an AODVv2 message is indicated by the
msg-addr-length (MAL) in the msg-header, as specified in
<xref target="RFC5444"/>.</t>
<t> When multiple messages are aggregated
into a single packet according to RFC 5444 formatting, and the
aggregation of messages is also authenticated (e.g., with IPsec),
it becomes unfeasible to delete individual messages. In such
cases, instead of deleting individual messages, they are maintained
in the aggregation of messages, but simply ignored for further
processing. In such cases where individual messages cannot be
deleted, in this document "disregarded" means "ignored". Otherwise,
any such "disregarded" AODVv2 messages SHOULD be deleted from
the aggregated messages in the RFC 5444 packet.
</t>
</section>
<!-- ============================================================= -->
<section anchor="seqnum" title="AODVv2 Sequence Numbers">
<t>AODVv2 sequence numbers allow AODVv2 routers to evaluate the
freshness of routing information.
Proper maintenance of sequence numbers assures that the
destination sequence number value stored by intermediate
AODVv2 routers is monotonically increasing
along any path from any source to the destination.
As a consequence, loop freedom is assured.</t>
<!-- TODO: enable Seq# == 0 -->
<t>Each AODVv2 router in the network MUST maintain its own
sequence number (OwnSeqNum, a 16-bit unsigned integer).
An AODVv2 router increments its OwnSeqNum as follows.
Most of the time, OwnSeqNum is incremented by simply
adding one (1). But to increment OwnSeqNum when it has the value
of the largest largest possible number representable as a 16-bit
unsigned integer (i.e., 65,535), it MUST be set to one (1). In other
words, the sequence number after 65,535 is 1.</t>
<t> An AODVv2 router SHOULD maintain OwnSeqNum in persistent storage.
If an AODVv2 router's OwnSeqNum is lost, it MUST take the
following actions to avoid the danger of routing loops.
First, the AODVv2 router MUST invalidate all route table
entries, by setting Route.Broken for each entry.
Furthermore the AODVv2 router MUST
wait for at least MAX_SEQNUM_LIFETIME before transmitting or
retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2
protocol message is received during this waiting period, the
AODVv2 router SHOULD perform normal route table entry updates.
<!-- TODO: CEP: What about relaying RREQ? -->
If a data packet is received for forwarding to another
destination during this waiting period, the AODVv2 router MUST
transmit a RERR message indicating that no route is available.
At the end of the waiting period the AODVv2
router sets its OwnSeqNum to one (1) and begins
performing AODVv2 protocol functions again.</t>
<!-- TODO: CEP: Actually, could forward...? -->
<!-- TODO: CEP: Actually, usual RERR rules? -->
</section>
<section anchor="metrics" title="Enabling Alternate Metrics">
<t>Route selection in AODVv2 MANETs depends upon associating metric
information with each route table entry. When presented
with candidate route update information, deciding
whether to use the update involves evaluating the metric.
Some applications may require the consideration of metric
information other than Hop Count, which has traditionally been
the default metric associated with routes in MANET.
In fact, it is well known that reliance on Hop Count can
cause selection of the worst possible route in many situations.
</t>
<t>It is beyond the scope of this document to describe how
applications specify route selection at the time they
launch processing. One possibility would be to provide a
route metric preference as part of the library routines for
opening sockets. In view of the above considerations,
it is important to enable route selection based on metric
information other than Hop Count -- in other words, based on
"alternate metrics". Each such alternate metric identifies a
"cost" of using the associated route, and there are many
different kinds of cost (latency, delay, financial, energy,
etc.).
</t>
<t>The most significant change when enabling use of alternate metrics is
to require the possibility of multiple routes to the same
destination, where the "cost" of each of the multiple routes is
measured by a different alternate metric. The other change
relevant to AODVv2 is that the method by which route updates
are tested for usefulness has to be slightly generalized to
depend upon a more abstract method of evaluation which, in this
document, is named "Cost(R)", where 'R' is the route information
to be evaluated.
From the above, the route table information for 'R' must
always include the type of metric by which Cost(R) is evaluated,
so the metric type does not have to be shown as a distinct
parameter for Cost(R).
Since determining loop freedom is known to depend
on comparing the Cost(R) of route update information to the
Cost(R) of an existing stored route using the same metric,
AODVv2 must also be able to invoke an abstract
routine which in this document is called "LoopFree(R1, R2)".
LoopFree(R1, R2) returns TRUE when, given that R2 is
loop-free and Cost(R2) is the cost of route R2, Cost(R1) is
known to guarantee loop freedom of the route R1.
In this document, LoopFree(R1,R2) will only be invoked for
routes R1 and R2 which use the same metric.
</t>
<t>Generally, HopCount may still be considered the default metric for
use in MANETs, notwithstanding the above objections. Each
metric has to have a Metric Type, and the Metric Type is
allocated by IANA as specified in <xref target="RFC6551"/>.
Each Route has to include the Metric Type as part of the
route table entry for that route.
Hop Count has Metric Type assignment 3. The Cost of a
route using Metric Type 3 is naturally the Hop Count between
the router and the destination. For routes R1 and R2 using
Metric Type 3, LoopFree (R1, R2) is TRUE when
Cost(R2) ≤ (Cost(R1) + 1). The specification of
Cost(R) and LoopFree(R1,R2) for metric types other than
3 is beyond the scope of this document.
</t>
<t>Whenever an AODV router receives metric information in an
incoming message, the value of the metric is as measured
by the transmitting router, and does not reflect the cost
of traversing the incoming link. In order to simplify the
description of storing accrued route costs in the route
table, the Cost() function is also defined to return the
value of traversing a link 'L'. In other words, the domain
of the Cost() function is enlarged to include links as well
as routes.
For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1
for all links.
The specification of Cost(L) for metric types other than
3 is beyond the scope of this document. Whether the argument
of the Cost() function is a link or a route will, in this
document, always be clear. As a natural result of the way
routes are looked up according to conformant metric type,
all intermediate routers handling a RteMsg will assign the
same metric type to all metric information in the RteMsg.
</t>
<t>For some metrics, a maximum value is defined, namely MAX_METRIC[i]
where 'i' is the Metric Type. AODVv2 does not store routes
that cost more than MAX_METRIC[i]. MAX_METRIC[3] is defined
to be MAX_HOPCOUNT, where as before 3 is the Metric Type of
the HopCount metric.
</t>
<!--
<t>For this purpose, a list of IP addresses nodes along with
relevant prefixes must be configured on each AODVv2:
<list style="hanging">
<t hangText="Client IP address"><vspace />The IP address of the
node that requires routing service from the AODVv2 router.</t>
<t hangText="Client Prefix Length"><vspace />The length of the
routing prefix associated with the client IP address.
</t>
</list>
</t>
<t>xxxxxxxxxxxxx
</t>
-->
</section>
</section>
<section title="AODVv2 Operations on Route Table Entries">
<t> In this section, operations are specified for updating
the route table due to timeouts and route updates
within AODVv2 messages. The route update information
in AODVv2 messages includes the destination IP address (DestIP),
SeqNum and prefix length associated with DestIP, and the
Metric from DestIP to the node transmitting the AODVv2
message. DestIP information and prefix length are encoded
within an RFC 5444 Address Block, and the SeqNum and Metric
associated with each DestIP are encoded in RFC 5444 AddrTLVs.
Optionally, there may be AddedNode route updates included
in AODVv2 messages, as specified in <xref target="RM_addl"/>.
In this section, RteMsg is either RREQ or RREP, RteMsg.Addr
denotes the [i]th address in an RFC 5444 AddrBlk of the RteMsg,
RteMsg.PfxLen denotes the associated prefix length for
RteMsg.Addr, and RteMsg.{field} denotes the corresponding
value in the named AddrTLV block associated with RteMsg.Addr.
All SeqNum comparisons use signed 16-bit arithmetic. </t>
<section anchor="test"
title="Evaluating Incoming Routing Information">
<t> If the incoming RteMsg does not have a MetricTypeTLV, then
the metric information contained by RteMsg is considered to
be of type DEFAULT_METRIC_TYPE.
Whenever an AODVv2 router (HandRtr) handles an incoming RteMsg
(i.e., RREQ or RREP), for every relevant address (RteMsg.Addr)
in the RteMsg, HandRtr searches its route table to see if
there is a route table entry with the same MetricType of
the RteMsg, matching RteMsg.Addr. If not,
HandRtr creates a route table entry for RteMsg.Addr as described
in <xref target="update_rte"/>.
Otherwise, HandRtr compares
the incoming routing information in RteMsg against the
already stored routing information in the route table
entry (Route) for RteMsg.Addr, as described below.
</t>
<t>Suppose a route table entry (Route[RteMsg.Addr]) uses the same
metric type as the incoming routing information, and contains
Route.SeqNum, Route.Metric, and Route.Broken. Suppose the
incoming routing information for Route.Addr is RteMsg.SeqNum
and RteMsg.Metric. The incoming routing
information is compared as follows:
<list style="hanging">
<t hangText="1. Stale::">
<![CDATA[ RteMsg.SeqNum < Route.SeqNum : ]]><vspace />
If RteMsg.SeqNum < Route.SeqNum
the incoming information is stale. Using stale
routing information is not allowed, since that might
result in routing loops. HandRtr MUST disregard the
routing information for RteMsg.Addr.
</t>
<t hangText="2. Unsafe against loops::">
<![CDATA[ (TRUE != LoopFree (RteMsg, Route)) :]]><vspace/>
If RteMsg is not Stale (as in (1)), RteMsg.Metric is next
considered to insure loop freedom.
If (TRUE != LoopFree (RteMsg, Route))
(see <xref target="metrics"/>), then the
incoming RteMsg information is not guaranteed to prevent routing
loops, and it MUST NOT be used.
</t>
<t hangText="3. Longer::"><vspace /><![CDATA[
(RteMsg.Metric >= Route.Metric) && (Route.Broken==FALSE)]]>
<vspace />
When RteMsg.SeqNum is the same as in a valid route table
entry, and LoopFree (RteMsg, Route) assures loop freedom,
incoming information still does not offer any improvement over
the existing route table information if
RteMsg.Metric ≥ Route.Metric.
Using such incoming routing information to update a route
table entry is not recommended.</t>
<t hangText="4. Offers improvement::"><vspace /> Incoming
routing information that does not match any of the above
criteria is better than existing routing table information and
SHOULD be used to improve the route table.
The following pseudo-code illustrates whether incoming
routing information should be used to update an existing
route table entry as described in <xref target="update_rte"/>.
<figure>
<artwork><![CDATA[
(RteMsg.SeqNum > Route.SeqNum) OR
{(RteMsg.SeqNum == Route.SeqNum) AND
[(RteMsg.Metric < Route.Metric) OR
((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]}
]]></artwork>
</figure>
The above logic corresponds to placing the following conditions
on the incoming route update (compared to the existing route
table entry) before it can be used:
<list style="symbols"><t>it is more recent, or</t>
<t>it is not stale and is shorter, or</t>
<t>it can safely repair a broken route.</t>
</list></t>
</list></t>
</section>
<section anchor="update_rte"
title="Applying Route Updates To Route Table Entries">
<t>To apply the route update, the route table entry is populated
with the following information:
<list style="symbols">
<t>Route.Address := RteMsg.Addr</t>
<t>If (RteMsg.PfxLen != 0), then Route.PfxLen := RteMsg.PfxLen</t>
<t>Route.SeqNum := RteMsg.SeqNum</t>
<t>Route.NextHopAddress := IP.SourceAddress (i.e., an
address of the node from which the RteMsg was received)</t>
<t>Route.NextHopInterface is set to the interface on which
RteMsg was received</t>
<t>Route.Broken flag := FALSE</t>
<t>If RteMsg.MetricType is included, then <vspace/>
Route.MetricType := RteMsg.MetricType.
Otherwise, Route.MetricType := DEFAULT_METRIC_TYPE.</t>
<t>Route.MetricType := RteMsg.MetricType</t>
<t>Route.Metric := RteMsg.Metric</t>
<t>Route.LastUsed := Current_Time</t>
<t>If RteMsg.VALIDITY_TIME is not included, then <vspace/>
Route.ExpirationTime := MAXTIME, otherwise
Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME
</t>
</list>
</t>
<t>With these assignments to the route table entry, a route has been
made available, and the route can be used to send any buffered data
packets and subsequently to forward any incoming data packets for
Route.Addr. An updated route entry also fulfills any outstanding route
discovery (RREQ) attempts for Route.Addr.</t>
</section>
<section anchor="timeout" title="Route Table Entry Timeouts">
<t>During normal operation, AODVv2 does not require any
explicit timeouts to manage the lifetime of a route.
However, the route table entry MUST be examined be
before using it to forward a packet,
as discussed in <xref target="e2edata"/>.
Any required expiry or deletion can occur at
that time. Nevertheless, it is permissible to
implement timers and timeouts to achieve the
same effect.</t>
<t>At any time, the route table can be examined and route
table entries can be expunged according to their
current state at the time of examination, as follows.
<list style="symbols">
<t>An Active route MUST NOT be expunged.</t>
<t>An Idle route SHOULD NOT be expunged.</t>
<t>An Expired route MAY be expunged
(least recently used first).</t>
<t>A route MUST be expunged if
(Current_Time - Route.LastUsed) >= MAX_SEQNUM_LIFETIME.
</t>
<t>A route MUST be expunged if
Current_Time >= Route.ExpirationTime </t>
</list>
If precursor lists are maintained for the route
(as described in <xref target="precursor"/>)
then the precursor lists must also be expunged at the
same time that the route itself is expunged.
</t>
</section>
</section>
<section anchor="RteMsg" title="Routing Messages RREQ and RREP (RteMsgs)">
<t>AODVv2 message types RREQ and RREP are together known as Routing
Messages (RteMsgs) and are used to discover a route between
an Originating and Target Node, denoted here by OrigNode and
TargNode. The constructed route is bidirectional, enabling
packets to flow between OrigNode and TargNode. RREQ and RREP
have similar information and function, but have some
differences in their rules for handling. The main difference
between the two messages is that RREQ messages are typically
multicast to solicit a RREP, whereas RREP is typically
unicast as a response to RREQ.</t>
<!--
RteMsg generation and
handling are described in <xref target="RteMsg"/>.
-->
<t>When an AODVv2 router needs to forward a data packet
from a node (OrigNode) in its set of router clients, and it
does not have a forwarding route toward the packet's IP
destination address (TargNode), the AODVv2 router
(in this section, called RREQ_Gen) generates a
RREQ (as described in <xref target="RREQ_gen" />) to
discover a route toward TargNode. Subsequently RREQ_Gen awaits
reception of an RREP message (see <xref target="RREP_gen"/>)
or other route table update (see <xref target="update_rte"/>)
to establish a route toward TargNode.
The RREQ message contains routing information to enable
RREQ recipients to route packets back to OrigNode, and the
RREP message contains routing information enabling RREP
recipients to route packets to TargNode.</t>
<section anchor="route_discovery"
title="Route Discovery Retries and Buffering">
<t>After issuing a RREQ, as described above RREQ_Gen
awaits a RREP providing a bidirectional route toward Target Node.
If the RREP is not received within RREQ_WAIT_TIME, RREQ_Gen may retry
the Route Discovery by generating another RREQ. Route
Discovery SHOULD be considered to have failed after
DISCOVERY_ATTEMPTS_MAX and the corresponding
wait time for a RREP response to the final RREQ.
After the attempted Route Discovery has failed, RREQ_Gen
MUST wait at least RREQ_HOLDDOWN_TIME before attempting
another Route Discovery to the same destination.
</t>
<t>To reduce congestion in a network, repeated attempts at
route discovery for a particular Target Node SHOULD utilize an
binary exponential backoff.</t>
<t>Data packets awaiting a route SHOULD be buffered by RREQ_Gen.
This buffer SHOULD have a fixed limited
size (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining
which packets to discard first is a matter of policy at each
AODVv2 router; in the absence of policy constraints, by
default older data packets SHOULD be discarded first.
Buffering of data packets can have both positive and
negative effects (albeit usually positive). Nodes without sufficient
memory available for buffering SHOULD be configured to disable buffering
by configuring BUFFER_SIZE_PACKETS == 0 and BUFFER_SIZE_BYTES == 0.
Doing so will affect the latency
required for launching TCP applications to new destinations.</t>
<t>If a route discovery attempt has failed (i.e.,
DISCOVERY_ATTEMPTS_MAX attempts have been made without
receiving a RREP) to
find a route toward the Target Node, any data packets buffered for
the corresponding Target Node MUST BE dropped and a Destination
Unreachable ICMP message (Type 3) SHOULD be delivered to the
source of the data packet. The code for the ICMP message is 1
(Host unreachable error). If RREQ_Gen is not the source
(OrigNode), then
the ICMP is sent over the interface from which OrigNode sent the
packet to the AODVv2 router. </t>
</section>
<section anchor="RteMsgStruct" title="RteMsg Structure">
<t>RteMsgs have the following general format:</t>
<t><figure anchor="figRteMsg"
title="RREQ and RREP (RteMsg) message structure">
<artwork><![CDATA[
+---------------------------------------------------------------+
| RFC 5444 Packet Header |
+---------------------------------------------------------------+
| RFC 5444 Message Header <msg-hopcount> |
+---------------------------------------------------------------+
| RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV |
+---------------------------------------------------------------+
| RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)} |
+---------------------------------------------------------------+
| RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) |
+---------------------------------------------------------------+
| Added Node Address Block (Optional) |
+---------------------------------------------------------------+
| Added Node Address TLV (SeqNum) |
+---------------------------------------------------------------+
| Added Node Address TLV (Metric[MetricType]) |
+---------------------------------------------------------------+
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Message Header"><vspace />This is typically mostly
boilerplate but can contain MsgTLVs as below.</t>
<t hangText="DestOnly TLV"><vspace />RREQ only: no Intermediate RREP.
</t>
<t hangText="MetricType TLV"><vspace />Metric Type for Metric AddrTLV
</t>
<t hangText="RteAddrBlk"><vspace />
This Address Block contains the IP addresses for RREQ
Originating and Target Node (OrigNode and TargNode).
Note that for both RREP and RREQ, the OrigNode and
TargNode are as identified in the context of the RREQ message
originator.
</t>
<t hangText="RteSeqNumTLV (Sequence Number AddrTLV)"><vspace />
This Address Block TLV is REQUIRED and carries the
destination sequence numbers associated with either
OrigNode or TargNode or both.</t>
<t hangText="(Optional) Added Node AddrBlk">
<vspace /> AODVv2 allows the inclusion of routing
information for other nodes in addition to OrigNode
and TargNode.</t>
<t hangText="(Optional) SeqNum AddrTLV">
If the Added Node AddrBlk is present, the SeqNum AddrTLV
is REQUIRED, to carry the destination sequence numbers
associated with the Added Nodes.</t>
<t hangText="(Optional) Metric AddrTLV">
If the Added Node AddrBlk is present, this AddrTLV
is REQUIRED, to carry the metric information associated
with the Added Nodes. See Below.</t>
</list>
The metric AddrTLV may be either a Metric8
AddrTLV or an Metric16 AddrTLV.</t>
</section>
<section anchor="RREQ_gen" title="RREQ Generation">
<t>RREQ_Gen generates the RREQ according to the following steps, with
order of protocol elements illustrated schematically
in <xref target="figRteMsg" />.
<list style="numbers">
<t>RREQ_Gen MUST increment its OwnSeqNum by one (1) according
to the rules specified in <xref target="seqnum" />. This assures that
all nodes with existing routing information will
use RREQ_Gen's new information to update existing routing
table information.</t>
<t>
OrigNode MUST be a unicast address. If RREQ_Gen is not OrigNode,
then OwnSeqNum will be used as the value of OrigNode.SeqNum.
will be used by AODVv2 routers to create a
route toward the OrigNode, enabling a RREP from TargRtr, and
eventually used for proper forwarding of data packets.</t>
<t>If RREQ_Gen requires that only TargRtr is allowed to generate a
RREP, then RREQ_Gen includes the "Destination RREP Only" TLV as part
of the RFC 5444 message header.
This also assures that TargRtr increments its sequence number.
Otherwise, intermediate AODVv2
routers MAY respond to the RREQ_Gen's RREQ if they have an
valid route to TargNode (see <xref target="iRREP" />).</t>
<t>msg-hopcount MUST be set to 0.
<list style="symbols"><t>This RFC 5444 constraint causes the typical
RteMsg payload incur additional enlargement.</t>
</list></t>
<t>RREQ_Gen adds the TargNode.Addr to the RREQ.</t>
<t>If a previous value of the TargNode's SeqNum is known (e.g.,
from an invalid routing table entry using longest-prefix matching),
RREQ_Gen SHOULD include TargNode.SeqNum in all but
the last RREQ attempt. If TargNode.SeqNum is not included,
it is assumed to be unknown by AODVv2 routers handling the RREQ;
if the optional feature Intermediate RREP is enabled, then any route
to TargNode
will satisfy the RREQ <xref target="I-D.perkins-irrep"/>.</t>
<t>RREQ_Gen adds OrigNode.Addr, its prefix,
and the RREQ_Gen.SeqNum (OwnSeqNum) to the RREQ.</t>
<t>If OrigNode.Metric is included it is set to
the cost of the route between OrigNode and RREQ_Gen.</t>
</list></t>
<t>An example RREQ message format
is illustrated in <xref target="RREQ-format" />.</t>
</section>
<section anchor="RREP_gen" title="RREP Generation">
<!-- CEP: prefix is associated with the OrigNode or TargNode, not the router -->
<t>An AODVv2 router (TargRtr, called in this section RREP_Gen)
generates a RREP in order to provide a route to the Target Node
(TargNode) of a RREQ, thus satisfying the routing requirement for
packets to flow between OrigNode and TargNode. This section
specifies the generation of an RREP by the RREP_Gen.
The basic format of an RREP conforms to the structure for
RteMsgs as illustrated in <xref target="figRteMsg"/>.
Optionally, RREP messages may be generated by AODVv2 routers
other than TargRtr; this optional message generation is known
as "Intermediate RREP" generation, and is specified in Internet
Draft <xref target="I-D.perkins-irrep"/>.
If TargNode is not a unicast IP address the RREP MUST NOT
be generated, and processing for the RREQ is complete.</t>
<t>Otherwise RREP_Gen generates the RREP as follows:
<list style="numbers">
<t>RREP_Gen first uses the routing information to update its
route table entry for OrigNode if necessary as specified
in <xref target="update_rte"/>.</t>
<t>RREP_Gen MUST increment its OwnSeqNum by one (1) according to the
rules specified in <xref target="seqnum" />.</t>
<t>RREP.AddrBlk[OrigNode] := RREQ.AddrBlk[OrigNode]</t>
<t>RREP.AddrBlk[TargNode] := RREQ.AddrBlk[TargNode]</t>
<t>RREP.SeqNumTLV[OrigNode] := RREQ.SeqNumTLV[OrigNode]</t>
<t>RREP.SeqNumTLV[TargNode] := OwnSeqNum</t>
<t>If Route[TargNode].PfxLen/8 is equal to the number of bytes in the
addresses of the RREQ (4 for IPv4, 16 for IPv6),
then no <prefix-length> is included with the iRREP.
Otherwise, RREP.PfxLen[TargNode] := RREQ.PfxLen[TargNode]
according to the rules of RFC 5444 AddrBlk encoding. </t>
<t>RREP.MetricType[TargNode] := Route[TargNode].MetricType</t>
<t>RREP.Metric[TargNode] := Route[TargNode].Metric</t>
<t><msg-hop-limit> SHOULD be set to
RteMsg.<msg-hop-count>.</t>
<t>IP.DestinationAddr := Route[OrigNode].NextHop</t>
</list></t>
<t>The message format for RREP
is illustrated in <xref target="RREP-format" />.</t>
</section>
<section anchor="RM_hand" title="Handling a Received RteMsg">
<t>Before an AODVv2 router (HandlingRtr) can process a received RteMsg
(i.e., RREQ or RREP), it first must verify that the RteMsg
is permissible according to the following steps.
For RREQ, RteMsg_Gen is OrigRtr, also called RREQ_Gen.
For RREP, RteMsg_Gen is TargRtr, also called RREP_Gen.
<list style="numbers">
<t>HandlingRtr MUST handle AODVv2 messages only from adjacent
routers as specified in <xref target="MsgStruct" />.
AODVv2 messages from other sources MUST be disregarded.
</t>
<t>If the RteMsg.<msg-hop-limit> is equal to 0,
then the message is disregarded.
</t>
<t>If the RteMsg.<msg-hop-count> is present,
and RteMsg.<msg-hop-count> ≥ MAX_HOPCOUNT,
then the message is disregarded.
</t>
<t>HandlingRtr examines the RteMsg to ascertain that it contains
the required information: TargNode.Addr, OrigNode.Addr,
RteMsg_Gen.Metric and RteMsg_Gen.SeqNum. If the required
information does not exist, the message is disregarded.</t>
<t>HandlingRtr checks that OrigNode.Addr and TargNode.Addr are valid
routable unicast addresses. If not, the message is disregarded.</t>
<t>HandlingRtr checks that the Metric Type associated with
OrigNode.Metric and TargNode.Metric is known, and that Cost(L)
can be computed. If not, the message is disregarded.
<list style="symbols">
<t>DISCUSSION: alternatively, can change the AddrBlk metric
to use HopCount, measured from<msg-hop-limit>.
</t>
</list></t>
<t>If MAX_METRIC[RteMsg.MetricType] ≤
(RteMsg_Gen.Metric + Cost(L)), where 'L' is the incoming link,
the RteMsg is disregarded.</t>
</list></t>
<t>An AODVv2 router (HandlingRtr) handles a permissible RteMsg
according to the following steps.
<list style="numbers">
<t>HandlingRtr MUST process the routing information
contained in the RteMsg as speciied in
<xref target="test" />.
</t>
<t>HandlingRtr MAY process AddedNode routing information
(if present) as specified in <xref target="addl-append" />
Otherwise, if AddedNode information is not processed, it
MUST be deleted.</t>
<t>By sending the updated RteMsg, HandlingRtr advertises that it
will route for addresses contained in the outgoing
RteMsg based on the information enclosed. HandlingRtr MAY choose
not to send the RteMsg, though not resending this RteMsg could
decrease connectivity in the network or result in a nonoptimal path.
The circumstances under which HandlingRtr might choose to not
re-transmit a RteMsg are not specified in this document. Some
examples might include the following:
<list style="symbols">
<t>HandlingRtr is already heavily loaded and does not want
to advertise routing for the contained addresses</t>
<t>HandlingRtr recently transmitted identical routing
information
(e.g. in a RteMsg advertising the same metric)</t>
<t>HandlingRtr is low on energy and has to reduce energy
expended for sending protocol messages or
packet forwarding</t>
</list>
Unless HandlingRtr is prepared to send an updated RteMsg,
it halts processing. Otherwise, processing continues
as follows.</t>
<t>HandlingRtr MUST decrement RteMsg.<msg-hop-limit>. If
RteMsg.<msg-hop-limit> is then zero (0),
no further action is taken.</t>
<t>HandlingRtr MUST increment RteMsg.<msg-hop-count>.</t>
</list>
Further actions to send an updated RteMsg depend upon whether
the RteMsg is an RREP or an RREQ</t>
<section anchor="RREQ_handle"
title="Additional Handling for Outgoing RREQ">
<t><list style="symbols">
<t>If the upstream router is in the Blacklist, and
Current_Time < BlacklistRmTime, then HandlingRtr MUST NOT
transmit any outgoing RREQ, and processing is complete.</t>
<t>Otherwise, if the upstream router is in the Blacklist, and
Current_Time ≥ BlacklistRmTime, then the upstream router
SHOULD be removed from the Blacklist, and message processing
continued.</t>
<t>If TargNode is a client of HandlingRtr, then
a RREP is generated by the HandlingRtr (i.e., TargRtr)
and unicast to the upstream router towards the RREQ OrigNode,
as specified in <xref target="RREP_gen" />. Afterwards,
TargRtr processing for the RREQ is complete.</t>
<t>If HandlingRtr is not the TargetNode,
then the outgoing RREQ (as altered by the procedure defined above)
SHOULD be sent to the IP multicast address LL-MANET-Routers
<xref target="RFC5498" />. If the RREQ is unicast, the
IP.DestinationAddress is set to the NextHopAddress.</t>
</list></t>
</section>
<section anchor="RREP_handle"
title="Additional Handling for Outgoing RREP">
<t><list style="symbols">
<t>If HandlingRtr is not OrigRtr then the outgoing RREP is sent to the
Route.NextHopAddress for the RREP.AddrBlk[OrigNode]. If
no forwarding route exists to OrigNode, then a RERR
SHOULD be transmitted to RREP.AddrBlk[TargNode]. See
<xref target="notational-conventions"/> for notational
conventions; OrigRtr, OrigNode, and TargNode are routers
named in the context of OrigRtr, that is, the router originating
the RREQ to which the RREP is responding.
</t>
</list></t>
</section>
<!-- CEP: TODO: Should specify that repeated RREQs deserve more attention -->
</section>
</section>
<section anchor="route_maint" title="Route Maintenance">
<t> AODVv2 routers attempt to maintain active routes. When a routing
problem is encountered, an AODVv2 router (namely, RERR_Gen)
attempts to quickly
notify upstream routers. Two kinds of routing problems may
trigger generation of a RERR message.
The first case happens when the router receives a packet
but does not have a route for the destination of the packet.
The second case happens immediately upon detection of a broken link
(see <xref target="link_breaks" />) of an Active route, to
quickly notify AODVv2 routers that that route is no
longer available. When the RERR message is generated, it MUST
be the only message in the RFC 5444 packet.
</t>
<section anchor="e2edata"
title="Handling Route Lifetimes During Packet Forwarding">
<t>Before using a route to forward a packet, an AODVv2 router MUST
check the status of the route as follows.
<list>
<t>If the route is marked has been
marked as Broken, it cannot be used for forwarding.</t>
<t>If Current_Time > Route.ExpirationTime, the route table
entry has expired, and a RERR SHOULD be generated.</t>
<t>Similarly, if (Route.ExpirationTime == MAXTIME), and if
Current_Time - Route.LastUsed > (ACTIVE_INTERVAL+MAX_IDLETIME),
the route has expired, and a RERR SHOULD be generated.</t>
<t>Furthermore, if Current_Time - Route.LastUsed >
(MAX_SEQNUM_LIFETIME), the
route table entry MUST be expunged.</t>
</list></t>
<t>Otherwise, if none of the above route error conditions are
indicated, Route.LastUsed := Current_Time, and
the packet is forwarded to the route's next hop.</t>
<t>Optionally, if a precursor list is maintained for the route, see
<xref target="precursor" /> for precursor lifetime operations.</t>
</section>
<section anchor="link_breaks" title="Active Next-hop Router
Adjacency Monitoring">
<t>Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2
routers on forwarding routes. This monitoring can be
accomplished by one or several mechanisms, including:</t>
<t><list style="symbols">
<t>Neighborhood discovery <xref target="RFC6130" /></t>
<t>Route timeout</t>
<t>Lower layer trigger that a neighboring
router is no longer reachable</t>
<t>Other monitoring mechanisms or heuristics</t>
</list>
</t>
<t>Upon determining that a next-hop AODVv2 router has become
unreachable, RERR_Gen follows the procedures specified
in <xref target="rerr_gen_2"/>. </t>
</section>
<section anchor="rerr_gen" title="RERR Generation">
<t> An RERR message is generated by a AODVv2 router (in this section,
called RERR_Gen) in order to to notify upstream routers that
packets cannot be delivered to certain destinations.
An RERR message has the following general structure:
<figure anchor="figRERRstruct" title="RERR message structure">
<artwork><![CDATA[
+---------------------------------------------------------------+
| RFC 5444 Packet Header |
+---------------------------------------------------------------+
| RFC 5444 Message Header <msg-hoplimit> <msg-hopcount> |
+---------------------------------------------------------------+
| UnreachableNode AddrBlk (Unreachable Node addresses) |
+---------------------------------------------------------------+
| UnreachableNode SeqNum AddrBlk TLV |
+---------------------------------------------------------------+
]]></artwork>
</figure></t>
<t> <list style="hanging">
<t hangText="Message Header"><vspace />RFC 5444 MsgHdr
may contain the following options:
<list style="symbols">
<t><msg-hop-limit></t>
<t><msg-hop-count></t>
<t>PktSource MsgTLV</t>
</list> </t>
<t hangText="UnreachableNode AddrBlk"><vspace />
This Address Block contains the IP addresses
unreachable by AODVv2 router transmitting
the RERR.</t>
<t hangText="Sequence Number AddrBlk TLV"><vspace />
This Address Block TLV carries the
destination sequence number associated
with the UnreachableNodes when that information
is available. </t>
<t hangText="UnreachableNode.PfxLen"><vspace />
The prefix length associated with an UnreachableNode.</t>
</list> </t>
<!-- TODO: redraw these, or else replace with text...
<t><figure anchor="figRERR">
<preamble>Example IPv4 RERR</preamble>
<artwork><![CDATA[
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
IP Header
+-+-+-+-+-+-+-+-+
| IP.Proto = UDP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.SourceAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.DestinationAddress = LL-MANET-Routers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = manet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Header
+-+-+-+-+-+-+-+-+
| ver=0 |0|0|0|0|
+-+-+-+-+-+-+-+-+
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RERR-type |0|1|0|0| MAL=3 | msg-size=15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit |
+-+-+-+-+-+-+-+-+
Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=1 |0|0|0|0|0| Rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnreachableNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-blk-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
-->
<t>
There are two kinds of events indicating that packets cannot
be delivered to certain destinations.
The two cases differ in the way that the neighboring
IP destination address for the RERR (i.e., RERR_dest) is chosen,
and in the way that the set of UnreachableNodes is identified.
</t>
<t>
In both cases, the MsgHdr.<msg-hop-limit> MUST be set to
MAX_HOPCOUNT. MsgHdr.<msg-hop-count> SHOULD be be included
and set to 0, to facilitate use of various route repair strategies
including Intermediate RREP <xref target="I-D.perkins-irrep"/>.</t>
<section anchor="rerr_gen_1" title="Case 1: Undeliverable Packet">
<t>
The first case happens when the router receives a packet but
does not have a valid route for the destination of the packet.
In this case, there is exactly one UnreachableNode to be
included in the RERR's AddrBlk.
RERR_dest SHOULD be the multicast address
LL-MANET-Routers, but RERR_Gen MAY instead set RERR_dest
to be the next hop towards the source IP address of the
packet which was undeliverable. In the latter case, the
PktSource MsgTLV MUST be included, containing the
the source IP address of the undeliverable packet.
If a value for the
UnreachableNode's SeqNum (UnreachableNode.SeqNum) is
known, it MUST be placed in the RERR.
Otherwise, if no Seqnum AddrTLV is included, all nodes handling
the RERR will assume their route through RERR_Gen towards
the UnreachableNode is no
longer valid and flag those routes as broken.
RERR_Gen MUST discard the packet or
message that triggered generation of the RERR.
</t>
<!-- NOTE: CEP: Verify unicast delivery of IP multicast packets ... -->
<!--
If the neighbor's IP address is
unavailable, RERR_Gen MAY attempt layer-2 unicast delivery
to the multicast address LL-MANET-Routers.
-->
</section>
<section anchor="rerr_gen_2" title="Case 2: Broken Link">
<!-- NOTE: CEP: Should this case (unrelated to packet delivery)
be moved to "Optional"? ... -->
<t> The second case happens when the link breaks to an active
downstream neighbor (i.e., the next hop of an active route).
In this case, RERR_dest MUST be the multicast address
LL-MANET-Routers, except when the optional
feature of maintaining precursor lists is used as specified
in <xref target="precursor"/>.
All Active, Idle and Expired routes that use the broken
link MUST be marked as Broken.
The set of UnreachableNodes is initialized by identifying
those Active routes which use the broken link.
For each such Active Route, Route.Dest is added to the
set of Unreachable Nodes.
After the Active Routes using the broken link have all been
included as UnreachableNodes, idle routes MAY also be included,
as long as the packet size of the RERR does not exceed the
MTU of the physical medium.
</t>
<t> If the set of UnreachableNodes is empty, no RERR is
generated. Otherwise, RERR_Gen generates a new RERR,
and the address of each UnreachableNode
(IP.DestinationAddress from a data packet or
RREP.TargNode.Address) is inserted into an AddrBlock.
If a prefix is known for the UnreachableNode.Address, it SHOULD
be included. Otherwise,
the UnreachableNode.Address is assumed to be a host address
with a full length prefix.
The value for each UnreachableNode's SeqNum (UnreachableNode.SeqNum)
MUST be placed in a SeqNum AddrTLV.
If none of UnreachableNode.Addr entries are associated with
known prefix lengths, then the AddrBLK SHOULD NOT include
any prefix-length information. Otherwise, for each
UnreachableNode.Addr that does not have any associated
prefix-length information, the prefix-length for that
address MUST be assigned to zero.
</t>
<!-- <c>UnreachAddrBlk</c> <c>Unreachable Node AddrBlk in RERR</c> -->
</section>
</section>
<section anchor="rerr_hand"
title="Receiving and Handling RERR Messages">
<t>When an AODVv2 router (HandlingRtr) receives a RERR message, it
uses the information provided to invalidate affected routes.
If the information in the RERR may be useful to upstream
neighbors using those routes, HandlingRtr subsequently sends
another RERR to those neighbors. This operation has the
effect of retransmitting the RERR information and is
counted as another "hop" for purposes of properly modifying
Msg.<msg-hop-limit> and Msg.<msg-hop-count>.
</t>
<t>HandlingRtr examines the incoming RERR to assure that it
contains Msg.<msg-hop-limit> and at least one
UnreachableNode.Address. If the required information does not exist,
the incoming RERR message is disregarded and further processing
stopped. Otherwise, for each UnreachableNode.Address, HandlingRtr
searches its route table for a route using longest prefix matching.
If no such Route is found, processing is complete for that
UnreachableNode.Address. Otherwise, HandlingRtr verifies the
following:
<list style="numbers">
<t>The UnreachableNode.Address is a routable
unicast address.</t>
<t>Route.NextHopAddress is the same as RERR
IP.SourceAddress.</t>
<t>Route.NextHopInterface is the same as the interface on
which the RERR was received.</t>
<!-- TODO?: CEP: the route should be invalidated regardless of SeqNum -->
<t>The UnreachableNode.SeqNum is unknown, OR
Route.SeqNum <= UnreachableNode.SeqNum (using
signed 16-bit arithmetic).</t>
</list>
</t>
<t> If the route satisfies all of the above conditions, HandlingRtr
sets the Route.Broken flag for that route. Furthermore, if
Msg.<msg-hop-limit> is greater than 0, then HandlingRtr adds
the UnreachableNode address and TLV information to an AddrBlk for
for delivery in the outgoing RERR message to one or more
of HandlingRtr's upstream neighbors.</t>
<t>If there are no UnreachableNode addresses to be transmitted
in an RERR to upstream routers, HandlingRtr MUST discard
the RERR, and no further action is taken.</t>
<t>Otherwise, Msg.<msg-hop-limit> is decremented by one (1) and
processing continues as follows:
<list style="symbols">
<t>If precursor lists are (optionally) maintained, the outgoing RERR
SHOULD be sent
to the active precursors of the broken route as specified
in <xref target="precursor"/>.</t>
<t>Otherwise, if the incoming RERR message was received at the
LL-MANET-Routers <xref target="RFC5498" /> multicast address,
the outgoing RERR SHOULD also be sent to LL-MANET-Routers.</t>
<t>Otherwise, if the PktSource MsgTLV is present, and HandlingRtr has a
Route to PktSource.Addr, then HandlingRtr MUST send the
outgoing RERR to Route[PktSource.Addr].NextHop.</t>
<t>Otherwise, the outgoing RERR MUST be sent to LL-MANET-Routers.</t>
</list>
</t>
</section>
</section>
<section anchor="unknown"
title="Unknown Message and TLV Types">
<t>If a message with an unknown type is received, the message
is disregarded.</t>
<t>For handling of messages that contain unknown TLV types,
ignore the information for processing, preserve it
unmodified for forwarding.</t>
</section>
<section anchor="gateway"
title="Simple Internet Attachment">
<t>Simple Internet attachment means attachment of a stub
(i.e., non-transit) network of AODVv2 routers to the
Internet via a single Internet AODVv2 router (called IAR).</t>
<t>As in any Internet-attached network,
AODVv2 routers, and their clients, wishing to be
reachable from hosts on the Internet MUST have IP addresses
within the IAR's routable and topologically correct prefix
(e.g. 191.0.2.0/24).</t>
<t>The IAR is responsible for generating RREQ messages to find nodes
within the MANET on behalf of nodes on the Internet, as
well as responding to route requests from the AODVv2 MANET on
behalf of the nodes on the Internet.</t>
<figure anchor="net_top" title="Simple Internet Attachment Example">
<artwork><![CDATA[
/-------------------------\
/ +----------------+ \
/ | AODVv2 Router | \
| | 191.0.2.2/32 | |
| +----------------+ | Routable
| +-----+--------+ Prefix
| | Internet | /191.0.2/24
| | AODVv2 Router| /
| | 191.0.2.1 |/ /----------------\
| | serving net +-------+ Internet \
| | 191.0.2/24 | \ /
| +-----+--------+ \----------------/
| +----------------+ |
| | AODVv2 Router | |
| | 191.0.2.3/32 | |
\ +----------------+ /
\ /
\-------------------------/
]]></artwork>
</figure>
<t>When an AODVv2 router within the AODVv2 MANET wants to discover
a route toward a node on the Internet, it uses the normal AODVv2
route discovery for that IP Destination Address. The IAR MUST
respond to RREQ on behalf of all Internet destinations.</t>
<t>When a packet from a node on the Internet destined for a
node in the AODVv2 MANET reaches the IAR, if the IAR does not
have a route toward that destination it will perform normal AODVv2
route discovery for that destination.</t>
</section>
<section title="Multiple Interfaces">
<t>AODVv2 may be used with multiple interfaces; therefore, the
particular interface over which packets arrive MUST be known
whenever a packet is received. Whenever a new route is
created, the interface through which the Route.Address can be
reached is also recorded in the route table entry.</t>
<t>When multiple interfaces are available, a node transmitting
a multicast packet with IP.DestinationAddress set to
LL-MANET-Routers SHOULD send the packet on all interfaces that
have been configured for AODVv2 operation.</t>
<t>Similarly, AODVv2 routers SHOULD subscribe to
LL-MANET-Routers on all their AODVv2 interfaces.</t>
</section>
<section title="AODVv2 Control Packet/Message Generation Limits">
<t>To avoid messaging overload, each AODVv2 router's rate
of packet/message generation SHOULD be limited. The rate and
algorithm for limiting messages (CONTROL_TRAFFIC_LIMITS) is
left to the implementor and should be administratively
configurable. AODVv2
messages SHOULD be discarded in the following order of
preference: RREQ, RREP, and finally RERR.</t>
</section>
<!-- ======================== Optional Features ======================== -->
<section anchor="optional" title="Optional Features">
<t> Some optional features of AODVv2, associated with AODV,
are not required by minimal implementations. These features are
expected to be useful in networks with greater mobility, or
larger node populations, or requiring shorter latency for
application launches. The optional features are as follows:</t>
<t><list style="symbols">
<t>Expanding Rings Multicast</t>
<t>Intermediate RREPs (iRREPs): Without iRREP, only the
destination can respond to a RREQ. </t>
<t>Precursor lists.</t>
<t>Reporting Multiple Unreachable Nodes. An RERR message can carry
more than one Unreachable Destination node for cases when
a single link breakage causes multiple destinations to become
unreachable from an intermediate router.</t>
<t>RREP_ACK.</t>
<t>Message Aggregation.</t>
<t>Inclusion of Added Routing Information.</t>
</list>
</t>
<section anchor="rings" title="Expanding Rings Multicast">
<t>For multicast RREQ, Msg.<msg-hop-limit> MAY be set in
accordance with an expanding ring search as described in
<xref target="RFC3561" /> to limit the RREQ propagation to a
subset of the local network and possibly reduce route
discovery overhead.</t>
</section>
<section anchor="iRREP" title="Intermediate RREP">
<t>This specification has been published as a separate
Internet Draft <xref target="I-D.perkins-irrep"/>.
</t>
</section>
<section anchor="precursor" title="Precursor Lists and Notifications">
<t>This section specifies an interoperable enhancement to AODVv2
(and possibly other reactive routing protocols) enabling
more economical notifications to active sources of traffic
upon determination that a route needed to forward such traffic to
its destination has become Broken.</t>
<!-- NOTE! CEP: TODO: Precursors should NOT be notified if
Precursor.LastUsed < (MAX_IDLETIME + ACTIVE_INTERVAL) -->
<!--
, then for
the IP.SourceAddress of the packet, Precursor[LastHop].LastUsed := Current_time.
the packet is forwarded to the route's next hop.
-->
<section title="Overview">
<t>In many circumstances, there might be several sources of traffic
for any particular destination. Each such source of traffic
is known as a "precursor" for the destination, as well as all
upstream routers between the forwarding AODVv2 router and the
traffic source. For each active destination, an AODVv2 router
MAY choose to keep track of the upstream neighbors that have
provided traffic for that destination; there is no need to
keep track of upstream routers any farther away than the next hop.
</t>
<t>Moreover, any particular link to an adjacent AODVv2 router may be
a path component of multiple routes towards various destinations.
The precursors for all destinations using the next hop across any
link are collectively known as the precursors for that next hop.
</t>
<t>When an AODVv2 router determines that an active link to one of its
downstream neighbors has broken,
the AODVv2 router detecting the broken link must mark multiple
routes as Broken, for each of the newly unreachable destinations,
as described in <xref target="rerr_gen"/>.
Each route that relies on the newly broken link is no longer valid.
Furthermore, the precursors of the broken link should be notified
(using RERR) about the change in status of their route
to a destination downstream along the broken next hop.
</t>
</section>
<section anchor="Precursor-Notification-Details"
title="Precursor Notification Details">
<t>During normal operation, each AODVv2 router wishing to maintain
precursor lists as described above,
maintains a precursor table and updates
the table whenever the node forwards traffic to one of
the destinations in its route table. For each precursor
in the precursor list, a record must be maintained to indicate
whether the precursor has been used for recent traffic (in other
words, whether the precursor is an Active precursor).
So, when traffic arrives from a precursor, the Current_Time is
used to mark the time of last use for the precursor list element
associated with that precursor.
</t>
<t>When an AODVv2 router detects that a link is broken, then for
each precursor using that next hop, the node MAY notify the
precursor using either unicast or multicast RERR:
<list style="hanging">
<t hangText="unicast RERR to each Active precursor"><vspace />
This option is useful when there are few Active precursors
compared to the number of neighboring AODVv2 routers.</t>
<t hangText="multicast RERR to RERR_PRECURSORS"><vspace />
RERR_PRECURSORS is, by default, LL-MANET-Routers
<xref target="RFC5498" />. This option is typically
preferable since fewer packet transmissions are required.</t>
</list>
Each active upstream neighbor (i.e., precursor) MAY then execute
the same procedure until all active upstream routers have
received the RERR notification.</t>
</section>
</section>
<section anchor="mcast-to-RREQ" title="Multicast RREP Response to RREQ">
<t>The RREQ Target Router (RREP_Gen) MAY, as an alternative to
unicasting a RREP, be configured
to distribute routing information about the route toward the RREQ
TargNode (TargRtr's client) more widely. That is, RREP_Gen
MAY be configured respond to a route discovery by generating a RREP,
using the procedure in <xref target="RREP_gen" />, but
multicasting the RREP to LL-MANET-Routers <xref target="RFC5498"/>.
Afterwards, RREP_Gen processing for the incoming RREQ is complete.</t>
<t>Broadcast response to incoming RREQ was originally specified
to handle unidirectional links, but it is expensive.
Due to the significant overhead, AODVv2 routers MUST NOT
use multicast RREP unless configured to do so by
setting the administrative parameter USE_MULTICAST_RREP.</t>
</section>
<section anchor="rrep_ack" title="RREP_ACK">
<t>Instead of relying on existing mechanisms for requesting
verification of link bidirectionality during Route
Discovery, RREP_Ack is provided as an optional feature
and modeled on the RREP_Ack message type from
AODV <xref target="RFC3561" />.</t>
<t>Since the RREP_ACK is simply echoed back to the node from
which the RREP was received, there is no need for any additional
RFC 5444 address information (or TLVs).
Considerations of packet TTL are as specified
in <xref target="MsgStruct" />. The message format
is illustrated in section <xref target="RREP_ACK-format" />.</t>
</section>
<section anchor="aggreg" title="Message Aggregation">
<t>The aggregation of multiple messages into a packet is
specified in RFC 5444 <xref target="RFC5444" />.</t>
<t>Implementations MAY choose to briefly delay
transmission of messages for the purpose of aggregation
(into a single packet) or to improve performance by using
jitter <xref target="RFC5148"/>.</t>
</section>
<section anchor="RM_addl"
title="Added Routing Information in RteMsgs">
<t>DSR <xref target="RFC4728" /> includes source routes as part of
the data of its RREPs and RREQs. Doign so allows additional
topology information to be multicast along with the RteMsg,
and potentially allows updating for stale routing information
at MANET routers along new paths between source and
destination. To maintain this functionality, AODVv2 has
defined a somewhat more general method that enables inclusion
of source routes in RteMsgs. </t>
<t>Appending routing information can eliminate some route
discovery attempts to the nodes whose information is
included, if handling AODVv2 routers use this information to
update their routing tables.</t>
<t>Note that, since the initial merger of DSR with AODV to
create this protocol, further experimentation has shown
that including
the additional routing information is not always helpful.
Sometimes it seems to help, and other times it seems to
reduce overall performance. The results depend upon
packet size and traffic patterns.
</t>
<section anchor="addl-append" title="Including Added Node Information">
<t>An AODVv2 router (HandlingRtr) MAY optionally append
AddedNode routing information to a RteMsg. This
is controllable by an option (APPEND_INFORMATION) which SHOULD be
administratively configurable or controlled according to the
traffic characteristics of the network.</t>
<t>The following notation is used to specify the methods for
inclusion of routing information for addtional nodes.
<list style="hanging">
<t hangText="AddedNode"><vspace />The
IP address of an additional node that can be reached via
the AODVv2 router adding this information. Each
AddedNode.Address MUST include its prefix. Each
AddedNode.Address MUST also have an associated
Node.SeqNum in the address TLV block.</t>
<t hangText="AddedNode.SeqNum"><vspace />The
AODVv2 sequence number associated with this routing
information.</t>
<t hangText="AddedNode.Metric"><vspace />The cost of
the route needed to reach the associated
AddedNode.Address. This field is increased by
Cost(L) at each intermediate AODVv2 router, where 'L'
is the incoming link.
If, for the Metric Type of the AddrBlk, it is not known how to
compute Cost(L), the AddedNode.Addr information MUST
be deleted from the AddedNode AddrBlk.</t>
</list></t>
<!-- TODO: CEP:
<t>Prior to appending an address
to a RteMsg, HandlingRtr SHOULD increment its OwnSeqNum as
defined in <xref target="seqnum" />. If OwnSeqNum is not
incremented the appended routing information might not be
usable, when received by nodes with existing
routing information. Incrementation of the sequence number
when appending information to a RteMsg in transit
(APPEND_INFORMATION_SEQNUM) SHOULD be administratively
configurable. Note that, during
handling of this RteMsg, OwnSeqNum may have already been
incremented; and in this case OwnSeqNum SHOULD NOT be
incremented again.</t>
-->
<t>The VALIDITY_TIME of routing information for appended
address(es) MUST be included, to inform routers about when
to expire this information. A typical value for VALIDITY_TIME
is (ACTIVE_INTERVAL+MAX_IDLETIME) - (Current_Time - Route.LastUsed)
but other values (less than MAX_SEQNUM_TIME) MAY be chosen.
The VALIDITY_TIME TLV is defined in <xref target="RFC5497" />.</t>
<t>SeqNum and Metric AddrTLVs about any appended address(es)
MUST be included.</t>
<t>Routing information about the TargNode MUST NOT be added to
the AddedAddrBlk. Also, duplicate address entries SHOULD
NOT be added. Only the best routing information
(<xref target="test" />) for a particular address SHOULD be
included; if route information is included for a destination
address already in the AddedAddrBlk, the previous information
SHOULD NOT be included in the outgoing RteMsg.</t>
</section>
<section anchor="using_addl" title="Handling Added Node Information">
<t>An intermediate node (i.e., HandlingRtr) obeys the following
procedures when
processing AddedNode.Address information and other
associated TLVs that are included with a RteMsg.
For each AddedNode (except the TargetNode) in the RteMsg,
the AddedNode.Metric information MUST be increased by Cost(L),
where 'L' is the incoming link.
If, for the Metric Type of the AddrBlk, it is not known how to
compute Cost(L), the AddedNode.Addr information MUST
be deleted from the AddedNode AddrBlk.
If the resulting Cost of the route to
the AddedNode is greater than MAX_METRIC[i], the AddedNode
information is discarded. If the resulting Distance value for another
node is greater than MAX_METRIC[i], the associated address and its
information are removed from the RteMsg.</t>
<t>After handling the OrigNode's routing information, then
each address that is not the TargetNode MAY be considered
for creating and updating routes. Creating and updating
routes to other nodes can eliminate RREQ for those IP
destinations, in the event that data needs to be forwarded
to the IP destination(s) now or in the near future.</t>
<t>For each of the additional addresses considered, HandlingRtr
first checks that the address is a routable
unicast address. If the address is not a unicast address, then
the address and all related information MUST be removed.</t>
<t>If the routing table does not have a matching route with
a known Route.SeqNum for this additional address using
longest-prefix matching, then a route MAY be created and
updated as described in <xref target="update_rte" />. If a
route table entry exists with a known Route.SeqNum, the
incoming routing information is compared with the route
table entry following the procedure described in <xref
target="test" />. If the incoming routing information is
used, the route table entry SHOULD be updated as
described in <xref target="update_rte" />.</t>
<t>If the routing information for an AddedNode.Address
is not used, then it is removed from the RteMsg.</t>
<t> If route information is included for a destination
address already in the AddedAddrBlk, the previous information
SHOULD NOT be included in the outgoing RteMsg.</t>
</section>
</section>
</section>
<!-- =================== Administrative Parameters ===================== -->
<section anchor="param" title="Administratively Configured
Parameters and Timer Values">
<t>AODVv2 contains several parameters which MUST be administratively
configured. The list of these follows:</t>
<texttable anchor="suggestedoptions"
title="Required Administratively Configured Parameters">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Description</ttcol>
<!-- Move to AODV2 Extensions document
TODO
<c>DID</c>
<c>All AODVv2 routers with the same DID that come in contact
with each other MUST operate with a compatible set of
configuration options, timing parameters, and protocol
extensions. If non-default potentially incompatible options,
timing parameters or protocol extensions are utilized the DID
MUST be set to a non-zero value.</c>
-->
<c>CLIENT_ADDRESSES</c>
<c>List of addresses and routing prefixes, for
which this AODVv2 router is responsible. If the list is
empty, this AODVv2 router is only
responsible for its own addresses.</c>
<c>USE_MULTICAST_RREP</c>
<c>Whether or not to use multicast RREP
(see <xref target="mcast-to-RREQ"/>).</c>
<c>DEFAULT_METRIC_TYPE</c>
<c>3 (Hop Count {see <xref target="RFC6551"/>}</c>
<c>AODVv2_INTERFACES</c>
<c>List of the interfaces participating in AODVv2 routing protocol.</c>
</texttable>
<t>AODVv2 requires certain timing information to be associated
with route table entries. The default values are as follows:</t>
<texttable anchor="suggestedparam"
title="Default Timing Parameter Values">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Value</ttcol>
<c>ACTIVE_INTERVAL</c>
<c>5 second</c>
<c>MAX_IDLETIME</c>
<c>200 seconds</c>
<c>MAX_SEQNUM_LIFETIME</c>
<c>300 seconds</c>
<c>ROUTE_RREQ_WAIT_TIME</c>
<c>2 seconds</c>
<c>UNICAST_MESSAGE_SENT_TIMEOUT</c>
<c>1 second</c>
<c>RREQ_HOLDDOWN_TIME</c>
<c>10 seconds</c>
</texttable>
<t>The above timing parameter values have worked well for small and
medium well-connected networks with moderate topology changes.</t>
<t>The timing parameters SHOULD be administratively configurable
for the network where AODVv2 is used. Ideally, for networks with
frequent topology changes the AODVv2 parameters should be adjusted
using either experimentally determined values or dynamic
adaptation. For example, in networks with infrequent topology
changes MAX_IDLETIME may be set to a much larger
value.</t>
<texttable anchor="otherparam"
title="Default Parameter Values">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Description</ttcol>
<c>MAX_HOPCOUNT</c>
<c>20 hops</c>
<c>This value MUST be larger than the AODVv2 network
diameter. Otherwise, routing messages may not reach their
intended destinations.</c>
<c>MAX_METRIC[i]</c>
<c>Not Specified in This Document</c>
<c>If defined, this is the maximum permissible value for
Metric Type 'i' (see <xref target="RFC6551"/>).
</c>
<c>MAXTIME</c>
<c>TBD</c>
<c>The maximum expressible value for clock time.</c>
<!-- Need to figure out what the time format. -->
<c>DISCOVERY_ATTEMPTS_MAX</c>
<c>3</c>
<c>The number of route discovery attempts to make before
indicating that a particular address is not reachable.</c>
<c>MTU</c>
<c>TBD -- depends on address family</c>
<c>Determines the maximum number of RFC 5444 AddrBlk entries</c>
</texttable>
<t>In addition to the above parameters and timing values,
several administrative options exist. These options have no
influence on correct routing behavior, although they may
potentially reduce AODVv2 protocol messaging in certain
situations. The default behavior is to NOT enable any of these
options; and although many of these options can be
administratively controlled, they may be better served by
intelligent control. The following table enumerates several of
the options.</t>
<texttable anchor="adminoptions"
title="Administratively Controlled Options">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Description</ttcol>
<c>APPEND_INFORMATION</c>
<c>Whether or not appending routing information for AddedNodes to a
RteMsg is enabled.</c>
<c>BUFFER_SIZE_PACKETS</c> <c>2</c>
<c>BUFFER_SIZE_BYTES</c> <c>MAX_PACKET_SIZE [TBD]</c>
<!-- TODO: CEP:
<c>APPEND_INFORMATION_SEQNUM</c>
<c>Whether to increment HandlingRtr's OwnSeqNum when append
HandlingRtr's routing information to a RteMsg.</c>
-->
<c>APPEND_IDLE_UNREACHABLE</c>
<c>Whether to append Unreachable information
about idle routes to RERR.</c>
<c>CONTROL_TRAFFIC_LIMIT</c>
<c>TBD [50 msgs/sec?]</c>
</texttable>
<t>Note: several fields have limited size (bits or bytes). These
sizes and their encoding may place specific limitations on the values
that can be set. For example, MsgHdr.<msg-hop-count> is a 8-bit
field and therefore MAX_HOPCOUNT cannot be larger than 255.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section specifies several message types, message
tlv-types, and address tlv-types. Also, a new registry of
16-bit alternate metric types is specified.</t>
<section anchor="msgtype" title="AODVv2 Message Types Specification">
<texttable anchor="msgtypes" title="AODVv2 Message Types">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<c>Route Request (RREQ)</c> <c>10 - TBD</c>
<c>Route Reply (RREP)</c> <c>11 - TBD</c>
<c>Route Error (RERR)</c> <c>12 - TBD</c>
<c>Route Reply Acknowledgement (RREP_ACK)</c> <c>13 - TBD</c>
</texttable>
</section>
<section anchor="msgtlvtypes"
title="Message and Address Block TLV Type Specification">
<texttable anchor="msgtlvtbl" title="Message TLV Types">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="left" width="45%">Value</ttcol>
<c>Unicast Response Request (RespReq)</c>
<c>10 - TBD</c>
<c>0 octets</c>
<c>Indicates to the handling (receiving) AODVv2 router that the
previous hop (IP.SourceAddress) expects a unicast reply
message within UNICAST_MESSAGE_SENT_TIMEOUT. </c>
<c></c>
<c></c>
<c></c>
<c> -- </c>
<c>Destination RREP Only (DestOnly)</c>
<c>11 - TBD</c>
<c>0 octets</c>
<c>Indicates that intermediate RREPs are prohibited.</c>
<c></c>
<c></c>
<c></c>
<c> -- </c>
<c>Packet source IP address (PktSource)</c>
<c>12 - TBD</c>
<c>4 or 16 octets</c>
<c>Provides the IP address for RERR messages generated due to
inability to deliver a packet.</c>
<c></c>
<c></c>
<c></c>
<c> -- </c>
<c>Metric Type</c>
<c>13 - TBD</c>
<c>1 octet</c>
<c>Type of metric in the Metric8 or Metric16 AddrTLV. </c>
</texttable>
</section>
<section anchor="addrtlvspec" title="Address Block TLV Specification">
<texttable anchor="addrtlvtypes"
title="Address Block TLV (AddrTLV) Types">
<ttcol align="center" width="25%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center" width="15%">Length</ttcol>
<ttcol align="left" width="50%">Value</ttcol>
<c>VALIDITY_TIME</c> <!-- Why is this here? Already allocated! -->
<c>1<xref target="RFC5497" /> </c>
<c>1 octet</c>
<c>The maximum amount of time that information can be
maintained before being deleted. The VALIDITY_TIME TLV is
defined in <xref target="RFC5497" />.</c>
<c></c>
<c></c>
<c></c>
<c> -- </c>
<c>Sequence Number (SeqNum)</c>
<c>10 - TBD</c>
<c>2 octets</c>
<c>The latest AODVv2 sequence number associated with the address.</c>
<c>Metric8</c>
<c>11 - TBD</c>
<c>1 octet</c>
<c>8-bit Cost of the route to reach the destination address.</c>
<c>Metric16</c>
<c>12 - TBD</c>
<c>2 octets</c>
<c>16-bit Cost of the route to reach the destination address.</c>
</texttable>
<t>The same number space should be used for both Metric8 and Metric16
metric types.
</t>
</section>
<section anchor="metric-type" title="Metric Type Number Allocation">
<t>Metric types are identified according to the assignments as specified
in <xref target="RFC6551"/>.
The metric type of the Hop Count metric is assigned to
be 3, in order to maintain compatibility with that existing
table of values from RFC 6551.
If non-additive metrics are to be used, the specification
for assessing the usability of route updates
(see <xref target="test"/> ) may require changes.</t>
<texttable anchor="metric-tbl" title="Metric Types">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Size</ttcol>
<c>Reserved</c>
<c>0</c>
<c>Undefined</c>
<c>Unallocated</c>
<c>1 -- 2</c>
<c>TBD</c>
<c>Hop Count</c>
<c>3 - TBD</c>
<c>1 octet</c>
<c>Unallocated</c>
<c>4 -- 254</c>
<c>TBD</c>
<c>Reserved</c>
<c>255</c>
<c>Undefined</c>
</texttable>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The objective of the AODVv2 protocol is for each router to
communicate reachability information about addresses for which it
is responsible. Positive routing information (i.e. a route
exists) is distributed via RteMsgs and negative routing information
(i.e. a route does not exist) via RERRs. AODVv2 routers that
handle these messages store the contained information to
properly forward data packets, and they generally provide this
information to other AODVv2 routers.</t>
<!--t>If a router transmits incorrect or false routing information,
it will likely be stored and propagated.</t-->
<!--IDC should we remove all mutable fields-->
<!--IDC Notify Reflection Attack-->
<t>This section does not mandate any specific security
measures. Instead, this section describes various security
considerations and potential avenues to secure AODVv2 routing.</t>
<t>The most important security mechanisms for AODVv2
routing are integrity/authentication and confidentiality. </t>
<t>In situations where routing information or router identity
are suspect, integrity and authentication techniques SHOULD be
applied to AODVv2 messages. In these situations, routing
information that is distributed over multiple hops SHOULD also
verify the integrity and identity of information based on
originator of the routing information. </t>
<t>A digital signature could be used to identify the source of
AODVv2 messages and information, along with its authenticity. A
nonce or timestamp SHOULD also be used to protect against replay
attacks. S/MIME and OpenPGP are two authentication/integrity
protocols that could be adapted for this purpose.</t>
<t>In situations where confidentiality of AODVv2 messages is
important, cryptographic techniques can be applied.</t>
<t>In certain situations, for example sending a RREP or RERR, an AODVv2
router could include proof that it has previously received valid
routing information to reach the destination, at one point of
time in the past. In situations where routers are suspected of
transmitting maliciously erroneous information, the original
routing information along with its security credentials SHOULD
be included.</t>
<t>Note that if multicast is used, any confidentiality and
integrity algorithms used MUST permit multiple receivers to
handle the message.</t>
<t>Routing protocols, however, are prime targets for
impersonation attacks. In networks where the node membership is
not known, it is difficult to determine the occurrence of
impersonation attacks, and security prevention techniques are
difficult at best. However, when the network membership is known
and there is a danger of such attacks, AODVv2 messages must be
protected by the use of authentication techniques, such as those
involving generation of unforgeable and cryptographically strong
message digests or digital signatures. While AODVv2 does not place
restrictions on the authentication mechanism used for this
purpose, IPsec Authentication Message (AH) is an appropriate
choice for cases where the nodes share an appropriate security
association that enables the use of AH.</t>
<t>In particular, routing messages SHOULD be authenticated to avoid
creation of spurious routes to a destination. Otherwise, an
attacker could masquerade as that destination and maliciously
deny service to the destination and/or maliciously inspect and
consume traffic intended for delivery to the destination. RERR
messages SHOULD be authenticated in order to prevent malicious
nodes from disrupting active routes between communicating
nodes.</t>
<t>If the mobile nodes in the ad hoc network have pre-established
security associations, the purposes for which the security associations
are created should include that of authorizing the processing of AODVv2
control packets. Given this understanding, the mobile nodes should be
able to use the same authentication mechanisms based on their IP
addresses as they would have used otherwise.</t>
<!--DEREK comments
Some threats to the system could include an injection of RERR message
either by an outside attacker, a rogue router, or a compromised
router. The TTL check protects against some injection techniques
unless it's injected by an actual rogue or compromised router.
In terms of source identification of a RREQ or RREP you might want to
add a digital signature field (which also requires some nonce or
timestamp to protect against replay attacks). There's also a question
of how you authorize a router to supply an RREP. For example a rogue
or compromised router could decide to "advertize" a route by
responding with an RREP even though it's not necessarily the "best"
route or it might not even have a route toward the destination.
When an intermediate router generates an RREP it needs to authenticate
that it has the original route. Perhaps what needs to happen is that
it includes the original RREP signed by the TargetNode in order to
prove
that it HAD (at one point in the past) a valid route toward the
TargetNode.
This is particularly an issue in generating the RREP on the fly to the
TargetNode from the OrigNode because there IS no RREP. In this case
it might want to include the original RREQ from the OrigNode as the
authentication token.
-->
<t>If the mobile nodes in the ad hoc network have pre-established
security associations, the purposes for which the security associations
Most AODVv2 messages are transmitted to the multicast address
LL-MANET-Routers <xref target="RFC5498" />. It is therefore
required for security that AODVv2 neighbors exchange security
information that can be used to insert an ICV <xref target="RFC6621" />
into the AODVv2 message block <xref target="RFC5444" />.
This enables hop-by-hop security, which is proper for these
message types that may have mutable fields. For destination-only
RREP discovery procedures, AODVv2 routers that share a security
association SHOULD use the appropriate mechanisms as specified
in RFC 6621.
The establishment of these security associations is out of scope
for this document.</t>
</section>
<section title="Acknowledgments">
<t>AODVv2 is a descendant of the design of previous MANET on-demand
protocols, especially AODV <xref target="RFC3561"></xref> and
DSR <xref target="RFC4728"></xref>. Changes to previous MANET
on-demand protocols stem from research and implementation
experiences. Thanks to Elizabeth Belding-Royer for her long time
authorship of AODV. Additional thanks to Luke Klein-Berndt,
Pedro Ruiz, Fransisco Ros, Henning Rogge, Koojana Kuladinithi,
Ramon Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi,
Romain Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu,
Christoph Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins
for reviewing of AODVv2, as well as several specification
suggestions.</t>
<t>
This revision of
AODVv2 separates the minimal base specification from
other optional features to expedite the process of
assuring compatibility with the existing LOADng
specification <xref target="I-D.clausen-lln-loadng" />
(minimal reactive routing protocol specification).
Thanks are due to
T. Clausen,
A. Colin de Verdiere,
J. Yi,
A. Niktash,
Y. Igarashi,
Satoh. H., and
U. Herberg
for their development of LOADng and sharing details for
assuring appropriateness of AODVv2 for their application.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1812" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5082" ?>
<?rfc include="reference.RFC.5444"?>
<?rfc include="reference.RFC.5497"?>
<?rfc include="reference.RFC.5498"?>
<?rfc include="reference.RFC.6551"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2328" ?>
<?rfc include="reference.RFC.2501" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.4193" ?>
<?rfc include="reference.RFC.4728" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.5148" ?>
<?rfc include="reference.RFC.6130" ?>
<?rfc include="reference.RFC.6549" ?>
<?rfc include="reference.RFC.6621" ?>
<?rfc include="reference.I-D.perkins-irrep" ?>
<reference anchor="Perkins99">
<front>
<title>Ad hoc On-Demand Distance Vector (AODV) Routing</title>
<author fullname="Charles E. Perkins" initials="C."
surname="Perkins">
<organization></organization>
</author>
<author fullname="Elizabeth M. Belding-Royer" initials="E."
surname="Belding-Royer">
<organization></organization>
</author>
<date month="February" year="1999" />
</front>
<seriesInfo name="Proceedings"
value="of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, pp. 90-100" />
</reference>
<!--
<?rfc include="reference.I-D.chakeres-manet-manetid" ?>
-->
<?rfc include="reference.I-D.clausen-lln-loadng" ?>
</references>
<section anchor="rfc5444-formats"
title="Example RFC 5444-compliant packet formats">
<t>The following three subsections show example RFC 5444-compliant
packets for AODVv2 message types RREQ, RREP, and RERR. These
proposed message formats are designed based on expected savings
from IPv6 addressable MANET nodes, and a layout for the Address TLVs
that may be viewed as natural, even if perhaps not the absolute
most compact possible encoding.</t>
<t>For RteMsgs, the msg-hdr fields are followed by
at least one and optionally two Address Blocks. The first AddrBlk
contains OrigNode and TargNode. For each AddrBlk,
there must be AddrTLVs of type Seqnum and of type Metric.
</t>
<t>In addition to the Seqnum TLV, there MUST be an AddrTLV
of type Metric. The msg-hop-count is
counts the number of hops followed by the RteMsg
from RteMsg_Orig to the current intermediate AODVv2 router handling
the RteMsg. Alternate metrics are enabled by the inclusion of the
MetricType MsgTLV.
When there is no such MetricType MsgTLV present, then the Metric
AddrTLV measures HopCount.
The Metric AddrTLV also provides a way for the RteMsg_Orig to
supply an initial nonzero cost for the route
between the RteMsg_Orig and its client node, i.e., either OrigNode
or TargNode.</t>
<t>AddedNode information MAY be included in a RteMsg by
adding a second AddrBlk. Both Metric AddrTLVs use the
same Metric Type.
</t>
<section anchor="RREQ-format" title="RREQ Message Format">
<t>The figure below illustrates a packet format for an example RREQ
message.
<figure anchor="figRREQ" title="Example IPv4 RREQ">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=24 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (bytes for Orig & Target)| Orig.Tail | Target.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=11 | type=SeqNum |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Orig.Node Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=SeqNum |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNodeHopCt |
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>
RREQ with SeqNum and Metric AddrTLVs added, and:
- two addresses in Address Block
- address length = 4 [IPv4], shared initial bytes = 3
- Sequence Number available only for Orig.Node in addr.tlv
- Hop Count available only for Orig.Node in Metric8 AddrTLV
- Addresses stored in the order OrigNode, TargNode</postamble>
</figure>
</t>
</section>
<section anchor="RREP-format" title="RREP Message Format">
<t>The figure below illustrates a packet format for an example RREP
message.
<figure anchor="figRREP" title="Example IPv4 RREP">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RREP | MF=4 | MAL=3 | msg-size=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=30 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (bytes for Orig & Target)| Orig.Tail | Target.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=13 | type=SeqNum |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Orig.Node Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target.Node Sequence # | type=Metric8 |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=1 | TargNodeHopCt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>
RREP with SeqNum and Metric AddrTLVs added, and:
- two addresses in AddrBlk
- address length = 4 [IPv4], shared initial bytes = 3
- One Sequence Number (for TargNode) in SeqNum AddrTLV
- Hop Count available only for Targ.Node in Metric8 AddrTLV
- Addresses stored in the order OrigNode, TargNode</postamble>
</figure>
</t>
<t> </t>
</section>
<section anchor="RERR-format" title="RERR Message Format">
<t>The figure below illustrates a packet format for an example RERR
message.
<figure anchor="figRERR" title="Example IPv4 RERR">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RERR | MF=4 | MAL=3 | msg-size=25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=25 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Two Dests)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=8 | type=SeqNum |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Dest_1 Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest_2 Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>
RERR with - Two Unreachable Node address in Address Block
- address length = 4 [IPv4], shared initial bytes = 3
- Two Sequence Numbers available in addr.tlv
- Addresses stored from Originator to Target</postamble>
</figure>
</t>
<t> </t>
</section>
<section anchor="RREP_ACK-format" title="RREP_ACK Message Format">
<t>The figure below illustrates a packet format for an example
RREP_ACK message. </t>
<t><figure anchor="figRREPAk" title="Example IPv4 RREP_ACK">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 |msg-type=RREPAk| MF=0 | MAL=3 | msg-size=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=3 |
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble> RREP_ACK - address length = 4 [IPv4] </postamble>
</figure>
</t>
</section>
</section>
<section anchor="changes"
title="Changes since revision ...-21.txt">
<t> The revisions of this document that were numbered 22 and 23 were
produced without sufficient time for preparation, and suffered
from numerous editorial errors. Therefore, this list of changes
is enumerated based on differences between this revision (24)
and revision 21.
<list style="symbols">
<t>Alternate metrics enabled:
<list style="symbols">
<t>New section added to describe general design approach.</t>
<t>Abstract functions "Cost()" and "LoopFree()" defined.</t>
<t>MAX_HOPCOUNT typically replaced by MAX_METRIC.</t>
<t>DEFAULT_METRIC_TYPE parameter defined, defaulting to HopCount.</t>
<t>MetricType MsgTLV defined.</t>
<t>Metric8 and Metric16 AddrTLVs defined.</t>
</list></t>
<t>Many changes for RFC 5444 compliance</t>
<t>New section added for "Notational Conventions"
(see <xref target="notational-conventions"/>).
Many changes to improve readability and accuracy
(e.g., eliminate use of "Flooding", "ThisNode", ...).</t>
<t>Reorganized and simplified route lifetime management
(see <xref target="rte"/>).</t>
<t>Reorganized document structure, combining closely related
small sections and eliminating top-level "Detailed ..."
section.
<list style="symbols">
<t>RREQ and RREP specification sections coalesced.</t>
<t>RERR specification sections coalesced.</t>
<t>Eliminated resulting duplicated specification.</t>
<t>New section added for "Notational Conventions".</t>
</list></t>
<t>Internet-Facing AODVv2 router renamed to be IAR</t>
<t>"Optional Features" section (see <xref target="optional"/>) created to
contain features not required within base specification, including:
<list style="symbols">
<t>Adding RREP-ACK message type instead of relying on reception of
arbitrary packets as sufficient response to establish bidirectionality.
</t>
<t>Expanding Rings Multicast</t>
<t>Intermediate RREPs (iRREPs): Without iRREP, only the
destination can respond to a RREQ. </t>
<t>Precursor lists.</t>
<t>Reporting Multiple Unreachable Nodes. An RERR message can carry
more than one Unreachable Destination node for cases when
a single link breakage causes multiple destinations to become
unreachable from an intermediate router.</t>
<t>Message Aggregation.</t>
<t>Inclusion of Added Routing Information.</t>
</list></t>
<t>Sequence number MUST be incremented after generating any RteMsg.</t>
<t>Resulting simplifications for accepting route updates in RteMsgs.</t>
<t>Sequence number MUST (instead of SHOULD) be set to 1 after rollover.</t>
<t>AODVv2 routers MUST (instead of SHOULD) only handle AODVv2 messages
from adjacent routers.</t>
<t>Clarification that Added Routing information in RteMsgs is
optional (MAY) to use.</t>
<t>Clarification that if Added Routing information in RteMsgs is
used, then the Route Table Entry SHOULD be updated using
normal procedures as described in <xref target="update_rte" />.</t>
<t>Clarification in <xref target="route_discovery" /> that nodes may be
configured to buffer zero packets.</t>
<t>Clarification in <xref target="route_discovery" /> that buffered
packets MUST be dropped if route discovery fails.</t>
<t>In <xref target="link_breaks" />, relax mandate for monitoring
connectivity to next-hop AODVv2 neighbors (from MUST to SHOULD),
in order to allow for minimal implementations </t>
<t>Remove Route.Forwarding flag; identical to "NOT" Route.Broken.</t>
<!-- This is allowable via RFC 5444
<t>Different address lengths are supported - from full 16 octet IPv6
addresses over 6 octet Ethernet MAC addresses and 4 octet IPv4
addresses to shorter 1 and 2 octet addresses. The only
requirement is, that within a given MANET, all addresses
are of the same address length. </t>
<t>Control messages can include TLV (Type-Length-Value) elements,
permitting protocol extensions to be developed. </t>
-->
<t>Routing Messages MUST be originated with the MsgHdr.<msg-hop-limit>
set to MAX_HOPCOUNT.</t>
<t>Maximum hop count set to MAX_HOPCOUNT, and 255 is reserved for "unknown".
Since the current draft only uses hop-count as distance,
this is also the current maximum distance.</t>
</list>
</t>
</section>
<!--
<section anchor="prop_changes"
title="Proposed additional changes for LOADng conformance">
<t><list style="symbols">
</list>
</t>
-->
<section anchor="change_address_location"
title="Shifting Network Prefix Advertisement Between AODVv2 Routers">
<t>Only one AODVv2 router within a MANET SHOULD be
responsible for a particular address at any time. If two AODVv2
routers dynamically shift the advertisement of a network prefix, correct
AODVv2 routing behavior must be observed. The AODVv2 router adding
the new network prefix must wait for any existing routing information
about this network prefix to be purged from the network. Therefore, it
must wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the
previous AODVv2 router for this address stopped
advertising routing information on its behalf.</t>
</section>
</back>
</rfc>
<!-- ====================================================================== -->
<!--
<msg-header> := <msg-type>
<msg-size:16> /* up to 65,545 bytes */
<msg-orig-addr>?
<msg-hop-limit:8>?
<msg-hop-count:8>?
<msg-seq-num:16>?
<tlv-block>
(<addr-block><tlv-block>)*
<address-block> := <num-addr:8>
<addr-flags:8>
(<head-length><head>?)?
(<tail-length><tail>?)?
<mid>*
<prefix-length>*
<tlv-block> := <tlvs-length:16> /* Aggregate length of <tlv>* */
<tlv>*
<tlv> := <tlv-type:8>
<tlv-flags:8>
<tlv-type-ext>?
(<index-start><index-stop>?)?
(<length><value>?)?
-->
| PAFTECH AB 2003-2026 | 2026-04-24 07:13:38 |