Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 © 1999, Cisco Systems, Inc. MPLS Traffic Engineering NANOG18 Robert Raszuk - IOS Engineering

Similar presentations


Presentation on theme: "1 © 1999, Cisco Systems, Inc. MPLS Traffic Engineering NANOG18 Robert Raszuk - IOS Engineering"— Presentation transcript:

1

2 1 © 1999, Cisco Systems, Inc. MPLS Traffic Engineering NANOG18 Robert Raszuk - IOS Engineering

3 2 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Location of files This presentation, handouts & demo are located at: ftp://ftpeng.cisco.com/rraszuk/nanog18 RR_MPLS_TE_Nanog.pdf - this presentationRR_MPLS_TE_Nanog.pdf - this presentation TE_Monitor.pdf - show & debug commandsTE_Monitor.pdf - show & debug commands TE_Config.pdf - full configuration syntaxTE_Config.pdf - full configuration syntax TE_SampleCfg.pdf - configuration sampleTE_SampleCfg.pdf - configuration sample TE_DEMO.tar - Tared TE offline demo (HTML)TE_DEMO.tar - Tared TE offline demo (HTML) TEisistdp_1.pdf - Demo’s Lab TopologyTEisistdp_1.pdf - Demo’s Lab Topology

4 3 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic Engineering: Motivations Reduce the overall cost of operations by more efficient use of bandwidth resources – by preventing a situation where some parts of a service provider network are over-utilized (congested), while other parts under-utilized cost saving ! The ultimate goal is cost saving !

5 4 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic Engineering: Motivations MPLS and Traffic Eng allows for one to spread the traffic and distribute it across the entire network infrastructure like magnetic fields between poles while also providing the redundancy required for high availability service.MPLS and Traffic Eng allows for one to spread the traffic and distribute it across the entire network infrastructure like magnetic fields between poles while also providing the redundancy required for high availability service. (Eric Dean) (Eric Dean)

6 5 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Without Traffic Engineering Cars: SFO-LAX LAX-SFO SAN-SMF SMF-SAN No Traffic Engineering analogy to Human Drivers

7 6 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. With Traffic Engineering Cars: SFO-LAX LAX-SFO SAN-SMF SMF-SAN Traffic Engineering analogy to Auto Pilot

8 7 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Routing solution to Traffic Engineering Construct routes for traffic streams within a service provider in such a way, as to avoids causing some parts of the provider’s network to be over-utilized, while others parts remain under- utilized R2 R3 R1

9 8 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. The “Overlay” Solution Routing at layer 2 (ATM or FR) is used for traffic engineering Analogy to direct highways between SFO-LAX & SAN-SMF. Nobody enters the highway in between. L3 L3 L3 L3 L3 L3 L3 L2 L2 L2 L2 L2 L2 L3 L3 L3 L3L3 PhysicalLogical

10 9 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic engineering with overlay R2 R3 R1 PVC for R2 to R3 traffic PVC for R1 to R3 traffic

11 10 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. “Overlay” solution: drawbacks Extra network devices (cost) More complex network management (cost) – two-level network without integrated network management – additional training, technical support, field engineering IGP routing scalability issue for meshes Additional bandwidth overhead (“cell tax”)

12 11 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic engineering with Layer 3 R2 R3 R1 IP routing: destination-based least-cost routing under-utilized alternate path Path for R2 to R3 traffic Path for R1 to R3 traffic

13 12 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic engineering with Layer 3 R2 R3 R1 IP routing: destination-based least-cost routing under-utilized alternate path Path for R2 to R3 traffic Path for R1 to R3 traffic

14 13 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic engineering with Layer 3 what is missing ? Path computation based just on IGP metric is not enough Support for “explicit” routing (aka “source routing”) is not available Analogy: San Jose San Jose

15 14 © 1999, Cisco Systems, Inc. MPLS Traffic Engineering 14 © 1999, Cisco Systems, Inc.

16 15 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. TE - key mechanisms “Explicit” routing (aka “source routing”) – Constrained-based Path Selection Algorithm (Example: Choose path with no congestion, avoid highways, select scenic roads etc…) – Extensions to OSPF/ISIS for flooding of resources / policy information (Live collection of traffic statistics - pilot tests in Europe) – MPLS as the forwarding mechanism (Auto Pilot programmed in each car when entering city)

17 16 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. TE - key mechanisms “Explicit” routing (aka “source routing”) – RSVP as the mechanism for establishing Label Switched Paths (LSPs) – use of the explicitly routed LSP’s in the forwarding table

