Latest

Home / MPLS/VPLS / MPLS Constraint-based Routing Label Distribution Protocol- (CR-LDP)

MPLS Constraint-based Routing Label Distribution Protocol- (CR-LDP)

October 23, 2020

 Today i am picking very interesting topic about the MPLS. Some of People are aware of MPLS technology and how it works in the ISP - Internet Service Provider environment but some of them are not aware of the MPLS concept even.

MPLS is a technology that offers to open up the internet by means of offering many additional services to programs using IP. MPLS forwards statistics using labels which are attached to each facts packet. these labels must be dispensed among the nodes that include the network.

So i have a question for you, Can you please let me know how many labels are used in the MPLS environment ? Did you read that ? Well i guess you knew, there are 2 labels used in the MPLS environment, Stress on your mind, which labels ?

Fig 1.1- MPLS Network


Let me remind you the flashbacks of that labels:

  1. One label that is generated by the LSR ( label Switch router ) by using LDP ( Label distribution Protocol )through out the network.
  2. Other label is generated by MP-iBGP protocol which provide the RD and RT information with VPNv4 information.

Hope you remember the concept of RT ( Route Target ) and RD ( Route Distinguisher ) in MPLS domain and you also knew why MP-iBGP used instead of iBGP protocol in MPLS domain ? Remember na ? well i am not touching this topic now, Lets start with the another features in MPLS named as RSVP which creates 3rd Label in MPLS domain.

Most of the new techniques that service Provider want to rely is the Traffic Engineering functions. There is currently LDP that help for Traffic Engineering which includes Resource Reservation Protocol (RSVP) and Constraint-based totally Routed Label Distribution Protocol (CR-LDP).

Even though the these protocols have a similar stage of functionality, the way they work is unique, and the designated function they provide is likewise not consistent. hardware carriers and community providers want clear records to help them decide which protocol to put into effect in a site visitors Engineered MPLS community.

Recognising that the use of LDP is important for the ease of tool manufacturers and network providers, this post actually explains the similarities and wide differences between these two protocols so that you can easily understand and assist to pick out which protocol is the right one to use in a specified networks.

Traffic Engineering may be under the control of manual interventions but they monitor the state of the network and traffic to be route or provision with additional resources so that you can compensate the problems which actually arise in the network. May be you can say that, Traffic Engineering actually driven by automated processes for information to get back through routing protocols or other means.

CR-LDP(Constraint-based Routing Label Distribution Protocol) 
Starting with the concept of CR-LDP first then we can go with the RSVP protocol in another article

Below is the example showing ER-LSP with CR-LDP Setup

Fig 1.2- CR-LDP


CR-LDP is a set of extensions to LDP specifically designed to facilitate constraint-based routing of LSPs. Like LDP, it uses TCP sessions between LSR peers and sends label distribution messages along the sessions. This allows it to assume reliable distribution of control messages. The basic flow for LSP setup using CR-LDP

The Ingress LSR, LSR A, determines that it needs to set up a new LSP to LSR C. The traffic parameters required for the session or administrative policies for the network enable LSR A to determine that the route for the new LSP should go through LSR B, which might not be the same as the hop-by-hop route to LSR C. 

Fig 1.3- Label Request and Mapping


LSR A builds a LABEL_REQUEST message with an explicit route of (B,C) and details of the traffic parameters requested for the new route. LSR A reserves the resources it needs for the new LSP, and then forwards the LABEL_REQUEST to LSR B on the TCP session. 

LSR B receives the LABEL_REQUEST message, determines that it is not the egress for this LSP, and forwards the request along the route specified in the message. It reserves the resources requested for the new LSP, modifies the explicit route in the LABEL_REQUEST message, and passes the message to LSR C. 

If necessary, LSR B may reduce the reservation it makes for the new LSP if the appropriate parameters were marked as negotiable in the LABEL_REQUEST. 

LSR C determines that it is the egress for this new LSP. It performs any final negotiation on the resources, and makes the reservation for the LSP. It allocates a label to the new LSP and distributes the label to LSR B in a LABEL_MAPPING message, which contains details of the final traffic parameters reserved for the LSP. 

LSR B receives the LABEL_MAPPING and matches it to the original request using the LSP ID contained in both the LABEL_REQUEST and LABEL_MAPPING messages.

The processing at LSR A is similar, but it does not have to allocate a label and forward it to an upstream LSR because it is the ingress LSR for the new LSP.