PDF 00009

SLA Management Handbook
GB 917
Public Evaluation/Version 1.5
June 2001
Page ii
GB 917 v1.5
TeleManagement Forum 2001
Page iii
Notice
The TeleManagement Forum (TM Forum) has made
every effort to ensure that the contents of this
document are accurate. However, no liability is
accepted for any errors or omissions or for
consequences of any use made of this document.
This document is a draft working document of TM
Forum and is provided to the public solely for
comments and evaluation. It is not a Forum Approved
Document and is solely circulated for the purposes of
assisting TM Forum in the preparation of a final
document in furtherance of the aims and mission of
TM Forum. Any use of this document by the recipient
is at its own risk. Under no circumstances will TM
Forum be liable for direct or indirect damages or any
costs or losses resulting from the use of this document
by the recipient.
This document is a copyrighted document of TM
Forum. Without the appropriate permission of the TM
Forum, companies that are not members of TM
Forum are not permitted to make copies (paper or
electronic) of this draft document other than for their
internal use for the sole purpose of making comments
thereon directly to TM Forum.
This document may involve a claim of patent rights by
one or more TM Forum members, pursuant to the
agreement on Intellectual Property Rights between
TM Forum and its members, and by non-members of
TM Forum.
Direct inquiries to the TM Forum office:
1201 Mt. Kemble Avenue
Morristown, NJ 07960 USA
Tel No. +1 973 425 1900
Fax No. +1 973 425 1515
TM Forum Web Page www.tmforum.org
GB 917 v1.5
Page iv
GB 917 v1.5
Page v
Acknowledgements
TeleManagement Forum would like to thank the following individuals for contributing
their time and expertise to the production of the SLA Management Handbook:
Sandro Borioni, Sodalia SpA
Stephen Cross, Nortel Networks
Bill DeYoung, Verizon (Team Sponsor)
Jane Hall, GMD FOKUS (Handbook Editor)
Peter Huckett, ACTERNA (Team Editor)
Peter Jasion, Tivoli
Veli Kokkonen, Sonera
Ranveer (Ran) Rathore, NASA
Lightsey Wallace, Lightsey Enterprises (Team Leader)
Alessandro Zorer, Sodalia SpA
A number of people have provided input and comments to the work of the team.
Although not an exhaustive list, many thanks to the following individuals for their
contributions:
Jock Embry, Opening Technologies
John Gormont, Spirent Communications
Hkan Kappelin, Ericsson
Mahmood Karbasi, Oracle
Han-Young Lee, Korea Telecom
Hans Pettersson, EHPT
Paul Short, TeleManagement Forum
GB 917 v1.5
Page vi
GB 917 v1.5
Page vii
About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service
providers and their suppliers. Its mission is to help service providers and network
operators automate their business processes in a cost- and time-effective way.
Specifically, the work of the TM Forum includes:
Establishing operational guidance on the shape of business
processes.
Agreeing on information that needs to flow from one process activity
to another.
Identifying a realistic systems environment
interconnection of operational support systems.
to
support
the
Enabling the development of a market and real products for

integrating and automating telecom operations processes.
The members of TM Forum include service providers, network operators and
suppliers of equipment and software to the communications industry. With that
combination of buyers and suppliers of operational support systems, TM Forum is
able to achieve results in a pragmatic way that leads to product offerings (from
member companies) as well as paper specifications.
GB 917 v1.5
Page viii
GB 917 v1.5
Page ix
About this document

This is a TM Forum Guidebook. The guidebook format is used when:
The document lays out a core part of TM Forums approach to
automating business processes. Such guidebooks would include the
Telecom Operations Map and the Technology Integration Map, but
not the detailed specifications that are developed in support of the
approach.
Information about TM Forum policy, or goals or programs is provided,
such as the Strategic Plan or Operating Plan.
Information about the marketplace is provided, as in the report on the
size of the OSS market.
Document Life Cycle

This is version 1.5 of the SLA Management Handbook. Version 1.5 supersedes all
previous versions in their entirety.
Document History
Version
Date
Version 0.1
August 7, 1999
Purpose
Version 0.2
December 12, 1999
Version 0.3
May 18, 2000
Provided for discussion at the Nice meeting
Version 0.4
May 29, 2000
Updated at the Nice meeting
Version 0.5
July 4, 2000
To provide the outline for the first draft version

Updated at the Las Vegas meeting
Release for Member Evaluation
Version 0.6
August 8, 2000
Version 0.7
November 2, 2000
Updated at the Washington meeting

Provided for promotion at TMW Chicago
Version 0.8
November 16, 2000
Updated at the Chicago meeting
Version 1.0
November 2000
Evaluation version for members only
Version 1.1
June 2001
Updated after the Paris and Nice meetings
Version 1.5
June 2001
Public Evaluation Version
GB 917 v1.5
Page x
Time Stamp
This version of the SLA Management Handbook can be considered valid until 31
December 2002 or such time as a further revision is issued.
How to obtain a copy

This document version is available from the TMF Central Web Site.
How to comment on this document

Readers are encouraged to provide comments to the SLA Management Team via
email.
Suggestions for comments:
1. In order to reduce file size, comments should excerpt only relevant paragraphs,
including identifying paragraph headers.
2. Be specific. Consider that you might be on a team trying to produce a single text
through the process of evaluating numerous comments. We appreciate significant
specific input. We are looking for more input than a word-smith, however
structural help is greatly appreciated where clarity benefits.
3. What to look for: errors, omissions, lack of clarity and missing references to other
accomplished work (please cite exact applicable section(s) of other documents).
4. Questions are welcome that provide direction for the team to further develop or
expand a specific area. However, the reader should be aware that this work is
intended to be a handbook not an exhaustive thesis, and that we do not intend to
duplicate other work.
5. Email all comments to the document editor, Jane Hall, hall@fokus.gmd.de with a
copy to the team leader, Lightsey Wallace, lwallace@mnsinc.com.
GB 917 v1.5
Page xi
Executive Summary
The objective of the Handbook is to assist two parties in developing a SLA (Service Level
Agreement) with a practical view of the fundamental issues. The two parties may be an end
Customer and their Service Provider (SP) or two Service Providers, where one Service
Provider has the Customer role buying support services from another Service Provider (e.g. who
may be acting as a network operator). These are described as the Customer-SP interface and
the SP-SP interface.
The perspective of the Handbook is that the end Customer develops telecommunication
service quality requirements necessary to operate their business. These requirements are
brought to the Service Provider and the two parties begin to assemble the optimum set of SLA
parameters and values for the services. The agreed-upon SLA requirements flow down through
the organizations of the associated SP(s) and become the basis for internal management
processes and QoS values. Customer satisfaction is improved by identifying the implications for
supporting the service by the internal support infrastructure(s) of both the SP and the Customer.
Two tools provide the foundation for clarifying management roles, processes, responsibilities and
expectations: 1) the Life Cycle of the Service and 2) the SLA Parameter Framework.
To clarify the roles of the Customer and the SP, a Service and its SLA is divided into five Life
Cycle stages: product/service development, negotiation and sales, implementation, execution,
assessment. Each life cycle stage addresses specific operations processes in the Telecom
Operations Map (TOM) [GB 910]. The SLA Life Cycle provides a complete process description
by delineating interactions between well-defined stages.
The SLA Parameter Framework provides a matrix for organizing parameters into six categories.
The three parameter categories are 1) technology-specific, 2) service-specific and 3)
technology/service-independent. The Customer has two interests: 1) impact on the single user
and 2) aggregate performance for a defined period. Examples of SLA parameters are included
for a variety of technologies and services.
Annex A addresses unique performance requirements of ebusiness (ecommerce) whose survival
may be threatened by even short lapses in telecommunication service(s). It is recognized that in
such cases, the business itself must examine all of its processes: both internal and those
outsourced or out-tasked. The telecommunication service represents only a portion of the
processes. Emphasis for an ebusiness typically includes eliminating Common Points of Failure
for all processes.
The SLA Management Handbook is an extension of the work developed in the Performance
Reporting Concepts and Definitions Document [TMF 701] and in the Service Provider to
Customer Performance Reporting Business Agreement [NMF 503]. The reader of the Handbook
will find that these documents offer a valuable introduction to SLA Management.
GB 917 v1.5
Page xii
GB 917 v1.5
Page xiii
Table of Contents
Notice .................................................................................................................................................................iii
Acknowledgements ..........................................................................................................................................v
About TeleManagement Forum ....................................................................................................................vii
About this document .......................................................................................................................................ix
Document Life Cycle ................................................................................................................................. ix
Document History...................................................................................................................................... ix
Time Stamp ................................................................................................................................................x
How to obtain a copy..................................................................................................................................x
How to comment on this document...........................................................................................................x
Executive Summary.........................................................................................................................................xi
Table of Contents ...........................................................................................................................................xiii
Table of Figures.............................................................................................................................................xvii
Chapter 1 Introduction ..................................................................................................................................1
1.1 Scope ...............................................................................................................................................2
1.2 Assumptions.....................................................................................................................................3
1.3 Intended Audience and Benefits.....................................................................................................3
1.3.1 Service Providers ....................................................................................................................3
1.3.2 Customers ...............................................................................................................................4
1.3.3 Equipment and Software Vendors .........................................................................................4
1.4 Document Outline ............................................................................................................................4
1.5 Using the Handbook ........................................................................................................................6
Chapter 2 Terms and Definitions.................................................................................................................7
Chapter 3 Motivation and Requirements for SLA Management...........................................................15
3.1 Introduction.....................................................................................................................................15
3.2 Business Model..............................................................................................................................16
3.3 Business Benefits ..........................................................................................................................17
3.3.1 Customer Benefits.................................................................................................................17
3.3.2 Service Provider Benefits......................................................................................................18
3.3.3 Vendor Benefits.....................................................................................................................19
3.4 Performance Reporting .................................................................................................................19
3.5 Requirements.................................................................................................................................21
3.5.1 Fulfillment...............................................................................................................................21
3.5.2 Assurance..............................................................................................................................22
3.5.3 Customer Interface Management.........................................................................................23
3.6 Examples........................................................................................................................................24
3.6.1 Leased Line Service..............................................................................................................24
3.6.2 Frame Relay Service ............................................................................................................25
3.6.3 ATM Cell Delivery Service ....................................................................................................26
3.6.4 IP-VPN Service .....................................................................................................................26
3.6.5 IP Service with DSL Access .................................................................................................27
3.6.6 Customer Care Help Desk Service ......................................................................................29
GB 917 v1.5
Page xiv
Chapter 4 QoS and the SLA Parameter Framework.............................................................................. 31

4.1 Parameter Classification............................................................................................................... 31
4.1.1 General Concepts................................................................................................................. 31
4.1.2 Performance Events and Performance Parameters .......................................................... 33
4.1.3 Network Performance and QoS .......................................................................................... 33
4.1.4 NP/QoS Requirements and QoS Classes .......................................................................... 34
4.1.5 NP, QoS and Grade of Service (GoS), and the Role of Traffic Engineering..................... 35
4.1.6 Network Bearer Services and Application Services ........................................................... 36
4.1.7 Parameter Dependence and Independence ...................................................................... 36
4.1.8 Service/Technology-independent Parameters ................................................................... 37
4.1.9 Technology-specific Parameters ......................................................................................... 38
4.1.10 Service-specific Parameters ................................................................................................ 39
4.2 Parameter Degradation ................................................................................................................ 41
4.2.1 Management of QoS and NP Parameters.......................................................................... 41
4.2.2 Role of In-Service Monitoring............................................................................................... 41
4.2.3 Degradation and Customer Trouble Reports...................................................................... 42
4.3 Performance Measures versus User Perception ........................................................................ 43
4.3.1 Measurement and Reporting Intervals ................................................................................ 43
4.3.2 Reporting Methods ............................................................................................................... 44
4.3.3 User Perception.................................................................................................................... 45
4.3.4 Aggregation of Parameters and QoS Index........................................................................ 46
4.3.5 Customer Satisfaction .......................................................................................................... 46
4.4 Violations and Remedies.............................................................................................................. 47
Chapter 5 SLA Life Cycle ........................................................................................................................... 49
5.1 Life Cycle Automation................................................................................................................... 49
5.1.1 Product/Service Development ............................................................................................. 50
5.1.2 Negotiation and Sales .......................................................................................................... 50
5.1.3 Implementation ..................................................................................................................... 51
5.1.4 Execution .............................................................................................................................. 51
5.1.5 Assessment .......................................................................................................................... 51
5.2 Use Cases and Scenarios............................................................................................................ 52
5.2.1 Product/Service Development with a New SLA.................................................................. 53
5.2.3 Implementation ..................................................................................................................... 56
5.2.4 Normal Execution ................................................................................................................. 57
5.2.5 Execution with SLA Violation ............................................................................................... 59
5.2.6 Assessment .......................................................................................................................... 60
Chapter 6 SLA Management Framework................................................................................................. 63
6.1 SLA Management Functions........................................................................................................ 63
6.1.1 Product/Service Development ............................................................................................. 63
6.1.3 Implementation ..................................................................................................................... 64
6.1.4 Execution and Assessment ................................................................................................. 64
6.2 SLA / QoS Data Management ..................................................................................................... 65
Chapter 7 SLA Modeling and Guidelines ................................................................................................ 67
7.1 Introduction.................................................................................................................................... 67
7.2 Role of SLAs within Service Products.......................................................................................... 67
7.2.1 Defining the Level of Service ............................................................................................... 70
7.2.2 Multiple Domain SLAs.......................................................................................................... 71
7.2.3 SLA to Service Mapping....................................................................................................... 72
7.3 Service Element Categories......................................................................................................... 73
7.4 SLA Mapping of QoS Parameters ............................................................................................... 74
7.4.1 Leased Line Service............................................................................................................. 74
7.4.2 Frame Relay Service............................................................................................................ 75
GB 917 v1.5
7.4.3
7.4.4
7.4.5
7.4.6
Page xv
ATM Cell Delivery Service ....................................................................................................76

IP-VPN Service .....................................................................................................................77
IP Service with DSL Access .................................................................................................78
Customer Care Help Desk Service ......................................................................................79
References........................................................................................................................................................81
Acronyms .........................................................................................................................................................83
Appendix I: Related Activities .......................................................................................................................89
I.1
3GPP..............................................................................................................................................89
I.2
Committee T1 ................................................................................................................................90
I.3
ETSI................................................................................................................................................91
I.4
EURESCOM ..................................................................................................................................92
I.4.1
Project P806 ..........................................................................................................................92
I.4.2
Project P906 ..........................................................................................................................92
I.4.3
Project P1008........................................................................................................................93
I.4.4
Other Projects of Relevance.................................................................................................93
I.5
IETF ................................................................................................................................................94
I.5.1
Differentiated Services Working Group................................................................................95
I.5.2
Integrated Services Working Group.....................................................................................96
I.5.3
IP Performance Metrics Working Group..............................................................................96
I.5.4
Internet Traffic Engineering Working Group ........................................................................97
I.5.5
Multiprotocol Label Switching Working Group.....................................................................97
I.5.6
Policy Framework Working Group .......................................................................................97
I.5.7
Resource Allocation Protocol Working Group .....................................................................98
I.6
IST Projects....................................................................................................................................98
I.6.1
AQUILA..................................................................................................................................98
I.6.2
CADENUS.............................................................................................................................99
I.6.3
FORM ....................................................................................................................................99
I.6.4
M3I .........................................................................................................................................99
I.6.5
TEQUILA ...............................................................................................................................99
I.7
ITU-T............................................................................................................................................ 100
I.7.1
ITU-T Study Group 2 Operational Aspects of Service Provision, Networks and
Performance ..................................................................................................................................... 101
I.7.2
ITU-T Study Group 4 Telecommunication Management, including TMN.................... 102
I.7.3
ITU-T Study Group 7 Data Networks and Open System Communications ................ 102
I.7.4
ITU-T Study Group 9 Integrated Broadband Cable Networks and Television and Sound
Transmission..................................................................................................................................... 103
I.7.5
ITU-T Study Group 11 Signalling Requirements and Protocols................................... 104
I.7.6
ITU-T Study Group 12 End-to-end Transmission Performance of Networks and
Terminals .......................................................................................................................................... 104
I.7.7
ITU-T Study Group 13 Multi-protocol and IP-based Networks and Their Internetworking
............................................................................................................................................. 104
I.7.8
ITU-T Study Group 15 Optical and Other Transport Networks .................................... 106
I.7.9
ITU-T Study Group 16 Services, Systems and Terminals............................................ 106
I.8
Quality of Service Development Group ..................................................................................... 107
I.9
Others.......................................................................................................................................... 108
Annex A: eBusiness SLA Management ................................................................................................... 113
A.1 Introduction.................................................................................................................................. 113
A.1.1 Background ........................................................................................................................ 113
A.1.2 Definition ............................................................................................................................. 114
A.1.3 SLA Groups ........................................................................................................................ 114
A.1.4 Scope.................................................................................................................................. 116
A.2 Business Drivers for SLA/QoS................................................................................................... 116
A.2.1 Interdependence ................................................................................................................ 116
A.2.2 Economic Considerations.................................................................................................. 117
GB 917 v1.5
Page xvi
A.3 Technical Considerations ........................................................................................................... 118

A.3.1 Common Point of Failure ................................................................................................... 118
A.3.2 Process Automation ........................................................................................................... 118
A.3.3 Security ............................................................................................................................... 119
A.3.4 Checklist and Guidelines.................................................................................................... 120
Annex B: Guidelines for Catalyst Project Input to the Handbook........................................................ 121
B.1 Introduction.................................................................................................................................. 121
B.2 Parameter Framework................................................................................................................ 121
B.3 Examples..................................................................................................................................... 122
B.3.1 IP Service with DSL Access............................................................................................... 122
B.3.2 ATM Cell Delivery............................................................................................................... 123
GB 917 v1.5
Page xvii
Table of Figures
Figure 1.1: Service Delivery Relationships............................................................................................1
Figure 3.1: The Business Reference Model........................................................................................16
Figure 3.2: SLA at the Customer-Service Provider Interface .............................................................17
Figure 3.3: Interaction of Performance Reporting with other Service Functions and Scope of
the Performance Reporting Interface Definition...........................................................................20
Figure 3.4: IP-VPN Service Concept ...................................................................................................27
Figure 3.5: Example of a Composite Service......................................................................................28
Figure 4.1: Quality of Service and Network Performance Concepts .................................................32
Figure 4.2: Distinction between QoS and NP......................................................................................33
Figure 4.3: Framework for Parameter Categories ..............................................................................36
Figure 4.4: IP Service with DSL Access ..............................................................................................37
Figure 4.5: ATM Cell Delivery Service.................................................................................................37
Figure 4.6: Availability Performance Measures...................................................................................40
Figure 4.7: Performance Levels...........................................................................................................42
Figure 4.8: Time Line for Reporting Network and Service Incidents..................................................44
Figure 5.1: Service and Associated SLA Life Cycle............................................................................49
Figure 5.2: Creation Portion of Service Development ........................................................................53
Figure 5.3: Internal Notice Portion of Service Development Phase...................................................55
Figure 5.4: The Negotiation and Sales Phase of SLA Management.................................................56
Figure 5.5: Implementation Flow of SLA Instantiation ........................................................................57
Figure 5.6: Normal Execution of SLA Service.....................................................................................58
Figure 5.7: Customer Detected SLA Violation ....................................................................................59
Figure 5.8 Assessment Initiation Flows ...............................................................................................61
Figure 6.1: Potential SLA Management Functions .............................................................................63
Figure 6.2: SLA Performance Data Collection ....................................................................................65
Figure 6.3: SLA/QoS Related Data......................................................................................................66
Figure 7.1: Service Composition..........................................................................................................68
Figure 7.2: Relationship between the SLA and Service Instances ....................................................69
Figure 7.3: Service Composition Example ..........................................................................................69
Figure 7.4: Components of a SLA Template.......................................................................................70
Figure 7.5: End-to-end Service Delivery across Multiple Service Domains ......................................71
GB 917 v1.5
Page xviii
Figure 7.6: Multiple Domain SLA Relationships Example 1 .............................................................. 72

Figure 7.7: Multiple Domain SLA Relationships Example 2 .............................................................. 72
Figure 7.8: SLA and Service Access Point Relationships ................................................................. 73
Figure 7.9: Service Element Categories ............................................................................................. 74
Figure 7.10: Leased Line Service Parameter Framework Example ................................................. 75
Figure 7.11: Frame Relay Service Parameter Framework Example ................................................ 76
Figure 7.12: ATM Cell Delivery Service Parameter Framework Example........................................ 77
Figure 7.13: IP-VPN Service Parameter Framework Example ......................................................... 78
Figure 7.14: IP Service with DSL Access Service Parameter Framework Example ....................... 79
Figure 7.15: Customer Care Help Desk Service Parameter Framework Example.......................... 80
Figure A.1: Classification of eBusiness Service Providers .............................................................. 115
Figure A.2: Availability for Services with Varying Redundancy (over 24 hours)............................. 117
Figure B.1: Framework for Parameter Categories ........................................................................... 122
Figure B.2: IP Service with DSL Access Parameter Framework Example..................................... 123
Figure B.3: ATM Cell Delivery Service Parameter Framework Example ....................................... 123
GB 917 v1.5
Page 1
Chapter 1 Introduction
A Service Level Agreement (SLA) is a formal negotiated agreement between two
parties. It is a contract that exists between the Service Provider (SP) and the
Customer. It is designed to create a common understanding about service quality,
priorities, responsibilities, etc. SLAs can cover many aspects of the relationship
between the Customer and the SP, such as performance of services, customer care,
billing, service provisioning, etc. [TMF 701]. However, although a SLA can cover such
aspects, agreement on the level of service is the primary purpose of a SLA. The
focus of this Handbook is therefore on the management of the SLA and the Quality of
Service (QoS) that is agreed in the SLA.
In the above definition, reference is made to a SP and a Customer. The SP is the
party providing a service and the Customer is the party ordering and receiving the
service. Both SP and Customer may be in a value chain of service provision (as
shown in Figure 1.1). This can mean that the Customer in one SLA may be the SP in
another SLA in the chain, and the SP in one SLA may be the Customer in another
SLA in the chain. However, for the purposes of any one SLA there will be a Customer
and a SP and so these general roles have been used in this document.
Customer
Internal
Provider
Service
Provider
Provider
Service
Provider
Service
Provider
Service
Provider
Provider
........
End
Customer
Customer
Customer
End Users
Provider
Service
Provider
Customer
Figure 1.1: Service Delivery Relationships
GB 917 v1.5
Page 2
1.1
Scope
The scope of the Handbook is to provide a tool to be used by both the Customer and
the SP in developing the SLA content and structure applicable to specific services.
Assignment of specific values to any parameter is part of a specific contract
negotiation and is beyond the scope of the Handbook. The term Customer refers to
the business that consumes a service; the Customer may also be another SP. An
end user is considered to be an individual within the Customer organization1.
This version of the Handbook focuses on a horizontal slice of the Telecom
Operations Map (TOM) through the Customer Care Processes tier encompassing all
those aspects related to SLA management [GB 910]. This includes negotiating the
SLA during the Sales process, setting the SLA parameters during the Order Handling
process, relating Customer trouble reports to the SLA during the Problem Handling
process and providing rebates and/or other penalties due to SLA violations as part of
the Invoicing & Collections and/or Customer QoS Management process. Although
some aspects of the TOM lower layer processes are considered, future versions of
the Handbook will address these in more depth.
The Handbook focuses on SLA Management from the perspective of the Customer
to SP interface including QoS issues. It will not prescribe QoS management from a
network or service implementation perspective.
QoS is a broad concept covering many performance aspects and numerous
measures. It may be defined as the collective effect of service performances that
determine the degree of satisfaction of a user of the service (see ITU-T
Recommendation [E.800]).
Several driving forces place a new emphasis on specifying QoS in a SLA. These
include the opening up of the telecom market to competitive service provision, the
explosion in ebusiness that requires very high QoS from network and associated
services, such as servers, databases, etc., and the development and deployment of
services based on network technologies such as ATM and IP. These cell/packetbased technologies raise new QoS issues over traditional circuit-based services in
terms of monitoring and collection of performance data, and interpreting that data into
QoS performance reports.
Agreement on terms and definitions for QoS parameters, and their measurement and
reporting, is key to constructing and managing SLAs between Customers and SPs.
Apart from functionality and price, service quality is an increasingly important factor
for Customers in the competitive telecommunication market. Some would say that
QoS is now the number one purchasing factor in selecting telecom services,
particularly for business Customers.
The Handbook provides assistance in organizing the often unwieldy topic of SLA
management through two tools: 1) the five-stage service Life Cycle and 2) the SLA
Parameter Framework.
GB 917 v1.5
The main focus of this Handbook is on business Customers.
Page 3
Development of a SLA must consider the complete life cycle of a service. Five stages
are identified: product/service development, negotiation and sales, implementation,
execution, and assessment. When the Customer-Provider interactions address each
of these stages in turn, the resultant expectations will be better aligned and the
relationship enhanced.
Many performance parameters exist that have similar names yet have drastically
different definitions. The SLA Parameter Framework is a useful tool for categorizing
individual parameters. This framework organizes SLA parameters into six categories
based upon whether they are technology-specific, service-specific or technology and
service-independent, and whether they affect the individual user or are aggregated
over a defined period.
1.2
Assumptions
This Handbook addresses SLA parameters that support a contract between two
parties. There are numerous business parameters contained in a contract that are not
covered by this Handbook. For example, while the rebate process is described in
terms of the parameters that may drive it, parameters for payment and terms are not
included.
Underlying systems and processes tend to be proprietary and will not be covered.
The Customer and SP(s) often choose to be free to develop their own internal
processes for market competitiveness. Therefore, the Handbook provides the
information to both parties that is necessary to develop and manage their internal
systems in a more efficient manner.
A SLA between a Customer and a SP can refer to one or more services that the
Customer is ordering from the SP. It is not necessarily restricted to one service offer
or even one type of service.
1.3
Intended Audience and Benefits
1.3.1 Service Providers

This Handbook will assist SPs in developing new services with associated SLA
parameters, align SLA parameters to meet Customer requirements and internal
processes, assign internal processes according to SLAs, and respond to SLA
requirements from other SPs.
The Handbook helps a SP introduce operational changes, improve internal
measurements and reporting, enrich Customer relations and differentiate itself from
its competitors.
GB 917 v1.5
Page 4
Service Provider is a general term including Network Operator (NO), Internet Service
Provider (ISP), Application Service Provider (ASP), etc.
1.3.2 Customers
This Handbook will assist Customers to negotiate a SLA contract that satisfies their
application requirements and to better understand the possibilities, limitations and
expectations related to performance and cost of a service. The SLA parameter
framework documents the needs of individual users.
The Handbook provides the technical framework within which projects on Customer
Service including SLA/QoS Management can function. The SLA technical framework
provides benefits to a SPs Customers as a means to develop a working
understanding of practical SLA parameters.
1.3.3 Equipment and Software Vendors

The Handbook helps Vendors, SPs and Customers create uniform cost-effective SLA
Management solutions. Such solutions consist of products and services needed to
satisfy requirements. Vendors of equipment and software solutions for Customers
and SPs will be assisted by the Handbook through the examples of services to be
managed and the performance parameters to be measured, reported and processed.
1.4
Document Outline
Chapter 2
Terms and Definitions
This chapter contains definitions of terms used in this document. Where possible,
they have been aligned with those from other related telecommunication bodies.
Chapter 3
Motivation and Requirements for SLA Management
Business drivers for SLA management are identified and business benefits for both
Customers and SPs described. Work presented in the Performance Reporting Team
documents is introduced. Requirements are summarized in terms related to
fulfillment, assurance and customer care, and build on the work in [NMF 503]. (Note:
Annex A addresses requirements related to ebusiness.) Example services are
introduced that are used for illustrative purposes in subsequent chapters.
Chapter 4
QoS and the SLA Parameter Framework
Agreement on terms and definitions for QoS parameters, and their measurement and
reporting, is key to constructing and managing SLAs between Customers and SPs.
Apart from functionality and price, service quality is an increasingly important factor
for Customers in the competitive telecommunication market. This section describes
SLA and QoS parameters, their classification and use.
GB 917 v1.5
Page 5
Many SLA parameters exist and a framework has been developed to arrange SLA
parameters into six categories. These six categories provide clarity in developing the
SLA specification and reduce possible misunderstandings and unrealistic
expectations. Some services may contain both technology-specific and servicespecific parameters, some may contain only one or the other. Many services contain
technology and service-independent parameters. A variety of examples is included to
illustrate the value of this framework.
The relationship between QoS and SLA is developed together with considerations
such as where SLA thresholds are captured, applied and managed.
A commonly overlooked aspect of SLA parameters is the relationship between the
aggregated requirements for quality and the impact on a single user instance of the
service. The framework addresses this issue. Certain SLA parameters may be of
more interest to the SP than the Customer and vice versa. This framework provides
an organized approach to jointly defining pertinent SLA parameters and ultimately
their values.
The parameter framework provides guidance for six categories of parameters while
specifically addressing the parameters related to an individual user. Other
considerations are included, such as degradation, measures and user perception,
violations and remedies. This chapter has additional value for its references to the
work of other external (e.g. standards) groups.
Chapter 5
SLA Life Cycle
Chapter 5 provides a tool for developing and administering SLAs during the entire life
cycle of the service and its associated SLA. When developing a SLA, consideration
must be given to the life cycle as it may affect SLA requirements. For example,
different combinations of processes are required to support the five phases of the
SLA life cycle. Different SLA parameters and values may apply during product/service
development, negotiation and sales, implementation, execution, and assessment.
The relevant use cases supporting SLA management are described and related to
the TOM processes.
Chapter 6
SLA Management Framework
This chapter discusses how process automation can support aspects of the SLA life
cycle and introduces functions that are related to SLA management. The data that is
required for SLA/QoS management is considered.
Chapter 7
SLA Modeling and Guidelines
A conceptual model is introduced that is useful for identifying the components from
which a SLA is constructed and the role of such components within a SPs service
offering to Customers. The SP service offering is decomposed into elementary
building blocks (elementary services and service access points) and the relationships
between them are described and illustrated by examples. Finally, a mapping scheme
between components comprising SLAs and the SLA Parameter Framework is
provided using the examples from Chapter 3.
GB 917 v1.5
Page 6
Appendix 1
Appendix 1 provides an overview of work being undertaken on SLA and QoS issues
by various standards bodies and other organizations.
Annexes
Aspects of SLA Management related to businesses where short-term loss of services
could impact the survival of the company are addressed in Annex A. This annex is an
extension of the Handbook, since these cases are not considered as a stand-alone
issue and must be closely correlated with standard management methods.
TM Forum Catalyst projects demonstrating SLA applicable measures and processes
are to be summarized in Annex B. These demonstrations will be fully reported
individually and the relevant SLA measures and processes will be highlighted in the
annex in a later version of this Handbook.
1.5
Using the Handbook

