SLA Management Handbook

Transcription

1 SLA Management Handbook GB 917 Public Evaluation/Version 1.5 June 2001

2 Page ii SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

3 SLA Management Handbook 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 USA Tel No Fax No TM Forum Web Page TeleManagement Forum 2001 GB 917 v1.5

4 Page iv SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

5 SLA Management Handbook 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 Håkan Kappelin, Ericsson Mahmood Karbasi, Oracle Han-Young Lee, Korea Telecom Hans Pettersson, EHPT Paul Short, TeleManagement Forum TeleManagement Forum 2001 GB 917 v1.5

6 Page vi SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

7 SLA Management Handbook Page vii About TeleManagement Forum TeleManagement Forum is an international consortium of communications service providers and their suppliers. Its mission is to help service providers and network operators automate their business processes in a cost- and time-effective way. Specifically, the work of the TM Forum includes: Establishing operational guidance on the shape of business processes. Agreeing on information that needs to flow from one process activity to another. Identifying a realistic systems environment to support the interconnection of operational support systems. Enabling the development of a market and real products for integrating and automating telecom operations processes. The members of TM Forum include service providers, network operators and suppliers of equipment and software to the communications industry. With that combination of buyers and suppliers of operational support systems, TM Forum is able to achieve results in a pragmatic way that leads to product offerings (from member companies) as well as paper specifications. TeleManagement Forum 2001 GB 917 v1.5

8 Page viii SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

9 SLA Management Handbook Page ix About this document This is a TM Forum Guidebook. The guidebook format is used when: The document lays out a core part of TM Forum s approach to automating business processes. Such guidebooks would include the Telecom Operations Map and the Technology Integration Map, but not the detailed specifications that are developed in support of the approach. Information about TM Forum policy, or goals or programs is provided, such as the Strategic Plan or Operating Plan. Information about the marketplace is provided, as in the report on the size of the OSS market. Document Life Cycle This is version 1.5 of the SLA Management Handbook. Version 1.5 supersedes all previous versions in their entirety. Document History Version Date Purpose Version 0.1 August 7, 1999 To provide the outline for the first draft version Version 0.2 December 12, 1999 Updated at the Las Vegas meeting Version 0.3 May 18, 2000 Provided for discussion at the Nice meeting Version 0.4 May 29, 2000 Updated at the Nice meeting Version 0.5 July 4, 2000 Release for Member Evaluation Version 0.6 August 8, 2000 Updated at the Washington meeting Version 0.7 November 2, 2000 Provided for promotion at TMW Chicago Version 0.8 November 16, 2000 Updated at the Chicago meeting Version 1.0 November 2000 Evaluation version for members only Version 1.1 June 2001 Updated after the Paris and Nice meetings Version 1.5 June 2001 Public Evaluation Version TeleManagement Forum 2001 GB 917 v1.5

10 Page x SLA Management Handbook Time Stamp This version of the SLA Management Handbook can be considered valid until 31 December 2002 or such time as a further revision is issued. How to obtain a copy This document version is available from the TMF Central Web Site. How to comment on this document Readers are encouraged to provide comments to the SLA Management Team via . Suggestions for comments: 1. In order to reduce file size, comments should excerpt only relevant paragraphs, including identifying paragraph headers. 2. Be specific. Consider that you might be on a team trying to produce a single text through the process of evaluating numerous comments. We appreciate significant specific input. We are looking for more input than a word-smith, however structural help is greatly appreciated where clarity benefits. 3. What to look for: errors, omissions, lack of clarity and missing references to other accomplished work (please cite exact applicable section(s) of other documents). 4. Questions are welcome that provide direction for the team to further develop or expand a specific area. However, the reader should be aware that this work is intended to be a handbook not an exhaustive thesis, and that we do not intend to duplicate other work. 5. all comments to the document editor, Jane Hall, [email protected] with a copy to the team leader, Lightsey Wallace, [email protected]. GB 917 v1.5 TeleManagement Forum 2001

11 SLA Management Handbook 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. TeleManagement Forum 2001 GB 917 v1.5

12 Page xii SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

13 SLA Management Handbook 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 Scope Assumptions Intended Audience and Benefits Service Providers Customers Equipment and Software Vendors Document Outline Using the Handbook...6 Chapter 2 Terms and Definitions...7 Chapter 3 Motivation and Requirements for SLA Management Introduction Business Model Business Benefits Customer Benefits Service Provider Benefits Vendor Benefits Performance Reporting Requirements Fulfillment Assurance Customer Interface Management Examples Leased Line Service Frame Relay Service ATM Cell Delivery Service IP-VPN Service IP Service with DSL Access Customer Care Help Desk Service...29 TeleManagement Forum 2001 GB 917 v1.5

14 Page xiv SLA Management Handbook Chapter 4 QoS and the SLA Parameter Framework Parameter Classification General Concepts Performance Events and Performance Parameters Network Performance and QoS NP/QoS Requirements and QoS Classes NP, QoS and Grade of Service (GoS), and the Role of Traffic Engineering Network Bearer Services and Application Services Parameter Dependence and Independence Service/Technology-independent Parameters Technology-specific Parameters Service-specific Parameters Parameter Degradation Management of QoS and NP Parameters Role of In-Service Monitoring Degradation and Customer Trouble Reports Performance Measures versus User Perception Measurement and Reporting Intervals Reporting Methods User Perception Aggregation of Parameters and QoS Index Customer Satisfaction Violations and Remedies Chapter 5 SLA Life Cycle Life Cycle Automation Product/Service Development Negotiation and Sales Implementation Execution Assessment Use Cases and Scenarios Product/Service Development with a New SLA Negotiation and Sales Implementation Normal Execution Execution with SLA Violation Assessment Chapter 6 SLA Management Framework SLA Management Functions Product/Service Development Negotiation and Sales Implementation Execution and Assessment SLA / QoS Data Management Chapter 7 SLA Modeling and Guidelines Introduction Role of SLAs within Service Products Defining the Level of Service Multiple Domain SLAs SLA to Service Mapping Service Element Categories SLA Mapping of QoS Parameters Leased Line Service Frame Relay Service GB 917 v1.5 TeleManagement Forum 2001

15 SLA Management Handbook Page xv ATM Cell Delivery Service IP-VPN Service IP Service with DSL Access Customer Care Help Desk Service...79 References...81 Acronyms...83 Appendix I: Related Activities...89 I.1 3GPP...89 I.2 Committee T I.3 ETSI...91 I.4 EURESCOM...92 I.4.1 Project P I.4.2 Project P I.4.3 Project P 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 I.7.1 ITU-T Study Group 2 Operational Aspects of Service Provision, Networks and Performance I.7.2 ITU-T Study Group 4 Telecommunication Management, including TMN I.7.3 ITU-T Study Group 7 Data Networks and Open System Communications I.7.4 ITU-T Study Group 9 Integrated Broadband Cable Networks and Television and Sound Transmission I.7.5 ITU-T Study Group 11 Signalling Requirements and Protocols I.7.6 ITU-T Study Group 12 End-to-end Transmission Performance of Networks and Terminals I.7.7 ITU-T Study Group 13 Multi-protocol and IP-based Networks and Their Internetworking I.7.8 ITU-T Study Group 15 Optical and Other Transport Networks I.7.9 ITU-T Study Group 16 Services, Systems and Terminals I.8 Quality of Service Development Group I.9 Others Annex A: ebusiness SLA Management A.1 Introduction A.1.1 Background A.1.2 Definition A.1.3 SLA Groups A.1.4 Scope A.2 Business Drivers for SLA/QoS A.2.1 Interdependence A.2.2 Economic Considerations TeleManagement Forum 2001 GB 917 v1.5

16 Page xvi SLA Management Handbook A.3 Technical Considerations A.3.1 Common Point of Failure A.3.2 Process Automation A.3.3 Security A.3.4 Checklist and Guidelines Annex B: Guidelines for Catalyst Project Input to the Handbook B.1 Introduction B.2 Parameter Framework B.3 Examples B.3.1 IP Service with DSL Access B.3.2 ATM Cell Delivery GB 917 v1.5 TeleManagement Forum 2001

17 SLA Management Handbook 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 TeleManagement Forum 2001 GB 917 v1.5

18 Page xviii SLA Management Handbook Figure 7.6: Multiple Domain SLA Relationships Example Figure 7.7: Multiple Domain SLA Relationships Example Figure 7.8: SLA and Service Access Point Relationships Figure 7.9: Service Element Categories Figure 7.10: Leased Line Service Parameter Framework Example Figure 7.11: Frame Relay Service Parameter Framework Example Figure 7.12: ATM Cell Delivery Service Parameter Framework Example Figure 7.13: IP-VPN Service Parameter Framework Example Figure 7.14: IP Service with DSL Access Service Parameter Framework Example Figure 7.15: Customer Care Help Desk Service Parameter Framework Example Figure A.1: Classification of ebusiness Service Providers Figure A.2: Availability for Services with Varying Redundancy (over 24 hours) Figure B.1: Framework for Parameter Categories Figure B.2: IP Service with DSL Access Parameter Framework Example Figure B.3: ATM Cell Delivery Service Parameter Framework Example GB 917 v1.5 TeleManagement Forum 2001

19 SLA Management Handbook 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 Service Provider Service Provider Service Provider Internal Provider Provider Service Provider Provider... End Customer Customer Customer End Users Provider Service Provider Customer Figure 1.1: Service Delivery Relationships TeleManagement Forum 2001 GB 917 v1.5

20 Page 2 SLA Management Handbook 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 organization 1. 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. 1 The main focus of this Handbook is on business Customers. GB 917 v1.5 TeleManagement Forum 2001

21 SLA Management Handbook Page 3 Development of a SLA must consider the complete life cycle of a service. Five stages are identified: product/service development, negotiation and sales, implementation, execution, and assessment. When the Customer-Provider interactions address each of these stages in turn, the resultant expectations will be better aligned and the relationship enhanced. Many performance parameters exist that have similar names yet have drastically different definitions. The SLA Parameter Framework is a useful tool for categorizing individual parameters. This framework organizes SLA parameters into six categories based upon whether they are technology-specific, service-specific or technology and service-independent, and whether they affect the individual user or are aggregated over a defined period. 1.2 Assumptions This Handbook addresses SLA parameters that support a contract between two parties. There are numerous business parameters contained in a contract that are not covered by this Handbook. For example, while the rebate process is described in terms of the parameters that may drive it, parameters for payment and terms are not included. Underlying systems and processes tend to be proprietary and will not be covered. The Customer and SP(s) often choose to be free to develop their own internal processes for market competitiveness. Therefore, the Handbook provides the information to both parties that is necessary to develop and manage their internal systems in a more efficient manner. A SLA between a Customer and a SP can refer to one or more services that the Customer is ordering from the SP. It is not necessarily restricted to one service offer or even one type of service. 1.3 Intended Audience and Benefits Service Providers This Handbook will assist SPs in developing new services with associated SLA parameters, align SLA parameters to meet Customer requirements and internal processes, assign internal processes according to SLAs, and respond to SLA requirements from other SPs. The Handbook helps a SP introduce operational changes, improve internal measurements and reporting, enrich Customer relations and differentiate itself from its competitors. TeleManagement Forum 2001 GB 917 v1.5

22 Page 4 SLA Management Handbook Service Provider is a general term including Network Operator (NO), Internet Service Provider (ISP), Application Service Provider (ASP), etc 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 SP s Customers as a means to develop a working understanding of practical SLA parameters Equipment and Software Vendors The Handbook helps Vendors, SPs and Customers create uniform cost-effective SLA Management solutions. Such solutions consist of products and services needed to satisfy requirements. Vendors of equipment and software solutions for Customers and SPs will be assisted by the Handbook through the examples of services to be managed and the performance parameters to be measured, reported and processed. 1.4 Document Outline Chapter 2 Terms and Definitions This chapter contains definitions of terms used in this document. Where possible, they have been aligned with those from other related telecommunication bodies. Chapter 3 Motivation and Requirements for SLA Management Business drivers for SLA management are identified and business benefits for both Customers and SPs described. Work presented in the Performance Reporting Team documents is introduced. Requirements are summarized in terms related to fulfillment, assurance and customer care, and build on the work in [NMF 503]. (Note: Annex A addresses requirements related to ebusiness.) Example services are introduced that are used for illustrative purposes in subsequent chapters. Chapter 4 QoS and the SLA Parameter Framework Agreement on terms and definitions for QoS parameters, and their measurement and reporting, is key to constructing and managing SLAs between Customers and SPs. Apart from functionality and price, service quality is an increasingly important factor for Customers in the competitive telecommunication market. This section describes SLA and QoS parameters, their classification and use. GB 917 v1.5 TeleManagement Forum 2001

23 SLA Management Handbook Page 5 Many SLA parameters exist and a framework has been developed to arrange SLA parameters into six categories. These six categories provide clarity in developing the SLA specification and reduce possible misunderstandings and unrealistic expectations. Some services may contain both technology-specific and servicespecific parameters, some may contain only one or the other. Many services contain technology and service-independent parameters. A variety of examples is included to illustrate the value of this framework. The relationship between QoS and SLA is developed together with considerations such as where SLA thresholds are captured, applied and managed. A commonly overlooked aspect of SLA parameters is the relationship between the aggregated requirements for quality and the impact on a single user instance of the service. The framework addresses this issue. Certain SLA parameters may be of more interest to the SP than the Customer and vice versa. This framework provides an organized approach to jointly defining pertinent SLA parameters and ultimately their values. The parameter framework provides guidance for six categories of parameters while specifically addressing the parameters related to an individual user. Other considerations are included, such as degradation, measures and user perception, violations and remedies. This chapter has additional value for its references to the work of other external (e.g. standards) groups. Chapter 5 SLA Life Cycle Chapter 5 provides a tool for developing and administering SLAs during the entire life cycle of the service and its associated SLA. When developing a SLA, consideration must be given to the life cycle as it may affect SLA requirements. For example, different combinations of processes are required to support the five phases of the SLA life cycle. Different SLA parameters and values may apply during product/service development, negotiation and sales, implementation, execution, and assessment. The relevant use cases supporting SLA management are described and related to the TOM processes. Chapter 6 SLA Management Framework This chapter discusses how process automation can support aspects of the SLA life cycle and introduces functions that are related to SLA management. The data that is required for SLA/QoS management is considered. Chapter 7 SLA Modeling and Guidelines A conceptual model is introduced that is useful for identifying the components from which a SLA is constructed and the role of such components within a SP s 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. TeleManagement Forum 2001 GB 917 v1.5

24 Page 6 SLA Management Handbook Appendix 1 Appendix 1 provides an overview of work being undertaken on SLA and QoS issues by various standards bodies and other organizations. Annexes Aspects of SLA Management related to businesses where short-term loss of services could impact the survival of the company are addressed in Annex A. This annex is an extension of the Handbook, since these cases are not considered as a stand-alone issue and must be closely correlated with standard management methods. TM Forum Catalyst projects demonstrating SLA applicable measures and processes are to be summarized in Annex B. These demonstrations will be fully reported individually and the relevant SLA measures and processes will be highlighted in the annex in a later version of this Handbook. 1.5 Using the Handbook QoS is used by a SP to measure performance both technically and in terms of Customer satisfaction. Determining the QoS provides a discriminator between various types of service that a supplier provides, and leads to opportunities to balance the level of service quality offered against price and Customer expectation. The use of QoS agreements in SLAs provides SPs with the opportunity to delight their Customers, build stronger long-term relationships and brand image, and maintain/grow market share. The growing complexity of global services brings together a myriad of services, suppliers and technologies, all with potentially different QoS requirements. SPs are trying to integrate these services into one Next Generation Network (NGN) that supports these requirements, while striking a delicate balance between cost and return on investment. Corporate Customers are seeking SLAs that offer deeper verification and analysis of the performance they are paying for. In addition to the primary requirement for high availability, the ability to monitor on an increasingly granular level is imperative for corporate networkers. For example, they want to know the number of successfully delivered packets in a given time period, the amount of time a user was connected to a server, notification of what traffic type is using the most bandwidth, what percentage of the traffic is going to a specific sub-network or server, etc. This Handbook is designed to be a reference for SPs as they develop new services and to assist in Customer discussions. It will inform and educate about the intricacies of SLAs as well as provide a structure for defining agreements such that relevant SLA parameters and values can be agreed upon that are achievable and verifiable. The Handbook is not intended to provide a cookbook of tables to be filled out without knowledge of the underlying requirements, capabilities or limitations of the technology or service(s). GB 917 v1.5 TeleManagement Forum 2001

