Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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]
Thomas Martin Knoll Technische Universität Chemnitz
• Motivation
• Internet Routing Enhancements
• MPLS-TE -> DS-MPLS-TE
• Current TE Requirement Drafts
• Inter-AS solutions
Talk Outline
Thomas Martin Knoll Technische Universität Chemnitz
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.
Thomas Martin Knoll Technische Universität Chemnitz
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”
Thomas Martin Knoll Technische Universität Chemnitz
Internet Routing concept - Autonomous Systems
AS2
AS4
AS3AS1
IGP area
IGP area
IGP area
Thomas Martin Knoll Technische Universität Chemnitz
MPLS network
AS2
AS4
AS3AS1
MPLS network
IGP area
IGP area
IGP area
Thomas Martin Knoll Technische Universität Chemnitz
DiffServ aware MPLS
AS2
AS4
AS3AS1
MPLS network
DS domain DS domain
DS domain
Thomas Martin Knoll Technische Universität Chemnitz
• 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
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
MPLS-TE Requirements (cont‘d)
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
Thomas Martin Knoll Technische Universität Chemnitz
MPLS-TE Requirements (cont‘d)
• 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 !
Thomas Martin Knoll Technische Universität Chemnitz
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 !
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
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
Thomas Martin Knoll Technische Universität 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 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
Thomas Martin Knoll Technische Universität 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 Universität Chemnitz
• 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
Thomas Martin Knoll Technische Universität Chemnitz
• 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)
Thomas Martin Knoll Technische Universität 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 Universität Chemnitz
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
Thomas Martin Knoll Technische Universität Chemnitz
Inter-AS scenario: „Extended or Virtual Trunck“
Inter-AS linksAS2 - SP2
P / PE P / PE
AS1 – SP1Local loopSP1 - CEs
either Inter-AS MPLS-LSPs
Thomas Martin Knoll Technische Universität Chemnitz
Inter-AS scenario: „End-to-End“
Inter-AS linksAS2 - SP2
P / PE P / PE
AS1 – SP1
CE1
Inter-AS MPLS-LSP
CE2
Thomas Martin Knoll Technische Universität 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 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
Thomas Martin Knoll Technische Universität Chemnitz
Thank you for your attention !