Carrier Supporting Carrier – CSC

CSC Carrier Supporting Carrier is a hierarchical MPLS VPN architecture between the Service Providers.

Service is an MPLS VPN service mostly but doesn’t have to be as you will see throughout the post.

I am explaining this topic in deep detail in my Onsite CCDE  Live/Webex CCDE  and  Self Paced CCDE  course.


Customer carrier ( Provider ) receives an MPLS VPN service from the Core/Backbone carrier.

Although CSC architecture is not common in real life, if you are studying for the CCDE , CCIE Service Provider, JNCIE exams, you should know this architecture.

We have two Service Providers at least. Can it be three ? Yes If two different customer carriers setup their Inter-AS MPLS VPN over a Core/Backbone Carrier,although architecture get really complex, it is possible. (Inter-AS Option C would be an ideal in this case)

Carrier Supporting Carrier also an Inter-AS MPLS VPN solution but it tries to solve different problem.

Let’s remember  what we were trying to accomplish with all the Inter-AS MPLS VPNs with the very high level overview picture.


Customer’s 2 sites are connected to 2 different service providers.

Let’s look at what problem Carrier Supporting Carrier Architecture solves.

Carrier Supporting Carrier Overview

Customer’s 2 sites are connected two same Service Provider which receives an MPLS VPN service from another Service Provider.

In the above picture from the SP-1 point of view, SP-S just provides a reachability between the SP-1 devices.

SP-2 doesn’t know anything about SP-1’s customer prefixes.This brings to solution a scalability.

SP-2 just carries Service Provider -1 routers loopbacks, not even infrastructure addresses.

I will talk about what would be the better solution rather than Carrier Supporting Carrier at the end of the article but let’s look at how Carrier Supporting Carrier works, in detail.


Carrier Supporting Carrier

We have two Service Providers, SP-1 and SP2. SP1’s customer has two location. R1 in location 1 is connected to SP-1 Site-1 router R1 which runs EIGRP.

R11 in location 2 is connected to SP-1 Site-2 router R9 which runs EIGRP .

SP-1 has OSPF in its both location as core IGP. SP-2 which is a backbone carrier has IS-IS as its core IGP.  LDP is a label signalling protocol for both Service Providers. ( It could be RSVP as well )

SP-1 is called as a Customer Carrier and SP-2 is called as a Backbone or Core Carrier.

R4 is a VPN route reflector in SP-1 Site 1. R10 is a VPN route reflector in SP-1 Site 2.They run MP-BGP VPNv4 session with the PEs.

SP-1 provides an MPLS L3 VPN service to CE Site-1 and Site-2. SP-2 provides an MPLS L3 VPN service to SP-1 which is customer carrier.

SP-2 treats SP-1 as its regular VPN customer thus on the edges SP-2 puts all SP-1 prefixes into VRF.

SP-1 doesn’t use VRF since SP-1 doesn’t send its customer prefixes to SP-2.Instead only loopback addresses of SP-1 is sent to SP-2. Thus Global routing table of SP-1 is advertised to the SP-2.

This can be achieved by running either IGP or BGP at the edges. In this topology R3-R5 and R7-R8 runs IGP, specifically OSPF as CSC-CE – CSC-PE protocol.

