组播VPN技术白皮书-6W101

手册下载

组播VPN技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2021 新华三技术有限公司 版权所有,保留一切权利。

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

除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。

本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。



概述

1.1  产生背景

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

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

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

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

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

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

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

1.2  技术优势

Comware利用MVPNMulticast Virtual Private Network,组播VPN方案来实现BGP/MPLS VPN网络内开展组播业务。MVPN方案支持MDTRSVP-TEmLDP三种模式。其中,RSVP-TE模式和mLDP模式属于NG MVPNNext Generation MVPN,下一代组播VPN)。

MVPN方案具有如下特点:

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

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

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

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

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

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

MDT模式MVPN

2.1  基本概念

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

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

·     MDTMulticast Distribution Tree,组播分发树):建立在属于同一VPN内所有PE间的组播分发树,包括Default-MDTData-MDT两种。

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

·     MTIMulticast Tunnel Interface,组播隧道接口):MTIMT的入/出口,相当于MVPN的入/出口,PE通过MTI连接到MT上,MTI在创建VPN实例的MVPN时自动创建。本地PE将私网数据从入口(MTI)投入MVPNMVPN自动将私网数据复制并传输到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-MDTDefault-Multicast Distribution Tree,默认组播分发树):以Default-Group为组地址的MDT,称为Default-MDTMVPN使用Default-Group唯一标识一棵Default-MDT。在该MVPN中传输的所有私网组播报文,无论从哪个PE进入公网,都经由此Default-MDT转发。不论公网或私网中有没有实际的组播业务,Default-MDT在公网中会一直存在。

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

·     Data-MDTData-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的所有PEPE收到组播报文后,如果其下游有该组播组的接收者,则继续向CE转发;否则将其丢弃。

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

说明

为了描述方便,我们将骨干网的属性用“P-”来表示,将MVPN实例的属性用“C-”来表示。譬如,本文中将VPN中的组播协议报文称为C-Control-Packet、组播数据报文称为C-Data-Packet,二者统称C-Packet;而骨干网中的组播协议报文则称为P-Control-Packet、组播数据报文称为P-Data-Packet,二者统称P-Packet

 

图1 MDT模式MVPN方案示意图

 

1所示,三个PE属于同一MVPN,各PE之间已建立MTC-Packet在源PE(如PE 1)处被封装在P-Packet中,并通过MT到达另一SitePE

·     如果某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上包含以下三种接口类型:

·     PNIProvider Network Interface,公网接口):是指PE上连接P设备的接口。PNI收发的报文使用公网路由转发表进行路由转发。

·     CNICustomer Network Interface,私网接口):是指PE上连接CE设备的接口。CNI收发的报文使用该接口所属VPN实例的组播路由转发表进行路由转发。

·     MTI:是PE上的虚拟接口,完成Default-MDTPIM配置,并建立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则用于在PECE之间建立PIM邻居关系以及在各PE之间通过MT建立PIM邻居关系,前者用以创建VPN实例自有的组播路由转发表和发现本VPN内的RP信息,后者用以发现RPF邻居和检测对端PEPIM能力。

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 2PNI接口Interface ARPF邻居为P

图3 公网侧的RPF检查

 

2.5.2  私网侧的RPF检查

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

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

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

 

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

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

 

2.6  Default-MDT

2.6.1  Default-MDT的建立

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

说明

·     Default-MDT的组播源地址必须是PE用来与其它PE建立IBGP连接的接口IP地址,否则会导致RPF检查失败。

·     Default-MDT的组播组地址是预先规划好的(即Default-Group),由管理员在每个PE上进行配置。属于同一MVPN的所有PE上所配置的组地址必须相同,而属于不同MVPNPE上所配置的组地址则必须不同。

 

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

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

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

 

6所示,公网中运行PIM-DMPE 1PE 2PE 3都支持VPN实例ADefault-MDT的创建过程如下:

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

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

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

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

图7 Default-MDT的建立过程

 

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

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

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

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

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

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

 

8所示,公网中运行双向PIM,且PE 1PE 2PE 3都支持VPN实例ADefault-MDT的创建过程如下:

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

(3)     PE 1Default-Group为组播组地址发送组播数据,在公网途径的每个网段都被该网段的DF无条件向RP转发,并在沿途各设备上分别创建(*239.1.1.1)表项。与此同时,PE 2PE 3也各自发起类似的创建过程,最终在MVPN中形成三棵分别以PE 1PE 2PE 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 1PE 2PE 3都支持VPN实例ADefault-MDT的创建过程为:PE 1PE 2PE 3两两之间先通过BGP互换各自的MDT路由信息(包含BGP接口地址和Default-Group地址等信息),然后分别向对方的BGP接口地址逐跳发送订阅报文(Subscribe Message),在公网沿途各设备上分别创建(SG)表项,从而形成一棵以本PE为根、其它PE为叶的SPT。最终在MVPN中形成三棵相互独立的SPT

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

说明

·     PIM-SSM中,借助“订阅报文”的概念表示加入报文。

·     PIM-SSM中,PE间需要通过BGP MDT路由交互PE地址及PE所在的Default-Group等信息,以便在公网上建立以PE为根的Default-MDT

 

