Network Working Group                                         M. McBride
Request for Comments: 4611                                     J. Meylor
BCP: 121                                                        D. Meyer
Category: Best Current Practice                              August 2006
        
Network Working Group                                         M. McBride
Request for Comments: 4611                                     J. Meylor
BCP: 121                                                        D. Meyer
Category: Best Current Practice                              August 2006
        

Multicast Source Discovery Protocol (MSDP) Deployment Scenarios

多播源发现协议(MSDP)部署场景

Status of This Memo

关于下段备忘

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

Abstract

摘要

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM).

本文档描述了多播源发现协议(MSDP)的域内和域间部署以及与协议无关的多播稀疏模式(PIM-SM)的最佳当前实践。

Table of Contents

目录

   1. Introduction ....................................................2
      1.1. BCP, Experimental Protocols, and Normative References ......3
   2. Inter-domain MSDP Peering Scenarios .............................4
      2.1. Peering between PIM Border Routers .........................4
      2.2. Peering between Non-Border Routers .........................5
      2.3. MSDP Peering without BGP ...................................7
      2.4. MSDP Peering at a Multicast Exchange .......................7
   3. Intra-domain MSDP Peering Scenarios .............................7
      3.1. Peering between MSDP- and MBGP-Configured Routers ..........8
      3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) .................8
      3.3. Hierarchical Mesh Groups ...................................9
      3.4. MSDP and Route Reflectors .................................10
      3.5. MSDP and Anycast RPs ......................................11
   4. Security Considerations ........................................11
      4.1. Filtering SA Messages .....................................11
      4.2. SA Message State Limits ...................................12
   5. Acknowledgements ...............................................12
   6. References .....................................................12
      6.1. Normative References ......................................12
      6.2. Informative References ....................................13
        
   1. Introduction ....................................................2
      1.1. BCP, Experimental Protocols, and Normative References ......3
   2. Inter-domain MSDP Peering Scenarios .............................4
      2.1. Peering between PIM Border Routers .........................4
      2.2. Peering between Non-Border Routers .........................5
      2.3. MSDP Peering without BGP ...................................7
      2.4. MSDP Peering at a Multicast Exchange .......................7
   3. Intra-domain MSDP Peering Scenarios .............................7
      3.1. Peering between MSDP- and MBGP-Configured Routers ..........8
      3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) .................8
      3.3. Hierarchical Mesh Groups ...................................9
      3.4. MSDP and Route Reflectors .................................10
      3.5. MSDP and Anycast RPs ......................................11
   4. Security Considerations ........................................11
      4.1. Filtering SA Messages .....................................11
      4.2. SA Message State Limits ...................................12
   5. Acknowledgements ...............................................12
   6. References .....................................................12
      6.1. Normative References ......................................12
      6.2. Informative References ....................................13
        
1. Introduction
1. 介绍

MSDP [RFC3618] is used primarily in two deployment scenarios:

MSDP[RFC3618]主要用于两种部署方案:

o Between PIM Domains

o PIM域之间

MSDP can be used between Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601] domains to convey information about active sources available in other domains. MSDP peering used in such cases is generally one-to-one peering, and utilizes the deterministic peer-RPF (Reverse Path Forwarding) rules described in the MSDP specification (i.e., it does not use mesh-groups). Peerings can be aggregated on a single MSDP peer. Such a peer can typically have from one to hundreds of peerings, which is similar in scale to BGP peerings.

MSDP可在协议独立多播稀疏模式(PIM-SM)[RFC4601]域之间使用,以传递有关其他域中可用活动源的信息。在这种情况下使用的MSDP对等通常是一对一对等,并利用MSDP规范中描述的确定性对等RPF(反向路径转发)规则(即,它不使用网格组)。对等可以聚合到单个MSDP对等上。这样的对等点通常可以有一到数百个对等点,其规模类似于BGP对等点。

o Within a PIM Domain

o 在PIM域中

MSDP is often used between Anycast Rendezvous Points (Anycast-RPs) [RFC3446] within a PIM domain to synchronize information about the active sources being served by each Anycast-RP peer (by virtue of IGP reachability). MSDP peering used in this scenario is typically based on MSDP mesh groups, where anywhere from two to tens of peers can comprise a given mesh group, although more than ten is not typical. One or more of these mesh-group peers may also have additional one-to-one peerings with MSDP peers outside that PIM domain for discovery of external sources. MSDP for anycast-RP without external MSDP peering is a valid deployment option and common.

MSDP通常在PIM域内的选播会合点(选播RPs)[RFC3446]之间使用,以同步关于每个选播RP对等方所服务的活动源的信息(凭借IGP可达性)。此场景中使用的MSDP对等通常基于MSDP网格组,其中两个到几十个对等可以组成给定的网格组,但不典型的情况是超过十个。一个或多个网状组对等点还可以与该PIM域之外的MSDP对等点进行额外的一对一对等,以发现外部源。无外部MSDP对等的anycast RP的MSDP是一种有效的部署选项,也是常见的。

Current best practice for MSDP deployment utilizes PIM-SM and the Border Gateway Protocol with multi-protocol extensions (MBGP) [RFC4271, RFC2858]. This document outlines how these protocols work together to provide an intra-domain and inter-domain Any Source Multicast (ASM) service.

