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
knoll@infotech.tu-chemnitz.de

Thomas Martin Knoll

Technische Universitt Chemnitz

Talk Outline
Motivation
Internet Routing Enhancements
MPLS-TE -> DS-MPLS-TE
Current TE Requirement Drafts
Inter-AS solutions

Thomas Martin Knoll

Technische Universitt Chemnitz

Motivation
Networks offering connectionless IP datagram service provide
packet delivery along the shortest path with single class best
effort treatment.
Single Autonomous Systems (AS) have been extended to support
MPLS & DiffServ, which offers differentiated path selection and
differentiated forwarding behaviour for a set of traffic classes.
Extending these capabilities across AS borders is the current
hot topic - known as Inter-AS-MPLS-TE.

Thomas Martin Knoll

Technische Universitt Chemnitz

Internet Routing concept

Routing Domain = IGP Routing Area
Hosts
Router

Intradomain Routing
e.g. OSPF, RIP,
EIGRP

Hosts

interior router
Interdomain Routing
e.g. BGP
border router

Intradomain Routing
e.g. OSPF, RIP,
EIGRP

Intradomain Routing
e.g. OSPF, RIP,
EIGRP

Router
Router

Gateway / Area Border Router

(more intelligent Router)

Routing Domain = IGP Routing Area

(Transit-Domain)

Routing Domain = IGP Routing Area

Thomas Martin Knoll

Technische Universitt Chemnitz

Internet Routing concept - Autonomous Systems

AS3
AS1

AS2
IGP area
IGP area
IGP area

AS4

Thomas Martin Knoll

Technische Universitt Chemnitz

MPLS network

AS3
AS1

AS2
IGP area
IGP area
IGP area

MPLS network

AS4

Thomas Martin Knoll

Technische Universitt Chemnitz

DiffServ aware MPLS

AS3
AS1

AS2
DS domain

DS domain

DS domain

MPLS network

AS4

Thomas Martin Knoll

Technische Universitt Chemnitz

IETF - Working Groups

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)

Thomas Martin Knoll

Technische Universitt Chemnitz

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,
MPLS can help
modelling,
characterisation, and
control of Internet traffic
=> achieve specific performance objectives (optimisation)

Thomas Martin Knoll

Technische Universitt Chemnitz

MPLS-TE Requirements (contd)

Traffic oriented performance objectives:

packet loss,
delay,
throughput,
and
enforcement of service level agreements
peak to peak packet delay variation,
loss ratio, and
maximum packet transfer delay

Single class best effort

Internet service model

Differentiated services
Internet

Resource oriented performance objectives:

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

Thomas Martin Knoll

Technische Universitt Chemnitz

MPLS-TE Requirements (contd)

Traffic Engineering = control problem !
IGP case
SPF = topology driven (no BW availability, no traffic characteristic)
=> causes congestion !
All matching traffic onto single path
=> equal cost path load sharing helps - falls down on stream convergence

IGP + Overlay case

overlay model: IP over ATM / IP over Frame Relay
=> virtual channels advertised as IGP links -> works -> very expensive!
+ constraint-based VC routing
+ configurable explicit VC paths
+ admission control functions
+ traffic shaping and traffic policing functions
+ VC protection

Thomas Martin Knoll

Technische Universitt Chemnitz

MPLS-TE Requirements (contd)

IGP + MPLS case

= integrated overlay model

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

TE-Problems => TE strength !

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 ?

Thomas Martin Knoll

Technische Universitt Chemnitz

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

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 !

TE-Problems => TE strength !

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

Thomas Martin Knoll

Technische Universitt Chemnitz

DiffServ-aware MPLS-TE Protocol Extensions

draft-ietf-tewg-diff-te-proto-07.txt - 3/04
Protocol extensions for support of DS-aware MPLS-TE

IGP-TE extensions
* RFC3630 - 9/03 = OSPF-TE (Opaque Link State Advertisements)
* RFC3784 - 5/04 = ISIS-TE
(extended Link State Protocol PDUs)
* Maximum Reservable Bandwidth => aggregate bw constraint TLVs
* Unreserved Bandwidth TLV in IGP advertisements

RSVP-TE extensions
* RFC3209 - 12/01 = RSVP-TE (new objects for explicitly routed LSPs)
* Class-Type object (format + handling)
* Error codes for CT object errors

further extension for both defined herein => *

no changes to actual constraint-based routing algorithm !
Bandwidth Constraints models: Max. Allocation / Russian Doll

Thomas Martin Knoll

Technische Universitt Chemnitz

Constraint-based Routing / QoS Routing

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:
map traffic & resource attributes & topology information
simple solution: prune not matching resources + SPF

Thomas Martin Knoll

Technische Universitt Chemnitz

Current TE Requirement Drafts

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

Most current activities

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

Thomas Martin Knoll

Technische Universitt Chemnitz

Inter-AS-MPLS Traffic Engineering solutions

IGP metrics (within AS)
+
BGP attribute (across ASes)

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/04
Use of Interior Gateway Protocol (IGP) Metric
as a second MPLS Traffic Engineering Metric

+
BGP attribute (across ASes)

Thomas Martin Knoll

Path computation
upon multiple
constraints
Resource
reservation

Technische Universitt Chemnitz

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 IGP

or intra-AS MPLS TE tunnel metrics of the BGP next-hop of exterior

routes learned from other AS over the inter-AS links
"BGP path attribute" based routing = egress traffic path selection
by interconnect (peering or transit) policies based 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

Thomas Martin Knoll

Technische Universitt Chemnitz

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

Thomas Martin Knoll

Technische Universitt Chemnitz

Inter-Area TE - LSP Setup

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 optimization across 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 !

Thomas Martin Knoll

Technische Universitt Chemnitz

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

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

Thomas Martin Knoll

Technische Universitt Chemnitz

Inter-area RSVP-TE => ERO expansion

Cisco wp example

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

Thomas Martin Knoll

Technische Universitt Chemnitz

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

either Inter-AS MPLS-LSPs

Inter-AS links

AS1 SP1 VPoP

PE

Thomas Martin Knoll

Inter-AS links

P / PE

P / PE

AS2 - SP2

AS1 SP1

Technische Universitt Chemnitz

Inter-AS scenario: Extended or Virtual Trunck

either Inter-AS MPLS-LSPs

P / PE
Local loop AS2 - SP2
SP1 - CEs

P / PE
Inter-AS links

AS1 SP1

Thomas Martin Knoll

Technische Universitt Chemnitz

Inter-AS scenario: End-to-End

Inter-AS MPLS-LSP
CE2

CE1
P / PE
AS2 - SP2

Thomas Martin Knoll

P / PE
Inter-AS links

AS1 SP1

Technische Universitt Chemnitz

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

Thomas Martin Knoll

Technische Universitt Chemnitz

Thank you for your attention !