Proceedings of Asia Pacific Conference ObComAPC-2004: Parallel and Distributed Computing Technologies, December 13-15, 2004: Vellore Institute of Technology, Vellore, TN, INDIA:

SLA FRAMEWORK FOR ENRICHED EXPERIENCE NETWORKS USING POLICY BASED DEA

S. Rajeev Assistant Professor Department of Electronics & Communication Engineering PSG College of Technology Coimbatore, Tamil Nadu [email protected]

S. N. Sivanandam Professor & Head Department of Computer Science & Engineering PSG College of Technology, Coimbatore, Tamil Nadu [email protected]

ABSTRACT A Service Level Agreement (SLA) [3] is a service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another domain [16]. Enriched Experience Networks (EEN) TM is a new form of broadband network, which requires an adaptable approach to service management that allows for personalized and ubiquitous services, which are available, on-demand. EEN is the application of Quality of Experience (QoE) concepts to Service-Enabled networks [1]. Quality of Experience (QoE) of a customer is defined as the level of satisfaction with a service from the perspective of that customer, based on their needs, wants and expectations [2]. Thus in EEN, customer needs and expectations are more focused and service provided in accordance to that. EENs require regular and fairly instantaneous interactions between the customer and the network. SLAs between the customer and the Infrastructure provider therefore needs to be more dynamic to be more customers focused. But SLA is a very static procedure, which is rather performed manually [3]. Thus in this paper we propose a Policy Based SLA Framework and a mathematical model which uses Data Envelopment Analysis (DEA) to provide more customer focused services in EEN. INTRODUCTION An EEN is a multi-service, technology-agnostic network that focuses on customer needs and expectations to maximize the perceived value of the services to the customers. It is a new form of broadband network which requires an adaptable approach to service management that allows for personalized and ubiquitous services. Quality of Experience (QoE) of a customer is defined as the level of satisfaction with a service from the perspective of that customer, based on their needs, wants and expectations. It is so important that perception of quality is matched with the value of the service to the customer. Next Generation Networks (NGN) implies convergence of the services to be offered, because a diverse collection of individual needs can be met by the use of one set of communications infrastructure. By focusing more on bit-pipe

K.V. Sreenaath Research Student Department of Information Technology PSG College of Technology, Coimbatore, Tamil Nadu [email protected]

services and multiple service convergence and by not addressing QoE, NGNs have suffered. Thus Enriched Experience Network (EEN) has evolved which is the application of Quality of Experience (QoE) concepts to serviceenabled networks. In EEN Service Level Agreement play a crucial as effective agreement must be made with focus on the customer needs. Service Level Agreement (SLA) is a static procedure, usually performed manually. But EEN expects that the service offered to the customer be more dynamic to satisfy their demands. Hence there is a compelling need to automate the Service Level Agreement between the customer and the infrastructure provider. In this paper we propose mathematical model Policy Based architecture for Service Level Trading between the customer and the infrastructure provider. The rest of the paper is organized as follows: A Mathematical Model for Service Level Agreement is given in Section 1. Policy Based architecture for SLA trading is given in section 2. Policy Specification for the SLA trading and Test Results are given in section 3 and 4. Conclusions are drawn in section 5. 1. MATHEMATICAL MODEL A mathematical model is considered in our framework which uses Linear Programming (LP) and uses Simplex Method [4] to solve it. The following performance metrics that ensure efficient customer service in EEN are considered in the model. (a) Bandwidth (b) Delay (c) Demand for Service (d) Packet Loss Factor (e) Congestion Factor (f) Queuing Delay (g) Throughput (h) Buffer Capacity (i) Jitter Let, Tb -Total (maximum) Bandwidth available for the Infrastructure Provider ‘ IPx ’ at instant ‘ t ’.

U b -Bandwidth being used by the Infrastructure Provider ‘ IPx ’ at instant ‘ t ’ RSb -Reserved bandwidth.

1

Copyright © ObComAPC-2004

Hence the bandwidth that can be used to offer service for customers, R Eb is given by REb  Tb  U b  RSb Let the demand in bandwidth for service from the customer be represented by DEb . And, D -Delay for the service from the Infrastructure Provider ‘ IPx ’ to the customer ‘ y ’.

C y - Cost of providing the service to the customer ‘ y ’.

Ob - Bandwidth offered by other Infrastructure Providers to the Infrastructure Provider ‘ IPx ’ for providing service to ‘ IPx ’s customers in case ‘ IPx ’ runs out of bandwidth. COIP - Cost for the bandwidth provided by other Infrastructure Providers to ‘ IPx ’. Hence the maximum bandwidth that the Infrastructure Provider ‘ IPx ’ can offer to its customers is given by

