Towards a Policy-Based Management for Ad Hoc Networks - CiteSeerX

Towards a Policy-Based Management for Ad Hoc Networks Mouna Ayari, Farouk Kamoun

Davor Males

CRISTAL Laboratory ENSI, University of Manouba 2010 Manouba, Tunisia [email protected], [email protected]

University of Paris-VI LIP6 Lab 8, rue du Capitaine Scott 75015 Paris - France [email protected]

Abstract— Quality of Service (QoS) management and provisioning in mobile ad hoc networks (manets) is a challenging task due to the lack of resources residing in the network as well as frequent changes in the network topology. Although a great deal of researches has been done in this area, QoS support for such networks remains an open issue. In this paper, we first propose a specific SLA (Service Level Agreement) for ad hoc networks. This Ad-Hoc-SLA defines user’s network requirements. It is also used to control network resource utilization. Then, we propose an extension of the Policy-Based Network Management (PBNM) system to support Ad-Hoc-SLA specification, negotiation, distribution and enforcement.

I. I NTRODUCTION A manet consists of a collection of mobile wireless nodes dynamically creating a temporary network without the assistance of any existing infrastructure or administrative support. Hence, manets have their own advantages such as high robustness and easiness to be set up at any time and anywhere. However, manets are a subject of many challenges and constraints. We argue that QoS support in manets is fundamentally different from that of traditional networks [1], [2]. According to RFC 2386 [3], QoS means providing a set of service requirements to the flows while transporting them from source to destination. Every application has its special requirements concerning required traffic characteristics and parameters like bandwidth, delay, jitter or packet loss and doesn’t need the highest level of quality for all parameters at the same time. Some applications are mostly concerned with high bandwidth, other with low delay and so on. Provisioning QoS over contemporary IP networks is often regulated and managed with the use of Service Level Agreements [4]. SLAs describe among others the technical configuration of a network

and user’s QoS requirements for specific applications and flows. However, SLAs have been already considered as business-oriented documents agreed upon between a service provider and its customers. We propose some adaptation of the SLA concept to fit ad hoc networks environment characteristics. Moreover, there is a semantic gap between what is specified in SLA and what should be implemented in ad hoc nodes. A promising technique to bridge this gap is by the use of Policy Based Network Management (PBNM) in SLA’s translation into policies, SLA’s management, control and enforcement processes. PBNM is nowadays very popular and largely deployed for QoS management in order to fulfil the quality requirements of the end user. However, this approach has been mainly used on fixed high-bandwidth networks. In our research, we discuss how to extend PBNM and we propose a specific SLA concept for mobile ad hoc networks. We aim to build a robust architecture for QoS management and control over manets. The remainder of this paper is organised as follows. In the second section, we present an overview of PBNM system. We enumerate PBNM benefits and briefly describe previous works. In the third section, we present our novel framework for QoS management and control over manets and its main components. We propose a specific SLA for ad hoc networks in the fourth section. Section five describes our dynamic domain formation procedure. In the sixth section, we propose extensions to the standard Common Open Policy Service (COPS) for use in manets. Finally, conclusion and directions for future research are presented in the last section. II. P OLICY BASED

NETWORK

M ANAGEMENT

Network management and configuration have already been a difficult task due to the variety of network

414

structures and the complexity of applications that they support. The setting up of network parameters has been done manually for each network entity. However, this creates enormous work for the network administrator and generates risks of incompatibilities and conflicts in the network configuration. In order to deal with these problems, there should be a way to encapsulate the complexity in the management of networks and services. Recently, a promising technique called Policy-Based Network Management has found with considerable interest in the network community. This approach introduces policies to control how users and applications can access and use network resources. A. What is a policy ? Policies are defined as a set of rules to administer, manage and control access to network resources [5]. These rules are typically expressed as condition / action pairs (if condition then action). A specific action can be taken when a particular condition occurs. Note that a rule specifies what is desired but doesn’t tell the network how to achieve it. Policies can be defined at different levels. Thus, it is important to distinguish between high-level policies and low-level policies [6]. A high-level policy is a presentation of the policy in a way that can be understood by a user (a human). Users can express in high level terms desired network performance behaviours. These high level terms cannot be directly implemented on network devices. They must be translated to a low-level form that can be applied on network elements. The Internet Engineering Task Force (IETF) [7] Policy Framework Working Group and the Distributed Management Task Force (DMTF) [8] have been working together to define standards for Policy Based Network Management. While DMTF concentrates on developing the CIM (Common Information Model), a generic information model for policy representation, the IETF has used and extended this model to build a scalable policy information model for IP networks. It also defined a general framework for PBNM system. B. The policy-based management system The major components found in a Policy-Based Management system [9] are shown in Fig. 1. A PBM system consists of the following components: 1) Policy management tool: The policy management tool is an interface between a network administrator and the PBNM system through which policies may be composed, edited, added and modified.