25 SLA Management Handbook Page 7 Chapter 2 Terms and Definitions Terms and definition used in this Handbook are mainly based on the TM Forum Performance Reporting Concepts and Definitions Document [TMF 701] and internationally agreed definitions published by the ITU. For example, ITU-T Recommendation M.60 [M.60] contains Maintenance Terminology and Definitions. In this chapter, only some key terms related to SLAs, QoS and performance are defined and their source identified. For the purposes of this Handbook, some definitions have been modified and/or extended. Where multiple definitions are in use within the industry, all are given. Not all of the terms and definitions in this chapter are necessarily used in this version of the Handbook but are included as they are expected to be relevant in later versions 2. For further information, please consult TMF 701, ITU-T and other references. Active (condition) condition (e.g. alarm) not cleared (ITU-T Rec. M.2140). *Administration (task) a broad group of functions that sustain telecommunication services once they have been established. Administration generally consists of network administration and service administration. Network administration ensures that the network is used efficiently and that Grade of Service (GoS) objectives are met. Service administration includes such diverse support functions as billing, collecting and switching service evaluation (ITU-T Rec. M.3010). Administrative Domain a collection of systems and sub-networks operated by a single organization or administrative authority. It may be subdivided into a number of routing domains (ITU-T Rec. X.400). *Aggregate Interval the time period over which raw data is summarized in a particular report. For example, raw 15-minute data may be aggregated into one-hour or 24-hour intervals for reporting purposes (TMF 701 modified). Alarm an alerting indication of a condition that may have immediate or potential negative impact on the state of service resources, e.g. network element, application, system, etc. (ITU-T Rec. M.3010 modified). *Alarm Surveillance a set of TMN management functions which provide, in near real-time, detection and indication of failures (ITU-T Rec. M.3010). *Anomaly a discrepancy between the actual and desired characteristic of an item. The desired characteristic may be expressed in the form of a specification. An anomaly may or may not affect the ability of an item to perform a required function (ITU-T Rec. M.20). 2 Terms and definitions not yet used are marked with a *. TeleManagement Forum 2001 GB 917 v1.5

26 Page 8 SLA Management Handbook Availability Performance the ability of an item to be in the state to perform a required function at a given instant of time or at any instant of time within a given time interval, assuming that the external resources, if required, are provided. Note that this ability depends on the combined aspects of the reliability performance, the maintainability performance and the maintenance support performance of an item. In the definition of the item, the external resources required must be delineated. The term availability is used as an availability performance measure (ITU-T Rec. M.60). Bearer Service a type of telecommunication service that provides the capability for the transmission of signals between user-network interfaces (ITU-T Rec. I.112). Clear the end of a fault; the termination of a standing condition (ITU-T Rec. M.2140). Connection an association of transmission channels, circuits or flows, switching and other functional units set up to provide a means for a transfer of information between two or more points in a telecommunication network (ITU-T Rec. Q.9 modified). *Connection Quality the collective effect of service performance, which determines the degree of satisfaction of a user with the particular connection (ITU-T Rec. M.3010). Customer a Customer is an entity which receives services offered by a Service Provider based on a contractual relationship. It may include the role of a network user (ITU-T Rec. M.3010). The term Customer refers to companies or organizations that make use of telecommunication services provided by a Service Provider. The Customer is the ultimate buyer of a network service, but the end user may or may not be the one who pays for the service (TMF 701 modified). Customer Contact Point a physical or conceptual point at which a Service Provider can interact with any Customer of the offered service for the purpose of maintaining communication services (TMF 701 modified). Customer Details information about the Customer, sometimes called Customer profile. Customer Premises Equipment (CPE) any network equipment sited at the Customer s premises used to provide the contracted service. Note that the CPE may be owned and operated by the Customer or the Service Provider (extracted from TMF 701). Customer SLA Performance Data correlation of the service quality and performance data against specific Customer service instances to provide specific performance data against individual service instances and SLAs. Customer to Service Provider Interface the boundary of information exchange between the Customer (whether end Customer or another Service Provider/Network Operator) and their Service Provider (TMF 701 modified). GB 917 v1.5 TeleManagement Forum 2001

27 SLA Management Handbook 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 TeleManagement Forum 2001 GB 917 v1.5

28 Page 10 SLA Management Handbook 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 TeleManagement Forum 2001

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

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

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

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

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

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

35 SLA Management Handbook Page 17 As shown in Figure 3.1, these roles comprise Customers, Service Providers, Other Providers/Operators, Third Party Applications Vendors, and Suppliers to Service Providers. A variety of business relationships can exist between these roles in a competitive market with multiple providers. These relationships can be formalized at the interfaces between the roles, as these are the points at which information needs to be exchanged. The particular interface that is the subject of this Handbook is that between Customer and Service Provider (see Figure 3.2). Relationship Customer Service Provider Contract Service Quality Figure 3.2: SLA at the Customer-Service Provider Interface The overall relationship is important in this context as Customers and SPs jointly negotiate a SLA covering the services being provided by the SP to the Customer and in so doing develop a greater understanding of the other s approach, requirements and responsibilities. 3.3 Business Benefits Customer Benefits A consistent approach to SLA management will provide the following benefits to a SP s Customers: Help Customers develop the baseline, establish the requirements, customize a SLA contract, validate the ongoing performance compliance to end-to-end service level objectives, and review and refine the SLA through an iterative process. Help Customers establish parameters, measurement methods, reports and exception handling in the SLA. Help Customers define high-level common terms and definitions for end-to-end service performance in the form of network technologyindependent QoS metrics, parameters and reports. These include items such as mean time to provision; mean time to identify, repair TeleManagement Forum 2001 GB 917 v1.5

36 Page 18 SLA Management Handbook Service Provider Benefits and resolve malfunction; service availability; end-to-end throughput, delays and errors. Help Customers evaluate the relationship between the technologyspecific service and network elements and the technology/serviceindependent parameters of the SLA. This includes considering how, within each of the multiple SP administrative domains, these parameters map, interpret or mimic the performance perceived by the Customer. Help Customers validate the QoS as defined in the SLA document by receiving predefined and exception reports and SP responses to performance inquiries. These include notifications of SLA violations, reports of any developing capacity problems, changes in usage patterns, and reporting delivered performance for comparison with the Customers' perceived performance. Help Customers evaluate a SP's methods for detecting degraded service performance, alerting the Customer and responding to performance events affecting the Customer's service. Help Customers verify the implementation of penalty provisions for failure to maintain and deliver the service as defined in the SLA, including cancellation fees. Help Customers define the end-to-end QoS metrics for multimedia telecommunication services, especially those carried over IP-based networks. Help Customers compare services and service quality levels offered by different SPs. A consistent approach to SLA management will: Help introduce operational changes, improve internal measurements and reporting, enrich Customer relations and differentiate the SP from its competitors. Help create more knowledgeable Customers who can better express their needs to the SP, which can reduce the time devoted to the negotiating process. Help create a common language and understanding with the Customer on characterizing network and operational parameters. Help create SP internal recognition of the Customer s perception of network errors and service interruptions. Help prioritize service improvement opportunities. Help create common SLA/QoS goals across multiple technology domains. Help standardize performance-gathering practices across multiple internal domains. GB 917 v1.5 TeleManagement Forum 2001

37 SLA Management Handbook Page Vendor Benefits A consistent approach to SLA management will: Help vendors understand Customer and SP requirements for SLAs. Help equipment suppliers agree on the mapping of technologyspecific parameters and measurement methods into service-specific parameters and measurement methods. Help software vendors agree on common interface definitions for SLA management. 3.4 Performance Reporting Work on performance reporting was undertaken by the Performance Reporting Team, which was concerned with performance reporting over the SP to Customer interface 3, 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. 3 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. TeleManagement Forum 2001 GB 917 v1.5

38 Page 20 SLA Management Handbook Scope of NMF 503 CUSTOMER Customer - SP Interface Reports Repository and Delivery Request on a SAP Request to create a TT A MTTR MRT MTBF Net.Perf. Traffic Data (Invoice and Credits) C O N T R A C T S L A Ordering TT Perf Billing SAP-Weight Garanteed SAP V l activity i t l SAP details SAP outage intervals Response time Event Common Objects MTTR, A, MRT, MTBF Net.Perf. Traffic Metrics SLA violations Net.Perf. Traffic Data Network Elements Report computation and aggregation Figure 3.3: Interaction of Performance Reporting with other Service Functions and Scope of the Performance Reporting Interface Definition The specific business requirements on the performing reporting interface are introduced. These are categorized either as mandatory core requirements or as optional requirements. The requirements are grouped as follows: Contract (SLA) related requirements Performance report related requirements Service availability related requirements General QoS requirements Report generation and distribution requirements Report frequency requirements Report customization requirements The general technical requirements on the interface include those concerned with transport, connection, security as well as other general requirements. The document is relevant to the SLA Management Handbook as reporting on performance is an essential part of SLA management. It is referenced here so that readers of this Handbook are aware of the TM Forum work already undertaken in the performance reporting area without it being explicitly repeated. GB 917 v1.5 TeleManagement Forum 2001

39 SLA Management Handbook 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 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 report s contents, format, destination, conditions and delivery media. Service definitions for each service covered by the SLA. Process for handling the defined boundary conditions. TeleManagement Forum 2001 GB 917 v1.5

40 Page 22 SLA Management Handbook Assurance 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. 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 TeleManagement Forum 2001

41 SLA Management Handbook 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 Customer s 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 Customer Interface Management These requirements are concerned with the interface between the Customer and the SP and with how the SP should interact with Customer inquiries concerning a service and its SLA. Req. 14: Customers should be to able to report troubles or faults, request changes and make inquiries about their services by telephone, fax or electronically, and receive notifications in the same variety of ways. Req. 15: The SP should provide a rapid response to Customer help desk inquires concerning service quality levels. Req. 16: The SP s Customer Contact Points should have information available on the status of any service about which the Customer could inquire. TeleManagement Forum 2001 GB 917 v1.5

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

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

44 Page 26 SLA Management Handbook ATM Cell Delivery Service IP-VPN Service 6 ATM Cell Delivery service is similar to the Frame Relay service discussed above. It consists of subscribers obtaining access lines to network ATM switches, and Virtual Circuits (VCs) from the Customer Premises Equipment (CPE) over the access lines, through the network of ATM switches, to other ATM Cell Delivery service Customers. In some cases, the CPE itself may be an ATM edge switch owned by the Customer and offering a range of service applications (voice, video, data, etc.) to users. The VCs may be either permanent (PVC) or switched (SVC). The structure of ATM allows for many more traffic QoS classes to be defined and the traffic characteristics to be more tightly controlled. The traffic QoS classes can range from Constant Bit Rate (CBR) or Deterministic Bit Rate (DBR), with speeds up to the access line rate, to a best effort Unspecified Bit Rate (UBR) class. These characteristics are established when the VC is created. Some advanced services allow re-negotiation of the traffic characteristics during the connection. Customers negotiate several parameters for access, plus per PVC parameters. For switched circuits, Customers negotiate other behavior based on the establishment of the SVC: Service Availability Access Line Speed Per VC Cell Rate (can be quite complex for non-real-time and realtime streams) Per VC Cell Propagation Delay Per VC Cell Delay Variation Per SVC Call Setup time Per SVC Blocked Calls Cell Error Ratio Cell Loss Ratio An IP-based Virtual Private Network (VPN) enables the transport of IP packets between a specified list of end points with a statistical assurance of QoS (loss, delay, availability) and a level of security equivalent to a network built with private facilities. The IP-VPN service has been developed to allow Customers to connect their different locations in a cost-effective manner using the IP protocol. A router is installed at each Customer site to allow connection to the IP backbone network (see Figure 3.4). 6 The IP-VPN service was one of the services selected by the SLA Management Wholesale and Retail Services catalyst (SLA catalyst team) and section is based upon that team s specification of the service. GB 917 v1.5 TeleManagement Forum 2001

45 SLA Management Handbook Page 27 SAP Service Access Point (SAP) IP Backbone SAP SAP Customer Premises Equipment Boundaries of IP VPN Service Management Figure 3.4: IP-VPN Service Concept The IP backbone is a publicly accessible network which may provide connectivity to the global Internet. Tunnels are used to segregate IP-VPN traffic from normal Internet traffic. This provides a virtual private network (i.e. an intranet ) using a public IP network. In this way, an IP-VPN provides the Customer with a Closed User Group service (community of interest) creating any-to-any (fully meshed) connectivity. The users of an IP-VPN only see the VPN connections within their own group. A number of parameters are negotiated between the Customer and the SP as part of the SLA. The following parameters may be part of the contract: Service Availability IP Packet Transfer Delay IP Packet Delay Variation (jitter) IP Packet Loss Ratio IP Packet Error Ratio Utilization IP Service with DSL Access The example shown in Figure 3.5 is an information service (e.g. access to Internet web pages) provided by an ISP over a Telecom Service Provider s (TSP) network to a group of subscribers. It should be noted that it is the role these organizations play that is important, not their traditional appearance as companies. For example, the TSP acts as a network bearer service provider and network operator providing connectivity between the ISP and its Customers. The ISP is the provider of the TeleManagement Forum 2001 GB 917 v1.5

46 Page 28 SLA Management Handbook 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 Application Service www+ SLA ISP TSP SLA User www+ SP 1 Internet Access SLA SP 2 IP Interface TX Network User Access Interface User www+ Network Bearer Service User CSP = Content Service Provider ISP = Internet Service Provider TSP = Telecom Service Provider Access Network www+ User www+ Figure 3.5: Example of a Composite Service There are therefore, at least two services involved in this example - a network bearer service provided by the TSP to the ISP and an application service provided by the ISP to its Customers. This is a classic example of the recursive nature shown in TMF 701 of a service comprised of service elements, each of which is a service itself comprised of service elements. In our example, the TSP, acting as SP 2, may transport the service over a number of different network technologies supporting the IP layer. The ISP, acting as SP1, on the other hand uses the network bearer service as a service element supporting its overall service to end Customers. As Figure 3.5 shows, there is a SAP group with a SLA between SP1 and SP2 and another SAP group between SP1 and its Customers. There is also a third service involved in this example and that is of content provider. This may be the ISP itself or its suppliers, such as vendors of film libraries, music, games, etc. The ISP may act purely as a portal giving access to these content providers, whether they are companies or individuals with web home pages. The implications for SLA management include the fact there is probably a SLA between the TSP and the ISP as well as a SLA between the ISP and its Customers. One is dependent on the other. In assessing the QoS delivered to the end Customer, the important thing to consider is the close coupling between the QoS of the telecom service provided by the TSP and the QoS of the information systems and technology GB 917 v1.5 TeleManagement Forum 2001

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

48 Page 30 SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

49 SLA Management Handbook Page 31 Chapter 4 QoS and the SLA Parameter Framework This chapter considers and defines the QoS parameters needed in a SLA and which might be reported to Customers on a regular basis. The intent here is not to specify actual performance values since these are commercially sensitive and subject to negotiation between SP and Customer. The objective is to define a method of classifying QoS parameters, listing and defining them in a consistent manner within the SLA. The SLA QoS parameters support a contract between two parties. Whether the SLA and its QoS parameters are considered part of the contract or an adjunct to it varies from provider to provider. There are numerous business parameters contained in a contract that are not covered by this Handbook. For example, while violations and remedies are discussed in terms of the parameters that may drive the process, parameters for payment and terms are not included since these are unique to each contract and a commercial agreement between the parties concerned. Similarly, proprietary underlying systems and processes used to support SLAs are not described. It is important to note that there is a distinct difference between the user/service QoS requirements defined in the SLA and the network level QoS/NP and QoS-enabling mechanisms Parameter Classification General Concepts Four main factors contribute collectively to the overall QoS perceived by the user of a telecommunication service (see Figure 4.1). These are serveability, operability, integrity and support, each of which should be considered as a concept or umbrella characterized by many measures or parameters (see ITU-T Rec. [E.800] and [E.801]). Serveability includes both accessibility performance and retainability performance. These in turn can be broken down in terms of trafficability, availability, reliability and propagation performance, all of which can be considered Network Performance (NP) that delivers QoS. Service integrity depends on transmission 7 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. TeleManagement Forum 2001 GB 917 v1.5

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

