组播VPN技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目  录

1 概述··· 1

1.1 产生背景·· 1

1.2 技术优势·· 1

2 MDT模式MVPN·· 1

2.1 基本概念·· 1

2.2 MDT模式基本原理·· 2

2.3 PE上的接口类型·· 3

2.4 PIM邻居关系·· 3

2.5 RPF检查·· 4

2.5.1 公网侧的RPF检查·· 4

2.5.2 私网侧的RPF检查·· 4

2.6 Default-MDT· 5

2.6.1 Default-MDT的建立·· 5

2.6.2 Default-MDT的数据转发·· 9

2.7 Data-MDT· 11

2.7.1 Data-MDT简介·· 11

2.7.2 Data-MDT切换消息·· 11

2.7.3 Data-Delay和Data-Holddown· 11

2.7.4 Data-MDT切换过程·· 12

2.8 跨AS的MDT模式MVPN· 12

2.8.1 A类跨AS的MDT模式MVPN· 12

2.8.2 B类跨AS的MDT模式MVPN· 13

2.8.3 C类跨AS的MDT模式MVPN· 14

3 NG MVPN·· 1

3.1 NG MVPN基本概念·· 1

3.2 MP-BGP路由扩展·· 1

3.2.1 BGP MVPN邻居建立·· 1

3.2.2 BGP MVPN路由·· 1

3.2.3 BGP MVPN路由属性·· 3

3.2.4 BGP VPN-IPv4路由携带的MVPN相关扩展团体属性·· 4

3.3 RSVP-TE模式·· 4

3.3.1 创建RSVP-TE P2MP隧道·· 4

3.3.2 创建相容性隧道·· 7

3.3.3 选择性隧道切换·· 9

3.4 mLDP模式·· 10

3.4.1 mLDP模式概述·· 10

3.4.2 mLDP P2MP隧道创建过程·· 11

3.4.3 创建相容性隧道·· 14

3.4.4 选择性隧道切换·· 15

3.4.5 跨AS的mLDP模式MVPN· 17

4 典型组网应用··· 1

4.1.1 单AS内MVPN· 1

4.1.2 跨AS的MVPN· 1

5 参考文献··· 1

 

1  概述

1.1  产生背景

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

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

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

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

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

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

为了解决上述问题，可以在BGP/MPLS VPN网络中部署组播VPN技术，将私网组播数据流量通过公网传递到远端的私网站点。

1.2  技术优势

Comware利用MVPN（Multicast Virtual Private Network，组播VPN）方案来实现在BGP/MPLS VPN网络内开展组播业务。MVPN方案支持MDT、RSVP-TE和mLDP三种模式。其中，RSVP-TE模式和mLDP模式属于NG MVPN（Next Generation MVPN，下一代组播VPN）。

MVPN方案具有如下特点：

·     对现有网络升级简单，仅需升级PE即可，无需对CE和P进行升级或修改其配置，也就是说MVPN方案对CE和P是透明的。骨干网无需感知私网内组播业务的变化，骨干网组播路由的稳定性得到了保证。

·     私网单播路由传递方式无需改变。MVPN方案借助现有的BGP/MPLS VPN技术，通过VPN-IPv4路由在VPN中传递组播源所在网络的路由，以便接收者及PE设备获取到达组播源的单播路由。

·     MDT模式的MVPN，利用公网自身的组播转发能力，解决了RPF检查问题。通过在PE将私网组播数据包封装成公网组播数据包，然后利用公网固有的组播转发能力实现私网组播数据在公网内的组播转发。

·     在NG MVPN中，公网使用BGP来传递私网组播协议报文和私网组播路由，不需要再配置其它组播协议，简化了网络部署复杂度，降低了网络维护难度。

·     在NG MVPN中，公网使用MPLS成熟的标签转发技术和隧道保护技术，使组播业务服务质量更高，可靠性更好。

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

2  MDT模式MVPN

2.1  基本概念

·     MVPN（Multicast Virtual Private Network，组播VPN）：在逻辑上表示某个VPN的私网组播数据在公网中的传播范围，在实际中则标识了网络中支持该VPN的所有PE。每个MVPN都服务于某个特定的VPN，属于该VPN的所有私网组播数据，都在此MVPN内传输。不同的VPN对应不同的MVPN。

·     MVPN实例：PE上为一个MVPN提供组播服务的虚拟实例，用来在PE上实现不同MVPN的业务隔离。

·     MDT（Multicast Distribution Tree，组播分发树）：建立在属于同一VPN内所有PE间的组播分发树，包括Default-MDT和Data-MDT两种。

·     MT（Multicast Tunnel，组播隧道）：在MVPN内将各PE连接到一起的通道称为MT，本地PE将私网组播报文封装成公网组播数据报文，通过MT在公网内进行组播转发，远端PE收到该报文后通过解封装将其还原成私网报文。

·     MTI（Multicast Tunnel Interface，组播隧道接口）：MTI是MT的入/出口，相当于MVPN的入/出口，PE通过MTI连接到MT上，MTI在创建VPN实例的MVPN时自动创建。本地PE将私网数据从入口（MTI）投入MVPN，MVPN自动将私网数据复制并传输到MVPN的所有出口（MTI），任何有需求的远端PE都可以从各自的出口（MTI）“打捞”私网数据。MTI上运行的PIM模式与其所属的VPN实例相同。只有当VPN实例中至少一个接口上使能了PIM协议，MTI上的PIM协议才会被使能；当VPN实例中所有接口上都关闭了PIM协议，MTI上的PIM协议也将被关闭。

·     Default-Group（默认组）：每个MVPN在公网上分配一个独立的组播组，称为Default-Group。它是MVPN在公网上的唯一标志，用来在公网上建立MVPN所对应的Default-MDT。不论私网组播报文属于哪个组播组、是协议报文还是数据报文，PE都统一将其封装为普通的公网组播数据报文，并以Default-Group作为其所属的公网组播组。

·     Default-MDT（Default-Multicast Distribution Tree，默认组播分发树）：以Default-Group为组地址的MDT，称为Default-MDT。MVPN使用Default-Group唯一标识一棵Default-MDT。在该MVPN中传输的所有私网组播报文，无论从哪个PE进入公网，都经由此Default-MDT转发。不论公网或私网中有没有实际的组播业务，Default-MDT在公网中会一直存在。