QoS is used by a SP to measure performance both technically and in terms of
Customer satisfaction. Determining the QoS provides a discriminator between
various types of service that a supplier provides, and leads to opportunities to balance
the level of service quality offered against price and Customer expectation. The use
of QoS agreements in SLAs provides SPs with the opportunity to delight their
Customers, build stronger long-term relationships and brand image, and
maintain/grow market share. The growing complexity of global services brings
together a myriad of services, suppliers and technologies, all with potentially different
QoS requirements. SPs are trying to integrate these services into one Next
Generation Network (NGN) that supports these requirements, while striking a delicate
balance between cost and return on investment.
Corporate Customers are seeking SLAs that offer deeper verification and analysis of
the performance they are paying for. In addition to the primary requirement for high
availability, the ability to monitor on an increasingly granular level is imperative for
corporate networkers. For example, they want to know the number of successfully
delivered packets in a given time period, the amount of time a user was connected to
a server, notification of what traffic type is using the most bandwidth, what percentage
of the traffic is going to a specific sub-network or server, etc.
This Handbook is designed to be a reference for SPs as they develop new services
and to assist in Customer discussions. It will inform and educate about the intricacies
of SLAs as well as provide a structure for defining agreements such that relevant SLA
parameters and values can be agreed upon that are achievable and verifiable.
The Handbook is not intended to provide a cookbook of tables to be filled out without
knowledge of the underlying requirements, capabilities or limitations of the technology
or service(s).
GB 917 v1.5
Page 7
Chapter 2 Terms and Definitions

Terms and definition used in this Handbook are mainly based on the TM Forum
Performance Reporting Concepts and Definitions Document [TMF 701] and
internationally agreed definitions published by the ITU. For example, ITU-T
Recommendation M.60 [M.60] contains Maintenance Terminology and Definitions. In
this chapter, only some key terms related to SLAs, QoS and performance are defined
and their source identified. For the purposes of this Handbook, some definitions have
been modified and/or extended. Where multiple definitions are in use within the
industry, all are given. Not all of the terms and definitions in this chapter are
necessarily used in this version of the Handbook but are included as they are
expected to be relevant in later versions2. For further information, please consult TMF
701, ITU-T and other references.
Active (condition) condition (e.g. alarm) not cleared (ITU-T Rec. M.2140).
*Administration (task) a broad group of functions that sustain telecommunication
services once they have been established. Administration generally consists of
network administration and service administration. Network administration ensures
that the network is used efficiently and that Grade of Service (GoS) objectives are
met. Service administration includes such diverse support functions as billing,
collecting and switching service evaluation (ITU-T Rec. M.3010).
Administrative Domain a collection of systems and sub-networks operated by a
single organization or administrative authority. It may be subdivided into a number of
routing domains (ITU-T Rec. X.400).
*Aggregate Interval the time period over which raw data is summarized in a
particular report. For example, raw 15-minute data may be aggregated into one-hour
or 24-hour intervals for reporting purposes (TMF 701 modified).
Alarm an alerting indication of a condition that may have immediate or potential
negative impact on the state of service resources, e.g. network element, application,
system, etc. (ITU-T Rec. M.3010 modified).
*Alarm Surveillance a set of TMN management functions which provide, in near
real-time, detection and indication of failures (ITU-T Rec. M.3010).
*Anomaly a discrepancy between the actual and desired characteristic of an item.
The desired characteristic may be expressed in the form of a specification. An
anomaly may or may not affect the ability of an item to perform a required function
(ITU-T Rec. M.20).
Terms and definitions not yet used are marked with a *.
GB 917 v1.5
Page 8
Availability Performance the ability of an item to be in the 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. Note that this
ability depends on the combined aspects of the reliability performance, the
maintainability performance and the maintenance support performance of an item. In
the definition of the item, the external resources required must be delineated. The
term availability is used as an availability performance measure (ITU-T Rec. M.60).
Bearer Service a type of telecommunication service that provides the capability for
the transmission of signals between user-network interfaces (ITU-T Rec. I.112).
Clear the end of a fault; the termination of a standing condition (ITU-T Rec.
M.2140).
Connection an association of transmission channels, circuits or flows, switching
and other functional units set up to provide a means for a transfer of information
between two or more points in a telecommunication network (ITU-T Rec. Q.9
modified).
*Connection Quality the collective effect of service performance, which
determines the degree of satisfaction of a user with the particular connection (ITU-T
Rec. M.3010).
Customer a Customer is an entity which receives services offered by a Service
Provider based on a contractual relationship. It may include the role of a network user
(ITU-T Rec. M.3010).
The term Customer refers to companies or organizations that make use of
telecommunication services provided by a Service Provider. The Customer is the
ultimate buyer of a network service, but the end user may or may not be the one who
pays for the service (TMF 701 modified).
Customer Contact Point a physical or conceptual point at which a Service
Provider can interact with any Customer of the offered service for the purpose of
maintaining communication services (TMF 701 modified).
Customer Details information about the Customer, sometimes called Customer
profile.
Customer Premises Equipment (CPE) any network equipment sited at the
Customers premises used to provide the contracted service. Note that the CPE may
be owned and operated by the Customer or the Service Provider (extracted from
TMF 701).
Customer SLA Performance Data correlation of the service quality and
performance data against specific Customer service instances to provide specific
performance data against individual service instances and SLAs.
Customer to Service Provider Interface the boundary of information exchange
between the Customer (whether end Customer or another Service Provider/Network
Operator) and their Service Provider (TMF 701 modified).
GB 917 v1.5
Page 9
*Data Collection Interval the period over which performance parameters are
accumulated to compute each stored measurement and detect maintenance
threshold crossings (ITU-T Rec. M.2140).
The time interval when statistics are retrieved from the network. This interval does not
have to be the same as the measurement interval because the network devices may
buffer statistics so that a number of them may be collected later (TMF 701).
Defect a defect is a limited interruption of the ability of an item to perform a required
function. It may or may not lead to a maintenance action depending on the results of
additional analysis (ITU-T Rec. M.20).
Degradation the presence of anomalies or defects in the absence of a fault (ITU-T
Rec. M.2140).
Degraded Service the presence of anomalies or defects that cause a degradation
in QoS, but do not result in total failure of the service.
Event an instantaneous occurrence that changes the global status of an object.
This status change may be persistent or temporary, allowing for surveillance,
monitoring, and performance measurement functionality, etc. Events may or may not
generate reports; they may be spontaneous or planned; they may trigger other events
or may be triggered by one or more other events (ITU-T Rec. X.700).
*Event Correlation Process a process that accepts events as input, performs one
or more event correlation sub-processes, and reports events as output (ITU-T Rec.
M.2140).
*Event Correlation Sub-process a single step in an event correlation process
*Event Report Message a message sent from one physical system to another that
contains information about an event (ITU-T Rec. M.2140).
*Event Set the set of all events that are grouped by a selection process for direct
comparison or patterning (ITU-T Rec. M.2140).
Failure the termination of the ability of an item to perform a required function. Note
that after a failure the item has a fault (ITU-T Rec. M.20).
Fault the inability of an item to perform a required function, excluding that inability
due to preventive maintenance, lack of external resources or planned actions. Note
that a fault is often the result of a failure of the item itself, but may exist without prior
failure (ITU-T Rec. M.20).
*Fault Management (FM) a set of TMN management functions which enable the
detection and localization of faults, the scheduling of repairs, and the testing out and
return to service of repaired equipment (ITU-T Rec. M.3010).
Grade of Service (GoS) the designed service quality, also known as guaranteed
QoS, used as a comparison with delivered (measured) QoS. A Service Provider
GB 917 v1.5
Page 10
commits a particular GoS to their Customers and then the QoS is a measurement of
what was actually delivered (TMF 701 modified).
An alternative definition is offered below based on ITU-T Study Group 2 work.
GoS is the minimum level of service quality designed into the network supporting the
service and maintained by traffic planning and engineering management actions
depending on traffic densities over the duration the service is offered or used. As
such, GoS represents a guaranteed expected level of service quality for any
connection in the same QoS class of a specified service at any instant, and may in
fact be improved upon depending on traffic loading of the network.
*Impairment a condition that causes anomalies or defects without causing a failure
(degrades the performance of a resource without causing a failure) (ITU-T Rec.
M.2140).
Indication an intermediate output of the event correlation process. A notification,
indicating a persistent network, application or system-detected trouble condition. The
three types of indication are fault indication, impairment indication, and trend
indication (ITU-T Rec. M.2140 modified).
*Independent Event an event that is not currently superceded by another event
Mean Time Between Failures (MTBF) the average time between failures of the
service.
Mean Time Between Outages (MTBO) the average time between outages of the
service.
Mean Time to Provide Service (MTPS) the average time to actually provide a
specified service from the date of signing a contract to provide service. This may or
may not be specified in the SLA.
Mean Time To Repair (MTTR) the average time to repair service resources.
Mean Time to Restore Service (MTRS) the average time to restore service after
reporting a fault; this time includes the time to sectionalize and locate the fault. This
may or may not be specified in the SLA.
Measurement Interval the time interval over which each performance parameter is
measured. For example, a parameter may be the number of errored seconds which
occurred over a fifteen minute measurement interval (TMF 701 modified).
Network Operator (NO)/Provider a company or organization which operates and
provides telecommunication network paths and connections as a business. These
may be direct to end Customers (in which case the NO is also a Service Provider) or
under contract to Service Providers who in turn provide services to end Customers.
Network Performance (NP) the ability of a network or network portion to provide
the functions related to communications between users. Note that NP applies to the
GB 917 v1.5
Page 11
Network Providers planning, development, operations and maintenance and is the

detailed technical part of QoS, excluding service support performance and human
factors. NP is the main influence on serveability performance. NP measures are
meaningful to Network Providers and are quantifiable at the part of the network to
which they apply. QoS measures are only quantifiable at a Service Access Point
(SAP) (ITU-T Rec. E.800).
Notification information emitted by a managed object relating to an event that has
occurred within the managed object; information passed from one Management
Application Function (MAF) to another regarding an event (ITU-T Rec. X.710 and
M.3010).
Operations these include the operation of work centers, technical support centers,
support systems, test equipment, methods and procedures, as well as the personnel
and training required to install and maintain all the elements that constitute the
network capability underlying the relevant services (ITU-T Rec. M.3010).
*Operations System the OS is the stand-alone system which performs Operations
Systems Functions (OSFs). For operational purposes, the management functionality
may be considered to be partitioned into layers, such as network element
management layer, network layer, service layer and business layer (ITU-T Rec.
M.3010).
Performance Management (PM) a set of TMN management functions which
enable the performance (i.e. the ability to reproduce the signal) of the network
services to be measured and corrective actions to be taken (ITU-T Rec. M.3010).
Performance Report a statement of performance achieved over a given
measurement interval and made available to the Customer by a variety of methods.
These include printed or electronic reports provided on a regular basis, stored reports
in a database accessible by the Customer or on-demand reports. Two basic types of
reports are normally available QoS performance against SLA guaranteed values
and traffic data/utilization reports (extracted from TMF 701).
Quality of Service (QoS) the collective effect of service performances which
determine the degree of satisfaction of a user of the service. Note that the quality of
service is characterized by the combined aspects of service support performance,
service operability performance, service integrity and other factors specific to each
service (ITU-T Rec. E.800).
Quality of Service Reports reports generated from the service quality and
performance data to report the performance of the service as a whole.
Raw Performance Data raw performance data collected from various data sources
including the network and service resources, such as network elements, network and
element management systems, and network and application servers. In addition, data
collected for the SPs OSSs, such as trouble ticketing, order processes, maintenance
and support, Customer care, etc.
*Ready for Service Date (RFSD) the specified date in the contract at which the
contracted service is ready for operation.
GB 917 v1.5
Page 12
Reporting Period the period at which performance reports are generated. It is

