mpls traffic engineering

7/29/2019 MPLS Traffic Engineering

1/151

1 1999, Cisco Systems, Inc.

MPLS Traffic

EngineeringNANOG18

Robert Raszuk - IOS [email protected]


2/151

2NANOG18 - 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 presentation

TE_Monitor.pdf - show & debug commands

TE_Config.pdf - full configuration syntax

TE_SampleCfg.pdf - configuration sample

TE_DEMO.tar - Tared TE offline demo (HTML)

TEisistdp_1.pdf - Demos Lab Topology


3/151


Traffic Engineering: Motivations

Reduce the overall cost of operations bymore efficient use of bandwidth resources

by preventing a situation where some parts ofa service provider network are over-utilized(congested), while other parts under-utilized

The ultimate goal is cost saving !


4/1514NANOG18 - Robert Raszuk 2000, Cisco Systems, Inc.

Traffic Engineering: Motivations

MPLS and Traffic Eng allows for one tospread the traffic and distribute it acrossthe entire network infrastructure likemagnetic fields between poles whilealso providing the redundancy required

for high availability service.

(Eric Dean)



Without Traffic Engineering

Cars:

SFO-LAX

LAX-SFO

SAN-SMF

SMF-SAN

No TrafficEngineering

analogy

to HumanDrivers



With Traffic Engineering

Cars:

SFO-LAX

LAX-SFO

SAN-SMF

SMF-SAN

TrafficEngineering

analogy

to Auto Pilot



Routing solution to TrafficEngineering

Construct routes for traffic streams within a service provider insuch a way, as to avoids causing some parts of the providersnetwork to be over-utilized, while others parts remain under-utilized

R2

R3

R1



The Overlay Solution

Routing at layer 2 (ATM or FR) is used for trafficengineering

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

L3 L3

Physical Logical



Traffic engineering with overlay

R2

R3

R1

PVC for R2 to R3 traffic

PVC for R1 to R3 traffic



Overlay solution: drawbacks

Extra network devices (cost)

More complex network management (cost)

two-level network without integrated network

management

additional training, technical support, fieldengineering

IGP routing scalability issue for meshes

Additional bandwidth overhead (cell tax)



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



12/151


Traffic engineering with Layer 3

R2

R3

R1

IP routing: destination-based least-cost routing

under-utilized alternate path




13/151


Traffic engineering with Layer 3what is missing ?

Path computation based just on IGPmetric is not enough

Support for explicit routing (aka

source routing) is not available

Analogy: SanJose

San

Jose


14/151


MPLS TrafficEngineering



15/151


TE - key mechanisms

Explicit routing (aka source routing)

Constrained-based Path Selection Algorithm

(Example: Choose path with no congestion, avoidhighways, select scenic roads etc)

Extensions to OSPF/ISIS for flooding ofresources / policy information (Live collection of

traffic statistics - pilot tests in Europe)

MPLS as the forwarding mechanism (Auto Pilotprogrammed in each car when entering city)


16/151


TE - key mechanisms

Explicit routing (aka source routing)

RSVP as the mechanism for establishingLabel Switched Paths (LSPs)

use of the explicitly routed LSPs in the

forwarding table


17/151


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

A B

C


18/151


TE basics

Traffic within a Service Provider as acollection of POP to POP traffic

trunks with known bandwidth andpolicy requirements

TE provides traffic trunk routing that

meets the goal of Traffic Engineering via a combination of on-line and off-line procedures


19/151


Requirements:

Differentiating traffic trunks:

large, critical traffic trunks must be well routed inpreference to other trunks

Handling failures:

automated re-routing in the presence of failures

Pre-configured paths:

for use in conjunction with the off-line routecomputation procedures

Support of multiple Classes of Service


20/151


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 LabelSwitched Paths (LSPs)

could provide more efficient use of networking

resources

Ability to include / exclude certain links for certaintraffic trunks


21/151


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 acombination of administrative +bandwidth constraints


22/151


Trunks Attributes



23/151


Trunk Attributes

Configured at the head-end of the trunk

Bandwidth

Priorities

setup priority: priority for taking a resource

holding priority: priority for holding aresource


24/151


Trunk attributes

Ordered list of Path Options

possible administratively specified paths (viaan off-line central server) - {explicit list}

Constrained-based Dynamically computedpaths 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.


25/151


Trunk Attributes

Resource class affinity (Policy)

supports the ability to include/exclude certain links forcertain 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= dont care, I care)

Link is characterized by a 32-bit resource-classattribute string

Default-value of tunnel/link bits is 0

