copper:copper_work_items:policy_architecture
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
copper:copper_work_items:policy_architecture [2015/05/12 01:27] Bryan Sullivan |
copper:copper_work_items:policy_architecture [2015/05/18 06:27] (current) Bryan Sullivan |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ===== Definitions ===== | ===== Definitions ===== | ||
| + | |||
| + | The following terms are widely used in this analysis, as basic concepts. | ||
| ^ Term ^ Meaning ^ | ^ 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. | | | 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. | | | 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 ===== | ===== Architectural Concept ===== | ||
| Line 14: | Line 25: | ||
| {{:copper:copper_work_items:policy_architecture.pptx|}} | {{:copper:copper_work_items:policy_architecture.pptx|}} | ||
| + | |||
| {{ :copper:copper_work_items:policy_architecture.png?700 |}} | {{ :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 ===== | ==== Architectural Aspects ===== | ||
| Line 47: | Line 92: | ||
| * What specific policy use cases can/should fall into each overall class | * What specific policy use cases can/should fall into each overall class | ||
| * locally handled by NFVI components | * locally handled by NFVI components | ||
| - | * handled by a closed-loop policy system, either | + | * handled by a closed-loop policy system, either VNF/service-specific or VNF-independent |
| - | * VNF/service-specific | + | |
| - | * VNF-independent | + | |
| ===== Requirements ===== | ===== Requirements ===== | ||
| Line 55: | Line 98: | ||
| ==== General Requirements ==== | ==== General Requirements ==== | ||
| - | General requirements for a policy architecture are below, with an assessment of the current state of support for these across major OPNFV components (1=poor, 5=excellent). | + | General requirements for a policy architecture are below. These will be analyzed further in subsequent sections of this analysis. |
| - | ^ Requirement ^ Description ^ OpenStack ^ OpenDaylight ^ | + | ^ Requirement ^ Description ^ |
| - | | Polled monitoring. | Exposure of state via request-response APIs. | TBD | TBD | | + | | 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. | |
| - | | Notifications. | Exposure of state via pub-sub APIs. | TBD | TBD | | + | | Polled monitoring. | Exposure of state via request-response APIs. | |
| - | | Realtime/near-realtime notifications. | Notifications that occur in actual or near realtime. | TBD | TBD | | + | | Notifications. | Exposure of state via pub-sub APIs. | |
| - | | Delegated policy. | CRUD operations on policies that are distributed to specific components for local handling, including one/more of monitoring, violation reporting, and enforcement. | TBD | TBD | | + | | Realtime/near-realtime notifications. | Notifications that occur in actual or near realtime. | |
| - | | Violation reporting. | Reporting of conditions that represent a policy violation. | TBD | TBD | | + | | Delegated policy. | CRUD operations on policies that are distributed to specific components for local handling, including one/more of monitoring, violation reporting, and enforcement. | |
| - | | Reactive enforcement. | Enforcement actions taken in response to policy violation events. | TBD | TBD | | + | | Violation reporting. | Reporting of conditions that represent a policy violation. | |
| - | | Proactive enforcement. | Enforcement actions taken in advance of policy violation events, e.g. blocking actions that could result in a policy violation. | TBD | TBD | | + | | Reactive enforcement. | Enforcement actions taken in response to policy violation events. | |
| - | | Compliance auditing. | Periodic auditing of state against policies. | TBD | TBD | | + | | 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 ==== | ==== Use-Case Derived Requirements ==== | ||
| - | ^ Requirement ^ Description ^ OpenStack ^ OpenDaylight ^ | + | ^ Requirement ^ Description ^ |
| - | | Compute Affinity/Anti-affinity | Place VMs based upon compute resources. | TBD | TBD | | + | | Compute Affinity/Anti-affinity | Place VMs based upon compute resources. | |
| - | | Storage Affinity/Anti-affinity | Place VMs based upon storage resources. | TBD | TBD | | + | | Storage Affinity/Anti-affinity | Place VMs based upon storage resources. | |
| - | | Network Affinity/Anti-affinity | Place VMs based upon network resources. | TBD | TBD | | + | | Network Affinity/Anti-affinity | Place VMs based upon network resources. | |
| - | | SDN Controller engineering rules | Apply engineering rule based policies via SDNCs. | TBD | TBD | | + | | SDN Controller engineering rules | Apply engineering rule based policies via SDNCs. | |
| - | | SDN Controller security policies| Apply security policies via SDNCs. | TBD | TBD | | + | | SDN Controller security policies| Apply security policies via SDNCs. | |
| - | | High Availability | Distribute VMs across diverse resources. | TBD | TBD | | + | | High Availability | Distribute VMs across diverse resources. | |
| - | | Geo-Diversity | Distribute VMs across geographically diverse resources. | TBD | TBD | | + | | 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. | TBD | TBD | | + | | 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. | TBD | TBD | | + | | 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 ==== | ||
| + | |||
copper/copper_work_items/policy_architecture.1431394030.txt.gz · Last modified: 2015/05/12 01:27 by Bryan Sullivan
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
