draft-ietf-mpls-3209-patherr-04.txt		draft-ietf-mpls-3209-patherr-05.txt
	Networking Working Group JP. Vasseur, Ed.		Networking Working Group JP. Vasseur, Ed.
	Internet-Draft George. Swallow		Internet-Draft George. Swallow
	Intended status: BCP Cisco Systems, Inc		Intended status: BCP Cisco Systems, Inc
	Expires: August 6, 2009 Ina. Minei		Expires: January 30, 2010 Ina. Minei
	Juniper Networks		Juniper Networks
	February 2, 2009		July 29, 2009
	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-04.txt		draft-ietf-mpls-3209-patherr-05.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 August 6, 2009.		This Internet-Draft will expire on January 30, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	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) Traffic Engineering (TE) Path Error message and to the		(RSVP) Traffic Engineering (TE) Path Error message and to the
	behavior of a node receiving an RSVP Path Error message for a		behavior of a node receiving an RSVP Path Error message for a
	preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering		preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS
	Label Switched Path (TE LSP). This document does not define any new		(GMPLS) Traffic Engineering Label Switched Path (TE LSP). This
	protocol extensions.		document does not define any new 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3		2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4		2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4
	2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 5		2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4
	2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5		2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5
	3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5		3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 6		7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	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) Traffic Engineering (TE) Path Error message and to the		(RSVP) Traffic Engineering (TE) Path Error message and to the
	behavior of a node receiving an RSVP Path Error message for a		behavior of a node receiving an RSVP Path Error message for a
	preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering		preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS
	Label Switched Path (TE LSP).		(GMPLS) Traffic Engineering Label Switched Path (TE LSP).
	[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 for the		This document describes only PathErr message processing for the
	specific case of a preempted Traffic Engineering Label Switched Path		specific case of a preempted Traffic Engineering Label Switched Path
	(TE LSP) where the term preemption is defined in [RFC3209].		(TE LSP) where the term preemption is defined in [RFC3209].
	skipping to change at page 3, line 34		skipping to change at page 3, line 34
	2. Protocol behavior		2. Protocol behavior
	PathErr messages are routed hop-by-hop using the path state		PathErr messages are routed hop-by-hop using the path state
	established when a Path message is routed through the network from		established when a Path message is routed through the network from
	the head-end to its tail-end.		the head-end to its 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].
	follows:
	<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
	<SESSION> <ERROR_SPEC>
	[ <POLICY_DATA> ...]
	[ <sender descriptor> ]
	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
	[ <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 a RSVP		several additional conditions that trigger the sending of a RSVP
	skipping to change at page 4, line 24		skipping to change at page 4, line 14
	[RFC2205], [RFC3209], and other documents are maintained in a		[RFC2205], [RFC3209], and other documents are maintained in a
	registry by the IANA.		registry by the IANA.
	The error conditions fall into two categories:		The error conditions fall into two categories:
	o Fatal errors represent disruptive conditions for a TE LSP,		o Fatal errors represent disruptive conditions for a TE LSP,
	o Non-fatal errors are non-disruptive conditions which have occurred		o Non-fatal errors are non-disruptive conditions which have occurred
	for this TE LSP		for this TE LSP
	Additionally, PathErr messages may be used in two circumstances:		PathErr messages may be used in two circumstances:
	o During TE LSP establishment,		o During TE LSP establishment,
	o After a TE LSP has been successfully established.		o After a TE LSP has been successfully established.
	Nodal behavior is dependent on which combination of the four cases		Nodal behavior is dependent on which combination of the four cases
	listed above applies. The following sections describe the expected		listed above applies. The following sections describe the expected
	behavior at nodes that perform a preemption action for a TE LSP (and		behavior at nodes that perform a preemption action for a TE LSP (and
	therefore report using error PathErr messages), and at nodes that		therefore report using error PathErr messages), and at nodes that
	receive PathErr messages. This text is a clarification and re-		receive PathErr messages. This text is a clarification and re-
End of changes. 11 change blocks.
	27 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/