defined independently for each SAP Group within the associated SLA (TMF 701).
Service a telecommunication service is a set of independent functions that are an
integral part of one or more business processes. This functional set consists of the
hardware and software components as well as the underlying communications
medium. The Customer sees all of these components as an amalgamated unit (TMF
701 modified).
Service Access Point (SAP) a logical or physical element located on the interface
between a Customers domain and the Service Providers domain, representing the
point at which a service is delivered. A SAP can be weighted in accordance with a
business-critical factor that is defined in the SLA (TMF 701 modified).
Service Access Point Group a group of SAPs against which Service Availability
must be reported. Each SAP normally belongs to one (or more than one) SAP Group
and each SAP Group contains at least one SAP. The association between SAP
Groups and SAPs is defined within the associated SLA, according to the required
computation and aggregation format (TMF 701).
Service Availability (SA) a measure of the fraction of time during a defined period
when the service provided is deemed to be better than a defined QoS threshold. SA
is measured in the context of a SLA between the Customer and the Service Provider
concerned. It is expressed as a percentage (SA%) to indicate the time during which
the contracted service (e.g. SVCs, PVCs, end-to-end circuits including protocols,
applications, etc.) at the respective SAPs is operational. Operational means that the
Customer has the ability to use the service as specified in the SLA (TMF 701
modified).
Note that the calculation of the SA may include weighting of the SAPs as noted
above. The detailed formula is contained in TMF 701 and ITU-T Rec. M.1539.
*Service Degradation Factor (SDF) a factor agreed between the Customer and
the Service Provider used to weight the service availability calculation when the
service is still available, but degraded from its contracted QoS (extracted from (TMF
701).
Service Descriptions - details of the service product catalogue offered by the SP.
Service Element a service element comprises one or more network or service
resources that are combined with other service elements to provide a service (TMF
701 modified).
Service Instance a service that has been instantiated for a Customer.
Service Level Agreement (SLA) a formal negotiated agreement between two
parties, sometimes called a Service Level Guarantee. It is a contract (or part of one)
that exists between the Service Provider and the Customer, designed to create a
common understanding about services, priorities, responsibilities, etc. (TMF 701
modified).
GB 917 v1.5
Page 13
An SLA or Contract is a set of appropriate procedures and targets formally or

informally agreed between Network Operators/Service Providers (NOs/SPs) or
between NOs/SPs and Customers, in order to achieve and maintain specified Quality
of Service (QoS) in accordance with ITU (ITU-T and ITU-R) Recommendations. The
SLA may be an integral part of the Contract. These procedures and targets are
related to specific circuit/service availability, error performance, Ready for Service
Date (RFSD), Mean Time Between Failures (MTBF), Mean Time to Restore Service
(MTRS), Mean Time To Repair (MTTR) (ITU-T Rec. M.1340).
Service Level Agreement Contracts individual-specific SLA contracts between
the SP and the Customer with the specific service details, agreed levels of service
quality, reporting schedules, and details of actions to be taken when the service
quality guarantees are not met.
Service Level Agreement Reports reports generated from the Customer SLA
quality and performance data to report the performance of the specific service
instance for a specific Customer against a SLA.
Service Level Agreement Templates definitions of the standard grades of service
which can be offered with a SLA, for example templates to describe gold and silver
service characteristics.
Service Provider (SP) a company or organization that provides telecommunication
services as a business. SPs may operate networks, or they may simply integrate the
services of other providers in order to deliver a total service to their Customers.
Providing a telecommunication service to any one end Customer may involve multiple
SPs, where one provider may sub-contract with other providers to fulfil the
Customers needs (TMF 701).
Note that the term Service Provider is now being used generically and may include
Telecom Service Providers (TSPs), Internet Service Providers (ISPs), Application
Service Providers (ASPs) and other organizations that provide services, e.g. internal
IT organizations that need or have SLA capabilities or requirements.
Service QoS and Performance Data aggregated service quality and performance
data combined from the many disparate raw data sources.
*Service Support Performance the ability of an organization to provide a service
and assist in its utilization. Note that an example of service support performance is
the ability to provide assistance in commissioning a basic service, or a supplementary
service such as the call waiting service or directory enquiries service (ITU-T Rec.
E.800).
*Standing Condition a condition that has duration, beginning with a failure and
ending with a clear (ITU-T Rec. M.2140).
Telecommunications Management Network (TMN) a TMN provides the means
used to transport and process information related to management of the
telecommunication network (ITU-T Rec. M.3010).
GB 917 v1.5
Page 14
Telecommunication Service that which is offered by a Service Provider to its

Customers in order to satisfy a specific telecommunication requirement. Note that
bearer services and teleservices are types of telecommunication service. Other types
of telecommunication service may be identified in the future (ITU-T Rec. I.112
modified).
*Threshold Crossing Alert a transient condition declared when a performance
monitoring parameter reaches or exceeds a preset threshold (ITU-T Rec. M.2140).
*Thresholding a process which is involved in decision making and which
compares the actual value of a parameter with a predetermined value to decide
whether an alarm action needs to be initiated (ITU-T Rec. M.3010).
Time to First Yield the time interval between initiating service and the first
reportable service-impacting event.
Transient Condition a condition that has no duration, a one-time report (ITU-T
Rec. M.2140).
Trouble the perception of a fault or degradation that is judged to require
maintenance attention (ITU-T Rec. M.2140).
User a person or a machine delegated by a Customer to use the services and/or
facilities of a telecommunication network or service offering. (ITU-T Rec. I.112
modified).
GB 917 v1.5
Page 15
Chapter 3 Motivation and

Requirements for SLA Management
3.1
Introduction
The increased significance of SLAs reflects the changes taking place in the
telecommunication industry. The liberalization of the telecommunication market has
been an important trigger leading to change and competition, and SLAs are one
response to such a competitive environment. The market is being opened up,
enabling a variety of providers to enter and compete for Customers. New entrants
need to gain market share and establish themselves as serious players. SLAs
provide one means of attracting Customers and can contribute to establishing the
credibility of a new SP by committing to provide guaranteed levels of support with
compensation if such guarantees are not met. Incumbent SPs are increasingly
offering SLAs in response.
The rapid evolution of the telecommunication market is leading to the introduction of
new services and new networking technologies in ever-shorter time scales. SLAs can
help encourage Customers to use such technologies and services as they provide a
commitment from the SP to guarantee specified performance levels. The high
dependency on the availability of networks and communication and information
services for an increasing number of critical business activities means that greater
numbers of Customers are looking for SLA guarantees to enable them to carry out
their business.
In addition, many IT departments are being measured by the service levels they
provide to other business units within their organization and must demonstrate their
ability to deliver on these internal SLAs. Customers can therefore use the SLA
commitments from the SP when planning their own systems and future growth. SLAs
are also advantageous for smaller organizations that do not have their own IT
department and networking specialists as SLAs can give them the performance
guarantees they need.
Competition in liberalized telecommunication markets and the demands of
Customers using more complex services are leading to greater emphasis on the
provision of efficient Customer service as a means of increasing a SPs competitive
edge. SLA and QoS management can contribute to determining how Customer care
is perceived. Customer perception is important, and good Customer relations and the
ability to meet commitments are more important than just price, especially for
business Customers. SLAs can therefore aid SPs in attracting Customers and
GB 917 v1.5
Page 16
maintaining loyalty. All of these factors assist in meeting Customer Relationship

Management (CRM) goals and initiatives.
All SPs are seeking new ways of doing business and are therefore investigating
opportunities for providing differentiated SLAs to their Customers in order to
distinguish the quality and reliability of their services from those of their competitors.
However, for several reasons, SPs are experiencing increasing difficulty in preparing
and managing these SLAs. SLAs have developed in an ad hoc way and there is no
list of common SLA terms to use when creating a Customer-specific agreement. In
addition, many of the performance parameters have focused on network and network
element performance whereas a SLA is concerned with ensuring service quality
levels. This requires translating such performance details into service level metrics
that are of relevance to the service being delivered and to Customer perception, i.e.
with an end-to-end perspective.
As value chains become more complex, multiple SPs are becoming involved in the
provision of a service to an end Customer. SLAs need to be concluded throughout
the value chain so that the end Customer can be given the required SLA support by
the retail SP. The SPs involved in the service provision require a common
understanding of service quality guarantees and a consistent approach to SLA
management in order to support the commitments that they are providing for the
services they deliver.
3.2
Business Model
This Handbook has adopted the business model of the TM Forum Telecom
Operations Map [GB 910], which is reviewed briefly for the purposes of SLA
management. The business reference model introduces the business relationships
between the various roles in a management value chain and illustrates the principal
points of contact between the roles.
Customer
Service Provider
Other Providers/
Operators
Third party
Applications
Vendors
Suppliers
Figure 3.1: The Business Reference Model
GB 917 v1.5
Page 17
As shown in Figure 3.1, these roles comprise Customers, Service Providers, Other
Providers/Operators, Third Party Applications Vendors, and Suppliers to Service
Providers. A variety of business relationships can exist between these roles in a
competitive market with multiple providers. These relationships can be formalized at
the interfaces between the roles, as these are the points at which information needs
to be exchanged. The particular interface that is the subject of this Handbook is that
between Customer and Service Provider (see Figure 3.2).
Relationship
Customer
Service
Provider
Contract
Service Quality
Figure 3.2: SLA at the Customer-Service Provider Interface

The overall relationship is important in this context as Customers and SPs jointly
negotiate a SLA covering the services being provided by the SP to the Customer and
in so doing develop a greater understanding of the others approach, requirements
and responsibilities.
3.3
Business Benefits
3.3.1 Customer Benefits

A consistent approach to SLA management will provide the following benefits to a
SPs Customers:
Help Customers develop the baseline, establish the requirements,
customize a SLA contract, validate the ongoing performance
compliance to end-to-end service level objectives, and review and
refine the SLA through an iterative process.
Help Customers establish parameters, measurement methods,
reports and exception handling in the SLA.
Help Customers define high-level common terms and definitions for
end-to-end service performance in the form of network technologyindependent QoS metrics, parameters and reports. These include
items such as mean time to provision; mean time to identify, repair
GB 917 v1.5
Page 18
and resolve malfunction; service availability; end-to-end throughput,

delays and errors.
Help Customers evaluate the relationship between the technologyspecific service and network elements and the technology/serviceindependent parameters of the SLA. This includes considering how,
within each of the multiple SP administrative domains, these
parameters map, interpret or mimic the performance perceived by the
Customer.
Help Customers validate the QoS as defined in the SLA document by
receiving predefined and exception reports and SP responses to
performance inquiries. These include notifications of SLA violations,
reports of any developing capacity problems, changes in usage
patterns, and reporting delivered performance for comparison with the
Customers' perceived performance.
Help Customers evaluate a SP's methods for detecting degraded
service performance, alerting the Customer and responding to
performance events affecting the Customer's service.
Help Customers verify the implementation of penalty provisions for
failure to maintain and deliver the service as defined in the SLA,
including cancellation fees.
Help Customers define the end-to-end QoS metrics for multimedia
telecommunication services, especially those carried over IP-based
networks.
Help Customers compare services and service quality levels offered
by different SPs.
3.3.2 Service Provider Benefits

A consistent approach to SLA management will:
Help introduce operational changes, improve internal measurements
and reporting, enrich Customer relations and differentiate the SP from
its competitors.
Help create more knowledgeable Customers who can better express
their needs to the SP, which can reduce the time devoted to the
negotiating process.
Help create a common language and understanding with the
Customer on characterizing network and operational parameters.
Help create SP internal recognition of the Customers perception of
network errors and service interruptions.
Help prioritize service improvement opportunities.
Help create common SLA/QoS goals across multiple technology
domains.
Help standardize performance-gathering practices across multiple
internal domains.
GB 917 v1.5
Page 19
3.3.3 Vendor Benefits

A consistent approach to SLA management will:
Help vendors understand Customer and SP requirements for SLAs.
Help equipment suppliers agree on the mapping of technologyspecific parameters and measurement methods into service-specific
parameters and measurement methods.
Help software vendors agree on common interface definitions for SLA
management.
3.4
Performance Reporting
Work on performance reporting was undertaken by the Performance Reporting
Team, which was concerned with performance reporting over the SP to Customer
interface3, and which produced the document Service Provider to Customer
Performance Reporting Business Agreement [NMF 503]. The document investigates
the business context and examines what is required for reporting on the quality of
services delivered to the Customer as well as the kind of information that needs to be
exchanged to meet these requirements. The requirements are intended to be generic
and suitable therefore for reporting on various services delivered by a SP to a
Customer.
In NMF 503, performance reporting was understood to include the following
functions:
Schedule Customer reports
Receive performance data
Compile Customer reports
Deliver report to Customer
The performance reporting functionality was expected to interact with other service
functions as shown in Figure 3.3 from NMF 503. Various scenarios are introduced to
illustrate how the interface would be used, for example, reporting with
acknowledgement, reporting via a mailing system, reporting on demand, modifying
the reporting mode.
Performance Reporting was one of the business processes in the document, A Service Management Business Process
Model, 1995, a predecessor to the Telecom Operations Map. The Performance Reporting process was developed into the
Customer QoS Management process in the Telecom Operations Map.
GB 917 v1.5
Page 20
Scope of NMF 503
CUSTOMER
Customer - SP Interface
Reports Repository and Delivery
Request
on a SAP
Request to
create a TT
Ordering
C
O
N
T
R
A
C
T
S
L
A
TT
SAP
details
SAP-Weight
Garanteed
V l activity
SAP
i t
l
A
MTTR
MRT
MTBF
SAP outage
intervals
Response time
(Invoice and
Credits)
Net.Perf.
Traffic Data
MTTR, A, MRT, MTBF
Perf
Net.Perf.
Traffic Metrics
SLA violations
Event
Common Objects
Billing
Net.Perf.
Traffic Data
Network
Elements
Report computation and aggregation
Figure 3.3: Interaction of Performance Reporting with other Service Functions and Scope
of the Performance Reporting Interface Definition
The specific business requirements on the performing reporting interface are
introduced. These are categorized either as mandatory core requirements or as
optional requirements. The requirements are grouped as follows:
Contract (SLA) related requirements
Performance report related requirements
Service availability related requirements
General QoS requirements
Report generation and distribution requirements
Report frequency requirements
Report customization requirements
The general technical requirements on the interface include those concerned with
transport, connection, security as well as other general requirements.
The document is relevant to the SLA Management Handbook as reporting on
performance is an essential part of SLA management. It is referenced here so that
readers of this Handbook are aware of the TM Forum work already undertaken in the
performance reporting area without it being explicitly repeated.
GB 917 v1.5
Page 21
The second document issued (and since updated) by the Performance Reporting
Team is Performance Reporting Concepts and Definitions [TMF 701]. This was
produced as the Performance Reporting Team had felt that such a document was
lacking, and a common understanding of service performance and service
performance definitions is required in defining a performance reporting interface
between Customer and SP. Service performance reporting depends on a number of
QoS parameters and these are defined and their usage explained in TMF 701. Also
included are definitions of SLAs and their contents, especially from the performance
reporting aspect. The SLA Management Handbook has used those definitions and
readers are therefore referred to TMF 701 for further information.
3.5
Requirements
This section identifies some of the requirements for the management of SLAs and
associated QoS parameters. Later chapters in this Handbook assume the existence
of these requirements, which have been grouped into categories that partially reflect
the life cycle of business process management in the Telecom Operations Map.
3.5.1 Fulfillment
The requirements in this section are concerned with the SLA negotiation and
engineering processes that take place during the fulfillment phase of the business
process model.
Req. 1: The SLA is an integral part of the overall service contract and should include
clear and unambiguous definitions of the following:
The measurable QoS metrics and parameters that can be guaranteed
by the SP for a specific service in terms that the Customer can
understand and agree to.
Service performance measurement method, measurement period,
reporting period and reporting frequency (see [TMF 701] for a
definition of these terms).
Customer and SP responsibilities, e.g. maintaining relevant hardware
and software.
SP procedures to be invoked on violation of SLA guarantees.
Any conditions that affect operability/commitment to support.
Selection of the type of reports associated with the service, specifying
each reports contents, format, destination, conditions and delivery
media.
Service definitions for each service covered by the SLA.
Process for handling the defined boundary conditions.
GB 917 v1.5
Page 22
Service cover time, i.e. the limits of SP support for different times of
the day/week/month/year, etc.
Dispute resolution procedures.
Req. 2: For any service the Customer should be able to select:
Parameters to guarantee.
Value ranges for the parameters.
Req. 3: When defining the service reliability and performance metrics for the SLA, the
following criteria should be considered:
Provide concrete repeatable measurements in a well-defined unit of
measurement without subjective interpretation.
Be useful to users and SPs in understanding the performance they
experience or provide.
Be measurable by SPs, their Customers and outside testing agencies.
Be useful as specification in the formal documents to help highperformance users purchase the capacity that they need and to verify
that it is actually met.
Be useful for publication in data sheets.
Be possible to provide measurements separately from each SP in a
value chain.
Be useful for diagnostics, including a diagnostic mode which can be
used to sectionalize or identify the weak link in a long multihop, multiprovider path.
Req. 4: Standards and targets must be set with a periodic (e.g. annual) service
performance review which should include procedures to update the SLA according to
changing Customer needs.
Req. 5: The SP needs to be able to create the following:
Thresholds for preventative activities to be initiated before a SLA
violation occurs.
A capability to store several values per parameter to support the need
for different values. For example different values may need to be
stored depending on time of day or week.
The ability to collect information from underlying element and network
management systems, such as performance management systems
and traffic management systems.
3.5.2 Assurance
The requirements in this section are concerned with the assurance processes after
the service has been provisioned and is being delivered to the Customer. They affect
mainly the monitoring of service quality levels and the reporting of information to the
Customer according to the SLA.
GB 917 v1.5
Page 23
Req. 6: The SP must be able to monitor and measure the delivered service quality
against SLA commitments at a level acceptable to the Customer and/or the
regulatory authorities.
Req. 7: Accurate Customer-oriented information about all SLA parameters must be
made available to Customers on a real-time and/or periodic basis as agreed in the
SLA.
Req. 8: Strong access control and authentication must be provided so that
Customers are able to see only their own data as agreed in the SLA.
Req. 9: The SP should provide a capability to detect degradation in service
performance, alert the Customer and respond to performance events affecting the
Customers service and associated SLA.
Req. 10: The SP should provide a fault monitoring and tracking capability to ensure
that faults are identified, tracked and resolved within time scales defined by SLAs,
and should notify Customers when these critical milestones are not met.
Req. 11: Customers should be kept informed of potential deviations from SLA
coverage, including both scheduled and unscheduled maintenance. In the case of
failure, Customers should be notified of the approximate time that the service will be
resumed and should be kept informed about the progress of problem resolution.
Req. 12: The SP should have soft thresholds for every parameter to be warned of
impending trouble and if Customers wish, they should be kept informed of any service
degradation that could lead to possible SLA violations.
Req. 13: For a service involving multiple SPs, the Customer-facing SP should be able
to account for degradation of service performance resulting from other SPs or
network operators. Arrangements should be made with the third parties that will
enable the Customer-facing SP to take appropriate action in case of SLA violations
caused by the third parties.
3.5.3 Customer Interface Management

These requirements are concerned with the interface between the Customer and the
SP and with how the SP should interact with Customer inquiries concerning a service
and its SLA.
Req. 14: Customers should be to able to report troubles or faults, request changes
and make inquiries about their services by telephone, fax or electronically, and
receive notifications in the same variety of ways.
Req. 15: The SP should provide a rapid response to Customer help desk inquires
concerning service quality levels.
Req. 16: The SPs Customer Contact Points should have information available on the
status of any service about which the Customer could inquire.
GB 917 v1.5
Page 24
3.6
Examples
The examples given here are provided as services that can be referred to in later
chapters of the Handbook. They cover a variety of service types for which a SLA may
be created and are intended to illustrate the application of the Handbook in different
contexts.
3.6.1 Leased Line Service4

A digital leased line service (leased circuit) is typically provided over PDH, SDH or
SONET transport network facilities. As such, it often comprises a simple E1 or T1
digital path or a subset of a higher speed digital path between two Network
Terminating Equipments (NTEs). The NTEs may be simple connectors, intelligent
loopback devices or more sophisticated equipment such as Channel Service Units
(CSUs), Add-Drop Multiplexers (ADMs), routers or switches. For example, the leased
line may be an ATM, FR or IP leased circuit service.
A leased circuit may be bi-directional or unidirectional. Examples are the provision of
transport paths between base and switching stations in a mobile network, transport of
television signals between broadcasting center and transmitter, and bandwidth pipes
for Internet Service Providers (ISPs) or other SPs. The main focus here is on
PDH/SDH.
The leased circuit end points (or Service Access Points) are at the boundaries
between the Network Operators (NOs) or between the NO and the end Customer. At
the SAP, the signal normally contains Path OverHead (POH) information, for
monitoring and maintenance purposes, as well as the payload. However, it should be
noted that due to regulatory and/or commercial conditions, access to this signal POH
for In-Service Monitoring (ISM) purposes may not be possible at the SAP by the NO,
e.g. when the Customer owns the NTE or Path Terminating Equipment (PTE). The
interface to the Customer may be an electrical interface as described in ITU-T
Recommendations G.703, G.707, G.708 and G.709, or an optical interface as
described in ITU-T Recommendations G.707 and G.957. The Customer should use
the standard POH defined in ITU-T Recommendations and ideally make it available
to the NO for ISM. All of these details should be written into the SLA terms during the
negotiation phase.
The portions of the leased circuit may in fact cross more than one NO and the
responsibility for providing the circuit may be a SP who owns only part or even none
of the network equipment supporting the circuit. The SP will negotiate with NOs
(providers) to assign network paths as required, and with the Customer regarding
visits to their premises for any installation of terminal equipment and testing of the
circuit.
The timing feed at each end of a leased circuit should be derived from a primary
reference clock operating in accordance with ITU-T Recommendation G.811. In
general, the leased circuit timing will be derived from the network supporting it and not
4
This description of a leased line service is based largely on ITU-T Recommendations for International Leased Circuits e.g.
draft determined Rec. M.13SDH published in COM 4-R54 March 2000.
GB 917 v1.5
Page 25
from the Customers equipment. The network clock is normally used to drive the
Customers equipment. If the leased circuit is provided by multiple NOs, agreement
must be reached on the source of the master clock or the provision of appropriate
facilities to take account of timing differences.
Three key areas of performance need to be checked when bringing-into-service or
maintaining a PDH or SDH leased circuit. These are error performance, timing
performance and availability performance. Delay performance is also important for
some leased circuits, e.g. those carrying television and sound programme signals.
3.6.2 Frame Relay Service5

Frame Relay network technology is ideal for combining the main advantages of
leased lines (short delay, high transmission capacity, protocol transparency) and
packet switching (efficient use of backbone network capacity). The dynamic
transmission method and the short delay times in the backbone network make the
Frame Relay service particularly suitable for data-intensive applications for which the
demands on network transmission capacity can fluctuate at short notice.
The Frame Relay backbone network consists of a large number of network nodes
that are interlinked by trunks. A number of Service Access Points (SAPs) are
available for logical connections to the backbone network. The Customer only has to
pay the access charges to connect to the nearest SAP. In physical terms, the
Customer's communication equipment (router, FRAD) is connected to a port at the
nearest network node in the Frame Relay backbone network using an access line.
The transmission speeds for this access line may not be identical to those of the
Frame Relay port. The access line forms part of the Frame Relay service, i.e. the SP
is responsible for orders and billing (one-stop shopping and one-stop billing).
A number of parameters may be negotiated between the Customer and the SP as
part of the SLA, such as:
Service (Frame Relay PVC) Availability *
Frame Transfer Delay*
Frame Transfer Delay Variation
Frame Delivery Ratio*
Data Delivery Ratio*
Minimum Information Rate
Committed Information Rate
Peak Information Rate
Frame Error Ratio
* As defined by the Frame Relay Forum in [FRF.13].
The Frame Relay service was one of the services selected by the SLA Management Wholesale and Retail Services catalyst
(SLA catalyst team) and section 3.6.2 is based upon that teams specification of the service.
GB 917 v1.5
Page 26
3.6.3 ATM Cell Delivery Service

ATM Cell Delivery service is similar to the Frame Relay service discussed above. It
consists of subscribers obtaining access lines to network ATM switches, and Virtual
Circuits (VCs) from the Customer Premises Equipment (CPE) over the access lines,
through the network of ATM switches, to other ATM Cell Delivery service Customers.
In some cases, the CPE itself may be an ATM edge switch owned by the Customer
and offering a range of service applications (voice, video, data, etc.) to users.
The VCs may be either permanent (PVC) or switched (SVC). The structure of ATM
allows for many more traffic QoS classes to be defined and the traffic characteristics
to be more tightly controlled. The traffic QoS classes can range from Constant Bit
Rate (CBR) or Deterministic Bit Rate (DBR), with speeds up to the access line rate, to
a best effort Unspecified Bit Rate (UBR) class. These characteristics are established
when the VC is created. Some advanced services allow re-negotiation of the traffic
characteristics during the connection.
Customers negotiate several parameters for access, plus per PVC parameters. For
switched circuits, Customers negotiate other behavior based on the establishment of
the SVC:
Service Availability
Access Line Speed
Per VC Cell Rate (can be quite complex for non-real-time and realtime streams)
Per VC Cell Propagation Delay
Per VC Cell Delay Variation
Per SVC Call Setup time
Per SVC Blocked Calls
Cell Error Ratio
Cell Loss Ratio
3.6.4 IP-VPN Service6

An IP-based Virtual Private Network (VPN) enables the transport of IP packets
between a specified list of end points with a statistical assurance of QoS (loss, delay,
availability) and a level of security equivalent to a network built with private facilities.
The IP-VPN service has been developed to allow Customers to connect their different
locations in a cost-effective manner using the IP protocol. A router is installed at each
Customer site to allow connection to the IP backbone network (see Figure 3.4).
The IP-VPN service was one of the services selected by the SLA Management Wholesale and Retail Services catalyst (SLA
catalyst team) and section 3.6.4 is based upon that teams specification of the service.
GB 917 v1.5
Page 27
Service
Access
Point (SAP)
SAP
IP Backbone
SAP
SAP
Customer Premises Equipment

Boundaries of IP VPN Service Management
Figure 3.4: IP-VPN Service Concept

The IP backbone is a publicly accessible network which may provide connectivity to
the global Internet. Tunnels are used to segregate IP-VPN traffic from normal Internet
traffic. This provides a virtual private network (i.e. an intranet) using a public IP
network. In this way, an IP-VPN provides the Customer with a Closed User Group
service (community of interest) creating any-to-any (fully meshed) connectivity. The
users of an IP-VPN only see the VPN connections within their own group.
A number of parameters are negotiated between the Customer and the SP as part of
the SLA. The following parameters may be part of the contract:
IP Packet Transfer Delay
IP Packet Delay Variation (jitter)
IP Packet Loss Ratio
IP Packet Error Ratio
Utilization
3.6.5 IP Service with DSL Access

The example shown in Figure 3.5 is an information service (e.g. access to Internet
web pages) provided by an ISP over a Telecom Service Providers (TSP) network to
a group of subscribers. It should be noted that it is the role these organizations play
that is important, not their traditional appearance as companies. For example, the
TSP acts as a network bearer service provider and network operator providing
connectivity between the ISP and its Customers. The ISP is the provider of the
GB 917 v1.5
Page 28
application service (i.e. the OSI layer 7), the application being information/Internet
access. However, the TSP could also be the ISP as well and vice versa.
CSP
User
SP 3
www+
Application Service
SLA
User
ISP
SP 1
TSP
SLA
www+
SP 2
Internet
Access
SLA
IP
Interface
TX
Network
User
Access
Interface
Network Bearer Service
User
www+
User
Access
Network
CSP = Content Service Provider

ISP = Internet Service Provider
TSP = Telecom Service Provider
www+
User
www+
Figure 3.5: Example of a Composite Service

There are therefore, at least two services involved in this example - a network
bearer service provided by the TSP to the ISP and an application service provided
by the ISP to its Customers. This is a classic example of the recursive nature shown
in TMF 701 of a service comprised of service elements, each of which is a service
itself comprised of service elements.
In our example, the TSP, acting as SP 2, may transport the service over a number of
different network technologies supporting the IP layer. The ISP, acting as SP1, on the
other hand uses the network bearer service as a service element supporting its
overall service to end Customers. As Figure 3.5 shows, there is a SAP group with a
SLA between SP1 and SP2 and another SAP group between SP1 and its
Customers.
There is also a third service involved in this example and that is of content provider.
This may be the ISP itself or its suppliers, such as vendors of film libraries, music,
games, etc. The ISP may act purely as a portal giving access to these content
providers, whether they are companies or individuals with web home pages.
The implications for SLA management include the fact there is probably a SLA
between the TSP and the ISP as well as a SLA between the ISP and its Customers.
One is dependent on the other. In assessing the QoS delivered to the end Customer,
the important thing to consider is the close coupling between the QoS of the telecom
service provided by the TSP and the QoS of the information systems and technology
GB 917 v1.5
Page 29
used by the ISP, e.g. servers, databases, video stores, etc. For a business doing
most of its transactions via ebusiness, this interdependence becomes critical. No
amount of duplication or redundancy built into the telecom links can compensate for
weaknesses in the IS/IT used by the ISP. This leads to the concept of two orthogonal
axes of business survivability and telecom dependence where the further along the
telecom dependence scale reliance is placed, the greater the risk to business
survivability becomes.
3.6.6 Customer Care Help Desk Service

The Customer Care Help Desk is an integral part of the overall service provided by
SPs. Since Customers need to be well informed about the nature of any fault, the
impact of faults on their contracted service, the status of resolution, and anticipated
time to restore the service to full operational status, the Customer Help Desk plays a
very important part in complying with a SLA contract.
An organizational service, such as the extended Help Desk support, enables a SP to
differentiate its service offering for different types of Customers. For example, a
network bearer service, such as an Internet access to an ISP via DSL, could be
offered as a stand-alone service with a limited Help Desk support (e.g. 8 a.m. to 5
p.m.). A SOHO (Small Office Home Office) Customer who uses the Internet
connection for ebusiness purposes (possibly not only during usual office hours) could
need, and therefore pay for, an added service providing extended Help Desk support.
The Customer Care Help Desk service is intrinsically different from the examples
provided above for two reasons. First, while the others are network-based services,
this one is essentially an organizational service that does not provide any network
service or connectivity per se. Second, it depends on other (network bearer/valueadded) services and is normally sold as an add-on to a SPs commercial offers.
A set of time-of-day-based parameters could be negotiated between the Customer
and the SP as part of the SLA for this type of service. For example, the following
parameters could be part of the contract:
Mean Time to Respond i.e. wait for an available operator
Max Time to Respond for a Single Call
Mean Time to Examine Requests - i.e. entire time to process the
request
Max Time to Examine a Single Request
GB 917 v1.5
Page 30
GB 917 v1.5
Page 31
Chapter 4 QoS and the SLA

Parameter Framework
This chapter considers and defines the QoS parameters needed in a SLA and which
might be reported to Customers on a regular basis. The intent here is not to specify
actual performance values since these are commercially sensitive and subject to
negotiation between SP and Customer. The objective is to define a method of
classifying QoS parameters, listing and defining them in a consistent manner within
the SLA.
The SLA QoS parameters support a contract between two parties. Whether the SLA
and its QoS parameters are considered part of the contract or an adjunct to it varies
from provider to provider. There are numerous business parameters contained in a
contract that are not covered by this Handbook. For example, while violations and
remedies are discussed in terms of the parameters that may drive the process,
parameters for payment and terms are not included since these are unique to each
contract and a commercial agreement between the parties concerned. Similarly,
proprietary underlying systems and processes used to support SLAs are not
described.
It is important to note that there is a distinct difference between the user/service QoS
requirements defined in the SLA and the network level QoS/NP and QoS-enabling
mechanisms7.
4.1
Parameter Classification
4.1.1 General Concepts

Four main factors contribute collectively to the overall QoS perceived by the user of a
telecommunication service (see Figure 4.1). These are serveability, operability,
integrity and support, each of which should be considered as a concept or umbrella
characterized by many measures or parameters (see ITU-T Rec. [E.800] and
[E.801]). Serveability includes both accessibility performance and retainability
performance. These in turn can be broken down in terms of trafficability, availability,
reliability and propagation performance, all of which can be considered Network
Performance (NP) that delivers QoS. Service integrity depends on transmission
There are a number of places where important distinctions are drawn in order to clarify the confusion that exists. For
example, performance events and performance parameters are not the same thing. Neither are NP and QoS. Distinctions are
drawn between technology-specific, service-specific, and technology/service-independent parameters.
GB 917 v1.5
Page 32
(information transfer) NP. Further discussion of QoS and NP is contained in sections

4.1.2 and 4.1.3.
Quality of
Service
Support
Performance
Serveability
Performance
Operability
Performance
Integrity
Performance
QoS
QoS
NP
NP
Trafficability
Performance
Availability
Performance
Propagation
Performance
Transmission
Performance
Figure 4.1: Quality of Service and Network Performance Concepts

QoS parameters contained in a SLA need to be classified, defined and measured in a
consistent way in order to avoid confusion among users. In a competitive service
provision environment, Customers want to benchmark what is offered by SPs,
whether they are Telecom Service Providers (TSPs), Internet Service Providers
(ISPs) or Application Service Providers (ASPs). Service users generally identify two
groups of performance aspects - the administrative or human-related aspects and the
network or technical-related aspects. Very often, the human-related aspects
(including ease of use) are most important to the user, even though not always
recognized by the SP.
The EURESCOM Project P806 proposes we accept that users will define their own
QoS requirements in terms that reflect their personal needs, and that these QoS
requirements then need to be mapped by the SP (and its connecting providers) into
parameters that reflect their own, often technical, terminology [P806]. QoS from the
viewpoint of the Customer or user relates to the parameters or measures considered
essential in the use of the service. QoS in the context of the SP relates to NP
parameters contributing to the overall end-to-end performance of the service. Project
P.806 is important since the requirements for Public Network Operators (PNOs) to
collect and publish QoS statistics has already been established through European
Community (EC) directives relating to Open Network Provision (ONP), e.g. Directive
92/44/EEC on the application of ONP to leased lines.
The complexity of such calculations increases dramatically when one considers the
case of multiple SPs in global markets. It is worth noting that services may be based
on a range of technologies incorporating their own style of management and control.
This can range from straightforward leased lines to best effort IP router networks.
The P806 framework is generic in the sense that it is service/technology/networkindependent.
GB 917 v1.5
Page 33
4.1.2 Performance Events and Performance Parameters

It is important to distinguish between performance events and performance
parameters. Events are instantaneous phenomena that occur within the network
supporting the service or its environment that affect the QoS delivered. Examples are
Errored Seconds (ESs), Severely Errored Seconds (SESs), Severely Errored Periods
(SEPs), lost or misdirected cells and packets, loss of signal, loss of network
synchronization, lightning strikes, earthquakes, etc.
Performance parameters are derived by processing events over a measurement
interval into a defined metric that can be reported. These may be time-related
measures that can be expressed in terms of mean values or fractiles, ratios, which
are estimators of probabilities, or event rates or intensities contributing to reliability
performance. Examples are Errored Second Ratio (ESR), percentage Availability,
Throughput, Utilization, Severely Errored Period Intensity (SEPI), Mean Time
Between Outages or Failure (MTBO or MTBF), Outage Intensity (OI), Mean Time to
Provide Service (MTPS), Mean Time to Restore Service (MTRS), time to first yield8,
average call response time, etc.
4.1.3 Network Performance and QoS

NP depends on a SPs planning, development, operations and maintenance of the
network supporting the service, and it can be considered the core of the technical part
of QoS. It is up to the SP to combine the NP parameters in such a way that the
economic requirements of the SP as well as the satisfaction of the user are both
fulfilled. Usually, this requires a compromise between economy and QoS. An
essential difference between QoS and NP measures is that QoS is user-orientated
while NP is network provider-orientated. Thus QoS focuses on user-perceivable
effects (not their causes) and NP on the efficiency of the network in providing services
to the Customer. The result is that QoS measures are relevant between Service
Access Points (SAPs), usually on an end-to-end basis, while NP measures are
relevant between borders of network portions, see Figure 4.2 below.
Quality of Service
Network Performance
User-oriented
Provider-oriented
Service attribute
Connection element
Focus on user-observable effects
Focus on planning, design and development,

operations an d maintenance of network
Between (at) Service Access Points
End-to-end or network connection element

capabilities
Figure 4.2: Distinction between QoS and NP9

It is important therefore to distinguish between NP and QoS events and parameters.
In a client/server network, many of the events and parameters in the server network
8
9
Time to first yield is defined as the time interval between initiating service and the first reportable service-impacting event.
Derived from Handbook on Quality of Service and Network Performance [ITU_Hbk].
GB 917 v1.5
Page 34
layer are NP phenomena that may or may not affect the client service supported by
the network. This depends on the type of service and the application, and whether the
latter employs software or hardware capable of riding over or smoothing the effect of
network events. For example, error correction and retransmission applied at the
upper OSI layers of a data communication service may compensate for error events
and poor performance at the physical, data link, network or transport layers. In other
cases, the application may not be able to handle short break events, even though
these events do not result in server layer unavailability, and the application in the
client layer may have to be restarted. These short break events of periods of severe
errors can even be stretched as they impact the higher protocol layers.
4.1.4 NP/QoS Requirements and QoS Classes

NP is usually specified in terms of end-to-end and individual network portion events
and parameters, and these may be grouped into so-called QoS classes. For the
switched network (whether circuit-switched or packet-switched), there are two types
of QoS requirements. These are call- and connection-level QoS requirements, and
information-transfer QoS requirements. The first set is related to the call or connection
set-up, modification and release phases, and includes delays and blocking
probabilities of requests. One measure of these is End-to-end Connection Blocking
Probability (ECBP). The second set is associated with the information transfer phase,
and hence applicable to connections already established through the network. These
requirements are usually technology-specific and/or service-specific and relate to
service integrity performance. Note that for an IP-based (so-called connection-less)
network, there is still a phase of connection route set-up and an information transfer
phase for each packet. This may be true for a network using defined QoS
mechanisms, e.g. RSVP, as opposed to purely best effort operation. Furthermore,
router reconfiguration can contribute to delay in either the set-up or information
transfer phases of a call.
The existence of two types of QoS requirements calls also for the definition of two
types of QoS classes. Call- and connection-level QoS classes are characterized
mainly by a target value for ECBP. Information transfer-level QoS classes are
characterized by a set of performance objective values. Each QoS class provides a
guaranteed minimum level of NP to support a particular service and includes values
of QoS that can be expected.
As an example, ITU-T Rec. I.371 specifies a limited set of ATM Transfer Capabilities
(ATCs), each with a number of QoS classes [I.371]. An ATC is intended to support an
ATM layer service model and associated QoS through a set of ATM layer traffic
profile parameters and procedures.
The use of ATCs has both a user's perspective, wherein a transfer capability is seen
as suitable for a given set of applications, and a network operator's perspective,
wherein a transfer capability may provide gain through statistical multiplexing. For the
case of an ATM cell delivery service, the NP supported by the ATC and the delivered
QoS are one and the same. For the case of ATM supporting higher layer application
services, e.g. voice, video, IP, etc. carried over a core ATM/SDH network, the ATC
guarantees a minimum level of NP provided that the ATC traffic profile parameters
are not exceeded. Policing mechanisms are employed at the ATM layer to minimize
GB 917 v1.5
Page 35
network congestion and stop users abusing their bandwidth privileges/contracts. The
same approach should apply at the IP network layer.
Much of the foregoing discussion is technology-specific to ATM, but is important since
ATM is one of the core transport network technologies in use today. It includes these
QoS control mechanisms on which higher layer protocols such as IP may depend in
a packet-based network environment. Nevertheless, it is recognized that so-called
Next Generation Networks based on IP over other supporting transmission systems
will use similar QoS control mechanisms at the IP layer. Later, we will draw
distinctions between technology/service-independent, technology-specific and
service-specific QoS performance parameters.
The IETF has been working on a range of RFCs specifying QoS/NP, measurement
methods, and means of managing performance at the IP layer. One RFC 2330
specifies a framework for IP performance metrics, and this was used as input to ITUT Study Group 13 in developing new Recommendation Y.1540 on the same topic.
Further information on IETFs Working Groups and ITU-Ts activities can be found in
Appendix I.
4.1.5 NP, QoS and Grade of Service (GoS), and the Role of Traffic Engineering
From the QoS requirements, the end-to-end NP objectives of the connections are
derived. However, the network can provide different treatment to the different QoS
classes, but it also may occur that a network provides the same treatment to all or to
several QoS classes. In the latter case, the most stringent requirement for each QoS
parameter must be provided for all of the connections, which then receive the same
treatment. An important consequence of these two possibilities is that the end-to-end
NP objectives are derived not only from the QoS requirements, but also from the
Network Operators planning and traffic engineering strategy.
Grade of Service (GoS) is defined by a number of traffic engineering variables used
to provide a measure of adequacy of a group of resources under specified conditions.
GoS criteria are used for the dimensioning of the network and the equipment
supporting the service. The GoS is characterized by a number of trafficability
performance parameters (see Figure 4.1) such as calling rate, call set-up delay,
answer-signal delay, internal and external blocking.
As with QoS requirements, two levels of GoS objectives can be distinguished - the
call- and connection-level GoS governed mainly by the ECBP and the information
transfer-level GoS objectives. For ATM, the latter are the maximum queuing delay
(defined as a remote quantile of the cell delay distribution) and the mean queuing
delay (both based on the QoS/NP parameters CTD and CDV) and the CLR. It is
perhaps worth noting that QoS delivered by cell/packet-based networks will depend
even more on traffic engineering methods and effectiveness than for circuit-switched
networks.
GB 917 v1.5
Page 36
4.1.6 Network Bearer Services and Application Services

Furthermore, the service offered needs to be clearly defined. Is it a network bearer
service supporting, but independent of, the application carried, or is it an application
service, e.g. voice, video, sound programme, etc. supported by lower layer network
connectivity? The ATM example quoted above can be both - an ATM network bearer
service used to support IP-based, FR-based or circuit-based services, or a pure cell
stream delivery service. A parameter measured between (or at) access points of a
bearer service is a NP parameter to the provider of the bearer service, but a QoS
parameter to the user or client of the bearer service. ATM is therefore a good
example of both a service and a supporting network technology. Similar arguments
can be applied to IP. It can be a supporting network technology or purely a packet
delivery service.
Some people regard the SLA as a kind of Business API and QoS as a kind of
Network API. Whether this is true depends to some extent on whether a network
bearer service or an application service is being considered. It also depends on
whether the technical QoS aspects are considered part of the SLA/Contract or an
adjunct to it. In general terms, a service is a product provided by one entity to another
for which payment may be made.
4.1.7 Parameter Dependence and Independence

It is important to distinguish between QoS parameters that are independent of the
service and network technology supporting the service, those which are servicespecific and those that are network technology-specific. This distinction was made
early on in the TM Forum work on Performance Reporting (see [TMF 701]) and was
later refined to distinguish between single user instance and aggregated
requirements as shown in the parameter framework below (Figure 4.3):
Parameter Category
Service
Perspective
Technology-specific
Service-specific
Technology/Service independent
Single User
Instance
(SAP-related)
e.g. physical interface

details
e.g. service type or bundle
e.g. max. down-time of

one event
Aggregated
Requirements
e.g. monthly reported

parameters
e.g. billing method (usageor time-based)
e.g. aggregate availability

over all users
Figure 4.3: Framework for Parameter Categories

The two rows distinguish between single-user instance (SAP-related) aspects such
as the service interface or maximum down-time for a single event, and aggregated
requirements such as the billing and reporting periods or aggregate availability. It is
important to distinguish between a single user instance and aggregated requirements
from the users perspective. Typically the single user is the initiator of a trouble report.
For example, when availability is specified over a billing period, it would be possible
for a single outage for a single user to shut down that user entirely and still meet the
GB 917 v1.5
Page 37
overall requirements. The single user instance parameters would define the
maximum down time for a single event and the minimum up-time between events.
This detail may be lost when working at the aggregated requirements level.
The SP's perspective is different from the Customer's, and internally at least, the SP
has issues high on their agenda such as revenue generation/continuity, differentiated
services and least cost to maintain networks and services. These issues might
feature in the internal SLA between departments of a SP or between one SP
(retailer) and another (wholesaler). Note that availability performance can be specified
in all six categories.
Some services may contain both technology-specific and service-specific
parameters, while some may contain only one or the other. Two examples follow to
illustrate:
Parameter Category
Service
Perspective
Technology-specific
Service-specific
Single User
Instance
(SAP-related)
e.g. speed
e.g. delay, throughput
e.g. availability, max. time

to restore
Aggregated
Requirements
e.g. total UAS
e.g. delay distribution
e.g. MTBF, MTTR, MTRS
Figure 4.4: IP Service with DSL Access

Parameter Category
Service
Perspective
Technology-specific
Service-specific
Single User
Instance
(SAP-related)
e.g. CER, CLR, CTD, CDV - all max.

values
e.g. availability, max. time

to restore
Aggregated
Requirements
e.g. CER, CLR, CTD, CDV - all mean

values and totals
e.g. MTBF, MTTR, MTRS
Figure 4.5: ATM Cell Delivery Service
4.1.8 Service/Technology-independent Parameters

Service/technology-independent QoS parameters are those which are often (if not
always) specified in a SLA. Examples include those already mentioned such as
Percentage Availability, MTBO or MTBF, OI, MTPS, MTRS, time to first yield,
average call response time, etc. These are sometimes referred to as operational
performance criteria and some are reportable by SPs to regulatory authorities on a
GB 917 v1.5
Page 38
compulsory regular basis, e.g. time to first yield. Included in this set might be
integrated or consolidated billing for a basket of services, accuracy of billing and
payment terms.
Other aspects of service/technology-independence are billing period, security (of both
service access and information transfer/delivery) and the specification in the SLA of
alternate routing/redundancy of network connections providing the service with
avoidance of Common Points of Failure (CPoFs). For many mission-critical services,
these factors are very important and need consideration. In an ebusiness
environment, they are critical to the survival of the users business, particularly for
large companies and financial institutions. Security of service access and information
transfer/delivery in an ebusiness environment is covered in more detail in Annex A.
A further aspect of network technology-independence is the issue of server reliability
for those services that use computer server farms. One might consider this
technology-dependence of the service offered as opposed to dependence on network
technology supporting the service. It is suggested this issue be treated as a servicespecific parameter.
A new aspect of QoS is the introduction of the acceptability concept and its
determinants. This concept or measure is used to describe the attitude of users to
new technology and new technical applications, e.g. mobile Internet access.
Acceptability can be defined as the ratio of the total number of people in a service
target group and the number of people actually using a service. The new consumer
also wants everything faster and better than before. Customer satisfaction is now
increasingly defined as immediacy rather than QoS.
It should be noted that most of these service/technology-independent parameters are
specified and measured with respect to time. Thus the recording of accurate time of
day when events occur is critical to delivering guaranteed QoS. Doing this across
multiple SPs, NOs and time zones can be difficult and ITU has standardized this time
stamping of events and information exchange in terms of UTC - Universal Recorded
Time. ITU-T Study Group 2 has developed a Recommendation for Network
Management which tracks the time from when a network defect is introduced through
all the stages of reporting the defect, taking actions, etc. to when the physical repair is
made. This is discussed further in section 4.3.
4.1.9 Technology-specific Parameters

Technology-specific QoS parameters are those related to the network technology
supporting the service, particularly where the service offered is a network bearer
service. Examples already quoted are the ATM NP and QoS parameters and the
well-known PDH/SDH physical layer parameters quoted on digital leased circuits. In
addition, technology-specific parameters such as physical characteristics of the SAP
need to be specified. Some of the technology-specific parameters may not be
relevant to a service end user, but need to be considered internally within the SP or
between NOs/SPs. The decision on which parameters to include in a SLA may be an
individual choice for each service contract.
Examples of QoS parameters for each network technology layer follow:
GB 917 v1.5
Page 39
Physical layer: copper/optical cable and terrestrial/satellite radio

parameters of Loss, Crosstalk, Delay, Dispersion, Q-factor.
Note: renting of unbundled copper loop, copper coaxial cable and optical
fiber are now services provided by some NOs. Similarly, renting of
microwave radio transceiver towers and satellite bandwidth are also
services.
xDSL layer: system parameters of Bit Rates (up- and downstream),
Bits/Hz, Reach, Radiation, Crosstalk.
PDH/SDH layer: BBE, ES, SES, SEP, Jitter, Wander, Slip events and
their derived parameters of BBER, ESR, SESR, SEPI; UAS,
Availability, Pk-Pk Jitter, TIE, MTIE.
ATM layer: CE, CL, CM, SESATM, SECB, CD events and their derived
parameters of CER, CLR, CMR, SECBR, CTD, CDV, UAS,
Availability, Throughput, Utilization. Associated with these are traffic
descriptors or traffic profile parameters specified in the service
contract including PCR, SCR, MCR, MBS, PEI and CDVT.
FR layer: lost or corrupted frame events and their derived parameters
of Frame Loss Ratio of committed frames (FLRc), Frame Transfer
Delay (FTD), Availability, Throughput, Utilization. Associated with
these are traffic descriptors or traffic profile parameters specified in
the service contract including PIR, CIR.
IP layer: lost or corrupted packet events and their derived parameters
of IP Packet Loss Ratio (IPLR), IP Packet Transfer Delay (IPTD), IP
Packet Delay Variation (IPDV, sometimes called Packet Jitter),
Availability, Throughput, Utilization.
One of the biggest challenges is mapping the QoS/NP parameters between different
network technology layers and determining their impact on the highest-level service
client in use.
4.1.10 Service-specific Parameters

Service-specific QoS parameters are those typically related to the application carried
by the network and, as mentioned above, service-specific or application-specific
technology parameters such as reliability and availability of computer servers,
databases, etc. As ebusiness expands, computer server parameters will become
increasingly important and impact the overall availability of the service offered.
eBusiness aspects of QoS/SLA management are covered in more detail in Annex A.
Probably the most significant dependability QoS/NP parameter for any service is
Availability. This depends on the combined aspects of the reliability, the
maintainability and the maintenance support performance of an item and refers to
any part of the network or entity supporting the service, whether hardware or
software. Availability performance may typically be expressed by the following
measures (see also the ITU-T Handbook on QoS and NP [ITU-Hbk]):
GB 917 v1.5
Page 40
Measure
Availability
Estimation
Units
Example
Up-times x 100
(%)
99.9%
(%)
0.1%
(hours)
8.76 hrs over

one year
Up-times + Down-times
Unavailability
Down-times x 100
Up-times + Down-times
Mean accumulated down-time

over a given time interval
down-times accumulated over a given time

interval
Figure 4.6: Availability Performance Measures

This definition of availability has been further refined and expanded to take account of
SAP weighting (see [TMF 701]). Examples of service-specific QoS parameters for
some services follow:
Voice telephony: call connectivity and quality measures
ABR/ASR/CCR/CSR/NER; network connection failures and
retainability, Customer Affecting Incidents (CAIs) and Defects Per
Million (DPM); PSTN speech and 3.1 kHz audio loudness (speech
level), attenuation, noise, crosstalk, echo, distortion; ISDN call set-up
failures and delay, propagation delay (including differential delay
between B-channels), G.821 error performance, premature release,
release failure and delay, CLI reliability.
Note: with the increasing use of digital network technology, control and
management of echo has become increasingly important, even for quite
close destinations from a caller. For Voice over IP (VoIP), delay and echo
are two of the major hurdles to overcome.
Data: BER, % EFS, errored PDUs, lost PDUs, UAS, Availability digital
data parameters; loss, attenuation, group delay distortion, noise,
impulse noise analog data parameters.
Facsimile: image quality, character error rate, call cut-off, modem
speed reduction, transaction time and availability.
Mobile telephony: call completion rate, call dropout rate, noise, echo,
distortion and availability.
Sound programme: noise, crosstalk, stereo channel interference,
distortion and availability.
Support & maintenance: service penetration (e.g. telephones per
100 population), supplying service instruction and information, access
to SP (e.g. answering requests, response times), service supply and
removal (e.g. MTPS) and service repair (e.g. MTTR).
GB 917 v1.5
4.2
Page 41
Parameter Degradation
Network and service performance will inevitably vary over time as equipment ages
and external influences take effect. Not least will be the effect of varying traffic levels
in the supporting network. Unforeseen external events such as physical disasters
may have more catastrophic effects. To ensure contracted QoS is sustained, it is not
sufficient just to provide and commit network resources. Monitoring and management
of the QoS parameters quoted in the SLA are also important to retaining Customer
satisfaction and loyalty, and avoiding any SLA violations and penalties. QoS
monitoring is required to detect and locate degradation in QoS performance.
Furthermore, the distribution of QoS along a route needs to be monitored, not simply
the end-to-end QoS although the latter is what is of most interest to the service end
user. This requires monitoring of real-time traffic flows in different network segments.
Detailed description of monitoring methods is outside the scope of this Handbook.
4.2.1 Management of QoS and NP Parameters

An adequate picture of the QoS/NP can only be obtained by defining a set of
parameters (a profile) which should be quantified. A SP may (usually will) use more
stringent values in design, commissioning, operation and maintenance or for
contractual aspects, and setting new targets, than the minimum specified in the SLA.
In practice, QoS/NP management consists of mapping actual values of parameters
against different performance objective values. The latter are specified for
international networks and services by ITU-T Recommendations, notably by Study
Group 13 for network design and Study Group 4 for network operations and
maintenance. In many cases, these Recommendations also allocate the performance
objectives to different portions of the network in such a way that each network
provider is aware of its responsibilities and can assess its required NP and QoS.
Some mix of OSI layers 1, 2 and 3 methods of controlling QoS will be required that
can translate end user QoS requirements into technology-specific QoS/NP
parameters. This must include consideration of QoS distribution and propagation
between carriers forming part of any connection. This is done via allocation of
performance objectives referred to above. Real-time responses are required to
network resource demand fluctuations. Impacts on QoS between user flows on the
same bearers must be avoided. Thus QoS monitoring as well as good network
planning and design are needed. The close coupling between network traffic
engineering and QoS/NP cannot be overemphasized. Depending on the network
technologies employed, a range of QoS management approaches is available.
Detailed discussion of these is really a network management issue and outside the
scope of this Handbook.
4.2.2 Role of In-Service Monitoring

At a network level, continuous In-Service Monitoring (ISM) of NP is preferable for
detecting degradation in performance and its impact on the QoS delivered. This is
increasingly possible using built-in digital signal overhead such as framing bytes,
Error Detection Codes (EDCs) and Performance Report Messages (PRMs). The
GB 917 v1.5
Page 42
objective is to provide pro-active performance monitoring and reporting such that

degradations are discovered early and action taken before SLA guarantees are
breached. Degraded Performance Limit (DPL) and Unacceptable Performance Limit
(UPL) thresholds are set within network elements, and when these are exceeded,
notifications are generated to network management systems. These in turn filter,
correlate, integrate and process the performance events that may result in alarms,
and generate network-level trouble reports and trouble tickets that report serviceaffecting situations. See ITU-T Rec. M.2140 for a comprehensive discussion of these
processes [M.2140]. Further information can also be found in the ITU-T TMN M.3xxxseries Recommendations. Figure 4.7 represents implied relationships between the
engineered level for the NP and other factors related to grades of service.
Performance
Level
Engineered Level
Performance
Sets
Delivered Level
Guaranteed Level
Gold
Silver
Bronze
Grade of Service
Figure 4.7: Performance Levels
4.2.3 Degradation and Customer Trouble Reports

At a service level, the ability to monitor and report QoS parameters to a Customer
and deal with any reported troubles from the Customer is crucial to delivering QoS
guaranteed in the SLA. This is the core of Customer QoS Management within
Customer Care. Correlating Customer trouble reports with network trouble reports to
determine the nature of a trouble and confirm whether a service-affecting fault exists
within the network is all part of the process. Degraded performance can therefore be
considered just as much a fault as complete disconnection or unavailability of a
service.
GB 917 v1.5
Page 43
A further aspect of QoS degradation is the impact of fraud prevention measures, e.g.
cut-off of legitimate traffic. This needs further study.
In the case of multimedia services, ITU-T Study Group 16 has suggested terminals
should provide for an orderly degradation of QoS with priorities such that video, data,
audio and control will be degraded in that order. For example, the multimedia terminal
may reduce the frame rate, packet rate or media bit rate, or even turn off media
considered to be of lesser importance.
4.3
Performance Measures versus User Perception
4.3.1 Measurement and Reporting Intervals

QoS and NP parameters should be measurable or at least calculable (based on
monitoring of events as already discussed). However, it should be realized that
almost all measures are time-dependent and for NP should in principle be considered
as random (stochastic) variables. As such, the performance parameters can only be
estimated.
Three main sources of performance data are network measurements, Customer
interviews and Customer complaints. The user perception of QoS is relevant during
both provision and operation of the service. To cover all aspects of QoS,
measurements should be carried out both at (or as near as possible to) the user
access point and also at each network node. This raises the issues of accuracy,
scalability and cost. Monitoring at the Customer Premises Equipment (CPE) requires
at least one monitor per end point, which is desirable because the monitoring traffic
experiences nearly the same performance as the Customers traffic. However, this is
costly and difficult to scale to large networks, and can result in large amounts of
management traffic to be transported across the network thereby increasing the
congestion and consuming network resources. Furthermore, the SP may not own the
CPE and may not have access to it continuously.
Measurements may be made manually, semi-automatically or fully-automatically
using test calls or live traffic. However, it should be noted that measurements using
test calls normally cannot be truly representative of performance experienced by live
traffic, particularly for packet-based networks and services, and can only give an
estimate of likely performance experienced by the user. Only if the test calls are sent
along a parallel connection that has been established with the same route and QoS
class can the result be significant. This is possible in a permanent virtual connection,
but unlikely in a dynamically switched network. Furthermore, test call monitoring traffic
competes with Customers traffic and therefore increases network congestion and
consumes valuable network resources.
GB 917 v1.5
Page 44
The time line aspect of reporting network incidents affecting QoS can be illustrated
thus:
T0
T1
Defect Customer
Intro
Impact
T2
Detection
T3
NM Action
T4
Referred
T5
T6
Notifications
Started
Customer
Impact
T7
Physical
Repair
T0 - the time that a defect is first introduced in the network regardless of whether or not any Customer
service is impacted.
T1 - the time the first Customer attempt or use is impacted.
T2 - the time that the network problem (defect) is detected by the Network Manager. The detection can be
via a system or verbal, e.g. a Customer trouble report. If the detection is from an OS, the detection time is
the time when the exception occurred, not when first seen.
T3 - the time that a NM control action occurred as a means to minimizing or eliminating the Customer
impact.
T4 - the time the defect was referred to another group (maintenance, provisioning, routing, etc.)
T5 - the time when appropriate notifications started.
T6 - the time Customer impact stopped due to NM control action, restoration or hardware/software repair
made.
T7 - the time physical restoration was completed.
Figure 4.8: Time Line for Reporting Network and Service Incidents
Measurements of these time intervals has been suggested as a way of characterizing
QoS and NP in terms of best in class, world class and average bands.
As noted earlier, many of the QoS parameters are time-related. There are two
aspects to this - the sampling or measurement period over which each parameter is
calculated, and the reporting interval over which the parameters are averaged and
reported. The sampling period may be every second, every minute, every 15 minutes
or every 24 hours for example. The reporting period is typically one month. Thus,
real-time QoS parameters are typically measured over the sampling period, stored in
a database and reported as historical data every month. The choice of Customer
reporting interface implementation will be influenced by a number of factors, including
the contracted reporting interval.
4.3.2 Reporting Methods

Service end users want clear and concise information about QoS that is primarily
technology-independent, predictable, measurable, accurate, easy-to-understand and
applicable. QoS/SLA reporting is covered in more detail in NMF 503 and TMF 701,
including both normal and exception reporting, and both externally to the Customer
and internally within a SP. These documents also cover reporting methods such as
web-based user interfaces, which is one specific technology implementation of a
Customer interface - there are others, for example, report repositories that a
Customer can access on demand. Flexibility in performance reporting of key
QoS/SLA parameters is likely to increase with the use of enabling technologies such
as Wireless Application Protocol (WAP). These are the kinds of tools the Customer
might have in order to check whether they are receiving the kind of service quality for
which they contracted.
GB 917 v1.5
Page 45
4.3.3 User Perception

Measurement of QoS by a SP at the network level may not be the same as user
perception of QoS. This leads to the question is QoS relative or absolute? and
comparisons might be made, for example, between data over a WAN and over a
LAN, voice over an IP-based network and over PSTN, and video over a telecom
network versus broadcast TV.
For voice services, checking user perception may involve specifying and measuring
QoS performance both objectively, using measuring devices, and subjectively using
people. Objective measurement often involves In-service Non-intrusive Measuring
Devices (INMDs) that measure call clarity, noise and echo. Analysis and
interpretation of the results obtained is also specified. Subjective measurements often
use standardized signal generators and human listeners from which Mean Opinion
Scores (MOSs) are derived.
However, to date the main QoS parameters quoted in a SLA or contract for voice
services are availability of the service, ability to make calls (dial tone) and accuracy of
billing. There have been no guarantees as such on call completions or levels of noise,
echo, delay and distortion, but the network has been engineered to deliver acceptable
QoS in most cases. By keeping toll circuit delay below 100ms, using echo cancellers
and maintaining low error ratios on digital connections, voice telephony QoS is
normally not an issue. Another network control used is the measure of Customer
Affecting Incidents in terms of Blocking Defects Per Million mentioned earlier.
However, it is remarkable how such poor QoS is tolerated by Customers on mobile
services including lost calls/call dropouts, blocking, and high levels of noise, echo,
delay and distortion!
For data services, new users often do not understand error conditions and perfection
is expected. Higher level protocols have made LANs appear flawless and better
physical layer network transport makes this almost true. Experienced users expect
WANs to behave like LANs. User expectations on response times to query/request
type messages escalate as technology improves.
Other real-time services such as video (MPEG and broadcast TV), sound programme
and CD music are much more demanding. For IP-based networks, a given level of IP
transport QoS results in a level of user-perceived audio/video QoS that is a function in
part of the effectiveness of the methods used to overcome transport QoS problems.
Bit errors on a packet-based network generally are either corrected at a lower layer,
or result in packet loss. Packet loss requires the receiver to be able to compensate for
lost packets in a fashion that conceals errors to the maximum possible extent. For
data and control, retransmission at the transport layer is used. For audio and video,
retransmission approaches need further study.
In an IP-based network, QoS and traffic engineering (capacity management) will be
even more closely related than in a traditional circuit-switched network. Thus traffic
engineering measures are critical to managing and maintaining QoS in conformance
with the SLA.
GB 917 v1.5
Page 46
Again, the issue of devices attached to the network, or people such as Customer
Care representatives, involved in delivering the service have a big impact on user
perception of QoS. The number of firewalls or router nodes used in delivering IPbased services should be taken into account, and whether their traffic handling
capacity is adequate for delivering the QoS offered.
Increasingly in the future, QoS at acceptable cost will be the differentiating factor
between SPs in a competitive service provision environment.
4.3.4 Aggregation of Parameters and QoS Index

In order to simplify specification and reporting of QoS parameters, it may be desirable
to aggregate a number of parameters into some kind of QoS Index (figure of merit)
over the reporting period. Trying to relate technology-independent and technologyspecific QoS/SLA parameters might be considered delving too deep down into the
Telecom Operations Map [GB 910]. Nevertheless, finding some way of aggregating
performance parameters into a simpler QoS Index could give a SP a competitive
advantage as well as being simpler for Customers to understand.
The Quality of Service Development Group (QSDG) have started considering an
Objective Quality Score (OQS) in order to enable end-to-end quality control
mechanisms to be implemented over converged networks. This proposes a rating
system providing an independent score index based on the industry standard test
parameters, and results in rating variations from the industry median score. In this
format, a carrier may score above or below the median and receive AAA to CCC
rating from an independent rating service. This approach merits further study.
4.3.5 Customer Satisfaction

QoS is not equivalent to the users perception of a given service. According to ITU-T
Recommendation E.800, QoS is the profile (more or less complete) of the numerous
values of the QoS measures, including both administrative- and network-related
measures [E.800]. The well known Pareto 80/20 rule often applies - 80% of the
problems can be identified from 20% of the measures. For example, 80% of
Customer complaints might refer to a small number of parameters such as too long a
delay for new installations, agreed time to repair and restore service not met, poor
support information and service, high congestion in the busy hour, etc. One challenge
is to identify Customer-sensitive measures and particularly the values that satisfy
the Customer, which may vary from one target group (market segment) to another.
The QSDG has been studying Customer satisfaction for some time. The usual
method of measuring Customer satisfaction is using a survey, the value of which is
naturally subject to the type of questions asked, and the quality of the data obtained
from them. A full survey covers many aspects of the telecommunication business
such as Pre-sales, Post-sales, Development, QoS/NP, Fraud and Security, etc. In
constructing and managing SLAs, some means of measuring Customer satisfaction
should be implemented. Cultural issues and human factors need to be taken into
account. The Customer satisfaction/perception with/of a given service or selected
parameters can be assessed, for example, by the Mean Opinion Score (MOS) rating
method in terms of bad 1, poor 2, fair 3, good 4, excellent 5.
GB 917 v1.5
Page 47
Further information on measuring Customer satisfaction is available in the ITU-T

Handbook on Quality of Service and Network Performance [ITU-Hbk].
4.4
Violations and Remedies

Depending on the terms of the SLA/Contract, QoS violations may result in a variety of
actions, including compensation, future discounts, rebates, alternate service routing,
etc. However, Customers do not really want refunds via SLAs, they want quality
assurance of the services provided. Nevertheless, in a commercially competitive
service provision environment, Customers will expect rebates if provided for in the
contract. The conditions under which these occur are a commercial issue between
SP and Customer. Note that a QoS violation may be Customer-induced, e.g. a
violation of contracted traffic profile parameters, which in turn may result in action
favoring the SP.
SLA monitoring and management should therefore include setting limits (see section
4.2.2) warning the SP that violations of contracted performance could occur unless
remedial actions are taken. The level at which these are set depends on individual
NO/SP network and traffic engineering management strategy. Some operators
choose to over-provision network resources and accept under-utilization to avoid
congestion. Others choose to operate the network close to capacity limits and
therefore need to implement ISM with limits set appropriately.
GB 917 v1.5
Page 48
GB 917 v1.5
Page 49
Chapter 5 SLA Life Cycle
5.1
Life Cycle Automation

Management of SLAs/QoS requires interaction between many of the TOM processes
[GB 910]. In order to analyze the interactions and individual requirements more
thoroughly, various stages or phases must be considered separately first. This life
cycle of a SLA is analyzed in the five phases as shown in Figure 5.1. After the phases
are introduced, a set of use cases and the flow-through of the TOM processes are
presented. These use cases are not intended to be prescriptive but are provided to
illustrate one approach to the process flows involved in SLA management.
The five phases used to analyze SLA Management are:
Product/Service Development
Negotiation and Sales
Implementation
Execution
Im
Develop Templates
and Parametric
Boundaries
Negotiate
Individual
Contracts
em
l
p
n
io
t
ta
en
Take Line/Service
Orders and Provision
Ex
ec
ut
io
n
Pr
D od
ev uc
el t/S
op e
m rv
e n ic
t e
N
eg
ot
ia
tio
n
an
d
Sa
l
es
Assessment
Monitor,
Surveillance,
Maintain, Bill
ss
s
es
en
Reassess
Figure 5.1: Service and Associated SLA Life Cycle
GB 917 v1.5
Page 50
5.1.1 Product/Service Development

The Product/Service Development process can be started by several events. Both
internal and external triggers may show a SP that it is time to develop another SLA;
market demand, competitive pressures (not always the same as market demand),
internal indications of service conditions, extreme experiences with current SLAs. The
phase of SLA service development covers:
Identification of Customer needs
Identification of appropriate service characteristics
What parameters?
What levels of service?
What values?
Identification of network capabilities
Preparation of standard SLA templates
Each service description identifies the relevant SLA parameters and indicates
whether SLA parameter values can be selected individually or in a bundled fashion.
A discussion of potential SLA and QoS parameters can be found in chapter 4.
Exit Criteria: New service(s) with SLA Templates.
5.1.2 Negotiation and Sales

Negotiation and Sales is the phase where a Customer subscribes to a service
offering, with or without modifications. The model presented here assumes that the
Customer is contracting for many potential service instances for installation and
delivery over time (contract period). In general, the process will be approximately the
same for individual instance sales where a SLA is involved, since a SLA is a contract
which has several responsibilities that must be spelled out during the negotiation
phase. The phase includes:
Selection of the values of SLA parameters applicable to a specific
service instance
The costs incurred by the Customer when signing the SLA
The costs incurred by the SP when a SLA violation occurs
Definition of reports associated with service (note that the time when a
report may be generated is dependent on the periods related to the
relevant SLA parameters, e.g. availability over a unit of time, such as
one day, week, month, quarter, year)
Exit Criteria: Signed Contract.
GB 917 v1.5
Page 51
5.1.3 Implementation
Service implementation is the phase where the service is enabled and the individual
Customer instance is put into production. Each of these activities will be executed
slightly differently in each company implementing SLAs, but the overall requirements
will be the same. For this analysis, the implementation phase is considered to include
network provisioning, which may be placed into another phase by some companies.
This phase will always include the order and instantiation of the individual Customer
service per the contract. There are three aspects to service implementation:
Configuration of the network to support the service in general
(network provisioning)
Configuration of the network to enable a specific instance of a service
according to the SLA for a Customer (service configuration)
Service activation
Exit Criteria: Instantiated, Tested, and Accepted service instance.
5.1.4 Execution
The Execution phase covers all normal operations of the services covered by the
SLA.
Normal in-service execution and monitoring
Real-time reporting and service quality validation
Real-time SLA violation handling
5.1.5 Assessment
Assessment takes place in two time frames. The first is scheduled during a single
Customer SLA contract period where the assessment is related to the Customer's
QoS. The second time frame is related to the SPs overall quality goals, objectives
and risk management. These two assessment and review activities have differing
uses within the SP.
Customer Periodic Review
Quality of Customer Service
Satisfaction of Customer with Service Quality
Improvement Potential
Changing Customer Requirements

Internal Business Review
Overall Service Quality across all Customers
Realignment of Service Goals
Realignment of Service Operations
Identification of Service Support Problems
Creation of different SLA levels
GB 917 v1.5
Page 52
5.2
Use Cases and Scenarios

The following use cases start the analysis of data flows and process actions required
to support the above SLA life cycles. By looking at each phase of the life cycle, the
detailed ramifications of SLA management on the baseline TOM processes can be
evaluated. The inputs and outputs listed below are selected based on their relevance
to SLA/QoS management and do not repeat flows that would be covered as a nonSLA related service. TOM processes participate in more than one life cycle phase.
The use cases which follow are provided to relate the life cycle phases above to the
TOM processes which support SLA management [GB 910]. The desired list of use
cases is:
Product/Service development with a new SLA
New SLA against existing service
New service with SLA

Negotiation of SLA Contract
Sell individual service instance with associated SLA
Basic Service Execution
Steady state, no problems
Steady state, degraded performance, no SLA violation
Steady state, SP detected SLA violation
Steady state, Customer reported problem no SLA violation
Steady state, Customer reported problem SLA violation

Periodic Customer assessment
Periodic business assessment
GB 917 v1.5
Page 53
5.2.1 Product/Service Development with a New SLA
Customer Interface Management

1
Sales
Order
Service
Planning
Develop
Service
Config
6
4
Problem Customer Invoicing

QoS
Mgmt
Handling
Collections
Service
Problem
Resolve
Service
Quality
Mgmt
Network Network Network Network

Planning Inventory Provision
Maint
Develop
Mgmt
Restore
Rating
Discount
Network
Data
Mgmt
Figure 5.2: Creation Portion of Service Development

In Figure 5.2, the information flow of the first part of the creation of a service is
depicted.
1. Customer requirements are gathered either over time or as a result of a
Customer RFP. These requirements are for services with SLAs that do not
currently exist, either no service at all, a service with no SLA offered, or Customer
SLA needs that exceed the current SLA parameter definitions. This information
flow includes the service description for the base service (SAP, SAP technology,
access technology, speeds, overall circuit parameters (e.g. CIR), etc) and the
QoS parameters required by the Customer (see chapter 4).
SALES: would take the disparate requests from separate customers, examine the
current catalogue of services for close matches, estimate the business potential for
new Customers, additional revenue from existing Customers, plus the value of
retained revenue, and pass the requests to service planning and development. Part
of this function is sometimes performed in a group termed Product Line Management
or Marketing.
2. The Customer requirements combined with the potential market value for this
new service and the estimated service lifetime is passed to Service Planning and
Development.
SP&D: splits the requirements into operations-specific requirements and
network/technology requirements. (Service) Architectural alternatives for providing the
new service are weighed and the operations impacts of the different architectures are
balanced against the different potential impacts of changing service needs (emerging
technologies that could drive Customer demand in a different direction, e.g. VoIP, or
GB 917 v1.5
Page 54
Soft Switch). This results in preferences or priorities being placed on the underlying
technology requested from the network. These requests are then sent to the Network
Planning and Development process block. The order of flows 3 and 5 can be parallel.
3. Detailed network requirements are forwarded to the Network Planning and
Development process block to obtain network costs (capital and expense), and
the time frame that would be required to implement the new service with the
technical SLAs as specified. This flow indicates all the technical parameters
(service-specific and technology-specific) needed for the SLA support, including
technology preferences (not hard and fast rules), performance parameters,
geographic requirements (potentially including phasing), and time frame
requirements.
NP&D: analyzes the new service requirements against its existing network inventory
and operations support structure including both network and operations capacity and
geographic coverage. During this analysis NP&D examines the current network
experience for performance and reliability, and formulates a cost to upgrade the
network, field operations, and support systems to provide the new service, including a
realistic time frame. NP&D may need to flow data to all other network layer process
blocks to arrive at the estimate. It may also need to issue RFI/Ps to get new
equipment costs.
4. Cost (expense and capital) and time estimates are returned to SP&D. These may
include specific technology recommendations if during the NP&D investigation it
was determined that one technology was not mature enough to support the QoS
or Service Availability requested.
5. Optional: Query to SQM to obtain current network quality figures for intended
infrastructure and geography. May request Customer QoS reports if responding
to RFP or periodic Customer review.
SQM: processes the required information for delivery back to SP&D.
6. Response to query.
SP&D: evaluates feasibility of service based on cost and revenue projections, and
network technology availability. If feasible, it creates service descriptions and SLA
templates.
Phase continues on Figure 5.3.
GB 917 v1.5
Page 55

8
Sales
Order
Service
Planning
Develop
Service
Config

QoS
Handling
Collections
Mgmt
9
10
11
12
Service
Problem
Resolve
Service
Quality
Mgmt
Network Network Network

Develop
Mgmt
Network
Maint
Restore
Rating
Discount
Network
Data
Mgmt
Figure 5.3: Internal Notice Portion of Service Development Phase

SP&D: analyzes all returned data and determines the possible SLAs that will meet
the company's risk model.
7.
SP&D returns the permissible SLA parameters with values to Sales (PLM)
with ranges of values, required financial returns necessary to cover risks, geographic
restrictions, and lead time before the SLAs may be offered.
8,9,10,11,12. Notices of new service parameters go to most of the rest of the
organization for inclusion into standard business practices.

Figure 5.4 depicts the data flow during the Negotiation and Sales phase of a SLA
service. The end of this phase is a signed SLA with both Customer and SP knowing
exactly what is expected of each other, what is covered and when, and what recourse
is available.
GB 917 v1.5
Page 56

1
Sales
Order
2
4
5
6
3
Service
Planning
Develop
Service
Config

QoS
Handling
Collections
Mgmt
Service
Problem
Resolve
Service
Quality
Mgmt

Maint
Develop
Mgmt
Restore
Rating
Discount
Network
Data
Mgmt
Figure 5.4: The Negotiation and Sales Phase of SLA Management

1. Customer inquiry for service contract including SLAs.
2. Service and SLA details.
3. Network inventory reservation details commensurate with SLA details requested.
4. Inventory and service details back to ordering/contracting office based on
feedback received from network inventory reservation request.
5. Network and SLA details to SQM to initialize monitoring all aspects.
6. Rate rebate SLA information to set up Customer rate rebate details in preparation
for individual sales on contract.
7. Initialization details for Customers QoS and SLA parameters.
8. Signed and ready for individual sales SLA.
During implementation, a Customers individual order is taken from Customer request
to working accepted instance (see Figure 5.5). During this time frame, the network is
specifically built out to allow for the individual Customer request, the individual
components are put into service and activated. Any testing for Quality purposes is
conducted, and the Customer is notified that the service is turned up, with some form
of (positive) response from the Customer reflecting acceptance of the service
instance.
GB 917 v1.5
Page 57

1
Sales
Order
Service
Planning
Develop
3
4
Service
Config

QoS
Handling
Mgmt
Collections
Service
Problem
Resolve
Service
Quality
Mgmt

Maint
Develop
Mgmt
Restore
7
6
Rating
Discount
Network
Data
Mgmt
Figure 5.5: Implementation Flow of SLA Instantiation

1. An order against an existing contract with SLAs. This order can be by phone, fax,
or via an E-Bonding arrangement.
2. Order enters the service configuration process. This may be automatically
through a direct customer web interface, or through other electronic ordering
channels (i.e. this and step 1 may be the same step).
3. The order, along with the SLA parameters, enters provisioning, starting the
applicable installation and provisioning timers.
4. The additional facilities are entered into the database for data acquisition and
retention.
5,6,7. Order details conditioning the appropriate processes to include the newly
ordered service for later SLA processing.
8. Confirmation of successfully ordered and hopefully tested service.
9. Response to Customer. May be electronic from same systems used in 8.
5.2.4 Normal Execution

Also known as steady state, normal execution is the phase where the Customer
receives service on all the contracted and instantiated service instances. This section
analyzes the situation where although service outages occur, no outage exceeds
either the individual or aggregated parameters set in the SLA.
GB 917 v1.5
Page 58

4
Sales
Order

QoS
Handling
Mgmt Collections
Service
Planning
Develop
Service
Config
Service
Problem
Resolve
Service
Quality
Mgmt
Rating
Discount
3a

Maint
Develop
Mgmt
Restore
2
1
Network
Data
Mgmt
1a
Figure 5.6: Normal Execution of SLA Service

1. Notifications and Performance Data
infrastructure. These are in the form of:
arrive
from
the
service-providing
Alarms that represent the failure of a component that affects the service
of one or more Customers.
Threshold Crossing Alerts that represent congestion or performance

degradation in a congestable resource that forces slowed or diminished
capacity to perform Customer services.
Performance data from various service components that is used for

general monitoring of service levels, as well as longer-term prediction of
required resource upgrades.
2. In the case of Alarms, the network undertakes restoration procedures, including

reporting the outage to the Service Problem Resolution process, indicating the
time and potential duration of the outage to allow Service Problem Resolution to
determine potential alternate actions.
3. Both positive and negative data is then fed to the Service Quality Management
Process for QoS calculations and averaging to maintain statistical data on the
supplied service.
4. Individual Service interruption data is sent to the Customer QoS Management
process for tallying against individual Customer's SLA contracts.
5. Overall Service Quality data is sent to the Customer QoS Management to monitor
and report aggregate technology and service performance.
GB 917 v1.5
Page 59
6. Periodic Service Performance reports are sent to the Customer on either a

requested or agreed basis.
5.2.5 Execution with SLA Violation

From time to time, service conditions will exceed the parameters specified in the SLA.
At least two cases need to be examined, one where the SP detects the outage first,
and one where the Customer detects and reports it first. The second case is depicted
in Figure 5.7.
10

1
Sales
Order

QoS
Mgmt
Handling
Collections
Service
Problem
Resolve
Service
Quality
Mgmt
Network Network Network

Develop
Mgmt
Network
Maint
Restore
Service
Planning
Develop
Service
Config
Rating
11
9
Discount
Network
Data
Mgmt
Figure 5.7: Customer Detected SLA Violation

1. In this instance, the Customer perceives service degradation and reports the
visible parameters to the Problem Handling process.
2. These are checked against the Customer's SLA to determine potential priorities
or other actions dependent on the type of Customer contract.
3. The entire problem with contract commitment data is given to the Service
Problem Restoration process for normal flow handling.
4. In some cases, Service Problem Resolution will require changes to be made to
the underlying infrastructure per contractual agreements. This requirement will be
sent to the Network Maintenance and Restoration process for activation. In other
cases, the data will be simply reported to Service Quality Management process
for incorporation into ongoing Customer and service quality monitoring and
management.
GB 917 v1.5
Page 60
5. Where infrastructure changes were required to resolve the Customer's problem,

the results of the changes as well as the time taken and all other infrastructure
and operational parameters are reported to the Network Data Management
process for normal reporting and tracking purposes.
6. Infrastructure data from any corrections is forwarded to the Service Quality
Management process as a result of the impact of the negative infrastructure
activities.
7. Since the implication of the scenario initialization was that the Customer detected
a SLA violation from some infrastructure outage, the Service Quality
Management process should detect this and report it to the Customer QoS
Management process, assuming that there was actually a SLA violation.
8. Assuming that a SLA violation was detected, Customer QoS Management would
report the violation to the Rating and Discounting process for billing adjustment.
9. This discount is reported to the Invoicing process for normal monthly billing
inclusion (or whatever the SLA had specified).
10. The Customer is notified in semi real-time about the actions taken on their behalf.
11. The normal bill comes at the end of the billing cycle with the SLA agreed
treatment included.
5.2.6 Assessment
During the assessment phase, SLAs are examined to determine if they still fit the
business needs. There are several triggers for the assessment, including periodic
either per service or overall, Customer triggered reevaluation, Customer exit, etc.
GB 917 v1.5
Page 61

Sales
1a
Service
Planning
Develop
Order
Service
Config

QoS
Handling
Collections
Mgmt
Service
Problem
Resolve
Service
Quality
Mgmt

Maint
Develop
Mgmt
Restore
Rating
Discount
1c
1b
Network
Data
Mgmt
Figure 5.8 Assessment Initiation Flows

1. Requests to reassess the parameters of SLAs are sent to the Service Planning
and Development process. These can originate from:
1a. The Customer with needs to change the parameters because their business
needs have changed,
1b. Service Quality Management because the service being provided is not
meeting the required levels on an average basis,
1c. Customer QoS Management because given SLAs are not being supported
and require excessive rebates.
With minor differences, these inputs are taken and factored back into the same
process and flows as in Service Development, this time with sharpened data and
objectives.
GB 917 v1.5
Page 62
GB 917 v1.5
Page 63
Chapter 6 SLA Management

Framework
This chapter describes a set of potential functions that can be used to provide
process automation to aspects of the SLA Management life cycle.
6.1
SLA Management Functions

As previously discussed in chapter 5, the SLA Management process life cycle covers
five phases: Product/Service Development, Negotiation and Sales, Implementation,
Execution, and Assessment. Figure 6.1 positions the SLA-related functions over the
Telecom Operations Map, aligned with the phases of the life cycle [GB 910].
Customer
SLA & QoS
Reporting
SLA
Negotiation
SLA
Order
Handling
Sales
Problem
Handling
Order
SLA
Planning &
Development
Service Planning
& Development
SLA
Service
Configuration
Service
Configuration
Customer QoS
Invoicing and
Collections
SLA Management
Proactive
Monitoring
QoS
Analysis
& Reporting
Service Problem
Resolution
SLA
Rating &
Discounting
Service
Service Quality
Rating and
Performance
Management
Discounting
Data
Warehousing
Network
Planning
& Development
Network
Inventory
Management
Network
Provisioning
Product & Service

Development
Implementation
Negotiation & Sales
Execution & Assessment
Network
Maintenance
& Restoration
Application
& Server
Performance
Data Collection
Process
Performance
Data Collection
Network Data
Technology
Performance
Management
Data Collection
Data Collection & Aggregation

(out of scope of current Handbook work)
Figure 6.1: Potential SLA Management Functions
6.1.1 Product/Service Development

Product/Service Development functions support service planning and development
activities in forecasting, defining, and constructing a catalogue of available service
products. Service products are created in terms of functionality, characteristics and
the related SLA templates.
GB 917 v1.5
Page 64
Application support for Product/Service Development helps the SP to determine what

service to offer, what classes of service to offer, what parameters to measure for each
class of service and what standard parameter values to guarantee for each class of
service. It is also important to identify the impacts of the introduction of a new service
on the operation of existing services.

The catalogue of service products is then used during the Negotiation and Sales
process to negotiate service options, classes of service and potentially the values of
SLA parameters with the Customer. The scope for negotiation may depend on the
service on offer and the type of Customer. For example, a SP may offer only predefined service levels to residential or SOHO Customers, but may allow custom
negotiation with large corporate Customers.
During sales and ordering the SP captures the Customer-specific information for a
particular service offering and verifies the orders feasibility. This requires the
verification of available network resources and the capability to meet and assure the
requested level of service.
Once an order has been confirmed, the SP needs to design the instance of the
requested services and request or reserve the required capacity in the network. This
may involve deployment of new network and/or service resources, or just the
configuration of existing equipment. These network resources need to be configured
to support the required levels of service quality specified in the SLA.
6.1.4 Execution and Assessment

The Network Data Management process is supported by a number of functions, each
one collecting different types of raw performance data from different sources. For
example, Network Performance Data Collection collects raw network performance
data from network elements and network element management systems. Process
Performance Data Collection collects raw operational process performance data from
systems such as Trouble Ticketing and Provisioning. Application & Server
Performance Data Collection collects raw service performance data from other
applications (e.g. email, web servers and DNS).
GB 917 v1.5
Page 65
Customer
SLA & QoS
Reporting
Customer/SLA
Layer
SLA
Proactive
Monitoring
QoS
Analysis
& Reporting
Service
Layer
Service
Performance
Data
Aggregation
Data
Collection
Layer
Network
Performance
Data Collection
E.g. ATM, FR, IP
& Server
Application
& Server
Performance
Data Collection
E.g. Web Server, DNS
Process
Performance
Data Collection
E.g. Trouble Ticketing,

Service Provisioning
Data Collection & Aggregation

(out of scope of current Handbook work)
Figure 6.2: SLA Performance Data Collection

As shown in Figure 6.2, raw process data and service configuration details related to
operational process parameters are aggregated to provide service level quality
metrics from the technology, service and process performance data. QoS Analysis &
Reporting and SLA Proactive Monitoring use the service performance data to
correlate service performance against set operating targets and SLA guarantees.
The Customer SLA Reporting function correlates QoS data with Customer service
descriptive data and SLA thresholds in order to produce SLA reports detailing offered
services and service quality achieved.
6.2
SLA / QoS Data Management

The challenge to providing truly integrated SLA Management is the effective
management of all the related Service and Customer data. SLA Management
functions need to combine, correlate, assess, and manage a wide variety of data
sources to effectively manage the fulfillment and assurance of SLAs. There is a need
to draw on many data sources within a SPs Operations Support System (OSS)
environment, such as information on Customers, services, and service performance
(as shown in Figure 6.3).
GB 917 v1.5
Page 66
Customer
Details
Service
Instances
Customer SLA
Performance Data
SLA Reports
SLA
Contracts
Service QoS &
Performance Data
Service
Descriptions
QoS Reports
SLA
Templates
Raw
Performance
Data
Implementation
Product & Service

Development
Negotiation & Sales
Figure 6.3: SLA/QoS Related Data
GB 917 v1.5
Page 67
Chapter 7 SLA Modeling and

Guidelines
7.1
Introduction
Much as the SLA management processes are an integral part of a SPs total service
management solution, so too is the actual SLA an integral part of the service
providers product offerings - depicting exact details of the service construct, quality
expectations, and delivery. This chapter introduces the major components and
relationships that comprise a SLA between a SP and a Customer. The goal of this
chapter is to:
Help SPs and Customers identify the components comprising SLAs
and the role of these components within a SP service offering to
Customers.
Identify different aspects of SLAs at each link within the supply chain.
Help SPs find a mapping scheme between SLAs and QoS
parameters.
Provide inputs for evaluating impacts and requirements in different
operational process areas when a new service offering and SLA is
designed.
SLAs may be defined between organizations within a SP domain. This includes
allocating performance objectives for different portions of the network connection in
connecting SP domains. Intuitively the same approach used here to model Customer
SLAs can be applied to internal SLAs.
This chapter is not prescriptive for SPs when defining contracts and SLAs. Rather it
presents a conceptual model to analyze the different roles, types of SPs and
Customers, and types of services. It is not always easy to map a Customers quality
expectations into the SPs terms. It is outside the scope of this chapter to identify
criteria and guidelines to perform this mapping.
7.2
Role of SLAs within Service Products

A SP maintains a portfolio of products and services available for Customers to order.
This product portfolio consists of a number of commercial offers. A commercial offer
GB 917 v1.5
Page 68
represents a service package offered by the SP to the Customer and could be a

single service (e.g. an ATM PVC) or a service bundle (e.g. an xDSL access with
email and web hosting). The SP may package different service bundles to meet
different Customer requirements (Figure 7.1).
may purchase
0..*
Product Bundle
0..*
Customer
2..*
0..*
may purchase
0..*
Commercial Offer
0..*
0..*
1..*
1..*
composed of
SLA Template
1..*
Service Element
1
composed of
0..*
Service Level
Objective
1..*
Service Resource
Figure 7.1: Service Composition

The commercial offers available to the Customer are composed of a number of
supporting service capabilities, or service elements. Each service element may be
associated with a class or grade of service (e.g. Gold, Silver) as defined by a set of
standard SLAs, or SLA templates.
A service element typically models technology-specific capabilities (e.g. an ATM
bearer service, IP connectivity, xDSL connectivity) or operational capabilities (e.g.
help desk support) and represents the individual features typically visible to
Customers (although actual visibility to the Customer depends on the SPs policy and
on the nature of the service). The capabilities of any service element are provided
by the capabilities of one or more other service elements, or at the lowest level, one
or more physical service resources.
Service resources are the base level building blocks for composing the basic service
elements and are usually not visible to the Customer. The service resources are the
key elements over which the SP has control to manage the levels of service offered
and measure the levels of service achieved. A service decomposition example is
described later around Figure 7.3.
An actual instance of a SLA is the specific definition of the required quality for a
specific service instance, or set of instances, of a commercial offer for a single
GB 917 v1.5
Page 69
Customer. At the heart of the relationship between the Customer and the Service
Provider for the provision of a service instance is the service contract10 (Figure 7.2).
relates to
Customer
Commercial Offer
defines service
level objectives for
1
1..*
0..*
instantiates 1
agrees to 1..*
1..*
Service Contract
1..*
Service
Instance
covers
1
agrees to 1..*
SLA Template
0..*
0..*
references
1..*
Service Provider
contains
0..*
Service Level
Agreement
Figure 7.2: Relationship between the SLA and Service Instances

Figure 7.3 depicts a service composition example for an IP Access service with email
and web hosting. The underlying service capabilities are supported by a number of
service resources, such as the access network and application servers. The
combination of these service resources provides the basic service elements from
which commercial offers can be composed. The SLA templates represent pre-defined
differentiated levels of service that define the service level objectives for a service
element and are used to build the definition of a commercial offer.
cia
er
m
m
Co fers
Of
s
A late
SL mp
Te
Residential Basic
Internet
Basic
Email
ice s
rv nt
Se eme
El
ice es
rv rc
Se sou
Re
Premium
Email
SOHO Basic
Internet
Residential
Access
Email
Service
Email
Server
SOHO PRO
Internet
SOHO
Access
SOHO PRO
Access
Web Hosting
Silver
IP Access
Service
Authentication
Server
DHCP
Server
Access
Device
Web Hosting
Gold
Web Hosting
Service
Network
Elements
Web
Server
Figure 7.3: Service Composition Example
10
The actual relationship between the service contract and the SLA can be SP-specific, for instance the SLA can be
considered part of the contract, or the SLA can be considered to be the contract.
GB 917 v1.5
Page 70
7.2.1 Defining the Level of Service

The role of the SLA template is to capture a set of service level objectives for a
service along with details of consequences for not meeting the specified objectives,
and potentially any exclusion conditions, as shown in Figure 7.4. The service level
objective is the representation of the guaranteed level of service offered in the SLA,
as previously described in Chapter 4, Figure 4.7, which defines individual objectives
for a service in terms of the service metric, threshold values, and tolerances. A
service level objective could be related to the entire service bundle, to a service
element, or to a single SAP, but it is always connected to something visible to the
Customer.
Commercial Offer
1
defines service
0..*
Service Level
Agreement
0..*
1..*
references
SLA Template
1
defines
1..*
Service Level
Objective
0..*
1..*
applies to
defines
applies to
1
1..*
Consequence
defines
0..*
Exclusion
1
0..*
SLA Parameter
Figure 7.4: Components of a SLA Template

The production of a SLA template is an intrinsic part of service development. These
SLA templates relate to standard product/service offerings and contain default
values specified during the product/service development phase.
Once a Customer purchases an instance of a service, the template is used as the
blueprint to form the actual SLA as part of the service contract between the Customer
and the SP. As discussed previously in this Handbook, there may also be scope for
custom negotiation of the SLA terms between the Customer and the SP, depending
on the type of service offered. In this situation, the SLA Template provides a baseline
for negotiation.
SLA templates effectively form part of the SPs product catalogue. For the Customer
the choice of SLA level may be explicit in the service order, or may be implicit in the
commercial offer or product bundle description (e.g. a VIP bundle which combines a
set of gold level services).
GB 917 v1.5
Page 71
For many kinds of service element, the Customer could order multiple instances
(such as five ATM PVCs). In these cases, the SLA template may take into account
this multiplicity providing both SLA parameters for individual instances and for the
group of instances as a whole. For example, a SLA template related to a service
offering which includes a PDH access to a backbone network with a set of PVCs
crossing that network, could include parameters with threshold values set for each
PVC (e.g. Cell Loss Ratio on a single PVC in one direction) and also general
parameters calculated on the group of PVCs (e.g. Maximum Cell Loss Ratio for all
the PVCs).
7.2.2 Multiple Domain SLAs

As previously discussed, a service element could depend on another service element
to provide an underlying service capability. For example, there are dependencies
between an IP connectivity service and an access service to an ISP gateway, and
between a mailbox service and an IP connectivity service. Therefore, the service
offering provided to the Customer could be built as a bundle of services with or
without mutual relationships. In these cases, the SLA template should take into
account dependencies between services because SLA parameters are impacted by
these relationships (e.g. availability of an IP connectivity service depends on the
availability of the access service). In addition, dependencies between services could
extend beyond the boundary of a single contract.
A service element might depend on other service elements in different service
offerings from the same SP. Dependencies could span multiple SP domains (or
different organizations within the same SP, as in the case of internal SLAs), this is
illustrated in the example of Figure 7.5. In the provision of the ISP service to the
Customer, Service 1, there are a number of sub-domain services, Services 2-6, that
build up the end-to-end service delivery, each potentially being subject to a SLA.
End-to-end Service
Customer
Internet
Service
Provider
Service 1
Service 2
Service 3
Access
Provider
Service 6
Service 5
Service 4
Network
Service
Provider
Network
Service
Provider
Figure 7.5: End-to-end Service Delivery across Multiple Service Domains

Where services cross multiple SPs, the significance of ensuring consistency of SLA
parameters and their values in all the supporting SLAs must be considered.
There could be (at least) two different types of SLA between SPs (or internal SLAs).
In the simple case there is a straightforward relationship between capabilities of the
GB 917 v1.5
Page 72
supplied service to the requirements of the consuming service with a one-to-one

mapping between the service instance and the Customer, as shown in Figure 7.6.
Here SP1 can make a direct correlation between the Customer SLAs a,b,c and the
SP2 SLAs 1,2,3.
End-to-end Service
SLAa
SLA1
SLAb
Service
Provider 2
SLA2
Service
Provider 1
SLA3
SLAc
Customers
Figure 7.6: Multiple Domain SLA Relationships Example 1

The second type of SLA, depicted in Figure 7.7, could be needed when SP2 cannot
provide service to SP1 at the same granularity as SP1 provides to the end Customer.
In this case, which happens for example when a predefined capacity within a
backbone network is set up during network creation by SP2 for SP1s Customers,
there is no direct correlation between SLAs a,b,c and SLA4. In particular, SLA4 could
not be based on parameters related to a single customer service, but could focus on
statistical indicators related to the Grade of Service (GoS, see Section 4.1.5) of the
entire bundle provided by SP2 to SP1.
End-to-end Service
SLAa
SLAb
Service
Provider 2
SLA4
Service
Provider 1
SLAc
Customers
Figure 7.7: Multiple Domain SLA Relationships Example 2
7.2.3 SLA to Service Mapping

One of the key aspects of a SLA is the association of the required levels of service to
the specific service details of a Service Instance. As defined in Chapter 2, the Service
Access Point (SAP) represents the logical element located between Customer and
SP domains. In the case of dependencies relating to services supplied by different
SPs the SAP characterizes the point where the SLA between the SPs is defined
(sometime called an NNI).
GB 917 v1.5
Page 73
Service Contract
1
0..*
1..*
Commercial Offer
0..*
1..*
relates to
defines service
contains
0..*
0..*
Service Level
Agreement
1..*
references
SLA Template
covers
1..*
1..*
composed of
Service Instance
relates service
objective to
1..*
1..*
provides service at
Service Access
Point
1..*
Service Element
1
1..*
has
Figure 7.8: SLA and Service Access Point Relationships

The relationship between the SLA and the SAPs for the service instance provides the
mapping between the service level objectives and the physical service resources that
comprise the service (see Figure 7.8). This gives the context in which to monitor
performance of the SLA parameters against the service level objectives defined in the
SLA.
7.3
Service Element Categories
Previous sections describe the different components comprising SLAs and their relationships. This
section focuses on the service element component, providing a table which identifies services offered
by SPs in terms of categories, giving examples of service elements for each category (see Figure
7.9).
GB 917 v1.5
Page 74
Service Category
Physical Connectivity
Bearer
Application
Contents
Operational
Self Operation
Other
Service Element
xDSL
PDH
SDH
SONET
Radio
ATM
FR
IP
Mailbox
Web
VoIP
On-line trade
News
VOD
Call Center
Problem Handling
Fulfillment/Provisioning
Call Center
Self Provisioning
Self Customer Care
Security11
Figure 7.9: Service Element Categories
7.4
SLA Mapping of QoS Parameters

In order to illustrate how SLA conceptual modeling could be applied in the real world,
this section provides a mapping between SLA components and the SLA parameter
framework described in Section 4.1.7, using the six examples of Chapter 3.
7.4.1 Leased Line Service

From the SLA modeling point of view, the Leased Line service is an example of a
simple service that is provided between two SAPs (the leased circuit end points). SLA
parameters are related to PDH or SDH transport pipe performance, such as
transmission delay between the end points of the circuit or severely errored seconds
(measured at the SAP).
SLA parameters for a Leased Line service could be mapped to the SLA parameter
framework as described by the examples provided in Figure 7.10.
11
GB 917 v1.5
For example, a RADIUS proxy gateway to an ISP.
Page 75
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Technologyspecific
Service-specific
Technology/Service
-independent
Max. Errored Seconds Ratio
Max. unavailability time
Max. Severely Errored Seconds Ratio
Max. Time To Restore
Max. Transfer Delay
Max. Delay Variation
Mini mum Time

Between Failures
Total unavailability
seconds
Aggregated
Requirements
Mean Errored Seconds Ratio

Mean Severely Errored Seconds Ratio
Mean Transfer Delay
Mean Bit Error Ratio
MTBF
MTTR
MTTP
Figure 7.10: Leased Line Service Parameter Framework Example
7.4.2 Frame Relay Service

A Frame Relay service offering could be provided by a SP on top of different network
technologies and underlying protocols. Typically, the service provided to the
Customer could be composed of two types of service element: physical access and
connectivity services.
The access service covers the access line (e.g. a T1 TDM data pipe) connecting the
CPE (that could be owned by the Customer or by the SP) with the FR backbone
network (NNI interface), while the connectivity service links two accesses by means
of a PVC (DLCI). A Customer may purchase an access for each site it needs to be
connected by the FR service, and a set of PVCs12.
SLA parameters for a Frame Relay service could be defined as:
SAP such as Error or Discarded Frame Ratio for a single SAP, which
is located at the UNI between the Customer and the SP or at the NNI
(a backbone PVC end point)13;
SE for a service element composed of multiple SAPs (e.g. a
connection is perceived by the Customer as a single PVC with two
end point SAPs), SAP-level parameters could be aggregated to obtain
a QoS value at the service level, such as Frame Loss Ratio of the
PVC and the Frame Transfer Delay;
Aggregated SE SLA parameters for multiple instances of the same
service element could be provided, such as the mean availability for
all the PVCs, or for the combination of different SE types, such as the
availability of an access and all its linked PVCs;
12
13
The number of PVCs needed to connect all sites is (N-1) for each access.
This type of SAP is needed when access services and backbone PVCs are provided by different SPs.
GB 917 v1.5
Page 76
Service bundle parameters aggregated for the entire service bundle,

such as Service Availability and the MTTR.
SLA parameters for a Frame Relay service could be mapped to the SLA parameter
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Service-specific
Max. Frame Error Ratio for a particular PVC
Max. Frame Transfer Delay for a particular PVC
Frame Delivery Ratio for a particular PVC
Max. Frame Delay Variation for a particular PVC
Max. unavailability
time for an access
line
Max. Time To
Restore
Minimum Time
Between Failures
Max. unavailability
time for all the access
lines
Max. Frame Error Ratio for all the PVCs
Mean Frame Error Ratio for a particular PVC
Mean Frame Error Ratio for all the PVCs
MTBF
Mean Frame Transfer Delay for a particular PVC
MTTR
Mean Frame Transfer Delay for all the PVCs
MTTP
Figure 7.11: Frame Relay Service Parameter Framework Example
7.4.3 ATM Cell Delivery Service

The same considerations of service provision are valid for the ATM Cell Delivery
Service. The distinction made between access and connectivity services applies as
well, providing help in defining SLA parameters for the different components of the
SLA.
SLA parameters for the ATM Cell Delivery service could be mapped to the SLA
parameter framework as described by the examples provided in Figure 7.12.
GB 917 v1.5
Page 77
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Service-specific
Max. Cell Error Ratio for a particular PVC
Max. Cell Transfer Delay for a particular PVC
Max. Cell Loss Ratio for a particular PVC
Max. unavailability
time for a PVC
Max. Time To
Restore
Max. Cell Delay Variation for a particular PVC
Minimum Time
Between Failures
Max. Cell Error Ratio for all the PVCs
Mean Cell Error Ratio for a particular PVC
Max. unavailability
time for all the PVCs
Mean Cell Error Ratio for all the PVCs
MTBF
Mean Cell Transfer Delay for a particular PVC
MTTR
Mean Cell Transfer Delay for all the PVCs
MTTP
Figure 7.12: ATM Cell Delivery Service Parameter Framework Example
7.4.4 IP-VPN Service

The IP-VPN service offering is provided to the Customer by means of a set of
accesses from the CPE (routers) to the IP backbone network. Here, two types of SE
could be highlighted: the access service and the IP backbone connectivity service. As
this service is related to a VPN, it is important to monitor the SLA needs at the
Customer site14, i.e. the geographical end point of the VPN.
Therefore, SLA parameters for an IP-VPN service could be defined as:
SAP such as IP Packet Loss Ratio for a single SAP, which is
located at the entry point to a VPN connection;
Customer site since a Customer site could require multiple SAPs
(e.g. for connecting different sites), SAP parameters could be
aggregated to obtain a QoS value at the site, such as availability of a
particular site;
SE for a service element composed of multiple SAPs (e.g. a
connection between two SAPs) SAP parameters could be aggregated
to obtain a QoS value at the service level, such as the IP Packet Loss
Ratio of the connection and the IP Packet Transfer Delay;
Aggregated SE SLA parameters for multiple instances of the same
service element could be provided, such as the mean availability for
all the accesses;
14
It could also be useful to monitor the SLA at the Customer site for FR and ATM services.
GB 917 v1.5
Page 78
Service bundle parameters aggregated for the entire IP-VPN service

bundle, such as Service Availability and the MTTR.
IP-VPN SLA parameters could be mapped to the SLA parameter framework as
described by the examples provided in Figure 7.13.
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Speed
Total UAS
Service-specific
Max. IP Packet
Transfer Delay for a
particular access
Max. unavailability
time for an access
line
Max. IP Packet Delay

Variation
Max. Time To
Restore
Max. IP Packet Loss

Ratio
Minimum Time
Between Failures
Max. IP Packet
Transfer Delay for all
the accesses
Max. unavailability
time for a particular
Customer site
Mean IP packet
particular Customer
site
Max. unavailability
time for all the access
lines
MTBF
Mean IP packet
particular access
MTTR
MTTP
Mean IP Packet
Delay Variation
Mean IP Packet
Throughput
Figure 7.13: IP-VPN Service Parameter Framework Example
7.4.5 IP Service with DSL Access

This service, as described in Section 3.4.5, is a bundle of network bearer services
(e.g. IP connectivity to the ISP), application services (e.g. web hosting and security)
and content services (e.g. news and music), where multiple SPs could be involved in
the provision of the service to an end Customer. Different SLAs could be defined
throughout the value chain (e.g. between the TSP and the ISP as well as between
the ISP and the end Customer) so that the end Customer can be given the required
SLA support by the retail SP (e.g. the ISP).
The end Customer is interested in the quality of the overall service, therefore the SLA
between the ISP and the end Customer could involve all the aspects of the service
bundle, providing SLA parameters which cover the network, the application and the
GB 917 v1.5
Page 79
content aspects of the service. For example, in addition to the IP-related technologyspecific parameters, such as IP packet delay and jitter, application parameters, such
as the web server availability (i.e. the web server is reachable from the Customer site
via HTTP Get request), or content parameters, such as service content delay (i.e.
delay in transferring a minimum amount of content), could all be provided in the SLA
for this service bundle.
IP Service with DSL Access SLA parameters could be mapped to the SLA parameter
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Max. IP Packet
Transfer Delay from
Customer access
Max. IP Packet Delay

Variation
Max. IP Packet Loss

Ratio
Mean IP packet
Transfer Delay from
Customer access
Mean IP Packet
Delay Variation
Mean IP Packet
Throughput
Service-specific
Max. web server

unavailability time
Max. Service Content

Transfer Delay
Max. unavailability
time for an access
line
Max. Service Content

Delay Variation
Max. Time To
Restore
Minimum Time
Between Failures
Mean unavailability
time for all the service
bundle
MTBF
MTTR
MTTP
Mean web server

unavailability time
Mean Service
Content Transfer
Delay
Mean Service
Content Delay
Variation
Figure 7.14: IP Service with DSL Access Service Parameter Framework Example
7.4.6 Customer Care Help Desk Service

This service offering provides an example of a simple SE that is provided to the
Customer (here there is no need to explode the service into more fine grained SEs).
The SAP related to this service is an abstraction of the means the Customer uses to
contact the Help Desk support organization (e.g. a conceptual representation of a
free toll number). SLA parameters, such as Mean Time To Respond to a Customer
request, could be defined here only at the service level. This example illustrates a
Customer Care Help Desk service that has only technology/service-independent
parameters.
Customer Care Help Desk Service SLA parameters could be mapped to the SLA
parameter framework as described by the examples provided in Figure 7.15.
GB 917 v1.5
Page 80
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Not applicable
Not applicable
Service-specific
Not applicable
Not applicable
Max. Unavailability
Max. Time to
Respond (i.e. wait for
an available operator)
for a single call
Max. Time to
Examine a single
Request (i.e. process
the request)
Mean Time to
Respond
Mean Time to
Examine Requests
Figure 7.15: Customer Care Help Desk Service Parameter Framework Example
GB 917 v1.5
Page 81
References
[E.800]
Terms and Definitions Related to Quality of Service and Network Performance

including Dependability, ITU-T Recommendation E.800, Geneva, August 1994.
[E.801]
Framework for service quality agreement, ITU-T Recommendation E.801,

Geneva, October 1996.
[FRF.13]
Service Level Definitions Implementation Agreement, FRF.13, Frame Relay

Forum Technical Committee, Freemont, CA, August 1998.
[GB 910]
Telecom Operations Map, GB 910, Approved Version 2.1, TeleManagement

Forum, Morristown, NJ, March 2000.
[I.371]
Traffic control and congestion control in B-ISDN, ITU-T Recommendation I.371,

Geneva, March 2000.
[ITU-Hbk]
Handbook on Quality of Service and Network Performance, ITU-T, Geneva, 1984,

revised 1993.
[M.60]
Maintenance Terminology and Definitions, ITU-T Recommendation M.60,

Geneva, March 1993.
[M.2140]
Transport network event correlation, ITU-T Recommendation M.2140, Geneva,

February 2000.
[NMF 503]
Service Provider to Customer Performance Reporting Business Agreement, NMF

503, Issue 1.0, TeleManagement Forum, Morristown, NJ, March 1997.
[P806]
Project P806, Deliverable 1, The EQoS Framework Version 2, EURESCOM,

September 1999.
[TMF 701]
Performance Reporting Concepts & Definitions Document, TMF 701, Evaluation

Version Issue 1.1, TeleManagement Forum, Morristown, NJ, May 1999.
[WP-SLA]
White Paper on Service Level Agreements, Best Practices Committee, Application

Service Provider Industry Consortium, 2000.
GB 917 v1.5
Page 82
GB 917 v1.5
Page 83
Acronyms
3GPP
ABR
ABT
AIP
ANSI
ANT
API
ASP
ASPIC
ASR
ATC
ATIS
ATM
BBE
BBER
BER
BICC
B-ISDN
CATV
CBR
CCR
CD
CDR
CDV
CDVT
CE
CER
CIM
CIR
CL
CLI
CLR
CM
CMR
CN
CNM
COPS
CPE
CPoF
CTD
DBR
DiffServ
DLCI
Third Generation Partnership Project

Available Bit Rate
ATM Block Transfer
Application Infrastructure Provider
American National Standards Institute
Access Network Transport
Application Programming Interface
Application Service Provider
Application Service Provider Industry Consortium
Answer/Seize Ratio
ATM Transfer Capability
Alliance for Telecommunications Industry Solutions
Asynchronous Transfer Mode
Background Block Error
Background Block Error Ratio
Bit Error Ratio
Bearer-Independent Call Control
Broadband Integrated Services Digital Network
Cable Television (Community Antenna Television)
Constant Bit Rate
Call Completion Record
Cell Delay
Call Data Record
Cell Delay Variation
Cell Delay Variation Tolerance
Cell Error
Cell Error Ratio
Common Information Model
Committed Information Rate
Cell Loss
Calling Line Identifier
Cell Loss Ratio
Cell Misinsertion
Cell Misinsertion Ratio
Core Network
Customer Network Management
Common Open Policy Service
Customer Premises Equipment
Common Point of Failure
Cell Transfer Delay
Deterministic Bit Rate
Differentiated Services
Data Link Connection Identifier
GB 917 v1.5
Page 84
DMTF
DNS
DPL
DS
DSCP
DSL
DSS
ECBP
EDC
EDGE
EFS
EQoS
ES
ESR
ETSI
EURESCOM
FDD
FR
FRAD
FSA
FTD
G-CDR
GERAN
GFR
GGSN
GII
GoS
GPRS
GSM
HCPN
HTTP
IAB
IESG
IETF
IMT
IN
INMD
IntServ
IOPS.ORG
IP
IPDV
IPER
IPLR
IPPM
IPTD
IRTF
ISDN
ISM
ISO
ISP
IST
GB 917 v1.5
Distributed Management Task Force

Domain Naming Service
Degraded Performance Limit
Differentiated Services
DiffServ Code Point
Digital Subscriber Line
Digital Subscriber SIgnalling System
End-to-end Connection Blocking Probability
Error Detection Code
Enhanced Data rates for GSM Evolution
Error Free Seconds
EURESCOM Quality of Service
Errored Second
Errored Second Ratio
European Telecommunications Standards Institute
European Institute for Research and Strategic Studies in Telecommunications
Frequency Division Duplex
Frame Relay
Frame Relay Access Device
Framework Study Area
Frame Transfer Delay
Gateway GPRS Support Node Call Detail Record
GSM/EDGE Radio Access Network
Guaranteed Frame Rate
GPRS Gateway Support Node
Global Information Infrastructure
Grade of Service
General Packet Radio Service
Global System for Mobile communication
Hybrid Circuit-switched/Packet-based Network
Hyper Text Transfer Protocol
Internet Architecture Board
Internet Engineering Steering Group
Internet Engineering Task Force
International Mobile Telecommunications
Intelligent Network
In-service Non-intrusive Measuring Device
Integrated Services
Internet Operators Group
Internet Protocol
IP Packet Delay Variation
IP Packet Error Ratio
IP Packet Loss Ratio
IP Performance Metrics
IP Packet Transfer Delay
Internet Research Task Force
Integrated Services Digital Network
In-Service Monitoring
International Organization for Standardization
Internet Service Provider
Information Society Technologies
ISV
IT
ITAA
ITU-R
ITU-T
LAN
LDP
LSR
MBS
MCR
MIB
MOS
MPEG
MPLS
MTBF
MTBO
MTIE
MTPS
MTRS
MTTP
MTTR
NER
NGN
NII
N-ISDN
NM
NMDG
NMF
NNI
NO
NP
NP&D
NPC
NSP
NTE
OAM
OI
ONP
OS
OSI
OSS
OTN
PC
PCR
PDH
PDN
PDP
PDN
PDU
Page 85
Independent Software Vendor

Information Technology
Information Technology Association of America
International Telecommunication Union Radiocommunication Sector
International Telecommunication Union Telecommunication Standardization
Sector
Local Area Network
Label Distribution Protocol
Label Switching Router
Maximum Burst Size
Mean Cell Rate
Management Information Base
Mean Opinion Score
Moving Picture Coding Experts Group
Multiprotocol Label Switching
Mean Time Between Failures
Mean Time Between Outages
Maximum Time Interval Error
Mean Time to Provide Service
Mean Time to Restore Service
Mean Time to Provision
Mean Time To Repair
Network Effectiveness Ratio
Next Generation Network
National Information Infrastructure
Narrow band Integrated Services Digital Network
Network Management
Network Measurement Development Group
Network Management Forum
Network-Node Interface
Network Operator
Network Performance
Network Planning and Development
Network Parameter Control
Network Service Provider
Network Terminating Equipment
Operations, Administration & Maintenance
Outage Intensity
Open Network Provision
Operations System
Open Systems Interconnection
Operations Support System
Optical Transport Network
Personal Computer
Peak Cell Rate
Plesiochronous Digital Hierarchy
Public Data Network
Packet Data Protocol
Public Data Network
Protocol Data Unit
GB 917 v1.5
Page 86
PEI
PHB
PIB
PIR
PLM
PNO
POH
PRM
PS
PSTN
PVC
QoS
QOSF
QSDG
RAN
RFC
RFI
RFP
RFSD
RSVP
SA
SAP
SBR
S-CDR
SCR
SDH
SE
SECB
SECBR
SEP
SEPI
SES
SESR
SGSN
SLA
SLO
SLS
SLSU
SMI
SOHO
SONET
SP
SP&D
SQM
SVC
TCA
TCP
TDD
TDM
TEWG
TFT
GB 917 v1.5
Peak Emission Interval

Per Hop Behavior
Policy Information Base
Peak Information Rate
Product Line Management
Public Network Operator
Path OverHead
Performance Report Message
Packet Switched
Public Switched Telephone Network
Permanent Virtual Circuit
Quality of Service
Quality of Service Forum
Quality of Service Development Group
Radio Access Network
Request for Comments
Request for Information
Request for Proposal
Ready For Service Date
Resource Reservation Protocol
Service Access Point
Statistical Bit Rate
Serving GPRS Support Node Call Detail Record
Sustainable Cell Rate
Synchronous Digital Hierarchy
Service Element
Severely Errored Cell Block
Severely Errored Cell Block Ratio
Severely Errored Period
Severely Errored Period Intensity
Severely Errored Second
Severely Errored Second Ratio
Serving GPRS Support Node
Service Level Agreement
Service Level Objective
Service Level Specification
Service Level Specification and Usage
Structure of Management Information
Small Office Home Office
Synchronous Optical Network
Service Provider
Service Planning and Development
Service Quality Management
Switched Virtual Circuit
Traffic Conditioning Agreement
Transmission Control Protocol
Time Division Duplex
Time-Division Multiplexing
Traffic Engineering Working Group
Traffic Flow Template
TIE
TIPHON
TMF
TMN
TOM
TSAG
TSP
TT
TV
UAS
UBR
UMTS
UNI
UPC
UPL
UTC
UTRA
VAR
VC
VCI
VOD
VoIP
VPI
VPN
WAN
WAP
WTSA
XIWT
XML
Page 87
Time Interval Error

Telecommunications and Internet Protocol Harmonization over Networks
TeleManagement Forum
Telecommunications Management Network
Telecom Operations Map
Telecommunication Standardization Advisory Group
Telecom Service Provider
Trouble Ticket
Television
Unavailable Seconds
Unspecified Bit Rate
Universal Mobile Telecommunications System
User-Network Interface
User Parameter Control
Unacceptable Performance Limit
Universal Time, Coordinated
UMTS Terrestrial Radio Access
Value Added Reseller
Virtual Circuit
Virtual Circuit Identifier
Video On Demand
Voice over IP
Virtual Path Identifier
Virtual Private Network
Wide Area Network
Wireless Access Protocol
World Telecommunications Standardization Assembly
Cross-Industry Working Team
Extensible Markup Language
GB 917 v1.5
Page 88
GB 917 v1.5
Page 89
Appendix I: Related Activities

With the increased focus on SLAs, many standards bodies and other organizations
around the world are working on SLA and QoS issues and parameters. These
include 3GPP, Committee T1, ETSI, EURESCOM, IETF, the European Unions IST
program, ITU-T, and the Quality of Service Development Group (QSDG). This
Appendix attempts to summarize the current work, but it must be recognized this is
only a snapshot of what is an evolving study. The authors are grateful to these bodies
and their work, which has provided useful input for this Handbook.
I.1
3GPP
The 3GPP (Third Generation Partnership Project) was established in 1998 and is
composed of organizational partners (e.g. regional standards bodies) and market
representation partners (e.g. industry associations) who have agreed to cooperate in
the production of globally applicable Technical Specifications and Technical Reports
for a 3rd Generation Mobile System based on evolved GSM (Global System for
Mobile communication) core networks and the radio access technologies that they
support (i.e. UMTS Terrestrial Radio Access (UTRA) both Frequency Division Duplex
(FDD) and Time Division Duplex (TDD) modes). The Partners have further agreed to
cooperate in the maintenance and development of the GSM Technical Specifications
and Technical Reports, including evolved radio access technologies (e.g. General
Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE)).
Individual members wishing to participate in the work can do so if they are members
of one of the organizational partners.
Work on a variety of aspects of 3rd generation technology, including performance and
QoS, is undertaken in the 5 Technical Specification Groups (TSG) of 3GPP, namely:
TSG CN (Core Network)
TSG GERAN (GSM/EDGE Radio Access Network)
TSG RAN (Radio Access Network)
TSG SA (Services and System Aspects)
TSG T (Terminals)
Currently working groups SA2, CN1, CN4, RAN3 and GERAN are dealing with QoS
aspects.
The basic principles and mechanisms considering service performance in 3G are
specified in 3GPP documents 3G TS 23.107 (Quality of Service, Concept and
GB 917 v1.5
Page 90
Architecture) and 3G TS 23.060 (General Packet Radio Service (GPRS); Service

description; Stage 2). The QoS concept in 3G TS 23.107 suggests using the following
traffic classes in order to classify the performance requirements:
conversational
streaming
interactive
background
Based on these traffic classes the document describes detailed parameters
concerning UMTS bearer services.
3G TS 23.060 enhances the Packet Data Protocol (PDP) context mechanisms
introduced in GPRS stage 1 and introduces another concept called Traffic Flow
Template (TFT). TFT enables the use of multiple simultaneous PDP contexts per
user with different performance requirements. TFT serves as a group of filters that are
signaled to the GPRS Gateway Support Node (GGSN) during PDP context activation
or modification. Each PDP context has one TFT but each TFT may contain up to
eight filters (the first PDP context established might not have a TFT thus serving as a
default PDP context).
3G TS 32.015 (Charging and billing; 3G call and event data for the Packet Switched
(PS) domain) describes the mechanisms used for charging and billing. The QoS
information in the S-CDR (Serving GPRS Support Node Call Detail Record) which
is generated by the SGSN (Serving GPRS Support Node) and in the G-CDR
(Gateway GPRS Support Node Call Detail Record), which is generated by the
GGSN, is related to the PDP context activation and modification. Each time there is a
tariff or QoS change, a container is added to the CDR (Call Detail Record).
Further information on the work of 3GPP is available from its web site
http://www.3GPP.org
I.2
Committee T1
Committee T1 is sponsored by the Alliance for Telecommunications Industry
Solutions (ATIS) and is accredited by the American National Standards Institute
(ANSI) as the North American standards body for telecommunications. Established in
1984, it develops technical standards and reports regarding interfaces for U.S.
telecommunication networks as well as positions on related subjects under
consideration in various international standards bodies. It has six technical
subcommittees that develop draft standards and technical reports and which make
recommendations in their area of expertise.
One of the subcommittees concerned with QoS and NP is the Technical
Subcommittee T1A1 responsible for Performance and Signal Processing. It has three
Working Groups:
T1A1.1 - Multi-Media Communications Coding and Performance
GB 917 v1.5
Page 91
T1A1.2 - Network Survivability Performance

