Service Level Negotiation in Autonomous Systems Management

Service Level Negotiation in Autonomous Systems Management Nader MBAREK Francine KRIEF University of Bordeaux 1, France

Abstract We propose a framework for service level negotiation in autonomous systems management. The negotiation process occurs between high-level autonomic managers to guarantee an end-to-end service level for specijk application trafic jlows. In the proposed framework, we provide autonomous systems with a new interaction opportunity thanks to the negotiation with their peers. To be in conformance with self-aware management systems, the proposed negotiation protocol called SLNP is used in a Web services environment.

1. Introduction The quantitative explosion of communication networks and the great evolution of technologies are at the origin of IT (Information Technology) infrastructure management difficulties and problems due to an increasing complexity. Therefore, their Total Cost of Ownership is becoming more and more important [I]. Traditional management techniques based on human interventions are no longer efficient. Indeed, it is difficult for a human operator to anticipate systems components interactions and cope with heterogeneous technologies [2]. Thus, one of the stakes of the coming years is the deployment of a new paradigm, which will make it possible to bring autonomy in the IT infrastructures thanks to a new management concept called SelfManagement. Contrary to traditional management where human interventions are necessary, autonomous systems realize the self-management of their resources and adapt their behavior to internal and external changes according to global goals specified by highlevel policies and directives. In this setting, we propose a framework describing service level negotiation protocol for autonomous systems interactions. This paper is organized in four sections. The first describes briefly the self-management concepts. In the second section, we discuss the importance of

negotiation and Web services technologies usage for autonomous systems interactions. The next section describes a framework for service level negotiation in autonomous systems management and the last section presents a test bed for our service level negotiation proposition.

2. Self-Management The vision for bringing autonomy in IT infrastructures is the creation of self-management systems (without human intervention) to cope with increasing complexity and excessive maintenance costs. Such autonomous systems are able to be self-organized. Networks become a collection of interconnected selfgoverned entities where human intervention is limited to high-level directives and system management details are transparent for the administrators. The starting point of this new paradigm is biological systems and in particular, the autonomic nervous system to which we partly owe the term Autonomic Computing [3]. Like humans with their autonomic nervous system, networks with their autonomous systems must be reliable and offer guaranties of availability, security, safety, maintainability: that is to say achieve dependability [4], This new management concept makes it possible thanks to a holistic approach where all research fields are implicated to contribute in the evolution towards a global autonomy in networks. It seems that evolution towards fully autonomous systems could not be reached before 2020 [ 5 ] . Although the objectives list of the self-management concept was extended since 2001 (year of this new paradigm birth), the main objectives for autonomous systems are Self-configuring, Self-optimizing, Selfhealing and Self-protecting [ 6 ] . To achieve those objectives, autonomous systems have a detailed knowledge of their internal state as well as their environment thanks to a continuous monitoring. A change detection induce the autonomous system to adjust its resources and the monitoring continues to determine if the new measures satisfy the desired

0-769S-26S3-S/06/$20.00 (c) 2006 IEEE

performance. That is the closed control loop of selfmanagement systems. It conforms to global objectives without human interventions. It is implemented by autonomic managers which control managed resources thanks to sensors and effectors manageability interfaces [7].

3. Autonomous systems interactions Self-management systems have a distributed infrastructure where autonomous entities collaborate when delivering or consuming services. In that way, it is based on a Service-Oriented Architecture (SOA) where different interactions could take place [8].

3.1 Negotiation usage Autonomous systems interactions are dynamic and a negotiation could take place to achieve an agreement on a service level. This negotiation is a challenging area within this new paradigm. Indeed, unlike service level standardization efforts with SLA, SLS and WSLA related research, there is a lack in negotiation protocol and strategies specification. For a negotiation interaction, autonomous systems must provide their location in a registry so that a negotiation process could take place thanks to negotiation protocol or other negotiation techniques. This negotiation could be multilateral and use several parameters. After a negotiation success, an autonomous system must guarantee the agreed on parameters values.

