< draft-ietf-pce-discovery-reqs-04.txt		draft-ietf-pce-discovery-reqs-05.txt >
	Network Working Group J.L. Le Roux (Editor)		Network Working Group J.L. Le Roux (Editor)
	Internet Draft France Telecom		Internet Draft France Telecom
	Category: Informational		Category: Informational
	Expires: November 2006		Expires: December 2006
	May 2006		June 2006
	Requirements for Path Computation Element (PCE) Discovery		Requirements for Path Computation Element (PCE) Discovery
	draft-ietf-pce-discovery-reqs-04.txt		draft-ietf-pce-discovery-reqs-05.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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	6.2. Scope of PCE Discovery.....................................10		6.2. Scope of PCE Discovery.....................................10
	6.2.1. Inter-AS specific requirements.............................10		6.2.1. Inter-AS specific requirements.............................10
	6.3. PCE Information Synchronization............................11		6.3. PCE Information Synchronization............................11
	6.4. Discovery of PCE deactivation..............................11		6.4. Discovery of PCE deactivation..............................11
	6.5. Policy Support.............................................11		6.5. Policy Support.............................................11
	6.6. Security Requirements......................................12		6.6. Security Requirements......................................12
	6.7. Extensibility..............................................12		6.7. Extensibility..............................................12
	6.8. Scalability................................................12		6.8. Scalability................................................12
	6.9. Operational orders of magnitudes...........................13		6.9. Operational orders of magnitudes...........................13
	6.10. Manageability considerations...............................13		6.10. Manageability considerations...............................13
	7. Security Considerations....................................13		6.10.1. Configuration of PCE Discovery parameters.................13
	8. Acknowledgments............................................13		6.10.2. PCE Discovery MIB modules.................................14
	9. References.................................................14		6.10.2.1. PCC MIB module..........................................14
	9.1. Normative references.......................................14		6.10.2.2. PCE MIB module..........................................14
	9.2. Informative references.....................................14		6.10.3. Monitoring Protocol Operations............................15
	10. Authors' Addresses:........................................14		6.10.4. Impact on network operations..............................15
	11. Intellectual Property Statement............................15		7. Security Considerations....................................15
			8. Acknowledgments............................................16
			9. References.................................................16
			9.1. Normative references.......................................16
			9.2. Informative references.....................................16
			10. Editor Address.............................................16
			11. Contributors' Addresses....................................16
			12. Intellectual Property Statement............................17
	1. Contributors		1. Contributors
	The following are the authors that contributed to the present		The following are the authors that contributed to the present
	document:		document:
	Jean-Louis Le Roux (France Telecom)		Jean-Louis Le Roux (France Telecom)
	Paul Mabey (Qwest Communications)		Paul Mabey (Qwest Communications)
	Eiji Oki (NTT)		Eiji Oki (NTT)
	Richard Rabbat (Fujitsu)		Richard Rabbat (Fujitsu)
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	N can be beyond fifty).		N can be beyond fifty).
	Hence, an automated PCE discovery mechanism allowing a PCC to		Hence, an automated PCE discovery mechanism allowing a PCC to
	dynamically discover a set of PCEs is highly desirable.		dynamically discover a set of PCEs is highly desirable.
	4.2. Requirements overview		4.2. Requirements overview
	A PCE discovery mechanism that satisfies the requirements set forth		A PCE discovery mechanism that satisfies the requirements set forth
	in this document MUST allow a PCC to automatically discover the		in this document MUST allow a PCC to automatically discover the
	location of one or more of the PCEs in its domain.		location of one or more of the PCEs in its domain.
	Where inter-domain path computation is required, the PCE discovery		Where inter-domain path computation is required and policy permits,
	method MUST allow a PCC to automatically discover the location of		the PCE discovery method MUST allow a PCC to automatically discover
	PCEs in other domains that can assist with inter-domain path		the location of PCEs in other domains that can assist with inter-
	computation.		domain path computation.
	A PCE discovery mechanism MUST allow a PCC to discover the set of one		A PCE discovery mechanism MUST allow a PCC to discover the set of one
	or more domains where a PCE has TE topology visibility and can		or more domains where a PCE has TE topology visibility and can
	compute paths. It MUST also allow the discovery of the potential		compute paths. It MUST also allow the discovery of the potential
	inter-domain path computation functions of a PCE (inter-area, inter-		inter-domain path computation functions of a PCE (inter-area, inter-
	AS, inter-layer, etc.).		AS, inter-layer, etc.).
	A PCE discovery mechanism MUST allow the control of the discovery		A PCE discovery mechanism MUST allow the control of the discovery
	scope, that is the set of one or more domains (areas, ASs) where		scope, that is the set of one or more domains (areas, ASs) where
	information related to a given PCE has to be disclosed.		information related to a given PCE has to be disclosed.
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 17 ¶
	information is optional in the PCE-based architecture, but such		information is optional in the PCE-based architecture, but such
	information could also be obtained by other mechanisms, such as the		information could also be obtained by other mechanisms, such as the
	PCC-PCE communication protocol.		PCC-PCE communication protocol.
	6.1.1. General PCE Information (Mandatory support)		6.1.1. General PCE Information (Mandatory support)
	6.1.1.1. Discovery of PCE Location		6.1.1.1. Discovery of PCE Location
	The PCE discovery mechanism MUST allow the discovery, for a given		The PCE discovery mechanism MUST allow the discovery, for a given
	PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE.		PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE.
	This address will typically be a loop-back address that is always		This address will typically be an address that is always reachable,
	reachable, if there is any connectivity to the PCE.		if there is any connectivity to the PCE.
	This address will be used by PCCs to communicate with a PCE, through		This address will be used by PCCs to communicate with a PCE, through
	a PCC-PCE communication protocol.		a PCC-PCE communication protocol.
	6.1.1.2. Discovery of PCE Domains and Inter-domain Functions		6.1.1.2. Discovery of PCE Domains and Inter-domain Functions
	Inter-domain path computation is a key application of the PCE		Inter-domain path computation is a key application of the PCE
	architecture. This can rely on a multiple-PCE path computation, where		architecture. This can rely on a multiple-PCE path computation, where
	PCEs in each domain compute a part of the end-to-end path and		PCEs in each domain compute a part of the end-to-end path and
	collaborate with each other to find the end-to-end-path. Inter-domain		collaborate with each other to find the end-to-end-path. Inter-domain
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	to take part into the computation of inter-domain paths, by		to take part into the computation of inter-domain paths, by
	collaborating with PCEs in other domains. Conversely, a PCE may have		collaborating with PCEs in other domains. Conversely, a PCE may have
	visibility in multiple domains but the operator may not want that the		visibility in multiple domains but the operator may not want that the
	PCE be used for inter-domain path computations.		PCE be used for inter-domain path computations.
	The PCE discovery mechanisms MUST also allow discovery of the set of		The PCE discovery mechanisms MUST also allow discovery of the set of
	one or more domains toward which a PCE can compute paths. For		one or more domains toward which a PCE can compute paths. For
	instance in an inter-AS path computation context, there may be		instance in an inter-AS path computation context, there may be
	several PCEs in an AS, each one responsible for taking part in the		several PCEs in an AS, each one responsible for taking part in the
	computation of inter-AS paths toward a set of one or more destination		computation of inter-AS paths toward a set of one or more destination
	ASs, and a PCC must discover the destination ASs each PCE is		ASs, and a PCC may have to discover the destination ASs each PCE is
	responsible for.		responsible for.
	6.1.2. Detailed PCE Information (Optional support)		6.1.2. Detailed PCE Information (Optional support)
	6.1.2.1. Discovery of PCE Capabilities		6.1.2.1. Discovery of PCE Capabilities
	In the case where there are several PCEs with distinct capabilities		In the case where there are several PCEs with distinct capabilities
	available, a PCC has to select one or more appropriate PCEs.		available, a PCC has to select one or more appropriate PCEs.
	For that purpose the PCE discovery mechanism MAY support the		For that purpose the PCE discovery mechanism MAY support the
	skipping to change at page 11, line 49 ¶		skipping to change at page 11, line 48 ¶
	such discovery in an order of magnitude of 60 seconds, and the		such discovery in an order of magnitude of 60 seconds, and the
	operator should have the ability to configure the Discovery delay.		operator should have the ability to configure the Discovery delay.
	6.5. Policy Support		6.5. Policy Support
	The PCE Discovery mechanism MUST allow for policies to restrict the		The PCE Discovery mechanism MUST allow for policies to restrict the
	discovery scope to a set of authorized domains, to control and		discovery scope to a set of authorized domains, to control and
	restrict the type and nature of the information to be disclosed, and		restrict the type and nature of the information to be disclosed, and
	also to filter and translate some information at domains borders. It		also to filter and translate some information at domains borders. It
	MUST be possible to apply these policies on a per PCE basis.		MUST be possible to apply these policies on a per PCE basis.
	The way these policies could be managed is out of the scope of this
	document.
	Note that the Discovery mechanisms MUST allow disclosing policy		Note that the Discovery mechanisms MUST allow disclosing policy
	information so as to control the disclosure policies at domain		information so as to control the disclosure policies at domain
	boundaries.		boundaries.
	Also, it MUST be possible to apply different policies when disclosing		Also, it MUST be possible to apply different policies when disclosing
	PCE information to different domains.		PCE information to different domains.
	6.6. Security Requirements		6.6. Security Requirements
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 19 ¶
	- Interception of PCE discovery information (sniffing);		- Interception of PCE discovery information (sniffing);
	- Falsification of PCE discovery information;		- Falsification of PCE discovery information;
	- Information disclosure to non-authorized PCCs (PCC spoofing).		- Information disclosure to non-authorized PCCs (PCC spoofing).
	- DoS Attacks		- DoS Attacks
	Note that security of the PCE Discovery procedures is of particular		Note that security of the PCE Discovery procedures is of particular
	importance in an inter-AS context, where PCE discovery may increase		importance in an inter-AS context, where PCE discovery may increase
	the vulnerability to attacks and the consequences of these attacks.		the vulnerability to attacks and the consequences of these attacks.
	Hence mechanisms MUST be defined to ensure authenticity, integrity,		Hence mechanisms MUST be defined to ensure authenticity, integrity,
	privacy, and containment of PCE discovery information:		confidentiality, and containment of PCE discovery information:
	- There MUST be a mechanism to authenticate discovery information;		- There MUST be a mechanism to authenticate discovery information;
	- There MUST be a mechanism to verify discovery information		- There MUST be a mechanism to verify discovery information
	integrity;		integrity;
	- There MUST be a mechanism to encrypt discovery information;		- There MUST be a mechanism to encrypt discovery information;
	- There MUST be a mechanism to restrict the scope of discovery to a		- There MUST be a mechanism to restrict the scope of discovery to a
	set of authorized PCCs and to filter PCE information disclosed		set of authorized PCCs and to filter PCE information disclosed
	at domain boundaries (as per defined in 6.5).		at domain boundaries (as per defined in 6.5).
			A PCE and PCC MUST be identified by a globally unique ID, which may
			be for instance a combination of AS number an IP address.
	Mechanisms MUST be defined in order to limit the impact of a		Mechanisms MUST be defined in order to limit the impact of a
	DoS attack on the PCE discovery procedure (e.g. filter out excessive		DoS attack on the PCE discovery procedure (e.g. filter out excessive
	PCE information change and flapping PCEs). Note also that DOS		PCE information change and flapping PCEs). Note also that DOS
	attacks may be either accidental (caused by a mis-behaving		attacks may be either accidental (caused by a mis-behaving
	PCE system) or intentional. As discussed in [PCE-COM-REQ] such		PCE system) or intentional. As discussed in [PCE-COM-REQ] such
	mechanisms may include packet filtering, rate limiting, no		mechanisms may include packet filtering, rate limiting, no
	promiscuous listening, and where applicable use of private addresses		promiscuous listening, and where applicable use of private addresses
	spaces.		spaces.
	Also, key consideration MUST be given in terms of how to establish a		Also, key consideration MUST be given in terms of how to establish a
	skipping to change at page 13, line 28 ¶		skipping to change at page 13, line 28 ¶
	6.9. Operational orders of magnitudes		6.9. Operational orders of magnitudes
	This section gives minimum order of magnitude estimates of what the		This section gives minimum order of magnitude estimates of what the
	PCE discovery mechanism should support.		PCE discovery mechanism should support.
	- Number of PCCs discovering a given PCE: 1000		- Number of PCCs discovering a given PCE: 1000
	- Number of PCEs to be discovered by a given PCC: 100		- Number of PCEs to be discovered by a given PCC: 100
	6.10. Manageability considerations		6.10. Manageability considerations
	Manageability of PCE discovery MUST addresses the following		Mechanisms are REQUIRED to manage PCE discovery operations. This
	considerations:		includes the configuration of PCE Discovery functions and policies,
			as well as, the monitoring of the discovery protocol activity.
	- need for a MIB module for PCE discovery;		6.10.1. Configuration of PCE Discovery parameters
	- configuration implications for the protocol.
			It MUST be possible to enable and disable the PCE discovery function
			at a PCC and at a PCE.
			On the PCC it MUST be possible for an operator to activate/deactivate
			automatic PCE discovery. The activation of automatic discovery MUST
			not prevent static configuration of PCE information that may
			supplement discovered information.
			On the PCE it MUST be possible for an operator to control the
			application of discovery policies by which the specific PCE is
			discovered. As described in Section 6.5, this control MUST include
			the ability to:
			- restrict the discovery scope to a set of authorized domains;
			- define the type and nature of the information disclosed;
			- specify the filtering and translation to be applied to the PCE
			information disclosed at domain borders.
			These configuration options MAY be supported through an
			implementation-specific local configuration interface, or MAY be
			supported via a standardised interface (such as a MIB module, as
			below).
			6.10.2. PCE Discovery MIB modules
			PCE Discovery MIB modules MUST be specified for the control of the
			function on PCCs and PCEs.
			6.10.2.1. PCC MIB module
			The MIB module that will run on PCCs MUST include at least:
			- A control to disable automatic discovery by the PCC;
			- The set of known PCEs;
			- The number of known PCEs, and the number of discovered PCEs.
			For each PCE reported in the MIB module, the following information
			MUST be available:
			- Information advertised by the PCE (i.e., discovered information);
			- Information locally configured about the PCE;
			- The time since the PCE was discovered;
			- The time since any change to the discovered information for the PCE;
			Note that when a PCE is no longer alive (see section 6.4), it SHOULD
			no longer be reported in the PCC MIB module.
			The MIB module SHOULD also provide the average and maximum rates of
			arrival, departure and modification of PCE discovery to enable
			effective analysis of the operation of the protocols. Further, the
			MIB module SHOULD report on the operation of the discovery protocol
			by counting the number of unacceptable and incomprehensible
			information exchanges.
			The PCC MIB module SHOULD also be used to provide notifications
			when thresholds (e.g. on the maximum rate of change, on the number of
			unacceptable messages) are crossed, or when important events occur
			(e.g. the number of discovered PCEs decreases to zero).
			6.10.2.2. PCE MIB module
			The MIB module that will run on PCEs MUST include at least:
			- A control to disable automatic discovery announcements by the PCE;
			- Information to be advertised by the PCE, although this information
			MAY be present as read-only;
			- The discovery policies active on the PCE, although this information
			MAY be present as read-only.
			The MIB module SHOULD also include:
			- The time since the last change to the advertised PCE information;
			- The time since the last change to the advertisement policies;
			- Control of on which interfaces the PCE issues advertisements where
			this is applicable to the protocol solution selected.
			Note that a PCE MAY also be configured to discover other PCEs. In
			this case it SHOULD operate the MIB module described in section
			6.10.2.1 as well as the module described here.
			6.10.3. Monitoring Protocol Operations
			It MUST be possible to monitor the operation of any PCE discovery
			protocol. Where an existing protocol is used to support the PCE
			discovery function, this monitoring SHOULD be achieved using the
			techniques already defined for that protocol, enhanced by the MIB
			modules described above. Where, those techniques are inadequate, new
			techniques MUST be developed.
			Monitoring of the protocol operation demands support for at least the
			following functions:
			- Correlation of information advertised against information received;
			- Counts of dropped, corrupt, and rejected information elements;
			- Detection of 'segmented' networks. That is, the ability to detect
			and diagnose the failure of a PCE advertisement to reach a PCC.
			6.10.4. Impact on network operations
			Frequent changes in PCE information may have a significant impact on
			PCCs that receive the advertisements, might destabilise the operation
			of the network by causing the PCCs to swap between PCEs, and might
			harm the network through excessive advertisement traffic. Hence it
			MUST be possible to apply at least the following controls:
			- Configurable limit on the rate of announcement of changed
			parameters at a PCE;
			- Control of the impact on PCCs such as through discovery messages
			rate-limiting;
			- Configurable control of triggers that cause a PCC to swap to
			another PCE.
	7. Security Considerations		7. Security Considerations
	This document is a requirement document and hence does not raise by		This document is a requirement document and hence does not raise by
	itself any particular security issue.		itself any particular security issue.
	A set of security requirements that MUST be addressed when		A set of security requirements that MUST be addressed when
	considering the design and deployment of a PCE Discovery mechanism		considering the design and deployment of a PCE Discovery mechanism
	have been identified in section 6.6.		have been identified in section 6.6.
	8. Acknowledgments		8. Acknowledgments
	We would like to thank Benoit Fondeviole, Thomas Morin, Emile		We would like to thank, in chronological order, Benoit Fondeviole,
	Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai		Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng,
	Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri		Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor
	Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil		Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou
	Bitar, Kenji Kumaki and Ross Callon for their useful comments and		Berger, Nabil Bitar, and Kenji Kumaki.
	suggestions.
			Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley
			and Sam Hartman for their review and constructive discussions during
			the final stages of publication.
	9. References		9. References
	9.1. Normative references		9.1. Normative references
	[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.
	[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation		[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
	Element (PCE) Architecture", draft-ietf-pce-architecture, work in		Element (PCE) Architecture", draft-ietf-pce-architecture, work in
	progress.		progress.
	9.2. Informative references		9.2. Informative references
	[PCE-COM-REQ] Ash, J., Le Roux, J.L., "PCE Communication Protocol		[PCE-COM-REQ] Ash, J., Le Roux, J.L., "PCE Communication Protocol
	Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in		Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in
	progress.		progress.
	10. Authors' Addresses:		10. Editor Address
	Jean-Louis Le Roux (Editor)		Jean-Louis Le Roux (Editor)
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: jeanlouis.leroux@francetelecom.com		Email: jeanlouis.leroux@francetelecom.com
			11. Contributors' Addresses
	Paul Mabey		Paul Mabey
	Qwest Communications		Qwest Communications
	950 17th Street,		950 17th Street,
	Denver, CO 80202,		Denver, CO 80202,
	USA		USA
	Email: pmabey@qwest.com		Email: pmabey@qwest.com
	Eiji Oki		Eiji Oki
	NTT		NTT
	Midori-cho 3-9-11		Midori-cho 3-9-11
	skipping to change at page 15, line 14 ¶		skipping to change at page 17, line 28 ¶
	CANADA,		CANADA,
	Email: ting_wo.chung@bell.ca		Email: ting_wo.chung@bell.ca
	Raymond Zhang		Raymond Zhang
	BT Infonet		BT Infonet
	2160 E. Grand Ave.		2160 E. Grand Ave.
	El Segundo, CA 90025		El Segundo, CA 90025
	USA		USA
	Email: raymond_zhang@infonet.com		Email: raymond_zhang@infonet.com
	11. Intellectual Property Statement		12. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 16 change blocks.
	32 lines changed or deleted		151 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/