Anycast-RP Using Protocol Independent Multicast (PIM)
RFC 4610

Document Type RFC - Proposed Standard (August 2006; No errata)
Authors Yiqun Cai  , Dino Farinacci 
Last updated 2015-10-14
Replaces draft-farinacci-pim-anycast-rp
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4610 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Bill Fenner
Send notices to (None)
Network Working Group                                       D. Farinacci
Request for Comments: 4610                                        Y. Cai
Category: Standards Track                                  Cisco Systems
                                                             August 2006

         Anycast-RP Using Protocol Independent Multicast (PIM)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This specification allows Anycast-RP (Rendezvous Point) to be used
   inside a domain that runs Protocol Independent Multicast (PIM) only.
   Other multicast protocols (such as Multicast Source Discovery
   Protocol (MSDP), which has been used traditionally to solve this
   problem) are not required to support Anycast-RP.

1.  Introduction

   Anycast-RP as described in [I1] is a mechanism that ISP-based
   backbones have used to get fast convergence when a PIM Rendezvous
   Point (RP) router fails.  To allow receivers and sources to
   Rendezvous to the closest RP, the packets from a source need to get
   to all RPs to find joined receivers.

   This notion of receivers finding sources is the fundamental problem
   of source discovery that MSDP was intended to solve.  However, if one
   would like to retain the Anycast-RP benefits from [I1] with less
   protocol machinery, removing MSDP from the solution space is an

   This memo extends the Register mechanism in PIM so Anycast-RP
   functionality can be retained without using MSDP.

Farinacci & Cai             Standards Track                     [Page 1]
RFC 4610                  Anycast-RP using PIM               August 2006

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [N2].

2.  Overview

   o A unicast IP address is chosen to use as the RP address.  This
     address is statically configured, or distributed using a dynamic
     protocol, to all PIM routers throughout the domain.

   o A set of routers in the domain is chosen to act as RPs for this RP
     address.  These routers are called the Anycast-RP set.

   o Each router in the Anycast-RP set is configured with a loopback
     interface using the RP address.

   o Each router in the Anycast-RP set also needs a separate IP address,
     to be used for communication between the RPs.

   o The RP address, or a prefix that covers the RP address, is injected
     into the unicast routing system inside of the domain.

   o Each router in the Anycast-RP set is configured with the addresses
     of all other routers in the Anycast-RP set.  This must be
     consistently configured in all RPs in the set.

3.  Mechanism

   The following diagram illustrates a domain using 3 RPs where
   receivers are joining to the closest RP according to where unicast
   routing metrics take them and 2 sources sending packets to their
   respective RPs.

   The rules described in this section do not override the rules in
   [N1].  They are intended to blend with the rules in [N1].  If there
   is any question on the interpretation, precedent is given to [N1].

         S1-----RP1              RP2                RP3------S3
                / \               |
               /   \              |
              R1   R1'            R2

Farinacci & Cai             Standards Track                     [Page 2]
RFC 4610                  Anycast-RP using PIM               August 2006

   Assume the above scenario is completely connected where R1, R1', and
   R2 are receivers for a group, and S1 and S3 send to that group.
   Assume RP1, RP2, and RP3 are all assigned the same IP address, which
   is used as the Anycast-RP address (let's say the IP address is RPA).

   Note, the address used for the RP address in the domain (the
   Anycast-RP address) needs to be different than the addresses used by
   the Anycast-RP routers to communicate with each other.

   The following procedure is used when S1 starts sourcing traffic:

   o S1 sends a multicast packet.

   o The designated router (DR) directly attached to S1 will form a PIM
     Register message to send to the Anycast-RP address (RPA).  The
     unicast routing system will deliver the PIM Register message to the
     nearest RP, in this case RP1.

   o RP1 will receive the PIM Register message, decapsulate it, and send
     the packet down the shared-tree to get the packet to receivers R1
     and R1'.

   o RP1 is configured with RP2 and RP3's IP address.  Since the
     Register message did not come from one of the RPs in the anycast-RP
Show full document text