T1A1.3 - Performance of Digital Networks and Services
These Working Groups are responsible for developing standards and technical
reports related to their area of focus. T1A1.1 has a number of ongoing projects
concerned with performance and performance measurements for a variety of media.
T1A1.2 is studying network survivability performance by establishing a framework for
measuring service outages and a framework for classifying network survivability
techniques and measures. It has produced a number of technical reports and is
working on a Draft Technical Report on a Reliability/Availability Framework for IPBased Networks and Services, which includes discussion of how to specify
reliability/availability metrics in SLAs. T1A1.3 is investigating the performance of
networks and services with particular focus on performance parameter definitions,
measurement methods and techniques, and numeric objects. Information on current
projects and work in progress is available from the web site: http://www.t1.org.
I.3
ETSI
ETSI (European Telecommunication Standards Institute) is responsible for Europeanlevel telecommunication standards. Most of the QoS-related work in ETSI is
performed as sub-tasks under projects. The only body dealing directly with QoS in
ETSI is TC STQ (Technical Committee for Speech Processing, Transmission &
Quality Aspects).
The most interesting work concerning QoS is going on under the TIPHON project
(Telecommunications and Internet Protocol Harmonization Over Networks). TIPHON
WG 5 deals with end-to-end quality of service aspects.
Some relevant publications produced by ETSI include:
ETR 003, Network Aspects (NA); General Aspects of Quality of
Service (QoS) and Network Performance (NP), October 1994.
ETR 138, Quality of Service indicators for Open Network Provision
(ONP) of voice telephony and Integrated Services Digital Network
(ISDN), December 1997
ETSI TS 101 329, End to End Quality of Service in TIPHON Systems,
Part 1: General aspects of Quality of Service (QoS), Part 2: Definition
of Quality of Service (QoS) Classes, July 2000
Information on ETSI activities is available from the ETSI web site: http://www.etsi.org.
GB 917 v1.5
Page 92
I.4
EURESCOM
EURESCOM is a group of European telecommunication service provider companies
working together on pre-competitive research and development projects in
telecommunications. Set up as a German private company with over 20 shareholders
from different European countries, its headquarters is located in Heidelberg. Some
EURESCOM projects relevant to QoS and SLAs are introduced below. Further
information on EURESCOM projects and deliverables is available from the
EURESCOM web site: http://www.eurescom.de.
I.4.1
Project P806
Project P806 EQoS - A common framework for QoS/Network Performance in a
multi-provider environment developed a common service quality framework for
multi-operator/provider provisioning environments and applied it to various scenarios.
It produced the following public deliverables:
Deliverable D1: The EQoS Framework final version, September 1999. D1 provides
the EQoS approach of handling QoS in a multi-provisioning environment. The EQoS
framework comprises the QoS definition and the generic structure of a QoS
agreement at the interface between user and provider.
Deliverable D2: IN/Internet interconnection scenarios and harmonised agreements,
February 1999. D2 investigates the applicability of the EQoS framework presented in
the preliminary version of D1 to IN and Internet cases. In particular, the generic
structure and examples of the content of an interconnection agreement are given.
Deliverable D4: How to apply EQoS? Case Study VOIP. QoS Handbook Outline,
June 2000. D4 provides a methodology on how to apply the EQoS framework in
practice. The methodology is applied to a VoIP service as provided by the ETSI
project TIPHON. Suggestions are also given on how the ITU-T QoS Handbook [ITUHbk] could be updated in the light of the EQoS framework principles.
I.4.2
Project P906
Project P906 QUASIMODO - QUAlity of Service MethODOlogies and solutions
within the service framework: Measuring, managing and charging QoS investigated
QoS in IP-based networks and services and the correlation between QoS at the user
level and network performance at the network level. The following deliverables were
published:
Deliverable D1: Offering Quality classes to end users, May 2000. D1 presents the
QUASI model which can be applied to single-provider IP networks. Three application
categories are defined and for each of these categories two quality classes are
provided, resulting in six possible data flows that need to be mapped to network
performance parameters. The deliverable reports on lab tests that were carried out to
establish the correlation between the quality classes and the network performance
levels.
GB 917 v1.5
Page 93
Deliverable D2: Methodologies and tools for QoS measurement and management,
February 2001. D2 discusses the results obtained from implementations of the
QUASI model based on DiffServ and IntServ models. The methods used to measure
and manage QoS were evaluated and it was found that the QUASI model provides
useful contributions to QoS measurement and management.
Deliverable D3: Methodologies and policies for QoS charging, February 2001. D3 is
concerned with charging for QoS in IP-based networks. Two approaches were
designed, specified, prototyped and evaluated. Results of the experiments are
expected to contribute to QoS charging system design to enable service providers to
charge efficiently for QoS in IP-based networks.
A number of technical information documents have been produced by the project
which provide more detailed information on topics covered by the deliverables.
I.4.3
Project P1008
Project P1008 Inter-operator Interfaces for ensuring end-to-end IP QoS is
investigating the requirements on inter-domain support for end-to-end IP services and
is specifying interfaces between domains for managing the interconnection of IPbased services and networks. The available deliverables are:
Deliverable D1: State of the art of IP Inter-domain management and supporting
measurements, July 2000. D1 investigates existing and prospective technologies
supporting QoS for multi-domain IP services, including reviews of the relevant work
from organizations such as ETSI, IETF and ITU-T, and also EURESCOM itself. More
detailed information on some of these technologies is provided in a series of annexes
to the main document.
Deliverable D2: Selected Scenarios and requirements for end-to-end IP QoS
management, February 2001, investigates some approaches to managing IP
between service providers on an end-to-end basis. Various business models for
interconnection between operators to support IP QoS services are introduced and
scenarios provided to demonstrate how end-to-end IP QoS could be provided and
managed for different services. SLAs between providers and the kind of parameters
they may contain are discussed. An annex provides further details of the issues
discussed.
I.4.4
Other Projects of Relevance