M b  REb  Ob The objective here is to provide the best possible service to the customer at a minimum cost in order to be more customers centric. Minimize (C y  DEb ) As stated earlier,

C y in the above equation represents the

cost Infrastructure Provider ‘ IPx ’ charges for the service to the customer ‘ y ’. 1.1 CONSTRAINTS There are certain set of constraints that define the model. The first constraint is that the demand for service from the customer, DEb should be less than or equal to the maximum bandwidth, M b ‘ IPx ’ can offer. DEb  M b The following constraints check if the performance metrics in the service offered by ‘ IPx ’ to the customer ‘ y ’ fall within the boundaries as expected by the customer ‘ y ’. These boundary constants for the performance metrics are set by the customers in their SLA negotiation with their Infrastructure Providers. The Service Delay, D should be set to a tolerable limit expressed by a constant ‘ p1 ’ as expected by the customer.

D  p1 The Packet Loss Factor P for the service provided should not exceed a maximum limit set as constant ‘ p2 ’, P  p2 The Congestion in the channel offered for service Co should be within the acceptable limits represented by the constant ‘ p3 ’, Co  p3

Q should not exceed an allowable limit expressed as the constant ‘ p4 ’, Q  p4 Queuing Delay

Throughput TH should be greater than or equal to a particular constant ‘ p5 ’, TH  p5 Buffer capacity BC should not be less than, as given by the constant ‘

p6 ’, BC  p6

1.2 NON-NEGATIVITY CONSTRAINTS The following are the non-negativity constraints assumed in the model: Cost C y should always be positive, C y  0 , The bandwidth that can be offered for service to the customer should be positive, REb  0 or M b  0 as the case may be. 2. FRAMEWORK OF THE POLICY BASED SLA FOR ENRICHED EXPERIENCED NETWORKS The growing interest in the field of Policy-Based Networking [5] to monitor and control the access rights of resources in large distributed systems, and in areas like Quality of Service (QoS), Wireless Networks [6, 7], Network Security, SLA and IP address allocation etc., have identified us to use policy based approaches to SLAs, as SLAs are normally setup manually[8]. As in EEN customer needs and expectations are more focused SLAs can’t be set up manually. Thus the Service Level Agreement between the customer and the Infrastructure Provider should be automated using the mathematical model proposed in Section 1 along with the Policy Based approach which is explained in the next section. 2.1 POLICY BASED SLA ARCHITECTURE The policy based SLA architecture for EEN is shown in Fig.1. The architecture depicts the Service Trading between a customer and an Infrastructure Provider. Both the Customer and the Infrastructure Provider has an SLA trader (SLAT) which trades the Service Level Agreement. The Infrastructure Provider has a Policy Server which is used as a decision point and a Policy Management Console (PMC). PMC is the entity responsible for creating, modifying or deleting policy rules or entries in Lightweight Directory Access Protocol (LDAP)[9] server. Policies are rules that govern the choices in behavior of a system. They define what actions shall be taken and for what or for whom, and under what conditions. The dynamic nature of the Service Level Agreement is achieved by storing higher level policies in the Directory Server. When the customer needs some service initially from the infrastructure provider the customer SLAT trades with the Infrastructure Provider SLAT. Protocols such as new Border Gateway Protocol (BGP) [10] attributes, the Internet Open Trading Protocol (IOTP), Resource Reservation Protocol (RSVP) extensions, SLAT, etc can be used for the communication between the SLATs. When the Infrastructure Provider SLAT receives the Service trading from the customer it queries the policy server. The Policy Server takes appropriate policies from the Directory server through LDAP and implements the Mathematical Model proposed in section 1 using Data Envelopment Analysis [11]. In addition to this, the Policy Server queries the Authentication, Authorization and Accounting server to check if the customer is an authenticated one and if he is authorized for the service he is demanding. The

2

Copyright © ObComAPC-2004

policy server also queries other policy relevant servers such as Certificate servers and time servers. The policy server then comes up with an agreement that satisfies the customer constraints. The Infrastructure Provider SLAT then trades of the agreement with the Customer SLAT and finally comes with an agreement. 3. POLICY SPECIFICATIONS FOR THE SLA TRADING The existing policy specification languages such as Ponder [12], Policymaker [13], etc. are not extensible. Hence Policy Specification Language extension for EEN is developed and used for specifying policies for the Service Level Agreement based on the Framework proposed. The policy Specification for the SLA trading is given below. Provisioning algorithm and Profitability Analysis algorithm given in [14], does not suit the framework as it takes in to consideration very few performance metrics for trading. So provisioning algorithm and Profitability Analysis algorithm with appropriate enhancements is used.

