LAB#18 - Multicast - NG-MVPN

Description: A basic topology to enable NG-MVPN in ISP backbone for serving IPTV service.

Reason: The base specification for BGP/MPLS VPNs, RFC4364, only addresses unicast, and the first proposal for multicast support in BGP/MPLS VPNs is often known as Draft Rosen (which is now RFC6037). Most multicast implementations are based on the Draft and predate RFC6037. Draft Rosen is not fully consistent with standard MBGP unicast VPN and has the following limitations:

• Limited options for Transport: Draft Rosen only defines GRE or IP-in-IP for tunneling for multicast traffic and utilizes PIM to build trees. Most implementations based on the draft preferred the GRE encapsulation rather than IP-in-IP. The draft also limits the flexibility of other tunneling technologies like P2MP RSVP-TE, P2MP mLDP, and MP2MP mLDP.
• Control Plane Scalability: In Draft Rosen, the CE router maintains neighbor relationships with the PEs. The PEs maintains PIM adjacencies with other PEs which are part of the same MVPN. PE adjacency has to be maintained on a per MVPN per PE granularity which presents some control plane scalability issues. For example, consider a PE anticipating 100 MVPN services distributed across 100 PEs. Each PE will have to maintain 9900 (99×100) PIM adjacencies in addition to the adjacencies it needs to form to its directly connected CEs. In order to preserve 9900 PIM adjacencies, the PE would be sending approximately 330 PIM hello packets per second (using default 30s PIM hello timer), a significant stress on the PEs control plane. The numbers will get worse as the number of MVPN services or PEs increases. This isn’t a problem with Unicast VPNs where PEs has to only maintain a single BGP relationship with each PE or just a single relationship with the RR, regardless of the number of VPNs present on the CE.
• Availability: Draft Rosen does not specify any protection mechanisms like FRR or custom traffic engineered trees.
• Operational Consistency: Draft Rosen specifies the use of different protocols for Unicast and Multicast (PIM for Control and GRE for Data). Maintaining multiple protocols for unicast and multicast increases operational cost and complexity. Ideally, we would leverage a unified control (MP-BGP) and data plane (MPLS) for unicast and multicast.
• Maintaining State in the Backbone: Draft Rosen requires P routers to run PIM, which means each P router needs to maintain at least the number of MVPNs because there is one or more MDT (Default) per VPN. The P router is further burdened if Data MDT’s are also used. If you compare this with Unicast VPN, P routers don’t maintain any per VPN state.
• Lack of Aggregation: Draft Rosen does not specify any capabilities to aggregate multiple MVPNs into a single P-Tree. In an ideal situation, one would want to carry traffic from multiple VPNs into a single multicast tree.

The above limitations mentioned could also be considered as the wish list for NG MVPN.

Now many of you may ask what is NG-MVPN,

Next Generation multicast VPN framework utilizes a BGP control plane and offers a variety of options for data plane encapsulation. BGP is responsible for signaling both unicast and multicast information between PEs, replacing the need for running PIM in the SP core. The elegance of a single control plane protocol is that it provides operational simplicity and ultimately lower OPEX. One important thing to keep in mind is that NG MVPN framework was not intended to replace Draft Rosen, but instead offer more choices and flexibility in addition to what Draft Rosen originally provided.

Diagram:

1- Three Nodes (2 PE's & 1P)

2- IPTV server to be as a source for the receiver (in this LAB we can't perform real IPTV server as we don't have it in the simulator)

3- Receiver ( IPTV STB, a Modem, ...etc)

PreConfiguration:

1- IP-PLAN:

• three Loopback IP's for the nodes system IP.
• Four /30 subnet for IGP connectivity.

2- OSPF within the Autonomous system.

Configuration:

1- Configure BGP between (PE1<>P1 and PE2<>P2) with MP-BGP and MVPN

PE-1

P-1

PE-2

now with this configuration, we will have each PE node to originates a multicast tree locally towards the other PE node that are members of this MVPN instance. 

This behavior creates a full mesh of Inclusive-Provider Multicast Service Interfaces (I-PMSIs) across all PE nodes in the MVPN.

so what is "PMSI":

NG-MVPN introduces the concept of PMSI (P-Mulicast Service Interfaces) to bring separation between the “service” and “transport” mechanisms. A PMSI is a conceptual “overlay” on the P-network that refers to a “service”. This “overlay” can take packets from one PE belonging to a particular MVPN and deliver them to other or all the PEs belonging to that same MVPN. A PMSI always has the scope of single MVPN, and a single MVPN can have one or more PMSIs. 

those mesh PMSI are called P-Tunnel and in our lab we are using MLDP to the method that is going to use for transporting C-Multicast traffic.

Below are the result of establish of the MVPN,

PE-1

P-1

PE-2

2- Configuring VRF instance to serve IPTV service, ( in our LAB we will use PIM-SSM as PE-CE protocol and MLDP for transport protocol)

PE-1

* the interface (to-IPTV) is the connection with the IPTV server

* the static route is the source IP for multicast IPTV service and we add it here to be injected in the RT so PIM can understand how to reach the source.

* enable PIM in the interface of IPTV because this PE will be the sender and specify the subnet of the receivers (233.0.0.0/23) as we may use it as sender-receiver.

in MVPN section,

* we will use the default SPT for discovering the path of the multicast

* BGP will be the signaling for C-multicast

* For the transport tunnel we will use "MLDP"

the multicast is by default enabled in the LDP as below,

the VRF target will be unicast, as each PE will use a unique VRF target.

for PE-2 we will enable IGMP as this node will be Receiver only,

Result,

PE-1

PE-2

check BGP MVPN routes

now check if MLDP is working

here below is the result if the Receiver is connected to the IPTV server,

THANK YOU

If you have any question, plesae contact me :), CHEERS

AHMED KAREEM DIMAH