1 / 77

MPLS Traffic Engineering -SESSION B- MPLS BOOTCAMP Mosaddaq Turabi - mturabi@cisco

MPLS Traffic Engineering -SESSION B- MPLS BOOTCAMP Mosaddaq Turabi - mturabi@cisco.com. RSVP/TE SCALING. 2. © 1999, Cisco Systems, Inc. . RSVP/TE and Scalability. Very Different Than IntServ Context.

memphis
Download Presentation

MPLS Traffic Engineering -SESSION B- MPLS BOOTCAMP Mosaddaq Turabi - mturabi@cisco

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. MPLS Traffic Engineering-SESSION B-MPLS BOOTCAMPMosaddaq Turabi - mturabi@cisco.com

  2. RSVP/TE SCALING 2 © 1999, Cisco Systems, Inc.

  3. RSVP/TE and Scalability Very Different Than IntServ Context • State applies to a collection of flows (i.e. a traffic trunk), rather than to a single (micro) flow • RSVP sessions are used between routers, not hosts • Sessions are long-lived (up to a few weeks) • Paths are not bound by destination-based routing • Reference: ‘Applicability Statement for Extensions to RSVP for LSP-Tunnels’ (draft-awduche-mpls-rsvp-tunnel-applicability-01.txt)

  4. RSVP/TE and Scalability Very Different Than IntServ Context • RFC2208: “the resource requirements for running RSVP on a router increases proportionally with the number of separate sessions” • TE: that is why using traffic trunks to aggregate flows is essential • RFC2208: “supporting numerous small reservations on a high-bandwidth link may easily overtax the routers and is inadvisable” • TE : n/a in the context of TE - traffic trunks aggregate multiple flows

  5. TE/RSVP Scalability • With basic RSVP (RFC2205), 10000 TE LSP tunnels flowing through a 75x0 or 12000 is not a problem • Could be used in tiered approach - Core & Regions • Already deployed on a number of Tier-1 ISP backbones

  6. Some Design Considerations - CURRENT SINGLE AREA/LEVEL SUPPORT - FUTURE SUPPORT FOR MULTI AREA/LEVEL - NOT ALL THE ROUTERS TO BE THE HEAD-END OR TAIL-END - NEED FOR MPLS-TE WITHIN A POP?

  7. DEPLOYMENT STRATEGIES 7 © 1999, Cisco Systems, Inc.

  8. Deployment strategy Two strategies to TE deployment • Full mesh of TE tunnels • “proper” - more complex procedure, but more benefits overall • Emergency Routing tool for congestion management • “hack” - may be harder to track over time

  9. Generic Issues • The geographical scope of the MPLS system • Administrative constraint • A region with tight resource or with many links of asymetric bw’s should be included • The participating routers • hardware/software constraint • The hierarchy of the MPLS system • single layer (full mesh) • 2-layer hierarchy (full mesh in regions, full mesh between regions)

  10. Generic Issues • The bandwidth requirement of the LSPs • Traffic Matrix based on TE counters • The path attribute of the LSPs • Off-line vs Online CBR, usually on-line • Policy Affinity • The priority of the LSPs • larger trunks should have better priority • better resource utilization

  11. Generic Issues • The adaptability of the LSPs • not too often (not below the hour) • Resiliency of the LSPs • second path option (less demanding) • fast re-route, link protection • Tunnel BW is not policed

  12. Full Mesh Source: X. Xiao, GlobalCenter Inc. a Global Crossing CompanyIEEE network, March/April 2000 Source: 12 © 1999, Cisco Systems, Inc.

  13. Deployment Strategy • 0. Select a noncritical area first • 1. Initial collection of a Traffic Matrix • TMS • full-mesh of 0-kbps LSPs • 2. Adjust BW constraint • 95% percentile • Tackling Interface Congestion • under-subscribe a link (ip rsvp ban 100000 on an OC3) • inflate the LSPs • Trade-off: congestion avoidance vs link efficiency • WANDL can make sure all LSPs will be routed • Emergency: manually redirect traffic with explicit routes

  14. Deployment Strategy • 3. Periodic update of the LSPs bandwidth • daily, weekly (cron job) • avoid changing bw requirements of all LSPs at the same time • 4. Offline CBR • optimize the LSP placement: BW*routing metric • let the largest LSP take the best path • one by one, starting with highest priority LSPs, and according to BW demands for same priority • offline path configured as first path option

  15. Hierarchical Full-Mesh

  16. GlobalFrontierIEEE Network March/April2000 • MPLS Net: 200 nodes: DS3 to OC48 • 9 regions • full-mesh per region • 10 to 50 nodes per region • 100 to 2500 LSPs per region • Core Mesh • 2500 LSP’s

  17. Emergency Routing Tool for Congestion Management Source: X. Xiao, GlobalCenter Inc. a Global Crossing CompanyIEEE network, March/April 2000 Source: 17 © 1999, Cisco Systems, Inc.

  18. Deployment strategy As needed to clear up congestion 1) enable CEF everywhere 2) config your IGP, RSVP 3) configure TE tunnels around congested links - one IGP tunnel, one or more explicit-path tunnels

  19. Deployment strategy As needed to clear up congestion 4) turn up tunnels one at a time via ‘autoroute announce’ 5) add BW requirements to tunnels Tunnel BW ratio is important.

  20. MPLS TE and VPN Source: 20 © 1999, Cisco Systems, Inc.

  21. T3 T2 T1 I1 I2 I2 I2 I2 B B B B B B MPLS TE and VPN P P The directed LDP session between the head-end and tail-end provides the head-end with the appropriate label binding information for the BGP next-hop (I2 in this example) P P P P Directed LDP session PE PE CE CE

  22. Path Protection 22 © 1999, Cisco Systems, Inc.

  23. Path Protection • Step1: link failure detection • O(depends on L2/L1) • Step2a: IGP reaction (ISIS case) • Either via Step1 or via IGP hello expiration (30s by default for ISIS) • 5s (default) must occur by default before the generation of a new LSP • 5.5s (default) must occur before a change of the LSPDB and the consecutive SPF run. The next SPF run can only occur 10s after (default) • Flooding time (LSP are paced (16ms for first LSP, 33ms between LSPs, depend also on link speed) • Once the RIB is updated, this change must be incorporated into CEF • The head-end finally computes the new topology and finds out that some established LSPs are affected; it schedules a re-optimisation for them

  24. Path Protection • Step2b: RSVP signalization • rsvp path states with the failed intf and send tear to head-end • Step2: Either stepA or stepB alarms the head-end • Step3: Re-optimization • dijkstra computation: O(0.5)ms per node (rule of thumb) • RSVP signalisation time to instal re-routed tunnel • convergence in the order of several seconds (at least).

  25. Path ProtectionSpeed it Up • Fine Tune the IGP convergence • through adequate tuning, ISIS could be tuned to converge in 2-3s, thus ensuring that the convergence time bottleneck is the signalisation time for the new tunnel. • Several tunnels in parallel with load-balancing • if combined with the IGP convergence, the path resilience could be brought to around 2-3s • One end-2-end tunnel in parallel but in backup mode • feature under development (Fast Path Protection)

  26. Fast Re-Route(aka Link Protection)An Overview 26 © 1999, Cisco Systems, Inc.

  27. Objective • FRR allows for temporarily routing around a failed link or node while the head-end may re-optimize the entire LSP • re-routing under 50ms • scalable (must support lots of LSPs)

  28. Fast Reroute Overview • Controlled by the routers at ends of a failed link • link protection is configured on a per link basis • Session_Attribute’s Flag 0x01 allows the use of Link Protection for the signalled LSP • Uses nested LSPs (stack of labels) • original LSP nested within link protection LSP

  29. Static Backup Tunnel R9 R8 R4 R2 R5 R1 Pop R6 R7 17 22 Setup: Path (R2->R6->R7->R4) Labels Established on Resv message

  30. Routing Prior R2-R4 Link Failure R9 R8 R4 R2 Pop R5 R1 14 37 R7 R6 Setup: Path (R1->R2->R4->R9) Labels Established on Resv message

  31. Link Protection Active R9 R8 R4 R2 R5 R1 R7 R6 On failure of link from R2 -> R4, R2 simply changes outgoing Label Stack from 14 to <17, 14>

  32. Link Protection Active R9 R8 Pop 14 Swap 37->14 Push 17 R4 R2 Push 37 R5 R1 R7 R6 Swap 17->22 Pop22 Label Stack: R1 R2 R6 R7 R4 R9 37 17 22 14 None 14 14

  33. Fast Re-RouteMore Details on Link Protection (FRR v1) 33 © 1999, Cisco Systems, Inc.

  34. V1 Constrain • We protect the facility (link), not individual LSPs • scalability vs granularity • No node resilience • Static backup tunnel • The protected link must use the global label space • A backup tunnel can backup at most one link, but n LSPs travelling via this link

  35. Terminology R9 R8 R4 R2 • LSP: end-to-end tunnel onto which data normally flows (eg R1 to R9) R5 R1 R7 R6 • BackUp tunnel: temporary route to take in the event of a failure

  36. Terminology • Link Protection • In the event of a link failure, an LSP is re-routed to the next-hop using a pre-configured backup tunnel

  37. How to indicate a link is protected and which tunnel is the backup? • On R2 (For LSPs flowing from R2 to R4): interface pos <r2tor4> mpls traffic-eng backuptunnel 1000link • LSPs are unidirectional, so the same protection should be enable for the opposite direction if reverse LSP is conf.

  38. How to setup the backup tunnel? • Just as a normal tunnel whose head-end is R2 and tail-end is R4 • v1 requires a manually configured ERO interface Tunnel1000 ip unnumbered Loopback0 tunnel destination R4 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 800 tunnel mpls traffic-eng path-option 1 explicit name backuppath1 ip explicit-path name backuppath1 enable next-address R6 next-address R7 next-address R4

  39. Which LSPs can be re-routed on R2 in the event of R2-R4 failure? • The LSPs flowing through R2 that • have R2-R4 as Outgoing Interface • have been signalled by their respective head-ends with a session attribute flag 0x01=ON (may use fast-re-route tunnels) • int tunnel 1 ## config on the head-end • tunnel mpls traffic-eng fast-reroute

  40. Global Label Allocation POP R9 R8 14 R4 R2 R5 R1 • For the blue LSP, R4 bound a global label of 14 • Any MPLS frame received by R4, with label 14, will be switched onto the link to R9 with a POP, whatever the incoming interface R7 R6

  41. How fast is fast? • Link Failure Notification • Usual PoS alarm detection • PoS driver optimisation to interrupt RP in < 1ms • Expected call to net_cstate(idb, UP/DOWN) identifying the DOWN state of the protected int to start our protection action. • RP updates the master TFIB (replace a swap by a swap-push) • < 1ms • Master TFIB change notified to the linecards • < 1ms

  42. Path & Resv Msgs [Error & Tear] R4 R2 R3 R1 When no link protection: Conf. Resv Tear Conf. Path Tear Resv Tear When link protection: Path Error R4 waits for refresh Resv in place

  43. LSP Re-Optimisation • Head-end notified by PathError • special flag (reservation in place) indicates that the path states must not be destroyed. It is just a hint to the head-end that the path should be re-optimised • Head-end notified by IGP

  44. Why the Patherror? • The Patherror might be faster • In case of multi-area IGP, the IGP will not provide the information • In case of very fast up-down-up, the LSP will be put on the backup tunnel and will stay there as the IGP will not have originated a new LSP/LSA • a router waits a certain time before originating a new LSP/LSA after a topological change

  45. DiffServ and LSP Reoptimization • In order to optimize the bandwdith usage, backup tunnels might be configured with 0kbps • Although usually the backbone is though as being congestion-free, during re-routing some local congestion might occur • Use diffserv to handle this short-term congestion • Use LSP reoptimization to handle the long-term congestion

  46. Layer1/2 and Layer3 • Backup Tunnel should not use • the protected L3 link • the protected L1/L2 links!!! • Use WANDL (loaded with both L3 and L1/2 topologies) to compute the best paths for backup tunnels • Download this as static backup tunnels to the routers

  47. Fast Re-RouteNode Protection 47 © 1999, Cisco Systems, Inc.

  48. Overview R9 R8 R4 R3 Backup Tunnel to the next-hop of the LSPs next-hop R2 R5 R1 R7 R6

  49. A few more details • Assume • R2 is configured with resilience for R3 • R2 receives a path message for a new LSP whose ERO is {R3, R4, …}, whose Session is (R9, 1, R1), whose sender is (R1, 1) and whose session attribute is (0x01 ON, 0x02 OFF) • 0x01: may use local fast-reroute if available • 0x02: merge capable

  50. A few more details • Then • R2 checks if it already has a tunnel to R4 • If not, R2 builds a backup tunnel to R4 (currently just like in link protection - manual explicit setup). • R2 sends a Path onto the tunnel with Session (R9, 1, R1), Sender (R2, 1), Session Attribute (0x01 OFF, 0x02 ON) and PHOP R2

More Related