Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4601

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

Pages: 150
Obsoletes:  2362
Obsoleted by:  7761
Updated by:  505957966226
Part 6 of 6 – Pages 119 to 150
First   Prev   None

ToP   noToC   RFC4601 - Page 119   prevText

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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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   noToC   RFC4601 - 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).