Fig. 1 P OLICY BASED M ANAGEMENT A RCHITECTURE

2) Policy repository: A policy repository is a model abstraction or a centralized database where policies and resource information about network elements are stored under a structured way. 3) Policy Decision Point (PDP): The PDP or policy server is a logical component responsible for the high level decision-making. The PDP’s decision is based on policies retrieved from the policy repository as well as on level network information collected from network management entities. The policy server generally retrieves policy from the policy repository, interprets and translates them into a format that can be used to enforce decision in the network through Policy Enforcement Points. 4) Policy Enforcement Point (PEP): A PEP is a network device (a router, a switch, an end-host) which requests and applies policy-based decisions from one or more PDPs. A PEP is also responsible for collecting the necessary information about the current network state, the traffic situation, transmission errors as well as any relevant information and reporting them to the PDP. It is important to notice that the separation between a PDP and a PEP is a logical separation and doesn’t necessarily involve a physical separation. Both components may be integrated into the same node depending on the PDP-PEP interaction scenario. In order to simplify and facilitate interactions and exchange policy information between a PEP and a PDP, the IETF Resource Allocation Protocol (RAP) Working Group has defined the Common Open Policy Server (COPS)

415

protocol [10] and its extension for provisioning COPS-PR [11]. COPS-PR is an extensible protocol that provides a proactive and global view of the network management. COPS-SLS defined in [12] attempts to extend PEP functionalities to end terminals in order to allow SLS negotiation between an Internet Service Provider (ISP) and its clients. III. T OWARDS

A NOVEL

QOS

MANAGEMENT AND

CONTROL ARCHITECTURE FOR MANETS

is required in ad hoc networks to locate the most suitable nodes that can assume the PDP role. B. Dynamic domain formation In order to adapt th centraliezd Policy-Based Networking system to a decentralized approach, we propose a dynamic domain formation. This domain formation procedure dynamically divides the whole network into domains managed by PDPs. C. Resource Discovery

The idea of extending PBNM to ad hoc networks is recent. An interesting approach to extend PBNM to manage manets is proposed in [13], [14], [15]. However, in this work, there isn’t a procedure or a mechanism for policy server’s selection. Researchers assume that during the initial deployment of a manet, a certain number of policy servers are present in the network. A second solution is described in [16]. It uses PBNM and Diffserv to define a QoS management architecture. Diffserv is used in order to implement QoS mechanisms while the configuration of the Diffserv parameters is performed using PBNM. But, the weakness of this solution resides in the use of a centralized management station. The system is inefficient if the management station becomes damaged or not accessible by ad hoc nodes. Moreover, the proposed model is fully proactive. This may introduce problems since ad hoc networks are time-varying in terms of resources and network behaviour. We need dynamic policies that can be adapted to the current state of the network. A fundamental challenge is how to adapt the traditional PBNM centralized service to a decentralized paradigm on which manets are based. In the following, we give a description of our Ad-Hoc-SLA management framework and its major components. The framework shown in Fig.2 combines SLA management networking and PBNM. It consists of the following schemes: A. PDP Selection mechanism PDPs form a dominant set in the network. They control and assign policies and decisions to be enforced in the network. PDPs accomplish several tasks such as processing Ad-hoc-SLA and PEP’s requests, checking possible conflicts in policies, receiving and collecting information about network and node behaviours, making decisions and forwarding these decisions to PEPs for enforcement. Moreover, each PDP disposes of a policy repository to store policy information of all nodes belonging to its domain. So, a PDP selection mechanism

