GB917 SLA Handbook Release 3-0 v0-9

TM Forum 2011
SLA Management
Handbook

Release 3.0
GB917
TM Forum Approved Version 0.9

January, 2011
SLA Management Handbook

GB917, Version 0.9 TM Forum 2011 Page 2 of 56
Notice

This material, including documents, code and models, has been through review cycles;
however, due to the inherent complexity in the design and implementation of software and
systems, no liability is accepted for any errors or omissions or for consequences of any use
made of this material.
Under no circumstances will the TM Forum be liable for direct or indirect damages or any costs
or losses resulting from the use of this specification. The risk of designing and implementing
products in accordance with this specification is borne solely by the user of this specification.
This material bears the copyright of TM Forum and its use by members and non-members of
TM Forum is governed by all of the terms and conditions of the Intellectual Property Rights
Policy of the TM Forum (http://www.tmforum.org/Bylaws/1094/home.html) and may involve a
claim of patent rights by one or more TM Forum members or by non-members of TM Forum.

Direct inquiries to the TM Forum office:
240 Headquarters Plaza,
East Tower 10
th
Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org

Table of Contents

Notice ...................................................................................................................................................................2
Table of Contents ..............................................................................................................................................2
List of Figures ....................................................................................................................................................5
Executive Summary ..........................................................................................................................................6
1. Introduction ....................................................................................................................................................8
1.1. Intended Audience...........................................................................................................................8
1.2. Scope of This Document .................................................................................................................8
1.3. Benefits of This New Release ...................................................................................................... 11
2. Key Concepts and Definitions .................................................................................................................. 13
2.1. Actors ............................................................................................................................................ 13
2.1.1. Informal Model ...................................................................................................................... 13
2.1.2. Definition of Terms ................................................................................................................ 13
2.2. Services......................................................................................................................................... 15
2.2.1. Informal Model ...................................................................................................................... 16
2.3. Service Level Agreement ............................................................................................................. 18
2.3.1. Informal Model ...................................................................................................................... 18
2.4. Measurements .............................................................................................................................. 22
2.4.1. Informal Model ...................................................................................................................... 22
2.5. Summary of Definitions ................................................................................................................ 25
3. SLA Life Cycle Processes ......................................................................................................................... 27
3.1. Overview ....................................................................................................................................... 27
3.2. SLA Specification.......................................................................................................................... 29
3.2.1. Introduction to SLA Specification Methodology .................................................................. 29
3.2.2. Step 1: Initial SLA draft ......................................................................................................... 30
3.2.3. Step 2: Verify SLA Completeness ....................................................................................... 31
3.2.4. Step 3 Verify SLA Feasibility ............................................................................................... 34
3.2.5. Step 4: Document and Review ............................................................................................ 35
3.2.6. Step 5: Finalize ..................................................................................................................... 35
3.2.7. Three SLA Specification Cases ........................................................................................... 37
3.2.8. Integrator and interdependence specific issues ................................................................. 39
3.3. SLA Management ......................................................................................................................... 40
3.4. Summary: Checklist of Recommendations ................................................................................. 41
4. Next steps .................................................................................................................................................... 42
Appendix A: Abbreviations .......................................................................................................................... 43
Abbreviations and Acronyms .................................................................................................................. 43
Appendix B: References ............................................................................................................................... 45
References ............................................................................................................................................... 45
Source or Use .......................................................................................................................................... 45
IPR Releases and Patent Disclosures ................................................................................................... 45
Appendix C Illustration of definitions ...................................................................................................... 47
KPIs and KQIs ......................................................................................................................................... 47

SLAs and Measurements ....................................................................................................................... 47
VPLS example ......................................................................................................................................... 48
Appendix D Use Case 1: IPTV SLA .......................................................................................................... 51
Appendix E Use Case 2: Emergency Telecom Services SLA .............................................................. 52
Appendix F Use Case 3: Business VPN SLA .......................................................................................... 53
Administrative Appendix ............................................................................................................................... 54
About this document ................................................................................................................................ 54
Document History .................................................................................................................................... 54
Version History .................................................................................................................................... 54
Release History ................................................................................................................................... 55
Acknowledgments ................................................................................................................................... 55


List of Figures
Figure 1. Business Process Framework level 1 processes with SLA positioning 9
Figure 2. Business Process Framework Operations level 2 processes with SLA positioning
9
Figure 3. Business Process Framework SIP (Strategy, Infrastructure & Product) level 2
processes with SLA positioning 10
Figure 4. Business Process Framework Customer QoS/SLA Management level 3 processes
10
Figure 5. Business Process Framework CRM Support & Readiness level 3 processes 11
Figure 6. SLA Specification and Management (by SP) 11
Figure 7. SLA Specification/Negotiation in SP-Customer relationship 11
Figure 8. Complex Service Delivery Relationships 13
Figure 9. Service overview 16
Figure 10. Illustration of SLAs, OLAs (Internal SLAs), Implicit SLAs and SLSes (with KQIs and
SLS Thresholds) in 3 different scenarios (a,b,c) 18
Figure 11. Measurement concepts used for SLAs 22
Figure 12. SLS Parameters, SLS Thresholds, and SLM(T)s for two SLAs 23
Figure 13. Metrics for QoS and QoE 24
Figure 14. SLA Life Cycle Phases 27
Figure 15. Common pattern: SLA Specification processes 30
Figure 16. GB917 v3 proposed analysis matrix for SLA completeness 33
Figure 17. SLA Specification processes (composition and sequence flow) 36
Figure 18. SP-side initial specification: creation of Proposed SLAs 37
Figure 19. Customer-side initial specification: creation of Requirements 38
Figure 20. Customized SLA Specification illustration: using SP and Customer inputs to create
Customized SLAs 39
Figure 21. Integrator role in SLA Specification 40
Figure 22. Example of SO-driven definition of an Implicit SLA and its measurements 48
Figure 23. Illustration of Products, Services and SAPs with a VPN example 49
Figure 24. SLAs, OLAs, and Contracts in a VPN example 50


Executive Summary
The objective of the SLA Management Handbook is to assist two parties in developing a Service
Level Agreement (SLA) by providing a practical view of the fundamental issues. The parties may be
an end customer, e.g. an Enterprise, and a Service Provider (SP), or between two Service
Providers. In the latter case, one SP acts as a customer buying services from the other.
This latter case can be extended to include the scenario where a Service Provider provides a
complex service to an end Customer, using a value chain or value network of services from one or
more other Service Providers. This is a major new consideration for this release of the SLA
management Handbook.
The perspective of the SLA Management handbook is to consider the requirements of all parties
when developing SLAs for the services provided. From the Customer perspective, this means that
the end Customer develops its service requirements (not restricted to simply telecommunications
services) based on its business applications, which are presented to a SP and the two parties
negotiate the specific set of SLA parameters and parameter values that best serves both parties.
From the SP perspective, each offered product or service can be provided with a standard Product
SLA, however this may or may not meet the requirements of the Customer, hence the negotiation
can be based on the Customers needs as represented by its service requirements and the SPs
capabilities as represented by its standard Product SLA.
For the SP, the agreed SLA requirements will flow down through its organization and become the
basis for its internal management and control of its Service Quality Management processes. For
Enterprise customers, the SLA requirements serve as a foundation or component of its internal
business services.
Service Providers have historically reported the performance of their networks against a set of Key
Performance Indicators (KPIs). These are inherently network focused and provide little direct
indication of the end-to-end service delivery that the network supports. Nevertheless KPIs are an
important measurement for network operations and will continue to be so for the foreseeable future.
Modern communications services have led to a requirement for indicators that are focused on service
quality rather than network performance; the focus of Customers has become Quality of Experience
(QoE). These Key Quality Indicators (KQIs) provide a measurement of a specific aspect of the
performance of the product, product component(s), service or service element(s) and draw their data
from a number of sources including the KPIs.
The Business Process Framework (formerly known as eTOM, enhanced Telecom Operations Map)
presents SLA management as a group of processes at the intersection of the Customer Relationship
Management and Assurance. In addition there are a series of processes and process components
at various other positions, which support the specification and management of SLAs. These have
been used as a guide for this version of the handbook.
The previous release of this handbook consisted of multiple Volumes; this release consists of a single
volume, and in so doing, meets a major objective of keeping the overall document to a manageable
length. In addition, it provides a full set of harmonized definitions of terms used in the field of SLA

management, where there is a wide range of interpretations in use in the industry today. Other
objectives that have been addressed included support for modern, complex services, especially
those that are not inherently networking services and those that are provided via a Value Chain of
Service Providers. It should be capable of supporting SLA lifecycles for any service or product.
This Handbook therefore provides a full set of definitions, updates on rules and methodology for the
specification and development of SLAs, as well as useful tools such as matrices and checklists for
use in SLA management.


1. Introduction
1.1. Intended Audience
This Guidebook is aimed at technical staff within Service Providers (SP), Solution
Providers, Vendors and others that are planning the deployment or design of Service
Level Agreement (SLA) Management solutions. It is aimed at both Strategic Product
Planners and Implementors within these organizations. In addition, this Guidebook is
intended to be used by End-User organizations, i.e. the Customers of the Service
Providers, and also by Groups representing Customers, that are procuring Services that
are to be managed using a Service Level Agreement.
1.2. Scope of This Document
This document defines a framework for planning, design, implementation and operation
of SLA Management. As such, it provides an overall architecture, including definition of
terms and processes, which is consistent with the relevant TM Forum architecture,
definitions and processes, e.g. Business Process Framework, Information Framework
(formerly known as SID: Shared Information/Data model), etc.

In addition, examples of how this architecture can be applied to modern
telecommunications services are included. However, these examples are not intended to
be definitive approaches. The TM Forum is developing Application Notes that address
SLA Management of several services (such as VoIP Applications, IPTV, etc.) and these
should be considered as more definitive for each given service.

Where possible, the concepts discussed within this version draw on earlier versions and
on work from organizations such as the ITU-T and ETSI. It is clear that SLA Management
has become a well-documented topic. However, as it has evolved in multiple
organizations, there has been divergence of terminology and in some cases of
methodology. This document attempts to clarify the inevitable inconsistencies.

Figure 1 shows SLA Management in the context of the Business Process Framework.
According to Business Process Framework release 8.1, it intersects the Assurance stack
at the Customer Relationship Management layer. Figure 2 shows this further
decomposed to show the Business Process Framework Level 2 processes for the
Operations capability within a Service Provider.

This document also considers the processes that support the development of SLA
Specifications, that can be agreed with Customers, in order to support SLA management.
These processes are identified within the Business Process Framework release 8.1, and
the positions are shown in Figures 1, 2 and 3. Note that SLA specification is only a
component of some of these processes, and so it is not fully explored in Business
Process Framework release 8.1.


SLA Spec
SLA Spec
SLA Mgt
SLA Mgt SLA Mgt



SLA Spec
SLA Mgt

Figure 3. Business Process Framework SIP (Strategy, Infrastructure &
Product) level 2 processes with SLA positioning

Figures 4 to 7 show further decomposition of the Business Process Framework
processes to level 3, showing where the SLA Management and
Specification/Negotiation processes are provided. This document explores the
SLA Specification processes in more detail than in the Business Process
Framework release 8.1, and it is planned that the refinements are added to a
future version of the Business Process Framework.

SLA Mgt

Figure 4. Business Process Framework Customer QoS/SLA Management level 3
processes


SLA Mgt

Figure 5. Business Process Framework CRM Support & Readiness
level 3 processes

SLA Spec
SLA Mgt

Figure 6. SLA Specification and Management (by SP)

SLA Spec

Figure 7. SLA Specification/Negotiation in SP-Customer relationship

1.3. Benefits of This New Release
This new release of the SLA Management Guidebook (GB917 Release 3.0) is a
standalone document, which replaces Release 2.5.

It provides benefits of relevance to todays telecommunications services, as well as
simplification, clarification and consistency with other TM Forum documents.

Release 2.5 of this Guidebook was a four-volume set, covering the following:

1) Executive Overview of the remaining volumes
2) Concepts and Principles the core SLA Guide itself
3) Service and Technology Examples providing application examples
4) Enterprise and Applications the Enterprise Customer perspective

