关键词：组播，VPN，MD，MTI，RPF

摘    要：组播VPN是一项在现有BGP/MPLS IP VPN基础上支持组播业务的技术，该技术通过对私网组播报文进行封装，并将其由各Site间建立的组播隧道进行传递，以完成组播数据在私网之间的传送。本文介绍了组播VPN的基本概念、实现方案和典型组网应用。

缩略语：

目  录

1 概述... 4

1.1 产生背景... 4

1.2 技术优点... 5

2 MD VPN技术实现... 6

2.1 MD VPN概述... 6

2.2 Share-MDT. 7

2.2.1 Share-MDT的建立... 7

2.2.2 PIM邻居关系... 8

2.2.3 PE上的接口类型... 9

2.2.4 MVRF的RPF检查... 10

2.2.5 Share-MDT的数据转发... 11

2.3 Switch-MDT. 13

2.3.1 Switch-MDT切换消息... 13

2.3.2 Switch-Delay和Switch-Holddown. 14

2.3.3 Switch-MDT切换过程... 14

2.4 跨AS的MD VPN. 15

2.4.1 跨AS的MD VPN的难题... 15

2.4.2 跨AS的MD VPN解决方案... 16

3 典型组网应用... 17

3.1 单AS内MD VPN. 17

3.2 跨AS的MD VPN. 18

4 参考文献... 19

1  概述

1.1  产生背景

IP组播的应用越来越广泛，很多行业开始将其作为应用的解决方案。同时VPN技术在企业网中的应用也越来越普及，在目前的电子政务网、电力数据等企业网络中，几乎都是基于BGP/MPLS IP VPN的架构，通过将不同部分划分到不同的VPN中以实现部门间的数据隔离。同样地，对部门内部的视频会议、数据共享等组播业务也需要实现VPN隔离，因此就有了组播VPN日益紧迫的需求。但在RFC 4364中只提出了针对单播VPN业务的解决方案，并没有对组播VPN业务的开展给出具体规划或建议。因此如何在VPN环境中应用组播技术，成为需要解决的重要问题之一。

ISP希望能够利用BGP/MPLS IP VPN本身的构架为用户提供组播VPN业务，该方案应具备可扩展性，并充分利用骨干网自身的组播能力；VPN用户希望每个Site的CE只与相应的PE建立PIM邻居关系，而与远端Site的CE无关，用户网络不需要为使用组播VPN而更改其配置，用户现有的组播应用方案（如PIM模式、RP位置、RP发现机制等）不受影响。除此以外，在BGP/MPLS IP VPN网络内开展组播业务还需解决以下几方面的问题：

(1)        私网地址空间重叠。由于BGP/MPLS IP VPN网络允许各VPN的私网地址空间重叠，因此不同VPN用户所使用的组播源和组播组地址可能是重叠的，PE需要能够将私网组播数据正确地转发给同一VPN内的用户。

(2)        公网支持组播功能。私网组播数据除了在私网内进行组播转发外，如果在公网中也能进行组播转发，将使公网的数据负载大大减少，从而节约带宽。

(3)        在公网对私网组播数据进行RPF检查。组播数据的转发模式与单播不同，要根据组播源地址和入接口对组播数据进行RPF检查，只有通过检查才能被转发。而在BGP/MPLS IP VPN网络中，由于公网中的P设备无法获得私网路由，因此不能直接对私网组播数据进行转发。

(4)        私网组播数据实现按需发送。一个VPN由多个Site构成，每个Site连接到不同的PE，但并非每个Site都需要组播数据，因此如果私网组播数据通过公网时只流向那些有需求的PE，将会减少PE的负荷。

(5)        对现有网络改造小。目前，BGP/MPLS IP VPN网络已被广泛应用，要在现有网络基础上开展组播业务，应对现有网络进行最小的改造，尽量使用现有设备的功能实现对组播VPN的支持，以降低网络建设成本。

为了解决在BGP/MPLS IP VPN网络中运营组播业务所面临的这些挑战，IETF制订了相关草案——draft-rosen-vpn-mcast，在该草案的历史版本中曾提出过组播VPN的三种解决方案：MD方案、VPN-IP PIM方案和基于PIM NBMA技术的MD方案，这三种方案优缺点的比较如表1所示。

