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

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