·     Data-Group（数据组）：当某私网组播数据的流量达到或超过阈值时，入口PE会为其分配一个独立的组播组，称为Data-Group，并通知其它PE使用该组播组在公网内转发该组播数据流量。一个MVPN唯一确定一个Data-Group范围以备进行Data-MDT切换。在进行Data-MDT切换时，PE从Data-Group范围中选取一个被引用最少的地址，流量达到或超过切换阈值的私网组播报文将使用该地址进行封装。

·     Data-MDT（Data-Multicast Distribution Tree，数据组播分发树）：以Data-Group为组地址的MDT，称为Data-MDT。下游存在接收者的PE加入Data-Group，形成一棵Data-MDT，入口PE使用Data-MDT在公网中转发封装后的私网组播数据。

2.2  MDT模式基本原理

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

对于VPN实例来说，公网传输是透明的，私网数据的传输在PE上的MTI处完成了无缝连接：VPN实例只知道将私网数据从MTI发出，然后远端就能从MTI接收。其实中间经历了复杂的公网传输过程，即MDT传输过程。

 

图1 MDT模式MVPN方案示意图

 

如图1所示，三个PE属于同一MVPN，各PE之间已建立MT。C-Packet在源PE（如PE 1）处被封装在P-Packet中，并通过MT到达另一Site的PE：

·     如果某PE（如PE 2）的下游有接收者，则该PE将剥掉P-Packet的报文头还原成C-Packet转发给其CE。

·     如果某PE（如PE 3）的下游没有接收者，P-Data-Packet将被该PE直接丢弃。

由此可以看出，上述方案存在一个重要的缺点：在骨干网中，组播数据将沿Default-MDT转发给MVPN内的所有PE，不会考虑PE下游是否存在组播接收者。这样造成了带宽浪费，也增加了PE的处理负担。

为了克服这个缺点，MDT模式MVPN方案提出一个权衡组播路由优化与可扩展性的折中方案：对于流量较小的组播业务，仍使用Default-MDT；而对于流量较大的组播业务，则为其单独分配Data-MDT，将组播数据以Data-Group为目的地址沿Data-MDT转发给那些真正有接收需求的PE。

2.3  PE上的接口类型

PE上包含以下三种接口类型：

·     PNI（Provider Network Interface，公网接口）：是指PE上连接P设备的接口。从PNI收发的报文使用公网路由转发表进行路由转发。

·     CNI（Customer Network Interface，私网接口）：是指PE上连接CE设备的接口。从CNI收发的报文使用该接口所属VPN实例的组播路由转发表进行路由转发。

·     MTI：是PE上的虚拟接口，完成Default-MDT和PIM配置，并建立IBGP连接后，MTI会自动创建并进入Up状态。MTI就是MT的入/出口，也相当于MVPN的入/出口。

2.4  PIM邻居关系

如图2所示，在MDT传输组播数据前需要建立如下三种PIM邻居关系：

·     PE-P邻居关系：PE上公网接口与链路对端P上的接口之间建立的PIM邻居关系。

·     PE-CE邻居关系：PE上绑定VPN实例的接口与链路对端CE上的接口之间建立的PIM邻居关系。

·     PE-PE邻居关系：PE上的VPN实例通过MTI收到远端PE上的VPN实例发来的PIM Hello报文后建立的邻居关系。

图2 PIM邻居关系示意图

 

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

2.5  RPF检查

RPF检查是PIM协议重要的组成部分。PIM使用单播路由表来确定RPF信息，包括用于报文RPF检查的RPF接口信息和用于PIM加入/剪枝消息的RPF邻居信息。公网侧和私网侧的RPF检查方式有所不同。

2.5.1  公网侧的RPF检查

当PE进行公网侧的RPF检查时，其情形与不存在组播VPN时完全一样。如图3所示，此时Default-MDT尚未建立，PE 2对来自P的组播报文进行RPF检查时，RPF接口为PE 2的PNI接口Interface A，RPF邻居为P。

图3 公网侧的RPF检查

 

2.5.2  私网侧的RPF检查

当PE进行私网侧的RPF检查时，又可分为以下两种情况：

·     对来自本端组播源的报文进行RPF检查。这种情形也与不存在组播VPN时完全一样。如图4所示，PE 1对来自CE 1的组播报文进行RPF检查时，RPF接口为PE 1的CNI接口Interface A，RPF邻居为CE 1。

图4 对来自本端组播源的报文进行RPF检查

 

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

图5 对来自远端组播源的报文进行RPF检查

 

2.6  Default-MDT

2.6.1  Default-MDT的建立

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

 

公网中运行的组播路由协议可以是PIM-DM、PIM-SM、双向PIM或PIM-SSM中的一种。在这四种情况下，创建Default-MDT的过程是有区别的。

1. 在PIM-DM网络中创建Default-MDT

图6 在PIM-DM网络中创建Default-MDT

 

如图6所示，公网中运行PIM-DM，PE 1、PE 2和PE 3都支持VPN实例A。Default-MDT的创建过程如下：

(1)     PE 1通过VPN实例A的MTI与其它PE建立PIM邻居关系时，会将私网PIM协议报文封装成公网组播数据报文（封装时以MVPN源接口的IP地址为源地址、Default-Group为目的地址）在公网中发送。发送时，PE 1以其它支持VPN实例A的PE为组播组成员，在整个公网范围内发起扩散—剪枝过程，在公网沿途各设备上分别创建（11.1.1.1，239.1.1.1）表项，从而形成一棵以PE 1为根、PE 2和PE 3为叶的SPT。

(2)     与此同时，PE 2和PE 3也各自发起类似的扩散—剪枝过程，最终在MVPN中形成三棵相互独立的SPT。

在PIM-DM网络中，由这三棵相互独立的SPT共同组成Default-MDT。

2. 在PIM-SM网络中创建Default-MDT

图7 Default-MDT的建立过程

 

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

(3)     在PE 1上配置Default-Group之后，PE 1就会通过PIM协议向骨干网RP发起（*，G）加入，并在骨干网沿途各设备上创建（*，Default-Group）表项。PE 2和PE 3也各自发起类似的加入过程，最终在MVPN中形成一棵以公网RP为根，PE 1、PE 2和PE 3为叶的RPT。

(4)     在PE 1的MVPN实例上配置PIM之后，PIM协议会周期性地组播PIM Hello消息，PE 1将其封装成P-Data-Packet（封装时以MTI源接口的地址作为源地址、Default-Group为目的地址）并向骨干网RP发起注册，在骨干网沿途各设备上创建（S，Default-Group）表项。PE 2和PE 3也各自发起类似的注册过程，最终在MVPN中形成三棵相互独立的、连接PE与RP的SPT。

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