MSDP部署的当前最佳实践利用PIM-SM和带多协议扩展的边界网关协议(MBGP)[RFC4271,RFC2858]。本文档概述了这些协议如何协同工作以提供域内和域间任意源多播(ASM)服务。

The PIM-SM specification assumes that SM operates only in one PIM domain. MSDP is used to enable the use of multiple PIM domains by distributing the required information about active multicast sources to other PIM domains. Due to breaking the Internet multicast infrastructure down to multiple PIM domains, MSDP also enables the possibility of setting policy on the visibility of the groups and sources.

PIM-SM规范假定SM仅在一个PIM域中运行。MSDP通过将有关活动多播源的所需信息分发给其他PIM域,用于启用多个PIM域的使用。由于将Internet多播基础设施分解为多个PIM域,MSDP还允许设置组和源可见性策略。

Transit IP providers typically deploy MSDP to be part of the global multicast infrastructure by connecting to their upstream and peer multicast networks using MSDP.

传输IP提供商通常通过使用MSDP连接到其上游和对等多播网络,将MSDP部署为全球多播基础设施的一部分。

Edge multicast networks typically have two choices: to use their Internet providers' RP, or to have their own RP and connect it to their ISP using MSDP. By deploying their own RP and MSDP, they can use internal multicast groups that are not visible to the provider's RP. This helps internal multicast be able to continue to work in the event that there is a problem with connectivity to the provider or that the provider's RP/MSDP is experiencing difficulties. In the simplest cases, where no internal multicast groups are necessary, there is often no need to deploy MSDP.

边缘多播网络通常有两种选择:使用其互联网提供商的RP,或拥有自己的RP并使用MSDP将其连接到ISP。通过部署自己的RP和MSDP,他们可以使用提供商的RP看不到的内部多播组。这有助于内部多播在与提供商的连接出现问题或提供商的RP/MSDP遇到困难时继续工作。在最简单的情况下,不需要内部多播组,通常不需要部署MSDP。

1.1. BCP, Experimental Protocols, and Normative References
1.1. BCP、实验方案和规范性参考文献

This document describes the best current practice for a widely deployed Experimental protocol, MSDP. There is no plan to advance the MSDP's status (for example, to Proposed Standard). The reasons for this include:

本文档描述了广泛部署的实验协议MSDP的当前最佳实践。没有计划提高MSDP的状态(例如,达到拟定标准)。原因包括:

o MSDP was originally envisioned as a temporary protocol to be supplanted by whatever the IDMR working group produced as an inter-domain protocol. However, the IDMR WG (or subsequently, the BGMP WG) never produced a protocol that could be deployed to replace MSDP.

o MSDP最初被设想为一个临时协议,由IDMR工作组作为域间协议产生的任何协议取代。然而,IDMR工作组(或随后的BGMP工作组)从未产生过可用于替代MSDP的协议。

o One of the primary reasons given for MSDP to be classified as Experimental was that the MSDP Working Group came up with modifications to the protocol that the WG thought made it better but that implementors didn't see any reasons to deploy. Without these modifications (e.g., UDP or GRE encapsulation), MSDP can have negative consequences to initial packets in datagram streams.

o MSDP被归类为实验性协议的一个主要原因是,MSDP工作组提出了对协议的修改,工作组认为这些修改使协议变得更好,但实施者看不到任何部署的理由。如果没有这些修改(例如UDP或GRE封装),MSDP可能会对数据报流中的初始数据包产生负面影响。

o Scalability: Although we don't know what the hard limits might be, readvertising everything you know every 60 seconds clearly limits the amount of state you can advertise.

o 可伸缩性:虽然我们不知道硬限制可能是什么,但每60秒阅读一次你所知道的所有内容显然限制了你可以宣传的状态数量。

o MSDP reached nearly ubiquitous deployment as the de facto standard inter-domain multicast protocol in the IPv4 Internet.

o MSDP作为IPv4 Internet中事实上的标准域间多播协议几乎无处不在。

o No consensus could be reached regarding the reworking of MSDP to address the many concerns of various constituencies within the IETF. As a result, a decision was taken to document what is (ubiquitously) deployed and to move that document to Experimental. While advancement of MSDP to Proposed Standard was considered, for the reasons mentioned above, it was immediately discarded.

o 未能就修改MSDP以解决IETF内各成员关注的诸多问题达成共识。因此,决定记录(普遍)部署的内容,并将该文档移动到实验平台。在考虑将MSDP提升至拟定标准的同时,出于上述原因,立即将其废弃。

o The advent of protocols such as source-specific multicast and bi-directional PIM, as well as embedded RP techniques for IPv6, have further reduced consensus that a replacement protocol for MSDP for the IPv4 Internet is required.

o 源特定多播和双向PIM等协议的出现,以及IPv6嵌入式RP技术的出现,进一步降低了人们对IPv4互联网需要MSDP替代协议的共识。

The RFC Editor's policy regarding references is that they be split into two categories known as "normative" and "informative". Normative references specify those documents that must be read for one to understand or implement the technology in an RFC (or whose technology must be present for the technology in the new RFC to work) [RFCED]. In order to understand this document, one must also understand both the PIM and MSDP documents. As a result, references to these documents are normative.

RFC编辑关于参考文献的政策是将参考文献分为“规范性”和“信息性”两类。规范性参考文件规定了为理解或实施RFC中的技术而必须阅读的文件(或新RFC中的技术必须存在的文件)[RFCED]。为了理解本文件,还必须理解PIM和MSDP文件。因此,对这些文件的引用是规范性的。

