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 Instructor Led 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.
Customer's 2 sites are connected to the POP locations of a Service Provider which receives an MPLS VPN service from another Service Provider.
In the above picture from the SP-1 point of view,
SP-2 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.
.jpg)
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 Architecture Perspective" Book. It covers the SP network Technologies with also explaining in detail a factious SP network.
What about you ?
Are you an Enterprise or Service Provider engineer ?
Do you provide or receive Carrier Supporting Carrier service ?