supported. Research and the trials of different
implementations are improving the knowledge,
but the real-life implementation causes the ‘soft-
ness’ of SLAs. In short, today’s SLAs cannot
promise more than what is technically possible
to support. However, this fact does not mean that
the future is not very bright for the SLA. When
the technology is evolving the SLAs have a pos-
sibility of including even ‘hard’ QoS guarantees.
Acquiring more experience and deciding on the
mechanisms that are crucial and optimal, not
only differentiated services may be offered, but
also the QoS guarantees can be assured. This
implies that the content of SLAs would include
sharpened values.
As shown in the examples of existing SLAs pre-
sented in Chapter 4, the selection of QoS param-
eters describes the performance of communica-
tions between any two points within a network.
The way of realising and handling SLAs are typ-
ically of a cloud type since that is the easiest to
specify and support. After introducing the addi-
tional features/functionality in the IP-based net-
work, moving towards stricter QoS guarantees
will be feasible and the SLAs would be of the
tunnel/funnel types. The granularity could cover
a single packet, flow, session, monthly subscrip-
tion, 10-year agreement, etc.
Naturally, no prediction can be certain and obvi-
ously many issues are still open both related to
the usage and applicability of the mechanisms to
support the QoS architecture [rfc2990]. But it is
given in different surveys that it is better to give
some guarantees and feedback to the customers
rather than to lean on best effort services for a
provider who wants to build/keep brand-name
and attract/preserve loyalty of customers. There-
fore, SLAs undoubtedly have a future, both in
single- and multi-provider situations, although
there are still many open issues to be studied
further. In the case where a single provider pro-
vides its services by crossing only one adminis-
trative domain that he owns/controls, the SLA
is still needed to formalise the behaviour of cus-
tomers and the resulting expectations related to
QoS.
References
[aquila] Salsano, S et al. 2000. Definition and
usage of SLSs in the AQUILA consortium.Inter-
net Draft. draft-salsano-aquila-sls-00.txt.
[Cain97] Caine, A. Negotiating an Effective Ser-
vice Level Agreement.Gilbert&Tobin, 1997.
http://www.gtlaw.com.au
[diffserv] IETF DiffServ WG charter.(2001,
October 8) [online] – URL: http://www.ietf.org/
html.charters/diffserv-charter.html
[E.801] ITU-T. Framework for service quality
agreement.Geneva, 1996. (ITU-T E.801.)[epoch] Epoch Internet web site.(2001, October
8) [online] – URL: http://www.epoch.net[epoch-a] Epoch Internet SLA-related web site.
(2001, October 8) [online] – URL: http://www.
epoch.net/corpinfo/sla_access.html[epoch-sla] Epoch Internet SLA-related web site.
URL: http://www.epoch.net/corpinfo/
agreements.html[epoch-w] Epoch Internet SLA-related web site.
URL: http://www.epoch.net/corpinfo/
sla_hosting_colo.html[ETR003] ETSI. Network Aspects: general
aspects of Quality of Service and Network Per-
formance.Sophia Antipolis, 1994. (ETR 003.)
(ref. RTR/NA-042102).[GB917] TMF.GB917 SLA Management Hand-
book, Member Evaluation version 1.0.Novem-
ber 2000. (TMF GB917.)[Gray00] Gray, J. Negotiating An Effective Ser-
vice Level Agreement – II.Sydney, Gilbert&
Tobin, 2000.[I2-site] Internet 2 project site. URL:
http://www.internet2.edu/html/about.html[I.350] ITU-T. General Aspects of Quality of
Service and Network Performance in Digital
Networks, including ISDN.Geneva, 1993.
(ITU-T I.350.)[id-term] Grosmann, D. New terminology for
diffserv.draft-ietf-diffserv-new-terms-04.txt.
IETF, March 2001.[many] IETF. T’Jones, Y et al. Service Level
Specification and Usage Framework.Internet
Draft, October 2000. http://www.ietf.org/inter-
net-drafts/draft-manyfolks-sls-framework-00.txt[NMF701] Network Management Forum. Per-
formance Reporting Definitions.1997. (NMF
701.)[policy] IETF policy WG charter.http://www.
ietf.org/html.charters/policy-charter.html[P806d1] EURESCOM. EQoS – A common
framework for QoS/NP in a multi-provider
environment.Heidelberg, 1999. (EURESCOM
P806-GI Deliverable 1.)