In order to take the appropriate decision to accept or refuse the PEP’s request and then to dictate and provide a fair use of resources, the PDP must be aware of the available network resources. This includes network topology updates, PEP and PDP capabilities, bandwidth utilization ...etc. D. Ad-Hoc-SLA specification and translation process The Ad-Hoc-SLA specification deals with introducing service and performance requirements of a user (a PEP) to the management system. If the user’s request is accepted by the PDP, QoS specification is translated into policies [6], [17]. E. Policy negotiation and distribution process In the scope of this article, we propose extensions to the standard Common Open Policy Service protocol for use to support inter-PDP negotiation and mobility nodes managing. F. Ad-Hoc-SLA and policy enforcement Policy enforcement is a crucial phase since the success or the failure of the management system is checked. It consists of installing and implementing low level policies using device specific mechanisms. G. Ad-Hoc-SLA and policy monitoring The task is how to manage and monitor the compliance of an Ad-Hoc-SLA. This required a feedback mechanism between various PEPs and their PDP. In addition, each PDP has to exchange performance and monitoring information with other PDPs. H. Adaptation In the case of manets, we need a management QoS architecture which should be able to dynamically adapt itself with changes in network state and configuration. In this article we focus our interest on three aspects. First, we introduce a specific ad hoc SLA concept. Then, we describe the dynamic domain formation procedure. Finally, we propose extensions to the COPS protocol.

416

by multiple PDPs to enforce policies. In order to avoid conflicts and make consistent and coherent decisions, an inter-PDP communication might occur. In the following, we present the SLS part of the AdHoc-SLA. The SLS attributes are defined by TEQUILA project [19]. A. SLS Identification The SLS Identification is a field used by an ad hoc service provider and an ad hoc client to identify the SLS and the service the SLS is related to. SLS Identification = (SLS Id, Service Id) • •

Fig. 2 O UR P OLICY BASED M ANAGEMENT F RAMEWORK

SLS Id : is the parameter identifying the SLS. Service Id : is the parameter identifying the service the SLS is related to.

B. Scope IV. A D -H OC -SLA An Ad-Hoc-SLA is an agreement between all ad hoc nodes that regulates interactions between them and network resources consumption. Ad-Hoc-SLA specifies user’s service level requirements in its SLS (Service Level Specification) part [18]. We have added a second part that specifies common protocols and mechanisms used by the network such as the routing protocol, energy management consumption mechanisms and bandwidth management mechanisms. In our framework, we assume that all nodes are cooperative and can communicate directly with each other or through a multi-hop path. Because of its relaying capabilities, a mobile ad hoc node can play one or two of the following roles: • An ad hoc “server provider” which is the entity that makes a decision to accept or refuse the service level client’s request. It is also responsible for the enforcement of this decision. • An ad hoc client which is the entity that queries for a given transport service level and consumes network resources. It can establish a connexion to an ad hoc service provider. A policy client can be an application, a user, an organisation or a policy server. The technical part of the Ad-Hoc-SLA (the SLS part) can be negotiated between an ad hoc client and an ad hoc service provider. If we consider the PBNM model, the ad hoc service provider acts as a PDP. On the other hand, the ad hoc client acts as a PEP since it is asking for and consuming network resources controlled by the ad hoc service provider. Notice that a network can be managed

This field must specify where packets conforming to the SLS are entering and exiting the ad hoc network. The associated scope of an SLS must be expressed by a couple of ingress and egress interfaces. •

•

The “ingress node” is the host that sends data, classifying, marking and policing packets. The “egress node” is the destination node.

C. Flow Identification The Flow Identification (Flow Id) of an SLS associated for a given service offering indicates for which IP packets the QoS policy for that specific service offering is to be enforced. An SLS Flow Id may formally be specified by setting one or more of the following attributes: Flow Id = (DSCP, source information, destination information, application information) D. Traffic Envelop and Traffic Conformance The traffic envelop describes the traffic (conformance) characteristics of the IP packet stream identified by the Flow Id. The traffic envelop is a set of Traffic Conformance Parameters, describing how the packet stream should look like to get the guarantees indicated by the performance parameters (defined in Subsection IV-F). E. Excess treatment This attribute specifies how excess traffic (or out-ofprofile traffic, according to the profile described by the traffic envelope and traffic conformance field) is treated.

417

F. Performance parameters The performance parameters describe the service guarantees the network offers to the user for the packet stream described by the Flow Id and the scope. There are four performance parameters: • one-way transit delay, optional quantile • packet delay variation or jitter, optional quantile • packet loss • throughput G. Service schedule This field indicates the start time and the end time of the period for which the service is provided. H. Monitoring The monitoring indicates the QoS parameters that have to be monitored and reported. They will be applied on the set of interfaces defined in the Scope block of the SLS Template. V. DYNAMIC