51 SLA Management Handbook Page Performance Events and Performance Parameters It is important to distinguish between performance events and performance parameters. Events are instantaneous phenomena that occur within the network supporting the service or its environment that affect the QoS delivered. Examples are Errored Seconds (ESs), Severely Errored Seconds (SESs), Severely Errored Periods (SEPs), lost or misdirected cells and packets, loss of signal, loss of network synchronization, lightning strikes, earthquakes, etc. Performance parameters are derived by processing events over a measurement interval into a defined metric that can be reported. These may be time-related measures that can be expressed in terms of mean values or fractiles, ratios, which are estimators of probabilities, or event rates or intensities contributing to reliability performance. Examples are Errored Second Ratio (ESR), percentage Availability, Throughput, Utilization, Severely Errored Period Intensity (SEPI), Mean Time Between Outages or Failure (MTBO or MTBF), Outage Intensity (OI), Mean Time to Provide Service (MTPS), Mean Time to Restore Service (MTRS), time to first yield 8, average call response time, etc Network Performance and QoS NP depends on a SP s planning, development, operations and maintenance of the network supporting the service, and it can be considered the core of the technical part of QoS. It is up to the SP to combine the NP parameters in such a way that the economic requirements of the SP as well as the satisfaction of the user are both fulfilled. Usually, this requires a compromise between economy and QoS. An essential difference between QoS and NP measures is that QoS is user-orientated while NP is network provider-orientated. Thus QoS focuses on user-perceivable effects (not their causes) and NP on the efficiency of the network in providing services to the Customer. The result is that QoS measures are relevant between Service Access Points (SAPs), usually on an end-to-end basis, while NP measures are relevant between borders of network portions, see Figure 4.2 below. Quality of Service User-oriented Service attribute Focus on user-observable effects Between (at) Service Access Points Provider-oriented Connection element Network Performance Focus on planning, design and development, operations an d maintenance of network End-to-end or network connection element capabilities Figure 4.2: Distinction between QoS and NP 9 It is important therefore to distinguish between NP and QoS events and parameters. In a client/server network, many of the events and parameters in the server network 8 Time to first yield is defined as the time interval between initiating service and the first reportable service-impacting event. 9 Derived from Handbook on Quality of Service and Network Performance [ITU_Hbk]. TeleManagement Forum 2001 GB 917 v1.5

52 Page 34 SLA Management Handbook 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 NP/QoS Requirements and QoS Classes NP is usually specified in terms of end-to-end and individual network portion events and parameters, and these may be grouped into so-called QoS classes. For the switched network (whether circuit-switched or packet-switched), there are two types of QoS requirements. These are call- and connection-level QoS requirements, and information-transfer QoS requirements. The first set is related to the call or connection set-up, modification and release phases, and includes delays and blocking probabilities of requests. One measure of these is End-to-end Connection Blocking Probability (ECBP). The second set is associated with the information transfer phase, and hence applicable to connections already established through the network. These requirements are usually technology-specific and/or service-specific and relate to service integrity performance. Note that for an IP-based (so-called connection-less ) network, there is still a phase of connection route set-up and an information transfer phase for each packet. This may be true for a network using defined QoS mechanisms, e.g. RSVP, as opposed to purely best effort operation. Furthermore, router reconfiguration can contribute to delay in either the set-up or information transfer phases of a call. The existence of two types of QoS requirements calls also for the definition of two types of QoS classes. Call- and connection-level QoS classes are characterized mainly by a target value for ECBP. Information transfer-level QoS classes are characterized by a set of performance objective values. Each QoS class provides a guaranteed minimum level of NP to support a particular service and includes values of QoS that can be expected. As an example, ITU-T Rec. I.371 specifies a limited set of ATM Transfer Capabilities (ATCs), each with a number of QoS classes [I.371]. An ATC is intended to support an ATM layer service model and associated QoS through a set of ATM layer traffic profile parameters and procedures. The use of ATCs has both a user's perspective, wherein a transfer capability is seen as suitable for a given set of applications, and a network operator's perspective, wherein a transfer capability may provide gain through statistical multiplexing. For the case of an ATM cell delivery service, the NP supported by the ATC and the delivered QoS are one and the same. For the case of ATM supporting higher layer application services, e.g. voice, video, IP, etc. carried over a core ATM/SDH network, the ATC guarantees a minimum level of NP provided that the ATC traffic profile parameters are not exceeded. Policing mechanisms are employed at the ATM layer to minimize GB 917 v1.5 TeleManagement Forum 2001

53 SLA Management Handbook 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 ITU- T Study Group 13 in developing new Recommendation Y.1540 on the same topic. Further information on IETF s Working Groups and ITU-T s activities can be found in Appendix I 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 Operator s 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. TeleManagement Forum 2001 GB 917 v1.5

54 Page 36 SLA Management Handbook Network Bearer Services and Application Services Furthermore, the service offered needs to be clearly defined. Is it a network bearer service supporting, but independent of, the application carried, or is it an application service, e.g. voice, video, sound programme, etc. supported by lower layer network connectivity? The ATM example quoted above can be both - an ATM network bearer service used to support IP-based, FR-based or circuit-based services, or a pure cell stream delivery service. A parameter measured between (or at) access points of a bearer service is a NP parameter to the provider of the bearer service, but a QoS parameter to the user or client of the bearer service. ATM is therefore a good example of both a service and a supporting network technology. Similar arguments can be applied to IP. It can be a supporting network technology or purely a packet delivery service. Some people regard the SLA as a kind of Business API and QoS as a kind of Network API. Whether this is true depends to some extent on whether a network bearer service or an application service is being considered. It also depends on whether the technical QoS aspects are considered part of the SLA/Contract or an adjunct to it. In general terms, a service is a product provided by one entity to another for which payment may be made Parameter Dependence and Independence It is important to distinguish between QoS parameters that are independent of the service and network technology supporting the service, those which are servicespecific and those that are network technology-specific. This distinction was made early on in the TM Forum work on Performance Reporting (see [TMF 701]) and was later refined to distinguish between single user instance and aggregated requirements as shown in the parameter framework below (Figure 4.3): Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent e.g. physical interface details e.g. monthly reported parameters e.g. service type or bundle e.g. billing method (usageor time-based) e.g. max. down-time of one event e.g. aggregate availability over all users Figure 4.3: Framework for Parameter Categories The two rows distinguish between single-user instance (SAP-related) aspects such as the service interface or maximum down-time for a single event, and aggregated requirements such as the billing and reporting periods or aggregate availability. It is important to distinguish between a single user instance and aggregated requirements from the user s perspective. Typically the single user is the initiator of a trouble report. For example, when availability is specified over a billing period, it would be possible for a single outage for a single user to shut down that user entirely and still meet the GB 917 v1.5 TeleManagement Forum 2001

55 SLA Management Handbook 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 Single User Instance (SAP-related) Aggregated Requirements Technology-specific Service-specific Technology/Service - independent e.g. speed e.g. delay, throughput e.g. availability, max. time to restore e.g. total UAS e.g. delay distribution e.g. MTBF, MTTR, MTRS Figure 4.4: IP Service with DSL Access Parameter Category Service Perspective Single User Instance (SAP-related) Aggregated Requirements Technology-specific Service-specific Technology/Service - independent e.g. CER, CLR, CTD, CDV - all max. values e.g. CER, CLR, CTD, CDV - all mean values and totals e.g. availability, max. time to restore e.g. MTBF, MTTR, MTRS Figure 4.5: ATM Cell Delivery Service Service/Technology-independent Parameters Service/technology-independent QoS parameters are those which are often (if not always) specified in a SLA. Examples include those already mentioned such as Percentage Availability, MTBO or MTBF, OI, MTPS, MTRS, time to first yield, average call response time, etc. These are sometimes referred to as operational performance criteria and some are reportable by SPs to regulatory authorities on a TeleManagement Forum 2001 GB 917 v1.5

56 Page 38 SLA Management Handbook 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 user s 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 Technology-specific Parameters Technology-specific QoS parameters are those related to the network technology supporting the service, particularly where the service offered is a network bearer service. Examples already quoted are the ATM NP and QoS parameters and the well-known PDH/SDH physical layer parameters quoted on digital leased circuits. In addition, technology-specific parameters such as physical characteristics of the SAP need to be specified. Some of the technology-specific parameters may not be relevant to a service end user, but need to be considered internally within the SP or between NOs/SPs. The decision on which parameters to include in a SLA may be an individual choice for each service contract. Examples of QoS parameters for each network technology layer follow: GB 917 v1.5 TeleManagement Forum 2001

57 SLA Management Handbook Page 39 Physical layer: copper/optical cable and terrestrial/satellite radio parameters of Loss, Crosstalk, Delay, Dispersion, Q-factor. Note: renting of unbundled copper loop, copper coaxial cable and optical fiber are now services provided by some NOs. Similarly, renting of microwave radio transceiver towers and satellite bandwidth are also services. xdsl layer: system parameters of Bit Rates (up- and downstream), Bits/Hz, Reach, Radiation, Crosstalk. PDH/SDH layer: BBE, ES, SES, SEP, Jitter, Wander, Slip events and their derived parameters of BBER, ESR, SESR, SEPI; UAS, Availability, Pk-Pk Jitter, TIE, MTIE. ATM layer: CE, CL, CM, SES ATM, SECB, CD events and their derived parameters of CER, CLR, CMR, SECBR, CTD, CDV, UAS, Availability, Throughput, Utilization. Associated with these are traffic descriptors or traffic profile parameters specified in the service contract including PCR, SCR, MCR, MBS, PEI and CDVT. FR layer: lost or corrupted frame events and their derived parameters of Frame Loss Ratio of committed frames (FLRc), Frame Transfer Delay (FTD), Availability, Throughput, Utilization. Associated with these are traffic descriptors or traffic profile parameters specified in the service contract including PIR, CIR. IP layer: lost or corrupted packet events and their derived parameters of IP Packet Loss Ratio (IPLR), IP Packet Transfer Delay (IPTD), IP Packet Delay Variation (IPDV, sometimes called Packet Jitter), Availability, Throughput, Utilization. One of the biggest challenges is mapping the QoS/NP parameters between different network technology layers and determining their impact on the highest-level service client in use Service-specific Parameters Service-specific QoS parameters are those typically related to the application carried by the network and, as mentioned above, service-specific or application-specific technology parameters such as reliability and availability of computer servers, databases, etc. As ebusiness expands, computer server parameters will become increasingly important and impact the overall availability of the service offered. ebusiness aspects of QoS/SLA management are covered in more detail in Annex A. Probably the most significant dependability QoS/NP parameter for any service is Availability. This depends on the combined aspects of the reliability, the maintainability and the maintenance support performance of an item and refers to any part of the network or entity supporting the service, whether hardware or software. Availability performance may typically be expressed by the following measures (see also the ITU-T Handbook on QoS and NP [ITU-Hbk]): TeleManagement Forum 2001 GB 917 v1.5

58 Page 40 SLA Management Handbook Measure Estimation Units Example Availability Up-times x 100 Up-times + Down-times Unavailability Down-times x 100 Mean accumulated down-time over a given time interval Up-times + Down-times down-times accumulated over a given time interval Figure 4.6: Availability Performance Measures (%) 99.9% (%) 0.1% (hours) 8.76 hrs over one year This definition of availability has been further refined and expanded to take account of SAP weighting (see [TMF 701]). Examples of service-specific QoS parameters for some services follow: Voice telephony: call connectivity and quality measures ABR/ASR/CCR/CSR/NER; network connection failures and retainability, Customer Affecting Incidents (CAIs) and Defects Per Million (DPM); PSTN speech and 3.1 khz audio loudness (speech level), attenuation, noise, crosstalk, echo, distortion; ISDN call set-up failures and delay, propagation delay (including differential delay between B-channels), G.821 error performance, premature release, release failure and delay, CLI reliability. Note: with the increasing use of digital network technology, control and management of echo has become increasingly important, even for quite close destinations from a caller. For Voice over IP (VoIP), delay and echo are two of the major hurdles to overcome. Data: BER, % EFS, errored PDUs, lost PDUs, UAS, Availability digital data parameters; loss, attenuation, group delay distortion, noise, impulse noise analog data parameters. Facsimile: image quality, character error rate, call cut-off, modem speed reduction, transaction time and availability. Mobile telephony: call completion rate, call dropout rate, noise, echo, distortion and availability. Sound programme: noise, crosstalk, stereo channel interference, distortion and availability. Support & maintenance: service penetration (e.g. telephones per 100 population), supplying service instruction and information, access to SP (e.g. answering requests, response times), service supply and removal (e.g. MTPS) and service repair (e.g. MTTR). GB 917 v1.5 TeleManagement Forum 2001

59 SLA Management Handbook Page 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 Management of QoS and NP Parameters An adequate picture of the QoS/NP can only be obtained by defining a set of parameters (a profile) which should be quantified. A SP may (usually will) use more stringent values in design, commissioning, operation and maintenance or for contractual aspects, and setting new targets, than the minimum specified in the SLA. In practice, QoS/NP management consists of mapping actual values of parameters against different performance objective values. The latter are specified for international networks and services by ITU-T Recommendations, notably by Study Group 13 for network design and Study Group 4 for network operations and maintenance. In many cases, these Recommendations also allocate the performance objectives to different portions of the network in such a way that each network provider is aware of its responsibilities and can assess its required NP and QoS. Some mix of OSI layers 1, 2 and 3 methods of controlling QoS will be required that can translate end user QoS requirements into technology-specific QoS/NP parameters. This must include consideration of QoS distribution and propagation between carriers forming part of any connection. This is done via allocation of performance objectives referred to above. Real-time responses are required to network resource demand fluctuations. Impacts on QoS between user flows on the same bearers must be avoided. Thus QoS monitoring as well as good network planning and design are needed. The close coupling between network traffic engineering and QoS/NP cannot be overemphasized. Depending on the network technologies employed, a range of QoS management approaches is available. Detailed discussion of these is really a network management issue and outside the scope of this Handbook Role of In-Service Monitoring At a network level, continuous In-Service Monitoring (ISM) of NP is preferable for detecting degradation in performance and its impact on the QoS delivered. This is increasingly possible using built-in digital signal overhead such as framing bytes, Error Detection Codes (EDCs) and Performance Report Messages (PRMs). The TeleManagement Forum 2001 GB 917 v1.5

60 Page 42 SLA Management Handbook objective is to provide pro-active performance monitoring and reporting such that degradations are discovered early and action taken before SLA guarantees are breached. Degraded Performance Limit (DPL) and Unacceptable Performance Limit (UPL) thresholds are set within network elements, and when these are exceeded, notifications are generated to network management systems. These in turn filter, correlate, integrate and process the performance events that may result in alarms, and generate network-level trouble reports and trouble tickets that report serviceaffecting situations. See ITU-T Rec. M.2140 for a comprehensive discussion of these processes [M.2140]. Further information can also be found in the ITU-T TMN M.3xxxseries Recommendations. Figure 4.7 represents implied relationships between the engineered level for the NP and other factors related to grades of service. Performance Level Engineered Level Delivered Level Performance Sets Guaranteed Level Gold Bronze Silver Grade of Service Figure 4.7: Performance Levels Degradation and Customer Trouble Reports At a service level, the ability to monitor and report QoS parameters to a Customer and deal with any reported troubles from the Customer is crucial to delivering QoS guaranteed in the SLA. This is the core of Customer QoS Management within Customer Care. Correlating Customer trouble reports with network trouble reports to determine the nature of a trouble and confirm whether a service-affecting fault exists within the network is all part of the process. Degraded performance can therefore be considered just as much a fault as complete disconnection or unavailability of a service. GB 917 v1.5 TeleManagement Forum 2001

61 SLA Management Handbook Page 43 A further aspect of QoS degradation is the impact of fraud prevention measures, e.g. cut-off of legitimate traffic. This needs further study. In the case of multimedia services, ITU-T Study Group 16 has suggested terminals should provide for an orderly degradation of QoS with priorities such that video, data, audio and control will be degraded in that order. For example, the multimedia terminal may reduce the frame rate, packet rate or media bit rate, or even turn off media considered to be of lesser importance. 4.3 Performance Measures versus User Perception Measurement and Reporting Intervals QoS and NP parameters should be measurable or at least calculable (based on monitoring of events as already discussed). However, it should be realized that almost all measures are time-dependent and for NP should in principle be considered as random (stochastic) variables. As such, the performance parameters can only be estimated. Three main sources of performance data are network measurements, Customer interviews and Customer complaints. The user perception of QoS is relevant during both provision and operation of the service. To cover all aspects of QoS, measurements should be carried out both at (or as near as possible to) the user access point and also at each network node. This raises the issues of accuracy, scalability and cost. Monitoring at the Customer Premises Equipment (CPE) requires at least one monitor per end point, which is desirable because the monitoring traffic experiences nearly the same performance as the Customers traffic. However, this is costly and difficult to scale to large networks, and can result in large amounts of management traffic to be transported across the network thereby increasing the congestion and consuming network resources. Furthermore, the SP may not own the CPE and may not have access to it continuously. Measurements may be made manually, semi-automatically or fully-automatically using test calls or live traffic. However, it should be noted that measurements using test calls normally cannot be truly representative of performance experienced by live traffic, particularly for packet-based networks and services, and can only give an estimate of likely performance experienced by the user. Only if the test calls are sent along a parallel connection that has been established with the same route and QoS class can the result be significant. This is possible in a permanent virtual connection, but unlikely in a dynamically switched network. Furthermore, test call monitoring traffic competes with Customers traffic and therefore increases network congestion and consumes valuable network resources. TeleManagement Forum 2001 GB 917 v1.5

