NG-mVPN Series - Control Plane

NG-mVPN Series - Control Plane

Introduction

This series on NG-mVPN (short for Next-Generation Multicast VPN) will start with the limitations of Rosen-model and introduce the control-plane as described in RFC 6514. Multicast in BGP/MPLS VPNs is described in RFC 6513.

Rosen-model with GRE uses a combination of PIM and GRE encapsulations for control-plane and data-plane, respectively. The Customer-multicast (C-Multicast) packets are encapsulated in GRE in the Provider network. Using Data MDTs, some sort of efficiency is achieved but there are limitations with this model as discussed next.

Rosen-model limitations

The limitations of Rosen-model are-

• The Provider network must be IP multicast enabled.
• Atleast one multicast tree per customer (Default MDT), and a number of Data MDTs per multicast source, per customer. Hence, a large number of multicast states must be maintained in the Provider network.
• PIM is used between PE routers for a particular VRF and hence, 2 different control plane protocols - MP-BGP for unicast, and PIM for multicast.
• Multicast traffic is GRE encapsulated (atleast for Rosen-model with GRE) and hence, 2 different data plane encapsulations - MPLS for unicast, and GRE for multicast.
• Fast-restoration techniques like MPLS-TE which have worked well for unicast traffic do not apply for multicast traffic.

NG-mVPN Control Plane

NG-mVPN is described in RFC 6513 and RFC 6514. The control-plane within the provider network is based on BGP. So, BGP is used for exchanging VPNv4 unicast prefixes and multicast information between PE routers. BGP performs following functions -

1. Auto-discovery of remote PE routers within an NG-mVPN instance
2. Exchange of data plane information between PE routers
3. Exchange of C-Multicast information

RFC 6514 introduces a new SAFI (value 5) for MCAST-VPN for control plane operations. The document also introduces a new BGP NLRI called MCAST-VPN NLRI which is carried in BGP UPDATE messages. The MCAST-VPN NLRI is of the format as shown below and there are 7 different Route Types defined by the RFC.

Before the route-types are defined, it is important to understand PMSI.

Provider Multicast Service Interface (PMSI)

For a given mVPN, when a PE receives multicast traffic from a CE, it must be able to forward to other PEs in the same mVPN. The concept of PMSI is introduced which provides an overlay on the P-network. A PE gives the packet to the PMSI, and the underlying transport mechanism, P-Tunnel, delivers the packet to some or all remote PEs in the mVPN, and the receiving PEs are able to determine the mVPN to which the packet belongs. Note there is distinction between PMSI and P-tunnel, as the PMSI belongs to a single mVPN, while the P-tunnel may carry traffic from multiple PMSIs.

There are 2 types of PMSIs :

1. Inclusive PMSI (I-PMSI) - The I-PMSI has 2 variants :
   1. Multidirectional I-PMSI (MI-PMSI) - MI-PMSI enables "any PE router" for a given mVPN to transmit a message such that it is received by all PE routers attached to that mVPN.
   2. Unidirectional I-PMSI (UI-PMSI) - UI-PMSI enables "a PE router" for a given mVPN to transmit a message such that it is received by all PE routers attached to that mVPN.
1. Selective PMSI (S-PMSI) - S-PMSI enables a PE router for a given mVPN to transmit a message such that it is received by a "subset of PE routers" attached to that mVPN. S-PMSIs are instantiated based on the number of C-Multicast Sources.

PMSI Tunnel Attribute

A new optional transitive BGP Path attribute is defined called PMSI Tunnel attribute. This attribute identifies the P-tunnel. The format of this attribute is shown below.

The Tunnel Type field indicates the various types of tunneling technologies available to establish PMSI tunnel between PE routers to transport multicast traffic. Within the MPLS Label field, the high-order 20-bits contain the label value. The semantics of Tunnel Identifier field depends on the type of the tunnel.

Type 0 : No tunnel information present

The PMSI attribute carries no tunnel information and is used for explicit tracking of C-Multicast flow by setting the Leaf Information Required flag 'L' to 1 in the attribute.

Type 1 : RSVP-TE P2MP LSP

The Tunnel Identifier is [Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID] from the RSVP-TE P2MP Session Object.

Type 2 : mLDP P2MP LSP

The Tunnel Identifier is the mLDP P2MP FEC Element (type 0x0508) which has Tree-type, Root-node address and Opaque-value.

Type 3 : PIM-SSM Tree

The Tunnel Identifier is [P-Source Address, P-Multicast Group].

Type 4 : PIM-SM Tree

The Tunnel Identifier is [P-Sender Address, P-Multicast Group].

Type 5 : Bi-Dir PIM Tree

The Tunnel Identifier is [P-Sender Address, P-Multicast Group].

Type 6 : Ingress Replication

The Tunnel Identifier carries the unicast tunnel (MP2P for LDP, P2P for RSVP-TE) end-point IP address of the local PE.

Type 7 : mLDP MP2MP LSP

The Tunnel Identifier is the mLDP MP2MP FEC Element (type 0x0509).

Source AS Extended Community

A new BGP Extended community is introduced called Source AS extended community. The format is as follows.

This extended community is advertised by PEs in BGP UPDATE message carrying VPNv4 prefixes that has sites of a given mVPN when connected via segmented Inter-AS tunnels.

VRF Route Import Extended Community

Another BGP Extended community is introduced called VRF Route Import extended community. The format is as follows.

This extended community is advertised by PEs in BGP UPDATE message carrying VPNv4 prefixes that has sites of a given mVPN connected to them.

mVPN Auto-Discovery - Intra-AS

This section of the article will describe the auto-discovery of PE routers for a given mVPN and the routes involved in an intra-AS environment.

