Verification and certification of service-level agreements

General description: 

The ubiquity of Internet access, and the wide variety of Internet-enabled devices, have made the Internet a principal pillar of the Information Society. As the importance of the Internet to everyday life grows, reliability of the characteristics of Internet service (availability, throughput, delay, etc.) grows important as well. Service Level Agreements (SLAs) between providers and customers of Internet services regulate the minimum level of service provided in terms of one or more measurable parameters.

The verification of an SLA is technically equivalent to the verification of the implicit guarantees of service made by a provider offering Internet service. Currently SLAs are tested in terms of some network performance parameters as "bandwidth'' (generally expressed in terms of raw throughput). However, with the evolution of the applications SLAs will regard aspects more and more related to user perception.

mSLAcert was developed for the verification and certification level agreement. It is composed of two components, a server and an agent. The measurement is based on RTT tests and TCP/UDP downloads from server to agent; at end of the download tests the agent sends a report back to the server, reporting the measured parameters. The reasoner can request additional tests for the SLA verification to the supervisor. The supervisor, sends the test specifications to the probe, which after completing the test it will send the data back to the supervisor, that could also be seen by the reasoner. After the result comparison carried out by the reasoner, a PDF paper will prepared to certify the delay and throughput measured by the agent.

The main mplane components involved in this use case

In the figure below are describet the mPlane components involved in this use case.

The main mplane component involved in this use case are the active probe (mSLAcert) the supervisor and the reasoner. The probe will do the active measurements based on the specification that they have (step 1), it will test RTT, throughput, jitter and datagram loss. After that the probes do the measurements the data is stored on the repository, in this use case the amount of data is small so the data is stored locally (step 2-3). When a measurement is finished the reasoner checks the data for possible problems (step 4,7,9). Based on the result of the reasoner, it can request new measurement from the probes, with different specifications (step 5,8,10) or request additional analysis from the repository (step 11). In case the reasoner will determine that all the measurements are correct it will ask the Supervisor to release a PDF that will certify the RTT and throughput of the client (step 6 and 12).

How to setup and deploy the use-case  

For the detailed instructions on the deployment, setup, and demo of the use-case we refer interested readers to the corresponding demontration guidelines page (link).