Network Working Group D. Kim
Request for Comments: 3446 Verio
Category: Informational D. Meyer
H. Kilmer
D. Farinacci
Procket Networks
January 2003
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)
使用协议独立多播（PIM）和多播源发现协议（MSDP）的选播渲染点（RP）机制
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.
版权所有（C）互联网协会（2003年）。版权所有。
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.
本文档描述了一种机制，该机制允许在单个共享树协议独立的多播稀疏模式（PIM-SM）域中每个组具有任意数量的渲染点（RP）。
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.
RFC 2362中定义的PIM-SM只允许每个组有一个活动RP，因此，对于部署PIM-SM的多区域网络，最佳RP布局的决策可能会产生问题。
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.
Anycast RP放松了PIM-SM中的一个重要约束，即在任何时候只有一个组可以激活RP映射。单一映射属性有几个含义，包括流量集中、缺少可伸缩寄存器去封装（使用共享树时）、活动RP失败时收敛缓慢、多播数据包的可能次优转发以及远程RP依赖性。PIM-SM的这些特性已经在本地大陆或跨大陆规模的多播部署中得到了证明。因此，很明显，ISP主干网需要一种机制，允许在单个PIM-SM域中为每个组定义多个活动RP。此外，任何此类机制也应解决上述问题。
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.
这里描述的机制旨在解决域中的RPs之间更好的故障转移（收敛时间）和寄存器去封装负载共享（同样，当使用共享树时）的需要。它主要用于使用MBGP、多播源发现协议[MSDP]和PIM-SM协议的网络中的应用程序，用于本机多播部署，但不限于这些协议。特别是，Anycast RP适用于也支持MSDP的任何PIM-SM网络（需要MSDP，以便域中的各种RP保持活动源的一致视图）。但是请注意，运行MBGP不需要部署Anycast RP的域。最后，选播RP方案的一般要求是，选播地址不得用作RP的SA消息中的RP地址。
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].
关键字必须、不得、可、可选、必需、推荐、应、不应、不应按照BCP 14、RFC 2119[RFC2119]中的定义进行解释。
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.
anycast RP解决方案为域中任意数量的活动RP之间的快速故障转移和共享树负载平衡提供了解决方案。
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.
虽然PIM-SM允许为给定的组定义多个RP，但在给定时间只能激活一个组到RP的映射。用于平衡覆盖多播组空间的多个RP之间的寄存器解除封装负载的传统部署机制是在多个定义的RP之间拆分224.0.0.0/4空间。只要多播通信量仍然较低，这是一个可接受的解决方案，但随着多播通信量的增加，会出现问题，特别是因为定义RPs之间分组空间的网络运营商并不总是具有组之间通信量分布的先验知识。这可以通过周期性的重新配置来克服，但是操作方面的考虑导致这种解决方案的可扩展性很差。
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
当单个RP服务于给定的多播组时，该组的所有连接都将发送到该RP，而不管RP与源和接收器之间的拓扑距离如何。初始数据也将发送到RP，直到达到配置的最短路径树切换阈值，或者如果网络配置为始终使用RP根共享树，则数据将始终发送到RP。即使所有来源和
receivers are in any given single region, and RP is topologically distant from the sources and the receivers. This is an artifact of the dynamic nature of multicast group members, and of the fact that operators may not always have a priori knowledge of the topological placement of the group members.
接收器位于任何给定的单个区域，并且RP在拓扑上与源和接收器保持距离。这是多播组成员的动态特性的产物，也是运营商可能并不总是对组成员的拓扑位置有先验知识这一事实的产物。
Taken together, these effects can mean that (for example) although all the sources and receivers of a given group are in Europe, they are joining towards the RP in the USA and the data will be traversing a relatively expensive pipe(s) twice, once to get to RP, and back down the RP rooted tree again, creating inefficient use of expensive resources.
综上所述，这些影响可能意味着（例如），尽管给定组的所有源和接收器都在欧洲，但它们在美国加入了RP，数据将两次穿过相对昂贵的管道，一次到达RP，然后再次返回RP根树，从而造成昂贵资源的低效使用。
As outlined above, a single active RP per group may cause local sources and receivers to become dependent on a topologically distant RP. In addition, when multiple RPs are configured, there can be considerable convergence delay involved in switching to the backup RP. This delay may exist independent of the toplogical location of the primary and backup RPs.
如上所述，每个组的单个活动RP可能会导致本地源和接收器依赖于拓扑上距离较远的RP。此外，当配置多个RP时，切换到备份RP可能会有相当大的收敛延迟。此延迟可能独立于主RP和备份RP的拓扑位置而存在。
Given the problem set outlined above, a good solution would allow an operator to configure multiple RPs per group, and distribute those RPs in a topologically significant manner to the sources and receivers.
鉴于上述问题集，一个好的解决方案将允许运营商为每组配置多个RP，并以具有拓扑意义的方式将这些RP分发给源和接收器。
All the RPs serving a given group or set of groups are configured with an identical anycast address, using a numbered interface on the RPs (frequently a logical interface such as a loopback is used). RPs then advertise group to RP mappings using this interface address. This will cause group members (senders) to join (register) towards the topologically closest RP. RPs MSDP peer with each other using an address unique to each RP. Since the anycast address is not a unique address (by definition), a router MUST NOT choose the anycast unicast address as the router ID, as this can prevent peerings and/or adjacencies from being established.
为给定组或组集提供服务的所有RPs都使用相同的选播地址进行配置，使用RPs上的编号接口（通常使用诸如环回之类的逻辑接口）。然后，RPs使用此接口地址公布组到RP的映射。这将导致组成员（发送方）使用每个RP唯一的地址相互加入（注册）拓扑上最接近的RP。RPs MSDP对等方。由于选播地址不是唯一地址（根据定义），路由器不得选择选播单播地址作为路由器ID，因为这可以防止建立对等和/或邻接。
In summary then, the following steps are required:
总之，需要以下步骤：
The first step is to create the set of group-to-anycast-RP-address mappings to be used in the domain. Each RP participating in an anycast RP set must be configured with a consistent set of group to RP address mappings. This mapping will be used by the non-RP routers in the domain.
第一步是创建要在域中使用的组到选播RP地址映射集。参与选播RP集的每个RP必须配置一组一致的组到RP地址映射。此映射将由域中的非RP路由器使用。
The next step is to configure each RP for the group range with the anycast RP address. If a dynamic mechanism, such as auto-RP or the PIMv2 bootstrap mechanism, is being used to advertise group to RP mappings, the anycast IP address should be used for the RP address.
下一步是使用选播RP地址为组范围配置每个RP。如果使用动态机制（如auto RP或PIMv2引导机制）公布组到RP的映射，则应将选播IP地址用于RP地址。
3.1.3. Configure MSDP peerings between each of the anycast RPs in the set
3.1.3. 在集合中的每个选播RP之间配置MSDP对等
Unlike the group to RP mapping advertisements, MSDP peerings must use an IP address that is unique to the endpoints; that is, the MSDP peering endpoints MUST use a unicast rather than anycast address. A general guideline is to follow the addressing of the BGP peerings, e.g., loopbacks for iBGP peering, physical interface addresses for eBGP peering. Note that the anycast address MUST NOT be used as the RP address in SA messages (as this would case the peer-RPF check to fail).
与组到RP映射广告不同，MSDP对等必须使用端点唯一的IP地址；也就是说，MSDP对等端点必须使用单播地址而不是选播地址。一般准则是遵循BGP对等的寻址，例如，iBGP对等的环回，eBGP对等的物理接口地址。请注意，选播地址不得用作SA消息中的RP地址（因为这会导致对等RPF检查失败）。
3.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings
3.1.4. 使用组到选播RP地址映射配置非RP
Finally, each non-RP router must learn the set of group to RP mappings. This could be done via static configuration, auto-RP, or by PIMv2 bootstrap mechanism.
最后，每个非RP路由器必须学习组到RP的映射集。这可以通过静态配置、自动RP或PIMv2引导机制实现。
3.1.5. Ensure that the anycast IP address is reachable by all routers in the domain
3.1.5. 确保域中的所有路由器都可以访问选播IP地址
This is typically accomplished by causing each RP to inject the /32 into the domain's IGP.
这通常是通过使每个RP将/32注入域的IGP来实现的。
Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages [MSDP]. The BGP routing tables are examined to determine which peer is the next hop towards the originating RP of the SA message. Such a peer is called an "RPF peer". See [MSDP] for details of the Peer-RPF check.
每个MSDP对等方以“对等RPF泛洪”方式接收和转发来自RP地址的消息。对等RPF泛洪的概念是关于转发SA消息[MSDP]。检查BGP路由表以确定哪个对等方是SA消息的发起RP的下一跳。这种对等称为“RPF对等”。有关对等RPF检查的详细信息，请参阅[MSDP]。
It should be noted that using MSDP in this way forces the creation of (S,G) state along the path from the receiver to the source. This state may not be present if a single RP was used and receivers were forced to stay on the shared tree.
应该注意的是，以这种方式使用MSDP会强制沿从接收器到源的路径创建（S，G）状态。如果使用了单个RP并且接收器被强制停留在共享树上，则此状态可能不存在。
Since the solution described here makes heavy use of anycast addressing, care must be taken to avoid spoofing. In particular unicast routing and PIM RPs must be protected.
由于这里描述的解决方案大量使用了选播寻址，因此必须小心避免欺骗。特别是单播路由和PIM RPs必须受到保护。
Both internal and external unicast routing can be weakly protected with keyed MD5 [RFC1828], as implemented in an internal protocol such as OSPF [RFC2328] or in BGP [RFC2385]. More generally, IPSEC [RFC2401] could be used to provide protocol integrity for the unicast routing system.
内部和外部单播路由都可以使用密钥MD5[RFC1828]进行弱保护，如在内部协议（如OSPF[RFC2328]或BGP[RFC2385]中实现的那样。更一般地说，IPSEC[RFC2401]可用于为单播路由系统提供协议完整性。
While not a security issue, it is worth noting that if unicast routing is unstable, then the actual RP that source or receiver is using will be subject to the same instability.
虽然不是安全问题，但值得注意的是，如果单播路由不稳定，那么源或接收器使用的实际RP将受到相同的不稳定性的影响。
The mechanisms described in [RFC2362] should be used to provide protocol message integrity protection and group-wise message origin authentication.
[RFC2362]中描述的机制应用于提供协议消息完整性保护和分组消息源身份验证。
As is the the case for BGP, MSDP peers can be protected using keyed MD5 [RFC1828].
与BGP的情况一样，可以使用键控MD5[RFC1828]保护MSDP对等点。
John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided insightful comments on earlier versions for this idea.
John Meylor、Bill Fenner、Dave Thaler和Tom Pusateri对这个想法的早期版本提供了深刻的评论。
This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the authors.
本备忘录是互联网工程任务组运营和管理领域MBONE部署工作组（MBONED）的产品。向提交意见<mboned@ns.uoregon.edu>或者是作者。
[MSDP] D. Meyer and B. Fenner, Editors, "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP]D.Meyer和B.Fenner，编辑，“多播源发现协议（MSDP）”，正在进行中。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1995年8月。
[RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC1828]Metzger，P.和W.Simpson，“使用密钥MD5的IP认证”，RFC 1828，1995年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
Dorian Kim Verio, Inc. EMail: dorian@blackrose.org
Dorian Kim Verio，Inc.电子邮件：dorian@blackrose.org
Hank Kilmer EMail: hank@rem.com
Hank Kilmer电子邮件：hank@rem.com
Dino Farinacci Procket Networks EMail: dino@procket.com
Dino Farinaci Procket Networks电子邮件：dino@procket.com
David Meyer EMail: dmm@maoz.com
David Meyer电子邮件：dmm@maoz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。