CCDE – Next Generation Multicast – NG-MVPN

Introduction

Multicast is a great technology that although it provides great benefits, is seldomly deployed. It’s a lot like IPv6 in that regard. Service providers or enterprises that run MPLS and want to provide multicast services have not been able to use MPLS to provide multicast  Multicast has then typically been delivered by using Draft Rosen which is a mGRE technology to provide multicast. This post starts with a brief overview of Draft Rosen. This post should give a good overview of mVPN for CCDE candidates.

Draft Rosen

Draft Rosen uses GRE as an overlay protocol. That means that all multicast packets will be encapsulated inside GRE. A virtual LAN is emulated by having all PE routers in the VPN join a multicast group. This is known as the default Multicast Distribution Tree (MDT). The default MDT is used for PIM hello’s and other PIM signaling but also for data traffic. If the source sends a lot of traffic it is inefficient to use the default MDT and a data MDT can be created. The data MDT will only include PE’s that have receivers for the group in use.

Draft Rosen is fairly simple to deploy and works well but it has a few drawbacks. Let’s take a look at these:

• Overhead – GRE adds 24 bytes of overhead to the packet. Compared to MPLS which typically adds 8 or 12 bytes there is 100% or more of overhead added to each packet
• PIM in the core – Draft Rosen requires that PIM is enabled in the core because the PE’s must join the default and or data MDT which is done through PIM signaling. If PIM ASM is used in the core, an RP is needed as well. If PIM SSM is run in the core, no RP is needed.
• Core state – Unneccessary state is created in the core due to the PIM signaling from the PE’s. The core should have as little state as possible
• PIM adjacencies – The PE’s will become PIM neighbors with each other. If it’s a large VPN and a lot of PE’s, a lot of PIM adjacencies will be created. This will generate a lot of hello’s and other signaling which will add to the burden of the router
• Unicast vs multicast – Unicast forwarding uses MPLS, multicast uses GRE. This adds complexity and means that unicast is using a different forwarding mechanism than multicast, which is not the optimal solution
• Inefficency – The default MDT sends traffic to all PE’s in the VPN regardless if the PE has a receiver in the (*,G) or (S,G) for the group in use

Based on this list, it is clear that there is a room for improvement. The things we are looking to achieve with another solution is:

• Shared control plane with unicast
• Less protocols to manage in the core
• Shared forwarding plane with unicast
• Only use MPLS as encapsulation
• Fast Restoration (FRR)

NG-MVPN

To be able to build multicast Label Switched Paths (LSPs) we need to provide these labels in some way. There are three main options to provide these labels today:

• Multipoint LDP(mLDP)
• RSVP-TE P2MP
• Unicast MPLS + Ingress Replication(IR)

MLDP is an extension to the familiar Label Distribution Protocol (LDP). It supports both P2MP and MP2MP LSPs and is defined in RFC 6388.

RSVP-TE is an extension to the unicast RSVP-TE which some providers use today to build LSPs as opposed to LDP. It is defined in RFC 4875.

Unicast MPLS uses unicast and no additional signaling in the core. It does not use a multipoint LSP.

Multipoint LSP

Normal unicast forwarding through MPLS uses a point to point LSP. This is not efficient for multicast. To overcome this, multipoint LSPs are used instead. There are two different types, point to multipoint and multipoint to multipoint.

• Replication of traffic in core
• Allows only the root of the P2MP LSP to inject packets into the tree
• If signaled with mLDP – Path based on IP routing
• If signaled with RSVP-TE – Constraint-based/explicit routing. RSVP-TE also supports admission control

• Replication of traffic in core
• Bidirectional
• All the leafs of the LSP can inject and receive packets from the LSP
• Signaled with mLDP
• Path based on IP routing

Core Tree Types

Depending on the number of sources and where the sources are located, different type of core trees can be used. If you are familiar with Draft Rosen, you may know of the default MDT and the data MDT.

Signalling the Labels

As mentioned previously there are three main ways of signalling the labels. We will start by looking at mLDP.

• LSPs are built from the leaf to the root
• Supports P2MP and MP2MP LSPs
  • mLDP with MP2MP provides great scalability advantages for “any to any” topologies
    • “any to any” communication applications:
      • mVPN supporting bidirectional PIM
      • mVPN Default MDT model
      • If a provider does not want  tree state per ingress PE source
• Supports Fast Reroute (FRR) via RSVP-TE unicast backup path
• No periodic signaling, reliable using TCP
• Control plane is P2MP or MP2MP
• Data plane is P2MP
• Scalable due to receiver driven tree building
• Supports MP2MP
• Does not support traffic engineering

RSVP-TE can be used as well with the following characteristics.

• LSPs are built from the head-end to the tail-end
• Supports only P2MP LSPs
• Supports traffic engineering
  • Bandwidth reservation
  • Explicit routing
  • Fast Reroute (FRR)
• Signaling is periodic
• P2P technology at control plane
  • Inherits P2P scaling limitations
• P2MP at the data plane
  • Packet replication in the core

RSVP-TE will mostly be interesting for SPs that are already running RSVP-TE for unicast or for SPs involved in video delivery. The following table shows a comparision of the different protocols.

Assigning Flows to LSPs

After the LSPs have been signalled, we need to get traffic onto the LSPs. This can be done in several different ways.

• Static
• PIM
  • RFC 6513
• BGP Customer Multicast (C-Mcast)
  • RFC 6514
  • Also describes Auto-Discovery
