--- 1/draft-ietf-mpls-te-scaling-analysis-03.txt 2008-12-02 18:12:02.000000000 +0100 +++ 2/draft-ietf-mpls-te-scaling-analysis-04.txt 2008-12-02 18:12:02.000000000 +0100 @@ -1,60 +1,60 @@ - Network Working Group S. Yasukawa Internet-Draft NTT Intended Status: Informational A. Farrel -Created: June 19, 2008 Old Dog Consulting -Expires: December 19, 2008 O. Komolafe +Created: December 2, 2008 Old Dog Consulting +Expires: June 2, 2009 O. Komolafe Cisco Systems 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 - By submitting this Internet-Draft, each author represents that any - 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 - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. - The list of Internet-Draft Shadow Directories can be - accessed at http://www.ietf.org/shadow.html. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns - for MPLS-TE core networks, and examines the value of two techniques - (LSP hierarchies, and multipoint-to-point LSPs) for improving - scaling. The intention is to motivate the development of appropriate - deployment techniques and protocol extensions to enable the - application of MPLS-TE in large networks. + for the number of Label Switching Paths (LSPs) in MPLS-TE core + networks, and examines the value of two techniques (LSP hierarchies, + and multipoint-to-point LSPs) for improving scaling. The intention is + to motivate the development of appropriate deployment techniques and + protocol extensions to enable the application of MPLS-TE in large + networks. - This document considers only scalability for point-to-point MPLS-TE. - Point-to-multipoint MPLS-TE is for future study. + This document only considers the question of achieving scalability + for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint + MPLS-TE LSPs are for future study. Contents 1. Introduction .................................................. 3 1.1 Overview ..................................................... 3 1.2 Glossary of Notation ......................................... 4 2. Issues of Concern for Scaling ................................. 5 2.1 LSP State ................................................... 5 2.2 Processing Overhead .......................................... 5 2.3 RSVP-TE Implications ......................................... 6 2.4 Management ................................................... 7 @@ -90,22 +90,22 @@ 9. Combined Models ............................................... 34 10. An Alternate Solution ........................................ 35 10.1 Pros and Cons of the Alternate Solution ..................... 36 11. Management Considerations .................................... 37 12. Security Considerations ...................................... 37 13. Recommendations .............................................. 38 14. IANA Considerations .......................................... 38 15. Acknowledgements ............................................. 38 16. Intellectual Property Consideration .......................... 39 17. Normative References ......................................... 39 - 18. Informative References ....................................... 39 - 19. Authors' Addresses ........................................... 40 + 18. Informative References ....................................... 40 + 19. Authors' Addresses ........................................... 41 1. Introduction Network operators and service providers are examining scaling issues as they look to deploy ever-larger traffic engineered Multiprotocol Label Switching (MPLS-TE) networks. Concerns have been raised about 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 plane and management plane resources threatens to outweigh the benefits and popularity of MPLS-TE, while the physical limitations of @@ -165,31 +165,31 @@ of 'duplicate' LSPs. This issue is not addressed in this document. It should also be understood that certain deployment models where separate traffic engineered LSPs are used to provide different services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or different classes of service [RFC3270], may result in 'duplicate' or 'parallel' LSPs running between any pair of provider edge nodes (PEs). This scaling factor is also not considered in this document, but may be easily applied as a linear factor by the reader. - The intention of this document is to help service providers discover - whether existing protocols and implementations can support the - network sizes that they are planning. To do this, it presents an - analysis of some of the scaling concerns for MPLS-TE core networks, - and examines the value of two techniques for improving scaling. This - should motivate the development of appropriate deployment techniques - and protocol extensions to enable the application of MPLS-TE in large - networks. + This document is designed to help service providers discover whether + existing protocols and implementations can support the network sizes + that they are planning. To do this, it presents an analysis of some + of the scaling concerns for MPLS-TE core networks, and examines the + value of two techniques for improving scaling. This should motivate + the development of appropriate deployment techniques and protocol + extensions to enable the application of MPLS-TE in large networks. - This document considers only scalability for point-to-point MPLS-TE. - Point-to-multipoint MPLS-TE is for future study. + This document only considers the question of achieving scalability + 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 This document applies consistent notation to define various parameters of the networks that are analyzed. These terms are defined as they are introduced though-out the document, but are grouped together here for quick reference. Refer to the full definitions in the text for detailed explanations. n A network level. n = 1 is the core of the network. @@ -203,22 +203,23 @@ R The number of rungs in a ladder network. E The number of edge nodes (PEs) subtended below (directly or indirectly) a spar node in a ladder network. K The cost-effectiveness of the network expressed in terms of the ratio of the number of PEs to the number of network nodes. 2. Issues of Concern for Scaling 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 - there is a limit to the number LSPs that can be supported. + of LSPs at a Label Switching Router (LSR) or within the network. + These issues may mean that there is a limit to the number LSPs that + can be supported. 2.1 LSP State 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 necessary to maintain forwarding plane state and the additional information required when LSPs are established through control plane protocols. While the size of the LSP state is implementation- dependent, it is clear that any implementation will require some data in order to maintain LSP state. @@ -315,23 +316,24 @@ Another practical concern for the scalability of large MPLS-TE networks is the ability to manage the network. This may be constrained by the available tools, the practicality of managing large numbers of LSPs, and the management protocols in use. Management tools are software implementations. Although such implementations should not constrain the control plane protocols, it is realistic to appreciate that network deployments will be limited 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 - an NMS may be able to support a large number of LSPs, the number that - can be supported by an EMS (or the number supported by an NMS - per-LSR) is more likely to be limited. + a Network Management System (NMS) may be able to support a large + number of LSPs, the number that can be supported by anElement + 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 management protocols. For example, an LSR may be swamped by management protocol requests to read information about the LSPs that it supports, and this might impact its ability to sustain those LSPs 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 support. All of these consideration encourage a reduction in the number of @@ -572,25 +573,25 @@ /| /| /| /| |\ |\ |\ |\ PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE Figure 5 : An Example Ladder Network 3.3 Commercial Drivers for Selected Configurations It is reasonable to ask why these two particular network topologies have been chosen. - The consideration must be physical scalability. Each node (label - switching router - LSR) is only able to support a limited number of - physical interfaces. This necessarily reduces the ability to fully - mesh a network and leads to the tree-like structure of the network - toward the PEs. + The most important consideration is physical scalability. Each node + (label switching router - LSR) is only able to support a limited + number of physical interfaces. This necessarily reduces the ability + to fully mesh a network and leads to the tree-like structure of the + network toward the PEs. A realistic commercial consideration for an operator is the fact that the only revenue-generating nodes in the network are the PEs. Other nodes are needed only to support connectivity and scalability. 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 minimizing the number of levels, and by maximizing the connectivity at each layer, M(n). Ultimately, however, this would produce a network of just interconnected PEs, which is clearly in conflict with the physical scaling situation. @@ -1862,41 +1863,59 @@ 15. Acknowledgements The authors are grateful to Jean-Louis Le Roux for discussions and review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson, and Anders Gavler for their comments. Thanks to Dave Allen for useful discussion of the maths. 16. Intellectual Property Consideration - 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. + The IETF Trust 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 any IETF 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. - 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. + Copies of Intellectual Property 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. + any standard or specification contained in an IETF Document. Please + 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 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 18. Informative References @@ -1957,25 +1976,30 @@ Olufemi Komolafe Cisco Systems 96 Commercial Street Edinburgh EH6 6LX United Kingdom EMail: femi@cisco.com 20. 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. + All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. 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 - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. + 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.