Policy Unification and Organization

Because the policy framework is expandable and multipurpose, it might contain many types of policies, which users might want to organize according to some useful dimensions.  Users can define attributes that specify the scope of policies, and these attributes can be extended to the policy-enabled functions and components. Useful policy organizing dimensions might include:

• Policy type or category (taxonomical)
• Policy ownership or administrative domain
• Geographic area or location, 
• Technology type  
• Policy language and version 
• Security level or other security-related values, specifiers, or limiters

Attributes can be specified for each dimension. In addition to being defined for individual policies themselves, these attributes can be used to define the scope of these additional additional policy-related functions:

• Policy events or requests/triggers 
• Policy decision, enforcement, or other functions 
• Virtual functions of any type 

Policy-writers can define attributes so that policy events or requests self-indicate their scope. The scope is then examined by a suitable function and subsequently acted upon accordingly. Policy decisions and enforcement functions can self-indicate their scope of decision-making, enforcement, or other capabilities. Virtual functions can be automatically attached to the appropriate Policy Framework and distribution mechanisms.

Policy Use

At runtime, policies that were previously distributed to policy-enabled components are used by those components to control or influence their functionality and behavior, including any actions that are taken. In many cases, those policies will be used to make decisions, where these decisions will often be conditional upon the current situation. A major An example of this approach is the feedback/control loop pattern that is driven by DCAE. Many specific control loops can be defined. In a particular control loop, each participant (for example, orchestrator, controller, DCAE, virtual function) will receive policies that determine how it should act as part of that loop. All of the policies for that loop will have been previously created together, ensuring correct and coordinated closed-loop action. DCAE can receive specific policies for data collection (for example, what data to collect, how to collect, and how often), data analysis (for example, what type and depth of analysis to perform), and signature and event publishing (for example., 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 (such as orchestrators and controllers) can receive specific policies that determining the actions to take upon receiving the triggered event from DCAE. Each component in the loop participant could can also receive policies determining that specify the specific events to which it the component subscribes.

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.

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.