draft-ietf-manet-aodv-11.txt   draft-ietf-manet-aodv-12.txt 
Mobile Ad Hoc Networking Working Group Charles E. Perkins Mobile Ad Hoc Networking Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center INTERNET DRAFT Nokia Research Center
19 June 2002 Elizabeth M. Belding-Royer 4 November 2002 Elizabeth M. Belding-Royer
University of California, Santa Barbara University of California, Santa Barbara
Samir R. Das Samir R. Das
University of Cincinnati University of Cincinnati
Ad hoc On-Demand Distance Vector (AODV) Routing Ad hoc On-Demand Distance Vector (AODV) Routing
draft-ietf-manet-aodv-11.txt draft-ietf-manet-aodv-12.txt
Status of This Memo Status of This Memo
This document is a submission by the Mobile Ad Hoc Networking Working This document is a submission by the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the manet@ietf.org mailing list. be submitted to the manet@ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 1, line 72 skipping to change at page 1, line 72
4.1. Route Request (RREQ) Message Format . . . . . . . . . . . 5 4.1. Route Request (RREQ) Message Format . . . . . . . . . . . 5
4.2. Route Reply (RREP) Message Format . . . . . . . . . . . . 6 4.2. Route Reply (RREP) Message Format . . . . . . . . . . . . 6
4.3. Route Error (RERR) Message Format . . . . . . . . . . . . 8 4.3. Route Error (RERR) Message Format . . . . . . . . . . . . 8
4.4. Route Reply Acknowledgment (RREP-ACK) Message Format . . 9 4.4. Route Reply Acknowledgment (RREP-ACK) Message Format . . 9
5. AODV Operation 9 5. AODV Operation 9
5.1. Maintaining Sequence Numbers . . . . . . . . . . . . . . 9 5.1. Maintaining Sequence Numbers . . . . . . . . . . . . . . 9
5.2. Route Table Entries and Precursor Lists . . . . . . . . . 11 5.2. Route Table Entries and Precursor Lists . . . . . . . . . 11
5.3. Generating Route Requests . . . . . . . . . . . . . . . . 12 5.3. Generating Route Requests . . . . . . . . . . . . . . . . 12
5.4. Controlling Dissemination of Route Request Messages . . . 13 5.4. Controlling Dissemination of Route Request Messages . . . 13
5.5. Processing and Forwarding Route Requests . . . . . . . . 13 5.5. Processing and Forwarding Route Requests . . . . . . . . 14
5.6. Generating Route Replies . . . . . . . . . . . . . . . . 15 5.6. Generating Route Replies . . . . . . . . . . . . . . . . 15
5.6.1. Route Reply Generation by the Destination . . . . 15 5.6.1. Route Reply Generation by the Destination . . . . 16
5.6.2. Route Reply Generation by an Intermediate Node . 16 5.6.2. Route Reply Generation by an Intermediate Node . 16
5.6.3. Generating Gratuitous RREPs . . . . . . . . . . . 16 5.6.3. Generating Gratuitous RREPs . . . . . . . . . . . 17
5.7. Receiving and Forwarding Route Replies . . . . . . . . . 17 5.7. Receiving and Forwarding Route Replies . . . . . . . . . 17
5.8. Operation over Unidirectional Links . . . . . . . . . . . 18 5.8. Operation over Unidirectional Links . . . . . . . . . . . 19
5.9. Hello Messages . . . . . . . . . . . . . . . . . . . . . 19 5.9. Hello Messages . . . . . . . . . . . . . . . . . . . . . 19
5.10. Maintaining Local Connectivity . . . . . . . . . . . . . 20 5.10. Maintaining Local Connectivity . . . . . . . . . . . . . 20
5.11. Route Error Messages, Route Expiry and Route Deletion . . 21 5.11. Route Error Messages, Route Expiry and Route Deletion . . 21
5.12. Local Repair . . . . . . . . . . . . . . . . . . . . . . 22 5.12. Local Repair . . . . . . . . . . . . . . . . . . . . . . 23
5.13. Actions After Reboot . . . . . . . . . . . . . . . . . . 24 5.13. Actions After Reboot . . . . . . . . . . . . . . . . . . 24
5.14. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 24 5.14. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 25
6. AODV and Aggregated Networks 25 6. AODV and Aggregated Networks 25
7. Using AODV with Other Networks 25 7. Using AODV with Other Networks 26
8. Extensions 26 8. Extensions 26
8.1. Hello Interval Extension Format . . . . . . . . . . . . . 26 8.1. Hello Interval Extension Format . . . . . . . . . . . . . 27
9. Configuration Parameters 27 9. Configuration Parameters 27
10. Security Considerations 28 10. Security Considerations 29
11. IPv6 Considerations 29 11. IPv6 Considerations 30
12. Acknowledgments 29 12. Acknowledgments 30
A. Draft Modifications 31 A. Draft Modifications 32
1. Introduction 1. Introduction
The Ad hoc On-Demand Distance Vector (AODV) algorithm enables The Ad hoc On-Demand Distance Vector (AODV) algorithm enables
dynamic, self-starting, multihop routing between participating mobile dynamic, self-starting, multihop routing between participating mobile
nodes wishing to establish and maintain an ad hoc network. AODV nodes wishing to establish and maintain an ad hoc network. AODV
allows mobile nodes to obtain routes quickly for new destinations, allows mobile nodes to obtain routes quickly for new destinations,
and does not require nodes to maintain routes to destinations that and does not require nodes to maintain routes to destinations that
are not in active communication. AODV allows mobile nodes to respond are not in active communication. AODV allows mobile nodes to respond
to link breakages and changes in network topology in a timely manner. to link breakages and changes in network topology in a timely manner.
skipping to change at page 3, line 8 skipping to change at page 3, line 8
carried out in the same way as for any other destination IP address. carried out in the same way as for any other destination IP address.
AODV is a routing protocol, and it deals with route table AODV is a routing protocol, and it deals with route table
management. Route table information must be kept even management. Route table information must be kept even
for short-lived routes, such as are created to temporarily for short-lived routes, such as are created to temporarily
store reverse paths towards nodes originating RREQs. AODV store reverse paths towards nodes originating RREQs. AODV
uses the following fields with each route table entry: uses the following fields with each route table entry:
- Destination IP Address - Destination IP Address
- Destination Sequence Number - Destination Sequence Number
- Vaild Destination Sequence Number - Valid Destination Sequence Number
- Interface - Interface
- Hop Count (number of hops needed to reach destination) - Hop Count (number of hops needed to reach destination)
- Next Hop - Next Hop
- List of Precursors (described in Section 5.2) - List of Precursors (described in Section 5.2)
- Lifetime (expiration or deletion time of the route) - Lifetime (expiration or deletion time of the route)
- Routing Flags - Routing Flags
- State - State
Managing the sequence number is crucial to avoiding routing loops, Managing the sequence number is crucial to avoiding routing loops,
even when links break and a node is no longer reachable to supply even when links break and a node is no longer reachable to supply
skipping to change at page 10, line 10 skipping to change at page 10, line 10
- Immediately before a node originates a route discovery, it MUST - Immediately before a node originates a route discovery, it MUST
increment its own sequence number. This prevents problems with increment its own sequence number. This prevents problems with
deleted reverse routes to the originator of a RREQ. deleted reverse routes to the originator of a RREQ.
- Immediately before a destination node originates a RREP in - Immediately before a destination node originates a RREP in
response to a RREQ, it MUST update its own sequence number to response to a RREQ, it MUST update its own sequence number to
the maximum of its current sequence number and the destination the maximum of its current sequence number and the destination
sequence number in the RREQ packet. sequence number in the RREQ packet.
When the destination increments its sequence number, it MUST do so by When the destination increments its sequence number, it MUST do so
treating the sequence number value as if it were an unsigned number. by treating the sequence number value as if it were an unsigned
To accomplish sequence number rollover, if the sequence number has number. To accomplish sequence number rollover, if the sequence
already been assigned to be the largest possible number representable number has already been assigned to be the largest possible number
as a 32-bit unsigned integer (i.e., 4294967295), then when it is representable as a 32-bit unsigned integer (i.e., 4294967295), then
incremented it will then have a value of zero (0). On the other when it is incremented it will then have a value of zero (0). On
hand, if the sequence number currently has the value 2147483647, the other hand, if the sequence number currently has the value
which is the largest possible positive integer if 2's complement 2147483647, which is the largest possible positive integer if 2's
arithmetic is in use with 32-bit integers, the next value will be complement arithmetic is in use with 32-bit integers, the next value
2147483648, which is the most negative possible integer in the same will be 2147483648, which is the most negative possible integer in
numbering system. The representation of negative numbers is not the same numbering system. The representation of negative numbers
relevant to the incrementation of AODV sequence numbers. This is is not relevant to the increment of AODV sequence numbers. This is
in contrast to the manner in which the result of comparing two AODV in contrast to the manner in which the result of comparing two AODV
sequence numbers is to be treated (see below). sequence numbers is to be treated (see below).
In order to ascertain that information about a destination is not In order to ascertain that information about a destination is not
stale, the node compares its current numerical value for the sequence stale, the node compares its current numerical value for the sequence
number with that obtained from the incoming AODV message. This number with that obtained from the incoming AODV message. This
comparison MUST be done using signed 32-bit arithmetic, this is comparison MUST be done using signed 32-bit arithmetic, this is
necessary to accomplish sequence number rolloever. If the result of necessary to accomplish sequence number rollover. If the result of
subtracting the currently stored sequence number from the value of subtracting the currently stored sequence number from the value of
the incoming sequence number is less than zero, then the information the incoming sequence number is less than zero, then the information
related to that destination in the AODV message MUST be discarded, related to that destination in the AODV message MUST be discarded,
since that information is stale compared to the node's currently since that information is stale compared to the node's currently
stored information. stored information.
The only other circumstance in which a node may change the The only other circumstance in which a node may change the
destination sequence number in one of its route table entries is destination sequence number in one of its route table entries is
in response to a lost or expired link to the next hop towards that in response to a lost or expired link to the next hop towards that
destination. The node determines which destinations use a particular destination. The node determines which destinations use a particular
skipping to change at page 11, line 27 skipping to change at page 11, line 27
sequence number field is set to false. The route is only updated if sequence number field is set to false. The route is only updated if
the new sequence number is either the new sequence number is either
(i) higher than the destination sequence number in the route (i) higher than the destination sequence number in the route
table, or table, or
(ii) the sequence numbers are equal, but the hop count (of (ii) the sequence numbers are equal, but the hop count (of
the new information) plus one, is smaller than the the new information) plus one, is smaller than the
existing hop count in the routing table, or existing hop count in the routing table, or
(iiI) the sequence number is unknown. (iii) the sequence number is unknown.
The Lifetime field of the routing table entry is either The Lifetime field of the routing table entry is either
determined from the control packet, or it is initialized to determined from the control packet, or it is initialized to
ACTIVE_ROUTE_TIMEOUT. This route may now be used to send any queued ACTIVE_ROUTE_TIMEOUT. This route may now be used to send any queued
data packets and fufills any outstanding route requests. data packets and fulfills any outstanding route requests.
Each time a route is used to forward a data packet, its Active Each time a route is used to forward a data packet, its Active
Route Lifetime field of the source, destination and the next hop Route Lifetime field of the source, destination and the next hop
on the path to the destination is updated to be no less than the on the path to the destination is updated to be no less than the
current time plus ACTIVE_ROUTE_TIMEOUT. Since the route between each current time plus ACTIVE_ROUTE_TIMEOUT. Since the route between each
originator and destination pair are expected to be symmetric, the originator and destination pair are expected to be symmetric, the
Active Route Lifetime for the previous hop, along the reverse path Active Route Lifetime for the previous hop, along the reverse path
back to the IP source, is also updated to be no less than the current back to the IP source, is also updated to be no less than the current
time plus ACTIVE_ROUTE_TIMEOUT. time plus ACTIVE_ROUTE_TIMEOUT.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
retry. retry.
Data packets waiting for a route (i.e., waiting for a RREP after a Data packets waiting for a route (i.e., waiting for a RREP after a
RREQ has been sent) SHOULD be buffered. The buffering SHOULD be RREQ has been sent) SHOULD be buffered. The buffering SHOULD be
"first-in, first-out" (FIFO). If a route discovery has been attempted "first-in, first-out" (FIFO). If a route discovery has been attempted
RREQ_RETRIES times at the maximum TTL without receiving any RREP, all RREQ_RETRIES times at the maximum TTL without receiving any RREP, all
data packets destined for the corresponding destination SHOULD be data packets destined for the corresponding destination SHOULD be
dropped from the buffer and a Destination Unreachable message SHOULD dropped from the buffer and a Destination Unreachable message SHOULD
be delivered to the application. be delivered to the application.
To reduce congestion in a network, repeated attempts by a source
node at route discovery for a single destination MUST utilize a
binary exponential backoff. The first time a source node broadcasts
a RREQ, it waits NET_TRAVERSAL_TIME milliseconds for the reception
of a RREP. If a RREP is not received within that time, the source
node sends a new RREQ. When calculating the time to wait for
the RREP after sending the second RREQ, the source node MUST use
a binary exponential backoff. Hence, the waiting time for the
RREP corresponding to the second RREQ is 2 * NET_TRAVERSAL_TIME
milliseconds. If a RREP is not receivied within this time period,
another RREQ may be sent, up to RREQ_RETRIES additional attempts
after the first RREQ. For each additional attempt, the waiting time
for the RREP is multiplied by 2, so that the time conforms to a
binary exponential backoff.
5.4. Controlling Dissemination of Route Request Messages 5.4. Controlling Dissemination of Route Request Messages
To prevent unnecessary network-wide dissemination of RREQs, the To prevent unnecessary network-wide dissemination of RREQs, the
originating node SHOULD use an expanding ring search technique. In originating node SHOULD use an expanding ring search technique.
an expanding ring search, the originating node initially uses a TTL In an expanding ring search, the originating node initially
= TTL_START in the RREQ packet IP header and sets the timeout for uses a TTL = TTL_START in the RREQ packet IP header and sets the
receiving a RREP to NET_TRAVERSAL_TIME milliseconds. If the RREQ timeout for receiving a RREP to RING_TRAVERSAL_TIME milliseconds.
times out without a corresponding RREP, the originator broadcasts the RING_TRAVERSAL_TIME is calculcated as described in section 9. The
RREQ again with the TTL incremented by TTL_INCREMENT. This continues TTL_VALUE used in calculating RING_TRAVERSAL_TIME is set equal to
until the TTL set in the RREQ reaches TTL_THRESHOLD, beyond which a the value of the TTL field in the IP header. If the RREQ times out
TTL = NET_DIAMETER is used for each attempt. Each time, the timeout without a corresponding RREP, the originator broadcasts the RREQ
for receiving a RREP is calculated as described in Section 5.4. When again with the TTL incremented by TTL_INCREMENT. This continues until
it is desired to have all retries traverse the entire ad hoc network, the TTL set in the RREQ reaches TTL_THRESHOLD, beyond which a TTL =
this can be achieved by configuring TTL_START and TTL_INCREMENT both NET_DIAMETER is used for each attempt. Each time, the timeout for
to be the same value as NET_DIAMETER. receiving a RREP is RING_TRAVERSAL_TIME. When it is desired to have
all retries traverse the entire ad hoc network, this can be achieved
by configuring TTL_START and TTL_INCREMENT both to be the same value
as NET_DIAMETER.
The Hop Count stored in an invalid routing table entry indicates The Hop Count stored in an invalid routing table entry indicates
the last known hop count to that destination in the routing table. the last known hop count to that destination in the routing table.
When a new route to the same destination is required at a later time When a new route to the same destination is required at a later time
(e.g., upon route loss), the TTL in the RREQ IP header is initially (e.g., upon route loss), the TTL in the RREQ IP header is initially
set to the Hop Count plus TTL_INCREMENT. Thereafter, following set to the Hop Count plus TTL_INCREMENT. Thereafter, following
each timeout the TTL is incremented by TTL_INCREMENT until TTL = each timeout the TTL is incremented by TTL_INCREMENT until TTL =
TTL_THRESHOLD is reached. Beyond this TTL = NET_DIAMETER is used. TTL_THRESHOLD is reached. Beyond this TTL = NET_DIAMETER is used.
Timeouts MAY be more accurately determined dynamically via Once TTL = NET_DIAMETER, the timeout for waiting for the RREP is set
measurement, instead of using a statically configured value related to NET_TRAVERSAL_TIME, as specified in section 5.3.
to NODE_TRAVERSAL_TIME.
An expired routing table entry SHOULD NOT be expunged before An expired routing table entry SHOULD NOT be expunged before
(current_time + DELETE_PERIOD) (see section 5.11). Otherwise, the (current_time + DELETE_PERIOD) (see section 5.11). Otherwise, the
soft state corresponding to the route (e.g., last known hop count) soft state corresponding to the route (e.g., last known hop count)
will be lost. Furthermore, a longer routing table entry expunge time will be lost. Furthermore, a longer routing table entry expunge time
MAY be configured. Any routing table entry waiting for a RREP SHOULD MAY be configured. Any routing table entry waiting for a RREP SHOULD
NOT be expunged before (current_time + 2 * NET_TRAVERSAL_TIME). NOT be expunged before (current_time + 2 * NET_TRAVERSAL_TIME).
5.5. Processing and Forwarding Route Requests 5.5. Processing and Forwarding Route Requests
skipping to change at page 18, line 4 skipping to change at page 18, line 19
(i) the sequence number in the routing table is invalid in (i) the sequence number in the routing table is invalid in
route table entry. route table entry.
(ii) the Destination Sequence Number in the RREP is greater (ii) the Destination Sequence Number in the RREP is greater
than the node's copy of the destination sequence number than the node's copy of the destination sequence number
and the known value is valid, or and the known value is valid, or
(iii) the sequence numbers are the same, but the route is no (iii) the sequence numbers are the same, but the route is no
longer active, or longer active, or
(iiii) the sequence numbers are the same, and the New Hop Count
(iv) the sequence numbers are the same, and the New Hop Count
is smaller than the hop count in route table entry. is smaller than the hop count in route table entry.
If either the route table entry to the destination is created or If either the route table entry to the destination is created or
updated, the next hop in the route entry is assigned to be the node updated, the next hop in the route entry is assigned to be the node
from which the RREP is received, which is indicated by the source IP from which the RREP is received, which is indicated by the source IP
address field in the IP header; the hop count is the New Hop Count; address field in the IP header; the hop count is the New Hop Count;
the expiry time is the current time plus the Lifetime in the RREP the expiry time is the current time plus the Lifetime in the RREP
message; and the destination sequence number is the Destination message; and the destination sequence number is the Destination
Sequence Number in the RREP message. The current node can now begin Sequence Number in the RREP message. The current node can now begin
using this route to forward data packets to the destination. using this route to forward data packets to the destination.
skipping to change at page 23, line 48 skipping to change at page 24, line 18
When a link breaks along an active route, there are often multiple When a link breaks along an active route, there are often multiple
destinations that become unreachable. The node that is upstream destinations that become unreachable. The node that is upstream
of the lost link tries an immediate local repair for only the one of the lost link tries an immediate local repair for only the one
destination towards which the data packet was traveling. Other destination towards which the data packet was traveling. Other
routes using the same link MUST be marked as invalid, but the node routes using the same link MUST be marked as invalid, but the node
handling the local repair MAY flag each such newly lost route as handling the local repair MAY flag each such newly lost route as
locally repairable; this local repair flag in the route table MUST be locally repairable; this local repair flag in the route table MUST be
reset when the route times out (e.g., after the route has been not reset when the route times out (e.g., after the route has been not
been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs, been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs,
these other routes will be repaired as needed when packets arrive these other routes will be repaired as needed when packets arrive for
for the other destinations. Alternatively, depending upon local the other destinations. Hence, these routes are repaired as needed;
congestion, the node MAY begin the process of establishing local if a data packet does not arrive for the route, then that route will
repairs for the other routes, without waiting for new packets to not be repaired. Alternatively, depending upon local congestion,
arrive. the node MAY begin the process of establishing local repairs for
the other routes, without waiting for new packets to arrive. By
proactively repairing the routes that have broken due to the loss
of the link, incoming data packets for those routes will not be
subject to the delay of repairing the route and can be immediately
forwarded. However, repairing the route before a data packet is
received for it runs the risk of repairing routes that are no longer
in use. Therefore, depending upon the local traffic in the network
and whether congestion is being experienced, the node MAY elect to
proactively repair the routes before a data packet is received;
otherwise, it can wait until a data is received, and then commence
the repair of the route.
5.13. Actions After Reboot 5.13. Actions After Reboot
A node participating in the ad hoc network must take certain actions A node participating in the ad hoc network must take certain actions
after reboot as it might lose all sequence number records for all after reboot as it might lose all sequence number records for all
destinations, including its own sequence number. However, there destinations, including its own sequence number. However, there
may be neighboring nodes that are using this node as an active next may be neighboring nodes that are using this node as an active next
hop. This can potentially create routing loops. To prevent this hop. This can potentially create routing loops. To prevent this
possibility, each node on reboot waits for DELETE_PERIOD. During this possibility, each node on reboot waits for DELETE_PERIOD. During this
time, the node does not transmit any RREP messages. If the node time, the node does not transmit any RREP messages. If the node
skipping to change at page 27, line 35 skipping to change at page 28, line 20
ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds
ALLOWED_HELLO_LOSS 2 ALLOWED_HELLO_LOSS 2
BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME
DELETE_PERIOD see note below DELETE_PERIOD see note below
HELLO_INTERVAL 1,000 Milliseconds HELLO_INTERVAL 1,000 Milliseconds
LOCAL_ADD_TTL 2 LOCAL_ADD_TTL 2
MAX_REPAIR_TTL 0.3 * NET_DIAMETER MAX_REPAIR_TTL 0.3 * NET_DIAMETER
MIN_REPAIR_TTL see note below MIN_REPAIR_TTL see note below
MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT
NET_DIAMETER 35 NET_DIAMETER 35
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10 NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10
NODE_TRAVERSAL_TIME 40 NODE_TRAVERSAL_TIME 40
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME
RERR_RATELIMIT 10 RERR_RATELIMIT 10
RING_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * (TTL_VALUE + TIMEOUT_BUFFER)
RREQ_RETRIES 2 RREQ_RETRIES 2
RREQ_RATELIMIT 10 RREQ_RATELIMIT 10
TIMEOUT_BUFFER 2
TTL_START 1 TTL_START 1
TTL_INCREMENT 2 TTL_INCREMENT 2
TTL_THRESHOLD 7 TTL_THRESHOLD 7
TTL_VALUE see note below
The MIN_REPAIR_TTL should be the last known hop count to The MIN_REPAIR_TTL should be the last known hop count to
the destination. If Hello messages are used, then the the destination. If Hello messages are used, then the
ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the
value (ALLOWED_HELLO_LOSS * HELLO_INTERVAL). value (ALLOWED_HELLO_LOSS * HELLO_INTERVAL).
TTL_VALUE is the value of the TTL field in the IP header while the
expanding ring search is being performed. This is described further
in section 5.4. The TIMEOUT_BUFFER is configurable. Its purpose is
to provide a buffer for the timeout so that if the RREP is delayed
due to congestion, a timeout is less likely to occur while the RREP
is still en route back to the source. To omit this buffer, set
TIMEOUT_BUFFER = 0.
DELETE_PERIOD should be an upper bound on the time for which an DELETE_PERIOD should be an upper bound on the time for which an
upstream node A can have a neighbor B as an active next hop for upstream node A can have a neighbor B as an active next hop for
destination D, while B has invalidated the route to D. Beyond this destination D, while B has invalidated the route to D. Beyond this
time B can delete the route to D. The determination of the upper time B can delete the route to D. The determination of the upper
bound somewhat depends on the characteristics of the underlying bound somewhat depends on the characteristics of the underlying
link layer. If Hello messages are used to determine the continued link layer. If Hello messages are used to determine the continued
availability of links to next hop nodes, DELETE_PERIOD must be at availability of links to next hop nodes, DELETE_PERIOD must be at
least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. If the link layer feedback least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. If the link layer feedback
is used to detect loss of link, DELETE_PERIOD must be at least is used to detect loss of link, DELETE_PERIOD must be at least
ACTIVE_ROUTE_TIMEOUT. If hello messages are received from a neighbor ACTIVE_ROUTE_TIMEOUT. If hello messages are received from a neighbor
skipping to change at page 31, line 7 skipping to change at page 32, line 7
IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, IPv4, IPv6 and OSI. Request for Comments (Informational) 2030,
Internet Engineering Task Force, October 1996. Internet Engineering Task Force, October 1996.
[6] C. Perkins, E. Royer, and S. Das. Ad Hoc On Demand Distance [6] C. Perkins, E. Royer, and S. Das. Ad Hoc On Demand Distance
Vector (AODV) Routing for IP version 6 (work in progress). Vector (AODV) Routing for IP version 6 (work in progress).
Internet Draft, Internet Engineering Task Force. Internet Draft, Internet Engineering Task Force.
draft-perkins-manet-aodv6-01.txt, November 2001. draft-perkins-manet-aodv6-01.txt, November 2001.
A. Draft Modifications A. Draft Modifications
The following are major changes between this version (11) of the AODV The following are major changes between this version (12) of the AODV
draft and the previous version: draft and the previous version (11):
- Added definitions for valid route, invalid route and sequence
number.
- Re-added discussion in processing and forwarding RREQ that it is
necessary to update the destination sequence number in a RREQ
being forwarded to the maximum known sequence number.
- Added ``destination only'' ('D') flag.
- Specify hello messages should only be used by nodes on active
routes.
- Clarify RERR messages are generated only in response failing to
send data.
- Removed term ``broken''.
- Routes should be created or updated to the previous hop when a
control message is received.
- Added comments near route creation instructions that routes may
be used once created and should cancel further route discovery or
local repair for those destinations.
- Removed NTP timestamp extension
- Added ``route state'' field to routing table.
- Removed ``last hop count'' field from routing table.
- Removed ``infinite hop count'' from draft.
- Added ``unknown sequence number'' flag to RREQ. - Added binary exponential backoff to repeated RREQ attempts
for the same destination.
- Restructured Route Table Entries and Precursor Lists (section 5.2 - Included a mechanism for dynamically calculating the waiting
to inlcude how to create and update routes. time for a RREP during an expanding ring search. This includes the
addition of a new parameter, RING_TRAVERSAL_TIME.
- Route Lifetime to source must be updated when forwarding data - Added the TTL_VALUE and TIMEOUT_BUFFER parameters to help
packets. dynamically calculate the waiting time for a RREP during an
expanding ring search.
- Specify that during reboot no control messages should be - Clarified the option of proactive local repair for recently
forwarded. broken routes.
Author's Addresses Author's Addresses
Questions about this memo can be directed to: Questions about this memo can be directed to:
Charles E. Perkins Charles E. Perkins
Communications Systems Laboratory Communications Systems Laboratory
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94303 Mountain View, CA 94303
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/