18 17 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. What is a “traffic trunk” ? Aggregation of (micro) flows that are: – forwarded along a common path (within a service provider) – often from a POP to another POP – share a common QoS requirement (if L-LSPs are used) Essential for scalability D AB C

19 18 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. TE basics Traffic within a Service Provider as a collection of “POP to POP traffic trunks” with known bandwidth and policy requirements TE provides traffic trunk routing that meets the goal of Traffic Engineering – via a combination of on-line and off- line procedures

20 19 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Requirements: Differentiating traffic trunks: – large, ‘critical’ traffic trunks must be well routed in preference to other trunks Handling failures: – automated re-routing in the presence of failures Pre-configured paths: – for use in conjunction with the off-line route computation procedures Support of multiple Classes of Service

21 20 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Requirements (cont.) Constraining sub-optimality: – should re-optimize on new/restored bandwidth in a non-disruptive fashion - maintain the existing route until the new route is established, without any double counting Ability to “spread” traffic trunk across multiple Label Switched Paths (LSPs) – could provide more efficient use of networking resources Ability to include / exclude certain links for certain traffic trunks

22 21 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Design Constraints Constrained to a single routing domain – initially constrained to a single area Requires OSPF or IS-IS Unicast traffic Focus on supporting routing based on a combination of administrative + bandwidth constraints

23 22 © 1999, Cisco Systems, Inc. Trunks Attributes 22 © 1999, Cisco Systems, Inc.

24 23 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Trunk Attributes Configured at the head-end of the trunk Bandwidth Priorities – setup priority: priority for taking a resource – holding priority: priority for holding a resource

25 24 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Trunk attributes Ordered list of Path Options – possible administratively specified paths (via an off-line central server) - {explicit list} – Constrained-based Dynamically computed paths based on combo of Bw and policies Re-optimization – each path option is enabled or not for re- optimization, interval given in seconds. – Max 1 week (7*24*3600), Disable 0, Def 1h.

26 25 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Trunk Attributes Resource class affinity (Policy) – supports the ability to include/exclude certain links for certain traffic trunks based on a user-defined Policy – Tunnel is characterized by a 32-bit resource-class affinity bit string 32-bit resource-class mask (0= don’t care, I care) – Link is characterized by a 32-bit resource-class attribute string – Default-value of tunnel/link bits is 0 – Default value of the tunnel mask = 0x0000FFFF

27 26 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example0: 4-bit string, default Trunk A to B: – tunnel = 0000, t-mask = 0011 ADEB and ADCEB are possible AB 0000 C DE

28 27 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example1a: 4-bit string Setting a link bit in the lower half drives all tunnels off the link, except those specially configured Trunk A to B: – tunnel = 0000, t-mask = 0011 Only ADCEB is possible AB C DE

29 28 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example1b: 4-bit string A specific tunnel can then be configured to allow such links by clearing the bit in its affinity attribute mask Trunk A to B: – tunnel = 0000, t-mask = 0001 Again, ADEB and ADCEB are possible AB C DE

30 29 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example1c: 4-bit string A specific tunnel can be restricted to only such links by instead turning on the bit in its affinity attribute bits Trunk A to B: – tunnel = 0010, t-mask = 0011 No path is possible AB C DE

31 30 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example2a: 4-bit string Setting a link bit in the upper half drives has no immediate effect Trunk A to B: – tunnel = 0000, t-mask = 0011 ADEB and ADCEB are both possible AB C DE

32 31 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example2b: 4-bit string A specific tunnel can be driven off the link by setting the bit in its mask Trunk A to B: – tunnel = 0000, t-mask = 0111 Only ADCEB is possible AB C DE

33 32 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example2c: 4-bit string A specific tunnel can be restricted to only such links Trunk A to B: – tunnel = 0100, t-mask = 0111 No path is possible AB C DE

34 33 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Trunk Attribute Resource Class Affinity (Policy) The user defines the semantics: – this bit/mask says “low-delay path excluded” Flexible (maybe too flexible :) – 1c vs 2c ?… in 1c, the default tunnels will not be willing to flow via the special links

35 34 © 1999, Cisco Systems, Inc. Link Attributes and their flooding 34 © 1999, Cisco Systems, Inc.

36 35 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Link Resource Attributes Resource attributes are configured on every link in a network – bandwidth – Link Attributes – TE-specific link metric

37 36 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Link Resource Attributes Resource attributes are flooded throughout the network – bandwidth per priority (0-7) – Link Attributes (Policy) – TE-specific link metric – draft-li-mpls-igp-te-00.txt

