• Next-Generation Multicast VPN Design Options • Multicast VPN Network-Level Reliability Design Options • Next-Generation MVPN CoS Design Considerations
Advanced Connectivity Design Overview
Advanced connectivity services include various advanced options provided on top of the basic connectivity services (for example, multicast traffic distribution). Services in this category are requested by a fraction of the basic connectivity customers and are usually sold at premium prices and in small volume.
This solution describes the multicast VPN (MVPN) service where multicast traffic is delivered within a customer VPN, including traffic sourced from extranets.
This document describes the use of MVPNs as the advanced connectivity service for this solution. The MVPN service provides a multicast traffic distribution option that functions over a base Layer 3 VPN service. The MVPN service can be provided to business customers or used by the service provider.
Multicast VPNs are used to deploy multicast service in an existing VPN or as part of a transport infrastructure. Essentially, multicast data is transmitted between private networks over a VPN infrastructure by encapsulating the original multicast packets. As expected, in networks running a multicast VPN service, traffic sources send multicast traffic to the network, while multicast receivers consume that traffic. The difference between transmitting and receiving devices is functional. In other words, each customer edge (CE) device can be used as both a receiver and a source. However, this functional merge usually results in a different set of protocols functioning at the attachment circuit (for example, IGMP instead of PIM).
The following sections provide more information about different MVPN options: • Understanding Draft-Rosen VPNs
• Understanding Next-Generation Multicast VPNs Understanding Draft-Rosen VPNs
Originally defined by RFC2547, “BGP/MPLS VPNs” in October 2004, Layer 3 BGP/MPLS VPNs are widely deployed today. In February 2006, RFC 2547 was superseded by RFC 4364, “BGP/MPLS IP Virtual Private Networks (VPNs).” Because of their association with the original RFC number and the primary author of the RFC, these VPNs are commonly referred to as “2547” or “Draft-Rosen” VPNs.
NOTE: This document does not provide configurations for Draft-Rosen VPNs. However, it is important to understand this type of VPN to better understand its limitations and the subsequent advantages of using a next-generation multicast VPN configuration.
Draft-Rosen MVPN Deployment
RFC 2547 and RFC 4364 describe protocols and procedures for creating BGP/MPLS VPNs to forward VPN unicast traffic only. Multicast VPN traffic is handled using an incremental approach (RFC 6037), where the multicast traffic configuration is overlaid onto the BGP/MPLS unicast network.
Basic MVPN deployment requires the use of a mechanism for carrying MVPN-specific multicast routing information. This mechanism, known as the “control plane,” carries control messages from “receivers” in the network to different “sources” in the network to indicate that the receiver sites are prepared to receive traffic from source (sender) sites. In addition to the control plane, a mechanism is required to carry the multicast traffic between routers. This mechanism, known as the “data plane,” carries traffic from sources to identified receivers.
NOTE: Different MVPNs might use the same address space (RFC 1918), including an IP multicast address space. To support the overlapping address space, a best practice would be to use the same route distinguisher as that used by the Draft-Rosen VPNs for unicast traffic.
Draft-Rosen MVPN Limitations
In a typical Draft-Rosen multicast VPN deployment model, VPN multicast traffic travels over an existing unicast Draft- Rosen network, resulting in the need for a virtual router architecture. In this model, Protocol Independent Multicast- Sparse Mode (PIM-SM) is used to exchange control plane information between virtual routing and forwarding (VRF) instances. Employing this type of network, where customer domain multicast protocol information (for example, PIM join or prune messages) is received from local CE routers and propagated to other PE devices, scale can become an issue. For any given MVPN, a PE device must maintain a PIM session with every other PE device that has a membership in that MVPN. As an example, a network containing 1,000 MVPNs per PE device and 100 sites per MVPN would have 100,000 PIM neighbors per PE device generating 3,300 PIM hellos per second.
Understanding Next-Generation Multicast VPNs
To address the control and data plane scaling issues brought about through the use of Draft-Rosen MVPNs, which requires providers to maintain two different routing and forwarding mechanisms for VPN unicast and multicast services, the IETF Layer 3 VPN working group defined next-generation MVPNs. The working group published an IETF draft (draft-ietf-l3vpn-2547bis-mcast) that is a superset of the previous specifications for MVPNs. In addition, the following two main drafts were created to define next-generation MVPN design and configuration:
• draft-ietf-l3vpn-2547bis-mcast-bgp—Outlines the procedures of the next-generation MVPN
• draft-ietf-l3vpn-2547bis-mcast—Describes the building blocks for the different next-generation MVPN configuration options The use of scalable, reliable, and secure next-generation multicast VPN configurations can enable service providers to increase revenues by deploying more lucrative, media-rich applications.
The next-generation MVPN drafts introduced a BGP-based control plane that is modeled after its highly successful counterpart of the VPN unicast control plane. Leveraging the functionality of common unicast BGP-MPLS VPNs, next- generation MVPNs utilize the following properties:
• The BGP protocol distributes all necessary routing information to enable the VPN multicast service.
• The BGP protocol distributes C-multicast routes, resulting in the control traffic exchange being out-of-band from the data plane. This implementation enables the separation of the control and data plane protocols and simplifies the use of new transport technologies (for example, point-to-multipoint MPLS) for delivering MVPN services.
The use of a BGP-based NG MVPN control plane enables the support of both flexible topologies (for example, extranet or hub-and-spoke) and IPv6 addressing. Implementing IPv6-based NG MVPN enables the use of MPLS encapsulation for IPv6 multicast. As an added benefit, IPv6-based next-generation MVPN uses the same model as IPv6 VPN for unicast (as defined in RFC 4659), ensuring a more compatible integration of IPv6 multicast services with existing IPv4 next-generation MVPN or IPv6 unicast VPN models.
BGP MVPNs provide multihoming support for connecting a multicast source to two provider edge (PE) devices, enabling subsecond failover from a PE node failure. The autodiscovery of MVPN members available with the BGP approach provides a high degree of automation for establishing provider tunnels that are used for carrying MVPN data between PE devices.
The multicast VPN connectivity service designed in this solution adheres to RFC 6513, “Multicast in MPLS/BGP IP VPNs,” also known as next-generation MVPNs. Figure 21 shows the general NG MVPN design topology.
PIM IGMP MP-BGP PIM PIM PE-C P-RP C-RP PE-C P-RP C-RP PE-A PE-B P P P P CE-C CE-D CE-A CE-B Multicast Source-B Multicast Receiver-A Multicast Receiver-B Rendezvous point in a customer instance for any source multicast Rendezvous point in a provider instance MSDP MSDP Multicast Source-A
Figure 21: NG MVPN design topology
Because of the large number of transport and signaling options, multicast VPN is one of the most complex services to design. Table 11 lists the NG MVPN designs supported in this example.
Table 11: MVPN Transport and Signaling Options
Parameter Next-Generation MVPN P2MP RSVP-TE Next-Generation MVPN P2MP mLDP Next-Generation MVPN P2P Rosen V7 Rosen V6 PE device autodiscovery mechanism BGP BGP BGP BGP PIM-SMRouting of the customer multicast between PE devices
BGP BGP BGP PIM-SM PIM-SM
Replication Core Core Ingress Core Core
Provider tunnel type P2MP RSVP-TE P2MP mLDP P2P RSVP-TE/LDP IP in GRE The same next-generation MVPN BGP signaling mechanism is shared by each option. The only difference is in the provider tunnel configuration.
This solution incorporates NG MVPN signaling.
Next-Generation Multicast VPN Design Options
The following sections provide design considerations for NG MVPN configuration: • Next-Generation MVPN BGP Signaling
• Next-Generation MVPN Provider Tunnels Next-Generation MVPN BGP Signaling
In this scenario, BGP is used to signal information about active multicast sources and receivers and to facilitate PE router autodiscovery. Figure 22 shows multicast traffic being delivered over an MPLS core using a provider tunnel, P2MP, or P2P (ingress replication) signal using RSVP-TE.
PIM IGMP MP-BGP PIM PIM PE-C C-RP PE-D C-RP PE-A PE-B P P P CE-C CE-D CE-A CE-B Multicast Source-B Multicast Receiver-A Multicast Receiver-B Provider Tunnel (P2MP is shown) Rendezvous point in a customer instance for any source multicast
Multicast Source-A
P
Figure 22: Next-generation MVPN design
Directly attached hosts signal group membership to PE routers using IGMP or Multicast Listener Discovery (MLDv2). Routers use PIM-SM/SSM instead.
In any source multicast scenario, PE routers should discover active sources and should distribute this information to the rest of the network. Automatic discovery is greatly simplified when a source is directly attached to the router.
When a CE device resides between the source and the router, discovery can occur in one of the following two ways: • Configure a rendezvous point (RP) at the PE router in a customer instance (C-RP) and specify that CE routers use the
defined RP
• Configure the Multicast Source Discovery Protocol (MSDP) protocol to operate between the PE router and a customer RP This design uses the first RP configuration option, because the deployment of basic PIM configurations is prevalent in service provider networks.
For redundancy, you can configure several C-RPs, each on a different PE router. Rendezvous points can share the same IP address (anycast RP) and information about active sources that are registered on different C-RPs is exchanged automatically using BGP, eliminating the need to run MSDP between C-RPs.
As this is a multicast VPN deployment, it is expected that some multicast source sites might send multicast traffic in some groups and receive multicast traffic in other groups. Defining selective multicast trees (where the default behavior is inclusive and all groups share the same tree) results in optimal traffic distribution. Provider tunnel configuration remains the same, but there is more than one tunnel and there is an additional mapping configuration between the multicast groups and tunnels at the PE device.
RFC 6513 also defines aggregate multicast distribution trees, which are those that aggregate multicast traffic from multiple VPNs. Aggregate trees are not supported by this solution.
Next-Generation MVPN Provider Tunnels
This NG MVPN design supports the P2MP RSVP-TE provider tunnels type. When using this tunnel type, it is assumed that this multicast service is used for delivery of continuous multicast traffic flows with known bandwidth.
The design uses the vrf-table-label statement when configuring the VPN instance. This statement maps the inner label of a packet to a specific VPN routing and forwarding (VRF) table, enabling IP route lookup. All routes in the VRF configured with this option are advertised with the label allocated per VRF. The result is an inefficiency where multicast traffic is duplicated at the P-PE interface when the PE router also serves in a P router role. To alleviate this inefficiency, virtual tunnel interfaces are used for multicast traffic only.
Two virtual tunnel interfaces are needed for redundancy. One interface is defined as the primary. Traffic processing at the virtual tunnel interface does have performance implications. The PFE where the virtual tunnel interface resides is called the anchor PFE.
NOTE: Using either uplink or the access-facing PFEs as anchors can help to avoid extra hops through the switch fabric in distributed systems such as the Juniper Networks MX960 3D Universal Edge Router. Choosing an access PFE as an anchor has the benefit of fate sharing with the access interfaces. In cases where only one PFE serves all customer interfaces, virtual tunnel interface redundancy might not be required at all. However, because customer access interfaces might reside on several different PFEs, virtual tunnel redundancy will most likely be required.
In some deployments, a customer might choose a specific anchor PFE to optimize multicast traffic replication through the device. In this solution, however, virtual tunnel interfaces are configured only at the uplink PFE.
One of the main benefits in using a next-generation MVPN deployment is its clean and straightforward extranet MVPN implementation. For multicast sources and receivers to reside in different VPNs, you must configure route import and export policies for the PE devices to enable communication between receivers and sources. When configuring these route policies:
• At the PE device with multicast sources attached, import into the source VPN routes from VPNs where receivers reside
NOTE: You can limit the import to sites with receivers only.
• At the PE device with multicast receivers attached, import into respective receiver VPN routes from the source VPN
NOTE: Limit the import to sites with sources only.
If the same PE device serves both source VPN (with local sources) and receiver VPNs, you must include an auto-export configuration.
Multicast VPN Network-Level Reliability Design Options
Multicast VPN high availability design inherits some of the redundancy and the reliability design considerations highlighted for the basic Layer 3 VPN service design.
Link-level redundancy is implemented by using the same aggregated Ethernet technology used for Layer 3 VPN unicast service. For local repair of the P2MP RSVP-TE LSPs in the network core, link protection is used.
Next-Generation MVPN CoS Design Considerations
The class-of-service (CoS) architecture used for the MVPN service is the same as that used for the basic connectivity (Layer 3 VPN/DIA) CoS architecture.