This new release is intended to meet the following objectives:
Provide support for modern telecommunications services such as Content Delivery,
and the increased likelihood of services being provided by multiple co-operating
service providers through a single Integrator.
Provide a simpler guide where possible.
Update and support the evolving core TM Forum concepts and architecture where
necessary.
Acknowledge the interdependent and complex nature of SLA relationships for
modern services.
Resolve terminology issues between bodies of work in this field.

This new release provides benefits for Customers, Users, User Communities and other
Consumer Groupings, as well as for Service Providers and Solution Vendors. In
particular, the standardization of measurements and methodology provides for more
meaningful comparisons between Service Providers, and also for the easier exchange of
SLA reports between Service Providers and Customers/Users.

This new release does not cover the following topics even though they are related to SLA
Management:
1) Modeling of penalties for non-compliance to an SLA, and conversely, rewards for
compliance
2) Regulatory aspects
3) Legal guidelines


2. Key Concepts and Definitions
2.1. Actors
2.1.1. Informal Model
The following figure shows an overview of the main SLA-related entities which are
described in this section.

SP
Role
Customer
Role
SP
Role
SP
Role
SP
Role
Customer
Role
SP
Role
Customer
Role
SP
Role
Customer
Role
SP
Role
Customer
Role
SLA SLA
SLA
SLA
SLA
SLA
SLA
Integrator
Role
A1
A2
Ak
...
A3
A4
SLA
Ax
Ay
Customer
Role
Customer
Role
CG1
shared
SLA

Figure 8. Complex Service Delivery Relationships
2.1.2. Definition of Terms
Service Level Agreement (SLA)
A Service Level Agreement (SLA) is an element of a formal, negotiated commercial
contract between two parties, i.e. a Service Provider (SP) and a Customer. It documents
the common understanding of all aspects of the service and the roles and responsibilities
of both parties from service ordering to service termination. SLAs can include many
aspects of a service, such as performance objectives, customer care procedures, billing
arrangements, service provisioning requirements, etc. Although an SLA can address
such items, the specification of the service level commitments on the SP part is the

primary purpose of an SLA. Consequently, the concepts and principles in this handbook
focus on the specification and management of SLAs, and on a framework for identifying
quality and performance factors, i.e. for defining an appropriate Service Level
Specification (SLS), including target numbers in the form of SLS Thresholds
1

.
Actors and Roles: Service Provider (SP) and Customer
In this handbook, SP and Customer refer to roles, and any organization, business, or
person can have several roles in different context. The generic term of an entity with a
role is an Actor.

The SP is the party offering, providing and billing the service. The Customer is the party
ordering and paying the service.

More precisely, definitions from ITU-T Recommendation M.3320 [1] can be quoted:
Service Provider: A general reference to an entity who provides telecommunication
2

(we can add and telecommunication-related services) services to Customers and
other users either on a tariff or contract basis. A Service Provider may or may not
operate a network. A Service Provider may or may not be a Customer of another
Service Provider. (definition 1.4.6).
Customer

: The Customer is an organization which has a business relationship with a
Service Provider for the provision of network services. A Customer may encompass
one or more end users of telecommunications services. (definition 1.4.7).
Both SP and Customer may be in a value chain of service delivery as shown in Figure 8.
In this case, an Actor with a Customer role in one SLA may have a SP role in another
SLA in the chain. Therefore, SLAs may be related to each other.

Integrator Role
Figure 8 shows that a given actor (e.g., actor A1) may actually need to function as a
Customer to more than one other actor (e.g., actors A2 to Ak) in order to provide a
service to its Customers (such as Ax and Ay). This concept (referred to as an Integrator
Role) is becoming more and more prevalent in the global marketplace.

Customer Group
A Customer Group can be defined on the SP side without the customers being aware of it
(based on their region, profile, subscription package, assigned server, etc.). It can also be
an organized group of customers who deliberately decide to join, based on common
interests (social networks) or to obtain more bargaining power in a collective contract
negotiation. For instance, in Figure 8, Actors Ax and Ay in their Customer role, could form
a Customer Group CG1 for actor A1 in their SP role.
The SLA between an SP and each Customer of a Customer Group may be shared, i.e.
the same SLA would apply to each member of the group (shared SLA), either as a
globally unique SLA for the Customer Group as a single entity, or as a set of instances of
the same SLA for each individual Customer.

1
These terms will be defined later in the document.
2
Although M.3320 restricts the definition of SP to an entity who provides telecommunication services, this document uses the
term SP more generically, i.e., an entity who provides any one of a number of different types of services, e.g., within this
document an SP may be a Telco, Content Provider, Over-the-Top Application Provider, Advertiser, Supplier, etc.