Default value of the tunnel mask = 0x0000FFFF

E l 0 4 bit t i d f lt


26/151


Example0: 4-bit string, default

Trunk A to B:

tunnel = 0000, t-mask = 0011

ADEB and ADCEB are possible

A B

0000

0000 0000

00000000

C

D E

E l 1 4 bit t i


27/151


Example1a: 4-bit string

Setting a link bit in the lower half drives all tunnels offthe link, except those specially configured

Trunk A to B:

tunnel = 0000, t-mask = 0011

Only ADCEB is possible

A B

0000

0000 0000

00100000

C

D E


28/151

Example1c 4 bit string


29/151


Example1c: 4-bit string

A specific tunnel can be restricted to only such links byinstead turning on the bit in its affinity attribute bits

Trunk A to B:

tunnel = 0010, t-mask = 0011

No path is possible

A B

0000

0000 0000

00100000

C

D E

Example2a: 4 bit string


30/151


Example2a: 4-bit string

Setting a link bit in the upper half drives has noimmediate effect

Trunk A to B:

tunnel = 0000, t-mask = 0011

ADEB and ADCEB are both possible

A B

0000

0000 0000

01000000

C

D E

Example2b: 4 bit string


31/151


Example2b: 4-bit string

A specific tunnel can be driven off the link by setting thebit in its mask

Trunk A to B:

tunnel = 0000, t-mask = 0111

Only ADCEB is possible

A B

0000

0000 0000

01000000

C

D E

Example2c: 4 bit string


32/151


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

A B

0000

0000 0000

01000000

C

D E

Trunk Attribute


33/151


Resource Class Affinity (Policy) The user defines the semantics:

this bit/mask says low-delay pathexcluded

Flexible (maybe too flexible :)

1c vs 2c ? in 1c, the default tunnels

will not be willing to flow via the speciallinks


34/151

Link Resource Attributes


35/151


Link Resource Attributes

Resource attributes are configured onevery link in a network

bandwidth

Link Attributes

TE-specific link metric


36/151

Per Priority Available BW


37/151


Per-Priority Available BW

DT=0 Link L, BW=100 D advertises: AB(0)=100== AB(7)=100AB(i) = Available Bandwidth at priority I

DT=2 Link L, BW=100

D advertises: AB(0)=AB(1)=AB(2)=100AB(3)=AB(4)==AB(7)=70

T=1 Setup of a tunnel over L at priority=3 for 30 units

DT=4 Link L, BW=100

D advertises: AB(0)=AB(1)=AB(2)=100AB(3)=AB(4)=70AB(5)=AB(6)=AB(7)=40

T=3 Setup of an additional tunnel over L at priority=5 for 30 units

Information Distribution


38/151



Re-use the flooding service from theLink-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



39/151



Periodic (timer-based)

On significant changes of availablebandwidth (threshold scheme)

On link configuration changes

On LSP Setup failure

Periodic Timer


40/151


Periodic Timer

Periodically, a node checks if the

current TE status is the same as theone lastly broadcasted.

If different, it floods its updated TELinks status

Significant Change


41/151


Significant Change

Each time a threshold iscrossed, an update issent

Denser population asutilization increases

Different thresholds forUP and Down (stabler)

50%

100%

70%

85%92%

Update

Update

LSP Setup Failure


42/151


LSP Setup Failure

Due to the threshold scheme, it is possiblethat one node thinks he can signal an LSPtunnel via node Z while in fact, Z does nothave the required resources

When Z receives the Resv message and

refuses the LSP tunnel, it broadcasts anupdate of its status


43/151


Constrained-basedComputation


Constrained-Based Routing


44/151


Constrained Based Routing

In general, path computation for an LSP mayseek to satisfy a set of requirementsassociated with the LSP, taking into account a

set of constraints imposed by administrativepolicies and the prevailing state of the network-- which usually relates to topology data andresource availability. Computation of an

engineered path that satisfies an arbitrary setof constraints is referred to as "constraintbased routing.

Draft-li-mpls-igp-te-00.txt

Path Computation


45/151


Path Computation

On demand by the trunks head-end:

for a new trunk

for an existing trunk whose (current)LSP failed

for an existing trunk when doing re-optimization

Path Computation


46/151


Path Computation

Input:

configured attributes of traffic trunksoriginated at this router

attributes associated with resources

available from IS-IS or OSPF

topology state information

available from IS-IS or OSPF


47/151

Path Computation


48/151


at Co putat o

Output:

explicit route - expressed as a sequence ofrouter IP addresses

interface addresses for numbered links

loopback address for unnumbered links

