Aktuelle Aktivitäten der IETF auf dem Gebiet der ... · Inter-area RSVP-TE => ERO expansion Cisco...

Thomas Martin Knoll Technische Universität Chemnitz

Aktuelle Aktivitäten der IETF auf demGebiet der Verkehrssteuerung

(Traffic Engineering) in MPLS-Netzen

ITG-FG 5.2.3 - Next Generation Networks10. Sitzung am 23. Juli 2004 in Chemnitz

Thomas KnollTU Chemnitz - Professur Daten- und KommunikationstechnikTelefon 0371 531 3246Email [email protected]


• Motivation

• Internet Routing Enhancements

• MPLS-TE -> DS-MPLS-TE

• Current TE Requirement Drafts

• Inter-AS solutions

Talk Outline


Networks offering connectionless IP datagram service provide

packet delivery along the shortest path with 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 behaviour for 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 Routinge.g. OSPF, RIP,

EIGRP

Routing Domain = IGP Routing Area

“interior router”

Hosts

Intradomain Routinge.g. OSPF, RIP,

EIGRP

Router

Routing Domain = IGP Routing Area

Hosts

Gateway / Area Border Router(“more intelligent” Router)

Router

Intradomain Routinge.g. OSPF, RIP,

EIGRP

Routing Domain = IGP Routing Area(Transit-Domain)

Interdomain Routinge.g. BGP

“border router”


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


DiffServ aware MPLS

AS2

AS4

AS3AS1

MPLS network

DS domain DS 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


MPLS-TE Requirements

RFC2702 - 9/99„Requirements for Traffic Engineering Over MPLS“

=> functional capabilities required to implement policies that facilitateefficient 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 (cont‘d)

Traffic oriented performance objectives:

Resource oriented performance objectives:

Single class best effortInternet service model

• packet loss,• delay,• throughput, and• enforcement of service level agreements

Differentiated servicesInternet

• 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



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 sharing helps - 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 !


DiffServ aware MPLS-TE Requirements

RFC3564 - 7/03„Requirements for Support of Differentiated Services-aware MPLSTraffic 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 oftraffic flows of same FEC

•Traffic Trunk -> LSP(s)•E-LSP / L-LSP•Class-Type (CT): trunk + linkconstraint

?

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


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


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/04“Use of Interior Gateway Protocol (IGP) Metricas a second MPLS Traffic Engineering Metric”+BGP attribute (across ASes)

– Path computationupon multipleconstraints

– Resourcereservation

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 metrics of the BGP next-hop of exteriorroutes learned from other AS over the inter-AS links

• "BGP path attribute" based routing = egress traffic path selectionby interconnect (peering or transit) policies based upon one or acombination of BGP path attributes

Sub-optimum traffic distribution across inter-AS links

Un-deterministic traffic condition changes due to uncoordinated IGP andBGP routing policies or topology changes within other AS


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 optimization across AS bordersaim: same optimization strategy and quality as with single AS=> CSPF across IGP areas !

• Routing: IGP hierarchy confinement -> head end LSR only localtopology 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


• Path computation:- Per-area path computation based on ERO expansion on theHead-End LSR and on ABRs, with two options for ABRselection: * 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


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

Inter-AS links

AS2 - SP2

P / PE

Inter-AS links

P / PE

AS1 – SP1AS1 – SP1 VPoPPE

either Inter-AS MPLS-LSPs


Inter-AS scenario: „Extended or Virtual Trunck“

Inter-AS linksAS2 - SP2

P / PE P / PE

AS1 – SP1Local loopSP1 - CEs

either Inter-AS MPLS-LSPs


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 can‘t 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


Thank you for your attention !

Aktuelle Aktivitäten der IETF auf dem Gebiet der ... · Inter-area RSVP-TE => ERO expansion Cisco...

Documents

Transcript of Aktuelle Aktivitäten der IETF auf dem Gebiet der ... · Inter-area RSVP-TE => ERO expansion Cisco...