idnits 2.17.1 draft-farrel-mpls-preemption-interim-00.txt: 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 61 lines 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 2003) is 7467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3209' is mentioned on line 53, but not defined == Missing Reference: 'SOFT-PREEMPT' is mentioned on line 447, but not defined == Unused Reference: 'RFC2119' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'SOFTPREEMPT' is defined on line 624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2751 (Obsoleted by RFC 3181) == Outdated reference: A later version (-18) exists of draft-ietf-mpls-soft-preemption-01 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel 2 Internet Draft Old Dog Consulting 3 Category: Informational 4 Expires: May 2004 5 November 2003 7 Interim Report on MPLS Pre-emption 9 draft-farrel-mpls-preemption-interim-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full 14 conformance with all provisions of Section 10 of RFC 2026 15 [RFC2026]. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 Abstract 36 This document is an interim report into pre-emption in MPLS systems. 38 At the 58th IETF, the MPLS Working Group determined that there are 39 several interpretations of how pre-emption should be achieved within 40 MPLS systems. This document is the result of the initial enquiries to 41 vendors and other implementors into the question of how and why they 42 offer pre-emption funtion in their MPLS inplementations. 44 This document is intended to be a short-lived document and only 45 exists to document the current findings. It will be superceded or 46 retired. 48 1. Introduction 50 The most recent charter of the MPLS working group includes the work 51 item to develop a solution for "soft pre-emption" within MPLS 52 systems. This work item was contested by some people who regard MPLS 53 signaling (and in particular RSVP-TE as documented by [RFC 3209]) to 54 already include mechanisms for soft pre-emption. 56 A common understanding of the correct behavior during pre-emption 57 will be beneficial to vendors trying to get their hardware to inter- 58 work, and to network operators trying to offer services in networks 59 built from equipment from more than one vendor. 61 Without commenting on the correct interpretation of pre-existing 62 documents, this document aims to establish the following. 64 - Behavioral characteristics of Admission Control in MPLS and GMPLS 65 systems. 66 - Desired characteristics of pre-emption. 67 - A terminology for soft and hard pre-emption. 68 - A record of implemented pre-emption behavior. 70 If necessary, a subsequent document will describe the conclusions of 71 the MPLS working group with regard to the correct interpretation of 72 the procedures for pre-emption. 74 2. Background 76 2.1 Default PathErr Processing 78 [RFC2205] defines RSVP procedures including the procedures for 79 handling PathErr messages that are used to report events or errors 80 from a downstream node to an upstream node. The predominant use of 81 PathErr in [RFC2205] is to report a problem that occurs while an RSVP 82 path is being established. There is no specific text that refers to 83 the use of a PathErr once a path has been established, but [RFC2205] 84 does include the following text. 86 PathErr messages are very simple; they are simply sent upstream to 87 the sender that created the error, and they do not change path 88 state in the nodes though which they pass. 90 2.2 The Origins of Priority in RSVP 92 [RFC2751] introduces the concept of priority to RSVP and suggests how 93 it may be signaled using the Policy Data object. 95 Priority can be used in this context to modify the traditional first- 96 come first-served Capacity-based Admissions Control (CAC) into a 97 Priority-based Admisssions Control (PAC). 99 [RFC2751] concentrates mainly on PAC and says very little about the 100 operation of pre-emption. The following text is relevant. 102 When a previously admitted flow is preempted, a copy of the 103 preempting flow's PREEMPTION_PRI element is sent back toward the 104 PDP that originated the preempted PREEMPTION_PRI object. This PDP, 105 having information on both the preempting and the preempted 106 priorities may construct a higher priority PREEMPTION_PRI element 107 in an effort to re-instate the preempted flow. 109 However, [RFC2750] describes the processing of policy errors as 110 follows. 112 Policy errors are reported by either ResvErr or PathErr messages 113 with a policy failure error code in the ERROR_SPEC object. 115 2.3 Priority and Pre-emption in MPLS 117 [RFC3209] defines RSVP-TE and introduces the concept of setup and 118 holding priorities for LSPs. This enables the implementation of 119 PAC in MPLS systems, and facilitates pre-emption of a lower priority 120 LSP by a higher priority LSP. 122 Pre-emption in this case means that some or all of the system 123 resources previously reserved for the lower priority LSP are assigned 124 to the higher priority LSP. 126 [RFC3209] contains the following text. 128 When a new Path message is considered for admission, the bandwidth 129 requested is compared with the bandwidth available at the priority 130 specified in the Setup Priority. 132 If the requested bandwidth is not available a PathErr message is 133 returned with an Error Code of 01, Admission Control Failure, and 134 an Error Value of 0x0002. The first 0 in the Error Value 135 indicates a globally defined subcode and is not informational. 136 The 002 indicates "requested bandwidth unavailable". 138 If the requested bandwidth is less than the unused bandwidth then 139 processing is complete. If the requested bandwidth is available, 140 but is in use by lower priority sessions, then lower priority 141 sessions (beginning with the lowest priority) MAY be preempted to 142 free the necessary bandwidth. 144 When preemption is supported, each preempted reservation triggers 145 a TC_Preempt() upcall to local clients, passing a subcode that 146 indicates the reason. A ResvErr and/or PathErr with the code 147 "Policy Control failure" SHOULD be sent toward the downstream 148 receivers and upstream senders. 150 3. Ambiguity 152 Confusion and diverse implementations have arrisen owing to the lack 153 of definitive instructions for error handling within [RFC3209]. The 154 diversity of implementations has been driven both by assumed 155 interpretations of [RFC3209] and by the needs of specific Admission 156 Control implementations. 158 4. Admission Control 160 The implementation of Admission Control turns out to be a major 161 factor in the decision about how to implement pre-emption within an 162 MPLS system. 164 4.1 Capacity-based Admission Control (CAC) 166 CAC operates by allocating system resources to flows (for example, 167 LSPs) as a function of the bandwidth requested during signaling and 168 the capacity of the links or router that supports the flow. Each 169 router is responsible for managing its own resources. 171 When a request for more bandwidth than can be supported by the links 172 of router is receieved, the CAC request fails and a signaling error 173 is returned. The CAC request may fail because the requested resources 174 exceed the total available in the system. The request may also fail 175 if some resources have already been reserved for other flows meaning 176 that the requested resources exceed the currently avilable resources 177 on the links or router. 179 4.2 Policy-based Admission Control (PAC) 181 PAC is a modification of CAC that allows the available resources to 182 be subdivided by priority. This means that some of the resources can 183 be reserved for use only by higher priority flows. High priority 184 flows can use high and low priority resources, but low priority flows 185 can use only low priority resources. 187 4.3 Pre-emption 189 PAC facilitates pre-emption. A resource request for a high priority 190 flow may pre-empt a low priority flow, and commandeer its resources. 191 The low priority flow is usually notified through signaling. 193 4.4 Best-Effort Traffic 195 Best-effort traffic does not have any resources specifically reserved 196 for it. It is sent on the understanding that if there is no capacity 197 at some point in the network it will be discarded. If, however, there 198 are resources that are available either because they have not been 199 reserved or because the flow for which they were reserved is not 200 using them, then the best-effort traffic may get through. 202 4.5 Statistical Admissions Control 204 Some implementations of Admissions Control are statistical. This 205 means that CAC requests are managed against a count of available 206 resources. When a CAC request is successful the count of available 207 resources is decremented. 209 PAC may also be managed in a statistical model. 211 In a statistical Admissions Control implementation no resources are 212 specifically assigned to each flow, and there is no attempt to police 213 the flows at transit routers. It is a requirement of successful 214 operation that the edge nodes adhere to the implicit contract of 215 their resource requests. Policing is sometimes applied at the network 216 edges or through management applications. 218 A consequence of this is that if one flow exceeds its contract, other 219 flows will suffer. 221 It is hard to support best-effort traffic in a statistical CAC 222 system. 224 4.6 Per-flow Admission Control 226 Per-flow Admission Control operates as CAC or PAC, and explicitly 227 assigns resources for the use by the flow. This means that a flow 228 that stays within its contracted limits is guaranteed resources to 229 meet its contract regardless of the behavior of the other flows in 230 the system. 232 A flow that exceeds its contracted limits may see its excess traffic 233 discarded. However, if there are unused or unallocated resources in 234 the system, the excess traffic may use these. 236 Similarly, best-effort traffic can be supported in this Admission 237 Control model since it is clear that that traffic should only be 238 allowed when there are spare resources. 240 5. Pre-emption Models 242 There are two pre-emption models applicable to MPLS systems. 244 5.1 Soft Pre-emption 246 In soft pre-emption, a higher priority LSP commandeers the resources 247 previously assigned to a lower priority LSP. The lower priority LSP 248 is not torn down and can continue to forward traffic on a best-effort 249 basis. 251 Note that resource reservations on other LSRs are not changed, and 252 the degradation to best-effort happens only at the point of pre- 253 emption. 255 A notification is normally sent to upstream and downstream LSRs to 256 warn them that the expected levels of service have been disrupted at 257 one LSR along the LSP. This allows end-to-end or local repair to be 258 performed to re-instate the desired level of service. 260 5.2 Hard Pre-emption 262 In hard pre-emption, a higher priority LSP commandeers the resources 263 previously assigned to a lower priority LSP, and the lower priority 264 LSP is torn down at the point of pre-emption. That is, the labels are 265 released and the entry is removed from the LFIB. Any traffic that 266 arrives with the old label is black-holed. 268 A notification message is sent to upstream and downstream LSRs to 269 inform them of this event and, if the notified LSR is unable or 270 unwilling to perform local repair, it may also tear the LSP by 271 releasing resources and labels and forwarding the notification. 273 5.3 Head-end Teardown 275 Note that an ingress LSR that is informed of soft pre-emption may 276 respond by explicitly tearing down the pre-empted LSP. Although this 277 results in the release of labels and disruption of data traffic, it 278 is not counted as hard pre-emption. The distinction between soft and 279 hard pre-emption is made only at the LSR where the pre-emption 280 occurs, and only at the time of pre-emption. 282 5.4 Applicability of Pre-emption Models 284 It will be observed that since the soft pre-emption model degrades 285 the pre-empted LSP to best-effort, it is not well-suited to 286 statistical Admission Control. In this mode hard pre-emption is 287 more applicable. 289 Soft pre-emption can be used in per-flow admission control. 291 5.5 Methods of Notification 293 In the current confusion about the correct method of performing 294 pre-emption both soft and hard pre-emption implemtations use a 295 PathErr and ResvErr message containing the "Policy Control failure" 296 error code to notify upstream and downstream LSRs of the pre-emption 297 event. 299 There is no way to distinguish from the received message 300 whether the pre-emption point performed soft or hard pre-emption. 302 5.6 Interworking of Pre-emption Models 304 The two pre-emption models do not interwork satisfactorily with the 305 current usage of the same messages and error codes. 307 5.6.1 Hard Pre-emption in a Soft Pre-emption Network 309 Consider a pre-emption point that applies hard pre-emption in a 310 network of LSRs that assume soft pre-emption. The other LSRs will 311 assume that the LSP is up and will continue to send traffic which 312 will be black-holed. 314 The Path refresh from the LSR immediately upstream of the pre-empting 315 LSR will be rejected with an error of "Admission Control failure" 316 because it will be seen as a new LSP setup request. This error might 317 trigger the tear-dwon of the LSP or might simply be propagated to the 318 ingress. 320 The pre-empting LSR will cease to send Resv refreshes so the LSP will 321 eventually timeout from the upstream LSRs. 323 Similarly, the downstream LSRs will not receive Path refreshes and 324 may receive a ResvErr or ResvTear in response to its Resv refresh. 326 In this case there is heavy reliance on the ingress LSP deciding 327 that best-effort is not good enough. It must either re-route or 328 tear the LSP. 330 5.6.2 Soft Pre-emption in a Hard Pre-emption Network 332 If the pre-emption point performs soft pre-emption and signals this 333 event upstream and downstream to the remainder of the network, and if 334 the remainder of the network assumes that hard pre-emption has been 335 performed then the worst that happens is that labels are wasted at 336 the pre-emption point. 338 Upstream of the pre-emption point, the notification of pre-emption 339 causes the release of state, rsources and labels. This means that no 340 more traffic will be passed to the pre-emption point on the pre- 341 empted LSP. Also, no Path refresh will be sent, and the Resv refresh 342 received from the pre-emption point may be rejected with a ResvErr or 343 ResvTear. In time, the pre-emption point will time-out the LSP and 344 release the labels. 346 Downstream of the pre-emption point, the Path refresh from the pre- 347 emption point may cause the LSP to be re-established. This partial 348 LSP will never carry traffic and will be removed when the pre-emption 349 point times-out the LSP as described above. 351 6. Tying Resources to Labels 353 An LSP is defined by the existence of entries in the Label Forwarding 354 Information Base (LFIB) at each LSR along the LSP. These entries map 355 {incoming interface, incoming label} to {outgoing interface, outgoing 356 label}. 358 6.1 Packet-Based Networks 360 An LSP may exist with or without reserved resources at each or any 361 LSR along its path. An LSP with no resources reserved at any point is 362 described as 'best effort'. An LSP with no resources reserved at a 363 particular LSR or on a particular link is best effort through that 364 LSR or on that link. 366 In an MPLS network, a distinction should be drawn between the pre- 367 emption of resources (such as buffers) and the pre-emption of labels. 368 It is not a requirement that the release of resources forces a 369 release of label. The LSP may survive pre-emption with its resources 370 removed (best effort) or reduced (degraded). 372 Packet LSRs that are incapable or unwilling to offer best effort 373 LSPs, MAY choose to offer only hard pre-emption. This might arise 374 where admission control is purely an arithmetic accounting function, 375 and edge nodes are required to police flows. 377 Where soft pre-emption is appplied, it is usual to only release 378 resources at the LSRs where pre-emption occurs. That is, the 379 resources are left assigned to the LSP at all other LSRs. 381 6.2 Non-Packet Networks 383 For non-packet switching types (such as lambda switching) there is a 384 hard binding between resources and labels. In these cases, it is not 385 possible to pre-empt resources without releasing the label. 387 Hard pre-emption is usually applied in non-packet networks. 389 6.3 Separating Signaling State from LSP State 391 Some implementations may choose to retain signaling state for an LSP 392 even when the labels have been released during hard pre-emption. 394 This may be particualrly useful in optical networks where resources 395 are manually deprovisioned and reprovisioned. 397 7. Methods of Signaling Pre-emption 399 The poll of vendors and implementors has shown that several methods 400 for signaling pre-emption events have been implemented or considered 401 for implementation. These are presented below without comment upon 402 their efficacy or properness. 404 7.1 PathErr and ResvErr with Policy Control Failure Error Code 406 As described in [RFC3209] the pre-emption point sends a PathErr 407 upstream and a ResvErr downstream. The messages carry the "Policy 408 Control failure" error code. 410 This mechanism is used in both hard and soft pre-emption 411 implementations. In some implementations the ingress automatically 412 responds to the PathErr with a PathTear. 414 7.2 PathErr with State Removal 416 Using the mechanism described in [RFC3473] a PathErr is sent upstream 417 carrying the "Policy Control failure" error code and with the 418 Path_State_Removed flag set. At the same time, a PathTear is sent 419 downstream. 421 This mechanism is used in hard pre-emption implementations. 423 7.3 ResvTear and ResvErr 425 A ResvTear is sent upstream and a ResvErr carrying the "Policy 426 Control failure" error code is sent downstream. The ingress 427 automatically responds to the ResvTear with a PathTear. 429 This mechanism has been suggested for use in hard pre-emption 430 implementations. 432 7.4 Notify Message 434 The Notify message introduced in [RFC3473] is sent upstream and 435 downstream carrying the "Policy Control failure" error code. The 436 Admin_Status object is included with the D-bit set to indicate that 437 LSP teardown is required. 439 This mechanism has been suggested for use in hard pre-emption 440 implementations. 442 7.5 Resv Message with Record Route Object 444 A Resv message is sent upstream with a flag in the RRO subobject 445 conveying the information about pre-emption for a specific hop. 447 This mechanism is introduced in [SOFT-PREEMPT] to provide a way to 448 perform soft pre-emption in systems that use the technique described 449 in section 7.1 to perform hard pre-emption. 451 8. Error Codes and State Removal 453 The Addmission Control error code in [RFC2205] is defined as carrying 454 an Error Value of the form ssur cccc cccc cccc where it is mandated 455 that u = 1 to denote 457 u = 1: RSVP may use message to update local state and forward 458 the message. This means that the message is informational. 460 Note that a ResvErr may carry the InPlace flag in the ERROR_SPEC 461 object to indicate that the resources are still in place. This 462 is of no particular help during pre-emption. 464 GMPLS [RFC3473] introduced the Path_State_Removed flag for inclusion 465 in PathErr messages to indicate to an upstrem LSR that the downstream 466 LSR has completely removed the Path state for the LSP. The 467 implication being that the resources have been freed, the labels 468 released, and the LSP torn down. 470 9. A Side Note on PathErr Processing 472 One other factor should be brought into consideration: How is a 473 PathErr message handled when it is received for an established LSP 474 and the PathErr carries an error code other than "Policy Control 475 failure"? 477 10. Other Requirements 479 Two other notes on the requirements of pre-emption can be made. 481 10.1 Reducing the Impact of Pre-emption 483 Where the establishment of one LSP requires pre-emption of resources 484 at multiple LSRs, it is desireable that the same LSP be pre-empted 485 at each intermediate LSR when possible and subject to the local 486 policy. 488 Where the establishment of two or more further LSPs requires 489 pre-emption at different points in the network, it is desireable 490 that the same LSP be pre-empted in each case where possible 491 and subject to the local policy. 493 The coordination of LSPs for pre-emption is a matter for individual 494 implementations. The protocol messages used to indicate pre-emption 495 must make it possible for each LSR to gather sufficient information 496 to perform this function. 498 10.2 When To Apply Pre-emption 500 It is normal to apply pre-emption on the reverse leg of LSP setup 501 when processing Resv. However, when processing a Path message: 503 - The likely need for and possibility of pre-emption may be taken 504 into account during path computation and routing. 506 - Pre-emption may be applied on the forward leg of LSP setup so 507 that, if it is known that pre-emption will be required (if the LSP 508 sets up successfully), pre-emption can be performed ahead of time. 510 - In bidirectional LSPs (see [RFC3473]), and in particular when the 511 resource is bound to the label, it may be necessary to allocate 512 resources for the upstream data flow while processing the Path 513 message during LSP setup. This may require that pre-emption is 514 performed when processing the Path message. 516 11. Summary of Deployed Solutions 518 Appendix A lists some of the deployed solutions according to an 519 informal survey of implementors and vendors. This information was 520 garnered from a private email survey conducted by the co-chairs of 521 the CCAMP working group. 523 11.1 Soft Pre-emption 525 There is only one deployed solution for soft pre-emption. 527 - A PathErr with the code "Policy Control failure" is sent 528 upstream, and a ResvErr with the code "Policy Control 529 failure" is sent downstream. 531 There is a further solution for soft pre-emption under development. 533 - A Resv message MAY be sent upstream with a flag in RRO subobject 534 conveying the information about pre-emption for a specific hop. 536 11.2 Hard Pre-emption 538 There are two deployed solutions for hard pre-emption. 540 - A PathErr with the code "Policy Control failure" is sent upstream, 541 and a ResvErr with the code "Policy Control failure" is sent 542 downstream. 544 - A PathErr with the code "Policy Control failure" and the 545 Path_State_Removed flag (see [RFC3473]) set is sent upstream. At 546 the same time, a PathTear is sent downstream. 548 12. Security Considerations 550 This is an informational document that introduces no new protocols 551 nor protocol extensions. There are no security implications of this 552 document. 554 The attention of implementors is drawn to the security sections of 555 the documents describing the pre-emption signaling features that they 556 are implementing. 558 13. Acknowledgements 560 Thanks to Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar and 561 Kireeti Kompella for a detailed discussion and exposee of the 562 problems. 564 14. Intellectual Property Consideration 566 The IETF takes no position regarding the validity or scope 567 of any intellectual property or other rights that might be 568 claimed to pertain to the implementation or use of the 569 technology described in this document or the extent to 570 which any license under such rights might or might not be 571 available; neither does it represent that it has made any 572 effort to identify any such rights. Information on the 573 IETF's procedures with respect to rights in standards-track 574 and standards-related documentation can be found in BCP-11. 575 Copies of claims of rights made available for publication 576 and any assurances of licenses to be made available, or the 577 result of an attempt made to obtain a general license or 578 permission for the use of such proprietary rights by 579 implementors or users of this specification can be obtained 580 from the IETF Secretariat. 582 The IETF invites any interested party to bring to its 583 attention any copyrights, patents or patent applications, or 584 other proprietary rights which may cover technology that may 585 be required to practice this standard. Please address the 586 information to the IETF Executive Director. 588 15. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. 594 and S. Jamin, "Resource ReserVation Protocol -- 595 Version 1 Functional Specification", RFC 2205, 596 September 1997. 598 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 599 RFC 2750, January 2000. 601 [RFC2751] Herzog, S., "Signaled Preemption Priority Policy 602 Element", RFC 2751, January 2000. 604 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 605 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 606 to RSVP for LSP Tunnels", RFC 3209, December 2001. 608 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 609 Switching (GMPLS) Signaling Functional Description", 610 RFC 3471, January 2003. 612 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - 613 RSVP-TE Extensions", RFC 3473 January 2003. 615 16. Informative References 617 [RFC2026] Bradner, S., "The Internet Standards Process 618 -- Revision 3", RFC 2026, October 1996. 620 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 621 "Multiprotocol Label Switching 622 Architecture", RFC 3031, January 2001. 624 [SOFTPREEMPT] Meyer, Maddux, Vasseur, Villamizar and Birjandi, 625 "MPLS Traffic Engineering Soft preemption", 626 draft-ietf-mpls-soft-preemption-01.txt, October 2003, 627 work in progress. 629 17. Authors' Addresses 631 Adrian Farrel 632 Old Dog Consulting 633 Phone: +44 (0) 1978 860944 634 EMail: adrian@olddog.co.uk 636 18. Full Copyright Statement 638 Copyright (C) The Internet Society (2003). All Rights 639 Reserved. 641 This document and translations of it may be copied and 642 furnished to others, and derivative works that comment on 643 or otherwise explain it or assist in its implementation may 644 be prepared, copied, published and distributed, in whole or 645 in part, without restriction of any kind, provided that the 646 above copyright notice and this paragraph are included on 647 all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by 649 removing the copyright notice or references to the Internet 650 Society or other Internet organizations, except as needed 651 for the purpose of developing Internet standards in which 652 case the procedures for copyrights defined in the Internet 653 Standards process must be followed, or as required to 654 translate it into languages other than English. 656 The limited permissions granted above are perpetual and 657 will not be revoked by the Internet Society or its 658 successors or assigns. This document and the information 659 contained herein is provided on an "AS IS" basis and THE 660 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 661 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 662 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 665 PURPOSE. 667 Apendix A Implementation Reports 669 A.1 Company 1 671 Hardware vendor. 673 A.1.1 Soft Pre-emption 675 A Resv message is sent upstream with a flag in the RRO subobject 676 conveying the information about pre-emption for a specific hop. 678 Not currently deployed. Implementation under development. 680 A.1.2 Hard Pre-emption 682 A PathErr with the code "Policy Control failure" is sent upstream, 683 and a ResvErr with the code "Policy Control failure" is sent 684 downstream. 686 Significantly large deployment. 688 A.1.3 Processing of Other PathErrs for Established LSPs 690 Unknown. 692 A.2 Company 2 694 Hardware vendor. 696 A.2.1 Soft Pre-emption 698 Not currently supported. 700 A.2.2 Hard Pre-emption 702 A PathErr with the code "Policy Control failure" is sent upstream, 703 and a ResvErr with the code "Policy Control failure" is sent 704 downstream. 706 Significantly deployment. 708 A.2.3 Processing of Other PathErrs for Established LSPs 710 Unknown. 712 A.3 Company 3 714 Hardware vendor. 716 A.3.1 Soft Pre-emption 718 A PathErr with the code "Policy Control failure" is sent upstream, 719 and a ResvErr with the code "Policy Control failure" is sent 720 downstream. The ingress always responds with PathTear. 722 Some deployment. 724 A.3.2 Hard Pre-emption 726 Not supported. 728 A.3.3 Processing of Other PathErrs for Established LSPs 730 PathErr is informational only. It does not disrupt the state of 731 existing LSPs. 733 A.4 Company 4 735 Software vendor. 737 A.4.1 Soft Pre-emption 739 A PathErr with the code "Policy Control failure" is sent upstream, 740 and a ResvErr with the code "Policy Control failure" is sent 741 downstream. 743 Considerable deployment. 745 A.4.2 Hard Pre-emption 747 Not supported. 749 A.4.3 Processing of Other PathErrs for Established LSPs 751 PathErr is informational only. It does not disrupt the state of 752 existing LSPs. 754 A.5 Company 5 756 Hardware vendor. 758 A.5.1 Soft Pre-emption 760 A PathErr with the code "Policy Control failure" is sent upstream, 761 and a ResvErr with the code "Policy Control failure" is sent 762 downstream. 764 Some deployment. 766 A.5.2 Hard Pre-emption 768 A PathErr with the code "Policy Control failure" and the 769 Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the 770 same time, a PathTear is sent downstream. 772 Some deployment. 774 A.5.3 Processing of Other PathErrs for Established LSPs 776 PathErr is informational only. it does not disrupt the state of 777 existing LSPs. 779 A.6 Company 6 781 Hardware vendor. 783 A.6.1 Soft Pre-emption 785 Not supported. 787 A.6.2 Hard Pre-emption 789 A PathErr with the code "Policy Control failure" is sent upstream, 790 and a ResvErr with the code "Policy Control failure" is sent 791 downstream. The ingress always responds with PathTear. 793 Under development. 795 A.6.3 Processing of Other PathErrs for Established LSPs 797 State is retained, but ingress always responds with PathTear. 799 A.7 Company 7 801 Software vendor. 803 A.7.1 Soft Pre-emption 805 A PathErr with the code "Policy Control failure" is sent upstream, 806 and a ResvErr with the code "Policy Control failure" is sent 807 downstream. 809 Significant deployment. 811 A.7.2 Hard Pre-emption 813 A PathErr with the code "Policy Control failure" and the 814 Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the 815 same time, a PathTear is sent downstream. 817 A.7.3 Processing of Other PathErrs for Established LSPs 819 Depends on Path_State_Removed flag. 821 A.8 Company 8 823 Hardware vendor. 825 A.8.1 Soft Pre-emption 827 Not supported. 829 A.8.2 Hard Pre-emption 831 A PathErr with the code "Policy Control failure" is sent upstream, 832 and a ResvErr with the code "Policy Control failure" is sent 833 downstream. 835 Some deployment. 837 A.8.3 Processing of Other PathErrs for Established LSPs 839 The LSP is torn down. 841 A.9 Company 9 843 Hardware vendor. 845 A.9.1 Soft Pre-emption 847 Not supported. 849 A.9.2 Hard Pre-emption 851 A PathErr with the code "Policy Control failure" is sent upstream, 852 and a ResvErr with the code "Policy Control failure" is sent 853 downstream. 855 Some deployment. 857 A.9.3 Processing of Other PathErrs for Established LSPs 859 Unknown. 861 A.10 Company 10 863 Hardware vendor. 865 A.10.1 Soft Pre-emption 867 Not supported. 869 A.10.2 Hard Pre-emption 871 Not supported. 873 A.10.3 Processing of Other PathErrs for Established LSPs 875 The LSP is torn down. 877 Some deployment.