38 37 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Per-Priority Available BW D T=0 Link L, BW=100 D advertises: AB(0)=100=…= AB(7)=100 AB(i) = ‘Available Bandwidth at priority I” D T=2 Link L, BW=100 D advertises: AB(0)=AB(1)=AB(2)=100 AB(3)=AB(4)=…=AB(7)=70 T=1 Setup of a tunnel over L at priority=3 for 30 units D T=4 Link L, BW=100 D advertises: AB(0)=AB(1)=AB(2)=100 AB(3)=AB(4)=70 AB(5)=AB(6)=AB(7)=40 T=3 Setup of an additional tunnel over L at priority=5 for 30 units

39 38 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Information Distribution Re-use the flooding service from the Link-State IGP – opaque LSA for OSPF draft-katz-yeung-ospf-traffic-00.txt – new wide TLV for IS-IS draft-ietf-isis-traffic-00.txt

40 39 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Information Distribution Periodic (timer-based) On significant changes of available bandwidth (threshold scheme) On link configuration changes On LSP Setup failure

41 40 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Periodic Timer Periodically, a node checks if the current TE status is the same as the one lastly broadcasted. If different, it floods its updated TE Links status

42 41 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Significant Change Each time a threshold is crossed, an update is sent Denser population as utilization increases Different thresholds for UP and Down (stabler) 50% 100% 70% 85% 92% Update

43 42 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. LSP Setup Failure Due to the threshold scheme, it is possible that one node thinks he can signal an LSP tunnel via node Z while in fact, Z does not have the required resources When Z receives the Resv message and refuses the LSP tunnel, it broadcasts an update of its status

44 43 © 1999, Cisco Systems, Inc. Constrained-based Computation 43 © 1999, Cisco Systems, Inc.

45 44 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Constrained-Based Routing “In general, path computation for an LSP may seek to satisfy a set of requirements associated with the LSP, taking into account a set of constraints imposed by administrative policies and the prevailing state of the network -- which usually relates to topology data and resource availability. Computation of an engineered path that satisfies an arbitrary set of constraints is referred to as "constraint based routing”. Draft-li-mpls-igp-te-00.txt

46 45 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Computation “On demand” by the trunk’s head-end: – for a new trunk – for an existing trunk whose (current) LSP failed – for an existing trunk when doing re- optimization

47 46 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Computation Input: – configured attributes of traffic trunks originated at this router – attributes associated with resources available from IS-IS or OSPF – topology state information available from IS-IS or OSPF

48 47 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Computation Prune links if: – insufficient resources (e.g., bandwidth) – violates policy constraints Compute shortest distance path – TE uses its own metric – Tie-break: selects the path with the highest minimum bandwdith so far, then with the smallest hop-count

49 48 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Computation Output: – explicit route - expressed as a sequence of router IP addresses interface addresses for numbered links loopback address for unnumbered links – used as an input to the path setup component

50 49 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example Tunnel’s request: – Priority 3, BW = 30 units, – Policy string: 0000, mask: 0011 AB C D E G BW(3)=60 BW(3)=50 BW(3)=80 BW(3)=20 BW(3)=50 BW(3)=70 BW(3)=80

51 50 © 1999, Cisco Systems, Inc. MPLS as the forwarding mechanism 50 © 1999, Cisco Systems, Inc.

52 51 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. MPLS Labels Two types of MPLS Labels: Prefix Labels & Tunnel Labels LDP RSVP MP-BGP CR-LDP PIM Distributed by:

53 52 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. MPLS as forwarding engine Traffic engineering requires explicit routing capability IP supports only the destination-based routing – not adequate for traffic engineering MPLS provides simple and efficient support for explicit routing – label swapping – separation of routing and forwarding

54 53 © 1999, Cisco Systems, Inc. LSP tunnel Setup 53 © 1999, Cisco Systems, Inc.

55 54 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP Extensions to RFC2205 for LSP Tunnels downstream-on-demand label distribution instantiation of explicit label switched paths allocation of network resources (e.g., bandwidth) to explicit LSPs rerouting of established LSP-tunnels in a smooth fashion using the concept of make-before-break tracking of the actual route traversed by an LSP-tunnel diagnostics on LSP-tunnels the concept of nodal abstraction preemption options that are administratively controllable draft-ietf-mpls-rsvp-lsp-tunnel-0X.txt

