One document matched: draft-ietf-manet-dymo-22.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'?>
<rfc category="std" docName="draft-ietf-manet-dymo-22" 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>3590 North First Street, Suite 300</street>
-->
<street>Central Expressway</street>
<city>San Jose</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-421-1172</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>Extensible Markup Language</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 enables
on-demand, multihop unicast routing among participating AODVv2
routers. The basic operations of the AODVv2 protocol are route
discovery and route maintenance. Route discovery is performed
when an AODVv2 router receives a packet from a node under its
responsibility to a destination for which it does not have a
route. Route maintenance is performed to help ensure that the
route being used to forward packets from the source to the
destination remains operational.</t>
<t>During route discovery, the originator's AODVv2 router
initiates dissemination of a Route Request (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 dissemination process, each intermediate AODVv2 router
records a route to the originator. When the target's AODVv2 router
receives the RREQ, it responds with a Route Reply (RREP) sent
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 sent toward the packet source to indicate
the route to particular destination addresses is invalid or
missing. When the source's AODVv2 router receives the RERR, it
deletes the route. If this source's AODVv2 router later receives a
packet for forwarding to the same destination, it will need to
perform route discovery again for that destination.</t>
<t>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.</t>
</section>
<section title="Applicability Statement">
<t>The AODVv2 routing protocol is designed for stub or
disconnected 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 routers forward
packets to only a small portion of the other AODVv2 routers, due
to the on-demand nature of route discovery and route
maintenance.</t>
<t>AODVv2 is applicable to memory constrained devices, since
little routing state is maintained in each AODVv2 router. Only
routing information related to active sources and destinations
is maintained, in contrast to most proactive routing protocols
that require routing information to all routers within the
routing region be maintained.</t>
<t>AODVv2 supports routers with multiple interfaces participating
in the MANET. AODVv2 routers can also perform routing on behalf of
other nodes, attached via participating or non-participating
interfaces.</t>
<t>AODVv2 routers perform route discovery to find a route to a
particular destination. Therefore, AODVv2 routers MUST be
configured to initiate and respond to route discovery on behalf
of certain nodes, identified by address. 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 any time within an AODVv2 routing region, only one AODVv2 router
SHOULD be responsible for, i.e. "own", any particular
address. 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 router behavior
for shifting responsibility for an address from one AODVv2
router to another is mentioned in <xref
target="change_address_location" />.</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="I-D.ietf-manet-nhdp" />) of ensuring and monitoring
bi-directionality is recommended. Otherwise, persistent packet
loss may occur.</t>
<t>The routing algorithm in AODVv2 may be operated at layers other
than the network layer, using layer-appropriate addresses.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <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 several different pieces of information or
protocols; for example, exchange of AODVv2 routing messages,
other protocols (e.g. NDP <xref target="RFC4861" /> or NHDP
<xref target="I-D.ietf-manet-nhdp" />), or manual
configuration. Similarly, loss of a routing adjacency may also
be based upon several pieces of information, and 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 /> A metric of the
distance a message or piece of information has
traversed. The minimum value of distance is the number of IP
hops traversed. The maximum value is 65,535.</t>
<!-- Move to AODV2 Extensions document
TODO
<t hangText="AODVv2 Identifier (DID)"><vspace />A DID is
maintained for each AODVv2 routing process (ThisNode.DID), and
the default value is zero (0). Each routing message is
tagged with its associated DID (MsgTLV.DID), unless zero
(0). Upon receipt of AODVv2 protocol message an AODVv2 routing
protocol process SHOULD only attend to messages with a
matching DID value.</t>
-->
<t hangText="AODVv2 Sequence Number (SeqNum)"><vspace />An AODVv2
Sequence Number is maintained by each AODVv2 router
process. This sequence number is used by other AODVv2 routers
to identify the temporal order of routing information
generated and ensure loop-free routes.</t>
<!-- Never used!
<t hangText="Forwarding Route"><vspace />A route that is
used to forward data packets. Forwarding routes are
generally maintained in a forwarding information base (FIB)
or the kernel forwarding/routing table.</t>
-->
<t hangText="Multihop-capable Unicast IP Address"><vspace
/>A multihop-capable 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) are examples of
multihop-capable unicast IP addresses.</t>
<!-- TODO: citation here -->
<t hangText="Originating Node (OrigNode)"><vspace /> The
originating node is the source, its AODVv2 router creates a
AODVv2 control message on its behalf in an effort to
disseminate some routing information. The originating node
is also referred to as a particular message's
originator.</t>
<t hangText="Route Error (RERR)"><vspace />A RERR message is
used to indicate that an AODVv2 router does not have a forwarding
route to one or more particular addresses.</t>
<t hangText="Route Reply (RREP)"><vspace />A RREP message is
used to disseminate routing information about the RREP
TargetNode to the RREP OrigNode and the AODVv2 routers
between them.</t>
<t hangText="Route Request (RREQ)"><vspace />A RREQ message
is used to discover a valid route to a particular
destination address, called the RREQ TargetNode. When an AODVv2
router processes a RREQ, it learns routing information on
how to reach the RREQ OrigNode.</t>
<t hangText="Target Node (TargetNode)"><vspace />The
TargetNode is the ultimate destination of a message.</t>
<t hangText="This Node (ThisNode)"><vspace />ThisNode
corresponds to the AODVv2 router process currently performing
a calculation or attending to a message.</t>
<t hangText="Type-Length-Value structure (TLV)"><vspace />A
generic way to represent information, please see <xref
target="RFC5444" /> for additional
information.</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="Data Structures">
<section title="Route Table Entry">
<t>The route table entry is a conceptual data structure.
Implementations may use any internal representation that
conforms to the semantics of a route as specified in this
document.</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 />Indicates that the
associated address is a network address, rather than a
host address. The value is the length of the
netmask/prefix. </t>
<t hangText="Route.SeqNum"><vspace />The AODVv2 SeqNum
associated with this routing information.</t>
<t hangText="Route.NextHopAddress"><vspace />The 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
attending 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 cause the protocol to operate
incorrectly.</t>
<t>In addition to a route table data structure, each route
table entry may have several timers associated with the
information. These timers/timeouts are discussed in <xref
target="timeout" />.</t>
</section>
<section title="AODVv2 Messages">
<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 following notation
conventions. Information found in the table.</t>
<texttable anchor="packetprefixes">
<ttcol align="center">Information Location</ttcol>
<ttcol align="center">Notational Prefix</ttcol>
<c>IP header</c>
<c>IP.</c>
<c>UDP header</c>
<c>UDP.</c>
<!-- TODO: decide about keeping RFC 4444 format.
-->
<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>
<section title="Generalized Packet and Message Structure">
<t>AODVv2 messages conform to the generalized packet and
message format as described in <xref
target="RFC5444" />. Here is a brief
description of the format. A packet is made up of
messages. A message is made up of a message header, message
TLV block, and zero or more address blocks. Each of the
address blocks may also have an associated address TLV
block.</t>
<t>For interoperability with other AODVv2 routers, all AODVv2
messages specified in this document SHOULD 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 stated. Therefore, all AODVv2 routers SHOULD
subscribe to LL-MANET-Routers <xref
target="RFC5498" /> for receiving control
packets. Note that multicast packets MAY be sent via
unicast. For example, this may occur for certain link-types
(non broadcast mediums), improved robustness, or manually
configured router adjacencies.</t>
<t>Unicast AODVv2 messages (e.g. RREP) unless otherwise
specified in this document are sent with the IP destination
set to the Route.NextHopAddress of the route to the
TargetNode.</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, it is discarded. This
mechanism helps to ensures that packets have not passed
through any intermediate routers, and it is known as GTSM
<xref target="RFC5082" />.</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-->
<!-- Move to AODV2 Extensions document
TODO
<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>
-->
<t>AODVv2 control packets SHOULD be given priority queuing and
channel access.</t>
</section>
<section title="Routing Message (RteMsg) - RREQ and RREP">
<t>Routing Messages (RteMsgs) are used to disseminate routing
information. There are two AODVv2 message types that are
considered to be routing messages (RteMsgs): RREQ and RREP. They
contain very similar information and function, but have
slightly different handling rules. The main difference
between the two messages is that RREQ messages generally
solicit a RREP, whereas a RREP is the response to RREQ.</t>
<t>RteMsg creation and handling are described in <xref
target="RteMsg" />. </t>
<t>A RteMsg requires 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 RREQ the
IP.DestinationAddress is set to LL-MANET-Routers <xref
target="RFC5498" />. For unicast RREP
the IP.DestinationAddress is set to the NextHopAddress
toward the RREP TargetNode.</t>
<t hangText="IP.ProtocolNumber and
UDP.DestinationPort"><vspace />The 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 the UDP port 269 (manet) <xref
target="RFC5498" /> in conjunction with the IP Protocol
Number 17 (UDP).</t>
<t hangText="MsgHdr.HopLimit"><vspace />The remaining
number of hops this message is allowed to traverse.</t>
<t hangText="AddBlk.TargetNode.Address"><vspace />The IP
address of the message TargetNode. In a RREQ the
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)">
<t>A RERR message is used to disseminate 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:
<list style="hanging">
<t hangText="IP.SourceAddress"><vspace />The IP address of
the AODVv2 router that sent this packet. This field is
generally filled automatically by the operating system and
should not require special handling.</t>
<t hangText="IP.DestinationAddress"><vspace />For
multicast RERR messages, The IP address is set to
LL-MANET-Routers <xref target="RFC5498"
/>. For unicast RERR messages, the IP address is set to
the NextHopAddress.</t>
<t hangText="IP.ProtocolNumber and
UDP.DestinationPort"><vspace />The 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 the UDP port 269 (manet) <xref
target="RFC5498" /> in conjunction with the IP Protocol
Number 17 (UDP).</t>
<t hangText="MsgHdr.HopLimit"><vspace />The remaining
number of hops this message is allowed to traverse.</t>
<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>
<section title="Detailed Operation">
<section anchor="seqnum" title="AODVv2 Sequence Numbers">
<t>AODVv2 sequence numbers allow AODVv2 routers to judge the
freshness of routing information and 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) on behalf
of the addresses for which it is responsible. OwnSeqNum a
16-bit unsigned integer. The circumstances for ThisNode to
increment its OwnSeqNum are described in <xref target="RteMsg"
/>.</t>
</section>
<section anchor="seqnuminc" title="Numerical Operations on OwnSeqNum">
<t>When ThisNode increments its OwnSeqNum it MUST do so by
treating the sequence number value as an unsigned
number.</t>
</section>
<section title="OwnSeqNum Rollover">
<t>Incrementing an OwnSeqNum whose value is the largest
largest possible number representable as a 16-bit unsigned
integer (i.e., 65,535), SHOULD 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 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
control message is received during this waiting period, the
AODVv2 router SHOULD handle it normally but MUST NOT transmit
or retransmit any AODVv2 messages. If a data packet is
received for forwarding to another destination during this
waiting period, the AODVv2 router MUST generate 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 begins
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 new incoming routing information for a
particular node in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg
message type - RREQ/RREP), the quality of the new routing
information is evaluated to determine its
usefulness. Incoming routing information is classified as
follows:
<list style="hanging">
<t hangText="1. Stale"><vspace /> If Node.SeqNum -
Route.SeqNum < 0 (using signed 16-bit arithmetic) the
incoming information is stale. Using stale routing
information is not allowed, since doing so might
result in routing loops.
<figure>
<artwork><![CDATA[
(Node.SeqNum - Route.SeqNum < 0)
using signed 16-bit arithmetic
]]></artwork>
</figure></t>
<t hangText="2. Loop-possible"><vspace /> If Node.SeqNum
== Route.SeqNum the incoming information may cause loops
if used; in this case additional information MUST be
examined. If Route.Dist or Node.Dist is unknown or
zero (0), then the routing information is
loop-possible. If Node.Dist > Route.Dist + 1, then
the routing information is loop-possible. Using
loop-possible routing information is not allowed,
otherwise routing loops may be formed.
<figure>
<artwork><![CDATA[
(Node.SeqNum == Route.SeqNum) AND
((Node.Dist is unknown) OR
(Route.Dist is unknown) OR
(Node.Dist > Route.Dist + 1))
]]></artwork>
</figure></t>
<t hangText="3. Disfavored or equivalent"><vspace />In case
of known equal SeqNum, the information is disfavored in
multiple cases: (case i) if Node.Dist == Route.Dist + 1
(it is a greater distance 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. This condition reduces the number of RREQ flooded by
stopping forwarding of RREQ with equivalent distance.
<figure>
<artwork><![CDATA[
((Node.SeqNum == Route.SeqNum) AND
(((Node.Dist == Route.Dist + 1) AND (Route.Broken == false)) OR
((Node.Dist == Route.Dist) AND
(RteMsg is RREQ) AND (Route.Broken == false))))
]]></artwork>
</figure></t>
<t hangText="4. Preferable"><vspace /> Incoming routing
information that does not match any of the above criteria
is loop-free and better than the information existing in
the routing table. 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). For completeness, we provide the following
(optimized) pseudo-code.
<figure>
<artwork><![CDATA[
(Node.SeqNum - Route.SeqNum > 0) OR
using signed 16-bit arithmetic
((Node.SeqNum == Route.SeqNum) AND
((Node.Dist < Route.Dist) OR
((Node.Dist == Route.Dist + 1) AND (Route.Broken == true)) OR
((Node.Dist == Route.Dist) AND
((RteMsg is RREP) OR (Route.Broken == true)))))
]]></artwork>
</figure></t>
</list></t>
</section>
<section anchor="update_rte"
title="Creating or Updating a Route Table Entry with
Received Preferable Routing Information">
<t>The 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 node that transmitted
this AODVv2 RteMsg packet (i.e., the IP.SourceAddress),</t>
<t>the Route.NextHopInterface is set to the interface that this
AODVv2 packet was received on,</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.</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>At this point, a forwarding route has been created and
the Route.Forwarding flag set. Afterward, the route can be
used to send any queued data packets and forward any
incoming data packets for Route.Address. This route also
fulfills any outstanding route discovery 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. After updating a route table
entry, it SHOULD be maintained for at least
ROUTE_AGE_MIN. Failure to maintain the information might
result in lost messages/packets, or in the worst case
scenario 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 is time sensitive, and MUST
be deleted after a time in order to ensure loop-free
routing.</t>
<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. This
operation is also 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, the node 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).</t>
<!-- TODO: move to AODVv2 Extensions document, note lack of justification
for use of Path Accumulation
<t>Additional routing information can be added to this RteMsg
using the procedure described in <xref
target="RM_append"/>.</t>
-->
<t>The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT.</t>
<t>For 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>
<t> The IP.DestinationAddress for multicast RREQ is set to
LL-MANET-Routers. For links that do not support multicast or
situations in which unicast messaging is preferred, the
IP.DestinationAddress for unicast RREQ is set to the
NextHopAddress.</t>
<!-- Move to AODV2 Extensions document
TODO
<t>Each AODVv2 routing protocol message SHOULD contain
ThisNode.DID's value in a message TLV (MsgTLV.DID). If
ThisNode.DID value is zero (0) it MAY be omitted.</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
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 65,535. 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>
<!-- Move to AODVv2 Extensions document, note lack of justification for use
TODO
<t>Additional routing information can be added to this RteMsg
using the procedure described in <xref
target="RM_append"/>.</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>
<!-- Move to AODV2 Extensions document
TODO
<t>Each AODVv2 routing protocol message SHOULD contain
ThisNode.DID's value in a message TLV (MsgTLV.DID). If
ThisNode.DID value is zero (0) it MAY be omitted.</t>
-->
</section>
<!-- TODO: Move to a new companion AODV2 Extensions document...
<section anchor="Int_RREP_create" title="Intermediate AODVv2 Router RREP Creation">
<t>Sometimes an AODVv2 router other than the TargetNode's AODVv2
router (call it an "intermediate AODVv2 router") has routing
information that can satisfy an incoming RREQ. An
intermediate AODVv2 router can issue a intermediate AODVv2 router
RREP on behalf of the TargetNode's AODVv2 router.</t>
<t>Before creating a intermediate AODVv2 router RREP,
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
about ThisNode might be considered stale by a handling
AODVv2 router. In this case, the RREP would not reach the RREP
TargetNode.</t>
<t>When an intermediate AODVv2 router originates a RREP in
response to a RREQ on behalf of the TargetNode's AODVv2
router, it sends the RREP to the RREQ OrigNode with
additional routing information (Address, Prefix, SeqNum,
Dist, etc.) about the RREQ TargetNode.
- - START NESTED TODO in Move to a new companion AODV2 Extensions document...
-->
<!-- Move to AODVv2 Extensions document, note lack of justification for use
TODO
Appending additional
routing information is described in <xref target="RM_append" />.
-->
<!--
- - END NESTED TODO in Move to a new companion AODV2 Extensions document...
</t>
<t>The Intermediate AODVv2 router SHOULD also issue a RREP to
the RREQ TargetNode, so that the RREQ TargetNode receives
routing information on how to reach the RREQ OrigNode.</t>
<t>When an intermediate AODVv2 router creates this RREP, it
sends a RREP to the RREQ TargetNode with additional routing
information (Address, Prefix, SeqNum, Dist, etc.) about the
RREQ OrigNode.</t>
</section>
- - END TODO: Move to a new companion AODV2 Extensions document...
-->
<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 do not
exist, the message is discarded and further processing
stopped. </t>
<!-- Move to AODV2 Extensions document
TODO
<t>Next, ThisNode decides whether to attend to this
message. If the message contains a MsgTLV.DID it SHOULD
match ThisNode.DID's value. If the message does not contain
a MsgTLV.DID it is assumed to be zero (0) and SHOULD be
discarded if ThisNode.DID's value is not zero (0).</t>
-->
<t>Next, ThisNode MAY selectively attend to messages based
upon information in the message. ThisNode SHOULD only
handle messages from adjacent AODVv2 routers. If ThisNode
chooses not to handle this message, the message is
discarded and further processing stopped.</t>
<t>ThisNode checks if the AddBlk.OrigNode.Address is a valid
multihop-capable (e.g. site or global scope) unicast
address. If the address is not a valid unicast address, the
message is discarded 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 multihop-capable 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 considered preferable and 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>For each address (except the TargetNode) in the RteMsg that
includes AddTLV.Dist information, the AddTLV.Dist
information MAY be incremented. If the resulting Distance
value for the OrigNode is greater than 65,535, the message
is discarded. If the resulting Distance value for another
node is greater than 65,535, the associated address and its
information are removed from the RteMsg. The updated Distance
value will influence judgment of the routing information
(<xref target="test" />).</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 the that the address is a multihop-capable
unicast address. If the address is not a unicast address,
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 is 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
considered preferable, the route table entry is updated as
described in <xref target="update_rte" />.</t>
<t>If the routing information for an AdditionalNode.Address
is not considered preferable, then it is removed from the
RteMsg. Removing this information ensures that the information
is not propagated.</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 ThisNode is the AODVv2 router responsible for the
TargetNode and 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" />. At this
point, 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>
<!-- TODO: Move to a new companion AODV2 Extensions document...
<t>If ThisNode is not the TargetNode, this RteMsg is a RREQ, the
RREQ contains the TargetNode.AddTLV.SeqNum, and ThisNode has
a forwarding route to the TargetNode with a SeqNum where
Route.TargetNode.SeqNum - RREQ.TargetNode.AddTLV.SeqNum
> 0 (using signed 16-bit arithmetic); then ThisNode MAY
respond with an intermediate AODVv2 router RREP. The procedure
for performing intermediate AODVv2 router RREP is described in
<xref target="Int_RREP_create" />. If an intermediate AODVv2
router RREP is sent, ThisNode need not perform any more
operations for the RteMsg being processed.</t>
-->
<!-- Move to AODVv2 Extensions document, note lack of justification for use
TODO
<t>After handling a RteMsg or creating a new RteMsg, ThisNode MAY
append additional routing information to the RteMsg prior to
redistributing this information, according
to the procedure described in <xref target="RM_append"
/>. The additional routing information can help reduce route
discoveries at the expense of increased message size.</t>
<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 65,535, the message is discarded. If the
resulting Distance value for another node is greater than
65,535, the associated address and its information are
removed from the RteMsg.</t>
<t>Next, the MsgHdr.HopLimit is decremented by one (1). If
this RteMsg's MsgHdr.HopLimit is greater than or equal to one
(1), ThisNode is not the TargetNode, AND this RteMsg is a RREQ,
then the current RteMsg (altered by the procedure defined above)
SHOULD be sent to the IP.DestinationAddress LL-MANET-Routers
<xref target="RFC5498" />. If the RREQ is
unicast, the IP.DestinationAddress is set to the
NextHopAddress.</t>
<t>If this RteMsg's MsgHdr.HopLimit is greater than or equal to
one (1), 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>Some examples of why ThisNode might choose to not
re-issue a RteMsg are: if ThisNode does not want to advertise
routing for the contained addresses because it is already
heavily loaded; if ThisNode has already issued nearly
identical routing information (e.g. ThisNode had recently
issued a RteMsg with nearly the same distance); or if ThisNode
is low on energy and does not want to expend energy for
control message sending or packet forwarding. The exact
circumstances producing such behavior are not specified
in this document.</t>
</section>
<!-- Move to AODVv2 Extensions document, note lack of justification for use
TODO
<section anchor="RM_append"
title="Adding Additional Routing Information to a RteMsg">
<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>AODVv2 routers can append routing information to a RteMsg. This
option (APPEND_INFORMATION) SHOULD be administratively
configurable or intelligently controlled.</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 or intelligently controlled. 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. If
Route.Dist is not known, it MUST NOT be included.</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>
</section>
-->
</section>
<section anchor="route_discovery" title="Route Discovery">
<t>When a source's AODVv2 router needs to forward a data packet
on behalf of an attached node and it does not have a
forwarding route to the data packet's unicast IP destination
address, ThisNode 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 OrigNode AODVv2 router waits for a
route to be created to the TargetNode. If a route is not
created within RREQ_WAIT_TIME, ThisNode 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 failed after
DISCOVERY_ATTEMPTS_MAX and the final RREQ's corresponding
RREQ_WAIT_TIME.</t>
<t>To reduce congestion in a network, repeated attempts at
route discovery for a particular TargetNode SHOULD utilize an
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) and older data
packets SHOULD be discarded first.</t>
<t>Buffering of data packets can have both positive and
negative effects, and therefore buffer settings
(BUFFER_DURING_DISCOVERY) SHOULD be administratively
configurable or intelligently controlled.</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 are dropped and a Destination
Unreachable ICMP message SHOULD be delivered to the
source.</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 MUST 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="I-D.ietf-manet-nhdp" /></t>
<t>Route timeout</t>
<t>Lower layer feedback that a particular adjacent
router is no longer reachable</t>
<t>Other monitoring mechanisms or heuristics</t>
</list>
</t>
<t>Upon determining that a next-hop AODVv2 router is
unreachable, ThisNode MUST remove the affected forwarding
routes (those with an 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 the
IP.SourceAddress, ThisNode SHOULD set the "ROUTE_USED" timeout
to the value ROUTE_USED_TIMEOUT for the route to the
IP.SourceAddress upon receiving a data packet. If the timer
for ROUTE_DELETE is set, it is removed.</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. If the timer for ROUTE_DELETE is set, it is
removed.</t>
</section>
<section anchor="rerr_create" title="RERR Generation">
<t>A RERR informs AODVv2 routers that a route to certain
destinations is not available through ThisNode.</t>
<t>When creating 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
is set to MSG_HOPLIMIT.</t>
<!-- TODO: move to AODVv2 Extensions document,
<t>Additional UnreachableNodes that require the same
unavailable link (routes with the same Route.NextHopAddress
and Route.NextHopInterface) SHOULD be added to the RERR, as
additional AddBlk.UnreachableNode.Address entries with their
associated prefix. The SeqNum if known SHOULD also be
included. Appending UnreachableNode information notifies
each node that handles this message of additional routes
that are no longer available. This option
(APPEND_EXTRA_UNREACHABLE) SHOULD be administratively
configurable or intelligently controlled.</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>
<!-- Move to AODV2 Extensions document
TODO
<t>Each AODVv2 routing protocol message SHOULD contain
ThisNode.DID's value in a message TLV (MsgTLV.DID). If
ThisNode.DID value is zero (0) it MAY be omitted.</t>
-->
<t>A multicast RERR is sent to the IP.DestinationAddress
LL-MANET-Routers <xref target="RFC5498"
/>. Sending the RERR to the LL-MANET-Routers address
notifies all nearby AODVv2 routers that might depend on the
now broken link. If the RERR is unicast, the
IP.DestinationAddress is set to the NextHopAddress.</t>
<t>At this point, the packet or message that forced
generation of this RERR SHOULD be discarded.</t>
</section>
<section anchor="rerr_proc" title="RERR Handling">
<t>First, ThisNode examines the RteMsg to ensure that it
contains the required information: MsgHdr.HopLimit and
AddBlk.UnreachableNode.Address. If the required information
do not exist, the message is discarded and further
processing stopped. </t>
<!-- Move to AODV2 Extensions document
TODO
<t>Next, ThisNode decides whether to handle this
message. If the message contains a MsgTLV.DID it SHOULD
match ThisNode.DID's value. If the message does not contain
a MsgTLV.DID it is assumed to be zero (0) and SHOULD be
discarded if ThisNode.DID's value is not zero (0).</t>
-->
<t>Next, ThisNode MAY selectively handle messages based
upon information in the message. ThisNode MAY choose to only
handle messages from adjacent AODVv2 routers. If ThisNode
chooses not to handle this message, the message is
discarded and further processing stopped.</t>
<t>When an AODVv2 router handles a RERR, it examines each
UnreachableNode's information. The attending 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 multihop-capable
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>During handling if Route.SeqNum is zero (0) or unknown
and UnreachableNode.SeqNum exists in the RERR and is not
zero (0), then Route.SeqNum MAY be set to
UnreachableNode.SeqNum. Setting Route.SeqNum can reduce
future RERR handling and forwarding.</t>
<t>Each UnreachableNode that did not result in a broken
route is removed from the RERR, since propagation of this
information will not result in any benefit.</t>
<t>Each UnreachableNode that did result in a broken route
SHOULD remain in the RERR.</t>
<t>If any UnreachableNode was removed, all other information
(AddTLVs) associated with the removed address(es) MUST also
be removed.</t>
<t>After handling if Route.SeqNum is known and an
UnreachableNode.SeqNum is not included in the RERR, then
Route.SeqNum (i.e. UnreachableNode.SeqNum) MAY be added to
the RERR. Including UnreachableNode.SeqNum can reduce future
RERR handling and forwarding.</t>
<t>If no UnreachableNode addresses remain in the RERR, no
other handling is required and the RERR is discarded.</t>
<t>If handling continues, the MsgHdr.HopLimit is
decremented by one (1). Further, if this RERR's new
MsgHdr.HopLimit is greater than one (1) and at least one
unreachable node address remains in the RERR, then the
updated RERR SHOULD be sent.</t>
<t>A multicast RERR is sent to the IP.DestinationAddress
LL-MANET-Routers <xref target="RFC5498" />. If
the RERR is unicast, the IP.DestinationAddress is set to the
NextHopAddress.</t>
</section>
</section>
<!-- Move to AODV2 Extensions document
TODO
<section anchor="did"
title="AODVv2 Identifier (DID)">
<t>Each AODVv2 routing protocol process MUST have an associated
AODVv2 Identifier (DID). The DID allows multiple AODVv2 routing
protocol processes to operate over the same links and on the
same device independently. This function may also be used to
administratively separate AODVv2 processes with incompatible
options, timers, or extensions.</t>
<t>The DID is similar in function to OSPF Instance ID <xref
target="RFC5340"></xref> <xref
target="I-D.ietf-ospf-multi-instance"></xref>, OSPF Area ID
<xref target="RFC2328"></xref> <xref target="RFC5340"></xref>,
and/or the MANET_ID TLV <xref
target="I-D.chakeres-manet-manetid"></xref>.</t>
<t>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 (see <xref
target="param" />), and protocol extensions. In cases with
non-default options, the DID value SHOULD be administratively
chosen.</t>
<t>The default DID value is zero (0), and using this value
requires that the implementation utilize options and timing
parameters compatible with those defined in <xref
target="param"/>.</t>
<t>Each AODVv2 routing protocol message sent MUST contain its
associated DID in a message TLV; unless the DID value is zero
(0), in which case it MAY be omitted.</t>
<t>Upon receipt of AODVv2 protocol message an AODVv2 routing
protocol process SHOULD only process messages with a DID
(MsgTLV.DID) value matching its own DID (ThisNode.DID).</t>
</section>
-->
<section anchor="unknown"
title="Unknown Message and TLV Types">
<t>If a message with an unknown type is received, the message
is discarded.</t>
<t>For handling of messages that contain unknown TLV types,
the default behavior is to leave the information in control
messages unmodified. Although, this behavior (UNKNOWN_TYPES)
MAY be administratively controlled.</t>
</section>
<section anchor="prefix" title="Advertising Network Addresses">
<t>AODVv2 routers specify the 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. </t>
</section>
<section anchor="gateway"
title="Simple Internet Attachment">
<t>Simple Internet attachment consists of a stub network of
AODVv2 routers connected to the Internet via a single Internet
AODVv2 router (IDR).</t>
<t>AODVv2 routers, and hosts behind these routers, wishing to be
reachable from hosts on the Internet MUST have IP addresses
within the IDR's routable and topologically correct prefix
(e.g. 192.0.2.0/24).</t>
<t>The IDR 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 IDR is
responsible for properly responding 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 IDR, if the IDR 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 control 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 or intelligently controlled. AODVv2 control
messages SHOULD be discarded in the following order of
preference: RREQ, RREP, and finally RERR.</t>
</section>
</section>
<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>60 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>10 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 routing control 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>
<!-- TODO: move to AODVv2 Extensions document, note lack of justification
for use of Path Accumulation
<c>APPEND_EXTRA_UNREACHABLE</c>
<c>Whether to append additional Unreachable information to RERR.</c>
-->
<c>UNKNOWN_TYPES</c>
<c>What action to take when an unknown TLV type is
received. The default action is to forward this information
unmodified. Another action would be to remove this
information.</c>
<c>CONTROL_TRAFFIC_LIMITS</c>
<c>AODVv2 control 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
MANET <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 message within
UNICAST_MESSAGE_SENT_TIMEOUT. Any unicast packet will serve this
purpose, and it MAY be an ICMP REPLY message. If a message is not
sent, 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, like 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 AODVv2. 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>Many good ideas from LOADng
<xref target="I-D.clausen-lln-loadng" /> are shaping
this evolution of the [manet] 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>
</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.5340" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.4728" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.5148"?>
<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.ietf-manet-nhdp" ?>
<?rfc include="reference.I-D.ietf-ospf-multi-instance" ?>
<?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>Protocol renamed to be AODVv2</t>
<t>Intermediate RREPs (iRREPs) are to be put into new document. Without
iRREP, only the destination can respond to a RREQ. </t>
<t>Precursor lists not supported, based on reported performance loss.</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>Adding additional unreachable destinations to RERR is not
specified in this document, to match LOADng behavior. </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>
<section anchor="change_address_location"
title="Shifting Responsibility for an Address 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 pass responsibility of an address correct
AODVv2 routing behavior must be observed. The AODVv2 router adding
the new address must wait for any exiting routing information
about this address 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 participating and
advertising routing information on its behalf.</t>
</section>
</back>
</rfc>
<!--
================================================================================
-->
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:41 |