Transcript - TERENA

Connect. Communicate. Collaborate
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
Connect. Communicate. Collaborate
Objective
Connect. Communicate. Collaborate
• To provision end-to-end network services
• ... across multiple administrative domains
• ... using automated, cooperating tools.
• Our specific network service: QoS
Introduction to QoS
Connect. Communicate. Collaborate
• 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
QoS multi-domain service
• IMAGE
Connect. Communicate. Collaborate
Multi-domain QoS
Challenges
Connect. Communicate. Collaborate
• 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.
Solution
Connect. Communicate. Collaborate
• Automate the QoS provisioning across the
domains!
• GEANT SA3 developed AMPS (Advance MultiDomain Provisioning System) for this purpose.
AMPS architecture:
Connect. Communicate. Collaborate
• 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
AMPS InterDomain
Connect. Communicate. Collaborate
• 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
AMPS IntraDomain
Connect. Communicate. Collaborate
• 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
AMPS Pathfinder
Connect. Communicate. Collaborate
• Is used by InterDomain and IntraDomain for both crossdomain 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
QoS in GRnet
Connect. Communicate. Collaborate
• 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!
GRNet Topology DB
Connect. Communicate. Collaborate
• 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
GRnet ANStool
Connect. Communicate. Collaborate
• 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
GRnet Intradomain
Connect. Communicate. Collaborate
• 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
GRnet AMPS interop
Connect. Communicate. Collaborate
GRnet Pathfinder
Connect. Communicate. Collaborate
• 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
GRnet AMPS client
Connect. Communicate. Collaborate
• 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
Development, testing and
production
Connect. Communicate. Collaborate
• 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
Acknowledgements
Connect. Communicate. Collaborate
• 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
For More Information
Connect. Communicate. Collaborate
• GEANT2: http://www.geant2.net/
– Toby Rodwell, [email protected]
• GRnet: http://www.grnet.gr/
– Angelos Varvitsiotis, [email protected]
– Christos Bouras, [email protected]
– Vangelis Haniotakis, [email protected]
– ANStool: http://anstool.grnet.gr:6080/