Chapter 28
Inter-Domain SLA Enforcement in QoS-Enabled Networks C. Marinos, V. Pouli, M. Grammatikou, and V. Maglaris
Abstract Traditionally, network Service Providers specify Service Level Agreements (SLAs) in order to guarantee service availability and performance to their customers. However, these SLAs are rather static and span a single provider domain. Thus, they are not applicable to a multi-domain environment (including edge networks of distributed Grid resources) and do not enable users with the flexibility to set up and monitor e2e services. In this chapter we present a framework for dynamic management of SLAs; the framework contains a collection of APIs and modules that allow for the dynamic creation, configuration, and delivery via automated management of an end-to-end SLA created from the merging of the per-domain SLAs. We assume that individual domains are QoS aware, since near real-time applications (e.g., IP voice and video sessions and Grids for remote control of sensors – instruments) may impose stringent performance requirements, even on over-engineered backbone and edge networks. Keywords Service Level Agreement (SLA) · Multi-domain · SLA Framework · QoS · Inter-domain · Intra-domain
1 Introduction A Service Level Agreement (SLA) is a contract between a network provider and a customer defining all aspects of the service offered. It may specify the levels of availability, serviceability, performance, and operation conditions [7, 12]. It may also define the procedures and the reports that must be provided to track and ensure compliance with the SLA or describe other attributes of the service, such as billing and penalties in case of SLA violations [2]. C. Marinos (B) Network Management and Optimal Design Lab. (NETMODE), National Technical University of Athens, Iroon Polytexniou 9, 15780 Zografou, Greece e-mail:
[email protected]
F. Davoli et al. (eds.), Remote Instrumentation and Virtual Laboratories, C Springer Science+Business Media, LLC 2010 DOI 10.1007/978-1-4419-5597-5_28,
351
352
C. Marinos et al.
In Grid environments [4] where applications or users require resources from heterogeneous domains offering various performance guarantees, the issue of acquiring a specified level of QoS is of great importance. The lack of control in traditional Best Effort IP networks created the need for efficient QoS mechanisms, notably the DiffServ protocols [8]. Marking and policing of flows is implemented in edge routers according to per-domain SLAs. This way we may offer a variety of end-toend services across multiple, separately administrated domains. Based on the DiffServ architecture, the Premium IP (PIP) service was implemented in European Research and Education Networks [11]. Using DiffServ priorities, traffic can be classified as high-priority PIP, Best Effort (BE) for standard IP applications, and Less than Best Effort (LBE) for non-time critical bulk data transfer. The Premium IP service provides a virtual leased line service as PIP data packets are not expected to experience congestion in the network regardless of the load of the other traffic classes. It is suitable for near real-time applications, such as Voice over IP (VoIP), video conferencing, and time critical remote control of instruments and devices as demonstrated in the GRIDCC project [5]. In this chapter we present a framework for dynamic management of SLAs, developed for Premium IP e2e (end-to-end) services offered in a multi-domain network. The framework allows for the dynamic creation, configuration, and delivery via automated management of an e2e SLA created by merging SLAs provided by each domain. Note that although our work concentrated on PIP offered by European Research and Education Networks and their interconnection network GÉANT2, the proposed framework is applicable to any QoS-enabled multi-domain environment. The rest of the chapter is organized as follows. Section 2 presents some related work; Section 3 describes the SLA Framework along with its core components and its architecture. Sections 4 and 5 deal with SLA management and monitoring, respectively. Section 6 concludes the chapter and presents some future work.
2 Related Work To date, several frameworks have been proposed to support the creation and management of services based on SLAs. Hoffner et al. [6] present a Contract Framework and Dan et al. [3] propose a schema to support the provision of Web Services to customers at different service levels. The Web Service Management Language (WSML) [10] provides a powerful tool for the formal XML-based specification of custom-made SLAs for Web Services. Such a language has been introduced with the specific aim of allowing the definition of SLAs in a precise and unambiguous way, an essential prerequisite for automating SLA management. Analogies also exist as to the perception of a service from the network perspective. The COPS [1] protocol, standardized by the IETF, proposes a logical approach for dispatching policies throughout the network. On the manufactures’ side, CISCO indicates DiffServ as the preferred technology to achieve SLA management and considers delay, jitter,
28 Inter-Domain SLA Enforcement in QoS-Enabled Networks
353
packet loss, throughput, and availability as the most vital SLA parameters for an IP service. Related to the above proposals, our framework proposes an automated mechanism for SLA generation, which can be deployed in real QoS-enabled networks.
3 End-to-End SLA Framework 3.1 End-to-End SLA Issues In principle, an end-to-end SLA has to contain all necessary parameters to provide end-to-end control for a service instance specification between two end points. The e2e SLA should be transparent to the end user, regardless of underlying networks and intermediate domains. For the generation of an e2e SLA, several issues have to be examined: Different ISPs must agree to cooperate with each other, authorize and configure the framework’s communication between other cooperating ISPs, and specify clearly what actions are taken and by whom. Depending on the service request type (unidirectional, bidirectional), the SLA Framework will deliver the respective end-to-end SLA. This distinction is necessary since the downstream (closer to the destination) domain may not wish to participate in the e2e marking and policing setup requested by the upstream (closer to the source) domain. In order to honor the guarantees stipulated in the e2e SLA, we need to continuously monitor, for the whole service duration, all SLA parameters in the contract between the user and the service providers. The e2e monitoring SLA will be based on the investigation and monitoring of all the per-domain SLAs along the path and must not impact on the network performance. Due to the fact that we are dealing with a multi-domain environment where QoS provisioning is each domain’s responsibility, the e2e SLA will be derived from the merging of each domain’s SLA, as shown in Fig. 28.1. The merging rules are described in Table 28.1.
3.2 End-to-End SLA Template Description An SLA is a set of technical and non-technical parameters agreed between the consumer and the provider. An SLA contract can be formed by two different parts: (i) an administrative and legal part that contains information that does not depend on the particular service (e.g., user authentication, availability information, privacy and security aspects) and (ii) the Service Level Specification (SLS) part, which is a set of parameters and their corresponding values that define the technical parameters of the service provisioning for a specific flow instance. While SLAs represent a high-level
354
C. Marinos et al.
Fig. 28.1 End-to-end SLA template
Parameters Service instance scope
Flow description
End-to-end performance guarantees
Monitoring infrastructure
Reliability
Table 28.1 SLO part Description This field should contain the technical information of the ingress interface and the egress interface of each domain involved in the path This field should contain the DSCP value, the IP source–destination address pair along with the protocol and the ports that the application is targeted to The SLA performance guarantees field of the end-to-end SLA is proposed to adopt the guarantees derived from the individual SLAs involved in the service provision across the path. More specifically, capacity will be less or equal to the minimum of the capacities in each SLA instance: Ce2e ≤ min{Ci } MTU value supported by the end-to-end SLA will be less or equal to the minimum MTU value of the chain of individual SLAs: MTUe2e ≤ min{MTUi } One-Way Delay is an additive metric and therefore the corresponding field in the e2e SLA will be produced as follows: OWDe2e ≥ {OWDi } IPDVe2e : We treat IPDV as an RMS value and use its square as an additive parameter Packet loss: This will be the sum of all the packet losses across the individual domains: PLe2e ≥ {PLi } This field should contain information on the monitoring capabilities of each domain in terms of which parameters are monitored, the points where measurements are possible, the availability of measurements Reliability should define allowed mean downtime per unit of time for the service provision and maximum allowed time-to-repair (TTR) in case of breakdown for the provision of the e2e service described by the e2e SLA, as the worst figures among the individual SLAs along the end-to-end path
28 Inter-Domain SLA Enforcement in QoS-Enabled Networks
355
description of a required service, SLSs are more formal documents containing a list of technical parameters. It is useful to deal with the SLA components as two objects. An Administrative Level Object (ALO) referring to the administrative and legal part and a Service Level Object (SLO) referring to the Service Level Specification. As mentioned before the administrative details contained in the ALO remain the same in each domain for each service request while the information contained in the SLO part is specific for every service instance. The information of the SLO part should contain the fields shown in Table 28.1. We can represent in an XML format, as shown in Example 28.1, a possible example of the two parts, the ALO and the SLO, along with the information that they contain.
Example 28.1 SLA template
