Page 1 of 7

A FRAMEWORK FOR SERVICE LEVEL AGREEMENT MANAGEMENT

Tobey Trygar Gregory Bain Telcordia Technologies and National Communications System

Piscataway, NJ Arlington, VA

Abstract Although widely cited as a mechanism for establishing clear understanding between service providers and service customers, Service Level Agreements (SLAs) have widely differing definitions within the telecommunications industry. Especially noteworthy is the lack of agreement on their scope, structure, and role in a service based system and their placement in service management systems. However, recent work of the Telemanagement Forum on SLAs provides clearer incite into the utility of these agreement. This paper describes an SLA framework and includes an example of the application of this framework to Emergency Telecommunications.

1. The Service Context 1.1 THE ENTERPRISE CUSTOMER

Figure 1 illustrates the Enterprise Customer view of the relationships among its Business Applications, Business Services, and Network Services. A Business Application is a process, function, product or service that together fulfils a Business Requirement. Examples include Call and Order Processing Centers. A Business Service is a facility that provides a business function. Examples include voice, video conferencing, and internet access. Some Business Services such as a Call Center require access to Network Services.

Enterprise Business Applications

Enterprise Business Services

Internal Network Service

External Network Service

Component Of

Supports

Supports

Supports Supports

SupportsNetwork Services

Figure 1 Services And Applications

The Enterprise’s External Network Services are obtained from Information and Communications Service Providers (ICSP). The ICSP’s telecommunications services are the Enterprise’s External Network Services

1.2 TELECOMMUNICATIONS SERVICES A telecommunications service is composed of a set of independent functions. These functions are supported by hardware and software resources including. Figure 2 illustrates the relationship between service functions and service resources.

1.3 SERVICE ACCESS POINTS A service is delivered to a Customer at conceptual points called Service Access Points (SAP). The SAPs distinguish the boundary between the Customer domain and the Service Provider domain.

Service Function

Enabling Function OAM FunctionPrimary Function

Service Resource

Staff Intellectual PropertyAnd LicensesHardware/Software

Supports

OAM = Operations, Administration, And Maintenance

Component Of

Component Of

1,,* 0..* 0..*

1..* 0..* 0..*

Figure 2: Service Functions And Service Resources Note that at a primary SAP the Enterprise service requirements are transformed into requirements for the public network provider. This transformation is based on the SLA Parameter Framework defined in Section 2.

PrimarySAP

PrimarySAPEnterprise

Campus Network

Internal Network Service

External Network Service• Service Specific • Technology Specific• Service/Technology Independent

SAP = Service Access Point

SAP

User

End-To-End

Edge-To-Edge

SAP

Private Campus Network

User

Public Network

Figure 3: SAP Locations

Page 2 of 7

Figure 3 illustrates the location of the SAP between an internal and an external network service. This SAP is always between two distinct business entities. A SAP on the business entity boundary is defined as a primary SAP to distinguish it from SAPs associated with other functional boundaries.

1.4 SERIVCE LEVEL AGREEMENTS A Service Level Agreement (SLA) is a formal negotiated agreement between two parties. 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 Service Provider (SP), such as performance of services, customer care, billing, service provisioning, etc. Given these factors, SLAs provide significant value in facilitating acquisition / contract processes for SPs and customers.

1.5 PERFORMANCE PERSPECTIVES The six factors illustrated in Figure 4 are the main contributors to the overall service performance delivered to the Customer. These factors are high level concepts that are in turn characterized by many parameters. See ITU-T Recommendations E.800 and E.801, [E.800, E.801], for more information on these performance factors and their associated parameters.

Support Performance

Operability Performance

Accessibility Performance

Retainability Performance

Integrity Performance

Security Performance

Network Item Dependability Performance

Trafficability (Grade of Service)

Performance

Is The Basis For

Network Performance

Service Performance

Component Of

Transmission Performance

Component Of

Planning, Provisioning, and Administration

Performance Figure 4: Performance Relationships

