draft-ietf-mpls-te-scaling-analysis-03.txt		draft-ietf-mpls-te-scaling-analysis-04.txt
	Network Working Group S. Yasukawa		Network Working Group S. Yasukawa
	Internet-Draft NTT		Internet-Draft NTT
	Intended Status: Informational A. Farrel		Intended Status: Informational A. Farrel
	Created: June 19, 2008 Old Dog Consulting		Created: December 2, 2008 Old Dog Consulting
	Expires: December 19, 2008 O. Komolafe		Expires: June 2, 2009 O. Komolafe
	Cisco Systems		Cisco Systems
	An Analysis of Scaling Issues in MPLS-TE Core Networks		An Analysis of Scaling Issues in MPLS-TE Core Networks
	draft-ietf-mpls-te-scaling-analysis-03.txt		draft-ietf-mpls-te-scaling-analysis-04.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
	applicable patent or other IPR claims of which he or she is aware		the 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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			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		The list of Internet-Draft Shadow Directories can be accessed at
	accessed at http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	Traffic engineered Multiprotocol Label Switching (MPLS-TE) is		Traffic engineered Multiprotocol Label Switching (MPLS-TE) is
	deployed in providers' core networks. As providers plan to grow these		deployed in providers' core networks. As providers plan to grow these
	networks, they need to understand whether existing protocols and		networks, they need to understand whether existing protocols and
	implementations can support the network sizes that they are planning.		implementations can support the network sizes that they are planning.
	This document presents an analysis of some of the scaling concerns		This document presents an analysis of some of the scaling concerns
	for MPLS-TE core networks, and examines the value of two techniques		for the number of Label Switching Paths (LSPs) in MPLS-TE core
	(LSP hierarchies, and multipoint-to-point LSPs) for improving		networks, and examines the value of two techniques (LSP hierarchies,
	scaling. The intention is to motivate the development of appropriate		and multipoint-to-point LSPs) for improving scaling. The intention is
	deployment techniques and protocol extensions to enable the		to motivate the development of appropriate deployment techniques and
	application of MPLS-TE in large networks.		protocol extensions to enable the application of MPLS-TE in large
			networks.
	This document considers only scalability for point-to-point MPLS-TE.		This document only considers the question of achieving scalability
	Point-to-multipoint MPLS-TE is for future study.		for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint
			MPLS-TE LSPs are for future study.
	Contents		Contents
	1. Introduction .................................................. 3		1. Introduction .................................................. 3
	1.1 Overview ..................................................... 3		1.1 Overview ..................................................... 3
	1.2 Glossary of Notation ......................................... 4		1.2 Glossary of Notation ......................................... 4
	2. Issues of Concern for Scaling ................................. 5		2. Issues of Concern for Scaling ................................. 5
	2.1 LSP State ................................................... 5		2.1 LSP State ................................................... 5
	2.2 Processing Overhead .......................................... 5		2.2 Processing Overhead .......................................... 5
	2.3 RSVP-TE Implications ......................................... 6		2.3 RSVP-TE Implications ......................................... 6
	2.4 Management ................................................... 7		2.4 Management ................................................... 7
	skipping to change at page 2, line 53		skipping to change at page 2, line 53
	9. Combined Models ............................................... 34		9. Combined Models ............................................... 34
	10. An Alternate Solution ........................................ 35		10. An Alternate Solution ........................................ 35
	10.1 Pros and Cons of the Alternate Solution ..................... 36		10.1 Pros and Cons of the Alternate Solution ..................... 36
	11. Management Considerations .................................... 37		11. Management Considerations .................................... 37
	12. Security Considerations ...................................... 37		12. Security Considerations ...................................... 37
	13. Recommendations .............................................. 38		13. Recommendations .............................................. 38
	14. IANA Considerations .......................................... 38		14. IANA Considerations .......................................... 38
	15. Acknowledgements ............................................. 38		15. Acknowledgements ............................................. 38
	16. Intellectual Property Consideration .......................... 39		16. Intellectual Property Consideration .......................... 39
	17. Normative References ......................................... 39		17. Normative References ......................................... 39
	18. Informative References ....................................... 39		18. Informative References ....................................... 40
	19. Authors' Addresses ........................................... 40		19. Authors' Addresses ........................................... 41
	1. Introduction		1. Introduction
	Network operators and service providers are examining scaling issues		Network operators and service providers are examining scaling issues
	as they look to deploy ever-larger traffic engineered Multiprotocol		as they look to deploy ever-larger traffic engineered Multiprotocol
	Label Switching (MPLS-TE) networks. Concerns have been raised about		Label Switching (MPLS-TE) networks. Concerns have been raised about
	the number of Label Switched Paths (LSPs) that need to be supported		the number of Label Switched Paths (LSPs) that need to be supported
	at the edge and at the core of the network. The impact on control		at the edge and at the core of the network. The impact on control
	plane and management plane resources threatens to outweigh the		plane and management plane resources threatens to outweigh the
	benefits and popularity of MPLS-TE, while the physical limitations of		benefits and popularity of MPLS-TE, while the physical limitations of
	skipping to change at page 4, line 26		skipping to change at page 4, line 26
	of 'duplicate' LSPs. This issue is not addressed in this document.		of 'duplicate' LSPs. This issue is not addressed in this document.
	It should also be understood that certain deployment models where		It should also be understood that certain deployment models where
	separate traffic engineered LSPs are used to provide different		separate traffic engineered LSPs are used to provide different
	services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or		services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or
	different classes of service [RFC3270], may result in 'duplicate' or		different classes of service [RFC3270], may result in 'duplicate' or
	'parallel' LSPs running between any pair of provider edge nodes		'parallel' LSPs running between any pair of provider edge nodes
	(PEs). This scaling factor is also not considered in this document,		(PEs). This scaling factor is also not considered in this document,
	but may be easily applied as a linear factor by the reader.		but may be easily applied as a linear factor by the reader.
	The intention of this document is to help service providers discover		This document is designed to help service providers discover whether
	whether existing protocols and implementations can support the		existing protocols and implementations can support the network sizes
	network sizes that they are planning. To do this, it presents an		that they are planning. To do this, it presents an analysis of some
	analysis of some of the scaling concerns for MPLS-TE core networks,		of the scaling concerns for MPLS-TE core networks, and examines the
	and examines the value of two techniques for improving scaling. This		value of two techniques for improving scaling. This should motivate
	should motivate the development of appropriate deployment techniques		the development of appropriate deployment techniques and protocol
	and protocol extensions to enable the application of MPLS-TE in large		extensions to enable the application of MPLS-TE in large networks.
	networks.
	This document considers only scalability for point-to-point MPLS-TE.		This document only considers the question of achieving scalability
	Point-to-multipoint MPLS-TE is for future study.		for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint
			MPLS-TE LSPs are for future study.
	1.2 Glossary of Notation		1.2 Glossary of Notation
	This document applies consistent notation to define various		This document applies consistent notation to define various
	parameters of the networks that are analyzed. These terms are defined		parameters of the networks that are analyzed. These terms are defined
	as they are introduced though-out the document, but are grouped		as they are introduced though-out the document, but are grouped
	together here for quick reference. Refer to the full definitions in		together here for quick reference. Refer to the full definitions in
	the text for detailed explanations.		the text for detailed explanations.
	n A network level. n = 1 is the core of the network.		n A network level. n = 1 is the core of the network.
	skipping to change at page 5, line 14		skipping to change at page 5, line 14
	R The number of rungs in a ladder network.		R The number of rungs in a ladder network.
	E The number of edge nodes (PEs) subtended below (directly or		E The number of edge nodes (PEs) subtended below (directly or
	indirectly) a spar node in a ladder network.		indirectly) a spar node in a ladder network.
	K The cost-effectiveness of the network expressed in terms of		K The cost-effectiveness of the network expressed in terms of
	the ratio of the number of PEs to the number of network nodes.		the ratio of the number of PEs to the number of network nodes.
	2. Issues of Concern for Scaling		2. Issues of Concern for Scaling
	This section presents some of the issues associated with the support		This section presents some of the issues associated with the support
	of LSPs at an LSR or within the network. These issues may mean that		of LSPs at a Label Switching Router (LSR) or within the network.
	there is a limit to the number LSPs that can be supported.		These issues may mean that there is a limit to the number LSPs that
			can be supported.
	2.1 LSP State		2.1 LSP State
	LSP state is the data (information) that must be stored at an LSR in		LSP state is the data (information) that must be stored at an LSR in
	order to maintain an LSP. Here we refer to the information that is		order to maintain an LSP. Here we refer to the information that is
	necessary to maintain forwarding plane state and the additional		necessary to maintain forwarding plane state and the additional
	information required when LSPs are established through control		information required when LSPs are established through control
	plane protocols. While the size of the LSP state is implementation-		plane protocols. While the size of the LSP state is implementation-
	dependent, it is clear that any implementation will require some data		dependent, it is clear that any implementation will require some data
	in order to maintain LSP state.		in order to maintain LSP state.
	skipping to change at page 7, line 25		skipping to change at page 7, line 26
	Another practical concern for the scalability of large MPLS-TE		Another practical concern for the scalability of large MPLS-TE
	networks is the ability to manage the network. This may be		networks is the ability to manage the network. This may be
	constrained by the available tools, the practicality of managing		constrained by the available tools, the practicality of managing
	large numbers of LSPs, and the management protocols in use.		large numbers of LSPs, and the management protocols in use.
	Management tools are software implementations. Although such		Management tools are software implementations. Although such
	implementations should not constrain the control plane protocols, it		implementations should not constrain the control plane protocols, it
	is realistic to appreciate that network deployments will be limited		is realistic to appreciate that network deployments will be limited
	by the scalability of the available tools. In practice, most existing		by the scalability of the available tools. In practice, most existing
	tools have a limit to the number of LSPs that they can support. While		tools have a limit to the number of LSPs that they can support. While
	an NMS may be able to support a large number of LSPs, the number that		a Network Management System (NMS) may be able to support a large
	can be supported by an EMS (or the number supported by an NMS		number of LSPs, the number that can be supported by anElement
	per-LSR) is more likely to be limited.		Management System (EMS) (or the number supported by an NMS per-LSR)
			is more likely to be limited.
	Similarly, practical constraints may be imposed by the operation of		Similarly, practical constraints may be imposed by the operation of
	management protocols. For example, an LSR may be swamped by		management protocols. For example, an LSR may be swamped by
	management protocol requests to read information about the LSPs that		management protocol requests to read information about the LSPs that
	it supports, and this might impact its ability to sustain those LSPs		it supports, and this might impact its ability to sustain those LSPs
	in the control plane. OAM, alarms, and notifications can further add		in the control plane. OAM, alarms, and notifications can further add
	to the burden placed on an LSR and limit the number of LSPs it can		to the burden placed on an LSR and limit the number of LSPs it can
	support.		support.
	All of these consideration encourage a reduction in the number of		All of these consideration encourage a reduction in the number of
	skipping to change at page 12, line 49		skipping to change at page 12, line 49
	/| /| /| /| |\ |\ |\ |\		/| /| /| /| |\ |\ |\ |\
	PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE		PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE
	Figure 5 : An Example Ladder Network		Figure 5 : An Example Ladder Network
	3.3 Commercial Drivers for Selected Configurations		3.3 Commercial Drivers for Selected Configurations
	It is reasonable to ask why these two particular network topologies		It is reasonable to ask why these two particular network topologies
	have been chosen.		have been chosen.
	The consideration must be physical scalability. Each node (label		The most important consideration is physical scalability. Each node
	switching router - LSR) is only able to support a limited number of		(label switching router - LSR) is only able to support a limited
	physical interfaces. This necessarily reduces the ability to fully		number of physical interfaces. This necessarily reduces the ability
	mesh a network and leads to the tree-like structure of the network		to fully mesh a network and leads to the tree-like structure of the
	toward the PEs.		network toward the PEs.
	A realistic commercial consideration for an operator is the fact that		A realistic commercial consideration for an operator is the fact that
	the only revenue-generating nodes in the network are the PEs. Other		the only revenue-generating nodes in the network are the PEs. Other
	nodes are needed only to support connectivity and scalability.		nodes are needed only to support connectivity and scalability.
	Therefore, there is a desire to maximize S(PE) while minimizing the		Therefore, there is a desire to maximize S(PE) while minimizing the
	sum of S(n) for all values of (n). This could be achieved by		sum of S(n) for all values of (n). This could be achieved by
	minimizing the number of levels, and by maximizing the connectivity		minimizing the number of levels, and by maximizing the connectivity
	at each layer, M(n). Ultimately, however, this would produce a		at each layer, M(n). Ultimately, however, this would produce a
	network of just interconnected PEs, which is clearly in conflict with		network of just interconnected PEs, which is clearly in conflict with
	the physical scaling situation.		the physical scaling situation.
	skipping to change at page 39, line 7		skipping to change at page 39, line 7
	15. Acknowledgements		15. Acknowledgements
	The authors are grateful to Jean-Louis Le Roux for discussions and		The authors are grateful to Jean-Louis Le Roux for discussions and
	review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson,		review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson,
	and Anders Gavler for their comments. Thanks to Dave Allen for useful		and Anders Gavler for their comments. Thanks to Dave Allen for useful
	discussion of the maths.		discussion of the maths.
	16. Intellectual Property Consideration		16. Intellectual Property Consideration
	The IETF takes no position regarding the validity or scope of any		The IETF Trust takes no position regarding the validity or scope of
	Intellectual Property Rights or other rights that might be claimed to		any Intellectual Property Rights or other rights that might be
	pertain to the implementation or use of the technology described in		claimed to pertain to the implementation or use of the technology
	this document or the extent to which any license under such rights		described in any IETF Document or the extent to which any license
	might or might not be available; nor does it represent that it has		under such rights might or might not be available; nor does it
	made any independent effort to identify any such rights. Information		represent that it has made any independent effort to identify any
	on the procedures with respect to rights in RFC documents can be		such rights.
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of Intellectual Property disclosures made to the IETF
	assurances of licenses to be made available, or the result of an		Secretariat and any assurances of licenses to be made available, or
	attempt made to obtain a general license or permission for the use of		the result of an attempt made to obtain a general license or
	such proprietary rights by implementers or users of this		permission for the use of such proprietary rights by implementers or
	specification can be obtained from the IETF on-line IPR repository at		users of this specification can be obtained from the IETF on-line IPR
	http://www.ietf.org/ipr.		repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		any standard or specification contained in an IETF Document. Please
	ietf-ipr@ietf.org.		address the information to the IETF at ietf-ipr@ietf.org.
			The definitive version of an IETF Document is that published by, or
			under the auspices of, the IETF. Versions of IETF Documents that are
			published by third parties, including those that are translated into
			other languages, should not be considered to be definitive versions
			of IETF Documents. The definitive version of these Legal Provisions
			is that published by, or under the auspices of, the IETF. Versions of
			these Legal Provisions that are published by third parties, including
			those that are translated into other languages, should not be
			considered to be definitive versions of these Legal Provisions.
			For the avoidance of doubt, each Contributor to the IETF Standards
			Process licenses each Contribution that he or she makes as part of
			the IETF Standards Process to the IETF Trust pursuant to the
			provisions of RFC 5378. No language to the contrary, or terms,
			conditions or rights that differ from or are inconsistent with the
			rights and licenses granted under RFC 5378, shall have any effect and
			shall be null and void, whether published or posted by such
			Contributor, or included with or in such Contribution.
	17. Normative References		17. Normative References
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)		[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label		Hierarchy with Generalized Multi-Protocol Label
	Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,		Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
	October 2005.		October 2005.
	18. Informative References		18. Informative References
	skipping to change at page 41, line 7		skipping to change at page 41, line 28
	Olufemi Komolafe		Olufemi Komolafe
	Cisco Systems		Cisco Systems
	96 Commercial Street		96 Commercial Street
	Edinburgh		Edinburgh
	EH6 6LX		EH6 6LX
	United Kingdom		United Kingdom
	EMail: femi@cisco.com		EMail: femi@cisco.com
	20. Disclaimer of Validity		20. Disclaimer of Validity
	This document and the information contained herein are provided on an		All IETF Documents and the information contained therein are provided
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
			FOR A PARTICULAR PURPOSE.
	21. Full Copyright Statement		21. Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2008 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	This document is subject to the rights, licenses and restrictions		This document is subject to BCP 78 and the IETF Trust's Legal
	contained in BCP 78, and except as set forth therein, the authors		Provisions Relating to IETF Documents
	retain all their rights.		(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.
End of changes. 20 change blocks.
	65 lines changed or deleted		87 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/