One document matched: draft-ietf-manet-dymo-23.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:
== Text to allow CDS flooding of multicast RREQ
== Check on Route.Broken flag
== Route.Dist or Node.Dist is unknown or zero (what is the difference?)
== Check on uses of Route.Prefix
== Make packet formats
== Insert data structure for blacklisted nodes?
== Add processing for arbitrary metrics
++ 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-23" 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="RFC2119" />.
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 dropping packets,
when a route being used to forward packets from the source to a
destination breaks, and to avoid prematurely expunging routes
from the route table.</t>
<t>During route discovery, an AODVv2 router
initiates flooding of a Route Request message (RREQ) throughout the
network to find a route to a particular destination, via the
AODVv2 router responsible for this destination. During this
hop-by-hop flooding process, each intermediate AODVv2 router
receiving the RREQ message records a route to the originator.
When the target's AODVv2 router receives the RREQ, it records a
route to the originator and responds with a Route Reply (RREP) unicast
hop-by-hop toward the originating AODVv2 router. Each intermediate
AODVv2 router that receives the RREP creates a route to the
target, and then the RREP is unicast hop-by-hop toward the
originator. When the originator's AODVv2 router receives the RREP,
routes have then been established between the originating AODVv2
router and the target AODVv2 router in both directions.</t>
<t>Route maintenance consists of two operations. In order to
preserve routes in use, AODVv2 routers extend route lifetimes upon
successfully forwarding a packet. In order to react to changes
in the network topology, AODVv2 routers monitor traffic being
forwarded. When a data packet is received for forwarding and a
route for the destination is not known or the route is broken,
then the AODVv2 router of the source of the packet is notified.
A Route Error (RERR) is transmitted to indicate
the route to one or more affected destination addresses is Broken or
missing. When the source's AODVv2 router receives the RERR, it
marks the route as broken. Before the AODVv2 router can forward
a packet to the same destination, it has to
perform route discovery again for that destination.</t>
<t>Similarly to AODV, AODVv2 uses sequence numbers to ensure loop
freedom <xref target="Perkins99" />. Sequence numbers enable AODVv2
routers to determine the temporal order of AODVv2 route discovery
messages, thereby avoiding use of stale routing information.
Also, 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>Additionally, this document 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 relationship between
selected bi-directional neighboring routers for the purpose of
exchanging routing information. Not every pair of neighboring
routers will necessarily form an adjacency. Neighboring routers may
form an adjacency based on various information or other
protocols; for example, exchange of AODVv2 routing messages,
other protocols (e.g. NDP <xref target="RFC4861" /> or NHDP
<xref target="RFC6130" />), or manual
configuration. Loss of a routing adjacency may also
be based upon similar information; monitoring of
adjacencies where packets are being forwarded is required (see
<xref target="link_breaks" />).</t>
<!-- Why is this here????? TODO: change to "cost". Enable use of "metrics".
-->
<t hangText="Distance (Dist)"><vspace /> An unsigned integer
which measures the
distance a message or information element has traversed.
The minimum value of distance is the number of IP hops
traversed, 0 for local information. The maximum value
is 254. The value 255 is reserved to indicate that the
distance is unknown.</t>
<t hangText="AODVv2 Sequence Number (SeqNum)"><vspace />An AODVv2
Sequence Number is an unsigned integer maintained by each AODVv2
router. This sequence number guarantees the temporal order
of routing information to maintain loop-free routes.
The value zero (0) is reserved to indicate that the SeqNum
for a destination address is unknown.</t>
<t hangText="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="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.
corresponds to the AODVv2 router process currently performing
a calculation or processing a message.</t>
<t hangText="Flooding"><vspace /> In this document, flooding a message
refers to the process of delivering the message to every
AODVv2 router in the network. This may be done according to
methods specified in <xref target="RFC5148" />.</t>
<t hangText="Routable Unicast IP Address"><vspace/>
A routable unicast IP address is a unicast IP
address that when put into the IP.SourceAddress or
IP.DestinationAddress field is scoped sufficiently to be
forwarded by a router. Globally-scoped unicast IP addresses
and Unique Local Addresses (ULAs) <xref target="RFC6130" />
are examples of routable unicast IP addresses.</t>
<!-- Can a node determine whether an address is multihop-capable? [CEP] -->
<t hangText="Originating Node (OrigNode)"><vspace/>
The originating node is the data source node; if it is not
itself an AODVv2 router, its AODVv2 router creates a
AODVv2 RREQ message on its behalf in an effort to
flood some routing information. The originating node
is also referred to as a particular message's originator.</t>
<t hangText="Target Node (TargetNode)"><vspace />
The TargetNode denotes the ultimate destination of a message.</t>
<t hangText="This Node (ThisNode)"><vspace />
ThisNode denotes the AODVv2 router currently processing
an AODVv2 message.</t>
<t hangText="Route Error (RERR)"><vspace />
A RERR message is used to indicate that an AODVv2 router no longer
has a route to one or more particular destinations.</t>
<t hangText="Route Reply (RREP)"><vspace />
A RREP message is used to supply routing information about the RREQ
TargetNode to the RREQ OrigNode and 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.
<!-- MOVE THIS -->
When an AODVv2
router processes a RREQ, it learns routing information on
how to reach the RREQ OrigNode.</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>
</list></t>
</section>
<section title="Applicability Statement">
<t>The AODVv2 routing protocol is designed for stub (i.e., non-transit) or
disconnected (i.e., from the Internet) mobile ad hoc networks (MANETs).
AODVv2 handles a
wide variety of mobility patterns by dynamically 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 sparse traffic scenarios where any particular router
forwards packets to only a small percentage of the AODVv2 routers in
the network, due
to the on-demand nature of route discovery and route maintenance.
<!--
The nets do not have to be mobile, and AODVv2 may be applicable
in low power lossy sensor networks.
-->
</t>
<t>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
routing region be maintained.</t>
<t>AODVv2 supports routers with multiple interfaces.
In addition to routing for their local processes,
AODVv2 routers can also route on behalf of
other non-routing nodes (i.e., "hosts"), reachable via those interfaces.
Any such node which is not itself an AODVv2 router SHOULD NOT
be served by more than one AODVv2 router.
<!-- Need to relax this constraint -->
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 routers perform route discovery to find a route to a
particular destination. Therefore, AODVv2 routers MUST must be
configured to respond to RREQs for a certain set of addresses.
When AODVv2 is the only protocol interacting with the forwarding
table, AODVv2 MAY be
configured to perform route discovery for all unknown unicast
destinations.</t>
<t>At all times within an AODVv2 routing region, only one AODVv2 router
SHOULD be serve
any routing client. The coordination
among multiple AODVv2 routers to distribute
routing information correctly for a shared address (i.e. an address
that is advertised and can be reached via multiple AODVv2 routers) is
not described in this document. The AODVv2 router operation of shifting
responsibility for a routing client from one AODVv2 router to
another is mentioned in <xref target="change_address_location" />
Each AODVv2 router, if serving router clients other than itself,
is configured with information about the IP addresses of its clients.
There is no requirement that
an AODVv2 router have information about the router clients
of other AODVv2 routers.
Address assignment procedures are entirely out of scope for AODVv2.</t>
<t>AODVv2 only utilizes bidirectional links. In the case of
possible unidirectional links, either blacklists (see <xref
target="black" />) or other means (e.g. adjacency establishment
with only neighboring routers that have bidirectional
communication as indicated by NHDP <xref
target="RFC6130" />) of ensuring and monitoring
bi-directionality is recommended. Otherwise, persistent packet
loss could occur.</t>
<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
exact a performance penalty in case of AODVv2 router reboots.</t>
</section>
<section title="Data Structures">
<section title="Route Table Entry">
<t>The route table entry is a conceptual data structure.
Implementations may use any internal representation so long as
it provides access to the same information as specified below.</t>
<t>Conceptually, a route table entry has the following fields:
<list style="hanging">
<t hangText="Route.Address"><vspace />The (host or network)
destination address of the node(s) associated with the routing
table entry.</t>
<t hangText="Route.Prefix"><vspace />
The value is the length of the netmask/prefix. If the value
of the Route.Prefix 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 AODVv2 SeqNum
associated with a route table entry.</t>
<t hangText="Route.NextHopAddress"><vspace />An IP
address of the adjacent AODVv2 router on the path toward the
Route.Address.</t>
<t hangText="Route.NextHopInterface"><vspace />The
interface used to send packets toward the
Route.Address.</t>
<!--
<t hangText="Route.Forwarding"><vspace />A flag indicating
whether this Route can be used for forwarding data
packets. This flag MAY be provided for management and
monitoring.</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_proc" />).</t>
</list></t>
<t>The following field is optional:
<list style="hanging">
<t hangText="Route.Dist"><vspace />A dimensionless metric
indicating the distance traversed before reaching the
Route.Address node.</t>
</list>
Not including optional information may cause performance
degradation, but it will not prohibit the protocol from discovering
valid routes.</t>
<t>In addition to a route table data structure, each route
table entry may have several timers associated with the
information. Timers and timeouts are discussed in <xref
target="timeout" />.</t>
</section>
<section anchor="MsgStruct"
title="AODVv2 Message Structure and Information Elements">
<t hangText="IP ProtocolNumber and
UDP DestinationPort"><vspace />IP Protocol Number 138 (manet)
has been reserved for MANET protocols <xref target="RFC5498" />.
In addition to using this IP protocol number, AODVv2 may use UDP
at destination port 269 (manet) <xref target="RFC5498" />.</t>
<t>AODVv2 messages are transmitted in packets that conform to
the generalized packet and
message format as described in <xref target="RFC5444" />.
Here is a brief description of the format.
</t>
<t>
<list style="hanging">
<t><vspace /> A packet formatted according to RFC5444
contains zero or more messages. </t>
<t><vspace /> A message contains a message header,
message TLV block, and zero or more address blocks. </t>
<t><vspace /> Each of the address blocks may also have
an associated address TLV block.</t>
</list>
</t>
<t> All AODVv2 messages SHOULD be sent using the IP
protocol number (138) reserved for manet protocols <xref
target="RFC5498" />; or the UDP destination port (269)
reserved for manet protocols <xref target="RFC5498" /> and
IP protocol number for UDP.</t>
<t>Most AODVv2 messages are sent with the IP destination address
set to the link-local multicast address LL-MANET-Routers
<xref target="RFC5498" /> unless otherwise specified. Therefore,
all AODVv2 routers
SHOULD <!-- MUST? [CEP] -->
subscribe to LL-MANET-Routers <xref target="RFC5498" /> to
receiving AODVv2 messages. Note that multicast packets MAY be sent
via unicast. For example, this may occur for certain link-types
(non broadcast mediums), for manually configured router adjacencies,
or in order to improve robustness.</t>
<t>When describing AODVv2 protocol messages, it is necessary to
refer to fields in several distinct parts of the overall
packet. These locations include the IP header, the UDP header,
and fields from <xref target="RFC5444" />. This document
uses the notational conventions found in table 1.</t>
<texttable anchor="packetprefixes">
<ttcol align="center">Information Location</ttcol>
<ttcol align="center">Notational Prefix</ttcol>
<c>IP header</c> <c>IP.</c>
<c>RFC5444 message header</c> <c>MsgHdr.</c>
<c>RFC5444 message TLV</c> <c>MsgTLV.</c>
<c>RFC5444 address blocks</c> <c>AddBlk.</c>
<c>RFC5444 address block TLV</c> <c>AddTLV.</c>
</texttable>
<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 ignored by AODVv2.
This mechanism, known as "The Generalized TTL Security Mechanism"
(GTSM) <xref target="RFC5082" /> helps to ensure that packets
have not traversed any intermediate routers.</t>
<t>The length of an address (32 bits for IPv4 and 128 bits
for IPv6) inside an AODVv2 message depends on the
msg-addr-length (MAL) in the msg-header, as specified in
<xref target="RFC5444"/>.</t>
<!--t>If a packet contains only a single AODVv2 message and no
packet TLVs, it need not include a packet-header <xref
target="RFC5444" />.</t-->
<t>IP packets containing AODVv2 protocol messages SHOULD be
given priority queuing and channel access.</t>
<t>AODVv2 messages require the following information:
<list style="hanging">
<t hangText="IP.SourceAddress"><vspace />The IP address of
the node currently sending this packet. This field is
generally filled automatically by the operating system and
should not require special handling.</t>
<t hangText="IP.DestinationAddress"><vspace />The IP
address of the packet destination. For multicast messages the
IP.DestinationAddress is set to LL-MANET-Routers <xref
target="RFC5498" />. For unicast messages
the IP.DestinationAddress is set to the NextHopAddress
toward the TargetNode.</t>
<!-- Check this!! -->
<t hangText="MsgHdr.HopLimit"><vspace />The remaining
number of hops this message is allowed to traverse.
If an AODVv2 message within a RFC 5444 packet has exhausted
its hop limit, then it should be removed from the packet.
</t>
</list></t>
</section>
<section anchor="RteMsgIEs"
title="RteMsg-specific Protocol Elements">
<t>AODVv2 message types RREQ and RREP are denoted as Routing
Messages (RteMsgs) and used to flood routing information.
RREQ and RREP have similar information and function, but have
slightly different handling rules. The main difference between
the two messages is that RREQ messages are generally broadcast
to solicit a RREP, and conversely a RREP is the unicast
response to RREQ. RteMsg creation and handling are described
in <xref target="RteMsg"/>. </t>
<t>Unicast AODVv2 RteMsgs (e.g. RREP) unless otherwise
specified are sent with the IP destination
set to the Route.NextHopAddress of the route to the TargetNode.</t>
<t>A RteMsg REQUIRES the following information in addition to
the fields indicated in <xref target="MsgStruct"/>:
<list style="hanging">
<t hangText="AddBlk.TargetNode.Address"><vspace />
The IP address of the message TargetNode. In a RREQ the
IP address of the message TargetNode is the destination
address for which route
discovery is being performed. In a RREP the TargetNode is
the RREQ OrigNode address. The TargetNode address is the
first address in a routing message.</t>
<t hangText="AddBlk.OrigNode.Address"><vspace />
The IP address of the originator and its associated prefix
length. In a RREQ the OrigNode is the source's address and
prefix. In a RREP the OrigNode is the RREQ TargetNode's
address and prefix for which a RREP is being
generated. This address is the second address in the
message for RREQ.</t>
<t hangText="OrigNode.AddTLV.SeqNum"><vspace />The AODVv2
sequence number of the originator's AODVv2 router.</t>
</list></t>
<t>A RteMsg may optionally include the following information:
<list style="hanging">
<t hangText="TargetNode.AddTLV.SeqNum"><vspace />The last
known AODVv2 sequence number of the TargetNode.</t>
<!--
<t hangText="TargetNode.AddTLV.Dist"><vspace />The last
known Distance to the TargetNode.</t>
-->
<t hangText="AddBlk.AdditionalNode.Address"><vspace />The
IP address of an additional node that can be reached via
the AODVv2 router adding this information. Each
AdditionalNode.Address MUST include its prefix. Each
AdditionalNode.Address MUST also have an associated
Node.SeqNum in the address TLV block.</t>
<t hangText="AdditionalNode.AddTLV.SeqNum"><vspace />The
AODVv2 sequence number associated with this routing
information.</t>
<t hangText="OrigNode.AddTLV.Dist"><vspace />A metric of
the distance to reach the associated OrigNode.Address. This
field is incremented by at least one at each intermediate
AODVv2 router.</t>
<t hangText="AdditionalNode.AddTLV.Dist"><vspace />A
metric of the distance to reach the associated
AdditionalNode.Address. This field is incremented by at
least one at each intermediate AODVv2 router.</t>
</list></t>
<!-- TODO: redraw these, or else replace with text...
<figure anchor="figRM">
<preamble>Example IPv4 RREQ</preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IP Header
+-+-+-+-+-+-+-+-+
| IP.Proto = UDP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.SourceAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.DestinationAddress = LL-MANET-Routers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = manet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Header
+-+-+-+-+-+-+-+-+
| ver=0 |0|0|0|0|
+-+-+-+-+-+-+-+-+
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ-type |0|1|0|0| MAL=3 | msg-size=23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit |
+-+-+-+-+-+-+-+-+
Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=2 |1|0|0|0|0| Rsv | HeadLength=3 | Head :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Head (cont) | Target.Tail | Orig.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-block-size=6 |AODVv2SeqNum-type|0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=2 | Orig.SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
-->
</section>
<section title="Route Error (RERR)-specific Protocol Elements">
<t>A RERR message is used to flood the information
that a route is not available for one or more particular
addresses.</t>
<t>RERR creation and handling are described in <xref
target="route_maint" />.</t>
<t>A RERR requires the following information in addition to
the field indicated in <xref target="MsgStruct"/>:
<list style="hanging">
<t hangText="AddBlk.UnreachableNode.Address"><vspace />
The address of an UnreachableNode and its associated prefix
length. Multiple unreachable addresses may be included in
a RERR.</t>
</list></t>
<t>A Route Error may optionally include the following
information:</t>
<t><list style="hanging">
<t hangText="UnreachableNode.AddTLV.SeqNum"><vspace />
The last known AODVv2 sequence number of the unreachable
node. If a SeqNum for an address is zero (0) or not
included, it is assumed to be unknown. This case occurs
when a node receives a message to forward to a destination
for which it does not have any information in its routing
table.</t>
</list></t>
<!-- TODO: redraw these, or else replace with text...
<t><figure anchor="figRERR">
<preamble>Example IPv4 RERR</preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IP Header
+-+-+-+-+-+-+-+-+
| IP.Proto = UDP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.SourceAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.DestinationAddress = LL-MANET-Routers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = manet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Header
+-+-+-+-+-+-+-+-+
| ver=0 |0|0|0|0|
+-+-+-+-+-+-+-+-+
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RERR-type |0|1|0|0| MAL=3 | msg-size=15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit |
+-+-+-+-+-+-+-+-+
Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=1 |0|0|0|0|0| Rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnreachableNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-blk-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
-->
</section>
</section>
<section title="Detailed Operation for the Base Protocol">
<section anchor="seqnum" title="AODVv2 Sequence Numbers">
<t>AODVv2 sequence numbers allow AODVv2 routers to judge the freshness
of routing information and consequently ensure loop freedom.</t>
<section title="Maintaining A Node's Own Sequence Number">
<t>AODVv2 requires that each AODVv2 router in the network
maintain its own AODVv2 sequence number (OwnSeqNum). OwnSeqNum a
16-bit unsigned integer. An AODVv2 router increments its OwnSeqNum
under the circumstances described in <xref target="RteMsg"/>.</t>
<t>Incrementing an OwnSeqNum whose value is the largest
largest possible number representable as a 16-bit unsigned
integer (i.e., 65,535), MUST be set to one (1). In other
words, the sequence number after 65,535 is 1.</t>
</section>
<section title="Actions After OwnSeqNum Loss">
<t>An AODVv2 router SHOULD maintain its own sequence number in
persistent storage.</t>
<t>If an AODVv2 router's OwnSeqNum is lost, it MUST take
certain actions to avoid creating routing loops. To prevent
this possibility after OwnSeqNum loss an AODVv2 router MUST
wait for at least ROUTE_DELETE_TIMEOUT before fully
participating in the AODVv2 routing protocol. If an AODVv2
protocol message is received during this waiting period, the
AODVv2 router SHOULD perform normal route table entry updates
but MUST NOT transmit or retransmit any AODVv2 RREQ or RREP messages.
<!-- 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 this route is not available and reset its
waiting timeout. At the end of the waiting period the AODVv2
router sets its OwnSeqNum to one (1) and begin
participating.</t>
<t>The longest a node need wait is
ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the end of the maximum
waiting period a node SHOULD set its OwnSeqNum to one (1)
and begins participating.</t>
</section>
</section>
<section title="AODVv2 Routing Table Operations">
<section anchor="test" title="Judging Routing Information's Usefulness">
<t>Given a route table entry (Route.SeqNum, Route.Dist, and
Route.Broken) and incoming routing information for a particular
destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg
message type - RREQ/RREP), the incoming routing
information is classified as follows:
<list style="hanging">
<t hangText="1. Stale (Node.SeqNum < Route.SeqNum)"><vspace />
If Node.SeqNum < Route.SeqNum (using signed 16-bit
arithmetic) the incoming information is stale. Using stale
routing information is not allowed, since that might
result in routing loops.</t>
<t hangText="2. Not safe against loops"><vspace /> If Node.SeqNum
== Route.SeqNum, additional information MUST be
examined. If Route.Dist or Node.Dist is unknown or zero (0),
or if Node.Dist > Route.Dist + 1, then the incoming
information is not guaranteed to prevent routing loops.
Using such incoming routing information is not allowed.
The following pseudocode is offered to indicate the
logical condition under which the incoming information
is not guaranteed to protect against loops.
<figure>
<artwork><![CDATA[
(Node.SeqNum == Route.SeqNum) AND
((Node.Dist > Route.Dist + 1) OR
(Route.Dist is unknown) OR (Node.Dist is unknown))
]]></artwork>
</figure></t>
<t hangText="3. Offers no improvement"><vspace />In case
of known equal SeqNum, the information is considered worse
than the existing route table information in
multiple cases: (case i) if Node.Dist > Route.Dist
(it is a more expensive route) AND Route.Broken ==
false; (case ii) if Node.Dist == Route.Dist (equal
distance route) AND Route.Broken == false AND this RteMsg is a
RREQ. Such RREQs offer no improvement and SHOULD NOT be
retransmitted. Updating route table entries using such
incoming routing information is not allowed.
<!-- Why not for RREPs? -->
<figure>
<artwork><![CDATA[
((Node.SeqNum == Route.SeqNum) AND
(((Node.Dist > Route.Dist) AND (Route.Broken == false)) OR
((Node.Dist == Route.Dist) AND
(RteMsg is RREQ) AND (Route.Broken == false))))
]]></artwork>
</figure></t>
<t hangText="4. Offers improvement"><vspace /> Incoming routing
information that does not match any of the above criteria
is loop-free and better than the existing routing table
information.
<!--
Information is always preferable if
Node.SeqNum - Route.SeqNum > 0 (using signed 16-bit
arithmetic). In the case of equal sequence numbers, the
information is preferable in multiple cases: (case i) if
Node.Dist < Route.Dist; (case ii) if Node.Dist ==
Route.Dist + 1 AND Route.Broken == true (a broken route is
being repaired); (case iii) if Node.Dist == Route.Dist AND
it is a RREP (RREP with equal distance are forwarded) OR
Route.Broken == true (a broken route is being
repaired).
-->
We provide the following pseudo-code to determine whether
incoming routing information should be used to update
an existing route table entry.
<figure>
<artwork><![CDATA[
(/* signed 16-bit arithmetic */ Node.SeqNum - Route.SeqNum > 0) OR
((Node.SeqNum == Route.SeqNum) AND
[(Node.Dist < Route.Dist) OR
((Route.Broken == true) AND (Node.Dist <= Route.Dist + 1)) OR
((RteMsg is RREP) AND (Node.Dist == Route.Dist)]
]]></artwork>
</figure></t>
</list></t>
</section>
<section anchor="update_rte"
title="Creating or Updating Route Table Entries">
<t>Each route table entry is populated with the following information:
<list style="numbers">
<t>the Route.Address is set to Node.Address,</t>
<t>the Route.Prefix is set to the Node.Prefix.</t>
<t>the Route.SeqNum is set to the Node.SeqNum,</t>
<t>the Route.NextHopAddress is set to the IP.SourceAddress (i.e., an
address of the node that last transmitted the RteMsg packet)</t>
<t>the Route.NextHopInterface is set to the interface on which
the incoming AODVv2 packet was received,</t>
<t>the Route.Broken flag is set to false,</t>
<t>if known, the Route.Dist is set to the Node.Dist,</t>
</list>
<!--
Fields without known values are not populated with any value.
Are there any?? -->
</t>
<t>The timer for the minimum delete timeout (ROUTE_AGE_MIN)
is set to ROUTE_AGE_MIN_TIMEOUT. The timer for the maximum
delete timeout (ROUTE_SEQNUM_AGE_MAX) is set to
Node.AddTLV.VALIDITY_TIME <xref target="RFC5497" /> if
included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to
ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and
others are described in <xref target="timeout"/>.</t>
<t>With these assignments to the route table entry, a route has been
created and the Route.Forwarding flag set. Afterward, the route can be
used to send any buffered data packets and to forward any incoming data
packets for Route.Address. This route also fulfills any outstanding route
discovery (RREQ) attempts for Node.Address.</t>
</section>
<section anchor="timeout" title="Route Table Entry Timeouts">
<section title="Minimum Delete Timeout (ROUTE_AGE_MIN)">
<t>When an AODVv2 router transmits a RteMsg, other AODVv2
routers expect the transmitting AODVv2 router to have a
forwarding route to the RteMsg originator. A route table
entry SHOULD be kept in the route table for at least
ROUTE_AGE_MIN after it has been updated. Failure to maintain
the route table
entry might result in lost messages/packets, or
several duplicate messages.</t>
<t>After the ROUTE_AGE_MIN timeout a route can safely be
deleted.</t>
</section>
<section title="Maximum Sequence Number Delete Timeout
(ROUTE_SEQNUM_AGE_MAX)">
<t>Sequence number information for route table entries is time
sensitive, and MUST be deleted after a time in order to ensure
loop-free routing.</t>
<!-- Why?? [CEP] -->
<t>After the ROUTE_SEQNUM_AGE_MAX timeout a route's sequence
number information MUST be discarded.</t>
</section>
<section title="Recently Used Timeout (ROUTE_USED)">
<t>When a route is used to forward data packets, this
timer is set to expire after ROUTE_USED_TIMEOUT,
as discussed in <xref target="e2edata"/>.</t>
<t>If a route has not been used recently, then a timer for
ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT.</t>
</section>
<section title="Delete Information Timeout (ROUTE_DELETE)">
<t>As time progresses the likelihood that old routing
information is useful decreases, especially if the network
nodes are mobile. Therefore, old information SHOULD be
deleted.</t>
<t>After the ROUTE_DELETE timeout if a forwarding route
exists it SHOULD be removed, and the routing table entry
SHOULD also be deleted.</t>
<!--ROUTE_DELETE should be bigger than ROUTE_AGE_MIN-->
</section>
</section>
</section>
<section anchor="RteMsg" title="Routing Messages">
<section anchor="RREQ_create" title="RREQ Creation">
<t>Before an AODVv2 router creates a RREQ it SHOULD increment
its OwnSeqNum by one (1) according to the rules specified in
<xref target="seqnum" />. Incrementing OwnSeqNum will
ensure that all nodes with existing routing information will
consider this new information preferable to existing routing
table information. If the sequence number is not
incremented, certain AODVv2 routers might not consider this
information preferable, if they have existing better routing
information.</t>
<t>First, ThisNode adds the AddBlk.TargetNode.Address to the
RREQ; the unicast IP Destination Address for which a
forwarding route does not exist.</t>
<t>If a previous value of the TargetNode.SeqNum is known
(from a routing table entry using longest-prefix matching),
it SHOULD be placed in TargetNode.AddTLV.SeqNum in all but
the last RREQ attempt. If a TargetNode.SeqNum is not
included, it is assumed to be unknown by handling
nodes. This operation ensures that no intermediate AODVv2
routers reply, and ensures that the TargetNode's AODVv2 router
increments its sequence number.</t>
<t>Next, ThisNode adds AddBlk.OrigNode.Address, its prefix,
and the OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RteMsg.</t>
<t>The OrigNode.Address is the address of the source for
which this AODVv2 router is initiating this route
discovery. The OrigNode.Address MUST be a unicast
address. This information will be used by nodes to create a
route toward the OrigNode, enabling delivery of a RREP, and
eventually used for proper forwarding of data packets.</t>
<t>If OrigNode.Dist is included it is set to a number,
greater than zero (0), representing the distance between
OrigNode and ThisNode.</t>
<t>The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT.</t>
</section>
<section anchor="Tar_RREP_create" title="RREP Creation">
<t>First, the AddBlk.TargetNode.Address is added to the
RREP. The TargetNode is the ultimate destination of this
RREP; the RREQ OrigNode.Address.</t>
<t>Next, AddBlk.OrigNode.Address and prefix are added to the
RREP. The AddBlk.OrigNode.Address is the RREQ
TargetNode.Address. The AddBlk.OrigNode.Address MUST be a
unicast IP address. ThisNode SHOULD advertise the largest
known prefix containing AddBlk.OrigNode.Address.</t>
<t>When the RteMsg TargetNode's AODVv2 router creates a RREP,
if the TargetNode.SeqNum was not included in the RREQ,
ThisNode MUST increment its OwnSeqNum by one (1) according to the
rules specified in <xref target="seqnum" />.</t>
<t>If TargetNode.SeqNum was included in the RteMsg and
TargetNode.SeqNum - OwnSeqNum < 0 (using signed 16-bit
arithmetic), OwnSeqNum SHOULD be incremented by one (1)
according to the rules specified in <xref target="seqnum" />.</t>
<t>If TargetNode.SeqNum is included in the RteMsg and
TargetNode.SeqNum == OwnSeqNum (using signed 16-bit
<!-- Why?? [CEP] -->
arithmetic) and OrigNode.Dist will not be included in the RREP being
generated, OwnSeqNum SHOULD be incremented by one (1)
according to the rules specified in <xref target="seqnum" />.</t>
<t>If OwnSeqNum is not incremented the routing information
might be considered stale. In this case, the RREP might not
reach the RREP Target.</t>
<t>After any of the sequence number operations above, the
RREP OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also be added
to the RREP.</t>
<t>Other AddTLVs in the RREP for the OrigNode and TargetNode
SHOULD be included and set accordingly. If OrigNode.Dist is
included it is set to a number greater than zero (0) and
less than or equal to 254. The Distance value will
influence judgment of the routing information (<xref
target="test" />) against known information at other AODVv2
routers that handle this RteMsg.</t>
<t>The MsgHdr.HopLimit is set to MSG_HOPLIMIT.</t>
<t>The IP.DestinationAddress for RREP is set to the IP
address of the Route.NextHopAddress for the route to the
RREP TargetNode.</t>
</section>
<section anchor="RM_proc" title="RteMsg Handling">
<t>First, ThisNode examines the RteMsg to ensure that it
contains the required information: MsgHdr.HopLimit,
AddBlk.TargetNode.Address, AddBlk.OrigNode.Address, and
OrigNode.AddTLV.SeqNum. If the required information does not
exist, the message is discarded and further processing
stopped. </t>
<t>ThisNode MUST only handle AODVv2 messages from adjacent routers.
</t>
<t>ThisNode checks if the AddBlk.OrigNode.Address is a valid
routable unicast
address. If not, the
message is ignored and further processing stopped.</t>
<t>ThisNode also checks whether AddBlk.OrigNode.Address is
an address handled by this AODVv2 router. If this node is the
originating AODVv2 router, the RteMsg is dropped.</t>
<t>ThisNode checks if the AddBlk.TargetNode.Address is a
valid routable unicast address. If the address is
not a valid unicast address, the message is discarded and
further processing stopped.</t>
<t>Next, ThisNode checks whether its routing table has an
entry to the AddBlk.OrigNode.Address using longest-prefix
matching <xref target="RFC1812" />. If a route with a valid
Route.SeqNum does not exist, then the new routing
information is used to create a new route table
entry is created and updated as described in <xref
target="update_rte" />. If a route table entry does exists
and it has 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 considered preferable, the route table entry
is updated as described in <xref target="update_rte" />.</t>
<t>At this point, if the routing information for the
OrigNode was not preferable then this RteMsg SHOULD be discarded
and no further processing of this message SHOULD be
performed.</t>
<t>If the TargetNode is a router client of ThisNode this RteMsg
is a RREQ, then ThisNode responds
with a RREP to the RREQ OrigNode (the new RREP's
TargetNode). The procedure for issuing a new RREP is
described in <xref target="Tar_RREP_create" />. Afterwards,
ThisNode need not perform any more operations for the
RteMsg being processed.</t>
<t>As an alternative to issuing a RREP, ThisNode MAY choose
to distribute routing information about ThisNode (the RREQ
TargetNode) more widely. That is, ThisNode MAY optionally
perform a route discovery by issuing a RREQ with ThisNode
listed as the TargetNode, using the procedure in <xref
target="RREQ_create" />. At this point, ThisNode need not
perform any more operations for the RteMsg being processed.</t>
<!-- Note: I think this is supposed to enable "broadcast RREP". -->
<t>For each address (except the TargetNode) in the RteMsg that
includes AddTLV.Dist information, the AddTLV.Dist
information is incremented by at least one (1). The updated
Distance value will influence judgment of the routing
information (<xref target="test" />) against known
information at other AODVv2 routers that handle this RteMsg.</t>
<t>If the resulting Distance value for the OrigNode is
greater than 254, the message is discarded. If the
resulting Distance value for another node is greater than
254, the associated address and its information are
removed from the RteMsg. If the MsgHdr.HopLimit is equal to one (1),
then the message is discarded. Otherwise, the MsgHdr.HopLimit is
decremented by one (1).</t>
<t>If ThisNode is not the TargetNode, AND this RteMsg is a RREQ,
then the current RteMsg (as altered by the procedure defined above)
SHOULD be sent to the IP multicast address LL-MANET-Routers
<xref target="RFC5498" />. If the RREQ is unicast, the
IP.DestinationAddress is set to the NextHopAddress.</t>
<t>If ThisNode is not the TargetNode, AND this RteMsg is a
RREP, then the current RteMsg is sent to the
Route.NextHopAddress for the RREP's TargetNode.Address. If
no forwarding route exists to TargetNode.Address, then a RERR
SHOULD be issued to the OrigNode of the RREP.</t>
<t>By sending the updated RteMsg, ThisNode advertises that it
will route for addresses contained in the outgoing
RteMsg based on the information enclosed. ThisNode MAY choose
not to send the RteMsg, though not resending this RteMsg could
decrease connectivity in the network or result in a
non-shortest distance path.</t>
<t>The circumstances under which ThisNode might choose to not
re-issue a RteMsg are not specified in this document. Some examples
might include the following:</t>
<t><list style="symbols">
<t>if ThisNode does not want to advertise
routing for the contained addresses because it is already
heavily loaded</t>
<t>if ThisNode has already issued
identical routing information (e.g. ThisNode had recently
issued a RteMsg with the same distance)</t>
<t>if ThisNode
is low on energy and does not want to expend energy for
protocol message sending or packet forwarding</t>
</list>
</t>
</section>
</section>
<section anchor="route_discovery" title="Route Discovery">
<t>When an AODVv2 router needs to forward a data packet
and it does not have a forwarding route to the destination
address, it sends a RREQ (described in <xref
target="RREQ_create" />) to discover a route to the particular
destination (TargetNode).</t>
<t>After issuing a RREQ, the AODVv2 router (OrigNode) waits for a
RREP indicating the next hop for a route to the TargetNode. If a
route is not created within RREQ_WAIT_TIME, OrigNode may again try to
discover a route by issuing another RREQ using the procedure
defined in <xref target="RREQ_create" /> again. Route
discovery SHOULD be considered to have failed after
DISCOVERY_ATTEMPTS_MAX and the corresponding
wait time for a response to the final RREQ.</t>
<!-- Needed: a timeout parameter for the length of time before next RREQ -->
<t>To reduce congestion in a network, repeated attempts at
route discovery for a particular TargetNode SHOULD utilize an
binary exponential backoff.</t>
<!--
<t>For example, the first time an AODVv2 router issues a RREQ, it
waits RREQ_WAIT_TIME for a route to the TargetNode. If a route
is not found within that time, the AODVv2 router MAY send
another RREQ. If a route is not found within two (2) times the
current waiting time, another RREQ MAY be sent. No more than
DISCOVERY_ATTEMPTS_MAX route discovery attempts SHOULD be made
before considering route discovery for this destination to
have failed. For each additional attempt, the waiting time for
the previous RREQ is multiplied by two (2) so that the waiting
time conforms to a binary exponential backoff.</t>
-->
<t>Data packets awaiting a route SHOULD be buffered by the
source's AODVv2 router. 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, and therefore settings for buffering
(BUFFER_DURING_DISCOVERY) SHOULD be administratively
configurable. Nodes without sufficient memory available for
buffering may be configured with BUFFER_DURING_DISCOVERY = FALSE;
this will affect the latency required for launching TCP applications
to new destinations.</t>
<t>If a route discovery attempt has failed (i.e. an attempt or
multiple attempts have been made without receiving a RREP) to
find a route to the TargetNode, any data packets buffered for
the corresponding TargetNode 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 the AODVv2 router is not the source
(OrigNode), then
the ICMP is sent over the interface from which the source sent the
packet to the AODVv2 router. </t>
</section>
<section anchor="route_maint" title="Route Maintenance">
<t>A RERR SHOULD be issued if a data packet is to be forwarded
and it cannot be delivered to the next-hop because no
forwarding route for the IP.DestinationAddress exists; RERR
generation is described in <xref target="rerr_create" />.</t>
<t>Upon this condition, an ICMP Destination Unreachable
message SHOULD NOT be generated unless this router is
responsible for the IP.DestinationAddress and that
IP.DestinationAddress is known to be unreachable.</t>
<t>In addition to inability to forward a data packet, a RERR
SHOULD be issued immediately after detecting a broken link
(see <xref target="link_breaks" />) of a forwarding route to
quickly notify AODVv2 routers that certain routes are no
longer available. If a newly unavailable route has not been
used recently (indicated by ROUTE_USED), the RERR SHOULD NOT
be generated. </t>
<section anchor="link_breaks" title="Active Next-hop Router
Adjacency Monitoring">
<t>Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2
routers on forwarding routes. This monitoring can be
accomplished by one or several mechanisms, including:</t>
<t><list style="symbols">
<t>Neighborhood discovery <xref target="RFC6130" /></t>
<t>Route timeout</t>
<t>Lower layer trigger that a neighboring
router is no longer reachable</t>
<t>Other monitoring mechanisms or heuristics</t>
</list>
</t>
<t>Upon determining that a next-hop AODVv2 router has become
unreachable, ThisNode MUST remove the affected forwarding
routes (those using the unreachable next-hop) and unset the
Route.Forwarding flag. ThisNode also flags the associated
routes in AODVv2's routing table as Broken. For each broken
route the timer for ROUTE_DELETE is set to
ROUTE_DELETE_TIMEOUT.</t>
</section>
<section anchor="e2edata"
title="Updating Route Lifetimes During Packet Forwarding">
<t>To avoid removing the forwarding route to reach an
IP.SourceAddress, ThisNode SHOULD set the "ROUTE_USED" timeout
to the value ROUTE_USED_TIMEOUT for the route to that
IP.SourceAddress upon receiving a data packet or an
AODVv2 message. If the timer
for ROUTE_DELETE is set, that timer is removed.
The Route.Broken flag is unset.
</t>
<t>To avoid removing the forwarding route to the
IP.DestinationAddress that is being used, ThisNode SHOULD set the
"ROUTE_USED" timeout to the value ROUTE_USED_TIMEOUT for the
route to the IP.DestinationAddress upon sending a data
packet or an AODVv2 message. If the timer for ROUTE_DELETE
is set, it is removed. The Route.Broken flag is unset.
</t>
</section>
<section anchor="rerr_create" title="RERR Generation">
<t> When an AODVv2 router receives a packet (from PrevHopAddress),
and the router (ThisNode) does not have a route available for
the destination of the packet, ThisNode uses an RERR message
is used to inform one or more neighboring AODVv2 routers that
its route to the packet destination is no longer available.</t>
<t>When ThisNode creates a new RERR, the
address of the first UnreachableNode (IP.DestinationAddress
from a data packet or RREP.TargetNode.Address) is inserted
into an Address Block AddBlk.UnreachableNode.Address.
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. If a value for the
UnreachableNode's SeqNum (UnreachableNode.AddTLV.SeqNum) is
known, it SHOULD be placed in the RERR. The MsgHdr.HopLimit
SHOULD be set to MSG_HOPLIMIT.</t>
<t>If SeqNum information is not known or not included in the
RERR, all nodes handling the RERR will assume their routing
information associated with the UnreachableNode is no
longer valid and flag those routes as broken.</t>
<t>A RERR MAY be sent to the multicast address LL-MANET-Routers
<xref target="RFC5498" />, thus
notifying all nearby AODVv2 routers that might depend on the
now broken link. If the RERR is unicast, the
IP.DestinationAddress is set to the PrevHopAddress.</t>
<t>After sending the RERR, ThisNode SHOULD discard the packet or
message that triggered generation of the RERR.</t>
</section>
<section anchor="rerr_proc" title="RERR Handling">
<t>First, ThisNode examines the incoming RERR to ensure that it
contains MsgHdr.HopLimit and
AddBlk.UnreachableNode.Address. If the required information
does not exist, the incoming RERR message is discarded and further
processing stopped. </t>
<t>When an AODVv2 router handles a RERR, it examines the
information for each UnreachableNode. The AODVv2 router
removes the forwarding route, unsets the Route.Forwarding
flag, sets the Route.Broken flag, and the timer for
ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each
UnreachableNode.Address found using longest prefix matching
that meets all of the following conditions:</t>
<t><list style="numbers">
<t>The UnreachableNode.Address is a routable
unicast address.</t>
<t>The Route.NextHopAddress is the same as the RERR
IP.SourceAddress.</t>
<t>The Route.NextHopInterface is the same as the interface on
which the RERR was received.</t>
<t>The Route.SeqNum is zero (0), unknown, OR the
UnreachableNode.SeqNum is zero (0), unknown, OR
Route.SeqNum - UnreachableNode.SeqNum <= 0 (using
signed 16-bit arithmetic).</t>
</list></t>
<t>If Route.SeqNum is zero (0) or unknown
and UnreachableNode.SeqNum exists in the RERR and is not
zero (0), then Route.SeqNum SHOULD be set to
UnreachableNode.SeqNum. Setting Route.SeqNum can reduce
future RERR handling and forwarding.</t>
<t>Each UnreachableNode that did not result in marking a route
table entry as broken route is removed from the RERR, since
propagation of such information will not result in any benefit.</t>
<t>Each UnreachableNode that did indicate a broken route
SHOULD remain in the RERR.</t>
<t>If any UnreachableNode was removed, all other information
(AddTLVs) associated with the UnreachableNode address(es) MUST
also be removed.</t>
<t>If Route.SeqNum is known and an
UnreachableNode.SeqNum is not included in the RERR, then
Route.SeqNum (i.e. UnreachableNode.SeqNum) MAY be included with
the RERR. Including UnreachableNode.SeqNum can reduce future
RERR handling and forwarding.</t>
<t>If no UnreachableNode addresses remain in the RERR,
or if the MsgHdr.HopLimit is equal to one (1), then
the RERR MUST be discarded.</t>
<t>Otherwise, the MsgHdr.HopLimit is decremented by one (1).
The RERR SHOULD be sent to the multicast address
LL-MANET-Routers <xref target="RFC5498" />. Alternatively, if
the RERR is unicast, the IP.DestinationAddress is set to the
PrevHopAddress.</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 ignored.</t>
<t>For handling of messages that contain unknown TLV types,
ignore the information for processing, preserve it
unmodified for forwarding.</t>
</section>
<section anchor="prefix" title="Advertising Network Addresses">
<t>AODVv2 routers MAY specify a prefix length for each advertised
address. Any nodes (other than the advertising AODVv2 router)
within the advertised prefix MUST NOT participate in the AODVv2
protocol directly. For example, advertising 192.0.2.1 with a
prefix length of 24 indicates that all nodes with the matching
192.0.2.X are reachable through this AODVv2 router. An AODVv2
router MUST NOT advertise network addresses unless it can
guarantee its ability for forwarding packets to any host address
within the address range of the corresponding network.</t>
</section>
<section anchor="gateway"
title="Simple Internet Attachment">
<t>Simple Internet attachment consists of a stub (i.e., non-transit)
network of AODVv2 routers connected to the Internet via a single Internet
AODVv2 router (IAR).</t>
<t>As in any Internet-attached network,
AODVv2 routers, and hosts behind these routers, wishing to be
reachable from hosts on the Internet MUST have IP addresses
within the IAR's routable and topologically correct prefix
(e.g. 192.0.2.0/24).</t>
<t>The IAR is responsible for generating RREQ to find nodes
within the AODVv2 Region on behalf of nodes on the Internet, as
well as responding to route requests from the AODVv2 region on
behalf of the nodes on the Internet.</t>
<figure anchor="net_top" title="Simple Internet Attachment Example">
<artwork><![CDATA[
/--------------------------\
/ Internet \
\ /
\------------+-------------/
|
Routable & |
Topologically |
Correct |
Prefix |
+-----+--------+
| Internet |
/------| AODVv2 |-------\
/ | Router | \
/ |192.0.2.1/32 | \
| |Responsible | |
| | for | |
| |AODVv2 Region | |
| |192.0.2.0/24 | |
| +--------------+ |
| +----------------+ |
| | AODVv2 Router | |
| | 192.0.2.2/32 | |
| +----------------+ |
| +----------------+ |
| | AODVv2 Router | |
| | 192.0.2.3/32 | |
\ +----------------+ /
\ /
\-----------------------------/
]]></artwork>
</figure>
<t>When an AODVv2 router within the AODVv2 Region wants to discover
a route to 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 the Internet destination.</t>
<t>When a packet from a node on the Internet destined for a
node in the AODVv2 region reaches the IAR, if the IAR does not
have a route to that destination it will perform normal AODVv2
route discovery for that destination.</t>
</section>
<section title="Multiple Interfaces">
<t>AODVv2 may be used with multiple interfaces; therefore, the
particular interface over which packets arrive MUST be known
whenever a packet is received. Whenever a new route is
created, the interface through which the Route.Address can be
reached is also recorded in the route table entry.</t>
<t>When multiple interfaces are available, a node transmitting
a multicast packet with IP.DestinationAddress set to
LL-MANET-Routers SHOULD send the packet on all interfaces that
have been configured for AODVv2 operation.</t>
<t>Similarly, AODVv2 routers SHOULD subscribe to
LL-MANET-Routers on all their AODVv2 interfaces.</t>
</section>
<section title="AODVv2 Control Packet/Message Generation Limits">
<t>To ensure predictable messaging overhead, 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> Several optional features of AODVv2, and 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>
</list>
</t>
<section anchor="rings" title="Expanding Rings Multicast">
<t>For multicast RREQ, the MsgHdr.HopLimit 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.draft-perkins-irrep"/> -->.</t>
</section>
<section anchor="precursor" title="Precursor Notification">
<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. This document specifies
a simple modification to AODVv2 (and possibly other reactive routing
protocols) enabling faster notifications to known sources of traffic
upon determination that a route for such traffic's destination has
become Broken.</t>
<section title="Overview">
<t>If an AODVv2 router, while attempting to forward a packet to
a particular destination, determines that the next hop (one of
its neighbors) is no longer reachable, AODVv2 specifies that
the router notify the source of that packet that the route to
the destination has become Broken. In the existing specification,
the notification to the source is a unicast RERR message.</t>
<t>However, in many cases there will be several sources of
of traffic for that particular destination. In fact, the
broken link for the next hop in question may be a path component
of numerous other routes for other destinations, and in that case
the node detecting the broken link must mark as Broken multiple
routes, one for each of the newly unreachable destinations.
Each route that uses the newly broken link is no longer valid.
For each such route, every node along the way from the source
using that route, to the node detecting the broken link, is
known as a "precursor" for the broken next hop.
All the precursors for a particular next hop
should be notified about the change in status of their route
to a destination downstream from the broken next hop.
</t>
</section>
<section anchor="Precursor Notification Details"
title="Precursor Notification">
<t>During normal operation, each node wishing to enable the
improved notification for precursors of any links to its
next hop neighbors has to keep track of the precursors.
This is done by maintaining a precursor table and updating
the table whenever the node initiates or relays a RREP
message back to a node originating a RREQ message. When the
node transmits the RREP message, it is implicitly agreeing
to forward traffic from the RREQ originator towards the
RREP originator (i.e., along the next hop link to the
neighbor from which the RREP was received). The "other"
next hop, which is the neighbor along the way towards the
originator of the RREQ message, is then the next precursor
for the route towards the destination requested by the RREQ.</t>
<t>Each such precursor should then be recorded as a precursor for
a route along the next hop. The same next hop may be in service
for routes to multiple destinations, but for precursor list
management it is only important to keep track of precursors
for a particular next hop; the exact destination does not
matter, only the particular next hop towards the destination(s).
</t>
<t>When a node observes that one of its neighbors is no longer
reachable, the node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>Otherwise, for all destinations no longer reachable because of
the changed status of the next hop, the
node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>For each precursor of the next hop, the node MAY notify the
precursor in one of three ways:</t>
<t><list style="symbols">
<t>unicast RERR</t>
<t>broadcast RERR</t>
<t>multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS</t>
</list>
</t>
<t>Each precursor then MAY execute the same procedure until all
affected traffic sources have received the RERR route
maintenance information.</t>
<t>When a precursor receives a unicast RERR, the precursor
MUST further unicast the RERR message
towards the affected traffic source.
If a precursor receives a broadcast or multicast RERR,
the precursor MAY further retransmit the RERR towards
the traffic source.
</t>
</section>
</section>
<section anchor="bigger-RERR" title="Reporting Multiple Unreachable Nodes">
</section>
<section anchor="aggreg" title="Message Aggregation">
<t>The aggregation of multiple messages into a packet is not
specified in this document, but if aggregation does occur
the IP.SourceAddress and IP.DestinationAddress of all
contained messages MUST be the same.</t>
<t>Implementations MAY choose to temporarily 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_append"
title="Adding Additional Routing Information to a RteMsg">
<t>DSR <xref target="RFC4728" /> includes source routes as part of
the data of its RREPs and RREQs. Doign so allows additional
topology information to be flooded along with the RteMsg,
and potentially allows updating for stale routing information
at MANET routers along new paths between source and
destination. To maintain this functionality, AODVv2 has
defined a somewhat more general method that enables inclusion
of source routes in RteMsgs.
</t>
<t>Appending routing information can alleviate route
discovery attempts to the nodes whose information is
included, if other AODVv2 routers use this information to
update their routing tables.</t>
<t>Note that, since the initial merger of DSR with AODV to
create this protocol, further experimentation has shown
that including
the additional routing information is not always helpful.
Sometimes it seems to help, and other times it seems to
reduct overall performance.
</t>
<t>AODVv2 routers can append 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>Prior to appending an address controlled by this AODVv2
router to a RteMsg, ThisNode MAY increment its OwnSeqNum as
defined in <xref target="seqnum" />. If OwnSeqNum is not
incremented the appended routing information might not be
considered preferable, when received by nodes with existing
routing information. Incrementation of the sequence number
when appending information to a RteMsg in transit
(APPEND_INFORMATION_SEQNUM) SHOULD be administratively
configurable. Note that, during
handling of this RteMsg OwnSeqNum may have already been
incremented; and in this case OwnSeqNum need not be
incremented again.</t>
<t>If an address controlled by this AODVv2 router includes
ThisNode.Dist, it is set to a number greater than zero (0).</t>
<t>For added addresses (and their prefixes) not controlled
by this AODVv2 router, Route.Dist can be included if known.</t>
<t>The VALIDITY_TIME of routing information for appended
address(es) MUST be included, to inform routers about when
to delete this information. The VALIDITY_TIME TLV is
defined in <xref target="addrtlvspec" />.</t>
<t>Additional information (e.g. SeqNum and Dist) about any
appended address(es) SHOULD be included.</t>
<t>Note that the routing information about the TargetNode
MUST NOT be added. Also, duplicate address entries SHOULD
NOT be added. Instead, only the best routing information
(<xref target="test" />) for a particular address SHOULD be
included.</t>
<t>Intermediate nodes obey the following procedures when
processing AddBlk.AdditionalNode.Address information and other
associated TLVs that are included with a RteMsg.
For each address (except the TargetNode) in the RteMsg that
includes AddTLV.Dist information, the AddTLV.Dist
information MUST be incremented. If the resulting Distance
value for the OrigNode is greater than 254, the message
is discarded. If the resulting Distance value for another
node is greater than 254, 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, ThisNode
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 AdditionalNode.Address
is not used, then it is removed from the RteMsg.</t>
</section>
</section>
<!-- =================== Administrative Parameters ===================== -->
<section anchor="param" title="Administratively Configured
Parameters and Timer Values">
<t>AODVv2 contains several parameters which MUST be administratively
configured. The list of these follows:</t>
<texttable anchor="suggestedoptions">
<preamble>Required Administratively Configured Parameters</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Description</ttcol>
<!-- Move to AODV2 Extensions document
TODO
<c>DID</c>
<c>All AODVv2 routers with the same DID that come in contact
with each other MUST operate with a compatible set of
configuration options, timing parameters, and protocol
extensions. If non-default potentially incompatible options,
timing parameters or protocol extensions are utilized the DID
MUST be set to a non-zero value.</c>
-->
<c>RESPONSIBLE_ADDRESSES</c>
<c>List of addresses or routing prefixes, for
which this AODVv2 router is responsible. If,
RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only
responsible for its own addresses.</c>
<c>AODVv2_INTERFACES</c>
<c>List of the interfaces participating in AODVv2 routing protocol.</c>
</texttable>
<t>AODVv2 contains a number of timers. The default timing
parameter values follow:</t>
<texttable anchor="suggestedparam">
<preamble>Default Timing Parameter Values</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Value</ttcol>
<c>ROUTE_TIMEOUT</c>
<c>5 seconds</c>
<c>ROUTE_AGE_MIN_TIMEOUT</c>
<c>1 second</c>
<c>ROUTE_SEQNUM_AGE_MAX_TIMEOUT</c>
<c>600 seconds</c>
<c>ROUTE_USED_TIMEOUT</c>
<c>ROUTE_TIMEOUT</c>
<c>ROUTE_DELETE_TIMEOUT</c>
<c>2 * ROUTE_TIMEOUT</c>
<c>ROUTE_RREQ_WAIT_TIME</c>
<c>2 seconds</c>
<c>UNICAST_MESSAGE_SENT_TIMEOUT</c>
<c>1 second</c>
</texttable>
<t>The above timing parameter values work 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 ROUTE_USED_TIMEOUT may be set to a much larger
value.</t>
<texttable anchor="otherparam">
<preamble>Default Parameter Values</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Description</ttcol>
<c>MSG_HOPLIMIT</c>
<c>20 hops</c>
<c>This value MUST be larger than the AODVv2 network
diameter. Otherwise, routing messages may not reach their
intended destinations.</c>
<c>DISCOVERY_ATTEMPTS_MAX</c>
<c>3</c>
<c>The number of route discovery attempts to make before
indicating that a particular address is not reachable.</c>
</texttable>
<t>In addition to the above parameters and timing values,
several administrative options exist. These options have no
influence on correct routing behavior, although they may
potentially reduce AODVv2 protocol messaging in certain
situations. The default behavior is to NOT enable any of these
options; and although many of these options can be
administratively controlled, they may be better served by
intelligent control. The following table enumerates several of
the options.</t>
<texttable anchor="adminoptions">
<preamble>Administratively Controlled Options</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Description</ttcol>
<!-- TODO: move to AODVv2 Extensions document, note lack of justification
for use of Path Accumulation
<c>APPEND_INFORMATION</c>
<c>Whether to append ThisNode's routing information to a
RteMsg.</c>
<c>APPEND_INFORMATION_SEQNUM</c>
<c>Whether to increment ThisNode's OwnSeqNum when append
ThisNode's routing information to a RteMsg.</c>
-->
<c>BUFFER_DURING_DISCOVERY</c>
<c>Whether and how much data to buffer during route discovery.</c>
<c>APPEND_EXTRA_UNREACHABLE</c>
<c>Whether to append additional Unreachable information to RERR.</c>
<c>CONTROL_TRAFFIC_LIMITS</c>
<c>AODVv2 messaging SHOULD be limited to avoid consuming
all the network bandwidth.</c>
</texttable>
<t>Note: several fields have limited size (bits or bytes) these
sizes and their encoding may place specific limitations on the
values that can be set. For example, MsgHdr.HopLimit is a 8-bit
field and therefore MSG_HOPLIMIT cannot be larger than 255.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>In its default mode of operation, AODVv2 uses the UDP port
269 <xref target="RFC5498" /> to carry protocol
packets. AODVv2 also uses the link-local multicast address
LL-MANET-Routers <xref target="RFC5498" />.</t>
<t>This section specifies several message types, message
tlv-types, and address tlv-types.</t>
<section anchor="msgtype" title="AODVv2 Message Types Specification">
<texttable anchor="msgtypes">
<preamble>AODVv2 Message Types</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<c>Route Request (RREQ)</c>
<c>10 - TBD</c>
<c>Route Reply (RREP)</c>
<c>11 - TBD</c>
<c>Route Error (RERR)</c>
<c>12 - TBD</c>
</texttable>
</section>
<section anchor="black" title="Message and Address Block TLV Type Specification">
<texttable anchor="pkttlvtypes">
<preamble>Message TLV Types</preamble>
<ttcol align="center" width="35%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="left" width="45%">Value</ttcol>
<c>Unicast Response Request</c>
<c>10 - TBD</c>
<c>0 octets</c>
<c>Indicates to the processing node that the previous hop
(IP.SourceAddress) expects a unicast reply message within
UNICAST_MESSAGE_SENT_TIMEOUT. Any unicast packet will serve this
purpose, and it MAY be an ICMP REPLY message. If the reply is not
received, then the previous hop can assume that the link is
unidirectional and MAY blacklist the link to this node.</c>
</texttable>
</section>
<section anchor="addrtlvspec" title="Address Block TLV Specification">
<texttable anchor="addrtlvtypes">
<preamble>Address Block TLV Types</preamble>
<ttcol align="center" width="25%">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center" width="15%">Length</ttcol>
<ttcol align="left" width="50%">Value</ttcol>
<!-- Move to AODV2 Extensions document
TODO
<c>AODVv2 Identifier (DID)</c>
<c>9 - TBD</c>
<c>DID length</c>
<c>ThisNode.DID's value. More information can be found in <xref target="did" /></c>
-->
<c>AODVv2 Sequence Number (AODVv2SeqNum)</c>
<c>10 - TBD</c>
<c>up to 2 octets</c>
<c>The AODVv2 sequence num associated with this address. The sequence
number may be the last known sequence number.</c>
<c>Distance</c>
<c>11 - TBD</c>
<c>up to 2 octets</c>
<c>A metric of the distance traversed by the information
associated with this address.</c>
<c>VALIDITY_TIME</c>
<c>1<xref target="RFC5497" /> </c>
<c></c>
<c>The maximum amount of time that information can be
maintained before being deleted. The VALIDITY_TIME TLV is
defined in <xref target="RFC5497" />.</c>
</texttable>
<t></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The objective of the AODVv2 protocol is for each router to
communicate reachability information to 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 to the destination.
When an intermediate router creates 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 to the
TargetNode.
This is particularly an issue in creating 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.
-->
</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, 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 isolates the minimal base specification and
other optional features to simplify the process of
ensuring 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
ensuring appropriateness of AODVv2 for LLNs.
</t>
</section>
</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"?>
</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" ?>
<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="changes"
title="Changes since the Previous Version">
<t><list style="symbols">
<t>Internet-Facing AODVv2 router renamed to be IAR</t>
<t>"Optional Features" section created to contain features
not required within base specification, including:
</t>
<t><list style="symbols">
<t>Intermediate RREPs (iRREPs): Without iRREP, only the
destination can respond to a RREQ. </t>
<t>Precursor lists.</t>
<t>An RERR may reporting multiple unreachable nodes. </t>
<t>Message Aggregation.</t>
</list></t>
<t>Sequence number MUST (instead of SHOULD) be set to 1 after rollover.</t>
<t>ThisNode MUST (instead of SHOULD) only handle AODVv2 messages
from adjacent routers.</t>
<t>Clarification that Additional Routing information in RteMsgs is
optional (MAY) to use.</t>
<t>Clarification that if Additional 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 routing domain, all addresses
are of the same address length. </t>
<t>Control messages can include TLV (Type-Length-Value) elements,
permitting protocol extensions to be developed. </t>
-->
<t>Routing Messages MUST be originated with the MsgHdr.HopLimit
set to MSG_HOPLIMIT. Previously, this was not mandated.</t>
<t>Maximum hop count set to 254, with 255 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">
<t>Revise message formats to be compatible with LOADng requirements,
removing RFC 5444 headers for minimal packet size</t>
<t>Adding RREP-ACK message type instead of relying on reception of
arbitrary packets as sufficient response to establish bidirectionality.
</t>
</list>
</t>
-->
<section anchor="change_address_location"
title="Shifting Network Prefix Advertisement Between AODVv2 Routers">
<t>Only one AODVv2 router within a routing region 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>
<!-- ====================================================================== -->
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:39 |