Chapter 7 – SLA Modeling and Guidelines
7.2 Role of SLAs within Service Products
7.2.2 Multiple Domain SLAs
As previously discussed, a service element could depend on another service element to provide an underlying service capability. For example, there are dependencies between an IP connectivity service and an access service to an ISP gateway, and between a mailbox service and an IP connectivity service. Therefore, the service offering provided to the Customer could be built as a bundle of services with or without mutual relationships. In these cases, the SLA template should take into account dependencies between services because SLA parameters are impacted by these relationships (e.g. availability of an IP connectivity service depends on the availability of the access service). In addition, dependencies between services could extend beyond the boundary of a single contract.
A service element might depend on other service elements in different service offerings from the same SP. Dependencies could span multiple SP domains (or different organizations within the same SP, as in the case of internal SLAs), this is illustrated in the example of Figure 7.5. In the provision of the ISP service to the Customer, Service 1, there are a number of sub-domain services, Services 2-6, that build up the end-to-end service delivery, each potentially being subject to a SLA.
Access
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
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.
Service Provider 2
Service Provider 1 End-to-end Service
SLA1 SLA2
SLAc SLA3 SLAb SLAa
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, SLA4could 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.
Service Provider 2
Service Provider 1 End-to-end Service
SLA4
SLAc SLAb SLAa
Customers
Figure 7.7: Multiple Domain SLA Relationships Example 2
7.2.3 SLA to Service Mapping
One of the key aspects of a SLA is the association of the required levels of service to the specific service details of a Service Instance. As defined in Chapter 2, the Service Access Point (SAP) represents the logical element located between Customer and SP domains. In the case of dependencies relating to services supplied by different SPs the SAP characterizes the point where the SLA between the SPs is defined (sometime called an NNI).
Commercial Offer
defines service level objectives for 1
0..*
references 1..*
0..* SLA Template
Service Instance Service Element
Service Access Point Service Contract
Service Level Agreement
composed of 1..*
1..*
1..*
1 covers
1..* 1..*
0..*
1 1
1..*
0..*
provides service at 1..*
1..*
relates service objective to
has relates to
contains
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).
Service Category Service Element xDSL
PDH SDH SONET Physical Connectivity
Radio ATM FR Bearer
IP Mailbox Web Application
VoIP
On-line trade News Contents
VOD Call Center Problem Handling Operational
Fulfillment/Provisioning Call Center
Self Provisioning Self Operation
Self Customer Care
Other Security11
Figure 7.9: Service Element Categories
7.4 SLA Mapping of QoS Parameters
In order to illustrate how SLA conceptual modeling could be applied in the real world, this section provides a mapping between SLA components and the SLA parameter framework described in Section 4.1.7, using the six examples of Chapter 3.
7.4.1 Leased Line Service
From the SLA modeling point of view, the Leased Line service is an example of a simple service that is provided between two SAPs (the leased circuit end points). SLA parameters are related to PDH or SDH transport pipe performance, such as transmission delay between the end points of the circuit or severely errored seconds (measured at the SAP).
SLA parameters for a Leased Line service could be mapped to the SLA parameter framework as described by the examples provided in Figure 7.10.
11 For example, a RADIUS proxy gateway to an ISP.
Parameter Category
• Max. Errored Seconds Ratio
• Max. Severely Errored Seconds Ratio
• Max. Transfer Delay
• Max. Delay Variation
• Max. unavailability time
• Max. Time To Restore
• Mini mum Time Between Failures Aggregated
Requirements
• Mean Errored Seconds Ratio
• Mean Severely Errored Seconds Ratio
• Mean Transfer Delay
• Mean Bit Error Ratio
• Total unavailability seconds
• MTBF
• MTTR
• MTTP
Figure 7.10: Leased Line Service Parameter Framework Example
7.4.2 Frame Relay Service
A Frame Relay service offering could be provided by a SP on top of different network technologies and underlying protocols. Typically, the service provided to the Customer could be composed of two types of service element: physical access and connectivity services.
The access service covers the access line (e.g. a T1 TDM data pipe) connecting the CPE (that could be owned by the Customer or by the SP) with the FR backbone network (NNI interface), while the connectivity service links two accesses by means of a PVC (DLCI). A Customer may purchase an access for each site it needs to be connected by the FR service, and a set of PVCs12.
SLA parameters for a Frame Relay service could be defined as:
SAP– such as Error or Discarded Frame Ratio for a single SAP, which is located at the UNI between the Customer and the SP or at the NNI (a backbone PVC end point)13;
SE – for a service element composed of multiple SAPs (e.g. a connection is perceived by the Customer as a single PVC with two end point SAPs), SAP-level parameters could be aggregated to obtain a QoS value at the service level, such as Frame Loss Ratio of the PVC and the Frame Transfer Delay;
Aggregated SE – SLA parameters for multiple instances of the same service element could be provided, such as the mean availability for all the PVCs, or for the combination of different SE types, such as the availability of an access and all its linked PVCs;
12 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.
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 7.11.
Parameter Category Service
Perspective Technology-specific Service-specific Technology/Service -independent
Single User Instance (SAP-related)
• Max. Frame Error Ratio for a particular PVC
• Max. Frame Transfer Delay for a particular PVC
• Frame Delivery Ratio for a particular PVC
• Max. Frame Delay Variation for a particular PVC
• Max. unavailability time for an access line
• Max. Time To Restore
• Minimum Time Between Failures Aggregated
Requirements
• 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 all the access lines
• MTBF
• MTTR
• MTTP
Figure 7.11: Frame Relay Service Parameter Framework Example
7.4.3 ATM Cell Delivery Service
The same considerations of service provision are valid for the ATM Cell Delivery Service. The distinction made between access and connectivity services applies as well, providing help in defining SLA parameters for the different components of the SLA.
SLA parameters for the ATM Cell Delivery service could be mapped to the SLA parameter framework as described by the examples provided in Figure 7.12.
Parameter Category Service
Perspective
Technology-specific Service-specific Technology/Service -independent
Single User Instance (SAP-related)
• 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. unavailability time for a PVC
• 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 all the PVCs
• MTBF
• MTTR
• MTTP
Figure 7.12: ATM Cell Delivery Service Parameter Framework Example
7.4.4 IP-VPN Service
The IP-VPN service offering is provided to the Customer by means of a set of accesses from the CPE (routers) to the IP backbone network. Here, two types of SE could be highlighted: the access service and the IP backbone connectivity service. As this service is related to a VPN, it is important to monitor the SLA needs at the Customer site14, i.e. the geographical end point of the VPN.
Therefore, SLA parameters for an IP-VPN service could be defined as:
SAP – such as IP Packet Loss Ratio for a single SAP, which is located at the entry point to a VPN connection;
Customer site – since a Customer site could require multiple SAPs (e.g. for connecting different sites), SAP parameters could be aggregated to obtain a QoS value at the site, such as availability of a particular site;
SE – for a service element composed of multiple SAPs (e.g. a connection between two SAPs) SAP parameters could be aggregated to obtain a QoS value at the service level, such as the IP Packet Loss Ratio of the connection and the IP Packet Transfer Delay;
Aggregated SE – SLA parameters for multiple instances of the same service element could be provided, such as the mean availability for all the accesses;
14 It could also be useful to monitor the SLA at the Customer site for FR and ATM services.
Service bundle – parameters aggregated for the entire IP-VPN service bundle, such as Service Availability and the MTTR.
IP-VPN SLA parameters could be mapped to the SLA parameter framework as described by the examples provided in Figure 7.13.
Parameter Category Service
Perspective Technology-specific Service-specific Technology/Service -independent
Single User Instance (SAP-related)
• Speed • Max. IP Packet
Transfer Delay for a particular access
• Max. IP Packet Delay Variation
• Max. IP Packet Loss Ratio
• Max. unavailability time for an access line
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 a particular Customer site
• Max. unavailability time for all the access lines
• MTBF
• MTTR
• MTTP
Figure 7.13: IP-VPN Service Parameter Framework Example
7.4.5 IP Service with DSL Access
This service, as described in Section 3.4.5, is a bundle of network bearer services (e.g. IP connectivity to the ISP), application services (e.g. web hosting and security) and content services (e.g. news and music), where multiple SPs could be involved in the provision of the service to an end Customer. Different SLAs could be defined throughout the value chain (e.g. between the TSP and the ISP as well as between the ISP and the end Customer) so that the end Customer can be given the required SLA support by the retail SP (e.g. the ISP).
The end Customer is interested in the quality of the overall service, therefore the SLA between the ISP and the end Customer could involve all the aspects of the service bundle, providing SLA parameters which cover the network, the application and the
content aspects of the service. For example, in addition to the IP-related technology-specific parameters, such as IP packet delay and jitter, application parameters, such as the web server availability (i.e. the web server is reachable from the Customer site via HTTP Get request), or content parameters, such as service content delay (i.e.
delay in transferring a minimum amount of content), could all be provided in the SLA for this service bundle.
IP Service with DSL Access SLA parameters could be mapped to the SLA parameter framework as described by the examples provided in Figure 7.14.
Parameter Category Service
Perspective Technology-specific Service-specific Technology/Service -independent
• Max. unavailability time for an access line
• Mean unavailability time for all the service bundle
• MTBF
• MTTR
• MTTP
Figure 7.14: IP Service with DSL Access Service Parameter Framework Example
7.4.6 Customer Care Help Desk Service
This service offering provides an example of a simple SE that is provided to the Customer (here there is no need to explode the service into more fine grained SEs).
The SAP related to this service is an abstraction of the means the Customer uses to contact the Help Desk support organization (e.g. a conceptual representation of a free toll number). SLA parameters, such as Mean Time To Respond to a Customer request, could be defined here only at the service level. This example illustrates a Customer Care Help Desk service that has only technology/service-independent parameters.
Customer Care Help Desk Service SLA parameters could be mapped to the SLA parameter framework as described by the examples provided in Figure 7.15.
Parameter Category Service
Perspective
Technology-specific Service-specific Technology/Service -independent
Single User Instance (SAP-related)
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)
Aggregated Requirements
Not applicable Not applicable • Mean Time to
Respond
• Mean Time to Examine Requests
Figure 7.15: Customer Care Help Desk Service Parameter Framework Example
References
[E.800] Terms and Definitions Related to Quality of Service and Network Performance including Dependability, ITU-T Recommendation E.800, Geneva, August 1994.
[E.801] Framework for service quality agreement, ITU-T Recommendation E.801, Geneva, October 1996.
[FRF.13] Service Level Definitions Implementation Agreement, FRF.13, Frame Relay Forum Technical Committee, Freemont, CA, August 1998.
[GB 910] Telecom Operations Map, GB 910, Approved Version 2.1, TeleManagement Forum, Morristown, NJ, March 2000.
[I.371] Traffic control and congestion control in B-ISDN, ITU-T Recommendation I.371, Geneva, March 2000.
[ITU-Hbk] Handbook on Quality of Service and Network Performance, ITU-T, Geneva, 1984, revised 1993.
[M.60] Maintenance Terminology and Definitions, ITU-T Recommendation M.60, Geneva, March 1993.
[M.2140] Transport network event correlation, ITU-T Recommendation M.2140, Geneva, February 2000.
[NMF 503] Service Provider to Customer Performance Reporting Business Agreement, NMF 503, Issue 1.0, TeleManagement Forum, Morristown, NJ, March 1997.
[P806] Project P806, Deliverable 1, The EQoS Framework – Version 2, EURESCOM, September 1999.
[TMF 701] Performance Reporting Concepts & Definitions Document, TMF 701, Evaluation Version Issue 1.1, TeleManagement Forum, Morristown, NJ, May 1999.
[WP-SLA] White Paper on Service Level Agreements, Best Practices Committee, Application Service Provider Industry Consortium, 2000.
Acronyms
3GPP Third Generation Partnership Project
ABR Available Bit Rate
ABT ATM Block Transfer
AIP Application Infrastructure Provider ANSI American National Standards Institute ANT Access Network Transport
API Application Programming Interface ASP Application Service Provider
ASPIC Application Service Provider Industry Consortium
ASR Answer/Seize Ratio
ATC ATM Transfer Capability
ATIS Alliance for Telecommunications Industry Solutions
ATM Asynchronous Transfer Mode
BBE Background Block Error
BBER Background Block Error Ratio BER Bit Error Ratio
BICC Bearer-Independent Call Control B-ISDN Broadband Integrated Services Digital Network CATV Cable Television (Community Antenna Television) CBR Constant Bit Rate
CCR Call Completion Record
CD Cell Delay
CDR Call Data Record CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance CE Cell Error
CER Cell Error Ratio
CIM Common Information Model CIR Committed Information Rate
CL Cell Loss
CLI Calling Line Identifier CLR Cell Loss Ratio CM Cell Misinsertion CMR Cell Misinsertion Ratio
CN Core Network
CNM Customer Network Management COPS Common Open Policy Service CPE Customer Premises Equipment CPoF Common Point of Failure CTD Cell Transfer Delay DBR Deterministic Bit Rate
DiffServ Differentiated Services DLCI Data Link Connection Identifier
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
ISV Independent Software Vendor
IT Information Technology
ITAA Information Technology Association of America
ITU-R International Telecommunication Union – Radiocommunication Sector
ITU-T International Telecommunication Union – Telecommunication Standardization Sector
LAN Local Area Network LDP Label Distribution Protocol LSR Label Switching Router MBS Maximum Burst Size MCR Mean Cell Rate
MIB Management Information Base
MOS Mean Opinion Score
MPEG Moving Picture Coding Experts Group MPLS Multiprotocol Label Switching
MTBF Mean Time Between Failures MTBO Mean Time Between Outages MTIE Maximum Time Interval Error MTPS Mean Time to Provide Service MTRS Mean Time to Restore Service MTTP Mean Time to Provision MTTR Mean Time To Repair NER Network Effectiveness Ratio NGN Next Generation Network
NII National Information Infrastructure
N-ISDN Narrow band Integrated Services Digital Network
NM Network Management
NMDG Network Measurement Development Group NMF Network Management Forum
NNI Network-Node Interface
NO Network Operator
NP Network Performance
NP&D Network Planning and Development NPC Network Parameter Control
NSP Network Service Provider NTE Network Terminating Equipment
OAM Operations, Administration & Maintenance
OI Outage Intensity
ONP Open Network Provision
OS Operations System
OSI Open Systems Interconnection OSS Operations Support System OTN Optical Transport Network
PC Personal Computer
PCR Peak Cell Rate
PDH Plesiochronous Digital Hierarchy
PDN Public Data Network
PDP Packet Data Protocol
PDN Public Data Network
PDU Protocol Data Unit
PEI Peak Emission Interval PHB Per Hop Behavior PIB Policy Information Base PIR Peak Information Rate PLM Product Line Management PNO Public Network Operator
POH Path OverHead
PRM Performance Report Message
PS Packet Switched
PSTN Public Switched Telephone Network
PSTN Public Switched Telephone Network