1. Connect. Communicate. Collaborate AMPS/ANStool interop: Automated cross-domain QoS Vangelis Haniotakis, GRnet / UoCrete TNC2007, Copenhagen, May 21 2007

2. Connect. Communicate. Collaborate Contents Objective Introduction to QoS Multi-domain QoS Challenges AMPS QoS in GRnet ANStool AMPS-ANStool interoperability Development, testing and production

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

4. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate QoS multi-domain service IMAGE

6. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate Solution Automate the QoS provisioning across the domains! GEANT SA3 developed AMPS (Advance Multi- Domain Provisioning System) for this purpose.

8. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate GRNet Topology DB A suite of tools that –discover network topology and 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate GRnet AMPS interop

17. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate 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. Connect. Communicate. Collaborate For More Information GEANT2: http://www.geant2.net/http://www.geant2.net/ –Toby Rodwell, Toby.Rodwell@dante.org.ukToby.Rodwell@dante.org.uk GRnet: http://www.grnet.gr/http://www.grnet.gr/ –Angelos Varvitsiotis, avarvit@grnet.gravarvit@grnet.gr –Christos Bouras, bouras@cti.grbouras@cti.gr –Vangelis Haniotakis, haniotak@ucnet.uoc.grhaniotak@ucnet.uoc.gr –ANStool: http://anstool.grnet.gr:6080/http://anstool.grnet.gr:6080/