3. 在双向PIM网络中创建Default-MDT

图8 在双向PIM网络中创建Default-MDT

 

如图8所示，公网中运行双向PIM，且PE 1、PE 2和PE 3都支持VPN实例A。Default-MDT的创建过程如下：

(5)     PE 1向公网RP发起（*，G）加入，以Default-Group为组播组地址，在公网沿途各设备上分别创建（*，239.1.1.1）表项。与此同时，PE 2和PE 3也各自发起类似的加入过程，最终在MVPN中形成一棵以公网RP为根，PE 1、PE 2和PE 3为叶的接收者侧RPT。

(6)     PE 1以Default-Group为组播组地址发送组播数据，在公网途径的每个网段都被该网段的DF无条件向RP转发，并在沿途各设备上分别创建（*，239.1.1.1）表项。与此同时，PE 2和PE 3也各自发起类似的创建过程，最终在MVPN中形成三棵分别以PE 1、PE 2和PE 3为根、公网RP为叶的组播源侧RPT。

在双向PIM网络中，由接收者侧RPT和组播源侧RPT共同构成的双向RPT（*，239.1.1.1）就是Default-MDT。

4. 在PIM-SSM网络中创建Default-MDT

图9 在PIM-SSM网络中创建Default-MDT

 

如图9所示，公网中运行PIM-SSM，且PE 1、PE 2和PE 3都支持VPN实例A。Default-MDT的创建过程为：PE 1、PE 2和PE 3两两之间先通过BGP互换各自的MDT路由信息（包含BGP接口地址和Default-Group地址等信息），然后分别向对方的BGP接口地址逐跳发送订阅报文（Subscribe Message），在公网沿途各设备上分别创建（S，G）表项，从而形成一棵以本PE为根、其它PE为叶的SPT。最终在MVPN中形成三棵相互独立的SPT。

在PIM-SSM网络中，由这三棵相互独立的SPT共同组成Default-MDT。

 

2.6.2  Default-MDT的数据转发

当Default-MDT建立完毕之后，就可以在VPN中进行组播数据的传递了。在如下两种情况下，组播数据通过Default-MDT转发的过程为：

·     组播源与接收者处于同一PE侧

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

图10 组播源与接收者处于同一PE侧

 

如图10所示，CE 1连接组播源S，CE 2连接组播组G的接收者。PE 1收到来自CE 2的PIM加入消息后，将接口Interface B加入到（*，G）表项的出接口列表中，通过查找PE 1到Source的单播路由后将接口Interface A作为该表项的入接口。组播数据从CE 1发送到PE 1，再由PE 1转发给CE 2。

·     组播源与接收者处于不同PE侧

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

图11 组播源与接收者处于不同PE侧

 

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

2.7  Data-MDT

2.7.1  Data-MDT简介

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

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

 

2.7.2  Data-MDT切换消息

Data-MDT切换消息是一种UDP报文，该消息中包含了私网组播源地址、私网组播组地址和Data-Group地址。当发起Data-MDT切换时，它将被封装在P-Packet中，由源PE周期性地通过Default-MDT发送给同一MVPN的所有PE。源PE将一直发送Data-MDT切换消息，直至组播数据的转发速率低于阈值。希望接收该组播数据的PE在收到该消息后将发送PIM加入消息以加入Data-MDT。此后，如果这些PE在Data-Timeout时间内都没有收到新的Data-MDT切换消息，则删除为Data-MDT创建的组播转发表项。

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

2.7.3  Data-Delay和Data-Holddown

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

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

2.7.4  Data-MDT切换过程

图12 Data-MDT切换

 

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

(7)     源PE（如PE 1）周期性地检测组播数据的转发速率，一旦满足切换条件就从Data-Group范围中选取一个被引用最少的Data-Group地址，沿Default-MDT向下游所有PE发送Data-MDT切换消息。

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

(9)     在PE 1发送Data-MDT切换消息Data-Delay时间后，组播数据的传输就会从Default-MDT切换到Data-MDT。

2.8  跨AS的MDT模式MVPN

在实际组网应用中，当一个VPN跨越多个AS时，需要连通其分布在不同AS内的Site，这种VPN跨越多个AS的应用方式被称为跨域VPN。跨域VPN的解决方案包括：

·     ASBR之间建立VRF-to-VRF连接，也称为A类跨AS。

·     ASBR之间通过MP-EBGP发布VPN-IPv4路由，也称为B类跨AS。

·     PE之间通过MP-EBGP发布VPN-IPv4路由，也称为C类跨AS。

2.8.1  A类跨AS的MDT模式MVPN

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

图13 A类跨AS的MDT模式MVPN示意图

 

采用本方式时，需在每个AS内各建立一个独立的MVPN，在各MVPN之间实现私网组播数据跨AS的传输。跨AS传输私网组播数据的过程如下：

(10)     由于PE 3与PE 4互把对方视为自己的CE，因此：在AS 1中，CE 1与PE 4（相当于PE 3的CE）之间可以互通组播业务；在AS 2中，CE 2与PE 3（相当于PE 4的CE）之间也可以互通组播业务。

(11)     CE 1发出的VPN 1的私网组播协议和数据报文通过MT 1到达PE 4后，被PE 4视为与自己私网接口相连的VPN 2的私网报文，于是将其通过MT 2转发给CE 2；CE 2发出的VPN 2的报文也同理到达CE 1。这样，就实现了私网组播数据在CE 1与CE 2之间的互通。

2.8.2  B类跨AS的MDT模式MVPN

如图14所示，VPN跨越了AS 1和AS 2两个自治系统，PE 3和PE 4分别是AS 1和AS 2的ASBR。PE 3和PE 4通过MP-EBGP相连。在此组网中，ASBR之间通过MP-EBGP交换它们从各自AS内的PE上接收的VPN-IPv4路由。

图14 B类跨AS的MDT模式MVPN

 

采用本方式时，只需在所有AS内统一建立一个MVPN即可，在该MVPN内部实现公网组播数据跨AS的传输。具体实现方式如下：

(12)     公网使用RPF代理向量创建Default-MDT

 

在此组网中，由于AS 1与AS 2之间的公网路由相互隔离，设备无法找到去往其它AS中PE的路由，从而导致RPF检查失败，因此要引入RPF代理向量来协助完成公网的RPF检查。Default-MDT的具体创建过程如下：

a.     PE 1向PE 2发起PIM加入时，把从BGP MDT路由中获得的下一跳地址（BGP MDT路由中的下一跳为本AS的ASBR，即PE 3的地址）作为RPF代理向量，PE 1将此RPF代理向量封装在发往PE 2的PIM加入报文中。