62 Page 44 SLA Management Handbook The time line aspect of reporting network incidents affecting QoS can be illustrated thus: T0 T1 T2 T3 T4 T5 T6 T7 Defect Customer Detection NM Action Referred Notifications Customer Physical Intro Impact Started Impact 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 Reporting Methods Service end users want clear and concise information about QoS that is primarily technology-independent, predictable, measurable, accurate, easy-to-understand and applicable. QoS/SLA reporting is covered in more detail in NMF 503 and TMF 701, including both normal and exception reporting, and both externally to the Customer and internally within a SP. These documents also cover reporting methods such as web-based user interfaces, which is one specific technology implementation of a Customer interface - there are others, for example, report repositories that a Customer can access on demand. Flexibility in performance reporting of key QoS/SLA parameters is likely to increase with the use of enabling technologies such as Wireless Application Protocol (WAP). These are the kinds of tools the Customer might have in order to check whether they are receiving the kind of service quality for which they contracted. GB 917 v1.5 TeleManagement Forum 2001

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

64 Page 46 SLA Management Handbook 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 Aggregation of Parameters and QoS Index In order to simplify specification and reporting of QoS parameters, it may be desirable to aggregate a number of parameters into some kind of QoS Index (figure of merit) over the reporting period. Trying to relate technology-independent and technologyspecific QoS/SLA parameters might be considered delving too deep down into the Telecom Operations Map [GB 910]. Nevertheless, finding some way of aggregating performance parameters into a simpler QoS Index could give a SP a competitive advantage as well as being simpler for Customers to understand. The Quality of Service Development Group (QSDG) have started considering an Objective Quality Score (OQS) in order to enable end-to-end quality control mechanisms to be implemented over converged networks. This proposes a rating system providing an independent score index based on the industry standard test parameters, and results in rating variations from the industry median score. In this format, a carrier may score above or below the median and receive AAA to CCC rating from an independent rating service. This approach merits further study Customer Satisfaction QoS is not equivalent to the user s perception of a given service. According to ITU-T Recommendation E.800, QoS is the profile (more or less complete) of the numerous values of the QoS measures, including both administrative- and network-related measures [E.800]. The well known Pareto 80/20 rule often applies - 80% of the problems can be identified from 20% of the measures. For example, 80% of Customer complaints might refer to a small number of parameters such as too long a delay for new installations, agreed time to repair and restore service not met, poor support information and service, high congestion in the busy hour, etc. One challenge is to identify Customer-sensitive measures and particularly the values that satisfy the Customer, which may vary from one target group (market segment) to another. The QSDG has been studying Customer satisfaction for some time. The usual method of measuring Customer satisfaction is using a survey, the value of which is naturally subject to the type of questions asked, and the quality of the data obtained from them. A full survey covers many aspects of the telecommunication business such as Pre-sales, Post-sales, Development, QoS/NP, Fraud and Security, etc. In constructing and managing SLAs, some means of measuring Customer satisfaction should be implemented. Cultural issues and human factors need to be taken into account. The Customer satisfaction/perception with/of a given service or selected parameters can be assessed, for example, by the Mean Opinion Score (MOS) rating method in terms of bad 1, poor 2, fair 3, good 4, excellent 5. GB 917 v1.5 TeleManagement Forum 2001

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

66 Page 48 SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

67 SLA Management Handbook Page 49 Chapter 5 SLA Life Cycle 5.1 Life Cycle Automation Management of SLAs/QoS requires interaction between many of the TOM processes [GB 910]. In order to analyze the interactions and individual requirements more thoroughly, various stages or phases must be considered separately first. This life cycle of a SLA is analyzed in the five phases as shown in Figure 5.1. After the phases are introduced, a set of use cases and the flow-through of the TOM processes are presented. These use cases are not intended to be prescriptive but are provided to illustrate one approach to the process flows involved in SLA management. The five phases used to analyze SLA Management are: Product/Service Development Negotiation and Sales Implementation Execution Assessment Product/Service Development Negotiation and Sales Implementation Execution Assessment Develop Templates and Parametric Boundaries Negotiate Individual Contracts Take Line/Service Orders and Provision Monitor, Surveillance, Maintain, Bill Reassess Figure 5.1: Service and Associated SLA Life Cycle TeleManagement Forum 2001 GB 917 v1.5

68 Page 50 SLA Management Handbook Product/Service Development The Product/Service Development process can be started by several events. Both internal and external triggers may show a SP that it is time to develop another SLA; market demand, competitive pressures (not always the same as market demand), internal indications of service conditions, extreme experiences with current SLAs. The phase of SLA service development covers: Identification of Customer needs Identification of appropriate service characteristics What parameters? What levels of service? What values? Identification of network capabilities Preparation of standard SLA templates Each service description identifies the relevant SLA parameters and indicates whether SLA parameter values can be selected individually or in a bundled fashion. A discussion of potential SLA and QoS parameters can be found in chapter 4. Exit Criteria: New service(s) with SLA Templates Negotiation and Sales Negotiation and Sales is the phase where a Customer subscribes to a service offering, with or without modifications. The model presented here assumes that the Customer is contracting for many potential service instances for installation and delivery over time (contract period). In general, the process will be approximately the same for individual instance sales where a SLA is involved, since a SLA is a contract which has several responsibilities that must be spelled out during the negotiation phase. The phase includes: Selection of the values of SLA parameters applicable to a specific service instance The costs incurred by the Customer when signing the SLA The costs incurred by the SP when a SLA violation occurs Definition of reports associated with service (note that the time when a report may be generated is dependent on the periods related to the relevant SLA parameters, e.g. availability over a unit of time, such as one day, week, month, quarter, year) Exit Criteria: Signed Contract. GB 917 v1.5 TeleManagement Forum 2001

69 SLA Management Handbook Page 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 Execution Assessment 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 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 SP s overall quality goals, objectives and risk management. These two assessment and review activities have differing uses within the SP. Customer Periodic Review Quality of Customer Service Satisfaction of Customer with Service Quality Improvement Potential Changing Customer Requirements Internal Business Review Overall Service Quality across all Customers Realignment of Service Goals Realignment of Service Operations Identification of Service Support Problems Creation of different SLA levels TeleManagement Forum 2001 GB 917 v1.5

70 Page 52 SLA Management Handbook 5.2 Use Cases and Scenarios The following use cases start the analysis of data flows and process actions required to support the above SLA life cycles. By looking at each phase of the life cycle, the detailed ramifications of SLA management on the baseline TOM processes can be evaluated. The inputs and outputs listed below are selected based on their relevance to SLA/QoS management and do not repeat flows that would be covered as a non- SLA related service. TOM processes participate in more than one life cycle phase. The use cases which follow are provided to relate the life cycle phases above to the TOM processes which support SLA management [GB 910]. The desired list of use cases is: Product/Service development with a new SLA New SLA against existing service New service with SLA Negotiation of SLA Contract Sell individual service instance with associated SLA Basic Service Execution Steady state, no problems Steady state, degraded performance, no SLA violation Steady state, SP detected SLA violation Steady state, Customer reported problem no SLA violation Steady state, Customer reported problem SLA violation Periodic Customer assessment Periodic business assessment GB 917 v1.5 TeleManagement Forum 2001

71 SLA Management Handbook Page Product/Service Development with a New SLA Customer Interface Management 1 2 Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections 5 3 Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount 6 4 Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt Figure 5.2: Creation Portion of Service Development In Figure 5.2, the information flow of the first part of the creation of a service is depicted. 1. Customer requirements are gathered either over time or as a result of a Customer RFP. These requirements are for services with SLAs that do not currently exist, either no service at all, a service with no SLA offered, or Customer SLA needs that exceed the current SLA parameter definitions. This information flow includes the service description for the base service (SAP, SAP technology, access technology, speeds, overall circuit parameters (e.g. CIR), etc) and the QoS parameters required by the Customer (see chapter 4). SALES: would take the disparate requests from separate customers, examine the current catalogue of services for close matches, estimate the business potential for new Customers, additional revenue from existing Customers, plus the value of retained revenue, and pass the requests to service planning and development. Part of this function is sometimes performed in a group termed Product Line Management or Marketing. 2. The Customer requirements combined with the potential market value for this new service and the estimated service lifetime is passed to Service Planning and Development. SP&D: splits the requirements into operations-specific requirements and network/technology requirements. (Service) Architectural alternatives for providing the new service are weighed and the operations impacts of the different architectures are balanced against the different potential impacts of changing service needs (emerging technologies that could drive Customer demand in a different direction, e.g. VoIP, or TeleManagement Forum 2001 GB 917 v1.5

72 Page 54 SLA Management Handbook 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 TeleManagement Forum 2001

73 SLA Management Handbook Page 55 Customer Interface Management 8 7 Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount 12 Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt Figure 5.3: Internal Notice Portion of Service Development Phase SP&D: analyzes all returned data and determines the possible SLAs that will meet the company's risk model. 7. SP&D returns the permissible SLA parameters with values to Sales (PLM) with ranges of values, required financial returns necessary to cover risks, geographic restrictions, and lead time before the SLAs may be offered. 8,9,10,11,12. Notices of new service parameters go to most of the rest of the organization for inclusion into standard business practices Negotiation and Sales Figure 5.4 depicts the data flow during the Negotiation and Sales phase of a SLA service. The end of this phase is a signed SLA with both Customer and SP knowing exactly what is expected of each other, what is covered and when, and what recourse is available. TeleManagement Forum 2001 GB 917 v1.5

74 Page 56 SLA Management Handbook Customer Interface Management 1 Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount 6 3 Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt Figure 5.4: The Negotiation and Sales Phase of SLA Management 1. Customer inquiry for service contract including SLAs. 2. Service and SLA details. 3. Network inventory reservation details commensurate with SLA details requested. 4. Inventory and service details back to ordering/contracting office based on feedback received from network inventory reservation request. 5. Network and SLA details to SQM to initialize monitoring all aspects. 6. Rate rebate SLA information to set up Customer rate rebate details in preparation for individual sales on contract. 7. Initialization details for Customer s QoS and SLA parameters. 8. Signed and ready for individual sales SLA Implementation During implementation, a Customer s 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 TeleManagement Forum 2001

75 SLA Management Handbook Page 57 Customer Interface Management 1 Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt 8 Figure 5.5: Implementation Flow of SLA Instantiation 1. An order against an existing contract with SLAs. This order can be by phone, fax, or via an E-Bonding arrangement. 2. Order enters the service configuration process. This may be automatically through a direct customer web interface, or through other electronic ordering channels (i.e. this and step 1 may be the same step). 3. The order, along with the SLA parameters, enters provisioning, starting the applicable installation and provisioning timers. 4. The additional facilities are entered into the database for data acquisition and retention. 5,6,7. Order details conditioning the appropriate processes to include the newly ordered service for later SLA processing. 8. Confirmation of successfully ordered and hopefully tested service. 9. Response to Customer. May be electronic from same systems used in Normal Execution Also known as steady state, normal execution is the phase where the Customer receives service on all the contracted and instantiated service instances. This section analyzes the situation where although service outages occur, no outage exceeds either the individual or aggregated parameters set in the SLA. TeleManagement Forum 2001 GB 917 v1.5

76 Page 58 SLA Management Handbook Customer Interface Management 4 Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections 6 3 Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt 3a 1a Figure 5.6: Normal Execution of SLA Service 1. Notifications and Performance Data arrive from the service-providing infrastructure. These are in the form of: Alarms that represent the failure of a component that affects the service of one or more Customers. Threshold Crossing Alerts that represent congestion or performance degradation in a congestable resource that forces slowed or diminished capacity to perform Customer services. Performance data from various service components that is used for general monitoring of service levels, as well as longer-term prediction of required resource upgrades. 2. In the case of Alarms, the network undertakes restoration procedures, including reporting the outage to the Service Problem Resolution process, indicating the time and potential duration of the outage to allow Service Problem Resolution to determine potential alternate actions. 3. Both positive and negative data is then fed to the Service Quality Management Process for QoS calculations and averaging to maintain statistical data on the supplied service. 4. Individual Service interruption data is sent to the Customer QoS Management process for tallying against individual Customer's SLA contracts. 5. Overall Service Quality data is sent to the Customer QoS Management to monitor and report aggregate technology and service performance. GB 917 v1.5 TeleManagement Forum 2001

77 SLA Management Handbook Page Periodic Service Performance reports are sent to the Customer on either a requested or agreed basis Execution with SLA Violation From time to time, service conditions will exceed the parameters specified in the SLA. At least two cases need to be examined, one where the SP detects the outage first, and one where the Customer detects and reports it first. The second case is depicted in Figure 5.7. Customer Interface Management Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount 8 4 Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt 6 5 Figure 5.7: Customer Detected SLA Violation 1. In this instance, the Customer perceives service degradation and reports the visible parameters to the Problem Handling process. 2. These are checked against the Customer's SLA to determine potential priorities or other actions dependent on the type of Customer contract. 3. The entire problem with contract commitment data is given to the Service Problem Restoration process for normal flow handling. 4. In some cases, Service Problem Resolution will require changes to be made to the underlying infrastructure per contractual agreements. This requirement will be sent to the Network Maintenance and Restoration process for activation. In other cases, the data will be simply reported to Service Quality Management process for incorporation into ongoing Customer and service quality monitoring and management. TeleManagement Forum 2001 GB 917 v1.5

78 Page 60 SLA Management Handbook 5. Where infrastructure changes were required to resolve the Customer's problem, the results of the changes as well as the time taken and all other infrastructure and operational parameters are reported to the Network Data Management process for normal reporting and tracking purposes. 6. Infrastructure data from any corrections is forwarded to the Service Quality Management process as a result of the impact of the negative infrastructure activities. 7. Since the implication of the scenario initialization was that the Customer detected a SLA violation from some infrastructure outage, the Service Quality Management process should detect this and report it to the Customer QoS Management process, assuming that there was actually a SLA violation. 8. Assuming that a SLA violation was detected, Customer QoS Management would report the violation to the Rating and Discounting process for billing adjustment. 9. This discount is reported to the Invoicing process for normal monthly billing inclusion (or whatever the SLA had specified). 10. The Customer is notified in semi real-time about the actions taken on their behalf. 11. The normal bill comes at the end of the billing cycle with the SLA agreed treatment included 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 TeleManagement Forum 2001

79 SLA Management Handbook Page 61 Customer Interface Management 1a Sales Order Problem Handling Customer QoS Mgmt Invoicing Collections 1c Service Planning Develop Service Config Service Problem Resolve Service Quality Mgmt Rating Discount 1b Network Planning Develop Network Inventory Mgmt Network Provision Network Maint Restore Network Data Mgmt Figure 5.8 Assessment Initiation Flows 1. Requests to reassess the parameters of SLAs are sent to the Service Planning and Development process. These can originate from: 1a. The Customer with needs to change the parameters because their business needs have changed, 1b. Service Quality Management because the service being provided is not meeting the required levels on an average basis, 1c. Customer QoS Management because given SLAs are not being supported and require excessive rebates. With minor differences, these inputs are taken and factored back into the same process and flows as in Service Development, this time with sharpened data and objectives. TeleManagement Forum 2001 GB 917 v1.5

80 Page 62 SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

81 SLA Management Handbook Page 63 Chapter 6 SLA Management Framework This chapter describes a set of potential functions that can be used to provide process automation to aspects of the SLA Management life cycle. 6.1 SLA Management Functions As previously discussed in chapter 5, the SLA Management process life cycle covers five phases: Product/Service Development, Negotiation and Sales, Implementation, Execution, and Assessment. Figure 6.1 positions the SLA-related functions over the Telecom Operations Map, aligned with the phases of the life cycle [GB 910]. Customer Interface Management SLA Negotiation SLA Order Handling Customer SLA & QoS Reporting Sales SLA Planning & Development Order SLA Service Configuration Problem Customer QoS Handling SLA Management Proactive Monitoring QoS Analysis & Reporting Invoicing and Collections SLA Rating & Discounting Service Planning & Development Service Configuration Service Problem Resolution Service Quality Service Performance Management Data Warehousing Rating and Discounting Network Planning & Development Network Inventory Management Network Provisioning Network Maintenance & Restoration Application & Server Performance Data Collection Process Performance Data Collection Network Data Technology Management Performance Data Collection Product & Service Development Implementation Data Collection & Aggregation (out of scope of current Handbook work) Negotiation & Sales Execution & Assessment Figure 6.1: Potential SLA Management Functions Product/Service Development Product/Service Development functions support service planning and development activities in forecasting, defining, and constructing a catalogue of available service products. Service products are created in terms of functionality, characteristics and the related SLA templates. TeleManagement Forum 2001 GB 917 v1.5

82 Page 64 SLA Management Handbook Application support for Product/Service Development helps the SP to determine what service to offer, what classes of service to offer, what parameters to measure for each class of service and what standard parameter values to guarantee for each class of service. It is also important to identify the impacts of the introduction of a new service on the operation of existing services Negotiation and Sales The catalogue of service products is then used during the Negotiation and Sales process to negotiate service options, classes of service and potentially the values of SLA parameters with the Customer. The scope for negotiation may depend on the service on offer and the type of Customer. For example, a SP may offer only predefined service levels to residential or SOHO Customers, but may allow custom negotiation with large corporate Customers. During sales and ordering the SP captures the Customer-specific information for a particular service offering and verifies the order s feasibility. This requires the verification of available network resources and the capability to meet and assure the requested level of service 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 Execution and Assessment The Network Data Management process is supported by a number of functions, each one collecting different types of raw performance data from different sources. For example, Network Performance Data Collection collects raw network performance data from network elements and network element management systems. Process Performance Data Collection collects raw operational process performance data from systems such as Trouble Ticketing and Provisioning. Application & Server Performance Data Collection collects raw service performance data from other applications (e.g. , web servers and DNS). GB 917 v1.5 TeleManagement Forum 2001

83 SLA Management Handbook Page 65 Customer/SLA Layer Service Layer SLA Proactive Monitoring Service Performance Data Aggregation Customer SLA & QoS Reporting QoS Analysis & Reporting Data Collection Layer Network Performance Data Collection & Server Application & Server Performance Data Collection Process Performance Data Collection E.g. ATM, FR, IP E.g. Web Server, DNS E.g. Trouble Ticketing, Service Provisioning Execution & Assessment Data Collection & Aggregation (out of scope of current Handbook work) Figure 6.2: SLA Performance Data Collection As shown in Figure 6.2, raw process data and service configuration details related to operational process parameters are aggregated to provide service level quality metrics from the technology, service and process performance data. QoS Analysis & Reporting and SLA Proactive Monitoring use the service performance data to correlate service performance against set operating targets and SLA guarantees. The Customer SLA Reporting function correlates QoS data with Customer service descriptive data and SLA thresholds in order to produce SLA reports detailing offered services and service quality achieved. 6.2 SLA / QoS Data Management The challenge to providing truly integrated SLA Management is the effective management of all the related Service and Customer data. SLA Management functions need to combine, correlate, assess, and manage a wide variety of data sources to effectively manage the fulfillment and assurance of SLAs. There is a need to draw on many data sources within a SP s Operations Support System (OSS) environment, such as information on Customers, services, and service performance (as shown in Figure 6.3). TeleManagement Forum 2001 GB 917 v1.5

84 Page 66 SLA Management Handbook Service Instances Customer Details SLA Contracts Customer SLA Performance Data SLA Reports Service QoS & Performance Data Service Descriptions SLA Templates QoS Reports Product & Service Development Raw Performance Data Implementation Negotiation & Sales Execution & Assessment Figure 6.3: SLA/QoS Related Data GB 917 v1.5 TeleManagement Forum 2001

85 SLA Management Handbook Page 67 Chapter 7 SLA Modeling and Guidelines 7.1 Introduction Much as the SLA management processes are an integral part of a SP s total service management solution, so too is the actual SLA an integral part of the service provider s 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 Customer s quality expectations into the SP s terms. It is outside the scope of this chapter to identify criteria and guidelines to perform this mapping. 7.2 Role of SLAs within Service Products A SP maintains a portfolio of products and services available for Customers to order. This product portfolio consists of a number of commercial offers. A commercial offer TeleManagement Forum 2001 GB 917 v1.5

86 Page 68 SLA Management Handbook represents a service package offered by the SP to the Customer and could be a single service (e.g. an ATM PVC) or a service bundle (e.g. an xdsl access with and web hosting). The SP may package different service bundles to meet different Customer requirements (Figure 7.1). may purchase Product Bundle 0..* 0..* Customer 0..* may purchase 2..* Commercial Offer 0..* SLA Template 0..* 0..* composed of 1..* 1..* Service Element * 1..* Service Level Objective composed of 1..* Service Resource Figure 7.1: Service Composition The commercial offers available to the Customer are composed of a number of supporting service capabilities, or service elements. Each service element may be associated with a class or grade of service (e.g. Gold, Silver) as defined by a set of standard SLAs, or SLA templates. A service element typically models technology-specific capabilities (e.g. an ATM bearer service, IP connectivity, xdsl connectivity) or operational capabilities (e.g. help desk support) and represents the individual features typically visible to Customers (although actual visibility to the Customer depends on the SP s policy and on the nature of the service). The capabilities of any service element are provided by the capabilities of one or more other service elements, or at the lowest level, one or more physical service resources. Service resources are the base level building blocks for composing the basic service elements and are usually not visible to the Customer. The service resources are the key elements over which the SP has control to manage the levels of service offered and measure the levels of service achieved. A service decomposition example is described later around Figure 7.3. An actual instance of a SLA is the specific definition of the required quality for a specific service instance, or set of instances, of a commercial offer for a single GB 917 v1.5 TeleManagement Forum 2001

87 SLA Management Handbook 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 contract 10 (Figure 7.2). Customer agrees to 1..* Service Contract agrees to 1..* 0..* 1 relates to covers Commercial Offer 1..* instantiates 1 1..* 0..* Service Instance 1..* defines service level objectives for 1 SLA Template 1..* 0..* references Service Provider 1 contains Service Level Agreement 0..* Figure 7.2: Relationship between the SLA and Service Instances Figure 7.3 depicts a service composition example for an IP Access service with and web hosting. The underlying service capabilities are supported by a number of service resources, such as the access network and application servers. The combination of these service resources provides the basic service elements from which commercial offers can be composed. The SLA templates represent pre-defined differentiated levels of service that define the service level objectives for a service element and are used to build the definition of a commercial offer. Commercial Offers Residential Basic Internet SOHO Basic Internet SOHO PRO Internet SLA Templates Basic Premium Residential Access SOHO Access SOHO PRO Access Web Hosting Silver Web Hosting Gold Service Elements Service IP Access Service Web Hosting Service Service Resources Server Authentication Server DHCP Server Access Device Network Elements Web Server Figure 7.3: Service Composition Example 10 The actual relationship between the service contract and the SLA can be SP-specific, for instance the SLA can be considered part of the contract, or the SLA can be considered to be the contract. TeleManagement Forum 2001 GB 917 v1.5

88 Page 70 SLA Management Handbook Defining the Level of Service The role of the SLA template is to capture a set of service level objectives for a service along with details of consequences for not meeting the specified objectives, and potentially any exclusion conditions, as shown in Figure 7.4. The service level objective is the representation of the guaranteed level of service offered in the SLA, as previously described in Chapter 4, Figure 4.7, which defines individual objectives for a service in terms of the service metric, threshold values, and tolerances. A service level objective could be related to the entire service bundle, to a service element, or to a single SAP, but it is always connected to something visible to the Customer. Commercial Offer 1 defines service level objectives for Service Level Agreement 0..* 1..* references 0..* SLA Template * defines 1..* defines 1..* defines 0..* Service Level Objective applies to 1 1 Consequence 1..* 0..* applies to Exclusion 1 SLA Parameter Figure 7.4: Components of a SLA Template The production of a SLA template is an intrinsic part of service development. These SLA templates relate to standard product/service offerings and contain default values specified during the product/service development phase. Once a Customer purchases an instance of a service, the template is used as the blueprint to form the actual SLA as part of the service contract between the Customer and the SP. As discussed previously in this Handbook, there may also be scope for custom negotiation of the SLA terms between the Customer and the SP, depending on the type of service offered. In this situation, the SLA Template provides a baseline for negotiation. SLA templates effectively form part of the SP s product catalogue. For the Customer the choice of SLA level may be explicit in the service order, or may be implicit in the commercial offer or product bundle description (e.g. a VIP bundle which combines a set of gold level services). GB 917 v1.5 TeleManagement Forum 2001

89 SLA Management Handbook 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) Multiple Domain SLAs As previously discussed, a service element could depend on another service element to provide an underlying service capability. For example, there are dependencies between an IP connectivity service and an access service to an ISP gateway, and between a mailbox service and an IP connectivity service. Therefore, the service offering provided to the Customer could be built as a bundle of services with or without mutual relationships. In these cases, the SLA template should take into account dependencies between services because SLA parameters are impacted by these relationships (e.g. availability of an IP connectivity service depends on the availability of the access service). In addition, dependencies between services could extend beyond the boundary of a single contract. A service element might depend on other service elements in different service offerings from the same SP. Dependencies could span multiple SP domains (or different organizations within the same SP, as in the case of internal SLAs), this is illustrated in the example of Figure 7.5. In the provision of the ISP service to the Customer, Service 1, there are a number of sub-domain services, Services 2-6, that build up the end-to-end service delivery, each potentially being subject to a SLA. Customer End-to-end Service Service 2 Service 1 Service 3 Internet Service Provider Access Provider Service 4 Network Service Provider Service 5 Network Service Provider Service 6 Figure 7.5: End-to-end Service Delivery across Multiple Service Domains Where services cross multiple SPs, the significance of ensuring consistency of SLA parameters and their values in all the supporting SLAs must be considered. There could be (at least) two different types of SLA between SPs (or internal SLAs). In the simple case there is a straightforward relationship between capabilities of the TeleManagement Forum 2001 GB 917 v1.5