resulted in a standard definition called WSDM (Web Services Distributed Management). The latter is made of two specifications called MUWS (Management Using Web Services) [ 9 ] and MOWS (Management Of Web Services) [lo]. The first specification (MUWS) could be a standard way to implement manageability interfaces so that autonomic managers use WS technologies to control managed resources. The adoption of this specification improves interoperability between distributed heterogeneous managed resources and autonomic managers thanks to standardized WS technologies usage. MUWS provides a standard and flexible way to specify manageability capabilities exposed by managed resources manageability interfaces. The manageability capabilities are extensible to enable a full coverage of selfmanagement objectives. WSDM standard uses many WS related specifications such as Web Services Architecture, XML, XML Schema, WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol), WS-Addressing, WS Base Notification and WS Resource Properties. WSDM enables manageability capabilities access using WS technologies for messages sending and resources properties description, notifications and discovery. This specification is very interesting for selfmanagement systems. Indeed, its usage enables a standardization of interactions between managed resources and autonomic managers thanks to interoperable Web services technologies.

4. Proposed framework

3.2. Web services usage Open standards adoption for internal and external autonomous systems interactions is vital to succeed in the evolution towards complete autonomy in IT infrastructure. Indeed different technologies and products with a lack of interoperability make it difficult to achieve self-management objectives in such heterogeneous environment and distributed infrastructure without standards usage. One possible solution is the adoption of Web services to cope with those difficulties. Self-management systems could be implemented using improved Web services standard technologies to control different managed resources. In that way, standardization efforts are made in the OASIS (Organization for the Advancement of Structured Information Standards) organization in collaboration with other standardization groups such as the DMTF (Distributed Management Task Force), the GGF (Global Grid Forum) and especially W3C (World Wide Web Consortium) because many of the WS (Web services) technologies used for self-management were standardized in this consortium. Those efforts

In this section, we expose a framework for autonomous systems interactions including a negotiation protocol and Web services technologies usage for horizontal and vertical interactions. Fig 1 represents our proposed framework. The definition of the different entities implicated in the interaction processes are given in the next section.

4.1. Framework components definitions The framework contains the following entities: - HAM High-level Autonomic Manager; it uses a negotiation protocol to communicate with other HAMS to achieve an agreement on a service level. Besides, it controls one or more LAMS thanks to a standardized manageability interface. - LAM Low-level Autonomic Manager; it controls one or more managed resources thanks to the same kind of interface that a HAM uses for managing it. - MR: Managed Resource(s); it could be a hardware or a software entity (server, router, database.. .). One or

0-7695-2653-5/06/$20.00 (c) 2006 IEEE

$" & ?==

$!

!

$!

B !! !

/

! ! ! " /&"

4

/

! ! ! " /&"

Figure 1. Autonomous more managed resources expose their manageability capabilities thanks to one manageability interface made of Sensor and Effector interfaces. - S: Sensor; it enables the HAM and the LAM to request or receive a monitoring information notification from, respectively, the LAMS and the MRs which are under their control. - E: Effector; it gives the HAM and the LAM the means to perform actions for modifying the behavior of the entities under their control. - Registry: it is an UDDI registry. The HAM entities use this registry to publish their Web services to facilitate their discovery. - AS: Autonomous System; it is a collection of autonomic managers and managed resources with manageability interfaces. The nature of an autonomous system depends on the nature of the managed resources it contains. An autonomous system is a selfmanagement system.

4

4

/

/

/

/

/

/

4

4

4

B !! !

/

/

!

/

/

! ! ! " /&"

systems interactions previously publish their Web services in the UDDI registry to make the negotiation process possible. Once the negotiation procedure finished successfully, every AS and precisely every HAM is responsible of the service level guarantee within the corresponding AS. This guarantee will be possible thanks to the second kind of interaction. It is an intra AS vertical interaction where High-level Autonomic Manager provides the Low-level Autonomic Managers with the negotiated service level so that they modify the configuration of their managed resources according to the service level parameters values. The manageability interface that enables this vertical interaction between a HAM and a LAM but also a LAM and the corresponding managed resources is based on the WSDM standard. The MUWS specification of WSDM enables a standard implementation of the sensors and effectors interfaces and enhances interoperability between heterogonous technologies.

4.2. Model of operation

