RFC 3214 (rfc3214) - Page 3 of 11

LSP Modification Using CR-LDP

RFC 3214             LSP Modification Using CR-LDP          January 2002


   presented.  The concept of LSPID in CR-LDP is used to achieve the LSP
   modification, without releasing the LSP and interrupting the service
   and, without double booking the bandwidth.  In Section 4, an example
   is described to demonstrate an application of the presented method in
   dynamically managing network bandwidth requirements without
   interrupting service.  In CR-LDP, an action indicator flag of
   _modify_ is used in order to explicitly specify the behavior, and
   allow the existing LSPID to support other networking capabilities in
   the future.  Reference [3], RFC XXXX, specifies the action indicator
   flag of _modify_ for CR-LDP.

3. LSP Modification Using CR-LDP

3.1 Basic Procedure for Resource Modification

   LSP modification can only be allowed when the LSP is already set up
   and active. That is, modification is not defined nor allowed during
   the LSP establishment or label release/withdraw phases.  Only
   modification requested by the ingress LSR of the LSP is considered in
   this document for CR-LSP.  The Ingress LSR cannot modify an LSP
   before a previous modification procedure is completed.

   Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique in
   the MPLS network.  The ingress LSR R1 of L1 has in its FTN (FEC To
   NHLFE) table FEC1 -> Label A mapping where A is the outgoing label
   for LSP L1.  To modify the characteristics of L1, R1 sends a Label
   Request Message.  In the message, the TLVs will have the new
   requested values, and the LSPID TLV is included which indicates the
   value of L-id1.  The Traffic Parameters TLV, the ER-TLV, the Resource
   Class (color) TLV and the Preemption TLV can have values different
   from those in the original Label Request Message, which  has been
   used to set up L1 earlier.  Thus, L1 can be changed in its bandwidth
   request (traffic parameter TLV), its traffic service class (traffic
   parameter TLV), the route it traverses (ER TLV) and its setup and
   holding (Preemption TLV) priorities. The ingress LSR R1 now still has
   the entry in its FTN as FEC1 -> Label A.  R1 is waiting to establish
   another entry for FEC1.

   When an LSR Ri along the path of L1 receives the Label Request
   message, its behavior is the same as that of receiving any Label
   request message.  The only extension is that Ri examines the LSPID
   carried in the Label Request Message, L-id1, and identifies if it
   already has L-id1.  If Ri does not have L-id1, Ri behaves the same as
   receiving a new Label Request message.  If Ri already has L-id1, Ri
   takes the newly received Traffic Parameter TLV and computes the new
   bandwidth required and derives the new service class.  Compared with
   the already reserved bandwidth for L-id1, Ri now reserves only the
   difference of the bandwidth requirements. This prevents Ri from doing



Ash, et al.                 Standards Track