draft-ietf-manet-aodv-06.txt   draft-ietf-manet-aodv-07.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
14 July 2000 Elizabeth M. Royer 24 November 2000 Elizabeth M. 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-06.txt draft-ietf-manet-aodv-07.txt
Status of This Memo Status of This Memo
This document is a submission by the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the manet@itd.nrl.navy.mil mailing list.
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
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission by the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the manet@itd.nrl.navy.mil mailing list.
Distribution of this memo is unlimited.
Abstract Abstract
The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is
intended for use by mobile nodes in an ad hoc network. It offers intended for use by mobile nodes in an ad hoc network. It offers
quick adaptation to dynamic link conditions, low processing and quick adaptation to dynamic link conditions, low processing and
memory overhead, low network utilization, and determines unicast memory overhead, low network utilization, and determines unicast
between sources and destinations. It uses destination sequence between sources and destinations. It uses destination sequence
numbers to ensure loop freedom at all times (even in the face of numbers to ensure loop freedom at all times (even in the face of
anomalous delivery of routing control messages), solving problems anomalous delivery of routing control messages), solving problems
(such as ``counting to infinity'') associated with classical distance (such as ``counting to infinity'') associated with classical distance
skipping to change at page 1, line 50 skipping to change at page 1, line 49
intended for use by mobile nodes in an ad hoc network. It offers intended for use by mobile nodes in an ad hoc network. It offers
quick adaptation to dynamic link conditions, low processing and quick adaptation to dynamic link conditions, low processing and
memory overhead, low network utilization, and determines unicast memory overhead, low network utilization, and determines unicast
between sources and destinations. It uses destination sequence between sources and destinations. It uses destination sequence
numbers to ensure loop freedom at all times (even in the face of numbers to ensure loop freedom at all times (even in the face of
anomalous delivery of routing control messages), solving problems anomalous delivery of routing control messages), solving problems
(such as ``counting to infinity'') associated with classical distance (such as ``counting to infinity'') associated with classical distance
vector protocols. vector protocols.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Overview 1 2. Overview 2
3. AODV Terminology 2
4. Route Request (RREQ) Message Format 3
5. Route Reply (RREP) Message Format 4 3. AODV Terminology 3
6. Route Error (RERR) Message Format 6 4. Route Request (RREQ) Message Format 4
7. Route Reply Acknowledgement (RREP-ACK) Message Format 7 5. Route Reply (RREP) Message Format 5
8. AODV Operation 7 6. Route Error (RERR) Message Format 7
8.1. Maintaining Route Utilization Records . . . . . . . . . . 7
8.2. Generating Route Requests . . . . . . . . . . . . . . . . 7
8.2.1. Controlling Route Request broadcasts . . . . . . 8
8.3. Forwarding Route Requests . . . . . . . . . . . . . . . . 9
8.3.1. Processing Route Requests . . . . . . . . . . . . 9
8.4. Generating Route Replies . . . . . . . . . . . . . . . . 11
8.4.1. Route Reply Generation by the Destination . . . 11
8.4.2. Route Reply Generation by an Intermediate Node . 11
8.5. Generating Gratuitous RREPs . . . . . . . . . . . . . . . 12
8.6. Forwarding Route Replies . . . . . . . . . . . . . . . . 13
8.7. Hello Messages . . . . . . . . . . . . . . . . . . . . . 14
8.8. Maintaining Local Connectivity . . . . . . . . . . . . . 14
8.9. Route Error Messages . . . . . . . . . . . . . . . . . . 15
8.9.1. Local Repair . . . . . . . . . . . . . . . . . . 16
8.10. Route Expiry and Deletion . . . . . . . . . . . . . . . . 18
8.11. Actions After Reboot . . . . . . . . . . . . . . . . . . 18
9. AODV and Aggregated Networks 19 7. Route Reply Acknowledgment (RREP-ACK) Message Format 8
10. Using AODV with Other Networks 19 8. AODV Operation 8
8.1. Maintaining Route Utilization Records . . . . . . . . . . 8
8.2. Generating Route Requests . . . . . . . . . . . . . . . . 9
8.2.1. Controlling Route Request broadcasts . . . . . . 10
8.3. Forwarding Route Requests . . . . . . . . . . . . . . . . 11
8.3.1. Processing Route Requests . . . . . . . . . . . . 11
8.4. Generating Route Replies . . . . . . . . . . . . . . . . 13
8.4.1. Route Reply Generation by the Destination . . . 13
8.4.2. Route Reply Generation by an Intermediate Node . 14
8.5. Generating Gratuitous RREPs . . . . . . . . . . . . . . . 14
8.6. Forwarding Route Replies . . . . . . . . . . . . . . . . 15
8.7. Hello Messages . . . . . . . . . . . . . . . . . . . . . 16
8.8. Maintaining Local Connectivity . . . . . . . . . . . . . 17
8.9. Route Error Messages . . . . . . . . . . . . . . . . . . 18
8.9.1. Local Repair . . . . . . . . . . . . . . . . . . 19
8.10. Route Expiry and Deletion . . . . . . . . . . . . . . . . 21
8.11. Actions After Reboot . . . . . . . . . . . . . . . . . . 21
8.12. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 22
9. AODV and Aggregated Networks 22
11. Extensions 20 10. Using AODV with Other Networks 23
11.1. Hello Interval Extension Format . . . . . . . . . . . . . 20
12. Configuration Parameters 21 11. Extensions 24
11.1. Hello Interval Extension Format . . . . . . . . . . . . . 24
13. Security Considerations 22 12. Configuration Parameters 25
14. Acknowledgements 22 13. Security Considerations 26
A. Draft Modifications 24 14. Acknowledgments 27
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
quickly to link breakages and changes in network topology. The quickly to link breakages and changes in network topology. The
skipping to change at page 2, line 28 skipping to change at page 2, line 46
AODV is a routing protocol, and it deals with route table management. AODV is a routing protocol, and it deals with route table management.
Route table information must be kept even for ephemeral routes, such Route table information must be kept even for ephemeral routes, such
as are created to temporarily store reverse paths towards nodes as are created to temporarily store reverse paths towards nodes
originating RREQs. AODV uses the following fields with each route originating RREQs. AODV uses the following fields with each route
table entry: table entry:
- Destination IP Address - Destination IP Address
- Destination Sequence Number - Destination Sequence Number
- Interface
- Hop Count (number of hops needed to reach destination) - Hop Count (number of hops needed to reach destination)
- Last Hop Count (described in subsection 8.2.1) - Last Hop Count (described in subsection 8.2.1)
- Next Hop - Next Hop
- List of Precursors (described in Section 8.1) - List of Precursors (described in Section 8.1)
- Lifetime (expiration or deletion time of the route) - Lifetime (expiration or deletion time of the route)
- Routing Flags - Routing Flags
3. AODV Terminology 3. AODV Terminology
This protocol specification uses conventional meanings [1] for This protocol specification uses conventional meanings [1] for
capitalized words such as MUST, SHOULD, etc., to indicate requirement capitalized words such as MUST, SHOULD, etc., to indicate requirement
levels for various protocol features. This section defines other levels for various protocol features. This section defines other
terminology used with AODV that is not already defined in [3]. terminology used with AODV that is not already defined in [3].
skipping to change at page 2, line 49 skipping to change at page 3, line 27
This protocol specification uses conventional meanings [1] for This protocol specification uses conventional meanings [1] for
capitalized words such as MUST, SHOULD, etc., to indicate requirement capitalized words such as MUST, SHOULD, etc., to indicate requirement
levels for various protocol features. This section defines other levels for various protocol features. This section defines other
terminology used with AODV that is not already defined in [3]. terminology used with AODV that is not already defined in [3].
active route active route
A routing table entry with a finite metric in the Hop Count A routing table entry with a finite metric in the Hop Count
field. A routing table may contain entries that are not active field. A routing table may contain entries that are not active
(invalid routes or entries). They have an inifnite metric (invalid routes or entries). They have an infinite metric
in the Hop Count field. Only active entries can be used to in the Hop Count field. Only active entries can be used to
forward data packets. Invalid entries are eventually deleted. forward data packets. Invalid entries are eventually deleted.
forwarding node forwarding node
A node which agrees to forward packets destined for another A node which agrees to forward packets destined for another
destination node, by retransmitting them to a next hop which is destination node, by retransmitting them to a next hop which is
closer to the unicast destination along a path which has been closer to the unicast destination along a path which has been
set up using routing control messages. set up using routing control messages.
skipping to change at page 7, line 5 skipping to change at page 8, line 12
Unreachable Destination Sequence Number Unreachable Destination Sequence Number
The last known sequence number, incremented by one, The last known sequence number, incremented by one,
of the destination listed in the previous Unreachable of the destination listed in the previous Unreachable
Destination IP Address field. Destination IP Address field.
The RERR message is sent whenever a link break causes one or more The RERR message is sent whenever a link break causes one or more
destinations to become unreachable. The unreachable destination destinations to become unreachable. The unreachable destination
addresses included are those of all lost destinations which are now addresses included are those of all lost destinations which are now
unreachable due to the loss of that link. unreachable due to the loss of that link.
7. Route Reply Acknowledgement (RREP-ACK) Message Format 7. Route Reply Acknowledgment (RREP-ACK) Message Format
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4 Type 4
Reserved Sent as 0; ignored on reception. Reserved Sent as 0; ignored on reception.
The RREP-ACK message is used to acknowledge receipt of an RREP The RREP-ACK message is used to acknowledge receipt of a RREP
message. It is used in cases where the link over which the RREP message. It is used in cases where the link over which the RREP
message is sent may be unreliable. message is sent may be unreliable.
8. AODV Operation 8. AODV Operation
This section describes the scenarios under which nodes generate This section describes the scenarios under which nodes generate
RREQs, RREPs and RERRs for unicast communication, and how the message RREQs, RREPs and RERRs for unicast communication, and how the message
data are handled. data are handled.
8.1. Maintaining Route Utilization Records 8.1. Maintaining Route Utilization Records
skipping to change at page 8, line 7 skipping to change at page 9, line 23
to a destination and does not have one available. This can happen to a destination and does not have one available. This can happen
if the destination is previously unknown to the node, or if a if the destination is previously unknown to the node, or if a
previously valid route to the destination expires or is broken previously valid route to the destination expires or is broken
(i.e., an infinite metric is associated with the route). The (i.e., an infinite metric is associated with the route). The
Destination Sequence Number field in the RREQ message is the last Destination Sequence Number field in the RREQ message is the last
known destination sequence number for this destination and is copied known destination sequence number for this destination and is copied
from the Destination Sequence Number field in the routing table. If from the Destination Sequence Number field in the routing table. If
no sequence number is known, a sequence number of zero is used. The no sequence number is known, a sequence number of zero is used. The
Source Sequence Number in the RREQ message is the node's own sequence Source Sequence Number in the RREQ message is the node's own sequence
number. The Broadcast ID field is incremented by one from the last number. The Broadcast ID field is incremented by one from the last
broadcast ID used by the current node for the same destination. The broadcast ID used by the current node. Each node maintains only one
Hop Count field is set to zero. broadcast ID. The Hop Count field is set to zero.
A source node often expects to have bidirectional communications with A source node often expects to have bidirectional communications with
a destination node. In such cases, it is not sufficient for the a destination node. In such cases, it is not sufficient for the
source node to have a route to the destination node; the destination source node to have a route to the destination node; the destination
must also have a route back to the source node. In order to cause must also have a route back to the source node. In order to cause
this to happen as efficiently as possible, any generation of an RREP this to happen as efficiently as possible, any generation of an RREP
by an intermediate node (as in section 8.4) for delivery to the by an intermediate node (as in section 8.4) for delivery to the
source node, should be accompanied by some action which notifies the source node, should be accompanied by some action which notifies the
destination about a route back to the source node. The source node destination about a route back to the source node. The source node
selects this mode of operation in the intermediate nodes by setting selects this mode of operation in the intermediate nodes by setting
skipping to change at page 13, line 46 skipping to change at page 16, line 18
entry for the source node to determine the next hop for the RREP entry for the source node to determine the next hop for the RREP
packet, and then forwards the RREP towards the source with its Hop packet, and then forwards the RREP towards the source with its Hop
Count incremented by one. Count incremented by one.
When any node generates or forwards a RREP, the precursor list for When any node generates or forwards a RREP, the precursor list for
the corresponding destination node is updated by adding to it the the corresponding destination node is updated by adding to it the
next hop node to which the RREP is forwarded. Also, at each node the next hop node to which the RREP is forwarded. Also, at each node the
(reverse) route used to forward a RREP has its lifetime changed to (reverse) route used to forward a RREP has its lifetime changed to
current time plus ACTIVE_ROUTE_TIMEOUT. current time plus ACTIVE_ROUTE_TIMEOUT.
If a node forwards an RREP over a link that is likely to have errors, If a node forwards a RREP over a link that is likely to have errors,
the node MAY set the `A' flag to require that the recipient of the the node MAY set the `A' flag to require that the recipient of the
RREP is to acknowledge receipt of the RREP by sending a RREP-ACK RREP acknowledge receipt of the RREP by sending a RREP-ACK message
message back. back.
8.7. Hello Messages 8.7. Hello Messages
A node MAY offer connectivity information by broadcasting local A node MAY offer connectivity information by broadcasting local
Hello messages as follows. Every HELLO_INTERVAL milliseconds, the Hello messages as follows. Every HELLO_INTERVAL milliseconds, the
node checks whether it has sent a broadcast (e.g., a RREQ or an node checks whether it has sent a broadcast (e.g., a RREQ or an
appropriate layer 2 message) within the last HELLO_INTERVAL. If it appropriate layer 2 message) within the last HELLO_INTERVAL. If it
has not, it MAY generate a broadcast RREP with TTL = 1, called a has not, it MAY generate a broadcast RREP with TTL = 1, called a
Hello message, with the message fields set as follows: Hello message, with the message fields set as follows:
skipping to change at page 16, line 49 skipping to change at page 19, line 41
which it appears. which it appears.
8.9.1. Local Repair 8.9.1. Local Repair
When a link break in an active route occurs, the node upstream of When a link break in an active route occurs, the node upstream of
that break MAY choose to repair the link locally if the destination that break MAY choose to repair the link locally if the destination
is no farther than MAX_REPAIR_TTL hops away. To repair the link is no farther than MAX_REPAIR_TTL hops away. To repair the link
break itself, it increments the sequence number for the destination break itself, it increments the sequence number for the destination
and then broadcasts a RREQ for that destination. The TTL of the RREQ and then broadcasts a RREQ for that destination. The TTL of the RREQ
should initially be set to the following value: should initially be set to the following value:
max (MIN_REPAIR_TTL, 0.5 TTL to source) + LOCAL_ADD_TTL. max(MIN_REPAIR_TTL, 0.5 TTL to source) + LOCAL_ADD_TTL
Thus, local repair attempts should never be visible to the source Thus, local repair attempts should never be visible to the source
node, and will always have minimum TTL equal to MIN_REPAIR_TTL node, and will always have minimum TTL equal to MIN_REPAIR_TTL
+ LOCAL_ADD_TTL. The node initiating the repair then waits the + LOCAL_ADD_TTL. The node initiating the repair then waits the
discovery period to receive RREPs in response to the RREQ. If, at discovery period to receive RREPs in response to the RREQ. If, at
the end of the discovery period, it has not received a RREP for that the end of the discovery period, it has not received a RREP for that
destination, it proceeds as described in Section 8.9 by creating a destination, it proceeds as described in Section 8.9 by creating a
RERR message for that destination. RERR message for that destination.
On the other hand, if the nodes does receive one or more RREPs during On the other hand, if the nodes does receive one or more RREPs during
the discovery period, the node proceeds as described in Section 8.6, the discovery period, the node proceeds as described in Section 8.6,
skipping to change at page 19, line 7 skipping to change at page 22, line 19
the waiting timer (Lifetime) to expire after current time plus the waiting timer (Lifetime) to expire after current time plus
DELETE_PERIOD. DELETE_PERIOD.
It can be shown that by the time the rebooted node comes out of It can be shown that by the time the rebooted node comes out of
the waiting phase and becomes an active router again, none of its the waiting phase and becomes an active router again, none of its
neighbors will be using it as an active next hop any more. Its own neighbors will be using it as an active next hop any more. Its own
sequence number gets updated once it receives a RREQ from any other sequence number gets updated once it receives a RREQ from any other
node, as the RREQ always carries the maximum destination sequence node, as the RREQ always carries the maximum destination sequence
number seen en route. number seen en route.
8.12. Interfaces
Because AODV should operate smoothly over wired, as well as wireless,
networks, and because it is likely that AODV will also be used with
multi-homed radios, the interface over which packets arrive must
be known to AODV whenever a packet is received. This includes the
reception of RREQ, RREP, and RERR messages. Whenever a packet is
received from a new neighbor, the interface on which that packet was
received is recorded into the route table entry for that neighbor,
along with all the other appropriate routing information. Similarly,
whenever a route to a new destination is learned, the interface
through which the destination can be reached is also recorded into
the destination's route table entry.
When multiple interfaces are available, a node receiving and
rebroadcasting a RREQ message rebroadcasts that message on all
interfaces. Similarly, when a node needs to transmit a RERR, it
should only broadcast it on those interfaces which have precursor
nodes for that route.
9. AODV and Aggregated Networks 9. AODV and Aggregated Networks
AODV has been designed for use by mobile nodes with IP addresses AODV has been designed for use by mobile nodes with IP addresses
that are not necessarily related to each other, to create an ad hoc that are not necessarily related to each other, to create an ad hoc
network. However, in some cases a collection of mobile nodes MAY network. However, in some cases a collection of mobile nodes MAY
operate in a fixed relationship to each other and share a common operate in a fixed relationship to each other and share a common
subnet prefix, moving together within an area where an ad hoc network subnet prefix, moving together within an area where an ad hoc network
has formed. Call such a collection of nodes a ``subnet''. In this has formed. Call such a collection of nodes a ``subnet''. In this
case, it is possible for a single node within the subnet to advertise case, it is possible for a single node within the subnet to advertise
reachability for all other nodes on the subnet, by responding with reachability for all other nodes on the subnet, by responding with
skipping to change at page 22, line 38 skipping to change at page 27, line 9
Currently, AODV does not specify any special security measures. Currently, AODV does not specify any special security measures.
Route protocols, however, are prime targets for impersonation Route protocols, however, are prime targets for impersonation
attacks, and must be protected by use of authentication techniques attacks, and must be protected by use of authentication techniques
involving generation of unforgeable and cryptographically strong involving generation of unforgeable and cryptographically strong
message digests or digital signatures. It is expected that, in message digests or digital signatures. It is expected that, in
environments where security is an issue, that IPSec authentication environments where security is an issue, that IPSec authentication
headers will be deployed along with the necessary key management to headers will be deployed along with the necessary key management to
distribute keys to the members of the ad hoc network using AODV. distribute keys to the members of the ad hoc network using AODV.
14. Acknowledgements 14. Acknowledgments
We acknowledge with gratitude the work done at University of We acknowledge with gratitude the work done at University of
Pennsylvania within Carl Gunter's group, as well as at Stanford and Pennsylvania within Carl Gunter's group, as well as at Stanford and
CMU, to determine some conditions (especially involving reboots and CMU, to determine some conditions (especially involving reboots and
lost RERRs) under which previous versions of AODV could suffer from lost RERRs) under which previous versions of AODV could suffer from
routing loops. Contributors to those efforts include Karthikeyan routing loops. Contributors to those efforts include Karthikeyan
Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and
Davor Obradovic. The idea of a DELETE_PERIOD, for which expired Davor Obradovic. The idea of a DELETE_PERIOD, for which expired
routes (and, in particular, the sequence numbers) to a particular routes (and, in particular, the sequence numbers) to a particular
destination must be maintained, was also suggested by them. destination must be maintained, was also suggested by them.
skipping to change at page 23, line 4 skipping to change at page 27, line 23
CMU, to determine some conditions (especially involving reboots and CMU, to determine some conditions (especially involving reboots and
lost RERRs) under which previous versions of AODV could suffer from lost RERRs) under which previous versions of AODV could suffer from
routing loops. Contributors to those efforts include Karthikeyan routing loops. Contributors to those efforts include Karthikeyan
Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and
Davor Obradovic. The idea of a DELETE_PERIOD, for which expired Davor Obradovic. The idea of a DELETE_PERIOD, for which expired
routes (and, in particular, the sequence numbers) to a particular routes (and, in particular, the sequence numbers) to a particular
destination must be maintained, was also suggested by them. destination must be maintained, was also suggested by them.
We also acknowledge the comments and improvements suggested by SJ Lee We also acknowledge the comments and improvements suggested by SJ Lee
(especially regarding local repair) and Mahesh Marina. (especially regarding local repair) and Mahesh Marina.
References References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement [1] S. Bradner. Key words to use in RFCs to indicate requirement
Levels. Request for Comments (Best Current Practice) 2119, levels. RFC 2119, March 1997.
Internet Engineering Task Force, March 1997.
[2] IEEE 802.11 Committee, AlphaGraphics #35, 10201 N.35th Avenue,
Phoenix AZ 85051. Wireless LAN Medium Access Control MAC and
Physical Layer PHY Specifications, June 1997. IEEE Standard
802.11-97.
[3] Charles E. Perkins. Terminology for Ad-Hoc Networking (work in
progress). draft-ietf-manet-terms-00.txt, November 1997.
A. Draft Modifications
The following are major changes between this version (06) of the AODV
draft and the previous version (05):
- Removed sections on Broadcast, Multicast, QoS, and
Autoconfiguration into separate documents
- Added Gratuitous RREP feature
- Added optional ability for RREP sender to require acknowledgement [2] IEEE Standards Department. Wireless LAN medium access control
(NOT YET!) (MAC) and physical layer (PHY) specifications, IEEE standard
802.11--1997, 1997.
- Added local repair (NOT YET!) [3] C. E. Perkins. Mobile ad hoc networking terminology. IETF
Internet Draft, draft-ietf-manet-term-00.txt (Work in Progress),
October 1997.
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/