Subject: A new draft

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Nov 2000 17:29:28 -0800

Hi,

I have submitted an Internet-Draft on a new
Multicast protocol for Ad Hoc networks. I 
have attached the draft to this mail. Any 
comments are welcome.

Thanks
Vijay

INTERNET-DRAFT                                     Vijay Devarapalli
draft-vijay-manet-mzr-00.txt                   Nokia Research Center
Expires May 2000                                       Ali A. Selcuk
                                                     Deepinder Sidhu
                                                           UMBC MCTR
                                                       November 2000

          MZR: A Multicast protocol for Mobile Ad Hoc networks
                     <draft-vijay-manet-mzr-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   This document proposes a new multicast protocol for Mobile Ad Hoc
   networks, called the Multicast routing protocol based on Zone Routing
   (MZR).  MZR is a source-initiated on-demand protocol, in which a
   multicast delivery tree is created using a concept based on the zone
   routing mechanism.  It belongs to the family of source-tree-based
   protocols, in which a delivery tree rooted at the source is created
   for each active multicast session.  MZR does not depend on any
   underlying unicast protocol for a global routing substructure.  The
   protocol's reaction to topological changes is restricted to a node's
   neighborhood and is not propagated throughout the network.

1. Introduction

Devarapalli, Selcuk, Sidhu                                      [Page 1]

INTERNET-DRAFT                                             November 2000

   In this document, we propose a new multicast protocol for Mobile Ad
   Hoc networks, called the Multicast routing protocol based on Zone
   Routing (MZR).  MZR is a source-tree-based, source-initiated, on-
   demand routing protocol, which is based on the concept of zone
   routing.

   The zone routing mechanism was originally described in the Zone
   Routing Protocol [6] developed by the Wireless Networks Lab at
   Cornell University.  It is a hybrid approach between the proactive
   and reactive routing protocols, where routing is proactive inside the
   zones (i.e., a unicast route is proactively maintained between every
   pair of nodes in a zone) and reactive between the zones (i.e., a
   route between two nodes in different zones is created when needed).
   This hybrid approach provides a balance between the efficient packet
   delivery of proactive routing and the low maintenance cost of
   reactive routing.

   MZR is a source-tree-based multicast routing protocol.  For each
   multicast session, identified by a <source_id, group_id> pair, a
   multicast delivery tree rooted at the source is created.  One
   advantage of the source-tree-based routing protocols over the shared-
   tree-based protocols is that they do not have a single point of
   failure like the group leader (or the rendezvous point) as in the
   shared-tree protocols.  This is significant when it comes to ad hoc
   networks because of the constant mobility of the nodes.  Network
   mobility further increases the overhead of group leader election.
   Also, in the source-tree approach traffic is evenly distributed over
   the network rather than being concentrated on the shared tree.

   The MZR protocol is source-initiated, which means that a multicast
   delivery tree is created when the source needs to send multicast data
   to its group members; and it is on-demand, which means that the
   delivery tree is created only when there is data to be sent to the
   group members.

   MZR does not depend on any underlying unicast routing protocol for
   its operation as other multicast protocols do [3,4,5].

2. Terminology

   This protocol specification uses conventional meanings as specified
   in RFC 2119 for capitalized words such as MUST, SHOULD, etc., to
   indicate requirement levels for various protocol features.  Other
   terminology used by the protocol are defined in this section.

      Node

Devarapalli, Selcuk, Sidhu                                      [Page 2]

INTERNET-DRAFT                                             November 2000

           Any device participating in the ad hoc network.

      Zone Routing

           A hybrid approach combining advantages of proactive
           and reactive protocols, where routing is proactive
           inside the zones and reactive between the zones.  [6]
           has more details.

      Zone
           A node's local neighborhood specified by a zone radius.

      Zone radius

           Radius of each node's zone in terms of network hops.

      Border Node

           A node which is on the periphery of a zone.  The distance
           from the border node to the zone's center (to which the
           zone belongs) in terms of network hops is equal to the
           zone radius.

      Upstream

           The next hop on the multicast source tree towards the source
           of the multicast session.

      Downstream

           The next hop in the multicast source tree away from the
           source of the multicast session.

      Proactive Routing Protocols

           Routing protocols which constantly exchange routing
           information to keep the routing tables at each node current
           and up-to-date.

      Reactive Routing Protocols

           Routing protocols which do an on-demand route discovery
           when data needs to be sent to a particular destination.

