MVPN...Multicast VPN over MPLS, basic theory question...

mprescher · ‎01-16-2009

(If this should go to the switching forum just holler.)

This question concerns the basic premise for architecting a large-scale MVPN deployment with multiple VRF's per sub-organization within a very large enterprise. The MPLS PE-P architecture is already in place and managed by an independent group not unlike a service provider environment.

Organizations are beginning to request multicast application support, for the most part geographically isolated but in some cases the traffic would reach across the enterprise. MVPN seems like the proper solution.

The details of the configuration don't are not a big concern as long as I understand the philosophy for implementation.

Question(s): Is the idea that you create a VRF dedicated to multicast resources for a given group or organization or client, and then you use the MPLS MVPN infrastructure knobs to pass that dedicated VRF-based multicast resource, (using RD imports and exports just as with MPLS VRF traffic) in to other user VRF's that want to join and receive the multicast?

The other approach I was imagining was that the multicast source was added within an existing user data VRF, imported and exported but then filtered with policy-routing (access-lists) so that if desired, only the multicast traffic, (and not the user traffic that is also present in that VRF) could be mixed with other desired VRF's?

Which of these two theories of distribution are in the "spirit" of a best-practice MVPN architecture? If I am completely off, what is this 3rd theory?

Laurent Aubert · ‎01-16-2009

Hi,

MVPN allows the multicast traffic of one VPN to stay inside this VPN.

The main difference is the implementation way:

- Unicast traffic is encapsulated in a LSP and a service label (VPN label) allocated by the remote PE is used to find the good output interface (except if it's an aggregate label but it's a specific case). So we are talking here about pt-2-pt connection only.

- Multicast traffic is encapsulated in a GRE tunnel which destination address is also a multicast address but only known by the backbone. So you need to allocate at least one multicast address to each VPN (you can compare that to QinQ where all VLANs of one customer are encapsulated in a single VLAN provided by the SP). So you see MPLS has nothing to do with MVPN so far. LDP has been improved to support pt-2-mp and mp-2-mp lsp and its integration is currently on-going in the IOS.

As a results you will have two multicast domain: one for the customer and one for the SP which are completely isolated. Having a unique multicast address in the SP domain for each VPN allows the complete separation between multicast customer domain.

Hope this helps.

Let me know if you have other question

Thanks

laurent.

mprescher · ‎01-19-2009

Thanks...

...is there a documented "best-practice" approach regarding whether mvpn/mpls multicast sources could/should be architected such that they exist within a dedicated multicast services VRF and then shared on demand using Multicast VPN Extranet support?

(The assumption here is that even within a mid-sized organization within the enterprise, there may be a variety of multicast sources and a variety of internal sub-group VRF's. Meaning, it would be desireable to centralize/secure that groups multicast sources while making its content available to its various sub-groups/other VRFs. Assume a high-security environment.)

Laurent Aubert · ‎01-19-2009

Hi,

We support Multicast VPN Extranet:

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_mc_vpn_extranet_ps6922_TSD_Products_Configuration_Guide_Chapter.html

The design really depends on where are the sources and the receivers. If you want receivers no to exchange unicast traffic but should be able to receive the same multicast traffic then multicast extranet makes sence. Other wise everyone should be in the same VPN.

Let me know if it helps

Thanks

Laurent.

shivlu jain · ‎01-17-2009

go with rosen draft.

http://tools.ietf.org/html/draft-rosen-vpn-mcast-08

regards

shivlu jain

Mohamed Sobair · ‎01-20-2009

Hello,

The Idea is simple:

The definition of Mvpn is a VPN that supports multicast natively...

The Provider is totally transparent for the customer Multicast traffic.

This Solution creats a multicat tunnel, unlike GRE tunnel, This tunnel is not a point to point, it tracks the remote PE and unicast the multicast packet to the remote PE. Being the Source of Multicast the Originator BGP Session ID and the Multicast destination is the MDT-DATA Group.

Only a single Mvrf (Multicast VRF) is supported per customer.

Aunique group is required for each customer, a unique source is also required and its recommended to be the loopback interface of the BGP session.

PEs Signal the use of DATA-MDT via UDP port 3232 to the remote PE, Only CEs intend recipent of Multicast has to Join the Group.

The Unique Default-MDT Group is used to forward Pim Control Messages.

Only PIM SSM & Sparse-Mode is supported, PIM Bidirection will be supported later once it proves stability.

HTH

Mohamed