Professional Documents
Culture Documents
PDF 00009
PDF 00009
GB 917
Public Evaluation/Version 1.5
June 2001
Page ii
GB 917 v1.5
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
to
support
the
GB 917 v1.5
Page viii
GB 917 v1.5
Page ix
Document History
Version
Date
Version 0.1
August 7, 1999
Purpose
Version 0.2
Version 0.3
Version 0.4
Version 0.5
July 4, 2000
Version 0.6
August 8, 2000
Version 0.7
November 2, 2000
Version 0.8
Version 1.0
November 2000
Version 1.1
June 2001
Version 1.5
June 2001
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.
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
GB 917 v1.5
7.4.3
7.4.4
7.4.5
7.4.6
Page xv
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
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
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
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
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
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.4
Document Outline
Chapter 2
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
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
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
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
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
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
GB 917 v1.5
Page 7
GB 917 v1.5
Page 8
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
(ITU-T Rec. M.2140).
*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
(ITU-T Rec. M.2140).
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
GB 917 v1.5
Page 12
GB 917 v1.5
Page 13
GB 917 v1.5
Page 14
GB 917 v1.5
Page 15
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
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
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
3.3
Business Benefits
GB 917 v1.5
Page 18
GB 917 v1.5
Page 19
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
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
Perf
Net.Perf.
Traffic Metrics
SLA violations
Event
Common Objects
Billing
Net.Perf.
Traffic Data
Network
Elements
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.
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.
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.
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
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
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
User
www+
User
Access
Network
www+
User
www+
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.
GB 917 v1.5
Page 30
GB 917 v1.5
Page 31
4.1
Parameter Classification
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
Support
Performance
Serveability
Performance
Operability
Performance
Integrity
Performance
QoS
QoS
NP
NP
Trafficability
Performance
Availability
Performance
Propagation
Performance
Transmission
Performance
GB 917 v1.5
Page 33
Network Performance
User-oriented
Provider-oriented
Service attribute
Connection element
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.
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
Technology-specific
Service-specific
Technology/Service independent
Single User
Instance
(SAP-related)
Aggregated
Requirements
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
Technology/Service independent
Single User
Instance
(SAP-related)
e.g. speed
Aggregated
Requirements
Technology-specific
Service-specific
Technology/Service independent
Single User
Instance
(SAP-related)
Aggregated
Requirements
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.
GB 917 v1.5
Page 39
GB 917 v1.5
Page 40
Measure
Availability
Estimation
Units
Example
Up-times x 100
(%)
99.9%
(%)
0.1%
(hours)
Up-times + Down-times
Unavailability
Down-times x 100
Up-times + Down-times
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.
GB 917 v1.5
Page 42
Performance
Level
Engineered Level
Performance
Sets
Delivered Level
Guaranteed Level
Gold
Silver
Bronze
Grade of 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
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.
GB 917 v1.5
Page 45
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.
GB 917 v1.5
Page 47
4.4
GB 917 v1.5
Page 48
GB 917 v1.5
Page 49
5.1
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
GB 917 v1.5
Page 50
What parameters?
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.
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
Improvement Potential
GB 917 v1.5
Page 52
5.2
GB 917 v1.5
Page 53
Sales
Order
Service
Planning
Develop
Service
Config
6
4
Service
Quality
Mgmt
Rating
Discount
Network
Data
Mgmt
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
Sales
Order
Service
Planning
Develop
Service
Config
9
10
11
12
Service
Problem
Resolve
Service
Quality
Mgmt
Network
Maint
Restore
Rating
Discount
Network
Data
Mgmt
GB 917 v1.5
Page 56
Sales
Order
2
4
5
6
3
Service
Planning
Develop
Service
Config
Service
Quality
Mgmt
Rating
Discount
Network
Data
Mgmt
5.2.3 Implementation
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
Sales
Order
Service
Planning
Develop
3
4
Service
Config
Service
Quality
Mgmt
7
6
Rating
Discount
Network
Data
Mgmt
GB 917 v1.5
Page 58
Sales
Order
Service
Planning
Develop
Service
Config
Service
Problem
Resolve
Service
Quality
Mgmt
Rating
Discount
3a
2
1
Network
Data
Mgmt
1a
arrive
from
the
service-providing
Alarms that represent the failure of a component that affects the service
of one or more Customers.
GB 917 v1.5
Page 59
10
Sales
Order
Service
Quality
Mgmt
Network
Maint
Restore
Service
Planning
Develop
Service
Config
Rating
11
9
Discount
Network
Data
Mgmt
GB 917 v1.5
Page 60
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
1a
Service
Planning
Develop
Order
Service
Config
Service
Quality
Mgmt
Rating
Discount
1c
1b
Network
Data
Mgmt
GB 917 v1.5
Page 62
GB 917 v1.5
Page 63
6.1
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
Implementation
Network
Maintenance
& Restoration
Application
& Server
Performance
Data Collection
Process
Performance
Data Collection
Network Data
Technology
Performance
Management
Data Collection
GB 917 v1.5
Page 64
6.1.3 Implementation
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.
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
& Server
Application
& Server
Performance
Data Collection
Process
Performance
Data Collection
6.2
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
GB 917 v1.5
Page 67
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
GB 917 v1.5
Page 68
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
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
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
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
Commercial Offer
1
defines service
level objectives for
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
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).
Service 1
Service 2
Service 3
Access
Provider
Service 6
Service 5
Service 4
Network
Service
Provider
Network
Service
Provider
GB 917 v1.5
Page 72
SLAa
SLA1
SLAb
Service
Provider 2
SLA2
Service
Provider 1
SLA3
SLAc
Customers
SLAa
SLAb
Service
Provider 2
SLA4
Service
Provider 1
SLAc
Customers
GB 917 v1.5
Page 73
Service Contract
1
0..*
1..*
Commercial Offer
0..*
1..*
relates to
defines service
level objectives for
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
7.3
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
7.4
11
GB 917 v1.5
Page 75
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Technologyspecific
Service-specific
Technology/Service
-independent
Total unavailability
seconds
Aggregated
Requirements
MTBF
MTTR
MTTP
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
Aggregated
Requirements
Technology-specific
Service-specific
Technology/Service independent
Max. unavailability
time for an access
line
Max. Time To
Restore
Minimum Time
Between Failures
Max. unavailability
time for all the access
lines
MTBF
MTTR
MTTP
GB 917 v1.5
Page 77
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Service-specific
Technology/Service independent
Max. unavailability
time for a PVC
Max. Time To
Restore
Minimum Time
Between Failures
Max. unavailability
time for all the PVCs
MTBF
MTTR
MTTP
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
Aggregated
Requirements
Technology-specific
Speed
Total UAS
Service-specific
Technology/Service independent
Max. IP Packet
Transfer Delay for a
particular access
Max. unavailability
time for an access
line
Max. Time To
Restore
Minimum Time
Between Failures
Max. IP Packet
Transfer Delay for all
the accesses
Max. unavailability
time for a particular
Customer site
Mean IP packet
Transfer Delay for a
particular Customer
site
Max. unavailability
time for all the access
lines
MTBF
Mean IP packet
Transfer Delay for a
particular access
MTTR
MTTP
Mean IP Packet
Delay Variation
Mean IP Packet
Throughput
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
framework as described by the examples provided in Figure 7.14.
Parameter Category
Service
Perspective
Single User
Instance
(SAP-related)
Aggregated
Requirements
Technology-specific
Max. IP Packet
Transfer Delay from
Customer access
Mean IP packet
Transfer Delay from
Customer access
Mean IP Packet
Delay Variation
Mean IP Packet
Throughput
Service-specific
Max. unavailability
time for an access
line
Max. Time To
Restore
Minimum Time
Between Failures
Mean unavailability
time for all the service
bundle
MTBF
MTTR
MTTP
Mean Service
Content Transfer
Delay
Technology/Service independent
Mean Service
Content Delay
Variation
Figure 7.14: IP Service with DSL Access Service Parameter Framework Example
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
Technology/Service independent
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]
[E.801]
[FRF.13]
[GB 910]
[I.371]
[ITU-Hbk]
[M.60]
[M.2140]
[NMF 503]
[P806]
[TMF 701]
[WP-SLA]
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
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
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
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
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
GB 917 v1.5
Page 88
GB 917 v1.5
Page 89
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
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
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
GB 917 v1.5
Page 94
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
I.5.1
15
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
I.5.3
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
I.5.5
I.5.6
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
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
I.7.3
GB 917 v1.5
Page 103
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
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
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
Page 105
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
I.7.9
GB 917 v1.5
Page 107
I.8
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
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)
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
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.
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
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
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
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
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
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:
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
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
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
Service-specific
Service Perspective
Technology/Serviceindependent
#1
#2
#3
Aggregated
Instances
#4
#5
#6
B.3
Examples
GB 917 v1.5
Page 123
Parameter Category
Technology-specific
Service-specific
Service Perspective
Single User Instance
(SAP-related)
Aggregated
Requirements
Technology/Serviceindependent
e.g. speed
Parameter Category
Technology-specific
Service-specific
Service Perspective
Single User Instance
(SAP-related)
Aggregated
Requirements
Technology/Serviceindependent
GB 917 v1.5