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

Versions: 00

IETF MANET Working Group                             Jorjeta G. Jetcheva
INTERNET-DRAFT                                Carnegie Mellon University
                                                        David B. Johnson
                                                         Rice University
                                                            13 July 2001


         The Adaptive Demand-Driven Multicast Routing Protocol
                   for Mobile Ad Hoc Networks (ADMR)

                     <draft-ietf-manet-admr-00.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 that 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.

   This Internet-Draft is a submission to the IETF Mobile Ad Hoc
   Networks (MANET) Working Group.  Comments on this draft may be sent
   to the Working Group at manet@itd.nrl.navy.mil, or may be sent
   directly to the authors.

















Jetcheva and Johnson          Expires 13 January 2002           [Page i]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


Abstract

   The Adaptive Demand-Driven Multicast Routing protocol (ADMR) has been
   designed specifically for use in the ad hoc network environment.
   Multicast routing state in ADMR is dynamically established and
   maintained only for groups that have at least one receiver and
   one active sender in the network.  Each multicast data packet is
   forwarded along the shortest-delay path with multicast forwarding
   state, from the sender to the receivers.  Senders are not required
   to announce their intention to start or stop sending data to the
   group, or to join the group to which they wish to send.  Receivers
   dynamically adapt to the sending pattern of senders and mobility in
   the network in order to efficiently balance overhead and maintenance
   of the multicast routing state as nodes in the network move or as
   wireless transmission conditions in the network change.  State for
   groups whose senders have become inactive or whose receivers have
   left the group is expired automatically without the need for control
   signaling or application-level notification at the source.  ADMR
   also detects when mobility in the network is too high to efficiently
   maintain multicast routing state, and instead reverts to flooding
   for a short period of time it determines that the high mobility has
   subsided.































Jetcheva and Johnson          Expires 13 January 2002          [Page ii]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001




                                Contents



Status of This Memo                                                    i

Abstract                                                              ii

 1. Introduction                                                       1

 2. Assumptions                                                        3

 3. Terminology                                                        4
     3.1. General Terms . . . . . . . . . . . . . . . . . . . . . .    4
     3.2. Specification Language  . . . . . . . . . . . . . . . . .    5

 4. ADMR Protocol Overview                                             6
     4.1. Multicast State Setup . . . . . . . . . . . . . . . . . .    6
           4.1.1. Multicast Receiver Discovery  . . . . . . . . . .    6
           4.1.2. Multicast Source Discovery  . . . . . . . . . . .    8
     4.2. Multicast Packet Forwarding . . . . . . . . . . . . . . .    9
     4.3. Multicast State Maintenance . . . . . . . . . . . . . . .   10
           4.3.1. Link Break Detection  . . . . . . . . . . . . . .   11
           4.3.2. Link Break Repair . . . . . . . . . . . . . . . .   12
     4.4. Reaction to Mobility  . . . . . . . . . . . . . . . . . .   14
     4.5. State Expiration  . . . . . . . . . . . . . . . . . . . .   15

 5. Conceptual Data Structures                                        16
     5.1. Sender Table  . . . . . . . . . . . . . . . . . . . . . .   16
     5.2. Membership Table  . . . . . . . . . . . . . . . . . . . .   17
     5.3. Node Table  . . . . . . . . . . . . . . . . . . . . . . .   17
     5.4. Send Buffer . . . . . . . . . . . . . . . . . . . . . . .   18

 6. ADMR Header Format                                                19
     6.1. Fixed Portion of ADMR Header  . . . . . . . . . . . . . .   20
     6.2. Source Information Option . . . . . . . . . . . . . . . .   22
     6.3. Receiver Join Option  . . . . . . . . . . . . . . . . . .   25
     6.4. Multicast Solicitation Option . . . . . . . . . . . . . .   27
     6.5. Repair Notification Option  . . . . . . . . . . . . . . .   29
     6.6. Reconnect Option  . . . . . . . . . . . . . . . . . . . .   31
     6.7. Reconnect Reply Option  . . . . . . . . . . . . . . . . .   33
     6.8. Multicast Group Address Option  . . . . . . . . . . . . .   34
     6.9. Multicast Sender Address Option . . . . . . . . . . . . .   35
    6.10. Pad1 Option . . . . . . . . . . . . . . . . . . . . . . .   36
    6.11. PadN Option . . . . . . . . . . . . . . . . . . . . . . .   37

 7. Detailed Operation                                                38
     7.1. General Packet Processing . . . . . . . . . . . . . . . .   38



Jetcheva and Johnson         Expires 13 January 2002          [Page iii]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


           7.1.1. Originating a Packet  . . . . . . . . . . . . . .   38
           7.1.2. Adding an ADMR Header to a Packet . . . . . . . .   39
           7.1.3. Receiving a Packet  . . . . . . . . . . . . . . .   40
     7.2. Multicast Receiver Discovery  . . . . . . . . . . . . . .   41
           7.2.1. Originating a Receiver Discovery Keep-Alive . . .   41
           7.2.2. Processing a Received Receiver Discovery
                          Keep-Alive . . . . . . . . . . . . . . . .  42
           7.2.3. Originating a Receiver Join . . . . . . . . . . .   43
           7.2.4. Processing a Receiver Join  . . . . . . . . . . .   44
     7.3. Multicast Source Discovery  . . . . . . . . . . . . . . .   45
           7.3.1. Originating a Multicast Solicitation  . . . . . .   45
           7.3.2. Processing a Multicast Solicitation . . . . . . .   46
           7.3.3. Originating a Unicast Keep-Alive  . . . . . . . .   47
           7.3.4. Processing a Unicast Keep-Alive . . . . . . . . .   48
     7.4. Multicast State Maintenance . . . . . . . . . . . . . . .   49
           7.4.1. Originating a Maintenance Keep-Alive  . . . . . .   49
           7.4.2. Processing a Maintenance Keep-Alive . . . . . . .   50
           7.4.3. Originating a Repair Notification . . . . . . . .   50
           7.4.4. Processing a Repair Notification  . . . . . . . .   51
           7.4.5. Originating a Reconnect . . . . . . . . . . . . .   52
           7.4.6. Processing a Reconnect  . . . . . . . . . . . . .   53
           7.4.7. Originating a Reconnect Reply . . . . . . . . . .   53
           7.4.8. Processing a Reconnect Reply  . . . . . . . . . .   54
           7.4.9. Originating a Multicast Group Option  . . . . . .   54
          7.4.10. Processing a Multicast Group Option . . . . . . .   55
          7.4.11. Originating a Multicast Sender Address Option . .   55
          7.4.12. Processing a Multicast Sender Address Option  . .   55

 8. Constants                                                         56

 9. IANA Considerations                                               58

10. Security Considerations                                           59

Acknowledgments                                                       60

References                                                            61

Chair's Address                                                       62

Authors' Addresses                                                    63












Jetcheva and Johnson          Expires 13 January 2002          [Page iv]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


1. Introduction

   The Adaptive Demand-Driven Multicast Routing protocol (ADMR) enables
   efficient multicast data packet delivery in wireless ad hoc networks.
   The protocol does not require any existing infrastructure or
   preconfiguration to operate.  It discovers "multi-hop" routes between
   multicast receivers for a group and senders that have data to send
   to that group, and maintains connectivity between these senders and
   receivers in the face of route disconnection caused by effects such
   as node motion, propagation phenomena, or wireless interference.

   ADMR conforms to the standard IP multicast API in which any node
   can send data to any multicast group without explicitly announcing
   its intention to send or to stop sending, and any node can join or
   leave a multicast group at any time.  In addition, ADMR supports
   the source-specific multicast API [3], allowing receivers to join
   source-specific groups.

   The design of ADMR has been guided by the following requirements:
   low overhead and battery consumption, active link break detection
   and maintenance, correct and efficient operation in the presence of
   control packet loss, and adaptiveness to change in network conditions
   such as mobility or packet loss.

   The operation of ADMR is driven by the presence of data packets being
   sent and by changes in network conditions, rather than by continuous
   or periodic background activity of the protocol.  The protocol tunes
   its behavior in response to changing mobility in the network without
   requiring GPS or other external positioning information.

   In ADMR, source-based forwarding trees for a group are created
   whenever there is at least one source and one receiver for the group
   active in the network.  ADMR monitors the traffic pattern of the
   multicast source application, and based on that can detect link
   breaks in the tree, as well as sources that have become inactive and
   will not be sending any more data.  In the former case, the protocol
   initiates local repair procedures, and then global repair if the
   local repair fails.  In the latter case, multicast forwarding state
   is silently expired without the need to send an explicit shutdown
   message.  To enable monitoring for link breaks in the multicast
   forwarding tree when the source is not sending data temporarily, ADMR
   sends a limited number of keep-alives at increasing inter-packet
   times.  To balance the cost of the keep-alives against that of
   maintaining the multicast routing state, when the source has not
   sent any data for a period of time that constitutes a significant
   deviation from its sending pattern, the keep-alives stop and the
   entire tree silently expires.  A significant deviation from a
   source's sending pattern is an indication that the source is likely
   to be inactive for a while, in which case it would be wasteful to
   maintain routing state in the network.



Jetcheva and Johnson          Expires 13 January 2002           [Page 1]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   ADMR detects changes in mobility in the network and can adjust the
   frequency of the keep-alives it sends accordingly.  If desired,
   keep-alives may also optionally be sent in between application data
   packets in order to speed up detection and repair of link breaks.  If
   mobility in the network becomes too high to allow timely multicast
   state setup and maintenance, ADMR switches to flooding for some
   period of time, after which it attempts to operate efficiently again
   as the mobility in the network may have decreased.  Detection of high
   mobility in the network is based on frequency of link breaks in the
   multicast forwarding tree and does not require any additional control
   traffic or GPS or other external positioning information.










































Jetcheva and Johnson          Expires 13 January 2002           [Page 2]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


2. Assumptions

   We assume that all nodes wishing to communicate with other nodes
   within the ad hoc network are willing to participate fully in the
   protocols of the network.  In particular, each node participating in
   the network should also be willing to forward packets for other nodes
   in the network.

   We refer to the minimum number of hops necessary for a packet to
   reach from any node located at one extreme edge of the network to
   another node located at the opposite extreme, as the diameter of the
   network.  We assume that the diameter of an ad hoc network will be
   small (e.g., perhaps 5 or 10 hops), but may often be greater than 1.

   Packets may be lost or corrupted in transmission on the wireless
   network.  A node receiving a corrupted packet can detect the error
   and discard the packet.




































Jetcheva and Johnson          Expires 13 January 2002           [Page 3]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


3. Terminology

3.1. General Terms

      link

         A communication facility or medium over which nodes can
         communicate at the link layer, such as an Ethernet (simple or
         bridged).  A link is the layer immediately below IP.

      interface

         A node's attachment to a link.

      prefix

         A bit string that consists of some number of initial bits of an
         address.

      link-layer address

         A link-layer identifier for an interface, such as IEEE 802
         addresses on Ethernet links.

      packet

         An IP header plus payload.

      piggybacking

         Including two or more conceptually different types of data in
         the same packet so that all data elements move through the
         network together.

      network flood

         The flood of a packet in which each node in the network
         forwards the packet if it receives it and has not previously
         forwarded it.

      tree flood

         The flood of a packet constrained to the nodes in a multicast
         forwarding tree.  The packet is forwarded by any node in the
         tree receiving the packet that has not previously forwarded it,
         and nodes in the tree may accept and forward the packet when
         received from any other node in the tree.






