A Policy Based QoS Management System for DiffServ Based Wireless Networks S. Rajeev1, Dr. S. N. Sivanandam2, K.V. Sreenaath3 1

Department of Electronics & Communication Engineering 2 Department of Computer Science & Engineering 3 Department of Information Technology PSG College of Technology, Coimbatore, India

Abstract- Policy based management is being adopted widely for different domains like QoS, security and VPNs in order to allow new services and facilitate network management. The interface to the network device and the information models required for specifying policies are either standardized or being standardized in IETF and DMTF. We present an architecture of a policy based QoS management System for Diffserv Based Wireless Networks which are based on COPS for interfacing with the network device and on LDAP for interfacing with a directory server for storing policies. The Diffserv policies are installed based on role combination assigned to the network device interfaces. The directory access could become a bottleneck in scaling the performance of the policy server and it can be improved substantially by employing appropriate policy caching mechanisms. This paper considers various QoS parameters in the wireless network and proposes the policy based architecture for QoS management in wireless networks.

Typical usage of policies includes: • Service Level Agreement (SLA) between two adjacent domains. • Device configuration, queuing mechanisms, drop strategies, access filter lists, etc. • Traffic classification/marking (e.g. DiffServ Marking) Provision of QoS has been studied at various level of protocol hierarchy as given under: • MAC level reservation protocols such as EC-MAC [1]. • Scheduling algorithms for wireless networks state, losses [2]. • Network level signaling protocol such as Resource Reservation Protocol (RSVP) [3].

The Policy based QoS architecture proposed is based on Differentiated Services (DiffServ) model [4] and IETF/DMTF framework. Diffserv uses the Type of Service (TOS) field of the IP Keywords- Policy Based Networks, Wireless Differentiated Service packet header for classification. Each IP packet is then given a Networks, Quality of Service, Directory Enabled Networks, Policy particular treatment at each node resulting in some form of quality Specifications. assurance. Diffserv has better scalability properties when compared to integrated services that use flow-level QoS specifications. The I. INTRODUCTION current design of Diffserv considers only wired networks. We HERE is a growing need to provide QoS in wireless and mobile propose an enhanced architecture which is policy based to suit to applications due to the recent increase in real time applications. wireless networks. Common Open Policy Service (COPS) With increasing complexity, heterogeneity and size of computer protocol [5] is used for interfacing with network devices and networks, their management is also getting more complicated, Lightweight Directory Access Protocol (LDAP) [6] for storing error-prone and costly. Moreover, it is important to achieve policies in a directory. The Diffserv policies are installed based on business objective-controlled usage of network resources. These role combination assigned to the network device interfaces and are the main drivers for an automated and consistent management policy caching is used to improve the performance. The paper is organized as follows: an overview of Wireless QoS of these networks. Policy Based Network Management (PBNM) is an over-arching technology for an automated management of and policy based networking is given in Section II; .Section III networks. Policies encode the high-level goals and requirements of describes the architecture of the policy based management system management. Policy based management is being adopted for the based wireless network and the Policy specification widely for different domains like Quality of Service (QoS), language. Component interaction through routers is described in security and Virtual Private Networks (VPNs). Also, the interface to Section IV. Experimental Setup and Conclusions are drawn in the network device and the information models required for Section V and VI. specifying policies are either standardized or being standardized in IETF and Distributed Management Task Force (DMTF).

T

II. OVERVIEW OF WIRELESS QOS AND POLICY BASED NETWORKING 1) Wireless Network QoS Parameters High Loss Rate: Wireless networks are characterized by more frequent packet losses because of fading effects, etc. The scheduler may think that a certain DSCP is being satisfied with the required number of packets scheduled, but the receiver is not receiving the packets at the required rate. It will be useful to have feedback from the receiver so that some compensation techniques can be employed [7, 8]. The Base Station (BS) can better handle compensation of lost bandwidth using this information. Battery Power Constraints: Current mobile battery technology does not allow more than a few hours of continuous mobile operation. Two of the major consumers of power in a mobile are the network interface (14%) and the CPU/memory (21%). Therefore, network protocols should be designed to be more energy efficient [9]. The mobile can use the signaling mechanism to periodically send messages about its power level to the BS. The BS can then use this information to dynamically decide packet scheduling, packet dropping, etc. Classification of Packets within a Flow: Present Diffserv mechanisms treat all packets within a flow identically. Even though a distinction can be made between packets as in-profile or out-of-profile, all in-profile packets are treated the same way. In many situations (e.g., while using layered video), it may be necessary to distinguish packets within a flow. This is because some packets from a flow level could be more important than the others and a local condition like power level may lead to different treatments of these packets. Thus, the packets within a flow must be made distinguishable, and bits in the TOS field may be used for this purpose [11]. To summarize, the various possible factors needed to make the Diffserv architecture [11] suitable for wireless networks were discussed in this section. Low Bandwidth: Wireless networks available today are mostly low bandwidth systems [26]. Most of the current LANs operate at 2 Mbps with migration upto 11 Mbps available. However, the available wireless LAN bandwidth is still an order of magnitude less than the typical wired LAN bandwidth of 100 Mbps. This leads to two decisions. First, the signaling protocol should be very simple and highly scalable. It is also better to modify an existing protocol for compatibility with other existing network protocols. Second, the mobile should not be swamped with too much data from a wired sender with higher network bandwidth. This can be handled to a large extent by transport protocol control, but the problem can be

