tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4601

 
 
 

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

Part 6 of 6, p. 119 to 150
Prev RFC Part

 


prevText      Top      Up      ToC       Page 119 
4.9.4.  Register-Stop Message Format

   A Register-Stop is unicast from the RP to the sender of the Register
   message.  The IP source address is the address to which the register
   was addressed.  The IP destination address is the source address of
   the register message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Group Address (Encoded-Group format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
        Described in Section 4.9.

   Group Address
        The group address from the multicast data packet in the
        Register.  Format described in Section 4.9.1. Note that for
        Register-Stops the Mask Len field contains the full address
        length * 8 (e.g., 32 for IPv4 native encoding), if the message
        is sent for a single group.

   Source Address
        The host address of the source from the multicast data packet in
        the register.  The format for this address is given in the
        Encoded-Unicast address in Section 4.9.1. A special wild card
        value consisting of an address field of all zeros can be used to
        indicate any source.

4.9.5.  Join/Prune Message Format

   A Join/Prune message is sent by routers towards upstream sources and
   RPs.  Joins are sent to build shared trees (RP trees) or source trees
   (SPT).  Prunes are sent to prune source trees when members leave
   groups as well as sources that do not use the shared tree.

Top      Up      ToC       Page 120 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Upstream Neighbor Address (Encoded-Unicast format)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     | Num groups    |          Holdtime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address 1 (Encoded-Group format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           .                                   |
   |                           .                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address m (Encoded-Group format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 121 
   PIM Version, Type, Reserved, Checksum
        Described in Section 4.9.

   Unicast Upstream Neighbor Address
        The address of the upstream neighbor that is the target of the
        message.  The format for this address is given in the Encoded-
        Unicast address in Section 4.9.1. For IPv6 the source address
        used for multicast messages is the link-local address of the
        interface on which the message is being sent.  For IPv4, the
        source address is the primary address associated with that
        interface.

   Reserved
        Transmitted as zero, ignored on receipt.

   Holdtime
        The amount of time a receiver must keep the Join/Prune state
        alive, in seconds.  If the Holdtime is set to '0xffff', the
        receiver of this message should hold the state until canceled by
        the appropriate canceling Join/Prune message, or timed out
        according to local policy.  This may be used with dial-on-demand
        links, to avoid keeping the link up with periodic Join/Prune
        messages.

        Note that the HoldTime must be larger than the
        J/P_Override_Interval(I).

   Number of Groups
        The number of multicast group sets contained in the message.

   Multicast group address
        For format description, see Section 4.9.1.

   Number of Joined Sources
        Number of joined source addresses listed for a given group.

   Joined Source Address 1 .. n
        This list contains the sources for a given group that the
        sending router will forward multicast datagrams from if received
        on the interface on which the Join/Prune message is sent.

        See Encoded-Source-Address format in Section 4.9.1.

   Number of Pruned Sources
        Number of pruned source addresses listed for a group.

Top      Up      ToC       Page 122 
   Pruned Source Address 1 .. n
        This list contains the sources for a given group that the
        sending router does not want to forward multicast datagrams from
        when received on the interface on which the Join/Prune message
        is sent.

   Within one PIM Join/Prune message, all the Multicast Group Addresses,
   Joined Source addresses, and Pruned Source addresses MUST be of the
   same address family.  It is NOT PERMITTED to mix IPv4 and IPv6
   addresses within the same message.  In addition, the address family
   of the fields in the message SHOULD be the same as the IP source and
   destination addresses of the packet.  This permits maximum
   implementation flexibility for dual-stack IPv4/IPv6 routers.  If a
   router receives a message with mixed family addresses, it SHOULD only
   process the addresses that are of the same family as the unicast
   upstream neighbor address.

4.9.5.1.  Group Set Source List Rules

   As described above, Join/Prune messages are composed of one or more
   group sets.  Each set contains two source lists, the Joined Sources
   and the Pruned Sources.  This section describes the different types
   of group sets and source list entries that can exist in a Join/Prune
   message.

   There are two valid group set types:

   Wildcard Group Set
        The wildcard group set is represented by the entire multicast
        range:  the beginning of the multicast address range in the
        group address field and the prefix length of the multicast
        address range in the mask length field of the Multicast Group
        Address (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8' for IPv6).
        Each Join/Prune message SHOULD contain at most one wildcard
        group set.  Each wildcard group set may contain one or more
        (*,*,RP) source list entries in either the Joined or Pruned
        lists.

        A (*,*,RP) source list entry may only exist in a wildcard group
        set.  When added to a Joined source list, this type of source
        entry expresses the router's interest in receiving traffic for
        all groups mapping to the specified RP.  When added to a Pruned
        source list a (*,*,RP) entry expresses the router's interest to
        stop receiving such traffic.  Note that as indicated by the
        Join/Prune state machines, such a Join or Prune will NOT
        override Join/Prune state created using a Group-Specific Set
        (see below).

Top      Up      ToC       Page 123 
        (*,*,RP) source list entries have the Source-Address set to the
        address of the RP, the Source-Address Mask-Len set to the full
        length of the IP address, and both the WC and RPT bits of the
        Source-Address set to 1.

   Group-Specific Set
        A Group-Specific Set is represented by a valid IP multicast
        address in the group address field and the full length of the IP
        address in the mask length field of the Multicast Group Address.
        Each Join/Prune message SHOULD NOT contain more than one group-
        specific set for the same IP multicast address.  Each group-
        specific set may contain (*,G), (S,G,rpt), and (S,G) source list
        entries in the Joined or Pruned lists.

     (*,G)
          The (*,G) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic sent to the
          group through the Rendezvous-Point shared tree.  There may
          only be one such entry in both the Joined and Pruned lists of
          a group-specific set.

          (*,G) source list entries have the Source-Address set to the
          address of the RP for group G, the Source-Address Mask-Len set
          to the full length of the IP address, and both the WC and RPT
          bits of the Encoded-Source-Address set.

     (S,G,rpt)
          The (S,G,rpt) source list entry is used in Join/Prune messages
          sent towards the RP for the specified group.  It expresses
          interest (or lack thereof) in receiving traffic through the
          shared tree sent by the specified source to this group.  For
          each source address, the entry may exist in only one of the
          Joined and Pruned source lists of a group-specific set, but
          not both.

          (S,G,rpt) source list entries have the Source-Address set to
          the address of the source S, the Source-Address Mask-Len set
          to the full length of the IP address, and the WC bit cleared
          and the RPT bit set in the Encoded-Source-Address.

     (S,G)
          The (S,G) source list entry is used in Join/Prune messages
          sent towards the specified source.  It expresses interest (or
          lack thereof) in receiving traffic through the shortest path
          tree sent by the source to the specified group.  For each
          source address, the entry may exist in only one of the Joined
          and Pruned source lists of a group-specific set, but not both.

Top      Up      ToC       Page 124 
          (S,G) source list entries have the Source-Address set to the
          address of the source S, the Source-Address Mask-Len set to
          the full length of the IP address, and both the WC and RPT
          bits of the Encoded-Source-Address cleared.

   The rules described above are sufficient to prevent invalid
   combinations of source list entries in group-specific sets.  There
   are, however, a number of combinations that have a valid
   interpretation but that are not generated by the protocol as
   described in this specification:

   o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same
     message is redundant as the (*,G) entry covers the information
     provided by the (S,G,rpt) entry.

   o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.

   o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
     generated.  (S,G,rpt) Joins are only sent when the router is
     receiving all traffic for a group on the shared tree and it wishes
     to indicate a change for the particular source.  As a (*,G) prune
     indicates that the router no longer wishes to receive shared tree
     traffic, the (S,G,rpt) Join would be meaningless.

   o As Join/Prune messages are targeted to a single PIM neighbor,
     including both a (S,G) Join and a (S,G,rpt) Prune in the same
     message is usually redundant.  The (S,G) Join informs the neighbor
     that the sender wishes to receive the particular source on the
     shortest path tree.  It is therefore unnecessary for the router to
     say that it no longer wishes to receive it on the shared tree.
     However, there is a valid interpretation for this combination of
     entries.  A downstream router may have to instruct its upstream
     only to start forwarding a specific source once it has started
     receiving the source on the shortest-path tree.

   o The combination of a (S,G) Prune and a (S,G,rpt) Join could
     possibly be used by a router to switch from receiving a particular
     source on the shortest-path tree back to receiving it on the shared
     tree (provided that the RPF neighbor for the shortest-path and
     shared trees is common).  However, Sparse-Mode PIM does not provide
     a mechanism for explicitly switching back to the shared tree.

Top      Up      ToC       Page 125 
   The rules are summarized in the tables below.

   +----------++------+-------+-----------+-----------+-------+-------+
   |          ||Join  | Prune | Join      | Prune     | Join  | Prune |
   |          ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||-     | no    | ?         | yes       | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||no    | -     | ?         | ?         | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||?     | ?     | -         | no        | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | ?     | no        | -         | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||yes   | yes   | yes       | yes       | -     | no    |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | yes   | ?         | ?         | no    | -     |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+

   +---------------++--------------+----------------+------------+
   |               ||Join (*,*,RP) | Prune (*,*,RP) | all others |
   +---------------++--------------+----------------+------------+
   |Join (*,*,RP)  ||-             | no             | yes        |
   +---------------++--------------+----------------+------------+
   |Prune (*,*,RP) ||no            | -              | yes        |
   +---------------++--------------+----------------+------------+
   |all others     ||yes           | yes            | see above  |
   +---------------++--------------+----------------+------------+

   yes  Allowed and expected.

   no   Combination is not allowed by the protocol and MUST NOT be
        generated by a router.  A router MAY accept these messages, but
        the result is undefined.  An error message MAY be logged to the
        administrator in a rate-limited manner.

   ?    Combination not expected by the protocol, but well-defined.  A
        router MAY accept it but SHOULD NOT generate it.

   The order of source list entries in a group set source list is not
   important, except where limited by the packet format itself.

Top      Up      ToC       Page 126 
4.9.5.2.  Group Set Fragmentation

   When building a Join/Prune for a particular neighbor, a router should
   try to include in the message as much of the information it needs to
   convey to the neighbor as possible.  This implies adding one group
   set for each multicast group that has information pending
   transmission and within each set including all relevant source list
   entries.

   On a router with a large amount of multicast state, the number of
   entries that must be included may result in packets that are larger
   than the maximum IP packet size.  In most such cases, the information
   may be split into multiple messages.

   There is an exception with group sets that contain a (*,G) Joined
   source list entry.  The group set expresses the router's interest in
   receiving all traffic for the specified group on the shared tree, and
   it MUST include an (S,G,rpt) Pruned source list entry for every
   source that the router does not wish to receive.  This list of
   (S,G,rpt) Pruned source-list entries MUST not be split in multiple
   messages.

   If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune
   message, but the router has more than N (S,G,rpt) Prunes to add, then
   the router MUST choose to include the first N (numerically smallest
   in network byte order) IP addresses.

4.9.6.  Assert Message Format

   The Assert message is used to resolve forwarder conflicts between
   routers on a link.  It is sent when a router receives a multicast
   data packet on an interface on which the router would normally have
   forwarded that packet.  Assert messages may also be sent in response
   to an Assert message from another router.

Top      Up      ToC       Page 127 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
        Described in Section 4.9.

   Group Address
        The group address for which the router wishes to resolve the
        forwarding conflict.  This is an Encoded-Group address, as
        specified in Section 4.9.1.

   Source Address
        Source address for which the router wishes to resolve the
        forwarding conflict.  The source address MAY be set to zero for
        (*,G) asserts (see below).  The format for this address is given
        in Encoded-Unicast-Address in Section 4.9.1.

   R    RPT-bit is a 1-bit value.  The RPT-bit is set to 1 for
        Assert(*,G) messages and 0 for Assert(S,G) messages.

   Metric Preference
        Preference value assigned to the unicast routing protocol that
        provided the route to the multicast source or Rendezvous-Point.

   Metric
        The unicast routing table metric associated with the route used
        to reach the multicast source or Rendezvous-Point.  The metric
        is in units applicable to the unicast routing protocol used.

   Assert messages can be sent to resolve a forwarding conflict for all
   traffic to a given group or for a specific source and group.

Top      Up      ToC       Page 128 
   Assert(S,G)
        Source-specific asserts are sent by routers forwarding a
        specific source on the shortest-path tree (SPTbit is TRUE).
        (S,G) Asserts have the Group-Address field set to the group G
        and the Source-Address field set to the source S.  The RPT-bit
        is set to 0, the Metric-Preference is set to MRIB.pref(S) and
        the Metric is set to MRIB.metric(S).

   Assert(*,G)
        Group-specific asserts are sent by routers forwarding data for
        the group and source(s) under contention on the shared tree.
        (*,G) asserts have the Group-Address field set to the group G.
        For data-triggered Asserts, the Source-Address field MAY be set
        to the IP source address of the data packet that triggered the
        Assert and is set to zero otherwise.  The RPT-bit is set to 1,
        the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric
        is set to MRIB.metric(RP(G)).

4.10.  PIM Timers

   PIM-SM maintains the following timers, as discussed in Section 4.1.
   All timers are countdown timers; they are set to a value and count
   down to zero, at which point they typically trigger an action.  Of
   course they can just as easily be implemented as count-up timers,
   where the absolute expiry time is stored and compared against a
   real-time clock, but the language in this specification assumes that
   they count downwards to zero.

   Global Timers

   Per interface (I):

        Hello Timer: HT(I)

        Per neighbor (N):

             Neighbor Liveness Timer: NLT(N,I)

        Per active RP (RP):

             (*,*,RP) Join Expiry Timer: ET(*,*,RP,I)

             (*,*,RP) Prune-Pending Timer: PPT(*,*,RP,I)

        Per Group (G):

             (*,G) Join Expiry Timer: ET(*,G,I)

Top      Up      ToC       Page 129 
             (*,G) Prune-Pending Timer: PPT(*,G,I)

             (*,G) Assert Timer: AT(*,G,I)

             Per Source (S):

                  (S,G) Join Expiry Timer: ET(S,G,I)

                  (S,G) Prune-Pending Timer: PPT(S,G,I)

                  (S,G) Assert Timer: AT(S,G,I)

                  (S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)

                  (S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)

   Per active RP (RP):

        (*,*,RP) Upstream Join Timer: JT(*,*,RP)

   Per Group (G):

        (*,G) Upstream Join Timer: JT(*,G)

        Per Source (S):

             (S,G) Upstream Join Timer: JT(S,G)

             (S,G) Keepalive Timer: KAT(S,G)

             (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)

   At the DRs or relevant Assert Winners only:

        Per Source,Group pair (S,G):

             Register-Stop Timer: RST(S,G)

4.11.  Timer Values

   When timers are started or restarted, they are set to default values.
   This section summarizes those default values.

   Note that protocol events or configuration may change the default
   value of a timer on a specific interface.  When timers are
   initialized in this document, the value specific to the interface in
   context must be used.

Top      Up      ToC       Page 130 
   Some of the timers listed below (Prune-Pending, Upstream Join,
   Upstream Override) can be set to values that depend on the settings
   of the Propagation_Delay and Override_Interval of the corresponding
   interface.  The default values for these are given below.

   Variable Name: Propagation_Delay(I)

+-------------------------------+--------------+----------------------+
|  Value Name                   |  Value       |  Explanation         |
+-------------------------------+--------------+----------------------+
|  Propagation_delay_default    |  0.5 secs    |  Expected            |
|                               |              |  propagation delay   |
|                               |              |  over the local      |
|                               |              |  link.               |
+-------------------------------+--------------+----------------------+

   The default value of the Propagation_delay_default is chosen to be
   relatively large to provide compatibility with older PIM
   implementations.

   Variable Name: Override_Interval(I)

+--------------------------+-----------------+-------------------------+
|  Value Name              |    Value        |    Explanation          |
+--------------------------+-----------------+-------------------------+
|  t_override_default      |    2.5 secs     |    Default delay        |
|                          |                 |    interval over        |
|                          |                 |    which to randomize   |
|                          |                 |    when scheduling a    |
|                          |                 |    delayed Join         |
|                          |                 |    message.             |
+--------------------------+-----------------+-------------------------+

   Timer Name: Hello Timer (HT(I))

+---------------------+--------+---------------------------------------+
|Value Name           | Value  | Explanation                           |
+---------------------+--------+---------------------------------------+
|Hello_Period         | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
|                     |        | message on bootup or triggered Hello  |
|                     |        | message to a rebooting neighbor.      |
+---------------------+--------+---------------------------------------+

Top      Up      ToC       Page 131 
   At system power-up, the timer is initialized to rand(0,
   Triggered_Hello_Delay) to prevent synchronization.  When a new or
   rebooting neighbor is detected, a responding Hello is sent within
   rand(0, Triggered_Hello_Delay).

   Timer Name: Neighbor Liveness Timer (NLT(N,I))

+--------------------------+----------------------+--------------------+
| Value Name               |  Value               |  Explanation       |
+--------------------------+----------------------+--------------------+
| Default_Hello_Holdtime   |  3.5 * Hello_Period  |  Default holdtime  |
|                          |                      |  to keep neighbor  |
|                          |                      |  state alive       |
+--------------------------+----------------------+--------------------+
| Hello_Holdtime           |  from message        |  Holdtime from     |
|                          |                      |  Hello Message     |
|                          |                      |  Holdtime option.  |
+--------------------------+----------------------+--------------------+

   The Holdtime in a Hello Message should be set to (3.5 *
   Hello_Period), giving a default value of 105 seconds.

   Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I),
   ET(S,G,rpt,I))

+----------------+----------------+------------------------------------+
| Value Name     |  Value         |  Explanation                       |
+----------------+----------------+------------------------------------+
| J/P_HoldTime   |  from message  |  Holdtime from Join/Prune Message  |
+----------------+----------------+------------------------------------+

   See details of JT(*,G) for the Holdtime that is included in
   Join/Prune Messages.

Top      Up      ToC       Page 132 
   Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I),
   PPT(S,G,I), PPT(S,G,rpt,I))