Jetcheva and Johnson          Expires 13 January 2002           [Page 4]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


3.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].
















































Jetcheva and Johnson          Expires 13 January 2002           [Page 5]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


4. ADMR Protocol Overview

   ADMR does not depend on the operation of any particular underlying
   unicast routing protocol in the ad hoc network, allowing complete
   flexibility in the set of protocols used.  In fact, ADMR can even
   work in networks with no unicast protocol.

   Currently, ADMR operates only over bidirectional links.


4.1. Multicast State Setup

   Multicast state is set up when some new multicast sender S starts
   sending to a group G for which at least one receiver exists in the
   network, or when a receiver joins a group G for which there is at
   least one source in the network.  Group G may be a source-specific
   group.  State setup following a link break is discussed later in
   Section 4.3.


4.1.1. Multicast Receiver Discovery

   The multicast forwarding state for a given multicast group G and
   sender S in ADMR is conceptually represented as a loosely-structured
   multicast forwarding tree rooted at S.

   When an application running at source S sends a multicast packet
   targeted at group G when no routing state yet exists for this sender
   and group, the routing layer on S adds an ADMR header to the data
   packet and sends the data packet as a network flood.  Each node in
   the network that receives this packet forwards it unless it has
   already forwarded a copy of it.  In addition, the node records in its
   Node Table the MAC address of the node from which it received the
   packet, and the sequence number stored in the packet's ADMR header.
   This information will be used for duplicate detection and also for
   forwarding Receiver Join packets back to the source as described
   below.  After forwarding the packet, each node processes the rest of
   the packet as a normal packet based on its group destination address.

   In addition to forwarding and processing the packet, receivers for
   group G send a Receiver Join packet back towards the source.  The
   Receiver Join is sent automatically along the shortest path traversed
   by the flood back towards the source.  Each node that forwards the
   Receiver Join creates a forwarding entry in its Membership Table
   for source S and group G, indicating that it is a forwarder for
   this sender and group.  The collection of paths with forwarding
   state between S and the receivers for G abstractly constitutes the
   forwarding tree.





Jetcheva and Johnson          Expires 13 January 2002           [Page 6]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   If there are multiple new receivers for a given multicast group G
   near each other in the network, many Receiver Join packets will
   traverse the same paths or subpaths on their way to the source S.
   However, in order to make each node along these paths a forwarder
   for G and S, as necessary, it is enough for one Receiver Join packet
   to be received and forwarded by each such node.  It would thus be
   possible to filter all but the first of these multiple Receiver Join
   packets received by each of these nodes, but doing so would leave the
   connection of these new receivers to the multicast forwarding tree
   susceptible to the loss of the single Receiver Join packet that was
   forwarded.  To reduce overhead and yet provide resilience to such
   packet loss, each node forwards at most RECEIVER_JOIN_COUNT Receiver
   Join packets for the last sequence number it has recorded in its Node
   Table entry for G and S.  To implement this filtering, when sending
   a Receiver Join packet, the receiver R copies the sequence number
   from the received multicast packet from S into its Receiver Join, and
   each node maintains in its Node Table entry a count of Receiver Join
   packets forwarded for the sequence number in that Node Table entry.

   Once a receiver for group G sends a Receiver Join packet in response
   to a multicast data flood, it sets a join timer.  If this timer
   expires and the receiver has not received data from the source, it
   will resend its Receiver Join packet and set the timer again.  At the
   next expiration of the timer, the receiver will flood a Multicast
   Solicitation (Section 4.1.2) on the assumption that the path the
   Receiver Join is trying to traverse is no longer connected.  The
   join timer value is set according to a field specified by the source
   in the ADMR header of the data flood and is computed based on an
   application-specified or default value of the expected inter-packet
   time at which the source application will be originating packets.

   The source buffers data packets while multicast state is being
   set up.  The source node will start sending packets only after
   STATE_SETUP time has elapsed and it has received at least one
   Receiver Join packet.  The STATE_SETUP wait time is intended to allow
   for multicast state to be set up in the network.  The source will not
   send data if there are no receivers for group G in the network as
   indicated by a lack of Receiver Join packets.

   Once the source has received at least one Receiver Join packet and
   the STATE_SETUP time has elapsed, the source can send the buffered
   packets for group G; optionally, the source may apply a pacing scheme
   to avoid sending a large burst of packets at once and creating
   temporary network congestion along the paths from the source to the
   receivers.

   To deal with partitions, an ADMR source MAY flood (instead of
   multicasting) a subset of its data packets, selected from the stream
   of normal data packets generated by the source application.  If it
   does so, the period between such flooded multicast data packets



Jetcheva and Johnson          Expires 13 January 2002           [Page 7]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   SHOULD be limited, e.g., on the order of several tens of seconds or
   more between flooded packets.


4.1.2. Multicast Source Discovery

   When an application running at some node R requests to join a
   group G, the node checks its Membership Table to determine if it is
   already connected to G. If the table indicates that it is a forwarder
   for G, it records in the entry for G that it is also a receiver
   member for the group.  If R is neither a forwarder nor a receiver for
   the group, the ADMR routing layer on R sends a Multicast Solicitation
   packet as a network flood.  The ADMR header MUST include a Multicast
   Group option which contains the multicast group address that the
   receiver is attempting to join.  If the group is a source-specific
   multicast group, the specific sender address S requested by the
   application MUST be included in a Multicast Sender Address option.

   Each node in the network forwards the Multicast Solicitation, except
   that in the case of source-specific multicast, the specified source
   does not forward this packet.  Also in this case, if a node receiving
   the Multicast Solicitation has a Membership Table entry for this
   group and source indicating that it is a forwarder, this node will
   instead unicast (rather than forward as part of the flood) the
   Multicast Solicitation only to the previous hop address indicated in
   that Membership Table entry; the packet thus follows the multicast
   tree towards the source, speeding up and decreasing the overhead of
   the receiver join.

   When any source S for multicast group G receives the Multicast
   Solicitation packet (or the single source, in the case of a
   source-specific multicast group join), the source replies to the
   Multicast Solicitation to advertise to R its existence as a sender
   for the group.  This reply may take one of two forms:

    -  If the next scheduled network flood of the next multicast data
       packet from the source application (Section 4.1.1) is to occur
       soon, S MAY choose to advance the time for this network flood
       and use this packet as the reply for the Multicast Solicitation
       from R.  This form of reply is appropriate, for example, when
       many new receivers attempt to join the group at about the same
       time, since S would then receive a Multicast Solicitation from
       each of them, but could use the single existing network flood of
       the next data packet to reply to all of them.

    -  The other form that this reply may take is for S to send an
       ADMR keep-alive packet unicast to R, following the path taken
       by R's Multicast Solicitation packet; each node forwarding this
       unicast keep-alive packet unicasts it to the address recorded in
       the previous hop address field of that node's Node Table entry



Jetcheva and Johnson          Expires 13 January 2002           [Page 8]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


       for R, created when it forwarded R's Multicast Solicitation as
       it traveled toward S.  When forwarding this unicast keep-alive
       packet toward R, each node updates its Node Table entry for S in
       the same way as it would for a flood from S, recording the path
       back to S in each entry's previous hop address field.

   When node R receives a keep-alive from a source for group G in
   response to its Multicast Solicitation, R sends a Receiver Join
   packet back to S in the same manner as described in Section 4.1.1,
   creating the forwarding state to connect it to the multicast
   forwarding tree for this group and source.

   If node S replies to the Multicast Solicitation from R by sending a
   unicast keep-alive, as described above, then S also sets a keep-alive
   retransmission timer and expects to receive the Receiver Join from R
   within a short time.  If S does not receive the Receiver Join, it
   will retransmit its reply to R's Multicast Solicitation (which again,
   may be in the form of S's next network flood of an existing multicast
   data packet or may use a unicast ADMR keep-alive packet).  If the
   timer expires a second time and S has not received a Receiver Join
   from R, then S assumes that the path that the unicast keep-alive
   is trying to traverse, created by the forwarding of R's Multicast
   Solicitation to S, is broken, and S advances its next scheduled
   network flood of a multicast data packet to reply to R.

   A multicast receiver considers itself connected once it receives
   a data packet that was sent to it via multicast as described in
   Section 4.2.


4.2. Multicast Packet Forwarding

   A node whose Membership Table indicates it is a forwarders for
   group G and source S forwards non-duplicate multicast packets with
   a source address of S and destination address of G. Each multicast
   packet is dynamically forwarded from S along the shortest-delay path
   through the tree to the receiver members of the multicast group, only
   by members of the multicast tree.

   In this packet forwarding, however, packets are not constrained to
   follow any particular branches or parent/child links in the tree.
   In particular, the tree is defined only by the set of nodes, not by
   particular branches between the nodes; packets being forwarded along
   the tree may be accepted and forwarded when received from any other
   node in the tree.  Different packets may thus reach a receiver along
   different paths within the forwarding tree when nodes along these
   paths acquire the wireless medium in a different order, or when the
   packet does not get received correctly over some path within the tree
   due to wireless interference.




Jetcheva and Johnson          Expires 13 January 2002           [Page 9]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   We refer to the flood of a packet constrained to the nodes in the
   multicast forwarding tree as a tree flood, and to the more general
   type of flood of a packet through all nodes as a network flood.

   When a sender using ADMR sends a multicast packet, it floods within
   the multicast distribution tree only towards the group's receivers,
   in contrast to other protocols in which the packet also floods
   back towards any other senders that are not receivers.  Although
   this difference requires maintenance of source-specific state in
   forwarding nodes, such state is required anyway in order to support
   the source-specific multicast service model [3].  In addition,
   source-specific state at each node is required in other protocols,
   since they must detect duplicate packets during a flood within the
   forwarding group, and any type of packet identifiers used for this
   duplicate detection when there may be multiple group senders must be
   source-specific.

   When a node R receives any multicast packet, in addition to
   forwarding the packet, if it has forwarding state for the group and
   source of the packet, node R also checks the entry for this sender
   and group in its Membership Table to determine if it is a receiver
   member.  If so, then R processes it as a multicast packet that it is
   intended to receive, passing the packet up to the next layer within
   its receiving protocol stack.

   In addition, as part of this processing of the received multicast
   packet, if the packet was sent as a tree flood (rather than as
   a network flood), then this indicates that the receiver node R
   is currently connected to the multicast forwarding tree for this
   sender and group.  The node considers itself to remain connected
   until detecting that it has become disconnected, as described in
   Section 4.3.

   If the MAC layer in use in the network supports MAC-layer multicast
   addressing and packet transmission, ADMR takes advantage of it by
   causing receivers and nodes in the multicast forwarding tree to join
   the MAC-layer multicast group corresponding to the network-layer
   multicast group address.  For example, the IP multicast model [2]
   defines a mapping from "Class D" IP addresses (multicast addresses)
   to multicast MAC addresses for Ethernet and similar wireless media
   such as IEEE 802.11 wireless LANs [4].  By utilizing MAC-layer
   multicast when available, ADMR limits the overhead on other nodes in
   the network due to multicast packet transmissions.


