RFC 3214 (rfc3214) - Page 3 of 11
LSP Modification Using CR-LDP
Alternative Format: Original Text Document
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
