Thực hiện chất lượng dịch vụ trong các mạng IP (P6)

6
Service Level
Management Techniques
Service Level Management (SLM) techniques are applicable to
a network transport operator – in the parlance of the previous
chapter – providing service assurances either to another network
transport operator, for a service provider, or an end user. Service
level techniques pertain to aggregates of services, and are con-
tractual in nature. The processes and terminology related to this
subjectaredealtwithinthischapter.
As in the previous chapters of this book, the terminology and
concepts from telecommunications world are when they can be
generalized to the multi-service Internet.
In this chapter, the context of service level management is dis-
cussed first, followed by a description of service planning and
creation process.
6.1 MODELS FOR SERVICE LEVEL MANAGEMENT
A network domain, in general, can include both transport net-
work elements such as routers and service-related ones, streaming
servers being examples of the latter. Both types can be present not
only when a transport network operator is also providing ser-
vices such as streaming, but also because a service provider may
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨
anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X
180 SERVICE LEVEL MANAGEMENT TECHNIQUES
Service layer
Transport layer

Mgmt
plane
Figure 6.1 Conceptual relation of management plane to service and
transport layers
have some kind of managed network of its own. The management
system of a domain, conceptually, manages both transport and
service-related resources in such a case. For this reason, the man-
agement plane is often drawn as shown in Figure 6.1. In reality,
the service and transport layer management is not always very
integrated. Taking a service provider as an example, the manage-
ment system for services may be advanced, but the transport level
management may be based on tools provided by the router ven-
dor. By default, there is no link between the two management
sub-systems, apart from the human operator. In what follows, we
shall concentrate on service level management, which leads to a
general view on management hierarchy, as we shall see.
6.1.1 Areas of service level management
An account of relation of service level management to general
network management can be found in [Kos01], for example.
The ITU-originated Telecommunications Management Network
(TMN) framework cited therein consists of five functional
areas, namely fault management, configuration management,
accounting management, performance management, and security
management.
Fault management, as the name indicates, is concerned with the
tasks related to error conditions in the network, including identi-
fication, correction, and reporting of faults.
Configuration management includes provisioning of services in
servers and network elements, including configuration of the trans-
port network elements in the case of an IP-based multi-service net-

work. The “downward branch” of the IETF traffic engineering loop
discussed in Chapter 4 is part of configuration management.
6.1 MODELS FOR SERVICE LEVEL MANAGEMENT 181
Accounting management relates to the collection of data of net-
work and service usage, providing input for charging. As such,
it is mostly related to the management of services, but must be
related to configuration of the transport network resources, too.
Performance management encompasses obtaining of data relating
to the performance of network elements and services. For practical
purposes, this is the “upward branch” of the IETF traffic engi-
neering loop. Performance management issues will be discussed
in more detail in Chapter 7.
Security management addresses the mechanisms of providing
security, as well as detection of security breaches. This issue is not
within the scope of the present book, and is best left to dedicated
studies on the subject.
6.1.2 Layers of service level management
Management within each of the five areas listed above, in turn, is
conceptually separated into four layers. In the order of increasing
degree of abstraction, these are:
1. Element management layer.
2. Network management layer.
3. Service management layer.
4. Business management layer.
The layers are illustrated in Figure 6.2.
The element management layer is the interface between the man-
agement system and individual network elements. The element
management layer typically has an element-proprietary interface
towards the individual network elements, and an abstracted inter-
face towards the management system. The element management

layer not only provides abstraction of the configurations of indi-
vidual elements, but also provides information about the capabil-
ities of the network elements.
A higher level of abstraction, the network management layer
provides the user of a network management system with an
overview on the network level of the services and network
elements. Such an overview provides a summary of the status
of multiple network elements, for example, for a routing domain
182 SERVICE LEVEL MANAGEMENT TECHNIQUES
Network element Network element Network element
Element mgmt Element mgmt Element mgmt
Network mgmt
Service management
Business management
Figure 6.2 Layers of management in the TMN model
or an entire AD. The overview of the network status must
provide two kinds of information: (a) information about the
operational status of individual network elements within the
scope of the overview. Such information can be used for spotting
individual network elements not performing according to the
specification. (b) Computation of performance indicators spanning
multiple elements. Such indicators can be used for identifying
performance problems due to sub-optimal configuration of
multiple network elements.
Thresholding based on the definition of triggering conditions
can be used to define multiple levels of abstraction in the net-
work. Thus, for example, upon notification of a fault on AD level,
the routing area granularity view can be invoked to look for the
cause or causes of the malfunction. If multiple elements are simul-
taneously in need of attention, the overview summary can be used