4.3. Multicast State Maintenance

   Multicast state maintenance refers to mechanisms within ADMR
   responsible for monitoring the forwarding tree for link breaks and
   for repairing these breaks when they occur.  Maintenance in ADMR



Jetcheva and Johnson          Expires 13 January 2002          [Page 10]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   begins as soon as the multicast forwarding state is set up, and
   continues as long as the source application generates packets and
   there are receivers in the network interested in receiving these
   packets.


4.3.1. Link Break Detection

   Each multicast packet originated by some node S for multicast group G
   contains a small ADMR header, including a number of fields used
   by the protocol in forwarding the packet and in maintaining the
   multicast distribution tree for S and G.  One of the fields in the
   ADMR header is the inter-packet time (interval) at which new packets
   should be expected from this sender S for this group G.  This field
   in the ADMR header is initialized by S for each packet originated;
   it is based on dynamically tracking the average interval at which it
   originates multicast packets for group G, or can optionally be set
   based on IP port number information or supplied by the application.

   This inter-packet time is used by members of the multicast forwarding
   tree to adaptively detect disconnection in the forwarding tree, as
   well as inactive periods during which the source application does
   not send data temporarily and it will be more resource-efficient to
   expire the multicast state.

   If the application layer at node S originates no new multicast
   packets for G within some multiple (e.g., 1.5) of this current
   inter-packet time, the routing layer at S begins originating
   "keep-alive" packets for G; the keep-alive packet is multicast to
   the group (not flooded through the network) and is used to maintain
   the existing forwarding state for the multicast distribution tree
   for S and G.  The inter-packet time between keep-alives SHOULD be
   multiplied by some factor (e.g., 2) with each successive keep-alive,
   until reaching a maximum interval; after some further multiple of
   this interval, S is assumed to no longer be an active sender for G;
   in this case, the keep-alives are stopped, and all forwarding state
   for this sender and group in the network is allowed to expire.

   The ADMR header includes the multiplicative factor increasing the
   time between successive keep-alives and a count of keep-alives left
   to send before the multicast state will expire, allowing all nodes
   receiving any of these keep-alive packets to know when the tree is
   scheduled to expire, if the sender application does not begin to
   send new multicast data packets before that time.  The keep-alive
   count is initialized to EXPIRATION_KEEPALIVE_COUNT (which is based on
   the inter-packet time) and is decremented by 1 for each successive
   keep-alive.

   Some forwarders or receiver members of a multicast group may become
   disconnected from the multicast forwarding tree for the group, as



Jetcheva and Johnson          Expires 13 January 2002          [Page 11]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   nodes in the network move or as wireless transmission conditions
   change.  Each forwarder or receiver for some multicast group G and
   source S detects that it has become disconnected from the multicast
   forwarding tree when it fails to receive a number of successive
   expected multicast data (or keep-alive) packets (e.g., 3) from S
   for G.  Upon detection of disconnection, ADMR begins link repair
   procedures, as described in Section 4.3.2.

   The frequency of the keep-alives can be based on the source's sending
   pattern or can be specified by the application if it wants to ensure
   a maximum latency to link break discovery.  In the latter case,
   keep-alives MAY be sent in between data packets as well, to ensure
   timely link break detection and repair.

   The frequency of keep-alives MAY also change with the level of
   mobility in the network.  Each receiver MAY keep track of the packet
   loss that it experiences based on a sequence number contained in
   each packet (which is also used for duplicate detection).  In the
   event of receiver-initiated link repair (Section 4.3.2), the receiver
   can set the Loss Coeff field in the ADMR header (Section 4.1.2) of
   the Receiver Join packet that it sends to the source as part of
   the repair.  When the source gets some number of such packets that
   indicate high packet loss at the multicast receivers, it can increase
   the frequency of the keep-alives that it sends (including ones in
   between data packets if necessary).


4.3.2. Link Break Repair

   Each node maintains a disconnection timer for each group G and
   sender S for which it is either a forwarder or a receiver member,
   and resets this timer each time it receives a packet for the group.
   The timer value is based on the inter-packet time value in the ADMR
   header of the last received packet, plus a time proportional to the
   node's hop count from the source S, as determined by the forwarding
   of the last packet from S that updated the node's Node Table entry
   for S.  This small increase in disconnection timeout value as a
   function of hop count is intended to generally allow nodes closer
   to S (i.e., closer to a broken link on the path from S) to detect
   the disconnection before nodes further from S.  This property is not
   required for correct operation of the protocol, but it improves the
   efficiency of the repair process.

   When some node C detects disconnection, it initiates a local repair
   of the multicast forwarding tree.  Node C first sends a Repair
   Notification packet to the other nodes in the subtree "below"
   node C in the multicast distribution tree for group G and sender S.
   Here, the subtree "below" is defined by the previous hop address
   recorded in each node's Node Table for sender S, such that any node
   whose previous hop for S is node C or is some other node below C is



Jetcheva and Johnson          Expires 13 January 2002          [Page 12]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   defined to be below C in the tree.  Although each multicast packet
   is forwarded through the tree without regard to such relationships,
   as described in Section 4.2, this relationship represents the set of
   nodes that received the previous multicast packet through C and who
   will thus possibly detect the disconnection themselves later, due to
   the increase in disconnection timer values with hop count from S.

   To forward the Repair Notification packet to the nodes in the subtree
   below C, each node accepts and forwards the Repair Notification
   packet only if the MAC-layer transmitting source address of the
   packet matches the previous hop address stored in that node's
   Membership Table entry for the multicast sender S.  In addition,
   the sequence number and bitmap in each node's Node Table entry
   (Section 5.3) are used to avoid duplicates in the forwarding of the
   Repair Notification packet.

   After sending the Repair Notification packet, node C waits for
   a period of time REPAIR_DELAY before proceeding with its local
   repair.  If, during this delay, node C receives a Repair Notification
   initiated by an upstream node for this same group and source, then C
   cancels its own local repair, since this other node is closer to the
   break and will perform the repair itself.

   The Repair Notification packet serves two purposes.  It is a
   notification to nodes in the subtree below C that a local repair is
   in progress and that they should not initiate their own local repair.
   It is also a chance to double-check that the link to node C's parent
   is indeed the one that is broken.  The Repair Notification will be
   received by nodes directly below C in the forwarding tree, and if the
   link from C to its parent B in the tree is actually not broken, may
   also be received by B.  In the Repair Notification packet, C lists
   the address of the node that is currently its parent, as represented
   by the previous hop address in its Membership Table entry for the
   multicast source S and group G.  If the Repair Notification is
   received by this parent node, it recognizes that one of the nodes
   directly below it in the tree (node C) is performing a local repair.
   The parent then sends a one-hop Repair Notification to C, causing it
   to cancel its local repair as described above.

   When a receiver member of the group receives a Repair Notification,
   it SHOULD postpone its disconnection timer for an interval of time
   determined by an estimate of the amount of time the local repair is
   expected to take.

   After this short delay, if node C has not received a Repair
   Notification initiated by an upstream node for this group and source,
   node C sends a hop-limited Reconnect packet as a form of network
   flood.  The Reconnect packet identifies the group and source for
   which the local repair is being performed.  The hop limit for the




Jetcheva and Johnson          Expires 13 January 2002          [Page 13]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   Reconnect packet (e.g., 3) limits this flood to only reaching nodes
   near C.

   In addition to the normal handling of a network flood in deciding
   whether or not to forward the packet, nodes that are forwarders for
   the group G and source S being repaired treat the Reconnect packet
   specially.  Such a node, if it has not received a Repair Notification
   for this repair, assumes that it is upstream of the repair node C
   and that it is therefore still connected to the source S in the
   tree.  Rather than forwarding the Reconnect packet as part of
   the hop-limited network flood, the node instead reinitializes the
   packet's hop count limit (TTL) to the default value and unicasts the
   packet to the node listed as its parent in the previous hop address
   field in its Node Table entry for S.  This packet is no longer
   treated as a network flood packet, and is instead forwarded by each
   node in turn to its parent in the same way, until reaching S.  If the
   node is in fact not upstream from the repair node C and its unicast
   Reconnect reaches C, node C will discard the packet.

   Instead, if the Reconnect reaches S (the node is truly upstream of
   the broken link at C and no other broken links are encountered),
   node S responds with a Reconnect Reply packet.  This Reconnect Reply
   packet is unicast back to the repair node C along the path the
   Reconnect took to reach S, as recorded in the Node Table entry at
   each node for C.Each node through which the Reconnect Reply packet
   is forwarded on the path to C becomes a forwarder for the multicast
   group G and source S, and creates an entry in its Membership Table to
   record this if it is not already a forwarder for it.

   If the local repair procedure succeeds, the multicast forwarding
   tree will be reconnected and the receiver members will continue to
   receive data as expected.  If the disconnection timer expires at some
   receiver member R for a group G and source S, this is an indication
   that the local repair has probably failed, perhaps because the amount
   of mobility in the network has been too great to allow the type of
   hop-limited repair attempted.  In this case, node R performs its own
   individual repair by rejoining the group and source in the same way
   as when it originally joined, as described in Section 4.1.2.


4.4. Reaction to Mobility

   Each receiver MAY keep track of how many times it had to perform
   a global repair (Section  4.3.2) to rejoin a group because of
   disconnection.  When this number reaches DISCONNECTION_THRESHOLD,
   the receiver sets the High Mobility (M) flag in the ADMR header of
   the Receiver Join packet.  When the source receives some number of
   Receiver Joins with this flag set, it switches to flooding mode in
   which every multicast packet is flooded.  The high number of re-joins
   indicate that the multicast state setup cannot keep up with the



Jetcheva and Johnson          Expires 13 January 2002          [Page 14]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   high mobility in the network and only flooding can deliver the data
   successfully.  After flooding for some period of time, the protocol
   reverts back to its normal mode of operation as mobility in the
   network may have decreased.