The IETF has adopted the policy that BCPs must not have normative references to Experimental protocols. However, this document is a special case in that the underlying Experimental document (MSDP) is not planned to be advanced to Proposed Standard.

IETF采取的政策是,BCP不得对实验协议进行规范性引用。然而,本文件是一个特例,因为基本实验文件(MSDP)不计划按照拟定标准进行改进。

The MBONED Working Group has requested approval under the Variance Procedure as documented in RFC 2026 [RFC2026]. The IESG followed the Variance Procedure and, after an additional 4 week IETF Last Call, evaluated the comments and status, and has approved this document.

MBONED工作组已根据RFC 2026[RFC2026]中记录的变更程序请求批准。IESG遵循变更程序,在额外的4周IETF最后一次呼叫后,评估了评论和状态,并批准了本文件。

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 RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

2. Inter-domain MSDP Peering Scenarios
2. 域间MSDP对等场景

The following sections describe the most common inter-domain MSDP peering possibilities and their deployment options.

以下各节介绍了最常见的域间MSDP对等可能性及其部署选项。

2.1. Peering between PIM Border Routers
2.1. PIM边界路由器之间的对等

In this case, the MSDP peers within the domain have their own RP located within a bounded PIM domain. In addition, the domain will typically have its own Autonomous System (AS) number and one or more MBGP speakers. The domain may also have multiple MSDP speakers. Each border router has an MSDP and MBGP peering with its peer routers. These external MSDP peering deployments typically configure the MBGP peering and MSDP peering using the same directly connected next hop peer IP address or other IP address from the same router. Typical deployments of this type are providers who have a direct peering with other providers, providers peering at an exchange, or providers who use their edge router to MSDP/MBGP peer with customers.

在这种情况下,域内的MSDP对等方在有界PIM域内拥有自己的RP。此外,域通常具有自己的自治系统(AS)号和一个或多个MBGP扬声器。域还可能有多个MSDP扬声器。每个边界路由器都有一个MSDP和MBGP与其对等路由器进行对等。这些外部MSDP对等部署通常使用同一直接连接的下一跳对等IP地址或来自同一路由器的其他IP地址配置MBGP对等和MSDP对等。这种类型的典型部署包括与其他提供商直接对等的提供商、在交换机上对等的提供商,或使用其边缘路由器与客户进行MSDP/MBGP对等的提供商。

For a direct peering inter-domain environment to be successful, the first AS in the MBGP best path to the originating RP should be the same as the AS of the MSDP peer. As an example, consider the following topology:

要使直接对等域间环境成功,MBGP中到原始RP的第一条AS最佳路径应与MSDP对等方的AS相同。作为一个例子,考虑以下拓扑:

         AS1----AS2----AS4
         |    /
         |   /
         |  /
         AS3
        
         AS1----AS2----AS4
         |    /
         |   /
         |  /
         AS3
        

In this case, AS4 receives a Source Active (SA) message, originated by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP first hop AS from AS4, in the best path to the originating RP, is AS2. The AS of the sending MSDP peer is also AS2. In this case, the peer-Reverse Path Forwarding check (peer-RPF check) passes, and the SA message is forwarded.

在这种情况下,AS4从AS2接收由AS1发起的源活动(SA)消息。AS2还具有与AS4的MBGP对等。从AS4到发起RP的最佳路径中的MBGP第一跳为AS2。发送MSDP对等方的AS也是AS2。在这种情况下,对等反向路径转发检查(对等RPF检查)通过,SA消息被转发。

A peer-RPF failure would occur in this topology when the MBGP first hop AS, in the best path to the originating RP, is AS2 and the origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH information prevents endless looping of SA packets.

当到达发起RP的最佳路径中的MBGP第一跳AS为AS2且发送MSDP对等方的起始AS为AS3时,该拓扑中将发生对等RPF故障。这种对BGP作为路径信息的依赖防止了SA数据包的无限循环。

Router code, which has adopted the latest rules in the MSDP document, will relax the rules between AS's a bit. In the following topology, we have an MSDP peering between AS1<->AS3 and AS3<->AS4:

路由器代码采用了MSDP文档中的最新规则,将稍微放宽AS之间的规则。在以下拓扑中,我们在AS1<->AS3和AS3<->AS4之间有一个MSDP对等:

                               RP
         AS1----AS2----AS3----AS4
        
                               RP
         AS1----AS2----AS3----AS4
        

If the first AS in best path to the RP does not equal the MSDP peer, MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3, since AS2 is the first AS in the MBGP best path to AS4 RP. With the latest MSDP document compliant code, AS1 will choose the peer in the closest AS along best AS path to the RP. AS1 will then accept SA's coming from AS3. If there are multiple MSDP peers to routers within the same AS, the peer with the highest IP address is chosen as the RPF peer.

如果到RP的第一个AS最佳路径不等于MSDP对等点,则MSDP对等点RPF将失败。因此AS1无法与AS3进行MSDP对等,因为AS2是MBGP中通向AS4 RP的第一个AS最佳路径。使用最新的符合MSDP文档的代码,AS1将选择距离RP最近的AS最佳路径中的对等方。AS1随后将接受来自AS3的SA。如果在同一个中有多个MSDP对等点到路由器,则选择具有最高IP地址的对等点作为RPF对等点。

