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


.  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:

   <PathErr message> ::= <Common Header> [ <INTEGRITY> ]

   <SESSION> <ERROR_SPEC>

   [ <POLICY_DATA> ...]

   [ <sender descriptor> ]

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

   [ <ADSPEC> ]

   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.


.  IANA Considerations

   This document does not require any action for IANA.


.  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


.  Acknowledgements


.  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]