I was recently asked: Is it possible to eliminate the use / enabling of LDP in MPLS networks while using RSVP for MPLS Traffic Engineering?
The only response I could hack-up at that point in time is the following:
Theoretically, for TE, RSVP with TE extensions takes care of the distribution of the MPLS labels and we do not need to configure Label Distribution Protocol (LDP) on the interfaces. Therefore, the MPLS network does not strictly need to have "mpls ip" on the interfaces, if TE is deployed. However, if you do not deploy TE to carry ALL traffic from ingress LSRs to egress LSRs ( for example, http://wiki.nil.com/MPLS_Traffic_Engineering_in_MPLS_VPN_environment), then you need LDP to avoid unlabeled traffic in the core network. MPLS VPN traffic, for instance, needs to be labeled at all times in the core network or it can demonstrate "unpredicable behaviour".
One of the problems of having a mix of RSVP and non-RSVP (LDP) traffic on a link is that bandwidth accounting is liable to break. A common misconception is that RSVP traffic is somehow special because it was set up with Resource Reservations. This is not true. The RSVP reservation exists in control plane only and no forwarding resources are actually set aside for it.
Inside Cisco IOS, a TE database is built from the TE information that the link state protocol sends. This dataset contains all the links that are enabled for MPLS TE and their characteristics or attributes. From this MPLS TE database, path calculation (PCALC) or constrained SPF (CSPF) calculates the shortest route that still adheres to all the constraints (most importantly the bandwidth) from the head end LSR to the tail end LSR. PCALC or CSPF is a shortest path first (SPF) algorithm modified for MPLS TE, so that constraints can be taken into account. The bandwidth available to TE and the attributes are configurable on all links of the networks. You configure the bandwidth requirement and attributes of the TE tunnel on the tunnel configuration of the head end LSR. PCALC matches the bandwidth requirement and attributes of the TE tunnel with the ones on the links, and from all possible paths, it takes the shortest one. The calculation is done on the head end LSR.
The intermediate LSRs on the LSP need to know what the incoming and outgoing labels are for the particular LSP for that TE tunnel. The intermediate LSRs can only learn the labels if the headend router and intermediate LSRs signal the labels by a signaling protocol. In the past, two signaling protocols were proposed: RSVP with extensions for TE (RSVP-TE) and constraintbased LDP (CR-LDP). Cisco IOS has RSVP with extensions for signaling MPLS TE tunnels and never had an implementation of CR-LDP. At the Internet Engineering Task Force (IETF),consensus was reached to carry on with developing RSVP as the signaling protocol for MPLS TE and to stop further development on CR-LDP. This was documented in RFC 3468, “The Multiprotocol Label Switching (MPLS) Working Group Decision on MPLS Signaling Protocols.”
The following is a quotation from the abstract of that RFC:
“This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on “Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels” (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to “Constraint-Based LSP Setup using Label Distribution Protocol (LDP)” (RFC 3212).”
References:
- MPLS Fundamentals by Luc de Ghein, Cisco Press
No comments:
Post a Comment