2.2. Peering between Non-Border Routers
2.2. 非边界路由器之间的对等

For MSDP peering between border routers, intra-domain MSDP scalability is restricted because it is necessary to also maintain MBGP and MSDP peerings internally towards their border routers. Within the intra-domain, the border router becomes the announcer of the next hop towards the originating RP. This requires that all intra-domain MSDP peerings mirror the MBGP path back towards the border router. External MSDP (eMSDP) peerings rely upon AS path for peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the announcer of the next hop.

对于边界路由器之间的MSDP对等,域内MSDP可伸缩性受到限制,因为还需要在内部维护MBGP和MSDP对其边界路由器的对等。在域内,边界路由器成为下一跳到发起RP的播音器。这要求所有域内MSDP对等将MBGP路径镜像回边界路由器。外部MSDP(eMSDP)对等依赖于AS路径进行对等RPF检查,而内部MSDP(iMSDP)对等依赖于下一跳的播音器。

While the eMBGP peer is typically directly connected between border routers, it is common for the eMSDP peer to be located deeper into the transit provider's AS. Providers, which desire more flexibility in MSDP peering placement, commonly choose a few dedicated routers within their core networks for the inter-domain MSDP peerings to their customers. These core MSDP routers will also typically be in the provider's intra-domain MSDP mesh group and be configured for Anycast RP. All multicast routers in the provider's AS should statically point to the Anycast RP address. Static RP assignment is the most commonly used method for group-to-RP mapping due to its deterministic nature. Auto-RP [RFC4601] and/or the Bootstrap Router (BSR) [BSR] dynamic RP mapping mechanisms could also be used to disseminate RP information within the provider's network

虽然eMBGP对等点通常直接连接在边界路由器之间,但eMSDP对等点通常位于传输提供商AS的较深处。提供商希望在MSDP对等放置方面具有更大的灵活性,通常会在其核心网络中选择一些专用路由器,用于向其客户进行域间MSDP对等。这些核心MSDP路由器通常也位于提供商的域内MSDP mesh组中,并为Anycast RP配置。提供商AS中的所有多播路由器应静态指向Anycast RP地址。静态RP分配是组到RP映射最常用的方法,因为它具有确定性。自动RP[RFC4601]和/或引导路由器(BSR)[BSR]动态RP映射机制也可用于在提供商的网络内传播RP信息

For an SA message to be accepted in this (multi-hop peering) environment, we rely upon the next (or closest, with latest MSDP spec) AS in the best path towards the originating RP for the RPF check. The MSDP peer address should be in the same AS as the AS of the border router's MBGP peer. The MSDP peer address should be advertised via MBGP.

为了在此(多跳对等)环境中接受SA消息,我们依赖于下一个(或最近的,具有最新MSDP规范)作为RPF检查的最佳路径,以到达原始RP。MSDP对等地址应与边界路由器的MBGP对等地址相同。MSDP对等地址应通过MBGP公布。

For example, in the diagram below, if customer R1 router is MBGP peering with the R2 router and if R1 is MSDP peering with the R3 router, then R2 and R3 must be in the same AS (or must appear, to AS1, to be from the same AS in the event that private AS numbers are deployed). The MSDP peer with the highest IP address will be chosen as the MSDP RPF peer. R1 must also have the MSDP peer address of R3 in its MBGP table.

例如,在下图中,如果客户R1路由器是与R2路由器进行MBGP对等的,并且如果R1是与R3路由器进行MSDP对等的,则R2和R3必须与相同(或者对于AS1,必须显示为与部署专用AS号码时相同)。将选择具有最高IP地址的MSDP对等方作为MSDP RPF对等方。R1的MBGP表中还必须有R3的MSDP对等地址。

         +--+    +--+    +--+
         |R1|----|R2|----|R3|
         +--+    +--+    +--+
         AS1     AS2     AS2
        
         +--+    +--+    +--+
         |R1|----|R2|----|R3|
         +--+    +--+    +--+
         AS1     AS2     AS2
        

From R3's perspective, AS1 (R1) is the MBGP next AS in the best path towards the originating RP. As long as AS1 is the next AS (or closest) in the best path towards the originating RP, RPF will succeed on SAs arriving from R1.

从R3的角度来看,AS1(R1)是通向起始RP的最佳路径中的下一个AS的MBGP。只要AS1是通向起始RP的最佳路径中的下一个AS(或最近的),RPF将在从R1到达的SAs上成功。

In contrast, with the single hop scenario, with R2 (instead of R3) border MSDP peering with R1 border, R2's MBGP address becomes the announcer of the next hop for R3, towards the originating RP, and R3 must peer with that R2 address. Moreover, all AS2 intra-domain MSDP peers need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP has a dependence upon peering with the address of the MBGP (or other IGP) announcer of the next hop.

与此相反,在单跳场景中,R2(而不是R3)边界MSDP与R1边界进行对等,R2的MBGP地址成为R3下一跳的宣告者,朝向原始RP,并且R3必须与该R2地址进行对等。此外,所有AS2域内MSDP对等方都需要跟随iMBGP(或其他IGP)向R2的对等,因为iMSDP依赖于与下一跳的MBGP(或其他IGP)宣告器的地址进行对等。

2.3. MSDP Peering without BGP
2.3. 无BGP的MSDP对等