90 Page 72 SLA Management Handbook supplied service to the requirements of the consuming service with a one-to-one mapping between the service instance and the Customer, as shown in Figure 7.6. Here SP1 can make a direct correlation between the Customer SLAs a,b,c and the SP2 SLAs 1,2,3. End-to-end Service SLAa SLAb SLAc Service Provider 2 SLA1 SLA2 SLA3 Service Provider 1 Customers Figure 7.6: Multiple Domain SLA Relationships Example 1 The second type of SLA, depicted in Figure 7.7, could be needed when SP2 cannot provide service to SP1 at the same granularity as SP1 provides to the end Customer. In this case, which happens for example when a predefined capacity within a backbone network is set up during network creation by SP2 for SP1 s Customers, there is no direct correlation between SLAs a,b,c and SLA4. In particular, SLA4 could not be based on parameters related to a single customer service, but could focus on statistical indicators related to the Grade of Service (GoS, see Section 4.1.5) of the entire bundle provided by SP2 to SP1. End-to-end Service SLAa SLAb Service Provider 2 SLA4 Service Provider 1 SLAc Customers Figure 7.7: Multiple Domain SLA Relationships Example SLA to Service Mapping One of the key aspects of a SLA is the association of the required levels of service to the specific service details of a Service Instance. As defined in Chapter 2, the Service Access Point (SAP) represents the logical element located between Customer and SP domains. In the case of dependencies relating to services supplied by different SPs the SAP characterizes the point where the SLA between the SPs is defined (sometime called an NNI). GB 917 v1.5 TeleManagement Forum 2001

91 SLA Management Handbook Page 73 Service Contract 0..* 1..* relates to Commercial Offer 1..* defines service level objectives for 0..* contains Service Level Agreement 0..* 1..* references 0..* SLA Template covers 1..* 1..* Service Instance 1..* provides service at relates service objective to 1..* Service Access Point 1..* has composed of 1..* Service Element 1 Figure 7.8: SLA and Service Access Point Relationships The relationship between the SLA and the SAPs for the service instance provides the mapping between the service level objectives and the physical service resources that comprise the service (see Figure 7.8). This gives the context in which to monitor performance of the SLA parameters against the service level objectives defined in the SLA. 7.3 Service Element Categories Previous sections describe the different components comprising SLAs and their relationships. This section focuses on the service element component, providing a table which identifies services offered by SPs in terms of categories, giving examples of service elements for each category (see Figure 7.9). TeleManagement Forum 2001 GB 917 v1.5

92 Page 74 SLA Management Handbook Service Category Service Element Physical Connectivity xdsl PDH SDH SONET Radio Bearer ATM FR IP Application Mailbox Web VoIP Contents On-line trade News VOD Operational Call Center Problem Handling Fulfillment/Provisioning Self Operation Call Center Self Provisioning Self Customer Care Other Security 11 Figure 7.9: Service Element Categories 7.4 SLA Mapping of QoS Parameters In order to illustrate how SLA conceptual modeling could be applied in the real world, this section provides a mapping between SLA components and the SLA parameter framework described in Section 4.1.7, using the six examples of Chapter Leased Line Service From the SLA modeling point of view, the Leased Line service is an example of a simple service that is provided between two SAPs (the leased circuit end points). SLA parameters are related to PDH or SDH transport pipe performance, such as transmission delay between the end points of the circuit or severely errored seconds (measured at the SAP). SLA parameters for a Leased Line service could be mapped to the SLA parameter framework as described by the examples provided in Figure For example, a RADIUS proxy gateway to an ISP. GB 917 v1.5 TeleManagement Forum 2001

93 SLA Management Handbook Page 75 Service Perspective Single User Instance (SAP-related) Aggregated Requirements Technologyspecific Max. Errored Seconds Ratio Parameter Category Service-specific Max. Severely Errored Seconds Ratio Max. Transfer Delay Max. Delay Variation Mean Errored Seconds Ratio Mean Severely Errored Seconds Ratio Mean Transfer Delay Mean Bit Error Ratio Technology/Service -independent Max. unavailability time Max. Time To Restore Mini mum Time Between Failures Total unavailability seconds MTBF MTTR MTTP Figure 7.10: Leased Line Service Parameter Framework Example Frame Relay Service A Frame Relay service offering could be provided by a SP on top of different network technologies and underlying protocols. Typically, the service provided to the Customer could be composed of two types of service element: physical access and connectivity services. The access service covers the access line (e.g. a T1 TDM data pipe) connecting the CPE (that could be owned by the Customer or by the SP) with the FR backbone network (NNI interface), while the connectivity service links two accesses by means of a PVC (DLCI). A Customer may purchase an access for each site it needs to be connected by the FR service, and a set of PVCs 12. SLA parameters for a Frame Relay service could be defined as: SAP such as Error or Discarded Frame Ratio for a single SAP, which is located at the UNI between the Customer and the SP or at the NNI (a backbone PVC end point) 13 ; SE for a service element composed of multiple SAPs (e.g. a connection is perceived by the Customer as a single PVC with two end point SAPs), SAP-level parameters could be aggregated to obtain a QoS value at the service level, such as Frame Loss Ratio of the PVC and the Frame Transfer Delay; Aggregated SE SLA parameters for multiple instances of the same service element could be provided, such as the mean availability for all the PVCs, or for the combination of different SE types, such as the availability of an access and all its linked PVCs; 12 The number of PVCs needed to connect all sites is (N-1) for each access. 13 This type of SAP is needed when access services and backbone PVCs are provided by different SPs. TeleManagement Forum 2001 GB 917 v1.5

94 Page 76 SLA Management Handbook Service bundle parameters aggregated for the entire service bundle, such as Service Availability and the MTTR. SLA parameters for a Frame Relay service could be mapped to the SLA parameter framework as described by the examples provided in Figure Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent Max. Frame Error Ratio for a particular PVC Max. Frame Transfer Delay for a particular PVC Frame Delivery Ratio for a particular PVC Max. Frame Delay Variation for a particular PVC Max. Frame Error Ratio for all the PVCs Mean Frame Error Ratio for a particular PVC Mean Frame Error Ratio for all the PVCs Mean Frame Transfer Delay for a particular PVC Mean Frame Transfer Delay for all the PVCs 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 Figure 7.11: Frame Relay Service Parameter Framework Example ATM Cell Delivery Service The same considerations of service provision are valid for the ATM Cell Delivery Service. The distinction made between access and connectivity services applies as well, providing help in defining SLA parameters for the different components of the SLA. SLA parameters for the ATM Cell Delivery service could be mapped to the SLA parameter framework as described by the examples provided in Figure GB 917 v1.5 TeleManagement Forum 2001