to decide the order of handling the fault conditions.
The service management layer handles the technical part of the con-
tracts towards customers and peer operators by managing the net-
work management layer. The precise functions depend on the type
of the service in question, being rather different for content down-
loading services and conferencing, for example. Usually the ser-
vice management system has to provide possibilities for creating,
6.1 MODELS FOR SERVICE LEVEL MANAGEMENT 183
Service layer
Transport layer
Mgmt
plane
Business
service
Network
element
Figure 6.3 Combined framework
modifying the composure of, and deleting services. Services that
are not provided for free have a charging policy associated with
them, and service invocation rights need to be managed. When
services require resources from neighbouring domains, the man-
agement of the technical content of SLAs for neighbours is one of
its tasks.
The business management layer is responsible for the business as-
pects of the agreements towards different parties involved. As will
be discussed below, business information is part of the SLAs in gen-
eral. This topic will be mostly outside of the scope of this book.
From this classification, it can be seen that service management is a
device for implementing business objectives using network level
tools. Comparing this hierarchy to that of Figure 6.1, it can be

observed that this classification addresses the management plane
only and the four layers of the above list are interfaces of the
management plane towards the network and management layers
(see Figure 6.3).
6.1.3 Models for managed data
The TMN model reviewed above is concerned with the management
processes on different abstraction levels. A more data-oriented view,
the Service Level Agreement (SLA) working group of Distributed
Management Task Force(DMTF) definesan object-oriented informa-
tion model called the Common Information Model (CIM) consisting
of the following layers [CIM99] Common Information Model (CIM)
Specification, version 2.2, DMTF, June 1999.
• Core models span applications, networks, devices, and users.
184 SERVICE LEVEL MANAGEMENT TECHNIQUES
• Common models span the technologies within a particular
management domain.
• Extension models are technology-specific extensions to the com-
mon models.
Fromthis viewpoint, servicelevelmanagement makes use of the core
and common models, being dependent on both service requirements
and operator processes. More discussion about CIM and its rela-
tion to other standards efforts can be found in [Kos01] and [SMJ00],
for instance.
Finally, service performance is also part of an IETF Application
Management Information Base (MIB), specified in [RFC2564]. This
RFC is mostly concerned with the application level performance
measurement methods.
6.2 SERVICE PLANNING AND CREATION PROCESS
To achieve accountability in service provision for the customer,
service level quality needs to be defined in a contract, usually

called a Service Level Agreement (SLA). Due to its bilateral con-
tractual nature, the contents of a SLA are defined by the parties of
the agreement, for example, the service provider and the transport
operator, or the service provider and the end user. To understand
what usually goes into a SLA and why, let us first take a look
at the interests of a customer before proceeding to service defini-
tion processes.
6.2.1 Interests of the customer
It is in the interests of SLA parties to be able to define received ser-
vice quality as accurately as possible. This is in principle true for
inter-operator, operator/service provider, and operator/end user
contracts. Naturally, long-term contracts involving large traffic
aggregates tend to be more elaborate. The most important reasons
for defining service quality precisely in an agreement are:
• Common understanding of what constitutes an acceptable service qual-
ity support. When the transport operator understands the qual-
ity requirements of services end-to-end, future development of
6.2 SERVICE PLANNING AND CREATION PROCESS 185
network transport resources can take service aspects better into
account. On the other hand, the service providers and customers
benefit from understanding of the issues related to transport.
• Transparency of charging. The customer typically wants to pay for
clearly defined service performance.
• Accountability. The means of assessing performance need to be
agreed upon.
• Definition of customers’ and operator’s liabilities in case of sub-optimal
service performance. This is often important when service forms a
part of the customers’ own business processes. Exceptional sit-
uations have a cost associated with them, and the responsibility
for financial consequences needs to be known in advance.