3. Route Tables

   MZR as a routing protocol uses the following data structures for its

Devarapalli, Selcuk, Sidhu                                      [Page 3]

INTERNET-DRAFT                                             November 2000

   operation.

3.1. Zone Routing Table

   Each mobile node participating in MZR maintains a Zone Routing Table,
   which contains unicast routes to all nodes inside its zone.  The
   routing information in this table is kept current by the proactive
   component running inside each zone.  Each route entry in the zone
   routing table has a timer associated with it.  If the timer expires,
   the corresponding entry is removed.  A zone route entry SHOULD
   contain atleast the following fields

    - Destination IP Address
    - Next Hop
    - Outgoing Interface
    - Hop Count
    - Lifetime timer
    - Routing Flags

3.2. Multicast Routing Table

   A multicast routing table is maintained at each node running MZR.  If
   a node were on a multicast tree, identified by a <source, group>
   pair, then it would have a multicast route entry corresponding to
   that tree.  Each multicast route entry has a timer associated with
   it, which is refreshed, whenever a node gets a refresh packet on the
   multicast tree.  The route entry has a pointer to the upstream node
   towards the source.  It also has a list of downstream nodes, to which
   data is replicated and forwarded.  Each multicast route entry SHOULD
   contain atleast the following fields.

    - Multicast Tree id <source, group>
    - Upstream node
    - List of downstream nodes
    - Lifetime timer
    - Routing Flags

3.3. Message Cache

   Each node MUST maintain a message cache for detecting duplicate data
   and control packets.  A Least Recently Used (LRU) scheme MAY be used
   to to prevent the cache from growing uncontrollably.

3.4. Neighbor Table

Devarapalli, Selcuk, Sidhu                                      [Page 4]

INTERNET-DRAFT                                             November 2000

   Each node SHOULD maintain a neighbor table where it stores the list
   of all its one hop neighbors with the corresponding interface address
   to reach them.

4. Protocol Description

   MZR has two parts to it.  A proactive protocol runs inside each zone,
   maintaining an up-to-date zone routing table at each node.  A
   reactive multicast tree creation is initiated when a source needs to
   send multicast data to its group members.  The following sections
   describe the protocol.

4.1 Zone Routing

   Existing routing protocols can be classified either as proactive or
   reactive protocols.  Both these classes of protocols suffer from
   disadvantages when it comes to ad hoc networks.  The Zone Routing
   approach is a hybrid approach [6], which tries to incorporate the
   advantages from both proactive and reactive protocols.  The original
   Zone Routing Protocol is described in [6].  It initiates the route
   determination procedure on-demand, but at limited search cost.  It
   limits the scope of the proactive procedure only to the node's zone.
   On the other hand, the global search for the destination (anywhere in
   the network), is done efficiently by querying only selected nodes in
   the network, as opposed to querying all the network nodes.  Each node
   in the network defines a zone around itself with the zone radius
   measured in terms of network hops.  A zone routing table containing
   unicast routes to all zone nodes is maintained at each node.  This
   table is kept current by running a proactive protocol inside each
   zone.  The important difference from pure proactive protocols is that
   the routing updates (carrying routing information) are restricted to
   the zone, and are not sent to the entire network.  For routes to
   destinations outside a node's zone, a reactive route discovery
   process is initiated.  The beauty of the zone routing protocol is the
   way in which the global flood search algorithm is implemented.
   Instead of flooding the route request packet throughout the network,
   a node selectively queries its border nodes for a route to a
   particular destination.  These border nodes first look in their zones
   for the destination.  If not found, they query their border nodes in
   turn.  The destination node eventually gets the route discovery
   packet and replies to the source.

   As the zone radius is significantly smaller than the network radius,
   the cost of learning the zones' topologies is a very small fraction
   of the cost required by a global proactive mechanism.  Zone routing
   is also much cheaper (in term of control traffic and congestion) and

Devarapalli, Selcuk, Sidhu                                      [Page 5]

INTERNET-DRAFT                                             November 2000

   faster than a global reactive route discovery mechanism, as the
   number of nodes queried in the process is [r_zone / r_network]^2 of
   the number of nodes queried by a global flooding process (r_zone is
   the zone radius and r_network is the network radius)[6].  MZR makes
   use of this querying mechanism for building a source-based multicast
   delivery tree.