used as an input to the path setupcomponent


49/151


50/151

MPLS Labels


51/151


Two types of MPLS Labels:

Prefix Labels & Tunnel Labels

LDP RSVP

MP-BGP CR-LDP

PIM

Distributed

by:

MPLS as forwarding engine


52/151


g g

Traffic engineering requires explicit routingcapability

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


53/151


LSP tunnel Setup


RSVP Extensions to RFC2205for LSP Tunnels


54/151


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

RSVP Extensions: new objects


55/151


LABEL_REQUEST found in Path

LABEL found in Resv

EXPLICIT_ROUTE found in Path

RECORD_ROUTE found in Path, Resv

SESSION_ATTRIBUTE found in Path 0x01 Fast Reroute Capable,0x02 Permit Merging, 0x04 May Reoptimize => SE

New 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.

LSP Setup


56/151


Initiated at the head-end of a trunk

Uses RSVP (with extensions) toestablish Label Switched Paths(LSPs) for traffic trunks


57/151


58/151

Path Setup - more details


59/151


R3R1

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 1R2

21



60/151


R3R1

Path:Common_HeaderSession(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 1R2

21


61/151



62/151


Resv:Common_Header

Session(R3-lo0, 0, R1-lo0)

PHOP(R3-1)Style=SEFlowSpec(2Mbps)

Sender_Template(R1-lo0, 00)Label=POP

Record_Route(R3-1)

R3R12 1

R221


63/151



64/151


R3R12 1

R221

Resv:Common_Header

Session(R3-lo0, 0, R1-lo0)PHOP(R2-1)

Style=SEFlowSpec (2Mbps)

Sender_Template(R1-lo0, 00)Label=5

Record_Route(R2-1, R3-1)


65/151

Trunk Admission Control


66/151


Performed by routers along a LabelSwitched Path (LSP)

Determines if resources are available

May tear down (existing) LSPs with a lowerpriority

Does the local accounting

Triggers IGP information distribution whenresource thresholds are crossed

Link Admission Control


67/151


Already invoked by Path message

if BW is available, this BW is put aside in a waitingpool (waiting for the RESV msg)

if this process required the pre-emption of

resources, LCAC notified RSVP of the pre-emptionwhich then sent PathErr and/or ResvErr for thepreempted tunnel

if BW is not available, LCAC says No to RSVPand a Path error is sent. A flooding of the nodesresource info is triggered, if needed

draft-ietf-mpls-rsvp-lsp-tunnel-02.txt


68/151


69/151


70/151


71/151

Reroute - More Details


72/151


R2 R3R1

ERO (R2-1, R3-1)Sender_Template(R1-lo0, 00)

2

3

1

3

12

Session(R3-lo0, 0, R1-lo0)

ERO (R2-1, , R3-3)Sender_Template(R1-lo0, 01)

00

01

0101

Resource Sharing


73/151



74/151


R2 R3R12 31 3

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)


75/151


R3


76/151


R2 R3R12 31 3

RSVP:

Common_HeaderSession(R3-lo0, 0, R1-lo0)

PHOP(R3-3)Style=SE

FlowSpec(3Mbps)

Sender_Template(R1-lo0, 01)Label=POP

Record_Route(R3-3)


R3


77/151


R2 R3R12 31 3


R3


78/151


R2 R3R12 31 3

RSVP:Common_Header

Session(R3-lo0, 0, R1-lo0)PHOP(R2-1)

Style=SEFlowSpec (3Mbps)

Sender_Template(R1-lo0, 01)Label=6

Record_Route(R2-1,, R3-3)

Sender_Template(R1-lo0, 00)Label=5Record_Route(R2-1, R3-1)


79/151


80/151


81/151


82/151


83/151


84/151


85/151


86/151


87/151


88/151


89/151


90/151


91/151


92/151


Fast ReRoute

More details on LinkProtection (FRR v1)



93/151


94/151

Terminology


95/151


Link Protection

In the event of a link failure, an LSP isrerouted to the next-hop using apreconfigured backup tunnel


96/151


97/151


98/151


99/151


100/151

Path state while Rerouting

Path ( PHOP=R2 )


101/151


R8

R2

R6

R4

R7

R1 R5

R9

BackUP tunnel

Path (, PHOP=R2, )

PathstatePathstate

PathError (Reservation in Place)

Path & Resv Msgs [Error & Tear]

R4R1 R2 R3


102/151


Path Tear

Resv Tear

Conf.Resv Tear Conf.

When no link protection:

R4 waits forrefresh

Path Error

Resv inplace

