[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 04                                                   
IETF MANET Working Group                                    Mario Gerla
INTERNET-DRAFT                                              Guangyu Pei
Expiration: May 1999                                        Sung-Ju Lee
                                  University of California, Los Angeles
                                                     Ching-Chuan Chiang
                                    Chung-Cheng Institute of Technology
                                                          November 1998


   On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks

                  <draft-ietf-manet-odmrp-00.txt>


Status of This Memo

   This document is a submission to the Mobile Ad-hoc Networks (manet)
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the Working Group mailing list at
   "manet@itd.nrl.navy.mil".  Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing
   protocol designed for ad-hoc networks with mobile hosts. ODMRP is
   a mesh-based, rather than a conventional tree-based, multicast
   scheme and uses a Forwarding Group concept (only a subset of nodes
   forwards the multicast packets via scoped flooding). It applies
   on-demand procedures to dynamically set up routes and maintain
   multicast group membership. ODMRP is well suited for ad-hoc
   wireless networks with mobile hosts where bandwidth is limited,
   topology changes frequently and rapidly, and power is constrained.



Gerla, Pei, Lee, and Chiang                                     [Page 1]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998


                                Contents

Status of This Memo                                                   1

Abstract                                                              1

 1. Introduction                                                      3

 2. Terminology                                                       4
     2.1. General Terms . . . . . . . . . . . . . . . . . . . . . .   4
     2.2. Specification Language  . . . . . . . . . . . . . . . . .   5

 3. Protocol Overview                                                 6
     3.1. Group Establishment and Route Setup . . . . . . . . . . .   6
           3.1.1. Mesh Creation . . . . . . . . . . . . . . . . . .   6
           3.1.2. Joining the Group . . . . . . . . . . . . . . . .   7
           3.1.3. Leaving the Group . . . . . . . . . . . . . . . .   8
           3.1.4. Timers  . . . . . . . . . . . . . . . . . . . . .   8
     3.2. Contents of Tables  . . . . . . . . . . . . . . . . . . .   9
           3.2.1. Member Table  . . . . . . . . . . . . . . . . . .   9
           3.2.2. Routing Table . . . . . . . . . . . . . . . . . .   9
           3.2.3. Message Cache . . . . . . . . . . . . . . . . . .   9
     3.3. Relationship with Unicast Routing Protocols . . . . . . .  10

 4. Packet and Table Formats                                         11
     4.1. Join Request Packet  . . . . . . . . . . . . . . . . . .   11
     4.2. Join Table Packet  . . . . . . . . . . . . . . . . . . .   12

 5. Operation                                                        14
     5.1. Forwarding Group Setup  . . . . . . . . . . . . . . . . .  14
           5.1.1. Originating a Join Request  . . . . . . . . . . .  14
           5.1.2. Processing a Join Request . . . . . . . . . . . .  14
           5.1.3. Originating a Join Table  . . . . . . . . . . . .  15
           5.1.4. Processing a Join Table . . . . . . . . . . . . .  15
     5.2. Multicast Data Packet Handling  . . . . . . . . . . . . .  15

 6. Configuration Parameters                                         16

 7. Protocol Applicability                                           17
  7.1. Networking Context . . . . . . . . . . . . . . . . . . . . .  17
  7.2. Protocol Characteristics and Mechanisms  . . . . . . . . . .  17

References                                                           19

Chair's Address                                                      20

Authors' Addresses                                                   20






Gerla, Pei, Lee, and Chiang                                    [Page 2]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



1. Introduction

   This document describes the On-Demand Multicast Routing Protocol
   (ODMRP) developed by the Wireless Adaptive Mobility (WAM) Lab [11]
   at UCLA. ODMRP applies "on-demand" routing techniques to avoid
   channel overhead and increase scalability. It uses the concept of
   "Forwarding Group," a set of nodes which is responsible for
   forwarding multicast data, to build a forwarding mesh for each
   multicast group. By establishing a mesh, drawbacks of multicast
   trees in mobile wireless networks (e.g., intermittent connectivity,
   traffic concentration, frequent tree reconfiguration, non-shortest
   path in a shared tree, etc.) are avoided. The forwarding group
   infrastructure reduces storage overhead and can handle a much
   looser connectivity among multicast members. The reduction of
   channel/storage overhead and the relaxed connectivity make ODMRP
   more scalable for large networks and more stable for mobile wireless
   networks. The following properties of ODMRP highlight its advantages
   as well as limitations.

   *   Low channel and storage overhead

   *   Usage of up-to-date and shortest routes

   *   Robustness to host mobility

   *   Maintenance and exploitation of multiple, redundant paths

   *   Scalability to large number of nodes

   *   Exploitation of the broadcast nature of wireless environments

   *   Independence from unicast routing protocols

   *   Ease of implementation

   *   Redundant forwarding due to mesh configuration

   *   Growth of transmitting table size when the number of group
       members increases

   The Forwarding Group Multicast Protocol (FGMP) was first introduced
   in [4] using a conventional routing structure (i.e., DSDV [8]). An
   extension of FGMP by incorporating on-demand scheme was proposed in
   [3]. ODMRP improves upon its predecessors by exploiting sender
   advertisement scheme which is more efficient than receiver
   advertisement scheme in a typical multicast environment where more
   receivers are present than multicast senders. Moreover, the sender
   advertisement fits better with unicast on-demand routing protocols.




Gerla, Pei, Lee, and Chiang                                    [Page 3]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



2. Terminology

2.1. General Terms

   This section defines terminology used in ODMRP that is not already
   defined in [7].

   node

      A device that implements IP.

   neighbor

      Nodes that are within the radio transmission range.

   forwarding group

       A group of nodes participating in multicast packet
       forwarding.

   multicast mesh

       The topology defined by the link connection between forwarding
       group members.

   join request

       The packet sent by multicast sources to establish/update
       group memberships and routes.

   join table

       The table broadcasted by each multicast receiver and forwarding
       node to establish/update group memberships and routes

   member table

       The table maintained by multicast receivers containing
       information of multicast sources for each multicast group it is
       associated with.

   routing table

      Table maintained by each node containing route information
      (e.g., next hop node) of existing active routes.







Gerla, Pei, Lee, and Chiang                                    [Page 4]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



2.2. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].















