表1 各方案优缺点比较

1.2  技术优点

在以上三种解决方案的较量中，MD方案最终脱颖而出，成为当前的主流解决方案——其缺点可以通过为高速流按需创建独立的隧道来修正。在最新的草案draft-rosen-vpn-mcast-08中，已将其它两个方案删除。MD方案之所以成为唯一被保留下来的解决方案，主要原因如下：

(1)        MD方案最大的优点是对现有网络升级简单，仅需升级PE即可，无需对CE和P进行升级或修改其配置，也就是说MD方案对CE和P是透明的。骨干网不必知道特定VPN内有多少个组播组的业务，于是骨干网的稳定性得到了保证。

(2)        MD方案利用公网自身的组播转发能力，解决了RPF检查问题。通过在PE将私网组播数据包封装成公网组播数据包，然后利用公网固有的组播转发能力实现私网组播数据在公网的组播转发。

(3)        MD方案为ISP提供了控制手段，方便骨干网络的规划和控制。ISP对自己的骨干网具有独立的控制权，而不需要关注VPN内部的业务信息。

(4)        MD方案支持所有的PIM模式，而且骨干网与VPN中的PIM模式相互独立，使ISP与VPN用户可以选择和保留各自的PIM模式。

MD方案基于现有的MPLS VPN架构，升级简单、兼容性好，是VPN支持组播的必然趋势。

2  MD VPN技术实现

2.1  MD VPN概述

顾名思义MD是一个集合，它由一些相互间可以收发组播数据的VRF组成——我们将每个VPN实例独立维护的单播路由转发表称为VRF，相应地称支持组播业务的VRF为MVRF，它同时维护单播和组播路由转发表。不同的MVRF加入到同一个MD中，通过MD内自动建立的MT将这些MVRF连接在一起，实现了不同Site之间的组播业务互通，从而形成了一个组播VPN网络。

在同一MD中建立的PE间的隧道称为MT，它用于在多个MVRF之间传输组播协议和数据报文。对于MVRF来说，MT就像是一个多路访问的LAN网络，同一MD内的各MVRF通过MTI接入这个网络中。

如同一个VRF只能属于一个VPN，一个MVRF也只能属于一个MD。每个MD会被分配一个独立的组播地址，称为Share-Group。Share-Group是一个MD的标志，在骨干网中是唯一的，不同MD的Share-Group必须不同。当两个MVRF之间通信时，C-Packet以GRE方式被封装在P-Packet里通过MT进行传输，P-Packet的源地址为PE用来建立BGP连接所使用的接口IP地址，目的地址为Share-Group。

MD方案的基本思想是：在骨干网中为每个VPN维护一棵称为Share-MDT的组播转发树。来自VPN中任一Site的组播报文（包括协议和数据报文）都会沿着Share-MDT被转发给属于该MD的所有PE：PE收到组播报文后，如果其MVRF内有该组播组的接收者，则继续向CE转发；否则将其丢弃。

图1 MD VPN解决方案示意图

如图1所示，三个MVRF属于同一MD，各MVRF之间已通过配置和协议交互建立起了MT。C-Packet在源PE（如PE 1）处被封装在P-Packet中，并通过MT到达另一Site的PE：如果某PE（如PE 2）的MVRF内有接收者，则该PE将剥掉P-Packet的报文头还原成C-Packet转发给其CE；如果某PE（如PE 3）的MVRF内没有接收者，P-Packet将被该PE直接丢弃。

由上可以看出，MD方案存在一个重要的缺点：在骨干网中，组播数据将沿Share-MDT转发给MD内的所有MVRF，即使某些MVRF并未连接有该组播组的接收者。这将导致大量带宽被无谓地消耗，而且当PE连接有多个MVRF时，这些无用的组播数据流也会给PE增加不小的负担。为此，MD方案提出一个权衡组播路由优化与可扩展性的折中方案：对于流量较小的组播业务，仍使用Share-MDT；而对于流量较大的组播业务，则为其单独分配一棵称为Switch-MDT的组播分发树，将组播数据以Switch-Group为目的地址沿Switch-MDT转发给那些真正有接收需求的PE。