Project P803 European IP Testbed was concerned with various aspects of IPv6
and support for QoS in an IP network. Volume 1 of its deliverable D4: Supporting
Differentiated Quality of Service in IP Networks, August 1999, provides an evaluation
of various approaches to QoS in IP networks.
Project P807 JUPITER II - Usability, Performability and Interoperability Trials in
Europe investigated the network technologies required to provide end-to-end QoS
over IP, particularly for multimedia services. Deliverable D3 Achieving Quality in
New Multimedia Services, March 2000, reports on the measuring methods and
GB 917 v1.5
Page 94
results of its evaluation of network performance and user perception of multimedia

QoS.
Project P905 AQUAVIT - Assessment of QUality for Audi-Visual signals over
Internet and UMTS investigated the issues involved in transmitting audio and video
signals over mobile and IP networks. It developed a methodology for evaluating
audiovisual quality in these networks and building testbeds in order to study the
methods for assessing the quality of audiovisual transmission. Deliverable D2
Methodology for subjective audiovisual quality evaluation in mobile and IP networks,
August 2000, discusses the test methodology used to evaluate the quality levels of
multimedia services over IP and UMTS networks. Deliverable D4 Main Findings,
May 2001, presents the projects testbeds, test methodologies, test results and
analyses.
Project P1006 DISCMAN - Differentiated Services - Network Configuration and
Management focused on DiffServ as a means of supporting QoS in IP networks. It
evaluated existing implementations, assessed traffic engineering mechanisms, such
as MPLS, for use in combination with DiffServ, and ran trials with multi-provider and
multi-vendor scenarios. Several Technical Specification and Technical Information
documents were produced that present the work of the project in more detail.
Project P1103 Inter-Operator IP QoS Framework - ToIP and UMTS Case Studies
is concerned with the provision of differentiated service quality to IP-based services
that span multiple networks from different operators. It will analyze business
requirements and models and will produce a validated IP QoS Provisioning
Framework.
I.5
IETF
The IETF (Internet Engineering Task Force) is a large open international community
of network designers, operators, vendors, and researchers concerned with the
evolution of the Internet architecture and the smooth operation of the Internet. It is
essentially a self-organized group of people who make technical and other
contributions to the engineering and evolution of the Internet and its technologies.
The IETF is not a traditional standards organization, although many specifications are
produced that become Internet standards. It is the principal body engaged in the
development of new Internet standard specifications. The mission of IETF includes:
Identifying, and proposing solutions to, pressing operational and
technical problems in the Internet.
Specifying the development or usage of protocols and the near-term
architecture to solve such technical problems for the Internet.
Making recommendations to the Internet Engineering Steering Group
(IESG) regarding the standardization of protocols and protocol usage
in the Internet.
Facilitating technology transfer from the Internet Research Task Force
(IRTF) to the wider Internet community.
GB 917 v1.5
Page 95
Providing a forum for the exchange of information within the Internet