1.5.1 SERVICE PERFORMANCE The service performance factors shown in Figure 4 are defined as follows. Service Support Performance is the ability to provide a service and assist in its utilization. Service Operability Performance is the ability of a service to be successfully and easily operated by a user. Service Accessibility Performance is the ability of a service to be obtained, within specified tolerances and other given conditions, when requested by the user. Service Retainability Performance is the ability of a service, once obtained, to continue to be provided under given conditions for a requested duration.

Service Integrity Performance is the degree to which a service is provided without excessive impairments, once obtained. Service Security Performance is the protection provided against unauthorized monitoring, fraudulent use, malicious impairment, misuse, human mistake, and natural disasters.

1.5.2 NETWORK PERFORMANCE Network Performance (NP) is a conceptual framework that enables network characteristics to be defined, measured, and controlled so that business objectives can be met and Customer requirements satisfied. Usually, this requires a compromise between the cost and capabilities of a network and the levels of performance that can be supported. Many of network events may not affect customer service. 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 or the data link layers. In other cases, an application may be vulnerable to short break events that are not considered to be a server layer failure.

1.6 QUALITY OF SERVICE Quality of Service (QoS) at first appears to be a clear, unambiguous concept. However, even a brief review of the literature reveals that QoS is an extremely overloaded term. This section briefly discusses the various ways in which the term QoS has been applied and concludes with the QoS definition adopted herein. Figure 5 is a class diagram that shows the five principal views of QoS. These are reviewed and the definition of QoS is provided.

Type Of

Quality of Service(QoS)

Traffic Engineering QoS Specifications

QoSPerceived

QoSAchieved/Delivered

QoS Offered By Service Providers

QoS Desired By Service Customers

Figure 5: Five Views Of Quality Of Service

1.6.1 TRAFFIC ENGINEERING QoS concepts are used in the Traffic Engineering process. Here, the QoS requirements are the basis for determining the value of traffic engineering parameters that provide a measure of the adequacy of the physical network under specified operating conditions. These are inputs to the network design and operations design processes. See [E.490.1] for additional information on the traffic engineering process. The QoS Traffic Engineering requirements are established by an SP based on a combination of its business objectives, expected service demand, current state of its network, its financial condition, etc.

Page 3 of 7

1.6.2 PERCEIVED QOS The QoS perceived by the user/customer is a statement expressing the level of quality as degrees of satisfaction. It is typically obtained from customer surveys and from unsolicited customer comments. There are several conceptual difficulties in using user perception of service performance in SLAs. Measurements may not capture the user perception of the performance of a service. Additionally, there is the question of whether a user’s perception of QoS is relative or absolute. For example, is the user’s perception of a data service over a WAN the same as for a data service over a LAN, of a voice service over an IP-based network the same as over a Public Switched Telephone Network, or of a video service over a telecommunications network the same as for broadcast TV? Finally, Customer Care representatives have a big impact on user perceptions.

1.6.3 CUSTOMER QOS REQUIREMENTS The Customer’s QoS specifications are descriptions of the level of quality required or preferred for a particular service. The level of quality is expressed in terms of measurable factors. A typical Customer only concerned with the resulting end-to-end service quality. From the Customer's point of view, QoS is expressed by parameters that focus on user/customer-perceivable effects, are independent of the internal design of the network, span all aspects of the user’s service experience, and can be assured by the service provider(s).

1.6.4 OFFERED QOS The third use of the QoS concept is in the specification of performance levels for SLAs, i.e., the service provider’s commitment to the customer. This usage requires that the QoS be characterized in terms of quantifiable, measurable parameters. The level of quality is expressed by values assigned to QoS parameters. These parameters are usually designed to be understandable to the Customer. Each service has its own set of QoS parameters.

1.6.5 ACHIEVED/DELIVERED QOS Achieved/Delivered QoS is based on direct or indirect measurements of the service at the SAPs. The parameters to be measured, the party responsible for the measurements, and the reporting frequency are in the SLA. The delivered QoS may or may not meet the commitments contained in the SLA. Typically, the SLA will specify actions to be taken in these cases. Possible actions include administrative changes by the SP to improve the service, payment of penalties for not meeting quality objectives, or the payment of incentives for exceeding quality objectives.

