< draft-rhodes-rsvp-recovery-signaling-00.txt		draft-rhodes-rsvp-recovery-signaling-01.txt >
	IETF A. Rhodes		IETF A. Rhodes
	Internet-Draft N. Neate		Internet-Draft N. Neate
	Expires: February 7, 2009 D. McWalter, Ed.		Intended status: Informational D. McWalter, Ed.
	Data Connection Ltd		Expires: September 5, 2009 Data Connection Ltd
	August 6, 2008		March 4, 2009
	Problems observed with RSVP recovery signaling		Problems observed with RSVP recovery signaling
	draft-rhodes-rsvp-recovery-signaling-00.txt		draft-rhodes-rsvp-recovery-signaling-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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		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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 February 7, 2009.		This Internet-Draft will expire on September 5, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Abstract		Abstract
	Implementation experience with RSVP-TE recovery signaling has		Implementation experience with RSVP-TE recovery signaling has
	uncovered some problems. Associations between LSPs in different		uncovered some problems. Associations between LSPs in different
	sessions are forbidden. Protecting LSPs cannot themselves be		sessions are forbidden. Protecting LSPs cannot themselves be
	protected. Overlapping repairs cause loss of traffic. This draft		protected. Overlapping repairs cause loss of traffic. This draft
	provides details of these problems for the community to consider.		provides details of these problems for the community to consider.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Association between LSPs in different sessions . . . . . . 3		3.1. Association between LSPs in different sessions . . . . . . 4
	3.2 LSP association in multi-domain protection cases . . . . . 3		3.2. LSP association in multi-domain protection cases . . . . . 4
	3.3 Protecting LSPs cannot themselves be protected . . . . . . 3		3.3. Protecting LSPs cannot themselves be protected . . . . . . 4
	3.4 Overlapping repairs cause loss of traffic . . . . . . . . 4		3.4. Overlapping repairs cause loss of traffic . . . . . . . . 5
	4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.5. segment-recording-desired flag is unassigned . . . . . . . 5
	4.1 Association between LSPs in different sessions . . . . . . 4		4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2 LSP association in multi-domain protection cases . . . . . 4		4.1. Association between LSPs in different sessions . . . . . . 5
	4.3 Protecting LSPs cannot themselves be protected . . . . . . 4		4.2. LSP association in multi-domain protection cases . . . . . 7
	4.4 Overlapping repairs cause loss of traffic . . . . . . . . 5		4.3. Protecting LSPs cannot themselves be protected . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4.4. Overlapping repairs cause loss of traffic . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4.5. segment-recording-desired flag is unassigned . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 6		7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2 Informative References . . . . . . . . . . . . . . . . . . 6		7.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . 8		9. Informative References . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This draft describes problems. It does not propose solutions.		This draft describes problems. It does not propose solutions.
	Our purpose in writing this draft is to determine how to resolve some		Our purpose in writing this draft is to determine how to resolve some
	RSVP-TE recovery problems we have encountered. We believe these		RSVP-TE recovery problems we have encountered. We believe these
	problems are due to limitations in existing RSVP signaling		problems are due to limitations in existing RSVP signaling
	procedures.		procedures.
	We would like the community to consider whether the following		We would like the community to consider whether the following
	scenarios are within the requirements for RSVP-TE protection. If so,		scenarios are within the requirements for RSVP-TE protection. If so,
	we would like comments on whether we have correctly interpreted the		we would like comments on whether we have correctly interpreted the
	existing RSVP-TE signaling proceduress in each case. If so, we		existing RSVP-TE signaling proceduress in each case. If so, we
	solicit collaboration in preparing proposals for interoperable		solicit further collaboration in preparing proposals for
	solutions.		interoperable solutions.
	2. Terminology		2. Terminology
	GMPLS recovery terminology is introduced by [RFC4427].		GMPLS recovery terminology is introduced by [RFC4427].
	'End-to-end protection' (e2e) procedures are defined by [RFC4872].		'End-to-end protection' (e2e) procedures are defined by [RFC4872].
	'Segment recovery' procedures are defined by [RFC4873].		'Segment recovery' procedures are defined by [RFC4873].
	3. Summary		3. Summary
	3.1 Association between LSPs in different sessions		3.1. Association between LSPs in different sessions
	Segment recovery protecting LSPs may have a different endpoint		Segment recovery protecting LSPs may have a different endpoint
	address from the corresponding protected LSP. The protected and		address from the corresponding protected LSP. The protected and
	protecting LSPs are therefore in different Sessions. The Association		protecting LSPs are therefore in different Sessions. The Association
	object of type 1 (recovery) is not effective in this case, as the		object of type 1 (recovery) is not effective in this case, as the
	Association ID can only associate to an LSP ID within the same		Association ID can only associate to an LSP ID within the same
	Session.		Session.
	3.2 LSP association in multi-domain protection cases		3.2. LSP association in multi-domain protection cases
	End-to-end protected LSPs may pass through several addressing		End-to-end protected LSPs may pass through several addressing
	domains, resulting in mappings of addresses in the Session and		domains, resulting in mappings of addresses in the Session and
	Sender-Template. This causes difficulties for LSP endpoints		Sender-Template. This causes difficulties for LSP endpoints
	attempting to associate protecting and protected LSPs.		attempting to associate protecting and protected LSPs.
	3.3 Protecting LSPs cannot themselves be protected		3.3. Protecting LSPs cannot themselves be protected
	End-to-end or segment protection can be applied to a protecting LSP.		End-to-end or segment protection can be applied to a protecting LSP.
	That LSP is both protecting and protected. This cannot be signaled		That LSP is both protecting and protected. This cannot be signaled
	because only a single Protection object is allowed and it contains a		because only a single Protection object is allowed and it contains a
	single bit to indicate whether the LSP is protecting or protected.		single bit to indicate whether the LSP is protecting or protected.
	3.4 Overlapping repairs cause loss of traffic		3.4. Overlapping repairs cause loss of traffic
	Segment protection can be provided by two overlapping recovery paths.		Segment protection can be provided by two overlapping recovery paths.
	A single failure may trigger restoration using both repairs. Traffic		A single failure may trigger restoration using both repairs. Traffic
	is lost in this case.		is lost in this case.
			3.5. segment-recording-desired flag is unassigned
			[RFC4873] s5.2 defines this flag, but no value is given. We need to
			ask IANA to assign a value.
	4. Detail		4. Detail
	4.1 Association between LSPs in different sessions		4.1. Association between LSPs in different sessions
	Association objects of type 1 (recovery) always associate LSPs		End-to-end recovery uses Association objects of type 1 (recovery) to
	belonging to the same session ([RFC4872] s6.1, [RFC4873] s3).		associate LSPs belonging to the same session. Association ID is (in
			most cases) set to the LSP ID of the associated LSP. See [RFC4872]
			s4.3, s6.1 and s16.
	Segment recovery repair paths must use the endpoint specified by		[RFC4873] s3.2 and s3.2.1 state that procedures for use of the
	explicit or dynamic control procedures ([RFC4873] s4.2 and s6.2).		Association ID in segment recovery are not modified from those
			defined in [RFC4872] for end-to-end recovery. The following example
			shows that different procedures are necessary.
	In cases where the recovery path endpoint differs from the protected		A G D
	LSP endpoint, it is not possible to satisfy these restrictions.		\ / \ /
			\ / \ /
			B-----C
			/ \
			/ \
			E F
	As a result, segment recovery repair paths are not effective in these		Protected LSP1: A-B-C-D, LSP ID 5
	cases (unless non-interoperable assumptions are made).		Protected LSP2: E-B-C-F, LSP ID 5
			Segment recovery LSP1: B-G-C (1+1 protection)
			Segment recovery LSP2: B-G-C (1+1 protection)
	4.2 LSP association in multi-domain protection cases		It is not possible for B and C to use LSP ID 5 to associate the two
			segment recovery LSPs with the protected LSPs.
	LSPs may traverse multiple IP addressing domains. Address mappings		Discussion with authors suggests that it is intended that B assigns
	may modify the Session and Sender-Template at domain boundaries.		an arbitrary value as the Association ID, although this is not
			clearly spelled out. Here is how this applies to the example:
			Protected LSP1: A-B-C-D, LSP ID 5, Assoc ID 23
			Protected LSP2: E-B-C-F, LSP ID 5, Assoc ID 24
			Segment recovery LSP1: B-G-C (1+1 protection) Assoc ID 23
			Segment recovery LSP2: B-G-C (1+1 protection) Assoc ID 24
			This works in many cases, but introduces ambiguity when both segment
			recovery and end-to-end recovery are used in a network.
			?? protected LSP3: B-C, LSP ID 1, Assoc ID 25
			Segment recovery LSP: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25
			End-to-end recovery LSP: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1
			It is not possible to decide which of these recovery LSPs protects
			LSP3, at least not using existing procedures. The difficulty becomes
			more marked as additional LSPs are added:
			?? protected LSP3: B-C, LSP ID 1, Assoc ID 25
			Segment protected LSP4: A-B-C-D, LSP ID 5, Assoc ID 1
			?? recovery LSP5: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25
			?? recovery LSP6: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1
			(All Association objects are Type 1, Association Source B).
			Significant analysis is required to determine which LSPs might be
			associated, and which recovery LSPs are segment or end-to-end
			recovery. In this case, we might choose to regard LSP3 as segment
			protected by LSP5 rather than e2e protected by LSP6, as this allows
			us to associate LSP4 with LSP6.
			Such deductions may fail or prove incorrect where protected and
			recovery LSPs are not 1:1 paired. Therefore we can expect to see
			transient mapping errors as LSPs are established and released. We
			can also expect to see permanent errors for recovery schemes such as
			(Full) LSP rerouting that do not always pair protected and recovery
			LSPs.
			Two approaches to remove this difficulty have been suggested. Both
			modify [RFC4873] procedures.
			1. For a given Association Source, match Association objects by
			first looking for a matching segment recovery Association ID. If
			none exists, then match by treating Association ID as an LSP ID
			within the given Session. This resolves the ambiguity but
			restricts identifier use at the Association Source: values chosen
			as segment recovery Association IDs are unusable as LSP IDs from
			that source, and vice versa. A branch node implementing this
			approach would not allow management to use the full range of LSP
			IDs.
			2. Introduce a new Association type for segment recovery. Use
			Association type 1 only for end-to-end recovery. This removes
			the ambiguity. This keeps separate the LSP ID and Association ID
			number spaces. The meaning of the Association ID is given by the
			Association type. This is back-compatible with deployments of
			[RFC4872] but disrupts deployments of [RFC4873].
			4.2. LSP association in multi-domain protection cases
			A GMPLS domain may contain multiple IP addressing domains. Therefore
			an LSP may traverse multiple IP addressing domains. [RFC4927] and
			[RFC5376] show inter-area and inter-AS (G)MPLS-TE tunnel
			establishment.
			A given IP address may occur in more than one area or AS. (Otherwise
			the areas or ASes are not separate addressing domains). In order to
			support this, address mappings must modify the Session and Sender-
			Template at address domain boundaries.
	Protected and protecting LSPs may achieve diversity by traversing		Protected and protecting LSPs may achieve diversity by traversing
	different domains. The modifications to Session and Sender-Template		different domains. The cumulative modifications to Session and
	may result in the LSPs being in different sessions at the end of the		Sender-Template may result in the LSPs being in different sessions at
	repair path.		the merge point.
	In this case, the Association ID in the Association object cannot be		........ ........... ........
	used to associate the protecting and protected LSPs: The		. . . . . .
	restrictions of [RFC4872] s6.1 and those of [RFC4873] s3 prevent the		. A------B-----C------D .
	association of LSPs in different sessions.		. / . . . . \ .
			. / . .....2..... . \ .
			. I 1 3 E .
			. \ . .....4..... . / .
			. \ . . . . / .
			. F------G-----H------J .
			. . . . . .
			........ ........... ........
	As a result, end-to-end recovery repair paths are not effective in		In this illustration, four addressing domains (1-4) are shown.
	these cases (unless non-interoperable assumptions are made).		Together they make up a GMPLS domain across which LSPs can be set up.
			If two LSPs take the paths IABCDE and IFGHJE, then it is unclear
			whether these LSPs can be considered to be in the same session at
			node E.
	4.3 Protecting LSPs cannot themselves be protected		A/B translates Tunnel Sender / ext tunnel ID from I to 'K'.
			C/D translates Tunnel Sender / ext tunnel ID from K to 'L'.
			F/G translates Tunnel Sender / ext tunnel ID from I to 'M'.
			H/J translates Tunnel Sender / ext tunnel ID from M to 'N'.
	Only one protection object may be signaled. See [RFC4872] s17 and		So E may regard the LSPs as being in different sessions, as their
	[RFC4873] s7.		extended tunnel ID will differ, as will their tunnel sender address
			and any Association Source. These values were all set to 'I' in
			addressing domain 1.
			In such cases, the statement of [RFC4872] s6.1 that "both LSPs MUST
			belong to the same session" is difficult to apply. End-to-end
			protection might therefore not be applicable to a GMPLS domain
			containing multiple IP addressing domains.
			Applicability might be achieved if the GMPLS address mapping peformed
			at IP addressing domain boundaries (AB, CD, FG, HJ) within a GMPLS
			domain were to be specified or constrained. This is for discussion.
			4.3. Protecting LSPs cannot themselves be protected
	A segment recovery repair path can itself be protected by end-to-end		A segment recovery repair path can itself be protected by end-to-end
	or segment recovery repairs, according to [RFC4873] s2. The result		or segment recovery repairs, according to [RFC4873] s2. The result
	is an LSP segment that is both protected and protecting.		is an LSP segment that is both protected and protecting.
			However, only one protection object may be signaled. See [RFC4872]
			s17 and [RFC4873] s7.
	The (P)rotecting bit in the protection object should be set for the		The (P)rotecting bit in the protection object should be set for the
	LSP's protecting role, but clear for its protected role. See		LSP's protecting role, but clear for its protected role. See
	[RFC4872] s4.2.1, s14.1 and [RFC4873] s6.1.		[RFC4872] s4.2.1, s14.1 and [RFC4873] s6.1.
	Therefore protecting LSPs cannot themselves be protected by repair		Therefore protecting LSPs cannot themselves be protected by repair
	paths (unless we include non-interoperable procedures).		paths (unless we include non-interoperable procedures).
	4.4 Overlapping repairs cause loss of traffic		4.4. Overlapping repairs cause loss of traffic
	Consider the following topology:		Consider the following topology:
	K-----------L		K-----------L
	/ \		/ \
	A===B===C===D===E===F===G===H		A===B===C===D===E===F===G===H
	\ /		\ /
	I-----------J		I-----------J
	Primary bidirectional LSP A-B-C-D-E-F-G-H is protected by two		Primary bidirectional LSP A-B-C-D-E-F-G-H is protected by two
	overlapping segment recovery paths B-K-L-F and C-I-J-G. Suppose 1:1		overlapping segment recovery paths B-K-L-F and C-I-J-G. Suppose 1:1
	protection with extra traffic.		protection with extra traffic.
	This 'overlapping protection' is a valid case, see [RFC4873] section		This 'overlapping protection' is a valid case, see [RFC4873] section
	1.		1.
	Consider a failure of link D-E.		Consider a failure of link D-E.
	K-----------L		K-----------L
	/ \		/ \
	A===B===C===D=X=E===F===G===H		A===B===C===D=X=E===F===G===H
	\ /		\ /
	I-----------J		I-----------J
	D detects this locally, and sends Notify to C (first Notify object in		D detects this locally, and sends Notify to C (first Notify object in
	the received Path). C and G communicate to remove extra traffic from		the received Path). C and G communicate to remove extra traffic from
	the C-I-J-G repair, and then send and receive normal traffic on C-I		the C-I-J-G repair, and then send and receive normal traffic on C-I
	and G-J.		and G-J.
	Meanwhile, E also detects the failure locally, and sends Notify to F		Meanwhile, E also detects the failure locally, and sends Notify to F
	(first Notify object in the received Resv). F likewise communicates		(first Notify object in the received Resv). F likewise communicates
	with B and normal traffic is sent and received on B-K and F-L.		with B and normal traffic is sent and received on B-K and F-L.
	K----->-----L		K----->-----L
	/ \		/ \
	A->-Bx<-C---D-X-E---F->xG<--H		A->-Bx<-C---D-X-E---F->xG<--H
	\ /		\ /
	I-----<-----J		I-----<-----J
	Forward traffic reaches G on the link F-G. However, G has switched		Forward traffic reaches G on the link F-G. However, G has switched
	to send and receive on G-J. Reverse traffic reaches B on C-B.		to send and receive on G-J. Reverse traffic reaches B on C-B.
	However, B has switched to send and receive on B-K.		However, B has switched to send and receive on B-K.
	The standard procedure causes the loss of traffic in both directions.		Thus the standard procedure causes the loss of traffic in both
			directions.
			It may possible to solve this problem by configuring or otherwise
			assigning master/slave roles to the branch and merge points. See
			[RFC4426] s2.3. Currently there is no protocol description for how
			the master/slave roles might be dynamically assigned, nor how
			configured master/slave roles would affect [RFC4872] or [RFC4873]
			switchover.
			The mandatory procedures from [RFC4872] s6.2 and s7.2 (applied to
			segment recovery by [RFC4873] s2.1) prescribe the behaviour of the
			endpoints. It may be that procedures need to be modified so that
			endpoints have some latitude to decide not to perform switchover in
			some cases.
			It is possible to detect the 'overlapping repairs' condition at nodes
			B and G by using SRRO objects. These are optionally present between
			F and H on the path, and between C and A on the Resv, see [RFC4873]
			s2 and s5.2. In order to detect the problem reliably, procedures
			would need to change to make them mandatory.
			4.5. segment-recording-desired flag is unassigned
			[RFC4873] s5.2 assigns this flag as part of the SESSION_ATTRIBUTE
			object. However, no request was made to IANA to assign a value for
			it.
			We could correct this omission by asking IANA to assign a value. At
			the time of writing 0x40 is the next available value, see http://
			www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.txt
			Note that it is also open to specify that an LSP_ATTRIBUTE flag for
			this purpose. For discussion.
	5. Security Considerations		5. Security Considerations
	This document does not propose any protocol changes.		This document does not propose any protocol changes.
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. Acknowledgements		7. Revision History
	Thanks to all reviewers, including Snigdho Bardalai and Remi		7.1. Changes in -01
	Theillaud.
	Differing interpretations of RSVP signaling procedures confirmed that		Sections 3.1 and 4.1 better describe interactions between end-to-end
	we should circulate this draft.		and segment recovery use of Association type 1 Association ID.
	8. References		Sections 3.5 and 4.5 added, describing a missing codepoint.
	8.1 Normative References		Section 4.1 includes examples.
	8.2 Informative References		Section 4.1 includes Added Adrian Farrel's suggestion for egress to
			match segment recovery associations in precedence to end-to-end
			recovery associations.
			Section 4.2 includes an example.
			Section 4.2 questions the applicability of [RFC4872] to GMPLS domains
			containing multiple IP addressing domains.
			Section 4.4 notes that the SRRO object could provide a tool for
			detecting overlapping repairs, though its presence is not mandatory.
			Section 4.4 is updated with discussion of [RFC4426] roles, which do
			not appear to provide a solution.
			8. Acknowledgements
			The authors would like to thank all who have contributed to our
			understanding of these issues, particularly Snigdho Bardalai, Adrian
			Farrel, Remi Theillaud and Dimitri Papadimitriou.
			9. Informative References
			[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
			"Generalized Multi-Protocol Label Switching (GMPLS)
			Recovery Functional Specification", RFC 4426, March 2006.
	[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and		[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
	Restoration) Terminology for Generalized Multi-Protocol		Restoration) Terminology for Generalized Multi-Protocol
	Label Switching (GMPLS)", RFC 4427, March 2006.		Label Switching (GMPLS)", RFC 4427, March 2006.
	[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE		[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
	Extensions in Support of End-to-End Generalized Multi-		Extensions in Support of End-to-End Generalized Multi-
	Protocol Label Switching (GMPLS) Recovery", RFC 4872,		Protocol Label Switching (GMPLS) Recovery", RFC 4872,
	May 2007.		May 2007.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,		[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
	"GMPLS Segment Recovery", RFC 4873, May 2007.		"GMPLS Segment Recovery", RFC 4873, May 2007.
			[RFC4927] Le Roux, J., "Path Computation Element Communication
			Protocol (PCECP) Specific Requirements for Inter-Area MPLS
			and GMPLS Traffic Engineering", RFC 4927, June 2007.
			[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
			Requirements for the Path Computation Element
			Communication Protocol (PCECP)", RFC 5376, November 2008.
	Authors' Addresses		Authors' Addresses
	Andrew Rhodes		Andrew Rhodes
	Data Connection Ltd		Data Connection Ltd
	100 Church Street		100 Church Street
	Enfield EN2 6BQ		Enfield EN2 6BQ
	United Kingdom		United Kingdom
	Email: adr@dataconnection.com		Email: adr@dataconnection.com
	Nic Neate		Nic Neate
	Data Connection Ltd		Data Connection Ltd
	100 Church Street		100 Church Street
	Enfield EN2 6BQ		Enfield EN2 6BQ
	United Kingdom		United Kingdom
	Email: nhn@dataconnection.com		Email: nhn@dataconnection.com
	David McWalter (editor)		David McWalter (editor)
	Data Connection Ltd		Data Connection Ltd
	100 Church Street		100 Church Street
	Enfield EN2 6BQ		Enfield EN2 6BQ
	United Kingdom		United Kingdom
	Email: dmcw@dataconnection.com		Email: dmcw@dataconnection.com
	Intellectual Property Statement
	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.
	Disclaimer of Validity
	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, THE IETF TRUST 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.
	Copyright Statement
	Copyright (C) The IETF Trust (2008). 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.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
End of changes. 39 change blocks.
	86 lines changed or deleted		283 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/