2.2  Share-MDT

2.2.1  Share-MDT的建立

Share-MDT是MD方案最基本的思想，它是一棵建立在同一VPN内所有PE之间的组播分发树，各MVRF间交互的所有组播协议和数据报文都通过由这棵分发树所形成的MT进行转发。Share-MDT将一直存在于骨干网中，而不论骨干网或者VPN中是否有实际的组播业务。

图2 Share-MDT的建立过程

如图2所示，以骨干网中运行PIM-SM为例，Share-MDT创建的具体过程如下：

l              当在PE 1的MVRF上配置Share-Group之后，PE 1就会向骨干网RP发起（*，Share-Group）加入，并在骨干网沿途各设备上创建（*，Share-Group）表项。PE 2和PE 3的加入过程与此类似。

l              当在PE 1的MVRF上配置PIM之后，PIM协议会周期性地组播PIM Hello消息，PE 1将其封装成P-Data-Packet并向骨干网RP发起注册，以IBGP接口地址S为组播源地址、Share-Group为组播组地址，在骨干网沿途各设备上创建（S，Share-Group）表项。PE 2和PE 3的注册过程与此类似。

最终，在MD中形成一棵以RP为根，PE 1、PE 2和PE 3为叶的RPT，以及连接各PE与RP的三棵相互独立的SPT，并由这些RPT和SPT共同构成Share-MDT。

2.2.2  PIM邻居关系

如图3所示，在MD方案中存在以下三种PIM邻居关系：

l              PE-P邻居关系：PE通过骨干网中的PIM与P建立的PIM邻居关系。

l              PE-CE邻居关系：PE通过其MVRF中的PIM与CE建立的PIM邻居关系。

l              PE-PE邻居关系：本地PE与远端PE通过各自MVRF中的PIM建立的PIM邻居关系。

图3 PIM邻居关系示意图

在MD方案中，骨干网中的PIM用于在PE之间建立MT以及为骨干网提供非VPN的组播服务；而MVRF中的PIM则用于在PE与CE之间建立PIM邻居关系以及在各PE之间通过MT建立PIM邻居关系，前者用以创建MVRF自有的组播路由转发表和发现本VPN内的RP信息，后者用以发现RPF邻居和检测对端PE的PIM能力。

2.2.3  PE上的接口类型

当在VRF上使能了组播路由功能后，MVRF就创建完毕了。PIM、IGMP、MSDP等组播协议都可以在MVRF内启动和工作，每个MVRF只包含本VPN内的组播路由转发信息。MT的创建会使全局路由转发表（以下简称全局MVRF）创建（*，G）或者（S，G）组播路由表项。MVRF中的（*，G）和（S，G）表项会将MTI包含在入接口或出接口列表中。对于一个PE来说，我们可以为其定义以下三类接口：

l              PNI：是指PE上连接P设备的接口。从PNI收发的报文使用全局MVRF进行路由，全局MVRF中保存的是骨干网的路由转发信息。

l              CNI：是指PE上连接CE设备的接口。从CNI收发的报文使用该接口所属的MVRF进行路由，MVRF中保存的是该Site的私网路由转发信息。

l              MTI：是PE上的虚拟接口，当配置完Share-MDT和PIM、IBGP连接也建立起来之后，MTI就已自动创建并up起来了。MTI就是MT的入/出口，也相当于MD的入/出口。在MVRF看来，MT就像一个LAN网络，所有MVRF都通过MTI接入到这个网络中。由于MTI只收发组播报文而不处理单播报文，这就要求进行RPF检查时采用其它方法。

2.2.4  MVRF的RPF检查

RPF检查是PIM协议重要的组成部分，PIM使用单播路由表来确定RPF信息，包括用于报文RPF检查的RPF接口信息和用于PIM加入/剪枝消息的RPF邻居信息。MVRF的RPF检查有以下两种应用场景：

1. 使用全局MVRF进行RPF检查

当PE使用全局MVRF进行RPF检查时，其情形与不存在组播VPN时完全一样。如图4所示，此时Share-MDT尚未建立起来，PE 2对来自P的组播报文进行RPF检查时，RPF接口为PE 2的PNI接口Serial2/1，RPF邻居为P。

