tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 2362

 
 
 

Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

Part 2 of 3, p. 13 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 13 
3 Detailed Protocol Description

   This section describes the protocol operations from the perspective
   of an individual router implementation.  In particular, for each
   message type we describe how it is generated and processed.

Top       Page 14 
3.1 Hello

   Hello messages are sent so neighboring routers can discover each
   other.

3.1.1 Sending Hellos

   Hello messages are sent periodically between PIM neighbors, every
   [Hello-Period] seconds.  This informs routers what interfaces have
   PIM neighbors.  Hello messages are multicast using address 224.0.0.13
   (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to
   [Hello-Holdtime], for neighbors to keep the information valid. Hellos
   are sent on all types of communication links.

3.1.2 Receiving Hellos

   When a router receives a Hello message, it stores the network layer
   address for that neighbor, sets its Neighbor-timer for the Hello
   sender to the Holdtime included in the Hello, and determines the
   Designated Router (DR) for that interface. The highest addressed
   system is elected DR.  Each Hello received causes the DR's address to
   be updated.

   When a router that is the active DR receives a Hello from a new
   neighbor (i.e., from an address that is not yet in the DRs neighbor
   table), the DR unicasts its most recent RP-set information to the new
   neighbor.

3.1.3 Timing out neighbor entries

   A periodic process is run to time out PIM neighbors that have not
   sent Hellos. If the DR has gone down, a new DR is chosen by scanning
   all neighbors on the interface and selecting the new DR to be the one
   with the highest network layer address. If an interface has gone
   down, the router may optionally time out all PIM neighbors associated
   with the interface.

3.2 Join/Prune

   Join/Prune messages are sent to join or prune a branch off of the
   multicast distribution tree. A single message contains both a join
   and prune list, either one of which may be null.  Each list contains
   a set of source addresses, indicating the source-specific trees or
   shared tree that the router wants to join or prune.

Top       Page 15 
3.2.1 Sending Join/Prune Messages

   Join/Prune messages are merged such that a message sent to a
   particular upstream neighbor, N, includes all of the current joined
   and pruned sources that are reached via N; according to unicast
   routing Join/Prune messages are multicast to all routers on multi-
   access networks with the target address set to the next hop router
   towards S or RP. Join/Prune messages are sent every [Join/Prune-
   Period] seconds. In the future we will introduce mechanisms to rate-
   limit this control traffic on a hop by hop basis, in order to avoid
   excessive overhead on small links.  In addition, certain events cause
   triggered Join/Prune messages to be sent.

   Periodic Join/Prune Messages:

   A router sends a periodic Join/Prune message to each distinct RPF
   neighbor associated with each (S,G), (*,G) and (*,*,RP) entry.
   Join/Prune messages are only sent if the RPF neighbor is a PIM
   neighbor.  A periodic Join/Prune message sent to a particular RPF
   neighbor is constructed as follows:

      1 Each router determines the RP for a (*,G) entry by using
        the hash function described. The RP address (with RPT and WC
        bits set) is included in the join list of a periodic Join/Prune
        message under the following conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward the RP for an active (*,G) or (*,*,RP)
             entry, and

           2 The outgoing interface list in the (*,G) or (*,*,RP)
             entry is non-NULL, or the router is the DR on the same
             interface as the RPF neighbor.

      2 A particular source address, S, is included in the join
        list with the RPT and WC bits cleared under the following
        conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward S, and

           2 There exists an active (S,G) entry with the RPT-bit
             flag cleared, and

           3 The oif list in the (S,G) entry is not null.

Top       Page 16 
      3 A particular source address, S, is included in the prune
        list with the RPT and WC bits cleared under the following
        conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward S, and

           2 There exists an active (S,G) entry with the RPT-bit
             flag cleared, and

           3 The oif list in the (S,G) entry is null.

      4 A particular source address, S, is included in the prune
        list with the RPT-bit set and the WC bit cleared under the
        following conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor  toward the RP and there exists a (S,G) entry with
             the RPT-bit flag   set and null oif list, or

           2 The Join/Prune message is being sent to the RPF
             neighbor toward the RP, there exists a (S,G) entry with the
             RPT-bit flag cleared and SPT-bit set, and the incoming
             interface toward S is different than the incoming interface
             toward the RP, or

           3 The Join/Prune message is being sent to the RPF
             neighbor toward the RP, and there exists a (*,G) entry and
             (S,G) entry for a directly connected source.

      5 The RP address (with RPT and WC bits set) is included in
        the prune list if:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward the RP and there exists a (*,G) entry with
             a null oif list (see Section 3.5.2).

      Triggered Join/Prune Messages:

      In addition to periodic messages, the following events will
      trigger Join/Prune messages if as a result, a) a new entry is
      created, or b) the oif list changes from null to non-null or non-
      null to null. The contents of triggered messages are the same as
      the periodic, described above.

      1 Receipt of an indication from IGMP that the state of
        directly-connected-membership has changed (i.e., new members
        have just joined `membership indication' or all members have

Top       Page 17 
        left), for a group G, may cause the last-hop router to build or
        modify corresponding (*,G) state.  When IGMP indicates that
        there are no longer directly connected members, the oif is
        removed from the oif list if the oif-timer is not running. A
        Join/Prune message is triggered if and only if a) a new entry is
        created, or b) the oif list changes from null to non-null or
        non-null to null, as follows:

           1 If the receiving router does not have a route entry
             for G the router creates a (*,G) entry, copies the oif list
             from the corresponding (*,*,RP) entry (if it exists), and
             includes the interface included in the IGMP membership
             indication in the oif list; as always, the router never
             includes the entry's iif in the oif list. The router sends
             a Join/Prune message towards the RP with the RP address and
             RPT-bit and WC-bits set in the join list. Or,

           2 If a (S,G)RPT-bit or (*,G) entry already exists, the
             interface included in the IGMP membership indication is
             added to the oif list (if it was not included already).

      2 Receipt of a Join/Prune message for (S,G), (*,G) or
        (*,*,RP) will cause building or modifying corresponding state,
        and subsequent triggering of upstream Join/Prune messages, in
        the following cases:

           1 When there is no current route entry, the RP address
             included in the Join/Prune message is checked against the
             local RP-Set information. If it matches, an entry will be
             created and the new entry will in turn trigger an upstream
             Join/Prune message. If the router has no RP-Set information
             it may discard the message, or optionally use the RP
             address included in the message.

           2 When the outgoing interface list of an (S,G)RPT-bit
             entry becomes null, the triggered Join/Prune message will
             contain S in the prune list.

           3 When there exists a (S,G)RPT-bit with null oif list,
             and an (*,G) Join/Prune message is received, the arriving
             interface is added to the oif list and a (*,G) Join/Prune
             message is triggered upstream.

           4 When there exists a (*,G) with null oif list, and a
             (*,*,RP) Join/Prune message is received, the receiving
             interface is added to the oif list and a (*,*,RP)
             Join/Prune message is triggered upstream.

Top       Page 18 
      3 Receipt of a packet that matches on a (S,G) entry whose
        SPT-bit is cleared triggers the following if the packet arrived
        on the correct incoming interface and there is a (*,G) or
        (*,*,RP) entry with a different incoming interface: a) the
        router sets the SPT-bit on the (S,G) entry, and b) the router
        sends a Join/Prune message towards the RP with S in the prune
        list and the RPT-bit set.

      4 Receipt of a packet at the DR from a directly connected
        source S, on the subnet containing the address S, triggers a
        Join/Prune message towards the RP with S in the prune list and
        the RPT-bit set under the following conditions: a) there is no
        matching (S,G) state, and b) there exists a (*,G) or (*,*,RP)
        for which the DR is not the RP.

      5 When a Join/Prune message is received for a group G, the
        prune list is checked. If the prune list contains a source or RP
        for which the receiving router has a corresponding active (S,G),
        (*,G) or (*,*,RP) entry, and whose iif is that on which the
        Join/Prune was received, then a join for (S,G), (*,G) or
        (*,*,RP) is triggered to override the prune, respectively. (This
        is necessary in the case of parallel downstream routers
        connected to a multi-access network.)

      6 When the RP fails, the RP will not be included in the
        Bootstrap messages sent to all routers in that domain. This
        triggers the DRs to send (*,G) Join/Prune messages towards the
        new RP for the group, as determined by the RP-Set and the hash
        function.  As described earlier, PMBRs trigger (*,*,RP) joins
        towards each RP in the RP-Set.

      7 When an entry's Join/Prune-Suppression timer expires, a
        Join/Prune message is triggered upstream corresponding to that
        entry, even if the outgoing interface has not transitioned
        between null and non-null states.

      8 When the RPF neighbor changes (whether due to an Assert or
        changes in unicast routing), the router sets a random delay
        timer (the Random-Delay-Join-Timer) whose expiration triggers
        sending of a Join/Prune message for the asserted route entry to
        the Assert winner (if the Join/Prune Suppression timer has
        expired.)

   We do not trigger prunes onto interfaces based on data packets.  Data
   packets that arrive on the wrong incoming interface are silently
   dropped.  However, on point-to-point interfaces triggered prunes may
   be sent as an optimization.

Top       Page 19 
   aragraphFragmentation It is possible that a Join/Prune message
   constructed according to the preceding rules could exceed the MTU of
   a network. In this case, the message can undergo semantic
   fragmentation whereby information corresponding to different groups
   can be sent in different messages.  However, if a Join/Prune message
   must be fragmented the complete prune list corresponding to a group G
   must be included in the same Join/Prune message as the associated
   RP-tree Join for G. If such semantic fragmentation is not possible,
   IP fragmentation should be used between the two neighboring hops.

3.2.2 Receiving  Join/Prune  Messages  When  a  router  receives
      Join/Prune message, it processes it as follows.

   The receiver of the Join/Prune notes the interface on which the PIM
   message arrived, call it I. The receiver then checks to see if the
   Join/Prune message was addressed to the receiving router itself
   (i.e., the router's address appears in the Unicast Upstream Neighbor
   Router field of the Join/Prune message).  (If the router is connected
   to a multiaccess LAN, the message could be intended for a different
   router.) If the Join/Prune is for this router the following actions
   are taken.

   For each group address G, in the Join/Prune message, the associated
   join list is processed as follows. We refer to each address in the
   join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit are
   both set. For each Sj in the join list of the Join/Prune message:

      1 If an address, Sj, in the join list of the Join/Prune
        message has the RPT-bit and WC-bit set, then Sj is the RP
        address used by the downstream router(s) and the following
        actions are taken:

           1 If Sj is not the same as the receiving router's RP
             mapping for G, the receiving router may ignore the
             Join/Prune message with respect to that group entry.  If
             the router does not have any RP-Set information, it may use
             the address Sj included in the Join/Prune message as the RP
             for the group.

           2 If Sj is the same as the receiving router's RP mapping
             for G, the receiving router adds I to the outgoing
             interface list of the (*,G) route entry (if there is no
             (*,G) entry, the router creates one first) and sets the
             Oif-timer for that interface to the Holdtime specified in
             the Join/Prune message. In addition, the Oif-Deletion-Delay
             for that interface is set to 1/3rd the Holdtime specified

Top       Page 20 
             in the Join/Prune message. If a (*,*,RP) entry exists, for
             the RP associated with G, then the oif list of the newly
             created (*,G) entry is copied from that (*,*,RP) entry.

           3 For each (Si,G) entry associated with group G: i) if
             Si is not included in the prune list, ii) if I is not on
             the same subnet as the address Si, and iii) if I is not the
             iif, then interface I is added to the oif list and the
             Oif-timer for that interface in each affected entry is
             increased (never decreased) to the Holdtime included in the
             Join/Prune message.  In addition, if the Oif-timer for that
             interface is increased, the Oif-Deletion-Delay for that
             interface is set to 1/3rd the Holdtime specified in the
             Join/Prune message.

             If the group address in the Join/Prune message is `*' then
             every (*,G) and (S,G) entry, whose group address hashes to
             the RP indicated in the (*,*,RP) Join/Prune message, is
             updated accordingly. A `*' in the group field of the
             Join/Prune is represented by a group address 224.0.0.0 and
             a group mask length of 4, indicating a (*,*,RP) Join.

           4 If the (Si,G) entry has its RPT-bit flag set to 1, and
             its oif list is the same as the (*,G) oif list, then the
             (Si,G)RPT-bit entry is deleted,

           5 The incoming interface is set to the interface used to
             send unicast packets to the RP in the (*,G) route entry,
             i.e., RPF interface toward the RP.

      2 For each address, Sj, in the join list whose RPT-bit and
        WC-bit are not set, and for which there is no existing (Sj,G)
        route entry, the router initiates one.  The router creates a
        (S,G) entry and copies all outgoing interfaces from the
        (S,G)RPT-bit entry, if it exists. If there is no (S,G) entry,
        the oif list is copied from the (*,G) entry; and if there is no
        (*,G) entry, the oif list is copied from the (*,*,RP) entry, if
        it exists. In all cases, the iif of the (S,G) entry is always
        excluded from the oif list.

           1 The outgoing interface for (Sj,G) is set to I.  The
             incoming interface for (Sj,G) is set to the interface used
             to send unicast packets to Sj (i.e., the RPF neighbor).

           2 If the interface used to reach Sj, is the same as I,
             this represents an error (or a unicast routing change) and
             the Join/Prune must not be processed.

Top       Page 21 
      3 For each address, Sj, in the join list of the Join/Prune
        message, for which there is an existing (Sj,G) route entry,

           1 If the RPT-bit is not set for Sj listed in the
             Join/Prune message, but the RPT-bit flag is set on the
             existing (Sj,G) entry, the router clears the RPT-bit flag
             on the (Sj,G) entry, sets the incoming interface to point
             towards Sj for that (Sj,G) entry, and sends a Join/Prune
             message corresponding to that entry through the new
             incoming interface; and

           2 If I is not the same as the existing incoming
             interface, the router adds I to the list of outgoing
             interfaces.

           3 The Oif-timer for I is increased (never decreased) to
             the Holdtime included in the Join/Prune message. In
             addition, if the Oif-timer for that interface is increased,
             the Oif-Deletion-Delay for that interface is set to 1/3rd
             the Holdtime specified in the Join/Prune message.

           4 The (Sj,G) entry's SPT bit is cleared until data comes
             down the shortest path tree.

      For each group address G, in the Join/Prune message, the
      associated prune list is processed as follows. We refer to each
      address in the prune list as Sp; Sp refers to the RP if the RPT-
      bit and WC-bit are both set. For each Sp in the prune list of the
      Join/Prune message:

      1 For each address, Sp, in the prune list whose RPT-bit and
        WC-bit are cleared:

           1 If there is an existing (Sp,G) route entry, the router
             lowers the entry's Oif-timer for I to its Oif-Deletion-
             Delay, allowing for other downstream routers on a multi-
             access LAN to override the prune. However, on point-to-
             point links, the oif-timer is expired immediately.

           2 If the router has a current (*,G), or (*,*,RP), route
             entry, and if the existing (Sp,G) entry has its RPT-bit
             flag set to 1, then this (Sp,G)RPT-bit entry is maintained
             (not deleted) even if its outgoing interface list is null.

      2 For each address, Sp, in the prune list whose RPT-bit is
        set and whose WC-bit cleared:

Top       Page 22 
           1 If there is an existing (Sp,G) route entry, the router
             lowers the entry's Oif-timer for I to its Oif-Deletion-
             Delay, allowing for other downstream routers on a multi-
             access LAN to override the prune. However, on point-to-
             point links, the oif-timer is expired immediately.

           2 If the router has a current (*,G), or (*,*,RP), route
             entry, and if the existing (Sp,G) entry has its RPT-bit
             flag set to 1, then this (Sp,G)RPT-bit entry is not
             deleted, and the Entry-timer is restarted, even if its
             outgoing interface list is null.

           3 If (*,G), or corresponding (*,*,RP), state exists, but
             there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is created
             . The outgoing interface list is copied from the (*,G), or
             (*,*,RP), entry, with the interface, I, on which the prune
             was received, is deleted.  Packets from the pruned source,
             Sp, match on this state and are not forwarded toward the
             pruned receivers.

           4 If there exists a (Sp,G) entry, with or without the
             RPT-bit set, the oif-timer for I is expired, and the
             Entry-timer is restarted.

      3 For each address, Sp, in the prune list whose RPT-bit and
        WC-bit are both set:

           1 If there is an existing (*,G) entry, with Sp as the RP
             for G, the router lowers the entry's Oif-timer for I to its
             Oif-Deletion-Delay, allowing for other downstream routers
             on a multi-access LAN to override the prune. However, on
             point-to-point links, the oif-timer is expired immediately.

           2 If the corresponding (*,*,RP) state exists, but there
             is no (*,G) entry, a (*,G) entry is created. The outgoing
             interface list is copied from (*,*,RP) entry, with the
             interface, I, on which the prune was received, deleted.

           For any new (S,G), (*,G) or (*,*,RP) entry created by an
           incoming Join/Prune message, the SPT-bit is cleared (and if a
           Join/Prune-Suppression timer is used, it is left off.)

   If the entry has a Join/Prune-Suppression timer associated with it,
   and if the received Join/Prune does not indicate the router as its
   target, then the receiving router examines the join and prune lists
   to see if any addresses in the list `completely-match' existing
   (S,G), (*,G), or (*,*,RP) state for which the receiving router
   currently schedules Join/Prune messages. An element on the join or

Top       Page 23 
   prune list `completely-matches' a route entry only if both the
   addresses and RPT-bit flag are the same.  If the incoming Join/Prune
   message completely matches an existing (S,G), (*,G), or (*,*,RP)
   entry and the Join/Prune arrived on the iif for that entry, then the
   router compares the Holdtime included in the Join/Prune message, to
   its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is
   lower, the Join/Prune-Suppression-timer is started at the
   [Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime] is
   equal, the tie is resolved in favor of the Join/Prune Message
   originator that has the higher network layer address.  When the
   Join/Prune timer expires, the router triggers a Join/Prune message
   for the corresponding entry(ies).

3.3 Register and Register-Stop

   When a source first starts sending to a group its packets are
   encapsulated in Register messages and sent to the RP. If the data
   rate warrants source-specific paths, the RP sets up source specific
   state and starts sending (S,G) Join/Prune messages toward the source,
   with S in the join list.

3.3.1 Sending Registers and Receiving Register-Stops

   Register messages are sent as follows:

      1 When a DR receives a packet from a directly connected
        source, S, on the subnet containing the address S,

           1 If there is no corresponding (S,G) entry, and the
             router has RP-Set information, and the DR is not the RP for
             G, the DR creates an (S,G) entry with the Register-
             Suppression-timer turned off and the RP address set
             according to the hash function mapping for the
             corresponding group. The oif list is copied from existing
             (*,G) or (*,*,RP) entries, if they exist. The iif of the
             (S,G) entry is always excluded from the oif list. If there
             exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune
             message towards the RP with S in the prune list and the
             RPT-bit set.

           2 If there is a (S,G) entry in existence, the DR simply
             restarts the corresponding Entry-timer.

           When a PMBR (e.g., a router that connects the PIM-SM region
           to a dense mode region running DVMRP or PIM-DM) receives a
           packet from a source in the dense mode region, the router

Top       Page 24 
           treats the packet as if it were from a directly connected
           source. A separate document will describe the details of
           interoperability.

      2 If the new or previously-existing (S,G) entry's Register-
        Suppression-timer is not running, the data packet is
        encapsulated in a Register message and unicast to the RP for
        that group. The data packet is also forwarded according to (S,G)
        state in the DR if the oif list is not null; since a receiver
        may join the SP-tree while the DR is still registering to the
        RP.

      3 If the (S,G) entry's Register-Suppression-timer is running,
        the data packet is not sent in a Register message, it is just
        forwarded according to the (S,G) oif list.

   When the DR receives a Register-Stop message, it restarts the
   Register-Suppression-timer in the corresponding (S,G) entry(ies) at
   [Register-Suppression-Timeout] seconds. If there is data to be
   registered, the DR may send a null Register (a Register message with
   a zero-length data portion in the inner packet) to the RP, [Probe-
   Time] seconds before the Register-Suppression-timer expires, to avoid
   sending occasional bursts of traffic to an RP unnecessarily.

3.3.2 Receiving Register Messages and Sending Register-Stops

   When a router (i.e., the RP) receives a Register message, the router
   does the following:

      1 Decapsulates the data packet, and checks for a
        corresponding (S,G) entry.

           1 If a (S,G) entry with cleared (0) SPT bit exists, and
             the received Register does not have the Null-Register-Bit
             set to 1, the packet is forwarded; and the SPT bit is left
             cleared (0). If the SPT bit is 1, the packet is dropped,
             and Register-Stop messages are triggered.  Register-Stops
             should be rate-limited (in an implementation-specific
             manner) so that no more than a few are sent per round trip
             time. This prevents a high datarate stream of packets from
             triggering a large number of Register-Stop messages between
             the time that the first packet is received and the time
             when the source receives the first Register-Stop.

           2 If there is no (S,G) entry, but there is a (*,G)
             entry, and the received Register does not have the Null-
             Register-Bit set to 1, the packet is forwarded according to
             the (*,G) entry.

Top       Page 25 
           3 If there is a (*,*,RP) entry but no (*,G) entry, and
             the Register received does not have the Null-Register-Bit
             set to 1, a (*,G) or (S,G) entry is created and the oif
             list is copied from the (*,*,RP) entry to the new entry.
             The packet is forwarded according to the created entry.

           4 If there is no G or (*,*,RP) entry corresponding to G,
             the packet is dropped, and a Register-Stop is triggered.

           5 A "Border bit" bit is added to the Register message,
             to  facilitate  interoperability mechanisms. PMBRs set this
             bit when   registering for  external  sources  (see Section
             2.7).  If  the  "Border bit" is set in the Register,
             the   RP does the following:

                1 If there is no matching (S,G) state, but there
                  exists (*,G) or (*,*,RP) entry, the RP creates a (S,G)
                  entry, with a `PMBR' field.  This field holds the
                  source of the Register (i.e. the outer network layer
                  address of the register packet).  The RP triggers a
                  (S,G) join towards the source of the data packet, and
                  clears the SPT bit for the (S,G) entry. If the
                  received Register is not a `null Register' the packet
                  is forwarded according to the created state. Else,

                2 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, and
                  the received Register is not a `null Register', the
                  decapsulated packet is forwarded to the oif list of
                  that entry. Else,

                3 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, the
                  decapsulated packet is forwarded to the oif list of
                  that entry, else

                4 The packet is dropped, and a Register-stop is
                  triggered towards the source of the Register.

        The (S,G) Entry-timer is restarted by Registers arriving from
        that source to that group.

      2 If the matching (S,G) or (*,G) state contains a null oif
        list, the RP unicasts a Register-Stop message to the source of
        the Register message; in the latter case, the source-address
        field, within the Register-Stop message, is set to the wildcard

Top       Page 26 
        value (all 0's). This message is not processed by intermediate
        routers, hence no (S,G) state is constructed between the RP and
        the source.

      3 If the Register message arrival rate warrants it and there
        is no existing (S,G) entry, the RP sets up a (S,G) route entry
        with the outgoing interface list, excluding iif(S,G), copied
        from the (*,G) outgoing interface list, its SPT-bit is
        initialized to 0. If a (*,G) entry does not exist, but there
        exists a (*,*,RP) entry with the RP corresponding to G , the oif
        list for (S,G) is copied - excluding the iif - from that
        (*,*,RP) entry.

        A timer (Entry-timer) is set for the (S,G) entry and this timer
        is restarted by receipt of data packets for (S,G).  The (S,G)
        entry causes the RP to send a Join/Prune message for the
        indicated group towards the source of the register message.

        If the (S,G) oif list becomes null, Join/Prune messages will not
        be sent towards the source, S.

3.4 Multicast Data Packet Forwarding

   Processing a multicast data packet involves the following steps:

      1 Lookup route state based on a longest match of the source
        address, and an exact match of the destination address in the
        data packet. If neither S, nor G, find a longest match entry,
        and the RP for the packet's destination group address has a
        corresponding (*,*,RP) entry, then the longest match does not
        require an exact match on the destination group address. In
        summary, the longest match is performed in the following order:
        (1) (S,G), (2) (*,G). If neither is matched, then a lookup is
        performed on (*,*,RP) entries.

      2 If the packet arrived on the interface found in the
        matching-entry's iif field, and the oif list is not null:

           1 Forward the packet to the oif list for that entry,
             excluding the subnet containing S, and restart the Entry-
             timer if the matching entry is (S,G).  Optionally, the
             (S,G) Entry-timer may be restarted by periodic checking of
             the matching packet count.

Top       Page 27 
           2 If the entry is a (S,G) entry with a cleared SPT-bit,
             and a (*,G) or associated (*,*,RP) also exists whose
             incoming interface is different than that for (S,G), set
             the SPT-bit for the (S,G) entry and trigger an (S,G) RPT-
             bit prune towards the RP.

           3 If the source of the packet is a directly-connected
             host and the router is the DR on the receiving interface,
             check the Register-Suppression-timer associated with the
             (S,G) entry. If it is not running, then the router
             encapsulates the data packet in a register message and
             sends it to the RP.

             This covers the common case of a packet arriving on the RPF
             interface to the source or RP and being forwarded to all
             joined branches. It also detects when packets arrive on the
             SP-tree, and triggers their pruning from the RP-tree. If it
             is the DR for the source, it sends data packets
             encapsulated in Registers to the RPs.

           3 If the packet matches to an entry but did not arrive on the
             interface found in the entry's iif field, check the SPT-bit
             of the entry. If the SPT-bit is set, drop the packet.  If
             the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP),
             entry for G. If the packet arrived on the iif found in
             (*,G), or the corresponding (*,*,RP), forward the packet to
             the oif list of the matching entry. This covers the case
             when a data packet matches on a (S,G) entry for which the
             SP-tree has not yet been completely established upstream.

           4 If the packet does not match any entry, but the source of
             the data packet is a local, directly-connected host, and
             the router is the DR on a multi-access LAN and has RP-Set
             information, the DR uses the hash function to determine the
             RP associated with the destination group, G. The DR creates
             a (S,G) entry, with the Register-Suppression-timer not
             running, encapsulates the data packet in a Register message
             and unicasts it to the RP.

           5 If the packet does not match to any entry, and it is not a
             local host or the router is not the DR, drop the packet.

3.4.1 Data triggered switch to shortest path tree (SP-tree)

   Different criteria can be applied to trigger switching over from the
   RP-based shared tree to source-specific, shortest path trees.

Top       Page 28 
   One proposed example is to do so based on data rate.  For example,
   when a (*,G), or corresponding (*,*,RP), entry is created, a data
   rate counter may be initiated at the last-hop routers.  The counter
   is incremented with every data packet received for directly connected
   members of an SM group, if the longest match is (*,G) or (*,*,RP). If
   and when the data rate for the group exceeds a certain configured
   threshold (t1), the router initiates `source-specific' data rate
   counters for the following data packets. Then, each counter for a
   source, is incremented when packets matching on (*,G), or (*,*,RP),
   are received from that source. If the data rate from the particular
   source exceeds a configured threshold (t2), a (S,G) entry is created
   and a Join/Prune message is sent towards the source.  If the RPF
   interface for (S,G) is not the same as that for (*,G) -or (*,*,RP),
   then the SPT-bit is cleared in the (S,G) entry.

   Other configured rules may be enforced to cause or prevent
   establishment of (S,G) state.

3.5 Assert

   Asserts are used to resolve which of the parallel routers connected
   to a multi-access LAN is responsible for forwarding packets onto the
   LAN.

3.5.1 Sending Asserts

   The following Assert rules are provided when a multicast packet is
   received on an outgoing multi-access interface "I" of an existing
   active (S,G), (*,G) or (*,*,RP) entry:

      1 Do unicast routing table lookup on source address from data
        packet, and send assert on interface "I" for source address in
        data packet; include metric preference of routing protocol and
        metric from routing table lookup.

      2 If route is not found, use metric preference of 0x7fffffff
        and metric 0xffffffff.

   When an assert is sent for a (*,G) entry, the first bit in the metric
   preference (the RPT-bit) is set to 1, indicating the data packet is
   routed down the RP-tree.

   Asserts should be rate-limited in an implementation-specific manner.

Top       Page 29 
3.5.2 Receiving Asserts

   When an Assert is received the router performs a longest match on the
   source and group address in the Assert message, only active entries
   -- that have packet forwarding state -- are matched.  The router
   checks the first bit of the metric preference (RPT-bit).

      1 If the RPT-bit is set, the router first does a match on
        (*,G), or (*,*,RP), entries; if no matching entry is found, it
        ignores the Assert.

      2 If the RPT-bit is not set in the Assert, the router first
        does a match on (S,G) entries; if no matching entry is found,
        the router matches (*,G) or (*,*,RP) entries.

      Receiving Asserts on an entry's outgoing interface:

      If the interface that received the Assert message is in the oif
      list of the matched entry, then this Assert is processed by this
      router as follows:

      1 If the Assert's RPT-bit is set and the matching entry is
        (*,*,RP), the router creates a (*,G) entry. If the Assert's
        RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP),
        the router creates a (S,G)RPT-bit entry.  Otherwise, no new
        entry is created in response to the Assert.

      2 The router then compares the metric values received in the
        Assert with the metric values associated with the matched entry.
        The RPT-bit and metric preference (in that order) are treated as
        the high-order part of an Assert metric comparison. If the value
        in the Assert is less than the router's value (with ties broken
        by the IP address, where higher network layer address wins),
        delete the interface from the entry. When the deletion occurs
        for a (*,G) or (*,*,RP) entry , the interface is also deleted
        from any associated (S,G)RPT-bit or (*,G) entries, respectively.
        The Entry-timer for the affected entries is restarted.

      3 If the router has won the election the router keeps the
        interface in its outgoing interface list. It acts as the
        forwarder for the LAN.

   The winning router sends an Assert message containing its own metric
   to that outgoing interface. This will cause other routers on the LAN
   to prune that interface from their route entries. The winning router
   sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit
   entry was matched.

Top       Page 30 
   Receiving Asserts on an entry's incoming interface

   If the Assert arrived on the incoming interface of an existing (S,G),
   (*,G), or (*,*,RP) entry, the Assert is processed as follows.  If the
   Assert message does not match the entry, exactly, it is ignored; i.e,
   longest-match is not used in this case. If the Assert message does
   match exactly, then:

      1 Downstream routers will select the upstream router with the
        smallest metric preference and metric as their RPF neighbor. If
        two metrics are the same, the highest network layer address is
        chosen to break the tie. This is important so that downstream
        routers send subsequent Joins/Prunes (in SM) to the correct
        neighbor. An Assert-timer is initiated when changing the RPF
        neighbor to the Assert winner.  When the timer expires, the
        router resets its RPF neighbor according to its unicast routing
        tables to capture network dynamics and router failures.

      2 If the downstream routers have downstream members, and if
        the Assert caused the RPF neighbor to change, the downstream
        routers must trigger a Join/Prune message to inform the upstream
        router that packets are to be forwarded on the multi-access
        network.

3.6 Candidate-RP-Advertisements and Bootstrap messages

   Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages
   unicast to the BSR by those routers that are configured as
   Candidate-RPs (C-RPs).

   Bootstrap messages are periodic PIM messages originated by the
   Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to
   distribute the current RP-set to all routers in that domain.

   The Bootstrap messages also support a simple mechanism by which the
   Candidate BSR (C-BSR) with the highest BSR-priority and address
   (referred to as the preferred BSR) is elected as the BSR for the
   domain.  We recommend that each router configured as a C-RP also be
   configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined
   function of Bootstrap messages as the vehicle for BSR election and
   RP-Set distribution.

   A Finite State Machine description of the BSR election and RP-Set
   distribution mechanisms is included in Appendix II.

Top       Page 31 
3.6.1 Sending Candidate-RP-Advertisements

   C-RPs periodically unicast C-RP-Advs to the BSR for that domain.  The
   interval for sending these messages is subject to local configuration
   at the C-RP.

   Candidate-RP-Advertisements carry group address and group mask
   fields.  This enables the advertising router to limit the
   advertisement to certain prefixes or scopes of groups.  The
   advertising router may enforce this scope acceptance when receiving
   Registers or Join/Prune messages.  C-RPs should send C-RP-Adv
   messages with the `Priority' field set to `0'.

3.6.2 Receiving C-RP-Advs and Originating Bootstrap

   Upon receiving a C-RP-Adv, a router does the following:

      1 If the router is not the elected BSR, it ignores the
        message, else

      2 The BSR adds the RP address to its local pool of candidate
        RPs, according to the associated group prefix(es) in the C-RP-
        Adv message. The Holdtime in the C-RP-Adv message is also stored
        with the corresponding RP, to be included later in the Bootstrap
        message. The BSR may apply a local policy to limit the number of
        Candidate RPs included in the Bootstrap message.  The BSR may
        override the prefix indicated in a C-RP-Adv unless the
        `Priority' field is not zero.

   The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer is
   initialized to the Holdtime in the RP's C-RP-Adv. When the timer
   expires, the corresponding RP is removed from the RP-set.  The RP-
   timer is restarted by the C-RP-Advs from the corresponding RP.

   The BSR also uses its Bootstrap-timer to periodically send Bootstrap
   messages.  In particular, when the Bootstrap-timer expires, the BSR
   originates a Bootstrap message on each of its PIM interfaces. To
   reduce the bootstrap message overhead during partition healing, the
   BSR should set a random time (as a function of the priority and
   address) after which the Bootstrap message is originated only if no
   other preferred Bootstrap message is received. For details see
   appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM-
   ROUTERS' group.  In steady state, the BSR originates Bootstrap
   messages periodically.  At startup, the Bootstrap-timer is
   initialized to [Bootstrap-Timeout], causing the first Bootstrap
   message to be originated only when and if the timer expires. For

Top       Page 32 
   timer details, see Section 3.6.3. A DR unicasts a Bootstrap message
   to each new PIM neighbor, i.e., after the DR receives the neighbor's
   Hello message (it does so even if the new neighbor becomes the DR).

   The Bootstrap message is subdivided into sets of group-prefix,RP-
   Count,RP-addresses.  For each RP-address, the corresponding Holdtime
   is included in the "RP-Holdtime" field.  The format of the Bootstrap
   message allows `semantic fragmentation', if the length of the
   original Bootstrap message exceeds the packet maximum boundaries (see
   Section 4). However, we recommend against configuring a large number
   of routers as C-RPs, to reduce the semantic fragmentation required.

3.6.3 Receiving and Forwarding Bootstrap

   Each router keeps a Bootstrap-timer, initialized to [Bootstrap-
   Timeout] at startup.

   When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS'
   group, it performs the following:

      1 If the message was not sent by the RPF neighbor towards the
        BSR address included, the message is dropped. Else

      2 If the included BSR is not preferred over, and not equal
        to, the currently active BSR:

           1 If the Bootstrap-timer has not yet expired, or if the
             receiving router is a C-BSR, then the Bootstrap message is
             dropped. Else

           2 If the Bootstrap-timer has expired and the receiving
             router is not a C-BSR, the receiving router stores the RP-
             Set and BSR address and priority found in the message, and
             restarts the timer by setting it to [Bootstrap-Timeout].
             The Bootstrap message is then forwarded out all PIM
             interfaces, excluding the one over which the message
             arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.

      3 If the Bootstrap message includes a BSR address that is
        preferred over, or equal to, the currently active BSR, the
        router restarts its Bootstrap-timer at [Bootstrap-Timeout]
        seconds. and stores the BSR address and RP-Set information.

        The Bootstrap message is then forwarded out all PIM interfaces,
        excluding the one over which the message arrived, to `ALL-PIM-
        ROUTERS' group, with a TTL of 1.

Top       Page 33 
      4 If the receiving router has no current RP set information
        and the Bootstrap was unicast to it from a directly connected
        neighbor, the router stores the information as its new RP-set.
        This covers the startup condition when a newly booted router
        obtains the RP-Set and BSR address from its DR.

   When a router receives a new RP-Set, it checks if each of the RPs
   referred to by existing state (i.e., by (*,G), (*,*,RP), or
   (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the
   new RP-set, that RP is considered unreachable and the hash algorithm
   (see below) is re-performed for each group with locally active state
   that previously hashed to that RP. This will cause those groups to be
   distributed among the remaining RPs. When the new RP-Set contains a
   new RP, the value of the new RP is calculated for each group covered
   by that C-RP's Group-prefix.  Any group for which the new RP's value
   is greater than the previously active RP's value is switched over to
   the new RP.

3.7 Hash Function

   The hash function is used by all routers within a domain, to map a
   group to one of the C-RPs from the RP-Set. For a particular group, G,
   the hash function uses only those C-RPs whose Group-prefix covers G.
   The algorithm takes as input the group address, and the addresses of
   the Candidate RPs, and gives as output one RP address to be used.

   The protocol requires that all routers hash to the same RP within a
   domain (except for transients). The following hash function must be
   used in each router:

      1 For RP addresses in the RP-Set, whose Group-prefix covers
        G, select the RPs with the highest priority (i.e. lowest
        `Priority' value), and compute a value:

   Value(G,M,C(i))=
   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

        where C_i is the RP address and M is a hash-mask included in
        Bootstrap messages.  The hash-mask allows a small number of
        consecutive groups (e.g., 4) to always hash to the same RP. For
        instance, hierarchically-encoded data can be sent on consecutive
        group addresses to get the same delay and fate-sharing
        characteristics.

        For address families other than IPv4, a 32-bit digest to be used
        as C_i must first be derived from the actual RP address. Such a
        digest method must be used consistently throughout the PIM

Top       Page 34 
        domain. For IPv6 addresses, we recommend using the equivalent
        IPv4 address for an IPv4-compatible address, and the CRC-32
        checksum [7] of all other IPv6 addresses.

      2 From the RPs with the highest priority (i.e.  lowest
        `Priority' value), the candidate with the highest resulting
        value is then chosen as the RP for that group, and its identity
        and hash value are stored with the entry created.

        Ties between RPs having the same hash value and priority, are
        broken in advantage of the highest address.

   The hash function algorithm is invoked by a DR, upon reception of a
   packet, or IGMP membership indication, for a group, for which the DR
   has no entry. It is invoked by any router that has (*,*,RP) state
   when a packet is received for which there is no corresponding (S,G)
   or (*,G) entry.  Furthermore, the hash function is invoked by all
   routers upon receiving a (*,G) or (*,*,RP) Join/Prune message.

3.8 Processing Timer Events

   In this subsection, we enumerate all timers that have been discussed
   or implied. Since some critical timer events are not associated with
   the receipt or sending of messages, they are not fully covered by
   earlier subsections.

   Timers are implemented in an implementation-specific manner. For
   example, a timer may count up or down, or may simply expire at a
   specific time. Setting a timer to a value T means that it will expire
   after T seconds.

3.8.1 Timers related to tree maintenance

   Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers
   associated with it: one for each interface in the outgoing interface
   list, one for the multicast routing entry itself, and one optional
   Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an
   Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In
   addition, DR's have a Register-Suppression-timer for each (S,G) entry
   and every router has a single Join/Prune-timer. (A router may
   optionally keep separate Join/Prune-timers for different interfaces
   or route entries if different Join/Prune periods are desired.)

     *    [Join/Prune-Timer] This timer is used for periodically
          sending aggregate Join/Prune messages.  To avoid
          synchronization among routers booting simultaneously, it is
          initially set to a random value between 1 and [Join/Prune-
          Period].  When it expires, the timer is immediately restarted

Top       Page 35 
          to [Join/Prune-Period]. A Join/Prune message is then sent out
          each interface.  This timer should not be restarted by other
          events.

     *    [Join/Prune-Suppression-Timer (kept per route entry)] A
          route entry's (optional) Join/Prune-Suppression-Timer may be
          used to suppress duplicate joins from multiple downstream
          routers on the same LAN. When a Join message is received from
          a neighbor on the entry's incoming interface in which the
          included Holdtime is higher than the router's own
          [Join/Prune-Holdtime] (with ties broken by higher network
          layer address), the timer is set to [Join/Prune-Suppression-
          Timeout], with some random jitter introduced to avoid
          synchronization of triggered Join/Prune messages on
          expiration. (The random timeout value must be < 1.5 *
          [Join/Prune-Period] to prevent losing data after 2 dropped
          Join/Prunes.)  The timer is restarted every time a subsequent
          Join/Prune message (with higher Holdtime/IP address) for the
          entry is received on its incoming interface.  While the timer
          is running, Join/Prune messages for the entry are not sent.
          This timer is idle (not running) for point-to-point links.

     *    [Oif-Timer (kept per oif for each route entry)] A timer for
          each oif of a route entry is used to time out that oif.
          Because some of the outgoing interfaces in an (S,G) entry are
          copied from the (*,G) outgoing interface list, they may not
          have explicit (S,G) join messages from some of the downstream
          routers (i.e., where members are joining to the (*,G) tree
          only). Thus, when an Oif-timer is restarted in a (*,G) entry,
          the Oif-timer is restarted for that interface in each existing
          (S,G) entry whose oif list contains that interface. The same
          rule applies to (*,G) and (S,G) entries when restarting an
          Oif-timer on a (*,*,RP) entry.

          The following table shows its usage when first adding the oif
          to the entry's oiflist, when it should be restarted (unless it
          is already higher), and when it should be decreased (unless it
          is already lower).

Set to                   | When                         | Applies  to
included Holdtime        | adding oif off Join/Prune    | (S,G) (*,G)
                         |                              | (*,*,RP)

Increased (only) to      | When                         | Applies to
included  Holdtime       | received Join/Prune          | (S,G) (*,G)
                         |                              | (*,*,RP)
(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G)
(*,G)  oif-timer  value  | (*,G) oif-timer restarted    | (S,G)

Top       Page 36 
          When the timer expires, the oif is removed from the oiflist if
          there are no directly-connected members. When deleted, the oif
          is also removed in any associated (S,G) or (*,G) entries.

     *    [Entry-Timer (kept per route entry)] A timer for each route
          entry is used to time out that entry. The following table
          summarizes its usage when first adding the oif to the entry's
          oiflist, and when it should be restarted (unless it is already
          higher).

Set to                | When                     | Applies to
[Data-Timeout]        | created off data packet  | (S,G)
included Holdtime     | created off Join/Prune   | (S,G) (*,G) (*,*,RP)

Increased (only) to   | When                     | Applies to
[Data-Timeout]        | receiving  data  packets | (S,G)no RPT-bit
oif-timer value       | any oif-timer restarted  | (S,G)RPT-bit (*,G)
                      |                          | (*,*,RP)
[Assert-Timeout]      | assert received          | (S,G)RPT-bit (*,G)
                      |                          | w/null oif

          When the timer expires, the route entry is deleted; if the
          entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT-
          bit entries are also deleted.

     *    [Register-Suppression-Timer (kept per (S,G) route entry)]
          An (S,G) route entry's Register-Suppression-Timer is used to
          suppress registers when the RP is receiving data packets
          natively. When a Register-Stop message for the entry is
          received from the RP, the timer is set to a random value in
          the range 0.5 * [Register-Suppression-Timeout] to 1.5 *
          [Register-Suppression-Timeout]. While the timer is running,
          Registers for that entry will be suppressed.  If null
          registers are used, a null register is sent [Probe-Time]
          seconds before the timer expires.

     *    [Assert-Timer (per (S,G) or (*,G) route entry)] The
          Assert-Timer for an (S,G) or (*,G) route entry is used for
          timing out Asserts received. When an Assert is received and
          the RPF neighbor is changed to the Assert winner, the Assert-
          Timer is set to [Assert-Timeout], and is restarted to this
          value every time a subsequent Assert for the entry is received
          on its incoming interface. When the timer expires, the router
          resets its RPF neighbor according to its unicast routing
          table.

Top       Page 37 
     *    [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)]
          The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry
          is used to prevent synchronization among downstream routers on
          a LAN when their RPF neighbor changes. When the RPF neighbor
          changes, this timer is set to a random value between 0 and
          [Random-Delay-Join-Timeout] seconds. When the timer expires, a
          triggered Join/Prune message is sent for the entry unless its
          Join/Prune-Suppression-Timer is running.

3.8.2 Timers relating to neighbor discovery

     *    [Hello-Timer] This timer is used to periodically send Hello
          messages. To avoid synchronization among routers booting
          simultaneously, it is initially set to a random value between
          1 and [Hello-Period]. When it expires, the timer is
          immediately restarted to [Hello-Period]. A Hello message is
          then sent out each interface. This timer should not be
          restarted by other events.

     *    [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for
          each neighbor is used to time out the neighbor state. When a
          Hello message is received from a new neighbor, the timer is
          initially set to the Holdtime included in the Hello message
          (which is equal to the neighbor's value of [Hello-Holdtime]).
          Every time a subsequent Hello is received from that neighbor,
          the timer is restarted to the Holdtime in the Hello.  When the
          timer expires, the neighbor state is removed.

3.8.3 Timers relating to RP information

     *    [C-RP-Adv-Timer (C-RP's only)] Routers configured as
          candidate RP's use this timer to periodically send C-RP-Adv
          messages. To avoid synchronization among routers booting
          simultaneously, the timer is initially set to a random value
          between 1 and [C-RP-Adv-Period]. When it expires, the timer is
          immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv message
          is then sent to the elected BSR. This timer should not be
          restarted by other events.

     *    [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a
          timer per RP in the RP-Set to monitor liveness. When a C-RP is
          added to the RP-Set, its timer is set to the Holdtime included
          in the C-RP-Adv message from that C-RP (which is equal to the
          C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP-
          Adv is received from that RP, its timer is restarted to the
          Holdtime in the C-RP-Adv. When the timer expires, the RP is
          removed from the RP-Set included in Bootstrap messages.

Top       Page 38 
     *    [Bootstrap-Timer] This timer is used by the BSR to
          periodically originate Bootstrap messages, and by other
          routers to time out the BSR (see 3.6.3).  This timer is
          initially set to [Bootstrap-Timeout]. A C-BSR restarts this
          timer to [Bootstrap-Timeout] upon receiving a Bootstrap
          message from a preferred router, and originates a Bootstrap
          message and restarts the timer to [Bootstrap-Period] when it
          expires.  Routers not configured as C-BSR's restart this timer
          to [Bootstrap-Timeout] upon receiving a Bootstrap message from
          the elected or a more preferred BSR, and ignore Bootstrap
          messages from non-preferred C-BSRs while it is running.

3.8.4 Default timer values

   Most of the default timeout values for state information are 3.5
   times the refresh period. For example, Hellos refresh Neighbor state
   and the default Hello-timer period is 30 seconds, so a default
   Neighbor-timer duration of 105 seconds is included in the Holdtime
   field of the Hellos. In order to improve convergence, however, the
   default timeout value for information related to RP liveness and
   Bootstrap messages is 2.5 times the refresh period.

   In this version of the spec, we suggest particular numerical timer
   settings.  A future version of the specification will specify a
   mechanism for timer values to be scaled based upon observed network
   parameters.

     *    [Join/Prune-Period] This is the interval between
          sending Join/Prune messages. Default: 60 seconds. This value
          may be set to take into account such things as the configured
          bandwidth and expected average number of multicast route
          entries for the attached network or link (e.g., the period
          would be longer for lower-speed links, or for routers in the
          center of the network that expect to have a larger number of
          entries). In addition, a router could modify this value (and
          corresponding Join/Prune-Holdtime value) if the number of
          route entries changes significantly (e.g., by an order of
          magnitude).  For example, given a default minimum Join/Prune-
          Period value, if the number of route entries with a particular
          iif increases from N to N*100, the router could increase its
          Join/Prune-Period (and Join/Prune-Holdtime), for that
          interface, by a factor of 10; and if/when the number of
          entries decreases back to N, the Join/Prune-Period (and
          Join/Prune-Holdtime) could be decreased to its previous value.
          If the Join/Prune-Period is modified, these changes should be
          made relatively infrequently and the router should continue to
          refresh at its previous Join/Prune-Period for at least
          Join/Prune-Holdtime, in order to allow the upstream router to

Top       Page 39 
          adapt.

     *    [Join-Prune Holdtime] This is the Holdtime specified in
          Join/Prune messages, and is used to time out oifs. This should
          be set to 3.5 * [Join/Prune-Period].  Default: 210 seconds.

     *    [Join/Prune-Suppression-Timeout] This is the mean
          interval between receiving a Join/Prune with a higher Holdtime
          (with ties broken by higher network layer address) and
          allowing duplicate Join/Prunes to be sent again. This should
          be set to approximately 1.25 * [Join/Prune-Period].  Default:
          75 seconds.

     *    [Data-Timeout] This is the time after which (S,G) state
          for a silent source will be deleted.  Default: 210 seconds.

     *    [Register-Suppression-Timeout] This is the mean
          interval between receiving a Register-Stop and allowing
          Registers to be sent again.  A lower value means more frequent
          register bursts at RP, while a higher value means longer join
          latency for new receivers.  Default: 60 seconds.  (Note that
          if null Registers are sent [Probe-Time] seconds before the
          timeout, register bursts are prevents, and [Register-
          Suppression-Timeout] may be lowered to decrease join latency.)

     *    [Probe-Time] When null Registers are used, this is the
          time between sending a null Register and the Register-
          Suppression-Timer expiring unless it is restarted by receiving
          a Register-Stop. Thus, a null Register would be sent when the
          Register-Suppression-Timer reaches this value.  Default: 5
          seconds.

     *    [Assert-Timeout] This is the interval between the last
          time an Assert is received, and the time at which the assert
          is timed out.  Default: 180 seconds.

     *    [Random-Delay-Join-Timeout] This is the maximum
          interval between the time when the RPF neighbor changes, and
          the time at which a triggered Join/Prune message is sent.
          Default: 4.5 seconds.

     *    [Hello-Period] This is the interval between sending
          Hello messages.  Default: 30 seconds.

     *    [Hello-Holdtime] This is the Holdtime specified in
          Hello messages, after which neighbors will time out their
          neighbor entries for the router. This should be set to 3.5 *
          [Hello-Period]. Default: 105 seconds.

Top       Page 40 
     *    [C-RP-Adv-Period] For C-RPs, this is the interval
          between sending C-RP-Adv messages. Default: 60 seconds.

     *    [RP-Holdtime] For C-RPs, this is the Holdtime specified
          in C-RP-Adv messages, and is used by the BSR to time out RPs.
          This should be set to 2.5 * [C-RP-Adv-Period].  Default: 150
          seconds.

     *    [Bootstrap-Period] At the elected BSR, this is the
          interval between originating Bootstrap messages, and should be
          equal to 60 seconds.

     *    [Bootstrap-Timeout] This is the time after which the
          elected BSR will be assumed unreachable when Bootstrap
          messages are not received from it. This should be set to `2 *
          [Bootstrap-Period] + 10'. Default: 130 seconds.

3.9 Summary of flags used

   Following is a summary of all the flags used in our scheme.

Bit           | Used in     | Definition

Border        | Register    | Register for external sources is coming
                              from PIM multicast  border  router
Null          | Register    | Register sent as Probe of RP, the
                              encapsulated IP data packet should not
                              be forwarded
RPT           | Route entry | Entry represents state on the RP-tree
RPT           | Join/Prune  | Join is associated with the shared tree and
                              therefore the Join/Prune message is
                              propagated along the RP-tree (source
                              encoded is an RP address)
RPT           | Assert      | The data packet was routed down the shared
                              tree; thus, the path indicated corresponds
                              to the RP tree
SPT           | (S,G) entry | Packets have arrived on the iif towards
                              S, and the iif is different from the
                              (*,G) iif
WC            |Join         | The receiver expects to receive packets
                              from all sources via this (shared tree)
                              path. Thus, the Join/Prune applies to a
                              (*,G) entry
WC            | Route entry | Wildcard entry; if there is no more
                              specific match for a particular source,
                              packets will be forwarded according to
                              this entry

Top       Page 41 
3.10 Security

   All PIM control messages may use IPsec [6] to address security
   concerns.



(page 41 continued on part 3)

Next RFC Part