An architecture for automated replacement of QoS policies - CiteSeerX

An Architecture for Automated Replacement of QoS Policies Lisandro Zambenedetti Granville, Gustavo Augusto Faraco de S´a Coelho, Maria Janilce Bosquiroli Almeida, Liane Margarida Rockenbach Tarouco Federal University of Rio Grande do Sul - UFRGS Institute of Informatics Av. Bento Gonc¸alves, 9500 - Bloco IV Porto Alegre, RS - Brazil fgranville, gcoelho, janilce, [email protected] Abstract This paper introduces the notion of PoP (Policy of Policies) used to define standard policy replacement strategies in a policy-based network. We also propose an architecture to support PoP within PDPs (Policy Decision Points originally defined by the IETF). The notion of PoP, and the proposed architecture allow the automation of the policy replacement task currently manually executed by the network administrator based on the network business plan. Keywords: policy-based network management, policy definition, policy of policies, meta-policies, policy replacement automation.

1

Introduction

The deployment of QoS-provisioning mechanisms in computer networks is necessary in order to provide different levels of services for networked applications. Typically, IP-based networks need more guaranties than those the best-effort approach can provide in order to allow the deployment of real-time and mission-critical applications. The QoS-provisioning mechanisms added to the network increase the amount of management information available to the network administrator. This new information must be considered in the network management strategy to guarantee the adequate behavior of the deployed QoS provisioning solution. From a network management point-of-view, dealing with this new information is a complex task that is not properly addressed by standard device-oriented management platforms [1]. Nowadays, Policy-Based Network Management (PBNM) [2] has been pointed out as an effective solution to the problem of managing QoS-enabled networks. Using high-level abstractions, network managers define policies that manage the network behavior. Special elements in the

network translate policy definitions into device-specific actions. That allows the abstraction of the device complexities and heterogeneity: network managers only specify what the network is supposed to do, and not how it should be done. When a new policy is deployed, a Policy Decision Point (PDP) [3] or a policy consumer [4] proceeds with the policy translation to device-specific actions in a Policy Enforcement Point (PEP) [3] or policy target [4]. While deploying, a policy may fail due to conflicts with other policies, lack of resources, or device unavailability, among other reasons. In all of those cases, the policy consumer should notify the network manager about the unsuccessful deployment. On the other hand, if the policy is said to be successfully deployed, no further verifications are executed by the PBNM system: the network manager is the one responsible for that. In this context, if a policy fails after its deployment, that condition is not perceived by the PBNM system, and the network administrator is forced to use monitoring solutions to check if the effective network QoS is consistent with the QoS defined in the deployed policies. When a problem in deployed policies is identified (regardless of which procedures were taken to do so), inappropriate policies must be replaced or removed, and possibly new policies have to be used, trying to lead the network operation to a consistent state. Nowadays, all these tasks are manually executed and automation could ease the complexities of dealing with all these procedures. This paper is specially concerned about the automation of the maintenance of policies when problems are identified after the deployment of such policies. Here we introduce the notion of PoP (Policy of Policies) in the sense that some policies are defined to coordinate the deployment of other policies. This is different from (but complements) the IETF notion of hierarchical policies [4], where simple policies rules are used to create more complex policies. We also propose an architecture that uses finite state machine to, internally to

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE

policy consumers, switch from one policy to another when special events (probably detected external problems) occur. The paper is divided as follows. In section 2 we introduce the notion of PoP (Policy of Policies) and in section 3 an architecture for PoP support in policy consumers is proposed. Finally, section 4 finishes the paper presenting final remarks and future work.

2

PoP - Policy of Policies

Nowadays, most of PBNM research projects are concerned with policies before and during their deployment. On the other hand, this paper focuses on the investigation of the maintenance of policies after their deployment. Here, two main points are of special interest:

 Checking the adequate operation of deployed policies  Replacement of policies with detected problems Checking the adequate operation of deployed policies is necessary to guarantee that the QoS observed in the network is consistent with the QoS specified in the policies. If the observed and defined QoS are too different from each other, the negotiated services will not be respected and applications will face degradation. Network managers are then supposed to proceed with actions to lead the network to a more consistent state. Such actions can include, for instance, the creation/ alteration/ removal of interfaces’ queueing disciplines in routers, definition of new policing processes or the activation of traffic shaping in edge routers. Since policies coordinate all these mechanisms, they are also expected to be created, removed or replaced when network managers have to solve a previously detected QoS problem. Thus, while checking for an adequate operation of policies is a task intended to find problems, replacement of policies is a task intended to solve such problems. This section discusses policy definition and introduces the notion of PoP (Policy of Policies). Since policies can be defined based on other policies, the notion of PoP can be misunderstood. To avoid a possible confusion, first we review how more complex policies can be created using simpler ones. After that, we check policy maintenance and finally the notion of PoP is introduced.

