ing more complicated by a shorter rollout time
for services, the functionality included in the
technology used nowadays still varies very much
(i.e. different technologies are still present in the
infrastructure supporting services like data trans-
fer, video, telephony, etc.), the technologies pre-
sent in the access portion are still evolving
towards those who can support high demand real
time services. In addition, the roles of a user/cus-
tomer and a provider are not so clear like in the
traditional telecom market, since any user may
be a provider to his users without having an
extensive set of equipment, but some value
added to the basic transport service(s). In short,
many issues, both technological and business,
have still to be studied in order to enable pro-
viders (and users) to capture and react in the
global IP market.
Understanding SLAs and their handling is
important for any provider that has to rely upon
its partners to offer any global service, and that
has to fulfil requirements of its users that may
easily use another provider if not satisfied. Hav-
ing a generic structure as presented in the previ-
ous chapter, enables providers to react fast (even
automated) when adapting to changes such as a
new role, introduction of a new service, changes
in the existing offer, introducing additional
mechanisms in the infrastructure, and so on.
Also, a process of negotiating SLAs is getting
more structured when using a template that is
independent of services, technologies, business.
Another important issue is that the practice used
in the traditional telecom does not have to be
abandoned by introducing new (multi-provider)
concepts and using SLAs.
Historically, the first SLAs in the Internet were
of peer-to-peer nature for public Network
Access Points (NAPs), whereby large backbone
providers make bilateral interconnection agree-
ments where the main issue is stating that the
volume of traffic a provider injects into the part-
ner’s network is equal to the traffic he should
allow coming into his own network from the
partner’s network (i.e. from a peer to a peer).
4.1 SLA Types for IP-based Services
SLAs for IP-based services will naturally be of
the same generic SLA types as presented in Sec-
tion 3.1, i.e. SLAs will differ according to the
level of detail included, language, nature of
parties involved, contracting period.
The interesting issue is actually whether an SLA
is agreed on a timely basis, i.e. in traditional
manner for a time period of e.g. one month (like
subscription for telephony service), or per ses-
sion, i.e. per each instantiation of a service. The
result of having SLA per session is a tremendous
amount of SLAs (and their respective content)
that have to be handled by providers. Therefore,
the issue of SLA management is getting more
pronounced.Regarding the performance level handled in the
SLA, three main categories are recognised:1.Application-level SLA– typically includes
statements for specifying the performance of
a specific application, e.g. the response time
of a database server will be less than 100 ms,
with a maximum of 100 clients connected
simultaneously, or the video server will be
available 99.9 % of the time during the
evening hours (between 1800 and 2400
hours), otherwise 95 % of the time. Another
example is statements included for a VoIP ser-
vice. The parameters chosen should reflect
both the speech quality and the connection
quality. In this case, different parameters are
used to express the quality of speech, and oth-
ers to express the connection quality. Some of
these are: Mean Opinion Score (MOS) for the
speech quality, and set-up delay for the con-
nection quality. Also, the differences caused
by e.g. realising a Voice over IP (VoIP) ser-
vice by implementing ITU-T’s H.323 [H.323]
or IETF’s Session Initiation Protocol (SIP)
[rfc2543], [sip], should be taken into account
when defining thresholds (or other objectives)
for the chosen parameters. For example, an
application level SLA for the VoIP service
may include the following: (1) the H.323 pro-
tocol suite is implemented, (2) NetMeeting™
is used as a client, (3) CPE characteristics
(including both hardware and software) are
specified, e.g. a Personal Computer (PC) with
a minimal hardware of a Pentium II (or equal)
CPU, 64 MB RAM, sound card, phone card,
loud speakers, microphone, or equivalent
headset, access to the IP network, and a mini-
mum software of the H.323 suite imple-
mented, and NetMeeting™, etc.2.Network-level SLA– deals with the perfor-
mance of the network offering a transport
service. Traditionally, in the Internet, a best-
effort service is offered, but now the paradigm
is changing in order to support real-time ser-
vices. Three different approaches can be
recognised5)(Figure 6):- Tunnel approach– defines aggregate QoS
between two specific points in the network.
5)Some argues that this way of organising SLAs better reflects the scope of the transport service pro-
vided, i.e. point-to-point (tunnel), point-to-multipoint (funnel), many-to-many point (cloud/hose).