2.6.2  Default-MDT的数据转发

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

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

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

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

 

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

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

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

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

 

11所示,VPN内部使用PIM-SMCE 1为该VPN内的RPCE 1连接组播源SCE 2连接组播组G的接收者。CE 2RPCE 1)发送PIM加入消息,PE 2将其封装成公网报文并沿Default-MDT发送给MVPN内的所有PEPE 3解封装后发现RP不在PE 3CE 3上,将其丢弃;PE 1解封装后发现RP在本侧CE 1上,于是将还原后的PIM加入消息向CE 1转发,同时将MTunnel0加入到(*G)表项的出接口列表中。CE 1收到PIM加入消息后,将组播数据(SG)转发给PE 1PE 1将其封装成P-Packet并沿Default-MDT发送给MVPN内的所有PEPE 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

说明

Data-MDT所使用的组地址Data-Group也是预先配置的。一个Default-Group唯一确定一个Data-Group范围以备进行Data-MDT切换在进行Data-MDT切换时,从Data-Group范围中选取一个被引用最少的地址作为Data-Group

 

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。此后,如果这些PEData-Timeout时间内都没有收到新的Data-MDT切换消息,则删除为Data-MDT创建的组播转发表项。

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

2.7.3  Data-DelayData-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切换的具体过程如下:

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

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

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

2.8  ASMDT模式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类跨ASMDT模式MVPN

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

图13 A类跨ASMDT模式MVPN示意图

 

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

(1)     由于PE 3PE 4互把对方视为自己的CE,因此:在AS 1中,CE 1PE 4(相当于PE 3CE)之间可以互通组播业务;在AS 2中,CE 2PE 3(相当于PE 4CE)之间也可以互通组播业务。

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

2.8.2  B类跨ASMDT模式MVPN

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

图14 B类跨ASMDT模式MVPN

 

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

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

提示

B类跨ASMDT模式MVPN组网中,公网只支持PIM-SSM模式。

 

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

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

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 1PE 2SPT

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

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

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

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

2.8.3  C类跨ASMDT模式MVPN

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

图15 C类跨ASMDT模式MVPN

 

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

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

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

NG MVPN

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

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

3.1  NG MVPN基本概念

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

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

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

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

3.2  MP-BGP路由扩展

3.2.1  BGP MVPN邻居建立

为了支持NG MVPNMP-BGP新增BGP MVPN地址族,该地址族用于协商和建立BGP MVPN邻居,并传递私网组播路由信息。对于BGP IPv4 MVPNBGP IPv6 MVPNAFIAddress Family Identifier,地址族标识符)分别为12SAFISubsequent Address Family Identifier,子地址族标识符)均为5

NG MVPN组网中,PE之间既可以建立IBGP邻居,也可以建立EBGP邻居:

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

·     建立EBGP邻居时,不需要部署RRBGP自动将从EBGP邻居收到的MVPN路由发送给其他EBGPIBGP邻居。

3.2.2  BGP MVPN路由

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

MVPN NLRI的格式如16所示。

图16 MVPN NLRI格式

 

MVPN NLRI各字段的含义如下:

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

·     LengthMVPN NLRIRoute Type specific字段的长度。

·     Route Type specificMVPN路由信息。不同类型的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收到自用户侧的SG加入请求时,会将SG加入消息转换成Source Tree Join route,并将该路由穿越公网发送给组播源侧PE

 

说明

15类称为MVPN A-D路由,主要作用是进行MVPN成员的自动发现和协助MPLS进行P2MP隧道的建立。67类称为C-multicast路由(C表示Customer,即来自于私网的组播路由),主要作用是发起私网用户加入和指导私网组播数据流量传递。目前,暂不支持6类路由。

 

3.2.3  BGP MVPN路由属性

1. PMSI Tunnel attribute

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

PMSI Tunnel attribute主要用于公网隧道的创建,目前携带在Intra-AS I-PMSI A-D routeS-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 LabelMPLS标签值,用于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 IDBGP VPN-IPv4路由所属的VPN实例信息,格式为32Router ID:VPN实例索引。组播源侧PE发布给接收者侧PEVPN-IPv4路由中包含此属性,接收者侧PE向组播源侧PE回应C-multicast route时会将此属性携带在路由中。组播源侧PE在收到接收者侧PE发送的Shared Tree Join routeSource 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协议在PathResv消息中新增如下对象:

·     P2MP SESSION对象

PathResv消息均可以携带该对象。

对象用来唯一标识一条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 LSPP2MP SESSION对象以及P2MP SENDER_TEMPLATE对象中的LSP ID字段来唯一确定。

·     S2L_SUB_LSP对象

PathResv消息均可以携带该对象。

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

·     P2MP_SENDER_TEMPLATE对象

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

RSVP P2MP协议P2P SENDER_TEMPLATE基础上增加Sub-Group Originator IDSub-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 IDSub-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的过程为:

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

(2)     Ingress LSRS2L_SUB_LSP对象中携带该Egress叶子节点地址建立CRLSP

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

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