• Security. It is important to agree in advance which information
need to be divulged to sustain normal operation of the ser-
vice. Also, reporting of security breaches is increasingly impor-
tant [Sch00].
These main goals can be mapped to more fine-grained needs related
to reporting of exceptional conditions, for example. The SLA con-
tents are discussed in more detail in Section 6.3 below.
It is useful to list next a few typical characteristics a customer
of a multi-service transport network is interested in. The second
and the third items in the list have been dealt with in the service
quality requirement section already, and the building blocks for
addressing the fourth one have been provided there.
• Service implementation time.
• Service availability.
• Service continuity.
• Service-specific quality parameters.
Service implementation time relates to the competitive edge of
customers of a transport network operator. In the case of creating
“hot” and “new” ad hoc services by a service provider, or cop-
ing with the need to implement quickly a modification into the
composition of a service, timeliness can be important.
Service availability and continuity relate to the quality of the
service provided, as seen on an aggregate level. Service specific
quality parameters, on the other hand, relate to the requirements
of individual service instances, as discussed in Chapter 2.
186 SERVICE LEVEL MANAGEMENT TECHNIQUES
Means of estimating these characteristics need to be defined.
Some commonly used estimators are:
• Mean Time Before Failure (MTBF). The average time between
failures.

• Mean Time to Provide Service (MTPS). The average time from
finalizing agreement between the service operator and the
customer to having the service in operational use. This can be
considered to be a formalization of the service implementation
time mentioned above.
• Mean Time to Restore Service (MTRS). Average time from
reporting a fault to service being restored.
Failure is used in the above list generically to indicate a state of
insufficient service quality support in the network. To define the
abnormal conditions more precisely, the TeleManagement Forum
(TMForum) defines different levels of deviations from the nor-
mal operation of the service support in the network [SMH01]. In
what follows, the terms have been interpreted from a service qual-
ity support viewpoint. The following definitions assume that the
desired service quality support has already been defined.
• Anomaly is a discrepancy between the desired and actual per-
formance.
• Defect is a limited interruption in the capability of network ele-
ment or network to perform required function.
• Impairment is a condition giving rise to anomalies and defects
without causing a failure.
• Failure is the termination of the ability of a network element or
network to provide the required function.
• Fault is the inability of a network or network element to provide
service quality support, excluding maintenance reasons, external
causes, or planned actions. Fault is often the result of a failure,
but may also exist without a failure.
It is important to note the role of service definition in fault
management according to these definitions. Unless sub-optimal
performance can be clearly defined, fault correction procedure

defined within SLA cannot be applied according to the terms of
the agreement.
6.2 SERVICE PLANNING AND CREATION PROCESS 187
Note that in applying the above definitions to a multi-service
network, the required function means support for all service qual-
ity aggregate types.
6.2.2 Network operator viewpoint
The set of service quality support mechanisms at the network
operator’s disposal may vary. A particular level of service quality
support for the customer can be provided with different combi-
nations of the network-side service quality support mechanisms
discussed in Chapter 3. The service performance obtained with
the tools needed by service level management are identical in
each case, although the actual tools on the network level may
be different from each other.
The mechanisms a network operator uses for configuring the
service quality support typically vary with network technology.
The same is typically true for measurement results based on
element-level information and quality characteristics obtained
from combining these. The operator must be able to provide
a means of service level quality monitoring irrespective of the
QoS technology used. The technologies that can be used for this
purpose will be discussed at length in the next chapter.
A special form of measurement is the definition of triggers for
exceptional conditions that the network operator is notified of.
Sub-optimal operation of the network or network elements can
be communicated to the network management system in vari-
ous ways.
• A notification is an indication that a predefined condition has
transpired in the network. Obtaining notifications requires a

way of defining the conditions, a mechanism for detecting that
the condition has occurred, and means of communicating the
condition. Preferably also a means of detecting the malfunc-
tioning of the notification mechanism should exist.
• An alarm is an indication of a condition that has negative impact
on the service quality support level. An alarm can be related to
a network element, a part of the network, or service level, for
example. From the above definition it is clear that an alarm is
188 SERVICE LEVEL MANAGEMENT TECHNIQUES
a special form of a notification, and thus has basically the same
kinds of requirements associated with it.
The notifications and alarms in the transport network element
management system that are visible to the transport operator
may not have one-to-one correspondence with failures and faults
defined in SLAs for service providers or end users. A simple
reason for this is that the same traffic aggregate in the transport
operator’s network may be shared by multiple internal or external
parties, each potentially associated with their own dedicated
SLA definitions. In such a case, a mapping function between
the notification conditions in the network and possible external
communication defined in individual SLAs may be needed.
Such a mapping may involve correlating multiple network-
defined conditions.
From the business perspective, a service level agreement defines
that the service provider will sell a certain item (service quality
support) at a defined price. In this sense, the SLA is no different
from any other business contract from a network operator point of
view – risks have to be evaluated and a price tag assigned to them.
If the network operator provides services itself, a SLA may still
be used for accounting and service quality supervision purposes.

