69th IETF Chicago July 2007

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

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

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

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

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

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

PE

P(2)

P(1)

69th IETF Chicago July 2007

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

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

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

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

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

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