RFC 3446 (rfc3446) - Page 2 of 7
Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
Alternative Format: Original Text Document
RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
The mechanism described here is intended to address the need for
better fail-over (convergence time) and sharing of the register
decapsulation load (again, when using the shared-tree) among RPs in a
domain. It is primarily intended for applications within those
networks using MBGP, Multicast Source Discovery Protocol [MSDP] and
PIM-SM protocols, for native multicast deployment, although it is not
limited to those protocols. In particular, Anycast RP is applicable
in any PIM-SM network that also supports MSDP (MSDP is required so
that the various RPs in the domain maintain a consistent view of the
sources that are active). Note however, a domain deploying Anycast
RP is not required to run MBGP. Finally, a general requirement of
the Anycast RP scheme is that the anycast address MUST NOT be used as
the RP address in the RP's SA messages.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in BCP 14, RFC 2119 [RFC 2119].
2. Problem Definition
The anycast RP solution provides a solution for both fast fail-over
and shared-tree load balancing among any number of active RPs in a
domain.
2.1. Traffic Concentration and Distributing Decapsulation Load Among RPs
While PIM-SM allows for multiple RPs to be defined for a given group,
only one group to RP mapping can be active at a given time. A
traditional deployment mechanism for balancing register decapsulation
load between multiple RPs covering the multicast group space is to
split up the 224.0.0.0/4 space between multiple defined RPs. This is
an acceptable solution as long as multicast traffic remains low, but
has problems as multicast traffic increases, especially because the
network operator defining group space split between RPs does not
always have a priori knowledge of traffic distribution between
groups. This can be overcome via periodic reconfigurations, but
operational considerations cause this type of solution to scale
poorly.
2.2. Sub-optimal Forwarding of Multicast Packets
When a single RP serves a given multicast group, all joins to that
group will be sent to that RP regardless of the topological distance
between the RP and the sources and receivers. Initial data will be
sent towards the RP also until configured the shortest path tree
switch threshold is reached, or the data will always be sent towards
the RP if the network is configured to always use the RP rooted
shared tree. This holds true even if all the sources and the
Kim, et al. Informational