6 Service Level Management Techniques Service Level Management (SLM) techniques are applicable to a network transport operator – in the parlance of the previous chapter – providing service assurances either to another network transport operator, for a service provider, or an end user. Service level techniques pertain to aggregates of services, and are con- tractual in nature. The processes and terminology related to this subjectaredealtwithinthischapter. As in the previous chapters of this book, the terminology and concepts from telecommunications world are when they can be generalized to the multi-service Internet. In this chapter, the context of service level management is dis- cussed first, followed by a description of service planning and creation process. 6.1 MODELS FOR SERVICE LEVEL MANAGEMENT A network domain, in general, can include both transport net- work elements such as routers and service-related ones, streaming servers being examples of the latter. Both types can be present not only when a transport network operator is also providing ser- vices such as streaming, but also because a service provider may Implementing Service Quality in IP Networks Vilho R ¨ ais ¨ anen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X 180 SERVICE LEVEL MANAGEMENT TECHNIQUES Service layer Transport layer Mgmt plane Figure 6.1 Conceptual relation of management plane to service and transport layers have some kind of managed network of its own. The management system of a domain, conceptually, manages both transport and service-related resources in such a case. For this reason, the man- agement plane is often drawn as shown in Figure 6.1. In reality, the service and transport layer management is not always very integrated. Taking a service provider as an example, the manage- ment system for services may be advanced, but the transport level management may be based on tools provided by the router ven- dor. By default, there is no link between the two management sub-systems, apart from the human operator. In what follows, we shall concentrate on service level management, which leads to a general view on management hierarchy, as we shall see. 6.1.1 Areas of service level management An account of relation of service level management to general network management can be found in [Kos01], for example. The ITU-originated Telecommunications Management Network (TMN) framework cited therein consists of five functional areas, namely fault management, configuration management, accounting management, performance management, and security management. Fault management, as the name indicates, is concerned with the tasks related to error conditions in the network, including identi- fication, correction, and reporting of faults. Configuration management includes provisioning of services in servers and network elements, including configuration of the trans- port network elements in the case of an IP-based multi-service net- work. The “downward branch” of the IETF traffic engineering loop discussed in Chapter 4 is part of configuration management. 6.1 MODELS FOR SERVICE LEVEL MANAGEMENT 181 Accounting management relates to the collection of data of net- work and service usage, providing input for charging. As such, it is mostly related to the management of services, but must be related to configuration of the transport network resources, too. Performance management encompasses obtaining of data relating to the performance of network elements and services. For practical purposes, this is the “upward branch” of the IETF traffic engi- neering loop. Performance management issues will be discussed in more detail in Chapter 7. Security management addresses the mechanisms of providing security, as well as detection of security breaches. This issue is not within the scope of the present book, and is best left to dedicated studies on the subject. 6.1.2 Layers of service level management Management within each of the five areas listed above, in turn, is conceptually separated into four layers. In the order of increasing degree of abstraction, these are: 1. Element management layer. 2. Network management layer. 3. Service management layer. 4. Business management layer. The layers are illustrated in Figure 6.2. The element management layer is the interface between the man- agement system and individual network elements. The element management layer typically has an element-proprietary interface towards the individual network elements, and an abstracted inter- face towards the management system. The element management layer not only provides abstraction of the configurations of indi- vidual elements, but also provides information about the capabil- ities of the network elements. A higher level of abstraction, the network management layer provides the user of a network management system with an overview on the network level of the services and network elements. Such an overview provides a summary of the status of multiple network elements, for example, for a routing domain 182 SERVICE LEVEL MANAGEMENT TECHNIQUES Network element Network element Network element Element mgmt Element mgmt Element mgmt Network mgmt Service management Business management Figure 6.2 Layers of management in the TMN model or an entire AD. The overview of the network status must provide two kinds of information: (a) information about the operational status of individual network elements within the scope of the overview. Such information can be used for spotting individual network elements not performing according to the specification. (b) Computation of performance indicators spanning multiple elements. Such indicators can be used for identifying performance problems due to sub-optimal configuration of multiple network elements. Thresholding based on the definition of triggering conditions can be used to define multiple levels of abstraction in the net- work. Thus, for example, upon notification of a fault on AD level, the routing area granularity view can be invoked to look for the cause or causes of the malfunction. If multiple elements are simul- taneously in need of attention, the overview summary can be used to decide the order of handling the fault conditions. The service management layer handles the technical part of the con- tracts towards customers and peer operators by managing the net- work management layer. The precise functions depend on the type of the service in question, being rather different for content down- loading services and conferencing, for example. Usually the ser- vice management system has to provide possibilities for creating, 6.1 MODELS FOR SERVICE LEVEL MANAGEMENT 183 Service layer Transport layer Mgmt plane Business service Network element Figure 6.3 Combined framework modifying the composure of, and deleting services. Services that are not provided for free have a charging policy associated with them, and service invocation rights need to be managed. When services require resources from neighbouring domains, the man- agement of the technical content of SLAs for neighbours is one of its tasks. The business management layer is responsible for the business as- pects of the agreements towards different parties involved. As will be discussed below, business information is part of the SLAs in gen- eral. This topic will be mostly outside of the scope of this book. From this classification, it can be seen that service management is a device for implementing business objectives using network level tools. Comparing this hierarchy to that of Figure 6.1, it can be observed that this classification addresses the management plane only and the four layers of the above list are interfaces of the management plane towards the network and management layers (see Figure 6.3). 6.1.3 Models for managed data The TMN model reviewed above is concerned with the management processes on different abstraction levels. A more data-oriented view, the Service Level Agreement (SLA) working group of Distributed Management Task Force(DMTF) definesan object-oriented informa- tion model called the Common Information Model (CIM) consisting of the following layers [CIM99] Common Information Model (CIM) Specification, version 2.2, DMTF, June 1999. • Core models span applications, networks, devices, and users. 184 SERVICE LEVEL MANAGEMENT TECHNIQUES • Common models span the technologies within a particular management domain. • Extension models are technology-specific extensions to the com- mon models. Fromthis viewpoint, servicelevelmanagement makes use of the core and common models, being dependent on both service requirements and operator processes. More discussion about CIM and its rela- tion to other standards efforts can be found in [Kos01] and [SMJ00], for instance. Finally, service performance is also part of an IETF Application Management Information Base (MIB), specified in [RFC2564]. This RFC is mostly concerned with the application level performance measurement methods. 6.2 SERVICE PLANNING AND CREATION PROCESS To achieve accountability in service provision for the customer, service level quality needs to be defined in a contract, usually called a Service Level Agreement (SLA). Due to its bilateral con- tractual nature, the contents of a SLA are defined by the parties of the agreement, for example, the service provider and the transport operator, or the service provider and the end user. To understand what usually goes into a SLA and why, let us first take a look at the interests of a customer before proceeding to service defini- tion processes. 6.2.1 Interests of the customer It is in the interests of SLA parties to be able to define received ser- vice quality as accurately as possible. This is in principle true for inter-operator, operator/service provider, and operator/end user contracts. Naturally, long-term contracts involving large traffic aggregates tend to be more elaborate. The most important reasons for defining service quality precisely in an agreement are: • Common understanding of what constitutes an acceptable service qual- ity support. When the transport operator understands the qual- ity requirements of services end-to-end, future development of 6.2 SERVICE PLANNING AND CREATION PROCESS 185 network transport resources can take service aspects better into account. On the other hand, the service providers and customers benefit from understanding of the issues related to transport. • Transparency of charging. The customer typically wants to pay for clearly defined service performance. • Accountability. The means of assessing performance need to be agreed upon. • Definition of customers’ and operator’s liabilities in case of sub-optimal service performance. This is often important when service forms a part of the customers’ own business processes. Exceptional sit- uations have a cost associated with them, and the responsibility for financial consequences needs to be known in advance. • Security. It is important to agree in advance which information need to be divulged to sustain normal operation of the ser- vice. Also, reporting of security breaches is increasingly impor- tant [Sch00]. These main goals can be mapped to more fine-grained needs related to reporting of exceptional conditions, for example. The SLA con- tents are discussed in more detail in Section 6.3 below. It is useful to list next a few typical characteristics a customer of a multi-service transport network is interested in. The second and the third items in the list have been dealt with in the service quality requirement section already, and the building blocks for addressing the fourth one have been provided there. • Service implementation time. • Service availability. • Service continuity. • Service-specific quality parameters. Service implementation time relates to the competitive edge of customers of a transport network operator. In the case of creating “hot” and “new” ad hoc services by a service provider, or cop- ing with the need to implement quickly a modification into the composition of a service, timeliness can be important. Service availability and continuity relate to the quality of the service provided, as seen on an aggregate level. Service specific quality parameters, on the other hand, relate to the requirements of individual service instances, as discussed in Chapter 2. 186 SERVICE LEVEL MANAGEMENT TECHNIQUES Means of estimating these characteristics need to be defined. Some commonly used estimators are: • Mean Time Before Failure (MTBF). The average time between failures. • Mean Time to Provide Service (MTPS). The average time from finalizing agreement between the service operator and the customer to having the service in operational use. This can be considered to be a formalization of the service implementation time mentioned above. • Mean Time to Restore Service (MTRS). Average time from reporting a fault to service being restored. Failure is used in the above list generically to indicate a state of insufficient service quality support in the network. To define the abnormal conditions more precisely, the TeleManagement Forum (TMForum) defines different levels of deviations from the nor- mal operation of the service support in the network [SMH01]. In what follows, the terms have been interpreted from a service qual- ity support viewpoint. The following definitions assume that the desired service quality support has already been defined. • Anomaly is a discrepancy between the desired and actual per- formance. • Defect is a limited interruption in the capability of network ele- ment or network to perform required function. • Impairment is a condition giving rise to anomalies and defects without causing a failure. • Failure is the termination of the ability of a network element or network to provide the required function. • Fault is the inability of a network or network element to provide service quality support, excluding maintenance reasons, external causes, or planned actions. Fault is often the result of a failure, but may also exist without a failure. It is important to note the role of service definition in fault management according to these definitions. Unless sub-optimal performance can be clearly defined, fault correction procedure defined within SLA cannot be applied according to the terms of the agreement. 6.2 SERVICE PLANNING AND CREATION PROCESS 187 Note that in applying the above definitions to a multi-service network, the required function means support for all service qual- ity aggregate types. 6.2.2 Network operator viewpoint The set of service quality support mechanisms at the network operator’s disposal may vary. A particular level of service quality support for the customer can be provided with different combi- nations of the network-side service quality support mechanisms discussed in Chapter 3. The service performance obtained with the tools needed by service level management are identical in each case, although the actual tools on the network level may be different from each other. The mechanisms a network operator uses for configuring the service quality support typically vary with network technology. The same is typically true for measurement results based on element-level information and quality characteristics obtained from combining these. The operator must be able to provide a means of service level quality monitoring irrespective of the QoS technology used. The technologies that can be used for this purpose will be discussed at length in the next chapter. A special form of measurement is the definition of triggers for exceptional conditions that the network operator is notified of. Sub-optimal operation of the network or network elements can be communicated to the network management system in vari- ous ways. • A notification is an indication that a predefined condition has transpired in the network. Obtaining notifications requires a way of defining the conditions, a mechanism for detecting that the condition has occurred, and means of communicating the condition. Preferably also a means of detecting the malfunc- tioning of the notification mechanism should exist. • An alarm is an indication of a condition that has negative impact on the service quality support level. An alarm can be related to a network element, a part of the network, or service level, for example. From the above definition it is clear that an alarm is 188 SERVICE LEVEL MANAGEMENT TECHNIQUES a special form of a notification, and thus has basically the same kinds of requirements associated with it. The notifications and alarms in the transport network element management system that are visible to the transport operator may not have one-to-one correspondence with failures and faults defined in SLAs for service providers or end users. A simple reason for this is that the same traffic aggregate in the transport operator’s network may be shared by multiple internal or external parties, each potentially associated with their own dedicated SLA definitions. In such a case, a mapping function between the notification conditions in the network and possible external communication defined in individual SLAs may be needed. Such a mapping may involve correlating multiple network- defined conditions. From the business perspective, a service level agreement defines that the service provider will sell a certain item (service quality support) at a defined price. In this sense, the SLA is no different from any other business contract from a network operator point of view – risks have to be evaluated and a price tag assigned to them. If the network operator provides services itself, a SLA may still be used for accounting and service quality supervision purposes. In this case, the business risk associated with an operator-internal SLA may be of different type than for an external SLA, a difference which is typically reflected in the contents of the respective SLA types when it exists. 6.2.3 Service definition In order to define service quality support needed, the customer of a network provider must first define the services themselves. The customer responsible for service definition is service provider. The different ways of carrying out this task are mostly beyond the scope of this book, but an “archetypical service engineering process” is outlined for the purposes of understanding the impact on SLA definition. The service creation process starts by defining the need that the service addresses. Next, the composition of the solution to the perceived need is defined in the form of the service. Multiple [...]... of three service types Token bucket parameters used for VoIP, treatment of out-of-profile traffic Token bucket parameters used for browsing, treatment of out-of-profile traffic Token bucket parameters used for data traffic, treatment of out-of-profile traffic Table 6.3 Example PDB characteristics for VoIP, browsing, and data traffic Service PDB VoIP Browsing Data traffic Characteristics Maximal allowed 90%,... and a transport operator as well as between two transport operators Let us compare these alternatives briefly For concreteness, IP telephony spanning multiple transport domains is used as an example SLA-based interworking means that the transport operators have mutual SLAs for IP transport support for necessary service types The SLAs can in this case be thought of being static, defining the service quality... to audio quality on normal PC hardware The ETSI EP TIPHON VoIP terminal classification, taking into account the effects of terminal hardware, is one way of handling this issue, but an assessment of its applicability to Internet services in general would require more study A possible approach would be the classification of the operating systems and TCP /IP stacks according to their delay and delay variation... as well as streaming • Host and host This is relevant to point-to-point services, such as IP telephony or messaging • Group of hosts Multicast conferencing falls within this category • Server and server Example of this could be machine-to-machine communications Obviously, “host” above can mean different kinds of IP hosts, including tabletop PCs, laptops, and GPRS/3G terminals “Server” is a generic term... that Carrier Sense Multiple Access/Collision Detection (CSMA/CD) in shared media may cause fractal traffic profiles [LTW + 94] An intentionally dramatic example can be seen in Figure 6.6 Switched Ethernet helps with this problem, but may not be enough Data traffic is typically inherently bursty, and it has been speculated that the very 6.4 END-TO-END SERVICES 203 behaviour of TCP /IP can give rise to similar... service support chain for delay-critical date types [Fin02] Support for real-time services in the operating system and network drivers is paramount for VoIP, covering the areas of Operating System (OS) process scheduling, interrupt handling, TCP /IP stack implementation, and device driver support Applications need an interface for using these mechanisms When the OS supports process prioritization deterministically... mechanisms can include, but need not be limited to, the following: • DiffServ This is the main topic of this book, although the service level management techniques also apply to the other technologies • IPoATM With IPoATM, separate capacity can be reserved for some of the aggregates, or alternatively common capacity reservation can be made for all traffic aggregates • Reserved capacity for service quality support... computing the end-to-end service quality When service providers are responsible for the end-to-end services spanning multiple transport domains, they may also be responsible for routing of the service instances, at least on the high level Routing considerations are usually a part of IP telephony-related service quality scenarios, for example When there are more than one service operators involved, the... instances are analysed this way Next, the service instance is broken down into service events From the definition of service events, one can derive the service quality support needed, using the analysis principles outlined in Chapter 2 Once the technical part is completed, a marketing strategy can be drafted, yielding the expected service deployment forecast At this stage, the traffic volumes and service quality... makes charging information more easily understandable for the end user It is also desirable not to receive bills from different parties of the end-to-end chain, which is why e.g the QoS support for VoIP in the access network should preferably be charged as part of the service provider bill 198 SERVICE LEVEL MANAGEMENT TECHNIQUES Service support can be of best effort type, or true multi-service support . indicators spanning multiple elements. Such indicators can be used for identifying performance problems due to sub-optimal configuration of multiple network elements traffic. Table 6.3 Example PDB characteristics for VoIP, browsing, and data traffic Service PDB Characteristics VoIP Maximal allowed 90%, 95% and 99% delay distribution