In this case, an enterprise maintains its own RP and has an MSDP peering with its service provider but does not BGP peer with them. MSDP relies upon BGP path information to learn the MSDP topology for the SA peer-RPF check. MSDP can be deployed without BGP, however, and as a result, there are some special cases where the requirement to perform a peer-RPF check on the BGP path information is suspended. These cases are:

在这种情况下,企业维护自己的RP,并与其服务提供商进行MSDP对等,但不与他们进行BGP对等。MSDP依赖于BGP路径信息来了解MSDP拓扑以进行SA对等RPF检查。但是,MSDP可以在没有BGP的情况下部署,因此,在某些特殊情况下,对BGP路径信息执行对等RPF检查的要求被挂起。这些个案包括:

o There is only a single MSDP peer connection.

o 只有一个MSDP对等连接。

o A default peer (default MSDP route) is configured.

o 已配置默认对等(默认MSDP路由)。

o The originating RP is directly connected.

o 原始RP直接连接。

o A mesh group is used.

o 使用网格组。

o An implementation is used that allows for an MSDP peer-RPF check using an IGP.

o 使用的实现允许使用IGP进行MSDP对等RPF检查。

An enterprise will typically configure a unicast default route from its border router to the provider's border router and then MSDP peer with the provider's MSDP router. If internal MSDP peerings are also used within the enterprise, then an MSDP default peer will need to be configured on the border router that points to the provider. In this way, all external multicast sources will be learned, and internal sources can be advertised. If only a single MSDP peering was used (no internal MSDP peerings) towards the provider, then this stub site will MSDP default peer towards the provider and skip the peer-RPF check.

企业通常会配置从其边界路由器到提供商边界路由器的单播默认路由,然后与提供商的MSDP路由器进行MSDP对等。如果企业中也使用内部MSDP对等,则需要在指向提供商的边界路由器上配置MSDP默认对等。通过这种方式,所有外部多播源都将被学习,而内部源可以被公布。如果仅对提供程序使用了单个MSDP对等(没有内部MSDP对等),则此存根站点将默认对提供程序进行MSDP对等,并跳过对等RPF检查。

2.4. MSDP Peering at a Multicast Exchange
2.4. 多播交换上的MSDP对等

Multicast exchanges allow multicast providers to peer at a common IP subnet (or by using point-to-point virtual LANs) and share MSDP SA updates. Each provider will MSDP and MBGP peer with each others directly connected exchange IP address. Each exchange router will send/receive SAs to/from their MSDP peers. They will then be able to forward SAs throughout their domain to their customers and any direct provider peerings.

多播交换允许多播提供商在公共IP子网(或通过使用点对点虚拟LAN)上进行对等,并共享MSDP SA更新。每个提供商将MSDP和MBGP相互对等,直接连接exchange IP地址。每个exchange路由器将向其MSDP对等方发送/接收SAs。然后,他们将能够将整个域中的SA转发给他们的客户和任何直接的提供商对等。

3. Intra-domain MSDP Peering Scenarios
3. 域内MSDP对等场景

The following sections describe the different intra-domain MSDP peering possibilities and their deployment options.

以下各节介绍不同的域内MSDP对等可能性及其部署选项。

3.1. Peering between MSDP- and MBGP-Configured Routers
3.1. MSDP和MBGP配置路由器之间的对等

The next hop IP address of the iBGP peer is typically used for the MSDP peer-RPF check (IGP can also be used). This is different from the inter-domain BGP/MSDP case, where AS path information is used for the peer-RPF check. For this reason, it is necessary for the IP address of the MSDP peer connection to be the same as the internal MBGP peer connection whether or not the MSDP/MBGP peers are directly connected. A successful deployment would be similar to the following:

iBGP对等方的下一跳IP地址通常用于MSDP对等方RPF检查(也可以使用IGP)。这不同于域间BGP/MSDP情况,其中AS路径信息用于对等RPF检查。因此,无论MSDP/MBGP对等点是否直接连接,MSDP对等点连接的IP地址都必须与内部MBGP对等点连接相同。成功的部署类似于以下内容:

                                 +----+
                                 | Rb | 3.3.3.3
                               / +----+
          AS1          AS2    /     |
         +---+         +--+  /      |
         |RP1|---------|Ra|         |
         +---+         +--+         |
         1.1.1.1     2.2.2.2        |
                             \      |
                              \     |
                               \ +-----+
                                 | RP2 |
                                 +-----+
        
                                 +----+
                                 | Rb | 3.3.3.3
                               / +----+
          AS1          AS2    /     |
         +---+         +--+  /      |
         |RP1|---------|Ra|         |
         +---+         +--+         |
         1.1.1.1     2.2.2.2        |
                             \      |
                              \     |
                               \ +-----+
                                 | RP2 |
                                 +-----+
        

where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update from MSDP peer 2.2.2.2, which is also the correct MBGP next hop for 1.1.1.1.

其中RP2 MSDP和MBGP与Ra(使用2.2.2.2)和Rb(使用3.3.3.3)对等。当MSDP SA更新从Ra到达RP2时,1.1.1.1的MSDP RPF检查通过,因为RP2从MSDP对等方2.2.2.2接收SA更新,这也是1.1.1.1的正确MBGP下一跳。

When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP lookup for 1.1.1.1 shows a next hop of 2.2.2.2, so RPF correctly fails, preventing a loop.

