Network Working Group Adrian Farrel Internet Draft Old Dog Consulting Category: Standards Track Updates: RFC 3209 and RFC 3473 Expires: July 2004 January 2004 Multiprotocol Label Switching Pre-emption draft-farrel-mpls-preemption-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 Multiprotocol Label Switching (MPLS) signaling is documented in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, using mechanisms inherited from "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205. MPLS includes the concept of pre-emption where, for administrative reasons such as contention for system resources, a new Label Switched Path (LSP) may displace an existing LSP. This document clarifies the procedures for MPLS pre-emption in the light of implementation experience. The procedures in this document updae those described in RFC 2205 and RFC 3209, but apply only to RSVP-TE used in the MPLS context. Farrel Page 1 draft-farrel-mpls-preemption-00.txt January 2004 1. Introduction Multiprotocol Label Switching (MPLS) traffic engineering Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE). These extensions include support for the concept of pre-emption such that a high priority LSP may commandeer the resources of a lower priority LSP [RFC3209]. The signaling procedures for pre-emption described in [RFC3209] have proven to be sufficiently unclear that various different implementations have been deployed. In order that pre-emption can be successfully deployed in the future, multi-vendor networks, this document clarifies the procedures. 1.1 Summary of Unclarity The lack of clarity in interpretation of [RFC3209] centers around whether MPLS pre-emption is "hard" or "soft". In soft pre-emption the resources of the pre-empted LSP are sequestered for the new LSP, but the old LSP remains in place. Signaling state is not removed, labels are not removed, the data forwarding path remains intact, but the traffic is forwarded only as "best effort" over the links/nodes at which pre-emption has occurred. In hard pre-emption the resources of the old LSP are re-allocated to the new LSP in exactly the same way, but the old LSP is torn down. The forwarding path is immediately broken and each LSR along the LSP is notified that the LSP is no longer active. Signaling state is discarded. 1.2 Summary of Solution This document defines MPLS pre-emption mechanisms according to local policy on the pre-empting node, and according to the error code reported in the PathErr/ResvErr message at all other nodes. Both soft and hard pre-emption are supported. New RSVP Error Values are defined to distinguish the cases. 1.3 Backwards Compatibility It is not possible to provide interoperable backwards compatiblity between the two interpretations of [RFC3209] since they are fundamentally different. However, the solution proposed in this document is fully backward compatible with existing implementations since [RFC3209] only specifies an RSVP Error Code for use during pre-emption and does not provide a qualifying Error Value. Thus, existing implementations have no reason to check the Error Value and are not susceptible to a change in that value. Farrel Page 2 draft-farrel-mpls-preemption-00.txt January 2004 Note that it is possible that some existing implementations use the Error Value suggested in [RFC2750]. 5 = ERR_PREEMPT : Flow was preempted This would not affect backwards compatibility unless existing implementations give other Error Values different treatments within the same "Policy Control failure" Error Code. 1.4 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. General Priority and Pre-emption Procedures This document makes no changes to the procedures for signaling LSP setup and holding priorities as described in [RFC3209]. This document makes no change to the mechanisms by which the need for pre-emption is determined, or by which LSPs to be pre-empted are selected. 2.1 Choice of Hard or Soft Pre-emption It is a local implementation or policy choice whether hard or soft pre-emption is applied. This choice is made at the pre-empting LSR. 3. Hard Pre-emption Procedures 3.1 Pre-empting LSR When an LSR determines that it is pre-empting an LSP and that it will apply hard pre-emption it MUST: - surrender all resources for the old LSP - immediately stop forwarding data on the old LSP - treat received labeled packets for the old LSP as having an unknown label - send a PathErr upstream for the old LSP carrying the "Policy Control failure"/"Hard Pre-empted" error - send a ResvErr downstream for the old LSP carrying the "Policy Control failure"/"Hard Pre-empted" error and with the inPlace flag clear - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Path and Resv state for a short period to prevent refresh messages from attempting to re-establish state or causing subsequent error messages. Farrel Page 3 draft-farrel-mpls-preemption-00.txt January 2004 3.2 Upstream LSRs 3.2.1 Transit LSRs An upstream transit LSR that receives a PathErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - treat received labeled packets for the LSP as having an unknown label - send a PathErr further upstream carrying the "Policy Control failure"/"Hard Pre-empted" error - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Path state for a short period to prevent refresh messages from attempting to re-establish state or causing subsequent error messages. 3.2.2 Ingress LSR An ingress LSR that receives a PathErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - discard all Path and Resv state for the LSP. An ingress LSR SHOULD NOT send a PathTear for the pre-empted LSP. An ingress LSR MAY attempt to re-establish the pre-empted LSP according to local policy. 3.3 Downstream LSRs 3.3.1 Transit LSRs A downstream transit LSR that receives a ResvErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - treat received labeled packets for the LSP as having an unknown label - send a ResvErr further downstream carrying the "Policy Control failure"/"Hard Pre-empted" error and with the inPlace flag clear - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Resv state for a short period to prevent refresh messages from causing subsequent error messages. 3.3.2 Egress LSR An egress LSR that receives a ResvErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - discard all Path and Resv state for the LSP. An egress LSR MUST NOT send further messages for the pre-empted LSP. Farrel Page 4 draft-farrel-mpls-preemption-00.txt January 2004 4. Soft Pre-emption Procedures 4.1 Pre-empting LSR When an LSR determines that it is pre-empting an LSP and that it will apply soft pre-emption it MUST: - surrender all resources for the old LSP - send a PathErr upstream for the old LSP carrying the "Policy Control failure"/"Soft Pre-empted" error - send a ResvErr downstream for the old LSP carrying the "Policy Control failure"/"Soft Pre-empted" error and with the inPlace flag set - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. A pre-empting LSR MAY modify the service delivered on the old LSP according to the reduced resources. This MAY result in traffic being treated as "best effort" and not delivered. A pre-empting LSR MAY use the receipt of a Path refresh message as a trigger to attempt to re-allocate the required resources, but it MUST NOT send a subsequent PathErr message if this attempt fails. A pre-empting LSR SHOULD use the receipt of a modified (i.e. trigger) Path message to attempt to re-allocate the required resources. If such an attempt is not successful, it SHOULD return a PathErr with the appropriate error according to the failure (probably Admission Control Failure) and continue to retain the LSP and the signaling state. 4.2 Upstream LSRs 4.2.1 Transit LSRs An upstream transit LSR that receives a PathErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - send a PathErr further upstream carrying the "Policy Control failure"/"Soft Pre-empted" error - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. An LSR MAY retain knowledge of the fact that the LSP has been pre- empted to help in future choices of LSPs that are pre-empted at this LSR. 4.2.2 Ingress LSR An ingress LSR that receives a PathErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. Farrel Page 5 draft-farrel-mpls-preemption-00.txt January 2004 An ingress LSR SHOULD take action according to local policy to attempt to repair or re-route the LSP (by chaning its priority, resource requirements or path), or tear the LSP by sending a PathTear message. 4.3 Dowstream LSRs 4.3.1 Transit LSRs A downstream transit LSR that receives a ResvErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - send a ResvErr further downstream carrying the "Policy Control failure"/"Soft Pre-empted" error and with the inPlace flag set - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. An LSR MAY retain knowledge of the fact that the LSP has been pre- empted to help in future choices of LSPs that are pre-empted at this LSR. 4.3.2 Egress LSR An egress LSR that receives a ResvErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data from the old LSP. An egress LSR SHOULD NOT send any further messages for the pre-empted LSP as a specific result of receiving the ResvErr. In particular, it SHOULD NOT trigger a ResvTear or PathErr message. 5. Conversion Between Soft and Hard Pre-emption A transit LSR MUST NOT attempt to convert from hard to soft pre- emption while forwarding an error message. The rules described in the previous sections MUST be followed and will prevent this operation. A transit or egress LSR MAY convert from soft to hard pre-emption. Such an LSR MAY (under local policy control) determine that a soft pre-emption event is a trigger for hard pre-emption. In this case, LSR act as though it is the pre-empting LSR (which, in fact it is) and starts the procedures for hard pre-emption. An ingress LSR MUST not convert from soft to hard pre-emption. It should send a PathTear if that is what it wishes to achieve. 6. Unchanged Processing 6.1 RSVP-TE This document in no way changes the processing for any other situation in RSVP-TE. Farrel Page 6 draft-farrel-mpls-preemption-00.txt January 2004 6.1.1 PathErr with "Policy Control failure" This document does not change the behavior of LSRs receiving PathErr messages carrying the "Policy Control failure" Error Code with Error Values other than the two specified in this document. This leaves exsting implementations free to continue the pre-emption behavior that they already have. 6.1.2 Other PathErr Processing The procedures in this document applies only to PathErr messages that carry the "Policy Control failure"/"Hard Pre-empted" or the "Policy Control failure"/"Soft Pre-empted" error. No change in processing is intended or applied for PathErr messages carrying any other combination of Error Code and Error Value in any other circumstances. In particular, the following text from [RFC2205] is assumed to apply in all cases except for pre-emption. There are two RSVP error messages, ResvErr and PathErr. 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. 6.2 GMPLS RSVP-TE is extended for use in GMPLS by [RFC3473]. [RFC3473] inherits the pre-emption procedures as described in [RFC3209] and [RFC2205] without further modification. The procedures in this document are intended to clarify and supersede the pre-emption procedures for GMPLS. 6.2.1 Path State Removal Note that [RFC3473] introduces the Path_State_Removed flag to be carried on the PathErr message to indicate that the LSP to which the PathErr message applies has had its state removed by the sender. All upstream LSRs receiving this flag MUST also remove their Path state. The meaning and use of the Path_State_Removed flag is not changed by this document. During soft pre-emption, the Path_State_Removed flag MUST not be set. During hard pre-emption, the Path_State_Removed flag MAY be set. Note however, that if the Path_State_Reomved flag is set by the pre- empting LSR, it SHOULD send PathTear downsteam in place of ResvErr. Farrel Page 7 draft-farrel-mpls-preemption-00.txt January 2004 7. IANA Considerations This document introduces two new Error Values for the Error Code "Policy control failure". They may be used on PathErr and ResvErr messages. Error Value Meaning TBD Hard Pre-emption TBD Soft Pre-emption The values are to be assigned by IANA. It is strongly suggested that values in excess of 32 be used and that a value of zero definitely NOT be used. 8. Security Considerations Neither interpretation of pre-emption changes the fundamentals of security as expressed in [RFC3209]. 9. Acknowledgements I would like to thank Loa Andersson for encouraging me to write this document. 10. 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. 11. 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. Farrel Page 8 draft-farrel-mpls-preemption-00.txt January 2004 [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. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. 12. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. 13. Authors' Addresses Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk 14. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Farrel Page 9