图4 使用全局MVRF进行RPF检查

2. 使用MVRF进行RPF检查

当PE使用MVRF进行RPF检查时，又可分为以下两种情况：

(1)        RPF接口属于同一MVRF。这种情形也与不存在组播VPN时完全一样。如图5所示，PE 1对来自CE 1的组播报文进行RPF检查时，RPF接口为PE 1的CNI接口Ethernet1/1，RPF邻居为CE 1。

图5 RPF接口属于同一MVRF

(2)        RPF接口属于全局MVRF。这种情况下组播报文来自远端MVRF，由于每个MVRF中只有一个MTI，它就是指向组播源的RPF接口。若某远端PE既是本地PE到达组播源的BGP路由的下一跳，又是本地PE的PIM邻居，则该远端PE就是本地PE的RPF邻居。如图6所示，此时Share-MDT已建立完毕，PE 1通过MT发送组播报文给PE 2，当PE 2对该报文进行RPF检查时，RPF接口为PE 2的MTI接口MTunnel0，RPF邻居为PE 1。

图6 RPF接口属于全局MVRF

2.2.5  Share-MDT的数据转发

当Share-MDT建立完毕之后，就可以在VPN中进行对组播数据的传递了。我们分以下两种情况来介绍组播数据通过Share-MDT转发的过程：

1. 组播源与接收者处于同一MVRF

当组播源与接收者处于同一MVRF时，只需在MVRF内部进行协议交互与数据转发，其情形与不存在组播VPN时一样。

图7 组播源与接收者处于同一MVRF

如图7所示，CE 1连接组播源S，CE 2连接组播组G的接收者。PE 1收到来自CE 2的PIM加入消息后，将接口Ethernet1/2加入到（*，G）表项的出接口列表中，而将接口Ethernet1/1作为该表项的入接口。组播数据从CE 1发送到PE 1，再由PE 1转发给CE 2。

2. 组播源与接收者处于不同MVRF

当组播源与接收者处于同一VPN的不同MVRF时，需要跨MVRF进行协议交互与数据转发。

图8 组播源与接收者处于不同MVRF

如图8所示，VPN内部使用PIM-SM，CE 1为该VPN内的RP，CE 1连接组播源S，CE 2连接组播组G的接收者。CE 2向RP（CE 1）发送PIM加入消息，PE 2将其封装成P-Packet并沿Share-MDT发送给MD内的所有PE：PE 3解封装后发现本MVRF内没有RP，便将其丢弃；PE 1解封装后发现本MVRF内有RP，于是将还原后的PIM加入消息向CE 1转发，同时将MTunnel0加入到（*，G）表项的出接口列表中。CE 1收到PIM加入消息后，将组播数据（S，G）转发给PE 1，PE 1将其封装成P-Packet并沿Share-MDT发送给MD内的所有PE：PE 3解封装后发现本MVRF内没有G的接收者，便将其丢弃；PE 2解封装后发现本MVRF内有G的接收者，于是将还原后的组播数据向CE 2转发。

2.3  Switch-MDT

Share-MDT最大的优点是骨干网上的组播状态稳定，而最大的缺点则是带宽利用率低：当组播流量较大时，无用的组播流会消耗Share-MDT上那些并无接收者的分支上的宝贵带宽。

针对这个问题，MD方案提出了Switch-MDT解决方案：在组播源所在PE上设置一定阈值，当该PE检测到组播数据的转发速率达到阈值时将新建一棵Switch-MDT，只有对这个组播数据感兴趣的PE才会加入这棵新树。切换完成后，组播数据将不再以Share-Group、而改以Switch-Group为目的地址沿Switch-MDT被转发给那些真正有接收需求的PE。

2.3.1  Switch-MDT切换消息