SELECTING A QOS PERSPECTIVE

[E.800] defines QoS as the collective effect of service performance which determines the degree of satisfaction of a user of the service. It also notes that QoS does not express or imply a degree of excellence in a comparative sense, nor is it used in a quantitative sense for technical evaluations. This definition does not provide guidance for specifying quantifiable QoS targets. To address this need, [E.860] has modified the [E.800] definition as follows:

QoS is the degree of conformance of the service delivered to a user by a provider in accordance with an agreement, i.e., an SLA, between them.”

This is the definition used in the remainder of the paper.

1.7 SERVICE PERFORMANCE SPECIFICATION Figure 6 describes the performance aspects of a generic service. The white boxes represent abstract classes or service templates whereas the shaded boxes represent specific instances of the service. The white boxes contain lists of parameter names, whereas the shaded boxes also associates a value with each of the items in the lists. As shown in Figure 6 a service has three types of performance characterizations, viz., a Level of Service (LoS), a Quality of Service (QoS), and qualitative factors. Qualitative factors are the non-measurable aspects of a service.

LoSParameter

QualitativeFactor

1..n 1..n

Service A

1..n

QoSParameter

S1:Service A

LoS = 1QoS = α

Characterize

Instantiation Of1

1..k

QoS = Quality Of Service LoS = Level Of Service

. . .S2:Service A

LoS = 1QoS = β

S3:Service A

LoS = nQoS = ρ

Figure 6: Service Specification Model

The LoS specification is the set of parameters that specify how the service will function and the QoS specification is a set of parameters that specify how much variation in the LoS parameters the Customer could experience.

2. SLA Tools This section provides three tools that are useful for structuring the complex process of SLA preparation and management. These tools are the Service Life Cycle, the Key Quality Indicator (KQI) Development Methodology, and the SLA Parameter Framework, [GB 917-x].

Page 4 of 7

Product/

Service

Develo

pment

Negotia

tion an

d Sales

Implem

entat

ion

Execu

tion

Asses

smen

t

Develop Templatesand Parametric

Boundaries

NegotiateIndividualContracts

Take ServiceOrders and Provision

Monitor, Surveillance,Maintain, Bill

Reassess

Decommiss

ion

Terminate

Continuous Feedback

1 2 3 54 6

Figure 7: Service And Associated SLA Life Cycle

2.1 THE SERVICE LIFE CYCLE The development of an SLA spans the six phase life cycle of a service shown in Figure 7. When the Customer-Provider interactions address each of these phases, the resultant expectations will be aligned.

2.1.1 PRODUCT/SERVICE DEVELOPMENT Typical initiating events include market demand, competitive pressures, and an evaluation of the success of active SLAs. The Product/Service Development phase of the SLA life cycle covers identification of customer needs, of appropriate product characteristics, of network capabilities, and the preparation of SLA templates. The exit criteria for this phase are new product descriptions with the corresponding SLA templates.

2.1.2 NEGOTIATION AND SALES The Negotiation and Sales Phase includes negotiating service options, LoS and QoS parameters, and permissible changes. This phase includes selection of the values of SLA parameters applicable to the service instances, the costs incurred by the customer, the SLA penalties or incentives, and specification of reports associated with product. The exit criterion for this phase is a signed contract.

2.1.3 IMPLEMENTATION The Implementation Phase of the life cycle covers the activities associated with enabling and activating service instances. The three major parts to the Implementation Phase are configuration of SP resources, configuration of the service instance, and service instance activation. The exit criterion is the tested, and accepted product.

2.1.4 EXECUTION The Execution Phase covers the operation of the services specified in the SLA. This includes normal in-service

execution and monitoring, real-time reporting, and real-time SLA violation processing.

2.1.5 ASSESSMENT One type of assessment focuses on a single Customer’s SLA and on the QoS delivered to this Customer. The type occurs when the SP is reviewing its overall quality goals, and risk management procedures. This later assessment is part of an overall internal business review.

