draft-ietf-manet-zone-iarp-01.txt   draft-ietf-manet-zone-iarp-02.txt 
INTERNET-DRAFT Zygmunt J. Haas, Cornell University INTERNET-DRAFT Zygmunt J. Haas, Cornell University
Marc R. Pearlman, Cornell University Marc R. Pearlman, Cornell University
Prince Samar, Cornell University Prince Samar, Cornell University
Expires in six months on December 2001 June 2001 Expires in six months on January 2003 July 2002
The Intrazone Routing Protocol (IARP) for Ad Hoc Networks The Intrazone Routing Protocol (IARP) for Ad Hoc Networks
<draft-ietf-manet-zone-iarp-01.txt> <draft-ietf-manet-zone-iarp-02.txt>
Status of this Memo Status of this Memo
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 RFC 2026, except the right to all provisions of Section 10 of RFC 2026, except the right to
produce derivative works is not granted. produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at line 38 skipping to change at line 38
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.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
This document describes the Intrazone Routing Protocol (IARP), a This document describes the Intrazone Routing Protocol (IARP), a
limited scope proactive routing protocol used to improve the limited scope proactive routing protocol used to improve the
performance of existing globally reactive routing protocols. With performance of existing globally reactive routing protocols. With
each node monitoring changes in its surrounding r-hop neighborhood each node monitoring changes in its surrounding R-hop neighborhood
(routing zone), global route discoveries to local destinations can be (routing zone), global route discoveries to local destinations can be
avoided. When a global route search is needed, the IARP's routing avoided. When a global route search is needed, the IARP's routing
zones can be used to efficiently guide route queries outwards (via zones can be used to efficiently guide route queries outwards (via
bordercasting) rather than blindly relaying queries from neighbor bordercasting) rather than blindly relaying queries from neighbor
to neighbor. The proactive maintenance of routing zones also helps to neighbor. The proactive maintenance of routing zones also helps
improve the quality of discovered routes, by making them more robust improve the quality of discovered routes, by making them more robust
to changes in network topology. Once routes have been discovered, to changes in network topology. Once routes have been discovered,
IARP's routing zone offers enhanced, real-time, route maintenance. IARP's routing zone offers enhanced, real-time, route maintenance.
Link failures can be bypassed by multiple hop paths within the Link failures can be bypassed by multiple hop paths within the
routing zone. Similarly, suboptimal route segments can be identified routing zone. Similarly, suboptimal route segments can be identified
and traffic re-routed along shorter paths. and traffic re-routed along shorter paths.
Haas, Pearlman, Samar Expires December 2001 [Page i] Haas, Pearlman, Samar Expires January 2003 [Page i]
Contents Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . i Status of this Memo . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Applicability Statement . . . . . . . . . . . . . . . . . . . iii Applicability Statement . . . . . . . . . . . . . . . . . . . iii
A. Networking Context . . . . . . . . . . . . . . . . . iii A. Networking Context . . . . . . . . . . . . . . . . . iii
B. Protocol Characteristics and Mechanisms . . . . . . . iii B. Protocol Characteristics and Mechanisms . . . . . . . iii
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1
skipping to change at line 79 skipping to change at line 79
B. Data Structures . . . . . . . . . . . . . . . . . . . . 5 B. Data Structures . . . . . . . . . . . . . . . . . . . . 5
C. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 6 C. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 6
D. State Machine . . . . . . . . . . . . . . . . . . . . . 6 D. State Machine . . . . . . . . . . . . . . . . . . . . . 6
E. Pseudocode Implementation . . . . . . . . . . . . . . . 7 E. Pseudocode Implementation . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Information . . . . . . . . . . . . . . . . . . . . . 11 Authors' Information . . . . . . . . . . . . . . . . . . . . . 11
MANET Contact Information . . . . . . . . . . . . . . . . . . . 11 MANET Contact Information . . . . . . . . . . . . . . . . . . . 11
Haas, Pearlman, Samar Expires December 2001 [Page ii] Haas, Pearlman, Samar Expires January 2003 [Page ii]
Applicability Statement Applicability Statement
A. Networking Context A. Networking Context
The Intrazone Routing Protocol (IARP) is a limited scope proactive The Intrazone Routing Protocol (IARP) is a limited scope proactive
routing protocol, which is used to support a primary global routing routing protocol, which is used to support a primary global routing
protocol. The scope of the IARP is defined by the routing zone protocol. The scope of the IARP is defined by the routing zone
radius: the distance in hops that IARP route updates are relayed. radius: the distance in hops that IARP route updates are relayed.
skipping to change at line 175 skipping to change at line 175
* Does the protocol require link or neighbor status sensing * Does the protocol require link or neighbor status sensing
(if so, how?) (if so, how?)
Yes. IARP proactively maintains local routing information Yes. IARP proactively maintains local routing information
(routing zones) based on detected changes in neighbor status. (routing zones) based on detected changes in neighbor status.
* Does the protocol have dependence on a central entity? * Does the protocol have dependence on a central entity?
(if so, how?) (if so, how?)
No. IERP is a fully distributed protocol. No. IARP is a fully distributed protocol.
Haas, Pearlman, Samar Expires December 2001 [Page iv] Haas, Pearlman, Samar Expires January 2003 [Page iv]
* Does the protocol function reactively? (if so, how?) * Does the protocol function reactively? (if so, how?)
No. No.
* Does the protocol function proactively? (if so, how?) * Does the protocol function proactively? (if so, how?)
Yes. IARP proactively maintains LOCAL routing information Yes. IARP proactively maintains LOCAL routing information
(routing zones) for each node. The routing zone information is (routing zones) for each node. The routing zone information is
leveraged, through the bordercasting mechanism, to support leveraged, through the bordercasting mechanism, to support
efficient global propagation of route queries. efficient global propagation of route queries.
skipping to change at line 211 skipping to change at line 211
No. It is assumed that security issues are adequately addressed No. It is assumed that security issues are adequately addressed
by the underlying protocols (IPsec, for example). by the underlying protocols (IPsec, for example).
* Does the protocol provide support for utilizing multi-channel, * Does the protocol provide support for utilizing multi-channel,
link-layer technologies? (if so, how?) link-layer technologies? (if so, how?)
Yes. It is assumed that each node's network interface is Yes. It is assumed that each node's network interface is
assigned a unique IP address. assigned a unique IP address.
Haas, Pearlman, Samar Expires December 2001 [Page v] Haas, Pearlman, Samar Expires January 2003 [Page v]
1. Introduction 1. Introduction
The design of ad hoc network routing protocols is influenced by link The design of ad hoc network routing protocols is influenced by link
instability (due to node mobility) and limitations in available instability (due to node mobility) and limitations in available
bandwidth and transmission power. Traditional wired networks use bandwidth and transmission power. Traditional wired networks use
proactive routing protocols, like OSPF [7] and RIP [15] to maintain proactive routing protocols, like OSPF [7] and RIP [15] to maintain
up-to-date routes to all networks nodes. More efficient proactive up-to-date routes to all networks nodes. More efficient proactive
routing protocols have been developed for ad hoc networks [1][5][8] routing protocols have been developed for ad hoc networks [1][5][8]
[9][14]. However, continuously tracking the frequent topology changes [9][14]. However, continuously tracking the frequent topology changes
skipping to change at line 264 skipping to change at line 264
paths. paths.
Within the context of the ZRP, we refer to the locally proactive Within the context of the ZRP, we refer to the locally proactive
routing component as the Intrazone Routing Protocol (IARP). The IARP routing component as the Intrazone Routing Protocol (IARP). The IARP
is not a specific routing protocol. Rather, it is a family of is not a specific routing protocol. Rather, it is a family of
limited-depth, proactive, link state routing protocols. In this limited-depth, proactive, link state routing protocols. In this
document, we provide an implementation of a simple timer-based IARP. document, we provide an implementation of a simple timer-based IARP.
In addition, we provide a set of basic guidelines which can be used to In addition, we provide a set of basic guidelines which can be used to
convert an existing proactive routing protocol to an IARP. convert an existing proactive routing protocol to an IARP.
Haas, Pearlman, Samar Expires December 2001 [Page 1] Haas, Pearlman, Samar Expires January 2003 [Page 1]
2. Routing Zones and Intrazone Routing 2. Routing Zones and Intrazone Routing
A routing zone for a node X is defined as the set of nodes whose A routing zone for a node X is defined as the set of nodes whose
minimum distance in *hops* from X is no greater than some parameter minimum distance in *hops* from X is no greater than some parameter
referred to as the zone radius. An example of a radius R == 2 hop referred to as the zone radius. An example of a radius R = 2 hop
routing zone (for node A) is shown below. routing zone (for node A) is shown below.
+-----------------------------------------+ +-----------------------------------------+
| +---+ | | +---+ |
| +---+ ---| F |-------| | | +---+ ---| F |-------| |
+---+ | +---+ --| C |--/ +---+ +---+ | +---+ | +---+ --| C |--/ +---+ +---+ |
| G |-----| D |--/ +---+ | E | | Routing Zone of | G |-----| D |--/ +---+ | E | | Routing Zone of
+---+ | +---+ | +---+ +---+ | node A +---+ | +---+ | +---+ +---+ | node A
| +---+ ---| B |-------| | (radius = 2 hops) | +---+ ---| B |-------| | (radius = 2 hops)
| | A |--/ +---+ | | | A |--/ +---+ |
| +---+ | | +---+ |
+-----------------------------------------+ +-----------------------------------------+
In this example nodes B through F are within the routing zone of A. In this example nodes B through F are within the routing zone of A.
Node G is outside A's routing zone. Also note that E can be reached by Node G is outside A's routing zone. Also note that E can be reached by
two paths from A, one with length 2 hops and one with length 3 hops. two paths from A, one with length 2 hops and one with length 3 hops.
Since the minimum is less than or equal than 2, E is within A's Since the minimum is less than or equal to 2, E is within A's routing
routing zone. Peripheral nodes are routing zone nodes whose minimum zone. Peripheral nodes are routing zone nodes whose minimum distance
distance to the node in question is equal exactly to the zone radius. to the node in question is equal exactly to the zone radius. In the
In the above figure, nodes D, F and E are A's peripheral nodes. These above figure, nodes D, F and E are A's peripheral nodes. These
peripheral nodes play an important role in efficient querying based on peripheral nodes play an important role in efficient querying based on
bordercasting. We note that each node maintains its own routing zone. bordercasting. We note that each node maintains its own routing zone.
As a result, routing zones of nearby nodes may overlap heavily. As a result, routing zones of nearby nodes may overlap heavily.
Each node proactively tracks the topology of its routing zone through Each node proactively tracks the topology of its routing zone through
an IntrAzone Routing Protocol (IARP). IARP is derived from globally an IntrAzone Routing Protocol (IARP). IARP is derived from globally
proactive link state routing protocols (for example, OSPF). The base proactive link state routing protocols (for example, OSPF). The base
protocol needs to be modified to ensure that the scope of the route protocol needs to be modified to ensure that the scope of the route
updates is restricted to the radius of the node's routing zone. The updates is restricted to the radius of the node's routing zone. The
required modifications and example IARP are described in the next required modifications and example IARP are described in the next
sections. sections.
Haas, Pearlman, Samar Expires December 2001 [Page 2] Haas, Pearlman, Samar Expires January 2003 [Page 2]
3. IARP Conversion Guidelines 3. IARP Conversion Guidelines
Traditional proactive link state protocols can be modified to serve as Traditional proactive link state protocols can be modified to serve as
an IARP by limiting link state updates to the scope of the link an IARP by limiting link state updates to the scope of the link
source's routing zone. The following guidelines can be used to source's routing zone. The following guidelines can be used to
convert existing proactive link state routing protocols to an IARP: convert existing proactive link state routing protocols to an IARP:
- The scope of link state advertisements are limited by a TTL (time - The scope of link state advertisements are limited by a TTL (time
to live) in the link state update packet. The TTL is initialized to to live) in the link state update packet. The TTL is initialized to
skipping to change at line 348 skipping to change at line 348
its link state (current set of neighbors and corresponding lists of its link state (current set of neighbors and corresponding lists of
link metrics) throughout its routing zone. Nodes monitor their link metrics) throughout its routing zone. Nodes monitor their
own link state by means of a neighbor discovery protocol *. own link state by means of a neighbor discovery protocol *.
The scope of a link state update is controlled by a TTL (time-to- The scope of a link state update is controlled by a TTL (time-to-
live) value that is carried in the link state packet. The TTL is live) value that is carried in the link state packet. The TTL is
initialized by the link source to R-1 hops (where R is the zone initialized by the link source to R-1 hops (where R is the zone
radius). Upon receipt of link state update packet, the link state is radius). Upon receipt of link state update packet, the link state is
recorded, the routing table is recomputed and the packet's TTL value recorded, the routing table is recomputed and the packet's TTL value
is decremented. As long as the TTL value is greater than 0, the link is decremented. As long as the TTL value is greater than 0, the link
state update packet is rebroadcast. state update packet is rebroadcasted.
* This IARP relies on the services of a separate protocol (referred to * This IARP relies on the services of a separate protocol (referred to
here as the Neighbor Discovery Protocol (NDP)) to provide current here as the Neighbor Discovery Protocol (NDP)) to provide current
information about a node's neighbors. At the least, this informa- information about a node's neighbors. At the least, this informa-
tion must include the IP addresses of all the neighbors. IARP and tion must include the IP addresses of all the neighbors. IARP and
NDP can be configured to support supplemental link quality metrics. NDP can be configured to support supplemental link quality metrics.
Haas, Pearlman, Samar Expires December 2001 [Page 3] Haas, Pearlman, Samar Expires January 2003 [Page 3]
A. Packet Format A. Packet Format
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Source Address | | Link Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State Seq Num | Zone Radius | TTL | | Link State Seq Num | Zone Radius | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | RESERVED | Link Dest Cnt | | RESERVED | RESERVED | Link Dest Cnt |
skipping to change at line 408 skipping to change at line 408
IP address of the reported link's source node. IP address of the reported link's source node.
* Link State Seq Num (unsigned int) (16 bits) * Link State Seq Num (unsigned int) (16 bits)
Sequence number used to track the link state history of Sequence number used to track the link state history of
the Link Source node. the Link Source node.
* Zone Radius (char) (8 bits) * Zone Radius (char) (8 bits)
Routing zone radius of the link's source node. Determines Routing zone radius of the link's source node. Determines
the extent that link state information propagates. the extent that link state information propagates.
Haas, Pearlman, Samar Expires December 2001 [Page 4] Haas, Pearlman, Samar Expires January 2003 [Page 4]
* TTL (char) (8 bits) * TTL (char) (8 bits)
number of hops remaining until packet is to be discarded number of hops remaining until packet is to be discarded
* Link Dest Count (char) (8 bits) * Link Dest Count (char) (8 bits)
number of link source's neighbors number of link source's neighbors
* Link Destination Address (node_id) (n * 32 bits) * Link Destination Address (node_id) (n * 32 bits)
IP addresses of the link source's neighbor nodes. IP addresses of the link source's neighbor nodes.
* Node/Link Metrics (metric) (n*X * 32 bits) * Node/Link Metrics (metric) (n*X * 32 bits)
skipping to change at line 460 skipping to change at line 460
| Addr | | ID | | | | Addr | | ID | | |
| (node_id) | (int) | (int) | (int) | (ls_info list) | | (node_id) | (int) | (int) | (int) | (ls_info list) |
+-----------|--------+-------+--------+------------------| +-----------|--------+-------+--------+------------------|
| | | | | | | | | | | |
|-----------|--------+-------+--------+------------------| |-----------|--------+-------+--------+------------------|
| | | | | | | | | | | |
|-----------|--------+-------+--------+------------------| |-----------|--------+-------+--------+------------------|
| | | | | | | | | | | |
+-----------|--------------------------------------------+ +-----------|--------------------------------------------+
Haas, Pearlman, Samar Expires December 2001 [Page 5] Haas, Pearlman, Samar Expires January 2003 [Page 5]
## detail of (ls_info) data type ## detail of (ls_info) data type
+---+---|---| +---+---|---|
| | ||||| | | |||||
+---+---|---| +---+---|---|
(a) (b) (c) (a) (b) (c)
(a) Link Destination Address (a) Link Destination Address
(b) Link Destination Subnet Mask (b) Link Destination Subnet Mask
(c) Link Metrics (c) Link Metrics
skipping to change at line 505 skipping to change at line 505
Event: Link state broadcast timer interrupt. Event: Link state broadcast timer interrupt.
Action: X consults the neighbor discovery process for its Action: X consults the neighbor discovery process for its
own link state (list of neighbors and corresponding own link state (list of neighbors and corresponding
link metrics). X updates its Link State Table and link metrics). X updates its Link State Table and
Routing Table accordingly. The TTL value is Routing Table accordingly. The TTL value is
initialized to R-1 hops (where R is the zone radius). initialized to R-1 hops (where R is the zone radius).
If the TTL is greater than 0 then X loads a link If the TTL is greater than 0 then X loads a link
state packet and broadcasts it to its neighbors. state packet and broadcasts it to its neighbors.
Haas, Pearlman, Samar Expires December 2001 [Page 6] Haas, Pearlman, Samar Expires January 2003 [Page 6]
D.2 D.2
Event: An IARP link state packet is received. Event: An IARP link state packet is received.
Action: The link state update is recorded in the Link State Action: The link state update is recorded in the Link State
Table and the Routing Table is updated accordingly. Table and the Routing Table is updated accordingly.
The TTL is decremented. If the TTL is greater The TTL is decremented. If the TTL is greater
than 0 then X broadcasts the link state packet to than 0 then X broadcasts the link state packet to
its neighbors. its neighbors.
D.3 D.3
skipping to change at line 554 skipping to change at line 554
{ {
link_source = MY_ID; link_source = MY_ID;
Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]); Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]);
TTL = R; TTL = R;
} }
// Record link state information in Link State Table // Record link state information in Link State Table
add(Link_State_Table, link_source, link_dest, mask, radius, add(Link_State_Table, link_source, link_dest, mask, radius,
link_metric, state_id, flags); link_metric, state_id, flags);
Haas, Pearlman, Samar Expires December 2001 [Page 7] Haas, Pearlman, Samar Expires January 2003 [Page 7]
// Recompute Routing Table // Recompute Routing Table
Routing_Table =compute_routes_from_links(Link_State_Table,node); Routing_Table =compute_routes_from_links(Link_State_Table,node);
// Report Routing Table update to IERP // Report Routing Table update to IERP
IARP_updated(); IARP_updated();
// Relay link state update only if link source lies inside of // Relay link state update only if link source lies inside of
// of routing zone (evaluated based on TTL value) // of routing zone (evaluated based on TTL value)
TTL--; TTL--;
if(TTL > 0) if(TTL > 0)
skipping to change at line 591 skipping to change at line 591
if(current_time()-insert_time > LINK_STATE_LIFETIME) if(current_time()-insert_time > LINK_STATE_LIFETIME)
remove_from_table(Link_State_Table, link_source); remove_from_table(Link_State_Table, link_source);
} }
// Recompute Routing Table // Recompute Routing Table
Routing_Table = compute_routes_from_links(Link_State_Table,node); Routing_Table = compute_routes_from_links(Link_State_Table,node);
// Report Routing Table update to IERP // Report Routing Table update to IERP
IARP_updated(); IARP_updated();
Haas, Pearlman, Samar Expires December 2001 [Page 8] Haas, Pearlman, Samar Expires January 2003 [Page 8]
5. References 5. References
[1] Garcia-Luna-Aceves, J.J. and Spohn, M., "Efficient Routing in [1] Garcia-Luna-Aceves, J.J. and Spohn, M., "Efficient Routing in
Packet-Radio Networks Using Link-State Information," Packet-Radio Networks Using Link-State Information,"
WCNC '99, September 1999. WCNC '99, September 1999.
[2] Haas, Z.J., Pearlman, M.R. and Samar, P., "Bordercast Resolution [2] Haas, Z.J., Pearlman, M.R. and Samar, P., "Bordercast Resolution
Protocol (BRP)," IETF Internet Draft, Protocol (BRP)," IETF Internet Draft,
draft-ietf-manet-brp-01.txt, June 2001. draft-ietf-manet-brp-02.txt, July 2002.
[3] Haas, Z.J., Pearlman, M.R. and Samar, P., "Interzone Routing [3] Haas, Z.J., Pearlman, M.R. and Samar, P., "Interzone Routing
Protocol (IERP)," IETF Internet Draft, Protocol (IERP)," IETF Internet Draft,
draft-ietf-manet-ierp-01.txt, June 2001. draft-ietf-manet-ierp-02.txt, July 2002.
[4] Haas, Z.J., Pearlman, M.R. and Samar, P., "Zone Routing Protocol [4] Haas, Z.J., Pearlman, M.R. and Samar, P., "Zone Routing Protocol
(ZRP)," IETF Internet Draft, draft-ietf-manet-zrp-04.txt, (ZRP)," IETF Internet Draft, draft-ietf-manet-zrp-04.txt,
January 2001. July 2002.
[5] Jacquet, P., Muhlethaler, P., Qayyum A., Laouiti A., Viennot L., [5] Jacquet, P., Muhlethaler, P., Qayyum A., Laouiti A., Viennot L.,
and Clausen T., "Optimized Link State Routing Protocol," and Clausen T., "Optimized Link State Routing Protocol,"
IETF Internet Draft, draft-ietf-manet-olsr-03.txt, IETF Internet Draft, draft-ietf-manet-olsr-03.txt,
November 2000. November 2000.
[6] Johnson, D.B. and Maltz, D.A., "Dynamic Source Routing in Ad-Hoc [6] Johnson, D.B. and Maltz, D.A., "Dynamic Source Routing in Ad-Hoc
Wireless Networks," in Mobile Computing, edited by T. Wireless Networks," in Mobile Computing, edited by T.
Imielinski and H. Korth, chapter 5, pp. 153-181, Imielinski and H. Korth, chapter 5, pp. 153-181,
Kluwer, 1996. Kluwer, 1996.
skipping to change at line 641 skipping to change at line 642
Routing Algorithm for Mobile Wireless Networks," Routing Algorithm for Mobile Wireless Networks,"
IEEE INFOCOM'97, Kobe, Japan, 1997. IEEE INFOCOM'97, Kobe, Japan, 1997.
[11] Pearlman, M.R. and Haas, Z.J., "Determining the Optimal [11] Pearlman, M.R. and Haas, Z.J., "Determining the Optimal
Configuration for the Zone Routing Protocol," IEEE JSAC, Configuration for the Zone Routing Protocol," IEEE JSAC,
August, 1999. August, 1999.
[12] Pearlman, M.R., Haas, Z.J. and S.I. Mir, "Using Routing Zones to [12] Pearlman, M.R., Haas, Z.J. and S.I. Mir, "Using Routing Zones to
Support Route Maintenance in Ad Hoc Networks," Support Route Maintenance in Ad Hoc Networks,"
IEEE WCNC 2000, Chicago, IL, Sept. 2000. IEEE WCNC 2000, Chicago, IL, Sept. 2000.
Haas, Pearlman, Samar Expires December 2001 [Page 9] Haas, Pearlman, Samar Expires January 2003 [Page 9]
[13] Perkins, C.E. and Royer, E.M., "Ad Hoc On-Demand Distance [13] Perkins, C.E. and Royer, E.M., "Ad Hoc On-Demand Distance
Vector Routing," IEEE WMCSA'99, New Orleans, LA, Feb. 1999 Vector Routing," IEEE WMCSA'99, New Orleans, LA, Feb. 1999
[14] Perkins, C.E. and Bhagwat, P., "Highly Dynamic [14] Perkins, C.E. and Bhagwat, P., "Highly Dynamic
Destination-Sequenced Distance-Vector Routing (DSDV) for Destination-Sequenced Distance-Vector Routing (DSDV) for
Mobile Computers," ACM SIGCOMM, vol.24, no.4, October 1994. Mobile Computers," ACM SIGCOMM, vol.24, no.4, October 1994.
[15] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [15] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
Haas, Pearlman, Samar Expires December 2001 [Page 10] Haas, Pearlman, Samar Expires January 2003 [Page 10]
Authors' Information Authors' Information
Zygmunt J. Haas Zygmunt J. Haas
Wireless Networks Laboratory Wireless Networks Laboratory
323 Frank Rhodes Hall 323 Frank Rhodes Hall
School of Electrical Engineering School of Electrical & Computer Engineering
Cornell University Cornell University
Ithaca, NY 14853 Ithaca, NY 14853
United States of America tel: (607) 255-3454, fax: (607) 255-9072 United States of America tel: (607) 255-3454, fax: (607) 255-9072
Email: haas@ee.cornell.edu Email: haas@ece.cornell.edu
Marc R. Pearlman Marc R. Pearlman
389 Frank Rhodes Hall 389 Frank Rhodes Hall
School of Electrical Engineering School of Electrical & Computer Engineering
Cornell University Cornell University
Ithaca, NY 14853 Ithaca, NY 14853
United States of America United States of America
tel: (607) 255-0236, fax: (607) 255-9072 tel: (607) 255-0236, fax: (607) 255-9072
Email: pearlman@ee.cornell.edu Email: pearlman@ece.cornell.edu
Prince Samar Prince Samar
372 Frank Rhodes Hall 374 Frank Rhodes Hall
School of Electrical Engineering School of Electrical & Computer Engineering
Cornell University Cornell University
Ithaca, NY 14853 Ithaca, NY 14853
United States of America United States of America
tel: (607) 255-9068, fax: (607) 255-9072 tel: (607) 255-9068, fax: (607) 255-9072
Email: samar@ee.cornell.edu Email: samar@ece.cornell.edu
The MANET Working Group contacted through its chairs: The MANET Working Group contacted through its chairs:
M. Scott Corson M. Scott Corson
Institute for Systems Research Institute for Systems Research
University of Maryland College Park, MD 20742 University of Maryland College Park, MD 20742
(301) 405-6630 (301) 405-6630
corson@isr.umd.edu corson@isr.umd.edu
Joseph Macker Joseph Macker
Information Technology Division Information Technology Division
Naval Research Laboratory Naval Research Laboratory
Washington, DC 20375 Washington, DC 20375
(202) 767-2001 (202) 767-2001
macker@itd.nrl.navy.mil macker@itd.nrl.navy.mil
Haas, Pearlman, Samar Expires December 2001 [Page 11] Haas, Pearlman, Samar Expires January 2003 [Page 11]
 End of changes. 

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