Gerla, Pei, Lee, and Chiang                                    [Page 5]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



3. Protocol Overview

3.1. Group Establishment and Route Setup

3.1.1. Mesh Creation

   In ODMRP, group membership and multicast routes are setup and
   updated by the source on demand. While a multicast source has
   packets to send, it periodically floods a member advertising
   packet. This packet, called a "Join Request" packet (format will
   be shown in Section 4.1.), is broadcasted periodically as long as
   the source has packets to send. This periodic transmission refreshes
   the membership information and updates the route in the face of
   node movements. When a node receives a Join Request packet, it
   stores multicast group ID, source ID, and sequence number to its
   "Message Cache" to detect duplicates. Previous node ID is stored as
   well for a use which will be described later. If the Join Request
   packet is not a duplicate and the hop count does not exceed the
   Time-To-Live value, it is relayed.

   When the Join Request packet reaches a multicast receiver, the
   receiving node creates or updates the source entry in its Member
   Table, whose format will be shown in Section 3.2.1. Expired entries
   are deleted from the member table. A multicast receiver also sends
   periodic control packets. Namely, from its "Member Table," it builds
   a "Join Table" and sends it to its neighbors. Section 4.2 will show
   the format of the Join Table. When a node receives a Join Table, it
   checks if the next node ID of one of the entries matches its own ID.
   If it does, the node realizes that it is on the path to the source
   and thus is part of the forwarding group; it sets the
   FORWARDING_GROUP_FLAG. It then broadcasts its own Join Table built
   upon matched entries. The next node ID field is filled in by
   extracting the information from its Member Cache of received Join
   Request packets. Namely, the next node ID is set to the previous
   node ID field of the Join Request that matches multicast group ID
   and sender ID of the Join Table just received. This way, the Join
   Table is propagated by each forward group member until it
   reaches the multicast source via the shortest delay path. This
   process sets up (or updates) the route from source to each receiver
   and builds a mesh of nodes, the forwarding group.












