Knoll Mpls Te

8/10/2019 Knoll Mpls Te

1/14

Thomas Martin Knoll Technische Universitt Chemnitz

Aktuelle Aktivitten der IETF auf dem

Gebiet der Verkehrssteuerung

(Traffic Engineering) in MPLS-Netzen

ITG-FG 5.2.3 - Next Generation Networks

10. Sitzung am 23. Juli 2004 in Chemnitz

Thomas Knoll

TU Chemnitz - Professur Daten- und Kommunikationstechnik

Telefon 0371 531 3246

Email [email protected]


Motivation

Internet Routing Enhancements

MPLS-TE -> DS-MPLS-TE

Current TE Requirement Drafts

Inter-AS solutions

Talk Outline


2/14


Networks offering connectionless IP datagram serviceprovide

packet delivery along the shortest pathwith single class best

effort treatment.

Motivation

Single Autonomous Systems(AS) have been extended to support

MPLS & DiffServ, which offers differentiated path selection and

differentiated forwarding behaviourfor a set of traffic classes.

Extending these capabilities across AS borders is the current

hot topic - known as Inter-AS-MPLS-TE.


Internet Routing concept

Router Intradomain Routing

e.g. OSPF, RIP,

EIGRP

Routing Domain = IGP Routing Area

interior router

Hosts

Intradomain Routinge.g. OSPF, RIP,

EIGRP

Router

Routin Domain = IGP Routin Area

Hosts

Gateway / Area Border Router

(more intelligentRouter)

Router

Intradomain Routinge.g. OSPF, RIP,

EIGRP

Routing Domain = IGP Routing Area(Transit-Domain)

Interdomain Routing

e.g. BGP

border router


3/14


Internet Routing concept - Autonomous Systems

AS2

AS4

AS3AS1

IGP area

IGP area

IGP area


MPLS network

AS2

AS4

AS3AS1

MPLS network

IGP area

IGP area

IGP area


4/14


DiffServ aware MPLS

AS2

AS4

AS3AS1

MPLS network

DS domainDS domain

DS domain


DiffServ(Differentiated Services) 02/99- Transport Area * An Architecture for Differentiated Services (RFC 2475)

* Definition of the DS Field in IPv4 and IPv6 (RFC 2474)

* Assured Forwarding PHB Group (RFC 2597)

* An Expedited Forwarding PHB (RFC 3246)