4.5. State Expiration

   Each forwarder node in the multicast forwarding tree for some group G
   and source S automatically expires its own state and leaves the tree
   when it determines that it is no longer necessary for multicast
   forwarding.  Similarly, the multicast source S automatically expires
   its state and stops transmitting multicast data packets when it
   determines that there are no downstream receiver members of the
   group for this source; the sender continues to send certain of its
   subsequent multicast packets as infrequent background network flood
   packets (rather than multicasting them), but otherwise defers sending
   other multicasts for this group until receiving at least one new
   Receiver Join packet, as described in Section 4.1.1.  This mechanism
   helps to prune nodes from the forwarding tree that are no longer
   needed because a downstream receiver has left or crashed or because,
   as a result of a disconnection and an ensuing repair, some forwarding
   state may no longer be necessary.

   The decision to expire this state is based at each such node on a
   technique is similar to the use of passive acknowledgements [?].
   In particular, each such node attempts to determine whether the
   multicast packets that it originates (at S) or forwards (at forwarder
   nodes) are subsequently forwarded by other nodes that received them
   from this node.

   In order to determine this for each multicast packet, a node C
   expects to hear at least one other node B that received the packet
   from C forward the packet; as described in Section 4, when node B
   receives and forwards a packet, B copies the MAC-layer source address
   of the received packet (i.e., node C's address) into the previous
   hop address field in the packet's ADMR header, before forwarding the
   packet.  If node C overhears B transmit this packet, C considers
   this as confirmation that it should continue forwarding subsequent
   multicast packets, so that nodes such as B can continue to receive
   them.  On the other hand, if S fails to receive such confirmation
   for a number of consecutive multicast packets that it sends, then C
   decides that it is no longer necessary in the multicast forwarding
   tree for this group and source, or in the case of the source S
   itself, that no receiver members or forwarders remain.  Receivers for
   a multicast sender and group that are not forwarders retransmit each
   data or keep-alive packet stripped of its data payload so that it
   serves in the same way as an acknowledgement to upstream nodes.





Jetcheva and Johnson          Expires 13 January 2002          [Page 15]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


5. Conceptual Data Structures

   The multicast forwarding state for ADMR is maintained locally by each
   node in a Sender Table (Section 5.1), Membership Table (Section 5.2),
   and Node Table (Section 5.3).  In addition each node maintains a Send
   Buffer (Section 5.4).


5.1. Sender Table

   The Sender Table at a node logically contains one entry for each
   multicast group address for which this node is an active sender.
   Each entry in the Sender Table includes the following values:

    -  The current inter-packet time for this node sending to the group.

    -  The multiplication factor for the inter-packet time between
       consecutive keep-alives.

    -  The inter-keepalive time.

    -  The value of the keep-alive packet count used for this group.
       This count is initialized to an EXPIRATION_KEEPALIVE_COUNT value
       and decremented with each successive keep-alive sent since the
       last data packet sent to the group by this node.  The state for a
       given group expires when this count reaches 0.

    -  A mobility counter used to track high mobility and packet loss
       statistics received from multicast receivers via Receiver Join
       packets.

    -  A packet loss field used to track high mobility and packet loss
       statistics received from multicast receivers via Receiver Join
       packets.

    -  A State Setup flag.  If set indicates that the STATE_SETUP timer
       has expired and the multicast sender can start sending if it has
       received at least one Receiver Join (Section 4.1.1).

    -  A Flood flag.  If set, indicates that the next multicast data
       packet should be flooded.  This flag is set periodically by the
       flood timer.

    -  A Flood Mode flag.  If set, indicates that the Flood flag should
       not be cleared, i.e., all multicast data packets are to be
       flooded.

    -  A Connected flag.  If set, indicates that there is at least one
       receiver for this sender and group in the network, as determined
       by this node.



Jetcheva and Johnson          Expires 13 January 2002          [Page 16]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


5.2. Membership Table

   The Membership Table at a node logically contains one entry for each
   combination of multicast group address and sender address for which
   this node is either a receiver member or a forwarder.  Each entry in
   the Membership Table includes the following values:

    -  A flag to indicate if this node is a receiver.

    -  A flag to indicate that this node is connected to the multicast
       tree for this sender and group.

    -  A flag bit to indicate if this node is a forwarder.

    -  The current inter-packet time for the sender sending to this
       group.

    -  The current value of the keep-alive count from packets received
       for the group.

    -  The multiplication factor for the inter-packet time of successive
       keep-alives.

   In addition, if a node is a receiver for this group and sender, the
   corresponding table entry also contains the following additional
   values:

    -  A mobility counter which keeps track of how many times the
       receiver was disconnected from the multicast tree.  This counter
       is re-initialized to 0 every MOBILITY_ESTIMATION_PERIOD.

    -  The previous hop address of data packets forwarded by this node
       for state maintenance purposes (Section 4.3).


5.3. Node Table

   The Node Table at a node logically contains one entry for each other
   node in the network from which this node has received a flooded
   packet.  Each entry in the Node Table includes the following values:

    -  The sequence number from the ADMR header of the most recent tree
       flood or network flood packet received from the node represented
       by this table entry.

    -  A bitmap representing a number of previous sequence numbers of
       packets from this sender.  The sequence number and bitmap are
       used to detect and discard duplicate packets during a flood:  if
       the bit corresponding to some sequence number in this bitmap
       is set, the packet is assumed to be a duplicate; all sequence



Jetcheva and Johnson          Expires 13 January 2002          [Page 17]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


       numbers prior to that corresponding to the first bit in the
       bitmap are also assumed to be duplicates (or are of no further
       interest and are discarded); this use of a bitmap is similar to
       the data structure suggested for anti-replay protection in the IP
       Security protocols [5].

    -  The previous hop address for the sender node and sequence
       number in this entry.  This value is taken from the MAC-layer
       transmitting source address of the flood packet received for this
       sequence number that contained the minimum hop count in its ADMR
       header.

   To manage space in the Node Table, new entries should be created only
   as needed, and existing entries should be retained in an LRU fashion.


5.4. Send Buffer

   The Send Buffer of a node implementing ADMR is a queue of packets
   that cannot be sent by that node yet because the node does not yet
   know of the existence of receivers for a multicast group, or because
   its STATE_SETUP timer has not yet expired.  Each packet in the Send
   Buffer is logically associated with the time that it was placed into
   the Buffer, and SHOULD be removed from the Send Buffer and silently
   discarded SEND_BUFFER_TIMEOUT seconds after initially being placed in
   the buffer.



























Jetcheva and Johnson          Expires 13 January 2002          [Page 18]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6. ADMR Header Format

   The Adaptive Demand-Driven Multicast Routing protocol (ADMR) makes
   use of a special header carrying control information that can be
   included in any existing IP packet.  This ADMR header in a packet
   contains a small fixed-sized, 4-octet portion, followed by a sequence
   of zero or more ADMR options carrying optional information.  The end
   of the sequence of ADMR options in the ADMR header is implied by the
   total length of the ADMR header.

   The ADMR header is inserted in the packet following the packet's IP
   header, before any following header such as a traditional (e.g., TCP
   or UDP) transport layer header.  Specifically, the Protocol field
   in the IP header is used to indicate that an ADMR header follows
   the IP header, and the Next Header field in the ADMR header is used
   to indicate the type of protocol header (such as a transport layer
   header) following the ADMR header.

   The total length of the ADMR header (and thus the combined length
   of all ADMR options present) MUST be a multiple of 4 octets.  This
   requirement preserves the alignment of any following headers in the
   packet.































Jetcheva and Johnson          Expires 13 January 2002          [Page 19]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.1. Fixed Portion of ADMR Header

   The fixed portion of the ADMR header is used to carry information
   that MUST be present in any ADMR header.  This fixed portion of the
   ADMR header has the following format:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |    Reserved   |        Payload Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                            Options                            .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header

         8-bit selector.  Identifies the type of header immediately
         following the ADMR header.  Uses the same values as the IPv4
         Protocol field [6].

      Reserved

         Sent as 0; ignored on reception.

      Payload Length

         The length of the ADMR header, excluding the 4-octet fixed
         portion.  The value of the Payload Length field defines the
         total length of all options carried in the ADMR header.

      Options

         Variable-length field; the length of the Options field is
         specified by the Payload Length field in the ADMR header.
         Contains zero or more pieces of optional information (ADMR
         options), encoded in type-length-value (TLV) format (with the
         exception of the Pad1 option, described in Section 6.10).

   The placement of ADMR options following the fixed portion of the ADMR
   header MAY be padded for alignment.  However, due to the typically
   limited available wireless bandwidth in ad hoc networks, this padding
   is not required, and receiving nodes MUST NOT expect options within
   an ADMR header to be aligned.  A node inserting an ADMR header into
   a packet MUST set the Don't Fragment (DF) bit in the packet's IP
   header.

   The following types of ADMR options are defined in this document for
   use within an ADMR header:



Jetcheva and Johnson          Expires 13 January 2002          [Page 20]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  Source Information Option (Section 6.2)

    -  Receiver Join option (Section 6.3)

    -  Multicast Solicitation option (Section 6.4)

    -  Repair Notification option (Section 6.5)

    -  Reconnect option (Section 6.6)

    -  Reconnect Reply option (Section 6.7)

    -  Multicast Group Address option (Section 6.8)

    -  Multicast Sender Address option (Section 6.9)

    -  Pad1 option (Section 6.10)

    -  PadN option (Section 6.11)


































Jetcheva and Johnson          Expires 13 January 2002          [Page 21]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.2. Source Information Option

   The Source Information carries information initialized by the
   multicast sender of the packet, needed by nodes forwarding or
   receiving the packet.  Each multicast data packet MUST contain a
   Source Information option.  A "keep-alive" packet is encoded as a
   multicast packet containing a Source Information option but without a
   data payload following the ADMR header.

   The Source Information option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Count   | Inter-Packet Time |  Keep-Alive Count |  MF   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Length|   Previous Hop MAC Address
   +-+-+-+-+-+-+-+-+------------------------------------------------


   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP limited broadcast address
         (255.255.255.255) when the packet is sent as a network
         flood.  Otherwise, MUST be set to the address of the multicast
         group to which this packet is sent.

   Source Information option fields:

      Option Type

         2

      Opt Data Len

         8-bit unsigned integer, which is the length of the option, in
         octets, excluding the Option Type and Opt Data Len fields.






Jetcheva and Johnson          Expires 13 January 2002          [Page 22]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


      Identification

         A unique value generated by the initiator (original sender) of
         the packet.  Nodes generate a new Identification value for each
         multicast packet for a given multicast group, for example on a
         sequence number counter of all multicast packets sent by the
         node to the group.

         This value allows a receiving node to determine whether it has
         recently seen a copy of this packet; if so, this receiving
         node MUST discard the packet.  When propagating a packet, this
         field MUST be copied from the received copy of the packet being
         propagated.

      Hop Count

         Contains the number of hops that this packet has traversed.
         It is initialized to 0 by the originator of the packet and is
         incremented by 1 each time the packet is forwarded.

      Inter-Packet Time

         Contains the estimated inter-packet time (in milliseconds) for
         packets sent by this source application to the destination
         multicast group.  This value MUST be set by the sender and MUST
         not be changed when the packet is forwarded.

      Keep-Alive Count

         Initialized to 0 and ignored on reception if the packet carries
         a data payload.  In the event that no data packets are sent by
         a multicast source, ADMR sends a limited number of keep-alives
         spread over a period of time.  The Keep-Alive Count field
         in these keep-alive packets indicates how many keep-alives
         are left to send before the multicast tree is scheduled to
         expire.  This count is copied from the keep-alive count in the
         corresponding Sender Table entry at the source.  The count in
         the table entry is initialized to EXPIRATION_KEEPALIVE_COUNT by
         the source when it starts sending keep-alives in the absence
         of data, and is decremented for each consecutive keep-alive.
         The keep-alive count in the Source Information option, along
         with the inter-packet time and multiplication factor there,
         allows nodes with multicast state for this group and source to
         determine when they should expire this multicast state even if
         some of the keep-alives are lost and not received.

      MF (Multiplication Factor)

         If the packet carries a data payload, this field MUST be
         initialized to 0 and ignored on reception.  Otherwise, the



Jetcheva and Johnson          Expires 13 January 2002          [Page 23]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


         keep-alive packets sent when the source application does not
         generate any more data packets MAY be sent at increasing
         inter-packet times as indicated by this field.

      Address Length

         The length in octets of the Previous Hop MAC Address field in
         the option.

      Previous Hop MAC Address

         Variable length field.  When forwarding a packet containing a
         Source Information option, this field contains the MAC address
         of the node from which this node received the packet being
         forwarded; the length of this field is given by the Address
         Length field.  When originating (rather than forwarding) this
         packet, the Address Length field MUST be set to 0 and this
         field MUST NOT be present in the option.

   The Source Information option MUST be followed by a Multicast Group
   Address option (Section 6.8) when the packet is flooded.
































Jetcheva and Johnson          Expires 13 January 2002          [Page 24]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.3. Receiver Join Option

   The Receiver Join option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Multicast Group Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Loss Coeff  |M|
   +-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP address of the multicast sender to which
         this receiver is trying to connect.

   Receiver Join option fields:

      Option Type

         3

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set to 7.

      Identification

         This value MUST be copied from the keep-alive packet in
         response to which the Receiver Join is sent, in order to enable
         filtering of Receiver Joins sent by different receivers in
         response to the same keep-alive, as described in Sections 4.1.1
         and 4.1.2.

      Multicast Group Address

         The address of the multicast group this node is trying to join.



Jetcheva and Johnson          Expires 13 January 2002          [Page 25]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


      Loss Coeff

         Indicates on a discrete scale how much packet loss this
         receiver is experiencing.  Setting different bits in this field
         can indicate different ranges of packet loss.  Based on the
         packet loss experienced by receivers for a group, a source MAY
         vary the frequency of the keep-alives that it sends in between
         data packets in order to be able to detect link breaks faster
         as described in Section 4.3.1.

      High Mobility (M)

         The node originating this option sets this bit to
         indicate that the receiver has been disconnected more
         than DISCONNECTION_THRESHOLD times during an interval of
         DISCONNECTION_FREQUENCY.

      Reserved

         Set to 0; ignored on reception.

































Jetcheva and Johnson          Expires 13 January 2002          [Page 26]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.4. Multicast Solicitation Option

   The Multicast Solicitation option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast Group Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Count   |
   +-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP limited broadcast address
         (255.255.255.255)

   Multicast Solicitation option fields:

      Option Type

         4

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set to 7.

      Identification

         A unique value generated by the initiator (original sender) of
         the packet.  Nodes generate a new Identification value for each
         multicast packet for a given multicast group, for example by a
         sequence number counter of all multicast packets sent by the
         node to the group.

         This value allows a receiving node to determine whether it has
         recently seen a copy of this packet; if so, this receiving
         node MUST discard the packet.  When propagating a packet, this



Jetcheva and Johnson          Expires 13 January 2002          [Page 27]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


         field MUST be copied from the received copy of the packet being
         propagated.

      Multicast Group Address

         The address of the multicast group this node is trying to join.

      Hop Count

         Contains the number of hops that this packet has traversed.
         It is initialized to 0 by the originator of the packet and is
         incremented by 1 each time the packet is forwarded.

   If the Multicast Solicitation is for a specific source, a Multicast
   Sender Address option (Section 6.9) MUST be included after the
   Multicast Solicitation option.





































Jetcheva and Johnson          Expires 13 January 2002          [Page 28]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.5. Repair Notification Option

   The Repair Notification option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast Sender Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Parent Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP address of the multicast group to which
         this repair notification is sent.

      Hop Limit (TTL)

         SHOULD be set to 1 if this packet is sent in response to
         another Repair Notification (Section 4.3.2) and to the default
         otherwise.

   Repair Notification option fields:

      Option Type

         5

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set
         to 10.

      Identification

         A unique value generated by the initiator (original sender) of
         the packet.  Nodes generate a new Identification value for each



Jetcheva and Johnson          Expires 13 January 2002          [Page 29]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


         multicast packet for a given multicast group, for example on a
         sequence number counter of all multicast packets sent by the
         node to the group.

         This value allows a receiving node to determine whether it has
         recently seen a copy of this packet; if so, this receiving
         node MUST discard the packet.  When propagating a packet, this
         field MUST be copied from the received copy of the packet being
         propagated.

      Multicast Sender Address

         The IP address of the sender whose tree this node is trying to
         repair (Section 4.3.2).

      Parent Address

         The address of the node that last forwarded a multicast data
         packet for this group and source to this node.  This field
         is used to determine if a node below this node is performing
         a repair for a node above this node, to which it is still
         connected; if so, the parent SHOULD take over the repair as it
         is closer to the broken link (Section 4.3.2).






























Jetcheva and Johnson          Expires 13 January 2002          [Page 30]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.6. Reconnect Option

   The Reconnect option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast Group Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast Sender Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Count   |
   +-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP limited broadcast address
         (255.255.255.255) by the originator of the packet.
         When the Reconnect reaches a node which is part of the tree
         connected to the multicast sender, this node MUST set this
         field to the address of the multicast sender which is the
         target of the reconnection as described in Section 4.3.2.

   Reconnect option fields:

      Option Type

         6

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set
         to 11.

      Identification

         A unique value generated by the initiator (original sender) of
         the packet.  Nodes generate a new Identification value for each



Jetcheva and Johnson          Expires 13 January 2002          [Page 31]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


         multicast packet for a given multicast group, for example on a
         sequence number counter of all multicast packets sent by the
         node to the group.

         This value allows a receiving node to determine whether it has
         recently seen a copy of this packet; if so, this receiving
         node MUST discard the packet.  When propagating a packet, this
         field MUST be copied from the received copy of the packet being
         propagated.

      Multicast Group Address

         The IP address of the group for which this link repair is
         performed.

      Multicast Sender Address

         The IP address of the sender for which this link repair is
         performed.

      Hop Count

         The number of hops that this packet has traversed.  Initialized
         to 0 by the originator of the packet and incremented by 1 each
         time the packet is forwarded.

      Reserved

         Sent as 0; ignored on reception.
























Jetcheva and Johnson          Expires 13 January 2002          [Page 32]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.7. Reconnect Reply Option

   The Reconnect Reply option is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Multicast Group Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         packet MUST NOT change this field.

      Destination Address

         MUST be set to the IP address of the originator of the
         Reconnect packet in response to which this Reconnect Reply is
         sent.

   Reconnect Reply option fields:

      Option Type

         7

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set to 6.

      Multicast Group Address

         The IP address of the multicast group for which this Reconnect
         Reply is sent.

      Reserved

         Set to 0; ignored on reception.







Jetcheva and Johnson          Expires 13 January 2002          [Page 33]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.8. Multicast Group Address Option

   The Multicast Group Address option MUST only appear after a Source
   Information option (Section 6.2) and is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast Group Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Multicast Group option fields:

      Option Type

         8

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set to 6.

      Reserved

         Set to 0; ignored on reception.

      Multicast Group Address

         A multicast group address.





















Jetcheva and Johnson          Expires 13 January 2002          [Page 34]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.9. Multicast Sender Address Option

   The Multicast Sender Address option MUST only appear after a
   Multicast Solicitation option (Section 6.4) and is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Multicast Sender Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Multicast Sender option fields:

      Option Type

         9

      Opt Data Len

         8-bit unsigned integer.  The length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  For the
         current definition of this option, this field MUST be set to 6.

      Reserved

         Set to 0; ignored on reception.

      Multicast Sender Address

         The IP address of a multicast sender.




















Jetcheva and Johnson          Expires 13 January 2002          [Page 35]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.10. Pad1 Option

   The Pad1 ADMR option is encoded as follows:

   +-+-+-+-+-+-+-+-+
   |  Option Type  |
   +-+-+-+-+-+-+-+-+

   Pad1 option fields:

      Option Type

         0

   A Pad1 option MAY be included in the Options field of a ADMR header
   in order to align subsequent ADMR options, but such alignment is
   not required and MUST NOT be expected by nodes receiving packets
   containing a ADMR header.

   The total length of a ADMR header, indicated by the Payload Length
   field in the ADMR header MUST be a multiple of 4 octets.  When
   building a ADMR header in a packet, sufficient Pad1 or PadN options
   MUST be included in the Options field of the ADMR header to make the
   total length a multiple of 4 octets.

   If more than one consecutive octet of padding is being inserted in
   the Options field of a ADMR header, the PadN option, described next,
   SHOULD be used, rather than multiple Pad1 options.

   Note that the format of the Pad1 option is a special case; it does
   not have an Opt Data Len or Option Data field.






















Jetcheva and Johnson          Expires 13 January 2002          [Page 36]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


6.11. PadN Option

   The PadN ADMR option is encoded as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
   |  Option Type  |  Opt Data Len |   Option Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

   PadN option fields:

      Option Type

         1

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

      Option Data

         A number of zero valued octets equal to the Opt Data Len.

         A PadN option MAY be included in the Options field of a ADMR
         header in order to align subsequent ADMR options, but such
         alignment is not required and MUST NOT be expected by nodes
         receiving packets containing a ADMR header.

         The total length of a ADMR header, indicated by the Payload
         Length field in the ADMR header MUST be a multiple of 4 octets.
         When building a ADMR header in a packet, sufficient Pad1 or
         PadN options MUST be included in the Options field of the ADMR
         header to make the total length a multiple of 4 octets.




















Jetcheva and Johnson          Expires 13 January 2002          [Page 37]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


7. Detailed Operation

7.1. General Packet Processing

   In addition to the special processing of each packet discussed
   in Sections 7.2 through 7.4, each packet should be processed as
   described in this section.


7.1.1. Originating a Packet

   When originating any packet, a node using ADMR MUST perform the
   following sequence of steps:

    -  If the IP destination of the packet is a multicast address, check
       the Sender Table for an entry for this multicast group.

    -  If no entry for the group exists, create an entry initialized as
       follows:

        *  Set inter-packet time to a default or specified value

        *  Set the keep-alive inter-packet time to 0 or a default.

        *  Set multiplication factor to a default or specified value

        *  Set keep-alive count to EXPIRATION_KEEPALIVE_COUNT

        *  Set the flood flag.

        *  Clear the flood mode flag.

        *  Clear the mobility flag.

       Schedule a flood timer for the periodic background flood
       (Section 4.1.1).

    -  If the flood flag, the state setup flag, and the connected flag
       are all cleared, then the packet is placed in the Send Buffer
       (Section 5.4).

    -  If the flood flag is set, insert an ADMR header in the packet
       as described in Section 7.1.2, and add a Source Information
       option to it.  Initialize the Inter-Packet Time in the Source
       Information option with the value from the Sender Table; the
       multiplication factor and keep-alive count field in the header
       are initialized to 0.  The IP destination address of the packet
       is set to the limited IP broadcast address (255.255.255.255), and
       a Multicast Group option is added initialized to the original IP
       destination address of the packet.  Clear the flood flag in the



Jetcheva and Johnson          Expires 13 January 2002          [Page 38]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


       Sender Table entry.  Reset the keep-alive count to its default
       value.

    -  If an entry for the group exists, and the flood flag is not set,
       insert an ADMR header in the packet as described in Section 7.1.2
       and add a Source Information option.  Initialize the inter-packet
       in the Source Information option with the value from the Sender
       Table; the multiplication factor and keep-alive count field in
       the header are initialized to 0.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.

    -  Reschedule the maintenance timer to POSTPONE_FACTOR times the
       average inter-packet time in the Sender Table entry.

    -  Increment the unforwarded packets counter in the Sender Table
       entry for this group.  This counter is used to keep track
       of whether sent packets are forwarded by a downstream node
       (Section 4.5).  Schedule the silent expiration timer with a
       timeout multiple of the average interpacket time.  When this
       timer goes off, the sender will stop sending multicast packets,
       except for the periodic background data flood.

    -  Set Previous Hop MAC Address to own MAC address and set the
       Address Length to the length of this address in octets.

    -  Transmit the packet.


7.1.2. Adding an ADMR Header to a Packet

   A node originating a packet adds an ADMR header to the packet, if
   necessary, to carry information needed by the routing protocol.  A
   packet MUST NOT contain more than one ADMR header.  An ADMR header
   is added to a packet by performing the following sequence of steps
   (these steps assume that the packet contains no other headers that
   MUST be located in the packet before the ADMR header):

    -  Insert an ADMR header after the IP header but before any other
       header that may be present.

    -  Set the Next Header field of the ADMR header to the Protocol
       number field of the packet's IP header.





Jetcheva and Johnson          Expires 13 January 2002          [Page 39]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  Set the Protocol field of the packet's IP header to the Protocol
       number assigned for an ADMR header.


7.1.3. Receiving a Packet

   When a node receives any packet containing an ADMR header, it must
   process the packet according to the following sequence of steps:

    -  If the destination address of the packet is a multicast address
       and the packet carries a data payload, compare the Previous Hop
       Mac Address in the packet header with own MAC address.  If the
       addresses match, clear the unforwarded packets counter in the
       Membership Table entry for this multicast group, or if this node
       is the IP source of the packet, clear the corresponding Sender
       Table unforwarded packets counter.  Reschedule the corresponding
       silent expiration timer.

    -  If the destination address of the packet is a multicast address
       and the packet carries a data payload, the node should lookup the
       entry in its Membership Table for the IP source and destination
       addresses in the packet.

    -  If the node is a forwarder or receiver for the multicast sender
       and group in the packet header, and the node determines that the
       packet is a duplicate by checking the sender and group entry in
       its Node Table, and looking up the Identification field in the
       packet header, the packet is dropped.

    -  If no entry exists for this sender and group in the Node Table,
       such an entry is created for future duplicate detection.  The
       Identification field is set to the Identification field in the
       packet.

    -  If the packet is not a duplicate and the node is a forwarder or
       receiver for this group and source (corresponding flag set in the
       Node Table entry for the group and source), the Node Table entry
       for the IP source and destination addresses is updated with the
       Identification field of the packet and the inter-Packet Time in
       its Source Information option.  In addition, the disconnection
       timer is scheduled (or rescheduled if already scheduled) and the
       expiration timer is canceled if it was set.

    -  If the node is a receiver, the ADMR header, including all options
       is removed and the rest of the packet is passed to the next layer
       in the protocol stack.

    -  If the node is a forwarder, the node increments the hop count
       filed in the header, and hands the packet to the network layer
       output routine.



Jetcheva and Johnson          Expires 13 January 2002          [Page 40]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  If the node is a forwarder, set the Previous Hop MAC Address
       field to the MAC source address and set the Address Length field
       to the length of the Previous Hop MAC Address in octets.

    -  If the packet does not have a payload, each option (if any) in
       the ADMR header is examined and processed in the order in which
       it occurs in the packet, skipping over any Pad1 or PadN options.


7.2. Multicast Receiver Discovery

   Multicast Receiver Discovery refers to the mechanisms within the
   ADMR protocol by which senders for a multicast group discover paths
   in the network to receivers for that multicast group.  A multicast
   sender performs receiver discovery when it has data packets to send
   to a multicast group and has not yet performed a discovery for that
   group.  Receiver Discovery MAY also be performed periodically in
   order to resolve partitions by sending certain of a source's packets
   as network floods.

   The Receiver Discovery procedure utilizes two types of messages,
   a Receiver Discovery Keep-Alive (Section 6.2) and a Receiver Join
   (Section 6.3), to actively search for receivers for the multicast
   group and to establish routes with multicast state to these receivers
   in order to be able to deliver multicast data to them.  These ADMR
   messages MAY be carried in any type of IP packet, through use of the
   ADMR header as described in Section 6.


7.2.1. Originating a Receiver Discovery Keep-Alive

   A node initiating a Receiver Discovery for a multicast group,
   creates and initializes a Source Information option in an ADMR header
   attached to the data packet that triggered the discovery for this
   group.  The Source Information option MUST be included in an ADMR
   header in the packet.  To initialize the Source Information option,
   the node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 2.

    -  The Opt Data Len field in the option MUST be set to the value 6.
       The total size of the Source Information option when initiated is
       8 octets; the Opt Data Len field excludes the size of the Option
       Type and Opt Data Len fields themselves.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter




Jetcheva and Johnson          Expires 13 January 2002          [Page 41]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


       value for generating a new Identification value for each
       multicast packet it originates for a given group.

    -  The Hop Count field MUST be initialized to 0.

    -  The Inter-Packet Time field MUST be initialized with the
       inter-packet time value from the Sender Table entry for this
       multicast group.

    -  The Keep-Alive count MUST be initialized to the keep-alive count
       value from the Sender Table entry for this multicast group.

    -  The MF (Multiplication Factor) field must be initialized to 0.

    -  A Multicast Group option MUST be added after the Source
       Information option and MUST be initialized to the IP address of
       the group to which the data packet that triggered the discovery
       is addressed.

   The Source Address in the IP header of this packet MUST be the node's
   own IP address.  The Destination Address in the IP header of this
   packet MUST be the IP "limited broadcast" address (255.255.255.255).

   A node MUST create a Sender Table when it first performs a Receiver
   Discovery for a multicast group (Section 5.1) and SHOULD schedule
   a flood timer which periodically sets the flood flag in the Sender
   Table entry.  It MUST also schedule a state setup timer with a value
   of STATE_SETUP (Section 4.1.1).  When this timer expires, it sets
   the state setup flag in the Sender Table entry for the corresponding
   multicast group.

   The Sender Table entry MUST be updated every time a Receiver
   Discovery is launched by clearing the flood flag unless the flood
   mode flag is set.


7.2.2. Processing a Received Receiver Discovery Keep-Alive

   When a node receives a packet with a Source Information option in it,
   which has an IP limited broadcast destination address and a Multicast
   Group option right after the Source Information option, it identifies
   the packet as a Receiver Discovery Keep-Alive and the node MUST
   process it according to the following sequence of steps:

    -  The node checks its Membership Table for an entry for the
       multicast sender and group in the ADMR header of this packet.

    -  If such an entry exists and the receiver flag is set but
       the connected flag is cleared, the node will send a Receiver




Jetcheva and Johnson          Expires 13 January 2002          [Page 42]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


       Join packet back towards the multicast sender as described in
       Section 7.2.3.

    -  If an entry exists with the receiver flag set, copy the multicast
       group address from the Multicast Group option into the IP
       destination field, remove all ADMR options, and pass the
       packet to the next layer in the protocol stack as described in
       Section 7.1.3.

    -  Create an entry in the Node Table for the IP source and multicast
       group of the packet if one does not already exist.

    -  Update the Node Table entry for the IP source of the packet with
       the Identification in the packet header.

    -  Update the Node Table entry's previous hop field with the MAC
       source address in the MAC header of the packet.

    -  Increment the Hop Count field in the Source Information option in
       the ADMR header.

    -  Transmit packet.


7.2.3. Originating a Receiver Join

   A multicast receiver originates a Receiver Join in response to a
   Receiver Discovery Keep-Alive (Section 7.2.2 or a unicast keep-alive
   (Section 7.3.4) sent in response to a Multicast Solicitation
   (Section 7.3.2), or when the disconnection timer at a receiver for a
   multicast sender and group expires (Section 4.3.2).

   The Receiver Join is returned in a Receiver Join option
   (Section 6.3).

   The Receiver Join option MUST be included in an ADMR header in the
   packet addressed to the multicast sender.  To initialize the Receiver
   Join option, the node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 3.

    -  The Opt Data Len field in the option MUST be set to the value 7.

    -  The Identification field must be set to the value of the
       Identification field in the keep-alive packet received from the
       multicast sender in order to enable Receiver Join filtering
       (Section 4.1.1).






Jetcheva and Johnson          Expires 13 January 2002          [Page 43]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The Multicast Group Address must be set to the address of
       the multicast group for which the keep-alive was sent by the
       multicast sender.

    -  The Loss Coefficient must be set to the value of the loss
       coefficient in the node's Membership Table entry for this group
       and source.

    -  The High Mobility Flag (M) must be set if the mobility flag in
       the node's Membership Table is set, otherwise it must be set to
       0.  The mobility counter must be incremented.

   The Destination Address field in the IP header of the packet carrying
   the Receiver Join option MUST be set to the address of the multicast
   sender which originated the the keep-alive.

   Schedule a join timer unless the Receiver Join was sent in response
   to a disconnection.


7.2.4. Processing a Receiver Join

   When a node receives a packet with a Receiver Join option in it, it
   MUST process it according to the following sequence of steps:

    -  If the IP destination address of the packet matches the node's IP
       address and the node does not have a Sender Table entry for the
       multicast group in the packet, then the packet is dropped.

    -  Otherwise if the node does have a Sender Table entry, if the
       connected flag is not set, then the node sets the flag and if the
       state setup flag is set (indicating that the STATE_SETUP time has
       elapsed), it sends all packets addressed to this multicast group
       that are currently in the Send Buffer, optionally pacing them to
       avoid network congestion.

    -  The node copies the Packet Loss Coefficient into the loss
       coefficient field in the Sender Table entry.  Based on the
       value of the coefficient, the node MAY change the frequency
       of its keep-alives by modifying the inter-keepalive time and
       multiplication factor in the Sender Table entry, and rescheduling
       the maintenance timer (Section 4.3).

    -  If the High Mobility flag in the packet is set, the node MUST
       increment the mobility counter in the Sender Table entry for the
       corresponding multicast group contained in the Receiver Join.  If
       the counter exceeds the MOBILITY_HIGH threshold, the flood and
       flood mode flags in the Sender Table entry are set and subsequent
       packets MAY be flooded for a period of TEMPORARY_FLOOD.




Jetcheva and Johnson          Expires 13 January 2002          [Page 44]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  If the IP destination address of the packet is not this node's
       address, then the node MUST check its Node Table for an entry for
       the IP destination address of the packet.

    -  If the value of the Identification field in the Receiver Join
       option matches the value stored in the Node Table entry, the node
       increments the joins counter in the entry.  If the counter is
       larger than MAX_RECEIVER_JOINS, the packet is dropped.

    -  Otherwise, the packet is sent after its destination MAC address
       is set to the address saved in the previous hop field of the Node
       Table entry for the IP destination address and multicast group
       address of the Receiver Join.


7.3. Multicast Source Discovery

   Multicast Source Discovery refers to mechanisms within the ADMR
   protocol which allow a receiver interested in joining a multicast
   group to discover all sources for the group in the network (or
   a specific source in the case of single-source multicast), and
   establish paths with multicast state to them.  The Multicast
   Source Discovery procedure uses three types of packets:  Multicast
   Solicitation (Section 6.4), Receiver Join (Section 6.3), and unicast
   keep-alive (Section 6.2).  These ADMR messages MAY be carried in any
   type of IP packet, through use of the ADMR header as described in
   Section 6.


7.3.1. Originating a Multicast Solicitation

   A receiver node initiating a Multicast Source Discovery, creates and
   and initializes a Multicast Solicitation option in an ADMR header.

   The Multicast Solicitation option MUST be included in an ADMR header
   and the destination IP address of the packet MUST be set to the
   limited broadcast address (255.255.255.255).  To initialize the
   Multicast Solicitation option, the node performs the following
   sequence of steps:

    -  The Option Type in the option MUST be set to the value 4.

    -  The Opt Data Len field in the option MUST be set to the value 7.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.



Jetcheva and Johnson          Expires 13 January 2002          [Page 45]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The Multicast Group Address MUST be set to the address of the
       multicast group the receiver is interested in joining.

    -  The Hop Count field must be initialized to 0.

    -  If the join is source specific, a Multicast Sender Address
       option MUST be added after the Multicast Solicitation option and
       initialized as described in Section 7.4.11.

    -  Transmit the packet.


7.3.2. Processing a Multicast Solicitation

   When a node receives a packet with a Multicast Solicitation option,
   it MUST process the packet according to the following sequence of
   steps:

    -  If there is a Multicast Sender Address option in the packet and
       it matches the IP destination address in the packet, the option
       is processed first and the packet discarded if the sender address
       in the option does not match the node's address.

    -  The node checks its Sender Table for an entry for the multicast
       group in the Multicast Solicitation option.

    -  If such an entry exists, this node is a source for the multicast
       group and:

        *  Creates and sends a unicast keep-alive in response to the
           Multicast Solicitation as described in Section 7.3.3.

        *  Creates an entry in the Node Table for the IP source of the
           packet if one does not already exist.

        *  Update the Node Table entry for the IP source of the packet
           with the Identification in the packet header, and the
           previous hop address in the entry with the MAC source address
           in the MAC header of the packet.

        *  Increment the Hop Count field in the Multicast Solicitation
           option in the ADMR header.

        *  If this is not a single-source join (i.e., no Multicast
           Sender Address option is attached), transmit packet.

    -  If the node does not have an entry in its Sender Table for the
       multicast group in the Multicast Solicitation option in the
       packet, then it is not a source for the group, and MUST do the
       following:



Jetcheva and Johnson          Expires 13 January 2002          [Page 46]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


        *  Create a Node Table entry for the IP source of the Multicast
           Solicitation.

        *  Update Node Table entry for the IP source of the packet with
           the Identification in the packet header, and the previous hop
           field in the entry with the MAC source address from the MAC
           header of the packet.

        *  If the destination IP address is the limited broadcast
           address and this is a single-source Multicast Solicitation,
           the node MUST check its Membership Table for an entry for
           the multicast source and group.  If such an entry exists
           and the node is a receiver or forwarder for the group and
           source (respective flag set in the Membership Table), it MUST
           set the IP destination address of the packet to the sender
           address from the Multicast Sender Address option, and set the
           MAC destination address to the previous hop field from the
           Membership Table entry.

        *  Increment the Hop Count field in the packet.

        *  Transmit packet.

   The node MUST set an expiration time for each Sender Table entry
   after which the previous hop information will be considered invalid.


7.3.3. Originating a Unicast Keep-Alive

   A unicast keep-alive is generated in response to a Multicast
   Solicitation (Section 7.3.2).  The node which received the Multicast
   Solicitation creates and initializes a Source Information option in
   an ADMR header.  The Source Information option MUST be included in
   an ADMR header in the packet.  To initialize the Source Information
   option, the node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 2.

    -  The Opt Data Len field in the option MUST be set to the value 6.
       The total size of the Source Information option when initiated is
       8 octets; the Opt Data Len field excludes the size of the Option
       Type and Opt Data Len fields themselves.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.




Jetcheva and Johnson          Expires 13 January 2002          [Page 47]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The Hop Count field MUST be initialized to 0.

    -  The Inter-Packet Time field MUST be initialized with the
       inter-packet time value from the Sender Table entry for this
       multicast group.

    -  The Keep-Alive count MUST be initialized to the keep-alive count
       value from the Sender Table entry for this multicast group.

    -  The MF (Multiplication Factor) field must be initialized to 0.

   - The node MUST schedule a retransmission timer for this packet
   (Section 4.1.2).

   The Source Address in the IP header of this packet MUST be the node's
   own IP address.  The Destination Address in the IP header of this
   packet MUST be the IP address of the multicast receiver which sent
   the Multicast Solicitation packet.


7.3.4. Processing a Unicast Keep-Alive

   When a node receives a packet with a Source Information option
   which has a unicast IP destination address and a Multicast Group
   option right after the Source Information option, this is a unicast
   keep-alive and the node MUST process it according to the following
   sequence of steps:

    -  The node checks its Node Table for an entry for the IP
       destination address and multicast group from the ADMR header of
       this packet.

    -  If no such entry exists, drop the packet.

    -  Otherwise, update the Node Table entry for the IP source of the
       packet with the Identification in the packet header.

    -  Update the MAC next hop address of the packet with the Node Table
       entry's previous hop field.

    -  Increment the Hop Count field in the Source Information option in
       the ADMR header.

    -  Transmit the packet.

   The node MUST set an expiration timer on the Node Table entry after
   which the previous hop information becomes invalid.






Jetcheva and Johnson          Expires 13 January 2002          [Page 48]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


7.4. Multicast State Maintenance

   Multicast State Maintenance refers to the mechanisms within the ADMR
   protocol by which link breaks in the multicast forwarding tree are
   detected and repaired.  All nodes that are receivers or forwarders
   for a given multicast source and group are involved in multicast
   state maintenance.

   The Multicast State Maintenance procedure utilizes 5 types of
   packets:  Maintenance Keep-Alive (Section 6.2), Repair Notification
   (Section 6.5), Reconnect (Section 6.6), and Reconnect Reply
   (Section 6.7), to actively detect links breaks in the multicast tree
   and repair them incrementally as needed.  These ADMR messages MAY be
   carried in any type of IP packet, through use of the ADMR header as
   described in Section 6.


7.4.1. Originating a Maintenance Keep-Alive

   A Maintenance Keep-Alive is sent when the maintenance timer expires
   (Section 7.1.1).  The Source Information option MUST be included in
   an ADMR header in the packet.  To initialize the Source Information
   option, the node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 2.

    -  The Opt Data Len field in the option MUST be set to the value 6.
       The total size of the Source Information option when initiated is
       8 octets; the Opt Data Len field excludes the size of the Option
       Type and Opt Data Len fields themselves.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.

    -  The Hop Count field MUST be initialized to 0.

    -  The Inter-Packet Time field MUST be initialized with the
       keep-alive inter-packet time value from the Sender Table entry
       for this multicast group.  If this entry is 0, then the average
       inter-packet time value should be copied into it and into the
       Source Information option of the packet.

    -  The Keep-Alive count MUST be initialized to the keep-alive count
       value from the Sender Table entry for this multicast group,
       and the keep-alive count value in the Sender Table must be
       decremented.



Jetcheva and Johnson          Expires 13 January 2002          [Page 49]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The MF (Multiplication Factor) field must be initialized to the
       the value from the corresponding Sender Table entry.

   The Source Address in the IP header of this packet MUST be the node's
   own IP address.  The Destination Address in the IP header of this
   packet MUST be the IP address of the multicast group to which this
   packet is sent.


7.4.2. Processing a Maintenance Keep-Alive

   When a node receives a packet with a Source Information option which
   has an IP multicast destination address, it identifies this packet as
   a Maintenance Keep-Alive and the node MUST process it according to
   the following sequence of steps:

    -  The node checks its Membership Table for an entry for the
       multicast sender and group from the ADMR header of this packet.

    -  If no such entry exists, drop the packet.

    -  Update the Node Table entry for the IP source of the packet with
       the Identification in the packet's ADMR header.

    -  If the previous hop address in the Membership Table entry for the
       multicast sender and group of the packet does not match the MAC
       source address, drop the packet (Section 4.3).

    -  Increment the Hop Count field in the Source Information option in
       the ADMR header.

    -  Schedule an expiration timer based on the Inter-Packet Time,
       Keep-Alive Count, and MF (Multiplication Factor) fields in the
       Source Information option.

    -  If node is a receiver, strip data payload from packet if any.
       A receiver transmits a packet stripped of its data payload so
       that it serves as a passive acknowledgement to upstream nodes
       (Section 4.5).

    -  Transmit packet.


7.4.3. Originating a Repair Notification

   A node originates a Repair Notification packet when its disconnection
   timer expires and its Membership Table has a set forwarding flag for
   a given multicast source and group.  In addition, a node originates
   a Repair Notification when it receives a Repair Notification from a
   node in which the Parent Node Address field is set to this node's



Jetcheva and Johnson          Expires 13 January 2002          [Page 50]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


   address.  In this case the TTL value in the IP header of the packet
   is set to 1.

   The Repair Notification option MUST be included in an ADMR header
   and the destination IP address of the packet MUST be the address of
   the multicast group for which a link break has been detected.  To
   initialize the Repair Notification Option, the node performs the
   following sequence of steps:

    -  The Option Type in the option MUST be set to the value 5.

    -  The Opt Data Len field in the option MUST be set to the value 10.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.

    -  The Multicast Sender Address field MUST be initialized with the
       IP address of the multicast sender in whose multicast tree the
       link break was detected.

    -  The Parent Address field MUST be set to the previous hop field
       from the node's Membership Table for the given multicast sender
       and group.

    -  If the Repair Notification is sent in response to another
       Repair Notification, set the TTL field in the packet to 1
       (Section 4.3.2).

    -  The node MUST schedule the repair timer.

    -  If node is a receiver as indicated by the receiver flag in its
       Membership Table entry, it MUST reschedule its disconnection
       timer by LOCAL_REPAIR_TIME.

    -  Transmit packet.


7.4.4. Processing a Repair Notification

   When a node receives a Repair Notification, it MUST process it
   according to the following sequence of steps:

    -  If the Parent Address field matches the node's address, it drops
       the Repair Notification packet, and creates and sends its own
       Repair Notification with a ttl = 1 as described in Section 7.4.3.




Jetcheva and Johnson          Expires 13 January 2002          [Page 51]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  Otherwise, if the node has an entry in its Membership Table for
       the multicast group address in the destination IP address of the
       packet, and the multicast sender in the Multicast Sender Address
       field in the Repair Notification option, and if the MAC source
       address of the packet matches the previous hop field in the
       Membership Table entry:

        *  If this entry indicates this node as a forwarder, then it
           cancels its disconnection timer and the repair timer if
           scheduled, and transmits the packet.

        *  Otherwise, if this entry indicates this node as a receiver,
           then the node postpones its disconnection timer by
           LOCAL_REPAIR_TIME.

        *  If the node is also a forwarder, it transmits the packet.

    -  Otherwise, drop the packet.


7.4.5. Originating a Reconnect

   A node originates a Reconnect after the repair timer for a given
   multicast source and group expires.  The Reconnect option MUST
   be included in an ADMR header and the destination IP address
   of the packet MUST be set to the limited broadcast address
   (255.255.255.255).  To initialize the Reconnect Option, the node
   performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 6.

    -  The Opt Data Len field in the option MUST be set to the value 11.

    -  The Identification field in the option MUST be set to a new
       value, different from that used for other multicast packets
       recently originated by this node for a particular multicast
       group.  For example, each node MAY maintain a single counter
       value for generating a new Identification value for each
       multicast packet it originates for a given group.

    -  The Multicast Group Address option MUST be initialized to the
       IP address of the multicast group for which the repair is being
       performed.

    -  The Multicast Sender Address field MUST be initialized to the IP
       address of the multicast sender for which the repair is being
       performed.

    -  The Hop Count field MUST be initialized to 0.




Jetcheva and Johnson          Expires 13 January 2002          [Page 52]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The IP TTL field MUST be set to LOCAL_REPAIR_TTL.

    -  Transmit the packet.


7.4.6. Processing a Reconnect

   When a node receives a Reconnect, it MUST process it according to the
   following sequence of steps:

    -  If the source IP address in the packet matches this node's
       address, drop packet.

    -  If the address in the Multicast Sender Address field in the
       Reconnect option matches the address of the node:  if the
       node has an entry in its Sender Table for the multicast group
       address from the Multicast Group Address field of the Reconnect
       option, then the node creates and sends a Reconnect Reply packet
       (Section 7.4.7), otherwise if no Sender Table entry exists, the
       Reconnect is dropped.

    -  Create an entry in the Node Table for the IP source of the packet
       if one does not already exist.

    -  Update the Node Table entry for the IP source of the packet with
       the Identification in the packet header, as well as the MAC
       source address in the MAC header of the packet.

    -  Check Membership Table for an entry for the multicast source and
       group address listed in the Reconnect option.  If such an entry
       exists and the forwarder and connected flags are set, then set
       the IP destination address of the packet to the value of the
       Multicast Sender Address field and the MAC destination address to
       the previous hop entry from the Membership table entry.

    -  Increment the Hop Count field in the Reconnect option in the ADMR
       header.

    -  Transmit packet.


7.4.7. Originating a Reconnect Reply

   A node originates a Reconnect Reply in response to a Reconnect packet
   as described in Section 4.3.2.  The Reconnect Reply option MUST be
   included in an ADMR header and the destination IP address of the
   packet MUST be set to the IP source address (i.e., the address of the
   node that initiated the repair) from the received Reconnect packet.
   To initialize the Reconnect Reply option, the node performs the
   following sequence of steps:



Jetcheva and Johnson          Expires 13 January 2002          [Page 53]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


    -  The Option Type in the option MUST be set to the value 7.

    -  The Opt Data Len field in the option MUST be set to the value 6.

    -  The Multicast Group Address field MUST be initialized to the
       address of the multicast group this Reconnect Reply pertains to.

    -  Transmit packet.


7.4.8. Processing a Reconnect Reply

   When a node receives a packet with a Reconnect Reply option in it, it
   MUST process it according to the following sequence of steps:

    -  If the IP destination in the packet header matches the address
       of the node, the node sets the connected flag in its Membership
       Table entry for the multicast group in the Multicast Group
       Address field in the Reconnect Reply option and the IP source
       address of the packet.  If no such Membership Table entry exists,
       the packet MUST be dropped.

    -  If the IP destination address of the packet does not match the
       node's IP address, then the node transmits the packet after
       it sets the destination MAC address to the value saved in the
       previous hop field in the Node Table entry for the multicast
       group in the Multicast Group Address field in the Reconnect Reply
       option and the IP source address of the packet.  This entry was
       created when this node forwarded the Reconnect packet in response
       to which the Reconnect Reply was sent.  If no such entry exists,
       the packet MUST be dropped.

    -  If this node is also a receiver, reschedule the disconnection
       timer.


7.4.9. Originating a Multicast Group Option

   The Multicast Group option MUST only appear after a Source
   Information option with a limited broadcast IP destination address
   (255.255.255.255).  To initialize the Multicast Group option, the
   node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 8.

    -  The Opt Data Len field in the option MUST be set to the value 6.

    -  The Multicast Group Address must be set to the IP address of the
       multicast group to which the packet is being sent.




Jetcheva and Johnson          Expires 13 January 2002          [Page 54]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


7.4.10. Processing a Multicast Group Option

   A Multicast Group option is processed as described in Section 7.2.2.


7.4.11. Originating a Multicast Sender Address Option

   The Multicast Group option MUST only appear after a Multicast
   Solicitation option.  To initialize the Multicast Sender Address
   option, the node performs the following sequence of steps:

    -  The Option Type in the option MUST be set to the value 9.

    -  The Opt Data Len field in the option MUST be set to the value 6.

    -  The Multicast Sender Address must be set to the IP address of the
       multicast sender to which the receiver is interested in sending a
       single-source Multicast Solicitation.


7.4.12. Processing a Multicast Sender Address Option

   A Multicast Sender Address option is processed as described in
   Section 7.3.2.





























Jetcheva and Johnson          Expires 13 January 2002          [Page 55]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


8. Constants

      STATE_SETUP

         A period of time during which multicast senders buffer data
         packets when they first perform a Receiver Discovery for a
         group (Section 4.1.1).  The STATE_SETUP wait time is intended
         to allow multicast state to be set up in the network before the
         data is sent out.

      EXPIRATION_KEEPALIVE_COUNT

         The number of consecutive keep-alive packets that are sent
         before multicast state for a given group and source expires
         (Section 4.5).  Value SHOULD be determined based on the
         inter-packet time for the multicast group.

      DISCONNECTION_THRESHOLD

         The DISCONNECTION_FREQUENCY that merits setting the
         High Mobility (M) flag in the Receiver Join option in the ADMR
         header (Section 7.2.3).

      DISCONNECTION_FREQUENCY

         The number of times a receiver has gotten disconnected over a
         period of MOBILITY_ESTIMATION_PERIOD (Section 4.3.1).

      MOBILITY_ESTIMATION_PERIOD

         Controls the interval over which DISCONNECTION_FREQUENCY is
         computed.

      MOBILITY_HIGH

         The threshold used by multicast senders to determine if enough
         receivers have set the High Mobility flag in their Receiver
         Joins to merit going into flood mode (Section 4.1.1).

      TEMPORARY_FLOOD

         The period of time a multicast sender spends in flood mode once
         the mobility counter has exceeded the MOBILITY_HIGH threshold
         (Section 4.1.1).

      REPAIR_DELAY

         The interval of time a node attempting a repair should wait
         after sending a Repair Notification and before initiating a
         local repair.



Jetcheva and Johnson          Expires 13 January 2002          [Page 56]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


      LOCAL_REPAIR_TTL

         The number of hops a Reconnect packet is allowed to traverse
         away from the source of the packet.

      POSTPONE_FACTOR

         The amount of time a receiver postpones initiating global
         repair after it gets notification that a local repair is in
         progress (Section 4.3.2).

      LOCAL_REPAIR_TIME

         The estimated time that a local repair would take.
         Used by receivers for a group and source to postpone
         their disconnection timer (which triggers global repair
         (Section 4.3.2)).

      MAX_RECEIVER_JOINS

         The maximum number of Receiver Joins sent in response
         to a given data flood that a network node should forward
         (Section 4.1.1).






























Jetcheva and Johnson          Expires 13 January 2002          [Page 57]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


9. IANA Considerations

   This document proposes the use of an ADMR header, which requires an
   IP Protocol number.

   In addition, this document proposes use of the value "No Next Header"
   originally defined for use in IPv6) within an IPv4 packet, to
   indicate that no further header follows an ADMR header.













































Jetcheva and Johnson          Expires 13 January 2002          [Page 58]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


10. Security Considerations

   This document does not specifically address security concerns.
   This document does assume that all nodes participating in the ADMR
   protocol do so in good faith and without malicious intent to corrupt
   the routing ability of the network.  In mission-oriented environments
   where all the nodes participating in the ADMR protocol share a
   common goal that motivates their participation in the protocol, the
   communications between the nodes can be encrypted at the physical
   channel or link layer to prevent attack by outsiders.











































Jetcheva and Johnson          Expires 13 January 2002          [Page 59]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


Acknowledgments

   The protocol described in this draft has been designed and developed
   within the Monarch Project, a research project at Rice University and
   Carnegie Mellon University which is developing adaptive networking
   protocols and protocol interfaces to allow truly seamless wireless
   and mobile node networking.














































Jetcheva and Johnson          Expires 13 January 2002          [Page 60]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


References

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

   [2] Steve Deering.  Host extensions for IP multicasting.  RFC 1112,
       August 1989.

   [3] Hugh Holbrook and Brad Cain.  Source-specific multicast for ip.
       Internet-Draft, draft-holbrook-ssm-arch-01.txt, November 2000.
       Work in progress.

   [4] IEEE Computer Society LAN MAN Standards Committee.  Wireless
       LAN Medium Access Control (MAC) and Physical Layer (PHY)
       Specifications, IEEE Std 802.11-1997.  The Institute of
       Electrical and Electronics Engineers, New York, New York, 1997.

   [5] S. Kent and R. Atkinson.  Security architecture for the internet
       protocol.  RFC 2401, November 1998.

   [6] Joyce K. Reynolds and Jon Postel.  Assigned numbers.  Internet
       Request For Comments RFC 1700, October 1994.































Jetcheva and Johnson          Expires 13 January 2002          [Page 61]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


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@flarion.com


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

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































Jetcheva and Johnson          Expires 13 January 2002          [Page 62]


INTERNET-DRAFT   Adaptive Demand-Driven Multicast Routing   13 July 2001


Authors' Addresses

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

        Jorjeta G. Jetcheva
        Carnegie Mellon University
        Computer Science Department
        5000 Forbes Avenue
        Pittsburgh, PA  15213-3891
        USA

        Phone: +1 412 268-3053
        Fax:   +1 412 268-5576
        Email: jorjeta@cs.cmu.edu


        David B. Johnson
        Rice University
        Computer Science Department, MS 132
        6100 Main Street
        Houston, TX 77005-1892
        USA

        Phone: +1 713 348-3063
        Fax:   +1 713 348-5930
        Email: dbj@cs.rice.edu



























Jetcheva and Johnson          Expires 13 January 2002          [Page 63]


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