Aktuelle Aktivitäten der IETF auf dem Gebiet der Verkehrssteuerung (Traffic Engineering) in MPLS-Netzen

Transcription

1 Aktuelle Aktivitäten der IETF auf dem Gebiet der Verkehrssteuerung (Traffic Engineering) in MPLS-Netzen ITG-FG Next Generation Networks 10. Sitzung am 23. Juli 2004 in Chemnitz Thomas Knoll TU Chemnitz - Professur Daten- und Kommunikationstechnik Telefon knoll@infotech.tu-chemnitz.de Talk Outline Motivation Internet Routing Enhancements MPLS-TE -> DS-MPLS-TE Current TE Requirement Drafts Inter-AS solutions

2 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. Internet Routing concept Routing Domain = IGP Routing Area Hosts Router Intradomain Routing e.g. OSPF, RIP, EIGRP interior router Interdomain Routing e.g. BGP Hosts border router Intradomain Routing e.g. OSPF, RIP, EIGRP Router Routing Domain = IGP Routing Area (Transit-Domain) Gateway / Area Border Router ( more intelligent Router) Intradomain Routing e.g. OSPF, RIP, EIGRP Router Routing Domain = IGP Routing Area

3 Internet Routing concept - Autonomous Systems AS1 AS2 AS3 IGP area IGP area IGP area AS4 MPLS network AS1 AS2 AS3 IGP area IGP area IGP area MPLS network AS4

4 DiffServ aware MPLS AS1 AS2 AS3 DS domain DS domain DS domain MPLS network AS4 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 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)

5 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, MPLS can help characterisation, and control of Internet traffic => achieve specific performance objectives (optimisation) MPLS-TE Requirements (cont d) 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 Resource oriented performance objectives: Single class best effort Internet service model Differentiated services Internet 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 MPLS-TE Requirements (cont d) IGP case 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 + 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 MPLS-TE Requirements (cont d) 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?

7 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 TE-Problems => TE strength! Tripple + mapping: IP traffic => DS classes => FEC => set up LSP(s) => phys. network? DS-MPLS-TE => different trunks -> independent LSP setups! 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 * RFC /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

8 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 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

9 Inter-AS-MPLS Traffic Engineering solutions 1 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 2 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) Path computation upon multiple constraints Resource reservation 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

10 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 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!

11 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 Inter-area RSVP-TE => ERO expansion Cisco wp example ERO next hop = loose object -> compute a path to this loose hop

12 Inter-AS scenario: Extended or Virtual PoP (VPoP) either Inter-AS MPLS-LSPs Inter-AS links Inter-AS links AS1 SP1 VPoP PE P / PE AS2 - SP2 P / PE AS1 SP1 Inter-AS scenario: Extended or Virtual Trunck either Inter-AS MPLS-LSPs P / PE P / PE Local loop SP1 - CEs AS2 - SP2 Inter-AS links AS1 SP1

13 Inter-AS scenario: End-to-End Inter-AS MPLS-LSP CE1 CE2 P / PE AS2 - SP2 Inter-AS links P / PE AS1 SP1 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

14 Thank you for your attention!