The Policy Creation component of OpenECOMP provides a centralized environment for the creation and management of easily-updatable conditional rules. This subsystem enables users to validate policies and rules, identify and resolve overlaps and conflicts, and derive additional policies where needed. Policies can support infrastructure, products and services, operation automation, and security. Users, who can be a variety of stakeholders such as network and service designers, operations engineers, and security experts, can easily create or change policy rules from the OpenECOMP Portal.
Policies are used to control, to influence, and to help ensure compliance with goals. A policy can be defined at a high level to create a condition, requirement, constraint, or need that must be provided, maintained, and enforced. A policy can also be defined at a lower or functional level, such as a machine-readable rule or software condition/assertion which enables actions to be taken based on a trigger or request, specific to particular selected conditions in effect at that time. Software policies that are supported include XACML policies, Drools policies, and lower level policies that are embodied in modeling languages such as YANG and TOSCA.
The Policy Creation subsystem also provides additional functionality once policies are initially created:
- Offline analysis of performance, fault, and closed-loop actions, enabling the discovery of new and signatures and refinement of existing ones
- Derivation of lower-level policies from higher-level policies
- Identification of conflicts and mitigation of them before deployment
Once validated and corrected for any conflicts, the policies are placed in an appropriate repository, and are made available to the other subsystems and components that might make use of them. In addition, the decisions and actions taken by the policy are distributed. Distribution occurs either in conjunction with the distribution of recipes (if for example they are related to service instantiation) or independently, if the policy is unrelated to a particular service. With this methodology, policies will already be available when needed by a component, minimizing real-time requests to a central policy engine or PDP (Policy Decision Point). This improves scalability and reduces latency.
************
Policy Distribution
After a policy has been initially created or an existing policy has been modified, the Policy Distribution Framework sends the policy from the repository to its points of use, before it is actually needed. This distribution is precisely targeted so that each distributed policy-enabled function automatically receives only the specific policies that match its needs and scope.
Separate notifications or events communicate the link or URL for a policy to the components that need it. Then, when a component needs the policy, it uses the link to fetch it. Components in some cases might also publish events indicating that they need new policies, eliciting a response with updated links or URLs. Also, in some cases, policies can indicate to components that they should subscribe to one or more policies, so that they receive automatic updates to those policies as they become available.
Policy Decision and Enforcement
Runtime policy decision and enforcement functionality is a distributed system that can apply to the various ECOMP modules in most cases (there could be some exceptions). For example, Policy rules for data collection and their frequency are enforced by DCAE data collection functionality. Analytic policy rules, anomalous / abnormal condition identification, and publication of events signaling detection of such conditions are enforced by DCAE Analytic applications. Policy rules for associated remedial or other action (e.g., further diagnosis) are enforced by the right actor/participant in a control loop (MSO, Controller, DCAE, etc.).
Figure 9 shows Policy Creation on the left, Policy Repository & Distribution at the bottom, and Policy use on the right (e.g., in Control Loops, or in VNFs). As shown in Figure 9, Policy Creation is in close association with ASDC. When fully integrated, policies will be created either in conjunction with Products &
Services (for policy scopes that are related to these), or separately for policies of scopes orthogonal to these (i.e., unrelated to particular products & services). Orthogonal policies may include various policies for operations, security, infrastructure optimization, etc.
Note that the architecture shown is a logical architecture, and may be implemented in various ways. Some functions in whole or in part may be implemented either as separate virtualized elements or within other (non-policy) functions.
7.4 Policy Unification and Organization
In an expandable, multi-purpose Policy Framework, many types of Policy may be used. Policy may be organized using many convenient dimensions in order to facilitate the workings of the Framework within D2.0. A flexible organizing principle termed Policy Scope will enable a set of attributes to specify (to the degree/precision desired, and using any set of desired
“dimensions”) the precise “scope” of both policies and policy-enabled functions/components. Useful organizing dimensions of Policy Scope may include:
(a) Policy type or category, e.g., taxonomical, (b) Policy ownership / administrative domain, (c) geographic area or location, (d) technology type and/or specifics, (e) Policy language, version, etc., (f) security level or other security-related values/specifiers/limiters, (g) particular defined grouping, and (h) any other dimensions/attributes as may be deemed helpful, e.g., by Operations. Note that attributes can be defined for each dimension.
7.6 Policy Use
At runtime, policies that were previously distributed to policy-enabled components will be used by those components to control or influence their functionality and behavior, including any actions that are taken. In
16
By then setting values for these attributes, Policy Scope can be used to specify the precise Policy
“scope” of: (A) Policy events or requests/triggers to allow each event/request to self-indicate its scope, e.g., which can then be examined by a suitable function for specifics of routing/delivery, (B) Policy decision/enforcement functions or other Policy functions to allow each Policy function to self-indicate its scope of decision making, enforcement, or other capabilities, (C) Virtual Functions of any type for auto-attachment to the appropriate Policy Framework and distribution mechanism instances, and most importantly to (D) individual policies to aid in management and distribution of the policies.
7.5 Policy Technologies
D2 Policy will utilize rather than replace various technologies; examples of possible policy areas are shown in the following table. These will be used, e.g., via translation capabilities, to achieve the best possible solution that takes advantage of helpful technologies while still providing in effect a single
D2.0 Policy “brain.”
many cases, those policies will be utilized to make decisions, where these decisions will often be conditional upon the current situation.
A major example of this approach is the feedback/control loop pattern driven by DCAE. Many
specific control loops can be defined. In a particular control loop, each participant (e.g., orchestrator, controller, DCAE, virtual function) will have received policies determining how it should act as part of that loop. All of the policies for that loop will have been previously created together, ensuring proper coordinated closed-loop action. DCAE can receive specific policies for data collection (e.g., what data to collect, how to collect, and how often), data analysis (e.g., what type and depth of analysis to perform), and signature and event publishing (e.g., what analysis results to look for as well as the specifics of the event to be published upon detecting those results). Remaining components of the loop (e.g., orchestrators, controllers, etc.) can receive specific policies determining actions to be taken upon receiving the triggered event from DCAE. Each loop participant could also receive policies determining the specific events to which it subscribes.