...
Policy Decision and Enforcement
Runtime Run-time 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)is done by the other applicable OpenECOMP subsystems. For example, Policy policy rules for data collection and their frequency are enforced by DCAE the data collection functionality of DCAE. Analytic policy rules, identification of anomalous / or abnormal condition identificationconditions, and publication of events signaling detection of such conditions are enforced by DCAE Analytic analytic applications. Policy rules for associated remedial or other action (e.g., further diagnosis) actions, or for further diagnostics, are enforced by the right actor/participant correct component in a control loop (such as the MSO, a Controller, or 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.
...
Service & Design Creation (SDC).
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
...