Policy Analysis

From SimpleWiki
Revision as of 18:29, 28 April 2010 by Marinosc (talk | contribs) (New page: <DIV style="text-align:justify"> Policy-based management has been proposed in recent years as a suitable means for managing Quality of Service (QoS) in IP networks. Yet despite research pr...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Policy-based management has been proposed in recent years as a suitable means for managing Quality of Service (QoS) in IP networks. Yet despite research projects, standardisation efforts, and substantial interest from industry, policy-based management is still not a reality. There are some vendor tools, mostly part of virtual private network provisioning toolsets, but policy-based management is still far from being widely adopted despite its potential benefits of flexibility and constrained programmability. One of the reasons for the reticence to adopt this technology is that it is difficult to analyse policies to determine that they will actually work given the capabilities of managed network devices, and to guarantee the stability of the network configuration given that policies may have conflicts leading to unpredictable effects.

In addition to analysing policies for consistency, there is a need to translate business needs into policies that can be enforced by the underlying systems. Often these requirements can be expressed as high-level policies which then must be transformed into lower-level policies, expressed in terms of management operations supported by the system. This process is called policy refinement and is another area of policy based systems research.

This section of the Quality of Service Management Information Portal serves as a focal point for research related to Policy Analysis.

General Description

The rapid evolution of the Internet, the increasing complexities and heterogeneity of modern networking technology, and the increase in the number of resources to be managed, pose a significant challenge to network management models. Policy Based Network Management (PBNM) is a promising solution for these demands, providing the means by which the administration process can be simplified and largely automated in a flexible manner. PBNM has been the subject of extensive research over the past decade, evidenced by several research and development efforts in both academia and industry, working groups leading standardization efforts, new technical conferences, and new commercial products. The policy-based approach can be used to manage different aspects of a network, commonly known as policy disciplines, including Quality of Service (QoS) and network security.

Although extensive work has been done in developing policy specification languages, protocols and architectures to support policy-based management, little attention has been devoted to the area of policy analysis. Policy analysis is considered to be an essential component of modern PBNM solutions and comprises two functionalities: namely conflict analysis and policy refinement.

Policy conflicts can be classified into domain-independent and application-specific. Conflicts of the first type can occur irrespective of the application domain for which the policies are being specified due to generic relationships that may exist between policy actions such as redundancy, mutual exclusion and modality. In the case of application-specific conflicts these relationships are bounded by the context of the application domain. In an environment where a number of policies need to coexist, there is always the likelihood that several policies will be in conflict, either because of a specification error or because of application-specific constraints. It is therefore important to provide a means of detecting conflicts in the policy specification.

Once the policy driven operation of a system has been analysed and the different types of conflicts that can arise have been identified, it is possible to define rules that can be used to recognise conflicting situations in the policy specification. In order to keep a system "conflict-free", these rules can be invoked during a conflict detection process prior to policy deployment to identify potential inconsistencies. This is known as static conflict detection and takes place at specification time. Although this process can reduce run-time errors and detect specification errors, its limitation is that it may not be possible to evaluate policy constraints, as they may depend on the run-time state of the system, so only potential than actual conflicts can be detected. This signifies the need of dynamic conflict detection, which makes use of similar detection rules but takes place at run-time. This leads us to the main difference between static and dynamic analysis techniques – conflict resolution.

The process of resolving some static conflict types involves giving precedence to one or more of the conflicting policies. Research on conflict resolution identified metrics that can be used to assign priorities to conflicting policies, which can automate the resolution in limited situations. However, many types of conflicts rely on human intervention for resolution. Although this process is manual, it does not impose any overheads on the functionality of the underlying system since it takes place before policy enforcement. In contrast to the above dynamic conflicts can only be determined at run-time, which signifies the need for an automated resolution process so as to minimize the delay induced on the operation of the system when a conflict is to be resolved.

Although policies can be defined at different levels of abstraction, they are usually referred to as high-level and low-level, with the former representing business objectives and the latter device-specific configuration. Typically policies will be introduced in a policy management tool in the form of high-level business needs. Thus, a requirement of the tool would be to bridge the gap between these needs and the technology being deployed. In other words there has to be a process to refine the high-level policies and provide a low-level representation that corresponds to the configuration of each device responsible to support the business needs. The main objectives of a refinement process are the following:

  • Determine the resources that are needed to satisfy the requirements of the policy.
  • Translate high-level policies into operational policies that the system can enforce.
  • Verify that the lower level policies actually meet the requirements specified by the high-level policy.

The first of these objectives involves mapping abstract entities defined as part of a high-level policy to concrete objects/devices that make up the underlying system. The second specifies the need to ensure that any policies derived by the refinement process be in terms of operations that are supported by the underlying system. The final objective requires that a process should exist for incrementally decomposing abstract requirements into successively more concrete ones, ensuring that at each stage the decomposition is correct and consistent.

The general view is that a policy analysis process should be as automated as possible with the system providing a certain degree of reasoning ability upon which to base its decisions. For this reason, attention has been lately given to logic-based formalisms (and supported reasoning types) for the representation of policies and managed systems such as the Event Calculus.


  • author

Related Links

  • [http://]


The list of journals, conferences and technical societies related to multicast communication does not mean to be exhaustive rather it is indicative. For additions/updates please contact the webmaster.


  • [http:/]

Major Conferences

  • [http:/]

Technical Societies

  • [http:/]


  • [http:/]