This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 Building a Policy-Based Management System
The reader must have noticed from the description of the various aspects of policy-based management for different scenarios that there are many similarities in the design of the underlying capabilities. In this section, we present the architecture of a generic policy-based management system and describe the functions needed to build it.
We start as a reference point with what is usually called the IETF/DMTF Policy Architecture. The IETF/DMTF Policy Architecture is found in many Request for Comments (RFCs) published regarding the use of policies in computer communication networks. (See the sidebar titled “IETF and DMTF” for more details.) Despite being cited as the IETF Policy Architecture or the DMTF Policy Architecture, it is worth pointing out that neither of the two organizations has actually standardized policy architectures. Thus, the architecture is not a standard formally defined by either the IETF or the DMTF. It is more akin to a folk architecture that is usually ascribed to the IETF and/or DMTF.
The reason the folk architecture is cited so frequently in academic circles is that it captures the driving principles behind the derivation and definition of many of the standard RFCs and drafts submitted to the IETF that deal with policies. Thus, even though this architecture is not put out in any of the official documents from the two organizations, it represents the guiding principles behind much of the standards work, and it is appropriate to refer to it as the IETF/DMTF architecture.
This policy architecture consists of four components as shown in Figure 1.1: a policy management tool, a policy repository, a policy decision point (PDP), and a policy enforcement point (PEP). The policy management tool provides a user interface for the creation and definition of policies. The policy repository provides mechanisms for storing policies and retrieving them as needed by the decision points. The policy decision points are modules in the system responsible for making policy decisions—that is, they examine the policies stored in the repository that would be applicable under a given circumstance and determine what needs to be done to comply with those policies. Policy enforcement points are elements that are responsible for enforcing the outcome of those policy decisions.
)
Figure 1.1 The IETF/DMTF Policy Architecture
Although the formal definition of policies, their types and usage, and the bare-bones IETF/DMTF policy architecture just described captures basic concepts used in all policy-based management systems for self-management, they hardly convey the complexity faced in implementing a PBMS. When building a PBMS, an architect needs to make several decisions regarding policy lifecycle: when and where policies are created, modified, and transformed from higher levels of abstraction to lower levels of abstraction; how they are stored, distributed, and enforced in a possibly geographically dispersed system; and finally, when a policy becomes obsolete, how it is retracted throughout a system without disrupting the system operation. Another aspect of this complexity comes from possibly conflicting policies in a system that need to be resolved. Conflicts arise often in a PBMS because there are often multiple policy authors responsible for managing different operating behaviors (self-healing policy versus self-protection policy) of the system. Conflicts can arise during definition time or at run-time and they need to be resolved to make a decision.
In the following chapters, we will cover some of these implementation issues of a PBMS in more detail.