Upload
ibnsomeone
View
227
Download
0
Embed Size (px)
Citation preview
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]
Thomas Martin Knoll Technische Universitt Chemnitz
Motivation
Internet Routing Enhancements
MPLS-TE -> DS-MPLS-TE
Current TE Requirement Drafts
Inter-AS solutions
Talk Outline
8/10/2019 Knoll Mpls Te
2/14
Thomas Martin Knoll Technische Universitt Chemnitz
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.
Thomas Martin Knoll Technische Universitt Chemnitz
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
8/10/2019 Knoll Mpls Te
3/14
Thomas Martin Knoll Technische Universitt Chemnitz
Internet Routing concept - Autonomous Systems
AS2
AS4
AS3AS1
IGP area
IGP area
IGP area
Thomas Martin Knoll Technische Universitt Chemnitz
MPLS network
AS2
AS4
AS3AS1
MPLS network
IGP area
IGP area
IGP area
8/10/2019 Knoll Mpls Te
4/14
Thomas Martin Knoll Technische Universitt Chemnitz
DiffServ aware MPLS
AS2
AS4
AS3AS1
MPLS network
DS domainDS domain
DS domain
Thomas Martin Knoll Technische Universitt 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
8/10/2019 Knoll Mpls Te
5/14
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,
modelling,
characterisation, and
control of Internet traffic
=> achieve specific performance objectives (optimisation)
MPLS can help
Thomas Martin Knoll Technische Universitt Chemnitz
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
8/10/2019 Knoll Mpls Te
6/14
Thomas Martin Knoll Technische Universitt Chemnitz
MPLS-TE Requirements (contd)
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
Thomas Martin Knoll Technische Universitt Chemnitz
MPLS-TE Requirements (contd)
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 !
8/10/2019 Knoll Mpls Te
7/14
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
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 !
Thomas Martin Knoll Technische Universitt 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
8/10/2019 Knoll Mpls Te
8/14
Thomas Martin Knoll Technische Universitt 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 Universitt 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
8/10/2019 Knoll Mpls Te
9/14
Thomas Martin Knoll Technische Universitt 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/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
Thomas Martin Knoll 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 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
8/10/2019 Knoll Mpls Te
10/14
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
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
8/10/2019 Knoll Mpls Te
11/14
Thomas Martin Knoll Technische Universitt Chemnitz
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)
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
8/10/2019 Knoll Mpls Te
12/14
Thomas Martin Knoll Technische Universitt Chemnitz
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
Thomas Martin Knoll Technische Universitt Chemnitz
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
8/10/2019 Knoll Mpls Te
13/14
Thomas Martin Knoll Technische Universitt 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 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
8/10/2019 Knoll Mpls Te
14/14
Thomas Martin Knoll Technische Universitt Chemnitz
Thank you for your attention !