--- 1/draft-ietf-mpls-te-scaling-analysis-01.txt 2008-04-24 13:12:16.000000000 +0200 +++ 2/draft-ietf-mpls-te-scaling-analysis-02.txt 2008-04-24 13:12:16.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group S. Yasukawa Internet-Draft NTT Intended Status: Informational A. Farrel -Created: October 13, 2007 Old Dog Consulting -Expires: April 13, 2008 O. Komolafe +Created: April 24, 2008 Old Dog Consulting +Expires: October 24, 2008 O. Komolafe 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 By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -28,100 +28,101 @@ The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Traffic engineered Multiprotocol Label Switching (MPLS-TE) is - deployed in providers' backbone networks. As providers plan to grow - these networks, they need to discover whether existing protocols and + deployed in providers' core networks. As providers plan to grow these + networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns - for MPLS-TE backbone networks, and examines the value of two - techniques for improving scaling. The intention is to motivate the - development of appropriate deployment techniques and protocol - extensions to enable the application of MPLS-TE in large networks. + for MPLS-TE core networks, and examines the value of two techniques + (LSP hierarchies, and multipoint-to-point LSPs) for improving + scaling. The intention is to motivate the development of appropriate + deployment techniques and protocol extensions to enable the + application of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. Contents 1. Introduction .................................................. 3 1.1 Overview ..................................................... 3 1.2 Glossary of Notation ......................................... 4 2. Issues of Concern for Scaling ................................. 5 2.1 LSP State ................................................... 5 2.2 Processing Overhead .......................................... 5 - 2.3 RSVP-TE Implications ......................................... 5 - 2.4 Management ................................................... 6 + 2.3 RSVP-TE Implications ......................................... 6 + 2.4 Management ................................................... 7 3. Network Topologies ............................................ 7 - 3.1 The Snowflake Network Topology ............................... 7 - 3.2 The Ladder Network Topology .................................. 9 + 3.1 The Snowflake Network Topology ............................... 8 + 3.2 The Ladder Network Topology .................................. 10 3.3 Commercial Drivers for Selected Configurations ............... 12 3.4 Other Network Topologies ..................................... 13 4. Required Network Sizes ........................................ 13 4.1 Practical Numbers ............................................ 14 5. Scaling in Flat Networks ...................................... 14 5.1 Snowflake Networks ........................................... 14 5.2 Ladder Networks .............................................. 16 6. Scaling Snowflake Networks with Forwarding Adjacencies ........ 19 6.1 Two Layer Hierarchy .......................................... 19 6.1.1 Tuning the Network Topology to Suit the Two Layer Hierarchy 20 6.2 Alternative Two Layer Hierarchy .............................. 21 6.3 Three Layer Hierarchy ........................................ 22 6.4 Issues with Hierarchical LSPs ............................... 23 7. Scaling Ladder Networks with Forwarding Adjacencies............ 24 7.1 Two Layer Hierarchy .......................................... 24 7.2 Three Layer Hierarchy ........................................ 25 7.3 Issues with Hierarchical LSPs ................................ 26 8. Scaling Improvements Through Multipoint-to-Point LSPs ......... 26 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.1 Comparison with Other Scenarios ............................ 30 8.4 Scaling Improvements for Ladder Networks ..................... 31 8.4.1 Comparison with Other Scenarios ............................ 32 8.4.2 LSP State Compared with LSP Numbers ........................ 33 8.5 Issues with MP2P LSPs ........................................ 33 9. Combined Models ............................................... 34 - 10. Management Considerations .................................... 35 - 11. Security Considerations ...................................... 35 - 12. Recommendations .............................................. 35 - 13. IANA Considerations .......................................... 36 - 14. Acknowledgements ............................................. 36 - 15. Intellectual Property Consideration .......................... 36 - 16. Normative References ......................................... 36 - 17. Informative References ....................................... 37 - 18. Authors' Addresses ........................................... 38 - 19. Disclaimer of Validity ....................................... 38 - 20. Full Copyright Statement ..................................... 38 + 10. An Alternate Solution ........................................ 35 + 10.1 Pros and Cons of the Alternate Solution ..................... 36 + 11. Management Considerations .................................... 37 + 12. Security Considerations ...................................... 37 + 13. Recommendations .............................................. 38 + 14. IANA Considerations .......................................... 38 + 15. Acknowledgements ............................................. 38 + 16. Intellectual Property Consideration .......................... 39 + 17. Normative References ......................................... 39 + 18. Informative References ....................................... 39 + 19. Authors' Addresses ........................................... 40 1. Introduction Network operators and service providers are examining scaling issues as they look to deploy ever-larger traffic engineered Multiprotocol Label Switching (MPLS-TE) networks. Concerns have been raised about the number of Label Switched Paths (LSPs) that need to be supported at the edge and at the core of the network. The impact on control plane and management plane resources threatens to outweigh the benefits and popularity of MPLS-TE, while the physical limitations of the routers may constrain the deployment options. Historically, it has been assumed that all MPLS-TE scaling issues can be addressed using hierarchical LSP [RFC4206]. However, analysis shows that the improvement gained by LSP hierarchies is not as - significant as might have been presumed in all topologies and at all - points in the network. Further, additional management issues are + significant in all topologies and at all points in the network as + might have been presumed. Further, additional management issues are introduced to determine the end-points of the hierarchical LSPs and to operate them. Although this does not invalidate the benefits of LSP hierarchies, it does indicate that additional techniques may be desirable in order to fully scale MPLS-TE networks. This document examines the scaling properties of two generic MPLS-TE network topologies, and investigates the benefits of two scaling techniques. 1.1 Overview @@ -131,32 +132,32 @@ 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 tree-shaped edges. MPLS-TE, however, establishes a logical full mesh between all edge 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 LSPs within the core of the network. 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 scaling parameters and examines how many LSPs might be required to be 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 they offer as well as of some of the concerns with using these techniques. - Of necessity, this document makes many generalizations. Not - least among these are a set of assumptions about the symmetry and + Of necessity, this document makes many generalizations. Not least + among these are a set of assumptions about the symmetry and connectivity of the physical network. It is hoped that these generalizations will not impinge on the usefulness of the overview of the scaling properties that this document attempts to give. Indeed, the symmetry of the example topologies tends to highlight the scaling issues of the different solution models, and this may be useful in exposing the worst case scenarios. Although protection mechanisms like Fast Re-route (FRR) [RFC4090] are briefly discussed, the main body of this document considers stable network cases. It should be noted that make-before-break @@ -167,25 +168,25 @@ separate traffic engineered LSPs are used to provide different services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or different classes of service [RFC3270], may result in 'duplicate' or 'parallel' LSPs running between any pair of provider edge nodes (PEs). This scaling factor is also not considered in this document, but may be easily applied as a linear factor by the reader. The intention of this document is to help service providers discover whether existing protocols and implementations can support the network sizes that they are planning. To do this, it presents an - analysis of some of the scaling concerns for MPLS-TE backbone - networks, and examines the value of two techniques for improving - scaling. This should motivate the development of appropriate - deployment techniques and protocol extensions to enable the - application of MPLS-TE in large networks. + analysis of some of the scaling concerns for MPLS-TE core networks, + and examines the value of two techniques for improving scaling. This + should motivate the development of appropriate deployment techniques + and protocol extensions to enable the application of MPLS-TE in large + networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. 1.2 Glossary of Notation This document applies consistent notation to define various parameters of the networks that are analyzed. These terms are defined as they are introduced though-out the document, but are grouped together here for quick reference. Refer to the full definitions in @@ -208,44 +209,53 @@ This section presents some of the issues associated with the support of LSPs at an LSR or within the network. These issues may mean that there is a limit to the number LSPs that can be supported. 2.1 LSP State LSP state is the data (information) that must be stored at an LSR in order to maintain an LSP. Here we refer to the information that is necessary to maintain forwarding plane state and the additional information required when LSPs are established through control - plane protocols. While the size of the LSP state is - implementation-dependent, it is clear that any implementation will - require some data in order to maintain LSP state. + plane protocols. While the size of the LSP state is implementation- + dependent, it is clear that any implementation will require some data + in order to maintain LSP state. Thus LSP state becomes a scaling concern because as the number of LSPs at an LSR increases, so the amount of memory required to maintain the LSPs increases in direct proportion. Since the memory capacity of an LSR is limited, there is a related limit placed on the number LSPs that can be supported. Note that techniques to reduce the memory requirements (such as data compression) may serve to increase the number of LSPs that can be supported, but this will only achieve a moderate multiplier and may 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 Depending largely on implementation issues, the number of LSPs - supported by an LSR may impact the processing speed for each LSP. For - example, control block search times can increase with the number of - control blocks, and even excellent implementations cannot completely - mitigate this fact. Thus, since CPU power is constrained in any LSR, - there may be a practical limit to the number of LSPs that can be - supported. + passing through an LSR may impact the processing speed for each LSP. + For example, control block search times can increase with the number + of control blocks to be searched, and even excellent implementations + cannot completely mitigate this fact. Thus, since CPU power is + constrained in any LSR, there may be a practical limit to the number + of LSPs that can be supported. Further processing overhead considerations depend on issues specific to the control plane protocols, and are discussed in the next section. 2.3 RSVP-TE Implications Like many connection-oriented signaling protocols, RSVP-TE requires 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 @@ -267,39 +277,40 @@ in a stable network. Observations of existing implementations indicate that there may be a threshold of around 50,000 LSPs above which an LSR struggles to achieve sufficient processing to maintain LSP state. Although refresh reduction [RFC2961] may substantially improve this situation, it has also been observed that under these circumstances the size of the Srefresh may become very large and the processing required may 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 improvement in performance for the LSR. However, it should be noted that RSVP-TE's soft-state nature depends on regular refresh messages, 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 Hello message, and can also be reduced by the use of various GMPLS extensions [RFC3473] such as the use of [RFC2961] message acknowledgements on all messages. RSVP-TE also requires that signaling adjacencies are maintained through the use of Hello message exchanges. Although [RFC3209] suggests that Hello messages should be retransmitted every 5ms, in practice values of around 3 seconds are more common. Nevertheless, the support of Hello messages can represent a scaling limitation on an RSVP-TE implementation since one message must be sent and received to/from each signaling adjacency every time period. This can impose 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 Another practical concern for the scalability of large MPLS-TE networks is the ability to manage the network. This may be constrained by the available tools, the practicality of managing large numbers of LSPs, and the management protocols in use. Management tools are software implementations. Although such implementations should not constrain the control plane protocols, it @@ -339,21 +350,21 @@ 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 form of a ladder and trees are attached rooted to the edge of the ladder. The sections that follow examine these topologies in detail in order to parameterize them. 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 connectivity to P-nodes as shown in Figure 1. There is no direct connectivity between the PEs. Dual homing of PEs to multiple P nodes is not considered in this document although it may be a valuable addition to a network configuration. P /|\ / | \ / | \ @@ -379,32 +390,34 @@ / | \ / | \ P(n+1) P(n+1) P(n+1) Figure 2 : Relationship Between P-Nodes 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 connected than this, but assuming a full mesh provides for 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 multiplier relationship between P(n) and P(n+1) at each level including down to PEs. 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 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 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). Thus: S(n) = S(1)*M(1)*M(2)*...*M(n-1) So the number of PEs can be expressed as: S(PE) = S(1)*M(1)*M(2)*...*M(n) where the network has (n) layers of P-nodes. @@ -443,40 +456,38 @@ Ladder networks typically have long and thin cores that are arranged as conventional ladders. That is, they have one or more spars connected by rungs. Each node on a spar may have: - connection to one or more other spars - connection to a tree of other core nodes - connection to customer nodes. 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 - nodes on the spars are themselves PEs, while the rest have PEs - subtended. + twelve nodes make up two spars connected by six rungs. PE PE PE PE - PE PE PE | PE | PE PE | PE | PE - \| \|/ |/ \| \|/ - PE-P-----P-----P-----PE-----P-----P--PE + PE PE PE | PE | PE PE PE | PE | PE + \| \|/ |/ | \| \|/ + PE-P-----P-----P-----P------P-----P--PE | | | | | |\ | | | | | | PE | | | | | | - PE-P-----P-----P-----P------P-----PE - /| /|\ |\ |\ |\ - PE PE PE | PE | PE | PE | PE + PE-P-----P-----P-----P------P-----P + /| /|\ |\ |\ |\ \ + PE PE PE | PE | PE | PE | PE PE PE PE PE PE Figure 4 : A Simplified Ladder Network. 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 another spar. Similarly, the connectivity between spars can be more complex with multiple connections from one spar-node to another spar. Lastly, the network may be complicated by the inclusion of more than two spars (or simplified by reduction to a single spar). These variables make the ladder network non-trivial to model. For the sake of simplicity we will make the following restrictions: - There are precisely two spars in the core network. @@ -607,29 +618,29 @@ and generalized network topologies for simplicity of modelling. In practice there are two other topological considerations. a. Multihoming 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 PEs that may be connected to more than one P(n). b. Meshing within a level 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 - series of concentric circles with spokes. + the same level including the possibility of links between PEs. + 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 of the networks. However, for the purposes of establishing the ground-rules for scaling, this document restricts itself to the - consideration of the symmetrical network described in Sections 2.1 - and 2.2. Discussion of other network formats may be introduced in a - future revision of this document. + consideration of the symmetrical networks described in Sections 2.1 + and 2.2. Discussion of other network formats is for future study. 4. Required Network Sizes An important question for this evaluation and analysis is the size of 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 physical connectivity? What type of MPLS-TE connectivity between PEs is required? Although presentation of figures for desired network sizes must be @@ -685,21 +696,21 @@ incoming into a particular PE. 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), the correct value is: L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1) = M(2)*(2*S(PE) - M(2) - 1) 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 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 between the locally subtended PEs. So: L(2) = 2*M(2)*(S(PE) - M(2)) + M(2)*(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(2). Each PE subtended below a P(1) node has an LSP in each @@ -760,21 +771,21 @@ seen from the snowflake network. They are: o E*(E-1) o M(1)*M(2)*(M(2)-1) = E*(M(2) - 1) o 2*E*E*(S(1) - 1) The number of LSPs in transit is more complicated to compute. It is simplified by not considering the ends of the ladders, but examining 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 - 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). : : : : : : : : : : : : P(2) P(2) P(2) P(2) P(2) P(2) \ | \ / | / \ | \ / | / \| \/ |/ ......P(1)---P(1)---P(1)...... | a | | @@ -911,21 +922,21 @@ 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. It remains the case that: L(PE) = 2*(S(PE) - 1) 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 - 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. Since the number of P(2) nodes is S(2), each P(2) node sees 2*(S(2) - 1) FA LSPs. Thus: 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 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 LSPs between attached P(2) nodes. In fact, the problem is identical @@ -1132,21 +1143,21 @@ 7. Scaling Ladder Networks with Forwarding Adjacencies 7.1 Two Layer Hierarchy 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 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 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. - 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. The number of LSPs seen by a P(1) node is then: o all of the tunnels terminating at the P(1) node o any transit tunnels o all of the LSPs due to subtended PEs. 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: @@ -1248,21 +1259,21 @@ this case is achieved by reducing the number of LSPs toward the destination as LSPs toward the same destination are merged. This section presents an overview of MP2P LSPs and describes their applicability and scaling benefits. 8.1 Overview of MP2P LSPs Note that the MP2P LSPs discussed here are for MPLS-TE and are not 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 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 pairs {incoming interface, incoming label} are mapped to a single pair {outgoing interface, outgoing label}. Obviously, if per-platform labels are used, this mapping may be optimized within an implementation. It is important to note that with MP2P MPLS-TE LSPs the traffic flows @@ -1345,21 +1356,21 @@ 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 LSP targeted at each downstream PE with one downstream segment (to 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 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 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 (M(2) + 1)*(S(PE) - M(2)) LSP segments. Thus: X(2) = M(2)*(1 + M(2)) + (M(2) + 1)*(S(PE) - M(2)) = S(PE)*(M(2) + 1) 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 @@ -1510,24 +1521,24 @@ Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see: E = 200 S(PE) = 2000 X(PE) = 3998 X(2) = 42000 X(1) <= 26000 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 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 for the example ladder networks. Note that the previous figures are modified to provide counts of LSP state rather than LSP numbers. Again, each LSP contributes one state at its end points, and two states at transit nodes. Thus, for the all cases we have X(PE) = 2*(S(PE) - 1) or @@ -1556,33 +1567,33 @@ A | X(2) | 68748 | 68748 | 68866 | 18360 | X(1) | 1554820 | 572266 | 2226 | 12580 -------+-------+------------+------------+-------------+------- B | X(2) | 159160 | 159160 | 159358 | 42000 | X(1) | 5032000 | 1433998 | 3898 | 26000 8.4.2 LSP State Compared with LSP Numbers Recall that in Section 8.3, the true benefit of MP2P was analyzed with respect to the LSP segment state required, rather than the - actual number of LSPs. This proved to be a more acurate comparison of - the techniques because the MP2P LSPs require state on each branch of - the LSP so the saving is not linear with the reduced number of LSPs. + actual number of LSPs. This proved to be a more accurate comparison + of the techniques because the MP2P LSPs require state on each branch + 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 - and may be added in a future release of this document. The net effect - is that it increases the state by an order of two for all transit - LSPs in the P2P models, and by a multiplier equal to the degree of - a node in the MP2P model. + A similar analysis could be performed here for the ladder network. + The net effect is that it increases the state by an order of two for + all transit LSPs in the P2P models, and by a multiplier equal to the + degree of a node in the MP2P model. A rough estimate shows that, as with snowflake networks, MP2P 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. 8.5 Issues with MP2P LSPs The biggest challenges for MP2P LSPs are the provision of support in the control and data planes. To some extent support must also be provided in the management plane. Control plane support is just a matter of defining the protocols and procedures [MP2P-RSVP], although it must be clearly understood that @@ -1646,51 +1657,173 @@ solutions within a network. 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 which the MP2P LSPs are tunneled. On the other hand, it is possible to construct solutions where MP2P FA LSPs are constructed within the network resulting in savings from both modes of operation. -10. Management Considerations +10. An Alternate Solution - The management issues of the two models presented in this document - have been discussed in line. Neither solution is without its + A simple solution to reducing the number of LSP tunnels handled by + 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. Note, however, that scalability of management tools is one of the motivators for this work and that network scaling solutions that reduce the active management of LSPs at the cost of additional effort 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 FA LSPs if it means that the network can be scaled to a larger size without being constrained by the management tools. The MP2P technique may prove harder to debug through OAM methods than the FA LSP approach. -11. Security Considerations +12. Security Considerations The techniques described in this document use existing or yet-to-be-defined signaling protocol extensions and are subject to the security provided by those extensions. Note that we are talking about tunneling techniques used within the network and both approaches are vulnerable to the creation of bogus tunnels that deliver data to an egress or consume network resources. 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 is important to be able to detect misconnections. -12. Recommendations +13. Recommendations 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 toolkit. At this stage, no further recommendations are made, but it would be valuable to consult more widely to discover: - The concerns of other service providers with respect to network scalability. @@ -1700,30 +1833,35 @@ - Desirable values for the cost-effectiveness of the network (parameter K) - The applicability, manageability and support for the two techniques described - The feasibility of combining the two techniques as discussed in 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. -14. Acknowledgements +15. Acknowledgements 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 Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -1733,100 +1871,98 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -16. Normative References +17. Normative References [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. -17. Informative References +18. Informative References - [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, - F. and S. Molendini, "RSVP Refresh Overhead - Reduction Extensions", RFC 2961, April 2001. + [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., + and S. Molendini, "RSVP Refresh Overhead Reduction + Extensions", RFC 2961, April 2001. - [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. - and B. Thomas, "LDP Specification", RFC 3036, - January 2001. + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., - Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions - to RSVP for LSP Tunnels", RFC 3209, December 2001. + [RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching + (MPLS) Support of Differentiated Services", RFC 3270, May + 2002. - [RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label - Switching (MPLS) Support of Differentiated - Services", RFC 3270, May 2002. + [RFC3473] Berger, L., et al., Editor, "Generalized Multi-Protocol + Label Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, January 2003. - [RFC3473] Berger, L., et al., Editor, "Generalized Multi- - Protocol Label Switching (GMPLS) Signaling Resource - ReserVation Protocol-Traffic Engineering (RSVP-TE) - Extensions", RFC 3473, January 2003. + [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- + Edge (PWE3) Architecture", RFC 3985, March 2005. - [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation - Edge-to-Edge (PWE3) Architecture", RFC 3985, March + [RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 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 - Provider-Provisioned Virtual Private Networks - (PPVPNs)", RFC 4110, July 2005. + Provider-Provisioned Virtual Private Networks (PPVPNs)", + RFC 4110, July 2005. - [RFC4972] Vasseur, JP., and Le Roux, JL., "Routing Extensions - for Discovery of Multiprotocol (MPLS) Label Switch - Router (LSR) Traffic Engineering (TE) Mesh - Membership", RFC 4972, July 2007. + [RFC4972] Vasseur, JP., and Le Roux, JL., "Routing Extensions for + Discovery of Multiprotocol (MPLS) Label Switch Router + (LSR) Traffic Engineering (TE) Mesh Membership", + 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 - Switched Paths in Multiprotocol Label Switching - Traffic Engineering", - draft-yasukawa-mpls-mp2p-rsvpte, work in progress. + Switched Paths in Multiprotocol Label Switching Traffic + Engineering", draft-yasukawa-mpls-mp2p-rsvpte, work in + progress. -18. Authors' Addresses +19. Authors' Addresses Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: s.yasukawa@hco.ntt.co.jp Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Olufemi Komolafe Cisco Systems 96 Commercial Street Edinburgh EH6 6LX 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -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 contained in BCP 78, and except as set forth therein, the authors retain all their rights.