• mLDP inband signaling
  • RFC 6826

Static

• Mostly applicable to RSVP-TE P2MP
• Static configuration of multicast flows per LSP
• Allows aggregation of multiple flows in a single LSP

PIM

• Dynamically assigns flows to an LSP by running PIM over the LSP
• Works over MP2MP and PPMP LSP types
• Mostly used but not limited to default MDT
• No changes needed to PIM
• Allows aggregation of multiple flows in a single LSP

BGP Auto-Discovery

• Auto-Discovery
  • The process of discovering all the PE’s with members in a given mVPN
• Used to establish the MDT in the SP core
• Can also be used to discover set of PE’s interested in a given customer multicast group (to enable S-PSMSI creation)
  • S-PMSI = Data MDT
• Used to advertise address of the originating PE and tunnel attribute information (which kind of tunnel)

BGP MVPN Address Family

• MPBGP extensions to support mVPN address family
• Used for advertisement of AD routes
• Used for advertisement of C-mcast routes (*,G) and (S,G)
• Two new extended communities
  • VRF route import – Used to import mcast routes, similar to RT for unicast routes
  • Source AS – Used for inter-AS mVPN
• New BGP attributes
  • PMSI Tunnel Attribute (PTA) – Contains information about advertised tunnel
  • PPMP label attribute – Upstream generated label used by the downstream clients to send unicast messages towards the source
• If mVPN address family is not used the address family ipv4 mdt must be used

BGP Customer Multicast

• BGP Customer Multicast (C-mcast) signalling on overlay
• Tail-end driven updates is not a natural fit for BGP
  • BGP is more suited for one-to-many not many-to-one
• PIM is still the PE-CE protocol
• Easy to use with SSM
• Complex to understand and troubleshoot for ASM

MLDP Inband Signaling

• Multicast flow information encoded in the mLDP FEC
• Each customer mcast flow creates state on the core routers
  • Scaling is the same as with default MDT with every C-(S,G) on a Data MDT
• IPv4 and IPv6 multicast in global or VPN context
• Typical for SSM or PIM sparse mode sources
• IPTV walled garden deployment
• RFC 6826

The natural choice is to stick with PIM unless you need very high scalability. Here is a comparison of PIM and BGP.

BGP C-Signaling

• With C-PIM signaling on default MDT models, data needs to be monitored
  • On default/data tree to detect duplicate forwarders over MDT and to trigger the assert process
  • On default MDT to perform SPT switchover (from (*,G) to (S,G))
• On default MDT models with C-BGP signaling
  • There is only one forwarder on MDT
    • There are no asserts
  • The BGP type 5 routes are used for SPT switchover on PEs
• Type 4 leaf AD route used to track type 3 S-PMSI (Data MDT) routes
• Needed when RR is deployed
• If source PE sets leaf-info-required flag on type 3 routes, the receiver PE responds with with a type 4 route

Migration

If PIM is used in the core, this can be migrated to mLDP. PIM can also be migrated to BGP. This can be done per multicast source, per multicast group and per source ingress router. This means that migration can be done gradually so that not all core trees must be replaced at the same time.

It is also possible to have both mGRE and MPLS encapsulation in the network for different PE’s.

To summarize the different options for assigning flows to LSPs

• Static
  • Mostly applicable to RSVP-TE
• PIM
  • Well known, has been in use since mVPN introduction over GRE
• BGP A-D
  • Useful where head-end assigns the flows to the LSP
• BGP C-mcast
  • Alternative to PIM in mVPN context
  • May be required in dual vendor networks
• MLDP inband signaling
  • Method to stitch a PIM tree to a mLDP LSP without any additional signaling

Optimizing the MDT

There are some drawbacks with the normal operation of the MDT. The tree is signalled even if there is no customer traffic leading to unneccessary state in the core. To overcome these limitations there is a model called the partitioned MDT running over mLDP with the following characteristics.

• Dynamic version of default MDT model
• MDT is only built when customer traffic needs to be transported across the core
• It addresses issues with the default MDT model
  • Optimizes deployments where sources are located in a few sites
  • Supports anycast sources
    • Default MDT would use PIM asserts
  • Reduces the number of PIM neighbors
    • PIM neighborship is unidirectional – The egress PE sees ingress PEs as PIM neighbors

Conclusion

There are many many different profiles supported, currently 27 profiles on Cisco equipment. Here are some guidelines to guide you in the selection of a profile for NG-MVPN.

• Label Switched Multicast (LSM) provides unified unicast and multicast forwarding
• Choosing a profile depends on the application and scalability/feature requirements
• MLDP is the natural and safe choice for general purpose
  • Inband signalling is for walled garden deployments
  • Partitioned MDT is most suitable if there are few sources/few sites
  • P2MP TE is used for bandwidth reservation and video distribution (few source sites)
  • Default MDT model is for anyone (else)
• PIM is still used as the PE-CE protocol towards the customer
• PIM or BGP can be used as an overlay protocol unless inband signaling or static mapping is used
• BGP is the natural choice for high scalability deployments
  • BGP may be the natural choice if already using it for Auto-Discovery
• The beauty of NG-MVPN is that profile can be selected per customer/VPN
  • Even per source, per group or per next-hop can be done with Routing Policy Language (RPL)

This post was heavily inspired and is basically a summary of the Cisco Live session BRKIPM-3017 mVPN Deployment Models by Ijsbrand Wijnands and Luc De Ghein. I recommend that you read it for more details and configuration of NG-MVPN.