Side_1_360

7.3 RSVP and LDP Overview

As described above, both RSVP and LDP can be
used for establishing LSPs. These protocols are
somewhat different as they were developed for
different purposes. RSVP was developed to sup-
port the IntServ service architecture enabling
an application to signal a request to reserve
resources in the network. On the other hand,
LDP is developed for the particular purpose of
establishing LSPs in the network, i.e. with this
protocol information can be exchanged between
routers about which labels can be used and for
what purposes.

A comparison of Constraint-Based LSP set-up
using LDP (CR-LDP) and LSP set-up using
RSVP is given in Table 2.

The main differences between CR-LSP and
RSVP are that:

• CR-LDP uses TCP whereas RSVP is carried
  directly on IP (or within UDP), which may
  imply that information exchange with CR-
  LDP could be more reliable;
  
  
  • The direction for reserving resources differs
    (i.e. ingress to egress and egress to ingress);
  
  
  • RSVP uses refresh messages for each LSP
    (some work is taken on to change this);
  
  
  • CR-LDP might have more problems dealing
    with failures and requires the rebuilding of
    LSPs on a backup system. RSVP includes
    mechanisms to recover from failures, possibly
    being more fault-tolerant;
  
  
  • Extensions to RSVP for policy management
    have been proposed.
  
  
  
  

8 Concluding Remarks

The main IP-related mechanisms have been out-

lined in this paper. These are promoted to sup-

port a range of services as well as allowing for

ensured service levels (at least to some extent).

Therefore, most providers are investigating

which mechanisms to introduce and how to con-

figure the mechanisms. Another aspect is that

different mechanisms may be preferable in dif-

ferent portions of the network/system. However,

still the end-to-end service is not adequately

delivered. This requires that solutions for map-

Category CR-LDP RSVP

Transport mechanism Transport on TCP (reliable) Raw IP packets (unreliable)

State management Hard state Soft state; needs per-flow refresh management

Messages required for LSP Request, Mapping Path, Resv, ResvConf

set-up and maintenance

Base architecture Based on LDP developed for MPLS Based on RSVP, but may require major changes

to the basic protocol to improve its scalability

Signalling of QoS and Can signal DiffServ and ATM Extendable; currently based on IntServ

traffic parameters traffic classes traffic classes

Types of LSPs Strict, loose and loose pinned Strict and loose, no pinning

Modes of label distribution Easy to support all modes since Only downstream on demand; need to run

and LSP set-up CR-LDP is based on LDP both RSVP and LPD for other modes

Path preemption Supported Supported

Failure notification Reliable procedure Unreliable procedure

Failure recovery Global and local repair Global and local repair; local repair done

using fast-reroute which requires precomputing

alternative paths at every node

Loop detection/prevention LDP employs Path Vector TLV to prevent May be done using the Record Route object

Label Request messages from looping.

Hop Count TLV is used to find looping LSPs

Path optimisation and rerouting LSP id can be used to prevent double Shared explicit filter prevents double booking

booking of bandwidth for an LSP when of bandwidth for an LSP when doing

doing ‘make-before-break’ ‘make-before-break’

Table 2 Comparison of

CR-LDP and RSVP

(from [Ghan99])