+--------------------------+---------------------+---------------------+
|Value Name                | Value               | Explanation         |
+--------------------------+---------------------+---------------------+
|J/P_Override_Interval(I)  | Default:            | Short period after  |
|                          | Effective_          | a join or prune to  |
|                          | Propagation_        | allow other         |
|                          | Delay(I) +          | routers on the LAN  |
|                          | EffectiveOverride_  | to override the     |
|                          | Interval(I)         | join or prune       |
+--------------------------+---------------------+---------------------+

   Note that both the Effective_Propagation_Delay(I) and the
   Effective_Override_Interval(I) are interface-specific values that may
   change when Hello messages are received (see Section 4.3.3).

   Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))

+---------------------------+---------------------+--------------------+
| Value Name                | Value               | Explanation        |
+---------------------------+---------------------+--------------------+
| Assert_Override_Interval  | Default: 3 secs     | Short interval     |
|                           |                     | before an assert   |
|                           |                     | times out where    |
|                           |                     | the assert winner  |
|                           |                     | resends an Assert  |
|                           |                     | message            |
+---------------------------+---------------------+--------------------+
| Assert_Time               | Default: 180 secs   | Period after last  |
|                           |                     | assert before      |
|                           |                     | assert state is    |
|                           |                     | timed out          |
+---------------------------+---------------------+--------------------+

   Note that for historical reasons, the Assert message lacks a Holdtime
   field.  Thus, changing the Assert Time from the default value is not
   recommended.