当RP2从MSDP peer 3.3.3.3接收到相同的SA更新时,1.1.1.1的MBGP查找将显示下一个跃点2.2.2,因此RPF将正确失败,从而阻止循环。

This deployment could also fail on an update from Ra to RP2 if RP2 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain deployments must have MSDP and MBGP (or other IGP) peering addresses that match, unless a method to skip the peer-RPF check is deployed.

如果RP2是MBGP对等于Ra上2.2.2.2以外的地址,则此部署在从Ra更新到RP2时也可能失败。域内部署必须具有匹配的MSDP和MBGP(或其他IGP)对等地址,除非部署了跳过对等RPF检查的方法。

3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer)
3.2. MSDP对等方不是BGP对等方(或没有BGP对等方)

This is a common MSDP intra-domain deployment in environments where few routers are running MBGP or where the domain is not running MBGP. The problem here is that the MSDP peer address needs to be the same as the MBGP peer address. To get around this requirement, the intra-domain MSDP RPF rules have been relaxed in the following topologies:

在很少有路由器运行MBGP或域未运行MBGP的环境中,这是一种常见的MSDP域内部署。这里的问题是MSDP对等地址需要与MBGP对等地址相同。为了规避这一要求,在以下拓扑中放宽了域内MSDP RPF规则:

o By configuring the MSDP peer as a mesh group peer.

o 通过将MSDP对等机配置为网状组对等机。

o By having the MSDP peer be the only MSDP peer.

o 通过让MSDP对等方成为唯一的MSDP对等方。

o By configuring a default MSDP peer.

o 通过配置默认MSDP对等点。

o By peering with the originating RP.

o 通过使用原始RP进行窥视。

o By relying upon an IGP for MSDP peer-RPF.

o 依靠一个用于MSDP对等RPF的IGP。

The common choice around the intra-domain BGP peering requirement, when more than one MSDP peer is configured, is to deploy MSDP mesh groups. When an MSDP mesh group is deployed, there is no RPF check on arriving SA messages when they are received from a mesh group peer. Subsequently, SA messages are always accepted from mesh group peers. MSDP mesh groups were developed to reduce the amount of SA traffic in the network since SAs, which arrive from a mesh group peer, are not flooded to peers within that same mesh group. Mesh groups must be fully meshed.

配置多个MSDP对等时,围绕域内BGP对等需求的常见选择是部署MSDP网状组。当部署了mesh组时,如果没有收到来自mesh组的MSDF消息,则在该组上进行RPP检查。随后,SA消息总是从mesh组对等方接受。开发MSDP mesh组是为了减少网络中的SA流量,因为从mesh组对等方到达的SA不会被淹没到同一mesh组中的对等方。网格组必须完全网格化。

If recent (but not currently widely deployed) router code is running that is fully compliant with the latest MSDP document, another option, to work around not having BGP to MSDP RPF peer, is to RPF using an IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for enterprise customers, who are not running BGP and who don't want to run mesh groups, to use their existing IGP to satisfy the MSDP peer-RPF rules.

如果最近(但目前尚未广泛部署)运行的路由器代码完全符合最新的MSDP文档,另一种解决方案是使用IGP(如OSPF、is-is、RIP等)来实现BGP到MSDP RPF对等,即RPF。这种新功能将允许企业客户,未运行BGP和不想运行mesh组的用户可以使用其现有IGP来满足MSDP对等RPF规则。

3.3. Hierarchical Mesh Groups
3.3. 分层网格组

Hierarchical mesh groups are occasionally deployed in intra-domain environments where there are a large number of MSDP peers. Allowing multiple mesh groups to forward to one another can reduce the number of MSDP peerings per router (due to the full mesh requirement) and hence reduce router load. A good hierarchical mesh group implementation (one that prevents looping) contains a core mesh group in the backbone, and these core routers serve as mesh group aggregation routers:

分层网格组偶尔部署在域内环境中,其中存在大量MSDP对等点。允许多个mesh组相互转发可以减少每个路由器的MSDP对等数量(由于全mesh需求),从而减少路由器负载。一个好的分层网状组实现(防止循环的实现)在主干中包含一个核心网状组,这些核心路由器充当网状组聚合路由器:

                      [R2]{A,2}
                      /  \
                     /    \
                    /      \
                   /        \
                  /          \
                 /            \
                /              \
         {A,1}[R1]-------------[R3]{A,3}
        
                      [R2]{A,2}
                      /  \
                     /    \
                    /      \
                   /        \
                  /          \
                 /            \
                /              \
         {A,1}[R1]-------------[R3]{A,3}
        

In this example, R1, R2, and R3 are in MSDP mesh group A (the core mesh group), and each serves as MSDP aggregation routers for their leaf (or second tier) mesh groups 1, 2, and 3. Since SA messages received from a mesh group peer are not forwarded to peers within that same mesh group, SA messages will not loop. Do not create topologies that connect mesh groups in a loop. In the above example, for instance, second-tier mesh groups 1, 2, and 3 must not directly exchange SA messages with each other or an endless SA loop will occur.

在本例中,R1、R2和R3位于MSDP网格组A(核心网格组)中,每个都用作其叶(或第二层)网格组1、2和3的MSDP聚合路由器。由于从mesh组对等方接收的SA消息不会转发到同一mesh组内的对等方,因此SA消息不会循环。不要创建在回路中连接网格组的拓扑。例如,在上面的示例中,第二层网格组1、2和3不得相互直接交换SA消息,否则将出现无休止的SA循环。