Gerla, Pei, Lee, and Chiang                                    [Page 6]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



   +--+       +--+       +--+
   |S1|-------|I1|-------|R1|
   +--+\      +--+      /+--+  Join Table of Node R1 and Node I1
        \              /        +----------------+  +----------------+
         \            /         |Sender|Next Node|  |Sender|Next Node|
          \          /          |------+---------|  |------+---------|
           \        /           |  S1  |    I1   |  |  S1  |    S1   |
            \      /            |------+---------|  +----------------+
   +--+      \+--+/      +--+   |  S2  |    I2   |
   |S2|-------|I2|-------|R2|   +----------------+
   +--+       +--+       +--+



   Let us consider the above figure as an example of Join Table
   forwarding process. Nodes S1 and S2 are multicast sources, and nodes
   R1 and R2 are multicast receivers. Node R2 sends its Join Table to
   both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to
   S2 via I2. When receivers send their Join Tables to next hop nodes,
   an intermediate node I1 sets the FORWARDING_GROUP_FLAG and builds
   its own Join Table since there is a next node ID entry in the
   received Join Table that matches its ID. Note that I1 has an entry
   for sender S1 but not for S2 because the next node ID for S2 in the
   join table received from R1 is not I1. In the meanwhile, node I2
   sets the FORWARDING_GROUP_FLAG, constructs its own Join Table and
   sends it to its neighbors. Note that I2 broadcasts the join table
   only once even though it receives two Join Tables from the
   receivers. This is because the second table arrival carries no new
   source information. Channel overhead is thus reduced dramatically in
   cases where numerous multicast receivers share the same links to the
   source.

   After this group establishment and route setup process, a multicast
   source can transmit packets to receivers via selected routes and
   forwarding groups. The periodic control packets are sent as long as
   data packets to send are still present. When receiving the multicast
   data packet, a node forwards it only when it is not a duplicate and
   the setting of FORWARDING_GROUP_FLAG has not expired. This procedure
   minimizes the traffic overhead and prevents sending packets through
   stale routes.

3.1.2. Joining the Group

   If a node wants to join a particular multicast group as a source,
   it simply sends the Join Request packet when it has data packets to
   send. Thereafter, this packet is periodically sent as long as the
   node has data to multicast.





Gerla, Pei, Lee, and Chiang                                    [Page 7]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



   If a node wants to join a particular multicast group as a receiver,
   it needs to send Join Table to its neighbors periodically as well as
   every time its Member Table is modified/updated.

3.1.3. Leaving the Group

   No explicit control packet needs to be sent to leave the group. If a
   multicast source wants to leave the group, it simply stops sending
   any Join Request packet since it doesn't have any multicast data to
   send to the group.

   If a receiver no longer wants to receive from a particular multicast
   group, it removes the corresponding entries from its Member Table
   and does not forward the Join Table for that group.

3.1.4. Timers

    ODMRP uses a soft state approach for maintaining routes and
    multicast/forwarding group members. The refresh and timeout
    intervals used in ODMRP are defined as follows:

    RTE_TIMEOUT

       Timeout interval for Routing Table entries (RTE).

    MEM_REFRESH

       Refresh period of transmitting Join Request by a source when it
       has data packets to send.

    MEM_TIMEOUT

       Timeout interval of Member Table entries.

    JT_REFRESH

       Refresh period of sending Join Tables when there are entries in
       Member Table.

    FG_TIMEOUT

       Timeout interval of FORWARDING_GROUP_FLAG by each forwarding
       group members.









Gerla, Pei, Lee, and Chiang                                    [Page 8]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



    Sender advertising packets (Join Requests) are issued by source
    members every MEM_REFRESH interval when there are data packets to
    send; entries in the Member Table which have not been refreshed
    (did not receive Join Request before MEM_TIMEOUT) are removed.
    Entries in routing table are deleted if the routes are not used in
    RTE_TIMEOUT period. Join Tables are issued every JT_REFRESH when
    valid entries exist in the Member Table. Any update of the member
    table triggers the transmission of a Join Table as well. If
    forwarding nodes are not refreshed (by receiving Join Tables)
    within FG_TIMEOUT, they are demoted to non-forwarding nodes. These
    parameters MUST be set to proper values in order to adapt to a
    rapidly changing topology.

3.2. Contents of Tables

   Nodes running ODMRP are required to maintain the following tables.
   These tables MAY be implemented in any format, but MUST include the
   fields specified in this document.

3.2.1. Member Table

   Member table needs to be maintained by multicast receivers. For
   each multicast group they are participating, they should store
   multicast source IP address and the timestamp value to detect the
   expired source. If no Join Request is received from a source in the
   Member Table within MEM_TIMEOUT, it is removed from the Member
   Table.