Top      Up      ToC       Page 133 
   Timer Names: Upstream Join Timer (JT(*,*,RP), JT(*,G), JT(S,G))

+-------------+--------------------+-----------------------------------+
|Value Name   | Value              | Explanation                       |
+-------------+--------------------+-----------------------------------+
|t_periodic   | Default: 60 secs   | Period between Join/Prune Messages|
+-------------+--------------------+-----------------------------------+
|t_suppressed | rand(1.1 *         | Suppression period when someone   |
|             | t_periodic, 1.4 *  | else sends a J/P message so we    |
|             | t_periodic) when   | don't need to do so.              |
|             | Suppression_       |                                   |
|             | Enabled(I) is      |                                   |
|             | true, 0 otherwise  |                                   |
+-------------+--------------------+-----------------------------------+
|t_override   | rand(0, Effective_ | Randomized delay to prevent       |
|             | Override_          | response implosion when sending a |
|             | Interval(I))       | join message to override someone  |
|             |                    | else's Prune message.             |
+-------------+--------------------+-----------------------------------+

   t_periodic 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).  If the
   Join/Prune-Period is modified during operation, 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 adapt.

   The holdtime specified in a Join/Prune message should be set to (3.5
   * t_periodic).

   t_override depends on the Effective_Override_Interval of the upstream
   interface, which may change when Hello messages are received.

   t_suppressed depends on the Suppression State of the upstream
   interface (Section 4.3.3) and becomes zero when suppression is
   disabled.