2.1.6 DECOMMISSIONING Possible SLA decommissioning issues include: responsibility for removal of equipment and wiring, removal schedule commitments, access to the Customer’s premises, and consequent change procedures.

2.2 KQI DEVELOPMENT METHODOLOGY KQI is a method for identifying metrics that capture the customer’s view of the quality of service.

Service Scenarios

AnalyzeTimeline

Identify Service Topology

Develop Matrix

Identify KPIDevelop KQIs

Step 1

Step 2

Step 3

Step 4

Steps 5 & 6

Figure 8: KQI Methodology

KQI combines a top down process for service specification with a bottom up process that captures the transactions necessary to delivery the service. This establishes a framework for mapping between the network data and the service data. The methodology starts with a description of the business problem and proceeds from the services scenarios to derive the KQIs and the measurement and metrics. The approach is illustrated in Figure 8.

2.2.1 CREATE SERVICE SCENARIOS Each service is decomposed into its service delivery components. The components are then analyzed to determine a set of service element performance and quality measurements that describe the overall KQI’s.

2.2.2 ESTABLISH TIMELINES Associated with each scenario is a timeline that captures both the customer’s and provider’s actions from the initial point of contact to the decommissioning of the service.

Page 5 of 7

The timeline identifies the customer’s interactions with the service at points in the life-cycle. It accounts for the effect of user actions and for possible options. Analyzing the timeline may require a review of the customer actions. By taking a top-down approach the full range of network and non-network interactions are identified. Business judgment is used to identify the significant interactions.

2.2.3 IDENTIFY THE SERVICE TOPOLOGY The service delivery topology is the ordered set of service resources needed to support the service. This includes the network components, the supporting system components, e.g., billing systems, the key process components, and any third party supplied service elements. The relationships between the service elements are also included.

2.2.4 DEVELOP A TRANSACTION MATRIX Each of the actions identified in the previous phase can be decomposed into discrete customer activities and technical actions. This information is represented in a transaction matrix where the rows of the matrix represent the customer interactions described Section 2.2.2 and the columns represent the service resources described in Section 2.2.3. The resources represent the primary service delivery path.

2.2.5 DEVELOP KEY QUALITY INDICATORS The Transaction Matrix is the mechanism for identifying the required KQIs. For example, the service resource column of the matrix identifies the resource availability KQIs. A degradation of the availability of any of the resources in the Transaction Matrix is likely to affect the service quality. Additionally, the interface where information is passed between service resources identifies KQIs associated with data integrity.

2.2.6 IDENTIFY MEASUREMENTS The Transaction Matrix identifies the metrics, i.e., the Key Performance Indicators (KPI), and measurements required to monitor the KQIs. This phase relates specifically to the service resources in question. The process of developing a desired measurement framework creates the necessary bottom up verification that the KQI’s support the SLA.

2.3 THE SLA PARAMETER FRAMEWORK The SLA parameter framework is used to classify service parameters so that they can be organized and defined in a consistent manner within the SLA.

2.3.1 TELECOMMUNICATIONS SERVICES The scope of an offered service must be clearly defined. For example, is it a network bearer service supporting, but independent of, the application carried, or is it an application service such as voice, video, or sound program, supported by server layer network connections? Services

based on ATM technology can be both - an ATM network bearer service used to support IP-based, Frame Relay-based or circuit-based services, or a pure cell stream delivery service. A parameter measured between (or at) SAPs of a bearer service is a network parameter to the ICSP, but a service parameter to the user or client of the bearer service.

2.3.2 PARAMETER CATEGORIES It is important to distinguish among performance parameters that are applicable to all services and all network technologies, are service-specific, or are network technology-specific. These categories and views are shown in Figure 9.

Service Parameter Categories

Technology Specific

Service Specific

Technology Service Independent

Individual User View

Parameter List 1

Parameter List 2

Parameter List 3

Aggregate View

Parameter List 4

Parameter List 5

Parameter List 6

