1 / 37

RATES: A Server for MPLS Traffic Engineering (Routing And Traffic Engineering Server)

RATES: A Server for MPLS Traffic Engineering (Routing And Traffic Engineering Server). P.Aukia, M.Kodialam, P. V. Koppol, V. Lakshaham, H. Sarin, B. Suter. Zlatokrilov Haim Advanced Topics in IP Networks 5/1/2001 Tel-Aviv University. Schedule. Introduction MPLS Architecture

Download Presentation

RATES: A Server for MPLS Traffic Engineering (Routing And Traffic Engineering Server)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RATES: A Server for MPLS Traffic Engineering(Routing And Traffic Engineering Server) P.Aukia, M.Kodialam, P. V. Koppol, V. Lakshaham, H. Sarin, B. Suter Zlatokrilov Haim Advanced Topics in IP Networks 5/1/2001 Tel-Aviv University

  2. Schedule • Introduction • MPLS Architecture • Traffic engineering • Architecture considerations • On-line routing • On-line routing-RATES approach • RATES software

  3. MPLS • Picture

  4. Playground • Goal: • Make best use on network structure • One of the solutions: • Explicit routing in MPLS • Implementation • RATES

  5. 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

  6. Traffic engineering & MPLS • MPLS ability to control path from Ingress to Egress can optimize utilization

  7. 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)

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

  9. 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 protocols • Enables Traffic Engineering and classification along with signalling protocol like RSVP CR-LDP

  10. 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.)

  11. Architecture Considerations and Design Choices

  12. 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…

  13. 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.

  14. LSP Route Computation • Triggered by: • Request from ingress node • Network administrator • LSP path setup is done using on-line routing algorithm • Re-routing upon link failure • alternate routes for as many LSPs as possible

  15. 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

  16. 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 standards • Using COPS

  17. COPS • Common Open Policy Server • PDP & PEP • Framework • COPS vs. SNMP • RATES uses COPS for: • Installing packet classifiers • Installation of LSPs

  18. SCALE • RATES operates on a network within single OSPF area • Get a complete and not summarized view (easier for traffic engineering)

  19. LSP Restoration Options • Multiple levels of rerouting by reaction time/BW/ efficiency • Path 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 needed • Administrative rerouting is possible as well

  20. 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

  21. 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

  22. 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

  23. 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

  24. On-line routing-RATES approachMinimal Interface routing • Route using a shortest path computation on an appropriately weighted graph

  25. Example • All links with residual BW of 1 unit • Request 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

  26. 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

  27. Cont… • “Critical links”- • link with a property that whenever an LSP is routed the max-flows values of one or more ingress-egress pairs decreases • Algorithm 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

  28. RATES Software Architecture • Work within heterogeneous network • Only requirements: MPLS and RSVP capable • Java and C++ in Unix • Each module is a Unix process • Event driven with message bus • Based on CORBA

  29. Major modules

  30. Features • Definition of constrains • Monitoring the network topology • Provisioning of LSPs • Alert on certain anomalous events

  31. Graphical User Interface

  32. Application Programming Interface • Explicit route computation • Uses network state, policies and user requests • Based on “minimum Interface” algorithm • Easy addition of modules like • specifying SLAs by additional parameters • Addition of path computation algorithms

  33. Restoration of LSPs • Let RATES detect failures, and then explicitly reroute LSPs if needed • Usage of backup paths • Simultaneous setup with active path • Complete path protection (Sharing of backup paths) • Single link protection (Better BW usage)

  34. COPS Policy Server • Very little application specific semantics • Allows extensions • Client requests and Server replies and server asynchronous updates • In RATES: • Extensions for intra-domain traffic engineering • Installation of policies • For those do not support COPS modifications are required

  35. Network Topology and State Discover • Could be set fed statically • Dynamic data can be accepted using SNMP • Auto discovery of topology by OSPF protocol entity for topology and state discovery

  36. 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

  37. Thanks for the attention

More Related