Policy-based management

Policy-based management[1] is a technology that can simplify the complex task of managing networks and distributed systems. Under this paradigm, an administrator can manage different aspects of a network or distributed system in a flexible and simplified manner by deploying a set of policies that govern its behaviour.[2] Policies are technology independent rules aiming to enhance the hard-coded functionality of managed devices by introducing interpreted logic that can be dynamically changed without modifying the underlying implementation. This allows for a certain degree of programmability without the need to interrupt the operation of either the managed system or of the management system itself. Policy-based management can increase significantly the self-managing aspects of any distributed system or network, leading to more autonomic behaviour demonstrated by Autonomic computing systems.[3]

Frameworks and languages

The most well known policy-based management architecture was specified jointly by the IETF and the DMTF. This consists of four main functional elements: the Policy Management Tool (PMT), Policy Repository, Policy Decision Point (PDP), and Policy Enforcement Point (PEP).

The PMT is used by an administrator to define or update the policies to be enforced in the managed network. Resulting policies are stored in a repository in a form that must correspond to an information model[4] so as to ensure interoperability across products from different vendors. When new policies have been added in the repository, or existing ones have been changed, the PMT issues the relevant PDP with notifications, which in turn interprets the policies and communicates them to the PEP. The latter is a component that runs on a policy-aware node and can execute (enforce) the different policies. The components of the architecture can communicate with each other using a variety of protocols. The preferred choice for communicating policy decisions between a PDP and network devices (PEPs) is the Common Open Policy Service (COPS) or SNMP, and LDAP for the PMT/PDP–repository communication.

The simplest approach for policy specification is through a sequence of rules, in which each rule is the form of a simple condition-action pair. The IETF policy framework adopts this approach and considers policies as rules that specify actions to be performed in response to defined conditions:

       if <condition(s)> then <action(s)>

The conditional part of the rule can be a simple or compound expression specified in either conjunctive or disjunctive normal form. The action part of the rule can be a set of actions that must be executed when the conditions are true. The IETF does not define a specific language to express network policies but rather a generic object-oriented information model for representing policy information. This model is a generic one, specifying the structure of abstract policy classes by means of association, thus allowing vendors to implement their own set of conditions and actions to be used by the policy rules.

Policy conflicts

As with any programmable system, a policy-driven one can suffer from inconsistencies incurred by contradicting rules governing its behaviour. These are known as policy conflicts[5] and come about as a result of specification errors, omissions, or contradictory management operations and, in some cases, can have catastrophic effects on the operation of the managed system. They have also been described as being analogous to software bugs[6] that occur when two or more policies are activated simultaneously enforcing contradictory management operations on the system.

Classification of policy conflicts

Policy conflicts are broadly classified into domain-independent and application-specific,[7] where the former, as the names suggest, are independent of the policy application, and the latter are bound by the constraints of the application domain. Example application domains that have been considered in the literature include quality of service (QoS) in IP networks,[5][8] distributed systems,[7][9] firewall security,[10][11] and call control in telecommunication networks.[12] Policy conflicts can also be classified according to the time-frame at which they can be detected: static conflicts[13] can be detected through off-line analysis at policy specification time, whereas dynamic conflicts[14] can only be detected when policies are enforced as they depend on the current state of the managed system. For example, conflicts can occur between policies for dynamically allocating resources and those setting quotas for users or classes of service. As such, automation should be a key aspect of dynamic analysis mechanisms so that the operational impact of a conflict can be kept to a minimum.

Detection and resolution of policy conflicts

To effectively use policies and drive the functionality of a managed system in a consistent manner, it is necessary to check that newly created policies do not conflict with each other or with policies already deployed in the system. To achieve this, detection processes utilise information regarding the conditions under which conflicts can arise to search policy spaces and identify policies that meet the conflict criteria. Based on the types of conflicts identified in the literature and the different application domains in which they occur, research has concentrated in the development of mechanisms and techniques for their effective detection. Although simple conflicts (e.g. modality conflicts) can be detected by syntactic analysis, more specialised inconsistencies require a precise definition of the conditions for a conflict, which sometimes include domain-specific knowledge, and processes that utilise such information to signal the occurrence of a conflict. Popular approaches for the detection of conflicts have been based on: meta-policies (detection rules),[5][7] policy relationships,[10][11] applicability spaces,[15] and information models.[16]

Resolution is the latter part of policy analysis, which aims at handling detected inconsistencies, preferably in an automated manner, so that consistency among policies can be restored. The process of resolving conflicts may involve retracting, suppressing, prioritising, or amending policies, and in some cases, enforcing a new policy altogether so that consistency among policy rules can be restored. The methodology in doing so depends heavily on the type of policies involved and the domain in which conflicts occur. Although human intervention is unavoidable in some situations, several research efforts focussed on techniques to automate the resolution process where possible. Popular approaches for the resolution of conflicts have been based on: meta-policies (resolution rules),[5][14] precedence,[7] policy ordering,[11][15] and conflict prevention.[17]

The time-frame at which conflicts can be detected influences the analysis methodology and requirements for dealing with them. Static conflicts are typically detected through analysis initiated manually by the system administrator; conflicts represent inconsistencies between policies and are typically resolved by amending the policies.[5][13] In contrast, run-time conflicts must be detected by a process that monitors policy enforcement and detects inconsistent situations in the system’s execution. Resolution must be achieved automatically, for example through enforcing resolution rules.[5][14] Lack of automation in the handling of run-time conflicts may have catastrophic consequences on the correct system operation, especially when managing QoS for delay sensitive applications.