DOMAIN FORMATION

A domain is formed by a PDP and its PEPs. On one hand, each PDP maintains a domain and a list of the other PDPs address and identifiers. On the other hand, each PEP tries to connect with the nearest PDP as its current PDP and becomes a member of that PDP’s domain. This will be optimal in terms of resource management since more the distance between a PDP and a PEP increases, more resources will be spent at intermediate nodes. To reach this purpose, we propose a simple distributed algorithm to form dynamic domains. The procedure shown in Fig. 3 is similar to techniques used for service and resource discovery in manets described in [20], [21]. A PDP periodically broadcasts at a low frequency an “Advertisement message” to its neighbouring nodes. This announcement message includes the PDP identifier (PDPID), the PDP Address IP, the expiration time of the announcement (TTL) and a distance field. The latter field contains an estimation of the distance between the PDP and the node that receives the advertisement. The metric used to measure the distance between a PDP and a PEP can be the number of hops, the transit delay or any other performance metric. Upon receiving an advertisement message, a PEP checks the value of the distance field. If it is smaller than the distance to its current PDP, it will put its current PDP (if it exists) as its last PDP, set the sender of the Advertisement message as its current PDP and forward the announcement to all its neighbouring nodes. Otherwise, the node stops

Fig. 3 D OMAIN F ORMATION M ANAGEMENT

forwarding the announcement message in order to reduce the signalling overhead. A node updating its current PDP, sends a “Client Reply” message to the selected PDP to join its domain. In the following section, we propose extensions to the standard Common Open Policy Service (COPS) protocol for use in manets. The signalling procedures are used to support inter-PDP negotiation and mobility nodes managing. VI. P OLICY

NEGOTIATION AND DISTRIBUTION PROCESS

Due to the PDP and PEP mobility, a PEP may move from a domain to another. However, the PDP may not have relevant policies for the PEP joining its domain. To address such case, we define new object called “New PDP Address” in the COPS protocol and an inter-PDP communication process. A PDP may decide to leave the network. This may cause great performance degradation in the network since the PDP is a decision centre and manager of its domain. To resolve this problem, we define a redirection mechanism. A. When a PEP joins a new domain Based on the dynamic domain formation mechanism described above, a PEP may change its current policy server to the nearest one. Its current PDP becomes its Last one (LPDP). After updating its current and last policy address fields, a PEP embeds the “New PDP Address” object in the COPS Close message and sends it to its LPDP. Notice that the “New PDP Address” object is similar to the “Last PDP Address” object defined

418

sends a COPS Decision message back to the NPDP in which it specifies information about the PEP and its related policies. Then, the NPDP replies with a COPS Report message to indicate the success or the failure of polices’s installation. If the procedure succeeds, the NPDP adds the related PEP to its domain. On the other hand, the LPDP sends a COPS Close message to its PEP indicating the closure of the connection. This Close message embeds the address of the new PDP in the field “Redirected PDP Address”. Notice that if a policy server becomes inaccessible (for example becomes damaged), the PEP switches immediately to its Last PDP. VII. C ONCLUSIONS Fig. 4 I NTER -PDP N EGOTIATION S CENARIO

in COPS Standard protocol. Then, the PEP starts a COPS connexion with its New PDP (NPDP) by sending a COPS Open message in which it indicates its last PDP address. Don’t having the relevant policies for this PEP, the NPDP sets up a COPS connection with the LPDP. New client type is added to address the interPDP communication. The signalling involved is shown in Fig. 4. The NPDP sends a COPS REQUEST message including information about the recently connected PEP in the Named ClientSI field. The LPDP answers by a COPS Decision message specifying relevant policies corresponding to the client. So, the NPDP downloads these policies and replies with a COPS Report message indicating the success or the failure of this procedure. If this operation is successfully accomplished, the LPDP removes the client from its domain.

AND FUTURE

W ORK

In this paper, we presented a new QoS management framework suitable for mobile ad hoc networks. Our proposed solution tries to take advantage of researches done in SLA management networking, Policy-Based Management Networks and ad hoc management networks. We have first introduced the Ad-Hoc-SLA concept in order to regulate mobile ad hoc node interactions and to simplify network resources management tasks. Then, to manage Ad-Hoc-SLA, we have extended the Policy-Based Management System to fit ad hoc networks features. In order to introduce a decentralized network management, we have described a dynamic domain formation procedure. Our procedure dynamically partitions the network into domains each managed by a policy server. Finally, we have proposed extensions of the Standard COPS Protocol to deal with nodes’s mobility and to allow inter-PDP communication.

