Carrier Supporting Carrier (CSC)

Carrier Supporting Carrier (CSC) is a solution that enables a service provider to use another service provider to connect parts of their own network. In this model, the service provider that provides connectivity over its network  is called the Backbone Carrier (BBC) and the provider that uses the network is called the Customer Carrier (CC). Using the transport services of another carrier allows the Customer Carrier to extend it’s network without the need to build and maintain it’s own infrastructure.

There are 3 main architecture for Layer 3 CsC:

  • Non-MPLS Carrier over MPLS VPN Carrier
  • MPLS VPN Carrier over Non-MPLS Carrier
  • MPLS VPN Carrier over MPLS VPN Carrier

 

Non-MPLS Carrier over MPLS VPN Carrier

**Transport/VPN refer to MPLS labels

In this design model, the customer carrier does not run MPLS across it’s internal network. The main advantage of this option is that it minimizes the number of prefixes sent to the backbone carrier as only the BGP next-hop IP’s from the different sites needs to be advertised. Some common use cases for this model would be:

  1. A global enterprise with a very large routing table that needs to be shared across different locations
  2. An Internet Service Provider that needs to connect it’s different remote sites

MPLS VPN Carrier over Non-MPLS Carrier

*Transport/VPN refer to MPLS labels

In the second model, the Backbone Carrier does not run MPLS VPN across it’s network. This is quite common for Internet Service Providers that do not offer MPLS VPN as a service. Some common use cases:

  1. During a migration or acquisition
  2. A large enterprise that wants to run MPLS VPN internally and over the internet. In this example MPLS run’s over a GRE tunnel but some more scalable solution could be mGRE or DMVPN (2547oDMVPN).

MPLS VPN Carrier over MPLS VPN Carrier

*Transport/VPN refer to MPLS labels

*CC-CE’s redistribute eBGP in IGP

In this last and most widely known model, the customer carrier run’s MP-BGP (eBGP or iBGP)  peering between the remote sites to exchange L3 VPN information over the carrier backbone. Again, only the BGP next hops (usually the loopbacks) are exchanged to the Backbone carrier. One caveat with this design is that if Route Reflectors are used with eBGP peering between the Customer Carrier devices then next hop must be set to unchanged (same as Inter-AS Option C) or sub-optimal traffic paths can be expected.

As seen in Option 1 and 3, there are two ways of exchanging label information between the backbone and customer carrier:

  • LDP + IGP (static/EIGRP/OSPF/IS-IS)
  • BGP + label

The preferred method is usually BGP in order to reduce the amount of protocols used (BGP will be used for eBGP to the Backbone carrier so it makes sense to run a single protocol instead of 2). One last note, using an IGP is not as much of a security risk as Inter-AS VPN Option C because the Backbone Carrier will not keep the exchanged routes in it’s global routing table but within the Customer Carrier PE-CE facing VRF.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s