alleviated by handling it partially at the Base Station (BS). Therefore, mechanisms may be used at the BS to send data to the mobiles based on current conditions such as channel condition, bandwidth available, etc. 2) Policy Based Networking Over the past few years, the growing interest in the field of policy-based networking is evidenced by several research and development efforts in both academia and industry, working groups leading standardization efforts, new technical conferences, and new commercial products supporting policybased management. However, the idea of using policies in network management is not new; the original idea is known to have evolved in the early 1970s [11], to monitor and control the access rights of resources in large distributed systems. Since then, with the evolution of the Internet, the increasing complexities and heterogeneity of modern networking technology, and the increase in the number of resources to be managed, it is not surprising that the policy-based approach to automating network management has become so popular. The policy-based approach can be used to manage different aspects of a network, commonly known as policy disciplines [12]. Some examples of policy disciplines are Quality of Service (QoS), Wireless Networks [27, 19], network security, and IP address allocation. Policy-based networking configures and controls the various operational characteristics of a network as a whole, providing the network operator with a simplified, logically centralized, and automated control over the entire network. In [13], a policy is defined as “a definite goal, course or method of action to guide and determine present and future decisions.” In general, policies can be seen as plans of an organization to achieve its objectives. This may involve a set of rules to govern the behavior of its network and its components (resources, users, applications, etc.), and the specification of a set of actions to be performed. Policies can be classified [14, 12] into different levels in a hierarchy allowing simplified abstraction of complex lowlevel policies to simple high-level policies that do not use networking jargon. Business-level or high-level policies are those that express the overall goals of an organization. Network level policies are essentially business level policies mapped and expressed into networking terminology. These are defined and entered by a network operator with a high-level perspective of the network topology, objectives and network- idle utilization. Node-level policies are those that correspond to the objectives and requirements at the different network nodes, and device-level policies are device-specific instructions that facilitate implementation of algorithms, for example, for classification, scheduling, buffer management, etc. The node and device level policies typically constitute the low-level policies. In order to successfully deploy policies in a network, the policies need to satisfy certain requirements [12]. They should be precisely defined and specified to be understood and enforced at a network

element. The policies must be compatible with the capabilities of the network element where they may be enforced. Furthermore, policies must be mutually consistent to avoid conflicts and ambiguous decision making. Finally, the policies should be simple, intuitive and easily understood at a higher-level by human operators, and the network operator should be able to specify them with ease. The Internet Engineering Task Force (IETF) and the Distributed Management Task Force (DMTF) have been working together to define a policy framework[16,15]. The IETF Policy Framework working group provides guidelines for defining a policy framework, and an information model and schemata to define, store and retrieve policies [15,13]. The architectural elements typically found in a policy-based system are as shown in Fig. 1.

(MIBs). A typical PIB structure is shown in Fig 2 below. It can be thought of as a tree, with branches representing Policy Rule Classes (PRCs) and the leaves representing Policy Rule Instances (PRIs). The Policy Decision Point (PDP) or the policy server generally retrieves the policies from the policy repository and performs complex policy interpretation and translation into a format that can then be used to configure one or more Policy Enforcement Points (PEPs) or policy clients.

Fig. 2 PIB Structure

Fig. 1 Key Architectural Elements of Policy Based Networking