Switch-MDT切换消息是一种UDP报文，它携带有组播源地址、组播组地址和Switch-Group地址。当发起Switch-MDT切换时，它将被封装在P-Packet中，由源PE以Switch-Interval为间隔（缺省为60秒）周期性地通过Share-MDT发送给同一MD的所有PE（224.0.0.13）。源PE将一直发送Switch-MDT切换消息，直至组播数据的转发速率低于了阈值，希望接收该组播数据的PE在收到该消息后将发送PIM加入消息以加入Switch-MDT。此后，当这些PE在Switch-Timeout时间内（缺省为180秒）都没有收到新的Switch-MDT切换消息，其为Switch-MDT创建的组播转发表项将会被老化删除。

未连接有接收者的PE在收到Switch-MDT切换消息后不会加入Switch-MDT，但会缓存该消息，以减少将来有接收者时加入Switch-MDT的延时。

2.3.2  Switch-Delay和Switch-Holddown

当组播流量达到或超过阈值、源PE发出Switch-MDT切换消息Switch-Delay时间（缺省为5秒）之后，组播业务才开始通过Switch-MDT发送，这样就为下游PE预留出了加入Switch-MDT的时间，以避免切换过程中数据的丢失。

此后，如果组播流量低于了阈值，源PE也不会马上切换回Share-MDT，而是只有组播流量在Switch-Holddown时间（缺省为60秒）内一直低于阈值，才切换回Share-MDT，这样就可以避免切换振荡。

2.3.3  Switch-MDT切换过程

图9 Switch-MDT切换

如图9所示，Switch-MDT切换的具体过程如下：

(1)        源PE（如PE 1）周期性地检测组播数据的转发速率，一旦满足切换条件就从Switch-Group-Pool中选择一个空闲的Switch-Group地址，沿Share-MDT向下游所有PE发送Switch-MDT切换消息。

(2)        下游PE收到该消息后，检查本MVRF内是否有该组播数据的接收者：若有（如PE 2）则向PE 1发送PIM加入消息以加入组地址为Switch-Group地址的Switch-MDT；若没有（如PE 3）则将该消息缓存起来，以便有接收者时能及时加入Switch-MDT。

(3)        在PE 1发送Switch-MDT切换消息Switch-Delay时间后，组播数据的传输就会从Share-MDT切换到Switch-MDT上了。

2.4  跨AS的MD VPN

2.4.1  跨AS的MD VPN的难题

由于RFC 4364提供了跨越AS的三种单播VPN解决方案：VRF-to-VRF连接方式、EBGP连接方式和Multi-Hop EBGP连接方式，因此MD VPN自然也必须支持这三种解决方案，能够跨越AS建立起MDT。建立跨AS的MDT需要关注以下几个方面：

l              PE在MVRF内进行RPF检查时，RPF邻居必须是远端PE，而不能是ASBR。因为纯粹的ASBR上不会配置MVRF，因而不会建立MT，不会参与MD的任何活动，也无法接收和处理发往MD的PIM消息。

l              ASBR在传播BGP更新报文时会改写VPNv4路由前缀的下一跳属性，使到组播源的下一跳邻居变成了ASBR，而不再是产生该前缀的远端PE。

l              P只维护AS内部的IGP路由信息，不会有到达其它AS的PE的路由信息，除非通过引入BGP路由，否则无法处理去往其它AS的PE的PIM消息。

l              ASBR未必会有关于其它AS的PE的单播路由，所以也不能处理去往其它AS的PE的PIM消息。

现在我们来分析一下跨AS的三种单播VPN解决方案分别对MD方案的要求：

l              在VRF-to-VRF连接方式中，ASBR上配置VRF，并担任PE的角色，所以MDT只需建立在各AS内部，不存在处理域间MDT和进行RPF检查的问题。当组播流到达本AS的ASBR的MVRF之后，将作为组播源进入相邻AS的ASBR的MVRF。由于不需要建立跨AS的MDT，因此不需要更改协议。这种方式唯一的缺点就是其固有的不可扩展性——当VPN很多时，配置的工作量将是可怕的。

l              在EBGP连接方式中，ASBR上不配置VRF，所以报文在AS间转发时必须进行封装，也就是说需要建立跨域的MDT，而关于其它AS的PE的路由信息在本AS的路由器上也未必拥有，P不知道关于其它AS的PE的路由信息，于是建立跨AS的MDT就缺少基本的支持；ASBR保存了所有VPNv4路由并修改了BGP的下一跳属性，因此PE在组播VPN内部的RPF检查也失去了远端PE的信息。

