- 4h ≤UA ≤8h implies service credit of 7*1/30
(one week); - UA ≥8h implies service credit of 30*1/30
(one month).
Other guarantees include:
Outage Notification Guarantee– Epoch guaran-
tees the customer that it will inform the customer
of any unexpected network unavailability within
1h of the occurrence of any guarantee break.
The customer will be informed by telephone or
email. If notification is delayed or not provided,
service credit of one day applies.
Internet Latency Guarantee– An average
monthly transmission rate of 85 ms or less is
guaranteed on the Epoch network. Latency
(average round trip transmission) is measured at
10-minute intervals and the average is calculated
monthly (at the end of every calendar month).
Service credit of one week will be provided if
the average Internet latency for a customer is
greater than 85 ms for any calendar month. If
it happens in two successive months, the service
credit is one month.
Packet Loss Guarantee– The average packet
loss ratio on the network will not be more than
5 % during any calendar month. It is measured
every 10 minutes and the average is calculated at
the end of each calendar month. One day of ser-
vice credit will be given to customers who expe-
rience a packet loss higher than 5 % per calendar
month.
Installation Guarantee– for web-hosting/co-
location services is implied 21 days after the
request is submitted. For a dedicated access ser-
vice, the installation requires up to 38 working
days after an order has been accepted and
entered into Epoch’s provisioning system. If this
is not met, the customer will receive one month
of service credit provided that the delay was not
caused by the customer or by any Force Majeure.
The equipment must be provided or approved by
Epoch and the customer has to co-operate, e.g.
to be present during the installation.
Regarding claims for service credit, they must be
submitted by a customer within seven business
days of the end of the month during which the
event occurred that gave rise to the claim. Epoch
also reserves the right to make changes to the
service level agreement.
6 International Fora and
SLAs/SLSs
As mentioned before, SLAs are present in the
telecom market, but in a slightly different form.
With emerging challenges for providing differ-
entiated IP-based services with QoS guarantees,
the interest for SLAs has increased rapidly.
Hence, the research on this topic is intensified.
In this section some examples of the work and
results from various standardisation bodies and
international fora related to SLAs are given.
First, an example of ITU-T agreement for the
telephony service is shown, followed by some
examples and the ongoing work from IETF on
the SLS topic, which is basically initiated by IST
projects Tequila and Aquila. The example of so-
called end-to-end SLA, from TMF (ex. NMF) is
described afterwards, and the EURESCOM pro-
jects P806-GI and P906-GI understanding of
SLAs and related issues are given at the end.
Note that several bodies studying this topic are
not discussed here, e.g. the DTMF SLA group.6.1 International Telecommunication
Union (ITU-T)
One example of an agreement can be found in
ITU-T Recommendation E.801 [E.801], which
describes a so-called Service Quality Agreement
(SQA) that is defined as “a bi- or multi-lateral
agreement between interconnecting ROAs9), net-
work providers and/or service providers, to initi-
ate a formalised programme for the monitoring,
measurement and setting of targets intended to
satisfy the end-user and other customers. When
appropriate, mutually agreed action plans will
be developed to improve a target that is below
the expected level of performance”.An SQA includes the following:- Introduction, e.g. describing the purpose of
the agreement; - Scope, e.g. the services covered and corre-
sponding interfaces are to be presented; - Confidentiality, for instance stating the confi-
dentiality concerning the content of the agree-
ment and sharing information between the
user and the provider; - Legal status, like stating the commitment to
fulfil the conditions; - Traffic patterns, e.g. describing relevant char-
acteristics of the traffic flows; - The relevant QoS parameters and correspond-
ing (range of) target values;
- ROAs (Recognised Operating Agencies).