b.     P 1收到该报文后，发现RPF代理向量不是本地地址，根据该向量查找到上游为PE 3，因此继续向PE 3发送携带RPF代理向量的PIM加入报文。

c.     PE 3收到该报文后，发现RPF代理向量是本地地址，无法再根据该向量查找上游，于是查找BGP MDT路由，发现去往PE 2的下一跳为PE 4，并且有直连路由，因此继续向PE 4发送携带RPF代理向量的PIM加入报文。

d.     PE 4收到该报文后，由于在本AS内可以找到去往PE 2的路由，于是将RPF代理向量剥离后逐跳向PE 2发送PIM加入报文，最终建立起从PE 1到PE 2的SPT。

e.     与此同时，PE 2也向PE 1发起类似的SPT建立过程，最终完成公网Default-MDT的建立。

(13)     私网使用BGP Connector进行RPF检查

接收者侧PE在私网通过MTI向组播源侧PE发送PIM加入报文时，需要查找到达组播源的私网路由，使用路由下一跳作为私网PIM加入报文中的上游邻居地址，以便组播源侧PE收到该报文后进行RPF检查。在非跨AS的情况下，下一跳正好对应组播源侧PE上MTI的源地址；但在B类跨AS的情况下，BGP协议会将下一跳改为本AS的ASBR地址，而不是组播源侧PE的地址，这样就会导致RPF检查失败。

为了避免这种情况，需要BGP对等体在交换VPN-IPv4路由时携带组播源侧PE的地址（该地址称为BGP Connector），接收者侧PE在私网通过MTI发送PIM加入报文时，报文中的上游地址填写为组播源侧PE的BGP Connector。

2.8.3  C类跨AS的MDT模式MVPN

如图15所示，VPN跨越了AS 1和AS 2两个自治系统，PE 3和PE 4分别是AS 1和AS 2的ASBR。PE 3和PE 4通过MP-EBGP相连，并互把对方视为P设备。在此组网中，不同AS的PE之间建立多跳MP-EBGP会话，并通过该会话直接在PE之间发布VPN-IPv4路由。

图15 C类跨AS的MDT模式MVPN

 

采用本方式时，只需在所有AS内统一建立一个MVPN即可，在该MVPN内实现公网组播数据跨AS的传输。跨AS传输私网组播数据的过程如下：

(14)     CE 1发出的私网组播协议和数据报文都经由PE 1上的MTI封装后在MT中传输。这样，被封装后的私网报文在公网中就变成了普通的公网组播数据报文。

(15)     在PE 3和PE 4这两台ASBR上配置了MP-EBGP连接后，AS 1和AS 2就实现了公网的互通，被封装成公网组播数据报文的私网报文就可以顺利到达PE 2。这样，就实现了私网组播数据在CE 1与CE 2之间的互通。

3  NG MVPN

NG MVPN是IP组播数据穿越BGP/MPLS L3VPN网络的新一代解决方案。NG MVPN通过MP-BGP协议传递私网组播路由，通过P2MP隧道传输私网组播协议报文和组播数据流量，实现私网组播数据流量通过公网传递到远端的私网站点。

NG MVPN方案支持两种模式：RSVP-TE模式和mLDP模式。

3.1  NG MVPN基本概念

·     MVPN（Multicast Virtual Private Network，组播VPN）：在逻辑上表示某个VPN的私网组播数据在公网中的传播范围，在实际中则标识了网络中支持该VPN的所有PE。每个MVPN都服务于某个特定的VPN，属于该VPN的所有私网组播数据，都在此MVPN内传输。不同的VPN对应不同的MVPN。

·     MVPN实例：PE上为一个MVPN提供组播服务的虚拟实例，用来在PE上实现不同MVPN的业务隔离。

·     Inclusive-Tunnel（相容性隧道）：承载来自于一个MVPN的所有组播业务。一个VPN实例唯一对应一条相容性隧道。PE将组播数据报文和PIM BSM（Bootstrap Message，自举报文）统一封装为普通的公网组播数据报文，并通过相容性隧道发送到公网中。

·     Selective-Tunnel（选择性隧道）：承载来自于一个或多个特定的组播组的组播业务。一个VPN实例可以对应多条选择性隧道。

3.2  MP-BGP路由扩展

3.2.1  BGP MVPN邻居建立

为了支持NG MVPN，MP-BGP新增BGP MVPN地址族，该地址族用于协商和建立BGP MVPN邻居，并传递私网组播路由信息。对于BGP IPv4 MVPN和BGP IPv6 MVPN，AFI（Address Family Identifier，地址族标识符）分别为1和2，SAFI（Subsequent Address Family Identifier，子地址族标识符）均为5。

在NG MVPN组网中，PE之间既可以建立IBGP邻居，也可以建立EBGP邻居：

·     建立IBGP邻居时，为简化全连接配置，需要部署RR（Route Reflector，路由反射器）。所有PE都只需和RR建立IBGP邻居关系。RR发现并接收PE发起的BGP连接后形成客户机列表，将从某个PE收到的路由反射给其他所有的PE。

·     建立EBGP邻居时，不需要部署RR。BGP自动将从EBGP邻居收到的MVPN路由发送给其他EBGP和IBGP邻居。

3.2.2  BGP MVPN路由

在NG MVPN中，MVPN路由信息是携带在BGP Update消息中的NLRI（Network Layer Reachable Information，网络层可达信息）字段中进行传递的，携带MVPN路由信息的NLRI也称为MVPN NLRI。

MVPN NLRI的格式如图16所示。

图16 MVPN NLRI格式

 

MVPN NLRI各字段的含义如下：

·     Route Type：MVPN路由的类型。MVPN路由一共分为7类。具体可参见表1。

·     Length：MVPN NLRI里Route Type specific字段的长度。

·     Route Type specific：MVPN路由信息。不同类型的MVPN路由包含不同的信息，所以该字段的长度是可变的。

表1 MVPN路由分类

