idnits 2.17.00 (12 Aug 2021) /tmp/idnits5494/draft-ash-crlsp-modify-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '..., which has b...' == Line 144 has weird spacing: '... to impleme...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1999) is 8339 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 20 looks like a reference -- Missing reference section? '2' on line 38 looks like a reference -- Missing reference section? '3' on line 40 looks like a reference -- Missing reference section? '4' on line 60 looks like a reference -- Missing reference section? '5' on line 208 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS WG J. Ash 2 Internet Draft Y. Lee 3 Document: draft-ash-crlsp-modify-00.txt AT&T 5 P. Ashwood-Smith 6 B. Jamoussi 7 L. Li 8 D. Fedyk 9 D. Skaleki 10 Nortel Networks 12 July 1999 14 LSP Modification Using CR-LDP 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [1]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1. Abstract 36 After a CR-LSP is set up, its bandwidth reservation may need to be 37 changed by the network operator, due to the new requirements for the 38 traffic carried on that CR-LSP [2]. This contribution presents an 39 approach to modify the bandwidth and possibly other parameters of an 40 established CR-LSP using CR-LDP [3] without service interruption. 41 The LSP modification feature can be supported by CR-LDP with a minor 42 extension of an _action indicator flag_. This feature has 43 application in dynamic network resources management where traffic of 44 different priorities and service classes is involved. 46 2. Conventions used in this document 48 L: LSP (Label Switched Path) 49 Lid: LSPID (LSP Identifier) 50 T: Traffic Parameters 51 R: LSR (Label Switching Router) 52 FTN: FEC To NHLFE 53 FEC: Forwarding Equivalence Class 54 NHLFE: Next Hop Label Forwarding Entity 55 TLV: Type Length Value 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC-2119 [4]. 61 3. Introduction 63 Consider an LSP L1 that has been established with its set of traffic 64 parameters T0. A certain amount of bandwidth is reserved along the 65 path of L1. Consider then that some changes are required on L1. For 66 example, the bandwidth of L1 needs to be increased to accommodate 67 the increased traffic on L1. Or the SLA associated with L1 needs to 68 be modified because a different service class is desired. The 69 network operator, in these cases, would like to modify the 70 characteristics of L1, for example, to change its traffic parameter 71 set from T0 to T1, without releasing the LSP L1 to interrupt the 72 service. In some other cases, network operators may want to reroute 73 a CR-LSP to a different path for either improved performance or 74 better network resource utilization. In all these cases, LSP 75 modification is required. In section 4 below, a method to modify an 76 active LSP using CR-LDP is presented. The concept of LSPID in CR-LDP 77 is used to achieve the LSP modification, without releasing the LSP 78 and interrupting the service and, without double booking the 79 bandwidth. Only a minimum extension on CR-LDP, an action indication 80 flag of _modify_ is needed in order to explicitly specify the 81 behavior, and allow the existing LSPID to support other networking 82 capabilities in the future. Section 5 specifies the action 83 indication flag of _modify_ for CR-LDP. In the appendix, an example 84 is described to demonstrate an application of the presented method 85 in dynamically managing network bandwidth requirements without 86 interrupting service. 88 4. LSP Modification Using CR-LDP 90 4.1 Basic Procedure 92 LSP modification can only be allowed when the LSP is already set up 93 and active. That is, modification is not defined nor allowed during 94 the LSP establishment or label release/withdraw phases. Only 95 modification requested by the ingress LSR of the LSP is considered 96 in this draft for CR-LSP. Ingress LSR cannot modify an LSP before a 97 previous modification procedure is completed. 99 Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique in 100 the MPLS network. The ingress LSR R1 of L1 has in its FTN (FEC To 101 NHLFE) table FEC1 -> Label A mapping where A is the outgoing label 102 for LSP L1. To modify the characteristics of L1, R1 sends a Label 103 Request Message. In the messages, the TLVs will have the new 104 requested values, and the LSPID TLV is included which indicates the 105 value of L-id1. The Traffic Parameters TLV, the ER-TLV, the Resource 106 Class (color) TLV and the Preemption TLV can have values different 107 from those in the original Label Request Message, which has been 108 used to set up L1 earlier. Thus, L1 can be changed in its bandwidth 109 request (traffic parameter TLV), its traffic service class (traffic 110 parameter TLV), the route it traverses (ER TLV) and its setup and 111 holding (Preemption TLV) priorities. The ingress LSR R1 now still 112 has the entry in FTN as FEC1 -> Label A. R1 is waiting to establish 113 another entry for FEC1. 115 When an LSR Ri along the path of L1 receives the Label Request 116 message, its behavior is the same as that of receiving any Label 117 request message. The only extension is that Ri examines the LSPID 118 carried in the Label Request Message, L-id1 and identifies if it 119 already has L-id1. If Ri does not have L-id1, Ri behaves the same as 120 receiving a new Label Request message. If Ri already has L-id1, Ri 121 takes the newly received Traffic Parameter TLV and computes the new 122 bandwidth required and derives the new service class. Compared with 123 the already reserved bandwidth for L-id1, Ri now reserves only the 124 difference of the bandwidth requirements. This prevents Ri from 125 doing bandwidth double booking. If a new service class is requested, 126 Ri also prepares to receive the traffic on L1 in, perhaps a 127 different type of queue, just the same as handling it for a Label 128 Request Message. Ri assigns a new label for the Label Request 129 Message. 131 When the Label Mapping message is received, two sets of labels exist 132 for the same LSPID. Then the ingress LSR R1 will have two outgoing 133 labels, A and B, associated with the same FEC, where B is the new 134 outgoing label received for LSP L1. The ingress LSR R1 can now 135 activate the new entry in FTN, FEC1 - > Label B. This means that R1 136 swaps traffic on L1 to the new label _B_ (_new_ path) for L1. The 137 packets can now be sent with the new label B, with the new set of 138 traffic parameters if any, on a new path, that is, if a new path is 139 requested in the Label Request Message for the modification. All the 140 other LSRs along the path will start to receive the incoming packets 141 with the new label. For the incoming new label, the LSR has already 142 established its mapping to the new outgoing label. Thus, the packets 143 will be sent out with the new outgoing label. The LSRs do not have 144 to implement new procedures to track the new and old 145 characteristics of the LSP. 147 The ingress LSR R1 then starts to release the original label A for 148 LSP L1. The Label Release Message is sent by R1 towards the down 149 stream LSRs. The Release message carries the LSPID of L-id1 and the 150 Label TLV to indicate which label is to be released. The Release 151 Message is propagated to the egress LSR to release the original 152 labels previously used for L1. Upon receiving the Label Release 153 Message, LSR R1 examines the LSPID, L-id1 and finds out that the L- 154 id1 has still another set of label (incoming/outgoing) under it. 156 Thus, the old label is released without releasing the resource in 157 use. That is, if the bandwidth has been decreased for L1, the delta 158 bandwidth is released. Otherwise, no bandwidth is released. This 159 modification procedure can not only be applied to modify the traffic 160 parameters and/or service class of an active LSP, but also to 161 reroute an existing LSP, and/or change its setup/holding priority if 162 desired. After the release procedure, the modification of the LSP is 163 completed. 165 The method described above follows the normal behavior of Label 166 Request / Mapping / Notification / Release /Withdraw procedure of a 167 CR-LDP operated LSR with a specific action taken on LSPID. If Label 168 Withdraw Message is used to withdraw a label associated with an 169 LSPID, the Label TLV should be included to specify which label to 170 withdraw. Since the LSPID can also be used for other feature 171 support, an action indication flag of _modify_ assigned to the LSPID 172 would explicitly explain the action/semantics that should be 173 associated with the messaging procedure. The details of this flag 174 are addressed in Section 3 below. 176 4.2 Priority Handling 178 When sending a Label Request Message for an active LSP L1 to request 179 changes, the setup priority used in the label Request Message can be 180 different from the one used in the previous Label Request Message, 181 effectively indicating the priority of this _modification_ request. 182 Network operators can use this feature to decide what priority is to 183 be assigned to a modification request, based on their 184 policies/algorithms and other traffic situations in the network. For 185 example, the priority for modification can be determined by the 186 priority of the customer/LSP. If a customer has exceeded the 187 reserved bandwidth of its VPN LSP tunnel by too much, the 188 modification request's priority may be given higher. 189 The Label Request message for the modification of an active LSP can 190 also be sent with a holding priority different from its previous 191 one. This effectively changes the holding priority of the LSP. Upon 192 receiving a Label Request Message that requests a new holding 193 priority, the LSR assigns the new holding priority to the bandwidth. 194 That is, the new holding priority is assigned to both the existing 195 incoming / outgoing labels and the new labels to be established for 196 the LSPID in question. In this way self-bumping is prevented. 198 4.3 Modification Failure Case Handling 200 A modification attempt may fail due to insufficient resource or 201 other situations. A Notification message is sent back to the ingress 202 LSR R1 to indicate the failure of Label Request Message that 203 intended to modify the LSP. Retry may be attempted if desired by the 204 network operator. 206 If the LSP on the original path failed when a modification attempt 207 is in progress, the attempt should be aborted by using the Label 208 Abort Request message as specified in LDP draft [5]. 210 5. Proposed Extensions to CR-LDP for CR-LSP Modification 212 5.1 _Action indicator Flag_ in LSPID TLV 214 As LSPID can be used for other purpose as well, for example, for LSP 215 merge or stacking, etc. which are not intended to be covered here, 216 an _action indicator flag_ is proposed to be carried in the LSPID 217 TLV. This _action indicator flag_ shows explicitly the action that 218 should be taken if the LSP already exists on the LSR receiving the 219 message. The indicator flag can take 4 bits (right most 4 bits) out 220 of the two reserved bytes in the LSPID TLV. A set of indicator code 221 points is proposed as follows: 223 0001: modify 225 The procedure for code point _modify_ is defined as in the above 226 section 2.1. The procedures for others are for future work. 228 5.2 New Status Code 230 Status code Type 231 Modify request not supported 0x04000008 233 This error code can be used to indicate that for some reason, the 234 modification attempt on the given LSPID is not allowed by the LSR. 235 For example, this can be an attempt that is sent out too soon after 236 last modification, before the LSR has completed the procedures in 237 the last modification attempt. 239 6. Intellectual Property Consideration 241 Nortel Networks may seek patent or other intellectual property 242 protection for some or all of the technologies disclosed in this 243 document. If any standards arising from this document are or become 244 protected by one or more patents assigned to Nortel Networks, Nortel 245 Networks is prepared to make a license available to any qualified 246 applicant upon reasonable and non-discriminatory terms and 247 conditions. Any such licenses will be subject to negotiations 248 outside of the IETF. 250 7. Security Considerations 252 No security issues are addressed in this draft. 254 8. References 255 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 256 9, RFC 2026, October 1996. 258 2 Ash, J., et. al., QoS Resource Management in MPLS-Based Networks, 259 draft-ash-qos-routing-00.txt, (work in progress). 261 3 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 262 draft-ietf-mpls-cr-ldp-01.txt, February 1999,(work in progress). 264 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 265 Levels", BCP 14, RFC 2119, March 1997. 267 5 Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp- 268 05.txt (work in progress) 270 9. Author's Addresses 272 Gerald R. Ash Young Lee 273 AT&T AT&T 274 Room MT E3-3C37 Room MT E3-3A04 275 200 Laurel Avenue 200 Laurel Avenue 276 Middletown, NJ 07748 Middletown, NJ 07748 277 USA USA 278 Phone: 732-420-4578 Phone: 732-420-4477 279 Fax: 732-440-6687 Fax: 732-440-6697 280 Email: gash@att.com Email: younglee@att.com 282 Bilel Jamoussi 283 Nortel Networks Corp. 284 3 Federal Street 285 Billerica, MA 01821 286 USA 287 phone: 978-288-4506 288 Email: jamoussi@NortelNetworks.com 290 Peter Ashwood-Smith Li Li 291 Nortel Networks Corp. Nortel Networks Corp. 292 P O Box 3511 Station C P O Box 3511 Station C 293 Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7 294 Canada Canada 295 Phone: +1 613 763-4534 phone: +1 613 765 3088 296 Email: petera@NortelNetworks.com lili@nortelnetworks.com 298 Darek Skalecki Don Fedyk 299 Nortel Networks Corp. Nortel Networks Corp. 300 P O Box 3511 Station C P O Box 3511 Station C 301 Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7 302 Canada Canada 303 phone: +1 613 765-2252 phone: +1 613 763 3268 304 Email: skalecki@NortelNetworks.com fedyk@nortelnetworks.com 305 Appendix 307 Application of LSP Bandwidth Modification in Dynamic Resource 308 Management 310 In this section, we gave an example of dynamic network resource 311 management using the LSP bandwidth modification capability. The 312 details of this example can be found in a previous Internet draft 313 presented in the last meeting. Assume that customers are assigned 314 with their CR-LSPs. These customers' are assigned with one of the 315 priorities as key, normal or best effort. The network operator 316 doesn't want to bump any LSPs during an LSP setup, so after these 317 CR-LSPs are set up, their holding priority are all assigned as the 318 highest. 320 The network operator wants to control the resource on the links of 321 LSRs, so all LSRs keep the usage status of its links and based on 322 the usage history, each link is assigned a current threshold 323 priority Pi. Which means that the link has no bandwidth available 324 for Label Request with a setup priority lower than Pi. When a LSP's 325 bandwidth needs to be modified, the operator uses policy based 326 algorithm to assign a priority for its modification request, say Mp 327 for LSP L2. Then the ingress LSR sends Label Request message with 328 (Setup Priority = Mp). The rule is then only if there is enough 329 bandwidth on the link and, the Setup priority in the Label Request 330 Message is higher in priority (Mp numerically smaller) than Pi of 331 the link, the Label Request Message will be accepted by the LSR. 332 Otherwise, the Label Request message will be rejected with a 333 Notification message indicates that there isn't enough resources. It 334 should also be note that when OSPF (or IS-IS) floods the link 335 available bandwidth information, the available bandwidth associated 336 with priority lower than Pi (numerical value bigger) should be 337 indicated as _0_. This procedure based on a priority threshold Pi is 338 implementation specific and value added. It offers networks 339 flexibility to prioritize and control its resources. 341 The calculation of Mp is network dependent, based on operator's own 342 algorithm. For example, the operator may assign a higher Mp to L2 if 343 L2 belongs to a customer with _Key_ priority. The operator may also 344 collect the actual usage of each LSP and assign a high Mp to L2 if 345 in the past week, L2 has exceeding its reserved bandwidth by 2 times 346 on the average, and the customer of L2 agrees to increase its 347 bandwidth for a better guaranteed service. Some operator may try to 348 increase the bandwidth of L2 on its existing path unsuccessfully as 349 there isn't enough bandwidth there. Then the operator is willing to 350 change the path of L2 in order to increase its bandwidth, but with a 351 lower priority Mp this time as L2 now is routed on its secondary 352 path, which should yield priority to the LSPs that are on its 353 primary paths here. 355 Full Copyright Statement 357 "Copyright (C) The Internet Society (date). All Rights Reserved. 358 This document and translations of it may be copied and furnished to 359 others, and derivative works that comment on or otherwise explain it 360 or assist in its implmentation may be prepared, copied, published 361 and distributed, in whole or in part, without restriction of any 362 kind, provided that the above copyright notice and this paragraph 363 are included on all such copies and derivative works. However, this 364 document itself may not be modified in any way, such as by removing 365 the copyright notice or references to the Internet Society or other 366 Internet organizations, except as needed for the purpose of 367 developing Internet standards in which case the procedures for 368 copyrights defined in the Internet Standards process must be 369 followed, or as required to translate it into