The TR149 [2] model (for Customer Experience, User Experience and QoS) also
introduces the following terms (section 2.4.1, "CE Framework Conceptual Model
Overview"):

User Role
A User is the consumer (organization, person, or machine) who invokes, in a legitimate
way, the services provided. The User is not necessarily a Customer in a shared
voice/video/internet residential service example, the Users would be entities making
phone calls, watching TV or Video-on-demand, or surfing the Internet. Such entities could
be family members, visitors, automated servers, etc. The Customer would be the entity
responsible for paying the service bill and with the decision power to modify or
discontinue the service, typically the household head(s).

User Group Member Role
This role, which refines the User role, can be applied to groups of Users implicitly defined
by social networking or by market segmentation (member of a User Group defined by an
SP, or by a market analysis firm), etc.

Value Chain
An arrangement of business relationships and agreements between market players that
are co-operating to deliver an end-to-end service and products to an end-user. Each
participant contributes to add value to the service or product ultimately delivered to the
User role within a Customer role. The longest value chain would start from a SP with no
Customer role and end at a Customer/User with no SP role. By definition, Integrators are
always in a Value Chain.

Value Network
The value network is the collaboration of the enterprise, its suppliers, complementors and
intermediaries with the customer to deliver value to the customer and provide benefit to
all the players in the value network. Several Value Chains are involved in a Value
Network.

2.2. Services
SLAs and SLA actors are defined around the central concept of Service. In this section,
we focus on this notion of Service, and also examine associated concepts such as
Service Access Point.

SP
Role
Customer
Role
Product Offer
(Marketing)
Product Instance
Customer-Facing
Service
Interface
Resource-Facing
Service
Service
Access
Point
Physical
Resource
Physical
Resource
Resource-Facing
Service
Logical
Resource
Service1 Service2
SLA

Figure 9. Service overview
Service
(also Product and Product Offer)
The word Service is quite generic and there are many definitions for it. In the TM Forum,
the Information Framework emphasizes the notion of Product (GB922 Addendum 0 v1.1
(Information Framework Primer)) [3]:
Services are tightly bound to Products. A Product may be implemented through one
or more Services which utilize Resources.

The Product can also be seen as the marketing (visible) view of the Service, the latter
being a more technical concept. The Product is the object of the transaction between a
Customer and a Service Provider.

Another TM Forum group (Business Process Framework), proposes a similar definition
[4]:
Services are developed by a Service Provider for sale within Products. The same
service may be included in multiple products, packaged differently, with different
pricing, etc.

From a SLA Management point of view, an SLA is attached to a Service, regardless of its
relation to a Product. More precisely, it is attached to a Customer-Facing Service (see
definition below).


Figure 9 reprises the SP, Customer, and SLA concepts already presented, and also
shows the Service, Product (distinguishing between the Product Offer (or Product
Offering) which is the abstract description of the Product, and the Product Instance, which
is an actual delivered Product, between a given SP and a given Customer), as well as
other concepts detailed hereafter.

Composite Service
Composite services are simply constructed by aggregating other services. In other words,
a composite service is itself a service and may contain other services, recursively. A
Product may be implemented through Services which may each be Composite or not.
The services can be aggregated from the same SP or from different SPs.

The Customer of a composite service would have a single SLA for the composite service
if it is delivered by an Integrator. Otherwise, the Customer essentially has to play the
Integrator role, and may have a separate SLA with each SP providing each component
service.

Besides, customers may or may not be aware of the fact that their delivered service is an
aggregation (from the same SP, or from multiple SPs through an integrator SP).

Figure 9 shows an example of two services (Service1 and Service2), components of a
composite Customer-Facing Service.

The recursive service composition depth (number of layers in the service hierarchy) is
arbitrary, and depends on the service model. Not every real component needs to be
represented in a service model used for a certain purpose like SLA management.

Services can also use different resources (logical or physical).

Specific expressions such as Service Element, Basic Service or Bearer Service
(telecommunication service that provides the capability for the transmission of signals
between user-network interfaces) can be used, but are relative to a point of view. A
"basic, low-level" service from a Customer point of view could be a "complex, top-level"
service from the SP point of view. The word "Service" in the present document covers all
these cases and points of view.

Customer-Facing Service (CFS) and Resource-Facing Service (RFS)
A Customer-Facing Service (CFS) is part of a product. In contrast, a Resource-Facing
Service (RFS) is transparent to the Customer, and is there to support Customer-Facing
Services. Therefore, these CFS and RFS concepts depend on a Customer-SP
relationship and are not absolute (a Service, without context, cannot be declared CFS or
RFS).

Service Access Point
A SAP (or UNI: User-Network Interface) is a logical point in the network, corresponding to
a service in a certain network layer (in the OSI sense), accessible by remote entities
participating in the same service, and able to communicate locally with other services
from other layers.

For example, it constitutes the logical interface between a Customer and a Service
Provider, where negotiated Products and Services are delivered, and a logical boundary
(i.e. demarcation) between Customer networks and SP networks.

2.3. Service Level Agreement
This section describes SLAs in more detail. We define KPIs/KQIs, SLSes (Parameters
and Thresholds), OLAs (a.k.a. Internal SLAs), and Implicit SLAs.

A3 A1 A1 A1 A2
Business Agreement
SLA
SLS
SP Customer
optional
internal agreement
OLA
(Internal SLA)
SLS
Dept B
(SP)
Dept A
(Customer)
Implicit SLA
SLS
SP Customer
Related concepts, but
different contexts
Thr
KQI
KPI KPI
Thr
KQI
KPI KPI
Thr
KQI
KPI KPI
(a) (b) (c)
(expectations)

Figure 10. Illustration of SLAs, OLAs (Internal SLAs), Implicit SLAs and
SLSes (with KQIs and SLS Thresholds) in 3 different scenarios (a,b,c)

Metric
A metric is a commonly identified and measurable concept. It can characterize a Product
or a Service. A metric is measured at a Measurement Point.
3

KPIs and KQIs
KPIs and KQIs are Metrics.
KPI

3
See definitions later in the document.
: when applied to networking, a technical metric (close to network technologies
and physical devices) which is measured directly.

KQI

: when applied to networking, a metric capturing the overall performance of a
Service or a Product, typically expressed as a percentage of customers, resources or
telecom entities (like a call or a session) meeting a certain level of quality. A KQI is an
abstracted and simple to understand metric, meaningful to the Customer, without
technical jargon specific to the SP. A KQI possibly aggregates a mix of KPIs,
intermediate computed components (usually from KPIs), other KQIs (from one or
even several SPs) and direct measurements, using appropriate mathematical
formulas (which are the KQI Estimators). A KQI does not necessarily correspond to
one or several Measurement Points.

Service Level Specification (SLS):
SLS Parameters and SLS Thresholds
An SLA defines what needs to be measured, how, where and when it should be
measured, as well as agreed-upon performance values which need to be achieved for
the contractual SLA to be satisfied. The SLA also describes which measuring and
reporting processes are used, and what should be done when the thresholds are not met
(SLA violation procedures).

The SLS is the set of all SLS Parameters (which are KQIs defined in the context of an
SLS) which need to be measured, and of all SLS Thresholds, which are the specification
of the actual values to be achieved for the SLS Parameters (multiple SLS Thresholds can
be associated to a single SLS Parameter, so as to specify various degrees of
requirements).

SLS Thresholds should be expressed using values or ranges. Each SLS Parameter may
have a different numerical translation of good and bad performance (large numbers for a
Loss Rate are bad, while large numbers for an Availability Rate are good). So for clarity,
each SLS Threshold should be provided with a direction of crossing (from good to bad),
to indicate on which side of the value or range boundary are the bad performance
measurement values.

SLS Expression
An SLS Expression is a condition involving at least one SLS Parameter and at least one
SLS Threshold. It states quantitatively the expectations on the involved SLS
Parameter(s).

In most SLS Expressions, one SLS Parameter is related to one corresponding SLS
Threshold.

However, more elaborate expressions on SLS Thresholds could involve multiple SLS
Parameters and multiple SLS Thresholds, so as to express SLS Parameter
dependencies. For example:
SLS parameters P1 and P2 are linked, and an excellent level of performance on one
of them can compensate an average (but not poor) level of performance on the other.
therefore, defining simple SLS Thresholds for P1 and P2 separately would not reflect
their dependency.

so a more accurate specification could be a logical expression (referred to as SLS
Expression) involving both P1 and P2 such as : "[(P1 very good) and (P2 OK)] or
[(P1 OK) and (P2 very good)]".
o SLS Parameters : P1, P2
o SLS Thresholds:
P1_A+ (very good level for P1)
P1_C (OK level for P1)
P2_A+ (very good level for P2)
P2_C (OK level for P2)
o SLS Expression : [ ( P1P1_A+) and (P2P2_C)] or [(P1P1_C)
and ( P2P2_A+)]
Note: SLS Expressions do not have to be symmetrical as in the example above.

In an SLA, the SLS Parameters should consist exclusively of KQIs, but the SLA (and
SLS) can describe KPIs used to compute KQIs. The SLS Thresholds defined in the SLA
should only refer to KQIs.

Ultimately, an SLS can be seen as a list of SLS Expressions, involving one or more KQIs
(SLS Parameters), with their associated SLS Thresholds and supporting KPIs.

Service Objectives (SO)
The SO apply in the business, financial and marketing areas. It is out of scope of the SLA
management, but SOs should be taken into account to specify the SLA. SLAs are driven
by SOs: increasing profit can mean for instance decreasing customer churn, growing the
customer base, and increasing customer satisfaction and loyalty. Corresponding SLS
Parameters and SLS Thresholds should therefore be defined to reflect the SO. Each
party (SP and Customer) may have their own SO.

Operational Level Agreement (OLA)
The term OLA (or Internal SLA, or Service Provider SLA) is commonly used in the
industry, and is similar to an SLA, although used in a different context. The term SLA is
used in the context of a Business Agreement, whereas the term OLA is used in the
context of an internal agreement. OLAs and SLAs are specified similarly (i.e. using
SLSes).

Implicit SLA
An Implicit SLA uses the same specification format as an SLA or an OLA, i.e. with an
SLS and a description of measurement points and violation procedures, but does not
exist within the context of an agreement (whether commercial or internal). It represents a
one-sided goal stated internally by an SP, aiming at achieving a certain level of quality for
a service, corresponding to the SP opinion of what the Customer expectations are.

If an SP negotiates an SLA with a Customer, then the expectations are assumed to be
known, so there are no cases of simultaneous SLAs and Implicit SLAs.

In any case (SLA, OLA, Implicit SLA), the SP role can decide internally to setup additional
performance parameters, and perhaps more ambitious performance targets. The latter

would be described in an SQM (Service Quality Management) SLO (Service Level
Objectives), possibly using a formalism resembling the SLS (parameters, thresholds, and
expressions).

The SLA/OLA and Contract terminology may be illustrated in the diagram of Figure 10. In
this figure, an actor A1 is shown in 3 different contexts:
(a) in an SP role, having a Business Agreement with an actor A2 in a Customer role.
The Business Agreement contains an SLA (for some CFS) which contains an SLS.
(b) with two internal departments (Dept A in the Customer role, and Dept B in the SP
role). A standalone OLA (or Internal SLA) is in place between the two departments,
and would be contained in an optional formal internal agreement.
(c) in an SP role again, but providing a service to a Customer (role of actor A3)
without any particular SLA, even though there might be a contract. But A1 decides to
set a certain SLS when providing this service. In this situation, A1 may decide to have
an Implicit SLA, for example as a tool to try to meet non-contractual expectations
from Customers.

SLA Template
The SLA Template is a ready-to-use, predefined set of SLA components, either with fully
specified SLSes, or with to-be-filled parameters for customization (place holders for SLS
Thresholds). Further customization is possible (add or remove SLA components). An
actor (SP or Customer) doing frequent business with recurring service types may save
time by starting an SLA negotiation with such a template. More details can be found in
ITU-T M.3342 [9] ("Guidelines for the definition of SLA representation templates").


2.4. Measurements
Measurement
Definition
SO
SLS
KPI
Measurements
Measurement
Point
SLA
SLS
Threshold
Estimator
SLM(T)
contains
related to
SLS Param
(KQI)
Estimator

Figure 11. Measurement concepts used for SLAs

Estimator
While the strict definition comes from statistics (a value computed from a sample so as to
infer the same value on the whole population), the notion of estimator can be broadened
to mean the following : a value obtained by a certain method, and expected to be
reasonably close to the true value of the Metric if it had been measured directly, if the
direct measurement was possible, and if the measurement action did not modify the
measured entity. In the scope of SLA management, NE measurements (used as inputs)
are considered to be direct measurements, regardless of whether estimators are used in
the NE or by probes to obtain the measurement. The formula used to compute a KQI (or
an intermediate KQI component) from several KPIs is an estimator.

Measurement Point
A Measurement Point is a physical and logical demarcation point where an estimator
method can be applied to obtain a measurement of a Metric. Not every Metric is
associated to Measurement Point(s). A Measurement Point can be colocated with a SAP.


Service Level Measurement at Time T (SLM(T))
For a given SLS Parameter, measurements can be obtained at Measurement Points at
time T, using Estimators. For a given SLS, the measured values of all the SLS
Parameters at time T are collectively called Service Level Measurement (SLM) at time T,
or SLM(T), as illustrated by Figure 12.

Whenever an SLA is evaluated at time T, the SLS Thresholds in the SLS of the SLA are
compared to the respective SLS Parameter measurements in an SLM (SLM(T), or some
aggregation of previous SLM(T)s), to decide for each SLS Threshold whether it is met or
not.

parameters
performance
measurement
Bad
Good
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10
P1 P2 P4 P5 P6 P7
P2 P3 P5 P7 P8 P9 P10 (SLA2 SLS Parameters)
(SLA1 SLS Parameters)
SLM(T,SLA1) :
SLS Thresholds not satisfied for P1, P2, P6 (at time T)
SLA1
SLS Thresholds
SLA2
SLS Thresholds
SLM(T,SLA2) :
All SLS Thresholds are satisfied (at time T)

Figure 12. SLS Parameters, SLS Thresholds, and SLM(T)s for two SLAs


SLAM
Network (L1-L6) Application (L7) Human perception
of Applications
and CFSes
Human perception
of global service
(delivery and wrap)
example:
Ethernet frame
loss rate
example:
TV channel
change delay
example:
number of visible
on-screen artifacts
per minute
examples:
satisfaction with
TV/voice/internet
bundled subscription
experience with customer care
customer satisfaction score
brand image
Measurable
Can be estimated
Resource-Facing Service
KPIs
Customer-Facing Service
KPIs/KQIs
Customer/User
Experience
KQIs
Increasing
Relevance
(SP and
Customer)
Increasing
Measurement Ease
for the SP
(subjective
perception)

Figure 13. Metrics for QoS and QoE

Figure 13 shows various scopes of Metrics related to RFSes, CFSes, and Customers,
and how they relate to SLA management. RFSes support CFSes, and therefore RFS
performance impacts CFS performance.

RFSes are not seen by Customers. RFS Metrics remain in the network layers L1-L7, but
usually focus on the lower layers. In an SLS, RFS Metrics provide measurements and
possibly KPIs, but probably not KQIs (SLS Parameters). They are relatively easy to
measure, but are difficult to relate directly to SOs, i.e. are usually not immediately relevant
in business and commercial dimensions.

CFSes are seen by Customers. CFS Metrics remain in the network layers L1-L7, but
usually focus on the higher layers and applications. In an SLS, CFS metrics can provide
measurements, KPIs or KQIs.

Customer/User Experience Metrics are more difficult to measure, but they are the most
relevant in the business relationship. They are prime candidates for KQIs. Some
Estimators may relate CFS/RFS metrics to Customer/User Experience Metrics.

If QoS is assessed, it will use mostly KQIs related to CFSes (and indirectly
measurements and KPIs related to supporting RFSes). If QoE is assessed, it will use
mostly KQIs related to Customers.


By definition, subjective perception almost eludes quantification, but as the domain of
Customer/User Experience is being refined, more and more global perception KQIs will
be progressively analyzed, and corresponding estimators will be validated, and can be
used in SLAs.

SLA Management bridges all these dimensions and focuses them on the Customer/User
Experience KQIs.

2.5. Summary of Definitions

Preferred term Meaning Source (or
inspiration)
Synonyms
SLA Part of a business agreement between an
SP and a Customer, quantitatively
specifying the service performance level
which the SP commits to deliver. Includes
SLS (SLS Parameters and Thresholds), as
well as a description of measuring,
reporting and violation handling processes.
GB917 -
Actor Entity with a Role GB917 -
Role Functions and behaviors of an Actor in a
relation
GB917 -
SP (Service Provider) Role of offering, providing and billing a
Service
M.3320 -
Customer Role of ordering and paying a Service M.3320 -
Integrator Role of offering a Service (as an SP) built
upon multiple ordered Services (as a
Customer)
GB917 -
Customer Group Group of Customers, with or without
awareness
GB917 -
User Role of consuming a Service TR149 -
User Group Member User role refined with membership to a user
group, with or without awareness
TR149 -
Value Chain Set of relationships between contributing
Actors leading to the delivery of a Service to
a Customer
GB917 -
Value Network Set of value chains which effectively
provide a benefit to all involved Actors
GB917 -
Service Part of the realization of a Product GB921,
GB922
-
Product Offer Commercial offer by a SP GB921,
GB922
-
Product Object of a transaction between an SP and
a Customer
GB921,
GB922
Product
Instance
Composite Service Aggregation of Services, possibly with
multiple levels in the hierarchy
GB922 -

CFS (Customer-
Facing Service)
Service in a Product, visible to the
Customer
GB922 -
RFS (Resource-
Facing Service)
Service not visible to a Customer GB922 -
SAP (Service Access
Point)
Logical network interface between a
Customer and an SP
GB917 UNI
Metric Commonly identified and measurable
concept
GB917 -
KPI In a telecom context, Metric close to
telecom technologies and devices
GB917 -
KQI In a telecom context, Metric meaningful to
non-technical people
GB917 -
SLS
(Service Level
Specification)
Set of all SLS Expressions (with their KQIs
and associated Thresholds and KPIs) to be
measured in an SLA
GB922 -
SLS Parameter KQI used in an SLS GB922 -
SLS Thresholds Specification of a quantitative value to be
reached by an SLS Parameter
GB917 -
SLS Expression Specification of one (or several
simultaneous) condition(s) relating SLS
Parameter(s) and SLS Threshold(s)
GB917 -
SO
(Service Objectives)
Statement of objectives for the Service in
business, financial, or marketing terms (i.e.
not telecom technologies)
GB917 -
OLA
(Operational Level
Agreement)
Part of an internal contract. Similar to an
SLA (same specification with an SLS) but
used in a different context.
GB917 Internal SLA,
SP SLA
Implicit SLA

One-sided SP goal of achieving a certain
level of service, specified using an SLS, not
related to any contract with a Customer,
and based on the SPs opinion of the
Customer expectations
GB917 -
SLA Template Predefined set of SLA components M.3342 -
Estimator Method to obtain or compute a measured
value of a Metric (also the value itself)
GB917 -
Measurement Point Physical and logical demarcation point
where an estimator method can be applied
GB917 -
SLM (T)
(Service Level
Measurement at time
T)
Measured values of the SLS Parameters of
an SLS at a time T; allow to assess
QoS/QoE by comparing to SLS Thresholds.
GB917 -
(*)QoS (Quality of
Service)
Degree of conformance of the Service to a
performance level specified using an SLS
E.800,
E.860 [5]
-
(*)QoE (Quality of
Experience)
QoS perceived by Users for CFSes E.800,
TR149
QoSE, QoUE
(*) definition out of scope of this document, but related.


3. SLA Life Cycle Processes
3.1. Overview

Before, during and after the SP-Customer relationship, the SLA follows several phases
described in Figure 14.

Initial
Specification
Activation /
Execution
Modification
Termination

Figure 14. SLA Life Cycle Phases

SLA initial specification phase
SLS Parameters, SLS Thresholds, SLS Expressions, Measurement Points, Estimators,
and SAPs (i.e. what will be measured, what quantitative values are the targets, how and
when it will be measured, where will the measurements be performed, and how the SLA
Management will be supported) are specified:
beforehand by the SP (service definition during the Product Lifecycle Management
and Operations Support and Readiness phases) and by the Customer (preparation of
requirements).
The Customer requirements may have a reduced scope (focus more on SLS items
and on SLA Violation procedures, and maybe less on SAPs and on SLA support
infrastructure), but can re-use the SLA specification formalism and methodology.
In addition, the SP may be in the more complex case of being an Integrator, thus
requiring more effort on the SLA specification, between their Customer role and their
SP role.
during a contract negotiation (customized SLA) between the SP and the Customer


The SLA support infrastructure should be part of the SP-side specification, to support
the SLA enforcement. This infrastructure can include a range of measurement equipment
and EMS/NMS for configuration, management, and supervision, an SQM (Service
Quality Management) system, as well as corresponding staff for Operations and
Customer support,.

The notification and escalation processes in case of SLA violation (i.e. when an SLM(T) is
not achieved at time T) are also specified : raising warnings and alarms in supervision
tools, triggering automated diagnostics operations or self-healing operations,
automatically contacting on-call staff, etc.

The business consequences of each SLA violation should also be specified (financial
penalty, obligation to restore performance according to SLA, etc.) with possible branching
scenarios of consequences.

SLA activation/execution phase
Once the Service starts being delivered, the SLA support infrastructure is activated, and
permanently (i.e. at the agreed sampling rate) verifies whether the SLA is satisfied (by
collecting measurements and constructing the SLM(T)s) and produces reports. If and
when the SLA is not satisfied, the specified SLA Violation procedures are executed.

Self-assessment of the SLA itself is also executed, for the sake of continuous
improvement, and may lead to modifications if inadequacies are found and agreed upon
between Customer and SP.

SLA modification phase
If an SLA is modified during its lifetime (Service modification, contract change, SLA
improvement decision, etc.), then all specifications should be reviewed and possibly
modified, following the same processes as during the initial specification phase.

SLA termination phase
If the contract is terminated (normal expiration without renewal, or interruption), then the
SLA does not apply anymore and its support infrastructure can be reallocated to other
tasks or be decommissioned.

The process of specifying an SLA takes place during two of these phases (Initial
Specification and Modification), and is described in section 3.2.

The process of actively using an SLA (permanent monitoring, reporting, escalation) is the
actual process of SLA Management, and is described in section 3.3. It takes place in the
SLA activation/execution phase.

Finally, a checklist of recommendations for SLA life cycle processes (Specification and
Management) is made in section 3.4.


3.2. SLA Specification
In this section, a methodology framework for specifying SLAs is presented.

Also, four SLA specification cases are briefly described: SP-side Proposed SLAs,
Customer-side Requirements, SP-Customer negotiation of Customized SLAs, and SP
Integrator specific issues.

3.2.1. Introduction to SLA Specification Methodology
SLA specification can take place during two SLA lifecycle phases: Initial Specification and
Modification. It consists in:
choosing the KQIs which are used as actual SLS parameters
choosing the actual values for the corresponding SLS Thresholds which implicitly
determine SLA violations
describing which estimators are used for measurements and aggregations
describing which expressions are used for conditions
describing the SLA Violation procedures, i.e. what are the consequences and
escalation processes in case of observed SLA violations.

The main goals of the SLA Specification methodology are to ensure:
SLA relevance
SLA
: make sure they are SO-driven, and take QoE into account
completeness/non-redundance
SLA
: use analysis matrices which check service
functions and performance categories
feasibility

: make sure measurements and aggregations are available and are
scalable (technically and economically), make sure SLA Management support
infrastructure is available and scalable
Customers should re-use elements of the SLA specification methodology to create their
Requirements. Standardization and commonality of SLA components, especially metrics,
can accelerate negotiations and improve SP and Customer productivity, thereby reducing
overall costs.


SLS (Prm, Thr, Exp),
MP, Est, SLAViolProc
candidate
SLA items
SLS (Parameters,
Thresholds, Expressions)
SLA Violation
Procedures
Measurement Points,
Estimators
SLAs or
Requirements
Library
of metrics
(Input)
Relevant
Complete
Step 5
Finalize
Step 3
Feasibility
Step 2
Completeness
Step 1
Transform input into
SLA candidate items
(reference)
(reference)
Metric
Template
New
Metric
(review until
complete
and feasible)
Feasible
(add/remove/modify)
(add/remove/modify)
Step 4
Document and
Review

Figure 15. Common pattern: SLA Specification processes

3.2.2. Step 1: Initial SLA draft
Input
o SO for both SP and Customer
:
o Product Offering for SP
o High-level requirements for Customers
o SLA Templates
o Customer Detailed Requirements for negotiated Customized SLAs.
o Metrics library
4

.
Output

: candidate SLA items
Overview
o translate informal text into formatted candidate SLA items
:

4
A standard metrics library including SLA metrics is planned by the Telemanagement Forum.

o ensure candidate SLS Thresholds and SLA Violation Procedures reflect
Customer expectations (explicit expectations from Customer Requirements,
or implicit expectations from SP analysis)
o can also use an analysis matrix

Good SLAs should reflect business concerns and expectations: they should translate the
Service Objectives (SO) of both parties (SP and Customer) into meaningful and relevant
service measurements (KQIs used as SLS parameters, based on supporting KPIs which
are necessary for the computation of KQIs).

From a business perspective, end-user satisfaction should eventually matter the most,
(obviously for the Customer role, but also for the SP role), so QoE-related KQIs are the
most important. KQIs related to resource or service usage or to resource or service
reliability are important for the SP (e.g. to estimate OPEX or to comply with government
regulations), but do not really matter to a Customer. Such KQIs can be used a SLS
parameters in OLAs, where the Customer role is in the same organization as the SP role.

The construction of the SO itself is out of scope of this document: we consider the SO as
an input when working on an SLA. Still, we can mention a couple of points regarding SO
construction, to ensure they are usable from an SLA point of view:
the methodology should start from a list of needs and expectations, forming an
unstructured SO.
then use methods like Key Factor Analysis (cf. TR149 [2]), Principal Component
Analysis, Data Clustering, etc. to sort these needs and expectations, and produce a
structured SO, from which it will be easier to determine relevant candidate KQIs,
thresholds, expressions and SLA Violations procedures.

3.2.3. Step 2: Verify SLA Completeness
Input

: current list of SLA items
Output

: updated list of SLA items
Overview
o agree on which analysis matrix to use, and which cells are in scope
:
o verify each matrix cell in scope, check for redundancies, gaps,
inconsistencies
o KQI/KPI breakdown based on technology analysis
o if needed (i.e. missing in the matrix) and available, import Metrics (as KQIs)
from libraries
o if relevant, propose new Metrics using Template, for inclusion in library

To ensure an SLA is complete in terms of SLS parameters (and corresponding
thresholds and violation procedures), an analysis matrix is very useful. An analysis matrix
considers service functions and performance categories (or criteria): each identified
service function may be evaluated according to each performance category.

For a given matrix, a given metric can be classified and placed in a cell, i.e. the metric
corresponds to a certain service function (the actual service instance within the function
should be indicated) and a certain performance category.

The overall approach for making sure an SLA specification is complete is the following:

define which analysis matrix
at a high level, decide
will be used (i.e. which categorizations are used for the
service functions and for the performance categories). This task can be performed
from scratch, or existing matrix templates can be used, with modifications if needed.
The SO can be used to help making choices for this definition.
which cells
then, the candidate metrics (KQIs and KPIs which are considered regardless of any
matrix) are re-examined and possibly mapped on the chosen matrix, or left out.
in this matrix will be required. Normally, they should
all be taken into account, but some particular reason or constraint may result in
leaving out certain cells. Here too, the SO can be used for this choice.
it then becomes apparent which cells are satisfactory from an SLA specification point
of view, and which cells need further work (too many or too few metrics). All required
cells for a given SLA should have at least one SLS Parameter. If a cell contains
several KQIs (perhaps with some redundancy, a decision to eliminate some of them
can be taken, or a summary KQI can be derived (using some empirical
formula/estimator, to be validated, based on these KQIs) and provide a summary of
the function/criteria.

When the KQIs (now promoted to SLS Parameters) are all listed in each required cell, the
SLS Thresholds and SLS Expressions are detailed for each, as well as the supporting
KPIs, estimator methods, measurement points, and SLA Violation Procedures. The
purpose of this handbook is not to list all the possible KQIs of each cell. Examples will be
given in the appendixes in R3.1.

Defining an analysis matrix for telecommunication services is not trivial: there are several
ways to categorize service functions and performance categories.

There is an existing body of template analysis matrices:
ITU-T G.1000 (2001) [6] provides a complete 11*7 analysis matrix for all aspects of
telecommunication services. It identifies eleven service functions (Sales and Pre-
Contract Activities, Provision, Alteration, Service Support, Repair, Cessation,
Connection Establishment, Information Transfer, Connection Release, Billing,
Network/Service Management By Customer) according to seven criteria (Speed,
Accuracy, Availability, Reliability, Security, Simplicity, Flexibility).
o note: E.802 (2007) uses the same analysis matrix as G.1000.
TM Forum BMF (Business Metrics Framework) Release 3.0 (GB935 V4.5 [16])
proposes a 6*7 analysis matrix (for classification of business metrics related to
telecom services) with a Customer side and an SP side. The (Customer/SP)
identified service functions are: awareness/acquisition, interaction/CRM,
agreement/fulfillment, support need / assurance, payment/billing, loyalty/retention,
and disengagement/attrition. The criteria for Customer experience are Access, Time,
and Quality (covering Usability, Accuracy, and Availability). The criteria for
Operational Efficiency are Cost, Time, Quality (covering Defects and Simplicity), and
Effectiveness (Process Flexibility&Automation, Utilization).

Other performance criteria could be considered, depending on the chosen classification
logic.

We propose here an example analysis matrix, with an example set of functions and
criteria which make sense in the context of SLA management for current data-centric

networks and service-centric customer applications. It should be noted that the choice of
which matrix to use is always open.

We propose a new 4*4 template analysis matrix with the following four service functions:
1) (Service wrap) Fulfillment / Agreement
2)
: activities associated with Customers ordering
initial service, and SPs activating the corresponding service (duration of order
fulfillment, success rate of activations, etc.)
(Service wrap) Assurance / Support Need
3)
: activities associated with Customers
reporting problems, and SPs resolving them (duration of resolution, success rate of
first resolution attempts, etc.)
(Service wrap) Billing / Payment
4)
: activities associated with the billing for a
telecommunication service to a customer (notification on time, tariff clarity, accuracy
(absence of errors), choice in notification methods and payment methods, ).
In-Service

