2.5 Determining traffic level – TCS
This term also relates to the provisioning of IP
services and is defined by the IETF. According
to the new terminology for the DiffServ WG of
the IETF [id-term], a TCS is a term related to the
DiffServ architecture, and should be understood
as “a set of parameters and their values which
together specify a set of classifier rules and a
traffic profile”. A TCS is an integral element
of an SLS.
3 Service Level Agreement
(SLA)
Facing the situations described in the introduc-
tion where changes are rather dynamic, the need
to describe principles for efficient arranging of
relationships between the actors is steadily get-
ting more pronounced. Generally speaking, any
relationship between two actors is associated
with a set of expectations as well as a set of obli-
gations. A Service Level Agreement(SLA) is an
explicit statement of the expectations and obliga-
tions that are agreed between two actors: a cus-
tomer and a provider [Verm99]. This term has
been used for a long time, and therefore many
different definitions of the term SLA exist.
These are developed by different fora for partic-
ular purposes, and are basically not competing
or overlapping, but rather have different focus.
The discussion on the term itself is omitted here;
some definitions of SLA (and more generally of
an agreement) can be found in [NMF701],
[P806d1], [Cain97], [Gray00].
Generally speaking, SLAs can be defined and
used in the context of any industry in which a
customer-provider relationship exists. Hence,
SLAs have been widely used in different indus-
tries and businesses for outsourcing services,
e.g. help desks, catering services, IT competence
centre, etc. For traditional telecommunication
services (e.g. telephony) similar concepts cover-
ing similar aspects (e.g. QoS) have been applied,
which did not have the form and name of an
SLA. The presence and the concept of the SLA
are getting revitalised as an area of research in
the IP-based environment, as discussed in the
next chapter. The SLA is designed in order to
create a common understanding of the service,
quality of that service, prices/pricing schemes,
priorities, responsibilities, etc.
A harmonised understanding may require a
negotiation process, a result of which is (a set
of) SLAs. The SLA negotiation process is very
demanding, and the team of experts from differ-
ent fields (e.g. technology (network architecture,
QoS, management, billing), economy and busi-
ness (strategic decisions, pricing, charging
schemes), law (jurisdictional, regulatory issues),
social science (anthropological, ethical issues)
may be involved. Before even starting the nego-
tiation process needs, gains, and business goals,
should be determined from both provider’s and
user’s point of view. Each team has to be aware
of main goals, limitations, capabilities, which
services to produce and which to buy (‘home-
made’ vs. ‘imported’ services), and to have
clearly determined core business and strategic
streamlines. After that, before making an SLA,
some preparation should be done so that the
starting situation is determined and described.
From a provider’s point of view, operational
capabilities and strategic position for different
functionality/systems have to be addressed and
known, e.g. billing, connectivity services, order-
ing/provisioning, network/service management,
liability, usage, repair, collocation, performance
reporting, customer relationships management,
etc. In addition, the costs of performing each of
the relevant functions should be analysed and
compared with the costs of buying services from
a sub-provider and agreeing the SLA with him.
From the user’s perspective the information of
this difference in costs may build a basis to
decide whether to go for a standard ‘menu’ solu-
tion offered by the provider, or to ask for a more
specific ‘tailored’ solution for the SLA. In the
latter case, the provider’s team would usually
adjust the terms according to the needs and
wishes of the user. The responsibilities in the
team can be redistributed according to the top-
ics/issues to be detailed. After running the nego-
tiation process and agreeing the SLA, SLA
assurance (that should be agreed upon as well)
has to verify that both sides keep the statements
in the SLA.Different practise and recommendations can be
found for the SLA negotiation, and some guide-
lines of establishing and conducting a negotia-
tion team are available, but this is not our focus
here. As a result of negotiations, an SLA is made
and would typically include:- The description of the serviceto be provided.
The description may be composed as a set of
service component descriptions (i.e. service
specification), or as a description of the ser-
vice scenarios relevant for the user. Also, a
type and a nature of the serviceto be pro-
vided. When describing a service, all service
components should be identified and de-
scribed on each of the interfaces between a
provider and a user, which is not a trivial task. - The QoS-related parthandling the quality
level of the service, including QoS parameter
definitions and objectives. This part of the
SLA will be elaborated further in the follow-
ing section. - The process of reporting problems and trou-
bleshooting, which may include information