4.2. Zone Construction

   Each mobile node participating in an ad hoc network constructs a zone
   around itself with a pre-configured zone radius.  A simplified
   distance vector protocol is implemented for creating zones and for
   maintaining a Zone Routing Table at each node.  Every node in the
   mobile ad hoc network periodically broadcasts an ADVERTISEMENT
   packet, identifying itself.  The propagation of the advertisement
   packets is restricted to a zone by setting the time-to-live (TTL)
   value of these packets to the zone radius.  The nodes that are within
   the transmission range of a node A pick up the advertisement packet
   sent by A.  Each node that receives an ADVERTISEMENT packet
   rebroadcasts it if the TTL of the packet is still valid.  Before the
   packet is rebroadcasted, the TTL of the packet is decremented by one.
   When a node B receives the advertisement packet from A, a route entry
   for A is created and stored in B's zone routing table.  The distance
   to A from B is set to the hop count in the advertisement packet and
   the next hop in the route entry is set to the node from which B
   received A's advertisement packet.  A soft state approach is followed
   to remove stale routes from the zone routing table.  Route entries
   expire if they are not periodically refreshed by advertisement
   packets from the corresponding nodes.

4.3. Zone Maintenance

   The zone routing table is kept up-to-date through the proactive
   protocol built on periodic advertisements.  Routes to destinations
   that moved away are removed when they expire.  Routes to new
   destinations are added to a node's zone routing table, when it
   receives advertisement packets from these destinations.  Also, the
   protocol's reaction to the changes in topology is localized to a
   zone.  Only the nodes within a zone are affected and only they need
   to update their zone routing tables.

   By looking at the zone routing table, a node can identify the
   interior zone nodes and the border nodes.  If the distance metric in
   a route entry is equal to the zone radius, the corresponding
   destination becomes a border node.  All the other nodes, whose route
   entries contain distances less than the zone radius become the

Devarapalli, Selcuk, Sidhu                                      [Page 6]

INTERNET-DRAFT                                             November 2000

   interior zone nodes. Each node SHOULD maintain a Neighbor Table,
   which contains all those nodes from which a node received
   ADVERTISEMENT packets with a hop count of one.

4.4. Multicast Tree Creation

   For each multicast session in the ad hoc network, a tree rooted at
   the source and identified by a <source, group> pair is created.
   Multicast group information is distributed separately and is not
   within the scope of this protocol.  Every node maintains a multicast
   routing table, which contains route entries corresponding to each
   active multicast session in the ad hoc network.  A multicast route
   entry is identified by the multicast session id, a <source, group>
   pair, and contains the IP address of the upstream node and a list of
   downstream nodes on the corresponding multicast tree.

   A multicast source initiates the creation of a multicast data
   delivery tree.  The tree creation is done in a two-stage process.
   The source initially tries to extend the tree inside its zone and
   then tries to extend the tree to the entire network.  The
   corresponding data packet and the subsequent data packets for the
   session are queued up for transmission until after the tree is
   created.  The source sends a TREE-CREATE to each zone node, through
   unicast routes obtained from the zone routing table.  A TREE-CREATE
   packet is uniquely identified by the corresponding session id.  The
   TTL of the TREE-CREATE packet is set to the zone radius and
   decremented by one each time it is forwarded.  When the TTL becomes
   zero, the packet is not forwarded further.  As the TREE-CREATE packet
   is propagated to a zone node, reverse route entries are created at
   each intermediate node.  The reverse routes are basically multicast
   route entries with the list of downstream nodes empty and the
   upstream node set to the node from which the TREE-CREATE packet was
   received.  These multicast route entries at the intermediate nodes
   are set to inactive when they are created.  When a zone node,
   interested in the multicast group session, receives the TREE-CREATE
   packet, it creates a multicast route entry and replies with a TREE-
   CREATE-ACK packet.  The TREE-CREATE-ACK is sent to the one hop
   neighbor which forwarded the TREE-CREATE packet.  The TREE-CREATE-ACK
   packet is finally sent back to the source through the reverse route
   created by the TREE-CREATE packet.  As the TREE-CREATE-ACK travels
   back to the source, the corresponding multicast route entry at each
   intermediate node is completed, activated and the node from which the
   TREE-CREATE-ACK was received is added to the list of the downstream
   nodes.  When the multicast route entry is activated at a node, it
   signals the creation of a new tree branch on which multicast data can
   be forwarded.  Even nodes, which are not interested in the multicast
   session, become members of the multicast tree if they provide