Top      Up      ToC       Page 134 
   Timer Name: Upstream Override Timer (OT(S,G,rpt))

+---------------+--------------------------+---------------------------+
| Value Name    | Value                    |  Explanation              |
+---------------+--------------------------+---------------------------+
| t_override    | see Upstream Join Timer  |  see Upstream Join Timer  |
+---------------+--------------------------+---------------------------+

   The upstream Override Timer is only ever set to t_override; this
   value is defined in the section on Upstream Join Timers.

   Timer Name: Keepalive Timer (KAT(S,G))

+-----------------------+-----------------------+----------------------+
| Value Name            |  Value                |  Explanation         |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period      |  Default: 210 secs    |  Period after last   |
|                       |                       |  (S,G) data packet   |
|                       |                       |  during which (S,G)  |
|                       |                       |  Join state will be  |
|                       |                       |  maintained even in  |
|                       |                       |  the absence of      |
|                       |                       |  (S,G) Join          |
|                       |                       |  messages.           |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period   |  ( 3 * Register_      |  As                  |
|                       |  Suppression_Time )   |  Keepalive_Period,   |
|                       |  + Register_          |  but at the RP when  |
|                       |  Probe_Time           |  a Register-Stop is  |
|                       |                       |  sent.               |
+-----------------------+-----------------------+----------------------+

   The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
   However, at the RP, the keepalive period must be at least the
   Register_Suppression_Time, or the RP may time out the (S,G) state
   before the next Null-Register arrives.  Thus, the KAT(S,G) is set to
   max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is
   sent.

Top      Up      ToC       Page 135 
   Timer Name: Register-Stop Timer (RST(S,G))

+---------------------------+--------------------+---------------------+
|Value Name                 | Value              | Explanation         |
+---------------------------+--------------------+---------------------+
|Register_Suppression_Time  | Default: 60 secs   | Period during       |
|                           |                    | which a DR stops    |
|                           |                    | sending Register-   |
|                           |                    | encapsulated data   |
|                           |                    | to the RP after     |
|                           |                    | receiving a         |
|                           |                    | Register-Stop       |
|                           |                    | message.            |
+---------------------------+--------------------+---------------------+
|Register_Probe_Time        | Default: 5 secs    | Time before RST     |
|                           |                    | expires when a DR   |
|                           |                    | may send a Null-    |
|                           |                    | Register to the RP  |
|                           |                    | to cause it to      |
|                           |                    | resend a Register-  |
|                           |                    | Stop message.       |
+---------------------------+--------------------+---------------------+

   If the Register_Suppression_Time or the Register_Probe_Time are
   configured to values other than the defaults, it MUST be ensured that
   the value of the Register_Probe_Time is less than half the value of
   the Register_Suppression_Time to prevent a possible negative value in
   the setting of the Register-Stop Timer.

5.  IANA Considerations

5.1.  PIM Address Family

   The PIM Address Family field was chosen to be 8 bits as a tradeoff
   between packet format and use of the IANA assigned numbers.  Because
   when the PIM packet format was designed only 15 values were assigned
   for Address Families, and large numbers of new Address Family values
   were not envisioned, 8 bits seemed large enough.  However, the IANA
   assigns Address Families in a 16-bit field.  Therefore, the PIM
   Address Family is allocated as follows:

     Values 0 through 127 are designated to have the same meaning as
     IANA-assigned Address Family Numbers [7].

     Values 128 through 250 are designated to be assigned for PIM by the
     IANA based upon IESG Approval, as defined in [9].

     Values 251 through 255 are designated for Private Use, as defined

Top      Up      ToC       Page 136 
     in [9].

5.2.  PIM Hello Options

   Values 17 through 65000 are to be assigned by the IANA.  Since the
   space is large, they may be assigned as First Come First Served as
   defined in [9].  Such assignments are valid for one year and may be
   renewed.  Permanent assignments require a specification (see
   "Specification Required" in [9].)

6.  Security Considerations

   This section describes various possible security concerns related to
   the PIM-SM protocol, including a description of how to use IPsec to
   secure the protocol.  The reader is referred to [15] and [16] for
   further discussion of PIM-SM and multicast security.  The IPsec
   authentication header [8] MAY be used to provide data integrity
   protection and groupwise data origin authentication of PIM protocol
   messages.  Authentication of PIM messages can protect against
   unwanted behaviors caused by unauthorized or altered PIM messages.

6.1.  Attacks Based on Forged Messages

   The extent of possible damage depends on the type of counterfeit
   messages accepted.  We next consider the impact of possible
   forgeries, including forged link-local (Join/Prune, Hello, and
   Assert) and forged unicast (Register and Register-Stop) messages.

