Network Working Group Adrian Farrel Internet Draft Old Dog Consulting Category: Informational Expires: May 2004 November 2003 Interim Report on MPLS Pre-emption draft-farrel-mpls-preemption-interim-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is an interim report into pre-emption in MPLS systems. At the 58th IETF, the MPLS Working Group determined that there are several interpretations of how pre-emption should be achieved within MPLS systems. This document is the result of the initial enquiries to vendors and other implementors into the question of how and why they offer pre-emption funtion in their MPLS inplementations. This document is intended to be a short-lived document and only exists to document the current findings. It will be superceded or retired. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 1. Introduction The most recent charter of the MPLS working group includes the work item to develop a solution for "soft pre-emption" within MPLS systems. This work item was contested by some people who regard MPLS signaling (and in particular RSVP-TE as documented by [RFC 3209]) to already include mechanisms for soft pre-emption. A common understanding of the correct behavior during pre-emption will be beneficial to vendors trying to get their hardware to inter- work, and to network operators trying to offer services in networks built from equipment from more than one vendor. Without commenting on the correct interpretation of pre-existing documents, this document aims to establish the following. - Behavioral characteristics of Admission Control in MPLS and GMPLS systems. - Desired characteristics of pre-emption. - A terminology for soft and hard pre-emption. - A record of implemented pre-emption behavior. If necessary, a subsequent document will describe the conclusions of the MPLS working group with regard to the correct interpretation of the procedures for pre-emption. 2. Background 2.1 Default PathErr Processing [RFC2205] defines RSVP procedures including the procedures for handling PathErr messages that are used to report events or errors from a downstream node to an upstream node. The predominant use of PathErr in [RFC2205] is to report a problem that occurs while an RSVP path is being established. There is no specific text that refers to the use of a PathErr once a path has been established, but [RFC2205] does include the following text. PathErr messages are very simple; they are simply sent upstream to the sender that created the error, and they do not change path state in the nodes though which they pass. 2.2 The Origins of Priority in RSVP [RFC2751] introduces the concept of priority to RSVP and suggests how it may be signaled using the Policy Data object. Priority can be used in this context to modify the traditional first- come first-served Capacity-based Admissions Control (CAC) into a Priority-based Admisssions Control (PAC). [RFC2751] concentrates mainly on PAC and says very little about the operation of pre-emption. The following text is relevant. When a previously admitted flow is preempted, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted PREEMPTION_PRI object. This PDP, Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 having information on both the preempting and the preempted priorities may construct a higher priority PREEMPTION_PRI element in an effort to re-instate the preempted flow. However, [RFC2750] describes the processing of policy errors as follows. Policy errors are reported by either ResvErr or PathErr messages with a policy failure error code in the ERROR_SPEC object. 2.3 Priority and Pre-emption in MPLS [RFC3209] defines RSVP-TE and introduces the concept of setup and holding priorities for LSPs. This enables the implementation of PAC in MPLS systems, and facilitates pre-emption of a lower priority LSP by a higher priority LSP. Pre-emption in this case means that some or all of the system resources previously reserved for the lower priority LSP are assigned to the higher priority LSP. [RFC3209] contains the following text. When a new Path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the Setup Priority. If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure, and an Error Value of 0x0002. The first 0 in the Error Value indicates a globally defined subcode and is not informational. The 002 indicates "requested bandwidth unavailable". If the requested bandwidth is less than the unused bandwidth then processing is complete. If the requested bandwidth is available, but is in use by lower priority sessions, then lower priority sessions (beginning with the lowest priority) MAY be preempted to free the necessary bandwidth. When preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, passing a subcode that indicates the reason. A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders. 3. Ambiguity Confusion and diverse implementations have arrisen owing to the lack of definitive instructions for error handling within [RFC3209]. The diversity of implementations has been driven both by assumed interpretations of [RFC3209] and by the needs of specific Admission Control implementations. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 4. Admission Control The implementation of Admission Control turns out to be a major factor in the decision about how to implement pre-emption within an MPLS system. 4.1 Capacity-based Admission Control (CAC) CAC operates by allocating system resources to flows (for example, LSPs) as a function of the bandwidth requested during signaling and the capacity of the links or router that supports the flow. Each router is responsible for managing its own resources. When a request for more bandwidth than can be supported by the links of router is receieved, the CAC request fails and a signaling error is returned. The CAC request may fail because the requested resources exceed the total available in the system. The request may also fail if some resources have already been reserved for other flows meaning that the requested resources exceed the currently avilable resources on the links or router. 4.2 Policy-based Admission Control (PAC) PAC is a modification of CAC that allows the available resources to be subdivided by priority. This means that some of the resources can be reserved for use only by higher priority flows. High priority flows can use high and low priority resources, but low priority flows can use only low priority resources. 4.3 Pre-emption PAC facilitates pre-emption. A resource request for a high priority flow may pre-empt a low priority flow, and commandeer its resources. The low priority flow is usually notified through signaling. 4.4 Best-Effort Traffic Best-effort traffic does not have any resources specifically reserved for it. It is sent on the understanding that if there is no capacity at some point in the network it will be discarded. If, however, there are resources that are available either because they have not been reserved or because the flow for which they were reserved is not using them, then the best-effort traffic may get through. 4.5 Statistical Admissions Control Some implementations of Admissions Control are statistical. This means that CAC requests are managed against a count of available resources. When a CAC request is successful the count of available resources is decremented. PAC may also be managed in a statistical model. In a statistical Admissions Control implementation no resources are specifically assigned to each flow, and there is no attempt to police the flows at transit routers. It is a requirement of successful operation that the edge nodes adhere to the implicit contract of Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 their resource requests. Policing is sometimes applied at the network edges or through management applications. A consequence of this is that if one flow exceeds its contract, other flows will suffer. It is hard to support best-effort traffic in a statistical CAC system. 4.6 Per-flow Admission Control Per-flow Admission Control operates as CAC or PAC, and explicitly assigns resources for the use by the flow. This means that a flow that stays within its contracted limits is guaranteed resources to meet its contract regardless of the behavior of the other flows in the system. A flow that exceeds its contracted limits may see its excess traffic discarded. However, if there are unused or unallocated resources in the system, the excess traffic may use these. Similarly, best-effort traffic can be supported in this Admission Control model since it is clear that that traffic should only be allowed when there are spare resources. 5. Pre-emption Models There are two pre-emption models applicable to MPLS systems. 5.1 Soft Pre-emption In soft pre-emption, a higher priority LSP commandeers the resources previously assigned to a lower priority LSP. The lower priority LSP is not torn down and can continue to forward traffic on a best-effort basis. Note that resource reservations on other LSRs are not changed, and the degradation to best-effort happens only at the point of pre- emption. A notification is normally sent to upstream and downstream LSRs to warn them that the expected levels of service have been disrupted at one LSR along the LSP. This allows end-to-end or local repair to be performed to re-instate the desired level of service. 5.2 Hard Pre-emption In hard pre-emption, a higher priority LSP commandeers the resources previously assigned to a lower priority LSP, and the lower priority LSP is torn down at the point of pre-emption. That is, the labels are released and the entry is removed from the LFIB. Any traffic that arrives with the old label is black-holed. A notification message is sent to upstream and downstream LSRs to inform them of this event and, if the notified LSR is unable or unwilling to perform local repair, it may also tear the LSP by releasing resources and labels and forwarding the notification. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 5.3 Head-end Teardown Note that an ingress LSR that is informed of soft pre-emption may respond by explicitly tearing down the pre-empted LSP. Although this results in the release of labels and disruption of data traffic, it is not counted as hard pre-emption. The distinction between soft and hard pre-emption is made only at the LSR where the pre-emption occurs, and only at the time of pre-emption. 5.4 Applicability of Pre-emption Models It will be observed that since the soft pre-emption model degrades the pre-empted LSP to best-effort, it is not well-suited to statistical Admission Control. In this mode hard pre-emption is more applicable. Soft pre-emption can be used in per-flow admission control. 5.5 Methods of Notification In the current confusion about the correct method of performing pre-emption both soft and hard pre-emption implemtations use a PathErr and ResvErr message containing the "Policy Control failure" error code to notify upstream and downstream LSRs of the pre-emption event. There is no way to distinguish from the received message whether the pre-emption point performed soft or hard pre-emption. 5.6 Interworking of Pre-emption Models The two pre-emption models do not interwork satisfactorily with the current usage of the same messages and error codes. 5.6.1 Hard Pre-emption in a Soft Pre-emption Network Consider a pre-emption point that applies hard pre-emption in a network of LSRs that assume soft pre-emption. The other LSRs will assume that the LSP is up and will continue to send traffic which will be black-holed. The Path refresh from the LSR immediately upstream of the pre-empting LSR will be rejected with an error of "Admission Control failure" because it will be seen as a new LSP setup request. This error might trigger the tear-dwon of the LSP or might simply be propagated to the ingress. The pre-empting LSR will cease to send Resv refreshes so the LSP will eventually timeout from the upstream LSRs. Similarly, the downstream LSRs will not receive Path refreshes and may receive a ResvErr or ResvTear in response to its Resv refresh. In this case there is heavy reliance on the ingress LSP deciding that best-effort is not good enough. It must either re-route or tear the LSP. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 5.6.2 Soft Pre-emption in a Hard Pre-emption Network If the pre-emption point performs soft pre-emption and signals this event upstream and downstream to the remainder of the network, and if the remainder of the network assumes that hard pre-emption has been performed then the worst that happens is that labels are wasted at the pre-emption point. Upstream of the pre-emption point, the notification of pre-emption causes the release of state, rsources and labels. This means that no more traffic will be passed to the pre-emption point on the pre- empted LSP. Also, no Path refresh will be sent, and the Resv refresh received from the pre-emption point may be rejected with a ResvErr or ResvTear. In time, the pre-emption point will time-out the LSP and release the labels. Downstream of the pre-emption point, the Path refresh from the pre- emption point may cause the LSP to be re-established. This partial LSP will never carry traffic and will be removed when the pre-emption point times-out the LSP as described above. 6. Tying Resources to Labels An LSP is defined by the existence of entries in the Label Forwarding Information Base (LFIB) at each LSR along the LSP. These entries map {incoming interface, incoming label} to {outgoing interface, outgoing label}. 6.1 Packet-Based Networks An LSP may exist with or without reserved resources at each or any LSR along its path. An LSP with no resources reserved at any point is described as 'best effort'. An LSP with no resources reserved at a particular LSR or on a particular link is best effort through that LSR or on that link. In an MPLS network, a distinction should be drawn between the pre- emption of resources (such as buffers) and the pre-emption of labels. It is not a requirement that the release of resources forces a release of label. The LSP may survive pre-emption with its resources removed (best effort) or reduced (degraded). Packet LSRs that are incapable or unwilling to offer best effort LSPs, MAY choose to offer only hard pre-emption. This might arise where admission control is purely an arithmetic accounting function, and edge nodes are required to police flows. Where soft pre-emption is appplied, it is usual to only release resources at the LSRs where pre-emption occurs. That is, the resources are left assigned to the LSP at all other LSRs. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 6.2 Non-Packet Networks For non-packet switching types (such as lambda switching) there is a hard binding between resources and labels. In these cases, it is not possible to pre-empt resources without releasing the label. Hard pre-emption is usually applied in non-packet networks. 6.3 Separating Signaling State from LSP State Some implementations may choose to retain signaling state for an LSP even when the labels have been released during hard pre-emption. This may be particualrly useful in optical networks where resources are manually deprovisioned and reprovisioned. 7. Methods of Signaling Pre-emption The poll of vendors and implementors has shown that several methods for signaling pre-emption events have been implemented or considered for implementation. These are presented below without comment upon their efficacy or properness. 7.1 PathErr and ResvErr with Policy Control Failure Error Code As described in [RFC3209] the pre-emption point sends a PathErr upstream and a ResvErr downstream. The messages carry the "Policy Control failure" error code. This mechanism is used in both hard and soft pre-emption implementations. In some implementations the ingress automatically responds to the PathErr with a PathTear. 7.2 PathErr with State Removal Using the mechanism described in [RFC3473] a PathErr is sent upstream carrying the "Policy Control failure" error code and with the Path_State_Removed flag set. At the same time, a PathTear is sent downstream. This mechanism is used in hard pre-emption implementations. 7.3 ResvTear and ResvErr A ResvTear is sent upstream and a ResvErr carrying the "Policy Control failure" error code is sent downstream. The ingress automatically responds to the ResvTear with a PathTear. This mechanism has been suggested for use in hard pre-emption implementations. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 7.4 Notify Message The Notify message introduced in [RFC3473] is sent upstream and downstream carrying the "Policy Control failure" error code. The Admin_Status object is included with the D-bit set to indicate that LSP teardown is required. This mechanism has been suggested for use in hard pre-emption implementations. 7.5 Resv Message with Record Route Object A Resv message is sent upstream with a flag in the RRO subobject conveying the information about pre-emption for a specific hop. This mechanism is introduced in [SOFT-PREEMPT] to provide a way to perform soft pre-emption in systems that use the technique described in section 7.1 to perform hard pre-emption. 8. Error Codes and State Removal The Addmission Control error code in [RFC2205] is defined as carrying an Error Value of the form ssur cccc cccc cccc where it is mandated that u = 1 to denote u = 1: RSVP may use message to update local state and forward the message. This means that the message is informational. Note that a ResvErr may carry the InPlace flag in the ERROR_SPEC object to indicate that the resources are still in place. This is of no particular help during pre-emption. GMPLS [RFC3473] introduced the Path_State_Removed flag for inclusion in PathErr messages to indicate to an upstrem LSR that the downstream LSR has completely removed the Path state for the LSP. The implication being that the resources have been freed, the labels released, and the LSP torn down. 9. A Side Note on PathErr Processing One other factor should be brought into consideration: How is a PathErr message handled when it is received for an established LSP and the PathErr carries an error code other than "Policy Control failure"? 10. Other Requirements Two other notes on the requirements of pre-emption can be made. 10.1 Reducing the Impact of Pre-emption Where the establishment of one LSP requires pre-emption of resources at multiple LSRs, it is desireable that the same LSP be pre-empted at each intermediate LSR when possible and subject to the local policy. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 Where the establishment of two or more further LSPs requires pre-emption at different points in the network, it is desireable that the same LSP be pre-empted in each case where possible and subject to the local policy. The coordination of LSPs for pre-emption is a matter for individual implementations. The protocol messages used to indicate pre-emption must make it possible for each LSR to gather sufficient information to perform this function. 10.2 When To Apply Pre-emption It is normal to apply pre-emption on the reverse leg of LSP setup when processing Resv. However, when processing a Path message: - The likely need for and possibility of pre-emption may be taken into account during path computation and routing. - Pre-emption may be applied on the forward leg of LSP setup so that, if it is known that pre-emption will be required (if the LSP sets up successfully), pre-emption can be performed ahead of time. - In bidirectional LSPs (see [RFC3473]), and in particular when the resource is bound to the label, it may be necessary to allocate resources for the upstream data flow while processing the Path message during LSP setup. This may require that pre-emption is performed when processing the Path message. 11. Summary of Deployed Solutions Appendix A lists some of the deployed solutions according to an informal survey of implementors and vendors. This information was garnered from a private email survey conducted by the co-chairs of the CCAMP working group. 11.1 Soft Pre-emption There is only one deployed solution for soft pre-emption. - A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. There is a further solution for soft pre-emption under development. - A Resv message MAY be sent upstream with a flag in RRO subobject conveying the information about pre-emption for a specific hop. 11.2 Hard Pre-emption There are two deployed solutions for hard pre-emption. - A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 - A PathErr with the code "Policy Control failure" and the Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the same time, a PathTear is sent downstream. 12. Security Considerations This is an informational document that introduces no new protocols nor protocol extensions. There are no security implications of this document. The attention of implementors is drawn to the security sections of the documents describing the pre-emption signaling features that they are implementing. 13. Acknowledgements Thanks to Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar and Kireeti Kompella for a detailed discussion and exposee of the problems. 14. Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 [RFC2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. 16. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [SOFTPREEMPT] Meyer, Maddux, Vasseur, Villamizar and Birjandi, "MPLS Traffic Engineering Soft preemption", draft-ietf-mpls-soft-preemption-01.txt, October 2003, work in progress. 17. Authors' Addresses Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk 18. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Apendix A Implementation Reports A.1 Company 1 Hardware vendor. A.1.1 Soft Pre-emption A Resv message is sent upstream with a flag in the RRO subobject conveying the information about pre-emption for a specific hop. Not currently deployed. Implementation under development. A.1.2 Hard Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Significantly large deployment. A.1.3 Processing of Other PathErrs for Established LSPs Unknown. A.2 Company 2 Hardware vendor. A.2.1 Soft Pre-emption Not currently supported. A.2.2 Hard Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Significantly deployment. A.2.3 Processing of Other PathErrs for Established LSPs Unknown. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 A.3 Company 3 Hardware vendor. A.3.1 Soft Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. The ingress always responds with PathTear. Some deployment. A.3.2 Hard Pre-emption Not supported. A.3.3 Processing of Other PathErrs for Established LSPs PathErr is informational only. It does not disrupt the state of existing LSPs. A.4 Company 4 Software vendor. A.4.1 Soft Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Considerable deployment. A.4.2 Hard Pre-emption Not supported. A.4.3 Processing of Other PathErrs for Established LSPs PathErr is informational only. It does not disrupt the state of existing LSPs. A.5 Company 5 Hardware vendor. A.5.1 Soft Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Some deployment. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 A.5.2 Hard Pre-emption A PathErr with the code "Policy Control failure" and the Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the same time, a PathTear is sent downstream. Some deployment. A.5.3 Processing of Other PathErrs for Established LSPs PathErr is informational only. it does not disrupt the state of existing LSPs. A.6 Company 6 Hardware vendor. A.6.1 Soft Pre-emption Not supported. A.6.2 Hard Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. The ingress always responds with PathTear. Under development. A.6.3 Processing of Other PathErrs for Established LSPs State is retained, but ingress always responds with PathTear. A.7 Company 7 Software vendor. A.7.1 Soft Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Significant deployment. A.7.2 Hard Pre-emption A PathErr with the code "Policy Control failure" and the Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the same time, a PathTear is sent downstream. A.7.3 Processing of Other PathErrs for Established LSPs Depends on Path_State_Removed flag. Farrel Page 1 draft-farrel-mpls-preemption-interim-00.txt November 2003 A.8 Company 8 Hardware vendor. A.8.1 Soft Pre-emption Not supported. A.8.2 Hard Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Some deployment. A.8.3 Processing of Other PathErrs for Established LSPs The LSP is torn down. A.9 Company 9 Hardware vendor. A.9.1 Soft Pre-emption Not supported. A.9.2 Hard Pre-emption A PathErr with the code "Policy Control failure" is sent upstream, and a ResvErr with the code "Policy Control failure" is sent downstream. Some deployment. A.9.3 Processing of Other PathErrs for Established LSPs Unknown. A.10 Company 10 Hardware vendor. A.10.1 Soft Pre-emption Not supported. A.10.2 Hard Pre-emption Not supported. A.10.3 Processing of Other PathErrs for Established LSPs The LSP is torn down. Some deployment. Farrel Page 1