1 / 12

An analysis of scaling issues in MPLS-TE backbone networks

An analysis of scaling issues in MPLS-TE backbone networks. Seisho Yasukawa, Adrian Farrel, and Olufemi Komolafe draft-yasukawa-mpls-scaling-analysis-04.txt. Introduction. Motivated by concerns about potentially excessive number of LSPs in MPLS-TE networks PE-PE LSPs required in a full mesh

seoras
Download Presentation

An analysis of scaling issues in MPLS-TE backbone networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An analysis of scaling issues in MPLS-TE backbone networks Seisho Yasukawa, Adrian Farrel, and Olufemi Komolafe draft-yasukawa-mpls-scaling-analysis-04.txt 69th IETF Chicago July 2007

  2. Introduction • Motivated by concerns about potentially excessive number of LSPs in MPLS-TE networks • PE-PE LSPs required in a full mesh • Multiple ‘parallel’ LSPs for service differentiation • How many LSPs can a core P-node support? • The old n-squared problem re-surfaces • Simple math…1000 PEs means up to 999000 LSPs in the core (per service type) • Important issue because number of LSPs supported by LSR constrained by factors such as • Amount of LSP state • Processing overhead • RSVP-TE overhead • Management complexity • Open questions include • Does use of hierarchical LSPs solve problem? • Are there other solutions? 69th IETF Chicago July 2007

  3. Progress • Last discussed in Dallas (March 2006) • Updates • Added discussion of “ladder topology” • New author: Femi from Glasgow University • Checked (and corrected) the math • Revised to clarify the problem and objectives 69th IETF Chicago July 2007

  4. Approach • Use exemplar topologies to give insight into potential MPLS-TE scaling issues • Exemplar topologies • Have characteristics similar to real networks • e.g. tree-like at edges, mesh-like in core • Have well-defined connectivity and symmetry • Amenable to mathematical analysis • Exemplar topologies considered in draft • Snowflake topology • Ladder network topology 69th IETF Chicago July 2007

  5. Exemplar Snowflake Network • Meshed core of P(1) nodes • P(n+1) nodes connected to P(n) nodes • PE nodes connected to P nodes • Well-defined connectivity and symmetry allows many important metrics to be computed • Number of levels & number of nodes per level may be varied PE P(2) P(1) 69th IETF Chicago July 2007

  6. Exemplar Ladder Network • Core of P(1) nodes looks like a ladder • Symmetrical trees subtended to core • P(n+1) nodes connected to P(n) nodes • PE nodes connected to P nodes • Well-defined connectivity and symmetry allows many important metrics to be computed • Number of levels & number of nodes per level may be varied P(1) P(2) PE 69th IETF Chicago July 2007

  7. Method • Using Snowflake & Ladder network, can study MPLS-TE scaling, considering • Flat networks • Forwarding adjacencies (hierarchical LSPs) • MP2P LSPs • Interesting metrics include • Number of PEs • Number of LSPs traversing different LSRs • Amount of LSP state at any LSR • Ratio of PE to P LSRs (cost-effectiveness) 69th IETF Chicago July 2007

  8. What are the Scaling Limitations? • Number of labels on a link • Signaling state on an LSR • Simple constraint on memory usage • Signaling processing • Searching control blocks • RSVP-TE soft state (even with refresh reduction) • RSVP-TE Hellos • Management • How many LSPs can the EMS/NMS handle • Monitoring • What management protocol load can the network support? • Status and statistics 69th IETF Chicago July 2007

  9. Normal Suggestion - Hierarchy • Hierarchical LSPs scale well, but: • Not as well as you might think • Obviously no benefit from core tunnels • PE-PE tunnels don’t help n-squared problem • Multiple layers of hierarchy needed to make full impact • Tunnel end-points see increase in state • Adds a significant management overhead • All tunnel end-points have to be planned • All tunnels have to be provisioned • Auto-mesh can help • Other issues: • OAM for PE-PE LSPs is degraded • Loss of information inside the tunnel • LSP aggregation reduces PE-PE TE possibilities • TE bandwidth granularity is reduced 69th IETF Chicago July 2007

  10. A Scaling Alternative – MP2P LSPs • LSPs “merge” automatically • Reduces number of LSPs towards the egress • Bandwidth has to be increased on downstream legs 69th IETF Chicago July 2007

  11. Savings and Issues with MP2P • MP2P LSPs give: • Good scaling of LSP numbers near egress • No benefit near ingress • Particularly good on ladder topologies • LSP numbers is not everything! • LSP state scales slightly less well • Traffic disambiguation may be needed • Same issue as LDP – what is the source? • New functional controls needed • Control of merging lies with the ingress or the egress? • Management of explicit routes • Resource sharing or resource increments? • New protocol extensions needed • To control the function above • For OAM 69th IETF Chicago July 2007

  12. Next Steps • Close off this I-D with a little more polish • Progress to RFC as individual submission • Will (presumably) attract MPLS WG review in last call • Persuade community that the problem is real • Encourage implementers to develop solutions • MP2P first proposal in draft-yasukawa-mpls-mp2p-rsvpte-02.txt • Happy to see any solution 69th IETF Chicago July 2007

More Related