Devarapalli, Selcuk, Sidhu                                      [Page 7]

INTERNET-DRAFT                                             November 2000

   connectivity to downstream member nodes.  Through this mechanism, the
   source succeeds in creating a multicast tree, rooted at the source
   and extending throughout its zone.

   Once the source is done with its zone, it tries to extend the
   multicast tree to the entire network.  The source identifies all the
   border nodes for its zone and sends a TREE-PROPAGATE message to each
   one of them.  The TTL of the TREE-PROPAGATE packet is set to the zone
   radius and the packet is unicasted to the border nodes.  The TTL is
   decremented by one each time the packet is forwarded.  If the TTL
   becomes zero, the packet is not forwarded.  Each TREE-PROPAGATE
   packet is uniquely identified by the corresponding multicast session
   id.  A TREE-PROPAGATE packet basically tells a node to extend the
   multicast tree inside its zone.  An optimization would be for the
   source to indicate to the border nodes to propagate the tree by
   setting a flag in the TREE-CREATE packets sent to them.  This will
   eliminate the need for separate TREE-PROPAGATE messages.  When a
   border node receives a TREE-PROPAGATE packet, it creates a multicast
   route entry for the session, and then sends a TREE-CREATE packet to
   each of its zone nodes.  This is done, even if the border node is not
   interested in the multicast session.  If a node in the border node's
   zone is interested in the session, it replies to the border node with
   a TREE-CREATE-ACK.  The same procedure as described in the previous
   section is followed to create multicast route entries at each
   intermediate node.  The border node in turn sends a TREE-CREATE-ACK
   packet, unicasted to the source.  This basically extends the
   multicast tree into the border node's zone with a unicast link
   between the source and the border node and multiple tree branches
   within the border node's zone.  Once the border node is done with its
   zone nodes, it MUST send a TREE-PROPAGATE message to all its border
   nodes.  These border nodes in turn try to extend the multicast tree
   inside their zones.  This continues till every mobile node in the ad
   hoc network gets a TREE-CREATE packet corresponding to the multicast
   tree being created.

   A node can be a member of multiple routing zones at the same time
   because the routing zones heavily overlap.  It is possible that a
   node receives multiple TREE-CREATE and TREE-PROPAGATE messages,
   effectively flooding the network.  This is prevented by early
   detection and termination of duplicate TREE-PROPAGATE threads.

4.5. Routing Mechanism

   The source starts transmitting data packets to the group members once
   the multicast delivery tree is created.  Each tree member has a valid
   multicast route entry with the upstream node set to the node from
   which it receives data packets and a list of downstream nodes on the

Devarapalli, Selcuk, Sidhu                                      [Page 8]

INTERNET-DRAFT                                             November 2000

   tree.  When a node on the multicast tree receives a data packet from
   its upstream node, it replicates the data packet and sends a copy to
   each node in the downstream list.  A node SHOULD stop transmitting
   data packets to a downstream node, if the downstream node migrates
   and moves out of its transmission range.

4.6. Maintaining the Multicast Tree

   In a mobile ad hoc network, frequent changes in the network topology
   due to node mobility can cause tree links to break.  To ensure
   continuous multicast data delivery in the presence of node mobility,
   the multicast tree has to be reconfigured quickly.  The following
   sections describe two mechanisms, one to maintain up-to-date
   multicast routing information at each tree member node and another
   for repairing tree link breaks.

4.6.1 Tree Refresh

   Each route entry in a node's multicast routing table has a timer
   associated with it.  When the timer expires, the corresponding
   multicast route entry is removed.  This is necessary to remove stale
   multicast information.  To ensure that the multicast route entries do
   not expire for the duration of the multicast session, the source MUST
   send a TREE-REFRESH packet every REFRESH_INTERVAL down the tree.  The
   TREE-REFRESH packet is identified by a unique session id, a <source,
   group> pair.  When a tree member receives a refresh packet, it
   updates the timer for the corresponding multicast route entry, and
   sends the refresh packet to all the downstream nodes on the tree.
   The source stops sending refresh packets once it finishes sending all
   the data for the corresponding session.  This mechanism ensures that
   a data delivery tree is maintained as long as the session is active.
   The source SHOULD piggyback the refresh packet on any data packet
   whenever possible.

