1 / 21

AMPS/ANStool interop: Automated cross-domain QoS

AMPS/ANStool interop: Automated cross-domain QoS. Vangelis Haniotakis, GRnet / UoCrete TNC2007, Copenhagen, May 21 2007. Contents. Objective Introduction to QoS Multi-domain QoS Challenges AMPS QoS in GRnet ANStool AMPS-ANStool interoperability Development, testing and production.

romanor
Download Presentation

AMPS/ANStool interop: Automated cross-domain QoS

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. AMPS/ANStool interop: Automated cross-domain QoS Vangelis Haniotakis, GRnet / UoCrete TNC2007, Copenhagen, May 21 2007

  2. Contents • Objective • Introduction to QoS • Multi-domain QoS Challenges • AMPS • QoS inGRnet • ANStool • AMPS-ANStool interoperability • Development, testing and production

  3. Objective • To provision end-to-end network services • ... across multiple administrative domains • ... using automated, cooperating tools. • Our specific network service: QoS

  4. Introduction to QoS • Demands for QoS in IP networks • Streaming multimedia, VoIP, teleconferencing • Safety-critical traffic • DiffServ • Class-based, coarse-grained traffic management • Client marks outgoing IP packets (DS field) • DSCP 0: Best effort, • In GRnet: 40/46/47: Premium-class IP • Network forwards marked packets with high priority

  5. QoS multi-domain service • IMAGE

  6. Multi-domain QoS Challenges • Each domain may have its own way of implementing QoS • DSCP values and assigned priorities • Admission control • Resilience guarantees • Network core implementation • Allotted bandwidth for each service type • A QoS service spanning multiple domains means the various domains need to agree on service parameters.

  7. Solution • Automate the QoS provisioning across the domains! • GEANT SA3 developed AMPS (Advance Multi-Domain Provisioning System) for this purpose.

  8. AMPS architecture: • Each domain runs several agents : • An Inter-Domain agent for cross-domain operations, • A Network Information agent for pathfinding, and, • An Intra-Domain agent that implements local provisioning operations and network configuration • Agents intercommunicate using SOAP

  9. AMPS InterDomain • Receives provisioning requests from clients • Intercommunicates with neighbors to negotiate PIP requests • Does message passing across domains • Handles status and transactions for requests • Communicates with local IntraDomain agent • Utilizes local Pathfinder agent to determine the next InterDomain agent to handle the request

  10. AMPS IntraDomain • Receives provisioning requests from InterDomain agent • Utilizes local Pathfinder agent to determine the internal path • Configures the nodes on the path and implements the request

  11. AMPS Pathfinder • Is used by InterDomain and IntraDomain for both cross-domain and local pathfinding • Uses ICMP traceroute to determine paths, and ingress / egress nodes from an administrative domain • AMPS service model: bandwidth reservations happen on each link. • This is sensitive to transient network failures or other topology changes • Utilizes a network information database to determine neighboring domains

  12. QoS in GRnet • Each client is allotted a certain amount of PIP bandwidth • PIP bandwidth has been pre-provisioned everywhere in the core • we ensure that the network can handle max allowed traffic from all clients at once, even in worst-case scenario re: links failing • Assigning the amount of allowable PIP traffic to each link is done via a complex algorithm.. but this allows us to • decide whether to admit a PIP request based solely on boundary knowledge (i.e. without calculating PIP sums for core links), and • to provide QoS guarantees under adverse network conditions, such as individual or multiple link failures. • This is significantly different to the standard AMPS service model, so.. • Let’s replace the AMPS implementations with our own!

  13. GRNet Topology DB • A suite of tools that • discover network topologyand configuration • store it in a relational database • allow for queries on it • Version 1: • An ad hoc schema and plain SQL API • AMPS Network Information database derived from this • Version 2 (under development): • Unified schema for multi-layer topologies (similar to cNIS) • Object-oriented design and API • XML API • Google Maps integration • ...and lots more

  14. GRnet ANStool • A web application that • Provides a UI for submission of network service requests • Communicates with the topology database • Tracks the request through its lifecycle • Produces network configuration commands • Provisions local domain QoS and VPN services • A fork was adopted by HEAnet, and is in production use (BLUEnet) • ANStool can be adapted to both host and utilize provisioning-related, SOAP-based web services

  15. GRnet Intradomain • We adapted ANStool to handle requests from AMPS for PIP provisioning inside the GRnet domain • ANStool can already provision PIP in the GRnet domain through its UI • We only needed to map the AMPS functions to local functions • ... adapting local functions and service model where necessary

  16. GRnet AMPS interop

  17. GRnet Pathfinder • Was developed from scratch to implement the AMPS pathfinder interface • AMPS InterDomain needs a Pathfinder to report the ingress and the egress points for a request • Because our service model does not need to know every link in the path, we can deduce this information by querying core routers for the MPLS LSPs towards the source and the destination of the request • This is advantageous compared to traceroute, since it takes at most two queries

  18. GRnet AMPS client • We replaced the vanilla AMPS UI implementation with ANStool • ANStool is now also a SOAP client, calling AMPS Interdomain • Wrapper functions map local ANStool functions to AMPS SOAP calls • Benefit: unified GRnet user experience for both local and cross-domain requests

  19. Development, testing and production • ANStool was adapted to comply with AMPS as follows: • Local QoS service model was changed to accommodate uni-directional QoS requests • UI logic was tweaked to push domain-crossing requests to AMPS Interdomain • A SOAP server was written utilizing php_soap • Pathfinder was developed from scratch • Lots of testing. Asynchronous services with many actors are hard to debug... • AMPS-ANStool interop is in production since Apr 2007

  20. Acknowledgements • GEANT2 SA3 developed the AMPS suite and contributed to the interoperability project. • GRnet • Angelos Varvitsiotis developed the GRnet topology database, and Pathfinder module. • Computer Technology Institute of Patras • Dimitris Primpas and Christos Bouras designed and adapted the GRnet QoS service • University of Crete • Vangelis Haniotakis handled the ANStool core code issues, SOAP adaptation and tests

  21. For More Information • GEANT2: http://www.geant2.net/ • Toby Rodwell, Toby.Rodwell@dante.org.uk • GRnet: http://www.grnet.gr/ • Angelos Varvitsiotis, avarvit@grnet.gr • Christos Bouras, bouras@cti.gr • Vangelis Haniotakis, haniotak@ucnet.uoc.gr • ANStool: http://anstool.grnet.gr:6080/

More Related