When link protection:

LSP reoptimization


103/151


Head-end notified by PathError

special flag (reservation in place)

indicates that the path states must notbe destroyed. It is just a hint to thehead-end that the path should bereoptimized

Head-end notified by IGP


104/151


105/151

DiffServ and LSP Reoptimization


106/151


In order to optimize the bandwdith usage, backuptunnels might be configured with 0kbps

no non-working bandwdith as in SDH!

Although usually the backbone is though as beingcongestion-free, during rerouting some localcongestion might occur

Use diffserv to handle this short-term congestion

Use LSP reoptimization to handle the long-termcongestion


107/151


108/151


109/151


110/151


111/151


112/151

A few More details


113/151


When R2 detects R3s failure, For the TFIB entry for the LSP, R2 changes theexisting swap by a swap to L and a push of thebackup tunnel label

R4s states are refreshed by the secondarypath 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)


114/151


115/151

A possible solution

RP RP


116/151


Keepalives between LCs

Keepalives between a LC and its master RP

LC

...LC

LC


117/151

Enhancement to SPF


118/151


During SPF each new node found is moved from aTENTative list to PATHS list. Now the first-hop isbeing determined via:

A. Check if there is any TE tunnel terminating at

this node from the current router and if so dothe metric check

B. If there is no TE tunnel and the node is directlyconnected use the first-hop from adj database

C. In non of the above applies the first-hop iscopied from the parent of this new node.


119/151


120/151


121/151


Other TE New Features



122/151


123/151


124/151


125/151


126/151

Example

In-Prog Bw: 55

In-Prog Bw: 10


127/151


Avail Bw: 100

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


128/151


129/151


130/151


131/151

Last hop label

IETF draft ietf mpls label encaps 07 txt


132/151


IETF draft-ietf-mpls-label-encaps-07.txtA 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]


133/151


QoS and RRR


QoS and RRR


134/151


MPLS TE can operate simultaneously (andorthogonally) with MPLS Diff-Serv

All Precedence/DSCP packets follow thesame TE tunnels

Diff-Serv provides selective discard (via WRED),

and selective scheduling (via WFQ)


135/151

DiffServ and fast-reroute/TE

In order to optimize the bandwdith usage backup


136/151


In order to optimize the bandwdith usage, backuptunnels might be configured with 0kbps

no non-working bandwdith as in SDH!

Although usually the backbone is though as beingcongestion-free, during rerouting some localcongestion might occur

Use diffserv to handle this short-term congestion

Use LSP reoptimization to handle the long-termcongestion


137/151


RSVP

LSP Signalling Protocolfor Traffic Engineering


MPLS-TE Signalling Protocol


138/151


Two proposed signaling mechanisms forMPLS traffic engineering are being

considered by the IETFs MPLS work group RSVP (Cisco and a number of Gigabit routerstartups (Avici, Argon, Ironbridge, Juniper, andTorrent))

CR-LDP (Ericsson, Ennovate, GDC, Nortel)

Why RSVP ?

What is needed: An IP signalling Protocol!


139/151


What is needed: ability to establish and maintain Label SwitchedPath along an explicit route

ability to reserve resources when establishing a

path

Interdependent, not independent tasks

benefit from consolidation

An IP signalling Protocol!

Do I need RSVP only for TE ?

Oth f RSVP i t d t k

NO !


140/151


Other uses of RSVP in todays 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)

RSVP is a natural choice


141/151


RFC2205: provides a general facility forcreating and maintaining distributedreservation state across a mesh of multicast

and unicast delivery paths

TE: use as a general facility for creating andmaintaining distributed forwarding &reservation state across a mesh of deliverypaths


RFC2205: transfers and manipulates QoS


142/151


RFC2205 p QoScontrol parameters as opaque data, passingthem to the appropriate traffic controlmodule for interpretation

TE: transfer and manipulate explicit routeand label control parameters as opaque datapass explicit route parameter to theappropriate routing module, and labelparameter to the MPLS module


Leverage Standardized Protocols

PIM for Multicast MPLSBGP f MPLS VPN


143/151


BGP for MPLS VPNs

RSVP for MPLS Traffic Engineering

LDP (TDP) has been designed because it was easier

than fixing all IGPs (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_surveyfor a list of RSVP implementations


144/151


145/151


146/151


147/151


148/151


149/151


Summary


Traffic Eng

Provides traffic engineering


150/151


g gcapabilities at Layer 3

above and beyond of what is provided

with ATM

Could be used for other applicationsas well

Shipping and deployed in production


151/151

mpls traffic engineering

Documents