56 55 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP Extensions: new objects LABEL_REQUESTLABEL_REQUEST found in Path LABELLABEL found in Resv EXPLICIT_ROUTEEXPLICIT_ROUTE found in Path RECORD_ROUTERECORD_ROUTE found in Path, Resv SESSION_ATTRIBUTESESSION_ATTRIBUTE found in Path 0x01 Fast Reroute Capable, 0x02 Permit Merging, 0x04 May Reoptimize => SE SESSION SENDER_TEMPLATEFILTER_SPECFLOWSPECNew C-Types are also assigned for the SESSION, SENDER_TEMPLATE, FILTER_SPEC, FLOWSPEC objects. All new objects are optional with respect to RSVP (RFC2205). The LABEL_REQUEST and LABEL objects are mandatory with respect to MPLS LSP signalisation specification.

57 56 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. LSP Setup Initiated at the head-end of a trunk Uses RSVP (with extensions) to establish Label Switched Paths (LSPs) for traffic trunks

58 57 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - Example Setup: Path (ERO = R1->R2->R6->R7->R4->R9) Reply: Resv communicates labels and reserves bandwidth on each link Pop Label 22 Label 49 Label 17 R8 R2 R6 R3 R4 R7 R1 R5 R9 Label 32

59 58 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R2 R3 R1 Path: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R1-2) Label_Request(IP) ERO (R2-1, R3-1) Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 00) Sender_Tspec(2Mbps) Record_Route(R1-2)

60 59 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 Path State: Session(R3-lo0, 0, R1-lo0) PHOP(R1-2) Label_Request(IP) ERO (R2-1, R3-1) Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 00) Sender_Tspec(2Mbps) Record_Route (R1-2) 2 1 R2 2 1

61 60 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 Path: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R2-2) Label_Request(IP) ERO (R3-1) Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 00) Sender_Tspec(2Mbps) Record_Route (R1-2, R2-2) 2 1 R2 2 1

62 61 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 2 1 R2 2 1 Path State: Session(R3-lo0, 0, R1-lo0) PHOP(R2-2) Label_Request(IP) ERO () Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 00) Sender_Tspec(2Mbps) Record_Route (R1-2, R2-2, R3-1)

63 62 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Resv: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R3-1) Style=SE FlowSpec(2Mbps) Sender_Template(R1-lo0, 00) Label=POP Record_Route(R3-1) Path Setup - more details R3 R1 2 1 R2 2 1

64 63 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 2 1 R2 2 1 Resv State Session(R3-lo0, 0, R1-lo0) PHOP(R3-1) Style=SE FlowSpec (2Mbps) Sender_Template(R1-lo0, 00) OutLabel=POP IntLabel=5 Record_Route(R3-1)

65 64 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 2 1 R2 2 1 Resv: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R2-1) Style=SE FlowSpec (2Mbps) Sender_Template(R1-lo0, 00) Label=5 Record_Route(R2-1, R3-1)

66 65 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Setup - more details R3 R1 2 1 R2 2 1 Resv state: Session(R3-lo0, 0, R1-lo0) PHOP(R2-1) Style=SE FlowSpec (2Mbps) Sender_Template(R1-lo0, 00) Label=5 Record_Route(R1-2, R2-1, R3-1)

67 66 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Trunk Admission Control Performed by routers along a Label Switched Path (LSP) Determines if resources are available May tear down (existing) LSPs with a lower priority Does the local accounting Triggers IGP information distribution when resource thresholds are crossed

68 67 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Link Admission Control Already invoked by Path message – if BW is available, this BW is put aside in a waiting pool (waiting for the RESV msg) – if this process required the pre-emption of resources, LCAC notified RSVP of the pre-emption which then sent PathErr and/or ResvErr for the preempted tunnel – if BW is not available, LCAC says “No” to RSVP and a Path error is sent. A flooding of the node’s resource info is triggered, if needed – ”draft-ietf-mpls-rsvp-lsp-tunnel-02.txt”

69 68 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Monitoring Use of new Record Route Object – keep track of the exact tunnel path – detects loops – copy of RRO to ERO allows for route pinning

70 69 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Re-Optimization Looks for opportunities to re-optimize – make before break – no double counting of reservations – via RSVP “shared explicit” style!

71 70 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Non-disruptive rerouting - new path setup Current Path (ERO = R1->R2->R6->R7->R4->R9) New Path (ERO = R1->R2->R3->R4->R9) - shared with Current Path Until R9 gets new Path Message, current Resv is refreshed Pop R8 R2 R6 R3 R4 R7 R1 R5 R9 32

72 71 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Non-disruptive rerouting - switching paths Pop R8 R2 R6 R3 R4 R7 R1 R5 R9 32 Resv: allocates labels for both paths Reserves bandwidth once per link PathTear can then be sent to remove old path (and release resources) 89 26