Figure 9: Service Parameter Category Framework

Figure 10 illustrates a typical relationship between the functions defined in Section 1.2 and the parameter categories. In most cases the Service Specific parameters refer to a service’s primary functions.

Functions Technology Specific

Service Specific

Technology/Service Independent

Primary X X X Enabling X X OAM X X

Figure 10: Service Functions and Parameter Categories

2.3.3 SERVICE VIEWS The rows in the SLA parameter table, c.f., Figure 9, distinguish between the individual user view and the aggregated view. The individual user view is associated with a SAP and covers service properties such as the maximum service down-time for an individual service user during a specified time period. The aggregated view captures the average performance over all users during a specified time period. The single user view parameters are used to define the maximum down time for a single event and the minimum up-time between events. This detail could be lost at the aggregated requirements level. Note that availability performance can be specified in all six categories.

Page 6 of 7

2.3.4 PARAMETER TABLE EXAMPLES Figure 11 illustrates some typical parameters that may be found in the Service Parameter Table. Some services may contain both technology-specific and service-specific parameters, while others may not.

Service Parameter Categories

Technology Specific

Service Specific

Technology Service Independent

Individual User View

Interface Specification

Service Type

Maximum Down-Time Of One Event

Aggregate View

Reported Parameters

Billing Method

Availability - All Users

Figure 11: Typical Service Parameters

2.3.5 INDEPENDENT PARAMETERS Service/technology independent service parameters are typically specified in an SLA. Examples include Percentage Availability, time to first failure, average call response time, etc. Furthermore integrated or consolidated billing for a basket of services, accuracy of billing and payment terms may also be included. Other service/technology independent factors are billing period, security (of both service access and information transfer/delivery) and the specification of alternate routing/redundancy of network connections providing the service, possibly including avoidance of Common Points of Failure (CPoFs). For many mission-critical services, these factors are very important. It should be noted that most of the service/technology independent parameters are specified and measured with respect to time. Thus access to accurate time of day information is critical to monitoring and assessing the delivered QoS.

2.3.6 TECHNOLOGY-SPECIFIC PARAMETERS Technology-specific service parameters are related to the telecommunications technology supporting the service, particularly when the service is a network bearer service. In addition, technology-specific parameters such as SAP physical characteristics need to be specified. Some of the technology-specific parameters may not be relevant to the service end user, but need to be considered by the SP. The decision on which parameters to include in an SLA is an individual choice for each service contract. Examples of QoS parameters for network layers follow:

(1) Physical media layer: Loss, Crosstalk, Delay, Dispersion, and Q-factor.

(2) xDSL layers: Bit Rates (up - and downstream), Reach, Radiation, Crosstalk.

(3) PDH/SDH layers: Errored Seconds, , Jitter, Wander, Pointer Adjustments,

(4) ATM layers: Cell Error, Cell Loss, Severely Errored Cell Block, Cell Delay.

(5) IP layer: Packet Loss Ratio, Packet Transfer Delay, Packet Delay Variation.

One of the biggest challenges is mapping the Service parameters between different network technology layers and determining their impact on the highest-level service client in use.

2.3.7 SERVICE SPECIFIC PARAMETERS Service-specific performance parameters are typically related to the application supported and include service-specific or application-specific technology parameters such as reliability and availability of computer servers, databases, etc. Service Availability is widely considered the most significant service parameter. Service Availability depends on the combined aspects of service accessibility, retainiability and integrity. Examples of service-specific parameters for selected services are:

(1) Voice telephony: call connectivity and quality measures, e.g., Answer/Seize Rate.

(2) Data: errored Protocol Data Units (PDU), lost PDUs.

(3) Mobile telephony: Call Completion Rate, Call Dropout Rate, Noise, Echo, Distortion..

(4) Sound program: Noise, Crosstalk, Stereo Channel Interference, Distortion and Availability.

