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

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