In this case, the business risk associated with an operator-internal
SLA may be of different type than for an external SLA, a difference
which is typically reflected in the contents of the respective SLA
types when it exists.
6.2.3 Service definition
In order to define service quality support needed, the customer
of a network provider must first define the services themselves.
The customer responsible for service definition is service provider.
The different ways of carrying out this task are mostly beyond
the scope of this book, but an “archetypical service engineering
process” is outlined for the purposes of understanding the impact
on SLA definition.
The service creation process starts by defining the need that
the service addresses. Next, the composition of the solution to
the perceived need is defined in the form of the service. Multiple
6.2 SERVICE PLANNING AND CREATION PROCESS 189
variants of the service may be planned, for example a “business”
variant and an “economy” one.
Having defined the service on aggregate level, one can next pro-
ceed to defining what constitutes an individual service instance.
If different variants such as the business and economy variants
exist, different types of service instances are analysed this way.
Next, the service instance is broken down into service events.
From the definition of service events, one can derive the service
quality support needed, using the analysis principles outlined in
Chapter 2.
Once the technical part is completed, a marketing strategy can
be drafted, yielding the expected service deployment forecast. At
this stage, the traffic volumes and service quality needs are known
and the starting point for SLA negotiation has been reached. The

composition of the final SLA may be affected by the SLA terms
provided by the network operator. The process is illustrated in
Figure 6.4. As noted in [SMJ00], the contents of the SLA need not
be fixed even when a SLA is finalized, but its contents can be
iteratively enhanced.
The Telecommunications Management Network terminology for
the operator-guaranteed Quality of Service level is “Grade of Ser-
vice” (GoS). In [SMH01], GoS is contrasted with delivered or mea-
sured service quality level as being an engineered service quality
level. This is akin to the ITU-T differentiation between planned
Definition of need for service
Definition of service composition
SLA negotiation
Service deployment forecast
Marketing strategy definition
Definition of service quality need
Definition of service events
Repeat
until result
acceptable
or process
abandoned
Figure 6.4 A simplified illustration of the service definition process. The
iteration based on feedback from SLA negotiation also leads back to a
phase below service composition definition
190 SERVICE LEVEL MANAGEMENT TECHNIQUES
and offered QoS [G.1000] discussed in Chapter 2. If multiple vari-
ants of a service are provided, they may have different GoS char-
acteristics associated with them.
The time-to-market factor in service creationis increasinglyimpor-

tant, which is reflected both in the SLA creation process and the
contents of the actual SLAs.
6.2.4 Reporting
Reporting means the definition of an agreed-upon process of con-
veying information to the customer by the other party of the agree-
ment, network operator or a service provider. Reporting is used to
convey information relevant to service performance, and is usu-
ally part of SLAs for service providers, peer transport operators,
and at least selected end users such as institutions and corporate
customers. The customer may have their own means of assessing
service performance, against which operator reporting can be com-
pared. According to [SMH01], the definition reporting includes the
following parts:
• scheduling of customer reports;
• receiving of performance data;
• compiling of customer reports;
• delivering of customer reports.
The scheduling and contents of customer reports are defined in
an agreement between the service/network provider and the cus-
tomer. The measured characteristics in the scheduled report can
relate to service quality performance, service availability, or to
operation of the network in general. For a multi-service network,
the measured characteristics may be different for each quality sup-
port aggregate. It is also possible for the customer to request a
measurement of not only the service quality aggregate, but also the
entire per-domain treatment, including edge functions. In addition
to what is measured, also the measurement methodology as well
as the frequency of measurements is specified in the agreement
on reporting.
Different kinds of reports may be compiled based on the tar-

geted readership as well as for purposes of covering different
reporting periods. For example, there may be separate customer