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