73 72 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R1 R2-1, R ERO (R2-1, R3-1) Sender_Template(R1-lo0, 00) Session(R3-lo0, 0, R1-lo0) R2-1, …, R ERO (R2-1, …, R3-3) Sender_Template(R1-lo0, 01) Resource Sharing

74 73 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R1 Path: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R1-2) Label_Request(IP) ERO (R2-1, …,R3-3) Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 01) Sender_Tspec(3Mbps) Record_Route(R1-2)

75 74 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R Path State: Session(R3-lo0, 0, R1-lo0) PHOP(R1-2) Label_Request(IP) ERO (R2-1, …,R3-3) Session_Attribute (S(3), H(3), 0x04) Sender_Template(R1-lo0, 01) Sender_Tspec(3Mbps) Record_Route (R1-2)

76 75 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R

77 76 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R RSVP: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R3-3) Style=SE FlowSpec(3Mbps) Sender_Template(R1-lo0, 01) Label=POP Record_Route(R3-3)

78 77 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R

79 78 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R RSVP: Common_Header Session(R3-lo0, 0, R1-lo0) PHOP(R2-1) Style=SE FlowSpec (3Mbps) Sender_Template(R1-lo0, 01) Label=6 Record_Route(R2-1, …, R3-3) Sender_Template(R1-lo0, 00) Label=5 Record_Route(R2-1, R3-1)

80 79 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Reroute - More Details R2 R3 R RSVP state: Session(R3-lo0, 0, R1-lo0) PHOP(R2-1) Style=SE FlowSpec Sender_Template(R1-lo0, 01) Label=6 Record_Route(R2-1, …, R3-3) Sender_Template(R1-lo0, 00) Label=5 Record_Route(R2-1, R3-1)

81 80 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Fast Restoration Handling link failures - two complementary mechanisms: Path protection Link/Node protection

82 81 © 1999, Cisco Systems, Inc. Path Protection 81 © 1999, Cisco Systems, Inc.

83 82 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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 LSP’s, 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 LSP’s are affected. It schedules a reoptimization for them

84 83 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Protection Step2b: RSVP signalisation – rsvp path states with the failed intf as oif is detected – check if another oif available (if loose ero) – if not, clear path state 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 rerouted tunnel  convergence in the order of several seconds (at least).

85 84 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path Protection Speed it Up Fine Tune the IGP convergence – Through adequate tuning, ISIS could be tuned to converge in 2-3s, this ensuring that the convergence time bottleneck is the signalisation time for the new tunnel. Several tunnels in parallel with load-babalancing – 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)

86 85 © 1999, Cisco Systems, Inc. Fast ReRoute (aka Link Protection) An Overview 85 © 1999, Cisco Systems, Inc.

87 86 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Objective FRR allows for temporarily routing around a failed link or node while the head-end may reoptimize the entire LSP – rerouting under 50ms – scalable (must support lots of LSP’s)

88 87 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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

89 88 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Static backup Tunnel Setup: Path (R2->R6->R7->R4) Labels Established on Resv message Pop R8 R2 R6 R4 R7 R1 R5 R9

90 89 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. R8 R2 R6 R4 R7 R1 R5 R9 Setup: Path (R1->R2->R4->R9) Labels Established on Resv message Pop Routing prior R2-R4 link failure

91 90 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Link Protection Active R8 R2 R6 R4 R7 R1 R5 R9 On failure of link from R2 -> R4, R2 simply changes outgoing Label Stack from 14 to

92 91 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Link Protection Active R8 R2 R6 R4 R7 R1 R5 R9 Push Push 37 Pop Pop 22 Swap Swap 37->14 Push Push 17 Swap Swap 17->22 Pop Pop 14 Label Stack:R1R2R6R7R4R None 14

93 92 © 1999, Cisco Systems, Inc. Fast ReRoute More details on Link Protection (FRR v1) 92 © 1999, Cisco Systems, Inc.

94 93 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. V1 Constrain We protect the facility (link), not individual LSP’s – 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

95 94 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Terminology LSP: end-to-end tunnel onto which data normally flows (eg R1 to R9) R8 R2 R6 R4 R7 R1 R5 R9 BackUp tunnel: temporary route to take in the event of a failure

96 95 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Terminology Link Protection – In the event of a link failure, an LSP is rerouted to the next-hop using a preconfigured backup tunnel

