there are two types of so-called specifications
included in the IP-based environment – an SLS,
and a Traffic Conditioning Specification (TCS),
which are also described here. The relationships
between these agreements/specifications are not
obvious, since different fora have made them for
different purposes and from the perspective of
offering different services on different infras-
tructures.
2.1 Business level – BLAs
On the business level between two actors3)a
Business Level Agreement (BLA) can be made.
It refers to the agreement made between two
legal entities/actors that includes a set of SLAs
and reflects the global business relationship
between the two actors involved. It is an
‘umbrella’ agreement, made on a business level,
which defines the frame within which the part-
ners may ‘move’ when negotiating any service
to be provided/used between them. In this type
of agreement, legal, economic (e.g. discount),
regulatory, etc. issues are stressed, rather than
technical details that are tackled in separate
SLAs covered by the BLA.
BLAs are made for the provision/usage of a set
of services, i.e. service packages. Such an agree-
ment is actually a function of the SLAs made
between the actors. For the generic case, the
functional dependability between various SLAs
(in particular the QoS parameters and their val-
ues) is not straightforward. It may be a mathe-
matical function (e.g. a sum) or any relational
function (e.g. lower than). On the other hand,
it might also be a rather complex relationship
between the sets of conditions. Assume, for
example, that the delay is a relevant QoS param-
eter and its maximum value should be decided
upon in the BLA. This value is a single value
(which simplifies the problem slightly). Con-
sider a selected set of traffic flows specifying
their maximum delay requirements. Then, pro-
viding a single value (for these traffic flows),
one may say that the worse case, that is, the min-
imum of the maximum delay requirements,
should be included as the statement in the BLA.
Some simplification when considering sets of
parameters may result in a less optimal use of
resources. Some steps could be taken, however,
like careful design, detailed specification of the
services sharing resources, user profile capturing
(e.g. time-of-day behaviour). Then, statements in
the BLA may be refined and the improved usage
of resources needed for assuring QoS used may
be obtained. Therefore, understanding the de-
pendencies between SLAs combined in a BLA
helps making adequate strategic decisions and
fulfilling user demands.In addition, situations where congestion may
occur are handled better, since reactions are
stated in the agreement. The conditions agreed
on in the BLA and SLA should be reflected in
both network elements’ configuration, mecha-
nisms and management solutions.2.2 Service level – SLAs
SLAs can be defined and used in the context of
any industry in which a provider-user relation-
ship exists. Hence, SLAs have been widely used
in different industries and businesses, for out-
sourcing services, e.g. help desks, catering ser-
vices, IT competence centre, etc.For traditional telecommunication services (e.g.
telephony) similar concepts covering similar
aspects (e.g. QoS) have been applied, which
might not have the form of an SLA. The pres-
ence and the concept of the SLA is rather unex-
plored for IP-based services, where many issues,
both technological and business, have still to be
studied. In addition, the situation is further com-
plicated by the fact that there is a shorter time to
roll out a service, the functionality included in
the applied technology varies a lot, and the
global picture of the market (user demands as
well as provider roles) is steadily changing.Basically, an SLA represents a harmonised
understanding between a user and a provider
regarding the service and the performance level
of the service required from the provider by the
user. It is designed in order to create and for-
malise a common understanding of the service,
quality of that service, prices/pricing schemes,
priorities, responsibilities, etc. In simple terms,
it should specify what the user will get and what
the provider is committed to provide. Various
aspects of the relationships between the parties
involved, like service/resource performance(s),
help desk, billing, provisioning, service manage-
ment, etc., can be included. As shown in Figure
2, an SLA would contain a set of SLSs (some
sources restrict an SLA to containing a single
SLS, but the issue of mapping SLAs and SLSs
is not so straightforward as will be discussed in
more detail in Chapter 7). SLAs contain much
more information than only SLS(s), related to
e.g. non-technical reactions, escalation schemes,
legal, regulatory, economic, business, ethical
issues.3)Note that a provider taking a role in the market is here called actor. Any legal entity, e.g. a com-
pany, is an actor when appearing in the market and using and/or providing a service or service
components.