3.2.2. Routing Table

   A routing table is created on demand and is maintained by each node.
   There is no specific routing table format required by ODMRP.
   However, the routing table MUST include the next hop address for
   each destination maintained in the routing table.

3.2.3. Message Cache

   Message Cache is maintained by each node to detect duplicates and to
   provide next hop information of routes. When a node receives a new
   Join Request, it MUST insert the following information to the
   Message Cache:

   * Multicast Group ID

   * Source Address

   * Sequence Number

   * Previous Hop Address



Gerla, Pei, Lee, and Chiang                                    [Page 9]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



3.3. Relationship with Unicast Routing Protocols

   ODMRP can coexist with any unicast routing protocol since it finds
   its own routes independently. From the point of view of scalability
   and mobility support, it makes most sense to use ODMRP in
   conjunction with on-demand unicast routing protocols such as
   DSR [2], ZRP [5], TORA [6], AODV [9], and ABR [10]. If, on the other
   hand, a conventional table driven unicast routing protocol is used,
   then, a conventional, tree based multicast protocol may be adequate.











































Gerla, Pei, Lee, and Chiang                                   [Page 10]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



4. Packet and Table Formats

4.1. Join Request Packet

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Ver  | Type  |   Reserved    |  Time To Live |   Hop Count   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Multicast Group IP Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Source IP Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Previous Hop IP Address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Ver

        ODMRP version number.

    Type

        01; ODMRP source Join Request.

    Reserved

        Sent as 0; ignored on reception.

    Time To Live

        Maximum number of hops this packet can traverse.

    Hop Count

        The number of hops traveled so far by this packet.

    Multicast Group IP Address

        The IP address of the multicast group.

    Sequence Number

        The sequence number assigned by the source to uniquely
        identify the packet.






Gerla, Pei, Lee, and Chiang                                   [Page 11]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



    Source IP Address

        The IP address of the node originating the packet.

    Previous Hop IP Address

        The IP address of the last node that has processed this packet.


4.2. Join Table Packet

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Ver  | Type  |    Count      |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Multicast Group IP Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Sender IP Address [1]                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Next Hop IP Address [1]                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               :                               |
    |                               :                               |
    |                               :                               |
    |                               :                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Sender IP Address [n]                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Next Hop IP Address [n]                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Ver

        ODMRP version number.

    Type

        02; ODMRP receiver Join Table.

    Count

        Number of (Sender IP Address, Next Hop IP Address)
        combinations.








Gerla, Pei, Lee, and Chiang                                   [Page 12]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



    Reserved

        Sent as 0; ignored on reception.

    Multicast Group IP address

        The IP address of the multicast group.

    Sender IP Address [1..n]

        The IP addresses of the sources of this multicast group.

    Next Hop IP Address [1..n]

        The IP addresses of next nodes that this packet is target to.





































Gerla, Pei, Lee, and Chiang                                   [Page 13]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



5. Operation

5.1. Forwarding Group Setup

5.1.1. Originating a Join Request

    When a multicast source has data packets to send, it periodically
    originates "Join Request" packets every MEM_REFRESH interval. The
    Type field MUST be set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE,
    but SHOULD be adjusted based on network size and network diameter.
    Sequence number MUST be large enough to prevent wraparound
    ambiguity, and Hop Count is initially set to zero. The source puts
    its IP address in the Source IP Address and Last Hop IP Address
    field. Note that Join Request packet is not sent when a source does
    not have any multicast packets to send.

5.1.2. Processing a Join Request

    When a node receives a Join Request packet:

    1. Check if it is a duplicate by comparing the (Source IP Address,
       Sequence Number) combination with the  entries in Message Cache.
       If duplicate, then discard the packet. DONE.

    2. If it is not a duplicate, insert an entry into Message Cache
       with the information of the received packet (i.e., Multicast
       Group IP Address, Sequence Number, Source IP Address, and
       Previous Hop IP Address).

    3. If the node is a receiver member of the multicast group, then
       insert/update the information into the Member Table and
       originate a Join Table packet (see Section 5.1.3.).

    4. Increase the Hop Count field by 1.

    5. If the Hop Count field value is equal to or larger than TTL,
       then discard the packet. DONE.

    6. If the Hop Count field value is less than TTL, then set the
       node's IP Address into Last Hop IP Address field and broadcast.
       DONE.