97 96 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. How to indicate a link is protected and which tunnel is the backup? On R2 (For LSP’s flowing from R2 to R4): interface pos mpls traffic-eng backup tunnel 1000 link LSP’s are unidirectional, so the same protection should be enable for the opposite direction if reverse LSP is conf.

98 97 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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

99 98 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Which LSP’s can be rerouted on R2 in the event of R2-R4 failure? The LSP’s 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- reroute tunnels) int tunnel 1 ## config on the head-end fast-reroute tunnel mpls traffic-eng fast-reroute

100 99 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Global Label Allocation For the blue LSP, R4 bound a global label of 14 whatever the incoming interfaceAny MPLS frame received by R4, with label 14, will be switched onto the link to R9 with a POP, whatever the incoming interface R8 R2 R6 R4 R7 R1 R5 R9 14 POP

101 100 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. How fast is fast? Link Failure Notification – Usual PoS alarm detection PoS driver optimisation< 1ms – 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 – < 1ms Master TFIB change notified to the linecards < 1ms – < 1ms

102 101 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path state while Rerouting R8 R2 R6 R4 R7 R1 R5 R9 BackUP tunnel Path (…, PHOP=R2, …) Path state PathError (Reservation in Place)

103 102 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Path & Resv Msgs [Error & Tear] R4 R1 R2R3 Path Tear Resv Tear Conf. Resv TearConf. When no link protection: R4 waits for refresh Path Error Resv in place When link protection:

104 103 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. LSP reoptimization LSP reoptimization 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 reoptimized Head-end notified by IGP

105 104 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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 Reliable PathErr optimization

106 105 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. R8 R2 R6 R4 R7 R1 R5 R9 BackUP tunnel Resv Resv state Resv state while Rerouting Resv Message is unicast to the Phop (R2) R2’s Path State has been informed that the Resv might arrive over a different intf as the one used by the Path message The loss of the interface does not affect the Path and Resv states for the LSP’s received on that interface that are marked fast reroutable!

107 106 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. DiffServ and LSP Reoptimization In order to optimize the bandwdith usage, backup tunnels might be configured with 0kbps no ‘non-working’ bandwdith as in SDH! – no ‘non-working’ bandwdith as in SDH! Although usually the backbone is though as being congestion-free, during rerouting some local congestion might occur diffservshort-term congestion – Use diffserv to handle this short-term congestion LSP reoptimizationlong-term congestion – Use LSP reoptimization to handle the long-term congestion

108 107 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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

109 108 © 1999, Cisco Systems, Inc. Fast ReRoute Node Protection 108 © 1999, Cisco Systems, Inc.

110 109 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. R8 R2 R6 R3 R7 R1 R5 R9 R4 Overview Backup Tunnel to the next-hop of the LSP’s next-hop

111 110 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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

112 111 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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

113 112 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. A few More details When R4 receives this Path message, – it matches the session with the LSP’s one – merge (and thus stop) this path message – sends a RESV back to R2 (unicast) and allocate the appropriate label L

114 113 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. A few More details When R2 detects R3’s failure, – For the TFIB entry for the LSP, R2 changes the existing ‘swap’ by a ‘swap to L’ and a ‘push of the backup tunnel label’ R4’s states are refreshed by the secondary path messages (over the backup tunnels) ERO of the original path is adjusted at R2 NHOP is modified in R2 (from R3 to R4) PHOP is modified in R4 (from R3 to R2)

115 114 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. A few More Details RESV is being sent back from R4 to R2 directly If R3 is still active and just the R2-R3 link failed R4 needs to ignore & drop any Tear-Down msg R3 would be sending after the termination of reception of path refreshes from R2.

116 115 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. How to detect R3’s failure? A node may fail while the link is still up A node’s linecard processes might survive, a main process failure (freeze of the RP process)

117 116 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. A possible solution Keepalives between LC’s Keepalives between a LC and its master RP LC RP... LC RP LC

118 117 © 1999, Cisco Systems, Inc. Assigning traffic to Paths (aka autoroute) 117 © 1999, Cisco Systems, Inc.

119 118 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Enhancement to SPF During SPF each new node found is moved from a TENTative list to PATHS list. Now the first-hop is being determined via: A. Check if there is any TE tunnel terminating at this node from the current router and if so do the metric check B. If there is no TE tunnel and the node is directly connected use the first-hop from adj database C. In non of the above applies the first-hop is copied from the parent of this new node.

120 119 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Enhancement to SPF - metric check Tunnel metric: A. Relative +/- X B. Absolute Y The default is relative metric of 0. Example: Metric of native IP path to the found node = Tunnel with relative metric of -10 => Tunnel with relative metric of +10 => Tunnel with absolute metric of 10 => 10

