If other ASPs are required to provide the same type of SLA monitoring and 

verification, an additional proxy will have to be deployed and configured by the 

customer for each ASP adding to management and processing overhead. 

Provides no way to compare performance of services provided by different ASPs. 

Leading on from this architecture, the idea of SLA verification as a service will be 

considered. In this scenario, the customer or the ASP may approach a third party to verify 

that the service is SLA compliant. This has a number of advantages. 

Only one proxy needs to be deployed to monitor multiple services from multiple 

ASPs. In this case, the party that delivers the SLA Verification Service will 

provide the proxy to the customer 

The Customer may prefer having an independent third party verify SLA 

compliance. 

The SLA Verification Service Provider (SLAVSP) can monitor multiple service 

from multiple providers and possibly provide information to the ASP that 

provides each service. 

To enable a third party to provide this service, it needs access to the SLA for the Customer 

and performance and available data captured by the proxy that the customer uses. Clearly co 

operation is required between all parties involved in the service including the Customer, 

ASP and the SLAVSP 

The ASP will still want to know how the service is performing for its Customers. However, 

the ASP now has the option of taking the data collected by the proxy and analysing it 

directly, or a more flexible approach would be for the SLAVSP to report on SLA 

Compliance. Since the proxy can do a certain amount an analysis locally, a mechanism may 

also be introduced whereby once the proxy detects that the service is not performing to 

specification, it alerts the ASP. The ASP may then retrieve information from the SLAVSP to 

diagnose the problem.