类型	名称	含义
1	Intra-AS I-PMSI A-D route	主要用于域内MVPN成员的自动发现，PE之间根据Intra-AS I-PMSI A-D Route建立相容性隧道
2	Inter-AS I-PMSI A-D route	主要用于域间MVPN成员的自动发现，由所有配置了MVPN功能ASBR发起
3	S-PMSI A-D route	当满足切换隧道的条件后，组播源侧PE向接收者侧PE发送S-PMSI A-D Route以进行选择性隧道切换
4	Leaf A-D route	接收者侧PE收到组播源侧PE发送的S-PMSI A-D Route后，回应Leaf A-D route，表示接收者侧PE存在建立选择性隧道的需求，协助组播源侧PE完成隧道信息收集
5	Source Active A-D route	当组播源侧PE发现一个新的组播源时，组播源侧PE向接收者侧PE发送Source Active A-D Route以通告组播源的位置信息
6	Shared Tree Join route	主要用来传递私网组播成员的加入信息。当接收者侧PE收到来自用户侧的（*，G）加入请求时，会将（*，G）加入消息转换成Shared Tree Join route，并将该路由穿越公网发送给组播源侧PE
7	Source Tree Join route	主要用来传递私网组播成员的加入信息，当接收者侧PE收到自用户侧的（S，G）加入请求时，会将（S，G）加入消息转换成Source Tree Join route，并将该路由穿越公网发送给组播源侧PE

 

 

3.2.3  BGP MVPN路由属性

1. PMSI Tunnel attribute

PMSI（Provider Multicast Service Interface，运营商组播服务接口）是指公网承载私网组播数据流量的逻辑通道。对指定的组播数据流量，在组播源侧PE上通过PMSI将私网组播数据流量分发给其他PE，接收者PE根据PMSI接收属于同一MVPN的组播数据流量。公网隧道是PMSI的具体实现形式，在NG MVPN中，公网隧道分为相容性隧道和选择性隧道。

PMSI Tunnel attribute主要用于公网隧道的创建，目前携带在Intra-AS I-PMSI A-D route和S-PMSI A-D route中，格式如图17所示。

图17 PMSI Tunnel attribute格式

 

PMSI Tunnel attribute各字段的含义如下：

·     Flags：标志位。目前只有3类路由携带此属性时，该字段有意义。

¡     3类路由S-PMSI A-D route携带此属性时，该标志位取值为0，表示接收者侧PE收到S-PMSI A-D route后不需要对此消息进行回应。

¡     3类路由S-PMSI A-D route携带此属性时，该标志位取值为1，表示接收者侧PE收到S-PMSI A-D route后需要回应4类路由Leaf A-D route。

·     Tunnel Type：隧道类型。目前只支持RSVP-TE P2MP隧道和mLDP P2MP隧道两种类型。

·     MPLS Label：MPLS标签值，用于VPN隧道复用，目前不支持。

·     Tunnel Identifier：隧道信息。

¡     对于RSVP-TE P2MP隧道，隧道信息为<P2MP ID, Tunnel ID, Extended Tunnel ID>。

¡     对于mLDP P2MP隧道，隧道信息为<Root node address, Opaque value>。

2. Router Target扩展团体属性

Route Target扩展团体属性用来控制BGP MVPN路由的发布和接收。

Route Target属性分为如下两类：

·     Export Target属性：为本地PE上的VPN实例设置Export Target属性后，PE在发布VPN实例对应MVPN实例的MVPN A-D路由时，会携带该Export Target属性。

·     Import Target：当PE收到其他PE发布的MVPN A-D路由时，检查路由中的Export Target属性。只有当此属性与PE上某个VPN实例的Import Target属性存在相同的属性值时，才接受该MVPN A-D路由，并在VPN实例中记录MVPN成员。如果不匹配，则丢弃该路由。

3.2.4  BGP VPN-IPv4路由携带的MVPN相关扩展团体属性

在NG MVPN网络中，BGP VPN-IPv4路由需要携带MVPN相关的扩展团体属性，以便对C-multicast路由的发布和接收进行控制，实现组播用户加入或者离开消息的准确传递。MVPN相关的扩展团体属性包含如下两种：

·     Source AS Extended Community：此属性携带本地BGP自治系统号信息，取值为MVPN组播源的AS号，格式为32位自治系统号::0。该属性主要用于跨域场景。

·     VRF Route Import Extended Community：此属性携带本地BGP实例的Router ID和BGP VPN-IPv4路由所属的VPN实例信息，格式为32位Router ID:VPN实例索引。组播源侧PE发布给接收者侧PE的VPN-IPv4路由中包含此属性，接收者侧PE向组播源侧PE回应C-multicast route时会将此属性携带在路由中。组播源侧PE在收到接收者侧PE发送的Shared Tree Join route或Source Tree Join route时，如果Router ID为自己的Router ID，则将该路由加入到VPN实例索引标识的VPN实例的组播转发表项中；否则，组播源侧PE忽略该路由。

3.3  RSVP-TE模式

RSVP-TE模式组播VPN的基本思想是：各PE之间两两建立IBGP邻居，通过MP-BGP协议发布MVPN路由信息，在公网上建立RSVP-TE P2MP隧道。私网组播数据通过相容性RSVP-TE P2MP隧道或选择性RSVP-TE P2MP隧道传输给远端PE，远端PE收到该报文后通过剥离标签信息将其还原成私网组播报文。

3.3.1  创建RSVP-TE P2MP隧道

RSVP-TE P2MP隧道是由RSVP-TE P2MP协议建立、用来承载私网组播流量的点对多点的隧道。RSVP-TE P2MP协议（Point-to-MultiPoint，点到多点）用于建立点到多点类型的CR-LSP（称为P2MP LSP）。一条或多条RSVP-TE P2MP LSP构成了点到多点类型的RSVP-TE P2MP隧道。

P2MP LSP具有多个目的节点。P2MP LSP头节点到各目的节点的点对点类型的LSP称为Sub-LSP。一条P2MP LSP由多条Sub-LSP组成。

1. RSVP-TE P2MP协议对RSVP协议扩展

RSVP P2MP协议在Path和Resv消息中新增如下对象：

·     P2MP SESSION对象

Path和Resv消息均可以携带该对象。

该对象用来唯一标识一条P2MP TE隧道。P2MP SESSION格式如图18所示。

图18 P2MP SESSION格式

 

P2MP SESSION各字段的含义如下：

¡     P2MP ID：头节点为不同的P2MP TE隧道分配不同的P2MP ID。

¡     MUST be zero：保留字段。

¡     Tunnel ID：隧道ID。

¡     Extended Tunnel ID：扩展隧道ID，取值为P2MP TE隧道的源地址。

一条P2MP LSP由P2MP SESSION对象以及P2MP SENDER_TEMPLATE对象中的LSP ID字段来唯一确定。

·     S2L_SUB_LSP对象

Path和Resv消息均可以携带该对象。