121 120 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Enhancement to SPF - metric check If the metric of the found TE tunnel at this node is higher then the metric for other tunnels or native IGP path this tunnel is not installed as next hop If the metric of the found TE tunnel is equal to other TE tunnels the tunnel is added to the existing next- hops If the metric of the found TE tunnel is lower then the metric of other TE tunnels or native IGP the tunnel replaces them as the only next-hop.

122 121 © 1999, Cisco Systems, Inc. Other TE New Features 121 © 1999, Cisco Systems, Inc.

123 122 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Auto-Bandwidth Monitor marked tunnels’ 5-min average counters every X minutes – default: X = 300 (seconds) – (config)# mpls traffic-eng auto-bw timers frequency Global command:

124 123 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Auto-Bandwidth Every Y minutes, update the BW constraint of the tunnel with the maximum of: – the largest 5-min values sampled during the last Y minutes (Def Y = 24 * 3600sec) - 24h – a configured maximum value – (config-if)# tunnel mpls traffic-eng auto-bw {frequency } {max-bw } – if the new Bw is not available, the old one is maintained (the new BW is signalled via a 2nd tunnel to follow make before break model) Per tunnel command:

125 124 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example

126 125 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Verbatim Applies to explicitly routed LSP’s Disable any check against TE/IGP database of the head end RSVP still check BW (and policy when this will be in Path) hop by hop Application: manual TE through multi-area IGP CLI: tunnel mpls traffic-eng path-option verbatim

127 126 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. In-Progress Allows an end-head to account for bw consumed by tunnels that it has just signalled and for whom the IGP LSA/LSP update has not reflected the available bandwdith

128 127 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Example Avail Bw: 100 In-Prog Bw: 55In-Prog Bw: 10 All tunnels require 45 units of BW In-progress counters reset upon new LSA/LSP reception In-progress counter decremented upon receipt of path-error

129 128 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Benefits Speed-up the installation of tunnels as it avoids spending time trying not working solutions Allows for better load-balancing – igp metric then max(min(path-bw)!

130 129 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Under/Overbook ML: Maximum link bandwidth: –This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors). This is useful for traffic engineering. MR: Maximum reservable link bandwidth: – This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link. UR(I): Unreserved bandwidth at Priority i: – This sub-TLV contains the amount of bandwidth reservable on this direction on this link, at a certain priority. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.

131 130 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Under/Overbook ML is set to B1 (eg 1500) MR is set to B2 (eg 4000) At t=0, for all i 0 to 7, UB(i) = M = (eg 4000) routerA's LCAC will not accept an LSP tunnel asking more than ML even if there is available bandwdith at the requested priority. However, LCAC would allow for example 5 trunks each asking 700 kbps (thus each asking less than ML) while the aggregate is smaller than MR: because { 700 < ML=1500 } and { 3500 < MR=4000 } AB... Physical T1 s0 A’s config: int s0 bandwidth (eg 1500 kbps) bandwidth (eg 1500 kbps) ip rsvp bandwdith (eg 4000 kbps) ip rsvp bandwdith (eg 4000 kbps) A’s config: int s0 bandwidth (eg 1500 kbps) bandwidth (eg 1500 kbps) ip rsvp bandwdith (eg 4000 kbps) ip rsvp bandwdith (eg 4000 kbps)

132 131 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Standby Current solution Solution: – 4 tunnels from A to B: – Tu1’s relative metric: -3 – Tu2 and tu3’s relative metric: -2 – Tu4’s relative metric: -1 AB Tu1: bw1 Tu2: bw2 Tu3: bw3 Tu4: bw4

133 132 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Last hop label IETF draft-ietf-mpls-label-encaps-07.txt – A value of 0 represents the "IPv4 Explicit NULL Label” – A value of 1 represents the "Router Alert Label” – A value of 2 represents the "IPv6 Explicit NULL Label" – A value of 3 represents the "Implicit NULL Label” New cli forces tailend to send implicit-null (3) instead of explicit null (0) - default. # [no] mpls traffic-eng signalling advertise implicit-null [ ] On receipt (n-1) node we must map 0, 1 or 3 to internal Implicit Null [1 only for historical reasons]

134 133 © 1999, Cisco Systems, Inc. QoS and RRR 133 © 1999, Cisco Systems, Inc.

135 134 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. QoS and RRR MPLS TE can operate simultaneously (and orthogonally) with MPLS Diff-Serv All Precedence/DSCP packets follow the same TE tunnels Diff-Serv provides selective discard (via WRED), and selective scheduling (via WFQ)

