I want to share some brief notes about two protocols used for setting up the LSP in MPLS: LDP and RSVP protocols.
LDP is the youngest one. Was created explicitly to distribute labels and it’s not an extension or added functionality to a relatively old protocol like in the RSVP.
LDP is designed to be highly extensible, using TLV triplets to be able to transport multiple additional fields in the future and warrantee the compatibility with previous versions via ignoring the unknown new fields.
LDP is highly flexible, as supports local and remote neighbors (using targeted LDP sessions). This flexibility allows an LSR to exchange label information with local and remote peers which enables it to support the engineering of multiple services and functionalities like LDP session protection.
LDP is a reliable protocol, because it uses TCP as transport. Only the neighbor discovery and maintenance is performed using UDP. The incremental updates functionality is a point in favor of its scalability.
Now you are being thinking: If LDP is so reliable, extensible, functional and scalable, why do we even think about using an alternative to it in the MPLS core to do the job of setting up the labeled switched paths? Well, it follows the explanation:
LDP follows the IGP in the decisions the later takes. The price to pay for that decision is loss of stability of the LSPs that LDP set up.
- Instability: if the IGP changes, the LDP will change with it, but late. LDP could set up instable LSPs in the network.
- Convergence: the convergence events that happens on every network are inherited by LDP and that could lead to data loss or looping conditions. The convergence time of the IGP will set a lower convergence time limit to LDP and to the LSPs (not considering LDP FRR capabilities yet).
- Race conditions: race conditions may always appear when two protocols interact in an unsynchronized way, and that may leads to data loss.
RSVP protocol was developed to support the IntServ QoS model resource reservations for each flow that demands specific QoS requirements as it traverses the network. Original RSVP does not scale very well because the number of end to end sessions that the intermediate devices must support may grow very fast in the SP core as more flows require QoS reservations, and that affects the control plane state that devices must support.
The extension performs scalability by aggregation, but… of what? It aggregates multiple flows of data into one LSP in a way that 1 RSVP session set up 1 LSP that can transport multiple flows of data. As the amount of state on each node of the network is proportional to the number of LSPs traversing the node, aggregation alleviates (that does not solve) the problem of scalability.
The path reservation is initiated by the ingress LSR using Path and Resv messages. The Path message travels from ingress LSR (head-end) to egress LSR (tail-end) and the Resv in the opposite direction.
- RSVP Path
- Label request
- ERO (Explicit Route Object, explicit route)
- RRO (Recorded Route Object, loop avoidance)
- Tspec (Bandwidth Reservation, QoS requirements)
- RSVP Resv
- Label object (Assigned Label)
- RRO (Loop avoidance)
One of the most advantage, RSVP does not follow the IGP, and that allows the head-end to take independent decisions about the traffic flows it reserves.
When to use wich one?
We need to use natively the LDP because as we explained before is a dedicated protocol exclusively for getting LSP paths in MPLS.
However if our networks needs enforce traffic engineering capabilitiies we’ll use RSVP.
LSP Designa Attributes
I you want to exapand your knowledge about MPLS I recommend you this great book:
MPLS Enabled Applications