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/