6.1.1.  Forged Link-Local Messages

   Join/Prune, Hello, and Assert messages are all sent to the link-local
   ALL_PIM_ROUTERS multicast addresses and thus are not forwarded by a
   compliant router.  A forged message of this type can only reach a LAN
   if it was sent by a local host or if it was allowed onto the LAN by a
   compromised or non-compliant router.

   1.  A forged Join/Prune message can cause multicast traffic to be
       delivered to links where there are no legitimate requesters,
       potentially wasting bandwidth on that link.  A forged leave
       message on a multi-access LAN is generally not a significant
       attack in PIM, because any legitimately joined router on the LAN
       would override the leave with a join before the upstream router
       stops forwarding data to the LAN.

   2.  By forging a Hello message, an unauthorized router can cause
       itself to be elected as the designated router on a LAN.  The
       designated router on a LAN is (in the absence of asserts)
       responsible for forwarding traffic to that LAN on behalf of any

Top      Up      ToC       Page 137 
       local members.  The designated router is also responsible for
       register-encapsulating to the RP any packets that are originated
       by hosts on the LAN.  Thus, the ability of local hosts to send
       and receive multicast traffic may be compromised by a forged
       Hello message.

   3.  By forging an Assert message on a multi-access LAN, an attacker
       could cause the legitimate designated forwarder to stop
       forwarding traffic to the LAN.  Such a forgery would prevent any
       hosts downstream of that LAN from receiving traffic.

6.1.2.  Forged Unicast Messages

   Register messages and Register-Stop messages are forwarded by
   intermediate routers to their destination using normal IP forwarding.
   Without data origin authentication, an attacker who is located
   anywhere in the network may be able to forge a Register or Register-
   Stop message.  We consider the effect of a forgery of each of these
   messages next.

   1.  By forging a Register message, an attacker can cause the RP to
       inject forged traffic onto the shared multicast tree.

   2.  By forging a Register-stop message, an attacker can prevent a
       legitimate DR from Registering packets to the RP.  This can
       prevent local hosts on that LAN from sending multicast packets.

   The above two PIM messages are not changed by intermediate routers
   and need only be examined by the intended receiver.  Thus, these
   messages can be authenticated end-to-end, using AH.  Attacks on
   Register and Register-Stop messages do not apply to a PIM-SSM-only
   implementation, as these messages are not required for PIM-SSM.

6.2.  Non-Cryptographic Authentication Mechanisms

   A PIM router SHOULD provide an option to limit the set of neighbors
   from which it will accept Join/Prune, Assert, and Hello messages.
   Either static configuration of IP addresses or an IPsec security
   association may be used.  Furthermore, a PIM router SHOULD NOT accept
   protocol messages from a router from which it has not yet received a
   valid Hello message.

   A Designated Router MUST NOT register-encapsulate a packet and send
   it to the RP unless the source address of the packet is a legal
   address for the subnet on which the packet was received.  Similarly,
   a Designated Router SHOULD NOT accept a Register-Stop packet whose IP
   source address is not a valid RP address for the local domain.

Top      Up      ToC       Page 138 
   An implementation SHOULD provide a mechanism to allow an RP to
   restrict the range of source addresses from which it accepts
   Register-encapsulated packets.

   All options that restrict the range of addresses from which packets
   are accepted MUST default to allowing all packets.

6.3.  Authentication Using IPsec

   The IPsec [8] transport mode using the Authentication Header (AH) is
   the recommended method to prevent the above attacks against PIM.  The
   specific AH authentication algorithm and parameters, including the
   choice of authentication algorithm and the choice of key, are
   configured by the network administrator.  When IPsec authentication
   is used, a PIM router should reject (drop without processing) any
   unauthorized PIM protocol messages.

   To use IPsec, the administrator of a PIM network configures each PIM
   router with one or more security associations (SAs) and associated
   Security Parameter Indexes (SPIs) that are used by senders to
   authenticate PIM protocol messages and are used by receivers to
   authenticate received PIM protocol messages.  This document does not
   describe protocols for establishing SAs.  It assumes that manual
   configuration of SAs is performed, but it does not preclude the use
   of a negotiation protocol such as the Internet Key Exchange [14] to
   establish SAs.

   IPsec [8] provides protection against replayed unicast and multicast
   messages.  The anti-replay option for IPsec SHOULD be enabled on all
   SAs.

   The following sections describe the SAs required to protect PIM
   protocol messages.

6.3.1.  Protecting Link-Local Multicast Messages

   The network administrator defines an SA and SPI that are to be used
   to authenticate all link-local PIM protocol messages (Hello,
   Join/Prune, and Assert) on each link in a PIM domain.

   IPsec [8] allows (but does not require) different Security Policy
   Databases (SPD) for each router interface.  If available, it may be
   desirable to configure the Security Policy Database at a PIM router
   such that all incoming and outgoing Join/Prune, Assert, and Hello
   packets use a different SA for each incoming or outgoing interface.

Top      Up      ToC       Page 139 
6.3.2.  Protecting Unicast Messages

   IPsec can also be used to provide data origin authentication and data
   integrity protection for the Register and Register-Stop unicast
   messages.

6.3.2.1.  Register Messages

   The Security Policy Database at every PIM router is configured to
   select an SA to use when sending PIM Register packets to each
   rendezvous point.

   In the most general mode of operation, the Security Policy Database
   at each DR is configured to select a unique SA and SPI for traffic
   sent to each RP.  This allows each DR to have a different
   authentication algorithm and key to talk to the RP.  However, this
   creates a daunting key management and distribution problem for the
   network administrator.  Therefore, it may be preferable in PIM
   domains where all Designated Routers are under a single
   administrative control that the same authentication algorithm
   parameters (including the key) be used for all Registered packets in
   a domain, regardless of who are the RP and the DR.

   In this "single shared key" mode of operation, the network
   administrator must choose an SPI for each DR that will be used to
   send it PIM protocol packets.  The Security Policy Database at every
   DR is configured to select an SA (including the authentication
   algorithm, authentication parameters, and this SPI) when sending
   Register messages to this RP.

   By using a single authentication algorithm and associated parameters,
   the key distribution problem is simplified.  Note, however, that this
   method has the property that, in order to change the authentication
   method or authentication key used, all routers in the domain must be
   updated.

6.3.2.2.  Register-Stop Messages

   Similarly, the Security Policy Database at each Rendezvous Point
   should be configured to choose an SA to use when sending Register-
   Stop messages.  Because Register-Stop messages are unicast to the
   destination DR, a different SA and a potentially unique SPI are
   required for each DR.

   In order to simplify the management problem, it may be acceptable to
   use the same authentication algorithm and authentication parameters,
   regardless of the sending RP and regardless of the destination DR.
   Although a unique SA is needed for each DR, the same authentication

