Network Working Group J. Ash Request for Comments: 3214 AT&T Category: Standards Track Y. Lee Ceterus Networks P. Ashwood-Smith B. Jamoussi D. Fedyk D. Skalecki Nortel Networks L. Li SS8 Networks January 2002 LSP Modification Using CR-LDP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The LSP modification feature can be supported by CR-LDP by use of the _modify_value for the _action indicator flag_ in the LSPID TLV. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.
1. Conventions Used in This Document ............................ 2 2. Introduction ................................................. 2 3. LSP Modification Using CR-LDP ................................ 3 3.1 Basic Procedure for Resource Modification .................. 3 3.2 Rerouting LSPs ............................................. 5 3.3 Priority Handling .......................................... 6 3.4 Modification Failure Case Handling ......................... 6 4. Application of LSP Bandwidth Modification in Dynamic Resource Management ................................................... 7 5. Acknowledgments .............................................. 8 6. Intellectual Property Considerations ......................... 8 7. Security Considerations ...................................... 8 8. References ................................................... 8 9. Authors' Addresses ........................................... 9 10. Full Copyright Statement ..................................... 11 RFC 2119 . section 3 below, a method to modify an active LSP using CR-LDP is
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 , RFC XXXX, specifies the action indicator flag of _modify_ for CR-LDP.
bandwidth double booking. If a new service class is requested, Ri also prepares to receive the traffic on L1 in just the same way as handling it for a Label Request Message, perhaps using a different type of queue. Ri assigns a new label for the Label Request Message. When the Label Mapping message is received, two sets of labels exist for the same LSPID. Then the ingress LSR R1 will have two outgoing labels, A and B, associated with the same FEC, where B is the new outgoing label received for LSP L1. The ingress LSR R1 can now activate the new entry in its FTN, FEC1 - > Label B. This means that R1 swaps traffic on L1 to the new label _B_ (_new_ path) for L1. The packets can now be sent with the new label B, with the new set of traffic parameters if any, on a new path, that is, if a new path is requested in the Label Request Message for the modification. All the other LSRs along the path will start to receive the incoming packets with the new label. For the incoming new label, the LSR has already established its mapping to the new outgoing label. Thus, the packets will be sent out with the new outgoing label. The LSRs do not have to implement new procedures to track the new and old characteristics of the LSP. The ingress LSR R1 then starts to release the original label A for LSP L1. The Label Release Message is sent by R1 towards the down stream LSRs. The Release message carries the LSPID of L-id1 and the Label TLV to indicate which label is to be released. The Release Message is propagated to the egress LSR to release the original labels previously used for L1. Upon receiving the Label Release Message, LSR Ri examines the LSPID, L-id1, and finds out that the L- id1 has still another set of labels (incoming/outgoing) under it. Thus, the old label is released without releasing the resource in use. That is, if the bandwidth has been decreased for L1, the delta bandwidth is released. Otherwise, no bandwidth is released. This modification procedure can not only be applied to modify the traffic parameters and/or service class of an active LSP, but also to reroute an existing LSP (as described in Section 3.2 below), and/or change its setup/holding priority if desired. After the release procedure, the modification of the LSP is completed. The method described above follows the normal behavior of Label Request / Mapping / Notification / Release / Withdraw procedure of a CR-LDP operated LSR with a specific action taken on an LSPID. If a Label Withdraw Message is used to withdraw a label associated with an LSPID, the Label TLV should be included to specify which label to withdraw. Since the LSPID can also be used for other feature support, an action indication flag of _modify_ assigned to the LSPID would explicitly explain the action/semantics that should be associated with the messaging procedure. The details of this flag are addressed in the CR-LDP document, Reference .
section 3.1. At another LSR Rj further along the path, the explicit route diverges from the previous route. Rj acts as Ri, but forwards the Label Request message along the new route. From this point onwards the Label Request Message is treated as setting up a new LSP by each LSR until the paths converge at later LSR Rk. The _modify_ value of the action indication flag is ignored. At Rk and subsequent LSRs, the Label Request Message is handled as at Ri. On the return path, when the Label Mapping message is received, two sets of labels for the LSPID exist where the new route coincide with the old. Only one set of labels will exist at LSRs where the routes diverge. When the Label Mapping message is received at the ingress LSR R1 it has two outgoing labels, A and B, associated with the same FEC, where B is the new outgoing label received for LSP L1. R1 can now activate the new entry in the FTN, FEC1 - > Label B and de-activate the old entry FEC1 - > Label A. This means that R1 swaps traffic on L1 to the new label B. The packets are now sent with the new label B, on the new path.
The ingress LSR R1 then starts to release the original label A for LSP L1. The Label Release Message is sent by R1 towards the down stream LSRs following the original route. The Release message carries the LSPID of L-id1 and the Label TLV to indicate which label is to be released. At each LSR the old label is released - no further action is required to change the path of the data packets which are already following the new route programmed by the Label Mapping message. At some LSRs, where the routes diverged, there is only one label for the LSPID. For example, between Rj and Rk, the Label Release Message will follow the old route. At LSRs between Rj and Rk only the labels from the original route will exist for LSPID L-id1. At these LSRs the LSPID TLV does not need to be examined to release the correct label, but it must still be updated and passed on to the next LSR as the Label Release message is propagated. In this way, at Rk where the routes converge, the downstream LSR will know which label to release and can continue to forward the Label Release Message along the old route.
operator. If the LSP on the original path failed when a modification attempt is in progress, the attempt should be aborted by using the Label Abort Request message as specified in the LDP document . In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values. 2]. Assume that customers or services are assigned with given CR- LSPs. These customers/services are assigned with one of three priorities: key, normal or best effort. The network operator does not want to bump any LSPs during an LSP setup, so after these CR-LSPs are set up, their holding priorities are all assigned as the highest value. The network operator wants to control the resource on the links of the LSRs, so each LSR keeps the usage status of its links. Based on the usage history, each link is assigned a current threshold priority Pi, which means that the link has no bandwidth available for a Label Request with a setup priority lower than Pi. When an LSP's bandwidth needs to be modified, the operator uses a policy-based algorithm to assign a priority for its modification request, say Mp for LSP L2. The ingress LSR then sends a Label Request message with Setup Priority = Mp. If there is sufficient bandwidth on the link for the modification, and the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than the Pi threshold of the link, the Label Request Message will be accepted by the LSR. Otherwise, the Label Request message will be rejected with a Notification message which indicates that there are insufficient resources. It should also be noted that when OSPF (or IS-IS) floods the available-link-bandwidth information, the available bandwidth associated with a priority lower than Pi (numerical value bigger) should be interpreted as _0_. This example based on a priority threshold Pi is implementation specific, and illustrates the flexibility of the modification procedure to prioritize and control network resources. The calculation of Mp can be network and service dependent, and is based on the operator's routing policy. For example, the operator may assign a higher priority (lower Mp value) to L2 bandwidth modification if L2 belongs to a customer or service with _Key_ priority. The operator may also collect the actual usage of each LSP
and assign a lower priority (higher Mp) to L2 bandwidth-increase modification if, for example, in the past week L2 has exceeded its reserved bandwidth by 2 times on the average. In addition, an operator may try to increase the bandwidth of L2 on its existing path unsuccessfully if there is insufficient bandwidth available on L2. In that case, the operator is willing to increase the bandwidth of another LSP, L3, with the same ingress/egress LSRs as L2, in order to increase the overall ingress/egress bandwidth allocation. However, in this case the L3 bandwidth modification is performed with a lower priority (higher Mp value) since L3 is routed on a secondary path, which results in the higher bandwidth allocation priority being given to the LSPs that are on their primary paths .  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Ash, J., "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-Based Multiservice Networks", Work in Progress.  Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint- based LSP Setup Using LDP", RFC 3212, January 2002.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.  Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Ash, J., Girish, M., Gray, E., Jamoussi,B. and G. Wright, "Applicability Statement for CR-LDP", RFC 3213, January 2002.
Darek Skalecki Nortel Networks Corp. P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 765-2252 EMail: firstname.lastname@example.org Young Lee Ceterus Networks EMail: email@example.com Li Li SS8 Networks 495 March Rd., 5th Floor Kanata, Ontario K2K 3G1 Canada Phone: +1 613 592-2100 ext. 3228 EMail: firstname.lastname@example.org Don Fedyk Nortel Networks Corp. 600 Tech Park Billerica, MA 01821 USA Phone: 978-288-3041 EMail: email@example.com
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.