B. When a PDP decides to leave the network To address such case, we define a redirection process. If for a given reason a PDP (LPDP) decides to leave the network, it should notify the others PDPs and redirect its connected PEPs to them. So, it chooses from its list of PDPs some policy servers to support its PEP negotiation and QoS enforcement tasks (for example the nearest ones). The redirection proposed mechanism is shown in Fig. 5. The LPDP establishes a new COPS communication with the chosen PDP (NPDP) by sending a COPS Open message. A new client type is introduced to indicate this case “PDP Redirection Negotiation”. If the NPDP accepts to be delegated it sends a COPS Accept message. Otherwise, it sends a COPS Close message. In case of acceptance, the LPDP 419

Fig. 5 PDP R EDIRECTION S CENARIO

In our ongoing research efforts, we are building the complete framework. It includes the PDP selection mechanism, a resource discovery approach and a system performance evaluation through simulations. We will also define suitable mechanisms for policy enforcement and QoS provisioning. R EFERENCES [1] S. Chakrabarti and A. Mishra, “QoS Issues in Ad Hoc Wireless Networks”, IEEE Communications Magazine, February 2001. [2] Dmitri D. Perkins and Herman D. Hughes, “Factors Affecting the Performance of Ad Hoc Networks”, Proceedings of the IEEE International Conference on Communications, April 2002. [3] E. Crawley and al., “A Framework for QoS-based Routing”, IETF RFC 2386, August 1998. [4] C . Bouras, M. Campanella, A. Sevasti, “SLA definition for the provision of an EF-based service”, March 2002. [5] A. Westerinen and al., “Terminology for Policy-Based Management”, IETF RFC 3198, November 2001. [6] T. H. Jonatan, “SLA enforced by policy”, Dept. of Computer Science, University of Twente, June 2001. [7] Internet Engineering Task Force (IETF): http://www.ietf.org, 2003. [8] The Distributed Management Task Force, Inc., (DMTF): http://www.dmtf.org, 2003. [9] J. Wong, R. Hunt, “Policy Based Network Management”, Department of Computer Science, University of Canterbury, New Zealand, February 2003. [10] D. Durham, et al., “The COPS (Common Open Policy Service) Protocol”, IETF RFC 2748, January 2000.

[11] K. Chan et al, “COPS usage for Policy Provisioning (COPSPR)”, IETF REF 3048, March 2001. [12] T.M.T. Nguyen and al. “COPS-PR Usage for SLS negotiation (COPS-SLS)”, Internet Draft, draft-nguyen-rap-cops-sls-03.txt, work in progress, January 2003. [13] K. Phanse, L. DaSilva and S. Midkiff, “Extending PolicyBased Management to Ad Hoc Networks”, Virginia Polytechnic Institute and State University, IREAN Research Workshop-2003, April 2003, Alexandria. [14] K. Phanse and L. DaSilva, “Protocol Support for Policy-Based Management of Mobile Ad Hoc Networks”, Virginia Polytechnic Institute and State University, July 2003. [15] K. S. Phanse, “Policy-Based Quality of Service Management in Wireless Ad Hoc Networks”, Virginia Polytechnic Institute and State University, October 2002. [16] A. Munaretto, N. Agoulmine, M. Fonseca, “Policy-based Management of Ad Hoc Entreprise Networks”, 2001. [17] D. Verma, “Policy-Based Networking: Architecture and Algorithms”, Chapter 3, published November 2000. [18] G. Cristallo and al., “Functional Architecture Definition and Top Level Design”, IST Project TEQUILA, Deliverable D1.1, September 2000. [19] D. Goderis and al., “Service Level Specification Semantics and Parameters”, Internet Draft, draft-tequila-sls-02.txt, February 2002. [20] J. Liu, K. Sohraby, Q. Zhang, Bo Li, and Wenwu Zhu, “Resource Discovery in Mobile Ad Hoc Networks”, Handbook on Ad Hoc Wireless Networks, CRC Press, 2002. [21] D. Chakraborty, A. Joshi, Y. Yesha, and T. Finin, “GSD: A Novel Group-based Service Discovery Protocol for MANETS”, Proceedings of International Workshop on Mobile and Wireless Communications Networks 2002, 2002.

420