Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
RFC 3446

Network Working Group                                             D. Kim
Request for Comments: 3446                                         Verio
Category: Informational                                         D. Meyer
                                                               H. Kilmer
                                                            D. Farinacci
                                                        Procket Networks
                                                            January 2003

             Anycast Rendevous Point (RP) mechanism using
                 Protocol Independent Multicast (PIM)
             and Multicast Source Discovery Protocol (MSDP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes a mechanism to allow for an arbitrary number
   of Rendevous Points (RPs) per group in a single shared-tree Protocol
   Independent Multicast-Sparse Mode (PIM-SM) domain.

1. Introduction

   PIM-SM, as defined in RFC 2362, allows for only a single active RP
   per group, and as such the decision of optimal RP placement can
   become problematic for a multi-regional network deploying PIM-SM.

   Anycast RP relaxes an important constraint in PIM-SM, namely, that
   there can be only one group to RP mapping can be active at any time.
   The single mapping property has several implications, including
   traffic concentration, lack of scalable register decapsulation (when
   using the shared tree), slow convergence when an active RP fails,
   possible sub-optimal forwarding of multicast packets, and distant RP
   dependencies.  These properties of PIM-SM have been demonstrated in
   native continental or inter-continental scale multicast deployments.
   As a result, it is clear that ISP backbones require a mechanism that
   allows definition of multiple active RPs per group in a single PIM-SM
   domain.  Further, any such mechanism should also address the issues
   addressed above.

Kim, et al.                  Informational                      [Page 1]
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 [RFC2119].

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