: all features related to the service itself. Can be broken down in categories
when applicable, such as Security or Interaction Control.
The suggested four performance criteria are as follows:
1) Availability
[7]
: Availability of an item to be in a state to perform a required function at a
given instant of time or at any instant of time within a given time interval, assuming
that the external resources, if required, are provided. (E.802 definition )
2) Restorability
[14]
: Should a disruption occur, services must be capable of being
reprovisioned, repaired, or restored to required service levels on a priority basis.
(ATIS-010009 description )
3) Reliability
[12]
: The probability that a service can perform a required function under stated
conditions for a given time interval (E.800 definition ).
4) Integrity
[12]
: The degree to which a service is provided without excessive impairments,
once obtained. (E.800 definition ).

Service
wrap
In service
Payment CRM/
Billing
Support Need CRM/
Assurance
Agreement CRM/
Fulfillment
Integrity Reliability Restorability Availability Customer SP
Service
wrap
In service
Payment CRM/
Billing
Support Need CRM/
Assurance
Agreement CRM/
Fulfillment
Integrity Reliability Restorability Availability Customer SP

Figure 16. GB917 v3 proposed analysis matrix for SLA completeness
As already mentioned, this proposed matrix is only a suggested template, and other
matrices can be used in a given SLA specification. Not only could the In-Service row be
further detailed, but also additional category columns could be added, such as Security,
to evaluate the Security performance of any feature, not just the Security-specific
features.