(3)     选择下一个叶子节点,重复步骤(2)。

(4)     Ingress LSR成功为所有的叶子节点创建Sub-LSPRSVP-TE P2MP LSP建立成功。

说明

在使用RSVP-TE建立P2MP LSP之前,需要先通过MVPN路由获取LSP的多个目的地址。详细的获取过程请参见“3.3.2  创建相容性隧道”和“3.3.3  选择性隧道切换”。

 

3. RSVP-TE P2MP报文转发

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

图20 RSVP P2MP转发示意图

 

3.3.2  创建相容性隧道

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

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

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

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

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

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

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

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

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

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

 

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

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

http://press/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/09-IP%E7%BB%84%E6%92%AD/09-%E7%BB%84%E6%92%ADVPN/%E7%BB%84%E6%92%ADVPN%E9%85%8D%E7%BD%AE.files/20210118_5515316_x_Img_x_png_14_1376282_30005_0.png

 

3.3.3  选择性隧道切换

1. 选择性隧道切换过程

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

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

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

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

(2)     接收者侧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

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

(4)     当存在下游接收者的接收者侧PE有多个时,可按照相同的方法创建多条Sub-LSP,从而形成以组播源侧PE为源端、所有存在接收者的接收者侧PE为目的端的RSVP-TE P2MP LSPRSVP-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 3PE 4PE 5)的“树形”隧道,组播流量在入口节点引入到该隧道中进行转发。当网络中的某些设备(即Receiver)需要接收组播报文时,组播源(即Source)仅需发送一份报文到入口节点,在分支节点(PE 2P 3)上进行报文的复制,从而保证不会重复占用带宽。

图25 mLDP P2MP组网示意图

http://press.h3c.com/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/10-MPLS/03-LDP/LDP%E9%85%8D%E7%BD%AE.files/20210118_5515329_x_Img_x_png_26_1376282_30005_0.png

 

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

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

·     Transit:中间节点,负责交换标签。

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

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

·     BudBud节点。既作为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主要包含以下几部分:

¡     TypemLDP建立的树形LSP类型,目前仅支持P2MP

¡     Address family:根节点地址类型。目前仅支持IPv4IPv6

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

¡     Root node address:根节点地址。

¡     Opaque lengthOpaque value的长度。

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

图27 P2MP FEC Element格式示意图

http://press.h3c.com/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/10-MPLS/03-LDP/LDP%E9%85%8D%E7%BD%AE.files/20210118_5515330_x_Img_x_png_27_1376282_30005_0.png

 

3. mLDP P2MP隧道建立

(4)28所示,本地和远端对等体成功协mLDP能力后,建立mLDP P2MP隧道的过程为:

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

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

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

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

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

http://press.h3c.com/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/10-MPLS/03-LDP/LDP%E9%85%8D%E7%BD%AE.files/20210118_5515331_x_Img_x_png_28_1376282_30005_0.png

 

4. mLDP P2MP报文转发

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

图29 mLDP P2MP转发示意图

 

3.4.3  创建相容性隧道

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

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

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

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

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

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

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

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

 

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

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

http://press/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/09-IP%E7%BB%84%E6%92%AD/09-%E7%BB%84%E6%92%ADVPN/%E7%BB%84%E6%92%ADVPN%E9%85%8D%E7%BD%AE.files/20210118_5515316_x_Img_x_png_14_1376282_30005_0.png

 

3.4.4  选择性隧道切换

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

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

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

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

图32 选择性隧道切换过程

 

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

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

 

3.4.5  ASmLDP模式MVPN

1. A类跨ASmLDP模式MVPN

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

图34 A类跨ASmLDP模式MVPN示意图

 

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

(1)     由于PE 3PE 4互把对方视为自己的CE,因此:在AS 100中,CE 1PE 4(相当于PE 3CE)之间可以互通组播业务;在AS 200中,CE 2PE 3(相当于PE 4CE)之间也可以互通组播业务。

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

说明

A类跨域无法在域间互相通告激活组播源的自动发现路由(Source Active A-D route),所以必须在RP间配置MSDPanycast-RP以实现域间组播源信息的传递

 

2. B类跨ASmLDP模式MVPN

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

图35 B类跨ASmLDP模式MVPN示意图

 

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

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

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

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

3. C类跨ASmLDP模式MVPN

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

图36 C类跨ASmLDP模式MVPN示意图

http://press/data/infoblade/Comware%20V7%E5%B9%B3%E5%8F%B0B75%E5%88%86%E6%94%AF%E4%B8%AD%E6%96%87/09-IP%E7%BB%84%E6%92%AD/09-%E7%BB%84%E6%92%ADVPN/%E7%BB%84%E6%92%ADVPN%E9%85%8D%E7%BD%AE.files/20210118_5515324_x_Img_x_png_21_1376282_30005_0.png

 

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

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

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

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

典型组网应用

4.1.1  ASMVPN

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

图37 ASMVPN组网图

 

4.1.2  ASMVPN

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

图38 ASMVPN组网图

 

参考文献

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

·     RFC 6513Multicast in MPLS/BGP IP VPNs

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

联系我们