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


GB917, Version 0.9 © TM Forum 2011 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 – 10th Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110 TM Forum Web Page: www.tmforum.org

http://www.tmforum.org/Bylaws/1094/home.html�

http://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.2.2. Definition of Terms ................................................................................................................ 16

2.3. Service Level Agreement ............................................................................................................. 18 2.3.1. Informal Model ...................................................................................................................... 18 2.3.2. Definition of Terms ................................................................................................................ 18

2.4. Measurements .............................................................................................................................. 22 2.4.1. Informal Model ...................................................................................................................... 22 2.4.2. Definition of Terms ................................................................................................................ 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 Customer’s needs as represented by its ‘service requirements’ and the SP’s 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 SpecSLA Mgt

SLA Mgt SLA Mgt



SLA SpecSLA 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 today’s 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.

SPRole

CustomerRole

SPRole

SPRole

SPRole

CustomerRole

SPRole

CustomerRole

SPRole

CustomerRole

SPRole

CustomerRole

SLASLA

SLA

SLA

SLA

SLA

SLA

IntegratorRole

A1

A2

Ak

...

A3

A4SLA

Ax

Ay

CustomerRole

CustomerRole

CG1

sharedSLA

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 Thresholds1

.

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 telecommunication2

(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.




SPRole

CustomerRole

Product Offer(Marketing)

Product Instance

Customer-FacingService

Interface

Resource-FacingService

ServiceAccessPoint

PhysicalResource

PhysicalResource

Resource-FacingService

LogicalResource

Service1 Service2

SLA

Figure 9. Service overview

2.2.2. Definition of Terms 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 A1A1A1A2

Business Agreement

SLA

SLS

SPCustomer

optionalinternal agreement

OLA(Internal SLA)

SLS

Dept B(SP)

Dept A(Customer)

Implicit SLA

SLS

SPCustomer

Related concepts, butdifferent contexts

ThrKQI

KPI KPIThrKQI

KPI KPIThrKQI

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)

2.3.2. Definition of Terms 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 : [(P1≥P1_A+) and (P2≥P2_C)] or [(P1≥P1_C) and (P2≥P2_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


MeasurementDefinition

SO

SLS

KPI

Measurements

MeasurementPoint

SLA

SLSThreshold

Estimator

SLM(T)

contains

related to

SLS Param(KQI)

Estimator

Figure 11. Measurement concepts used for SLAs

2.4.2. Definition of Terms 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

performancemeasurement

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)

SLA1SLS Thresholds

SLA2SLS 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 perceptionof Applicationsand CFSes

Human perceptionof global service(delivery and wrap)

example:•Ethernet frameloss rate

example:•TV channelchange delay

example:•number of visibleon-screen artifactsper minute

examples:•satisfaction withTV/voice/internetbundled subscription

•experience with customer care•customer satisfaction score•brand image

MeasurableCan be estimated

Resource-Facing ServiceKPIs

Customer-Facing ServiceKPIs/KQIs

Customer/UserExperience

KQIs

IncreasingRelevance

(SP andCustomer)

IncreasingMeasurement Easefor the SP

(subjectiveperception)

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 SP’s 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.

InitialSpecification

Activation /ExecutionModification

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

candidateSLA items

SLS (Parameters,Thresholds, Expressions)

SLA ViolationProcedures

Measurement Points,Estimators

SLAs orRequirements

Libraryof metrics

(Input)

Relevant

Complete

Step 5Finalize

Step 3Feasibility

Step 2Completeness

Step 1Transform input intoSLA candidate items

(reference)

(reference)

MetricTemplate

NewMetric

(review untilcompleteand feasible)

Feasible


(add/remove/modify)


(add/remove/modify)

Step 4Document 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 library4

• .

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

Overviewo 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

PaymentCRM/Billing

Support NeedCRM/Assurance

AgreementCRM/Fulfillment

IntegrityReliabilityRestorabilityAvailabilityCustomerSP

Service wrap

In service

PaymentCRM/Billing

Support NeedCRM/Assurance

AgreementCRM/Fulfillment

IntegrityReliabilityRestorabilityAvailabilityCustomerSP

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•



Overviewo 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•



Overviewo 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 Customer’s 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•


• : 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:

SLASpecification

Step 4Document

and Review

Step 2Completeness

Step 3Feasibility

Step 1Initial Draft

Step 5Finalize

Step 4Document

and Review

Step 2Completeness

Step 3Feasibility

Step 1Initial Draft

Step 5Finalize

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



3.2.7. Three SLA Specification Cases


SP SO

SP libraryof metrics

candidateSLA items

Product Offering




Review

ProposedSLAs

CompletenessFeasibility

SQMSLO

Std libraryof metrics

MetricTemplate

NewMetric

SLAMSupport

SQMNOC

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.



Cust SO

Cust libraryof metrics

candidateSLA items

High-LevelRequirements




Review

DetailedRequirements

Completeness

MetricTemplate

NewMetric

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 libraryof metrics

candidateSLA items

Product Offering




Review

ProposedSLAs

CompletenessFeasibility

SQMSLO


MetricTemplate

NewMetric

SLAMSupport

Cust SO

Cust libraryof metrics

candidateSLA items

High-LevelRequirements




Review

DetailedRequirements

Completeness

MetricTemplate

NewMetric

SQMNOC

CRM


Cust-SPNegotiation

CustomizedSLAs

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.

Cust1Integrator

CustomerRole

SPRole

CustomerRole

SP1

SPRole

SP2

SPRole

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-LQON (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-LQON) 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 aboutbad audio quality;

ROI for recent network upgrade

SLS :measure audio quality

in calls ofall customers,

on a weekly basis;set ambitious SLO

KQI component C1:call MOS-LQN

for one Customer

Measurements

MeasurementPoint : SAP or UNI

SLA withEnterpriseCustomers

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 timesbased on 50 nanosecond-accurate

timestamps

Estimator : MOS-LQN estimator for 10 seconds,using KPI-1, other IP impairments,

or signals analysis

KQI-1 :% VoIP Customers with

good audio qualityover a week

Measurements

Estimator : count all

KPI-2 (MOS-LQN) > 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 SP1’s network, and is made accessible to C1’s 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 SP1’s product offer in the VPN area, using VPLS technology VPLS-instance1: CFS

•

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

• , used in SP1’s network, to support CFSes such as VPLS-instance1.

LSP1,..,LSP10 : logical resources

•

, used in SP1’s 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 C1’s Layer2 Ethernet devices. SP1’s SAPs will perform encapsulation, multiplexing/demultiplexing and policing operations to C1’s traffic, and will interact with other layers (like IP/MPLS) in SP1’s 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 C1’s Ethernet ports, and the other services from other layers locally accessed by the SAPs include the IP/MPLS Resource-Facing Services.

SP1(ServiceProvider)

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 SP1’s organization. If SP1’s

MPLS interacts with MPLS networks of other service providers, then SP1’s 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(ServiceProvider)

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

KPIKPI 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 To be completed in R3.1.

Refer to GB938 [11].



Appendix E – Use Case 2: Emergency Telecom Services SLA To be completed in R3.1.

Refer to ATIS ETS [15].



Appendix F – Use Case 3: Business VPN SLA To be completed in R3.1.

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 Forum’s 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 June 18th: “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 John Timms, Telchemy

o Laurent Philippart, Alcatel-Lucent

o Quan Huynh-Thu, Psytechnics

o Ron Roman, Telcordia

o Dave Milham, TM Forum

o Tina O’Sullivan, 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

Documents