Whole purpose of this architecture is to provide reachability between CE-`1 and CE-2 by using SP-2 as transparent from the SP-1 point of view.

Thus SP-2 shouldn’t break end to end LSP. End to End LSP is setup between the SP-1’s edge routers.In our topology R2 and R9 has to reach each other’s loopback likewise Router reflector and the other PEs should reach each other.

IBGP VPNv4 session is setup between the RRs in each domain.

Since between the sites of SP-1, BGP session is an IBGP session, RR doesn’t change the next hop of the Edge PEs. If it is an EBGP session; on the RR you need to say that BGP next-hop shouldn’t be changed as in the Inter-AS Option C case.

If you will remember one thing from this article then read below paragraph.

 In the Carrier Supporting Carrier Architecture,in order to hide end user prefixes ( SP-1’s customer prefixes), between CSC-CE and CSC-PE (SP-1 and SP-2 ASBRs), mpls is enabled through either LDP or BGP+label (RFC 3107).


CSC-PEs ( R5 and R7 in our topology ) assign a VPN label for all of the loopbacks of SP-1. SP-2 advertises those label towards MP-BGP as a VPNv4 label to edge PEs, and also towards CSC-CE (R3 and R8 in our topology) through LDP or BGP.

So on the R5 and R7, we have three labels in the label stack in the SP-2 domain. In R6 top most label can be removed with PHP operation. (If Pipe mode QoS enables Explicit Null could be signalled , so PHP is not done)

Top most label (Transport label) is for the edge devices reachability for the  BGP next hop (Loopback of R5 and r7) of SP-2 , second label is VPN label for the customer/SP-1 for SP-1 edge devices reachability of SP-1 and the third label is the VPN label of SP-1 for the end customer prefixes.

If you use in SP-2 MPLS Traffic engineering and FRR for Carrier Supporting Carrier Service,  you see up to 5 labels in the label stack thus MTU needs be considered but also hardware should support deep label stack.

Although I explained only an MPLS VPN service in the Customer carrier network, Carrier Supporting Carrier architecture is used to provide an additional layer of hierarchy.

If customer carrier wants to provide an Internet Service and don’t want to receive CSC service from the backbone carrier for its MPLS VPN customers, same operation (Advertising only loopbacks from the CSC-CE to CSC-PE and assign a label for the loopbacks) is done.

Conclusion :

Although backbone/core carrier provides an MPLS Layer 3 VPN service with the Carrier Supporting Carrier architecture, better solution for backbone carrier is to provide Layer0 service (DWDM),Layer 1 (Sonet/SDH,POTN and so on) or layer 2 service ( Ethernet, MPLS L2VPN and so on) since providing MPLS Layer 3 VPN in this case operationally more complex than providing basic connectivity.

DWDM and SONET/SDH for the long haul links is an expensive solution,especially if the requirement is fast recovery.SONET/SDH can provide this but requires additional hardware such as APS (Automatic Protection Switching).

Thus probably for both customer carrier and backbone carrier ideal solution would be Layer 2 MPLS VPN on the backbone carrier.

To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Perspective” Book. It covers the SP network Technologies with also explaining in detail a factious SP network.  Click here

What about you ? 

Are you an Enterprise or Service Provider engineer ?

Do you provide or receive Carrier Supporting Carrier service ?

23 Replies to “Carrier Supporting Carrier – CSC”

  1. Orhan, what is the benefits and the drawback of CSC in comparison to inter-as options?, and when CSC can be considered the only feasible solution that meets the business requirements?

    1. Thanks for the question Ashrf.
      CSC is also an Inter-Autonomous System VPN architecture as I stated in the article as well.

      But customer carrier doesn’t have to carry only VPN prefixes over the core carrier infrastructure. There are two high level overview pictures in the article. Those pictures give us a good summary on differences.

      From the business point of view, Consider Ooredoo Qatar for example. Since I am currently working in Qatar I will use this SP as a customer carrier.

      Oorden wants to provide an MPLS VPN service to its some customers in Qatar. Those customers have an office and ask MPLS VPN service end to end.

      Now Ooredoo can setup an Inter-AS VPN service with another provider which has a POP in those remote location and two service providers can setup an Inter-AS MPLS VPN.
      In this case, Ooredoo doesn’t have to have a POP in remote location.

      But let’s say Ooredoo wants to grow that remote region so it will open a POP there.

      But the problem how that remote location will be connected to Ooredoo’s core network ? Of course there are many options from L0 to L3 and if the L3 VPN is suitable for Ooredoo they choose that service.

      Question comes to then, Should customer carrier choose L3 MPLS VPN or L2 service/circuit ?

      Answer is the same for the enterprise networks.

      Why should they choose L3 VPN vs L2 service and I have an article here.

    1. Probably I wrote it in a bit detail. so very quick answer would be, as a service provider (It can be an enterprise as well) I want to connect my sites end to end through an upstream provider which provides me an MPLS service. If I would get another service (not MPLS) maybe DWDM, POTN,SONET/SDH etc, we wouldn’t need CSC architecture. Both customer and core carriers MPLS VPN hierarchy creates CSC solution ( Hierarchical MPLS VPN )

  2. Thanks orhan.

    It think the CsC wont be used in the future as it s not supporting ipv6 and the best solution is using pseudowires to bypass the carrier in the middle 🙂
    What you think?

    1. Hi Driss,

      Of course as a customer carrier I would want to have l2 circuit from my upstream provider. I could manage then my own control plane. But I wouldn’t say something for the feature. Maybe someone receives or provides this service. But Why do you think it is not supported ?

      1. no i said that all service provider will prefer L2L in the futur because CsC doesn’t support IPv6 as i know,then it’s not scalable enough

        1. @Driss Yes l2 connection customer carrier should get and in real life they get as well. This is just an architecture which can be enabled and it is good to understand MPLS VPNs overall but probably not a good design.
          IPv6 can be supported, it is not a problem since from the customer carrier, you send only the loopback for end to end LSP. Customer carrier still advertise their customers IPv6 prefixes within the VRF context through MP-BGP VPNv4 session.

          1. i meant that PE mpls facing interface wouldn’t work if they are only in IPv6 address.
            Yes IPv6 will be supported in vrf trough VPNv6.
            Thank you so much, i really appreciate it 🙂

          2. CSC-CE and CSC-PE will have LDP if they run IGP but Customer carrier will address IPv4 addresses of its loopbacks. Then MPBGP VPNv6 session (Address family) can be activated over v4 BGP session. Thanks for following the posts carefully, and commenting them 🙂 It really encourages me for writing !

  3. Thanks sir for this explanation, clear design doubt so our service provider using this CSC for international ISP to merge with there partner ISP in different countries while having the flavor of Inter-AS Option A which mainly more secure but offcourse need highly resources…

    1. Thanks Haroon, Yes Inter-as option A requires extra management effort and CPU/Memory resources on the ASBRs but don’t forget that we are targeting different goals with CSC and the design is slightly different as well.

  4. Hey Orhan, as I commented on the option C post. I work for a latin american carrier in the regional network department. The carrier has coverage in several countries, and we have a core regional network which connects to the local network of every country. We have option C in the data core, and every country is seen as a separate carrier and has a couple of route reflectors connected to the core. It is a highly complicated implementation and the troubleshooting is also complex. But this way the core routers do not carry vpnv4 routes and are almost strictly for forwarding. This saves a lor of memory which was the goal, because these routers are also part of an internet topology, and have full tables from Tier 1 ISP’s providers. They are Juniper by the way.

  5. What will be design considerations if the Customer carrier provides MPLS L3VPN services to its customers, but the backbone carrier has MPLS L2VPN in its core?

    1. if customer carrier wants l3vpn service in CSC architecture, BB carrier has to send IP reachability information of Customer carrier from one site of its domain to other.

      That reachability information is the loopbacks of CC, not the customers of CC.

      So it cannot be supported with L2VPN since with l2 vn you carry the l2 payload.

  6. Hi, I have done a bit of research on L3VPN carried over a L2VPN core. It is very possible to do it. The reachability information (loopback of CC) is carried on the xconnect circuit at the CSC PE where it imposes 2 additional labels, middle label for the CSC CE loopback and top label for the remote CSC PE. On the CSC CE – CSC PE interface, we have IGP+Label but no mpls is confiured on the xconnect circuit at the CSC PE.

    1. Hi Eselfor , You are saying you have IGP +LDP but no mpls is configured ?
      If LDP is configured, you are dynamically controlling the Label operation and you have MPLS.
      For CSC operation , you need an encapsulation between CSC-CE and CSC-PE to hide the customer prefixes of Customer carrier fro the Backbone Carrier. It doesn’t have to be MPLS though but you need an abstraction.

  7. Orhanergun,
    The ultimate aim is to establish LSP between CSC-CEs. In this design, the provider is transparent and the CSC-CEs are just one hop away from each other. What I mean is IGP+label, with the label distribution not necessarily by LDP. Packets arriving at CSC-PE will have a single label (VPN labels). The CSC-PE then imposes 2 additional labels as normal in a L2VPN. It is interesting when you do packet analysis. 2 labels (customer vpn label and xconnect circuit label) have the S bit set to 1, but separated by the control word.

    1. So far good but only one point is wrong that CSC-PE will not receive a VPN label. It will receive a label for the Carrier carriers internal loopback ( and maybe for infrastructure space as well ) but that label eventually can be seen as VPN label of Backbone carrier.

      By the way ultimate goal is not to have an LSP between CSC-CEs. CSC-CE is a term to describe for the ASBRs of Customer Carrier.

      They need to have an end to end LSP which might be RRs if they do an EBGP on customer carrier sites or PEs even RR in the control plane but preserve the next hop of PEs ( By default )

Leave a Reply

Your email address will not be published.