4.6.2. Reaction to Link Breaks

   The downstream nodes are responsible for detecting link breaks and
   reconfiguring the tree.  When a link to an upstream node breaks, the
   downstream node can easily detect this by looking at its neighbor
   table or the zone routing table.  A node (say, A) initiates branch
   reconstruction when it loses connection to its upstream node and is
   still interested in the ongoing multicast session.  The node A
   initiates a search for the multicast tree by using the zone routing
   mechanism.  It first sends JOIN packets to all its zone nodes.  Each
   JOIN is uniquely identified by the corresponding multicast session

Devarapalli, Selcuk, Sidhu                                      [Page 9]

INTERNET-DRAFT                                             November 2000

   id.  The TTL of the JOIN packet is set to the zone radius and is
   decremented by one each time it is forwarded.  The packet is not
   forwarded if the TTL becomes zero.  If any of the nodes in A's zone
   is on the multicast tree and has a valid multicast route entry, it
   replies to A with a JOIN- ACK packet.  The node, before replying with
   a JOIN-ACK packet adds the node from which it received the JOIN
   request to the list of downstream nodes in the corresponding
   multicast route entry.  Multicast route entries are also set up at
   the intermediate nodes.

   If node A does not get a reply from its zone nodes, it tries to
   propagate its join request through the entire network, hoping it
   could connect to the multicast tree through some node.  It sends a
   JOIN-PROPAGATE packet to all its border nodes.  JOIN-PROPAGATEs are
   restricted to the zone by setting the TTL to the zone radius.  These
   border nodes in turn send join requests to their zone nodes.  If they
   get a response from any of their zone nodes, they reply to A with a
   JOIN-ACK.  If not, they MUST send a JOIN-PROPAGATE packet to their
   border nodes.  Using this mechanism, node A's join request is
   propagated to the entire network.  If A does not get a reply at all,
   it assumes that the network has been partitioned and it cannot
   connect to the existing multicast tree.  The main advantage with this
   rejoin process is that the branch reconstruction is localized if A
   manages to find a multicast tree node within its zone.

4.7. Tree Prunes

   Group membership is dynamic, where nodes are free to join and leave
   the multicast session in progress.  When a tree member is no longer
   interested in the group, it sends an explicit PRUNE message to its
   upstream node, which in turn removes it from its list of downstream
   nodes.  If the downstream list becomes empty as a result of this
   action and the node itself is not interested in the group, it sends
   an explicit prune message to its upstream node.

4.8. Joining a multicast session

   Joining a multicast session is very similar to the mechanism in which
   a node which loses connection to its upstream node tries to rejoin
   the tree.

5. Message Formats

   This following sections describe the message formats for the messages
   used by MZR.  Note that MZR is a protocol under development.  The

Devarapalli, Selcuk, Sidhu                                     [Page 10]

INTERNET-DRAFT                                             November 2000

   following message formats are not final and could be changed in the
   next versions of this draft.

5.1 ADVERTISEMENT

   ADVERTISEMENT messages are used by the unicast routing protocol
   running inside each zone to maintain the zone routing table.  They
   are also used to maintain a neighbor table at each node containing
   all its one hop neighbors.  The format of the ADVERTISEMENT packet is
   as follows.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |    Reserved   |   Hop Count   |     TTL       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Source IP Address                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination IP Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Prev Hop IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type      1

      Hop Count
           Set to zero initially.  Incremented by one each time it is
           rebroadcasted.

      TTL (Time to Live)
           Set to the zone radius, so that the propagation of the
           packet is restricted to the zone.  Decremented by one each
           time it is broadcasted.

      Source IP Address
           The IP address of the node advertising itself.

      Destination IP Address
           Set to the Broadcast address.

      Prev Hop IP Address
           IP address of the node which last processed this packet.

5.2. TREE-CREATE

   TREE-CREATEs are unicast messages from a node propagating the tree to

Devarapalli, Selcuk, Sidhu                                     [Page 11]

