Network Working Group D. Farinacci
Request for Comments: 4610 Y. Cai
Category: Standards Track Cisco Systems
August 2006
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)
使用协议独立多播（PIM）的选播RP
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
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.
此规范允许在仅运行协议独立多播（PIM）的域内使用Anycast RP（集合点）。其他多播协议（如传统上用于解决此问题的多播源发现协议（MSDP））不需要支持Anycast-RP。
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.
[I1]中描述的Anycast RP是一种基于ISP的主干网在PIM集合点（RP）路由器出现故障时用于快速收敛的机制。为了允许接收机和信源会合到最近的RP，来自信源的数据包需要到达所有RP以找到加入的接收机。
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 option.
MSDP的发现是为了解决这个问题，而MSDP的发现正是为了解决这个问题。但是，如果希望保留[I1]的Anycast RP优势，减少协议机制，则可以选择从解决方案空间中删除MSDP。
This memo extends the Register mechanism in PIM so Anycast-RP functionality can be retained without using MSDP.
本备忘录扩展了PIM中的注册机制，因此可以在不使用MSDP的情况下保留Anycast RP功能。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [N2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[N2]中所述进行解释。
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 选择单播IP地址作为RP地址。该地址是静态配置的，或使用动态协议分发给整个域中的所有PIM路由器。
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 选择域中的一组路由器作为此RP地址的RP。这些路由器称为选播RP集。
o Each router in the Anycast-RP set is configured with a loopback interface using the RP address.
o Anycast RP集中的每个路由器都配置了使用RP地址的环回接口。
o Each router in the Anycast-RP set also needs a separate IP address, to be used for communication between the RPs.
o Anycast RP集中的每个路由器还需要一个单独的IP地址，用于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 RP地址或覆盖RP地址的前缀被注入域内的单播路由系统。
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.
o 选播RP集中的每个路由器都配置有选播RP集中所有其他路由器的地址。这必须在集合中的所有RPs中一致配置。
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.
下图说明了使用3个RPs的域，其中接收器根据单播路由度量加入最近的RP，2个源向各自的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].
本节中描述的规则不覆盖[N1]中的规则。它们旨在与[N1]中的规则融为一体。如果对该解释有任何疑问，则以[N1]为准。
S1-----RP1 RP2 RP3------S3
/ \ |
/ \ |
R1 R1' R2
S1-----RP1 RP2 RP3------S3
/ \ |
/ \ |
R1 R1' R2
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).
假设上述场景完全连接，其中R1、R1'和R2是一个组的接收器，S1和S3发送到该组。假设RP1、RP2和RP3都分配了相同的IP地址，该地址用作选播RP地址（假设IP地址是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.
注意，域中RP地址使用的地址（选播RP地址）需要不同于选播RP路由器用于相互通信的地址。
The following procedure is used when S1 starts sourcing traffic:
S1开始寻源流量时使用以下程序：
o S1 sends a multicast packet.
o S1发送多播分组。
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 直接连接到S1的指定路由器（DR）将形成一个PIM寄存器消息，发送到选播RP地址（RPA）。单播路由系统将PIM寄存器消息传送到最近的RP，在本例中为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将接收PIM寄存器消息，将其解封，并将数据包沿共享树向下发送，以将数据包发送到接收器R1和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 set, RP1 assumes the packet came from a DR. If the Register is not addressed to the Anycast-RP address, an error has occurred and it should be rate-limited logged.
o RP1配置有RP2和RP3的IP地址。由于寄存器消息不是来自任意广播RP集中的一个RP，RP1假定数据包来自DR。如果寄存器未寻址到任意广播RP地址，则发生错误，应记录速率限制。
o RP1 will then send a copy of the Register message from S1's DR to both RP2 and RP3. RP1 will use its own IP address as the source address for the PIM Register message.
o 然后，RP1将从S1的DR向RP2和RP3发送注册消息的副本。RP1将使用自己的IP地址作为PIM注册消息的源地址。
o RP1 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP1 MUST create (S1,G) state.
o RP1可以通过向S1触发（S1，G）join消息来连接回源树。但是，RP1必须创建（S1，G）状态。
o RP1 sends a Register-Stop back to the DR. If, for some reason, the Register messages to RP2 and RP3 are lost, then when the Register suppression timer expires in the DR, it will resend Registers to allow another chance for all RPs in the Anycast-RP set to obtain the (S,G) state.
o RP1将寄存器停止发送回DR。如果由于某种原因，发送到RP2和RP3的寄存器消息丢失，则当DR中的寄存器抑制计时器过期时，它将重新发送寄存器，以允许选播RP集中的所有RP再次获得（S，G）状态。
o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2.
o RP2从RP1接收寄存器消息，对其进行解封，并将数据包沿共享树向下发送，以将数据包发送给接收器R2。
o RP2 sends a Register-Stop back to RP1. RP2 MAY wait to send the Register-Stop if it decides to join the source-tree. RP2 should wait until it has received data from the source on the source-tree
o RP2将寄存器停止发送回RP1。如果RP2决定加入源树，它可能会等待发送寄存器停止。RP2应该等待，直到它从源树上的源接收到数据
before sending the Register-Stop. If RP2 decides to wait, the Register-Stop will be sent when the next Register is received. If RP2 decides not to wait, the Register-Stop is sent now.
在发送寄存器之前停止。如果RP2决定等待，则在收到下一个寄存器时将发送寄存器停止。如果RP2决定不等待，则立即发送寄存器停止。
o RP2 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP2 MUST create (S1,G) state.
o RP2可以通过向S1触发（S1，G）join消息来连接回源树。但是，RP2必须创建（S1，G）状态。
o RP3 receives the Register message from RP1, decapsulates it, but since there are no receivers joined for the group, it can discard the packet.
o RP3从RP1接收Register消息，将其解封，但由于没有为该组加入接收器，因此它可以丢弃该数据包。
o RP3 sends a Register-Stop back to RP1.
o RP3将寄存器停止发送回RP1。
o RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1.
o RP3创建（S1，G）状态，因此当接收器在S1开始发送后加入时，RP3可以快速加入S1的源树。
o RP1 processes the Register-Stop from each of RP2 and RP3. There is no specific action taken when processing Register-Stop messages.
o RP1处理来自每个RP2和RP3的寄存器停止。在处理寄存器停止消息时，没有采取任何特定操作。
The procedure for S3 sending follows the same as above but it is RP3 that sends a copy of the Register originated by S3's DR to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain.
S3发送的过程与上述过程相同，但将S3的DR发起的寄存器副本发送到RP1和RP2的是RP3。因此，此示例显示了域中任何与不同RPs关联的源如何到达同一域中也与不同RPs关联的所有接收器。
o An RP will send a copy of a Register only if the Register is received from an IP address not in the Anycast-RP list (i.e., the Register came from a DR and not another RP). An implementation MUST safeguard against inconsistently configured Anycast-RP sets in each RP by copying the Time to Live (TTL) from a Register message to the Register messages it copies and sends to other RPs.
o 仅当从不在Anycast RP列表中的IP地址接收到寄存器时，RP才会发送寄存器副本（即，寄存器来自DR，而不是另一RP）。实现必须通过将生存时间（TTL）从寄存器消息复制到它复制并发送到其他RP的寄存器消息，防止每个RP中配置不一致的选播RP集。
o Each DR that PIM registers for a source will send the message to the Anycast-RP address (which results in the packet getting to the closest physical RP). Therefore, there are no changes to the DR logic.
o PIM为源注册的每个DR都会将消息发送到选播RP地址（这会导致数据包到达最近的物理RP）。因此，DR逻辑没有变化。
o Packets flow to all receivers no matter what RP they have joined to.
o 数据包流向所有接收者，无论他们加入了什么RP。
o The source gets Registered to a single RP by the DR. It's the responsibility of the RP that receives the PIM Register messages from the DR (the closest RP to the DR based on routing metrics) to get the packet to all other RPs in the Anycast-RP set.
o 源由DR注册到单个RP。RP负责从DR接收PIM注册消息（根据路由度量与DR最接近的RP），以将数据包发送到任意广播RP集中的所有其他RP。
o Logic is changed only in the RPs. The logic change is for sending copies of Register messages. Register-Stop processing is unchanged. However, an implementation MAY suppress sending Register-Stop messages in response to a Register received from an RP.
o 逻辑仅在RPs中更改。逻辑更改用于发送寄存器消息的副本。寄存器停止处理保持不变。然而，实现可以抑制响应于从RP接收的寄存器发送寄存器停止消息。
o The rate-limiting of Register and Register-Stop messages are done end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for specific rate-limiting logic between the RPs.
o 寄存器和寄存器停止消息的速率限制是端到端完成的。这是来自DR->RP1->{RP2和RP3}。RPs之间不需要特定的速率限制逻辑。
o When topology changes occur, the existing source-tree adjusts as it does today according to [N1]. The existing shared-trees, as well, adjust as they do today according to [N1].
o 当拓扑发生变化时，现有的源代码树会根据[N1]进行调整，就像今天一样。根据[N1]，现有的共享树也会像今天一样进行调整。
o Physical RP changes are as fast as unicast route convergence, retaining the benefit of [I1].
o 物理RP变化与单播路由收敛一样快，保留了[I1]的优点。
o An RP that doesn't support this specification can be mixed with RPs that do support this specification. However, the non-supporter RP should not have sources registering to it, but may have receivers joined to it.
o 不支持此规范的RP可以与支持此规范的RP混合使用。然而，非支持者RP不应该有注册到它的来源，但是可以有加入到它的接收者。
o If Null Registers are sent (Registers with an IP header and no IP payload), they MUST be replicated to all of the RPs in the Anycast-RP set so that source state remains alive for active sources.
o 如果发送空寄存器（具有IP头且无IP有效负载的寄存器），则必须将它们复制到Anycast RP集中的所有RP，以便活动源的源状态保持活动状态。
o The number of RPs in the Anycast-RP set should remain small so the amount of non-native replication is kept to a minimum.
o Anycast RP集中的RP数量应保持较小，以便将非本机复制量保持在最低限度。
o Since the RP, who receives a Register from the DR, will send copies of the Register to the other RPs at the same time it sends a Register-Stop to the DR, there could be packet loss and lost state in the other RPs until the time the DR sends Register messages again.
o 由于从DR接收寄存器的RP将在向DR发送寄存器停止的同时向其他RP发送寄存器副本，因此在DR再次发送寄存器消息之前，其他RP中可能存在数据包丢失和丢失状态。
The objective of this Anycast-PIM proposal is to remove the dependence on using MSDP. This can be achieved by removing MSDP peering between the Anycast-RPs. However, to advertise internal sources to routers outside of a PIM routing domain and to learn external sources from other routing domains, MSDP may still be required.
此Anycast PIM提案的目的是消除对使用MSDP的依赖。这可以通过删除选播RP之间的MSDP对等来实现。但是，要向PIM路由域之外的路由器公布内部源，并从其他路由域学习外部源，可能仍然需要MSDP。
In this capacity, when there are internal sources that need to be advertised externally, an Anycast-RP that receives a Register message, either from a DR or an Anycast-RP, should process it as described in this specification as well as how to process a Register message as described in [N1]. That means a Source-Active (SA) for the same internal source could be originated by multiple Anycast-RPs doing the MSDP peering. There is nothing inherently wrong with this other than that the source is being advertised into the MSDP infrastructure from multiple places from the source domain. However, if this is not desirable, configuration of one or more (rather than all) Anycast-RP MSDP routers would allow only those routers to originate SAs for the internal source. And in some situations, there is a good possibility not all Anycast-RPs in the set will have MSDP peering sessions so this issue can be mitigated to a certain extent.
在这种情况下，当存在需要对外公布的内部源时，从DR或选播RP接收寄存器消息的选播RP应按照本规范中所述处理该消息，以及如何按照[N1]中所述处理寄存器消息。这意味着同一内部源的源活动（SA）可以由多个执行MSDP对等的选播RP发起。这本身没有什么错，只是源代码从源域的多个位置发布到MSDP基础设施中。但是，如果不希望这样做，则一个或多个（而不是所有）选播RP MSDP路由器的配置将只允许这些路由器为内部源发起SAs。在某些情况下，很有可能并非集中的所有选播RP都有MSDP对等会话，因此可以在一定程度上缓解此问题。
From an Anycast-RP perspective, a source should be considered internal to a domain when it is discovered by an Anycast-RP through a received Register message, regardless of whether the Register message was sent by a DR, another Anycast-RP member, or the router itself.
从Anycast RP的角度来看，当Anycast RP通过接收到的寄存器消息发现源时，无论寄存器消息是由DR、另一个Anycast RP成员还是路由器本身发送的，都应将其视为域内部的源。
For learning sources external to a domain, the MSDP SA messages could arrive at multiple MSDP-peering Anycast-RPs. The rules for processing an SA, according to [I1], should be followed. That is, if G is joined in the domain, an (S,G) join is sent towards the source. And if data accompanies the SA, each Anycast-PIM RP doing MSDP peering will forward the data down each of its respective shared-trees.
对于域外部的学习源，MSDP SA消息可以到达多个MSDP对等选播RP。应遵循[I1]规定的SA处理规则。也就是说，如果在域中加入了G，则会向源发送（S，G）加入。如果SA中有数据，则执行MSDP对等的每个选播PIM RP都会将数据转发到其各自的共享树中。
The above assumes each Anycast-RP has external MSDP peering connections. If this is not the case, the Anycast-PIM routers with the MSDP peering connections would follow the same procedure as if a Data-Register or Null-Register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set.
以上假设每个Anycast RP都有外部MSDP对等连接。如果情况并非如此，则具有MSDP对等连接的Anycast PIM路由器将遵循与从DR或另一Anycast-RP接收数据寄存器或空寄存器相同的过程。也就是说，它们将向Anycast RP集的其他成员发送寄存器。
If there is a mix of Anycast-RPs that do and do not have external MSDP peering connections, then the ones that do must be configured with the set that do not. So Register messages are sent only to the members of the Anycast-RP set that do not have external MSDP peering connections.
如果混合了具有和不具有外部MSDP对等连接的Anycast RP，则必须使用不具有外部MSDP对等连接的集合来配置具有外部MSDP对等连接的那些RP。因此，注册消息仅发送给没有外部MSDP对等连接的Anycast RP集的成员。
The amount of Register traffic generated by this MSDP-peering RP would be equal to the number of active sources external to the domain. The Source-Active state would have to be conveyed to all other RPs in the Anycast-RP set since the MSDP-peering RP would not know about the group membership associated with the other RPs. To
此MSDP对等RP生成的寄存器通信量将等于域外部活动源的数量。源活动状态必须传送到选播RP集中的所有其他RP，因为MSDP对等RP不知道与其他RP关联的组成员身份。到
avoid this periodic control traffic, it is recommended that all Anycast-RPs be configured with external MSDP peering sessions so no RP in the Anycast-RP set will have to originate Register messages on behalf of external sources.
为了避免这种周期性的控制通信，建议所有选播RP配置外部MSDP对等会话，以便选播RP集中的RP不必代表外部源发起注册消息。
Within a routing domain, it is recommended that an Anycast-RP set defined in this specification should not be mixed with MSDP peering among the members. In some cases, the source discovery will work but it may not be obvious to the implementations which sources are local to the domain and which are not. This may affect external MSDP advertisement of internal sources.
在路由域内，建议本规范中定义的选播RP集不应与成员之间的MSDP对等混合。在某些情况下，源发现会起作用，但对于实现来说，哪些源是域本地的，哪些不是。这可能会影响内部源的外部MSDP广告。
Having said that, this document makes no attempt to connect MSDP peering domains together by using Anycast-PIM inside a transit domain.
尽管如此，本文档并未试图通过在传输域内使用Anycast PIM将MSDP对等域连接在一起。
This section describes the security consideration for Register and Register-Stop messages between Anycast-RPs. For PIM messages between DR and RP, please see [N1].
本节描述任意广播RP之间的注册和注册停止消息的安全考虑。有关DR和RP之间的PIM消息，请参阅[N1]。
An attacker may forge a Register message using one of the addresses in the Anycast-RP list in order to achieve one or more of the following effects:
攻击者可以使用Anycast RP列表中的一个地址伪造注册消息，以实现以下一个或多个效果：
1. Overwhelm the target RP in a denial-of-service (DoS) attack 2. Inject unauthorized data to receivers served by the RP 3. Inject unauthorized data and create bogus SA entries in other PIM domains if the target RP has external MSDP peerings
1. 在拒绝服务（DoS）攻击中压倒目标RP 2。向RP 3提供服务的接收器注入未经授权的数据。如果目标RP具有外部MSDP对等，则在其他PIM域中注入未经授权的数据并创建虚假SA条目
An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of-service, the effect of such an attack is limited because an RP usually ignores Register-Stop messages.
攻击者还可以使用Anycast RP列表中的一个地址伪造寄存器停止消息。但是，除了拒绝服务之外，这种攻击的效果也有限，因为RP通常会忽略寄存器停止消息。
The DoS attack using forged Register or Register-Stop messages cannot be prevented. But the RP can still be protected. For example, the RP can rate-limit incoming messages. It can also choose to refuse to process any Register-Stop messages. The actual protection mechanism is implementation specific.
无法防止使用伪造寄存器或寄存器停止消息的DoS攻击。但是RP仍然可以得到保护。例如，RP可以限制传入消息的速率。它还可以选择拒绝处理任何注册停止消息。实际的保护机制是特定于实现的。
The distribution of unauthorized data and bogus Register messages can be prevented using the method described in section 6.3.2 of [N1]. When RP1 sends a copy of a register to RP2, RP1 acts as [N1] describes the DR and RP2 acts as [N1] describes the RP.
使用[N1]第6.3.2节所述的方法，可以防止未经授权数据和虚假注册信息的传播。当RP1将寄存器的副本发送给RP2时，RP1充当[N1]来描述DR，RP2充当[N1]来描述RP。
As described in [N1], an RP can be configured using a unique SA and Security Parameter Index (SPI) for traffic (Registers or Register-Stops) to each member of Anycast-RPs in the list, but this results in a key management problem; therefore, it may be preferable in PIM domains where all Rendezvous Points are under a single administrative control to use the same authentication algorithm parameters (including the key) for all Registered packets in a domain.
如[N1]中所述，可以使用唯一的SA和安全参数索引（SPI）为列表中任意广播RP的每个成员的流量（寄存器或寄存器停止）配置RP，但这会导致密钥管理问题；因此，在PIM域中，如果所有集合点都在单个管理控制下，则对于域中的所有注册分组使用相同的认证算法参数（包括密钥）可能更为可取。
The authors prototyped this document in the cisco IOS and Procket implementations, respectively.
作者分别在cisco IOS和Procket实现中原型化了此文档。
The authors would like to thank John Zwiebel for doing interoperability testing of the two prototype implementations.
作者要感谢John Zwiebel对两个原型实现进行互操作性测试。
The authors would like to thank Thomas Morin from France Telecom for having an extensive discussion on Multicast the Registers to an SSM-based full mesh among the Anycast-RP set. This idea may come in a subsequent document.
作者要感谢来自法国电信的Thomas Morin，他对将寄存器多播到Anycast RP集中基于SSM的全网进行了广泛的讨论。这一想法可能会出现在后续文件中。
And finally, the authors would like to thank the following for their comments on earlier drafts:
最后，作者感谢以下人士对早期草案的评论：
Greg Shepherd (Procket Networks (now Cisco Systems)) Lenny Giuliano (Juniper Networks) Prashant Jhingran (Huawei Technologies) Pekka Savola (CSC/FUNET) Bill Fenner (AT&T) James Lingard (Data Connection) Amit Shukla (Juniper Networks) Tom Pusateri (Juniper Networks)
Greg Shepherd（Procket Networks（现为思科系统））Lenny Giuliano（Juniper Networks）Prashant Jhingran（华为技术）Pekka Savola（CSC/FUNET）Bill Fenner（AT&T）James Lingard（数据连接）Amit Shukla（Juniper Networks）Tom Pusateri（Juniper Networks）
[N1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[N1]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
[N2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N2]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[I1] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[I1]Kim，D.，Meyer，D.，Kilmer，H.，和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播渲染点（RP）机制”，RFC 3446，2003年1月。
Appendix A: Possible Configuration Language
附录A：可能的配置语言
A possible set of commands to be used could be:
要使用的一组可能的命令可以是：
ip pim anycast-rp <anycast-rp-addr> <rp-addr>
ip pim anycast-rp <anycast-rp-addr> <rp-addr>
Where:
哪里：
<anycast-rp-addr> describes the Anycast-RP set for the RP that is assigned to the group range. This IP address is the address that first-hop and last-hop PIM routers use to register and join to.
<anycast rp addr>描述分配给组范围的rp的anycast rp集。此IP地址是第一跳和最后一跳PIM路由器用于注册和加入的地址。
<rp-addr> describes the IP address where Register messages copies are sent to. This IP address is any address assigned to the RP router not including the <anycast-rp-addr>.
<rp addr>描述注册消息副本发送到的IP地址。此IP地址是分配给RP路由器的任何地址，不包括<anycast RP addr>。
Example:
例子：
From the illustration above, the configuration commands would be:
从上图中可以看出，配置命令为：
ip pim anycast-rp RPA RP1 ip pim anycast-rp RPA RP2 ip pim anycast-rp RPA RP3
ip pim anycast rp RPA RP1 ip pim anycast rp RPA RP2 ip pim anycast rp RPA RP3
Comment:
评论：
It may be useful to include the local router IP address in the command set so the above lines can be cut-and-pasted or scripted into all the RPs in the Anycast-RP set.
在命令集中包含本地路由器IP地址可能很有用，这样就可以将上面的行剪切、粘贴或编写脚本到Anycast RP集中的所有RP中。
But the implementation would have to be aware of its own address and not inadvertently send a Register to itself.
但实现必须知道自己的地址，而不是无意中向自己发送一个寄存器。
Authors' Addresses
作者地址
Dino Farinacci Cisco Systems
迪诺·法里纳奇思科系统公司
EMail: dino@cisco.com
EMail: dino@cisco.com
Yiqun Cai Cisco Systems
蔡益群思科系统
EMail: ycai@cisco.com
EMail: ycai@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。