diff options
Diffstat (limited to 'docs/development/design/architecture.rst')
-rw-r--r-- | docs/development/design/architecture.rst | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/docs/development/design/architecture.rst b/docs/development/design/architecture.rst new file mode 100644 index 0000000..02d8335 --- /dev/null +++ b/docs/development/design/architecture.rst @@ -0,0 +1,100 @@ +.. This work is licensed under a +.. Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) 2015-2017 AT&T Intellectual Property, Inc + +Architecture +============ + +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. + +.. image:: ./images/policy_architecture.png + :width: 700 px + :alt: policy_architecture.png + :align: center + +(source of the diagram above: +https://git.opnfv.org/cgit/copper/plain/design_docs/images/policy_architecture.pptx) + +Architectural Aspects +--------------------- + * Policies are reflected in two high-level goals + + * Ensure resource requirements of VNFs and services 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) + + * 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 |