INTERNET-DRAFT                                             November 2000

   the nodes belonging to its zone, informing them about a particular
   source tree being created.  The format of the TREE-CREATE message is
   as follows.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |P|          Reserved           |     TTL       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination IP Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Source IP Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Group IP Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Sequence Number                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type      2

      P         when set, the receiving node does a tree propagation
                too

      TTL (Time to Live)
           Set to the zone radius to restrict the propagation of the
           message to a zone.

      Destination IP Address
           Address of a zone node to which the TREE-CREATE is being
           unicasted to.

      Multicast Source IP Address & Multicast Group IP Address
           Uniquely identify the source tree being created

      Sequence Number
           Combined with the multicast source address and multicast
           group address, uniquely identifies the packet.

5.3. TREE-PROPAGATE

   TREE-PROPAGATEs are unicast messsages from a node propagating a
   source tree, to all its border nodes, telling them to propagate the
   source tree inside their respective zones.  The format is the same as
   TREE-CREATE message defined in section 5.2.  It can also be sent with
   TREE-CREATE message by setting the flag P.

      Type      3

Devarapalli, Selcuk, Sidhu                                     [Page 12]

INTERNET-DRAFT                                             November 2000

5.4. TREE-CREATE-ACK

   TREE-CREATE-ACK is sent when a node receives a TREE-CREATE message
   and it is interested in the corresponding multicast session.  The
   format of the message is as follows.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |            Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination IP Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Source IP Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Group IP Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type       4

      Destination IP Address
          IP address of the node to which the packet is being unicasted
          to.

      Multicast Source IP Address and Multicast Group IP Address
          Uniquely identify the multicast tree being created.

5.5. JOIN

   JOIN message is used by a node to join/rejoin an existing multicast
   session.  The format of the message is as follows.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |            Reserved           |     TTL       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination IP Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Source IP Address                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Source IP Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Multicast Group IP Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Sequence Number                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Devarapalli, Selcuk, Sidhu                                     [Page 13]

INTERNET-DRAFT                                             November 2000

      Type       5

      Destination IP Address
            IP address of the zone node to which the join packet is
            being unicasted to.

      Source IP Address
            IP Address of the node initiating the join/rejoin.

      Multicast Source IP Address & Multicast Group IP Address
            Uniquely identify a multicast session.

      Sequence Number
            Combined with the source IP address, uniquely identifies
            the packet.

5.6. JOIN-PROPAGATE

   This message is sent by a node trying to join or rejoin a multicast
   tree.  This is sent only when the node is unable to find a multicast
   member inside its zone.  It is unicasted to the border nodes. The
   format of the message is same as JOIN message (section 5.5) with the
   type field being different.

      Type       6

5.7. JOIN-ACK

   JOIN-ACK is sent by a node which is already on the multicast tree in
   reponse to a node which has sent an explicit JOIN message to it.  The
   format of the message is the same as TREE-CREATE-ACK message (section
   5.4) with the type field alone being different.

      Type       7

5.8. PRUNE

   The format of the message is the same as TREE-CREATE-ACK message
   (section 5.4) with the following fields having different semantics.

      Type       8

      Destination IP Address
           The address of the upstream node on the multicast tree.

Devarapalli, Selcuk, Sidhu                                     [Page 14]

INTERNET-DRAFT                                             November 2000

6. Configurable Parameters

   The following are some of the important parameters that would affect
   the performance of the protocol.  The default values for these
   parameters are specified in this section.  Each mobile node MAY
   modify these parameters for if required.

           Parameters              Default Values
           ----------              --------------
           ZONE_RADIUS             2
           REFRESH_INTERVAL        5 seconds
           ADVERTISE_INTERVAL      1 second
           ZONE_ROUTE_TIMEOUT      3 * ADVERTISE_INTERVAL

7. Security Considerations

   The security to any routing protocol, including MZR, requires a
   mechanism for the authentication of the routers (i.e., nodes) in the
   network.  The specifics of the routing security mechanism to be
   deployed would depend on the specifics of the underlying node
   authentication mechanism available (a public-key infrastructure, or a
   Kerboros-like secret-key authentication system, etc.).  At this
   point, MZR does not specify any security mechanism.

References

   [1]  S. Corson and J. Macker, Mobile Ad Hoc Networking (MANET):
        Routing Protocol Performance Issues and Evaluation
        Considerations, RFC 2501, January 1999

   [2]  Charles Perkins and Pravin Bhagwat, Highly dynamic Destination-
        Sequenced Distance-Vector routing for mobile computers,
        Proceedings of the SIGCOMM 1994, August 1994

   [3]  Elizabeth M. Royer and Charles Perkins, Multicast Operation of
        the Ad-Hoc On-Demand Distance Vector Routing Protocol,
        Proceedings of MobiCom'99, August 1999

   [4]  J.J Garcia-Luna-Aceves and E.L. Madruga, "The Core-Assisted Mesh
        Protocol", IEEE Journal on Selected Areas in Communication,
        vol. 17, no. 8, August 1999

   [5]  Bommaiah, Ethendranath, and et.al., AMRoute: Adhoc Multicast
        Routing Protocol, Intenet-Draft, draft-talpade-manet-amroute-
        00.txt, August 1998

