draft-ietf-mpls-3209-patherr-00.txt		draft-ietf-mpls-3209-patherr-01.txt
	Networking Working Group JP. Vasseur, Ed.		Networking Working Group JP. Vasseur, Ed.
	Internet-Draft George. Swallow		Internet-Draft George. Swallow
	Intended status: Best Current Cisco Systems, Inc		Intended status: Best Current Cisco Systems, Inc
	Practice Adrian. Farrel		Practice Adrian. Farrel
	Expires: November 4, 2007 Old Dog Consulting		Expires: August 11, 2008 Old Dog Consulting
	May 3, 2007		Ina. Minei
			Juniper Networks
			February 8, 2008
	Node behavior upon originating and receiving Resource ReserVation		Node behavior upon originating and receiving Resource ReserVation
	Protocol (RSVP) Path Error message		Protocol (RSVP) Path Error message
	draft-ietf-mpls-3209-patherr-00.txt		draft-ietf-mpls-3209-patherr-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 4, 2007.		This Internet-Draft will expire on August 11, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The aim of this document is to describe a common practice with regard		The aim of this document is to describe a common practice with regard
	to the behavior of a node sending a Resource ReserVation Protocol		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) Traffic Engineering (TE) Path Error message and to the
	RSVP Path Error message for a particular Multi-Protocol Label		behavior of a node receiving an RSVP Path Error message for a
	Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP).		preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering
			Label Switched Path (TE LSP). This document does not define any new
	This document does not define any new protocol extensions.		protocol extensions.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3		1. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4		1.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4
	1.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4		1.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4
	1.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5		1.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5
	2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		2. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	5. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Protocol behavior		1. Protocol behavior
	[RFC2205] defines two RSVP error message types: PathErr and ResvErr		[RFC2205] defines two RSVP error message types: PathErr and ResvErr
	that are generated when an error occurs. Path Error Messages		that are generated when an error occurs. Path Error Messages
	(PathErr) are used to report errors and travel upstream toward the		(PathErr) are used to report errors and travel upstream toward the
	head-end of the flow. Resv Error messages (ResvErr) travel		head-end of the flow. Resv Error messages (ResvErr) travel
	downstream toward the tail-end of the flow.		downstream toward the tail-end of the flow.
	This document describes only PathErr message processing. PathErr		This document describes only PathErr message processing for the
			specific case of a preempted Traffic Engineering Label Switched Path
			(TE LSP) where the term preemption is defined in [RFC3209]. PathErr
	messages are routed hop-by-hop using the path state established when		messages are routed hop-by-hop using the path state established when
	a Path message is routed through the network from the head-end to its		a Path message is routed through the network from the head-end to its
	tail-end.		tail-end.
	As stated in [RFC2205], PathErr messages do not modify the state of		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-		any node through which they pass; they are only reported to the head-
	end of the TE LSP (Traffic Engineering Label Switched Path).		end of the TE LSP (Traffic Engineering Label Switched Path).
	The format of the PathErr message as defined in [RFC2205] is as		The format of the PathErr message as defined in [RFC2205] is as
	follows:		follows:
	skipping to change at page 3, line 41		skipping to change at page 3, line 43
	[ <ADSPEC> ]		[ <ADSPEC> ]
	The ERROR_SPEC object includes the IP address of the node that		The ERROR_SPEC object includes the IP address of the node that
	detected the error (Error Node Address), and specifies the error		detected the error (Error Node Address), and specifies the error
	through two fields. The Error Code field encodes the category of the		through two fields. The Error Code field encodes the category of the
	error, for example, Policy Control Failure or Unknown object class.		error, for example, Policy Control Failure or Unknown object class.
	The Error Value field qualifies the error code to indicate the error		The Error Value field qualifies the error code to indicate the error
	with more precision. [RFC3209] extends RSVP as defined in [RFC2205]		with more precision. [RFC3209] extends RSVP as defined in [RFC2205]
	for the management of Multi-Protocol Label Switching (MPLS) Traffic		for the management of Multi-Protocol Label Switching (MPLS) Traffic
	Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies		Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies
	several additional conditions that trigger the sending of an RSVP		several additional conditions that trigger the sending of a RSVP
	PathErr message for which new error codes and error values have been		PathErr message for which new error codes and error values have been
	defined that extend the list defined in [RFC2205]. The exact		defined that extend the list defined in [RFC2205]. The exact
	circumstances under which such PathErr messages are sent are defined		circumstances under which a TE LSP is preempted and such PathErr
	in [RFC3209] and will not be repeated here.		messages are sent are defined in [RFC3209] and will not be repeated
			here.
	Values for the Error Code and Error Value fields defined in		Values for the Error Code and Error Value fields defined in
	[RFC2205], [RFC3209], and other documents are maintained in a		[RFC2205], [RFC3209], and other documents are maintained in a
	registry by the IANA. A full list can be seen at Section 5. The		registry by the IANA.
	error conditions fall into two categories: - fatal errors represent
	disruptive conditions for a TE LSP, - non-fatal errors are non-		The error conditions fall into two categories:
	disruptive conditions which have occurred for this TE LSP.
	Additionally, PathErr messages may be used in two circumstances: -		o Fatal errors represent disruptive conditions for a TE LSP,
	during TE LSP establishment, - after a TE LSP has been successfully
	established. Nodal behavior is dependent on which combination of the		o Non-fatal errors are non-disruptive conditions which have occurred
	four cases listed above applies. The following sections describe the		for this TE LSP
	expected behavior at nodes that detect (and therefore report using
	PathErr messages) errors, and at nodes that receive PathErr messages.		Additionally, PathErr messages may be used in two circumstances:
	This text is a clarification and re-statement of the procedures set
	out in [RFC3209] and does not define any new behavior. Section 2		o During TE LSP establishment,
	provides a list of the currently defined PathErr Error Codes and
	Error Values and indicates for each whether it is fatal or non-fatal.		o After a TE LSP has been successfully established.
			Nodal behavior is dependent on which combination of the four cases
			listed above applies. The following sections describe the expected
			behavior at nodes that perform a preemption action for a TE LSP (and
			therefore report using error PathErr messages), and at nodes that
			receive PathErr messages. This text is a clarification and re-
			statement of the procedures set out in [RFC3209] and does not define
			any new behavior.
	1.1. Behavior at Detecting Nodes		1.1. Behavior at Detecting Nodes
	In the case of fatal errors, the detecting node must send a PathErr		In the case of fatal errors, the detecting node must send a PathErr
	message reporting the error condition, and must clear the		message reporting the error condition, and must clear the
	corresponding Path and Resv (control plane) states. A direct		corresponding Path and Resv (control plane) states. A direct
	implication is that the data plane resources of such a TE LSP are		implication is that the data plane resources of such a TE LSP are
	also released, thus resulting in traffic disruption. It should be		also released, thus resulting in traffic disruption. It should be
	noted, however, that in fatal error cases, the LSP has usually		noted, however, that in fatal error cases, the LSP has usually
	already failed in the data plane, and traffic has already been		already failed in the data plane, and traffic has already been
	skipping to change at page 5, line 11		skipping to change at page 5, line 21
	the TE LSP. The message receiver should do likewise before		the TE LSP. The message receiver should do likewise before
	forwarding the message, but may retain state and clear the flag		forwarding the message, but may retain state and clear the flag
	before forwarding the message.		before forwarding the message.
	1.3. Data Plane Behavior		1.3. Data Plane Behavior
	Any node clearing either or both the Path or the Resv state of a TE		Any node clearing either or both the Path or the Resv state of a TE
	LSP MUST also free up the data plane resources allocated to the		LSP MUST also free up the data plane resources allocated to the
	corresponding TE LSP.		corresponding TE LSP.
	2. IANA Considerations		2. RSVP PathErr Messages For a Preempted TE LSP
	IANA maintains a registry of RSVP Error Codes and Error Values at		Two Error-code can be used to report a preempted TE LSPs:
	Section 5. The registry is labeled "Resource ReSerVation Protocol
	(RSVP) Parameters" / "Error Codes and Values" IANA is requested to
	add a column to this registry to indicate for each Error Code / Error
	Value combination whether the error reported constitutes a fatal or
	non-fatal error condition if the error is seen in an MPLS-TE system.
	It is suggested that the column in headed "MPLS-TE Fatal" and contain
	one of three values: Yes - The error condition represents a fatal
	condition as described in this document when applied to an MPLS TE
	LSP. No - The error condition represents a non-fatal condition as
	described in this document when applied to an MPLS TE LSP. N/A - The
	error condition cannot be applied to an MPLS TE LSP. IANA should
	require that all new assignments from this registry provide
	information in this column. In order to update this registry for the
	creation of this column, the table below supplies the setting of the
	column for each existing entry in the registry. IANA is requested to
	transfer this information into the registry. Note that only the
	Error Code and Error Value numbers are supplied here. No change to
	any of the other registry fields is implied.
	Error code Error Value Reference MPLS-TE Fatal		o As defined in [RFC2750]:Error Code=2: "Policy Control Failure",
	------------+--------------+--------------+--------------		Error Value=5 "Flow was preempted"
	0 Any [RFC2205] N/A
	1 Any [RFC2205] N/A		o As defined in [RFC2205], Error Code=12: "Service preempted"
	2 5 [RFC2750] Yes
	100 [RFC3476] N/A		In both cases, these are fatal errors.
	101 [RFC3476] N/A
	102 [RFC4495] N/A
	Any other [RFC2205] N/A
	3 Any [RFC2205] N/A
	4 Any [RFC2205] N/A
	5 Any [RFC2205] Yes
	6 Any [RFC2205] N/A
	7 Any [RFC2205] N/A
	8 Any [RFC2205] N/A
	9 Any [RFC2205] N/A
	10 Any [RFC2205] N/A
	11 Any [RFC2205] N/A
	12 Any [RFC2205] N/A
	13 Any [RFC2205]
	14 Any [RFC2205]
	15 Any [RFC2205] N/A
	16 Any [RFC2205] N/A
	17 Any [RFC2205] N/A
	18 Any [RFC2205] N/A
	19 Any [RFC2205] N/A
	20 Any [RFC2205] N/A
	21 Any [RFC2205]
	22 Any [RFC2205]
	23 Any [RFC2205]
	24 1 [RFC3209] Yes
	2 [RFC3209] Yes
	3 [RFC3209] Yes
	4 [RFC3209] Yes
	5 [RFC3209] Yes
	6 [RFC3209] Yes
	7 [RFC3209] Yes
	8 [RFC3209] Yes
	9 [RFC3209] Yes
	10 [RFC3209] Yes
	11 [RFC3473] Yes
	12 [RFC3473] Yes
	13 [RFC3473] Yes
	14 [RFC3473] Yes
	15 [RFC3473] Yes
	16 [RFC3473] Yes
	100 [RFC3476] N/A
	101 [RFC3476] N/A
	102 [RFC3476] N/A
	103 [RFC3474] N/A
	104 [RFC3474] N/A
	105 [RFC3474] N/A
	106 [RFC3474] N/A
	25 1 [RFC3209] No
	2 [RFC3209] No
	3 [RFC3209] No
	4 [RFC3473] No
	5 [RFC3473] No
	6 [draft-ietf-ccamp-loose-path-reopt] No
	7 [draft-ietf-ccamp-loose-path-reopt] No
	8 [draft-ietf-ccamp-loose-path-reopt] No
	26 Any [RFC3175] N/A
	27 Any [RFC3270] N/A
	28 Any [RFC4124] Yes
	29 Any [RFC4420]
	30 Any [RFC4420]
	3. Security Considerations		3. Security Considerations
	This document does not define any new procedures, but clarifies those		This document does not define any new procedures, but clarifies those
	defined in other documents where security considerations are already		defined in other documents where security considerations are already
	specified. This document does not raise specific security issues		specified. This document does not raise specific security issues
	beyond those of existing MPLS-TE. By clarifying the procedures, this		beyond those of existing MPLS-TE. By clarifying the procedures, this
	document reduces the security risk introduced by non-conformant		document reduces the security risk introduced by non-conformant
	implementations.		implementations.
	4. Acknowledgements		4. Acknowledgements
	The author would like to thank Carol Iturralde, Ashok Narayanan, Rom		The author would like to thank Carol Iturralde, Ashok Narayanan, Rom
	Reuther and Reshad Rahman.		Reuther and Reshad Rahman.
	5. URLs		5. Normative References
	[IANA-URL] http://www.iana.org/numbers.html
	6. Normative References
	[I-D.ietf-ccamp-loose-path-reopt]
	Vasseur, J., "Reoptimization of Multiprotocol Label
	Switching (MPLS) Traffic Engineering (TE) loosely routed
	Label Switch Path (LSP)",
	draft-ietf-ccamp-loose-path-reopt-02 (work in progress),
	February 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",		[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
	RFC 2750, January 2000.		RFC 2750, January 2000.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
	[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol
	(RSVP) Extension for the Reduction of Bandwidth of a
	Reservation Flow", RFC 4495, May 2006.
	Authors' Addresses		Authors' Addresses
	JP Vasseur (editor)		JP Vasseur (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Email: jpv@cisco.com		Email: jpv@cisco.com
	skipping to change at page 9, line 4		skipping to change at page 7, line 4
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Email: swallow@cisco.com		Email: swallow@cisco.com
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	Email: adrian@olddog.co.uk		Email: adrian@olddog.co.uk
			Ina Minei
			Juniper Networks
			1194 North Mathilda Ave.
			Sunnyvale, 94089
			Email: ina@juniper.net
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 17 change blocks.
	138 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/