I just want to understand why we extend the LDP between CSC-PE and CSC-CE? Agree that CSC-PE dont have the IP address of the CustomerISP's customer routes in VRF table! so I just need to understand how the forwarding will work for two different customerISP's customers?
The reason that label exchange (can be done with BGP as well) is extended to include the link between CSC-PE and CSC-CE is to avoid a IP lookup in the CSC-PE table for a customer prefix known only in the customer carrier network. Imagine plain IP (non-labeled) traffic from the CSC-CE towards a CSC-PE. As you said, the external destinations of the customer carrier are not in the VRF table of the CSC-PE. In a non-CSC scenario this is not the case, and a lookup is done in the VRF table for the customer destination IP. In the CSC scenario the CSC-PE cannot do such a lookup for the exact destination. The whole point of CSC as a scalability feature is to actually avoid having this type of information in the CSC-PE.
We sum up at this point: we cannot do an IP lookup for the exact destination IP in the CSC-PE. So, how do we forward packet to destination? If you recall, in the non-CSC L3 MPLS VPN scenario we do not want the P routers to keep VPN information. This problem was solved by using an IGP label on top of the VPN label. The P routers just need to deliver the labeled packet to the correct egress PE. This same logic is also applied in the CSC-scenario. Instead of examining the destination IP address at the ingress CSC-PE, we examine some label that can put us in the right track.
In CSC scenario the P routers continue to be unaware of VPN destinations. The CSC-PEs are aware of VPN destinations. Those VPN destinations are the internal addresses of customer carrier (bgp next-hops, etc.). The CSC-PE does not route towards the actual destination, but towards the correct next-hop/egress CSC-CE. So, CSC-PE can use a label for that egress CSC-CE instead of doing an IP lookup.
Now, how does a CSC-PE know who is the correct next-hop/egress CSC-CE for a destination ? Well the CSC-PE doesn't actually know that, which is the fun part :-) The CSC-CE is part of the BGP design of the customer carrier. The BGP routers of the customer carrier know this type of information. So, the ingress CSC-CE identifies the correct next-hop/egress CSC-CE for the destination and pushes a label to the packet before sending it to ingress CSC-PE. The CSC-PE will act on this label and send packet towards correct egress CSC-CE instead of the actual destination IP.
I have considered the case of a customer carrier having an IP core, which is the simplest CSC scenario to understand, but logic is not very different in other cases. If we have such an IP customer carrier, traffic routing between 2 end-customers of this customer carrier is done with the help of BGP at the customer carrier network. With the help of BGP, traffic reaches correct ingress CSC-CE, correct egress CSC-CE is identified there, corresponding label is pushed, and labeled packet is sent to ingress CSC-PE. Ingress CSC-PE finds egress CSC-PE, and the rest is similar to non-CSC scenario. Please tell me if you are with me so far :-) Just have in mind that in this IP core CSC scenario the internal addresses of the customer carriers are kept isolated in the VRFs (not the end-customer external addresses, customers are not isolated from each other).
Yes, Looking at it from the traditional Logic of MPLS-VPN Scenario, The P routers are not awre of the VPN labels and dont perform lookup at the VPN label , The PEs do perform lookup at the VPN label and CEF table.
IN CsC (Hierarchal Architecture), The CSC-CE is typically equivelant to the PE in the traditional VPN and performs lookup at the VPN label , the CSC-PE is typically the equivelant to the P routers in traditional MPLS-VPN (Intra-AS MPLS-VPN).
Therfore, The CSC-CE has to be configured with MP-BGP, This session carries all labeled VPNv4 or VPNv6 Networks between AS boundaries.
So the idea is to make CSC-PE as LSR instead of IP to MPLS push function, it will perform the label swap as well as PUSH function right! and At CSC-CE IP packet will be pushed a MPLS Label for next hop right!
Yes that's true, The CSC-PE is equivelant to the (P) LSR which performs Label Swapping. But this is considered within the Hierarchal Architecture. Keep in mind that CSC-PE is already performing PE functionality within its own AS.
The CSC scenarios can get more and more complicated as hierarchy grows and can get very lengthy to explain with words, especially if you need to know all the details of how routing information is distributed, how labels are assigned and distributed and how forwarding is actually performed end-to-end.
Since a picture is worth a thousand words, for more details, you might like to take a look at the following feature guide from IOS 12.2S (which is a quite good online description of how things work):
There are also some good books from cisco press that have details (MPLS and VPN architectures volumes I, II and if you have MPLS Fundamentals you can download the online chapter for MPLS VPNs from cisco press website).
Irrespective of the actual details, the bottom line for me is this: people discovered the label-stack trick to keep particular routers ignorant of some type of routing information and still manage to forward traffic correctly by using some other type of information that they can more easily have. The same trick can be applied in various cases. Also, if you take a look at the additional configuration required for CSC as compared to the non-CSC case, you will see that it is a lot less lengthy than the explanations of CSC (can't say if the additional work for software developers to support CSC was of equal small length though :-).
>> Irrespective of the actual details, the bottom line for me is this: people discovered the label-stack trick to keep particular routers ignorant of some type of routing information and still manage to forward traffic correctly by using some other type of information that they can more easily have. The same trick can be applied in various cases
This is the key point adding value and information to label stack depth
the objective of Carrier Supporting Carrier is to allow the Sub-Carrier to provide MPLS services going through the top provider network.
To be able to provide a L3 VPN service to a sub-carrier customer an end-to-end LSP must exist between the two PE routers of sub-provider.
From this comes the need for a LDP relationship between CSC-PE and CSC-CE: you need an LSP from CSC-CE1 to CSC-CE2 (or more extended)
The VPN label cannot be exposed to top-provider so the frame from CSC-CE1 to CSC-CE2 needs to have already a two label stack.
Inside TOP provider network a 3 labels stack is used.
Hope to help
Devang & Maria,
Just wanted to add the following:
The "Customer Carrier" could be:
2- MPLS VPN customer.
The Forwarding works similar to the forwarding mechanism in Normal PE routers. The CSC-CE has to implement IBGP between their geograohically seperated sites connected by the "Backbone Carrrier" , Because the ISP could carry Full Internet Routes , more than 100.000 routes , this doesnt scale and Only internal routes should be propagated between Both Carriers.
The External routes are not propagated, ONLY the Internal routes to reach the Egress and Ingress CSC-CE routers is carried out. LDP and MPLS has to be enabled on the CSC-CE and the required Memory should be minimum of 256 DRAM on the CSC-CE.
The VPNV4 Session between the CSC-CE routers carries labeled routes (IP + MPLS labels).
The required routing protocl between CSC-CE router and CSC-PE router supports RIP , OSPF , STatic.
The CSC is very Scalable Solution and both Carriers benefit from this solution.
The CSC-CE could implement IPsec between their Sites, and they dont need a dedicated links betweeen their Sites.
When someone first reads about CSC it seems that it only applies if the customer of the backbone provider is an ISP. I am not sure what you meant by "MPLS VPN customer", because the relevant documentation scenarios refer to a customer carrier that also provides MPLS VPN services to its own customers or a customer carrier that just runs MPLS and has no MPLS VPN customers. Irrespectively if you were referring to the usual documentation description or not, I believe that CSC is a solution that can also apply for a non-ISP customer of an MPLS VPN backbone provider in order to keep routes in CSC-PEs at the minimum. CSC is a scalability solution and can be applied in general (if CE can run MPLS of course).
Regarding the number of routes in the Internet routing table, the last time I checked out they were something less than 280 000 and keep climbing :-)
what I meant by "MPLS VPN customer" and "ISP customer" is that both represent Customer carriers for the Backbon carrier.
The ISP is certainly Internet provider for its own customer and the MPLS VPN provider is also VPN provider for its own customers.
My Point here is , since both are providers , They became a Customer Carrier for the Backbone Carrier when they are interconnected by the provider.