Devarapalli, Selcuk, Sidhu                                     [Page 15]

INTERNET-DRAFT                                             November 2000

   [6]  Z.J. Haas and M.R. Pearlman, "The Zone Routing Protocol (ZRP)
        for Ad Hoc Networks," Internet Draft, draft-ietf-manet-zone-zrp-
        02.txt, June 1999

   [7]  J.J Garcia-Luna-Aceves and M. Spohn, Source-Tree Routing in
        Wireless Networks, Proceedings of ICNP xc699, November 1999

   [8]  Josh Broch, D. B. Johnson, and D. A. Maltz, "The Dynamic Source
        Routing Protocol for Mobile Ad Hoc Networks", Internet-Draft,
        draft-ietf-manet-dsr-03.txt, Oct 1999.

   [9]  Samir Das, Elizabeth Royer and Charlie Perkins, Ad Hoc On-Demand
        Distance Vector (AODV) Routing Internet-Draft, draft-ietf-
        manet-aodv-06.txt, July 2000

   [10]  Vincent D. Park and Scott Corson, A Highly Adaptive Distributed
        Routing Algorithm for Mobile Wireless Networks, Proceedings of
        INFOCOM 97, April 1997

   [11] S.-J. Lee and et. al., A Performance Comparison Study of Ad Hoc
        Wireless Multicast Protocols, Proceedings of IEEE INFOCOM 2000,
        March 2000.

   [12] S.-J. Lee, M. Gerla, and C.-C. Chiang, On-Demand Multicast
        Routing Protocol, Proceedings of IEEE WCNC'99, September 1999

   [13] C.-C. Chiang, M. Gerla and L. Zhang, Forwarding Group Multicast
        Protocol (FGMP) for Multihop, Mobile Wireless Networks, Baltzer
        Cluster Computing, Vol.1, no.2, 1998

   [14] Z.J. Haas and S. Tabrizi, "On Some Challenges and Design Choices
        in Ad-Hoc Communications," IEEE MILCOM'98, October 1998

   [15] Z.J. Haas and Mark Pearlman, Determining the Optimal
        configuration for the Zone Routing Protocol, IEEE JSAC, special
        issue on Ad Hoc Networks, vol. 17, no. 8, August 1999

   [16] C.W. Wu and Y.C. Tay, "AMRIS: A Multicast Protocol for Ad hoc
        Wireless Networks", Proceedings of IEEE Military Communications
        (MILCOM) conference, 1999.

Chair's Addresses

   The Working Group can be contacted via its current chairs:

      M. Scott Corson
      Institute for Systems Research

Devarapalli, Selcuk, Sidhu                                     [Page 16]

INTERNET-DRAFT                                             November 2000

      University of Maryland
      College Park, MD  20742
      USA
      Phone:  +1 301 405 6630
      Email:  [email-masked]

      Joseph Macker
      Information Technology Division
      Naval Research Laboratory
      Washington, DC  20375
      USA
      Phone:  +1 202 767 2001
      Email:  [email-masked]

Authors' Addresses:

      Vijay Devarapalli
      Communication Systems Laboratory
      Nokia Research Center
      313 Fairchild Drive
      Mountain View, CA 94043
      USA
      Phone:  +1 650 625 2320
      Email:  [email-masked]

      Ali A. Selcuk
      Maryland Center for Telecommunications Research
      University of Maryland Baltimore County
      1000 Hilltop Circle
      Baltimore, MD 21250
      USA
      Phone:  +1 410 455 3063
      Email:  [email-masked]

      Deepinder Sidhu
      Maryland Center for Telecommunications Research
      University of Maryland Baltimore County
      1000 Hilltop Circle
      Baltimore, MD 21250
      USA
      Phone:  +1 410 455 3028
      Email:  [email-masked]

Devarapalli, Selcuk, Sidhu                                     [Page 17]