4.3. Negotiation protocol specification

The purpose of the proposed framework is the specification of autonomous systems interactions concepts to guarantee a service level for traffic flows generated from an ingress AS to an egress AS. To achieve this purpose, two kinds of interactions are represented by this framework as shown in fig. 1. The first one is an inter AS horizontal interaction where an ingress Autonomous System thanks to its High-level Autonomic Manager (HAM), initiates a peer to peer negotiation process with the following HAMS until arriving to the High-level Autonomic Manager of the egress Autonomous System. The communication between HAMs is based on a negotiation protocol that uses Web services technologies. All these HAMs must

Self-management autonomous systems cooperate with their peers to offer and use services. One way to achieve an agreement on the service level is the use of a negotiation protocol. It is a challenging area of research [ 5 ] [ 8 ] for the new paradigm of autonomic and autonomous systems. We propose a negotiation protocol called SLNP (Service Level Negotiation Protocol) adapted to a self-aware management environment. The SLNP protocol will use Web services technologies for a multilateral negotiation between High-level Autonomic Managers of several Autonomous systems. The requirements of our protocol ensue of the negotiation process specificities. Therefore, it is

0-7695-2653-5/06/$20.00 (c) 2006 IEEE

important to allow negotiation entities, i.e HAMS, to initiate, modify or release a service level already established following a previous negotiation. Furthermore, our protocol should be independent of the service level parameters in order to facilitate its extension in the future by the definition of new parameters of QoS, mobility or security [l 11. The terminology adopted for our protocol SLNP for the proposed framework is the following: - SHE (SLNP HAM Entity): a HAM entity that supports SLNP - SHI (SLNP HAM Initiator): an SHE that initiates the negotiation process. - SHR (SLNP HAM Responder): the last SHE on the negotiation path. - SHF (SLNP HAM Forwarder): any SHE between an SHI and an SHR and participating to the negotiation process. One or several SHF could be present on the negotiation path. We notice that an SHE is considered as an SHI, SHF or SHR according to the role it plays in the procedure of negotiation. SLNP messages are sent peer-to-peer through the different SHEs present on the negotiation path thanks to Web services technologies. This means that in an SHE, when an SLNP message is received by its Web service interface, a new one (different or not) is generated and sent to the adjacent SHE Web service interface. When an SHE receives a negotiation request, an interaction takes place with the corresponding Low-level Autonomic Managers to see if there are enough available resources for the requested service level. The decision that is going to be taken by an SHE to answer to an SLNP message (acceptance, dismissal, alternative values...), or the modification or not of the message to forward, is influenced by the interaction with the LAMs as well as high-level policies, directives and other kinds of information contained in the corresponding HAM knowledge plane. Once the negotiation finished successfully, a vertical interaction will take place between the different SHEs and their LAMs to provide them with the service level parameters values agreed on and this service level will be identified in their knowledge plane. A self-configuring function will occur thanks to another vertical interaction between the corresponding LAMs and their managed resources using manageability interfaces. Every LAM will try to guarantee a local part of the end-to-end service level. Managed resources sensors provide LAMs with measures corresponding to the negotiated service level. A self-optimizing function could occur to improve the corresponding resources usage. When a service level violation is detected, a self-healing function will occur and corrective actions are taken to solve this problem. If the problem is not solved the LAM sensor interface

will notify the HAM. The latter will take other corrective actions using the effectors interfaces of the LAMs under its control trying to cope with this problem. If the problem is persistent, the HAM will notify the other SHES of the service level degradation and a new negotiation process could take place to modify or release the negotiated service level. We define for SLNP six types of messages that permit us to satisfy the requirements presented in the beginning: - Negotiate: it is a message sent by the SHI toward the SHR. It permits to specify the service level parameters we will negotiate as well as their values. This message is interpreted by the adjacent SHF on the negotiation path and another Negotiate message (modified or not) is sent toward the following SHF Web service interface until the SHR. - Revision: it is sent by the SHR toward the SHI to propose an alternative to parameters andor values received in the Negotiate message. - Response: it is sent by the SHR or the SHI following a message containing a Response Request object in order to accept or reject a demand or a revision so that we finish the negotiation process with reasonable delays. A Response message that accepts the negotiation must contain an ID (Identifier) for the agreed on service level. - Modify: It is sent by the SHI toward the SHR with the service level ID recorded after a successful negotiation. This modification can either be negotiated or an immediate answer can be requested by the SHI via a Response Request object and the procedure is finished by a Response from the SHR. - Notify: This message is sent by an SHE to ask the SHI to degrade the service level that has already been negotiated. This message contains obligatory a Response Request object. This degradation could be accompanied by penalties. - Release: It is sent by the SHI to the SHR to release a negotiated service level. It contains the service level ID. The corresponding information in the knowledge plane will be deleted in every SHE when it receives a positive Response. The Finite State Machine (FSM) that we define for an SHE includes three states: EO is the free state in which the High-level Autonomic Manager has not started the negotiation procedure yet; E l is the state during which an SHE is waiting for a message from another SHE and finally the state E2 represents the end of the negotiation. The transition between the states is a result of a reception and/or the sending of an SLNP message. It is out of the scope of the FSM that we define to consider the external interactions with Lowlevel Autonomic Managers, nor the internal interactions like timers.

0-7695-2653-5/06/$20.00 (c) 2006 IEEE

AApppp. .SSLLSS aa

AApppp. .SSLLSS bb

SLNP E n d -U s e r M a n a ge r

S e rv ic e P ro v id e r SSeervrvicicee SSPP MMOONN MMaannaaggeer raa

S e rv ic e P ro v id e r SSeervrvicicee SSPP MMOONN MMaannaaggeer rbb

DDoommaainin MMaannaaggeer raa

DDoommaainin MMaannaaggeer rbb

DDMM MMOONN

NM L

NM L !

)* +