Top      Up      ToC       Page 140 
   algorithm and authentication algorithm parameters (secret key) can be
   shared by all DRs and by all RPs.

6.4.  Denial-of-Service Attacks

   There are a number of possible denial-of-service attacks against PIM
   that can be caused by generating false PIM protocol messages or even
   by generating data false traffic.  Authenticating PIM protocol
   traffic prevents some, but not all, of these attacks.  Three of the
   possible attacks include:

   -  Sending packets to many different group addresses quickly can be a
      denial-of-service attack in and of itself.  This will cause many
      register-encapsulated packets, loading the DR, the RP, and the
      routers between the DR and the RP.

   -  Forging Join messages can cause a multicast tree to get set up.  A
      large number of forged joins can consume router resources and
      result in denial of service.

   -  Forging a (*,*,RP) join presents a possibility for a denial-of-
      service attack by causing all traffic in the domain to flow to the
      PMBR issuing the join.  (*,*,RP) behavior is included here
      primarily for backwards compatibility with prior revisions of the
      spec.  However, the implementation of (*,*,RP) and PMBR is
      optional.  When using (*,*,RP), the security concerns should be
      carefully considered.

7.  Acknowledgements

   PIM-SM was designed over many years by a large group of people,
   including ideas, comments, and corrections from Deborah Estrin, Dino
   Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C.
   Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott
   Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly
   Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian
   Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike
   Davison, James Huang, Christopher Thomas Brown, and James Lingard.

   Thanks are due to the American Licorice Company, for its obscure but
   possibly essential role in the creation of this document.

Top      Up      ToC       Page 141 
8.  Normative References

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

   [2]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, October 2002.

   [3]  Deering, S., "Host extensions for IP multicasting", STD 5, RFC
        1112, August 1989.

   [4]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
        RFC 4507, August 2006.

   [7]  IANA, "Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

   [8]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

