Networking Working Group JP. Vasseur Internet-Draft George. Swallow Intended status: Best Current Cisco Systems, Inc Practice Adrian. Farrel Expires: March 9, 2007 Old Dog Consulting September 5, 2006 Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message draft-vasseur-mpls-3209-patherr-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on March 9, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a particular Multi-Protocol Label Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP). Vasseur, et al. Expires March 9, 2007 [Page 1] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 This text does not define any new protocol extensions. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Vasseur, et al. Expires March 9, 2007 [Page 2] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 1. Protocol behavior [RFC2205] defines two RSVP error message types: ResvErr and PathErr that are generated when an error occurs. Path Error Messages (PathErr) are used to report errors and travel upstream towards the head-end of the flow. PathErr messages are routed hop-by-hop using the path state. As stated in [RFC2205], PathErr messages do not modify the state of any node through which they pass; they are only reported to the head- end of the TE LSP (Traffic Engineering Label Switched Path). The format of the PathErr message is as follows: ::= [ ] [ ...] [ ] ::= [ ] The ERROR_SPEC object specifies the error and includes the IP address of the node that detected the error (Error Node Address). [RFC3209] specifies several conditions that trigger the sending of an RSVP PathErr message for which new error codes and error values have been defined that extend the list defined in [RFC2205]. The exact circumstances under which such PathErr messages are sent are defined in [RFC3209] and will not be repeated here. Error Code Meaning 02 Policy Control failure Reservation or path message has been rejected for administrative reasons, for example, required credentials not submitted, insufficient quota or balance, or administrative preemption. This Error Code may appear in a PathErr or ResvErr message. 24 Routing Problem This Error Code has the following globally-defined Error Value sub- Vasseur, et al. Expires March 9, 2007 [Page 3] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 codes: 1 Bad EXPLICIT_ROUTE object 2 Bad strict node 3 Bad loose node 4 Bad initial subobject 5 No route available toward destination 6 Unacceptable label value 7 RRO indicated routing loops 8 MPLS being negotiated, but a non-RSVP-capable router stands in the path 9 MPLS label allocation failure 10 Unsupported L3PID 25 Notify Error This Error Code has the following globally-defined Error Value sub- codes: 1 RRO too large for MTU 2 RRO Notification 3 Tunnel locally repaired PathErr message types defined in [RFC3209] fall into two categories: fatal errors (Policy Control Failure, Routing Problem) reporting a disruptive condition for a TE LSP and non-fatal errors (Notification) reporting a non-disruptive condition which as occurred for this TE LSP. Policy Control Failure is for example triggered upon TE LSP preemption. Routing Problems usually (but not necessarily) arise during LSP establishment and result in the LSP failing to be set up. PathErr message types defined in [RFC2205] can similarly be split into fatal errors and non-fatal errors. Detecting Node Behavior In the case of fatal errors, the detecting node must send a PathErr Vasseur, et al. Expires March 9, 2007 [Page 4] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 (Policy Control Failure, Routing Problem) message, and MUST clear the corresponding Path and Resv (control plane) states. A direct implication is that the data plane resources of such TE LSP are also released, thus resulting in traffic disruption. Clearly, where the error arises during LSP establishment, the implications are different to when it arises on an active LSP. Conversely, in the case of non-fatal errors, the originating node SHOULD send a PathErr (Notify) message, and MUST NOT clear control plane or data plane state as a result. Receiving Node Behavior In accordance with [RFC2205] a node receiving a PathErr message takes no action upon it and consequently MUST NOT clear Path or Resv control plane or data plane state. This is true regardless of the type of PathError, Notify or Routing Problem (non-fatal or fatal). RSVP states SHOULD only be affected upon receiving a PathTear message (Path and Resv states cleared, and data plane resources released), upon receiving a ResvTear message (Resv states cleared, and data plane resources released), in case of state refresh timeout (Path state timeout clears Path and Resv state, and data plane resources released), Resv state timeout clears Resv state only, and data plane resources are released), upon receiving a PathError message with the Path_State_Removed flag of the ERROR_SPEC object set (as defined in [RFC3473])(Path and Resv states cleared, and data plane resources released). Data plane behavior Any node clearing the Path or the Resv state of a TE LSP MUST also free up the data plane resources allocated to the corresponding TE LSP. 2. IANA Considerations This document does not require any action for IANA. 3. Security Considerations The practice described in this document does not raise specific security issues beyond those of existing MPLS-TE. Vasseur, et al. Expires March 9, 2007 [Page 5] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 4. Acknowledgements 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] This Internet-Draft is being submitted for eventual publication as an RFC with a proposed status of BCP. Discussion of this proposal should take place on the following mailing list: mpls@ietf.org. Authors' Addresses JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com George Swallow Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: swallow@cisco.com Vasseur, et al. Expires March 9, 2007 [Page 6] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Vasseur, et al. Expires March 9, 2007 [Page 7] Internet-Draft draft-vasseur-mpls-3209-patherr-00.txt September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Vasseur, et al. Expires March 9, 2007 [Page 8]