Gerla, Pei, Lee, and Chiang                                   [Page 14]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



5.1.3. Originating a Join Table

    A multicast receiver broadcasts a "Join Table" packet every
    JT_REFRESH as long as there are any entries in its Member Table.
    The transmission of Join Table is also triggered by the update of
    its Member Table. Each Sender IP Address and Next Hop IP Address
    pairs of a multicast group are contained in the Join Table packet.
    Next Hop IP Address information can be obtained from the Message
    Cache entries(Last Hop IP Address field of the Join Request
    packet).

5.1.4. Processing a Join Table

    When a Join Table is received:

    1. The node looks up the Next Hop IP Address field of the received
       Join Table entries. If no entries match the node's IP Address,
       do nothing. DONE.

    2. If one or more entries coincide with the node's IP Address, set
       the FORWARDING_GROUP_FLAG and build its own Join Table. Next Hop
       IP Address information can be obtained from the Join Cache
       entries (Last Hop IP Address field of the Join Request packet).

    3. Broadcast the Join Table packet.


5.2. Multicast Data Packet Handling

    Multicast sources broadcast the Data whenever they have packets
    to send. Nodes relay data packets only if the packet is not a
    duplicate and the FORWARDING_GROUP_FLAG has not expired.




















Gerla, Pei, Lee, and Chiang                                   [Page 15]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



6. Configuration Parameters

   This section specifies default values associated with ODMRP
   operation. Note that some of the values SHOULD be adjusted to nodes'
   mobility speed and network size.


   FG_TIMEOUT                               480    milliseconds

   JT_REFRESH                               160    milliseconds

   MEM_REFRESH                              400    milliseconds

   MEM_TIMEOUT                              960    milliseconds

   RTE_TIMEOUT                              960    milliseconds

   RT_DISCV_TIMEOUT                          30    seconds

   TIME_TO_LIVE_VALUE                        32    hops
































Gerla, Pei, Lee, and Chiang                                   [Page 16]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



7. Protocol Applicability

7.1. Networking Context

   ODMRP is best suited for mobile ad hoc wireless networks.

7.2. Protocol Characteristics and Mechanisms

   * Does the protocol provide support for unidirectional links? (if so,
   how?)

      - No. We assume bidirectional links.

   * 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 periodic messages are sent by multicast sources as
        long as there exist multicast packets to send. Multicast
        receivers also send periodic messages while there are multicast
        source entries in the Member Table.

   * Does the protocol require the use of reliable or sequenced packet
   delivery? (if so, how?)

      - No.

   * Does the protocol provide support for routing through a multi-
   technology routing fabric? (if so, how?)

      - No.

   * Does the protocol provide support for multiple hosts per router?
   (if so, how?)

      - No. In this document, we assume each mobile host is combined
        with a router, sharing the same IP address. It is possible,
        however, to extend the protocol to handle multiple hosts per
        router.





Gerla, Pei, Lee, and Chiang                                   [Page 17]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



   * Does the protocol support the IP addressing architecture? (if so,
   how?)

      - Yes. The message contains host IP address as its identification.

   * Does the protocol require link or neighbor status sensing (if so,
   how?)

      - No.

   * Does the protocol have dependence on a central entity? (if so,
   how?)

      - No.

   * Does the protocol function reactively? (if so, how?)

      - Yes. For example, the source creates and maintains routes and
        multicast group membership only when it has data packets to
        send.

   * Does the protocol function proactively? (if so, how?)

      - No.

   * Does the protocol provide loop-free routing? (if so, how?)

      - Yes. By using the Message Cache, duplicate packets are detected
        and packets can only go through the loop-free route.

   * Does the protocol provide for sleep period operation? (if so, how?)

      - No.

   * Does the protocol provide some form of security? (if so, how?)

      - TBD. The work is in progress.

   * Does the protocol provide support for utilizing multi-channel,
   link-layer technologies? (if so, how?)

      - This document assumed an arbitrary single channel link-layer
        protocol. The protocol can work with any MAC and link-layer
        technology. It can also support multi-channel link-layer
        technology (e.g., separate channels for data, control packets,
        etc.).






Gerla, Pei, Lee, and Chiang                                   [Page 18]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