136 135 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. QoS and RRR Future: – Scalable per-tunnel scheduling and policing Guaranteed PIPE in MPLS-VPN CoS – per-DSCP/per-FEC traffic engineering diffserv backbone capacity management

137 136 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. DiffServ and fast-reroute/TE In order to optimize the bandwdith usage, backup tunnels might be configured with 0kbps no ‘non-working’ bandwdith as in SDH! – no ‘non-working’ bandwdith as in SDH! Although usually the backbone is though as being congestion-free, during rerouting some local congestion might occur diffservshort-term congestion – Use diffserv to handle this short-term congestion LSP reoptimizationlong-term congestion – Use LSP reoptimization to handle the long-term congestion

138 137 © 1999, Cisco Systems, Inc. RSVP LSP Signalling Protocol for Traffic Engineering 137 © 1999, Cisco Systems, Inc.

139 138 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. MPLS-TE Signalling Protocol Two proposed signaling mechanisms for MPLS traffic engineering are being considered by the IETF’s MPLS work group – RSVP (Cisco and a number of Gigabit router startups (Avici, Argon, Ironbridge, Juniper, and Torrent)) – CR-LDP (Ericsson, Ennovate, GDC, Nortel)

140 139 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Why RSVP ? What is needed: – ability to establish and maintain Label Switched Path along an explicit route – ability to reserve resources when establishing a path Interdependent, not independent tasks – benefit from consolidation An IP signalling Protocol!

141 140 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Do I need RSVP only for TE ? Other uses of RSVP in today’s networks: Voice over IP call setup, Video (IPTV) Hybrid deployments (only where needed) QoS DiffServ Engineering (Cops) Qualitative Service for DiffServ with RSVP (as opposed to Quantitative RSVP IntServ model) NO !

142 141 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP is a natural choice RFC2205: “provides a general facility for creating and maintaining distributed reservation state across a mesh of multicast and unicast delivery paths” TE: use as a general facility for creating and maintaining distributed forwarding & reservation state across a mesh of delivery paths

143 142 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP is a natural choice RFC2205: “transfers and manipulates QoS control parameters as opaque data, passing them to the appropriate traffic control module for interpretation” TE: transfer and manipulate explicit route and label control parameters as opaque data pass explicit route parameter to the appropriate routing module, and label parameter to the MPLS module

144 143 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP is a natural choice Leverage Standardized Protocols – PIM for Multicast MPLS – BGP for MPLS VPN’s – RSVP for MPLS Traffic Engineering – LDP (TDP) has been designed because it was easier than fixing all IGP’s (RIP, EIGRP, OSPF, ISIS) – fast deployments and engineering consistency Leverage Deployed Experience – RSVP deployed since 1996 (IOS 11.2) – ww.isi.edu/rsvp/DOCUMENTS/ietf_rsvp_qos_survey for a list of RSVP implementations

145 144 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP is a natural choice RSVP easily supports – Dynamic resizing of tunnels or paths through refresh messages –Supports strict as well as loose source routes –No double counting of bandwidth when re- routing sub-optimal routes Extensible via definition of new objects

146 145 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. RSVP/TE and Scalability 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) Very Different than IntServ context

147 146 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. 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 RSVP/TE and Scalability Very Different than IntServ context

148 147 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. TE/RSVP Scalability With basic RSVP (RFC2205), RRR LSP tunnels flowing through a 75x0 or is not a problem Already Deployed on a number of Tier-1 ISP backbones – – Ship with 12.0(5)S Refresh Aggregation work will again enhance this scalability

149 148 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Conclusion Using RSVP as MPLS/TE signalling protocol is the natural and consistent choice It is however only one part of a whole solution: – MPLS as forwarding engine – IGP (OSPF/ISIS) extensions – Constrained Base Routing (RRR) – RSVP as MPLS/TE Signalling Protocol – Installation of Tunnels in the FIB

150 149 © 1999, Cisco Systems, Inc. Summary 149 © 1999, Cisco Systems, Inc.

151 150 NANOG18 - Robert Raszuk © 2000, Cisco Systems, Inc. Traffic Eng Provides traffic engineering capabilities at Layer 3 – above and beyond of what is provided with ATM Could be used for other applications as well Shipping and deployed in production

152 151 Presentation_ID © 1999, Cisco Systems, Inc.


Download ppt "1 © 1999, Cisco Systems, Inc. MPLS Traffic Engineering NANOG18 Robert Raszuk - IOS Engineering"

Similar presentations


Ads by Google