Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
MPLS Traffic Engineering:Checking Up Real-world Applicability
한국전자통신연구원 (ETRI)인터넷기술연구부
김창훈 {[email protected]}
KRnet 2001Internet Architecture Team / ETRI2
Table of ContentsWhat is MPLS-TE?
Definition, Necessity, Goals, and Vocabulary
MPLS-TE MechanismsLSP Routing, Traffic Protection, Load Balancing & Sharing, Path Reoptimization, FA LSPs, etc.
Real-world Deployment IssuesMPLS-TE Deployment Scenarios Practical Issues on MPLS TE DeploymentTE Servers
Ending Remarks
KRnet 2001Internet Architecture Team / ETRI3
Table of ContentsWhat is MPLS-TE?
Definition, Necessity, Goals, and Applications
MPLS-TE MechanismsLSP Routing, Traffic Protection, Load Balancing & Sharing, Path Reoptimization, FA LSPs, etc.
Real-world Deployment IssuesMPLS-TE Deployment ScenariosPractical Issues on MPLS TE DeploymentTE Servers
Ending Remarks
KRnet 2001Internet Architecture Team / ETRI4
What is Traffic Engineering?
The task of mapping traffic flows onto an existing physical topology to facilitate efficient and reliable network operations
Check mpls & tewg working group documents for more well-versed definitions
Requirements for Traffic Engineering Over MPLS (RFC 2702)A Framework for Internet Traffic Engineering (draft-ietf-tewg-framework-05.txt)
KRnet 2001Internet Architecture Team / ETRI5
Legacy Internet TE EffortsIGP Metric-Based TE
Remember “fish problem?”Drawbacks
“Blame Shifting”: only serves to move problem aroundLacks granularityInstability
Overlay Network ApproachATM core ringed by routers & overlaid PVCs on top of itDrawbacks
Full mesh overheadNot well integratedCell TaxATM SAR speed
KRnet 2001Internet Architecture Team / ETRI6
Benefits of MPLS
Low-overhead VCs for IPOriginally designed to make routers fasterNot true anymore!
Value of MPLS is now in TE, becauseMPLS can provide different path with different attributes for each different traffic flowIt doesn’t mean that metric-based TE can not accomplish this goal at all
a moot point!
KRnet 2001Internet Architecture Team / ETRI7
MPLS-TE!
Advantagesthe physical path of the “traffic-engineered path” is not limited to what the IGP would choose as the shortest path to reach the destinationprovides stand-by secondary paths and precomputed detouring pathsprovides strongly unified measurement and control for each “traffic-engineered path”provides traffic aggregation and disaggregation
KRnet 2001Internet Architecture Team / ETRI8
VocabularyLSP (Label Switched Path)
the “traffic-engineered path”
Primary and Secondary Pathsan LSP can contain a primary path & zero or more secondary paths
Named Patha sequence of explicit hops
LSP A
Primary Path Secondary Path
LSP B
Primary Path Secondary Path
Named Path 1
Named Path 2
KRnet 2001Internet Architecture Team / ETRI9
Vocabulary – cont’d
Traffic Trunk (TT)an aggregation of traffic flows going from an ingress to an egressforwarded through a common path with common TE requirementscharacterized by
its ingress and egressFEC a set of attributes that determines its behavioral characteristics
KRnet 2001Internet Architecture Team / ETRI10
Vocabulary – cont’d
Types of LSPsStatic LSPsLDP signaled LSPsRSVP/CR-LDP signaled LSPs
Explicit-path LSPsConstrained-path LSPsNote: both of the two above are not mutually exclusive!
KRnet 2001Internet Architecture Team / ETRI11
Components of MPLS-TE
Packet Forwarding ComponentMPLS, label switching itself
Information Distribution ComponentIGP (OSPF/IS-IS) extension
Path Selection ComponentConstrained Shortest Path First (CSPF) algorithm
Signaling ComponentLDP, CR-LDP, and RSVP-TE
Not all of these required!
KRnet 2001Internet Architecture Team / ETRI12
How everything fits into?
Link attributes
Link attributesmodification
RSVP signalingTED
LSP pathsCSPFLSP attributes
Routing table
advertised byIGP-extension
operatorinput
computes
structured as
reservation LSPestablishment
topology &resources
advertised byIGP-extension
KRnet 2001Internet Architecture Team / ETRI13
Table of ContentsWhat is MPLS-TE?
Definition, Necessity, Goals, and Applications
MPLS-TE MechanismsLSP Routing, Traffic Protection, Load Balancing & Sharing, Path Reoptimization, FA LSPs, etc.
Real-world Deployment IssuesMPLS-TE Deployment ScenariosPractical Issues on MPLS TE DeploymentTE Servers
Ending Remarks
KRnet 2001Internet Architecture Team / ETRI14
MPLS-TE Mechanisms
LSP Routingwith TE attributes (LSP & Link attributes)dynamic vs. explicit
Traffic Protection (Resilience)secondary paths and fast reroute
Path Reoptimization (Adaptivity)Load Sharing and Balancing
LSP-level traffic bifurcation
LSP Hierarchyforwarding adjacency LSPs, unnumbered links
KRnet 2001Internet Architecture Team / ETRI15
Configurable LSP AttributesCan specify the following attributes either for each LSP or for each path belonging to the LSP
bandwidth (traffic profile in CR-LDP)constrained (dynamic) vs. explicit pathaffinityadaptivity
reoptimize-timer, reoptimize-eventresilience
(stand by) secondary paths, fast reroutepriority & preemption
setup, holdroute recordhop-limit, cos, etc.
KRnet 2001Internet Architecture Team / ETRI16
Traffic Protection:Secondary Paths
LSPs may have zero or more secondary pathsSecondary Path Usage Procedure
fault detection failure notification secondary path computation secondary path signaling traffic switching-over ( retry to convert back)
When the path is “stand-by”fault detection failure notification traffic switching-over
Deficitsome loss may still exist
KRnet 2001Internet Architecture Team / ETRI17
Traffic Protection:Fast Reroute
Automatically reroutes traffic on an LSP using a pre-computed and pre-established detouring pathTraffic Protection Procedure
fault detection enabling detour failure notification (secondary path computation secondary path signaling) traffic switching-over
Failure onrouter C orlink B-C
router A
B
C
D
E
F
detour to skip A-B detour to skip C-D
detour to skip D-Edetour to skip B-C
detour to skip E-F
router A
B
C
D
E
F
KRnet 2001Internet Architecture Team / ETRI18
Path Reoptimization
Reoptimizationmeans adaptivity to network state evolution or degenerationis not related to fail-over (resilience);
a new path is always computed when topology failures occur that disrupt an established path
disabled by default due to stability concern
KRnet 2001Internet Architecture Team / ETRI19
Load Sharing & Balancing
Load SharingPath-level Load Sharing
not supported!LSP-level Load Sharing
supported, only when there are multiple LSPs in between the same ingress and egress pairload sharing factor might be manually setup or automatically determined in proportion to the bandwidth of each LSPprefix hashing not accurate!
Load Balancingis implicitly taken into account by CSPF
KRnet 2001Internet Architecture Team / ETRI20
LSP Hierarchy
An LSP might be used as an IGP link , a.k.a. forwarding adjacency (FA)
legacy hop-by-hop routed packets may use the LSP as a newly added linkother LSPs maybe recursively signaled over the LSP
by LDP, CR-LDP, and/or RSVP-TE
Such LSPs are calledFA LSPsIGP shortcutsunnumbered links
KRnet 2001Internet Architecture Team / ETRI21
LSP Hierarchy –cont’d
Use of FA LSPLocal use
Only the ingress of the LSP can utilize the LSPGlobal use
Other routers in the same domain can also use the LSPThe ingress must advertise the FA LSP to the IGP as a unidirectional point-to-point linkWe might need to configure a reverse LSP so that the SPF bidirectionality check succeeds
CautionIGP peering over FA LSPs must not be allowed!
KRnet 2001Internet Architecture Team / ETRI22
Advertising FA LSP and Its Metric
Now, how do we decide a path from A to D?Hop-by-hop A-B-C-D or A-E-(FA LSP)-D
The answer is comparing the metrics!FA LSPs must have static or dynamic metrics
What if both the two metrics are equal?ECMP load sharing
router A B C D
E F
FA LSP E-D
10 10 10
10
20
10 15
KRnet 2001Internet Architecture Team / ETRI23
Table of ContentsWhat is MPLS-TE?
Definition, Necessity, Goals, and Applications
MPLS-TE MechanismsLSP Routing, Traffic Protection, Load Balancing & Sharing, Path Reoptimization, FA LSPs, etc.
Real-world Deployment IssuesMPLS-TE Deployment ScenariosPractical Issues on MPLS TE DeploymentTE Servers
Ending Remarks
KRnet 2001Internet Architecture Team / ETRI24
General Guide for Deployment
High-level Steps for Fast DeploymentIdentify the Problem
congestion, too low or too high utilization, link/node failure, etc.
Gain Lab Experienceon a testbed
Test LSPs in Live Networkon a portion of production network
Deploy LSPs Along IGP Paths and Measureuses only RSVP signaling without CSPF
Reroute LSP to Explicit PathMonitor Results
KRnet 2001Internet Architecture Team / ETRI25
Deployment ScenariosFuturistic or Ideal Scenario
1. Identify each TT (Traffic Trunk) and its TE requirementsby autonomous policies or by SLA negotiationGranularity of TT might be various, from micro to macro
2. Construct FECs for the TT3. Design an LSP or a set of LSPs to route the TT4. Enforce the LSPs5. Measure and monitor network and traffic behavior6. Periodically adjust the attributes of the TT or the LSPs
Sometime, need to aggregated or disaggregate the TTs and LSPs
Standard information modeling for MPLS TEwork in progress in policy and mpls working groups
KRnet 2001Internet Architecture Team / ETRI26
Deployment Scenario – cont’d
Practical Scenario (currently feasible)1. Identify a specific TE problem2. Identify contributing flows
LSPs serve best for this purpose also3. Devise a cure for the problem using MPLS TE mechanisms
Adding a new FA LSP vs. rerouting an already existing oneUsing the LSP locally vs. globally?
4. Enforce the TE mechanisms5. Measure and monitor network and traffic behavior(Go to the step 1.)
AdvantagesLegacy hop-by-hop routing and IGP SPF still worksincorporates with metric-based TE
KRnet 2001Internet Architecture Team / ETRI27
Practical Scenario Example
1. Identify the problem the congestion2.1 Set up LSPs that simply follow the IGP path from
some routers to J2.2 Measure the traffic on the LSPs
LSP A-J : 70Mb the biggest contributorLSP B-J : 20MbLSP C-J : 30Mb, etc.
A
B
CD
E
F
31
1
J
H
G I1
1 1 1
1
1
1
2
1
KRnet 2001Internet Architecture Team / ETRI28
Practical Scenario Example – cont’d
3. Devise solutions and choose onesolution 1 : redirecting LSP A-J along another pathsolution 2 : adding a FA LSP between E and J that is actually routed along E-F-J
4. Enforce5. Measure and monitor network and traffic behavior
A
B
CD
E
F J
H
G I
1
KRnet 2001Internet Architecture Team / ETRI29
Deployment Sample Case
Global Crossing ltd.One of the 10 largest ISPs in the U.S.National backbone consists of ~50 POPs of more than 300 routersEnhanced IS-IS used as an IGP (all routers in the same level)All routers also runs BGP
Nation-wide MPLS deployment aimsBetter TE and VPN service provisioning
KRnet 2001Internet Architecture Team / ETRI30
Global Crossing’s Architecture
Two-tier ModelThe nation-wide network is divided into 9 regionsAll routers in each region are fully meshed to form the 1st layer of LSPs (100 ~ 2,500)Core routers in all regions are also fully meshed to form the 2nd layer of LSPs (100 ~ 2,500)
KRnet 2001Internet Architecture Team / ETRI31
Global Crossing’s General Guide
ProcedureCollect statistics using MPLS LSPs
By means of deploying LSPs without specifying their BW requirement and explicit pathPurpose is to collect traffic statistics in the interested areaCan induce the traffic matrix for the target network
Deploy LSPs with proper constraintsbandwidthexplicit hopsother TE attributes, if required
Periodic Update of the constraintsOffline Constraint-based Routing
KRnet 2001Internet Architecture Team / ETRI32
Practical Issues on Deployment
InteroperabilityDeficit of Online Path CalculationProblems regarding to Traffic TrunksMeasurement and Control Issues
KRnet 2001Internet Architecture Team / ETRI33
Interoperability
Vendor specific implementation details diverge!
Almost everything but signaling standard might be differentUsing more than two heterogeneous families in a domain may cause unpredictable operational problems
Need a unified abstraction system to hide, moderate, and arbitrate the differences
KRnet 2001Internet Architecture Team / ETRI34
Deficit of Online Path Calc.
Online path calc. considers one LSP at a time
undeterministicThe order in which an LSP is calculated plays a critical role!
Global optimization requiredOptimization tools that simultaneously examine each link’s resource constraints and the requirements of each LSPs all together are necessary
KRnet 2001Internet Architecture Team / ETRI35
Problems regarding to TTHow to define traffic trunks?
No standardManual classification
requires TE policiesgranularity and scalability concernpractically, only dest. prefix based classification supportedrequires, so called, “policy routing”
BGP-based classificationTransit traffic whose route updates’ next_hop is identical to the egress of an LSP are routed over the LSPonly supported by some implementation
Implicit classification by IGP
KRnet 2001Internet Architecture Team / ETRI36
Problems regarding to TT – cont’d
How to map a traffic trunk’s attributes onto LSPs’ constraints?
need a global viewmust be able to anticipate the effect, to some extentmust be able to rationalize
by simulationsby measurementsby policiesby intuition?by experience?
KRnet 2001Internet Architecture Team / ETRI37
Measurement and Control
Measurementprovides rationale and fundamental bases to induce proper TE constraints for TTs and LSPs
such as, traffic (demand) matrices, congestion indication, LSP statistics, etc.
methodsSNMP (various MIBs), CLI, Cisco Netflow and TMS, and/or JUNOS MPLS Statistics, RTFM probes, etc.
Controlmanages TE policies
policy editing, conflict check, enforcement, withdrawal, etc.customized to service specific policies, such as VPN policies
KRnet 2001Internet Architecture Team / ETRI38
TE Servers
PerformsProvisioning a Unified Management Environment
better interoperability
TE Policy ManagementNetwork & Traffic Measurement and AnalysesMPLS VPN ManagementSimulations and Analyses
failure simulationglobal optimization, etc.
Capacity Planning
KRnet 2001Internet Architecture Team / ETRI39
TE Servers:Products Introduction
WANDL, Inc. - MPLSView ®Automated data collection, layout, event collection and filtering (mainly focused on pre-configured LSPs)A quasi real-time view on the configuration of the network, including LSP set-up & state and per-LSP traffic flowPartnership with Cisco and Juniper
Makesystems, Inc. - NetMaker ®Network engineering and simulation tool for IP and MPLSMerged to OPNET Technologies, Inc.
Scalable Network Technologies, Inc. - QualNetOff-line network simulator for MPLS
ETRI - Wise<TE> ®
KRnet 2001Internet Architecture Team / ETRI40
Ending RemarksTraffic Engineering
the key to provide the advanced services, such asVoIP, VoMPLS, VPN, QoS, etc.
the most essential part in network management
MPLS TEone of the best fit for the Internet TEenlarges and expands the opportunity for better TEstill have a lot of interesting and debatable issues on deployment
adopting on-line/off-line TE serversIs MPLS TE really works better than metric-based TE?best practices for MPLS TEand so forth
trade-off!