9.  Informative References

   [10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
        Extensions for BGP-4", RFC 2858, June 2000.

   [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
        Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress,
        May 2006.

   [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
        October 2000.

   [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
        directional Protocol Independent Multicast", Work in Progress,
        October 2005.

   [14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

Top      Up      ToC       Page 142 
   [15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
        Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
        Issues and Enhancements", RFC 4609, August 2006.

   [16] Savola, P. and J. Lingard, "Last-hop Threats to Protocol
        Independent Multicast (PIM)", Work in Progress, January 2005.

   [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
        Address in an IPv6 Multicast Address", RFC 3956, November 2004.

   [18] Thaler, D., "Interoperability Rules for Multicast Routing
        Protocols", RFC 2715, October 1999.

Top      Up      ToC       Page 143 
Appendix A.  PIM Multicast Border Router Behavior

   In some cases, PIM-SM domains will interconnect with non-PIM
   multicast domains.  In these cases, the border routers of the PIM
   domain speak PIM-SM on some interfaces and speak other multicast
   routing protocols on other interfaces.  Such routers are termed PIM
   Multicast Border Routers (PMBRs).  In general, RFC 2715 [18] provides
   rules for interoperability between different multicast routing
   protocols.  In this appendix, we specify how PMBRs differ from
   regular PIM-SM routers.

   From the point of view of PIM-SM, a PMBR has two tasks:

   o To ensure that traffic from sources outside the PIM-SM domain
     reaches receivers inside the domain.

   o To ensure that traffic from sources inside the PIM-SM domain
     reaches receivers outside the domain.

   We note that multiple PIM-SM domains are sometimes connected together
   using protocols such as Multicast Source Discovery Protocol (MSDP),
   which provides information about active external sources, but does
   not follow RFC 2715.  In such cases, the domains are not connected
   via PMBRs because Join(S,G) messages traverse the border between
   domains.  A PMBR is required when no PIM messages can traverse the
   border.

A.1.  Sources External to the PIM-SM Domain

   A PMBR needs to ensure that traffic from multicast sources external
   to the PIM-SM domain reaches receivers inside the domain.  The PMBR
   will follow the rules in RFC 2715, such that traffic from external
   sources reaches the PMBR itself.

   According to RFC 2715, the PIM-SM component of the PMBR will receive
   an (S,G) Creation event when data from an (S,G) data packet from an
   external source first reaches the PMBR.  If RPF_interface(S) is an
   interface in the PIM-SM domain, the packet cannot be originated into
   the PIM domain at this router, and the PIM-SM component of the PMBR
   will not process the packet.  Otherwise, the PMBR will then act
   exactly as if it were the DR for this source (see Section 4.4.1),
   with the following modifications:

   o The Border-bit is set in all PIM Register messages sent for these
     sources.

   o DirectlyConnected(S) is treated as being TRUE for these sources.

Top      Up      ToC       Page 144 
   o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to
     be TRUE if iif is any interface that is not part of the PIM-SM
     component of the PMBR (see Section 4.2).

A.2.  Sources Internal to the PIM-SM Domain

   A PMBR needs to ensure that traffic from sources inside the PIM-SM
   domain reaches receivers outside the domain.  Using terminology from
   RFC 2715, there are two possible scenarios for this:

   o Another component of the PMBR is a wildcard receiver.  In this
     case, the PIM-SM component of the PMBR must ensure that traffic
     from all internal sources reaches the PMBR until it is informed
     otherwise.

     Note that certain profiles of PIM-SM (e.g., PIM-SSM, PIM-SM with
     Embedded RP) cannot interoperate with a neighboring wildcard
     receiver domain.

   o No other component of the PMBR is a wildcard receiver.  In this
     case the PMBR will receive explicit information as to which groups
     or (source,group) pairs the external domains wish to receive.

   In the former case, the PMBR will need to send a Join(*,*,RP) to all
   the active RPs in the PIM-SM domain.  It may also send a Join(*,*,RP)
   to all the candidate RPs in the PIM-SM domain.  This will cause all
   traffic in the domain to reach the PMBR.  The PMBR may then act as if
   it were a DR with directly connected receivers and trigger the
   transition to a shortest path tree (see Section 4.2.1).

   In the latter case, the PMBR will not need to send Join(*,*,RP)
   messages.  However, the PMBR will still need to act as a DR with
   directly connected receivers on behalf of the external receivers in
   terms of being able to switch to the shortest-path tree for
   internally-reached sources.

   According to RFC 2715, the PIM-SM component of the PMBR may receive a
   number of alerts generated by events in the external routing
   components.  To implement the above behavior, one reasonable way to
   map these alerts into PIM-SM state is as follows:

   o When a PIM-SM component receives an (S,G) Prune alert, it sets
     local_receiver_include(S,G,I) to FALSE for the discard interface.

   o When a PIM-SM component receives a (*,G) Prune alert, it sets
     local_receiver_include(*,G,I) to FALSE for the discard interface.

Top      Up      ToC       Page 145 
   o When a PIM-SM component receives an (S,G) Join alert, it sets
     local_receiver_include(S,G,I) to TRUE for the discard interface.

   o When a PIM-SM component receives a (*,G) Join alert, it sets
     local_receiver_include(*,G,I) to TRUE for the discard interface.

   o When a PIM-SM component receives a (*,*) Join alert, it sets
     DownstreamJPState(*,*,RP,I) to Join state on the discard interface
     for all RPs in the PIM-SM domain.

   o When a PIM-SM component receives a (*,*) Prune alert, it sets
     DownstreamJPState(*,*,RP,I) to NoInfo state on the discard
     interface for all RPs in the PIM-SM domain.

   We refer above to the discard interface because the macros and state
   machines are interface specific, but we need to have PIM state that
   is not associated with any actual PIM-SM interface.  Implementers are
   free to implement this in any reasonable manner.

   Note that these state changes will then cause additional PIM-SM state
   machine transitions in the normal way.

   These rules are, however, not sufficient to allow pruning off the
   (*,*,RP) tree.  Some additional rules provide guidance as to one way
   this may be done:

   o If the PMBR has joined on the (*,*,RP) tree, then it should set
     DownstreamJPState(*,G,I) to JOIN on the discard interface for all
     active groups.

   o If the router receives a (S,G) prune alert, it will need to set
     DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.

   o If the router receives a (*,G) prune alert, it will need to set
     DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for
     all active sources sending to G.

   The rationale for this is that there is no way in PIM-SM to prune
   traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and
   then pruning each source individually.

Top      Up      ToC       Page 146 
Appendix B.  Index

   Address_List. . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   Assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
   Assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
   AssertCancel(*,G) . . . . . . . . . . . . . . . . . . . . . . . 97,99
   AssertCancel(S,G) . . . . . . . . . . . . . . . . . . . . . .80,90,99
   AssertTimer(*,G,I). . . . . . . . . . . . . . . . . . . .16,24,91,132
   AssertTimer(S,G,I). . . . . . . . . . . . . . . . . . . .18,24,84,132
   AssertTrackingDesired(*,G,I). . . . . . . . . . . . . . . . .93,94,96
   AssertTrackingDesired(S,G,I). . . . . . . . . . . . . . . 85,86,87,89
   AssertWinner(*,G,I) . . . . . . . . . . . . . . . .16,22,24,93,97,100
   AssertWinner(S,G,I) . . . . . . . . . . . . . .18,22,24,86,90,100,100
   AssertWinnerMetric(*,G,I) . . . . . . . . . . . . . . . . . 16,97,101
   AssertWinnerMetric(S,G,I) . . . . . . . . . . . . . . . . . 18,90,101
   assert_metric . . . . . . . . . . . . . . . . . . . . . . . . . .  98
   Assert_Override_Interval. . . . . . . . . . . . . . . . . . 90,97,132
   Assert_Time . . . . . . . . . . . . . . . . . . . . . . . . 90,97,132
   AT(*,G,I) . . . . . . . . . . . . . . . . . . . . . .16,24,91,129,132
   AT(S,G,I) . . . . . . . . . . . . . . . . . . . . . .18,24,84,129,132
   CheckSwitchToSpt(S,G) . . . . . . . . . . . . . . . . . . . . . 27,28
   CouldAssert(*,G,I). . . . . . . . . . . . . . . . . . .92,93,94,95,98
   CouldAssert(S,G,I). . . . . . . . . . . . . . . . . 84,86,87,88,89,98
   CouldRegister(S,G). . . . . . . . . . . . . . . . . . . . . . . 39,41
   Default_Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . .  33
   DirectlyConnected(S). . . . . . . . . . . . . . . . . 27,27,29,41,143
   DownstreamJPState(*,*,RP,I) . . . . . . . . . . . . . . . . . .23,145
   DownstreamJPState(*,G,I). . . . . . . . . . . . . . . . . . . . .  23
   DownstreamJPState(S,G,I). . . . . . . . . . . . . . . . . . . . 23,40
   DownstreamJPState(S,G,rpt,I). . . . . . . . . . . . . . . . . . .  23
   DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
   dr_is_better(a,b,I) . . . . . . . . . . . . . . . . . . . . . . 33,33
   DR_Priority . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33
   Effective_Override_Interval(I). . . . . . . . . . . . . . .36,114,132
   Effective_Propagation_Delay(I). . . . . . . . . . . . . . . . .35,132
   ET(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . 15,46,128,131
   ET(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . 16,50,128,131
   ET(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . 18,53,129,131
   ET(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . .20,57,59,129,131
   GenID . . . . . . . . . . . . . . . . . 15,17,19,31,64,68,70,73,85,93
   Hash_Function . . . . . . . . . . . . . . . . . . . . . . . . .12,105
   Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . . . .33,131
   Hello_Period. . . . . . . . . . . . . . . . . . . . . . . . . .31,130
   HT(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,130
   IGMP. . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
   immediate_olist(*,*,RP) . . . . . . . . . . . . . . . . . . . . 22,64
   immediate_olist(*,G). . . . . . . . . . . . . . . . . . . . . . 22,68
   immediate_olist(S,G). . . . . . . . . . . . . . . . . . . . .22,40,73

Top      Up      ToC       Page 147 
   infinite_assert_metric(). . . . . . . . . . . . . . . . . . . . .  99
   inherited_olist(S,G). . . . . . . . . . . . . . 22,27,40,43,73,86,108
   inherited_olist(S,G,rpt). . . . . . . . . . . . . . 22,27,29,76,79,81
   I_Am_Assert_Loser(*,G,I). . . . . . . . . . . . . . . . . . . . .  24
   I_Am_Assert_Loser(S,G,I). . . . . . . . . . . . . . . . . . . . .  24
   I_am_DR(I). . . . . . . . . . . . . . . . . . . . . . .22,33,41,86,93
   I_am_RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44
   J/P_Holdtime. . . . . . . . . . . . .47,51,55,59,65,69,74,121,131,133
   J/P_Override_Interval(I). . . . . . . . . . . . . 48,51,55,59,121,132
   JoinDesired(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 64,79
   JoinDesired(*,G). . . . . . . . . . . . . . . . . . . .17,68,79,86,97
   JoinDesired(S,G). . . . . . . . . . . . . . . . . . 19,29,73,86,88,90
   joins(*,*,RP(G)). . . . . . . . . . . . . . . . . . . . . . . . .  22
   joins(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
   joins(*,G). . . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
   joins(S,G). . . . . . . . . . . . . . . . . . . . . . . . . .22,23,86
   JT(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . 15,62,129,133
   JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . 16,67,129,133
   JT(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 18,71,129,133
   KAT(S,G). . . . . . . . . . . . . . .18,26,27,28,41,43,73,108,129,134
   KeepaliveTimer(S,G) . . . . . . . 18,26,27,27,28,41,43,73,108,129,134
   Keepalive_Period. . . . . . . . . . . . . . . . . . . . . . . .27,134
   lan_delay_enabled(I). . . . . . . . . . . . . . . . . . . . . . 35,36
   LAN_Prune_Delay . . . . . . . . . . . . . . . . . . . . . . . . .  31
   local_receiver_exclude(S,G,I) . . . . . . . . . . . . . . . . . .  23
   local_receiver_include(*,G,I) . . . . . . . . . . . . . . . 23,93,144
   local_receiver_include(S,G,I) . . . . . . . . . . . . . . . . . 23,86
   local_receiver_include(S,G,I).. . . . . . . . . . . . . . . . . . 144
   lost_assert(*,G). . . . . . . . . . . . . . . . . . . . . . .22,24,86
   lost_assert(*,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
   lost_assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . 22,24
   lost_assert(S,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
   lost_assert(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . .  24
   lost_assert(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . .24,100
   MBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,7
   MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6,13
   MLD . . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
   MRIB. . . . . . . . . . . . . .6,7,11,15,19,25,62,66,66,75,98,103,128
   MRIB.next_hop(host) . . . . . . . . . . . . . . . . . . . 24,25,62,64
   my_assert_metric(*,G,I) . . . . . . . . . . . . . . . . . . . . .  94
   my_assert_metric(S,G,I) . . . . . . . . . . . . . . . . . 85,89,92,98
   NBR(Interface,IP_address) . . . . . . . . . . . . . . .25,37,62,64,66
   NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . 14,33,128,131
   OT(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . 20,77,129,134
   Override_Interval(I). . . . . . . . . . . . . 14,31,34,36,114,130,132
   packet_arrives_on_rp_tunnel(pkt). . . . . . . . . . . . . . . . .  43
   pim_exclude(S,G). . . . . . . . . . . . . . . . . . . . . 22,22,28,86
   pim_include(*,G). . . . . . . . . . . . . . . . . . 17,22,22,28,86,93

Top      Up      ToC       Page 148 
   pim_include(S,G). . . . . . . . . . . . . . . . . . . .19,22,22,28,86
   PPT(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . 15,46,128,132
   PPT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . 16,50,129,132
   PPT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 18,53,129,132
   PPT(S,G,rpt,I). . . . . . . . . . . . . . . . . . . .20,57,59,129,132
   Propagation_Delay(I). . . . . . . . . . . . . . . . . . 31,35,130,132
   Propagation_delay_default . . . . . . . . . . . . . . . . . . .35,130
   PruneDesired(S,G,rpt) . . . . . . . . . . . . . . . . . . 79,80,88,90
   prunes(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . .22,23,86
   Register-Stop(*,G). . . . . . . . . . . . . . . . . . . . . . . .  42
   Register-Stop(S,G). . . . . . . . . . . . . . . . . . . . . . . .  43
   Register-StopTimer(S,G) . . . . . . . . . . . . . . . . 38,39,129,135
   Register_Probe_Time . . . . . . . . . . . . . . . . . . . . 39,44,135
   Register_Suppression_Time . . . . . . . . . . . . . . . . . 39,44,135
   RP(G) . . . . . . . . . . . . 5,22,24,40,43,49,68,77,86,93,99,102,128
   RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   RPF'(*,G) . . . . . . . . . . . . . . . . 24,29,67,68,70,76,79,97,101
   RPF'(S,G) . . . . . . . . . . . . . . . . . . . 25,29,71,76,79,90,101
   RPF'(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . .24,76,79,102
   RPF_interface . . . . . . . . . . . . . . . . . . . . . . . . . .  93
   RPF_interface(host) . . . . . .24,27,29,41,68,69,74,86,93,100,108,143
   RPTJoinDesired(G) . . . . . . . . . . . . . . . . . . . . . .79,81,93
   rpt_assert_metric(G,I). . . . . . . . . . . . . . . . . . . .96,97,99
   RST(S,G). . . . . . . . . . . . . . . . . . . . . . . . 38,39,129,135
   SPTbit(S,G) . . . . . . . 19,27,29,43,53,74,76,79,86,86,89,90,100,108
   spt_assert_metric(S,I). . . . . . . . . . . . . . . . . . . 90,98,100
   SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10,106
   Suppression_Enabled(I). . . . . . . . . . . . . . . . . . . . .36,133
   SwitchToSptDesired(S,G) . . . . . . . . . . . . . . . . . . .28,28,43
   TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,13,26
   Triggered_Hello_Delay . . . . . . . . . . . . . . . . . . . 31,32,130
   t_joinsuppress. . . . . . . . . . . . . . . . . . . . .64,65,68,69,74
   t_override. . . . . . . . . . . . . . . . . . . . 64,68,73,78,133,134
   t_override_default. . . . . . . . . . . . . . . . . . . . . . .36,130
   t_periodic. . . . . . . . . . . . . . . . . . . . . . . .64,68,73,133
   t_suppressed. . . . . . . . . . . . . . . . . . . .36,65,69,73,74,133
   Update_SPTbit(S,G,iif). . . . . . . . . . . . . . . . . . . . . 27,29
   UpstreamJPState(S,G). . . . . . . . . . . . . . . . . . . . . .27,108

Top      Up      ToC       Page 149 
Authors' Addresses

   Bill Fenner
   AT&T Labs - Research
   1 River Oaks Place
   San Jose, CA 95134

   EMail: fenner@research.att.com


   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

   EMail: M.Handley@cs.ucl.ac.uk


   Hugh Holbrook
   Arastra, Inc.
   P.O. Box 10905
   Palo Alto, CA 94303

   EMail: holbrook@arastra.com


   Isidor Kouvelas
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134

   EMail: kouvelas@cisco.com

Top      Up      ToC       Page 150 
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).