Experience and available libraries of metrics can be taken advantage of when deciding
which particular SLS Parameter to choose, which KQI formulas or estimators to use, or
which KPIs are necessary.
Libraries of Metrics

Each organization and standard body can maintain lists of tried and tested KQIs/KPIs
(meaningful, feasible, scalable, accurate), and make them public or not, to be used as
input when selecting the SLS Parameters of an SLA.

The choice of KQIs used as SLS parameters can therefore have two kinds of origin: top-
down (determined by the SO or by the need to cover a certain service function and a
certain performance category, i.e. to fill an analysis matrix cell) or bottom-up (determined
by available technical metrics from which higher level aggregations can be constructed
and are found to be relevant).

Clearly, the final list of SLS parameters should be mostly top-down (SO-driven), and only
partly bottom-up (needs to be feasible), perhaps like an 80%-20% distribution.

An SLA violation occurs when a measured performance of some SLS Parameters is not
as good as the corresponding SLS Thresholds used in SLS Expressions.
SLA Violation Procedures

In theory, a separate handling procedure could be given for every SLS parameter. In
practice, a set of handling procedures can be specified, and the list of applicable SLS
parameters can be given. The analysis matrix can be used to define the handling
procedures. However, it should be verified that every SLS parameter is indeed attached
to a violation handling procedure.