community between vendors, users, researchers, agency contractors
and network managers.
The technical IETF work is carried out in its working groups, which are organized by
topic into various areas. These areas comprise Applications; General; Internet;
Operations and Management; Routing; Security; Transport; and User Services. Each
area has one or two area directors and several working groups. A working group is a
group of people who work under a charter to achieve a certain goal. That goal may
be the creation of an information document or a protocol specification, or the
resolution of problems in the Internet. The Internet Architecture Board (IAB) provides
the architectural oversight for the work being undertaken in the working groups and is
the technical advisory group for the Internet Society. The working groups publish
work in progress as Internet Drafts, which have a limited lifetime (a maximum of six
months) and no formal status but which indicate the direction of the work being
undertaken. Requests for Comments (RFCs) are documents that have reached a
certain maturity and stability and which cover a wide range of issues, including the
specification of Internet standards.
Internet development has been based on protocols that provide a fault-tolerant besteffort service which does not guarantee any specific QoS. However, as Internetbased network usage is becoming more ubiquitous and supporting more complex
services, often with stringent real-time and commercial requirements, the IETF has
concerned itself with how to provide QoS over the Internet. A number of working
groups are currently investigating various aspects of the issue, mainly at the transport
flow level. A brief summary of the status of the work considered most pertinent to
QoS and SLAs is provided in the following sections. Further information on the
working groups, their charters, Internet Drafts and RFCs, past meeting proceedings,
current activities/actions, etc. is available at the IETF web site: http://www.ietf.org.
I.5.1
Differentiated Services Working Group

The Differentiated Services (DiffServ) Working Group has developed a packet-based
priority service model that provides multiple classes of service in the network15.
Decisions on the quality of service of packet delivery are made at the boundary of a
network. The border routers of a network use 6 bits (the DiffServ Code Point - DSCP)
in the IP packet header to allocate the packet to a particular class of service16 and
can control admission of packets to the network. This DSCP is used by the core
routers within the network to determine the forwarding treatment, or per hop behavior
(PHB), of the packet. Three PHBs have been specified: a default Best Effort PHB,
Expedited Forwarding17, which requires packets to be serviced according to the rate
associated with the PHB, and Assured Forwarding18, which delivers packets in four
different classes each with three different levels of drop precedence. Work has also
been undertaken on the interaction of differentiated services with IP tunnels19, and on
15
RFC 2475, An Architecture for Differentiated Services, December 1998

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998
17
RFC 2598, An Expedited Forwarding PHB, June 1999
18
RFC 2597, Assured Forwarding PHB Group, June 1999
19
RFC 2983, Differentiated Services and Tunnels, October 2000
16
GB 917 v1.5
Page 96
the specification of per domain behaviors describing QoS attributes across a DiffServ
domain20.
The provision of different classes of service for traffic enables the traffic service
provider to offer agreements to the users of the traffic services. In RFC 2475 such an
agreement is referred to as a SLA21, but given the wider connotations of the term SLA
(as in this Handbook, for example), it is being proposed to use the term Service Level
Specification (SLS) instead22. A SLS corresponds to the network performance levels
that a SLA would have to be mapped to and should provide a set of parameters and
their values for determining traffic profiles.
The current focus includes work on additional components required to support
differentiated services, a model for managing and configuring DiffServ routers, a
SMIv2 MIB for implementing the DiffServ architecture, and a QoS Policy Information
Base (PIB) for configuring QoS policy for differentiated services.
I.5.2
Integrated Services Working Group

