One document matched: draft-ietf-manet-zone-iarp-02.txt
Differences from draft-ietf-manet-zone-iarp-01.txt
INTERNET-DRAFT Zygmunt J. Haas, Cornell University
Marc R. Pearlman, Cornell University
Prince Samar, Cornell University
Expires in six months on January 2003 July 2002
The Intrazone Routing Protocol (IARP) for Ad Hoc Networks
<draft-ietf-manet-zone-iarp-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026, except the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Abstract
This document describes the Intrazone Routing Protocol (IARP), a
limited scope proactive routing protocol used to improve the
performance of existing globally reactive routing protocols. With
each node monitoring changes in its surrounding R-hop neighborhood
(routing zone), global route discoveries to local destinations can be
avoided. When a global route search is needed, the IARP's routing
zones can be used to efficiently guide route queries outwards (via
bordercasting) rather than blindly relaying queries from neighbor
to neighbor. The proactive maintenance of routing zones also helps
improve the quality of discovered routes, by making them more robust
to changes in network topology. Once routes have been discovered,
IARP's routing zone offers enhanced, real-time, route maintenance.
Link failures can be bypassed by multiple hop paths within the
routing zone. Similarly, suboptimal route segments can be identified
and traffic re-routed along shorter paths.
Haas, Pearlman, Samar Expires January 2003 [Page i]
INTERNET DRAFT Intrazone Routing Protocol July 2002
Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Applicability Statement . . . . . . . . . . . . . . . . . . . iii
A. Networking Context . . . . . . . . . . . . . . . . . iii
B. Protocol Characteristics and Mechanisms . . . . . . . iii
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1
2. Routing Zones and Intrazone Routing . . . . . . . . . . . . 2
3. IARP Conversion Guidelines . . . . . . . . . . . . . . . . 3
4. Implementation Example - Timer Based Link State . . . . . . 3
A. Packet Format . . . . . . . . . . . . . . . . . . . . . 4
B. Data Structures . . . . . . . . . . . . . . . . . . . . 5
C. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 6
D. State Machine . . . . . . . . . . . . . . . . . . . . . 6
E. Pseudocode Implementation . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Information . . . . . . . . . . . . . . . . . . . . . 11
MANET Contact Information . . . . . . . . . . . . . . . . . . . 11
Haas, Pearlman, Samar Expires January 2003 [Page ii]
INTERNET DRAFT Intrazone Routing Protocol July 2002
Applicability Statement
A. Networking Context
The Intrazone Routing Protocol (IARP) is a limited scope proactive
routing protocol, which is used to support a primary global routing
protocol. The scope of the IARP is defined by the routing zone
radius: the distance in hops that IARP route updates are relayed.
IARP's proactive tracking of local network connectivity provides
support for route acquisition and route maintenance. First, routes
to local destinations are immediately available, avoiding the traffic
overhead and latency of a route discovery. When a global route
discovery is required for more distant destinations, inefficient
query broadcasting can be replaced by a more bandwidth efficient
query bordercasting [2], which directs queries to the periphery of
the routing zone.
Once routes have been discovered, IARP's routing zone offers
enhanced, real-time, route maintenance. Link failures can be
bypassed by multiple hop paths within the routing zone. Similarly,
suboptimal route segments can be identified, enabling traffic to be
re-routed along shorter paths.
B. Protocol Characteristics and Mechanisms
* Does the protocol provide support for unidirectional links?
(if so, how?)
Yes. The IARP can provide "local" support for unidirectional
links. A unidirectional link can be used as long as the link
source and link destination lie within each other's routing zone.
* Does the protocol require the use of tunneling? (if so, how?)
No.
* Does the protocol require using some form of source routing?
(if so, how?)
No.
* Does the protocol require the use of periodic messaging?
(if so, how?)
Yes. The IARP proactively maintains local routing information
(routing zones) based on periodic exchanges of neighbor
discovery messages.
Haas, Pearlman, Samar Expires January 2003 [Page iii]
INTERNET DRAFT Intrazone Routing Protocol (IARP) July 2002
* Does the protocol require the use of reliable or sequenced packet
delivery? (if so, how?)
IARP only assumes that link-layer (neighbor) unicasts are
delivered reliably and in-sequence. Reliable and sequenced
delivery of neighbor broadcasts and IP unicasts is not
required.
* Does the protocol provide support for routing through a multi-
technology routing fabric? (if so, how?)
Yes. It is assumed that each node's network interface is
assigned a unique IP address.
* Does the protocol provide support for multiple hosts per router?
(if so, how?)
Yes. Multiple hosts may be associated with a router. These
hosts can be identified by the neighbor discovery/maintenance
process.
By default, it is assumed that a host's association with a router
is not permanent. As a result, IARP exchanges routing
information for individual hosts in the same manner as routing
information for routers.
In cases where a router is permanently associated with a network
(subnetwork), IARP supports the exchange of network
(subnetwork) prefixes in place of all aggregated host IP
addresses.
* Does the protocol support the IP addressing architecture?
(if so, how?)
Yes. Each node is assumed to have a unique IP address (or set of
unique IP addresses in the case of multiple interfaces). The IARP
references all nodes/interfaces by their IP address.
* Does the protocol require link or neighbor status sensing
(if so, how?)
Yes. IARP proactively maintains local routing information
(routing zones) based on detected changes in neighbor status.
* Does the protocol have dependence on a central entity?
(if so, how?)
No. IARP is a fully distributed protocol.
Haas, Pearlman, Samar Expires January 2003 [Page iv]
INTERNET DRAFT Intrazone Routing Protocol (IARP) July 2002
* Does the protocol function reactively? (if so, how?)
No.
* Does the protocol function proactively? (if so, how?)
Yes. IARP proactively maintains LOCAL routing information
(routing zones) for each node. The routing zone information is
leveraged, through the bordercasting mechanism, to support
efficient global propagation of route queries.
* Does the protocol provide loop-free routing? (if so, how?)
Yes. IARP's link state proactive protocol is inherently
loop-free, although temporary loops may form while new link
state updates propagate through the routing zone.
* Does the protocol provide for sleep period operation? (if so, how?)
No. Sleep period operation is not addressed in this draft.
However, sleep period support can be included as needed.
* Does the protocol provide some form of security? (if so, how?)
No. It is assumed that security issues are adequately addressed
by the underlying protocols (IPsec, for example).
* Does the protocol provide support for utilizing multi-channel,
link-layer technologies? (if so, how?)
Yes. It is assumed that each node's network interface is
assigned a unique IP address.
Haas, Pearlman, Samar Expires January 2003 [Page v]
INTERNET DRAFT Intrazone Routing Protocol July 2002
1. Introduction
The design of ad hoc network routing protocols is influenced by link
instability (due to node mobility) and limitations in available
bandwidth and transmission power. Traditional wired networks use
proactive routing protocols, like OSPF [7] and RIP [15] to maintain
up-to-date routes to all networks nodes. More efficient proactive
routing protocols have been developed for ad hoc networks [1][5][8]
[9][14]. However, continuously tracking the frequent topology changes
in a practical ad hoc network can still produce an overwhelming amount
of control traffic. Even worse, most of the acquired route
information expires before it is ever used, making the proactive
control traffic a poor investment of bandwidth. In contrast, reactive
routing protocols [6][10][13] only initiate a global, query-based,
route discovery as routes are needed. While some delay is incurred in
route acquisition, the amount of overhead traffic is generally much
less than proactive routing protocols, because routing information is
not wasted. For this reason, reactive protocols are generally viewed
as being more suitable than proactive routing protocols for the power/
bandwidth limited mobile ad hoc network.
Although a global proactive routing protocol may overwhelm an ad hoc
network's resources, a LIMITED SCOPE proactive routing protocol can be
used to the advantage of a global reactive routing protocol. This
hybrid routing approach forms the basis for the Zone Routing Protocol
(ZRP) framework [4].
The cost for each node to proactively track the topology of its
surrounding R-hop neighborhood (routing zone) can be justified by
improved route discovery efficiency and more effective route
maintenance [11][12]. Routes to local destinations are immediately
available, avoiding route discoveries. When global route discovery is
needed, the routing zones can be used to efficiently guide route
queries outwards through bordercasting [2], rather than blindly
relaying queries from neighbor to neighbor. The proactive maintenance
of routing zones also helps improve the quality and survivability of
discovered routes, by making them more robust to changes in network
topology. Once routes have been discovered, routing zone offers
enhanced, real-time, route maintenance. Link failures can be bypassed
by multiple hop paths within the routing zone. Similarly, suboptimal
route segments can be identified and traffic re-routed along shorter
paths.
Within the context of the ZRP, we refer to the locally proactive
routing component as the Intrazone Routing Protocol (IARP). The IARP
is not a specific routing protocol. Rather, it is a family of
limited-depth, proactive, link state routing protocols. In this
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
convert an existing proactive routing protocol to an IARP.
Haas, Pearlman, Samar Expires January 2003 [Page 1]
INTERNET DRAFT Intrazone Routing Protocol July 2002
2. Routing Zones and Intrazone Routing
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
referred to as the zone radius. An example of a radius R = 2 hop
routing zone (for node A) is shown below.
+-----------------------------------------+
| +---+ |
| +---+ ---| F |-------| |
+---+ | +---+ --| C |--/ +---+ +---+ |
| G |-----| D |--/ +---+ | E | | Routing Zone of
+---+ | +---+ | +---+ +---+ | node A
| +---+ ---| B |-------| | (radius = 2 hops)
| | 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
two paths from A, one with length 2 hops and one with length 3 hops.
Since the minimum is less than or equal to 2, E is within A's routing
zone. Peripheral nodes are routing zone nodes whose minimum distance
to the node in question is equal exactly to the zone radius. In the
above figure, nodes D, F and E are A's peripheral nodes. These
peripheral nodes play an important role in efficient querying based on
bordercasting. We note that each node maintains its own routing zone.
As a result, routing zones of nearby nodes may overlap heavily.
Each node proactively tracks the topology of its routing zone through
an IntrAzone Routing Protocol (IARP). IARP is derived from globally
proactive link state routing protocols (for example, OSPF). The base
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
required modifications and example IARP are described in the next
sections.
Haas, Pearlman, Samar Expires January 2003 [Page 2]
INTERNET DRAFT Intrazone Routing Protocol July 2002
3. IARP Conversion Guidelines
Traditional proactive link state protocols can be modified to serve as
an IARP by limiting link state updates to the scope of the link
source's routing zone. The following guidelines can be used to
convert existing proactive link state routing protocols to an IARP:
- 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
R-1 hops by the link source. When a node receives the update
packet, it decrements the TTL value. When the TTL reaches 0, the
packet is discarded.
- If the base routing protocol performs link state table transfers
with new neighbors, link sources that are at least R-1 hops away
SHOULD be excluded from the transfer. This reduces the transmission
of redundant link state to neighbors closer to the link source, and
prevents transmission of out-of-zone link state to neighbors farther
from the link source.
- Nodes periodically update their link state tables, discarding link
sources that are farther than R-1 hops away.
- The IARP SHOULD support link state metrics that are consistent with
the metrics used by the Interzone Routing Protocol (IERP) [3].
These additional metrics allow the IERP to import IARP routes in
support of enhanced route maintenance (route repair, route
shortening, etc.).
4. Implementation Example - Timer Based Link State IARP
Nodes compute intrazone routes based on the proactively tracked link
state of each routing zone member. Each node periodically advertises
its link state (current set of neighbors and corresponding lists of
link metrics) throughout its routing zone. Nodes monitor their
own link state by means of a neighbor discovery protocol *.
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
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
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
state update packet is rebroadcasted.
* This IARP relies on the services of a separate protocol (referred to
here as the Neighbor Discovery Protocol (NDP)) to provide current
information about a node's neighbors. At the least, this informa-
tion must include the IP addresses of all the neighbors. IARP and
NDP can be configured to support supplemental link quality metrics.
Haas, Pearlman, Samar Expires January 2003 [Page 3]
INTERNET DRAFT Intrazone Routing Protocol July 2002
A. Packet Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State Seq Num | Zone Radius | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | RESERVED | Link Dest Cnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Destination 1 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Destination 1 Subnet Mask (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+--
| RESERVED | Metric Type | Metric Value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link
| RESERVED | Metric Type | Metric Value | Metrics
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RESERVED | Metric Type | Metric Value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+--
| |
| |
\| |/
\ /
\/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Destination n Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Destination n Subnet Mask (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+--
| RESERVED | Metric Type | Metric Value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link
| RESERVED | Metric Type | Metric Value | Metrics
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RESERVED | Metric Type | Metric Value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+--
Field Description:
* Link Source Address (node_id) (32 bits)
IP address of the reported link's source node.
* Link State Seq Num (unsigned int) (16 bits)
Sequence number used to track the link state history of
the Link Source node.
* Zone Radius (char) (8 bits)
Routing zone radius of the link's source node. Determines
the extent that link state information propagates.
Haas, Pearlman, Samar Expires January 2003 [Page 4]
INTERNET DRAFT Intrazone Routing Protocol July 2002
* TTL (char) (8 bits)
number of hops remaining until packet is to be discarded
* Link Dest Count (char) (8 bits)
number of link source's neighbors
* Link Destination Address (node_id) (n * 32 bits)
IP addresses of the link source's neighbor nodes.
* Node/Link Metrics (metric) (n*X * 32 bits)
This section of the packet is used to report the quality
of this link (or link source node).
* Metric Type (char) (8 bits)
Type of metric being reported
(based on pre-defined metric types)
* Metric Value (unsigned int) (16 bits)
Value of node / link metric specified by Metric Type
B. Data Structures
B.1 Routing Table
+-----------------------|--------------------------------+
| Dest | Subnet | Routes | Route |
| Addr | Mask | | Metrics |
| (node_id) | (node_id) | (node_id list) | (metric list) |
|-----------+-----------|----------------+---------------|
| | | | |
|-----------+-----------|----------------+---------------|
| | | | |
|-----------+-----------|----------------+---------------|
| | | | |
+-----------------------|--------------------------------+
B.2 Link State Table
+-----------|--------+-------+--------+------------------+
| Link | Zone | Link | Insert | Link State |
| Source | Radius | State | Time | Information |
| Addr | | ID | | |
| (node_id) | (int) | (int) | (int) | (ls_info list) |
+-----------|--------+-------+--------+------------------|
| | | | | |
|-----------|--------+-------+--------+------------------|
| | | | | |
|-----------|--------+-------+--------+------------------|
| | | | | |
+-----------|--------------------------------------------+
Haas, Pearlman, Samar Expires January 2003 [Page 5]
INTERNET DRAFT Intrazone Routing Protocol July 2002
## detail of (ls_info) data type
+---+---|---|
| | |||||
+---+---|---|
(a) (b) (c)
(a) Link Destination Address
(b) Link Destination Subnet Mask
(c) Link Metrics
C. Interfaces
C.1 Higher Layer (N/A)
C.2 Lower Layer (IP)
C.1.1 Deliver(packet)
Used by IP to deliver packet to IARP
C.3 NDP
C.3.1 Deliver()
Used by NDP to indicate an update in link state.
IARP retrieves the actual link state from NDP via
Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]).
D. State Machine
The IARP protocol consists of only one state (IDLE). Therefore,
no state transitions need to be specified. The IARP immediately
acts upon an event and then returns back to the IDLE state.
Notes: 1) X is used as a label for the node running this state
machine.
D.1
Event: Link state broadcast timer interrupt.
Action: X consults the neighbor discovery process for its
own link state (list of neighbors and corresponding
link metrics). X updates its Link State Table and
Routing Table accordingly. The TTL value is
initialized to R-1 hops (where R is the zone radius).
If the TTL is greater than 0 then X loads a link
state packet and broadcasts it to its neighbors.
Haas, Pearlman, Samar Expires January 2003 [Page 6]
INTERNET DRAFT Intrazone Routing Protocol July 2002
D.2
Event: An IARP link state packet is received.
Action: The link state update is recorded in the Link State
Table and the Routing Table is updated accordingly.
The TTL is decremented. If the TTL is greater
than 0 then X broadcasts the link state packet to
its neighbors.
D.3
Event: Link State Table refresh interrupt.
Action: Remove from the Link State Table any links that are
older than LINK_STATE_LIFETIME.
E. Pseudocode Implementation
We define two complimentary operations on packets:
extract(packet) and load(packet)
extract (packet)
extracts the fields of the IARP packet to the following
variables: {link_source, state_seq_num, radius, TTL,
link_dest[n], mask[n], link_metric[n][x]}
load (packet)
loads the values of the aforementioned variables into
the fields of the IARP packet.
E.1 Deliver(packet)
Deliver()
// This procedure handles both incoming link state packet and
// periodic advertisement of own link state
if(packet)
extract(packet);
else
{
link_source = MY_ID;
Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]);
TTL = R;
}
// Record link state information in Link State Table
add(Link_State_Table, link_source, link_dest, mask, radius,
link_metric, state_id, flags);
Haas, Pearlman, Samar Expires January 2003 [Page 7]
INTERNET DRAFT Intrazone Routing Protocol July 2002
// Recompute Routing Table
Routing_Table =compute_routes_from_links(Link_State_Table,node);
// Report Routing Table update to IERP
IARP_updated();
// Relay link state update only if link source lies inside of
// of routing zone (evaluated based on TTL value)
TTL--;
if(TTL > 0)
{
load(packet);
broadcast(packet);
}
else
discard(packet);
E.2 Refresh Link State Table args: ()
// Periodically remove from the Link State Table link states
// that are older than LINK_STATE_LIFETIME
for each link_source (BELONGING TO) Link_State_Table
{
insert_time = Link_State_Table[link_source].insert_time;
if(current_time()-insert_time > LINK_STATE_LIFETIME)
remove_from_table(Link_State_Table, link_source);
}
// Recompute Routing Table
Routing_Table = compute_routes_from_links(Link_State_Table,node);
// Report Routing Table update to IERP
IARP_updated();
Haas, Pearlman, Samar Expires January 2003 [Page 8]
INTERNET DRAFT Intrazone Routing Protocol July 2002
5. References
[1] Garcia-Luna-Aceves, J.J. and Spohn, M., "Efficient Routing in
Packet-Radio Networks Using Link-State Information,"
WCNC '99, September 1999.
[2] Haas, Z.J., Pearlman, M.R. and Samar, P., "Bordercast Resolution
Protocol (BRP)," IETF Internet Draft,
draft-ietf-manet-brp-02.txt, July 2002.
[3] Haas, Z.J., Pearlman, M.R. and Samar, P., "Interzone Routing
Protocol (IERP)," IETF Internet Draft,
draft-ietf-manet-ierp-02.txt, July 2002.
[4] Haas, Z.J., Pearlman, M.R. and Samar, P., "Zone Routing Protocol
(ZRP)," IETF Internet Draft, draft-ietf-manet-zrp-04.txt,
July 2002.
[5] Jacquet, P., Muhlethaler, P., Qayyum A., Laouiti A., Viennot L.,
and Clausen T., "Optimized Link State Routing Protocol,"
IETF Internet Draft, draft-ietf-manet-olsr-03.txt,
November 2000.
[6] Johnson, D.B. and Maltz, D.A., "Dynamic Source Routing in Ad-Hoc
Wireless Networks," in Mobile Computing, edited by T.
Imielinski and H. Korth, chapter 5, pp. 153-181,
Kluwer, 1996.
[7] Moy, J., "OSPF Version 2," INTERNET DRAFT STANDARD, RFC 2178,
July 1997.
[8] Murthy, S. and Garcia-Luna-Aceves, J.J., "An Efficient Routing
Protocol for Wireless Networks," MONET, vol. 1, no. 2,
pp. 183-197, October 1996.
[9] Ogier, R. "Efficient Routing Protocols for Packet-Radio Networks
Based on Tree Sharing," MoMUC '99, November 1999.
[10] Park, V.D. and Corson, M.S., "A Highly Adaptive Distributed
Routing Algorithm for Mobile Wireless Networks,"
IEEE INFOCOM'97, Kobe, Japan, 1997.
[11] Pearlman, M.R. and Haas, Z.J., "Determining the Optimal
Configuration for the Zone Routing Protocol," IEEE JSAC,
August, 1999.
[12] Pearlman, M.R., Haas, Z.J. and S.I. Mir, "Using Routing Zones to
Support Route Maintenance in Ad Hoc Networks,"
IEEE WCNC 2000, Chicago, IL, Sept. 2000.
Haas, Pearlman, Samar Expires January 2003 [Page 9]
INTERNET DRAFT Intrazone Routing Protocol July 2002
[13] Perkins, C.E. and Royer, E.M., "Ad Hoc On-Demand Distance
Vector Routing," IEEE WMCSA'99, New Orleans, LA, Feb. 1999
[14] Perkins, C.E. and Bhagwat, P., "Highly Dynamic
Destination-Sequenced Distance-Vector Routing (DSDV) for
Mobile Computers," ACM SIGCOMM, vol.24, no.4, October 1994.
[15] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
Haas, Pearlman, Samar Expires January 2003 [Page 10]
INTERNET DRAFT Intrazone Routing Protocol July 2002
Authors' Information
Zygmunt J. Haas
Wireless Networks Laboratory
323 Frank Rhodes Hall
School of Electrical & Computer Engineering
Cornell University
Ithaca, NY 14853
United States of America tel: (607) 255-3454, fax: (607) 255-9072
Email: haas@ece.cornell.edu
Marc R. Pearlman
389 Frank Rhodes Hall
School of Electrical & Computer Engineering
Cornell University
Ithaca, NY 14853
United States of America
tel: (607) 255-0236, fax: (607) 255-9072
Email: pearlman@ece.cornell.edu
Prince Samar
374 Frank Rhodes Hall
School of Electrical & Computer Engineering
Cornell University
Ithaca, NY 14853
United States of America
tel: (607) 255-9068, fax: (607) 255-9072
Email: samar@ece.cornell.edu
The MANET Working Group contacted through its chairs:
M. Scott Corson
Institute for Systems Research
University of Maryland College Park, MD 20742
(301) 405-6630
corson@isr.umd.edu
Joseph Macker
Information Technology Division
Naval Research Laboratory
Washington, DC 20375
(202) 767-2001
macker@itd.nrl.navy.mil
Haas, Pearlman, Samar Expires January 2003 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 19:02:02 |