A Policy Management Tool (PMT) provides the network administrator with an interface to interact with the network. A network administrator uses the policy management tool to define the various policies or policy groups. It is typically the function of the PMT to validate the syntactic and semantic correctness of the administrator input, to ensure consistency among the highlevel policies and to check for compatibility of the various policies. Further, the PMT typically determines the association between the policies and the various network elements where these policies are to be enforced, determines which low-level policies can be used to support the specified high-level policies and ensures that the specified policies are comprehensive enough to cover all the relevant scenarios. The policies specified at the PMT are then stored in a policy repository. A policy repository can be defined as a data store or a model abstraction that holds policy rules, their conditions and actions, and related policy data [13]. A Policy Information Base (PIB) can be considered as a type of policy repository. The concept of PIB is based on the Structure of Management Information (SMI) [31] to leverage the experience with the Simple Network Management Protocol (SNMP) [32] and related Management Information Bases

The PDP also needs to monitor any changes in the policies that might occur at the policy management tool or repository. A policy management tool may not detect policy conflicts at a lower level, and such conflicts may have to be handled by the PDP. The PEP is a network device (e.g., end-host or router) where the policies are actually executed or enforced. The PEP is also responsible for monitoring any relevant information (such as installation/removal of policies, updates about its current status, etc.) and reporting it to the PDP to facilitate automated efficient network management. 3) Policy Based QoS The IETF Resource Allocation Protocol (RAP) [17] working group is active in the field of QoS policy. It has defined, among other standards, the policy-based admission control framework [18], and the Common Open Policy Service (COPS) protocol and its extension – COPS for Provisioning (COPS-PR) [20]. COPS is a simple query protocol that facilitates communication between the policy clients and remote policy server(s). Two policy control models have been defined: outsourcing and provisioning. While COPS supports the outsourcing model, its extension COPS-PR integrates both the outsourcing and provisioning models. The outsourcing model is tailored to signaling protocols such as the resource ReSerVation Protocol (RSVP) [21, 22], which requires traffic management on a per-flow basis. On the other hand, the provisioning or configuration model is used to control aggregate traffic-handling mechanisms such as the Differentiated Services (DiffServ) architecture [23]. In the outsourcing model, when the

PEP receives an event (e.g. RSVP reservation request) that requires a new policy decision it sends a request (REQ) message to the remote Policy Decision Point (PDP). The PDP then makes a decision and sends a decision (DEC) message (e.g. accept or reject) back to the PEP. The outsourcing model is thus PEPdriven and involves a direct 1:1 relation between PEP events and PDP decisions. On the other hand, the provisioning or configurations model [20] makes no assumptions of such direct one to one correlation between PEP events and PDP decisions. The PDP may proactively provision the PEP reacting to external events, PEP events, and any combination thereof (N: M correlation). Provisioning thus tends to be PDP-driven and may be performed in bulk (e.g., entire router QoS configuration) or in portions (e.g., updating a DiffServ marking filter [24]).

policies and translating them into device specific commands for realizing those policies. For allocating resources on interdomain links and for implementing SLAs, the policy server (especially the bandwidth broker component) has to communicate with the policy server in the provider.

Fig. 3 Policy Distribution Model

III. ARCHITECTURE OF THE POLICY BASED MANAGEMENT SYSTEM FOR THE DIFFSERV BASED WIRELESS NETWORK Fig.4 illustrates the architecture of the policy based management system for Diffserv based wireless networks. The policy server is responsible for interpreting higher-level

Fig. 4 Policy based management system for Diffserv based Wireless Network

The policy server is mainly responsible for the following: • Retrieval of relevant policies created by the network administrator through the policy console after resolving any conflicts with existing policies; • translating the policies relevant for each of the PEP into the corresponding Policy Information Base (PIB) commands; • •

arriving at policies decisions from relevant policies for policy decision requests and maintaining those decision states; Taking appropriate actions such as deletion of existing decision states or modification of installed traffic control parameters in the PEP .For any modifications to currently installed policies.

