目 录
组播VPN是基于MPLS L3VPN网络来实现组播传输的技术。MPLS L3VPN是一种基于BGP(Border Gateway Protocol,边界网关协议)和MPLS(Multiprotocol Label Switching,多协议标签交换)扩展技术实现的VPN(Virtual Private Network,虚拟专用网),由运营商的骨干网和用户的各个Site(站点)组成,各Site之间彼此相互孤立,只有借助骨干网才能实现互通。VPN可以看作是一组策略,控制着各Site之间的连接。
图1 MPLS L3VPN典型应用
如图1所示,由Site 1、Site 3和Site 5组成VPN A网络,由Site 2、Site 4和Site 6组成VPN B网络,其中包括以下三种类型的设备:
l P(Provider):骨干网核心设备,不与CE直接相连,负责MPLS转发。
l PE(Provider Edge):骨干网边缘设备,与CE直接相连,负责VPN路由的处理,是MPLS L3VPN的主要实现者。
l CE(Customer Edge):用户网边缘设备,可以是路由器或交换机,也可以是一台主机,负责用户网络路由的发布。
l 在MPLS L3VPN中,属于同一VPN的两个Site之间使用两层标签来穿越公网传输报文。公网入口PE为报文打上内外两层标签:
l 外层标签:用于在骨干网内部进行交换,代表从本端PE到对端PE的一条LSP(Label Switched Path,标签交换路径)。借助这层标签,报文可以沿着LSP到达对端PE。
l 内层标签:代表通过骨干网相连的两个CE之间的一条LSP。主要标识报文属于哪个Site,PE根据内层标签将报文转发到相应的CE。
如图2所示,网络中同时承载着三个相互独立的组播业务:公网实例、VPN实例A和VPN实例B。公共网络边缘的PE组播设备支持多实例,相当于多台独立运行的组播设备。各实例之间形成彼此隔离的平面,每个实例对应一个平面。
举例来说,图1中的PE 1上运行着三个实例:公网实例、VPN实例A和VPN实例B,可以把这三个不同的实例想象成三台独立运行的虚拟设备,分别是PE 1’、PE 1”和PE 1’”,每台虚拟设备则分别对应着一个平面,对应关系如图2所示。
图2 VPN中基于多实例的组播
以VPN实例A为例,组播VPN是指:当VPN A中的组播源向某组播组发送组播数据时,在网络中所有可能的接收者中,只有属于VPN A(即Site 1、Site 3或Site 5中)的组播组成员才能收到该组播源发来的组播数据。组播数据在各Site以及公网中均以组播方式进行传输。
由此分析,实现组播VPN所需具备的网络条件如下:
(1) 在每个Site内支持基于VPN实例的组播。
(2) 在公共网络内支持基于公网实例的组播。
(3) PE设备支持多实例组播:
l 通过VPN实例连接Site,支持基于VPN实例的组播;
l 通过公网实例连接公共网络,支持基于公网实例的组播;
l 支持公网实例与VPN实例之间的信息交流和数据转换。
Comware利用MD(Multicast Domain,组播域)方案来实现组播VPN,简称为MD VPN。
MD方案最大的优点是仅需要PE设备支持多实例,而无需升级CE和P设备,并且无需修改CE和P设备上原有的PIM配置。也就是说,MD方案对于CE和P是透明的。
MD VPN中所涉及到的基本概念如表1所示。
表1 MD VPN中的基本概念
概念 | 全称及中文解释 | 说明 |
MD | Multicast Domain,组播域 | 由一组相互连通的MVRF所组成的集合称为MD。每个MD都唯一对应着一个具备组播能力的VPN,连接该VPN的所有PE都属于这个MD |
MDT | Multicast Distribution Tree,组播分发树 | 是建立在属于同一VPN所有PE之间的组播分发树,包括Share-MDT和Switch-MDT |
MT | Multicast Tunnel,组播隧道 | 在MD内将各MVRF连接到一起的通道称为MT,用来传输MD内部的私网数据 |
MTI | Multicast Tunnel Interface,组播隧道接口 | MTI是MT的入/出口,相当于MD的入/出口,它只收发组播报文,而不收发单播报文。MTI在VPN实例配置了Share-Group并绑定MTI后自动创建。MVRF通过MTI访问MD,在MVRF看来,MTI就像一个LAN接口,而MD就像一个LAN网络,所有PE都连接在这个LAN网络里 |
MVRF | Multicast VPN Routing and Forwarding,组播VPN路由转发 | 使能了三层组播的VPN实例同时维护单播和组播的路由转发表,我们称之为MVRF。不同PE上的MVRF加入到同一个MD中,并通过MD内自动建立的MT连接起来,实现了不同Site间组播业务的互通,从而形成了一个组播VPN网络 |
Share-Group | 共享组 | 每个MD在公网上分配一个独立的组播地址,称为Share-Group。它是MD在公网上的唯一标志,用来在公网上建立MD所对应的Share-MDT |
Share-MDT | Share-Multicast Distribution Tree,共享组播分发树 | 以Share-Group为组地址的MDT,称为Share-MDT。VPN使用Share-Group唯一标识一棵Share-MDT。Share-MDT是在配置完成后自动生成的,在公网中将会一直存在,而不论公网或私网中有没有实际的组播业务 |
Switch-MDT | Switch-Multicast Distribution Tree,切换组播分发树 | 以Switch-Group为组地址的MDT,称为Switch-MDT。下游存在接收者的PE加入Switch-Group,形成一棵Switch-MDT,入口PE使用Switch-MDT在公网中转发封装后的私网组播数据 |
Switch-Group | 切换组 | 当某私网组播数据的流量达到或超过阈值时,入口PE会为其分配一个独立的组播地址,称为Switch-Group,并通知其它PE使用该地址在公网内转发该组播数据流量,从而实现Switch-MDT切换 |
Switch-Group-Pool | 切换组地址池 | 在进行Switch-MDT切换时,从Switch-Group-Pool中选取一个地址(即Switch-Group),从PE进入公网的私网组播报文将使用该地址进行封装。不同VPN的Switch-Group-Pool不能重叠,某VPN的Switch-Group-Pool中也不能含有其它VPN的Share-Group |
VRF | VPN Routing and Forwarding,VPN路由转发 | VPN实例独立维护的单播路由转发表 |
MD VPN实现机制的要点列举如下:
(1) 运营商构建的公共网络支持组播功能。PE同时支持公网实例和多个VPN实例,每个实例各自运行相互间独立的PIM。PE与CE之间通过VPN实例进行私网组播传输;PE与P之间则通过公网实例进行公网组播传输。
(2) MD在逻辑上表示某一特定VPN的私网组播数据在公网中的传播范围,在实际中则标识了网络中支持该VPN实例的所有PE设备。不同的VPN实例对应不同的MD。如图2所示,其中每个VPN实例平面的中央椭圆区域表示一个MD,服务于某个特定的VPN,在该VPN中传输的所有私网组播数据,都在此MD内传输。
(3) 在MD内部,私网数据通过MT进行传输。MT传输过程为:本地PE将私网组播报文封装成公网组播数据报文,并在公网内进行组播转发,远端PE收到该报文后通过解封装将其还原成私网报文。
(4) 本地PE将私网数据通过MTI发出,而远端PE则从MTI接收私网数据。如图3所示,可以将MD比作一个私网数据的传输池,MTI则是MD的入/出口。本地PE将私网数据从入口(MTI)投入传输池,传输池自动将私网数据复制并传输到MD的所有出口(MTI),任何有需求的远端PE都可以从各自的出口(MTI)“打捞”私网数据。
图3 公网实例PIM与VPN实例MD对应关系示意图
(5) 一个VPN实例唯一指定一个Share-Group地址。私网数据信息对于公网来说是透明的,不论私网组播报文属于哪个组播组、是协议报文还是数据报文,PE都统一将其封装为普通的公网组播数据报文,并以Share-Group作为其所属的公网组播组。之后,PE将封装好的公网组播数据报文发送到公网中。
(6) 一个Share-Group唯一对应一个MD,并利用公网资源唯一创建一棵Share-MDT以进行数据转发。在该VPN中传输的所有私网组播报文,无论从哪个PE进入公网,都经由此Share-MDT转发。
(7) 一个Share-Group唯一确定一个Switch-Group-Pool以备进行Switch-MDT切换。在进行Switch-MDT切换时,从Switch-Group-Pool中选取一个空闲的地址(即Switch-Group),从PE进入公网的、流量达到或超过切换阈值的私网组播报文将使用该地址进行封装。
(8) 网络中所有PE都在监测Share-MDT的转发速率。当从某PE进入公网的数据转发速率超过一定阈值时,该PE将作为源端沿Share-MDT向其下游发出切换消息,使用Switch-Group在该PE和有接收需求的远端PE之间新建一棵Switch-MDT。之后,进行Switch-MDT切换:即所有从该PE进入公网的私网组播数据流,不再使用Share-Group地址进行封装,而是被封装成公网的Switch-Group组播报文,从Share-MDT切换到新创建的Switch-MDT上。
& 说明:
VPN、MD、MTI、Share-Group与Switch-Group-Pool两两之间分别一一对应。
图4 MD VPN中的PIM邻居关系示意图
PIM邻居关系建立在直接相连且属于同一网段的两台或多台设备之间。如图4所示,在MD VPN中存在如下三种PIM邻居关系:
l PE-P邻居关系:指PE上公网实例接口与链路对端P上的接口之间所建立的PIM邻居关系。
l PE-PE邻居关系:指PE上的VPN实例通过MTI收到远端PE上的VPN实例发来的PIM Hello报文后所建立的邻居关系。
l PE-CE邻居关系:指PE上绑定VPN实例的接口与链路对端CE上的接口之间所建立的PIM邻居关系。
本节介绍MD VPN技术的实现原理,包括组播分发树的构建和工作过程,以及跨AS的实现方式。
对于VPN实例来说,公网传输是透明的,私网数据的传输在PE上的MTI处完成了无缝连接:VPN实例只知道将私网数据从MTI发出,然后远端就能从MTI接收。其实中间经历了复杂的公网传输过程,即MDT传输过程。
以Share-Group为组地址的MDT,称为Share-MDT。公网中运行的组播路由协议可以是PIM-DM、PIM-SM或PIM-SSM中的一种。在这三种情况下,创建Share-MDT的过程是有区别的。
图5 在PIM-DM网络中创建Share-MDT
如图5所示,公网中运行PIM-DM,且PE 1、PE 2和PE 3都支持VPN实例A。Share-MDT的创建过程如下:PE 1的公网实例以BGP接口地址(即建立BGP对等体时所使用的接口地址)为组播源地址、Share-Group地址为组播组地址、其它支持VPN实例A的PE为组播组成员,在整个公网范围内发起扩散—剪枝过程,在公网沿途的各设备上分别创建(11.1.1.1,239.1.1.1)表项,从而形成一棵以PE 1为根、PE 2和PE 3为叶的SPT。
同时,PE 2和PE 3也各自发起类似的扩散—剪枝过程,最终在MD中形成三棵相互独立的SPT。在PIM-DM网络中,由这三棵相互独立的SPT共同组成了一棵Share-MDT。
图6 在PIM-SM网络中创建Share-MDT
如图6所示,公网中运行PIM-SM,且PE 1、PE 2和PE 3都支持VPN实例A。Share-MDT的创建过程如下:
(1) PE 1的公网实例向公网RP发起加入(Join),以Share-Group地址为组播组地址,在公网沿途的各设备上分别创建(*,239.1.1.1)表项。同时,PE 2和PE 3也各自发起类似的加入过程,最终在MD中形成一棵以公网RP为根,PE 1、PE 2和PE 3为叶的RPT。
(2) PE 1的公网实例向公网RP发起注册(Register),以BGP接口地址为组播源地址、Share-Group地址为组播组地址,在公网沿途的各设备上分别创建(11.1.1.1,239.1.1.1)表项。同时,PE 2和PE 3也各自发起类似的注册过程,最终在MD中形成三棵相互独立的、连接PE与RP的SPT。
在PIM-SM网络中,由RPT(*,239.1.1.1)和这三棵相互独立的SPT共同组成了一棵Share-MDT。
图7 在PIM-SSM网络中创建Share-MDT
如图7所示,公网中运行PIM-SSM,且PE 1、PE 2和PE 3都支持VPN实例A。Share-MDT的创建过程如下:PE 1的公网实例分别向PE 2和PE 3的公网实例通知其本地的BGP MDT信息(包含BGP接口地址和Share-Group地址等信息),并互换BGP MDT路由信息;PE 2和PE 3收到来自PE 1的BGP MDT信息后,分别向PE 1的BGP接口地址逐跳发送订阅报文,在公网沿途的各设备上分别创建(11.1.1.1,232.1.1.1)表项,从而形成一棵以PE 1为根、PE 2和PE 3为叶的SPT。
同时,分别以PE 2和PE 3为根的SPT形成过程与此类似,最终在MD中形成三棵相互独立的SPT。在PIM-SSM网络中,由这三棵相互独立的SPT共同组成了一棵Share-MDT。
综前,无论公网中运行的是PIM-DM、PIM-SM还是PIM-SSM,Share-MDT都具有以下特点:
l 网络中所有支持VPN实例A的PE都加入该Share-MDT。
l 所有属于VPN A的私网组播报文(包括协议报文和数据报文)在进入公网后,均沿该Share-MDT向各PE转发,无论PE所连接的Site中是否存在接收者。
Share-MDT构建完成后,就可以进行组播报文的传输。其中,组播协议报文和组播数据报文的传输过程是不同的,下面分别进行介绍。
当私网组播接收者和组播源位于VPN网络中的不同Site时,组播协议报文必须跨越公网进行传输。协议报文在本地PE上被封装为普通的公网组播数据并沿Share-MDT进行传输,在远端PE上被解封装,从而继续进行正常的协议交互过程,最终建立一棵跨越公网的组播分发树。
(1) 当VPN网络中运行PIM-DM或PIM-SSM时,需要跨越公网创建SPT。
(2) 当VPN网络中运行PIM-SM时:
l 如果接收者与私网RP属于不同的Site,需要跨越公网发起加入以创建RPT。
l 如果组播源与私网RP属于不同的Site,需要跨越公网发起注册以创建SPT。
& 说明:
下面以公网和VPN网络中均运行PIM-SM、私网接收者跨越公网发起加入为例,介绍基于Share-MDT的组播协议报文的传输过程。
如图8所示,公网和VPN网络中分别运行PIM-SM,属于Site 2的私网组播组G(225.1.1.1)的接收者(Receiver)与CE 2相连;属于Site 1的CE 1作为G的RP;用于公网组播数据转发的Share-Group地址为239.1.1.1。
组播协议报文的交互过程如下:
(1) Receiver向CE 2发送IGMP报告以加入组播组G。CE 2在本地创建(*,225.1.1.1)表项,同时向私网RP(CE 1)发起加入。
(2) PE 2上的VPN实例收到CE 2发来的加入消息(Join Message)后,在本地创建(*,225.1.1.1)表项,并指定上游接口为MTI,然后PE 2将对该加入消息做进一步处理。这时,PE 2上的VPN实例将认为加入消息已从MTI发出。
(3) PE 2对加入消息以GRE(Generic Routing Encapsulation,通用路由封装)方式进行封装,以PE 2的BGP接口地址为组播源地址、Share-Group地址为组播组地址,转换成普通的公网组播数据报文(11.1.2.1,239.1.1.1),然后交由PE 2上的公网实例向公网进行转发。
(4) 组播数据报文(11.1.2.1,239.1.1.1)沿Share-MDT传输给各PE上的公网实例。各PE对其进行解封装,还原为发往私网RP的加入消息。然后,各PE分别检查该加入消息,如果发现私网RP在与其直连的Site中,则交由其上的VPN实例处理,否则丢弃该加入消息。
(5) PE 1上的VPN实例收到加入消息后,认为是从MTI获得的。在本地创建(*,225.1.1.1)表项,并指定下游接口为MTI、上游接口为朝向CE 1的接口。同时向私网RP发送加入消息。
(6) CE 1收到PE 1上的VPN实例发来的加入消息后,在本地更新或创建(*,225.1.1.1)表项。至此跨越公网的RPT创建完成。
当组播分发树创建完成后,私网组播数据沿组播分发树传输给各Site中的接收者。私网组播数据在本地PE上被封装为普通的公网组播数据并沿Share-MDT进行传输,在远端PE上被解封装,从而继续在私网内进行组播数据的传输。
(1) 当VPN网络中运行PIM-DM或PIM-SSM时,沿SPT跨越公网进行私网组播数据的传输。
(2) 当VPN网络中运行PIM-SM时(以下仅指RPT向SPT切换前的情形):
l 如果接收者与私网RP属于不同的Site,沿RPT跨越公网进行私网组播数据的传输。
l 如果组播源与私网RP属于不同的Site,沿SPT跨越公网进行私网组播数据的传输。
& 说明:
下面以公网和VPN网络中均运行PIM-DM、沿SPT跨越公网进行私网组播数据的传输为例,介绍基于Share-MDT的组播数据报文的传输过程。
如图9所示,公网和VPN网络中分别运行PIM-DM,属于Site 2的私网组播组G(225.1.1.1)的接收者(Receiver)与CE 2相连;属于Site 1的组播源(Source)向G发送组播数据;用于公网组播数据转发的Share-Group地址为239.1.1.1。
私网组播数据跨越公网进行传输的过程如下:
(1) Source发送私网组播数据(192.1.1.1,225.1.1.1)到CE 1。
(2) CE 1沿SPT将私网组播数据转发给PE 1,PE 1上的VPN实例查找转发表项。如果对应转发表项的出接口列表中包含MTI,则PE 1将对该私网组播数据做进一步处理。这时,PE 1上的VPN实例将认为私网组播数据已从MTI发出。
(3) PE 1对该私网组播数据以GRE方式进行封装,以PE 1的BGP接口地址为组播源地址、Share-Group地址为组播组地址,转换成普通的公网组播数据报文(11.1.1.1,239.1.1.1),然后交由PE 1上的公网实例向公网进行转发。
(4) 组播数据报文(11.1.1.1,239.1.1.1)沿Share-MDT传输给各PE上的公网实例。各PE对其进行解封装,还原为私网组播数据,然后交由相应的VPN实例处理。如果该PE上存在SPT的下游接口,则沿SPT转发该私网组播数据,否则将其丢弃。
(5) PE 2上的VPN实例查找转发表项,最终将私网组播数据送达Receiver。至此跨越公网的私网组播数据传输完成。
在公网中通过Share-MDT传送组播数据时,组播报文被传输到支持同一VPN实例的所有PE上,无论该PE所连接的Site内是否存在接收者。当私网中组播数据的传输速率比较大时,可能在公网中造成数据的泛滥。这样即浪费网络带宽,又增加了PE的处理负担。
为了解决上述问题,MD方案对此进行了优化:为进入公网的大流量私网组播数据,在连接有私网接收者和私网组播源的各PE之间,建立起专用的Switch-MDT。然后将该组播数据流从Share-MDT切换到Switch-MDT,从而实现按需进行组播。
从Share-MDT向Switch-MDT切换的过程如下:
(1) 源端PE(如PE 1)周期性地检测私网组播数据的转发速率。发起从Share-MDT向Switch-MDT的切换必须同时满足以下两点要求:
l 私网组播数据通过了由Share-MDT向Switch-MDT切换的ACL规则的过滤,否则仍沿Share-MDT转发;
l 私网组播数据的转发速率超过了切换阈值,且维持了一定的时间(即Switch-Delay),否则仍沿Share-MDT转发。
(2) PE 1从Switch-Group-Pool中分配一个空闲的Switch-Group地址,沿Share-MDT向所有下游PE发送切换消息。该消息中包括私网组播源地址、私网组播组地址和Switch-Group地址。
(3) 其它PE收到该消息后,检查自己是否连接有该私网组播数据的接收者:如果有,则加入以PE 1为根的Switch-MDT;如果没有,则将该消息缓存起来,等待有接收者时再加入Switch-MDT。
(4) 当PE 1发送切换消息一定时间后,PE 1停止使用Share-Group地址对私网组播数据进行封装,并改用Switch-Group地址进行封装,组播数据沿Switch-MDT向下分发。
(5) 当Share-MDT切换到Switch-MDT之后,PE 1会周期性地发送切换消息,以便后续有PE加入Switch-MDT。当某下游PE不再连接有接收者时,可以退出Switch-MDT。
& 说明:
Switch-MDT和Share-MDT都是同一个MD中的转发隧道。Share-MDT由Share-Group地址唯一确定;Switch-MDT则由Switch-Group地址唯一确定。每个Share-Group地址关联一组Switch-Group地址(即Switch-Group-Pool)。
当私网组播数据切换到Switch-MDT之后,由于情况变化而导致了不满足切换条件,PE 1就会把此私网组播数据从Switch-MDT反向切换回Share-MDT,反向切换的触发条件包括(满足其一即可):
l 私网组播数据转发速率低于指定切换阈值,且维持了一定的时间(即Switch-Holddown)。
l 当更改了Switch-Group-Pool后,用于私网组播数据封装的Switch-Group地址被排除在新地址池之外。
l 当控制私网组播数据由Share-MDT向Switch-MDT切换的ACL规则发生了变化,从而导致私网组播数据不能通过新ACL规则的过滤。
当整个VPN跨越多个AS(Autonomous System,自治系统)时,需要连通分布在不同AS内的各VPN节点。跨AS的MD VPN有以下两种实现方式:
如图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连接方式示意图
采用VRF-to-VRF方式时,需在每个AS内各建立一个独立的MD,在各MD之间实现私网组播数据跨AS的传输。
& 说明:
由于ASBR之间转发的只是私网组播数据,因此各AS内部运行的公网PIM模式可以不同,但属于同一VPN的所有接口(包括ASBR上绑定VPN实例的接口)上必须运行统一的PIM模式(PIM-DM、PIM-SM或PIM-SSM)。
如图11所示,VPN跨越了AS 1和AS 2两个自治系统,PE 3和PE 4分别是AS 1和AS 2的ASBR。PE 3和PE 4通过各自的公网实例相连,并互把对方视为P设备。
采用Multi-hop EBGP方式时,只需在所有AS内统一建立一个MD即可,在该MD内部实现公网组播数据跨AS的传输。