draft-ietf-mpls-te-scaling-analysis-01.txt   draft-ietf-mpls-te-scaling-analysis-02.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: October 13, 2007 Old Dog Consulting Created: April 24, 2008 Old Dog Consulting
Expires: April 13, 2008 O. Komolafe Expires: October 24, 2008 O. Komolafe
Cisco Systems Cisco Systems
An Analysis of Scaling Issues in MPLS-TE Backbone Networks An Analysis of Scaling Issues in MPLS-TE Core Networks
draft-ietf-mpls-te-scaling-analysis-01.txt draft-ietf-mpls-te-scaling-analysis-02.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 1, line 39 skipping to change at page 1, line 39
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 http://www.ietf.org/shadow.html. accessed at 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' backbone networks. As providers plan to grow deployed in providers' core networks. As providers plan to grow these
these networks, they need to discover 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 backbone networks, and examines the value of two for MPLS-TE core networks, and examines the value of two techniques
techniques for improving scaling. The intention is to motivate the (LSP hierarchies, and multipoint-to-point LSPs) for improving
development of appropriate deployment techniques and protocol scaling. The intention is to motivate the development of appropriate
extensions to enable the application of MPLS-TE in large networks. 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. This document considers only scalability for point-to-point MPLS-TE.
Point-to-multipoint MPLS-TE is for future study. Point-to-multipoint MPLS-TE is 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 ......................................... 5 2.3 RSVP-TE Implications ......................................... 6
2.4 Management ................................................... 6 2.4 Management ................................................... 7
3. Network Topologies ............................................ 7 3. Network Topologies ............................................ 7
3.1 The Snowflake Network Topology ............................... 7 3.1 The Snowflake Network Topology ............................... 8
3.2 The Ladder Network Topology .................................. 9 3.2 The Ladder Network Topology .................................. 10
3.3 Commercial Drivers for Selected Configurations ............... 12 3.3 Commercial Drivers for Selected Configurations ............... 12
3.4 Other Network Topologies ..................................... 13 3.4 Other Network Topologies ..................................... 13
4. Required Network Sizes ........................................ 13 4. Required Network Sizes ........................................ 13
4.1 Practical Numbers ............................................ 14 4.1 Practical Numbers ............................................ 14
5. Scaling in Flat Networks ...................................... 14 5. Scaling in Flat Networks ...................................... 14
5.1 Snowflake Networks ........................................... 14 5.1 Snowflake Networks ........................................... 14
5.2 Ladder Networks .............................................. 16 5.2 Ladder Networks .............................................. 16
6. Scaling Snowflake Networks with Forwarding Adjacencies ........ 19 6. Scaling Snowflake Networks with Forwarding Adjacencies ........ 19
6.1 Two Layer Hierarchy .......................................... 19 6.1 Two Layer Hierarchy .......................................... 19
6.1.1 Tuning the Network Topology to Suit the Two Layer Hierarchy 20 6.1.1 Tuning the Network Topology to Suit the Two Layer Hierarchy 20
6.2 Alternative Two Layer Hierarchy .............................. 21 6.2 Alternative Two Layer Hierarchy .............................. 21
6.3 Three Layer Hierarchy ........................................ 22 6.3 Three Layer Hierarchy ........................................ 22
6.4 Issues with Hierarchical LSPs ............................... 23 6.4 Issues with Hierarchical LSPs ............................... 23
7. Scaling Ladder Networks with Forwarding Adjacencies............ 24 7. Scaling Ladder Networks with Forwarding Adjacencies............ 24
7.1 Two Layer Hierarchy .......................................... 24 7.1 Two Layer Hierarchy .......................................... 24
7.2 Three Layer Hierarchy ........................................ 25 7.2 Three Layer Hierarchy ........................................ 25
7.3 Issues with Hierarchical LSPs ................................ 26 7.3 Issues with Hierarchical LSPs ................................ 26
8. Scaling Improvements Through Multipoint-to-Point LSPs ......... 26 8. Scaling Improvements Through Multipoint-to-Point LSPs ......... 26
8.1 Overview of MP2P LSPs ........................................ 27 8.1 Overview of MP2P LSPs ........................................ 27
8.2 LSP State : A Better Measure of Scalability .................. 27 8.2 LSP State: A Better Measure of Scalability ................... 27
8.3 Scaling Improvements for Snowflake Networks .................. 28 8.3 Scaling Improvements for Snowflake Networks .................. 28
8.3.1 Comparison with Other Scenarios ............................ 30 8.3.1 Comparison with Other Scenarios ............................ 30
8.4 Scaling Improvements for Ladder Networks ..................... 31 8.4 Scaling Improvements for Ladder Networks ..................... 31
8.4.1 Comparison with Other Scenarios ............................ 32 8.4.1 Comparison with Other Scenarios ............................ 32
8.4.2 LSP State Compared with LSP Numbers ........................ 33 8.4.2 LSP State Compared with LSP Numbers ........................ 33
8.5 Issues with MP2P LSPs ........................................ 33 8.5 Issues with MP2P LSPs ........................................ 33
9. Combined Models ............................................... 34 9. Combined Models ............................................... 34
10. Management Considerations .................................... 35 10. An Alternate Solution ........................................ 35
11. Security Considerations ...................................... 35 10.1 Pros and Cons of the Alternate Solution ..................... 36
12. Recommendations .............................................. 35 11. Management Considerations .................................... 37
13. IANA Considerations .......................................... 36 12. Security Considerations ...................................... 37
14. Acknowledgements ............................................. 36 13. Recommendations .............................................. 38
15. Intellectual Property Consideration .......................... 36 14. IANA Considerations .......................................... 38
16. Normative References ......................................... 36 15. Acknowledgements ............................................. 38
17. Informative References ....................................... 37 16. Intellectual Property Consideration .......................... 39
18. Authors' Addresses ........................................... 38 17. Normative References ......................................... 39
19. Disclaimer of Validity ....................................... 38 18. Informative References ....................................... 39
20. Full Copyright Statement ..................................... 38 19. Authors' Addresses ........................................... 40
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
the routers may constrain the deployment options. the routers may constrain the deployment options.
Historically, it has been assumed that all MPLS-TE scaling issues Historically, it has been assumed that all MPLS-TE scaling issues
can be addressed using hierarchical LSP [RFC4206]. However, analysis can be addressed using hierarchical LSP [RFC4206]. However, analysis
shows that the improvement gained by LSP hierarchies is not as shows that the improvement gained by LSP hierarchies is not as
significant as might have been presumed in all topologies and at all significant in all topologies and at all points in the network as
points in the network. Further, additional management issues are might have been presumed. Further, additional management issues are
introduced to determine the end-points of the hierarchical LSPs and introduced to determine the end-points of the hierarchical LSPs and
to operate them. Although this does not invalidate the benefits of to operate them. Although this does not invalidate the benefits of
LSP hierarchies, it does indicate that additional techniques may be LSP hierarchies, it does indicate that additional techniques may be
desirable in order to fully scale MPLS-TE networks. desirable in order to fully scale MPLS-TE networks.
This document examines the scaling properties of two generic MPLS-TE This document examines the scaling properties of two generic MPLS-TE
network topologies, and investigates the benefits of two scaling network topologies, and investigates the benefits of two scaling
techniques. techniques.
1.1 Overview 1.1 Overview
skipping to change at page 3, line 44 skipping to change at page 3, line 44
the core, but tree-shaped at the edges giving rise to a snow-flake the core, but tree-shaped at the edges giving rise to a snow-flake
design. Alternatively, the core may be more of a ladder shape with design. Alternatively, the core may be more of a ladder shape with
tree-shaped edges. tree-shaped edges.
MPLS-TE, however, establishes a logical full mesh between all edge MPLS-TE, however, establishes a logical full mesh between all edge
points in the network, and this is where the scaling problems arise points in the network, and this is where the scaling problems arise
since the structure of the network tends to focus a large number of since the structure of the network tends to focus a large number of
LSPs within the core of the network. LSPs within the core of the network.
This document presents two generic network topologies: the snow-flake This document presents two generic network topologies: the snow-flake
and the ladder, and attmepts to parameterize the networks by making and the ladder, and attempts to parameterize the networks by making
some generalities. It introduces terminology for the different some generalities. It introduces terminology for the different
scaling parameters and examines how many LSPs might be required to be scaling parameters and examines how many LSPs might be required to be
carried within the core of a network. carried within the core of a network.
Two techniques (hierarchical and multipoint-to-point LSPs) are Two techniques (hierarchical LSPs, and multipoint-to-point LSPs) are
introduced and an examination is made of the scaling benefits that introduced and an examination is made of the scaling benefits that
they offer as well as of some of the concerns with using these they offer as well as of some of the concerns with using these
techniques. techniques.
Of necessity, this document makes many generalizations. Not Of necessity, this document makes many generalizations. Not least
least among these are a set of assumptions about the symmetry and among these are a set of assumptions about the symmetry and
connectivity of the physical network. It is hoped that these connectivity of the physical network. It is hoped that these
generalizations will not impinge on the usefulness of the overview of generalizations will not impinge on the usefulness of the overview of
the scaling properties that this document attempts to give. Indeed, the scaling properties that this document attempts to give. Indeed,
the symmetry of the example topologies tends to highlight the the symmetry of the example topologies tends to highlight the
scaling issues of the different solution models, and this may be scaling issues of the different solution models, and this may be
useful in exposing the worst case scenarios. useful in exposing the worst case scenarios.
Although protection mechanisms like Fast Re-route (FRR) [RFC4090] are Although protection mechanisms like Fast Re-route (FRR) [RFC4090] are
briefly discussed, the main body of this document considers stable briefly discussed, the main body of this document considers stable
network cases. It should be noted that make-before-break network cases. It should be noted that make-before-break
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 The intention of this document is to help service providers discover
whether existing protocols and implementations can support the whether existing protocols and implementations can support the
network sizes that they are planning. To do this, it presents an network sizes that they are planning. To do this, it presents an
analysis of some of the scaling concerns for MPLS-TE backbone analysis of some of the scaling concerns for MPLS-TE core networks,
networks, and examines the value of two techniques for improving and examines the value of two techniques for improving scaling. This
scaling. This should motivate the development of appropriate should motivate the development of appropriate deployment techniques
deployment techniques and protocol extensions to enable the and protocol extensions to enable the application of MPLS-TE in large
application of MPLS-TE in large networks. networks.
This document considers only scalability for point-to-point MPLS-TE. This document considers only scalability for point-to-point MPLS-TE.
Point-to-multipoint MPLS-TE is for future study. Point-to-multipoint MPLS-TE is 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 an LSR or within the network. These issues may mean that
there is a limit to the number LSPs that can be supported. 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 plane protocols. While the size of the LSP state is implementation-
implementation-dependent, it is clear that any implementation will dependent, it is clear that any implementation will require some data
require some data in order to maintain LSP state. in order to maintain LSP state.
Thus LSP state becomes a scaling concern because as the number of Thus LSP state becomes a scaling concern because as the number of
LSPs at an LSR increases, so the amount of memory required to LSPs at an LSR increases, so the amount of memory required to
maintain the LSPs increases in direct proportion. Since the memory maintain the LSPs increases in direct proportion. Since the memory
capacity of an LSR is limited, there is a related limit placed on the capacity of an LSR is limited, there is a related limit placed on the
number LSPs that can be supported. number LSPs that can be supported.
Note that techniques to reduce the memory requirements (such as data Note that techniques to reduce the memory requirements (such as data
compression) may serve to increase the number of LSPs that can be compression) may serve to increase the number of LSPs that can be
supported, but this will only achieve a moderate multiplier and may supported, but this will only achieve a moderate multiplier and may
significantly decrease the ability to process the state rapidly. significantly decrease the ability to process the state rapidly.
In this document we define X(n) as "The number of LSP segment states
held by a P(n) node." This definition observes that an LSR at the end
of an LSP only has to maintain state in one direction (i.e., into the
network), while a transit LSR must maintain state in both directions
(i.e., toward both ends of the LSP). Furthermore, in multipoint-to-
point (MP2P) LSPs (see Section 8) a transit LSR may need to maintain
LSP state for one downstream segment (toward the destination) and
multiple upstream segments (from multiple sources).
2.2 Processing Overhead 2.2 Processing Overhead
Depending largely on implementation issues, the number of LSPs Depending largely on implementation issues, the number of LSPs
supported by an LSR may impact the processing speed for each LSP. For passing through an LSR may impact the processing speed for each LSP.
example, control block search times can increase with the number of For example, control block search times can increase with the number
control blocks, and even excellent implementations cannot completely of control blocks to be searched, and even excellent implementations
mitigate this fact. Thus, since CPU power is constrained in any LSR, cannot completely mitigate this fact. Thus, since CPU power is
there may be a practical limit to the number of LSPs that can be constrained in any LSR, there may be a practical limit to the number
supported. of LSPs that can be supported.
Further processing overhead considerations depend on issues specific Further processing overhead considerations depend on issues specific
to the control plane protocols, and are discussed in the next to the control plane protocols, and are discussed in the next
section. section.
2.3 RSVP-TE Implications 2.3 RSVP-TE Implications
Like many connection-oriented signaling protocols, RSVP-TE requires Like many connection-oriented signaling protocols, RSVP-TE requires
that state is held within the network in order to maintain LSPs. The that state is held within the network in order to maintain LSPs. The
impact of this is described in Section 2.1. Note that RSVP-TE impact of this is described in Section 2.1. Note that RSVP-TE
skipping to change at page 6, line 28 skipping to change at page 6, line 37
in a stable network. in a stable network.
Observations of existing implementations indicate that there may be a Observations of existing implementations indicate that there may be a
threshold of around 50,000 LSPs above which an LSR struggles to threshold of around 50,000 LSPs above which an LSR struggles to
achieve sufficient processing to maintain LSP state. Although refresh achieve sufficient processing to maintain LSP state. Although refresh
reduction [RFC2961] may substantially improve this situation, reduction [RFC2961] may substantially improve this situation,
it has also been observed that under these circumstances the size of it has also been observed that under these circumstances the size of
the Srefresh may become very large and the processing required may the Srefresh may become very large and the processing required may
still cause significant disruption to an LSR. still cause significant disruption to an LSR.
An alternative approach is to increase the refresh time. There is a Another approach is to increase the refresh time. There is a
correlation between the percentage increase in refresh time and the correlation between the percentage increase in refresh time and the
improvement in performance for the LSR. However, it should be noted improvement in performance for the LSR. However, it should be noted
that RSVP-TE's soft-state nature depends on regular refresh messages, that RSVP-TE's soft-state nature depends on regular refresh messages,
thus a degree of functionality is lost by increasing the refresh thus a degree of functionality is lost by increasing the refresh
time. This loss may be partially mitigated by the use of the RSVP-TE time. This loss may be partially mitigated by the use of the RSVP-TE
Hello message, and can also be reduced by the use of various GMPLS Hello message, and can also be reduced by the use of various GMPLS
extensions [RFC3473] such as the use of [RFC2961] message extensions [RFC3473] such as the use of [RFC2961] message
acknowledgements on all messages. acknowledgements on all messages.
RSVP-TE also requires that signaling adjacencies are maintained RSVP-TE also requires that signaling adjacencies are maintained
through the use of Hello message exchanges. Although [RFC3209] through the use of Hello message exchanges. Although [RFC3209]
suggests that Hello messages should be retransmitted every 5ms, in suggests that Hello messages should be retransmitted every 5ms, in
practice values of around 3 seconds are more common. Nevertheless, practice values of around 3 seconds are more common. Nevertheless,
the support of Hello messages can represent a scaling limitation on the support of Hello messages can represent a scaling limitation on
an RSVP-TE implementation since one message must be sent and received an RSVP-TE implementation since one message must be sent and received
to/from each signaling adjacency every time period. This can impose to/from each signaling adjacency every time period. This can impose
limits on the number of neighbors (physical or logical) that an LSR limits on the number of neighbors (physical or logical) that an LSR
supports. supports, but does not impact the number of LSPs that the LSR can
handle.
2.4 Management 2.4 Management
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
skipping to change at page 7, line 50 skipping to change at page 8, line 10
The second network topology considered is the ladder model. In this The second network topology considered is the ladder model. In this
type of network the core of the network is shaped and meshed in the type of network the core of the network is shaped and meshed in the
form of a ladder and trees are attached rooted to the edge of the form of a ladder and trees are attached rooted to the edge of the
ladder. ladder.
The sections that follow examine these topologies in detail in order The sections that follow examine these topologies in detail in order
to parameterize them. to parameterize them.
3.1 The Snowflake Network Topology 3.1 The Snowflake Network Topology
The snowflake toplogies considered in this document are based on a The snowflake topologies considered in this document are based on a
hierarchy of connectivity within the core network. PE nodes have hierarchy of connectivity within the core network. PE nodes have
connectivity to P-nodes as shown in Figure 1. There is no direct connectivity to P-nodes as shown in Figure 1. There is no direct
connectivity between the PEs. Dual homing of PEs to multiple P connectivity between the PEs. Dual homing of PEs to multiple P
nodes is not considered in this document although it may be a nodes is not considered in this document although it may be a
valuable addition to a network configuration. valuable addition to a network configuration.
P P
/|\ /|\
/ | \ / | \
/ | \ / | \
skipping to change at page 8, line 39 skipping to change at page 8, line 50
/ | \ / | \
/ | \ / | \
P(n+1) P(n+1) P(n+1) P(n+1) P(n+1) P(n+1)
Figure 2 : Relationship Between P-Nodes Figure 2 : Relationship Between P-Nodes
At the top level, P(1) nodes are connected in a full mesh. In At the top level, P(1) nodes are connected in a full mesh. In
reality, the level 1 part of the network may be slightly less well reality, the level 1 part of the network may be slightly less well
connected than this, but assuming a full mesh provides for connected than this, but assuming a full mesh provides for
generality. Thus, the snowflake topology comprises a clique with generality. Thus, the snowflake topology comprises a clique with
equivalent trees subtended from each node in the clique. topologically equivalent trees subtended from each node in the
clique.
The key multipliers for scalability are the number of P(1) nodes, and The key multipliers for scalability are the number of P(1) nodes, and
the multiplier relationship between P(n) and P(n+1) at each level the multiplier relationship between P(n) and P(n+1) at each level
including down to PEs. including down to PEs.
We define the multiplier M(n) as the number of P(n+1) nodes at level We define the multiplier M(n) as the number of P(n+1) nodes at level
(n+1) attached to any one P(n). Assume that M(n) is constant for all (n+1) attached to any one P(n). Assume that M(n) is constant for all
nodes at level n. Since nodes at the same level are not nodes at level n. Since nodes at the same level are not
interconnected (except at the top level), and since each P(n+1) node interconnected (except at the top level), and since each P(n+1) node
is connected to precisely one P(n) node, M(n) is one less than the is connected to precisely one P(n) node, M(n) is one less than the
degree of the node at level n. degree of the node at level n (that is, the P(n) node is attached to
M(n) nodes at level (n+1) and 1 node at level (n-1)).
We define S(n) as the number of nodes at level (n). We define S(n) as the number of nodes at level (n).
Thus: S(n) = S(1)*M(1)*M(2)*...*M(n-1) Thus: S(n) = S(1)*M(1)*M(2)*...*M(n-1)
So the number of PEs can be expressed as: So the number of PEs can be expressed as:
S(PE) = S(1)*M(1)*M(2)*...*M(n) S(PE) = S(1)*M(1)*M(2)*...*M(n)
where the network has (n) layers of P-nodes. where the network has (n) layers of P-nodes.
skipping to change at page 10, line 6 skipping to change at page 10, line 19
Ladder networks typically have long and thin cores that are arranged Ladder networks typically have long and thin cores that are arranged
as conventional ladders. That is, they have one or more spars as conventional ladders. That is, they have one or more spars
connected by rungs. Each node on a spar may have: connected by rungs. Each node on a spar may have:
- connection to one or more other spars - connection to one or more other spars
- connection to a tree of other core nodes - connection to a tree of other core nodes
- connection to customer nodes. - connection to customer nodes.
Figure 4 shows a simplified example of a ladder network. A core of Figure 4 shows a simplified example of a ladder network. A core of
twelve nodes make up two spars connected by six rungs. Two of the twelve nodes make up two spars connected by six rungs.
nodes on the spars are themselves PEs, while the rest have PEs
subtended.
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-P-----P-----P-----PE-----P-----P--PE PE-P-----P-----P-----P------P-----P--PE
| | | | | |\ | | | | | |\
| | | | | | PE | | | | | | PE
| | | | | | | | | | | |
PE-P-----P-----P-----P------P-----PE PE-P-----P-----P-----P------P-----P
/| /|\ |\ |\ |\ /| /|\ |\ |\ |\ \
PE PE PE | PE | PE | PE | PE PE PE PE | PE | PE | PE | PE PE
PE PE PE PE PE PE PE PE
Figure 4 : A Simplified Ladder Network. Figure 4 : A Simplified Ladder Network.
In practice, not all nodes on a spar (call them Spar-Nodes) need to In practice, not all nodes on a spar (call them Spar-Nodes) need to
have subtended PEs or CEs. That is, they can exist simply to give have subtended PEs. That is, they can exist simply to give
connectivity along the spar to other spar nodes, or across a rung to connectivity along the spar to other spar nodes, or across a rung to
another spar. Similarly, the connectivity between spars can be more another spar. Similarly, the connectivity between spars can be more
complex with multiple connections from one spar-node to another spar. complex with multiple connections from one spar-node to another spar.
Lastly, the network may be complicated by the inclusion of more than Lastly, the network may be complicated by the inclusion of more than
two spars (or simplified by reduction to a single spar). two spars (or simplified by reduction to a single spar).
These variables make the ladder network non-trivial to model. For the These variables make the ladder network non-trivial to model. For the
sake of simplicity we will make the following restrictions: sake of simplicity we will make the following restrictions:
- There are precisely two spars in the core network. - There are precisely two spars in the core network.
skipping to change at page 13, line 35 skipping to change at page 13, line 35
and generalized network topologies for simplicity of modelling. In and generalized network topologies for simplicity of modelling. In
practice there are two other topological considerations. practice there are two other topological considerations.
a. Multihoming a. Multihoming
It is relatively common for a node at level (n) to be attached to It is relatively common for a node at level (n) to be attached to
more than one node at level (n-1). This is particularly common at more than one node at level (n-1). This is particularly common at
PEs that may be connected to more than one P(n). PEs that may be connected to more than one P(n).
b. Meshing within a level b. Meshing within a level
A level in the network will often include links between P-nodes at A level in the network will often include links between P-nodes at
the same level. This may result in a network that looks like a the same level including the possibility of links between PEs.
series of concentric circles with spokes. This may result in a network that looks like a series of
concentric circles with spokes.
Both of these features are likely to have some impact on the scaling Both of these features are likely to have some impact on the scaling
of the networks. However, for the purposes of establishing the of the networks. However, for the purposes of establishing the
ground-rules for scaling, this document restricts itself to the ground-rules for scaling, this document restricts itself to the
consideration of the symmetrical network described in Sections 2.1 consideration of the symmetrical networks described in Sections 2.1
and 2.2. Discussion of other network formats may be introduced in a and 2.2. Discussion of other network formats is for future study.
future revision of this document.
4. Required Network Sizes 4. Required Network Sizes
An important question for this evaluation and analysis is the size of An important question for this evaluation and analysis is the size of
the network that operators require. How many PEs are required? What the network that operators require. How many PEs are required? What
ratio of P to PE is acceptable. How many ports do devices have for ratio of P to PE is acceptable. How many ports do devices have for
physical connectivity? What type of MPLS-TE connectivity between PEs physical connectivity? What type of MPLS-TE connectivity between PEs
is required? is required?
Although presentation of figures for desired network sizes must be Although presentation of figures for desired network sizes must be
skipping to change at page 15, line 13 skipping to change at page 15, line 13
incoming into a particular PE. incoming into a particular PE.
There are a total of M(2)*(M(2) - 1) LSPs between these M(2) PEs and There are a total of M(2)*(M(2) - 1) LSPs between these M(2) PEs and
since this value is erroneously included twice in 2*(S(PE) - 1)*M(2), since this value is erroneously included twice in 2*(S(PE) - 1)*M(2),
the correct value is: the correct value is:
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1) L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1)
= M(2)*(2*S(PE) - M(2) - 1) = M(2)*(2*S(PE) - M(2) - 1)
An alternative way of looking at this, that proves extensible for the An alternative way of looking at this, that proves extensible for the
calculation of L(1), is to obeserve that each PE subtended to a P(2) calculation of L(1), is to observe that each PE subtended to a P(2)
node has an LSP in each direction to all S(PE) - M(2) PEs in the rest node has an LSP in each direction to all S(PE) - M(2) PEs in the rest
of the system, and there are M(2) such locally subtended PEs; thus of the system, and there are M(2) such locally subtended PEs; thus
2*M(2)*(S(PE) - M(2)). Additionally there are M(2)*(M(2) - 1) LSPs 2*M(2)*(S(PE) - M(2)). Additionally there are M(2)*(M(2) - 1) LSPs
between the locally subtended PEs. So: between the locally subtended PEs. So:
L(2) = 2*M(2)*(S(PE) - M(2)) + M(2)*(M(2) - 1) L(2) = 2*M(2)*(S(PE) - M(2)) + M(2)*(M(2) - 1)
= M(2)*(2*S(PE) - M(2) - 1) = M(2)*(2*S(PE) - M(2) - 1)
L(1) can be computed in the same way as this second evaluation of L(1) can be computed in the same way as this second evaluation of
L(2). Each PE subtended below a P(1) node has an LSP in each L(2). Each PE subtended below a P(1) node has an LSP in each
skipping to change at page 16, line 37 skipping to change at page 16, line 37
seen from the snowflake network. They are: seen from the snowflake network. They are:
o E*(E-1) o E*(E-1)
o M(1)*M(2)*(M(2)-1) = E*(M(2) - 1) o M(1)*M(2)*(M(2)-1) = E*(M(2) - 1)
o 2*E*E*(S(1) - 1) o 2*E*E*(S(1) - 1)
The number of LSPs in transit is more complicated to compute. It is The number of LSPs in transit is more complicated to compute. It is
simplified by not considering the ends of the ladders, but examining simplified by not considering the ends of the ladders, but examining
an arbitrary segment of the middle of the ladder such as shown in an arbitrary segment of the middle of the ladder such as shown in
Figure 6. We look to compute and generalize the number of LSPs Figure 6. We look to compute and generalize the number of LSPs
traversing each core link (labelled a and b in Figure 6) and so traversing each core link (labeled a and b in Figure 6) and so
determine the number of transit LSPs seen by each P(1). determine the number of transit LSPs seen by each P(1).
: : : : : : : : : : : :
: : : : : : : : : : : :
P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2)
\ | \ / | / \ | \ / | /
\ | \ / | / \ | \ / | /
\| \/ |/ \| \/ |/
......P(1)---P(1)---P(1)...... ......P(1)---P(1)---P(1)......
| a | | | a | |
skipping to change at page 19, line 53 skipping to change at page 19, line 53
In this hierarchy model, the P(2) nodes are connected by a mesh of In this hierarchy model, the P(2) nodes are connected by a mesh of
tunnels. This means that the P(1) nodes do not see the PE-to-PE LSPs. tunnels. This means that the P(1) nodes do not see the PE-to-PE LSPs.
It remains the case that: It remains the case that:
L(PE) = 2*(S(PE) - 1) L(PE) = 2*(S(PE) - 1)
L(2) is slightly increased. It can be computed as the sum of all LSPs L(2) is slightly increased. It can be computed as the sum of all LSPs
for all attached PEs including the LSPs between the attached PE (this for all attached PEs including the LSPs between the attached PE (this
figure is unchanged from Section 5.1: i.e, M(2)*(2*S(PE) - M(2) - 1)) figure is unchanged from Section 5.1: i.e. M(2)*(2*S(PE) - M(2) - 1))
plus the number of FA LSPs providing a mesh to the other P(2) nodes. plus the number of FA LSPs providing a mesh to the other P(2) nodes.
Since the number of P(2) nodes is S(2), each P(2) node sees Since the number of P(2) nodes is S(2), each P(2) node sees
2*(S(2) - 1) FA LSPs. Thus: 2*(S(2) - 1) FA LSPs. Thus:
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1) L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
L(1), however, is significantly reduced and can be computed as the L(1), however, is significantly reduced and can be computed as the
sum of the number of FA LSPs to and from each attached P(2) to each sum of the number of FA LSPs to and from each attached P(2) to each
other P(2) in the network, including (but counting only once) the FA other P(2) in the network, including (but counting only once) the FA
LSPs between attached P(2) nodes. In fact, the problem is identical LSPs between attached P(2) nodes. In fact, the problem is identical
skipping to change at page 24, line 29 skipping to change at page 24, line 29
7. Scaling Ladder Networks with Forwarding Adjacencies 7. Scaling Ladder Networks with Forwarding Adjacencies
7.1 Two Layer Hierarchy 7.1 Two Layer Hierarchy
In Section 6.2, we observed that there is no value to placing FA LSPs In Section 6.2, we observed that there is no value to placing FA LSPs
between the P(1) nodes of our example snowflake topologies. This is between the P(1) nodes of our example snowflake topologies. This is
because those LSPs would be just one hop long and would, in fact, because those LSPs would be just one hop long and would, in fact,
only serve to increase the burden at the P(1) nodes. However, in the only serve to increase the burden at the P(1) nodes. However, in the
ladder model, there is value to this approach. The P(1) nodes are the ladder model, there is value to this approach. The P(1) nodes are the
spar nodes of the ladder, and they are not all mutually adjacent. spar nodes of the ladder, and they are not all mutually adjacent.
That is, the P(1)-to-P(1) hiearchical LSPs can create a full mesh of That is, the P(1)-to-P(1) hierarchical LSPs can create a full mesh of
P(1) nodes where one does not exist in the physical topology. P(1) nodes where one does not exist in the physical topology.
The number of LSPs seen by a P(1) node is then: The number of LSPs seen by a P(1) node is then:
o all of the tunnels terminating at the P(1) node o all of the tunnels terminating at the P(1) node
o any transit tunnels o any transit tunnels
o all of the LSPs due to subtended PEs. o all of the LSPs due to subtended PEs.
This is a substantial reduction because all of the transit LSPs are This is a substantial reduction because all of the transit LSPs are
reduced to just one per remote P(1) that causes any transit LSP. So: reduced to just one per remote P(1) that causes any transit LSP. So:
skipping to change at page 27, line 9 skipping to change at page 27, line 9
this case is achieved by reducing the number of LSPs toward the this case is achieved by reducing the number of LSPs toward the
destination as LSPs toward the same destination are merged. destination as LSPs toward the same destination are merged.
This section presents an overview of MP2P LSPs and describes their This section presents an overview of MP2P LSPs and describes their
applicability and scaling benefits. applicability and scaling benefits.
8.1 Overview of MP2P LSPs 8.1 Overview of MP2P LSPs
Note that the MP2P LSPs discussed here are for MPLS-TE and are not Note that the MP2P LSPs discussed here are for MPLS-TE and are not
the same concept familiar in the Label Distribution Protocol (LDP) the same concept familiar in the Label Distribution Protocol (LDP)
described in [RFC3036]. described in [RFC5036].
Traffic flows generally converge toward their destination and this Traffic flows generally converge toward their destination and this
can be utilized by MPLS in constructing an MP2P LSP. With such an can be utilized by MPLS in constructing an MP2P LSP. With such an
LSP, the LFIB mappings at each LSR are many-to-one so that multiple LSP, the LFIB mappings at each LSR are many-to-one so that multiple
pairs {incoming interface, incoming label} are mapped to a single pairs {incoming interface, incoming label} are mapped to a single
pair {outgoing interface, outgoing label}. Obviously, if per-platform pair {outgoing interface, outgoing label}. Obviously, if per-platform
labels are used, this mapping may be optimized within an labels are used, this mapping may be optimized within an
implementation. implementation.
It is important to note that with MP2P MPLS-TE LSPs the traffic flows It is important to note that with MP2P MPLS-TE LSPs the traffic flows
skipping to change at page 29, line 5 skipping to change at page 29, line 5
X(PE) = 4*(S(PE) - 1) if disambiguation is required X(PE) = 4*(S(PE) - 1) if disambiguation is required
Each P(2) node has M(2) downstream PEs. The P(2) sees a single MP2P Each P(2) node has M(2) downstream PEs. The P(2) sees a single MP2P
LSP targeted at each downstream PE with one downstream segment (to LSP targeted at each downstream PE with one downstream segment (to
that PE) and M(2) - 1 upstream segments from the other subtended PEs. that PE) and M(2) - 1 upstream segments from the other subtended PEs.
Additionally, each of these LSPs has an upstream segment from the one Additionally, each of these LSPs has an upstream segment from the one
upstream P(1). This gives a total of M(2)*(1 + M(2)) LSP segments. upstream P(1). This gives a total of M(2)*(1 + M(2)) LSP segments.
There are also LSPs running from the subtended PEs to each other PE There are also LSPs running from the subtended PEs to each other PE
in the network. There are S(PE) - M(2) such PEs, and the P(2) sees in the network. There are S(PE) - M(2) such PEs, and the P(2) sees
one upstream segement for each of these from each subtended PE. It one upstream segment for each of these from each subtended PE. It
also has one downstream segment for each of these LSPs. This gives also has one downstream segment for each of these LSPs. This gives
(M(2) + 1)*(S(PE) - M(2)) LSP segments. (M(2) + 1)*(S(PE) - M(2)) LSP segments.
Thus: Thus:
X(2) = M(2)*(1 + M(2)) + (M(2) + 1)*(S(PE) - M(2)) X(2) = M(2)*(1 + M(2)) + (M(2) + 1)*(S(PE) - M(2))
= S(PE)*(M(2) + 1) = S(PE)*(M(2) + 1)
Similarly, at each P(1) node there are M(1) downstream P(2) nodes and Similarly, at each P(1) node there are M(1) downstream P(2) nodes and
so a total of M(1)*M(2) downstream PEs. Each P(1) is connected in a so a total of M(1)*M(2) downstream PEs. Each P(1) is connected in a
skipping to change at page 32, line 22 skipping to change at page 32, line 22
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see: Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
E = 200 E = 200
S(PE) = 2000 S(PE) = 2000
X(PE) = 3998 X(PE) = 3998
X(2) = 42000 X(2) = 42000
X(1) <= 26000 X(1) <= 26000
8.4.1 Comparison with Other Scenarios 8.4.1 Comparison with Other Scenarios
The use of MP2P compares very favourably with all scaling scenarios. The use of MP2P compares very favorably with all scaling scenarios.
It is the only technique able to reduce the value of X(2), and it It is the only technique able to reduce the value of X(2), and it
does this by a factor of almost two. The impact on X(1) is better does this by a factor of almost two. The impact on X(1) is better
than everything except the three level hierarcy. than everything except the three level hierarchy.
The following table provides a quick cross-reference for the figures The following table provides a quick cross-reference for the figures
for the example ladder networks. Note that the previous figures are for the example ladder networks. Note that the previous figures are
modified to provide counts of LSP state rather than LSP numbers. modified to provide counts of LSP state rather than LSP numbers.
Again, each LSP contributes one state at its end points, and two Again, each LSP contributes one state at its end points, and two
states at transit nodes. states at transit nodes.
Thus, for the all cases we have Thus, for the all cases we have
X(PE) = 2*(S(PE) - 1) or X(PE) = 2*(S(PE) - 1) or
skipping to change at page 33, line 20 skipping to change at page 33, line 20
A | X(2) | 68748 | 68748 | 68866 | 18360 A | X(2) | 68748 | 68748 | 68866 | 18360
| X(1) | 1554820 | 572266 | 2226 | 12580 | X(1) | 1554820 | 572266 | 2226 | 12580
-------+-------+------------+------------+-------------+------- -------+-------+------------+------------+-------------+-------
B | X(2) | 159160 | 159160 | 159358 | 42000 B | X(2) | 159160 | 159160 | 159358 | 42000
| X(1) | 5032000 | 1433998 | 3898 | 26000 | X(1) | 5032000 | 1433998 | 3898 | 26000
8.4.2 LSP State Compared with LSP Numbers 8.4.2 LSP State Compared with LSP Numbers
Recall that in Section 8.3, the true benefit of MP2P was analyzed Recall that in Section 8.3, the true benefit of MP2P was analyzed
with respect to the LSP segment state required, rather than the with respect to the LSP segment state required, rather than the
actual number of LSPs. This proved to be a more acurate comparison of actual number of LSPs. This proved to be a more accurate comparison
the techniques because the MP2P LSPs require state on each branch of of the techniques because the MP2P LSPs require state on each branch
the LSP so the saving is not linear with the reduced number of LSPs. of the LSP so the saving is not linear with the reduced number of
LSPs.
A similar analysis could be performed here for the ladder network A similar analysis could be performed here for the ladder network.
and may be added in a future release of this document. The net effect The net effect is that it increases the state by an order of two for
is that it increases the state by an order of two for all transit all transit LSPs in the P2P models, and by a multiplier equal to the
LSPs in the P2P models, and by a multiplier equal to the degree of degree of a node in the MP2P model.
a node in the MP2P model.
A rough estimate shows that, as with snowflake networks, MP2P A rough estimate shows that, as with snowflake networks, MP2P
provides better scaling than the 1-level hierarchical model, and is provides better scaling than the 1-level hierarchical model, and is
considerably better at the core. But P2MP compares less will with the considerably better at the core. But MP2P compares less will with the
2-level hierarchy especially in the core. 2-level hierarchy especially in the core.
8.5 Issues with MP2P LSPs 8.5 Issues with MP2P LSPs
The biggest challenges for MP2P LSPs are the provision of support in The biggest challenges for MP2P LSPs are the provision of support in
the control and data planes. To some extent support must also be the control and data planes. To some extent support must also be
provided in the management plane. provided in the management plane.
Control plane support is just a matter of defining the protocols and Control plane support is just a matter of defining the protocols and
procedures [MP2P-RSVP], although it must be clearly understood that procedures [MP2P-RSVP], although it must be clearly understood that
skipping to change at page 35, line 10 skipping to change at page 35, line 10
solutions within a network. solutions within a network.
Note that if MP2P LSPs are tunneled through P2P FA LSPs across the Note that if MP2P LSPs are tunneled through P2P FA LSPs across the
core, none of the benefit of LSP merging is seen for the hops during core, none of the benefit of LSP merging is seen for the hops during
which the MP2P LSPs are tunneled. which the MP2P LSPs are tunneled.
On the other hand, it is possible to construct solutions where MP2P On the other hand, it is possible to construct solutions where MP2P
FA LSPs are constructed within the network resulting in savings from FA LSPs are constructed within the network resulting in savings from
both modes of operation. both modes of operation.
10. Management Considerations 10. An Alternate Solution
The management issues of the two models presented in this document A simple solution to reducing the number of LSP tunnels handled by
have been discussed in line. Neither solution is without its any node in the network has been proposed. In this solution it is
observed that part of the problem is caused purely by the total
number of LSP in the network, and that this is a function of the
number of PEs since a full mesh of PE-PE LSPs is required. The
conclusion of this observation is to move the tunnel end-points
further into the network so that, instead of having a full mesh of
PE-PE tunnels, we have only a full mesh of P(n)-P(n) tunnels.
Obviously, there is no change in the physical network topology, so
the PEs remain subtended to the P(n) nodes, and the consequence is
that there is no TE on the links between PEs and P(n) nodes.
In this case we have already done the hard work for computing the
number of LSP in the previous sections. The power of the analysis in
the earlier sections is demonstrated by its applicability to this new
model - all we need to do is make minor changes to the formulae. This
is most simply done by removing a layer from the network. We
introduce the term "tunnel end-point" (TEP), and replace the P(n)
nodes with TEPs. Thus, the example of a flat snowflake network in
Figure 3 becomes as shown in Figure 7. Corresponding changes can be
made to all of the sample topologies.
PE PE PE PE PE PE
\ \/ \/ /
PE--TEP TEP TEP TEP--PE
\ | | /
\| |/
PE--TEP---P(1)------P(1)---TEP--PE
/ \ / \
PE \ / PE
\/
P(1)
/|\
/ | \
/ | \
PE--TEP TEP TEP--PE
/ /\ \
PE PE PE PE
Figure 7 : An Example Snowflake Network With Tunnel End-Points
To perform the scaling calculations we need only replace the PE
counts in the formulae with TEP counts, and observe that there is
one fewer layer in the network. For example, in the flat snowflake
network shown in Figure 7 we can see that the number of LSPs seen
at a TEP is:
L(TEP) = 2*(S(TPE) - 1)
In our sample networks S(TPE) is typically of the order of 50 or 100
(the original values of S(2)), so L(TEP) is less than 200 which is
quite manageable.
Similarly, the number of LSPs handled by a P(1) node can be derived
from the original formula for the number of LSPs seen at a P(2) node
since all we have done is reduce n in P(n) from 2 to 1. So our new
formula is:
L(1) = M(1)*(2*S(TEP) - M(1) - 1)
With figures for M(1) = 10 and S(TEP) = 100, this gives us
L(1) = 1890. This is also very manageable.
10.1 Pros and Cons of the Alternate Solution
On the face of it, this alternate solution seems very attractive.
Simply by contracting the edges of the tunnels into the network, we
have shown a dramatic reduction in the number of tunnels needed, and
there is no requirement to apply any additional scaling techniques.
But what of the PE-P(n) links? In the earlier sections of this
document we have assumed that there was some requirement for PE-PE
LSPs with TE properties that extended to the PE-P(n) links at both
ends of each LSP. That means that there was a requirement to provide
reservation-based QoS on those links, to be able to discriminate
traffic flows for priority-based treatment, and to be able to
distinguish applications and sources that send data based on the LSPs
that carry the data.
It might be argued that, since the PE-P(n) links do not offer any
routing options (each such link provides the only access to the
network for a PE), most of the benefits of tunnels are lost on these
peripheral links. However, TE is not just about routing. Just as
important are the abilities to make resource reservations, to
prioritize traffic, and to discriminate between traffic from
different applications, customers, or VPNs.
Furthermore, in multihoming scenarios where each PE is connected to
more than one P(n) or where a PE has multiple links to a single P(n),
there may be a desire to preselect the link to be used and to direct
the traffic to that link using a PE-PE LSP. Note that multihoming
has not been considered in this document.
Operationally, P(n)-P(n) LSPs offer the additional management
overhead that is seen for hierarchical LSPs described in Section 6.
That is, the LSPs have to be configured and established through
additional configuration or management operations that are not
carried out at the PEs. As described in Section 6, automesh [RFC4972]
could be used to ease this task. But it must be noted that, as
mentioned above, some of the key uses of tunnels require that traffic
is classified and placed in an appropriate tunnel according to its
traffic class, end-points, originating application, and customer
(such as client VPN). This information may not be readily available
for each packet at the P(n) nodes since it is PE-based information.
Of course, it is possible to conceive of techniques to make this
information available such as assigning a different label for each
class of traffic, but this gives rise to the original problems of
larger numbers of LSPs.
Our conclusion is, therefore, that this alternate technique may be
suitable for the general distribution of traffic based solely on the
destination, or on a combination of the destination and key fields
carried in the IP header. In this case it can provide a very
satisfactory answer to the scaling issues in an MPLS-TE network. But
if more sophisticated packet classification and discrimination is
required, this technique will make the desired function hard to
achieve, and the trade-off between scaling and feature-level will
swing too far towards solving the scaling issue at the expense of
delivery of function to the customer.
11. Management Considerations
The management issues of the models presented in this document
have been discussed in line. No one solution is without its
management overhead. management overhead.
Note, however, that scalability of management tools is one of the Note, however, that scalability of management tools is one of the
motivators for this work and that network scaling solutions that motivators for this work and that network scaling solutions that
reduce the active management of LSPs at the cost of additional effort reduce the active management of LSPs at the cost of additional effort
to manage the more static elements of the network represent a to manage the more static elements of the network represent a
benefit. That is, it is worth the additional effort to set up MP2P or benefit. That is, it is worth the additional effort to set up MP2P or
FA LSPs if it means that the network can be scaled to a larger size FA LSPs if it means that the network can be scaled to a larger size
without being constrained by the management tools. without being constrained by the management tools.
The MP2P technique may prove harder to debug through OAM methods than The MP2P technique may prove harder to debug through OAM methods than
the FA LSP approach. the FA LSP approach.
11. Security Considerations 12. Security Considerations
The techniques described in this document use existing or The techniques described in this document use existing or
yet-to-be-defined signaling protocol extensions and are subject to yet-to-be-defined signaling protocol extensions and are subject to
the security provided by those extensions. Note that we are talking the security provided by those extensions. Note that we are talking
about tunneling techniques used within the network and both about tunneling techniques used within the network and both
approaches are vulnerable to the creation of bogus tunnels that approaches are vulnerable to the creation of bogus tunnels that
deliver data to an egress or consume network resources. deliver data to an egress or consume network resources.
The fact that the MP2P technique may prove harder to debug through The fact that the MP2P technique may prove harder to debug through
OAM methods than the FA LSP approach is a security concern since it OAM methods than the FA LSP approach is a security concern since it
is important to be able to detect misconnections. is important to be able to detect misconnections.
12. Recommendations 13. Recommendations
The analysis in this document suggests that the ability to signal The analysis in this document suggests that the ability to signal
MP2P MPLS-TE LSPs is a desirable addition to the operator's MPLS-TE MP2P MPLS-TE LSPs is a desirable addition to the operator's MPLS-TE
toolkit. toolkit.
At this stage, no further recommendations are made, but it would be At this stage, no further recommendations are made, but it would be
valuable to consult more widely to discover: valuable to consult more widely to discover:
- The concerns of other service providers with respect to network - The concerns of other service providers with respect to network
scalability. scalability.
skipping to change at page 36, line 14 skipping to change at page 38, line 37
- Desirable values for the cost-effectiveness of the network - Desirable values for the cost-effectiveness of the network
(parameter K) (parameter K)
- The applicability, manageability and support for the two techniques - The applicability, manageability and support for the two techniques
described described
- The feasibility of combining the two techniques as discussed in - The feasibility of combining the two techniques as discussed in
Section 9. Section 9.
13. IANA Considerations - The level of concern over the loss of functionality that would
occur if the alternate solution described in Section 10 was
adopted.
14. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
14. 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 for his comments. review input. Thanks to Ben Niven-Jenkins, JP Vasseur, and Loa
Andersson for their comments.
15. Intellectual Property Consideration 16. Intellectual Property Consideration
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.
skipping to change at page 36, line 47 skipping to change at page 39, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. 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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
16. 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.
17. Informative References 18. Informative References
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
F. and S. Molendini, "RSVP Refresh Overhead and S. Molendini, "RSVP Refresh Overhead Reduction
Reduction Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and B. Thomas, "LDP Specification", RFC 3036, and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
January 2001. Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions (MPLS) Support of Differentiated Services", RFC 3270, May
to RSVP for LSP Tunnels", RFC 3209, December 2001. 2002.
[RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label [RFC3473] Berger, L., et al., Editor, "Generalized Multi-Protocol
Switching (MPLS) Support of Differentiated Label Switching (GMPLS) Signaling Resource ReserVation
Services", RFC 3270, May 2002. Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3473] Berger, L., et al., Editor, "Generalized Multi- [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to-
Protocol Label Switching (GMPLS) Signaling Resource Edge (PWE3) Architecture", RFC 3985, March 2005.
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 3473, January 2003.
[RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation [RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute
Edge-to-Edge (PWE3) Architecture", RFC 3985, March Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005. 2005.
[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", work
in progress.
[RFC4110] Callon, R., and Suzuki, M., "A Framework for Layer 3 [RFC4110] Callon, R., and Suzuki, M., "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks Provider-Provisioned Virtual Private Networks (PPVPNs)",
(PPVPNs)", RFC 4110, July 2005. RFC 4110, July 2005.
[RFC4972] Vasseur, JP., and Le Roux, JL., "Routing Extensions [RFC4972] Vasseur, JP., and Le Roux, JL., "Routing Extensions for
for Discovery of Multiprotocol (MPLS) Label Switch Discovery of Multiprotocol (MPLS) Label Switch Router
Router (LSR) Traffic Engineering (TE) Mesh (LSR) Traffic Engineering (TE) Mesh Membership",
Membership", RFC 4972, July 2007. RFC 4972, July 2007.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 5036, October 2007.
[MP2P-RSVP] Yasukawa, Y., "Supporting Multipoint-to-Point Label [MP2P-RSVP] Yasukawa, Y., "Supporting Multipoint-to-Point Label
Switched Paths in Multiprotocol Label Switching Switched Paths in Multiprotocol Label Switching Traffic
Traffic Engineering", Engineering", draft-yasukawa-mpls-mp2p-rsvpte, work in
draft-yasukawa-mpls-mp2p-rsvpte, work in progress. progress.
18. Authors' Addresses 19. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769 Phone: +81 422 59 4769
EMail: s.yasukawa@hco.ntt.co.jp EMail: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
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: okomolaf@cisco.com EMail: femi@cisco.com
19. Disclaimer of Validity 20. Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
20. Full Copyright Statement 21. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 64 change blocks. 
130 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/