Policy refinement

Ideally, a policy-based management system should facilitate the definition of high-level administrative goals, which are easy for humans to express and understand, enable their translation into low-level policies and map them into commands that configure the managed devices accordingly. While the high-level goals reflect the business objectives of the network administrator, the low-level policies are responsible for device-level configurations.

Policy refinement is the process of transforming a high-level goal or abstract policy specification into low-level, concrete policies that can be enforced on the managed system. The main tasks of the refinement process are the following:

Several policy refinement approaches have been developed. The most notable ones are based on linear temporal logic [18] and event calculus.[19]

See also

References

  1. ↑ M.S. Sloman, "Policy Driven Management for Distributed Systems," Journal of Network and Systems Management, Vol. 2, No. 4, pp. 333-360, Plenoum Press, December 1994.
  2. ↑ D. Verma "Simplifying network administration using policy-based management", IEEE Network 2002.
  3. ↑ D. Agrawal, S. Calo, K. Lee, J. Lobo, D. Verma, "Policy Technologies for Self Managing Systems", IBM Press, 2008
  4. ↑ B. Moore, E. Ellesson, J. Strassner, A. Westerinen, “Policy Core Information Model,” RFC 3060, IETF, February 2001.
  5. 1 2 3 4 5 6 M. Charalambides, P. Flegkas, G. Pavlou, J.R. Loyola, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay, “Policy Conflict Analysis for DiffServ Quality of Service Management,” IEEE Transactions on Network and Service Management, Vol. 6, No. 1, March 2009.
  6. ↑ J. Strassner, “Policy-Based Network Management,” Morgan Kaufmann Publishers, ISBN 1- 55860-859-1, 2004.
  7. 1 2 3 4 E.C. Lupu, M.S. Sloman, “Conflicts in Policy-based Distributed Systems Management,” IEEE Transactions on Software Engineering - Special Issue on Inconsistency Management, Vol. 25, pp. 852-869, 1999.
  8. ↑ T. Samak, E. Al-Shaer, H. Li, “QoS Policy Modeling and Conflict Analysis,” proceedings of IEEE Workshop on Policies for Networks and Distributed Systems, New York, USA, June 2008.
  9. ↑ A.K. Bandara, E.C. Lupu, A. Russo, “Using Event Calculus to Formalise Policy Specification and Analysis,” proceedings of IEEE Workshop on Policies for Distributed Systems and Networks, Lake Como, Italy, June 2003.
  10. 1 2 E. Al-Shaer, H. Hamed, “Discovery of Policy Anomalies in Distributed Firewalls,” proceedings of IEEE Communications Society Conference, Hong Kong, March 2004.
  11. 1 2 3 E. Al-Shaer, H. Hamed, “Modeling and Management of Firewall Policies,” IEEE Transactions on Network and Service Management, Vol. 1, No. 1, April 2004.
  12. ↑ L. Blair, K. Turner, “Handling Policy Conflicts in Call Control,” proceedings of International Conference on Feature Interaction, Leicester, UK, June 2005.
  13. 1 2 M. Charalambides, P. Flegkas, G. Pavlou, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay, J.R. Loyola, “Policy Conflict Analysis for Quality of Service Management,” proceedings of IEEE Workshop on Policies for Distributed Systems and Networks, Stockholm, Sweden, June 2005.
  14. 1 2 3 M. Charalambides, P. Flegkas, G. Pavlou, J.R. Loyola, A.K. Bandara, E.C. Lupu, M.S. Sloman, A. Russo, N. Dulay, “Dynamic Policy Analysis and Conflict Resolution for DiffServ Quality of Service Management,” proceedings of IEEE/IFIP Network Operations and Management Symposium, Vancouver, Canada, April 2006.
  15. 1 2 D. Agrawal, J. Giles, K.W. Lee, J. Lobo, “Policy Ratification,” proceedings of IEEE Workshop on Policies for Networks and Distributed Systems, Stockholm, Sweden, June 2005.
  16. ↑ S. Davy, B. Jennings, J. Strassner, “Application Domain Independent Policy Conflict Analysis Using Information Models,” proceedings of IEEE/IFIP Network Operations and Management Symposium, Bahia, Brazil, April 2008.
  17. ↑ R. Chadha, Y. Cheng, J. Chiang, G. Levin, S.W. Li, A. Poylisher, L. LaVergne, S. Newman, “Scalable Policy Management for Ad Hoc Networks,” proceedings of Military Communications Conference, New Jersey, USA, October 2005.
  18. ↑ J.R. Loyola, J. Serrat, M. Charalambides, P. Flegkas, G. Pavlou, “A Methodological Approach toward the Refinement Problem in Policy-Based Management Systems,” IEEE Communications Magazine, Topics in Network and Service Management, Vol. 44, No. 10, October 2006.
  19. ↑ A.K. Bandara, E.C. Lupu, A. Russo, N. Dulay, M. Sloman, P. Flegkas, M. Charalambides, G. Pavlou, “Policy Refinement for IP Differentiated Services Quality of Service Management,” IEEE Transactions on Network and Service Management (TNSM), Vol. 2, No. 2, 2006.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.