DDMMMMOONN

E n d -U s e r M a n a ge r

&' ( )* +

&' ( )* +

, -

Figure 2. Swan architecture Fig 3 represents the FSM of the SHI. Three Self-aware mAnageNt (Swan) [12] is an exploratory French research project that aims to define messages, Negotiate, Modify and Release make the SHI change from state EO to state E l waiting for an new methods for self-management. To achieve this SHR message. The reception of a Revision message purpose, an architecture (Fig 2) was elaborated for a multi-domain QoS-enabled service provisioning and does not change the E l state of the SHI and the negotiation is prolonged whereas the sending or the monitoring where a service level will be negotiated for reception of a Response message results in a transition an end-user Visio conference traffic flows among three of the SHI state to E2 and the negotiation is finished. heterogeneous autonomous domains. Finally, the reception of the Notify message, which is We describe next the components of this architecture that implement the vision of the proposed obligatory accompanied by the sending of a Response message, results in a transition to E2. framework with the negotiation protocol. In the Swan architecture, the AS is an autonomous domain with its Revisiod -/Negotiate Negotiate Responselspecific set of network resources and managers. We distinguish two types of managers. First, the Domain Manager (DM) assures the LAM function described in the framework. Second, the Service Manager (SM) and I Revisiod \ I Service Provider (SP) are the same entity, it is called Response SM or SP when it performs respectively the HAM vertical interaction function (i.e DM control) or the I HAM horizontal interaction function (i.e service level negotiation). The monitoring entity (DM-Mon) is the implementation of the sensor interface that a DM uses to retrieve measures concerning the network resources under its control. We use Web services for all the interactions between those different entities. The Web Figure 3. The SHI FSM services used for the manageability interfaces implementations are not yet WSDM compliant. 5. Test bed: Swan architecture

We are working on a concrete demonstration of the proposed framework for service level negotiation in autonomous systems thanks to our participation in the elaboration of the Swan architecture.

5.1. Swan architecture

5.2. SLNP usage in Swan architecture The SLNP protocol is used for service level negotiation among the three SPs present in the architecture. The service level that we want to guarantee for the Visio conference application is

0-7695-2653-5/06/$20.00 (c) 2006 IEEE