Redundancy between mesh groups will also cause a loop and is subsequently not available with hierarchical mesh groups. For instance, assume that R3 had two routers connecting its leaf mesh group 3 with the core mesh group A. A loop would be created between mesh group 3 and mesh group A because each mesh group must be fully meshed between peers.

网格组之间的冗余也会导致循环,并且随后在分层网格组中不可用。例如,假设R3有两个路由器将其叶网格组3与核心网格组A连接。将在网格组3和网格组A之间创建一个循环,因为每个网格组必须在对等方之间完全网格化。

3.4. MSDP and Route Reflectors
3.4. MSDP和路线反射器

BGP requires all iBGP speakers that are not route-reflector clients or confederation members be fully meshed to prevent loops. In the route reflector environment, MSDP requires that the route reflector clients peer with the route reflector since the router reflector (RR) is the BGP announcer of the next hop towards the originating RP. The RR is not the BGP next hop, but is the announcer of the BGP next hop. The announcer of the next hop is the address typically used for MSDP peer-RPF checks. For example, consider the following case:

BGP要求所有不是路由反射器客户端或联盟成员的iBGP扬声器完全啮合,以防止环路。在路由反射器环境中,MSDP要求路由反射器客户端与路由反射器对等,因为路由器反射器(RR)是朝向发起RP的下一跳的BGP播音器。RR不是BGP下一跳,而是BGP下一跳的播音器。下一跳的宣告者是通常用于MSDP对等RPF检查的地址。例如,考虑以下情况:

               Ra--------RR
                         /|\
                        / | \
                       A  B  C
        
               Ra--------RR
                         /|\
                        / | \
                       A  B  C
        

Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, these RR clients will accept the SA because RR is the announcer of the next hop to the originating RP address.

Ra正在将MSDP SA转发到路由反射器RR。路由器A、B和C也与RR进行MSDP对等。当RR将SA转发给A、B和C时,这些RR客户端将接受SA,因为RR是到原始RP地址的下一跳的播音器。

An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B, or C because the announcer of the next hop is RR but the SA update came from Ra. Proper deployment is to have RR clients MSDP peer with the RR. MSDP mesh groups may be used to work around this requirement. External MSDP peerings will also prevent this requirement since the next AS is compared between MBGP and MSDP peerings, rather than the IP address of the announcer of the next hop.

如果Ra MSDP直接与路由器A、B或C进行对等,SA将对等RPF失败,因为下一跳的播音员是RR,但SA更新来自Ra。正确的部署是让RR客户端MSDP与RR对等。MSDP网格组可用于解决此要求。外部MSDP对等也将阻止此要求,因为MBGP和MSDP对等之间比较的是下一个AS,而不是下一跳播音员的IP地址。

Some recent MSDP implementations conform to the latest MSDP document, which relaxes the requirement of peering with the Advertiser of the next hop (the Route Reflector). This new rule allows for peering with the next hop, in addition to the Advertiser of the next hop. In the example above, for instance, if Ra is the next hop (perhaps due to using BGP's next hop self attribute), and if routers A, B, and C are peering with Ra, the SA's received from Ra will now succeed.

最近的一些MSDP实现符合最新的MSDP文档,该文档放宽了与下一跳广告商(路由反射器)进行对等的要求。除了下一跳的广告客户之外,这个新规则还允许在下一跳进行窥视。例如,在上面的示例中,如果Ra是下一个跃点(可能是由于使用BGP的下一个跃点自身属性),并且如果路由器A、B和C正在使用Ra进行对等,则从Ra接收到的SA现在将成功。

3.5. MSDP and Anycast RPs
3.5. MSDP和选播RPs

A network with multiple RPs can achieve RP load sharing and redundancy by using the Anycast RP mechanism in conjunction with MSDP mesh groups [RFC3446]. This mechanism is a common deployment technique used within a domain by service providers and enterprises that deploy several RPs within their domains. These RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address). These RPs will MSDP peer with each other using a separate loopback interface and are part of the same fully meshed MSDP mesh group. This loopback interface, used for MSDP peering, will typically also be used for the MBGP peering. All routers within the provider's domain will learn of the Anycast RP address through Auto-RP, BSR, or a static RP assignment. Each designated router in the domain will send source registers and group joins to the Anycast RP address. Unicast routing will direct those registers and joins to the nearest Anycast RP. If a particular Anycast RP router fails, unicast routing will direct subsequent registers and joins to the nearest Anycast RP. That RP will then forward an MSDP update to all peers within the Anycast MSDP mesh group. Each RP will then forward (or receive) the SAs to (from) external customers and providers.

通过将选播RP机制与MSDP网格组结合使用,具有多个RP的网络可以实现RP负载共享和冗余[RFC3446]。此机制是服务提供商和在其域中部署多个RP的企业在域中使用的常用部署技术。这些RP将在环回接口上配置相同的IP地址(使其成为选播地址)。这些RPs将使用单独的环回接口彼此进行MSDP对等,并且是同一个完全网格化的MSDP网格组的一部分。此环回接口用于MSDP对等,通常也用于MBGP对等。提供商域内的所有路由器将通过自动RP、BSR或静态RP分配了解选播RP地址。域中的每个指定路由器将源寄存器和组联接发送到选播RP地址。单播路由将这些寄存器和联接定向到最近的选播RP。如果特定的选播RP路由器失败,单播路由将随后的寄存器和联接定向到最近的选播RP。然后,该RP将向选播MSDP网格组内的所有对等方转发MSDP更新。然后,每个RP将SAs转发(或接收)给(来自)外部客户和提供商。