Every PE router that has an mVPN instance, originates the Intra-AS I-PMSI A-D route and advertises in IBGP. The Intra-AS I-PMSI A-D route type specific to MCAST-VPN NLRI is of following format.

The PMSI Tunnel attribute is also advertised with this route by selecting an appropriate tunnel type. And, the export Route-Target community of the VRF is also advertised in BGP UPDATE message.

mVPN Auto-Discovery - Inter-AS

This section of the article will describe the auto-discovery of PE routers for a given mVPN and the routes involved in a segmented inter-AS environment. In this case, the ASBR is configured to support mVPN and hence must be configured to accept Route-Target communities for the supported mVPNs.

The ASBR determines using Intra-AS auto-discovery procedure that one of the PEs in its AS has connected site(s) of the mVPN in another AS. The ASBR originates the Inter-AS I-PMSI A-D route and advertises in EBGP. The Inter-AS I-PMSI A-D route type specific to MCAST-VPN NLRI is of following format.

The route carries a PMSI attribute and the tunnel type is Ingress Replication with no MPLS label. The 'L' flag is set to 1. Note that all Intra-AS I-PMSI A-D routes can be aggregated into a single Inter-AS I-PMSI A-D route but that depends on the set of RTs carried in the BGP UPDATE message.

The originating ASBR also constructs a BGP extended community called ASBR Import-RT which carries the originating ASBR's IP address. The ASBR Import-RT extended community is also advertised in BGP message.

The receiving ASBR determines if the received route is the best path for its NLRI, then the ASBR re-advertises this route to other PEs and ASBRs within its own AS. The receiving ASBR also originates the Leaf A-D route and advertises to the EBGP neighbor from which the Inter-AS I-PMSI A-D route was received. The Leaf A-D route type specific to MCAST-VPN NLRI is of following format.

The Route Key field is set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route received from the EBGP neighbor and the Originating Router's IP address is set to the IP address of the ASBR. The PMSI tunnel attribute is also advertised with tunnel-type set to Ingress Replication and a downstream-assigned MPLS label. The receiving ASBR also constructs an ASBR Import-RT extended community by placing the IP address carried in the Next-Hop field of the Inter-AS I-PMSI A-D route.

When the ASBR receives the Leaf A-D route via EBGP with the Inter-AS I-PMSI A-D in Route Key field same as its own Inter-AS I-PMSI A-D route (and matches the ASBR Import-RT community), it sets up its forwarding state such that the packets received on the intra-AS tunnels are transmitted to the neighbor ASBR using the MPLS label advertised in PMSI attribute with Leaf A-D route.

C-Multicast Routes

The C-Multicast route exchange between PE routers refers to propagation of C-Joins from receiver PEs to sender PEs. C-Joins are translated into BGP C-Multicast mVPN routes and advertised via MCAST-VPN address-family towards sender PEs.

The RFC describes methods for 2 different multicast routing protocols between PE and CE - PIM and mLDP. Only PIM will be described here. mLDP could be used as PE-CE multicast routing protocol in Carrier-Supporting-Carrier (CSC) environments.

When a C-PIM instance on a particular PE creates a new (C-S,C-G) state and the selected upstream PE for C-S is not the local PE, then the local PE originates a Source-Tree Join route. The Source-Tree Join route type specific to MCAST-VPN NLRI is of following format.

When a PE receives a Source-Tree Join route, it originates a Source Active A-D route. The Source-Active A-D route type specific to MCAST-VPN NLRI is of following format.

The Source-Active A-D route is propagated to all PEs of the mVPN. The route carries the same set of RTs as the Intra-AS I-PMSI A-D route.

When a C-PIM instance on a particular PE creates a new (C-*,C-G) state and the selected upstream PE for C-RP is not the local PE, then the local PE originates a Shared-Tree Join route. The Shared-Tree Join route type specific to MCAST-VPN NLRI is of following format.

The local PE selects the upstream PE based on C-Multicast Source/C-Multicast RP address field and extracts-

• ASN from Source AS extended community
• RT from VRF Route Import extended community

The C-Multicast route is then advertised in IBGP based on these values.

When a PE router receives a C-Multicast route, the RT is checked and the C-S/C-RP address is checked to see if it originated the VPNv4 route for that address. Upon receiving a Source-Tree Join route, the PE creates a (C-S,C-G) state from the C-Multicast Source and C-Multicast Group fields of the MCAST-VPN NLRI for that particular mVPN. Upon receiving a Shared-Tree Join route, the PE creates a (C-*,C-G) state from the C-Multicast RP and C-Multicast Group fields of the MCAST-VPN NLRI for that particular mVPN.

Using S-PMSI A-D Route

The format of S-PMSI A-D route is as follows.

The RD and Originating Router's IP address fields uniquely identifies a given mVPN. The PE also advertises PMSI attribute with 'L' flag set to 1. It also creates a Route-Target for which the IP address is set to the Next-Hop of all S-PMSI A-D routes advertised by the PE. Other RTs associated with C-S/C-RP VPN-IP routes are also advertised.

The receiving PE originates a Leaf A-D route to the originating PE. It may then originate either a Source-Tree Join route to the originating PE, or a Shared-Tree Join route to the originating PE.

Summary

This was a brief overview of all the BGP route types that make up the NG-mVPN control plane signalling. There is not a lot of details covered with respect to originating/processing/receiving different routes, and hence reading RFCs is recommended.

References

RFC 6513 : Multicast in MPLS/BGP IP VPNs

RFC 6514 : BGP Encodings and Procedures for mVPNs

RFC 4360 : BGP Extended Communities Attribute