95 SLA Management Handbook Page 77 Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent Max. Cell Error Ratio for a particular PVC Max. Cell Transfer Delay for a particular PVC Max. Cell Loss Ratio for a particular PVC Max. Cell Delay Variation for a particular PVC Max. Cell Error Ratio for all the PVCs Mean Cell Error Ratio for a particular PVC Mean Cell Error Ratio for all the PVCs Mean Cell Transfer Delay for a particular PVC Mean Cell Transfer Delay for all the PVCs Max. unavailability time for a PVC Max. Time To Restore Minimum Time Between Failures Max. unavailability time for all the PVCs MTBF MTTR MTTP Figure 7.12: ATM Cell Delivery Service Parameter Framework Example IP-VPN Service The IP-VPN service offering is provided to the Customer by means of a set of accesses from the CPE (routers) to the IP backbone network. Here, two types of SE could be highlighted: the access service and the IP backbone connectivity service. As this service is related to a VPN, it is important to monitor the SLA needs at the Customer site 14, i.e. the geographical end point of the VPN. Therefore, SLA parameters for an IP-VPN service could be defined as: SAP such as IP Packet Loss Ratio for a single SAP, which is located at the entry point to a VPN connection; Customer site since a Customer site could require multiple SAPs (e.g. for connecting different sites), SAP parameters could be aggregated to obtain a QoS value at the site, such as availability of a particular site; SE for a service element composed of multiple SAPs (e.g. a connection between two SAPs) SAP parameters could be aggregated to obtain a QoS value at the service level, such as the IP Packet Loss Ratio of the connection and the IP Packet Transfer Delay; Aggregated SE SLA parameters for multiple instances of the same service element could be provided, such as the mean availability for all the accesses; 14 It could also be useful to monitor the SLA at the Customer site for FR and ATM services. TeleManagement Forum 2001 GB 917 v1.5

96 Page 78 SLA Management Handbook Service bundle parameters aggregated for the entire IP-VPN service bundle, such as Service Availability and the MTTR. IP-VPN SLA parameters could be mapped to the SLA parameter framework as described by the examples provided in Figure Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent Speed Max. IP Packet Transfer Delay for a particular access Max. IP Packet Delay Variation Max. IP Packet Loss Ratio Total UAS Max. IP Packet Transfer Delay for all the accesses Mean IP packet Transfer Delay for a particular Customer site Mean IP packet Transfer Delay for a particular access Mean IP Packet Delay Variation Mean IP Packet Throughput Max. unavailability time for an access line Max. Time To Restore Minimum Time Between Failures Max. unavailability time for a particular Customer site Max. unavailability time for all the access lines MTBF MTTR MTTP Figure 7.13: IP-VPN Service Parameter Framework Example IP Service with DSL Access This service, as described in Section 3.4.5, is a bundle of network bearer services (e.g. IP connectivity to the ISP), application services (e.g. web hosting and security) and content services (e.g. news and music), where multiple SPs could be involved in the provision of the service to an end Customer. Different SLAs could be defined throughout the value chain (e.g. between the TSP and the ISP as well as between the ISP and the end Customer) so that the end Customer can be given the required SLA support by the retail SP (e.g. the ISP). The end Customer is interested in the quality of the overall service, therefore the SLA between the ISP and the end Customer could involve all the aspects of the service bundle, providing SLA parameters which cover the network, the application and the GB 917 v1.5 TeleManagement Forum 2001

97 SLA Management Handbook 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 Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent Max. IP Packet Transfer Delay from Customer access Max. IP Packet Delay Variation Max. IP Packet Loss Ratio Mean IP packet Transfer Delay from Customer access Mean IP Packet Delay Variation Mean IP Packet Throughput Max. web server unavailability time Max. Service Content Transfer Delay Max. Service Content Delay Variation Mean web server unavailability time Mean Service Content Transfer Delay Mean Service Content Delay Variation 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 Figure 7.14: IP Service with DSL Access Service Parameter Framework Example Customer Care Help Desk Service This service offering provides an example of a simple SE that is provided to the Customer (here there is no need to explode the service into more fine grained SEs). The SAP related to this service is an abstraction of the means the Customer uses to contact the Help Desk support organization (e.g. a conceptual representation of a free toll number). SLA parameters, such as Mean Time To Respond to a Customer request, could be defined here only at the service level. This example illustrates a Customer Care Help Desk service that has only technology/service-independent parameters. Customer Care Help Desk Service SLA parameters could be mapped to the SLA parameter framework as described by the examples provided in Figure TeleManagement Forum 2001 GB 917 v1.5

98 Page 80 SLA Management Handbook Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Service - independent Not applicable Not applicable Max. Unavailability Max. Time to Respond (i.e. wait for an available operator) for a single call Max. Time to Examine a single Request (i.e. process the request) Not applicable Not applicable Mean Time to Respond Mean Time to Examine Requests Figure 7.15: Customer Care Help Desk Service Parameter Framework Example GB 917 v1.5 TeleManagement Forum 2001

99 SLA Management Handbook Page 81 References [E.800] [E.801] [FRF.13] [GB 910] [I.371] Terms and Definitions Related to Quality of Service and Network Performance including Dependability, ITU-T Recommendation E.800, Geneva, August Framework for service quality agreement, ITU-T Recommendation E.801, Geneva, October Service Level Definitions Implementation Agreement, FRF.13, Frame Relay Forum Technical Committee, Freemont, CA, August Telecom Operations Map, GB 910, Approved Version 2.1, TeleManagement Forum, Morristown, NJ, March Traffic control and congestion control in B-ISDN, ITU-T Recommendation I.371, Geneva, March [ITU-Hbk] Handbook on Quality of Service and Network Performance, ITU-T, Geneva, 1984, revised [M.60] [M.2140] [NMF 503] [P806] [TMF 701] [WP-SLA] Maintenance Terminology and Definitions, ITU-T Recommendation M.60, Geneva, March Transport network event correlation, ITU-T Recommendation M.2140, Geneva, February Service Provider to Customer Performance Reporting Business Agreement, NMF 503, Issue 1.0, TeleManagement Forum, Morristown, NJ, March Project P806, Deliverable 1, The EQoS Framework Version 2, EURESCOM, September Performance Reporting Concepts & Definitions Document, TMF 701, Evaluation Version Issue 1.1, TeleManagement Forum, Morristown, NJ, May White Paper on Service Level Agreements, Best Practices Committee, Application Service Provider Industry Consortium, TeleManagement Forum 2001 GB 917 v1.5

100 Page 82 SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

101 SLA Management Handbook Page 83 Acronyms 3GPP ABR ABT AIP ANSI ANT API ASP ASPIC ASR ATC ATIS ATM BBE BBER BER BICC B-ISDN CATV CBR CCR CD CDR CDV CDVT CE CER CIM CIR CL CLI CLR CM CMR CN CNM COPS CPE CPoF CTD DBR DiffServ DLCI Third Generation Partnership Project Available Bit Rate ATM Block Transfer Application Infrastructure Provider American National Standards Institute Access Network Transport Application Programming Interface Application Service Provider Application Service Provider Industry Consortium Answer/Seize Ratio ATM Transfer Capability Alliance for Telecommunications Industry Solutions Asynchronous Transfer Mode Background Block Error Background Block Error Ratio Bit Error Ratio Bearer-Independent Call Control Broadband Integrated Services Digital Network Cable Television (Community Antenna Television) Constant Bit Rate Call Completion Record Cell Delay Call Data Record Cell Delay Variation Cell Delay Variation Tolerance Cell Error Cell Error Ratio Common Information Model Committed Information Rate Cell Loss Calling Line Identifier Cell Loss Ratio Cell Misinsertion Cell Misinsertion Ratio Core Network Customer Network Management Common Open Policy Service Customer Premises Equipment Common Point of Failure Cell Transfer Delay Deterministic Bit Rate Differentiated Services Data Link Connection Identifier TeleManagement Forum 2001 GB 917 v1.5

102 Page 84 SLA Management Handbook DMTF Distributed Management Task Force DNS Domain Naming Service DPL Degraded Performance Limit DS Differentiated Services DSCP DiffServ Code Point DSL Digital Subscriber Line DSS Digital Subscriber SIgnalling System ECBP End-to-end Connection Blocking Probability EDC Error Detection Code EDGE Enhanced Data rates for GSM Evolution EFS Error Free Seconds EQoS EURESCOM Quality of Service ES Errored Second ESR Errored Second Ratio ETSI European Telecommunications Standards Institute EURESCOM European Institute for Research and Strategic Studies in Telecommunications FDD Frequency Division Duplex FR Frame Relay FRAD Frame Relay Access Device FSA Framework Study Area FTD Frame Transfer Delay G-CDR Gateway GPRS Support Node Call Detail Record GERAN GSM/EDGE Radio Access Network GFR Guaranteed Frame Rate GGSN GPRS Gateway Support Node GII Global Information Infrastructure GoS Grade of Service GPRS General Packet Radio Service GSM Global System for Mobile communication HCPN Hybrid Circuit-switched/Packet-based Network HTTP Hyper Text Transfer Protocol IAB Internet Architecture Board IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IMT International Mobile Telecommunications IN Intelligent Network INMD In-service Non-intrusive Measuring Device IntServ Integrated Services IOPS.ORG Internet Operators Group IP Internet Protocol IPDV IP Packet Delay Variation IPER IP Packet Error Ratio IPLR IP Packet Loss Ratio IPPM IP Performance Metrics IPTD IP Packet Transfer Delay IRTF Internet Research Task Force ISDN Integrated Services Digital Network ISM In-Service Monitoring ISO International Organization for Standardization ISP Internet Service Provider IST Information Society Technologies GB 917 v1.5 TeleManagement Forum 2001

103 SLA Management Handbook Page 85 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 Independent Software Vendor Information Technology Information Technology Association of America International Telecommunication Union Radiocommunication Sector International Telecommunication Union Telecommunication Standardization Sector Local Area Network Label Distribution Protocol Label Switching Router Maximum Burst Size Mean Cell Rate Management Information Base Mean Opinion Score Moving Picture Coding Experts Group Multiprotocol Label Switching Mean Time Between Failures Mean Time Between Outages Maximum Time Interval Error Mean Time to Provide Service Mean Time to Restore Service Mean Time to Provision Mean Time To Repair Network Effectiveness Ratio Next Generation Network National Information Infrastructure Narrow band Integrated Services Digital Network Network Management Network Measurement Development Group Network Management Forum Network-Node Interface Network Operator Network Performance Network Planning and Development Network Parameter Control Network Service Provider Network Terminating Equipment Operations, Administration & Maintenance Outage Intensity Open Network Provision Operations System Open Systems Interconnection Operations Support System Optical Transport Network Personal Computer Peak Cell Rate Plesiochronous Digital Hierarchy Public Data Network Packet Data Protocol Public Data Network Protocol Data Unit TeleManagement Forum 2001 GB 917 v1.5

104 Page 86 SLA Management Handbook 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 Peak Emission Interval Per Hop Behavior Policy Information Base Peak Information Rate Product Line Management Public Network Operator Path OverHead Performance Report Message Packet Switched Public Switched Telephone Network Permanent Virtual Circuit Quality of Service Quality of Service Forum Quality of Service Development Group Radio Access Network Request for Comments Request for Information Request for Proposal Ready For Service Date Resource Reservation Protocol Service Availability Service Access Point Statistical Bit Rate Serving GPRS Support Node Call Detail Record Sustainable Cell Rate Synchronous Digital Hierarchy Service Element Severely Errored Cell Block Severely Errored Cell Block Ratio Severely Errored Period Severely Errored Period Intensity Severely Errored Second Severely Errored Second Ratio Serving GPRS Support Node Service Level Agreement Service Level Objective Service Level Specification Service Level Specification and Usage Structure of Management Information Small Office Home Office Synchronous Optical Network Service Provider Service Planning and Development Service Quality Management Switched Virtual Circuit Traffic Conditioning Agreement Transmission Control Protocol Time Division Duplex Time-Division Multiplexing Traffic Engineering Working Group Traffic Flow Template GB 917 v1.5 TeleManagement Forum 2001

105 SLA Management Handbook Page 87 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 Time Interval Error Telecommunications and Internet Protocol Harmonization over Networks TeleManagement Forum Telecommunications Management Network Telecom Operations Map Telecommunication Standardization Advisory Group Telecom Service Provider Trouble Ticket Television Unavailable Seconds Unspecified Bit Rate Universal Mobile Telecommunications System User-Network Interface User Parameter Control Unacceptable Performance Limit Universal Time, Coordinated UMTS Terrestrial Radio Access Value Added Reseller Virtual Circuit Virtual Circuit Identifier Video On Demand Voice over IP Virtual Path Identifier Virtual Private Network Wide Area Network Wireless Access Protocol World Telecommunications Standardization Assembly Cross-Industry Working Team Extensible Markup Language TeleManagement Forum 2001 GB 917 v1.5

106 Page 88 SLA Management Handbook GB 917 v1.5 TeleManagement Forum 2001

107 SLA Management Handbook Page 89 Appendix I: Related Activities With the increased focus on SLAs, many standards bodies and other organizations around the world are working on SLA and QoS issues and parameters. These include 3GPP, Committee T1, ETSI, EURESCOM, IETF, the European Union s IST program, ITU-T, and the Quality of Service Development Group (QSDG). This Appendix attempts to summarize the current work, but it must be recognized this is only a snapshot of what is an evolving study. The authors are grateful to these bodies and their work, which has provided useful input for this Handbook. I.1 3GPP The 3GPP (Third Generation Partnership Project) was established in 1998 and is composed of organizational partners (e.g. regional standards bodies) and market representation partners (e.g. industry associations) who have agreed to cooperate in the production of globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile System based on evolved GSM (Global System for Mobile communication) core networks and the radio access technologies that they support (i.e. UMTS Terrestrial Radio Access (UTRA) both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) modes). The Partners have further agreed to cooperate in the maintenance and development of the GSM Technical Specifications and Technical Reports, including evolved radio access technologies (e.g. General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE)). Individual members wishing to participate in the work can do so if they are members of one of the organizational partners. Work on a variety of aspects of 3 rd 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 (Quality of Service, Concept and TeleManagement Forum 2001 GB 917 v1.5

108 Page 90 SLA Management Handbook Architecture) and 3G TS (General Packet Radio Service (GPRS); Service description; Stage 2). The QoS concept in 3G TS suggests using the following traffic classes in order to classify the performance requirements: conversational streaming interactive background Based on these traffic classes the document describes detailed parameters concerning UMTS bearer services. 3G TS enhances the Packet Data Protocol (PDP) context mechanisms introduced in GPRS stage 1 and introduces another concept called Traffic Flow Template (TFT). TFT enables the use of multiple simultaneous PDP contexts per user with different performance requirements. TFT serves as a group of filters that are signaled to the GPRS Gateway Support Node (GGSN) during PDP context activation or modification. Each PDP context has one TFT but each TFT may contain up to eight filters (the first PDP context established might not have a TFT thus serving as a default PDP context). 3G TS (Charging and billing; 3G call and event data for the Packet Switched (PS) domain) describes the mechanisms used for charging and billing. The QoS information in the S-CDR (Serving GPRS Support Node Call Detail Record) which is generated by the SGSN (Serving GPRS Support Node) and in the G-CDR (Gateway GPRS Support Node Call Detail Record), which is generated by the GGSN, is related to the PDP context activation and modification. Each time there is a tariff or QoS change, a container is added to the CDR (Call Detail Record). Further information on the work of 3GPP is available from its web site 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 TeleManagement Forum 2001

109 SLA Management Handbook Page 91 T1A1.2 - Network Survivability Performance T1A1.3 - Performance of Digital Networks and Services These Working Groups are responsible for developing standards and technical reports related to their area of focus. T1A1.1 has a number of ongoing projects concerned with performance and performance measurements for a variety of media. T1A1.2 is studying network survivability performance by establishing a framework for measuring service outages and a framework for classifying network survivability techniques and measures. It has produced a number of technical reports and is working on a Draft Technical Report on a Reliability/Availability Framework for IP- Based Networks and Services, which includes discussion of how to specify reliability/availability metrics in SLAs. T1A1.3 is investigating the performance of networks and services with particular focus on performance parameter definitions, measurement methods and techniques, and numeric objects. Information on current projects and work in progress is available from the web site: 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 ETR 138, Quality of Service indicators for Open Network Provision (ONP) of voice telephony and Integrated Services Digital Network (ISDN), December 1997 ETSI TS , 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: TeleManagement Forum 2001 GB 917 v1.5

110 Page 92 SLA Management Handbook 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: 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 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 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 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 [ITU- Hbk] 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 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 TeleManagement Forum 2001

111 SLA Management Handbook Page 93 Deliverable D2: Methodologies and tools for QoS measurement and management, February 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 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 D1 investigates existing and prospective technologies supporting QoS for multi-domain IP services, including reviews of the relevant work from organizations such as ETSI, IETF and ITU-T, and also EURESCOM itself. More detailed information on some of these technologies is provided in a series of annexes to the main document. Deliverable D2: Selected Scenarios and requirements for end-to-end IP QoS management, February 2001, investigates some approaches to managing IP between service providers on an end-to-end basis. Various business models for interconnection between operators to support IP QoS services are introduced and scenarios provided to demonstrate how end-to-end IP QoS could be provided and managed for different services. SLAs between providers and the kind of parameters they may contain are discussed. An annex provides further details of the issues discussed. I.4.4 Other Projects of Relevance Project P803 European IP Testbed was concerned with various aspects of IPv6 and support for QoS in an IP network. Volume 1 of its deliverable D4: Supporting Differentiated Quality of Service in IP Networks, August 1999, provides an evaluation of various approaches to QoS in IP networks. Project P807 JUPITER II - Usability, Performability and Interoperability Trials in Europe investigated the network technologies required to provide end-to-end QoS over IP, particularly for multimedia services. Deliverable D3 Achieving Quality in New Multimedia Services, March 2000, reports on the measuring methods and TeleManagement Forum 2001 GB 917 v1.5

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