The Integrated Services (IntServ) Working Group was one of the first to investigate
support for QoS on the Internet. It has developed an enhanced service model which
can provide QoS support for individual traffic flows in the network using a flow-based
reservation service23. This is established by use of a signaling protocol, such as
RSVP24, to request the class of service required. In addition to the default Best Effort
service class which provides no QoS control, IntServ specifies a Guaranteed
service25, which imposes upper bounds on end-to-end delay and provides an assured
level of bandwidth for real-time applications with stringent delivery requirements, and
a Controlled Load service26, which provides applications with a service equivalent to
best effort under unloaded conditions.
I.5.3
IP Performance Metrics Working Group

The IP Performance Metrics (IPPM) Working Group is developing a set of IP-related
standard metrics that can be applied to the quality, performance and reliability of
Internet data delivery services. The aim of the work is to enable providers and users
of Internet transport services achieve an accurate and common understanding of the
performance and reliability metrics for paths through the Internet. It also offers a
forum for sharing information about the implementation and application of these
metrics. A framework for the IP performance metrics work has been developed27,
20
RFC 3086, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, April 2001
In RFC 2475 a Service Level Agreement is defined as a service contract between a customer and a service provider that
specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or
another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in
part.
22
A Service Level Specification is considered to be a set of parameters and their values which together define the service
offered to a traffic stream by a DS domain. New Terminology for DiffServ, March 2001, Internet Draft <draft-ietf-diffserv-newterms-04.txt>.
23
RFC 1633, Integrated Services in the Internet Architecture: An Overview, June 1994
24
RFC 2210, The Use of RSVP with IETF Integrated Services, September 1997
25
RFC 2212, Specification of Guaranteed Quality of Service, September 1997
26
RFC 2211, Specification of the Controlled-Load Network Element Service, September 1997
27
RFC 2330, Framework for IP Performance Metrics, May 1998
21
GB 917 v1.5
Page 97
which provides the basis for the work on measuring connectivity28, delay29 and packet
loss30. Work is being undertaken on one-way loss pattern sample metrics, an
instantaneous packet delay variation metric, and the issues associated with
application-level measurements of network performance for periodic streams.
I.5.4
Internet Traffic Engineering Working Group

The Internet Traffic Engineering Working Group (TEWG) was set up at the end of
1999 and is concerned with the performance optimization of operational networks.
The group is working on a framework document which is intended to provide a
common basis for the development of traffic engineering capabilities for the Internet
and which will include discussion of the principles, architectures and methodologies
for performance evaluation and performance optimization of operational IP networks.
The group is focusing in the first instance on the control aspects of intra-domain
Internet traffic engineering although it may also consider solutions to the problems of
traffic engineering across autonomous systems boundaries.
I.5.5
Multiprotocol Label Switching Working Group

The Multiprotocol Label Switching (MPLS) Working Group has been working on a
label-switching approach that encapsulates packets with a label between the layer 2
and layer 3 headers. This label identifies the data flow to which the packet belongs in
that domain, thus enabling different QoS approaches to be adopted towards the
individual data flows31. The Working Group is responsible for standardizing the base
label-switching technology in conjunction with network layer routing and for specifying
the implementation of that technology over various link technologies. It has developed
the base Label Distribution Protocol (LDP) for communication between Label
Switching Routers (LSRs) 32, the basic MPLS architecture33 and the encoding to be
used by LSRs34. It has also produced specifications for running MPLS over ATM35
and Frame Relay36 links. It is working on specifying improved fault tolerance
mechanisms for LDP, on specifications for running MPLS over additional
technologies, and on specifying the framework for IP multicast over label switched
paths.
I.5.6
Policy Framework Working Group

The Policy Framework Working Group is developing a framework for policy-based
management that will enable policies and policy information to be represented,
managed, shared and reused in a vendor-independent, interoperable and scalable
manner. Work has been undertaken on developing a QoS policy schema and a
28
RFC 2678, IPPM Metrics for Measuring Connectivity, September 1999

RFC 2679, A One-way Delay Metric for IPPM, September 1999, and RFC 2681, A Round-trip Delay Metric for IPPM,
September 1999
30
RFC 2680, A One-way Packet Loss Metric for IPPM, September 1999
31
RFC 2702, Requirements for Traffic Engineering Over MPLS, September 1999
32
RFC 3036, LDP Specification, January 2001
33
RFC 3031, Multiprotocol Label Switching Architecture, January 2001
34
RFC 3032, MPLS Label Stack Encoding, January 2001
35
RFC 3035, MPLS using LDP and ATM VC Switching, January 2001
36
RFC 3034, Use of Label Switching on Frame Relay Networks Specification, January 2001
29
GB 917 v1.5
Page 98
policy framework QoS information model. The aim is to enable high-level policy
information to be translated into device configuration information for network QoS
applications. The work is being coordinated with the DiffServ Working Groups Policy
Information Base and Management Information Base to ensure that the information
model and schemata being developed by the Policy Framework Working Group are
compatible with and can use the information contained in the DiffServ PIB and MIB.
The Working Group is coordinating its development of the policy information model
with the Distributed Management Task Force and has produced version 1 of its
specification of an information model for representing policy information37. Current
work on terminology is aiming to provide a glossary of policy-related terms38. In this
glossary, a SLA is defined as the documented result of a negotiation between a
customer/consumer and a provider of a service, that specifies the levels of availability,
serviceability, performance, operation or other attributes of the service. A Service
Level Objective (SLO) which partitions an SLA into individual metrics and operational
information to enforce and/or monitor the SLA is defined as a set of parameters and
their values. A Service Level Specification (SLS) is defined as a combination of an
SLA (a negotiated agreement) and its SLOs (the individual metrics and operational
data to enforce)
I.5.7
Resource Allocation Protocol Working Group

This group is working to support a QoS-enabled Internet by establishing a means of
policy control for RSVP. It is coordinating its work with the Policy Framework group
and has established a framework for policy-based admission control decisions to
support QoS39. It has developed the COPS (Common Open Policy Service)
Protocol40, which enables a policy server and its clients to exchange policy
information, and usage of the COPS protocol to support policy provisioning41. It
intends to develop an object syntax for information related to QoS policy provisioning.
I.6
IST Projects
The European Union has a research program IST (Information Society Technologies)
which includes projects investigating SLAs and QoS, as introduced below. Further
information
on
the
program
and
projects
is
available
from
http://www.cordis.lu/ist/home.html.
I.6.1
AQUILA
Project IST-1999-10077 AQUILA (Adaptive Resource Control for QoS Using an IPbased Layered Architecture) is developing an enhanced architecture for QoS based
on existing IETF approaches, such as DiffServ, IntServ and MPLS, to enable end-toend QoS provisioning for applications in the Internet. It is basing its current work on
37
RFC 3060, Policy Core Information Model Version 1 Specification, February 2001
Policy Terminology, April 2001, Internet Draft <draft-ietf-policy-terminology-03.txt>
39
RFC 2753, A Framework for Policy-based Admission Control, January 2000
40
RFC 2748, The COPS (Common Open Policy Service) Protocol, January 2000
41
RFC 3084, COPS Usage for Policy Provisioning, March 2001
38
GB 917 v1.5
Page 99
the DiffServ approach and is enhancing the DiffServ architecture with a Resource
Control Layer to allow dynamic adaptation of resource allocation to user requests. It is
also developing a toolkit (the End-user Application Toolkit) to enable applications to
become aware of the QoS capabilities of the underlying network. Information on
AQUILA is available from http://www-st.inf.tu-dresden.de/aquila.
I.6.2
CADENUS
Project IST-1999-11017 CADENUS (Creation and Deployment of End-user Services
in Premium IP Networks) is concerned with a dynamic service configuration and
provisioning environment to support services with QoS guarantees in Premium IP
networks. It is developing a service creation and provisioning framework for the userprovider interface and will link user-related service components to network-related
service components. It is addressing issues related to the definition of SLAs for
services in Premium IP networks so that different levels of service quality can be
supported. This process is to be automated by combining and configuring preexisting service components and by automating the SLA processing. Further
information on CADENUS and related work is available from http://www.cadenus.org.
I.6.3
FORM
Project IST-1999-10357 FORM (Engineering a Co-operative Inter-Enterprise
Management Framework Supporting Dynamic Federated Organisations
Management) is developing a management framework and components to support
cooperation between distributed enterprises. It is realizing components for the
Fulfillment, Assurance and Billing end-to-end processes of TOM, including policybased negotiation and creation of SLAs for a VPN service that is based on a
Guaranteed QoS IP Service using the DiffServ architecture. Further information is
available from http://www.ist-form.org.
I.6.4
M3I
Project IST-1999-11429 M3I (Market Managed Multiservice Internet) is investigating
means to support differential charging between multiple levels of service. This will
enable charging rates to be applied appropriately to different levels of service quality
and tariffs to be changed dynamically. Various approaches to charging and the effect
of dynamic charging on network congestion are being examined and will be tested in
a prototype. Information on M3I can be obtained from http://www.m3i.org.
I.6.5
TEQUILA
Project IST-1999-11253 TEQUILA (Traffic Engineering for Quality of Service in the
Internet, at Large Scale) is investigating how to specify, implement and validate endto-end QoS guarantees using traffic management techniques within IP DiffServ
networks. The project is developing Service Level Specifications (SLSs) to support
QoS for both fixed and mobile users, mechanisms for negotiating, monitoring and
enforcing these SLSs via the use of contracted SLSs, and appropriate traffic
engineering schemes to support the QoS defined in the SLSs. The project has
GB 917 v1.5
Page 100
developed a framework for Service Level Specification and Usage and it is involved in
the establishment of a new IETF working group, the Service Level Specification and
Usage (SLSU) Working Group. This working group aims to formulate an agreed set
of service level specification parameters and semantics for use across administrative
boundaries. The Tequila web site is at http://www.ist-tequila.org.
I.7
ITU-T
ITU-T, the telecom standardization sector of ITU, has a wide number of
Recommendations on QoS and NP, and is developing new ones for new network
technologies and services. Up to now, ITU-T has not developed specific
Recommendations for SLAs as it regards these as commercial agreements between
contracting parties and outside its remit. Study Groups 2 and 4 and the QSDG are
beginning to address SLAs. QoS is a very broad concept that comprises many
performance aspects and numerous measures, and is defined by ITU-T as follows:
Quality of Service is the collective effect of service performances that determine the
degree of satisfaction of a user of the service (see ITU-T Rec. E.800 [E.800]).
Most Telecom Service Providers (TSPs), and certainly the Public Network Operators
(PNOs), base their QoS and NP definitions on the ITU-T framework defined in Recs
E.800 [E.800] and E.801 [E.801]. These Recommendations were defined by Study
Group 2 originally for circuit-switched voice telephony and telex services. E.800 and
E.801 have been extended to cover other services such as facsimile over the Public
Switched Telephone Network (PSTN). Other ITU-T Study Groups have done
extensive work on QoS and NP for other services and network technologies. The
groups currently concerned with QoS aspects include:
Study Group 2: Operational Aspects of Service Provision, Networks and Performance
Study Group 4: Telecommunication Management, including TMN
Study Group 7: Data Networks and Open System Communications
Study Group 9: Integrated Broadband Cable Networks and Television and Sound
Transmission
Study Group 11: Signalling Requirements and Protocols
Study Group 12: End-to-end Transmission Performance of Networks and Terminals
Study Group 13: Multi-protocol and IP-based Networks and Their Internetworking
Study Group 15: Optical and Other Transport Networks
Study Group 16: Multimedia Services, Systems and Terminals
GB 917 v1.5
Page 101
The ITU-T has also produced a Handbook on QoS and NP that is a good
internationally approved reference. This was first published in 1984 and updated in
1993 [ITU-Hbk].
From 27 September to 6 October 2000, the ITU-T held its World Telecommunication
Standardization Assembly (WTSA) at which the names, structure and responsibilities
of the ITU-T Study Groups were revised. These are briefly described below, but they
may change as Study Groups settle down after the WTSA. The WTSA also
established a new Special Study Group on IMT-200 and Beyond, responsible for
studies relating to network aspects of International Mobile Telecommunications 2000
and beyond, including wireless Internet, convergence of mobile and fixed networks,
mobility management, mobile multimedia functions, internetworking, interoperability
and enhancements to existing ITU-T Recommendations on IMT-2000. It remains to
be seen if this new Study Group will also study aspects of wireless NP and QoS.
Information on ITU-T
http://www.itu.int/ITU-T.
activities
is
available
from
the
ITU-T
web
site:
I.7.1 ITU-T Study Group 2 Operational Aspects of Service Provision, Networks and
Performance
ITU-T Study Group 2 is responsible for a wide range of operational aspects including
service definition, numbering, naming and addressing and routing, human factors,
traffic engineering and resource assignment, performance and interworking. It is the
lead Study Group for service definition (including all types of mobile services),
numbering and routing, and should recommend QoS for each service and interact
with other Study Groups (e.g. Study Group 13) in this respect as required. Study
Group 2 should also recommend measures to be taken to assure operational
performance of all networks (including network management) in order to meet the inservice NP and QoS.
Performance-related Recommendations include the E.4xx, E.5xx, E.6xx and E.7xx
series on network management and traffic engineering, closely related to NP and
QoS, and the E.8xx series on QoS, e.g. Recs E.80042 and E.80143.
Study Group 2 also has two offshoots - the Network Management Development
Group (NMDG) and the QoS Development Group (QSDG - see section I.8). The
NMDG and QSDG provide forums outside of the ITU-T, which facilitate the sharing of
detailed information that would be considered commercially confidential in the more
formal world of the ITU. The QSDG has begun to focus much of its effort on QoS in
VoIP networks and services. Study Group 2 has recognized that the emergence of
IP-based networks has increased the need for focus on many issues including traffic
engineering (network dimensioning and controls for achieving QoS objectives), QoS
from both the end-user and network perspective, and network management
techniques
42
43
ITU-T Recommendation E.800 Terms and definitions relating to QoS and NP including dependability
ITU-T Recommendation E.801 Framework for service quality agreement
GB 917 v1.5
Page 102
Study Group 2 has developed close collaboration with the IETF on IP-related studies,
and is developing a new E.TE-series of Recommendations on Framework for Traffic
Engineering & QoS Methods for IP-, ATM- & TDM-based Multi-service Networks.
I.7.2
ITU-T Study Group 4 Telecommunication Management, including TMN

ITU-T Study Group 4 is responsible for studies regarding the management of
telecommunication services, networks, and equipment using the telecommunication
management network (TMN) framework. Additionally it is responsible for other
telecommunication management studies relating to designations, transport-related
operations procedures (including configuration, fault and performance management),
and test and measurement techniques and instrumentation. As lead Study Group for
TMN, Study Group 4 has the responsibility of ensuring consistent application of TMN
principles by all Study Groups in their development of TMN-related specifications.
Study Group 4 has a number of Working Parties, one of which is very focused on
operational performance and QoS. It takes the design NP and QoS long-term
objectives specified by Study Group 13 and develops practical operational end-to-end
objectives and allocations between network sections. Examples are the M.1300series Recommendations for PDH and SDH leased circuits and M.2100-series
Recommendations for digital paths and networks. New Recommendations in the
M.22xx and M.23xx series are being developed for ATM and IP networks and
services.
Study Group 4 also develops TMN performance monitoring, test and measurement
techniques, and test equipment specifications for characterizing QoS and NP on
network equipment, systems and services. Other groups within SG 4 develop TMN
Recommendations for overall network and service management, including the
procedures for exchanging performance information between NOs/SPs.
It was agreed at the WTSA to transfer studies on Customer Network Management
(CNM) from Study Group 7 to Study Group 4. A new Study Group 4 activity has been
started on management of Hybrid Circuit-switched/Packet-based Networks (HCPNs)
in partnership with ATIS T1, IETF and ETSI TC/TMN.
I.7.3
ITU-T Study Group 7 Data Networks and Open System Communications

ITU-T Study Group 7 was responsible for studies relating to data communication
networks and the application of open system communications standards including
networking, directory and security. It was the lead Study Group on frame relay and for
communication system security. At the TSAG (Telecommunication Standardization
Advisory Group) meeting in March 2001, it was decided to merge Study Groups 7
and 10 into one new Study Group 17 called Data Networks and Telecommunication
Software. This new Study Group retains the responsibilities and lead Study Group
status of Study Group 7 and adds those of Study Group 10 on technical languages
and methods, and software aspects of telecom systems.
Up until the WTSA, Study Group 7 had five Working Parties, one of which was
responsible for network and service characteristics including NP and QoS. In the new
study period, two Questions are specifically relevant, one on NP and QoS in FR and
GB 917 v1.5
Page 103
packet-switched data communication networks and another on end-to-end QoS

multicast communications. These include the likely support of selected network
services by FR, particularly IP-based services. Performance parameter definitions are
constructed that provide a common performance vocabulary for network providers
and end users. These parameter definitions include service availability and are useroriented. Objectives providing a floor of performance are provided for service
offerings. Examples for packet-switched Public Data Networks (PDNs) can be found
in Recs X.13444. X.13545, X.13646, X.13747, and X.14048. Estimation methods for
assessing NP may also be provided, e.g. Recs X.13849 and X.13950. (Note: this study
area has potential overlap with similar work in Study Groups 2, 4, 12, 13 and 16).
Study Group 7 is also responsible for Frame Relay standards coordination within ITUT, ISO/IEC and the Frame Relay Forum. It has proposed that all the FR protocolrelated Recommendations, e.g. X.36. X.76. Q.933, are handled in a single Question,
and that the scope of this work should include FR/ATM interworking. Closely related
to this are studies on FR QoS including Recommendations X.14451, X.14552, and
X.14653.
I.7.4 ITU-T Study Group 9 Integrated Broadband Cable Networks and Television and
Sound Transmission
ITU-T Study Group 9 is responsible for studies relating to the use of cable and hybrid
networks, primarily designed for television and sound programme delivery to the
home, as integrated broadband networks to also carry voice or other time-critical
services, video on demand, interactive services, etc., and the use of
telecommunication systems for the contribution, primary distribution and secondary
distribution of television, sound programmes and similar data services.
From its inception, Study Group 9 has initiated and continued to pursue studies on
cable networks. Originally, these networks were known as cable television networks
since the initial product offering was television and sound programmes to the
consumer. The evolution of technology coupled with deregulation has enabled these
cable TV networks to offer connection to PCs, the Internet and the PSTN. Thus, the
networks are increasingly seen as simply cable networks, where television is one of
the offerings available, and Study Group 9 is now the lead Study Group within ITU-T
for integrated broadband cable and television networks, and responsible for
coordination with ITU-R on broadcasting matters.
Study Group 9 already has a number of Recommendations in the J-series and Nseries on NP and QoS for sound programme and television networks and services.
44
ITU-T Recommendation X.134 Basis for defining packet-switched performance parameters

ITU-T Recommendation X.135 Speed of service (delay and throughput) performance values for PDNs
46
ITU-T Recommendation X.136 Accuracy and dependability performance values for PDNs
47
ITU-T Recommendation X.137 Availability performance values for PDNs
48
ITU-T Recommendation X.140 General QoS parameters for communication via PDNs
49
ITU-T Recommendation X.138 Measurement of performance values for PDNs
50
ITU-T Recommendation X.139 Echo, drop, generator and test DTEs for measurement of performance values
51
ITU-T Recommendation X.144 User information transfer performance parameters for data networks providing FR PVC
service
52
ITU-T Recommendation X.145 Performance for data networks providing FR SVC service
53
ITU-T Recommendation X.146 Performance objectives and QoS classes applicable to FR
45
GB 917 v1.5
Page 104
Some of these relate to NP of equipment and transmission links while others specify
QoS of the services themselves. In the new study period, two Questions are
specifically focused on QoS aspects.
I.7.5
ITU-T Study Group 11 Signalling Requirements and Protocols

ITU-T Study Group 11 is responsible for studies relating to signalling requirements
and protocols for IP-related functions, some mobility-related functions, multimedia
functions and enhancements to existing Recommendations on access and
internetwork signalling protocols of ATM, N-ISDN and PSTN. It is the lead Study
Group on intelligent networks.
Until the WTSA, Study Group 11 had five Working Parties, one or two of which deal
with some QoS issues such as signalling of QoS requirements. An example of this is
Rec. Q.2965.254 within the DSS 2 family of ITU-T Recommendations. In the new
study period, one Question is specifically devoted to signalling requirements for
flexible management of dynamic bandwidth and QoS demands in connection control.
Particular attention is also being drawn to the study of Bearer-Independent Call
Control (BICC), which defines a new protocol to establish a call (e.g. a voice call) to
be established on any bearer (e.g. IP connection, becoming a VoIP call).
I.7.6 ITU-T Study Group 12 End-to-end Transmission Performance of Networks and

Terminals
ITU-T Study Group 12 is responsible for guidance on the end-to-end transmission
performance of networks, terminals and their interactions, in relation to the perceived
quality and acceptance by users of text, speech, and image applications. This work
includes the related transmission implications of all networks (e.g. those based on
PDH, SDH, ATM and IP) and all telecommunications terminals (e.g. handset, handsfree, headset, mobile, audiovisual, and interactive voice response).
Within its general area of study, a particular focus of Study Group 12 is the end-toend transmission quality delivered using a path that, with increasing frequency,
involves new interactions between terminal types and network technologies (e.g.,
mobile terminals and networks with IP segments). As the lead Study Group on QoS
and Performance, Study Group 12 develops roadmaps for ITU-T activities in these
areas.
Until the WTSA, Study Group 12 had three Working Parties, two of which included
studies on NP and QoS. One studies subjective and objective assessment of audio
and video quality. The other studies transmission performance and planning.
I.7.7 ITU-T Study Group 13 Multi-protocol and IP-based Networks and Their
Internetworking
ITU-T Study Group 13 is responsible for studies relating to internetworking of
heterogeneous networks encompassing multiple domains, multiple protocols and
innovative technologies with a goal to deliver high-quality, reliable networking.
54
GB 917 v1.5
ITU-T Recommendation Q.2965.2 - DSS No.2 Signalling of individual QoS parameters
Page 105
Specific aspects are architecture, interworking and adaptation, end-to-end

considerations, routing and requirements for transport.
Study Group 13 has four Working Parties, each concerned with some aspects of NP
and QoS. WP 4/13 is the principal group dealing with performance, while WP2/13
deals with certain traffic engineering aspects closely related to QoS, e.g. Rec. I.37155
on traffic and congestion control in ATM networks. WP3/13 includes some studies on
OAM and network management also relevant to NP and QoS, e.g. Rec. I.61056 on BISDN. Much of SG 13s work in the past was concerned with N-ISDN and B-ISDN,
but it is now the lead Study Group within ITU-T responsible for the IP Project that
coordinates studies on all IP-related aspects across ITU-T. It is also the lead Study
Group for B-ISDN, GII and satellite matters. Some further notes follow on the
approach taken by Study Group 13 to specifying NP and QoS, using ATM as an
example.
NP events and parameters are specified as performance objectives in QoS classes
giving guaranteed performance for certain types of traffic. ITU-T Rec. I.371 specifies
network traffic and congestion control design principles in support of network
management and NP/QoS. For example, at the ATM network layer, Rec. I.371
specifies a limited set of ATM Transfer Capabilities (ATCs), each with a number of
QoS classes. An ATC is intended to support an ATM layer service model and
associated QoS through a set of ATM layer traffic parameters and procedures. ATCs
currently specified by ITU-T are Deterministic Bit Rate (DBR), Statistical Bit Rate
(SBR), Available Bit Rate (ABR) and ATM Block Transfer (ABT). A new ATC called
Guaranteed Frame Rate (GFR) has just been agreed for transporting FR over ATM.
Each ATM connection has an explicitly or implicitly declared ATC with a QoS class
that has values of Cell Error Ratio (CER), Cell Loss Ratio (CLR), Cell Misinsertion
Rate (CMR), Cell Transfer Delay (CTD) and Cell Delay Variation (CDV). The
definitions and measurement methods for these are internationally standardized (see
ITU-T Recs I.35657 developed in WP 4/13 and O.19158 developed in Study Group 4).
A Recommendation similar to I.371 on IP traffic and congestion control is currently
being drafted.
WP 4/13 specifies long-term NP and QoS in terms of events, parameters, objectives
and allocations between network sections. These are used as network planning and
design values. As mentioned above, these long-term objectives are taken by Study
Group 4 as the starting point to develop operational criteria. For the ATM case, the
values of the ATM performance parameters are defined for different traffic profile
parameters such as Peak Cell Rate (PCR), Sustainable Cell Rate (SCR), Mean Cell
Rate (MCR), Maximum Burst Size (MBS), Peak Emission Interval (PEI) and CDV
Tolerance (CDVT) within each ATC.
Traffic entering an ATM network is policed by functions of User Parameter Control
(UPC) at the User-Network Interface (UNI) or Network Parameter Control (NPC) at
the Network-Node Interface (NNI) between connecting operators. Traffic cells not
55
ITU-T Recommendation I.371 Traffic control and congestion control in B-ISDN

ITU-T Recommendation I.610 B-ISDN operation and maintenance principles and functions
57
ITU-T Recommendations I.356 - B-ISDN ATM cell transfer performance
58
ITU-T Recommendation O.191 - Equipment to measure the cell transfer performance of ATM connections
56
GB 917 v1.5
Page 106
conforming to the traffic contract get tagged or dropped. QoS commitments depend
on traffic conformance to the traffic profile or descriptor values specified in the
contract and also on correct UPC/NPC functioning. Even though user QoS
requirements may vary over a continuous spectrum of values, a network will only
handle a restricted set of QoS classes.
Similar approaches are now being developed for the IP network layer. Rec. Y.154059
(ex-I.380) specifies a framework for NP and QoS events and parameters. Rec.
Y.1541 (ex-I.381) is being drafted specifying performance objectives and allocations.
I.7.8
ITU-T Study Group 15 Optical and Other Transport Networks

Study Group 15 is the focal point in ITU-T for studies on optical and other transport
networks, systems and equipment. This encompasses the development of
transmission layer-related standards for the access, metropolitan and long haul
sections of communication networks. Particular emphasis is given to global standards
providing for a high-capacity (Terabit) Optical Transport Network (OTN) infrastructure,
and for high-speed (multi-Megabit) network access. Study Group 15 has been and
continues to be the lead Study Group on Access Network Transport (ANT) and has
produced the ANT Standardization Plan. It is also now the lead Study Group for
optical technology-related standards.
Clearly, Recommendations for equipment, systems and networks have a bearing on
NP and QoS delivered to the Customer. These include the G-series
Recommendations on compression and speech enhancement signal processing,
voice gateway, and ATM/IP transport network equipment.
Study Group 15 also cooperates closely with the IETF, particularly in the area of
management of transport networks, systems and equipment, and has three official
representatives to the IETF.
I.7.9
ITU-T Study Group 16 Services, Systems and Terminals

Study Group 16 is responsible for studies relating to multimedia service definition and
multimedia systems, including the associated terminals, modems, protocols and
signal processing. It is the lead Study Group on multimedia services, systems and
terminals and also for ebusiness and ecommerce.
Following the WTSA in the new study period, Study Group 16 is organizing its studies
in a matrix structure with eight so-called horizontal Questions covering Framework
Study Areas (FSAs) and thirteen so-called vertical Questions that are projectoriented to deliver Recommendations. One of the FSAs is an umbrella Question for
all multimedia studies called Mediacom 2004. Another FSA is QoS and end-to-end
performance in multimedia systems. Looking forward, multimedia services will be
frequently operated over packet networks that support various types of QoS features,
including but not limited to ATM QoS services and IP QoS services. The general topic
of how multimedia systems and codecs interact with and request QoS from the
network and how this relates to end-to-end performance will be studied under this
59
GB 917 v1.5
ITU-T Recommendation Y.1540 IP packet transfer and availability performance parameters
Page 107
FSA. Other FSAs include multimedia architecture, applications and services,

interoperability, media coding, security and accessibility.
Much of Study Group 16s work is focused on H-series Recommendations for
network terminal equipment whose specifications contribute significantly to NP and
QoS. However, their work includes definition of differentiated QoS IP services and
support of those and IP network reliability, integrity and availability. Study Group 16
has a goal to operate multimedia services over existing and evolving IP networks as
defined by the IETF, has identified needed network improvements, and is working
with IETF on these requirements. Many of the H-series Recommendations will be
referenced/co-numbered in the Y-series Recommendations for IP-based networks
and the GII.
I.8
Quality of Service Development Group

