This is an old revision of the document!
This page will capture issues to be addressed in the overall architecture of OPNFV components.
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 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.
Issues to be investigated as part of establishing an overall cohesive/adaptive policy architecture:
* VNF/service-specific
* VNF-independent
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).
Requirement | Description | OpenStack | OpenDaylight |
---|---|---|---|
Polled monitoring. | Exposure of state via request-response APIs. | TBD | TBD |
Notifications. | Exposure of state via pub-sub APIs. | TBD | TBD |
Realtime/near-realtime notifications. | Notifications that occur in actual or near realtime. | 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. | TBD | TBD |
Violation reporting. | Reporting of conditions that represent a policy violation. | TBD | TBD |
Reactive enforcement. | Enforcement actions taken in response to policy violation events. | TBD | TBD |
Proactive enforcement. | Enforcement actions taken in advance of policy violation events, e.g. blocking actions that could result in a policy violation. | TBD | TBD |
Compliance auditing. | Periodic auditing of state against policies. | TBD | TBD |
Requirement | Description | OpenStack | OpenDaylight |
---|---|---|---|
Compute Affinity/Anti-affinity | Place VMs based upon compute resources. | TBD | TBD |
Storage Affinity/Anti-affinity | Place VMs based upon storage resources. | TBD | TBD |
Network Affinity/Anti-affinity | Place VMs based upon network resources. | TBD | TBD |
SDN Controller engineering rules | Apply engineering rule based policies via SDNCs. | TBD | TBD |
SDN Controller security policies | Apply security policies via SDNCs. | TBD | TBD |
High Availability | Distribute VMs across diverse resources. | TBD | TBD |
Geo-Diversity | Distribute VMs across geographically diverse resources. | TBD | TBD |
Group-Based Policy | Constrain configuration actions based upon association of specific state data to groups, e.g. ownership, 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. | TBD | TBD |