RFC 4601
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
Pages: 150
Obsoletes: 2362
Obsoleted by: 7761
Updated by: 5059 5796 6226
Obsoletes: 2362
Obsoleted by: 7761
Updated by: 5059 5796 6226
Part 6 of 6 – Pages 119 to 150
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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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).
(*,*,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.
(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.
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.
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.
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.
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)
(*,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.
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. | +---------------------+--------+---------------------------------------+
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.
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.
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.
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.
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
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
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.
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.
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
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.
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.
[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.
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.
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.
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.
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
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
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
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
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).