Connect. Communicate. Collaborate

AMPS/ANStool interop: Automated cross-domain QoS

Vangelis Haniotakis, GRnet / UoCrete

TNC2007, Copenhagen, May 21 2007

Connect. Communicate. CollaborateContents

• Objective• Introduction to QoS• Multi-domain QoS Challenges• AMPS• QoS in GRnet• ANStool• AMPS-ANStool interoperability• Development, testing and production

Connect. Communicate. CollaborateObjective

• To provision end-to-end network services• ... across multiple administrative domains• ... using automated, cooperating tools.

• Our specific network service: QoS

Connect. Communicate. CollaborateIntroduction 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

Connect. Communicate. CollaborateQoS multi-domain service

• IMAGE

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.

Connect. Communicate. CollaborateSolution

• Automate the QoS provisioning across the domains!

• GEANT SA3 developed AMPS (Advance Multi-Domain Provisioning System) for this purpose.

Connect. Communicate. CollaborateAMPS 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

Connect. Communicate. CollaborateAMPS 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

Connect. Communicate. CollaborateAMPS 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

Connect. Communicate. CollaborateAMPS 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

Connect. Communicate. CollaborateQoS 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!

Connect. Communicate. CollaborateGRNet 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

Connect. Communicate. CollaborateGRnet 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

Connect. Communicate. CollaborateGRnet 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

Connect. Communicate. CollaborateGRnet AMPS interop

Connect. Communicate. CollaborateGRnet 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

Connect. Communicate. CollaborateGRnet 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

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

Connect. Communicate. CollaborateAcknowledgements

• 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

Connect. Communicate. CollaborateFor 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/