2.1

Standard Policy Definition

As stated by Westerinen et al. [3], “policy is a set of rules to administer, manage, and control access to network resources”. Thus, one policy can be composed by one or more rules. Each rule, also known as policy rule, is the binding of a set of actions to a set of conditions. One policy rule is the basic element of a PBNM system, allowing

the creation of very simple policies (consisting of only one policy rule), or more complex policies (composed of several policy rules). The important point here is the fact that one policy can be formed by one policy rule or by several policy rules. If we think in policy rules as policies with just one rule, we can say that complex policies can be formed by the combination of simpler policies [5] [6] [7]. This notion is important because it is quite different from the notion of PoP to be presented in the following sections.

2.2 Policy Maintenance Nowadays, PBNM tools provide the manager with functionalities to proceed with the maintenance of the policies stored in the system. The possibility to group policy rules in one more complex policy is a form of assistance that the available tools supply to the user in order to try to ease the maintenance task of this information. As stated by Moore et al. [5], sharing and reusing are other reasons for grouping rules with common goals. Although this feature allows for keeping rules with common objectives together in only one group, there is still a lack of another mechanism that allows the automation of the replacement of such policies when special events are observed. The current situation is one in which the manager is forced to remove policies and to apply others when special events occur. Thus, in a network degradation situation, for example, the manager will have to manually apply one or more new policies in order to try to keep the essential applications and services operating correctly, in detriment of other less important services. The network manager is the person who best knows which applications and services must be kept and which must be removed in the several problem situations that happen daily. Thus, the manager already has, however informally, a business plan of actions for the most common situations (figure 1). In figure 1, four policies for a hypothetical network are presented. The policy ]1 is used daily and represents the normal operation situation of the network. The remaining policies represent the solutions that must be applied when certain problems are verified. Thus, policy ]2 is used when degradation in the VoIP service is detected; policy ]3, when the company ERP application has problems; and policy ]4 when critical situations occur in the hypothetical network. Current PBNM tools allow the storage of these four policies in the system but they do not allow the automation of the policy replacement process. Thus, it is a manager task to remove/enforce the policies when problems occur. Besides overloading the network manager, the policy maintenance task can be badly executed or can be delayed because it depends on human intervention. Thus, the automation of the policy replacement process would be an interesting solution for these problems. This is the PoP objective – to allow the

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE

Policy1 (Normal conditions)

Policy2 (VoIP degradation detected)

Rule1: VoIP service if (Application = VoIP) then Priority = 2 Rule2: ERP application if (Application = ERP) then Priority = 1 Rule3: Other applications if (Application = Other) then Priority = 0

Rule1: VoIP service if (Application = VoIP) then Priority = 2 MAX_AGGR_BW = 512 Kbps ; for all calls Rule2: ERP application if (Application = ERP) then Priority = 1 Rule3: Other applications if (Application = Other) then Priority = 0

Policy3 (ERP degradation detected)

Policy4 (Abnormal conditions)

VoIPproblem

GeneralProblem

P2 Normal P1 Normal Normal

ERPproblem

ERPproblem

Rule1: VoIP service Rule1: VoIP service if (Application = VoIP) if (Application = VoIP) then then Priority = 2 Priority = 2 MAX_AGGR_BW = 512 Kbps ; for all calls MAX_AGGR_BW = 512 Kbps ; for all calls Rule2: ERP application Rule2: ERP application if (Application = ERP) if (Application = ERP) then then Priority = 2 Priority = 2 MAX_AGGR_BW = 1024 Kbps MAX_AGGR_BW = 1024 Kbps Rule3: Other applications Rule3: HTTP e Mail applications if (Application = Other) if (Application = HTTP) or (Application = Mail) then Priority = 0 then Priority = 0 Rule4: Other applications if (Application = Other) then MAX_AGGR_BW = 0 Kbps ; deny services

sible standard policy that can be deployed in a policy target (e.g. router queueing discipline, traffic shaping process, etc.), either for direct usage or defined to be the replacement of other policies. Besides, a PoP definition also requires the identification of events that can trigger a policy replacement. Here, a finite state machine (FSM) is used as a means to define PoPs, where nodes represent scripts executed for replacement of policies, and transitions represent the events that lead to replacing a policy. P1:

remove all deploy Policy1

P2:

remove Policy1 deploy Policy2

P3:

remove Policy1 remove Policy2 deploy Policy3

P4:

remove all deploy Policy4

GeneralProblem

P3

P4

GeneralProblem

Figure 2. PoP example Figure 1. Policy plan example creation of higher level policies to coordinate the enforcement/removal of lower level policies as the ones previously presented (figure 1).

2.3

The Notion of PoP

The replacement of policies, when the observed QoS is too different from the specified QoS, is executed manually by the network administrator. We believe that the automation of such replacement would ease the task of maintaining network operations. As we saw in the previous subsection, the replacement of policies depends on the network business plan. Different networks have different policy replacement strategies. Thus, one requirement for policy replacement automation is the definition of which policies would replace which other policies, and under which circumstances. These definitions are based on the network goals, and can be seen as policies, but at a higher degree of functionality than standard policies. In this context, we introduce the notion of PoP (Policy of Policies). PoP is similar to meta-policies [8], since it defines higher functional policies. However, a PoP can be considered a meta-policy that orchestrates the deployment and the replacement of standard QoS policies when special events occur. These special events are typically triggered when problems in previously deployed policies are identified. Although we define PoP to coordenate QoS policies, it is important to mention that the PoP concept can be used with other types of policies, such as policies for access control. The definition of a PoP requires references to every pos-

Figure 2 shows an example of a very simple PoP that automates the policy management plan presented in figure 1. As expected, this PoP definition is composed by the state machine and the execution scripts that are activated by the transitions. For instance, script P2 will be executed when the event VoIPproblem is triggered. The script P2 removes Policy ]1 and deploys Policy ]2. Also, because the same rule to support VoIP service is defined in both Policy ]2 and Policy ]3, there is no need for a VoIP transition from node P3 to node P2. When planning a policy, the network administrator can group policy rules according to the network business plan. With PoPs, administrators are supposed to define the standard policies and PoPs (with their state machines and replacement scripts). It is important, in this case, to plan the standard policies and PoPs together, to reach an adequate replacement strategy. Policies should not be defined in an ad hoc nature, but rather as a group according to an overall management strategy. In this scenario, we think PoP can be a good assistance tool to help network managers bring their business plan goals, expressed in a higher level language, to another language that can be used to manage their networks. For the examples from figure 1 and 2, a more proper set of standard policies and corresponding PoP would be the ones presented in figure 3.

3 PoP Architecture In this section we propose an architecture to support PoP. The main point is the provisioning of a replacement automation engine inside PDPs. The proposed architecture is depicted in figure 4 and extends the IETF definitions for policy management systems [4].

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE

PolicyVoIPNormal (VoIP normal conditions) Rule1: VoIP service if (Application = VoIP) then Priority = 2

PolicyERPDegr (ERP degradation detected) Rule1: ERP application if (Application = ERP) then Priority = 2 MAX_AGGR_BW = 1024 Kbps

PolicyERPNormal (ERP normal conditions) Rule1: ERP application if (Application = ERP) then Priority = 1

PolicyOtherDegr (Other applications abnormal conditions) Rule1: HTTP e Mail applications if (Application = HTTP) or (Application = Mail) then Priority = 0 Rule2: Other applications if (Application = Other) then MAX_AGGR_BW = 0 Kbps ; deny services

UI (user interface) ES #1 (event source) IM (internal manager)

…

PolicyVoIPDegr (VoIP degradation detected) Rule1: VoIP service if (Application = VoIP) PolicyOtherNormal (Other applications normal conditions) then Rule1: Other applications Priority = 2 if (Application = Other) MAX_AGGR_BW = 512 Kbps ; for all calls then Priority = 0

PR (policy repository)

EI IPR (internal PR) IPDP (internal PDP)

ES #2 (event source) PDP (policy decision point)

PEP (policy enforcement point) VoIPproblem P2

Normal Normal

ERPproblem

ERPproblem

P1

VoIPproblem

VoIPproblem

Normal

P1:

GeneralProblem

GeneralProblem

P3

P2:

remove PolicyVoIPNormal deploy PolicyVoIPDegr

P3:

remove PolicyERPNormal deploy PolicyERPDegr

P4:

remove PolicyOtherNormal deploy PolicyOtherDegr

P4 ERPprobem

GeneralProblem

remove all deploy PolicyVoIPNormal deploy PolicyERPNormal deploy PolicyOtherNormal

Figure 3. Standard policies and corresponding PoP definitions