该对象用来携带P2MP LSP的目的地址。一个S2L_SUB_LSP只能携带一个目的地址，一个Path消息只能携带一个S2L_SUB_LSP。P2MP LSP支持多个目的地址，所以一条P2MP LSP需要使用多个Path消息。

·     P2MP_SENDER_TEMPLATE对象

Path消息中可以携带该对象。

RSVP P2MP协议在P2P SENDER_TEMPLATE基础上增加Sub-Group Originator ID、Sub-Group ID字段，用来标识同一个P2MP LSP的不同Path消息。节点使用自己的LSR ID作为Sub-Group Originator ID，并为不同Path消息分配不同的Sub-Group ID。

·     P2MP_FILTER_SPEC对象

Resv消息中可以携带该对象。

RSVP P2MP协议在P2P FILTER_SPEC基础上增加Sub-Group Originator ID、Sub-Group ID字段，用来标识同一个P2MP LSP的不同Resv消息。节点使用自己的LSR ID作为Sub-Group Originator ID，并为不同Resv消息分配不同的Sub-Group ID。

2. RSVP-TE P2MP LSP建立过程

图19 P2MP LSP建立过程

 

如图19所示，使用RSVP-TE建立P2MP LSP的过程为：

(16)     选择第一个Egress叶子节点为目的地址。

(17)     Ingress LSR在S2L_SUB_LSP对象中携带该Egress叶子节点地址建立CRLSP。

¡     Ingress LSR生成携带LABEL_REQUEST对象的P2MP Path消息，沿着通过CSPF计算出的路径将该消息逐跳发送给Egress LSR。Path消息经过的LSR，都依据Path消息生成路径状态。

¡     Egress LSR收到Path消息后，生成携带预留信息和LABEL对象的Resv消息，沿着Path消息的相反路径将该消息逐跳发送给Ingress LSR。Resv消息通告标签的同时，在沿途的LSR上预留一定的资源，并生成预留状态。

(18)     选择下一个叶子节点，重复步骤（2）。

(19)     当Ingress LSR成功为所有的叶子节点创建Sub-LSP时，RSVP-TE P2MP LSP建立成功。

(20)      

3. RSVP-TE P2MP报文转发

如图20所示，CE 1、CE 2和CE 3加入同一组播组。组播源Source只需向根节点PE 1发送一份信息，由网络中各设备根据该组播组中各成员的分布情况对该信息进行复制和标签转发，最后将该信息准确地发送给CE 1、CE 2和CE 3。根节点PE 1收到组播报文时，先查找组播路由表项，确认该组播报文需要通过RSVP P2MP LSP转发，然后为组播报文添加标签，根据组播标签转发表进行MPLS转发。

图20 RSVP P2MP转发示意图

 

3.3.2  创建相容性隧道

如图21所示，在组播源侧PE和接收者侧PE上均部署了BGP和MVPN之后，相容性隧道的创建过程如下：

(21)     组播源侧PE向接收者侧PE发送1类路由Intra-AS I-PMSI A-D route。该路由中携带了如下属性：

¡     Route Target：用于控制路由的发布和接收。

¡     PMSI Tunnel attribute，用于传递隧道信息。其中，Tunnel Type字段取值为RSVP-TE P2MP隧道；Tunnel Identifier取值为组播源侧PE为RSVP-TE P2MP隧道分配的隧道信息。

(22)     接收者侧PE向组播源侧PE发送1类路由Intra-AS I-PMSI A-D route，该路由中未携带PMSI Tunnel attribute，只携带了Route Target属性来控制路由的发布和接收。

(23)     接收者侧PE收到组播源侧PE发送的1类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接受此路由并将组播源侧PE记录为隧道的远端PE。

(24)     组播源侧PE接收到接收者侧PE发送的1类路由后，检查路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接受此路由，并向接收者侧PE发送Path消息，将接收者PE记录为隧道的目的端（即Egress叶子节点）。

(25)     组播源侧PE在收到接收者侧PE回应的Resv消息后，创建以组播源侧PE为源端、该接收者侧PE为目的端的Sub-LSP。

(26)     当有多个接收者侧PE时，可按照相同的方法创建多条Sub-LSP，从而形成以组播源侧PE为源端、所有接收者侧PE为目的端的RSVP-TE P2MP LSP。RSVP-TE P2MP LSP的具体建立过程参见“3.3.1  创建RSVP-TE P2MP隧道”。

图21 相容性隧道的创建过程

 

至此，MVPN中组播源侧PE到各个接收者侧PE之间的RSVP-TE P2MP相容性隧道创建完成，如图22所示。

图22 在公网中创建相容性隧道

 

3.3.3  选择性隧道切换

1. 选择性隧道切换过程

由于相容性隧道承载同一个MVPN的所有组播业务，该隧道由属于同一个MVPN的所有PE组成。因此对于接收者侧的所有PE，无论该PE是否有下游接收者，均会接收到组播数据流量，造成了网络中带宽的浪费，同时也加重了PE设备处理的负担。

当达到指定的切换条件时，相容性隧道可以切换到选择性隧道，以实现不同组播流量通过不同的隧道传递。

选择性隧道切换的过程如下：

(27)     组播源侧PE收到满足隧道切换条件的私网组播报文后，向接收者侧PE发送携带PMSI Tunnel attribute的S-PMSI A-D route，并要求接收者侧PE回应加入信息。

(28)     接收者侧PE收到组播源侧PE发送的S-PMSI A-D route后，记录该路由。若存在下游接收者，则接收者侧PE向组播源侧PE回应Leaf A-D route，同时接收者侧PE根据S-PMSI A-D route中携带的PMSI Tunnel attribute加入对应的隧道（由于此时组播源侧PE不知道隧道目的端PE的信息，所以隧道还未真正建立）。若不存在下游接收者，则接收者侧PE不会回应Leaf A-D route。

(29)     组播源侧PE收到接收者侧PE发送的Leaf A-D route后，创建以组播源侧PE为源端、该接收者侧PE为目的端的Sub-LSP。

(30)     当存在下游接收者的接收者侧PE有多个时，可按照相同的方法创建多条Sub-LSP，从而形成以组播源侧PE为源端、所有存在接收者的接收者侧PE为目的端的RSVP-TE P2MP LSP。RSVP-TE P2MP LSP的具体建立过程参见“3.3.1  创建RSVP-TE P2MP隧道”。

图23 选择性隧道切换过程

 

至此，MVPN中组播源侧PE到接收者侧PE之间的RSVP-TE P2MP选择性隧道创建完成，如图24所示。

