Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Policy Architecture ======

This page will capture issues to be addressed in the overall architecture of OPNFV components.

===== Definitions =====

The following terms are widely used in this analysis, as basic concepts.

^ Term ^ Meaning ^
| State | Information that can be used to convey or imply the state of something, e.g. an application, resource, entity, etc. This can include data held inside OPNFV components, "events" that have occurred (e.g. "policy violation"), etc. |
| Event | An item of significance to the policy engine, for which the engine has become aware through some method of discovery e.g. polling or notification. |

The following terms are borrowed from the [[http://en.wikipedia.org/wiki/XACML|XACML standard]]. While defined by XACML largely for [[http://en.wikipedia.org/wiki/Role-based_access_control|Role-Based Access Control]] purposes, these terms are used here for analogous ways for broader policy purposes.

^ Term ^ Meaning as used here ^
| Policy Administration Point (PAP) | An entity that defines/distributes/manages policies. |
| Policy Information Point (PIP) | An entity that acts as a source of policy-related events and state or additional contextual information necessary for policy decisions. |
| Policy Decision Point (PDP) | An entity that determines what response if any is needed to an event. |
| Policy Execution Point (PEP) | An entity that takes actions as determined by a PDP. |
| Policy Retrieval Point (PRP) | An entity that hosts policies. In general, this analysis assumes the PDP acts as PDP. | 

===== Architectural Concept =====

The following example diagram illustrates a "relationship diagram" type view of an NFVI platform, in which the roles of components focused on policy management, services, and infrastructure are shown. This view illustrates that a large-scale deployment of NFVI may leverage multiple components of the same "type" (e.g. SDN Controller), which fulfill specific purposes for which they are optimized. For example, a global SDN controller and cloud orchestrator can act as directed by a service orchestrator in the provisioning of VNFs per intent, while various components at a local and global level handle policy-related events directly and/or feed them back through a closed-loop policy design that responds as needed, directly or through the service orchestrator.

{{:copper:copper_work_items:policy_architecture.pptx|}}

{{ :copper:copper_work_items:policy_architecture.png?700 |}}

As defined above, here is an overview of the policy-related roles of the entities in the diagram above.

  * Service Design
    * PAP: defines generic and VNF/service-specific policies. Generic policies are administered at PRP/PDP entities and invoked for specific VNFs/services as needed through identifiers associated with resources managed by the entity. VNF-specific policies are administered for VNFs through the VNF package metadata. Service-specific policies are administered through service-specific metadata.
  * Policy Management / Distribution 
    * PAP: Administers generic policies into PRP entities through the APIs exposed by those entities. Establishes subscription to events where closed-loop handling is needed.\n
    * PRP: Hosts policies applied to closed-loop events as needed.
    * PIP: Forwards events to Service Orchestrators as needed (defined in policy rules or via Service Orchestrator subscription). 
    * PDP/PEP: Applies policy rules for generic policy events.
  * Service Orchestrator
    * PAP: Administers VNF/service-specific policies into PRP entities through the APIs exposed by those entities. Establishes subscription to events where closed-loop handling is needed. 
    * PIP: Applies service context information to closed-loop policy decisions.
    * PRP: Hosts service-specific policies applied to closed-loop events as needed.
    * PDP/PEP: Applies policy rules for service-specific policy events.
  * Cloud Orchestrator
    * PAP: Administers VNF/resource-specific policies into PRP entities through the APIs exposed by those entities. Establishes subscription to events where closed-loop handling is needed.
    * PIP: Forwards events to Service Orchestrators as needed (defined in policy rules or via Service Orchestrator subscription). 
    * PRP: Hosts generic and VNF-specific policies which are locally applied or invoke events to closed-loop systems.
    * PDP/PEP: Applies policy rules for generic and VNF-specific policy events.
  * Global Controller
    * PAP: Administers VNF/resource-specific policies into PRP entities through the APIs exposed by those entities. Establishes subscription to events where closed-loop handling is needed.
    * PIP: Forwards events to Service Orchestrators as needed (defined in policy rules or via Service Orchestrator subscription). 
    * PRP: Hosts generic and VNF-specific policies which are locally applied or invoke events to closed-loop systems.
    * PDP/PEP: Applies policy rules for generic and VNF-specific policy events.
  * Local Controller
    * PIP: Forwards events for closed-loop policy handling as needed (defined in policy rules or via closed-loop policy subscription). 
    * PRP: Hosts generic and VNF/resource-specific policies which are locally applied or invoke events to closed-loop systems.
    * PDP/PEP: Applies policy rules for generic and VNF/resource-specific policy events.
  * Nodal Controller
    * PIP: Forwards events for closed-loop policy handling as needed (defined in policy rules or via closed-loop policy subscription). 
    * PRP: Hosts generic and VNF/resource-specific policies which are locally applied or invoke events to closed-loop systems.
    * PDP/PEP: Applies policy rules for generic and VNF/resource-specific policy events.

==== Architectural Aspects =====

  * Policies are reflected in two high-level goals
    * Ensure resource requirements of VNFs are applied per VNF designer, service, and tenant intent
    * Ensure that generic policies are not violated, e.g. //networks connected to VMs must either be public or owned by the VM owner//
  * Policies are distributed through two main means
    * As part of VNF packages, customized if needed by Service Design tools, expressing intent of the VNF designer and service provider, and possibly customized or supplemented by service orchestrators per the intent of specific tenants
    * As generic policies provisioned into VIMs (SDN controllers and cloud orchestrators), expressing intent of the service provider re what states/events need to be policy-governed independently of specific VNFs
  * Policies are applied locally and in closed-loop systems per the capabilities of the local policy enforcer and the impact of the related state/event conditions
    * VIMs should be able to execute most policies locally
    * VIMs may need to pass policy-related state/events to a closed-loop system, where those events are relevant to other components in the architecture (e.g. service orchestrator), or some additional data/arbitration is needed to resolve the state/event condition
  * Policies are localized as they are distributed/delegated
    * High-level policies (e.g. expressing “intent”) can be translated into VNF package elements or generic policies, perhaps using distinct syntaxes
    * Delegated policy syntaxes are likely VIM-specific, e.g. Datalog (Congress), YANG (ODL-based SDNC), or other schemas specific to other SDNCs (Contrail, ONOS)
  * Closed-loop policy and VNF-lifecycle event handling are //somewhat// distinct
    * Closed-loop policy is mostly about resolving conditions that can't be handled locally, but as above in some cases the conditions may be of relevance and either delivered directly or forwarded to service orchestrators
    * VNF-lifecycle events that can't be handled by the VIM locally are delivered directly to the service orchestrator
  * Some events/analytics need to be collected into a more "open-loop" system which can enable other actions, e.g.
    * audits and manual interventions
	* machine-learning focused optimizations of policies (largely a future objective)
	
Issues to be investigated as part of establishing an overall cohesive/adaptive policy architecture:

  * For the various components which may fulfill a specific purpose, what capabilities (e.g. APIs) do they have/need to
    * handle events locally
	* enable closed-loop policy handling components to subscribe/optimize policy-related events that are of interest
  * For global controllers and cloud orchestrators
    * How do they support correlation of events impacting resources in different scopes (network and cloud)
	* What event/response flows apply to various policy use cases
  * What specific policy use cases can/should fall into each overall class
    * locally handled by NFVI components
	* handled by a closed-loop policy system, either VNF/service-specific or VNF-independent
	
===== Requirements =====

==== General Requirements ====

General requirements for a policy architecture are below. These will be analyzed further in subsequent sections of this analysis.

^ Requirement ^ Description ^
| Intent expression. | Specification of what a VNF designer, service, user, etc require per the deployment and lifecycle event handling for a VNF or VNF-enabled service. |
| Polled monitoring. | Exposure of state via request-response APIs. |
| Notifications. | Exposure of state via pub-sub APIs. |
| Realtime/near-realtime notifications. | Notifications that occur in actual or near realtime. |
| Delegated policy. | CRUD operations on policies that are distributed to specific components for local handling, including one/more of monitoring, violation reporting, and enforcement. |
| Violation reporting. | Reporting of conditions that represent a policy violation. |
| Reactive enforcement. | Enforcement actions taken in response to policy violation events. |
| Proactive enforcement. | Enforcement actions taken in advance of policy violation events, e.g. blocking actions that could result in a policy violation. |
| Compliance auditing. | Periodic auditing of state against policies. |

==== Use-Case Derived Requirements ====

^ Requirement ^ Description ^
| Compute Affinity/Anti-affinity | Place VMs based upon compute resources. |
| Storage Affinity/Anti-affinity | Place VMs based upon storage resources. |
| Network Affinity/Anti-affinity | Place VMs based upon network resources. |
| SDN Controller engineering rules | Apply engineering rule based policies via SDNCs. |
| SDN Controller security policies| Apply security policies via SDNCs. |
| High Availability | Distribute VMs across diverse resources. |
| Geo-Diversity | Distribute VMs across geographically diverse resources. |
| Group-Based Policy | Constrain configuration actions based upon association of specific state data to groups, e.g. ownership, group membership, etc.  |
| Role-Based Access Control | Constrain configuration actions based upon role of the configuration change requester, e.g. owner, group membership, etc.  |

===== Architecture Analysis for High-Level Requirements =====

The analysis below is based upon these basic architectural goals:

^ Goal ^ Description ^
| Localized enforcement. | Policies are expressed in terms native to an infrastructure manager and enforced locally where possible and desired. |
| Closed-loop enforcement. | Where necessary/desired, policy is enforced through closed-loop methods in which the policy-related event originator (PIP) publishes events per subscriptions or administered defaults for event reporting. | 
| Minimum policy translations. | Policies have be translated the least number of times possible before they are administered at a PRP/PDP. | 

The following sections are placeholders for analysis.

==== Intent Expression ====

==== Polled monitoring ==== 

==== Notifications ====

==== Realtime/near-realtime notifications ==== 

==== Delegated policy ==== 

==== Violation reporting ==== 

==== Reactive enforcement ==== 

==== Proactive enforcement ==== 

==== Compliance auditing ====
Wiki

User Tools

Site Tools

Page Tools