2.3.8 SERVICE DEGRADATION Network and service performance will inevitably vary over time as equipment ages and external influences take effect. Unexpectedly large variations in traffic levels may also impair service. Unforeseen events such as floods, hurricanes, earthquakes, or intentional acts may cause server service disruption. This requires that the performance levels be monitored at various points along a connection, not simply at its origin and destination.

3. Emergency Telecommunications Emergency Telecommunications (ET) is an explicit service available to authorized users that provides priority access to and preferential use of communications resources during periods of extreme service overload. An authorized user is an individual or organization to whom a priority assignment has been granted by a National Authority. In the United States, this role is filled by the National Communications Service (NCS). Authorized users include National Executive Leadership, Policy Makers, Disaster Response / Military Command and Control Staff, Public Health, Safety, and Law

Page 7 of 7

Enforcement Officials, Public Services / Utilities and Public Welfare and Disaster Recovery leaders. [TR-79, E.106, Y.1271]

3.1 THE ET LIFE CLYCE For ET services, the most significant elements of the life cycle are the Development and Assessment Phases. The NCS has activity engaged the service provider community to define its ET Service needs via participation in selected Standards Development Organizations and through direct discussions. In the United States, the Government Emergency Telecommunications Service (GETS) is an existing national switched voice and voice band data communications service that provides authorized local, state, and federal government wire line users with priority access to the Public Switched Telephone Network (PSTN) services. The NCS is currently working on priority voice over IP and broadband services. The NCS also conducts an ongoing assessment of GETS to monitor delivered services levels.

3.2 KQIS FOR ET SERVICES As noted in Section 3, ET there is a broad spectrum of ET users with each user community having unique objectives. However, in all cases, service users have stated that ET availability is paramount. Figure 12 is an example of mapping the availability KQI into service KPIs.

Support Performance

Operability Performance

Retainability Performance

Integrity Performance

Security Performance

Service Performance

Service Availability(Serveability)

Component Of

Component Of

Accessibility Performance

Figure 12: Mapping of Availability KQI to KPIs

The process of combining the three components of availability into a single metric is service dependent.

3.3 ET PARAMENTERS Figure 13 illustrates a mapping of the ET requirements into four of the six service performance factors defined in Section 1.5.1.

Requirements Access-ibility

Retain-ability Integrity Security

Priority Treatment TS TS TS Security I Location Confidentially

TS

Requirements Access-ibility

Retain-ability Integrity Security

Restorability TS TS Connectivity SS SS SS Interoperable SS Mobile TS TS TS Ubiquitous SS Survivable TS TS TS Voice TS TS TS Scaleable SS Reliability TS TS

Figure 13 ET Performance Mapping

The figure also indicates if the SLA parameter is Technology Specific (TS), Service Specific (SS) or Technology and Service Independent (I).

4. Conclusion As the scope and complexity of service offerings continues to grow, a structured approach for developing SLAs is essential. Clear service specifications are especially important for ETs that have complex requirements, extensive impacts for missed commitments, and limited opportunities for assessing performance prior to actual use. The paper describes a service context and three tools for SLA specification and illustrates the initial steps in preparing an SLA specification for a generic ET. References [E.106] Description Of An International Emergency Preference Scheme (IEPS), ITU-T Rec. E.106, 3/2000. [E.490.1] Overview Of Recommendations On Traffic Engineering, ITU-T Rec. E.490.1, 1/ 2003. [E.800] Terms And Definitions Related To Quality Of Service And Network Performance Including Dependability, ITU-T Rec. E.800, 8/1994. [E.801] Framework For Service Quality Agreement, ITU-T Rec. E.801, 10/1996. [E.860] Framework For A Service Level Agreement, ITU-T Rec. E.860, 6/2002. [GB 917-x] SLA Management Handbook Series Version 2, TeleManagement Forum, 1/2005. [TR-79] Overview Of Standards In Support Of Emergency Telecommunications Service (ETS), T1.TR.79-2003, ATIS, 2003. [Y.1271] Framework(s) On Network Requirements And Capabilities To Support Emergency Communications Over Evolving Circuit-Switched And Packet-Switched Networks, ITU-T Rec. Y.1271, 10/2004.