The network administrator uses the UI (user interface) to define standard policies and PoPs. Such policies and PoPs are then stored in the external PR (policy repository). The repository acts exactly the same way the IETF defined repository works [4], except that it now stores PoPs, too. The administrator can retrieve previously stored definitions to remove or modify them. To define the network behavior, the network administrator contacts PDPs (that can be seen as black box for now) throughout the UI. The PDPs then communicate with PEPs to enforce policies. External ES (event sources) can notify PDPs when special situations are detected. A typical example of an ES is a QoS monitor that checks network QoS and triggers notification every time QoS degradations are detected [9]. ES notifies PDPs accessing the EI (event interface) that is a unique event communication point in the PDPs. The proposed architecture splits the original IETF PDP into three main elements: IPR (internal policy repository), IM (internal manager) and IPDP (internal PDP). The IPDP acts exactly the same way as a standard PDP acts. It is controlled by a manager (in this case the IM), retrieves standard policies from a policy database (in this case the IPR), and contacts PEPs to proceed with the policy deployment and removal. Standard policies are used by the IPDP in the policy deployment / removal procedures, while PoPs are used by the IM to control the policy replacement strategy in the IPDP. The IPR is functionally identical to the external PR and stores the same kind of information: standard policies

Figure 4. PoP architecture and PoPs. However, the IPR communication interface is not based on LDAP, but on inter processes communications facilities (IPC), since this database is likely to be memory implemented.

3.1 IM and Policy Replacement The IM is the most important element involved in PoPs because IM is responsible for the implementation of the policy replacement engine. When a new set of standard policies and PoPs is available to a PDP, the network administrator contacts (using the UI) the PDP’s IM to proceed with the policies and PoPs transfer. This transfer results in the copy of policies and PoPs from the external PR to the IPR. The IM then retrieves a PoP state machine from the IPR. The initial state indicates the execution of a specific replacement script. Such script is also retrieved and executed by the IM. After its execution, the script definition is removed from IM, but a copy still exists in the IPR. Although figure 4 presents the UI as a single element, actually it should implement a whole system to coordinate the deployment of PoPs. In this context, the main issue addressed by the UI is the ability to inform the PDPs when new policies and PoPs are defined. The problems related to the scalability of the policy transfer process (from UI to PDP) faced in the PoP architecture are similar to those present in other PBNM solutions, when transferring policies from standard policy servers to standard PDPs. A state transition is executed within IM when its EI (event interface) receives an event by an external ES. When an event is received, the IM evaluates that event against the current state of the PoP’s state machine. If there is a defined transition from the current state to another that should be executed when the received event occur, then such event is consumed, and the transition proceeds. The new state indicates the execution of another policy replacement script that is also retrieved by the IM from the IPR. Again, that script is executed and after removed from IM, although a

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE

copy still remains on the IPR. On the other hand, if there is no transition associated to the received event, the event is discarded and no transition is executed by the IM. The policy removal process executed by a replacement script is identical to the removal process executed by standard PBNM system. The removal of a PoP, on the other hand, requires more interactions in the system. When a deployed PoP is removed from a PoP-enabled PDP, the PoP’s definition in the IPR is erased. Also, every policy associated to the removed PoP is erased from the IPR. However, if the same policy is associated to more than one PoP in the same IPDP, such policy is only removed when the last remaining PoP is also removed. The state machine controlled by the IM can be monitored by the administrator. Using the UI, the administrator contacts the IM and a reply is generated, informing the internal state of the defined PoP in use. Thus, the network administrator is able to verify which policy, from the set of policies formed in the business plan, is active. Concluding, it ends up with 3 possible interactions between UI and IM: policy and PoPs deployment, policy and PoPs removal, or IM monitoring.

3.2

Standard Policies and PoPs Retrieval

A critical point in PoP is the task of retrieving policies and PoPs from the external PR. The external PR typically stores all policies and PoPs used by all network’s PDPs. A distributed PR can be used although, but for simplicity we will consider only one centralized PR. The IPR, differently from the external PR, stores policies and PoPs related to a single PDP: the PDP that owns the IPR. Thus, IPR stores a subset of data stored in the external PR. As a consequence, the IPR is able to have a quite small storage capacity if compared to the external PR storage capacity. This is important, since PDPs have fewer resources than the management station and external databases. Considering that PDPs are expected, in the near future, to be implemented within network devices (e.g. routers and switches) the resources available to PDPs, such as memory, will not be that great. In this situation, even in PoP-enabled PDPs that use just one PoP at a time, the storage capacity of IPRs can be limited. Thus, in some circumstances, the IPR may be unable to store the whole set of standard policies and PoP. A solution for this lack of resources is to split the set of data required for PoP execution, and use a strategy to retrieve information on demand. To do that, when a PoP are to be used, its state machine and replacement scripts are evaluated, and a unique priority value is associated to each policy referenced by the PoP. This evaluation can be done by the management system when a PoP is defined, or by the PDP when a PoP is deployed. Policies “closer” to the initial state are assigned higher priority, while policies “far” from the initial state are assigned lower priority. When IPR

