技术产生的背景：
VPN（Virtual Private Network）技术的广泛应用，用户对在VPN中运营组播业务的需求日益迫切。比如用户租用了一个BGP MPLS VPN的专线，这个用户需要用组播来开视频会议，那么就给运营商提出了新的需求，因为普通的BGP MPLS VPN只能承载IPV4单播的流量（把IPV4单播地址转换成VPNV4的地址）而不能承载组播的流量，所以就需要一种新的技术把用户的组播流量在公网上透传。

技术解决的难点：
1，普通的VPN之所以很难解决用户组播穿越的问题，主要原因在于如何让公网路由器知道用户在哪里有组播的需求，然而单纯靠公网IPV4单播是无法解决这样的问题的，所以我们不光要在私网上实现组播，而且要在公网上也有一种类似组播一样点到多点的解决方案，而组播VPN就是其中的一种解决方案，是利用公网的组播来承载私网的组播。
2，运营商希望在支持MVPN的同时尽量对网络有比较少的更改，也就是说只更新部分设备而不必更新全部设备就可以支持私网组播。而MVPN很好的解决了这个问题，MVPN只需要PE的支持，而不需要对CE或者P设备做更改。

MVPN的基本概念：
1，MD（Multicast Domain）：可以理解为单播中的VRF，不同的VPN拥有不同的MD。
2，MT（Multicast Tunnel）：可以理解为私网组播的隧道，刚才说过了MVPN是通过公网组播地址来承载私网组播地址的，所以就要对数据报来进行封装，MVPN默认的封装是采用GRE来进行封装，实现PE to PE的一个隧道。
3，MTI（ Multicast Tunnel Interface）：可以理解为私网组播到公网组播隧道的出入口。如图所示。
4，Share Group：因为私网的组播需要在MTI上封装成公网的组播，所以需要提供一个公网的地址来进行转换。得到公网地址以后会沿着MT出发创建Share-MDT（Share-Multicast Distribution Tree）指导数据转发。Share-MDT连接着支持该VPN实例的所有PE。

MVPN的工作流程：
1，Receiver通过IGMP协议通知CE1接收并转发组播组G的数据。CE1在本地创建（*，G）项，同时向私网RP（CE2）发起加入过程。
2，PE1上的VPN实例接收到CE1发送的Join消息，本地创建（*，G）项，指定上游接口为MTI。然后将Join消息交由路由器做进一步处理。这时，PE1上的VPN实例认为Join消息已从MTI发出。
3，PE1对Join消息进行GRE封装，以PE2的IBGP接口地址为组播源地址，Share-Group地址为组播组地址，转换成普通的公网组播数据报文（S，G）（如图紫色）。然后交由PE1上的公网实例向公网转发。
4，组播数据报文（S，G）沿Share-MDT传输到各PE上的公网实例。各PE对报文进行解封装，还原为发往私网RP的Join消息。然后，各PE检查该Join消息，如果发现私网RP（CE2）在其直连site中，则交由其上的VPN实例处理，否则丢弃该Join消息。
5，PE2上的VPN实例接收到Join消息，认为是从MTI获得的。本地创建（*，G）项，指定下游接口为MTI、上游接口为朝向CE2的接口。同时向私网RP发送Join消息。
6，CE2收到PE2上的VPN实例发送的Join消息，本地更新或创建（*，G）项，至此跨越VPN的组播共享树构建完成。

Share-MDT到Switch-MDT的切换条件：

Share-MDT到Switch-MDT的切换是需要有两个条件来驱动的：
1，私网组播数据报文经过高级ACL规则过滤结果为permit。否则沿Share-MDT转发。
2，私网组播数据报文的转发速率超过了切换阈值，且维持一定的时间。在某些情况下，私网组播数据的转发速率会在切换阈值上下振荡。为了避免组播数据流在Share-MDT与Switch-MDT之间频繁切换，当系统经过计算发现转发速率高于阈值后，并不立即执行切换，而是启动switch-delay定时器，超时时间为该命令的配置值。在switch-delay定时器超时前，系统将继续检测数据转发速率。如果速率始终低于切换阈值则切换至Switch-MDT，否则继续使用Share-MDT进行报文转发。

未来展望：
这个技术目前在现网的应用很少，据我所知只在俄罗斯有过一个实验局点，测试成功以后却被下马了。我个人认为主要原因是在于MVPN不能很智能的发现接收者，按照私网的流量需求来智能的驱动公网隧道的建立，MVPN最开始的实现方法是用Share-MDT把流量传递给所有PE然后让PE来选择是否接受流量，这样是对带宽极大的浪费。目前来看即将取代这个技术的是P2MP TE，P2MP TE可以由PIM直接驱动隧道的建立，是真正的按需传递，不需要首先把流量传给所有的PE。其次他还可以基于RSVP，来实现有带宽保障的私网组播。大家可以在ietf.org上参加相关的讨论组来获取最新的资料。