LDM

 

 
Home ] Up ] Competences ] Competence Center ] Partners ] About ] Views ] Site Map ] Search ]
 
History ] Concept ] Frame ] FEC ] Routing ] LPC ] TCM ] DLL ] [ LDM ] QoS ] PF ] SMPLS ]


 

Up

 

Label Distribution Mechanisms

MPLS needs a mechanism for distributing labels in order to set up paths. The architecture does not assume that there will be a single protocol (known as a label distribution protocol, LDP) to complete this task, but rather a number of approaches that can be selected depending on the required characteristics of the LSPs. Where paths relate to certain routes, label distribution could be piggybacked onto routing protocols. Where labels are allocated to the packets of a specific flow, distribution can be included as part of the reservation protocol. New protocols have been developed for general label distribution and the support of explicitly routed paths. MPLS label distribution requires reliability and the sequencing of messages that relate to a single FEC. While some approaches, e.g., RSVP, use protocols that sit directly over IP (thus implying they are unlikely to be able to meet these reliability requirements), a number of the defined LDPs solve this issue by operating over TCP.

Within the MPLS architecture, label distribution binding decisions are generally made by the downstream node, which then distributes the bindings in the upstream direction. This implies that the receiving node allocates the label. However, there are also instances (especially when considering multicast communications) where upstream allocation may also be useful. In terms of the approach to state maintenance used within MPLS, a soft state mechanism is employed, implying that labels will require refreshing in order to avoid timeouts. Approaches to this include the MPLS peer keep-alive mechanism, and the timeout mechanisms inherent within routing and reservation protocols (in instances where they are used to carry out label distribution).

Traffic-engineered and/or QoS-enabled LSPs are conventionally referred to as constraint-routed LSPs (CR-LSPs), because they represent the path that satisfies additional constraints beyond simply being the shortest. The MPLS working group is developing two solutions for signaling such LSPs:

  •     RSVP

  •     LDP

One solution borrows from existing RSVP (M-RSVP); the other adds functionality to the base LDP (CR-LDP). At an abstract level there is a lot of similarity between the functions of the M-RSVP and CR-LDP. Both enable an LER to:

  •     Trigger and control the establishment of an LSP between itself and a remote LER

  •     Strict or loose specification of the route to be taken by the LSP

  •     Specify QoS parameters to be associated with this LSP, leading to specific queuing and scheduling behaviors at every hop

The major difference between these two protocols is the specific mechanisms used to pass their signaling messages from LSR to LSR across the MPLS network. (A strict route specifies every core LSR through which the LSP must transit. Routes may also be loosely defined - some of the transit LSRs are specified, and hops between each specified LSR are discovered using conventional IP routing.)

M-RSVP borrows RSVP's refreshed-soft-state model of regular PATH and RESV messages, defining it for use between two LERs. The exchange of PATH and RESV messages between any two LSRs establishes a label association with specific forwarding requirements. The concatenation of these label associations creates the desired edge-to-edge LSP.

CR-LDP defines a hard-state signaling protocol, extending the control messages inherent in basic LDP to enable a per-hop label association function similar to that achieved by M- RSVP.

A comparison of these two schemes is depicted in Table 3 and 4. It is important to note that the true value of MPLS cannot be realized unless one of these two protocols is deployed. It appears likely that both solutions will move to the standards track within the MPLS Working Group.

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 setup and maintenance

Request and Mapping

Path, Resv, and ResvConf

Base architecture

Based on LDP developed for MPLS

Based on RSVP, but may require major changes to the basic protocol to improve its scalability.

Table 3 - Signaling architectures of CR-LDP and RSVP.

Category

CR-LDP

RSVP

Signaling of QoS and traffic parameters

Can signal DiffServ and ATM traffic classes

Extendable; currently based on IntServ traffic classes

Types of CR-LSPs

Strict, loose, and loose pinned

Strict and loose; no pinning

Modes of label distribution and LSP setup

Easy to support all modes since CR-LDP is based on LDP

Only downstream on demand; need to run both RSVP and LDP 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 alternate paths at every node

Loop detection/prevention

LDP employs Path Vector TLV to prevent Label Request messages from looping. Hop Count TLV is used to find looping LSPs.

May be done using the Record Route object

Path optimization and rerouting

LSP ID can be used to prevent double booking of bandwidth for an LSP when doing "make-before-break'

Shared explicit filter prevents double booking of bandwidth for an LSP when doing "make-before-break"

Table 4 - Signaling support for traffic engineering features in CR-LDP and RSVP.

 

 

 
 
 
 
 
 
 
 
 
 
 
 
 

Home ] Up ] Competences ] Competence Center ] Partners ] About ] Views ] Site Map ] Search ]

History ] Concept ] Frame ] FEC ] Routing ] LPC ] TCM ] DLL ] [ LDM ] QoS ] PF ] SMPLS ]

 

 

Challange TACS - Solution TACS

 

 

The Best Networks Start with the Best Consultants - TACS

 

 

Copyright © 2023 TACS
Last modified: September 20, 2023