MPLS(Multiprotocol Label Switching 1997- Routing Area * Multiprotocol Label Switching Architecture (RFC 3031)

* MPLS Support of Differentiated Services (RFC 3270)

TEWG(Internet Traffic Engineering) 12/00- Sub-IP Area * Overview and Principles of Internet Traffic Engineering (RFC 3272)

* Draft: Requirements for Inter-area MPLS Traffic Engineering

* Draft: MPLS Inter-AS Traffic Engineering requirements

NSIS(Next Steps in Signaling) 03/02-Transport Area => IP signalling protocol(RSVP simplified)

IETF - Working Groups


5/14


MPLS-TE Requirements

RFC2702 - 9/99

Requirements for Traffic Engineering Over MPLS

=> functional capabilities required to implement policies that facilitate

efficient and reliable MPLS network operation

Capabilities applicable to any single AS label switched network with

2 paths between 2 nodes

TE = technology & scientific principles for:

measurement,

modelling,

characterisation, and

control of Internet traffic

=> achieve specific performance objectives (optimisation)

MPLS can help


MPLS-TE Requirements (contd)

Traffic oriented performance objectives:

Resource oriented performance objectives:

Single class best effort

Internet service model packet loss,

delay,

throughput, and

enforcement of service level agreements

Differentiated services

Internet

peak to peak packet delay variation,

loss ratio, and

maximum packet transfer delay

equal resource utilisation -> avoid unnecessary congestion

excess demand -> classical cong. control (rate limit., queue dropping ...) inefficient resource mapping/allocation -> traffic engineering

=> load balancing + other allocation policies


6/14



Traffic Engineering = control problem !

SPF = topology driven (no BW availability, no traffic characteristic)

=> causes congestion !

All matching traffic onto single path

=> equal cost path load sharinghelps - falls down on stream convergence

IGP case

+ constraint-based VC routing+ configurable explicit VC paths

+ admission control functions

+ traffic shaping and traffic policing functions

+ VC protection

overlay model: IP over ATM / IP over Frame Relay

=> virtual channels advertised as IGP links -> works -> very expensive!

IGP + Overlay case



MPLS => independent LSP setup process

constraint-based setup

explicit route path setup supported admission control = reservation (at least through LSP setup denial)

path protection by pre-configured backup LSPs

IGP + MPLS case = integrated overlay model

Tripple mapping: IP traffic => FEC => set up LSP(s) => phys. network

consistent FEC policies

LSP route selection

IGP routing (metric definition / drive traffic into LSP) LSP resource reservations / admission control ? / traffic shaping ?

TE-Problems => TE strength !


7/14


DiffServ aware MPLS-TE Requirements

RFC3564 - 7/03

Requirements for Support of Differentiated Services-aware MPLS

Traffic Engineering

Behavior Aggregate (BA): same DSCP

Per-Hop-Behavior (PHB): BA treatment

PHB Scheduling Class (PSC): ordering

Ordered Aggregate (OA): ordered BAs

Traffic Aggregate (TA): DSCPs -> PHB

Tripple + mapping:

IP traffic => DS classes => FEC => set up LSP(s) => phys. network

TE-Problems => TE strength !

Traffic Trunk: aggregation of

traffic flows of same FEC

Traffic Trunk -> LSP(s)

E-LSP / L-LSP

Class-Type (CT): trunk + link

constraint

?

DS-MPLS-TE => different trunks -> independent LSP setups !


DiffServ-aware MPLS-TE Protocol Extensions

IGP-TE extensions

* RFC3630 - 9/03= OSPF-TE (Opaque Link State Advertisements)* RFC3784 - 5/04= ISIS-TE (extended Link State Protocol PDUs)

draft-ietf-tewg-diff-te-proto-07.txt - 3/04

Protocol extensions for support of DS-aware MPLS-TE

Bandwidth Constraints models: Max. Allocation / Russian Doll

RSVP-TE extensions* RFC3209 - 12/01= RSVP-TE (new objects for explicitly routed LSPs)

further extension for both defined herein => *

no changes to actual constraint-based routing algorithm !

* Maximum Reservable Bandwidth => aggregate bw constraint TLVs

* Unreserved Bandwidth TLV in IGP advertisements

* Class-Type object (format + handling)

* Error codes for CT object errors


8/14


Mapping (LSP overlay) : LSP => physical network mapping

traffic trunk attributes(configured or derived) - traffic parameters + policing -> ATM (theory of effect. BW)

- path selection + maintenance (resource inclusion/exclusion)

- priority, preemption, resilience attributes

resource attributes (configured) - maximum allocation multiplier (over-/under-booking factor)

- resource class attribute (e.g. coloring for resource addressing

-> policy application,inclusion/exclusion-> disjuncted paths etc.)

Constraint-based Routing / QoS Routing

Constraint-based Routing:

map traffic & resource attributes & topology information

simple solution: prune not matching resources + SPF


Most current activities

Current TE Requirement Drafts

draft-ietf-tewg-interarea-mpls-te-req-02.txt (June 2004)

draft-ietf-tewg-interas-mpls-te-req-07.txt (June 2004)

draft-ietf-mpls-p2mp-requirement-03.txt (July 2004)

inter-area = IGP areas of single authority

Inter-AS = IGP area coupling among different authorities P2MP = Point-to-Multi-Point (multicast LSPs)

P2P-LSP mesh -> head-end replication

P2MP-LSP -> branch point replication

Requirement draft: normative set of functional constraints for suggested solutions

guideline for definition, selection and specification of such solutions

problem description to clear understanding wish list


9/14


IGP metrics (within AS)

+BGP attribute (across ASes)

Inter-AS-MPLS Traffic Engineering solutions

1

Coarse control of paths

No bandwidth guaranties No fast recovery

No demand for TE in IP-only networks

IP/MPLS networks targeted

IGP-TE + RSVP-TE => RFC3785 5/04Use of Interior Gateway Protocol (IGP) Metric

as a second MPLS Traffic Engineering Metric

+

BGP attribute (across ASes)

Path computationupon multiple

constraints

Resource

reservation

2


BGP based Inter-AS Traffic Engineering

TE by enforced BGP-based inter-AS routing policies

"Closest exit" routing= egress traffic path defined by the lowest IGPor intra-AS MPLS TE tunnel metricsof the BGP next-hopof exterior

routes learned from other AS over the inter-AS links

"BGP path attribute" based routing= egress traffic path selectionby interconnect(peering or transit) policiesbased upon one or a

combination of BGP path attributes

Sub-optimum traffic distribution across inter-AS links

Un-deterministic traffic condition changes due to uncoordinated IGP and

BGP routing policies or topology changes within other AS


10/14


Inter-Area MPLS-TE extensions

traffic engineering database (no inter-area TE db update)

path calculation (split/per segment calculation by ABRs ->concept of loose routing object)

maintenance

protection/restoration


Signalling: RSVP-TE ! - CR-LDP (RFC3212) discontinued !(ordered controlled LSP setup / downstream-on-demand label binding)

head-end LSR to set up inter-area TE LSP + explicitly specify:

* set of LSRs (including ABRs) by means of strict or loose hops* signal certain resources to be explicitly excluded

Path optimizationacross AS borders

aim: same optimization strategy and quality as with single AS

=> CSPF across IGP areas !

Routing:IGP hierarchy confinement -> head end LSR only local

topology view (no end-to-end)

* maintain containment of routing information + preserve IGP scalability* preclude leaking across area of any TE Topology related information

* non topology related information (e.g. TE router ids) allowed

* inter-area TE-LSP not to be advertised as link in IGP !

Inter-Area TE - LSP Setup


11/14


Path computation:

- Per-area path computation based on ERO expansion on the

Head-End LSR and on ABRs, with two options for ABR

selection: * Static configuration of ABRs as loose hops at the head-end LSR.

* Dynamic ABR selection.

- Inter-area end-to-end path computation * e.g. recursive constraint based searching (ABR collaboration)

Route diversity:

* LSP protection (primary & backup LSP) * sum bandwidth constraint through set of multiple TE-LSPs (SRLGs)

Route protection * local mechanisms (e.g. Fast Reroute, ...)

* ensure LSP independant RSVP signalling

Inter-Area TE - LSP Setup (cont`d)


Inter-area RSVP-TE => ERO expansion Cisco wp example

ERO next hop = loose object -> compute a path to this loose hop


12/14


Inter-AS scenario: Extended or Virtual PoP (VPoP)

Inter-AS links

AS2 - SP2

P / PE

Inter-AS links

P / PE

AS1 SP1AS1 SP1 VPoP

PE

either Inter-AS MPLS-LSPs


Inter-AS scenario: Extended or Virtual Trunck

Inter-AS links

AS2 - SP2

P / PE P / PE

AS1 SP1Local loop

SP1 - CEs

either Inter-AS MPLS-LSPs


13/14


Inter-AS scenario: End-to-End

Inter-AS linksAS2 - SP2

P / PE P / PE

AS1 SP1

CE1

Inter-AS MPLS-LSP

CE2


What if ... AS already triggers setup of segement LSP

=> LSP nesting vs. updated loose hop advertisement ?

over-provisioned network is (currently) cheaper than

DS-aware-MPLS and still sufficient?

sufficient quality path cant be found ?

Expectation: MPLS-TE replaces overlay -> for sure

MPLS trunk support by almost static provision (explicit paths)

=> seems to be current practice

DS support possibly pushed into core by local area support

multicast support in the long run TE + DS + DS/MPLS interaction

=> simple(not optimal) & manageable(technical/juristical) solution


14/14


Thank you for your attention !

Knoll Mpls Te

Documents