4. Security Considerations
4. 安全考虑

An MSDP service should be secured by explicitly controlling the state that is created by, and passed within, the MSDP service. As with unicast routing state, MSDP state should be controlled locally, at the edge origination points. Selective filtering at the multicast service edge helps ensure that only intended sources result in SA message creation, and this control helps to reduce the likelihood of state-aggregation related problems in the core. There are a variety of points where local policy should be applied to the MSDP service.

应该通过显式控制由MSDP服务创建并在其中传递的状态来保护MSDP服务。与单播路由状态一样,MSDP状态应在边缘起始点进行本地控制。多播服务边缘的选择性过滤有助于确保只有预期的源会导致SA消息的创建,并且此控制有助于降低核心中状态聚合相关问题的可能性。有许多地方应该将本地策略应用于MSDP服务。

4.1. Filtering SA Messages
4.1. 筛选SA消息

The process of originating SA messages should be filtered to ensure that only intended local sources are resulting in SA message origination. In addition, MSDP speakers should filter which SA messages get received and forwarded.

应过滤发起SA消息的过程,以确保只有预期的本地源会导致SA消息的发起。此外,MSDP发言人应过滤接收和转发的SA消息。

Typically, there is a fair amount of (S,G) state in a PIM-SM domain that is local to the domain. However, without proper filtering, SA messages containing these local (S,G) announcements may be advertised to the global MSDP infrastructure. Examples of this include domain-local applications that use global IP multicast addresses and sources that use RFC 1918 addresses [RFC1918]. To improve on the scalability of MSDP and to avoid global visibility of domain local (S,G) information, an external SA filter list is recommended to help prevent unnecessary creation, forwarding, and caching of well-known domain local sources.

通常,PIM-SM域中存在相当数量的(S,G)状态,这些状态是该域的本地状态。但是,如果没有适当的过滤,包含这些本地(S、G)公告的SA消息可能会发布到全球MSDP基础设施。使用本地多播地址的域1918和使用本地多播地址的域1918的示例。为了提高MSDP的可扩展性并避免域本地(S,G)信息的全局可见性,建议使用外部SA筛选器列表来帮助防止不必要地创建、转发和缓存已知域本地源。

4.2. SA Message State Limits
4.2. SA消息状态限制

Proper filtering on SA message origination, receipt, and forwarding will significantly reduce the likelihood of unintended and unexpected spikes in MSDP state. However, an SA-cache state limit SHOULD be configured as a final safeguard to state spikes. When an MSDP peering has reached a stable state (i.e., when the peering has been established and the initial SA state has been transferred), it may also be desirable to configure a rate limiter for the creation of new SA state entries.

对SA消息的发起、接收和转发进行适当过滤将显著降低MSDP状态中出现意外峰值的可能性。但是,应将SA缓存状态限制配置为状态峰值的最终保护措施。当MSDP对等已达到稳定状态时(即,当对等已建立且初始SA状态已转移时),也可能需要配置速率限制器以创建新SA状态条目。

5. Acknowledgements
5. 致谢

The authors would like to thank Pekka Savola, John Zwiebel, Swapna Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier versions of this document.

作者要感谢Pekka Savola、John Zwiebel、Swapna Yelamanchi、Greg Shepherd和Jay Ford对本文件早期版本的反馈。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4601]Fenner,B.,Handley,M.,Holbrook,H.,和I.Kouvelas,“协议独立多播-稀疏模式(PIM-SM):协议规范(修订版)”,RFC 46012006年8月。

[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271]Rekhter,Y.,Li,T.,和S.Hares,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918]Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,de Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[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月。

[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[RFC2858]Bates,T.,Rekhter,Y.,Chandra,R.,和D.Katz,“BGP-4的多协议扩展”,RFC 2858,2000年6月。

[RFC3446] 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.

[RFC3446]Kim,D.,Meyer,D.,Kilmer,H.,和D.Farinaci,“使用协议独立多播(PIM)和多播源发现协议(MSDP)的任意广播呈现点(RP)机制”,RFC 3446,2003年1月。

[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[RFC3618]Fenner,B.和D.Meyer,“多播源发现协议(MSDP)”,RFC3618,2003年10月。

6.2. Informative References
6.2. 资料性引用

[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, February 2003.

[BSR]Fenner,W.等人,“PIM稀疏模式的引导路由器(BSR)机制”,正在进行的工作,2003年2月。

   [RFCED]   http://www.rfc-editor.org/policy.html
        
   [RFCED]   http://www.rfc-editor.org/policy.html
        

Authors' Addresses

作者地址

Mike McBride Cisco Systems

麦克布莱德思科系统公司

   EMail: mcbride@cisco.com
        
   EMail: mcbride@cisco.com
        

John Meylor Cisco Systems

约翰·梅勒思科系统公司

   EMail: jmeylor@cisco.com
        
   EMail: jmeylor@cisco.com
        

David Meyer

大卫·梅耶尔

   EMail: dmm@1-4-5.net
        
   EMail: dmm@1-4-5.net
        

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)提供。