图24 创建选择性隧道并进行隧道切换

 

2. 选择性隧道的延迟切换

当组播流量满足切换条件后，连接组播源的PE会延迟一段时间才将组播业务切换到选择性隧道发送。这样就为下游PE预留出了回应Leaf A-D route的时间，并且预留了选择性隧道建立的时间，以避免切换过程中数据的丢失。

3.4  mLDP模式

3.4.1  mLDP模式概述

mLDP模式也是NG-MVPN的一种解决方案。与RSVP-TE模式差异点主要体现在公网隧道的构建方式：

·     RSVP-TE模式的P2MP隧道构建从Ingress PE开始，Ingress PE需要知道P2MP隧道的终点PE（叶子节点）的IP地址，从上游向下游通过RSVP协议建立标签隧道。

·     mLDP模式的P2MP隧道是从Egress PE开始，Egress PE需要知道Ingress PE（根节点）的IP地址，从下游向上游通过LDP协议签建立隧道。

3.4.2  mLDP P2MP隧道创建过程

1. mLDP P2MP节点角色

如图25所示，mLDP P2MP建立了一条由一个入口节点（PE 1）到多个尾节点（PE 3、PE 4、PE 5）的“树形”隧道，组播流量在入口节点引入到该隧道中进行转发。当网络中的某些设备（即Receiver）需要接收组播报文时，组播源（即Source）仅需发送一份报文到入口节点，在分支节点（PE 2和P 3）上进行报文的复制，从而保证不会重复占用带宽。

图25 mLDP P2MP组网示意图

 

mLDP P2MP隧道中包括如下节点角色：

·     Root：根节点。mLDP P2MP网络的Ingress节点，组播报文在此处被压入MPLS标签。根节点通过BGP通告的MVPN路由中的1类和3类路由将组播源信息和根节点信息传递给叶子节点。

·     Transit：中间节点，负责交换标签。

·     Branch：分支节点，中间节点中的一种。MPLS报文在此节点复制（根据其后叶子节点个数进行复制），然后进行标签交换。

·     Leaf：叶子节点。如果与本节点相连的设备中存在组播接收者，则本节点为叶子节点。叶子节点为mLDP P2MP隧道的尾节点。

·     Bud：Bud节点。既作为mLDP P2MP网络的叶子节点，又作为Branch节点。

2. LDP协议扩展

·     mLDP会话

mLDP会话建立时需协商mLDP能力，只有本地和远端对等体均支持mLDP P2MP功能，才能在二者之间建立mLDP P2MP隧道。mLDP会话消息格式如图26所示。

图26 mLDP会话消息格式

 

mLDP会话消息各字段的含义如下：

¡     U：设置为1，表示对端设备如果不支持协商，则可以忽略该TLV。

¡     V：设置为0，表示不需要转发协商报文。

¡     P2MP Capablity：设置为1，表示该LSP协商的是P2MP能力。

¡     S：会话初始的时候设置为1，表示具有P2MP能力。

¡     Reserved：保留字段。

·     P2MP FEC element

mLDP P2MP扩展了标签映射消息中的FEC TLV，用于建立mLDP P2MP隧道。扩展的FEC TLV称为P2MP FEC Element，其报文格式如图27所示。P2MP FEC Element主要包含以下几部分：

¡     Type：mLDP建立的树形LSP类型，目前仅支持P2MP。

¡     Address family：根节点地址类型。目前仅支持IPv4和IPv6。

¡     Address length：根节点地址长度。

¡     Root node address：根节点地址。

¡     Opaque length：Opaque value的长度。

¡     Opaque value：Opaque value用来在根节点区分不同的P2MP LSP，并携带一些关于P2MP的根节点和叶子节点的信息。

图27 P2MP FEC Element格式示意图

 

3. mLDP P2MP隧道建立

如(20)图28所示，本地和远端对等体成功协商mLDP能力后，建立mLDP P2MP隧道的过程为：

(31)     根节点通过BGP通告的MVPN路由中的1类和3类路由将组播源信息和根节点信息传递给叶子节点。叶子节点和中间节点选择到根节点的最优路由，并将该路由的下一跳作为自己的上游节点。

(32)     叶子节点向上游发送Label mapping消息，并生成相应转发表项。

(33)     中间节点接收到来自下游的Label mapping消息后，会查询是否给上游发送过标签映射消息。如果没有给上游发送过标签，则查询路由表确定上游后，向上游发送Label mapping消息，并生成对应的转发表项。如果已经发送过，则无需再次发送。

(34)     根节点收到下游发送的Label mapping消息后，会生成相应的转发表项。

图28 mLDP P2MP隧道建立过程示意图

 

4. mLDP P2MP报文转发

如图29所示，CE 1、CE 2和CE 3加入同一组播组。组播源Source只需向根节点PE 1发送一份信息，由网络中各设备根据该组播组中各成员的分布情况对该信息进行复制和标签转发，最后将该信息准确地发送给CE 1、CE 2和CE 3。根节点PE 1收到组播报文时，先查找组播路由表项，确认该组播报文需要通过mLDP P2MP隧道转发，然后为组播报文添加标签，根据组播标签转发表进行MPLS转发。

图29 mLDP P2MP转发示意图

 

3.4.3  创建相容性隧道

如图30所示，在组播源侧PE和接收者侧PE上均部署了BGP和MVPN之后，相容性隧道的创建过程如下：

(35)     组播源侧PE向接收者侧PE发送1类路由Intra-AS I-PMSI A-D route。该路由中携带了如下属性：

¡     Route Target：用于控制路由的发布和接收。

¡     PMSI Tunnel attribute，用于传递隧道信息。其中，Tunnel Type字段取值为mLDP P2MP隧道；Tunnel Identifier取值为组播源侧PE为mLDP P2MP隧道分配的隧道信息。

(36)     接收者侧PE收到组播源侧PE发送的1类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接受此路由并向组播源侧PE发送Label mapping消息。

(37)     接收者侧PE创建以组播源侧PE为根、接收者侧PE为叶的LSP。

(38)     当有多个接收者侧PE时，可按照相同的方法创建多条LSP，从而形成以组播源侧PE为根、所有接收者侧PE为叶的mLDP P2MP LSP。mLDP P2MP LSP的具体建立过程参见“3.4.2  mLDP P2MP隧道创建过程”。

图30 相容性隧道的创建过程

 

至此，MVPN中组播源侧PE到各个接收者侧PE之间的mLDP P2MP相容性隧道创建完成，如图22所示。