113 SLA Management Handbook Page 95 Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors and network managers. The technical IETF work is carried out in its working groups, which are organized by topic into various areas. These areas comprise Applications; General; Internet; Operations and Management; Routing; Security; Transport; and User Services. Each area has one or two area directors and several working groups. A working group is a group of people who work under a charter to achieve a certain goal. That goal may be the creation of an information document or a protocol specification, or the resolution of problems in the Internet. The Internet Architecture Board (IAB) provides the architectural oversight for the work being undertaken in the working groups and is the technical advisory group for the Internet Society. The working groups publish work in progress as Internet Drafts, which have a limited lifetime (a maximum of six months) and no formal status but which indicate the direction of the work being undertaken. Requests for Comments (RFCs) are documents that have reached a certain maturity and stability and which cover a wide range of issues, including the specification of Internet standards. Internet development has been based on protocols that provide a fault-tolerant besteffort service which does not guarantee any specific QoS. However, as Internetbased network usage is becoming more ubiquitous and supporting more complex services, often with stringent real-time and commercial requirements, the IETF has concerned itself with how to provide QoS over the Internet. A number of working groups are currently investigating various aspects of the issue, mainly at the transport flow level. A brief summary of the status of the work considered most pertinent to QoS and SLAs is provided in the following sections. Further information on the working groups, their charters, Internet Drafts and RFCs, past meeting proceedings, current activities/actions, etc. is available at the IETF web site: I.5.1 Differentiated Services Working Group The Differentiated Services (DiffServ) Working Group has developed a packet-based priority service model that provides multiple classes of service in the network 15. Decisions on the quality of service of packet delivery are made at the boundary of a network. The border routers of a network use 6 bits (the DiffServ Code Point - DSCP) in the IP packet header to allocate the packet to a particular class of service 16 and can control admission of packets to the network. This DSCP is used by the core routers within the network to determine the forwarding treatment, or per hop behavior (PHB), of the packet. Three PHBs have been specified: a default Best Effort PHB, Expedited Forwarding 17, which requires packets to be serviced according to the rate associated with the PHB, and Assured Forwarding 18, which delivers packets in four different classes each with three different levels of drop precedence. Work has also been undertaken on the interaction of differentiated services with IP tunnels 19, and on 15 RFC 2475, An Architecture for Differentiated Services, December RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December RFC 2598, An Expedited Forwarding PHB, June RFC 2597, Assured Forwarding PHB Group, June RFC 2983, Differentiated Services and Tunnels, October 2000 TeleManagement Forum 2001 GB 917 v1.5

114 Page 96 SLA Management Handbook the specification of per domain behaviors describing QoS attributes across a DiffServ domain 20. 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 SLA 21, 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) instead 22. A SLS corresponds to the network performance levels that a SLA would have to be mapped to and should provide a set of parameters and their values for determining traffic profiles. The current focus includes work on additional components required to support differentiated services, a model for managing and configuring DiffServ routers, a SMIv2 MIB for implementing the DiffServ architecture, and a QoS Policy Information Base (PIB) for configuring QoS policy for differentiated services. I.5.2 Integrated Services Working Group The Integrated Services (IntServ) Working Group was one of the first to investigate support for QoS on the Internet. It has developed an enhanced service model which can provide QoS support for individual traffic flows in the network using a flow-based reservation service 23. This is established by use of a signaling protocol, such as RSVP 24, to request the class of service required. In addition to the default Best Effort service class which provides no QoS control, IntServ specifies a Guaranteed service 25, which imposes upper bounds on end-to-end delay and provides an assured level of bandwidth for real-time applications with stringent delivery requirements, and a Controlled Load service 26, which provides applications with a service equivalent to best effort under unloaded conditions. I.5.3 IP Performance Metrics Working Group The IP Performance Metrics (IPPM) Working Group is developing a set of IP-related standard metrics that can be applied to the quality, performance and reliability of Internet data delivery services. The aim of the work is to enable providers and users of Internet transport services achieve an accurate and common understanding of the performance and reliability metrics for paths through the Internet. It also offers a forum for sharing information about the implementation and application of these metrics. A framework for the IP performance metrics work has been developed 27, 20 RFC 3086, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, April 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 RFC 2210, The Use of RSVP with IETF Integrated Services, September RFC 2212, Specification of Guaranteed Quality of Service, September RFC 2211, Specification of the Controlled-Load Network Element Service, September RFC 2330, Framework for IP Performance Metrics, May 1998 GB 917 v1.5 TeleManagement Forum 2001

115 SLA Management Handbook Page 97 which provides the basis for the work on measuring connectivity 28, delay 29 and packet loss 30. Work is being undertaken on one-way loss pattern sample metrics, an instantaneous packet delay variation metric, and the issues associated with application-level measurements of network performance for periodic streams. I.5.4 Internet Traffic Engineering Working Group The Internet Traffic Engineering Working Group (TEWG) was set up at the end of 1999 and is concerned with the performance optimization of operational networks. The group is working on a framework document which is intended to provide a common basis for the development of traffic engineering capabilities for the Internet and which will include discussion of the principles, architectures and methodologies for performance evaluation and performance optimization of operational IP networks. The group is focusing in the first instance on the control aspects of intra-domain Internet traffic engineering although it may also consider solutions to the problems of traffic engineering across autonomous systems boundaries. I.5.5 Multiprotocol Label Switching Working Group The Multiprotocol Label Switching (MPLS) Working Group has been working on a label-switching approach that encapsulates packets with a label between the layer 2 and layer 3 headers. This label identifies the data flow to which the packet belongs in that domain, thus enabling different QoS approaches to be adopted towards the individual data flows 31. The Working Group is responsible for standardizing the base label-switching technology in conjunction with network layer routing and for specifying the implementation of that technology over various link technologies. It has developed the base Label Distribution Protocol (LDP) for communication between Label Switching Routers (LSRs) 32, the basic MPLS architecture 33 and the encoding to be used by LSRs 34. It has also produced specifications for running MPLS over ATM 35 and Frame Relay 36 links. It is working on specifying improved fault tolerance mechanisms for LDP, on specifications for running MPLS over additional technologies, and on specifying the framework for IP multicast over label switched paths. I.5.6 Policy Framework Working Group The Policy Framework Working Group is developing a framework for policy-based management that will enable policies and policy information to be represented, managed, shared and reused in a vendor-independent, interoperable and scalable manner. Work has been undertaken on developing a QoS policy schema and a 28 RFC 2678, IPPM Metrics for Measuring Connectivity, September RFC 2679, A One-way Delay Metric for IPPM, September 1999, and RFC 2681, A Round-trip Delay Metric for IPPM, September RFC 2680, A One-way Packet Loss Metric for IPPM, September RFC 2702, Requirements for Traffic Engineering Over MPLS, September RFC 3036, LDP Specification, January RFC 3031, Multiprotocol Label Switching Architecture, January RFC 3032, MPLS Label Stack Encoding, January RFC 3035, MPLS using LDP and ATM VC Switching, January RFC 3034, Use of Label Switching on Frame Relay Networks Specification, January 2001 TeleManagement Forum 2001 GB 917 v1.5

116 Page 98 SLA Management Handbook 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 Group s 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 information 37. Current work on terminology is aiming to provide a glossary of policy-related terms 38. In this glossary, a SLA is defined as the documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service. A Service Level Objective (SLO) which partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA is defined as a set of parameters and their values. A Service Level Specification (SLS) is defined as a combination of an SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce) I.5.7 Resource Allocation Protocol Working Group This group is working to support a QoS-enabled Internet by establishing a means of policy control for RSVP. It is coordinating its work with the Policy Framework group and has established a framework for policy-based admission control decisions to support QoS 39. It has developed the COPS (Common Open Policy Service) Protocol 40, which enables a policy server and its clients to exchange policy information, and usage of the COPS protocol to support policy provisioning 41. It intends to develop an object syntax for information related to QoS policy provisioning. I.6 IST Projects The European Union has a research program IST (Information Society Technologies) which includes projects investigating SLAs and QoS, as introduced below. Further information on the program and projects is available from I.6.1 AQUILA Project IST 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 Policy Terminology, April 2001, Internet Draft <draft-ietf-policy-terminology-03.txt> 39 RFC 2753, A Framework for Policy-based Admission Control, January RFC 2748, The COPS (Common Open Policy Service) Protocol, January RFC 3084, COPS Usage for Policy Provisioning, March 2001 GB 917 v1.5 TeleManagement Forum 2001

117 SLA Management Handbook 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 I.6.2 CADENUS Project IST 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 I.6.3 FORM Project IST 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 I.6.4 M3I Project IST 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 I.6.5 TEQUILA Project IST 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 TeleManagement Forum 2001 GB 917 v1.5

118 Page 100 SLA Management Handbook 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 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 TeleManagement Forum 2001

119 SLA Management Handbook 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 It remains to be seen if this new Study Group will also study aspects of wireless NP and QoS. Information on 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 and E 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 ITU-T Recommendation E.800 Terms and definitions relating to QoS and NP including dependability 43 ITU-T Recommendation E.801 Framework for service quality agreement TeleManagement Forum 2001 GB 917 v1.5

120 Page 102 SLA Management Handbook Study Group 2 has developed close collaboration with the IETF on IP-related studies, and is developing a new E.TE-series of Recommendations on Framework for Traffic Engineering & QoS Methods for IP-, ATM- & TDM-based Multi-service Networks. I.7.2 ITU-T Study Group 4 Telecommunication Management, including TMN ITU-T Study Group 4 is responsible for studies regarding the management of telecommunication services, networks, and equipment using the telecommunication management network (TMN) framework. Additionally it is responsible for other telecommunication management studies relating to designations, transport-related operations procedures (including configuration, fault and performance management), and test and measurement techniques and instrumentation. As lead Study Group for TMN, Study Group 4 has the responsibility of ensuring consistent application of TMN principles by all Study Groups in their development of TMN-related specifications. Study Group 4 has a number of Working Parties, one of which is very focused on operational performance and QoS. It takes the design NP and QoS long-term objectives specified by Study Group 13 and develops practical operational end-to-end objectives and allocations between network sections. Examples are the M series Recommendations for PDH and SDH leased circuits and M.2100-series Recommendations for digital paths and networks. New Recommendations in the M.22xx and M.23xx series are being developed for ATM and IP networks and services. Study Group 4 also develops TMN performance monitoring, test and measurement techniques, and test equipment specifications for characterizing QoS and NP on network equipment, systems and services. Other groups within SG 4 develop TMN Recommendations for overall network and service management, including the procedures for exchanging performance information between NOs/SPs. It was agreed at the WTSA to transfer studies on Customer Network Management (CNM) from Study Group 7 to Study Group 4. A new Study Group 4 activity has been started on management of Hybrid Circuit-switched/Packet-based Networks (HCPNs) in partnership with ATIS T1, IETF and ETSI TC/TMN. I.7.3 ITU-T Study Group 7 Data Networks and Open System Communications ITU-T Study Group 7 was responsible for studies relating to data communication networks and the application of open system communications standards including networking, directory and security. It was the lead Study Group on frame relay and for communication system security. At the TSAG (Telecommunication Standardization Advisory Group) meeting in March 2001, it was decided to merge Study Groups 7 and 10 into one new Study Group 17 called Data Networks and Telecommunication Software. This new Study Group retains the responsibilities and lead Study Group status of Study Group 7 and adds those of Study Group 10 on technical languages and methods, and software aspects of telecom systems. Up until the WTSA, Study Group 7 had five Working Parties, one of which was responsible for network and service characteristics including NP and QoS. In the new study period, two Questions are specifically relevant, one on NP and QoS in FR and GB 917 v1.5 TeleManagement Forum 2001

121 SLA Management Handbook Page 103 packet-switched data communication networks and another on end-to-end QoS multicast communications. These include the likely support of selected network services by FR, particularly IP-based services. Performance parameter definitions are constructed that provide a common performance vocabulary for network providers and end users. These parameter definitions include service availability and are useroriented. Objectives providing a floor of performance are provided for service offerings. Examples for packet-switched Public Data Networks (PDNs) can be found in Recs X X , X , X , and X Estimation methods for assessing NP may also be provided, e.g. Recs X and X (Note: this study area has potential overlap with similar work in Study Groups 2, 4, 12, 13 and 16). Study Group 7 is also responsible for Frame Relay standards coordination within ITU- T, ISO/IEC and the Frame Relay Forum. It has proposed that all the FR protocolrelated Recommendations, e.g. X.36. X.76. Q.933, are handled in a single Question, and that the scope of this work should include FR/ATM interworking. Closely related to this are studies on FR QoS including Recommendations X , X , and X 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 N- series on NP and QoS for sound programme and television networks and services. 44 ITU-T Recommendation X.134 Basis for defining packet-switched performance parameters 45 ITU-T Recommendation X.135 Speed of service (delay and throughput) performance values for PDNs 46 ITU-T Recommendation X.136 Accuracy and dependability performance values for PDNs 47 ITU-T Recommendation X.137 Availability performance values for PDNs 48 ITU-T Recommendation X.140 General QoS parameters for communication via PDNs 49 ITU-T Recommendation X.138 Measurement of performance values for PDNs 50 ITU-T Recommendation X.139 Echo, drop, generator and test DTEs for measurement of performance values 51 ITU-T Recommendation X.144 User information transfer performance parameters for data networks providing FR PVC service 52 ITU-T Recommendation X.145 Performance for data networks providing FR SVC service 53 ITU-T Recommendation X.146 Performance objectives and QoS classes applicable to FR TeleManagement Forum 2001 GB 917 v1.5

122 Page 104 SLA Management Handbook Some of these relate to NP of equipment and transmission links while others specify QoS of the services themselves. In the new study period, two Questions are specifically focused on QoS aspects. I.7.5 ITU-T Study Group 11 Signalling Requirements and Protocols ITU-T Study Group 11 is responsible for studies relating to signalling requirements and protocols for IP-related functions, some mobility-related functions, multimedia functions and enhancements to existing Recommendations on access and internetwork signalling protocols of ATM, N-ISDN and PSTN. It is the lead Study Group on intelligent networks. Until the WTSA, Study Group 11 had five Working Parties, one or two of which deal with some QoS issues such as signalling of QoS requirements. An example of this is Rec. Q within the DSS 2 family of ITU-T Recommendations. In the new study period, one Question is specifically devoted to signalling requirements for flexible management of dynamic bandwidth and QoS demands in connection control. Particular attention is also being drawn to the study of Bearer-Independent Call Control (BICC), which defines a new protocol to establish a call (e.g. a voice call) to be established on any bearer (e.g. IP connection, becoming a VoIP call). I.7.6 ITU-T Study Group 12 End-to-end Transmission Performance of Networks and Terminals ITU-T Study Group 12 is responsible for guidance on the end-to-end transmission performance of networks, terminals and their interactions, in relation to the perceived quality and acceptance by users of text, speech, and image applications. This work includes the related transmission implications of all networks (e.g. those based on PDH, SDH, ATM and IP) and all telecommunications terminals (e.g. handset, handsfree, headset, mobile, audiovisual, and interactive voice response). Within its general area of study, a particular focus of Study Group 12 is the end-toend transmission quality delivered using a path that, with increasing frequency, involves new interactions between terminal types and network technologies (e.g., mobile terminals and networks with IP segments). As the lead Study Group on QoS and Performance, Study Group 12 develops roadmaps for ITU-T activities in these areas. Until the WTSA, Study Group 12 had three Working Parties, two of which included studies on NP and QoS. One studies subjective and objective assessment of audio and video quality. The other studies transmission performance and planning. I.7.7 ITU-T Study Group 13 Multi-protocol and IP-based Networks and Their Internetworking ITU-T Study Group 13 is responsible for studies relating to internetworking of heterogeneous networks encompassing multiple domains, multiple protocols and innovative technologies with a goal to deliver high-quality, reliable networking. 54 ITU-T Recommendation Q DSS No.2 Signalling of individual QoS parameters GB 917 v1.5 TeleManagement Forum 2001

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