A handling procedure details the proposed resolution processes, escalation processes,
and penalties associated to every event.

During the SLA Specification phase, the SLA violation response procedures should also
be defined, insofar as they impact the Customer. SLA violation detection procedures
would be part of the SLA Management procedures, and so do not need to be defined
here.

3.2.4. Step 3 Verify SLA Feasibility
Input

Output

Overview
o verify technical/economic feasibility ("what, where, when, how") : raw
NE/probe counters (KPIs) exist and are accessible, scalability, frequency and
volume of data, correctness of estimators, costs
:
o possibility of APIs if data exchange is needed
o SQM infrastructure and support is available
o SLA Management support is available


A validation of the chosen metrics (either KPIs, or KQIs chosen as SLS Parameters)
should be performed to ensure they are indeed measurable, and remain measurable in a
large deployment.

Raw counters have to be actually implemented in the installed versions of monitored
entities, export interfaces have to be accessible at the desired frequency (i.e. they can
sustain the induced load), and the management systems has to be able to collect all the
data and compute all the KQIs within the limits of the available resources (server CPU
and memory, port bandwidth, disk storage).

If additional parameters (other than measurements, for instance inventory data about
customers or topology, or architecture-dependent coefficients used in estimator
mathematical formulas) are needed to compute SLS Parameters, their availability must
be verified.

The feasibility study has to take collisions into account: not only each SLS Parameter
should be feasible individually, but also all of them together.

A need for Metric exchange APIs can exist, especially if an Actor is an Integrator. The
APIs should be described at a high level in the SLA specification (list of SLS parameters,
technology used, standard or proprietary) and point to a detailed technical reference.

The feasibility of the SLA management support (including the SQM infrastructure) is
essentially an SP internal issue, but may have some visibility to the Customer role, in
which case a high level description should be provided in the SLA. The SLA should at
least mention that SLA Management support is available and guaranteed. The exact
organization is out of scope of the SLA specification.

3.2.5. Step 4: Document and Review
Input

Output

Overview
o document current version of SLA (or Requirements)
:
o check if Step 2 and Step 3 are satisfactory, else iterate

This step ensures the current version of the SLA is completely documented, and follows
whichever documentation processes are in place in the organization.

For negotiated SLAs, the impact of impairments should be described in the Customers
own business terms and financial loss, for instance by using KQIs measuring a Customer
financial loss associated with a certain service failure (see case of Customer-defined
SLAs in TR148 [13]).

3.2.6. Step 5: Finalize
Input

Output

: finalized list of SLA items
Overview:

o document final version of SLA (or Requirements)

This step is the final verification of exit conditions, and can be materialized in a decision
review meeting.

Figure 17 summarizes the SLA Specification steps as processes:

SLA
Specification
Step 4
Document
and Review
Step 2
Completeness
Step 3
Feasibility
Step 1
Initial Draft
Step 5
Finalize
Step 4
Document
and Review
Step 2
Completeness
Step 3
Feasibility
Step 1
Initial Draft
Step 5
Finalize

Figure 17. SLA Specification processes (composition and sequence flow)