All the policies are stored in the LDAP server. Policy Editor (PE) is the entity responsible for creating, modifying or deleting policy rules or entries in LDAP server. LDAP protocol provides access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). It is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. It does not have the mechanism or notifying policy consumers of changes in the LDAP server. Therefore, it is the responsibility of the policy editor to indicate the changes in the LDAP server as and when required using an internal event messaging service. The policy server in addition to querying the LDAP server queries other policy relevant servers such as Certificate server, Time server, etc. The policy management client, also referred to as the policy editor (PE) provides a high-level user interface for operator input translates this input into the proper schema for storage in the directory server and pushes it out to the directory for storage. The Authentication, Authorization and Accounting server (AAA server) is responsible for authentication, authorization and accounting of the user after the relevant policies have been picked and enforced in the policy enforcers (routers).This AAA server is used by the base station to check if the user is authenticated one, authorized for the resource he requests and to check if he is accounted. The policy enforcer nearer to the base station enforces the policy decisions taken from the Policy Server. The base station then requests the nearest application server (after policies are enforced) and waits for the response from the application server. The base station first sends the request to the leaf access router which then sends it to the ingress router in the region .The ingress router then passes on the requests to the intermediate router. The request passes through the other intermediate routers and reaches the egress router which sends the request to the policy server through COPS.

3.1 Policy Specification Language: Policy Specification Languages help in defining policies using higher level language constructs. Even though available policy Specification Languages like Ponder [28], Policy Maker [29], they do not cater to the requirements for writing QoS for wireless Diff Serv. Networks, hence an extension policy is written and implemented for the architecture proposed. The policy specification language and its constructs are proposed in [30].

IV. COMPONENT INTERACTION THROUGH ROUTERS When the leaf access router receives the request from the base station it forwards the request to the region. The region can be composed of many domains as shown in Fig.5. Then the ingress router in the region gets the request and forwards it to the intermediate routers. The intermediate routers forward the request to the egress router. The egress router forwards the request to the policy server through COPS.

Fig. 5 Diffserv Region

The policy server queries the LDAP server and other policy related server to weigh the policy request (QoS request) against a set of rules. The policy server then sends back the policy decision or the set of policy rules back to the leaf access router. The leaf access router forwards the policy rule to the Policy Enforcer nearer to the base station which enforces the policy rules. After the policy rules are enforced, the base station queries the AAA

server for authentication, authorization and accounting purposes. If found that the user is a legitimate one and is eligible for the service he has requested, the base station requests the service from the nearest application server and gets back the response and sends it back to the mobile client. If the user is not found to be a legitimate user or is not eligible for the service he has requested the base station sends back the reply back to the user denying the request.

V. EXPERIMENTAL SETUP Ingress and Egress Routers were configured using Intel IXP 1200 Network processor systems. The test programs were written in MicroC and Assembly codes.

VI.

CONCLUSION

The Hardware Architecture for QoS in policy based management system for based wireless networks was constructed and Policy Specification Language Extensions written to support this architecture were successfully written, QoS parameters were added and tested in the environment. Details of test results are included in the final version of the paper. VII.

ACKNOWLEDGEMENT

The authors wish to thank the Network System Design Center In-charge in The Department of Electronics and Communication Laboratory, PSG College of Technology and Intel Inc., for providing facilities to implement the Architecture using IXP1200 Network processors. VIII. REFERENCES [1]

[2]

[3]

[4]

[5] [6] [7]

[8]

Jyh-Cheng Chen, K.M.Sivalingam, and R.Acharya “Comparative analysis of wireless ATM channel analysis protocols supporting multimedia traffic”, ACM/Baltzer Mobile Networks and Applications, pp.293-306, 1998. C.Fragouli, V.Sivaraman and M.Srivatsava, “Controlled multimedia wireless link sharing via enhanced channel based queuing with channel state dependent packet scheduling”, in proc IEEE INFOCOM, (San Francisco, CA), pp.572-580, Apr. 1998. I.Mahadevan and K.M.Sivalingam, “Architecture and experimental results for QoS in Mobile Networks using RSVP and CBQ”, ACM/Baltzer Wireless Networks Journal, Vol.6, No.3, pp.221-234, 2000. Y.Bernet, J.Binder, S.Blake, M.Carlson, E.Davies, B.Ohlman, D.Verma, Z.Wang and W.Weiss, “A Framework for Differentiated Services.”, IETF draft, draft-ietf-framework-00.txt, May 1998. D. Durham et. al., “.The COPS (Common Open Policy Service) protocol.” IETF RFC 2748, January 2000. Wahl, M., Howes, T., and S. Kille, “Lightweight Directory Access Protocol (v3)”, RFC 2251, December 1997. Lu, S., Nandagopal, T., and Bhargavan, V. “A Wireless Fair Service Algorithm for Packet Cellular Networks”, Proc. ACM MobiCom (Dallas, TX, Oct. 1998), pp. 10-20. Ramanathan, P., and Agrawal, P., “Adapting Packet Fair Queuing Algorithms to Wireless Networks”, Proc. ACM MobiCom (Dallas, TX, Oct. 1998), pp. 1-9.