The Quality of Service Development Group (QSDG), a separate body but part of ITU,
attempts to coordinate QoS study across the ITU and with other bodies such as
EURESCOM. Set up by ITU-T Study Group 2, the QSDG holds meetings at least
once a year and publishes articles on QoS and SLAs four times a year in the QSDG
Magazine.
The QSDG has taken great interest in the use of IP to handle voice traffic and has
been discussing network monitoring to assess QoS for IP-based networks. The
QSDG has noted that users accessing IP-based networks, especially the Internet,
tend to have far longer call durations than normal voice telephony users. This may
have an impact on the QoS experienced by other users trying to gain access to
services. At a recent meeting, the QSDG noted the importance of the new telecom
operators, usually called virtual telcos, who do not have their own network, but
choose to resell capacity on those owned by others. This increases the need for
defining, monitoring and managing SLAs between operators.
The QSDG has established Task Groups on the following areas:
effectiveness and quality in multimedia;
Internet quality and performance issues;
correlation between QoS/NP parameters, perceived
satisfaction and network management controls/actions;
Customer
mobile issues;
QoS aspects of ISDN, ATM and IP including IN;
risk analysis;
operational aspects of fraud prevention and their impact on QoS/NP;
reliability and availability of networks and services;
ISO and its application to improving telecom services;
call clarity and transmission performance;
GB 917 v1.5
Page 108
use of CDRs for QoS/NP improvements.

The QSDG plans to work in partnership with ITU-T Study Group 2 on revising
Recommendation E.801 on Service Quality Agreements and on a new
Recommendation on Service Level Agreements. It is also working on developing a
simple QoS Index that can be used to qualify the QoS of ISPs and TSPs. The
QSDG also works closely with the Network Management Development Group
(NMDG), another offshoot of ITU-T Study Group 2.
The QSDG has recognized what it calls the semantic disparity problem of two
competing strains involved in mapping of the well-being of elements in the enterprise
infrastructure into the well-being of services. This can be summarized as:
Parameters that are easy for network specialists to measure do not
translate well into parameters that are readily understood by ordinary
Customers.
Parameters that are readily understood by consumers are not easy for
network specialists to measure.
Furthermore, as the demand for hosted applications continues to grow, Applications
Service Provider (ASPs) are taking steps to convince Customers that their hosted
applications will be delivered and will perform as promised. The rationale is
simple: as enterprises begin to look to ASPs to host more mission-critical
applications, they are also demanding a higher level of performance and
operational responsibility from their carriers. Application-specific SLAs tell IT
managers that their carriers are willing to guarantee availability or pay the price in
either a stiff penalty or a hefty service credit.
Information on the QSDG is available from its web site: http://www.qsdg.com.
I.9
Others
There are many other organizations and consortia that are addressing SLAs and
QoS to a greater or lesser extent. Those listed below are concerned with issues that
are relevant to SLA and QoS.
ASPIC
(Application
http://www.aspindustry.org/
Service
Provider
Industry
Consortium)
The ASP Industry Consortium is an international group of companies representing all

aspects of the ASP industry that was formed to promote the ASP industry by
sponsoring research, promoting best practices and articulating the measurable
benefits of the evolving ASP delivery model. The ASPIC Best Practices Committee
has produced A White Paper on Service Level Agreements, November 2000,
intended to provide SPs in general and ASPs in particular with information to help
them prepare, negotiate and provide their customers and partners with SLAs. The
document (which is available to ASPIC members only) provides four SLA templates
covering network, hosting, application, and Customer care / help desk. Each of these
GB 917 v1.5
Page 109
templates consists of a set of SLA elements, metrics and, whenever available and
practical, industry ranges and calculation criteria.
ATM Forum: http://www.atmforum.com
The ATM Forum was formed in 1991 and is concerned with promoting the use of
ATM products and services through a rapid convergence of interoperability
specifications. Its members represent all aspects of the industry, equipment
manufacturers, service providers, software vendors, government and research
organizations, users and consultancies. It has a Technical Committee which consists
of several working groups investigating different areas of ATM technology. It has
developed technical interoperability specifications for ATM products and services,
including testing and management.
Cross-Industry Working Team (XIWT): http://www.xiwt.org
The XIWT is a membership organization of communications, computer systems,
information and service providers that are either U.S. companies or companies with a
significant amount of business in the U.S. It was founded to develop a common
technical vision for the National Information Infrastructure (NII). It promotes the
exchange of information and ideas and the dissemination of XIWT results at
workshops that it organizes. It has a number of Working Teams to research selected
issues in depth and to prepare white papers that can accelerate the evolution of the
NII by establishing a common understanding about the technical issues. The Internet
Performance Working Team has developed a common set of metrics and a common
measurement methodology that can be used to assess, monitor, negotiate, and test
compliance of service quality on the Internet. It has published two white papers in the
area of performance and QoS. Customer View of Internet Service Performance:
Measurement Methodology and Metrics, September 1998, outlines and discusses
various metrics for measuring Internet and IP performance along with a measurement
architecture and methodology. Examples in the document include Service Level
Agreement Monitoring, ISP Performance Comparison and Virtual Private Networking.
Internet Service Performance: Data Analysis and Visualization, July 2000, uses the
methodology outlined in the first paper in order to collect Internet performance data
which can be used to provide an insight into Internet performance.
DMTF (Distributed Management Task Force): http://www.dmtf.org
The DMTF was founded in 1992 and is an industry organization leading the
development, adoption and unification of management standards and initiatives for
desktop, enterprise and Internet environments. Its members are principally vendors of
hardware and software for PCs and their components. The DMTF is active in various
areas, including specification of the Desktop Management Interface (DMI), Common
Information Model (CIM), XML standards supporting the CIM, Web-based Enterprise
Management (WBEM), Directory Enabled Networks (DEN) and some support
standards for customer support and help desk applications. It has a number of
technical working groups supporting this work. In conjunction with the IETF Policy
Framework working group, the Service Level Agreement Working Group has
developed the CIM Core Policy Model for the CIM Schema, which was released as
version 2.5 in February 2001. The CIM Core Policy Model provides an extension to
the CIM for representing policy information. It is intended to support the specification
GB 917 v1.5
Page 110
of policies so that the service levels agreed in a SLA can be mapped to the devices in
a system in order to achieve the delivery of a service at the required level. The
Network Working Group has developed the CIM QoS Device Sub-Model for the CIM
Schema. This sub-model supports the use of policy to configure network systems by
providing a model of the network elements that need to be configured to achieve a
specified level of service. The work is currently focused on modeling the DiffServ
capabilities of network devices.
DSL Forum: http://www.adsl.com
The DSL Forum was formed in 1994 to provide information about DSL technologies,
their environment and the market. Its members include equipment suppliers, service
providers, testing/management suppliers and consultants. It promotes DSL by
providing both technical and marketing assistance to encourage its deployment. The
technical work is divided into separate working groups, including an Operations and
Network Management Group and a Testing and Interoperability Group.
Frame Relay Forum: http://www.frforum.com
The Frame Relay Forum was incorporated in 1991 as an association of vendors,
carriers, users and consultants committed to the education, promotion, and
implementation of Frame Relay in accordance with international standards. The
Technical Committee is responsible for the Frame Relay Forums formal approved
implementation agreements. One agreement of relevance is the Service Level
Definitions Implementation Agreement, FRF.13, August 1998. This implementation
agreement defines a reference model and service metric definitions for transfer
parameters that describe frame relay service performance.
Internet2: http://www.internet2.edu
Internet2 is a research and development consortium based in the U.S. that is
developing and testing advanced network technologies and applications that can then
be deployed in the global Internet. It is led by universities in cooperation with industry
and government and research organizations. Its work is undertaken in working
groups, which are associated with one of three technical areas: Engineering,
Middleware, Applications. The Quality of Service Working Group is concerned with
investigating the QoS needs for Internet2. It is involved in the QBone project, which is
an inter-domain testbed for DiffServ that seeks to provide the higher education
community with end-to-end services that can support the QoS requirements of
emerging advanced networked applications in teaching and research, such as
distance learning and remote instrumentation control. The Working Group has
available on the web site a number of presentations and papers, including QoS
Requirements for Internet2, April 1998, and QBone Architecture, August 1999.
Internet Operators Group (IOPS.ORG): http://www.iops.org
The IOPS.ORG was formed in 1997 by Internet service providers in the U.S. with the
aim of making the commercial Internet more robust and reliable. It is focusing on
resolving and preventing network integrity problems and is addressing issues that
require technical coordination and technical information sharing between ISPs. To
achieve these goals, it supports engineering analysis, system simulation and testing,
GB 917 v1.5
Page 111
and interaction with other groups and organizations. The technical work is performed
by working groups. One of its documents, Common Definitions and Methodologies
for Inter-Provider Packet Loss and Round Trip Delay, November 1999, provides
common definitions and proposes recommended methodologies for measuring
packet loss and round trip delay in order to facilitate inter-provider communications
when dealing with inter-provider performance issues.
ITAA (Information Technology Association of America) http://www.itaa.org
ITAA is an association representing a broad spectrum of the U.S. IT industry. In 2000,
the ITAA produced a set of SLA Guidelines for the ASP Industry - ITAA ASP SLA
Guidelines. These SLA Guidelines identify some of the key issues to be considered
when negotiating a SLA.
ITU-R (ITU Radiocommunication Sector): http://www.itu.int/ITU-R
ITU-R was established in 1993 and is responsible for all ITUs work in the field of
radiocommunications, including the characteristics and performance of radio
systems. Its work is undertaken in a variety of Study Groups which develop draft ITUR Recommendations concerning radiocommunication services and systems.
MPEG (Moving Pictures Coding Experts Group): http://www.cselt.it/mpeg
MPEG was created in 1988 to develop standards for the coded representation of
moving pictures, audio and their combination. It operates within the framework of the
Joint ISO/IEC Technical Committee (JTC 1) on Information technology and is formally
WG11 of SC29. Members are experts accredited by the National Standards Bodies
and represent companies from all industry domains with a stake in digital, audio and
multimedia. The technical work is undertaken at MPEG meetings. MPEG subgroups
are focused on particular aspects of the work and includes a test subgroup which is
concerned with the development of methods for, and the execution of subjective
assessment tests of, the quality of coded audio and moving pictures both individually
and combined. The results of its performance tests are published on the MPEG web
site.
NMDG (Network Measurement Development Group):
NMDG is part of ITU-T Study Group 2 (Network and Service Operation) and operates
directly under Working Party 2/2 (Network and Service Assessment). The Group
provides advice and guidance on network management, particularly in the E.410
series of Recommendations.
Open Group: http://www.opengroup.org
The Open Group was created to establish assurance of conformance to Open
Systems standards through the testing and certification of suppliers products. Its
members are IT vendors and buyers representing both government and commercial
enterprises. It works in three main areas: mobile and wireless communications,
enterprise integration, the use of UNIX as a platform. It has set up a Quality of Service
Task Force, which met for the first time at the Open Group meeting in October 2000.
The mission of this group is to further QoS guarantees throughout the end-to-end
GB 917 v1.5
Page 112
delivery of information, and this is being examined both from the network perspective
as well as from the perspective of the service and the application. Three working
groups have been established: technical, policy, and business, each looking at
specific issues related to the interests of the Task Force, including work on SLAs.
QoS Forum (QOSF): http://www.qosforum.com.
The QOSF is an international, industry forum created to accelerate the adoption of
standards-based QoS technologies, products and services in the global Internet and
enterprise networks. Its members are mainly telecommunication and IT equipment
and software vendors. Utilizing a comprehensive set of education, marketing and
testing services, the goal of the QOSF is to educate the market and facilitate the
deployment of QoS-enabled IP products and services. It does not specify standards
but works with standards bodies, such as the IETF. The QOSF has a number of
groups concerned with managing, marketing and contributing technically to the
QOSF. The Technology Working Group is responsible for the QOSFs technical
projects, contributing to white papers, the technical resource center and other
technical content produced by the QOSF. The QOSF has published a number of
white papers and other documents related to Internet QoS, such as Quality of Service
Glossary of Terms, May 1999, QoS Protocols and Architectures, July 1999, The
Need for QoS, July 1999, and Introduction to QoS Policies, July 1999.
GB 917 v1.5
Page 113
Annex A: eBusiness SLA

Management
A.1
Introduction
This annex addresses the SLA issues particular to services requiring ultra-high
availability, a requirement that exists for an increasing number of ebusinesses. The
ubiquity of universal voice interconnections between disparate systems now applies
to data services globally. This annex addresses data, multimedia and voice service
requirements as they are increasingly provided over the same backbone networks.
A.1.1 Background
eBusiness (or ecommerce) requires special attention for SLA management. The
telecommunication industry is now in a third phase of maturity.
In phase one (1960-1970s) a Customer simply purchased a telecommunication
service as only one of a number of services that was useful for the normal operation
of the business. In this phase telecommunications was not essential to the day-to-day
operation of the business and was ordered through a regular purchasing process.
Essentially, the loss of the service for a day fell into the severe nuisance category.
In phase two (1980-1990s) telecommunication services became one of a number of
vital components for the business operation. In this phase, telecommunication
management was assigned to a senior (Director) level manager. Global business
considerations increased the importance of top management attention. Loss of
service for a day created problems primarily related to business internal operations.
In phase three (2000 - >>>) the loss of telecommunication service seriously
jeopardizes business survival. The reliability of telecommunication services is
highlighted in the CEOs business plan. The following are offered as examples.
1) A business where the telecommunication service is the primary product ordering
(transaction delivery) mechanism to the Customer, such as a web-based stockbroker.
2) A business where the telecommunication service is the only product delivery
mechanism, such as downloaded software, music, etc.
3) Where an essential business process depends on a telecommunication service,
such as a car manufacturers automated order processing system with all vendors
connected over a private network.
GB 917 v1.5
Page 114
Historically, SPs and Network Operators used SLAs to ensure the quality of their networks.
Typical metrics describing the network performance are network availability, data loss, and
transmission delay.
The rise of the ASP models (as one example of an ebusiness SP); the evolution of
ecommerce and the maturity of network infrastructure have raised the service expectations of
end users. Due to the newness of the ebusiness industry, there are few documented or
benchmarked trends to serve as industry standards. As awareness of ebusiness benefits
increases, industry experts expect that SLAs will become the leading purchasing factor60.
In addition to defining SLAs, the ebusiness SP must determine what level of service to
guarantee to its Customers. These decisions should take into consideration the business risk
assumed by the SP for guaranteeing a particular level of service to the end user.
Business risk can be broken into two distinct categories: risks within the control of the SP and
those outside of its control. In order to guarantee a particular level of service, the ebusiness
SP must determine the potential risk factors within its control and those which are not.
The ebusiness SP should decide the contents of a SLA only after careful evaluation of all of
its performance risk factors and their respective causes. Ultimately, the price of a delivered
service should reflect the SLA conditions as well as the SP performance risk.
A.1.2 Definition
For the purposes of this Handbook, the following definition applies:
An ebusiness is a business where the impact of even a short loss of any
telecommunication-related service will cause severe loss of revenue and may
even threaten the survival of the business.
Where a business does not require ultra high availability, the main Handbook applies.
A.1.3 SLA Groups

The range of players potentially involved in the ebusiness value chain with SLAs
include:
Application Service Provider (ASP). The ASP expertise lies in IT
management for hosting particular services or applications, or in
storage and management of its Customers data.
Independent Software Vendor (ISV). The ISV is an expert in the
software or content that end users use to be efficient, effective and
speedier to market.
Application Infrastructure Provider (AIP). The AIP is a company
that has expertise in managing very large, highly capital-intensive
data centers.
60
GB 917 v1.5
This and the following paragraphs as well as section A.1.3 are based on work undertaken for [WP-SLA].
Page 115
Network Service Provider (NSP). The NSP is a company that

provides and manages network resources.
Service Portal. A service portal is a new and emerging function.
Service portal companies have expertise in the management and
retention of Customers for the ASP value chain.
Service Aggregator. Service aggregator is a variant of service portal;
it provides links to other application providers and/or acts as a
reseller, combining multiple applications into a single service or
service bundle.
Value Added Reseller (VAR). The VAR is a distributor of products,
which also provides additional services such as training and
integration services.
System Integrator. System integrators carry out technical integration
work to ensure that new software solutions integrate seamlessly with
a Customers existing information systems.
Back Office Provider. Back office companies provide specialist
solutions that help ebusiness SPs in managing their internal functions.
A typical way to classify ebusiness SPs is according to the specific functions they
provide. In Figure A.1 three classes of SPs are shown: network, hosting, and
applications with the associated help desk and business expertise. However, despite
the many business partners involved in providing the services that facilitate an
ebusiness transaction, the company with the direct contractual relationship to the end
user bears all of the risk associated with that particular transaction.
Help Desk,
Problem Resolution
Business, Industry and

Solution Expertise
Applications Management, Operating Systems,

Databases and Middleware
Data Center Facilities, and Server Hardware
Network and Connectivity
Figure A.1: Classification of eBusiness Service Providers

Any incidents affecting service that impact the purchasing and delivery of an
ebusiness application are usually attributed to the company with the contractual
relationship to the Customer, regardless of which party is at fault. The fair allocation of
risk among business partners is one way an ebusiness SP or NSP can make certain
representations of warranties to its Customers.
GB 917 v1.5
Page 116
A.1.4 Scope
This annex expands the SLA parameters already discussed in the Handbook and
identifies and develops additional SLA parameters and processes required by
ebusiness. The work in this annex will build upon sections within the body of the
Handbook. Neither the industry nor the Handbook addresses consequential
damages.
The annex introduces two topics primarily associated with ultra-high availability: 1)
multiple SPs and 2) Common Point of Failure.
A.2
Business Drivers for SLA/QoS
A.2.1 Interdependence
Business to Business (B2B)
Past business requirements for telecommunication services tended to be
within a closed system: the business itself or a small set of related
businesses.
The advent of ebusiness has changed this paradigm to one where a business
has little or no control over or correlation with the system(s) other businesses
(or individuals) may utilize in accomplishing connectivity.
Telecommunication is now an open system where the ebusiness desires
many off-net accesses (for business purposes, i.e. buying and/or selling). The
demand for disparate systems to inter-operate independently is a key
objective. Loss of access cannot be tolerated even at an individual instance
(Customer) nor at the ebusiness service aggregation location. An individual
instance (Customer access unavailability) has been shown to take their
business elsewhere, therefore the business is truly lost.
Internal business organization
An ebusiness may outsource the entire telecommunication services
component because it cannot be economically supported in-house. Because
of the explosive scalability requirements, based on success, outsourcing
affords and enables rapid infrastructure deployment. In fact, an increasing
number of ebusinesses act as an integrator of services, which constitutes the
ebusiness itself. Therefore, the ebusiness may have little expertise in
telecommunications.
Service components
Special treatment of service components applicable to an ebusiness is for
further study.
GB 917 v1.5
Page 117
A.2.2 Economic Considerations

Mass Market for ultra-high reliability
Telecommunication services have been available for years to a select
Customer base able to pay the necessary (high) price for ultra-high
availability. These solutions have most often taken advantage of redundancy
to obtain higher levels of reliability rather than endeavor to specify
unrealistically high reliability for a single service.
Figure A.2 shows the impact of redundant services on increased availability
on a per day basis. Dual services reduce down time by half. Significant
improvement is achieved with three (or more) services. This statistical
treatment assumes entirely independent services with no Common Point of
Failure (CPoF).
Base Service
Availability
90%
95%
98%
99%
Dual Service Redundancy
Down Time
2.4 Hrs
1.2 Hrs
29 Min
14 Min
Availability
95%
97.5%
99%
99%
Down Time
1.2 Hrs
36 Min
14 Min
7 Min
Triple Service Redundancy

Availability
99.67%
99.92%
99.98%
99.997%
Down Time
4.8 Min
1.2 Min
12 Sec
3 Sec
Figure A.2: Availability for Services with Varying Redundancy (over 24 hours)
Cost tradeoffs
Ultra-high availability requirements must examine the crossover between the
higher cost of a single high reliability service and the total cost of several
lower cost services having individually lower reliability requirements. This cost
analysis should include the internal cost associated with managing and
supporting multiple services by the Customer (or using an outsourced entity,
e.g. a server farm from an AIP).
Experience gained by the telecommunication industry providing multiple
services to a select market at a price associated with custom systems will
now help produce more readily available multiple service solutions at a lower
cost associated with a standard product offering. This annex suggests that
multiple service provider solutions will move rapidly down the cost scale and
soon become economically available to an increasing number of
ebusinesses.
GB 917 v1.5
Page 118
A.3
Technical Considerations
A.3.1 Common Point of Failure

Reliability
All components will fail. Reliability calculations are available for virtually any
telecommunication component. Networks are designed to provide redundant
paths, e.g. SDH/SONET, as restored essentially instantly even for a cable
dig. Multiple path routing is built into the IP networks. Switching at the packet
level achieves the same result as switched routing. The problem is typically at
the edge (access point).
Cost tradeoffs
When an ebusiness requires ultra-high availability, careful attention to the
cost implication of SLA parameters is needed. Very tight SLA parameter
values carry an associated higher cost. Alternative technical solutions should
be investigated thoroughly to assess whether the increased SLA parameter
specification represents the best system solution. Care must be taken by the
SP and the user so that the required service availability is clearly defined.
Changing a single parameter or value may create unintentional
consequences in other processes.
An example of an increasingly common technical solution to achieve faster
response time and increased reliability is redundancy through distributed (and
mirrored) databases and systems infrastructure. This solution has an
associated cost that places specific requirements on the interconnecting
network. This architecture places a different impact on SLA parameter
specification.
Internal - external
Internal CPoF for all business processes must be included in the analysis.
When external CPoF is considered, an associated internal redundancy is
required only to aggregate the individual external services.
A.3.2 Process Automation

The parameter framework in the Handbook, Chapter 4, describes two parameter
sets: 1) Single User Instance and 2) Aggregated Requirements. Each of these
parameter sets is associated with different time scales. This section addresses the
specific issues that differentiate the requirements for an ebusiness SLA management
system.
Single User Instance (SAP-related)
This parameter set is generally recognized as the primary source of trouble
calls and individual Customer satisfaction. Therefore, the SLA directs special
attention to the Single User Instance parameters. Manual support systems
seldom achieve faster response than 15 minutes. Therefore the implication of
GB 917 v1.5
Page 119
very tight SLA response time parameters (i.e. to trouble calls) requires
automation. Experience shows that response better than 15 minutes requires
automated processing, especially for fault recovery. SLA events that have the
potential of becoming SLA violations require immediate action and process
automation is required.
eBusiness requires availability to be specified over extremely short time
intervals (minutes instead of days), therefore service support systems must
be highly if not totally automated to achieve ultra-high availability. When the
SP automates backup and/or alternate routing, the Customers systems must
automatically compensate as well. Otherwise SLA performance targets are
not achieved. Therefore the automation of processes is necessary for both
the SP and the Customer.
Aggregate Requirements
This parameter set is generally a historical picture of performance. Special
requirements for the support of ultra-high availability services fall into a
necessity for immediate access to various reports and the automatic
generation of reports when a threshold is exceeded (or approached).
Access to Process Automation
The motivation for overall SLA management is described in Chapter 3. The
assumption here is that ebusiness (Customers) will have access, via the web,
to a controlled set of information and functions determined by the SP. The
objectives of process automation are marketing of the SP services, offering
additional services for revenue generation, and reducing the cost of delivering
SLA information to the Customer. Differentiation for ebusiness is to be
examined for the following:
Customer education of available services with SLA levels

Self-service selection based on predefined SLA templates
Information about speed to supply service
Customer-driven service modification of SLA parameters
(within a pre-agreed set)
Customer query of SLA performance status
A.3.3 Security
The topic of security is important. Two questions are posed without answers at this
time:
1) How could a SLA reflect security?
2) How could ebusiness security differ from security for any other business?
These questions are to be considered at a later date.
GB 917 v1.5
Page 120
A.3.4 Checklist and Guidelines

This section will contain specific ways to specify multiple SP solutions.
Multiple SP solution
The main consideration of multiple services is to achieve zero Common Point
of Failure. A SLA parameter in this case will be a guarantee that no CPoF
exists between SP xxx and SP zzz. This capability now exists, but not visible
is the production scale necessary to support a major industry move toward
this architectural solution61.
61
One potential impact for the telecommunication industry may be the necessity for interchange of sub-sets of provisioning
information between SPs.
GB 917 v1.5
Page 121
Annex B: Guidelines for Catalyst

Project Input to the Handbook
Note: Annex B will provide examples of SLA use from the catalyst projects. The text
currently in this annex comprises the guidelines issued to the catalyst project teams
concerning their input to this annex.
B.1
Introduction
The work of catalyst projects that (scope) measure and/or report SLA parameters will
be included as annexes to the SLA Handbook. This annex suggests a format in
which the results of catalyst projects will be documented for later inclusion within the
Handbook.
The SLA Management team Charter states that:
To provide correlation between the Process Automation and Catalyst work,
the catalyst teams reports related to the scope of the SLA/QoS Management
project will become annexes to the SLA/QoS Management Handbook. The
SLA/QoS team will provide editing assistance to format the report into an
annex, but will not undertake rewriting the entire catalyst report into annex
form.
The interface is desired to be two-way. Catalyst teams may request assistance with
SLA parameters from the Handbook team or may be demonstrating parameters that
have not been addressed within the Handbook. The Handbook team may request
additional development of a parameter by the Catalyst team.
A simple yet effective method or framework is needed for interaction between the
Handbook team and the Catalyst teams to effect the objective described above. The
framework described below is proposed to achieve this purpose with a minimum of
specification.
B.2
Parameter Framework
Figure B.1 illustrates how the SLA parameters that are visible to a Customer and
covered by the SP-Customer SLA agreement can be categorized (#1-#6).
The top row describes three types of parameters related to the contracted service:
GB 917 v1.5
Page 122
1) Technology-specific, 2) Service-specific, and 3) Technology & Serviceindependent

Some services may contain both technology-specific and service-specific
parameters, some may contain only one or the other. A variety of examples is being
developed.
The two rows describe two types of impact on the Customer:
1) Single User Instance (SAP-related) and 2) Aggregated Instances
Parameter Category
Technology-specific
Service-specific
Service Perspective
Technology/Serviceindependent
Single User Instance

(SAP-related)
#1
#2
#3
Aggregated
Instances
#4
#5
#6
Figure B.1: Framework for Parameter Categories

This parameter framework provides guidance for six categories of parameters while
specifically addressing the parameters related to an individual user. As an example of
the difference between a Single User Instance and Aggregated Instances: when
availability is specified over a billing period, it would be possible for a single outage to
shut down an individual user entirely yet still meet the aggregated instance
requirement. In this example the Single User Instance parameter would define the
maximum down time for a single event and the minimum time between events. This
detail may be lost when working at the Aggregated Instance level.
B.3
Examples
B.3.1 IP Service with DSL Access

The team then considered the example of an IP service (including a bundle of
service elements) with DSL access to a corporate network (see Figure B.2).
GB 917 v1.5
Page 123
Parameter Category
Technology-specific
Service-specific
Service Perspective
(SAP-related)
Aggregated
Requirements
e.g. speed
e.g. delay, throughput
e.g. availability, max.

time to restore
e.g. total UAS
e.g. delay distribution
e.g. MTBF, MTTR,

MTRS
Figure B.2: IP Service with DSL Access Parameter Framework Example
B.3.2 ATM Cell Delivery

Another example considered was an ATM cell delivery service where technologyspecific and service-specific parameters are the same (see chapter 4). These ATM
parameters are specified against a set of traffic profile parameters for a particular
contracted ATC, e.g. DBR (see Figure B.3)
Parameter Category
Technology-specific
Service-specific
Service Perspective
(SAP-related)
Aggregated
Requirements
e.g. CER, CLR, CTD CDV - all max. values
e.g. availability, max.

time to restore
e.g. CER, CLR, CTD CDV - all mean values and

totals
e.g. MTBF, MTTR,

MTRS
Figure B.3: ATM Cell Delivery Service Parameter Framework Example
GB 917 v1.5

PDF 00009

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PDF 00009

Hochgeladen von

Copyright:

Verfügbare Formate

SLA Management Handbook

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

About TeleManagement Forum

Enabling the development of a market and real products for

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

About this document

Document Life Cycle

December 12, 1999

May 18, 2000

Provided for discussion at the Nice meeting

May 29, 2000

Updated at the Nice meeting

To provide the outline for the first draft version

Release for Member Evaluation

Updated at the Washington meeting

November 16, 2000

Updated at the Chicago meeting

Evaluation version for members only

Updated after the Paris and Nice meetings

Public Evaluation Version

TeleManagement Forum 2001

SLA Management Handbook

How to obtain a copy

How to comment on this document

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

Chapter 4 QoS and the SLA Parameter Framework.............................................................................. 31

TeleManagement Forum 2001

SLA Management Handbook

ATM Cell Delivery Service ....................................................................................................76

TeleManagement Forum 2001

SLA Management Handbook

A.3 Technical Considerations ........................................................................................................... 118

TeleManagement Forum 2001

SLA Management Handbook

TeleManagement Forum 2001

SLA Management Handbook

Figure 7.6: Multiple Domain SLA Relationships Example 1 .............................................................. 72

TeleManagement Forum 2001

SLA Management Handbook

Figure 1.1: Service Delivery Relationships

TeleManagement Forum 2001

SLA Management Handbook

The main focus of this Handbook is on business Customers.

TeleManagement Forum 2001