< draft-ietf-pce-pcep-18.txt		draft-ietf-pce-pcep-19.txt >
	Networking Working Group JP. Vasseur, Ed.		Networking Working Group JP. Vasseur, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track JL. Le Roux, Ed.		Intended status: Standards Track JL. Le Roux, Ed.
	Expires: May 6, 2009 France Telecom		Expires: May 21, 2009 France Telecom
	November 2, 2008		November 17, 2008
	Path Computation Element (PCE) Communication Protocol (PCEP)		Path Computation Element (PCE) Communication Protocol (PCEP)
	draft-ietf-pce-pcep-18.txt		draft-ietf-pce-pcep-19.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 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 May 6, 2009.		This Internet-Draft will expire on May 21, 2009.
	Abstract		Abstract
	This document specifies the Path Computation Element Communication		This document specifies the Path Computation Element Communication
	Protocol (PCEP) for communications between a Path Computation Client		Protocol (PCEP) for communications between a Path Computation Client
	(PCC) and a Path Computation Element (PCE), or between two PCEs.		(PCC) and a Path Computation Element (PCE), or between two PCEs.
	Such interactions include path computation requests and path		Such interactions include path computation requests and path
	computation replies as well as notifications of specific states		computation replies as well as notifications of specific states
	related to the use of a PCE in the context of Multiprotocol Label		related to the use of a PCE in the context of Multiprotocol Label
	Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP		Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	8.2. Information and Data Models . . . . . . . . . . . . . . . 58		8.2. Information and Data Models . . . . . . . . . . . . . . . 58
	8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 58		8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 58
	8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 58		8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 58
	8.5. Requirements on Other Protocols and Functional		8.5. Requirements on Other Protocols and Functional
	Components . . . . . . . . . . . . . . . . . . . . . . . . 59		Components . . . . . . . . . . . . . . . . . . . . . . . . 59
	8.6. Impact on Network Operation . . . . . . . . . . . . . . . 59		8.6. Impact on Network Operation . . . . . . . . . . . . . . . 59
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
	9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 60		9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 60
	9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 60		9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 60
	9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 60		9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 60
	9.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 61		9.4. PCEP Message Common Header . . . . . . . . . . . . . . . . 61
	9.5. Notification Object . . . . . . . . . . . . . . . . . . . 62		9.5. Open Object Flag Field . . . . . . . . . . . . . . . . . . 62
	9.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 62		9.6. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 62
	9.7. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 63		9.7. NO-PATH Object Flag Field . . . . . . . . . . . . . . . . 63
	9.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 64		9.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 63
	9.9. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 64		9.9. LSPA Object Flag Field . . . . . . . . . . . . . . . . . . 64
	9.10. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 65		9.10. SVEC Object Flag Field . . . . . . . . . . . . . . . . . . 65
	9.11. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 65		9.11. Notification Object . . . . . . . . . . . . . . . . . . . 65
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 65		9.12. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 66
	10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 65		9.13. LOAD-BALANCING Object Flag Field . . . . . . . . . . . . . 68
	10.2. TCP Security Techniques . . . . . . . . . . . . . . . . . 66		9.14. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 68
	10.3. PCEP Authentication and Integrity . . . . . . . . . . . . 67		9.15. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 69
	10.4. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 67		9.16. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 69
	10.5. Key Configuration and Exchange . . . . . . . . . . . . . . 68		10. Security Considerations . . . . . . . . . . . . . . . . . . . 69
	10.6. Access Policy . . . . . . . . . . . . . . . . . . . . . . 69		10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 69
	10.7. Protection Against Denial of Service Attacks . . . . . . . 70		10.2. TCP Security Techniques . . . . . . . . . . . . . . . . . 70
	10.7.1. Protection Against TCP DoS Attacks . . . . . . . . . . 70		10.3. PCEP Authentication and Integrity . . . . . . . . . . . . 71
	10.7.2. Request Input Shaping/Policing . . . . . . . . . . . . 71		10.4. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 71
	11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 71		10.5. Key Configuration and Exchange . . . . . . . . . . . . . . 72
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72		10.6. Access Policy . . . . . . . . . . . . . . . . . . . . . . 73
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73		10.7. Protection Against Denial of Service Attacks . . . . . . . 74
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 73		10.7.1. Protection Against TCP DoS Attacks . . . . . . . . . . 74
	13.2. Informative References . . . . . . . . . . . . . . . . . . 73		10.7.2. Request Input Shaping/Policing . . . . . . . . . . . . 75
	13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 76		11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75
	Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 76		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
	Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 83		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84		13.1. Normative References . . . . . . . . . . . . . . . . . . . 77
	Intellectual Property and Copyright Statements . . . . . . . . . . 85		13.2. Informative References . . . . . . . . . . . . . . . . . . 77
			13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 80
			Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 80
			Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 87
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
			Intellectual Property and Copyright Statements . . . . . . . . . . 89
	1. Introduction		1. Introduction
	[RFC4655] describes the motivations and architecture for a Path		[RFC4655] describes the motivations and architecture for a Path
	Compuation Element (PCE) based model for the computation of		Compuation Element (PCE) based model for the computation of
	Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic		Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic
	Engineering Label Swtich Paths (TE LSPs). The model allows for the		Engineering Label Swtich Paths (TE LSPs). The model allows for the
	separation of PCE from Path Computation Client (PCC), and allows for		separation of PCE from Path Computation Client (PCC), and allows for
	the cooperation between PCEs. This necessitates a communication		the cooperation between PCEs. This necessitates a communication
	protocol between PCC and PCE, and between PCEs. [RFC4657] states the		protocol between PCC and PCE, and between PCEs. [RFC4657] states the
	skipping to change at page 29, line 23 ¶		skipping to change at page 29, line 23 ¶
	| |		| |
	// Optional TLVs //		// Optional TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: RP object body format		Figure 10: RP object body format
	The RP object body has a variable length and may contain additional		The RP object body has a variable length and may contain additional
	TLVs. No TLVs are currently defined.		TLVs. No TLVs are currently defined.
	Flags (24 bits)		Flags (32 bits)
	The following flags are currently defined:		The following flags are currently defined:
	o Pri (Priority - 3 bits): the Priority field may be used by the		o Pri (Priority - 3 bits): the Priority field may be used by the
	requesting PCC to specify to the PCE the request's priority from 1		requesting PCC to specify to the PCE the request's priority from 1
	to 7. The decision of which priority should be used for a		to 7. The decision of which priority should be used for a
	specific request is of a local matter and MUST be set to 0 when		specific request is of a local matter and MUST be set to 0 when
	unused. Furthermore, the use of the path computation request		unused. Furthermore, the use of the path computation request
	priority by the PCE's scheduler is implementation specific and out		priority by the PCE's scheduler is implementation specific and out
	of the scope of this document. Note that it is not required for a		of the scope of this document. Note that it is not required for a
	skipping to change at page 61, line 45 ¶		skipping to change at page 61, line 45 ¶
	1		1
	14 LOAD-BALANCING This document		14 LOAD-BALANCING This document
	Object-Type		Object-Type
	1		1
	15 CLOSE This document		15 CLOSE This document
	Object-Type		Object-Type
	1		1
	9.4. RP Object		9.4. PCEP Message Common Header
			IANA is requested to create a registry to manage the Flag field of
			the PCEP Message Common Header.
	New bit numbers may be allocated only by an IETF Consensus action.		New bit numbers may be allocated only by an IETF Consensus action.
	Each bit should be tracked with the following qualities:		Each bit should be tracked with the following qualities:
	o Bit number		o Bit number (counting from bit 0 as the most significant bit)
	o Capability Description		o Capability Description
	o Defining RFC		o Defining RFC
	Several bits are defined in this document. The following values have		No Bits are currently for the PCEP message common header.
	been assigned:
			9.5. Open Object Flag Field
			IANA is requested to create a registry to manage the Flag field of
			the Open object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			No Bits are currently for the Open object flag field.
			9.6. RP Object
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			Several bits are defined for the RP Object flag field in this
			document. The following values have been assigned:
	Codespace of the Flag field (RP Object)		Codespace of the Flag field (RP Object)
	Bit Description Reference		Bit Description Reference
	0-2 Priority This document		26 Strict/Loose This document
	3 Reoptimization This document		27 Bi-directional This document
	4 Bi-directional This document		28 Reoptimization This document
	5 Strict/Loose This document		29-31 Priority This document
	9.5. Notification Object		9.7. NO-PATH Object Flag Field
			IANA is requested to create a registry to manage the codespace of NI
			field and the Flag field of the NO-PATH object.
			Value Meaning Reference
			0 No path satisfying the set This document
			of constraints could be found
			1 PCE chain broken This document
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			One bit is defined for the NO-PATH Object flag field in this
			document:
			Codespace of the Flag field (NO-PATH Object)
			Bit Description Reference
			0 Unsatisfied constrained indicated This document
			9.8. METRIC Object
			IANA is requested to create a registry to manage the codespace of T
			field and the Flag field of the METRIC Object.
			Codespace of the T field (Metric Object)
			Value Meaning Reference
			1 IGP metric This document
			2 TE metric This document
			3 Hop Counts This document
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			Several bits are defined in this document. The following values have
			been assigned:
			Codespace of the Flag field (Metric Object)
			Bit Description Reference
			6 Computed metric This document
			7 Bound This document
			9.9. LSPA Object Flag Field
			IANA is requested to create a registry to manage the Flag field of
			the LSPA object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			One bit is defined for the LSPA Object flag field in this document:
			Codespace of the Flag field (LSPA Object)
			Bit Description Reference
			7 Local Protection Desired This document
			9.10. SVEC Object Flag Field
			IANA is requested to create a registry to manage the Flag field of
			the SVEC object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			Three bits are defined for the SVEC Object flag field in this
			document:
			Codespace of the Flag field (SVEC Object)
			Bit Description Reference
			21 Link Diverse This document
			22 Node Diverse This document
			23 SRLG Diverse This document
			9.11. Notification Object
	IANA is requested to create a registry for the Notification-type and		IANA is requested to create a registry for the Notification-type and
	Notification-value of the Notification Object and manage the code		Notification-value of the Notification Object and manage the code
	space.		space.
	Notification-type Name Reference		Notification-type Name Reference
	1 Pending Request cancelled This document		1 Pending Request cancelled This document
	Notification-value		Notification-value
	1: PCC cancels a set of pending requests		1: PCC cancels a set of pending requests
	2: PCE cancels a set of pending requests		2: PCE cancels a set of pending requests
	2 PCE Congestion This document		2 PCE Congestion This document
	Notification-value		Notification-value
	1: PCE in congested state		1: PCE in congested state
	2: PCE no longer in congested state		2: PCE no longer in congested state
	9.6. PCEP-ERROR Object		IANA is requested to create a registry to manage the Flag field of
			the Notification object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			No Bits are currently for the Flag Field of the Notification Object.
			9.12. PCEP-ERROR Object
	IANA is requested to create a registry for the Error-type and Error-		IANA is requested to create a registry for the Error-type and Error-
	value of the PCEP Error Object and manage the code space.		value of the PCEP Error Object and manage the code space.
	For each PCEP error, an Error-type and an Error-value are defined.		For each PCEP error, an Error-type and an Error-value are defined.
	Error-Type Meaning Reference		Error-Type Meaning Reference
	1 PCEP session establishment failure This document		1 PCEP session establishment failure This document
	Error-value=1: reception of an invalid Open message or		Error-value=1: reception of an invalid Open message or
	a non Open message.		a non Open message.
	Error-value=2: no Open message received before the expiration		Error-value=2: no Open message received before the expiration
	skipping to change at page 63, line 45 ¶		skipping to change at page 67, line 45 ¶
	Error-value=2: RRO missing for a reoptimization		Error-value=2: RRO missing for a reoptimization
	request (R bit of the RP object set)		request (R bit of the RP object set)
	Error-value=3: END-POINTS object missing		Error-value=3: END-POINTS object missing
	7 Synchronized path computation request missing This document		7 Synchronized path computation request missing This document
	8 Unknown request reference This document		8 Unknown request reference This document
	9 Attempt to establish a second PCEP session This document		9 Attempt to establish a second PCEP session This document
	10 Reception of an invalid object This document		10 Reception of an invalid object This document
	Error-value=1: reception of an object with P flag not set although		Error-value=1: reception of an object with P flag not set although
	the P-flag must be set according to this specification.		the P-flag must be set according to this specification.
	9.7. CLOSE Object		IANA is requested to create a registry to manage the Flag field of
			the PCEP-ERROR object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			No Bits are currently for the Flag Field of the PCEP-ERROR Object.
			9.13. LOAD-BALANCING Object Flag Field
			IANA is requested to create a registry to manage the Flag field of
			the LOAD-BALANCING object.
			New bit numbers may be allocated only by an IETF Consensus action.
			Each bit should be tracked with the following qualities:
			o Bit number (counting from bit 0 as the most significant bit)
			o Capability Description
			o Defining RFC
			No Bits are currently for the Flag Field of the LOAD-BALANCING
			Object.
			9.14. CLOSE Object
	The CLOSE object MUST be present in each Close message in order to		The CLOSE object MUST be present in each Close message in order to
	close a PCEP session. The reason field of the CLOSE object specifies		close a PCEP session. The reason field of the CLOSE object specifies
	the reason for closing the PCEP session. The reason field of the		the reason for closing the PCEP session. The reason field of the
	CLOSE object is managed by IANA.		CLOSE object is managed by IANA.
	Reasons		Reasons
	Value Meaning		Value Meaning
	1 No explanation provided		1 No explanation provided
	2 DeadTimer expired		2 DeadTimer expired
	3 Reception of a malformed PCEP message		3 Reception of a malformed PCEP message
	4 Reception of an unacceptable number of		4 Reception of an unacceptable number of
	unknown requests/replies		unknown requests/replies
	5 Reception of an unacceptable number of		5 Reception of an unacceptable number of
	unrecognized PCEP messages		unrecognized PCEP messages
	9.8. NO-PATH Object		IANA is requested to create a registry to manage the flag field of
			the CLOSE object.
	IANA is requested to create a registry to manage the codespace of NI
	field present in the NO-PATH Object.
	Value Meaning Reference
	0 No path satisfying the set This document
	of constraints could be found
	1 PCE chain broken This document
	9.9. METRIC Object
	IANA is requested to create a registry to manage the codespace of T
	field and the Flag field of the METRIC Object.
	Codespace of the T field (Metric Object)
	Value Meaning Reference
	1 IGP metric This document
	2 TE metric This document
	3 Hop Counts This document
	New bit numbers may be allocated only by an IETF Consensus action.		New bit numbers may be allocated only by an IETF Consensus action.
	Each bit should be tracked with the following qualities:		Each bit should be tracked with the following qualities:
	o Bit number		o Bit number (counting from bit 0 as the most significant bit)
	o Capability Description		o Capability Description
	o Defining RFC		o Defining RFC
	Several bits are defined in this document. The following values have		No Bits are currently for the Flag Field of the CLOSE Object.
	been assigned:
	Codespace of the Flag field (Metric Object)
	Bit Description Reference
	0 Bound This document
	1 Computed metric This document
	9.10. PCEP TLV Type Indicators		9.15. PCEP TLV Type Indicators
	IANA is requested to create a registry for the PCEP TLVs.		IANA is requested to create a registry for the PCEP TLVs.
	Value Meaning Reference		Value Meaning Reference
	1 NO-PATH-VECTOR TLV This document		1 NO-PATH-VECTOR TLV This document
	2 OVERLOAD-DURATION TLV This document		2 OVERLOAD-DURATION TLV This document
	3 REQ-MISSING TLV This document		3 REQ-MISSING TLV This document
	9.11. NO-PATH-VECTOR TLV		9.16. NO-PATH-VECTOR TLV
	IANA is requested to manage the space of flags carried in the NO-		IANA is requested to manage the space of flags carried in the NO-
	PATH-VECTOR TLV defined in this document, numbering them from 0 as		PATH-VECTOR TLV defined in this document, numbering them from 0 as
	the least significant bit.		the least significant bit.
	New bit numbers may be allocated only by an IETF Consensus action.		New bit numbers may be allocated only by an IETF Consensus action.
	Each bit should be tracked with the following qualities: - Bit number		Each bit should be tracked with the following qualities: - Bit number
	- Name flag - Reference		(counting from bit 0 as the most significant bit) - Name flag -
			Reference
	Bit Number Name Reference		Bit Number Name Reference
	31 PCE currently Unavailable This document		31 PCE currently Unavailable This document
	30 Unknown Destination This document		30 Unknown Destination This document
	29 Unknown Source This document		29 Unknown Source This document
	10. Security Considerations		10. Security Considerations
	10.1. Vulnerability		10.1. Vulnerability
	skipping to change at page 66, line 46 ¶		skipping to change at page 70, line 48 ¶
	At the time of writing, TCP-MD5 [RFC2385] is the only available		At the time of writing, TCP-MD5 [RFC2385] is the only available
	security mechanism for securing the TCP connections that underly PCEP		security mechanism for securing the TCP connections that underly PCEP
	sessions.		sessions.
	As explained in [RFC2385], the use of MD5 faces some limitations and		As explained in [RFC2385], the use of MD5 faces some limitations and
	does not provide as high a level of security as was once believed. A		does not provide as high a level of security as was once believed. A
	PCEP implementation supporting TCP-MD5 SHOULD be designed so that		PCEP implementation supporting TCP-MD5 SHOULD be designed so that
	stronger security keying techniques or algorithms that may be		stronger security keying techniques or algorithms that may be
	specified for TCP can be easily integrated in future releases.		specified for TCP can be easily integrated in future releases.
	The TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] specifies		The TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] (TCP-AO)
	new security procedures for TCP, but is not yet complete. Since it		specifies new security procedures for TCP, but is not yet complete.
	is believed that [I-D.ietf-tcpm-tcp-auth-opt] will offer		Since it is believed that [I-D.ietf-tcpm-tcp-auth-opt] will offer
	significantly improved security for applications using TCP.		significantly improved security for applications using TCP.
			Implementers should expect to update their implementation as soon as
			the TCP Authentication Option is published as an RFC.
	Implementations MUST support either TCP-MD5 or TCP Authentication		Implementations MUST support TCP-MD5 and should make the security
	Option and should make the security function available as a		function available as a configuration option.
	configuration option.
	Operators will need to observe that some deployed PCEP		Operators will need to observe that some deployed PCEP
	implementations may pre-date the completion of		implementations may pre-date the completion of
	[I-D.ietf-tcpm-tcp-auth-opt] and it will be necessary to configure		[I-D.ietf-tcpm-tcp-auth-opt] and it will be necessary to configure
	policy for secure communication between PCEP speakers that support		policy for secure communication between PCEP speakers that support
	the TCP Authentication Option, and those that don't.		the TCP Authentication Option, and those that don't.
	An alternative approach for security over TCP transport is to use the		An alternative approach for security over TCP transport is to use the
	Transport Layer Security (TLS) protocol [RFC5246]. This provides		Transport Layer Security (TLS) protocol [RFC5246]. This provides
	protection against eavesdropping, tampering, and message forgery.		protection against eavesdropping, tampering, and message forgery.
	skipping to change at page 73, line 44 ¶		skipping to change at page 77, line 47 ¶
	[I-D.farrel-rtg-common-bnf]		[I-D.farrel-rtg-common-bnf]
	Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used		Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
	in Various Protocol Specifications",		in Various Protocol Specifications",
	draft-farrel-rtg-common-bnf-07 (work in progress),		draft-farrel-rtg-common-bnf-07 (work in progress),
	November 2008.		November 2008.
	[I-D.ietf-mpls-mpls-and-gmpls-security-framework]		[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
	Fang, L. and M. Behringer, "Security Framework for MPLS		Fang, L. and M. Behringer, "Security Framework for MPLS
	and GMPLS Networks",		and GMPLS Networks",
	draft-ietf-mpls-mpls-and-gmpls-security-framework-03 (work		draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work
	in progress), July 2008.		in progress), November 2008.
	[I-D.ietf-pce-inter-layer-req]		[I-D.ietf-pce-inter-layer-req]
	Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda,		Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda,
	"PCC-PCE Communication and PCE Discovery Requirements for		"PCC-PCE Communication and PCE Discovery Requirements for
	Inter-Layer Traffic Engineering",		Inter-Layer Traffic Engineering",
	draft-ietf-pce-inter-layer-req-08 (work in progress),		draft-ietf-pce-inter-layer-req-08 (work in progress),
	October 2008.		October 2008.
	[I-D.ietf-pce-interas-pcecp-reqs]		[I-D.ietf-pce-interas-pcecp-reqs]
	Bitar, N., Kumaki, K., and R. Zhang, "Inter-AS		Bitar, N., Kumaki, K., and R. Zhang, "Inter-AS
	skipping to change at page 74, line 22 ¶		skipping to change at page 78, line 24 ¶
	[I-D.ietf-pce-manageability-requirements]		[I-D.ietf-pce-manageability-requirements]
	Farrel, A., "Inclusion of Manageability Sections in PCE		Farrel, A., "Inclusion of Manageability Sections in PCE
	Working Group Drafts",		Working Group Drafts",
	draft-ietf-pce-manageability-requirements-05 (work in		draft-ietf-pce-manageability-requirements-05 (work in
	progress), October 2008.		progress), October 2008.
	[I-D.ietf-pce-monitoring]		[I-D.ietf-pce-monitoring]
	Vasseur, J., Roux, J., and Y. Ikejiri, "A set of		Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
	monitoring tools for Path Computation Element based		monitoring tools for Path Computation Element based
	Architecture", draft-ietf-pce-monitoring-02 (work in		Architecture", draft-ietf-pce-monitoring-03 (work in
	progress), September 2008.		progress), November 2008.
	[I-D.ietf-rpsec-bgpsecrec]		[I-D.ietf-rpsec-bgpsecrec]
	Christian, B. and T. Tauber, "BGP Security Requirements",		Christian, B. and T. Tauber, "BGP Security Requirements",
	draft-ietf-rpsec-bgpsecrec-09 (work in progress),		draft-ietf-rpsec-bgpsecrec-10 (work in progress),
	November 2007.		November 2008.
	[I-D.ietf-tcpm-tcp-auth-opt]		[I-D.ietf-tcpm-tcp-auth-opt]
	Touch, J., Mankin, A., and R. Bonica, "The TCP		Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01		Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02
	(work in progress), July 2008.		(work in progress), November 2008.
	[I-D.kkoushik-pce-pcep-mib]		[I-D.kkoushik-pce-pcep-mib]
	Stephan, E. and K. Koushik, "PCE communication		Stephan, E. and K. Koushik, "PCE communication
	protocol(PCEP) Management Information Base",		protocol(PCEP) Management Information Base",
	draft-kkoushik-pce-pcep-mib-01 (work in progress),		draft-kkoushik-pce-pcep-mib-02 (work in progress),
	July 2007.		November 2008.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, August 1998.		Signature Option", RFC 2385, August 1998.
	[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Functional Description", RFC 3471,		(GMPLS) Signaling Functional Description", RFC 3471,
	January 2003.		January 2003.
End of changes. 26 change blocks.
	95 lines changed or deleted		254 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/