[9]

Agrawal, P., Chen, J.-C., and Sivalingam, K. M. “Energy efficient protocols for wireless networks”. Kluwer Academic, 1999, ch. 11. [10] S. Blake, D.Black, et al.: “An Architecture for Differentiated Services,” IETF RFC 2475, December 1998. [11] L. Lewis, “Implementing Policy in Enterprise Networks,” IEEE Communications Magazine, vol. 34, no. 1, pp. 50-55, January 1996. [12] D. Verma, “Policy-Based Networking: Architectures and Algorithms”, New Riders Publishing, November 2000. [13] A. Westerinen et al., “Terminology for Policy-Based Management,” IETF RFC 3198, November 2001. [14] R. Rajan, D. Verma, S. Kamat, E. Felstaine and S. Herzog, “A Policy Framework for Integrated and Differentiated Services in the Internet,” IEEE Network Magazine, vol. 13, no. 5, pp. 36-41, September/October 1999. [15] IETF Policy Framework Working Group: http://www.ietf.org/html.charters/policycharter.html. [16] The Distributed Management Task Force (DMTF). http://www.dmtf.org. [17] IETF Resource Allocation Protocol (RAP) working group:http://www.ietf.org/html.charters/rap-charter.html [18] R. Yavatkar, D. Pendarakis and R. Guerin, “A Framework for Policybased Admission Control,” IETF RFC 2753, January 2000. [19] S. Rajeev , Dr. 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 [20] K. Chan et al., “COPS usage for Policy Provisioning (COPS-PR),” IETF RFC 3084, March 2001. [21] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, “Resource ReServation Protocol (RSVP) – Version 1 Functional Specification,” IETF RFC 2205, September 1997. [22] S. Herzog et al., “COPS usage for RSVP,” IETF RFC 2749, January 2000. [23] S. Blake et al., “An Architecture for Differentiated Services,” IETF RFC 2475, December 1998. [24] KChan, R. Sahita, S. Hahn and K. McCloghrie, “Differentiated Services Quality of Service Policy Information Base,” IETF RFC 3317, March 2003. [25] S. Rajeev, Dr. S.N. Sivanandam , “Directory Management and Provisioning for Wireless Differentiated Services using Distributed Graph-Node Coloring”, Proc. International Conference on Wireless Communication Networks, Chennai, Jun 2003. [26] S. Rajeev, Dr. S.N. Sivanandam, “Frequency Planning, Allocation for Wireless Differentiated Services using Distributed Graph-Node Coloring” Proc. International Conference on Wireless Communication Networks, Chennai, Jun 2003 [27] S. Rajeev, Dr. 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 [28] 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, 29-31 Jan. 2001, Springer-Verlag LNCS 1995, pp. 18-39. [29] Mushroom, A., "Policy Maker, A Toolkit for Policy Based Security management", accepts and management NOMS with IEEE/IFIP network operation 2004, Seoul, Korea, 2004 [30] S. Rajeev, Dr. S.N. Sivanandam, “Policy Specification Language Development for Wireless Differentiated Service Networks” submitted to 12th International Conference on Advanced Computing & Communication ADCOM2004. [31] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose and S.Waldbusser,“Structure of Management Information Version 2 (SMIv2)”, IETF RFC 2578, April 1999. [32] W. Stallings, SNMP, SNMPv2, and CMIP: The Practical Guide to Network ManagementStandards, 1st edition, Addison-Wesley, 1993.

Please send all correspondence to First Author : First Author S. Rajeev M.E.,(Ph.D) Asst. Professor Department of Electronics & Communication Engineering PSG College of Technology, Peelamedu, Coimbatore – 641 004 Tamil Nadu. Ph : (0422) 2572177 ext. 436 Email : [email protected] , [email protected] Second Author Dr. S. N. Sivanandam Professor & Head Department of Computer Science & Engineering PSG College of Technology, Peelamedu, Coimbatore – 641 004 Tamil Nadu. Ph : (0422) 2572177 ext. 447 Email : [email protected] Third Author K.V. Sreenaath Department of Information Technology PSG College of Technology, Peelamedu, Coimbatore – 641 004 Tamil Nadu. Ph : (0422) 2572177 Email : [email protected]