8 Replies Latest reply: Feb 13, 2018 8:34 AM by Juan RSS

    Multicast VPN: Architecture

    Juan


      There are two basic models for mVPN deployment: Classic mVPN and NG mVPN.


      The Classic mVPN version (PIM/GRE) is based on the Draft Rosen and requires PIM in the Core of the provider network to be able to support mVPN traffic. This requirement introduces new protocols (PIM) and encapsulation mechanisms (mGRE) in the control and data planes. As we will discuss here, this model has a poor scalability and flexibility.


      NG mVPN model (BGP/MPLS) uses the same protocols used in MPLS L3 VPN unicast service (RFC 2547, RFC 4364 BGP MPLS VPNs) but with some extensions to the control and data plane protocols as necessary to be able to support multicast traffic. This model retains the good scalability and flexibility of the unicast VPN service.



      mVPN Model

      Classic mVPN

      NG mVPN

      Service

      MPLS L3 VPN Multicast

      MPLS L3 VPN Unicast and Multicast

      Overlay, Signaling, Control Plane

      PIM

      BGP

      Underlay, Transport, Data Plane, Multicast Distribution Trees (MDT)

      PIM/GRE - mGRE tunneling

      MDTs per VRF in Global RT

      mLDP, P2MP TE, IR
      Bandwidth Res., TE and FRR

      Core tree types

      Default MDT, Data MDT

      Default MDT, Data MDT, Partitioned MDT



       

      Classic mVPN (PIM/GRE)

       

      Classic mVPN model is the original solution for transporting multicast data between customer sites over a SP multicast-enabled core. This model is based on the Virtual Router (VR) model, where each VR in the VPN domain is running an instance of a routing protocol in charge of exchanging VPN reachability information between VRs.





      The Classic model uses different instances of a routing protocol (PIM) among PEs. One instance per mVPN. This means that we’ll end up with one different control plane per mVPN, and as a consequence, with a large number of routing peers and adjacencies per PE device.


      PIM is a soft state protocol and it is timer-based by design. This means that if the number of mVPN grows, control plane traffic needed to maintain PIM adjacencies will grow with it, limiting the scalability of the overall solution.


      In the underlay, this model uses PIM too. PIM in the underlay is needed to setup specific mVPN tunnels (mGRE) between PE devices (MDTs). These tunnels are logical tunnels that interconnect mVRF instances and can be used as a regular link. Customer routing protocol data is tunneled over them, resulting in coupling between the data and control planes.




      NG mVPN (BGP/MPLS)


      NG mVPN model defines an extension of the MPLS L3 VPN unicast model for multicast traffic. This model is based on the Aggregated Routing (AR) VPN model. In the aggregated routing model a backbone routing protocol is responsible for disseminating the VPN membership and reachability information for all the VPNs.





      With NG mVPN model, one single instance of a routing protocol (BGP) carries mVPN routing information for all the mVPN, resulting in routing information aggregation in one common control plane. In this case, the routing protocol only needs one adjacency per pair of edge devices (PE devices in full-mesh) or one adjacency per Route Reflector (RR).


      BGP is a hard-state protocol, meaning that it uses incremental updates when there is a change on the routing information and is not based on timers and periodic information refresh, helping to keep a quieter control plane.


      The data plane setup supports different tunneling technologies and it’s not limited to PIM. mLDP, P2MP TE and IR can be used as encapsulation mechanisms maintaining the same control plane (BGP) and allowing for aggregation in the data plane.


      The exchange of routing information is decoupled from the transport of mVPN data as the control plane protocol doesn’t use the data plane tunnels to perform the routing information exchange. There is not a dependency between planes as in the previous model.


      The introduction of BGP as a control plane protocol in this model brings some solution advantages seen in the MPLS L3 VPN unicast case, like scalability, hierarchy and aggregation. There are as well some other capabilities specific to the multicast case that should be considered, like end-point Auto Discovery (AD) and Automatic Tunnel Binding (ATB) incorporated into the BGP multicast AF (mVPNv4 and mVPNv6).




      Inter-AS peering


      The inter-AS integration is not easy for inter-AS options B and C when using the Classic model. In the control plane, this model needs direct exchange of control plane traffic (PIM) across PEs. IN PIM/GRE models the interconnection between PE devices NEED TO BE DIRECTLY CONNECTED (Emulated LAN).


      In the data plane, all the SPs must support mGRE tunneling in the core and their PE peer each other directly. The PE devices need to look like directly connected even if they belong to different AS, and this is rarely a desirable situation.


      NG model inter-AS integration is much more flexible, allowing for different tunneling technologies in different AS and segmented inter-as trees support. BGP/MPLS based routing can be able to consider inter-PE distance and take that into account into the mVPN route selection process (not possible with Emulated LAN).


      In this case, PE devices don’t need to be directly connected to each other as in the PIM/GRE case.




      Summary


      This table summarizes the most relevant mVPN design topics by comparing side-by-side the Classical and NG model.



      Scope

      Design Topic

      Classic mVPN

      NG mVPN

      Control Plane

      VPN model

      Virtual Router (VR) Model

      Aggregated Routing (AR) Model

      Control plane protocol

      PIM (overlay)

      MP-BGP

      Routing protocol instances

      1 per mVPN

      1 BGP instance

      Number of adjacencies

      1 per PE per mVPN instance

      1 per RR per PE

      Routing information aggregation

      No

      Yes

      Coupling between data and control planes

      Highly Coupled

      No dependency

      Periodic refresh

      Soft State (Timer based)

      Hard State (BGP Update based)

      Inter-AS connectivity

      Direct peering

      Indirect peering

      Routing efficiency

      Suboptimal (emulated LAN)

      Optimizable (BGP distances)

      Data Plane

      Tunneling protocols

      PIM (underlay)

      mLDP, P2MP TE, IR

      Tunneling protocol flexibility

      No

      Yes

      Encapsulation

      mGRE

      MPLS LSPs

      MDT configuration

      Manual

      BGP tunnel auto discovery and binding

      MDT aggregation

      No, 1 MDT per mVPN (minimum)

      Supports aggregation

      General

      Efficiency

      Low

      High

      Hierarchical control plane

      No

      Yes

      State

      High (due to lack of aggregation)

      Low

      Scalability

      Low (due to PIM)

      High (due to BGP)

      Deployment

      Hard (new protocols)

      Easy (extensions to existing protocols)

      OPEX

      High

      Medium

       

       

       

      mVPN Additional References


      These normative references could be useful for obtaining additional information of Classic and NG mVPN models.




      I hope you find it useful.