Fig.1 Architecture of the Policy Based SLA for EEN using DEA // On a trading event the action trade sends a pop-up displaying that the trading is being analyzed to check if all the constraints are satisfied with minimal cost based on the mathematical model proposed in section 1. Table 1: Policy Specification for SLA Trading inst oblig/Policies/TradingPolicy { on trading(customer_name,bw,delay, demand,packet_loss,congestion,queuing_delay, buffer_capacity,throughput);

subject /PMAs/TradePMA; do trade(customer_name,bw,delay, demand,packet_loss,congestion,queuing_delay, buffer_capacity,throughput); } The rule /Policies/TradingPolicy will invoke the action trade within the /PMAs/TradePMA’s engine, when the event trading is dispatched to the PMA from the trading event service.The corresponding java code which enforces this policy is given. Table 2: Java code for the Policy Specification for SLA Trading public void execute(LinkedList params) throws Exception { // parameter0: The string representing the trade that will be considered // For debugging: if (DEBUG) { System.out.println("*******"); System.out.println("Trading the offer of : "+ (String) params.get(0)); } // Pop up the action window JFrame window = new JFrame(); window.setTitle("Trading Console"); JLabel traders = new JLabel("Trader: "+ (String) params.get(0)); JPanel mainPanel = new JPanel(); mainPanel.add("Center",Trader); window.setContentPane(mainPanel); window.pack(); window.setSize(200,100); window.setLocation(100,50); window.setVisible(true); //The code for the simplex method to solve the Linear Programming model as given in section 1 should be included. } 4. TEST RESULTS USING DEA A simulation is performed using the QualNet Network Simulator [15]. The simplex method to solve the LP model given in the section 1 and the policy specification given in section 3 are used in the simulation environment. Data Envelopment Analysis is done using the simulator. The test environment has a Customer and an Infrastructure Provider as shown in Fig.1. The total bandwidth, used bandwidth, reserve bandwidth, and other performance metrics are shown as tables and graphs. In the simulation test environment the customer needs a service from the Infrastructure Provider with constraints on performance metrics. The Infrastructure Provider queries the Policy Server which uses the mathematical model proposed in section 1 and analyses the data using DEA and trades upon the agreement. The process of solving the mathematical model proposed above by simplex method including the values of the slack variable is shown in Tables 3 to 5. In the Simulation test since the bandwidth for the service requested by the customer is less than the remaining bandwidth

3

Copyright © ObComAPC-2004

,bandwidth offered by other Infrastructure Providers are not used. The performance metrics of the infrastructure provider are shown in Fig.2 to Fig. 5. It can be seen as per the constraints given on performance metrics by the customer who demands the service (see Fig.6 to Fig.8), the objective of minimizing the cost is arrived as shown in Fig. 13. Thus an effective SLA is traded between the Infrastructure Provider and the Customer demanding the service, satisfying the constraints on the performance metrics which affects the service. The values of the slack variables which are added in the process of solving the LP using simplex method are shown in Fig. 9, Fig. 10 and Fig. 11. The final objective of minimizing the cost based on constraints on metrics is achieved henceforth and hence QoE achieved. Table 3: Performance Metrics of Infrastructure Provider Values Performance Metrics of Infrastructure Provider Total Bandwidth (MBps) 7 Used Bandwidth (MBps) 2 Reserve Bandwidth (MBps) 0 Remaining Bandwidth (MBps) 5 Delay (x10-3sec) 2.9 Packet Loss Factor 0.2 Congestion Factor 0.3 Queuing Delay (x10-4sec) 0.2 Buffer Capacity-Number of Packets 100 Throughput (x103Bits/ec) 4.2 Offered Cost ($) 100 2 Bandwidth offered by other Infrastructure Providers (MBps) 40 Cost for the Bandwidth given by other Infrastructure Providers ($) 4 Bandwidth for the service Demanded by customer (Demanded Bandwidth) (MBps) Table 4: Adjustable Performance Metrics Original Value Final Value Performance Metric of Infrastructure Provider Offered Bandwidth-MBps 3 4 Offered Cost-$ 100 60

enhancements. A real-time implementation for the same using Intel IXP Network Processors could be a future work. REFERENCES

[1] [2]

[3]

[4] [5] [6]

[7]

[8]

[9] [10] [11] [12]

Table 5: Objective of Infrastructure Provider Objective Original Value Final Value Infrastructure Provider’s 900 720 (C  DE )

[13]

5. CONCLUSIONS A Policy based DEA framework is modeled for Enriched Experienced Networks using Linear Programming. Performance Metrics like Bandwidth, Delay, Demand for Service, Packet Loss, Congestion, Queuing Delay, Throughput, Buffer Capacity., that are crucial for the performance of EEN Networks are considered in this framework. The LP model constructed and solved show considerable performance

[15]

y

[14]

b

[16]

4

Nigel Sheridan-Smith, “A Distributed Policy-based Network Management (PBNM) system for Enriched experience Networks (EENs)”, Ph.D, University of Technology, Sydney. N. Sheridan-Smith, D. Colquitt, and J. Wootton, "Moving from Next-Generation Networks to Enriched-Experience Networks," University of Technology, Sydney, Australia, Confidential deliverable 1A, 30 September 2003. Fankhauser .G, Schweikert .D, Plattner .B, “Service Level Agreement Trading for the Differentiated Services Architecture”. Swiss Federal Institute of Technology, Computer Engineering and Networks Lab, Technical Report No. 59. Nov. 1999. Eric W. Weisstein. “Simplex Method” from MathWorld--A Wolfram Web Resource. http://mathworld.wolfram.com/SimplexMethod.htm L. Lewis, “Implementing Policy in Enterprise Networks,” IEEE Communications Magazine, vol. 34, no. 1, pp. 50-55, January 1996. S. Rajeev, S.N. Sivanandam, K. Duraivel, Santosh G. Rao, P. Pradeep “Policy Based Provisioning For Wireless Differentiated Services”, Proc. IEEE 12th Annual Symposium on Mobile Computing and Applications, Bangalore,Nov. 2003 S. Rajeev , S. N. Sivanandam , Mothi V. Sabaresan, B. Anand, “Frequency Allocation and Priority Handling in Multi-Service Wireless Differentiated Networks”, International Journal of System Modeling and Simulation, Vol. 2, pp.26-29, Jan.2004. Appan Ponnappan, Lingjia Yang, Radhakrishna Pillai.R Peter Braun, “A Policy Based QoS Management System for the IntServ/DiffServ Based Internet”, Proc. Third International Workshop on Policies for Distributed Systems and Networks, 2002 Wahl, M., Howes, T., and S. Kille, “Lightweight Directory Access Protocol (v3)”, RFC 2251, Dec. 1997. Y. Rekhter, T. Li, “A Border Gateway Protocol 4”, RFC1771, Mar. 1995 W.W. Cooper, L.M. Seiford and J. Zhu, eds, “Handbook on Data Envelopment Analysis”, Kluwer Academic Publisher, Boston, 2004. Nicodemos Damianou, Naranker Dulay, Emil Lupu, Morris Sloman, “The Ponder Policy Specification Language”, Proc. Policy 2001: Workshop on Policies for Distributed Systems and Networks, Bristol, UK,pp. 29-31 Jan. 2001. Mushroom, A., "Policy Maker, A Toolkit for Policy Based Security management", accepts and management NOMS with IEEE/IFIP network operation 2004, Seoul, Korea, 2004 Stefan Savage, Tom Anderson, Amit Aggarwal, David Becker, Neal Cardwell, Andy Collins, Eric Hoffman, John Snell, Amin Vahdat, Geoff Voelker, John Zahorjan, “Detour: A Case for Informed Internet Routing and Transport”, IEEE Micro, Vol.19, No 1 Jan. 1999. QualNet network simulator. Available at http://www.scalablenetworks.com S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss (1998). “An Architecture for Differentiated Services”, RFC 2475.

Copyright © ObComAPC-2004

APPENDIX – I

Fig. 2 Bandwidth Metrics of Infrastructure Provider

Fig. 3 Performance Metrics-I

Fig. 4 Performance Metrics-II

Fig. 5 Performance Metrics-III

Fig. 6 Maximum Value Constraints

Fig. 7 Minimum Value Constraints

5

Copyright © ObComAPC-2004

Fig. 8 Cost Constraints

Fig. 9 Slack Variable’s Values

Fig.10 Slack variable’s Value-II

Fig.11 Slack variable’s Value-III

Fig.12 Original and Final Value

Fig. 13 Objective

6

Copyright © ObComAPC-2004