[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/