One document matched: draft-ietf-manet-dymo-25.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-25" 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 an active
route breaks.</t>
<t>During route discovery, an AODVv2 router (RREQ_Gen) multicasts a
Route Request message (RREQ) to find a route toward some target
destination. Using a hop-by-hop retransmission algorithm, each AODVv2
router receiving the RREQ message records a route toward the originator.
When the target's AODVv2 router (RREP_Gen) receives the RREQ, it records a
route toward RREQ_Gen and generates a Route Reply (RREP) unicast
toward RREQ_Gen. Each AODVv2 router that receives the RREP stores a
route toward the target, and again unicasts the RREP toward the
originator. When RREQ_Gen receives the RREP, routes have then been
established between RREQ_Gen (the originating AODVv2 router) and
RREP_Gen (the target's AODVv2 router) in both directions.</t>
<t>Route maintenance consists of two operations. In order to
maintain active routes, AODVv2 routers extend route lifetimes upon
successfully forwarding a packet. When a data packet is received
downstream for forwarding but 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 AODVv2 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 />
Same as Sequence Number. </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 receiving and handling an AODVv2 message.</t>
<t hangText="Incoming Link"><vspace />A link over which an AODVv2 router
has received a message from an adjacent router.</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 (RREQ_Gen) has the
responsibility to generate a AODVv2 RREQ message on behalf of
OrigNode when necessary to discover a route.</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="RREP Generating Router (RREP_Gen)"><vspace/>
The RREP Generating Router is the AODVv2 router that serves TargNode.
RREP_Gen generates the RREP message to advertise a route for TargNode.
</t>
<t hangText="RREQ Generating Router (RREQ_Gen)"><vspace/>
The RREQ Generating Router is the AODVv2 router that serves OrigNode.
RREQ_Gen generates the RREQ message to discover a route for TargNode.
</t>
<t hangText="Sequence Number (SeqNum)"><vspace />AODVv2 mandates that each
AODVv2 router maintain an unsigned integer known as the router's
"Sequence Number". This Sequence Number guarantees the temporal
order of routing information to maintain loop-free routes.
This Sequence Number fulfills the same role as the "Destination
Sequence Number" of DSDV, and of AODV Sequence Number in
RFC 3561<xref target="RFC3561" />.
The value zero (0) is reserved to indicate that the Sequence Number
for an address is unknown.</t>
<t hangText="Target Node (TargNode)"><vspace />
The Target Node denotes the node for which a route is needed.</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="19" /></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> <!-- RFC 5444 message fields--> <c> -- </c>
<c><msg-hop-count></c>
<c>RFC 5444 Message Header <msg-hop-count></c>
<c><msg-hop-limit></c>
<c>RFC 5444 Message Header <msg-hop-limit></c>
<c>AddrBlk</c> <c>an RFC 5444 Address TLV 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 RFC 5444 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>MetricTLV</c> <c>Metric AddrTLV for AddrBlk</c>
<c>SeqNumTLV</c> <c>Sequence Number AddrTLV for AddrBlk</c>
<c> -- </c> <!-- Types of Nodes --> <c> -- </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.{field}</c> <c>Field in RREQ or RREP</c>
<c>HandlingRtr</c> <c>Handling Router</c>
<c>TargNode</c> <c>Target Node</c>
<c>UnreachableNode</c> <c>Unreachable Node</c>
</texttable>
</section>
<section anchor="apply" 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.
AODVv2 supports routers with multiple interfaces, as long
as each interface has its own (unicast routeable) IP address; the set
of all network interfaces supporting AODVv2 is administratively
configured in a list (namely, AODVv2_INTERFACES).
<!--
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>
In addition to routing for their local applications, AODVv2 routers can
also route on behalf of other non-routing nodes (i.e., "hosts", or,
in this document, "clients"), reachable via those interfaces.
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.
</t>
<t> 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" />.
Address assignment procedures are entirely out of scope for AODVv2.
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 AODVv2 router's IP address as well as SeqNum. 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>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 (e.g., 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 information 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.PrefixLength"><vspace />
The length of the netmask/prefix. If the value of
the Route.PrefixLength is not INVALID_PREFIX_LENGTH and
is 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 Sequence Number
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; an Expired
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 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
Acknowledgement Request (AckReq) message TLV
(see <xref target="msgtlvtypes"/>)
in the RREP. Any unicast packet will satisfy the Acknowledgement
Request, for example an ICMP REPLY message. If the verification
is not received within UNICAST_MESSAGE_SENT_TIMEOUT,
HandlingRtr SHOULD put the upstream neighbor in the
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="Blacklist.Node"><vspace />The IP address of the
node that did not verify bidirectional connectivity. </t>
<t hangText="Blacklist.RemoveTime"><vspace />The time at which
Blacklist.Node 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. AODVv2 defines the Sequence Number
to be the same for the AODVv2 router and each of
its clients.
</t>
<t>For this purpose, CLIENT_ADDRESSES must be configured on each
AODVv2 router with the following information:
<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 packets 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 specified in <xref target="RFC5444" />.
Here is a brief summary of the format.
<list style="hanging">
<t> A packet formatted according to RFC 5444
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
an associated TLV block; this TLV block may encode
multiple TLVs. According to RFC 5444, each such
TLV may itself include an array of values.</t>
</list>
If a packet contains only a single AODVv2 message and no
packet TLVs, it need only include a minimal 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),
and the IP destination is multiple hops away,
it becomes infeasible 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="Sequence Numbers">
<t>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
An AODVv2 router increments its SeqNum as follows.
Most of the time, SeqNum is incremented by simply
adding one (1). But to increment SeqNum 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 its SeqNum in persistent storage.
If an AODVv2 router's SeqNum 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 SeqNum 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>AODVv2 route selection in 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 metric
information other than Hop Count, which has traditionally been
the default metric associated with routes in MANET.
Unfortunately, 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 measures a
"cost" of using the associated route, and there are many
different kinds of cost (latency, delay, monetary, 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 metric.
Moreover, 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 for which
the Cost 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, (under the assumption of
nondecreasing SeqNum during Route Discovery) 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 simply 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.
MAX_HOPCOUNT MUST be larger than the AODVv2 network
diameter. Otherwise, AODVv2 protocol messages may not reach their
intended destinations.
</t>
<!--
<t>xxxxxxxxxxxxx
</t>
-->
</section>
<section anchor="supp-tbl" title="RREQ Table: Received RREQ">
<t>
Two incoming RREQ messages are considered to be "comparable" if
they were generated by the same AODVv2 router in order to
discover a route for the same destination with the same metric
type. Using that notion
of comparability, when RREQ messages are flooded in a MANET,
an AODVv2 router may well receive comparable RREQ messages
from more than one of its neighbors. A router, after
receiving an RREQ message, MUST check against previous
RREQs to assure
that its response message would contain useful information.
Otherwise, multicast RREQs are likely to be
retransmitted over and over again with zero additional benefit
but generating a great deal of unnecessary signaling traffic
and interference.
</t>
<t>
When optional multicast RREP (see <xref target="mcast-to-RREQ"/>) is
used to enable selection from among multiple possible return routes,
an AODVv2 router can eliminate useless RREP messages using the
analogous mechanism along with a RREP Table. Nevertheless,
the description in this section only refers to RREQ multicast messages.
</t>
<t>
To avoid transmission of useless RREQ messages,
while still enabling the proper handling of earlier RREQ
messages that may have somehow been delayed in the network,
it is needed for each AODVv2 router to keep a list of the
certain information about RREQ messages which it
has recently received.
</t>
<t>
This list is called the AODVv2
Received RREQ Table -- or, more briefly, the RREQ Table.
Two AODVv2 RREQ messages are comparable if:
<list style="symbols">
<t>they have the same metric type</t>
<t>they have the same OrigNode and TargNode addresses</t>
</list>
The RREQ Table is maintained so that
no two entries in the RREQ Table are comparable
-- that is,
all RREQs represented
in the RREQ Table either have different OrigNode addresses,
different TargNode addresses, different metric types,
or different message types.
If two RREQs have the same metric type and OrigNode and
Targnode addresses, the information from
the one with the older Sequence Number is not needed in the
table; in case
they have the same Sequence Number, the one with the greater
Metric value is not needed; in case they have the same Metric
as well, it does not matter which table entry is maintained.
Whenever a RREQ Table entry is updated, its Timestamp field
should also be updated to reflect the Current_Time.
</t>
<t>
Each entry in the RREQ Table has the following fields:
<list style="symbols">
<t>Metric Type</t>
<t>OrigNode address</t>
<t>TargNode address</t>
<t>Sequence Number</t>
<t>Metric</t>
<t>Timestamp</t>
</list>
</t>
<t>
Protocol handling of RERR messages eliminates the need for
tracking RERR messages, since the rules for RERR regeneration
prevent the phenomenon of useless retansmission
that affects RREQ and RREP multicast.
</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. Route update information in AODVv2
messages includes a destination IP address (DestIP),
SeqNum and prefix length associated with DestIP, and the
Metric from the node transmitting the AODVv2
message to DestIP. DestIP 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.PrefixLength 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 MetricType Message TLV, then
the metric information contained by RteMsg is considered to
be of type DEFAULT_METRIC_TYPE -- by default, 3 (for HopCount).
Whenever an AODVv2 router
(HandlingRtr) handles an incoming RteMsg (i.e., RREQ or RREP),
for every relevant address (RteMsg.Addr)
in the RteMsg, HandlingRtr 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, HandlingRtr creates
a route table entry for RteMsg.Addr as described
in <xref target="update_rte"/>.
Otherwise, HandlingRtr 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 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. Define RteMsg.Cost to be
(RteMsg.Metric + Cost(L)), where L is the incoming link.
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. HandlingRtr MUST NOT update the
route table entry using 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) above), RteMsg.Cost 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 to update any route table entry.
</t>
<t hangText="3. Longer::"><vspace /><![CDATA[
(RteMsg.Cost >= 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.Cost ≥ 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.Cost < 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.PrefixLength exists and is not INVALID_PREFIX_LENGTH,
then Route.PrefixLength := RteMsg.PrefixLength</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.Metric := (RteMsg.Metric + Cost(L)),
where L is the incoming link.</t>
<t>Route.LastUsed := Current_Time</t>
<t>If RteMsg.VALIDITY_TIME is included, then <vspace/>
Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME,
otherwise, Route.ExpirationTime :=
Current_Time + (ACTIVE_INTERVAL + MAX_IDLETIME).
</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
(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 Message Header (optionally, with MsgTLVs) |
+---------------------------------------------------------------+
| AddrBlk[1,2]:= [OrigNode,TargNode] |
+---------------------------------------------------------------+
| AddrBlk.PrefixLength[OrigNode OR TargNode] (Optional) |
+---------------------------------------------------------------+
| SeqNumTLV [OrigNode AND/OR TargNode] |
+---------------------------------------------------------------+
| MetricTLV [OrigNode, TargNode] (Optional) |
+---------------------------------------------------------------+
| Added Node Address Block (Optional) |
+---------------------------------------------------------------+
| Added Node Address SeqNumTLV |
+---------------------------------------------------------------+
| Added Node Address MetricTLV[MetricType] |
+---------------------------------------------------------------+
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Required Message Header Fields"><vspace />
The RteMsg MUST contain the following:
<list style="symbols">
<t><msg-hop-limit></t>
<t>Metric Type Message TLV, if MetricType != 3</t>
</list> </t>
<t hangText="Optional Message Header Fields"><vspace />
The RteMsg may contain the following:
<list style="symbols">
<t><msg-hop-count></t>
<t>DestOnly TLV (RREQ only: no Intermediate RREP)</t>
<t>MetricType TLV (Metric Type for Metric AddrTLV)</t>
<t>AckReq TLV (Acknowledgement Requested)</t>
</list> </t>
<t hangText="AddrBlk"><vspace />
This Address Block contains the IP addresses for RREQ
Originating and Target Node (OrigNode and TargNode).
For both RREP and RREQ, OrigNode and TargNode are as
identified in the context of the RREQ message
originator.
</t>
<t hangText="SeqNumTLV (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>
</t>
</section>
<section anchor="RREQ_gen" title="RREQ Generation">
<t>The AODVv2 router generating the RREQ (RREQ_Gen) on behalf
of its client OrigNode follows the steps in this section.
OrigNode MUST be a unicast address.
The order of protocol elements
is illustrated schematically in <xref target="figRteMsg" />.
<list style="numbers">
<t>RREQ_Gen MUST increment its SeqNum by one (1) according to the
rules specified in <xref target="seqnum" />. This assures that
each node receiving the RREQ will update its route table using
the information in the RREQ.</t>
<t>If RREQ_Gen requires that only the router providing connectivity
to TargNode is allowed to generate a RREP, then RREQ_Gen includes
the "Destination RREP Only" (DestOnly) TLV as part of the RFC 5444
message
header. This also assures that RREP_Gen increments its sequence
number. Otherwise, (if the optional behavior is enabled)
other AODVv2 routers MAY respond to the RREQ if they have an
valid route to TargNode (see <xref target="iRREP" />).</t>
<t><msg-hop-limit> SHOULD be set to MAX_HOPCOUNT.</t>
<t><msg-hop-count>, if included, MUST be set to 0.
<list style="symbols"><t>This RFC 5444 constraint causes the typical
RREQ payload to incur additional enlargement (otherwise,
<msg-hop-count> could often be used as the metric).</t>
</list></t>
<t>RREQ.AddrBlk[1] := OrigNode.Addr</t>
<t>RREQ.AddrBlk[2] := TargNode.Addr</t>
<t>If Route[OrigNode].PrefixLength/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
RREQ.AddrBlk. Otherwise,
RREQ.PrefixLength[OrigNode] := Route[OrigNode].PrefixLength
according to the rules of RFC 5444 AddrBlk encoding. </t>
<t>RREQ.AddrTLV.SeqNum[1] := RREQ_Gen SeqNum</t>
<t>RREQ.AddrTLV.SeqNum[2] := TargNode SeqNum (only if known)<vspace blankLines="1"/>
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's SeqNum.
If TargNode's SeqNum is not included, AODVv2 routers handling the RREQ
assumed that RREQ_Gen does not have that information.
If ENABLE_IRREP is enabled, then any route to TargNode
will satisfy the RREQ <xref target="I-D.perkins-irrep"/>.</t>
<t>RREQ.MetricTLV[1] := Route[OrigNode].Metric</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>This section specifies the generation of an RREP by an AODVv2
router (RREP_Gen) that provides connectivity for the Target Node
(TargNode) of a RREQ, thus satisfying the routing requirement for
packets to flow between OrigNode and TargNode.
If TargNode is not a unicast IP address the RREP MUST NOT
be generated, and processing for the RREQ is complete.
Before transmitting a RREP, the routing information of the RREQ
is processed as specified in <xref target="update_rte"/>.
The basic format of an RREP conforms to the structure for
RteMsgs as shown in <xref target="figRteMsg"/>.</t>
<t>RREP_Gen generates the RREP as follows:
<list style="numbers">
<t>RREP_Gen checks the RREQ against recently received RREQ information
as specified in <xref target="suppress"/>.
If a previously received RREQ has made the information in
the incoming RREQ to be useless, no RREP is generated and
processing is complete.</t>
<t>RREP_Gen MUST increment its SeqNum 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] := RREP_Gen's SeqNum</t>
<t>If Route[TargNode].PrefixLength/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
RREP.AddrBlk. Otherwise,
RREP.PrefixLength[TargNode] := Route[TargNode].PrefixLength
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-count>, if included, MUST be set to 0.</t>
<t><msg-hop-limit> SHOULD be set to
RREQ.<msg-hop-count>.</t>
<t>IP.DestinationAddr := Route[OrigNode].NextHop</t>
</list></t>
<t>An example 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 make use of 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.Metric is MetricTLV[OrigNode].
For RREP, RteMsg.Metric is MetricTLV[TargNode].
<list style="numbers">
<t>HandlingRtr MUST handle RteMsgs only from adjacent
routers as specified in <xref target="MsgStruct" />.
RteMsgs from other sources MUST be disregarded.
</t>
<t>HandlingRtr examines the RteMsg to ascertain that it contains
the required information: TargNode.Addr, OrigNode.Addr,
RteMsg.Metric, RteMsg.SeqNum and <msg-hop-limit>.
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 the Metric Type MsgTLV (if present) to assure that
the Metric Type associated with the Metric AddrTLV
information in the RREQ or RREP is known, and that Cost(L) can be
computed, where 'L' is the incoming link. If not, the message is
disregarded.
<list style="symbols">
<t>DISCUSSION: or, can change the AddrBlk metric to use
HopCount, e.g., measured from <msg-hop-count>.</t>
</list></t>
<t>If (MAX_METRIC[RteMsg.MetricType] - Cost(L)) ≤ RteMsg.Metric,
the RteMsg is disregarded, where Cost(L) denotes the cost of
traversing the incoming link (i.e., as measured by the
network interface receiving the incoming RteMsg).</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 for OrigNode
and TargNode contained in the RteMsg as specified 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>If RteMsg.<msg-hop-limit> is zero (0), no further
action is taken. Otherwise, HandlingRtr MUST decrement
RteMsg.<msg-hop-limit>.</t>
<t>If the RteMsg.<msg-hop-count> is present, and
<msg-hop-count> == MAX_HOPCOUNT,
then no further action is taken. Otherwise,
HandlingRtr MUST increment RteMsg.<msg-hop-count>
</t>
<t>By sending a RteMsg, HandlingRtr advertises that it will
route for addresses contained in the RteMsg based on
the information enclosed. HandlingRtr MAY choose not to send
the RteMsg, though not resending the RteMsg could decrease
connectivity in the network or result in nonoptimal paths.
The circumstances under which HandlingRtr might choose not to
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 more traffic</t>
<t>HandlingRtr recently transmitted identical routing
information (e.g. in a RteMsg advertising the same
metric) <xref target="suppress" /></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 a RteMsg, it halts
processing. Otherwise, further actions to transmit an updated
RteMsg depend upon whether
the incoming RteMsg is an RREP or an RREQ.</t>
</list></t>
<section anchor="RREQ_handle"
title="Additional Handling for Incoming RREQ">
<t><list style="symbols">
<t>If the upstream router is in the Blacklist, and
Current_Time < Blacklist.RemoveTime, then HandlingRtr MUST NOT
transmit any outgoing RteMsg, and processing is complete.</t>
<t>Otherwise, if the upstream router is in the Blacklist, and
Current_Time ≥ Blacklist.RemoveTime, then the upstream router
SHOULD be removed from the Blacklist, and message processing
continued.</t>
<t>The incoming RREQ MUST be checked against previously received
information from the RREQ Table <xref target="suppress"/>.
If the information in the incoming RteMsg is useless, then
then no further action is taken.</t>
<t>If TargNode is a client of HandlingRtr, then HandlingRtr generates
a RREP message as specified in <xref target="RREP_gen"/>, and
subsequently processing for the RREQ is complete. Otherwise,
processing continues as follows.</t>
<t>RREQ.MetricType := Route[OrigNode].MetricType</t>
<t>RREQ.MetricTLV[OrigNode] := Route[OrigNode].Metric</t>
<t>The RREQ (with updated fields as specified 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
Route[RREQ.TargNode].NextHopAddress.</t>
</list></t>
</section>
<section anchor="RREP_handle"
title="Additional Handling for Incoming RREP">
<t>As before, OrigNode and TargNode are named in the context of the
router (i.e., RREQ_Gen) originating the RREQ for which the RREP
was generated (see <xref target="notational-conventions"/>).
<list style="symbols">
<t> If no forwarding route exists to OrigNode, then a RERR SHOULD be
transmitted to RREP.AddrBlk[TargNode]. Otherwise, if
HandlingRtr is not RREQ_Gen then the outgoing RREP is sent to
the Route.NextHopAddress for the RREP.AddrBlk[OrigNode].
</t>
<t>If HandlingRtr is RREQ_Gen then the RREP satisfies
RREQ_Gen's earlier RREQ, and RREP processing is completed.
Any packets buffered for OrigNode should be transmitted.
</t>
</list></t>
</section>
<!-- CEP: TODO: Should specify that repeated RREQs deserve more attention -->
</section>
<section anchor="suppress" title="Suppressing Useless RteMsgs">
<t>Since RREQ messages are multicast, there are
common circumstances in which an AODVv2 router might respond
by sending out a RteMsgs (RREQ or RREQ) that is useless, given
the information transmitted after receiving in some other
recent RteMsg (see <xref target="supp-tbl" />). Before
transmitting a RteMsg,
AODVv2 routers MUST suppress such useless RteMsgs;
this is done by checking the list of recently received
RteMsgs to determine whether the incoming RteMsg
contains useful new information, as follows:
<list style="symbols">
<t>The AODVv2 router searches the RteMsg Table
for recent entries with the same OrigNode, TargNode,
and Metric Type. If there is no such entry, the incoming
RteMsg message is not suppressed.
A new entry for the incoming RteMsg information is created
in the RteMsg Table.</t>
<t>
If there is such an entry, and the incoming RteMsg has a newer
sequence number, the incoming RteMsg is not suppressed, and the
existing table entry MUST be updated to reflect the
new Sequence Number and Metric.
</t>
<t>Similarly, if the Sequence Numbers are the same, and the
incoming RteMsg offers a better Metric, the incoming
RteMsg not suppressed, and the RteMsg Table entry MUST
be updated to reflect the new Metric.
</t>
<t>Otherwise, the incoming RteMsg is suppressed.
</t>
</list>
</t>
<!--
If OrigNode & TargNode are different ==>> retransmit
==>> add new entry to table
If OrigNode & TargNode are same and new sequence number ==>> retransmit
==>> delete old entry from table
If OrigNode & TargNode & sequence number are same, and metric is better
==>> retransmit
==>> delete old entry from table
NOTE: must also specify insertion of new entries in Suppression table.
-->
</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 (denoted 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 upstream 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="Maintaining 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.</t>
<t>Similarly, if (Route.ExpirationTime == MAXTIME), and if
(Current_Time - Route.LastUsed) >
(ACTIVE_INTERVAL + MAX_IDLETIME),
the route has expired.</t>
<t>Furthermore, if Current_Time - Route.LastUsed >
(MAX_SEQNUM_LIFETIME), the
route table entry MUST be expunged.</t>
</list></t>
<t>If any of the above route error conditions hold true, the route
cannot be used to forward the packet, and an RERR message
MUST be generated (see <xref target="RERR_gen"/>). </t>
<t>Otherwise, 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>AODVv2 routers SHOULD monitor connectivity to adjacent
routers along active 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 link is broken</t>
<t>TCP timeouts</t>
<t>Other monitoring mechanisms or heuristics</t>
</list>
</t>
<t>If 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 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 Message Header <msg-hoplimit> <msg-hopcount> |
+---------------------------------------------------------------+
| UnreachableNode AddrBlk (Unreachable Node addresses) |
+---------------------------------------------------------------+
| UnreachableNode SeqNum AddrBlk TLV |
+---------------------------------------------------------------+
]]></artwork>
</figure></t>
<t> <list style="hanging">
<t hangText="Required Message Header Fields"><vspace />The RERR
MUST contain the following:
<list style="symbols">
<t><msg-hop-limit></t>
<t>PktSource Message TLV, if the RERR is unicast</t>
<t>Metric Type Message TLV, if MetricType != 3</t>
</list> </t>
<t hangText="Optional Message Header Fields"><vspace />The RERR
may contain the following:
<list style="symbols">
<t><msg-hop-count></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 each UnreachableNode when that information
is available. </t>
<t hangText="UnreachableNode.PrefixLength"><vspace />
The prefix length associated with an UnreachableNode.</t>
</list> </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 is chosen,
and in the way that the set of UnreachableNodes is identified.
</t>
<t>
In both cases, the <msg-hop-limit> MUST be included and
SHOULD be set to
MAX_HOPCOUNT. <msg-hop-count> SHOULD be be included
and set to 0, to facilitate use of various route repair strategies
including expanding rings multicast and
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
(either IP.DestinationAddress from a data packet or
RREP.AddrBlk[TargNode]).
The RERR SHOULD be sent to the multicast address
LL-MANET-Routers, but RERR_Gen MAY instead send the RERR
to the next hop towards the source IP address of the
packet which was undeliverable. In the latter case, the
PktSource Message TLV MUST be included, containing the
the source IP address of the undeliverable packet.
If SeqNum UnreachableNode is known, it SHOULD 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>
<t>
If an AODVv2 router receives an ICMP packet from
the address of one of its client nodes, it simply relays
the packet to the ICMP packet's destination address,
and does not generate any RERR message.
</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
adjacent AODVv2 router (i.e., the next hop of an active route).
In this case, the RERR MUST be sent to the multicast address
LL-MANET-Routers, except when the optional
feature of maintaining precursor lists is used as specified
in <xref target="precursor"/>.
All routes (Active, Idle and Expired) 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,
if allowed by the setting of ENABLE_IDLE_UNREACHABLE,
as long as the packet size of the RERR does not exceed the
MTU (interface "Maximum Transfer Unit") 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
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 INVALID_PREFIX_LENGTH, which is
a length strictly greater than the length of any valid address.
</t>
<t>Every broken route reported in the RERR MUST have the
same Metric Type. If the Metric Type is not 3, then
the RERR message MUST contain a MetricType MsgTLV
indicating the Metric Type of the broken route(s).
</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 delivery in the outgoing RERR message.
</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>(Optional) If precursor lists are 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 Message TLV 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, but 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>
<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 anchor="limit"
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 can be several sources of traffic
for a certain 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 when there are many precursors,
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 (RREP_Gen'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"/>
(subject to similar suppression algorithm for useless RREP multicasts
as described in
<xref target="suppress" />). The useless message suppression must
occur at every router handling the multicast RREP.
Afterwards, RREP_Gen processing for the incoming RREQ is complete.</t>
<t>Broadcast RREP 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" />. An example 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. Doing 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>Including additional routing information in outgoing RREQ or RREP
messages can eliminate some route
discovery attempts to the nodes whose information is
included, if AODVv2 routers receiving the information use it 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
Sequence Number associated with the AddedNode's 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>
<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 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 RteMsg.</t>
</section>
</section>
</section>
<!-- =================== Administrative Parameters ===================== -->
<section anchor="param" title="Administratively Configurable
Parameters and Timer Values">
<t>AODVv2 uses various configurable parameters of various types:
<list style="symbols">
<t>Timers</t>
<t>Protocol constants</t>
<t>Administrative (functional) controls</t>
<t>Other administrative parameters and lists</t>
</list>
The tables in the following sections show the parameters along
their definitions and default values (if any).</t>
<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, <msg-hop-count> is a 8-bit
field and therefore MAX_HOPCOUNT cannot be larger than 255.</t>
<section anchor="timers" title="Timers">
<t>AODVv2 requires certain timing information to be associated
with route table entries. The default values
are as follows, subject to future experience:</t>
<texttable anchor="timer-tbl"
title="Timing Parameter Values">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="left">Default Value</ttcol>
<c>ACTIVE_INTERVAL</c>
<c>5 second</c>
<c>MAX_IDLETIME</c>
<c>200 seconds</c>
<c>MAX_BLACKLIST_TIME</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>
</section>
<section anchor="constants" title="Protocol constants">
<t>AODVv2 protocol constants typically do not require changes.
The following table lists these constants, along with their values
and a reference to the specification describing their use.</t>
<texttable anchor="const-tbl"
title="Parameter Values">
<ttcol align="left" width="35%">Name</ttcol>
<ttcol align="left">Default Value</ttcol>
<ttcol align="left">Description</ttcol>
<c>DISCOVERY_ATTEMPTS_MAX</c>
<c>3</c>
<c><xref target="route_discovery"/></c>
<c>INVALID_PREFIX_LENGTH</c>
<c>255</c>
<c><xref target="RERR_gen_2"/>
</c>
<c>MAX_HOPCOUNT</c>
<c>20 hops</c>
<c><xref target="metrics" /></c>
<c>MAX_METRIC[i]</c>
<c>Specified only for HopCount</c>
<c><xref target="metrics" /></c>
<c>MAXTIME</c>
<c>[TBD]</c>
<c>Maximum expressible clock time</c>
<!-- Need to figure out what the time format. -->
</texttable>
</section>
<section anchor="controls" title="Administrative (functional) controls">
<t>The following administrative controls may be used to change the
operation of the network, by enabling optional behaviors.
These options are not required for
correct routing behavior, although they may
potentially reduce AODVv2 protocol messaging in certain
situations. The default behavior is to NOT enable most such options,
options. Packet buffering is enabled by default.</t>
<texttable anchor="suggestedoptions"
title="Administratively Configured Controls">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="left">Description</ttcol>
<c>APPEND_INFORMATION</c>
<c><xref target="addl-append"/></c>
<c>DEFAULT_METRIC_TYPE</c>
<c>3 {Hop Count (see <xref target="RFC6551"/>)}</c>
<c>ENABLE_IDLE_UNREACHABLE</c>
<c><xref target="RERR_gen_2"/></c>
<c>ENABLE_IRREP</c>
<c><xref target="RREQ_gen"/></c>
<c>USE_MULTICAST_RREP</c>
<c><xref target="mcast-to-RREQ"/></c>
</texttable>
</section>
<section anchor="other" title="Other administrative parameters and lists">
<t>The following table lists contains AODVv2 parameters which should
be administratively configured for each specific network.</t>
<texttable anchor="admincontrol"
title="Other Administrative Parameters">
<ttcol align="left" width="35%">Name</ttcol>
<ttcol align="left">Default Value</ttcol>
<ttcol align="left">Cross Reference</ttcol>
<c>AODVv2_INTERFACES</c>
<c></c>
<c><xref target="apply"/></c>
<c>BUFFER_SIZE_PACKETS</c>
<c>2</c>
<c><xref target="route_discovery"/></c>
<c>BUFFER_SIZE_BYTES</c>
<c>MAX_PACKET_SIZE [TBD]</c>
<c><xref target="route_discovery"/></c>
<c>CLIENT_ADDRESSES</c>
<c>AODVv2_INTERFACES</c>
<c><xref target="clients"/></c>
<c>CONTROL_TRAFFIC_LIMIT</c>
<c>TBD [50 packets/sec?]</c>
<c><xref target="limit"/></c>
</texttable>
</section>
</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="45%">Name</ttcol>
<ttcol align="center">Type (TBD)</ttcol>
<c>Route Request (RREQ)</c> <c>10</c>
<c>Route Reply (RREP)</c> <c>11</c>
<c>Route Error (RERR)</c> <c>12</c>
<c>Route Reply Acknowledgement (RREP_ACK)</c> <c>13</c>
</texttable>
</section>
<section anchor="msgtlvtypes"
title="Message TLV Type Specification">
<texttable anchor="msgtlvtbl" title="Message TLV Types">
<ttcol align="left" width="58%">Name</ttcol>
<ttcol align="center">Type (TBD)</ttcol>
<ttcol align="center">Length in octets</ttcol>
<ttcol align="left">Cross Reference</ttcol>
<c>Acknowledgment Request (AckReq)</c>
<c>10</c>
<c>0</c>
<c><xref target="blacklists"/></c>
<c>Destination RREP Only (DestOnly)</c>
<c>11</c>
<c>0</c>
<c><xref target="RREQ_gen"/></c>
<c>Packet Source (PktSource)</c>
<c>12</c>
<c>4 or 16</c>
<c><xref target="RERR_gen"/></c>
<c>Metric Type</c>
<c>13</c>
<c>1</c>
<c><xref target="RteMsgStruct"/></c>
</texttable>
</section>
<section anchor="addrtlvspec" title="Address Block TLV Specification">
<texttable anchor="addrtlvtypes"
title="Address Block TLV (AddrTLV) Types">
<ttcol align="left" width="45%">Name</ttcol>
<ttcol align="center">Type (TBD)</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Value</ttcol>
<c>Metric</c>
<c>10</c>
<c>depends on Metric Type</c>
<c><xref target="RteMsgStruct"/></c>
<c>Sequence Number (SeqNum)</c>
<c>11</c>
<c>2 octets</c>
<c><xref target="RteMsgStruct"/></c>
<c>VALIDITY_TIME</c>
<c>1</c>
<c>1 octet</c>
<c><xref target="RFC5497"/></c>
</texttable>
</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.
Non-addititve metrics are not supported in this draft.</t>
<texttable anchor="metric-tbl" title="Metric Types">
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Metric Size</ttcol>
<!--
<c>Reserved</c>
<c>0</c>
<c>Undefined</c>
-->
<c>Unallocated</c>
<c>0 -- 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 counts the number of hops
followed by the RteMsg from point of generation to the current
intermediate AODVv2 router handling
the RteMsg. Alternate metrics are enabled by the inclusion of the
MetricType Message TLV.
When there is no such MetricType Message TLV present, then the Metric
AddrTLV measures HopCount.
The Metric AddrTLV also provides a way for the AODV router generating
the RREQ or RREP to supply an initial nonzero cost for the route
to its client node (OrigNode or TargNode,
for RREQ or RREP respectively).</t>
<t>AddedNode information MAY be included in a RteMsg by
adding a second AddrBlk. Both Metric AddrTLVs use the
same Metric Type.
</t>
<t>In all cases, 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>
<section anchor="RREQ-format" title="RREQ Message Format">
<t><xref target="figRREQ"/> illustrates a packet format for an example RREQ
message.
<figure anchor="figRREQ"
title="Example IPv4 RREQ, with SeqNum and Metric AddrTLVs">
<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=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=28 | 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=Metric |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNodeHopCt |
+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble></postamble> -->
</figure>
<vspace blankLines="19" />
The fields in <xref target="figRREQ"/> are to be interpreted as follows:
<?rfc compact="yes" ?> <!-- conserve vertical whitespace -->
<?rfc subcompact="yes" ?> <!-- don't keep a blank line between list items -->
<list style="symbols">
<t>PV=0 (Packet Header Version = 0)</t>
<t>PF=0 (Packet Flags = 0)</t>
<t>msg-type=RREQ (first [and only] message is of type RREQ)</t>
<t>MF=4 (Message Flags = 4 [only msg-hop-limit field is present])</t>
<t>MAL=3
(Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)</t>
<t>AddrBlk flags:
<list style="symbols">
<t>bit 0 (ahashead): 1</t>
<t>bit 1 (ahasfulltail): 0</t>
<t>bit 2 (ahaszerotail): 0</t>
<t>bit 3 (ahassingleprelen): 0</t>
<t>bit 4 (ahasmultiprelen): 0</t>
<t>bits 5-7: RESERVED</t>
</list></t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both Originating & Target addresses)</t>
<t>Orig.Tail (4th byte of Originating Node IP address)</t>
<t>Target.Tail (4th byte of Target Node IP address)</t>
<t>addr.tlvs-length=11 (length in bytes for SeqNum and Metric TLVs</t>
<t>type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets)</t>
<t>AddrTLV flags for SeqNumTLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (SeqNum TLV values start at index 0)</t>
<t>tlv-length=2 (so there is only one TLV value, [1 = 2/2])</t>
<t>Orig.Node Sequence # (first [and only] TLV value for SeqNum TLVs</t>
<t>type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)</t>
<t>AddrTLV flags for MetricTLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (Metric TLV values start at index 0)</t>
<t>tlv-length=1 (so there is only one TLV value, [1 = 1/1])</t>
<t>OrigNodeHopCt (first [and only] TLV value for Metric TLVs)</t>
</list>
</t>
</section>
<section anchor="RREP-format" title="RREP Message Format">
<t><xref target="figRREP"/> illustrates a packet format for
an example RREP message.
<figure anchor="figRREP"
title="Example IPv4 RREP, with 2 SeqNums and 1 Metric">
<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=Metric |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=1 | TargNodeHopCt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble></postamble> -->
</figure>
<vspace blankLines="23" />
The fields in <xref target="figRREP"/> are to be interpreted as follows:
<list style="symbols">
<t>PV=0 (Packet Header Version = 0)</t>
<t>PF=0 (Packet Flags = 0)</t>
<t>msg-type=RREP (first [and only] message is of type RREP)</t>
<t>MF=4 (Message Flags = 4 [only msg-hop-limit field is present])</t>
<t>MAL=3
(Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)</t>
<t>AddrBlk flags:
<list style="symbols">
<t>bit 0 (ahashead): 1</t>
<t>bit 1 (ahasfulltail): 0</t>
<t>bit 2 (ahaszerotail): 0</t>
<t>bit 3 (ahassingleprelen): 0</t>
<t>bit 4 (ahasmultiprelen): 0</t>
<t>bits 5-7: RESERVED</t>
</list></t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both Originating & Target addresses)</t>
<t>Orig.Tail (4th byte of Originating Node IP address)</t>
<t>Target.Tail (4th byte of Target Node IP address)</t>
<t>addr.tlvs-length=13 (length in bytes for SeqNum and Metric TLVs</t>
<t>type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets)</t>
<t>AddrTLV flags for SeqNumTLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (SeqNum TLV values start at index 0)</t>
<t>tlv-length=4 (so there is are two TLV values, [2 = 4/2])</t>
<t>Orig.Node Sequence # (first of two TLV values for SeqNum TLVs</t>
<t>Targ.Node Sequence # (second of two TLV values for SeqNum TLVs</t>
<t>type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)</t>
<t>AddrTLV flags for MetricTLV [01010000, same as for SeqNumTLV]</t>
<t>Index-start=1 (Metric TLV values start at index 1)</t>
<t>tlv-length=1 (so there is only one TLV value, [1 = 1/1])</t>
<t>TargNodeHopCt (first [and only] TLV value for Metric TLVs)</t>
</list>
<vspace blankLines="23" />
</t>
</section>
<section anchor="RERR-format" title="RERR Message Format">
<t><xref target="figRERR"/> illustrates a packet format for an example RERR
message.
<figure anchor="figRERR"
title="Example IPv4 RERR with Two Unreachable Nodes">
<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=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=24 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 | Head (3 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=7 | type=SeqNum |0|0|1|1|0|1|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-length=4 | Dest_1 Sequence # | Dest_2 Seq# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest_2 Seq# |
+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble>RERR </postamble> -->
</figure>
The fields in <xref target="figRERR"/> are to be interpreted as follows:
<list style="symbols">
<t>PV=0 (Packet Header Version = 0)</t>
<t>PF=0 (Packet Flags = 0)</t>
<t>msg-type=RERR (first [and only] message is of type RERR)</t>
<t>MF=4 (Message Flags = 4 [only msg-hop-limit field is present])</t>
<t>MAL=3
(Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=24 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)</t>
<t>AddrBlk flags == 10000000
[same as RREQ and RREP AddrBlk examples]</t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both Unreachable Nodes, Dest_1 and Dest_2)</t>
<t>Dest_1.Tail (4th byte of Dest_1 IP address)</t>
<t>Dest_2.Tail (4th byte of Dest_2 IP address)</t>
<t>addr.tlvs-length=7 (length in bytes for SeqNum TLV</t>
<t>type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each)</t>
<t>AddrTLV flags for SeqNumTLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 0</t>
<t>bit 2 (thasmultiindex): 1</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 1</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (SeqNum TLV values start at index 0)</t>
<t>tlv-length=4 (so there is are two TLV values, [2 = 4/2])</t>
<t>Dest_1 Sequence # (first of two TLV values for SeqNum TLVs)</t>
<t>Dest_2 Sequence # (second of two TLV values for SeqNum TLVs)</t>
</list>
</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 |msgtype=RREPAck| MF=0 | MAL=3 | msg-size=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=4 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="changes"
title="Changes since revision ...-24.txt">
<t> The main goals of this revision are to improve readability and
to introduce a protocol update to handle suppression
of unnecessary multicast RREQs and certain other messages.
<list style="symbols">
<t>Specified operations for maintenance and use of RREQ Table
(see <xref target="supp-tbl"/>, <xref target="suppress" />).</t>
<t>Inserted explanations for example packet formats in appendix
(see <xref target="rfc5444-formats"/>).</t>
<t>Eliminated OwnSeqNum, RERR_dest, and various other abbreviations,
reworded relevant text.</t>
<t>Reorganized <xref target="param"/> into four sections so that the
various parameters are grouped more naturally into tables of
similar types.
</t>
<t>Replaced parameter descriptions in the tables in <xref target="param"/>,
with cross references to the parameter descriptions in the body of the
specification.</t>
<t>Created parameters and administrative controls ENABLE_IRREP and
MAX_BLACKLIST_TIME which had been alluded to in the body of the
specification.</t>
<t>Corrected metric comparison formulae to include cost of incoming link.</t>
<t>Renamed Unicast Response Request MsgTLV to be Acknowledgment Request.</t>
<t>Clarified <msg-hop-limit> and <msg-hop-count> mandates
and initialization.</t>
<t>Reformatted various tables to improve readability.</t>
<t>Changed some descriptions to apply to "Incoming" messages instead of
"Outgoing" messages, enabling simpler specification.</t>
<t>Many other minor editorial improvements to improve readability and
eliminate possibly ambiguities.</t>
</list></t>
</section>
<section anchor="prev_changes"
title="Changes between revisions ...-21.txt and ...-24.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 Message TLV defined.</t>
<t>Metric Address TLV 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 <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:36 |