References

    [1] Scott Bradner.  Key words for use in RFCs to Indicate
        Requirement Levels.  RFC 2119, March 1997.

    [2] Josh Broch, David B. Johnson, and David A. Maltz.  The Dynamic
        Source Routing Protocol for Mobile Ad Hoc Networks.
        Internet-Draft, draft-ietf-manet-dsr-00.txt, March 1998. Work
        in progress.

    [3] Ching-Chuan Chiang and Mario Gerla.  On-Demand Multicast in
        Mobile Wireless Networks.  In proceedings of IEEE ICNP'98,
        Austin, TX, October 1998. pp. 262-270.

    [4] Ching-Chuan Chiang, Mario Gerla, and Lixia Zhang.  Forwarding
        Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless
        Networks.  ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998.

    [5] Zygmunt J. Haas and Marc R. Pearlman.  The Zone Routing
        Protocol (ZRP) for Ad Hoc Networks. Internet-Draft,
        draft-ietf-manet-zone-zrp-01.txt, August 1998. Work in
        progress.

    [6] Vincent D. Park and M. Scott Corson.  Temporally-Ordered
        Routing Algorithm (TORA) Version 1 - Functional Specification.
        Internet-Draft, draft-ietf-manet-tora-spec-01.txt, August 1998.
        Work in progress.

    [7] Charles E. Perkins.  Mobile Ad Hoc Networking Terminology.
        Internet-Draft, draft-ietf-manet-term-00.txt, October 1997.
        Work in progress.

    [8] Charles E. Perkins and Pravin Bhagwat.  Highly Dynamic
        Destination-Sequenced Distance-Vector Routing (DSDV) for
        Mobile Computers. In proceedings of ACM SIGCOMM'94, London, UK,
        September 1994, pp. 234-244.

    [9] Charles E. Perkins and Elizabeth M. Royer.  Ad Hoc On Demand
        Distance Vector (AODV) Routing. Internet-Draft,
        draft-ietf-manet-aodv-01.txt, August 1998. Work in progress.

   [10] Chai-Keong Toh.  Associativity-Based Routing for Ad-Hoc Mobile
        Networks. Wireless Personal Communications Journal, Special
        Issue on Mobile Networking and Computing Systems, Kluwer
        Academic Publishers, vol. 4, no. 2, March 1997, pp. 103-139.

   [11] UCLA Wireless Adaptive Mobility (WAM) Laboratory.
        http://www.cs.ucla.edu/NRL/wireless




Gerla, Pei, Lee, and Chiang                                   [Page 19]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



Chair's Address



   The Working Group can be contacted via its current chairs:

        M. Scott Corson
        Institute for Systems Research
        University of Maryland
        College Park, MD  20742
        USA

        Phone:  +1 301 405-6630
        Email:  corson@isr.umd.edu


        Joseph Macker
        Information Technology Division
        Naval Research Laboratory
        Washington, DC  20375
        USA

        Phone:  +1 202 767-2001
        Email:  macker@itd.nrl.navy.mil



Authors' Addresses


   Questions about this document can also be directed to the authors:

        Mario Gerla
        405 Hilgard Ave.
        Computer Science Department
        University of California
        Los Angeles, CA  90095
        USA

        Phone:  +1 310 825-4367
        Fax:    +1 310 825-2273
        Email:  gerla@cs.ucla.edu










Gerla, Pei, Lee, and Chiang                                   [Page 20]


INTERNET-DRAFT    On-Demand Multicast Routing Protocol    November 1998



        Guangyu Pei
        405 Hilgard Ave.
        Computer Science Department
        University of California
        Los Angeles, CA  90095
        USA

        Phone:  +1 310 825-1888
        Email:  pei@cs.ucla.edu


        Sung-Ju Lee
        405 Hilgard Ave.
        Computer Science Department
        University of California
        Los Angeles, CA  90095
        USA

        Phone:  +1 310 206-8589
        Email:  sjlee@cs.ucla.edu


        Ching-Chuang Chiang
        Computer Science Department
        Chung-Cheng Institute of Technology
        Ta-Shi, TaoYuan 335
        Taiwan

        Phone:  +886 3 380-9331
        Fax:    +886 3 389-4770
        Email:  ccchiang@ccit.edu.tw





















Gerla, Pei, Lee, and Chiang                                   [Page 21]