l              Multi-Hop EBGP连接方式也存在着EBGP连接方式所具备的大部分缺点，但唯一不同的是，Multi-Hop EBGP连接方式保留了VPNv4路由的BGP的下一跳信息，这有助于PE在组播VPN内部进行RPF检查。

因此，建立跨AS的MD VPN必须解决RPF邻居以及建立跨AS的MDT时PIM消息的传递问题。

2.4.2  跨AS的MD VPN解决方案

由前面的分析可知，VRF-to-VRF连接方式和Multi-Hop EBGP连接方式为两种目前可实现的越跨AS的MD VPN解决方案。当VPN内的节点通过不同的AS连接时，可以通过VRF-to-VRF或Multi-hop EBGP的连接方式建立跨AS的VPN。

1. VRF-to-VRF连接方式

如图10所示，VPN跨越了AS 1和AS 2两个自治系统，PE 3和PE 4分别是AS 1和AS 2的ASBR。PE 3和PE 4通过各自的VPN实例相连，并互把对方视为CE设备。

图10 VRF-to-VRF连接方式示意图

某PE（如PE 1）去往另一AS的CE（如CE 2）的单播路由下一跳是本AS的ASBR（如PE 3），也就是说VPN通过ASBR进行了转接。通过这种方式实现MD方案，需要在两个AS里分别建立MD。两个MD的Share-Group可以相同，也可以不同，组播数据在这两个MD之间的传递通过ASBR进行转接。

2. Multi-hop EBGP连接方式

如图11所示，VPN跨越了AS 1和AS 2两个自治系统，PE 3和PE 4分别是AS 1和AS 2的ASBR。PE 3和PE 4通过各自的公网实例相连，并互把对方视为P设备。

图11 Multi-hop EBGP连接方式示意图

某PE（如PE 1）去往另一AS的CE（如CE 2）的单播路由下一跳是对方AS的PE（如PE 2），PE之间通过建立Multi-hop EBGP对等体关系把本AS内的VPN路由传送到对方AS。通过这种方式实现MD方案，在两个AS里只能建立一个MD，组播数据在这两个AS之间的传递通过域间组播实现。

3  典型组网应用

3.1  单AS内MD VPN

图12 单AS内MD VPN组网图

如图12所示，在同一AS中存在VPN a和VPN b这两个VPN，各VPN中有不同的组播源和接收者。公网中运行OSPF和MPLS，各PE与CE之间运行RIP，并在各PE间建立BGP对等体连接以传递私网路由。

开展AS内的VPN组播业务，需要在所有设备的公网实例和VPN实例中分别使能IP组播路由；在PE和CE连有接收者的接口上使能IGMP；在各设备的所有公、私网接口上均使能PIM-SM，并分别为公网和各VPN选取合适的C-BSR和C-RP。此外，还需要为VPN a和VPN b选取各自不同的Share-Group地址以及Switch-Group-Pool范围。

3.2  跨AS的MD VPN

图13 跨AS的MD VPN组网图

如图13所示，在两个AS中各存在VPN a和VPN b这两个VPN，各VPN中有不同的组播源和接收者。在各AS内分别运行OSPF和MPLS，各PE与CE之间运行OSPF，并在所有PE间建立BGP对等体连接以传递私网路由。

开展跨AS的VPN组播业务，需要在所有设备的公网实例和VPN实例中分别使能IP组播路由；在CE连有接收者的接口上使能IGMP；在处于ASBR位置的PE 2和PE 3之间建立MSDP对等体连接；在各设备的所有公、私网接口上均使能PIM-SM，并分别为各AS内的公网以及各VPN选取合适的C-BSR和C-RP。此外，还需要为VPN a和VPN b选取各自不同的Share-Group地址以及Switch-Group-Pool范围。

4  参考文献

l              RFC 4364：BGP/MPLS IP Virtual Private Networks (VPNs)

l              draft-rosen-vpn-mcast-08：Multicast in MPLS/BGP IP VPNs

Copyright ©2008 杭州华三通信技术有限公司 版权所有，保留一切权利。

非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。

本文档中的信息可能变动，恕不另行通知。