3.2.7. Three SLA Specification Cases
SP SO
SP library
of metrics
candidate
SLA items
Product Offering
SLS (Parameters,
SLA Violation
Procedures
Measurement Points,
Estimators
Review
Proposed
SLAs
Completeness
Feasibility
SQM
SLO
Std library
of metrics
Metric
Template
New
Metric
SLAM
Support
SQM NOC
CRM

Figure 18. SP-side initial specification: creation of Proposed SLAs

Before the first contract, when the Service (or Product Offering containing a Service) is
being designed and developed (or integrated), the SP will want to prepare Proposed
SLAs to be offered to or negotiated with Customers.

Referring to Figure 18, some early input for SLA can be collected at first, to build a list of
candidate SLA items:
unsorted, unclassified KQIs which could serve as SLS Parameters
KPIs which are necessary for the KQIs or which could be interesting for technical
specialists
expected quantitative values (achievable performance at design/development time,
which can be updated following testing phases) for corresponding SLS Thresholds
and SLS Expressions
Estimator methods and aggregation formulas for measurements
measurement units
time granularities (data collection and presentation)
potential SAPs in generic blueprint architectures
default SLA Violation procedures
SLA Templates

The main driver for this material is the SP SO (Service Objectives), to ensure the SLA is
relevant.

Then, this input is reviewed for completeness and feasibility. Existing libraries (SP-internal
or public standards) may be used to add missing metrics and use them as SLS

Parameters. Conversely, KQIs (or even KPIs) identified for an SLA may be proposed to
be integrated in a metric library, using a metric description template.

Several Proposed SLAs can be produced for the same service, corresponding to different
levels (for instance, the archetypal Gold, Silver and Bronze levels).

Moreover, the SLA Management support infrastructure can be described at a high level,
as another output of the review: Operations and Customer Management. Also,
SP-internal SQM SLOs can be derived from the Proposed SLA specification, for
additional measurements and service level objectives.

The review phase is iterated until the Proposed SLAs are found to be satisfactory.

Std library
of metrics
Cust SO
Cust library
of metrics
candidate
SLA items
High-Level
Requirements
SLS (Parameters,
SLA Violation
Procedures
Measurement Points,
Estimators
Review
Detailed
Requirements
Completeness
Metric
Template
New
Metric

Figure 19. Customer-side initial specification: creation of Requirements

Likewise, when a Customer is defining their Service needs (based on their Service
Objectives, see Figure 19), they may prepare a list of KQIs to be used as SLS
Parameters, and specify their performance requirements in terms of SLS Thresholds and
SLS Expressions. The expected SLA Violation response procedures can also be
detailed.

The Customer may focus more on reviewing the completeness of the Requirements
rather than the feasibility, which is more of an SP concern.

The benefits of using standard metrics (as SLS Parameters) are clear for both parties: the
Customer will be able to compare rapidly an SP Proposed SLA with their Requirements,
and identify possible gaps more rapidly, for faster resolution of issues.



SP SO
SP library
of metrics
candidate
SLA items
Product Offering
SLS (Parameters,
SLA Violation
Procedures
Measurement Points,
Estimators
Review
Proposed
SLAs
Completeness
Feasibility
SQM
SLO
Std library
of metrics
Metric
Template
New
Metric
SLAM
Support
Cust SO
Cust library
of metrics
candidate
SLA items
High-Level
Requirements
SLS (Parameters,
SLA Violation
Procedures
Measurement Points,
Estimators
Review
Detailed
Requirements
Completeness
Metric
Template
New
Metric
SQM NOC
CRM
Cust-SP
Negotiation
Customized
SLAs
Feasibility

Figure 20. Customized SLA Specification illustration: using SP and
Customer inputs to create Customized SLAs

When an SP and a Customer negotiate a contract, the Customer may choose to use
directly an SP Proposed SLA, or to negotiate a Customized SLA. The formal input of the
Customized SLA is the SP Proposed SLAs and the Customer Requirements (Figure 20).
The process of discussing and combining these inputs can follow the same pattern of
reviewing completeness and feasibility, and iterating until both parties are satisfied.

The SP may take advantage of these SP-Customer negotiations to update their library of
SLA Templates and Proposed SLAs, as well as their SLA Management Support
infrastructure, including SQM SLOs.

3.2.8. Integrator and interdependence specific issues
An Actor playing the role of an Integrator will have a Service Objective as a SP which will
reflect on their SOs as Customer. In particular, they will have end-to-end service
performance requirements: the level of service their own Customers will require or
expect, or that the Integrator will want to offer. So the Integrator as a Customer will use
this input when looking at the Proposed SLAs of their SPs, or when negotiating SLAs with
these SPs, as illustrated in Figure 21.

By applying a systematic methodology with all their supplier SPs, the Integrator will
ensure that each SLA with each supplier SP will align with their own SLAs with their
Customers. Also, if APIs are needed for exchanging data, this approach increases the
level of uniformity and standardization (since supplier SPs will now have Proposed SLAs,

analysis matrices and APIs for other Integrators), always beneficial for all participants in a
value network.

Cust1
Integrator
Customer
Role
SP
Role
Customer
Role
SP1
SP
Role
SP2
SP
Role
SLA1
SLA
SLA2
SP SO Cust SO
Cust SO
SP SO
SP SO

Figure 21. Integrator role in SLA Specification

3.3. SLA Management
To be completed in R3.1.


3.4. Summary: Checklist of Recommendations
SLS Parameters should consist only of KQIs (i.e. no KPIs, even though KPIs can
be used to build KQIs).
SLS Parameters should consist as much as possible of QoE-related KQIs.
If a Customer corresponds to several Users, the QoE KQIs for this Customer
should reflect the QoE of each User.
SLS Thresholds (applying only to SLS Parameters) should be expressed using
threshold values or ranges, and a direction of crossing (from good to bad)
SO should be the main driver of SLAs and should be listed and documented in
the SLA (or referred to, if it exists as a formal document).
measurement infrastructure should be detailed in the SLA specification
measurements in SLM(T)s should be reported in terms of distributions rather than
averages
for the SLA specification, agree on which analysis matrix should be used, and
which cells are required
verify all required cells have at least one SLS Parameter
for a given SLS Parameter in an analysis matrix, the corresponding service
instance within a service function (matrix row) should be indicated
if there are several SLS Parameters in a required cell, verify they do not overlap.
Otherwise, choose which to eliminate or combine.
every SLS parameter should be attached to a violation handling procedure
the feasibility of each KQI and KPI participating in SLS parameters has to be
verified
the collective feasibility of all SLS parameters together has to be verified
when deploying a monitoring and SLA verification tool, the following items should
be tested : the connections between the monitoring tools and monitored entities
are operational, the SLS parameters are all collected and computed correctly, the
SLS Threshold values are all correct, the reports of SLM(T)s and SLA Violations
are operational, the induced load on monitored entities is within the allocated
bandwidth, and the system continues to operate over long periods of time
if an Actor has the Integrator role, they have to ensure e2e quality is covered by
corresponding KQIs in their SO, so that these KQIs become SLS parameters
in a Value Network, SLA chains have to be consistent (responsibility of the
Integrator), so that APIs can be developed or even standardized to share
SLM(T)s between monitoring and SLAM tools
if an API for metric exchange is used, a high-level description should be provided
in the SLA specification, as well as a reference to a detailed description
the availability of an SLA management support (including the SQM infrastructure)
should be mentioned, and possibly described at a high level
To be continued in R3.1


4. Next steps
This release R3.0 of the Handbook focuses on definitions and SLA specification
methodology. The next release of this Handbook (R3.1) will complete this R3.0 with
processes for SLA management, as well as with illustrating examples (IPTV, ETS,
business VPNs). R3.1 will also include a review of the business processes related to
SLAs, the SLA-related data model classes, and the Business Benchmarking Metrics
Framework in the context of SLAs.


Appendix A: Abbreviations
Abbreviations and Acronyms
API Application Programmable Interface
APS Automatic Switch Protection
ATIS Alliance for Telecommunication Industry Solutions
ASON Automatically Switched Optical Network
CFS Customer-Facing Service
CPE Customer Premise Equipment
CRM Customer Relationship Management
EMS Element Management System
EP End Point
ETS Emergency Telecommunications Service
ETSI European Telecommunications Standards Institute
GETS Government Emergency Telecommunications Service
IETF Internet Engineering Task Force
IF Information Framework (TM Forum group)
IP Internet Protocol
IPTV IP Television
IVR Interactive Voice Response
ITU International Telecommunications Union
KBO Key Business Objective
KPI Key Performance Indicator
KQI Key Quality Indicator
LAN Local Area Network
LoS Level of Service
LSP Label Switched Path
MOS Mean Opinion Score
MPLS Multi-Protocol Label Switching
MVC Market Value Chain
MVG Market Value Graph
MVT Market Value Tree
NE Network Element
NMS Network Management System
OLA Operational Level Agreement
OSI Open Systems Interconnection
OSS Operations Support System
PSTN Public Switched Telephone Network
QoS Quality of Service
RFC Request For Comment (IETF)
RFS Resource-Facing Service
SAP Service Access Point
SLA Service Level Agreement
SLA-M Service Level Agreement Management (TM Forum group)
SLO Service Level Objective
SLS Service Level Specification
SP Service Provider
SQM Service Quality Management
SSN7 Signaling System Number 7

TDM Time-Division Multiplexing
TMF Telemanagement Forum (TM Forum)
TSP Telecommunications Service Priority
UNI User-Network Interface
VOD Video On Demand
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VoIP Voice over IP
WAN Wide Area Network
WPS Wireless Priority Service


Appendix B: References
References
Reference Description
[1] ITU-T M.3320 Management requirements framework for the TMN X-Interface (1997)
[2] TM Forum TR149 Technical Report:
Part 1 - Holistic e2e Customer Experience Framework
version 0.8 (May 2009)
[3] TM Forum GB922 Addendum 0 v1.1 (Information Framework Primer)
[4] TM Forum GB921, Business Process Framework Suite (especially addendum D :
Process Decompositions and Descriptions)
[5] ITU-T E.860 Framework of a service level agreement (2002)
[6] ITU-T G.1000 Communications quality of service: A framework and definitions (2001)
[7] ITU-T E.802 Framework and methodologies for the determination and application of
QoS parameters (2007)
[8] ITU-T Y.1315 QoS support for VPN services Framework and characteristics (2006)
[9] ITU-T M.3342 Guidelines for the definition of SLA representation templates (2006)
[10] TM Forum GB934 Best Practice: Voice over IP SLA Management
[11] TM Forum GB938 Best Practice: Video over IP SLA Management
[12] ITU-T E.800 Definitions Of Terms Related To Quality Of Service (2008)
[13] TM Forum TR148 Technical report: Managing the Quality of Customer Experience
[14] ATIS 0100004 Availability & Restorability Aspects of Emergency Telecommunications
Service (ETS) (2006)
[15] ATIS 0100009 Overview of Standards in Support of Emergency Telecommunications
Service (ETS) (2006)
[16] TM Forum GB935 Business Benchmarking Metrics Framework, Release 3.0, version
4.5, February 2010
[17]
Source or Use
Sources of technical information have been provided where relevant within the body
of this application note.
IPR Releases and Patent Disclosures
This handbook makes reference to international standards and recommendations,
including:
o ITU-T E.800, E.802, E.860, G.1000, M.3320, M.3342

o ATIS 0100004, 0100009

In order to implement this handbook, it is not necessary to implement any or all of
these recommendations in full. However, a best practice solution would use one or
more of these standards and recommendations.
Some of these standards and recommendations include IPR claimed by one or more
organizations, which, to the best of the knowledge of the SLAM team, has been made
available under the usual conditions of the ITU-T and ATIS. In addition, it is believed
that there is no new material introduced in this handbook (i.e. material that has not
already been defined in other standards and recommendations) that is the subject of
any IPR claim.


Appendix C Illustration of definitions
This Appendix contains illustrations and examples, to help understanding definitions
provided in section 2.
KPIs and KQIs

Example of KPIs and KQI in the case of VoIP (see GB934 [10]):
KPI-1: interarrival time between IP packets at a measured port, for example in
nanoseconds. List of the last 50 entries.
C1, component of KQI-1 : for a Customer placing a call, MOS-LQO
N
(Mean Opinion
Score, Listening Quality Objective measurement in Narrow-band audio context, cf.
P.564), score between 1 (bad) and 5 (excellent), with at least 2 decimal digits, relative
to the past interval of 10 seconds and to a given call, and whose computation takes
into account the KPI-1 (IP packet interarrival) measured at the 2 SAPs of the two
parties, as well as other IP impairment measurements, and signals analysis. The
measurement of this KQI-1 component C1 could yield different values for the two
parties.
KQI-1: percentage of Customer call with good audio quality over a time period (e.g.
busy hour, week, month). Takes into account all calls placed in the entire network,
aggregated per hour timeslot (xx:00:00 to xx:59:59), with KQI-1 component C1
(MOS-LQO
N
) higher than 3.65. Target value: should be more than 99.9%.

KQI-1 could be used as an SLS Parameter called Percentage of Customer calls with
good audio quality over the last 24 hours, and the target value of 99.9% could be used
as an SLS Threshold Minimal Customer call audio quality over 24H, with a numerical
value of 99.9, and a Good-To-Bad direction of crossing equal to High-To-Low. Then an
SLS Expression could be :
Percentage of Customer calls with good audio quality over the last 24 hours >
Minimal Customer call audio quality over 24H.

SLAs and Measurements

Figure 22 shows an example of an Implicit SLA (derived from the SP SO to raise the bar
on delivered call audio quality based on SP assumptions about Customer expectations).


SP SO :
develop enterprise VoIP revenue;
address complaints about
bad audio quality;
ROI for recent network upgrade
SLS :
measure audio quality
in calls of
all customers,
on a weekly basis;
set ambitious SLO
KQI component C1:
call MOS-LQ
N
for one Customer
Measurements
Measurement
Point : SAP or UNI
SLA with
Enterprise
Customers
SLS Thr :
>99.9%
KPI-1:
IP packet
interarrival time
Measurements
SLM(week34):
99.95% : OK
SLM(week35):
98.62% : not OK
Format :
histogram of 49 interarrival times
based on 50 nanosecond-accurate
timestamps
Estimator :
MOS-LQ
N
estimator for 10 seconds,
using KPI-1, other IP impairments,
or signals analysis
KQI-1 :
% VoIP Customers with
good audio quality
over a week
Measurements
Estimator :
count all
KPI-2 (MOS-LQ
N
) > 3.65,
for all calls
in entire network,
hourly aggregation

Figure 22. Example of SO-driven definition of an Implicit SLA and its
measurements

VPLS example

Let us consider a VPN example (Figure 23), which corresponds to the informal diagram
from Figure 9. A service provider SP1 has a VPN product offer SP1-VPN, and has
agreed with customer C1 to provide a VPLS-based VPN, which would be for example
product SP1-C1-VPN-VPLS. A certain VPLS instance VPLS-instance1 is deployed in
SP1s network, and is made accessible to C1s devices through some service access
points. VPLS-instance1 is a CFS, and is part of the realization of the VPLS-based VPN
product instance. Networking technologies such as MPLS, IP, Ethernet, as well as the
corresponding OAM tools, are RFSes used by SP1 in their own network, to support all
CFS instances. Logical resources such as LSPs (Label Switched Paths) and PW
(Pseudo-Wires) are used to implement RFSes. For example, VPLS-instance1 could be
implemented using ten LSPs LSP1,.., LSP10.

The list of entities in that example is as follows:
SP1 : service provider (role)


C1 : customer (role)
SP1-VPN: product offer

, one among other product offers from SP1
SP1-C1-VPN-VPLS: product instance

, object of a contract between SP1 and C1,
instance of SP1s product offer in the VPN area, using VPLS technology
VPLS-instance1: CFS

, realization of the product instance, used by C1s devices. This
VPLS-instance1 corresponds to the network entity configured by SP1s IT or
Operations staff in the routers and switches.
MPLS: RFS

, used in SP1s network, to support CFSes such as VPLS-instance1.
LSP1,..,LSP10 : logical resources

, used in SP1s network, to implement the portion of
the MPLS resource-facing service which supports VPLS-instance1.
SAPs: the Customer-Facing Service VPLS-instance1 could be presented to customer
C1 through 20 SAPs SAP1,..,SAP20, which would l

ook like Layer2 Ethernet ports to
C1s Layer2 Ethernet devices. SP1s SAPs will perform encapsulation,
multiplexing/demultiplexing and policing operations to C1s traffic, and will interact
with other layers (like IP/MPLS) in SP1s devices where they are deployed. So in this
case, for the SAPs, the service is a virtual LAN (VPN realized as a VPLS), the
network layer is Layer 2 Ethernet, the same-service remote entities interacting with
the SAPs are C1s Ethernet ports, and the other services from other layers locally
accessed by the SAPs include the IP/MPLS Resource-Facing Services.
SP1
(Service
Provider)
C1
(Customer)
SP1-VPN
(Product Offer)
SP1-C1-VPN-VPLS
(Product Instance)
VPLS-instance1
(CFS)
EthPort
MPLS
(RFS)
SAP
Devices Devices
(RFS)
LSP
(Logical
Resource)

Figure 23. Illustration of Products, Services and SAPs with a VPN example

SLAs and OLAs could be instantiated as follows (see Figure 24):
SP1 : provider, no SLA
C1 : customer, no SLA
SP1-VPN: product offer, may have an Implicit SLA, when applied to all existing
product instances in this product offer. SP1 may choose to set an Implicit SLA for the

global VPN service, regardless of the individually contracted SLAs with customers for
each VPN. If several departments of SP1 collaborate to provide the global VPN
service, they may agree on OLAs between themselves.
SP1-C1-VPN-VPLS : product instance
VPLS-instance1 : has an SLA, based essentially on QoE KQIs and on network
technology and application KPIs (L1-L7)
MPLS: may have OLAs and Implicit SLAs, depending on SP1s organization. If SP1s
MPLS interacts with MPLS networks of other service providers, then SP1s MPLS
may be covered by separate SLAs agreed upon between SP1 and these other
service providers.
LSP1, ..., LSP10 : would probably not have their own OLA, unless some automation
between software agents (cf. IPX/IPSphere) is deployed, to negotiate them
automatically (beyond auto-configuration). However, LSP KPIs/KQIs would be
measured at the LSP level, and be used and propagated upwards (consolidation and
aggregation) in the SLA, OLA, or Implicit SLA of the higher-level entities.
SAP1,.., SAP20 : like the LSPs, would probably not have their own OLA (they could
have an OLA in the case of SAPs with opening hours, or to distinguish between
SAP categories, with some SAPs more critical than others), but would be subject to
measurements, which would in turn be used as input for upper SLA, OLA, or Implicit
SLA.
SP1
(Service
Provider)
C1
(Customer)
SP1-VPN
(Product Offer)
SP1-C1-VPN-VPLS
(Product Instance)
VPLS-instance1
(CFS)
EthPort
MPLS
(RFS)
SAP
Devices Devices
(RFS)
LSP
(Logical
Resource)
OLA
OLA
KQI
KPI
KPI KPI
KPI
SLA
iSLA
iSLA
SP2
MPLS
(RFS)
SLA
KPI

Figure 24. SLAs, OLAs, and Contracts in a VPN example


Appendix D Use Case 1: IPTV SLA
Refer to GB938 [11].


Appendix E Use Case 2: Emergency Telecom Services SLA
Refer to ATIS ETS [15].


Appendix F Use Case 3: Business VPN SLA
Refer to Y.1315 [8].


Administrative Appendix
This Appendix provides additional background material about the TM Forum and this
document. In general, sections may be included or omitted as desired, however a
Document History must always be included.
About this document
This is a TM Forum handbook. The handbook format is used when:
o The document lays out a core part of TM Forums approach to automating
business processes. Such handbooks would include the Telecom
Operations Map and the Technology Integration Map, but not the detailed
specifications that are developed in support of the approach.
o Information about TM Forum policy, or goals or programs is provided, such
as the Strategic Plan or Operating Plan.
o Information about the marketplace is provided, as in the report on the size
of the OSS market.
Document History
Version History

Version
Number
Date
Modified
Modified by: Description of changes
0.1 2009-01-29 SLA team (TAW) drafted structure of document
0.2 2009-03-06 Gerard Damm included Ron Roman input for 2.1
0.3 2009-03-17 Gerard Damm filled sections 2.2, 2.3 (proposed new
section on SLA interdependency), some 2.4
0.3.5 2009-03-20 Gerard Damm updated section 2, input in section 3.1
0.3.8 2009-04-03 Gerard Damm streamlined section 2, input in 3.2-3.4
0.3.9 2009-04-23 Gerard Damm more references, new matrix
0.4.0 2009-07-07 Gerard Damm included inputs (RR,DM,LP,QHT)
0.4.1 2009-07-10 Gerard Damm post-audioconf edits
0.4.2 2009-08-10 Gerard Damm post-review edits; definitions summary
0.4.4 2009-08-20 Gerard Damm post-review edits; detached QoS from SLA
0.4.5 2009-09-18 Gerard Damm
0.4.6 2009-10-12 Gerard Damm more or less finalized definitions; reshaped
section 3 in light of new definitions
0.4.7 2009-11-02 Gerard Damm reviewed SLA lifecycle section
0.4.8 2009-12-02 Gerard Damm reworked SLA specification section
0.4.9 2009-12-13 Gerard Damm 3.3 and 3.4

0.5.4 2010-01-25 Gerard Damm pre-TAW edit
0.5.7 2010-01-27 Gerard Damm mid-TAW edit
0.6.0 2010-02-17 Gerard Damm post-TAW edit
0.6.2 2010-03-03 Gerard Damm more cleaning up
0.6.4 2010-04-05 Gerard Damm specification methodology finalized
0.6.6 2010-05-07 Gerard Damm R3.0 for Member Evaluation
0.7 2010-05-10 Alicja Kawecki Minor cosmetic corrections for web posting
and ME
0.8 2010-09-09 Gerard Damm handled CR from J une 18
th
: Business
Process Framework instead of eTOM,
Interface Framework instead of SID
0.9 2011-01-20 Alicja Kawecki Updated to reflect TM Forum Approved
status
Release History
<This section records the changes between this and the previous Official document release>

Release Number Date Modified Modified by: Description of changes
1.0
1.5
2.0
2.5
3.0 2010-05-07 Gerard Damm Update of R2.5, focus on
Definitions and Specification
methodology

Acknowledgments
This document was prepared by the members of the TeleManagement Forum SLAM
team:
o Gerard Damm, Alcatel-Lucent (Editor)
o Greg Bain, DHS
o J ohn Timms, Telchemy
o Laurent Philippart, Alcatel-Lucent
o Quan Huynh-Thu, Psytechnics
o Ron Roman, Telcordia
o Dave Milham, TM Forum
o Tina OSullivan, TM Forum
Documentation and work from standards bodies and other forums have also
contributed to the evolution of this document. This access was via public information
or TM Forum member knowledge. This list of standards bodies and forums is not
exhaustive and does not imply review and concurrence by these organizations or

their representatives. It is important however to acknowledge the work and their
influence on the TeleManagement Forum work:
o ITU-T
o ATIS

GB917 SLA Handbook Release 3-0 v0-9

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GB917 SLA Handbook Release 3-0 v0-9

Uploaded by

Copyright:

Available Formats

TM Forum 2011

You might also like