Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 214 times |
Download: | 0 times |
RATES: A Server for MPLS Traffic Engineering
(Routing And Traffic Engineering Server)
Zlatokrilov HaimAdvanced Topics in IP Networks 5/1/2001
Tel-Aviv University
P.Aukia, M.Kodialam, P. V. Koppol, V. Lakshaham, H. Sarin, B. Suter
Schedule
IntroductionMPLS Architecture
Traffic engineering
Architecture considerations
On-line routing
On-line routing-RATES approach
RATES software
MPLS
Picture
Playground
Goal: Make best use on network structure
One of the solutions:Explicit routing in MPLS
ImplementationRATES
IP Routing
Shortest paths computed using mostly static (usually traffic characteristic independent) link metrics
Enough for connectivity
Possibly bad use of available network resources• Unable to use alternate paths
• Potential for better QoS on the same infrastructure
Traffic engineering & MPLS
MPLS ability to control path from Ingress to Egress can optimize utilization
Offline Routing
All tunnels or LSPs and resources requests are know at the time the routing is done
Can be very affective
In practice demands may change in time
Problem: accommodate of new requests
Possible solution: rerouting of existing connections (not desirable)
On-Line Routing
Depends on information from routing protocols (OSPF IS-IS)
In LSP this link state database could be used
Difficult to obtain delay and buffer usage
RATES: uses only link state and bandwidth information for path selection
MPLS and Bandwidth guaranteed LSPs
Usage of LSPs as components of an IP Virtual-Private-Network (VPN) with bandwidth guaranties to satisfy Service-Level-Agreements (SLA).
LSP is then a “virtual traffic trunk” for flows with “Forwarding Equivalence Classes” (FEC)Classification of traffic (ToS bits, source etc.)FECs from policy server or other protocolsEnables Traffic Engineering and classification along with signalling protocol like RSVP CR-LDP
LSPs in RATES
Uses bandwidth guaranteed routes
What about other SLA metrics like: Jitter, Loss, Latency?
Concentrating on BW because the most common
If other SLA constrains -> convent the SLA to traffic effective BW ?!
Taking other metric into account is too complicated (policies etc.)
Architecture Considerations and Design
Choices
Centralized vs. Distributed implemetation
The algorithms used in RATES use only information obtainable distributedly via extensions to routing protocols (OSPF and IS-IS extensions for traffic engineering)
“Until the completion of standards distributed implementation is not desirable” ?!?!?!?!
Maybe it’s just easier…
Obtaining link state information
SNMP (Simple Network Management Protocol) Standardized MIBs for QoS related link and nodal attributes
Get link state data as part of protocol operation (only if extension exists)RATES – OSPF peering to obtain topology information and node states (up/down)
GUI for providing parameters as BW etc.Responsible for all BW allocation, enables keeping track of reserved and available BW.
LSP Route Computation
Triggered by:Request from ingress nodeNetwork administrator
LSP path setup is done using on-line routing algorithm
Re-routing upon link failurealternate routes for as many LSPs as possible
Policies
Packet classification for redirection of IP packets to LSPs
Routing tables that use LPS as next hop
RATES provides GUI for administrators to specify these policies
Installing an LSP route
Hop-by-hop provisioning (like ATM)Server communicates with source of route and spawns signalling from source to destination for route setup (like soft PVC in ATM)RATES: second option
No standardsUsing COPS
COPS
Common Open Policy ServerPDP & PEP
Framework
COPS vs. SNMP
RATES uses COPS for:Installing packet classifiers
Installation of LSPs
SCALE
RATES operates on a network within single OSPF area
Get a complete and not summarized view (easier for traffic engineering)
LSP Restoration Options
Multiple levels of rerouting by reaction time/BW/ efficiencyPath protected by backups:
Full associated BW reservation Shared or partially shared BW (requires extensions for MPLS)
Rerouting decision made by ingress router, no interaction with RATES neededAdministrative rerouting is possible as well
On-Line Routing
Along path:Residual BW=link BW–sum of LSP demand
Feasible link: if BW demand < link BW
Feasible network: all feasible paths
Objective: reject as few LSP request as possible
On-line routing-State of the ART
Min-hop algorithm (least number of feasible links
Simple
Not taking ingress-egress pair information
Does not adapt routing to increase successful rerouting
Easy to improve
Other Proposals
Widest Shortest Path algorithm (WSP)Feasible min-hop path with maximum residual path bottleneck link capacity
Not taking ingress-egress information into account
Without min-hop restriction does not work well
Cont…
Other algorithms:
Taking residual BW on link to influence the weight
Paths chosen with respect to dynamically changing weights
Idea: Not to use link capacity completely if alternate lower loaded path available
Disadvantage: not taking ingress-egress information, may make long paths
On-line routing-RATES approachMinimal Interface routing
Route using a shortest path computation on an appropriately weighted graph
Example
All links with residual BW of 1 unitRequest for LSP between S3 and D3 with BW=1
In min-hop: the route in 1-7-8-5 1-2-3-4-5 is better even though longer
Possible Objectives of on-line Routing
Key idea: pick paths that do not interfere too much with optional future LSP set-up requests between other source-destination pairs
Look for path that maximizes the minimum max-flow between all other ingress-egress pairs
Another possible objective: pick a path that maximizes a weighted sum of the max-flows between every other ingress-egress pair
Cont…“Critical links”-
link with a property that whenever an LSP is routed the max-flows values of one or more ingress-egress pairs decreasesAlgorithm for computation of such links
RATES: generating weighted graph where “critical links” have weights with increasing function.
The actual route is calculated using shortest path algorithms
RATES Software Architecture
Work within heterogeneous networkOnly requirements: MPLS and RSVP capable
Java and C++ in Unix
Each module is a Unix process
Event driven with message bus
Based on CORBA
Major modules
Features
Definition of constrains
Monitoring the network topology
Provisioning of LSPs
Alert on certain anomalous events
Graphical User Interface
Application Programming Interface
Explicit route computationUses network state, policies and user requests
Based on “minimum Interface” algorithm
Easy addition of modules likespecifying SLAs by additional parameters
Addition of path computation algorithms
Restoration of LSPs
Let RATES detect failures, and then explicitly reroute LSPs if needed
Usage of backup pathsSimultaneous setup with active path
Complete path protection (Sharing of backup paths)
Single link protection (Better BW usage)
COPS Policy Server
Very little application specific semanticsAllows extensionsClient requests and Server replies and server asynchronous updatesIn RATES:
Extensions for intra-domain traffic engineeringInstallation of policiesFor those do not support COPS modifications are required
Network Topology and State Discover
Could be set fed staticallyDynamic data can be accepted using SNMP
Auto discovery of topology by OSPF protocol entity for topology and state discovery
Edge Routers Requirements
Designated Ingress and Egress points of traffic engineering domain
Needs to support:MPLS tunnels and signalling RSVP+extensions
Filtering at packet route level
COPS with the required extensions
Thanks for the attention