is required to download a set of policies, those whose priority value is higher are downloaded first. If there is a lack of memory, policies with lower priority are not retrieved from the external PR. If a policy replacement executed by the IM requires the use of a policy absent in the IPR due to the lack of resources, some previously downloaded policies are removed, and the required policy is downloaded. In addition to other information cited before, IM is also expected to allow the network administrator (using the UI) to be able to check which policies were effectively downloaded and which ones have been already removed from the IPR. It is also important to note that the management of policies and PoPs transfers is wholly orchestrated by the IM. Although this feature makes the IM more complex, it keeps the other elements simpler. For example, from the IPDP point-of-view, there is only one policy repository: the IPR. External PR, UI and ESs are hidden to the IPDP implementation.

4 Conclusions and Future Work In this paper we have introduced the notion of PoP (Policy of Policies). A PoP is used to define a policy replacement strategy applied to a network that follows a specific business plan. A PoP is formed by a state machine and replacement scripts that control the replacement of deployed policies when special events (probably QoS detected problems) occur. We have discussed policy rules, standard policy definition, and the definition of policies when PoP is present. Although the grouping of policy rules to create more complex policies is a powerful feature, the network administrator is forced to plan policies differently when PoP is present, and the grouping mechanism also has to be used differently. This can make the use of policies in the presence of PoP more complex, but the complexity associated to a set of policies intended to be used in a standard manual replacement strategy is even greater. In this context, the complexity introduced by PoP is lower than the complexity actually present in manual policy replacement strategies. An architecture to support PoP was also proposed. The architecture splits the standard IETF PDP into three internal elements. An internal PDP operates the same way a normal PDP operates, but is controlled by an internal manager that is responsible for implementing a policy replacement engine. An internal policy repository is used to bring important policies closer to the internal PDP. The transfer of policies, their removal from the internal repository, and their usage in the IPDP are actions coordinated by the internal manager, too. We believe the main contribution of our work is the introduction of an issue that has not been investigated until now. Although the policy replacement strategy is an important issue in the maintenance of a policy-based network,

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE

its automation is currently performed manually. The introduction of PoP and the proposed architecture can be a real solution for such needed automation. In the future work to be developed, a prototype for the proposed architecture has to be implemented in order to verify the practical aspects involved in PoP. Another important point is the fact that the current PoP definitions are not related to temporal issues for simplicity. These temporal issues have to be investigated as well, mainly because the notion of PoP can introduce more policy conflicting situations. Finally, the mechanism for policy priority evaluation (required by internal policy repositories that lack memory) has to be more exactly defined to allow a proper implementation.

tems, IEEE Int. Workshop on Systems Management, pp.55-64. June. 1996. [9] M. Ribeiro, L. Granville, M. Almeida and L. Tarouco, QoS Monitoring System on IP Networks, IFIP/IEEE International Conference on Management of Multimedia Networks and Services, MMNS 2001.

References [1] M. Eder and S. Nag, Service Management Architectures Issues and Review, Request for Comments (RFC) 3052. Internet Engeeniring Task Force (IETF), Jan. 2001. [2] M. Sloman, Policy Driven Management for Distributed Systems, Journal of Network and Systems Management, vol. 2, pp.333-360. Dec. 1994. [3] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry and S. Waldbusser, Terminology for Policy-Based Management, Request for Comments (RFC) 3198. Internet Engeeniring Task Force (IETF), Nov. 2001. [4] H. Mahon, Y. Bernet, S. Herzog and J. Schnizlein, Requirements for a Policy Management System, . Internet Engeeniring Task Force (IETF), Nov. 2000. (expired draft). [5] B. Moore, E. Ellesson, J. Strassner and A. Westerinen, Policy Core Information Model, Request for Comments (RFC) 3060. Internet Engeeniring Task Force (IETF), Feb. 2001. [6] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, A. Westerinen, R. Chadha, M. Brunner, R. Cohen and J. Strassner, Policy Core Information Model Extensions, . Internet Engeeniring Task Force (IETF), Nov. 2001. (work in progress). [7] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen and B. Moore, Policy QoS Information Model, . Internet Engeeniring Task Force (IETF), Nov. 2001. (work in progress). [8] T. Koch, C. Krell and B. Kramer, Policy Definition Language for Automated Management of Distributed Sys-

Proceedings of the Seventh International Symposium on Computers and Communications (ISCC’02) 1530-1346/02 $17.00 © 2002 IEEE