图31 在公网中创建相容性隧道

 

3.4.4  选择性隧道切换

选择性隧道切换的过程如下：

(39)     组播源侧PE收到满足隧道切换条件的私网组播报文后，向接收者侧PE发送携带PMSI Tunnel attribute的S-PMSI A-D route，不要求接收者侧PE回应加入信息。

(40)     接收者侧PE收到组播源侧PE发送的S-PMSI A-D route后，记录该路由。若存在下游接收者，接收者侧PE根据S-PMSI A-D route中携带的PMSI Tunnel attribute，创建以组播源侧PE为根、接收者侧PE为叶的LSP。若不存在下游接收者，则接收者侧PE不创建对应的隧道。

(41)     当存在下游接收者的接收者侧PE有多个时，可按照相同的方法创建LSP，从而形成以组播源侧PE为根、所有存在接收者的接收者侧PE为叶的mLDP P2MP LSP。mLDP P2MP LSP的具体建立过程参见“3.4.2  mLDP P2MP隧道创建过程”。

图32 选择性隧道切换过程

 

至此，MVPN中组播源侧PE到接收者侧PE之间的mLDP P2MP选择性隧道创建完成，如图33所示。

图33 创建选择性隧道并进行隧道切换

 

3.4.5  跨AS的mLDP模式MVPN

1. A类跨AS的mLDP模式MVPN

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

图34 A类跨AS的mLDP模式MVPN示意图

 

采用本方式时，需在每个AS内各建立一个独立的MVPN，在各MVPN之间实现私网组播数据跨AS的传输。跨AS传输私网组播数据的过程如下：

(42)     由于PE 3与PE 4互把对方视为自己的CE，因此：在AS 100中，CE 1与PE 4（相当于PE 3的CE）之间可以互通组播业务；在AS 200中，CE 2与PE 3（相当于PE 4的CE）之间也可以互通组播业务。

(43)     CE 1发出VPN 1的私网组播协议和数据报文在PE 1上经过MPLS封装后通过mLDP Tunnel1到达PE 3，PE 3解封装后通过普通三层组播转发到达PE 4，该报文被PE 4视为与自己私网接口相连的VPN 2的私网报文，于是将其通过mLDP Tunnel2转发给CE 2；CE 2发出的VPN 2的报文也采用相同的方法到达CE 1。这样，就实现了私网组播数据在CE 1与CE 2之间的互通。

 

2. B类跨AS的mLDP模式MVPN

如图35所示，VPN跨越了AS 100和AS 200两个自治系统，PE 3和PE 4分别是AS 100和AS 200的ASBR，PE 3和PE 4通过MP-EBGP相连。在此组网中，ASBR之间通过MP-EBGP交换它们从各自AS内的PE上接收的VPN-IPv4路由。

图35 B类跨AS的mLDP模式MVPN示意图

 

采用本方式时，只需在所有AS内统一建立一个MVPN即可，在该MVPN内部实现私网组播数据跨AS的传输。隧道建立和流量转发过程如下：

(44)     CE 1收到组播流量后，如果域内RP为PE 1，则发送注册报文到PE 1；如果RP为CE 1或者CE 2，则需要通过MSDP或者Anycast-RP将组播源信息发送到PE 1。无论采用哪种方式，当PE 1发现组播源信息后，都会发送Source Active A-D route通告组播源，该路由可以直接通过BGP传递到PE 3、PE 4和PE 2。

(45)     PE 2收到Source Active A-D route后，检查本AS域内是否存在组播接收者信息。如果存在接收者，向上游发送C-Multicast Route加入，该路由可以直接通过BGP传递到PE 4、PE 3和PE 1。

(46)     PE 1收到C-Multicast Route后，将组播流量封装MPLS标签后通过mLDP隧道发送到PE 2，在PE 2上进行解封装后转发到私网侧。

3. C类跨AS的mLDP模式MVPN

如图36所示，VPN跨越了AS 100和AS 200两个自治系统，PE 3和PE 4分别是AS 100和AS 200的ASBR。PE 3和PE 4通过MP-EBGP相连，并互把对方视为P设备。在此组网中，不同AS的PE之间建立多跳MP-EBGP会话，并通过该会话直接在PE之间发布VPN-IPv4路由。

图36 C类跨AS的mLDP模式MVPN示意图

 

采用本方式时，只需在所有AS内统一建立一个MVPN即可，在该MVPN内实现私网组播数据跨AS的传输。跨AS传输私网组播数据的过程如下：

(47)     CE 1收到组播流量后，如果域内RP为PE 1，则发送注册报文到PE 1；如果RP为CE 1或者CE 2，需要通过MSDP或者Anycast-RP将组播源信息发送到PE 1。不管哪种方式，当PE 1发现组播源信息后，都会发送Source Active A-D route通告组播源，该路由可以通过BGP直接发送给PE 2。

(48)     PE 2上收到Source Active A-D route后，检查本AS域内是否存在组播接收者信息，如果存在接收者，向上游发送C-Multicast Route加入，该路由可以通过BGP直接传递到PE 1。

(49)     PE 1收到C-Multicast Route后，将组播流量封装MPLS标签后通过mLDP隧道中发送到PE 2，在PE 2上进行解封装后转发到私网侧。

4  典型组网应用

4.1.1  单AS内MVPN

在单自治域BGP/MPLS VPN网络中使用MVPN方案部署组播业务，可以实现同一个AS域内不同VPN的组播业务的隔离。如图37所示，组播源S 1、接收者R 1、R 2和R 3属于VPN a；组播源S 2、接收者R 4属于VPN b；骨干网属于同一个AS域。通过MVPN方案，可以实现VPN a和VPN b组播业务隔离，即R 1、R 2和R 3只能接收S 1发送的组播流量；R 4只能接收S 2发送的组播流量。

图37 单AS内MVPN组网图

 

4.1.2  跨AS的MVPN

在跨域BGP/MPLS VPN网络中使用MVPN方案部署组播业务，可以实现跨越不同AS域的不同VPN之间组播业务的隔离。如图38所示，组播源S 1和接收者R 2属于VPN a；组播源S 2和接收者R 1属于VPN b；骨干网跨越AS 100和AS 200。通过部署跨域MVPN方案，可以实现VPN a和VPN b组播业务隔离，即R 2只能接收S 1发送的组播流量；R 1只能接收S 2发送的组播流量。

图38 跨AS的MVPN组网图

 

5  参考文献

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

·     RFC 6513：Multicast in MPLS/BGP IP VPNs

·     RFC 6514：BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs