Carrier Supporting Carrier - The whole story (1)

After I've completely illustrated the Inter-AS MPLS VPN solution with all its options, I've decided to cover the Carrier Supporting Carrier with all its options as well.

It was described as Carriers' Carriers in draft-ietf-2547bis section 9 and followed in the final RFC 4364, and was named Carrier Supporting Carrier by Cisco, and Carrier of Carriers by Juniper.

Carrier Supporting Carrier solution enables small service providers to use the cloud of another large service provider in order to connect parts of their own networks, using the transport services provided by another service provider in this manner eliminates the need for the small service providers to build and maintain their own MPLS backbone.

The service provider that provides connectivity over its cloud to the other providers is called the Backbone carrier and the service provider that uses the cloud is called the Customer carrier.

NOTE The backbone carrier can support multiple customer carriers.

The customer carrier can be one of two types:

• An Internet Service Provider (ISP) - (MPLS enabled or not) - Providing Internet Access to its customers - As illustrated later the whole customer carrier in this case acts as a single VRF to the backbone carrier, while its customers' traffic is transported over this single VRF.

• A BGP/MPLS VPN service provider - Providing MPLS VPN services to its customers - As illustrated later the customer carrier in this case acts as a single VRF to the backbone carrier, while its customers' traffic is transported over a second level of VRFs that is significant to the customer carrier itself.

NOTE The whole idea of labeling between the CSC-PE and the CSC-CE is that the backbone carrier shall only learn internal customer carrier routing and not their customers' routes and thus the backbone carrier router shouldn't be doing routing lookups, and thus should be substituted with label switching - Despite in the ISP customer carrier case whether the customer carrier network is MPLS enabled or not.

CSC-PE and CSC-CE routers configuration is identical in both scenarios, the deference is only in the customer carrier network configuration; in the ISP case the customer carrier network is non-MPLS enabled network, and the customer carrier edge routers residing in different sites need to run iBGP between each other to exchange their customers' routes, while in the case of MPLS VPN SP the customer carrier network is MPLS enabled, and the customer carrier edge routers in different sites need to run MP-iBGP to exchange customers' VPN prefixes with their relative VPN labels, and accordingly the data plane differs end-to-end between both scenarios, since an extra VPN label is required in the BGP/MPLS VPN SP customer carrier scenario.

NOTE To be more specific, in the ISP case the ISP might or might not be MPLS enabled, but its all about does it provide BGP/MPLS VPN services or not.

With both customer carrier types, the CSC architecture is designed so that the CSC backbone carrier only needs to know about internal routes available within the customer carrier network in order to provide connectivity between all the customer carrier routers, while the customer carrier network doesn't need to know about any backbone carrier internal routes (since no communication is required between the customer carrier routers and the backbone carrier routers), this is assured by simply exchanging labeled packets between the customer carrier and the backbone carrier, adding the fact that the customer carrier traffic will be label switched within the backbone carrier network (as if VPN traffic within its own VRF), meaning that the backbone carrier routers do not need to know about routes that belong to end customers connected to the customer carrier - as if the backbone carrier routers are P routers for the customer carrier network. This makes CSC architecture highly scalable.

ISP Customer Carrier

BGP/MPLS VPN Customer Carrier

From the CSC backbone carrier point of view, it provides MPLS VPN services to the customer carrier where the customer carrier sites are connected as MPLS VPN sites, using its own VRF under the CSC PE/CE interfaces on the CSC-PE side. The difference between a normal MPLS VPN service and the CSC service is that the traffic going between the CSC-PE and CSC-CE is labeled traffic rather than traditional pure IP traffic.

In the ISP customer carrier case the traffic between the CSC-PE and the CSC-CE is labeled with one label (which is the label exchanged between them; either via LDP or eBGP as illustrated later), while in the case of BGP/MPLS VPN customer carrier the traffic is labeled with two labels (the CSC-PE/CE label + the VPN label exchanged between the customer carrier edge router via MP-iBGP).

Obviously, label information exchange is required between the CSC-PE and the CSC-CE routers, because the packets are forwarded through CSC backbone carrier, which is not aware of the end customers' routes, and thus must be label switched rather than traditionally IP forwarded, and thus must provide an end-to-end LSP path between the different customer carrier sites over the backbone carrier cloud.

After providing connectivity between the customer carrier sites the final step is to establish the iBGP (if the customer carrier is an ISP) or the MP-iBGP (if the customer carrier is a BGP/MPLS VPN service provider) sessions between the customer carrier edge routers in the different sites to transport the end customers' routes between them.

In the BGP/MPLS VPN SP case the customer carrier external routes are VPN-IPv4 routes, while in the ISP case the customer carrier external routes are IP routes.

There are generally two ways of exchanging routes and their labels, we can use any of them in the CSC solution between the CSC-PE and the CSC-CE routers:

• Using IGP for route exchange plus LDP for label exchange - Like normal MPLS VPN PE-CE routing (static/RIP/EIGRP/OSPF), but with MPLS enabled under the VRF interface on the CSC-PE side and the CSC-CE side (enabling LDP simply via mpls ip under the interfaces on both sides).

• Using BGP for both route and label exchange - Using eBGP between the CSC-PE and CSC-CE routers, like normal MPLS VPN PE-CE eBGP under the address-family ipv4 vrf on the CSC-PE side but adding the neighbor x.x.x.x send-label command and the mpls bgp forwarding interface command on both sides - When using eBGP for label exchange using the send-label option, mpls bgp forwarding is automatically configured under the interface.

NOTE When using eBGP + label between the CSC_PE and the CSC_CE we need to use the as-override on the CSC_PE if the CSC_CE routers are using the same ASN (as if this is an ordinary PE-CE routing protocol).

Using BGP for CSC is the recommended solution, due to the following facts:

• BGP takes the place of an IGP and LDP in a VPN VRF table since we can use BGP to distribute routes with their MPLS labels, and for sure using a single protocol instead of two simplifies the configuration and troubleshooting.

• BGP is the preferred routing protocol for connecting two ISPs, mainly because of its wide scale routing policies and ability to scale.

NOTE The eBGP IPv4 route plus label approach is also the recommended in Inter-AS MPLS VPN option 3 (Multi-hop MP-eBGP between RRs and eBGP between the ASBRs).

Using IGP+LDP in CSC is not as risky as with Inter-AS VPN Option 3(10C), since in the CSC scenario the customer carrier internal routes are populated into a specific VRF in the backbone carrier not in the global routing table, and no backbone carrier internal routes are distributed to the customer carrier network, since the traffic is going to be label switched over the backbone carrier (the backbone carrier internal routers acts like P routers for MPLS VPN traffic) and more over the VRF table is not populated by any backbone carrier internal routes, only the customer carrier internal routes learned from the CSC-CE routers, thus there is practically zero security risk in using IGP + LDP in the case of CSC.

Well, in the next post I'll be covering both Customer carrier types in details with configuration examples.

I hope that I've been informative.

BR,
Mohammed Mahmoud.