represented by an SLS (Service Level Specification) that contains a set of parameters that SPs negotiate using SLNP. Some of those parameters were specified in an SLS template [13] elaborated by the Tequila project. Other parameters are used by negotiation protocols such as COPS SLS [ 141 and DSNP [ 151. The SLS parameters are transported by the messages of OUT protocol and conform to an XML schema that we are specifying. The most important parameters are Service Schedule, Traffic Identification, Scope, Performance Guarantee (Bandwidth, Jitter, Delay, Loss Rate), Description and Traffic Conformance (Token Bucket), Excess Treatment, Negotiation Mode (predefined SLS or not), Renegotiation Interval.

management systems to collaborate for services offering and consuming. Future works concerns the integration of the specified SLNP protocol in the Swan architecture. We will focus OUT interest on the time spent in the negotiation process and evaluate the impact of WS usage.

7. References

[l] Yankee Group, “How Much Is an Hour of Downtime Worth to You?’, Must-Know Business Continuity Strategies, July 2002, p. 178-187. [2] A. Brown, and D. Patterson, “TO Err Is Human”, EASY’OI, Sweden, July 2001. [3] P. Horn, “Autonomic computing: IBM perspective on the state of information technology”, IBM T.J.Watson Labs, NY, Presented at AGENDA ’01, Scottsdale, October 2001, L I L [4] R. Sterritt, and D. Bustard, “Autonomic computing : a Negotiate {(Al,M,A3) means of achieving dependability?’, IEEE ECBS’03, Negotiate { (A1,M)+ Huntsville, p. 247-251, April 2003, p. 247-251. + (vl,v2,v3)} b [5] FET, “New communication paradigms for 2020”, Brain storming meeting report, Brussels, March 2004. [6] A.G. Ganek, and T.A Corbi, “The dawning of the autonomic computing era”, IBMSystems Journal, vol. 42, No I 1, 2003, p. 5-18. (v’ 1,v’2)} [7] IBM Group, “An architectural blueprint for autonomic Revision { (A1,M)+ I computing”, White paper, IBM Corporation, June 2005. (v’ 1,v’2)} [8] J.O. Kephart, and D.M. Chess, “The vision of autonomic computing”, IEEE Computer Society, vol. 36, No 1, January Negotiate {(Al,M) + 2003, p. 41-50. [9] W. Vambenepe, “Web Services Distributed Management: Negotiate {(Al,M) + (v”1,v”2) + RR} Management using Web Services (MUWS 1.0) Part l”, OASIS Standard, March 2005. (v”1,v”2) + RR} [ 101 I. Sedukhin, “Web Services Distributed Management: Response {Ack+ Management of Web Services (MOWS) 1.0”, OASIS 7 Standard, mars 2005. SLS ID} [ l l ] B. Benmammar, N. Thi Mai Trang, G. Pujolle, V. Response {Ack + Yilmaz “DBfinition d’un SLA / SLS”, IP-SIG Document, December 2003. SLS ID} [ 121 Self-aware mAnageNt (Swan) RNRT project accessible Figure 4. Example of SLNP MSC at: ht~://swan.elibel.tm,~/ Fig 4 represents a Message Sequence Chart (MSC) [13] D. Goderis, D. Griffin, C. Jacquenet, and G. Pavlou of a simple negotiation example. The SHI initiates the “Attributes of a service level specification template”, IETF, draft-tequila-sls-03, October 2003. negotiation with an SLS containing the attributes (Al, [14] N. Thi Mai Trang, N. Boukhatem,Y. Ghamri, G. Pujolle, A2,A3) with the values (Vl, V2, V3) and finally the “Service Level Negotiation and COPS-SLS Protocol”, IEEE negotiation finished with a RR (Response Request) that Communication Magazine, May 2002, pp. 158-165. results in the sending of a Response message with an [15] J. Chen, A. McAuley, V. Sarangan, “Dynamic Service SLS ID corresponding to (Al, A2)with the alternative Negotiation Protocol”, IETF, draft-dsnp-01, December 2002.

-

r

values (V”1, V”2).

6. Conclusion In this paper, we presented a framework that shows the importance of autonomous systems interactions thanks to the SLNP protocol specification and WS standard technologies usage. Service level negotiation in a standard manner makes it easier for self-

0-7695-2653-5/06/$20.00 (c) 2006 IEEE