124 Page 106 SLA Management Handbook 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 (ex-i.380) specifies a framework for NP and QoS events and parameters. Rec. Y.1541 (ex-i.381) is being drafted specifying performance objectives and allocations. I.7.8 ITU-T Study Group 15 Optical and Other Transport Networks Study Group 15 is the focal point in ITU-T for studies on optical and other transport networks, systems and equipment. This encompasses the development of transmission layer-related standards for the access, metropolitan and long haul sections of communication networks. Particular emphasis is given to global standards providing for a high-capacity (Terabit) Optical Transport Network (OTN) infrastructure, and for high-speed (multi-megabit) network access. Study Group 15 has been and continues to be the lead Study Group on Access Network Transport (ANT) and has produced the ANT Standardization Plan. It is also now the lead Study Group for optical technology-related standards. Clearly, Recommendations for equipment, systems and networks have a bearing on NP and QoS delivered to the Customer. These include the G-series Recommendations on compression and speech enhancement signal processing, voice gateway, and ATM/IP transport network equipment. Study Group 15 also cooperates closely with the IETF, particularly in the area of management of transport networks, systems and equipment, and has three official representatives to the IETF. I.7.9 ITU-T Study Group 16 Services, Systems and Terminals Study Group 16 is responsible for studies relating to multimedia service definition and multimedia systems, including the associated terminals, modems, protocols and signal processing. It is the lead Study Group on multimedia services, systems and terminals and also for ebusiness and ecommerce. Following the WTSA in the new study period, Study Group 16 is organizing its studies in a matrix structure with eight so-called horizontal Questions covering Framework Study Areas (FSAs) and thirteen so-called vertical Questions that are projectoriented to deliver Recommendations. One of the FSAs is an umbrella Question for all multimedia studies called Mediacom Another FSA is QoS and end-to-end performance in multimedia systems. Looking forward, multimedia services will be frequently operated over packet networks that support various types of QoS features, including but not limited to ATM QoS services and IP QoS services. The general topic of how multimedia systems and codecs interact with and request QoS from the network and how this relates to end-to-end performance will be studied under this 59 ITU-T Recommendation Y.1540 IP packet transfer and availability performance parameters GB 917 v1.5 TeleManagement Forum 2001

125 SLA Management Handbook Page 107 FSA. Other FSAs include multimedia architecture, applications and services, interoperability, media coding, security and accessibility. Much of Study Group 16 s work is focused on H-series Recommendations for network terminal equipment whose specifications contribute significantly to NP and QoS. However, their work includes definition of differentiated QoS IP services and support of those and IP network reliability, integrity and availability. Study Group 16 has a goal to operate multimedia services over existing and evolving IP networks as defined by the IETF, has identified needed network improvements, and is working with IETF on these requirements. Many of the H-series Recommendations will be referenced/co-numbered in the Y-series Recommendations for IP-based networks and the GII. I.8 Quality of Service Development Group The Quality of Service Development Group (QSDG), a separate body but part of ITU, attempts to coordinate QoS study across the ITU and with other bodies such as EURESCOM. Set up by ITU-T Study Group 2, the QSDG holds meetings at least once a year and publishes articles on QoS and SLAs four times a year in the QSDG Magazine. The QSDG has taken great interest in the use of IP to handle voice traffic and has been discussing network monitoring to assess QoS for IP-based networks. The QSDG has noted that users accessing IP-based networks, especially the Internet, tend to have far longer call durations than normal voice telephony users. This may have an impact on the QoS experienced by other users trying to gain access to services. At a recent meeting, the QSDG noted the importance of the new telecom operators, usually called virtual telcos, who do not have their own network, but choose to resell capacity on those owned by others. This increases the need for defining, monitoring and managing SLAs between operators. The QSDG has established Task Groups on the following areas: effectiveness and quality in multimedia; Internet quality and performance issues; correlation between QoS/NP parameters, perceived Customer satisfaction and network management controls/actions; 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; TeleManagement Forum 2001 GB 917 v1.5

126 Page 108 SLA Management Handbook use of CDRs for QoS/NP improvements. The QSDG plans to work in partnership with ITU-T Study Group 2 on revising Recommendation E.801 on Service Quality Agreements and on a new Recommendation on Service Level Agreements. It is also working on developing a simple QoS Index that can be used to qualify the QoS of ISPs and TSPs. The QSDG also works closely with the Network Management Development Group (NMDG), another offshoot of ITU-T Study Group 2. The QSDG has recognized what it calls the semantic disparity problem of two competing strains involved in mapping of the well-being of elements in the enterprise infrastructure into the well-being of services. This can be summarized as: Parameters that are easy for network specialists to measure do not translate well into parameters that are readily understood by ordinary Customers. Parameters that are readily understood by consumers are not easy for network specialists to measure. Furthermore, as the demand for hosted applications continues to grow, Applications Service Provider (ASPs) are taking steps to convince Customers that their hosted applications will be delivered and will perform as promised. The rationale is simple: as enterprises begin to look to ASPs to host more mission-critical applications, they are also demanding a higher level of performance and operational responsibility from their carriers. Application-specific SLAs tell IT managers that their carriers are willing to guarantee availability or pay the price in either a stiff penalty or a hefty service credit. Information on the QSDG is available from its web site: 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 Service Provider Industry Consortium) The ASP Industry Consortium is an international group of companies representing all aspects of the ASP industry that was formed to promote the ASP industry by sponsoring research, promoting best practices and articulating the measurable benefits of the evolving ASP delivery model. The ASPIC Best Practices Committee has produced A White Paper on Service Level Agreements, November 2000, intended to provide SPs in general and ASPs in particular with information to help them prepare, negotiate and provide their customers and partners with SLAs. The document (which is available to ASPIC members only) provides four SLA templates covering network, hosting, application, and Customer care / help desk. Each of these GB 917 v1.5 TeleManagement Forum 2001

127 SLA Management Handbook Page 109 templates consists of a set of SLA elements, metrics and, whenever available and practical, industry ranges and calculation criteria. ATM Forum: 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): 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): 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 The CIM Core Policy Model provides an extension to the CIM for representing policy information. It is intended to support the specification TeleManagement Forum 2001 GB 917 v1.5

128 Page 110 SLA Management Handbook 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: 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: 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 Forum s formal approved implementation agreements. One agreement of relevance is the Service Level Definitions Implementation Agreement, FRF.13, August This implementation agreement defines a reference model and service metric definitions for transfer parameters that describe frame relay service performance. Internet2: 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 Internet Operators Group (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 TeleManagement Forum 2001

129 SLA Management Handbook 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) 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): ITU-R was established in 1993 and is responsible for all ITU s 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 ITU- R Recommendations concerning radiocommunication services and systems. MPEG (Moving Pictures Coding Experts Group): 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: 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 The mission of this group is to further QoS guarantees throughout the end-to-end TeleManagement Forum 2001 GB 917 v1.5

130 Page 112 SLA Management Handbook 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): 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 QOSF s 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 GB 917 v1.5 TeleManagement Forum 2001

131 SLA Management Handbook Page 113 Annex A: ebusiness SLA Management A.1 Introduction This annex addresses the SLA issues particular to services requiring ultra-high availability, a requirement that exists for an increasing number of ebusinesses. The ubiquity of universal voice interconnections between disparate systems now applies to data services globally. This annex addresses data, multimedia and voice service requirements as they are increasingly provided over the same backbone networks. A.1.1 Background ebusiness (or ecommerce) requires special attention for SLA management. The telecommunication industry is now in a third phase of maturity. In phase one ( s) 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 ( s) 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 ( >>>) the loss of telecommunication service seriously jeopardizes business survival. The reliability of telecommunication services is highlighted in the CEO s 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 manufacturer s automated order processing system with all vendors connected over a private network. TeleManagement Forum 2001 GB 917 v1.5

132 Page 114 SLA Management Handbook 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 factor 60. In addition to defining SLAs, the ebusiness SP must determine what level of service to guarantee to its Customers. These decisions should take into consideration the business risk assumed by the SP for guaranteeing a particular level of service to the end user. Business risk can be broken into two distinct categories: risks within the control of the SP and those outside of its control. In order to guarantee a particular level of service, the ebusiness SP must determine the potential risk factors within its control and those which are not. The ebusiness SP should decide the contents of a SLA only after careful evaluation of all of its performance risk factors and their respective causes. Ultimately, the price of a delivered service should reflect the SLA conditions as well as the SP performance risk. A.1.2 Definition For the purposes of this Handbook, the following definition applies: An ebusiness is a business where the impact of even a short loss of any telecommunication-related service will cause severe loss of revenue and may even threaten the survival of the business. Where a business does not require ultra high availability, the main Handbook applies. A.1.3 SLA Groups The range of players potentially involved in the ebusiness value chain with SLAs include: Application Service Provider (ASP). The ASP expertise lies in IT management for hosting particular services or applications, or in storage and management of its Customers data. Independent Software Vendor (ISV). The ISV is an expert in the software or content that end users use to be efficient, effective and speedier to market. Application Infrastructure Provider (AIP). The AIP is a company that has expertise in managing very large, highly capital-intensive data centers. 60 This and the following paragraphs as well as section A.1.3 are based on work undertaken for [WP-SLA]. GB 917 v1.5 TeleManagement Forum 2001

133 SLA Management Handbook Page 115 Network Service Provider (NSP). The NSP is a company that provides and manages network resources. Service Portal. A service portal is a new and emerging function. Service portal companies have expertise in the management and retention of Customers for the ASP value chain. Service Aggregator. Service aggregator is a variant of service portal; it provides links to other application providers and/or acts as a reseller, combining multiple applications into a single service or service bundle. Value Added Reseller (VAR). The VAR is a distributor of products, which also provides additional services such as training and integration services. System Integrator. System integrators carry out technical integration work to ensure that new software solutions integrate seamlessly with a Customer s existing information systems. Back Office Provider. Back office companies provide specialist solutions that help ebusiness SPs in managing their internal functions. A typical way to classify ebusiness SPs is according to the specific functions they provide. In Figure A.1 three classes of SPs are shown: network, hosting, and applications with the associated help desk and business expertise. However, despite the many business partners involved in providing the services that facilitate an ebusiness transaction, the company with the direct contractual relationship to the end user bears all of the risk associated with that particular transaction. Help Desk, Problem Resolution Business, Industry and Solution Expertise Applications Management, Operating Systems, Databases and Middleware Data Center Facilities, and Server Hardware Network and Connectivity Figure A.1: Classification of ebusiness Service Providers Any incidents affecting service that impact the purchasing and delivery of an ebusiness application are usually attributed to the company with the contractual relationship to the Customer, regardless of which party is at fault. The fair allocation of risk among business partners is one way an ebusiness SP or NSP can make certain representations of warranties to its Customers. TeleManagement Forum 2001 GB 917 v1.5

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

135 SLA Management Handbook Page 117 A.2.2 Economic Considerations Mass Market for ultra-high reliability Telecommunication services have been available for years to a select Customer base able to pay the necessary (high) price for ultra-high availability. These solutions have most often taken advantage of redundancy to obtain higher levels of reliability rather than endeavor to specify unrealistically high reliability for a single service. Figure A.2 shows the impact of redundant services on increased availability on a per day basis. Dual services reduce down time by half. Significant improvement is achieved with three (or more) services. This statistical treatment assumes entirely independent services with no Common Point of Failure (CPoF). Base Service Dual Service Redundancy Triple Service Redundancy Availability Down Time Availability Down Time Availability Down Time 90% 2.4 Hrs 95% 1.2 Hrs 99.67% 4.8 Min 95% 1.2 Hrs 97.5% 36 Min 99.92% 1.2 Min 98% 29 Min 99% 14 Min 99.98% 12 Sec 99% 14 Min 99% 7 Min % 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. TeleManagement Forum 2001 GB 917 v1.5

136 Page 118 SLA Management Handbook A.3 Technical Considerations A.3.1 Common Point of Failure Reliability All components will fail. Reliability calculations are available for virtually any telecommunication component. Networks are designed to provide redundant paths, e.g. SDH/SONET, as restored essentially instantly even for a cable dig. Multiple path routing is built into the IP networks. Switching at the packet level achieves the same result as switched routing. The problem is typically at the edge (access point). Cost tradeoffs When an ebusiness requires ultra-high availability, careful attention to the cost implication of SLA parameters is needed. Very tight SLA parameter values carry an associated higher cost. Alternative technical solutions should be investigated thoroughly to assess whether the increased SLA parameter specification represents the best system solution. Care must be taken by the SP and the user so that the required service availability is clearly defined. Changing a single parameter or value may create unintentional consequences in other processes. An example of an increasingly common technical solution to achieve faster response time and increased reliability is redundancy through distributed (and mirrored) databases and systems infrastructure. This solution has an associated cost that places specific requirements on the interconnecting network. This architecture places a different impact on SLA parameter specification. Internal - external Internal CPoF for all business processes must be included in the analysis. When external CPoF is considered, an associated internal redundancy is required only to aggregate the individual external services. A.3.2 Process Automation The parameter framework in the Handbook, Chapter 4, describes two parameter sets: 1) Single User Instance and 2) Aggregated Requirements. Each of these parameter sets is associated with different time scales. This section addresses the specific issues that differentiate the requirements for an ebusiness SLA management system. Single User Instance (SAP-related) This parameter set is generally recognized as the primary source of trouble calls and individual Customer satisfaction. Therefore, the SLA directs special attention to the Single User Instance parameters. Manual support systems seldom achieve faster response than 15 minutes. Therefore the implication of GB 917 v1.5 TeleManagement Forum 2001

137 SLA Management Handbook Page 119 A.3.3 Security 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 Customer s systems must automatically compensate as well. Otherwise SLA performance targets are not achieved. Therefore the automation of processes is necessary for both the SP and the Customer. Aggregate Requirements This parameter set is generally a historical picture of performance. Special requirements for the support of ultra-high availability services fall into a necessity for immediate access to various reports and the automatic generation of reports when a threshold is exceeded (or approached). Access to Process Automation The motivation for overall SLA management is described in Chapter 3. The assumption here is that ebusiness (Customers) will have access, via the web, to a controlled set of information and functions determined by the SP. The objectives of process automation are marketing of the SP services, offering additional services for revenue generation, and reducing the cost of delivering SLA information to the Customer. Differentiation for ebusiness is to be examined for the following: Customer education of available services with SLA levels Self-service selection based on predefined SLA templates Information about speed to supply service Customer-driven service modification of SLA parameters (within a pre-agreed set) Customer query of SLA performance status 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. TeleManagement Forum 2001 GB 917 v1.5

138 Page 120 SLA Management Handbook A.3.4 Checklist and Guidelines This section will contain specific ways to specify multiple SP solutions. Multiple SP solution The main consideration of multiple services is to achieve zero Common Point of Failure. A SLA parameter in this case will be a guarantee that no CPoF exists between SP xxx and SP zzz. This capability now exists, but not visible is the production scale necessary to support a major industry move toward this architectural solution 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 TeleManagement Forum 2001

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

140 Page 122 SLA Management Handbook 1) Technology-specific, 2) Service-specific, and 3) Technology & Serviceindependent Some services may contain both technology-specific and service-specific parameters, some may contain only one or the other. A variety of examples is being developed. The two rows describe two types of impact on the Customer: 1) Single User Instance (SAP-related) and 2) Aggregated Instances Service Perspective Single User Instance (SAP-related) Aggregated Instances Parameter Category Technology-specific Service-specific Technology/Serviceindependent #1 #2 #3 #4 #5 #6 Figure B.1: Framework for Parameter Categories This parameter framework provides guidance for six categories of parameters while specifically addressing the parameters related to an individual user. As an example of the difference between a Single User Instance and Aggregated Instances: when availability is specified over a billing period, it would be possible for a single outage to shut down an individual user entirely yet still meet the aggregated instance requirement. In this example the Single User Instance parameter would define the maximum down time for a single event and the minimum time between events. This detail may be lost when working at the Aggregated Instance level. B.3 Examples B.3.1 IP Service with DSL Access The team then considered the example of an IP service (including a bundle of service elements) with DSL access to a corporate network (see Figure B.2). GB 917 v1.5 TeleManagement Forum 2001

141 SLA Management Handbook Page 123 Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Serviceindependent e.g. speed e.g. delay, throughput e.g. availability, max. time to restore e.g. total UAS e.g. delay distribution e.g. MTBF, MTTR, MTRS Figure B.2: IP Service with DSL Access Parameter Framework Example B.3.2 ATM Cell Delivery Another example considered was an ATM cell delivery service where technologyspecific and service-specific parameters are the same (see chapter 4). These ATM parameters are specified against a set of traffic profile parameters for a particular contracted ATC, e.g. DBR (see Figure B.3) Service Perspective Single User Instance (SAP-related) Aggregated Requirements Parameter Category Technology-specific Service-specific Technology/Serviceindependent e.g. CER, CLR, CTD CDV - all max. values e.g. CER, CLR, CTD CDV - all mean values and totals e.g. availability, max. time to restore e.g. MTBF, MTTR, MTRS Figure B.3: ATM Cell Delivery Service Parameter Framework Example TeleManagement Forum 2001 GB 917 v1.5