Noemi Wagner | c729db8 | 2019-03-07 13:55:42 +0100 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution |
| 2 | .. 4.0 International License. |
| 3 | .. http://creativecommons.org/licenses/by/4.0 |
| 4 | .. Copyright 2019 Nokia; Copyright 2017-2018 Huawei Technologies Co., Ltd.; Copyright 2017 AT&T Intellectual Property. |
| 5 | |
| 6 | Open Network Automation Platform Overview |
| 7 | ========================================= |
| 8 | |
| 9 | The Open Network Automation Platform (ONAP) project addresses the |
| 10 | rising need for a **common automation platform for telecommunication, cable, |
| 11 | and cloud service providers**—and their solution providers— that enables the |
| 12 | **automation of different lifecycle processes**, to deliver differentiated |
| 13 | network services on demand, profitably and competitively, while leveraging |
| 14 | existing investments. |
| 15 | |
| 16 | Prior to ONAP, telecommunication network operators had to keep up with the |
| 17 | scale and cost of manual changes required to implement new service offerings, |
| 18 | from installing new data center equipment to, in some cases, upgrading |
| 19 | customer equipment on-premises. Many operators are seeking to exploit |
| 20 | Software Defined Network (SDN) and Network Function Virtualization (NFV) |
| 21 | to improve service velocity, simplify equipment interoperability and |
| 22 | integration, and reduce overall CapEx and OpEx costs. In addition, the |
| 23 | current, highly fragmented management landscape makes it difficult to |
| 24 | monitor and guarantee service-level agreements (SLAs). |
| 25 | |
| 26 | ONAP is addressing these challenges by developing global and massive |
| 27 | scale (multi-site and multi-Virtual Infrastructure Manager (VIM)) |
| 28 | automation capabilities for both physical and virtual network elements. |
| 29 | It facilitates service agility by supporting data models for rapid |
| 30 | service and resource deployment, by providing a common set of Northbound |
| 31 | REST APIs that are open and interoperable, and by supporting model |
| 32 | driven interfaces to the networks. ONAP’s modular and layered nature |
| 33 | improves interoperability and simplifies integration, allowing it to |
| 34 | support multiple VNF environments by integrating with multiple VIMs, |
| 35 | virtualized network function managers (VNFMs), SDN Controllers, and |
| 36 | even legacy equipment. ONAP’s consolidated VNF requirements enable |
| 37 | commercial development of ONAP-compliant VNFs. This approach allows |
| 38 | network and cloud operators to optimize their physical and virtual |
| 39 | infrastructure for cost and performance; at the same time, ONAP’s |
| 40 | use of standard models reduces integration and deployment costs of |
| 41 | heterogeneous equipment, while minimizing management fragmentation. |
| 42 | |
| 43 | Scope of ONAP |
| 44 | ------------- |
| 45 | |
| 46 | ONAP enables end user organizations and their network or cloud providers |
| 47 | to collaboratively instantiate network elements and services in a dynamic, |
| 48 | closed control loop process, with real-time response to actionable events. |
| 49 | |
| 50 | ONAP’s major activities, that is designing, deploying and operating |
| 51 | services, are provided based on ONAP’s two major frameworks, namely on |
| 52 | Design-time framework and Run-time framework: |
| 53 | |
| 54 | .. image:: media/ONAP_main_functions.png |
| 55 | :scale: 40 % |
| 56 | |
| 57 | In order to design, deploy and operate services and assure these dynamic |
| 58 | services, ONAP activities are built up as follows: |
| 59 | |
| 60 | * **Service design** – Service design is built on a robust design framework that |
| 61 | allows specification of the service in all aspects – modeling the resources and |
| 62 | relationships that make up the service, specifying the policy rules that guide |
| 63 | the service behavior, specifying the applications, analytics and closed control |
| 64 | loop events needed for the elastic management of the service. |
| 65 | * **Service deployment** – Service deployment is built on an orchestration |
| 66 | and control framework that is policy-driven (Service Orchestrator and |
| 67 | Controllers) to provide automated instantiation of the service when |
| 68 | needed and managing service demands in an elastic manner. |
| 69 | * **Service operations** – Service operations are built on an analytic |
| 70 | framework that closely monitors the service behavior during the service |
| 71 | lifecycle based on the specified design, analytics and policies to enable |
| 72 | response as required from the control framework, to deal with situations |
| 73 | ranging from those that require healing to those that require scaling |
| 74 | of the resources to elastically adjust to demand variations. |
| 75 | |
| 76 | ONAP enables product- or service-independent capabilities for design, |
| 77 | deployment and operation, in accordance with the following foundational |
| 78 | principles: |
| 79 | |
| 80 | 1. Ability to dynamically introduce full service lifecycle orchestration |
| 81 | (design, provisioning and operation) and service API for new services |
| 82 | and technologies without the need for new platform software releases |
| 83 | or without affecting operations for the existing services |
| 84 | |
| 85 | 2. Carrier-grade scalability including horizontal scaling (linear scale-out) |
| 86 | and distribution to support large number of services and large networks |
| 87 | |
| 88 | 3. Metadata-driven and policy-driven architecture to ensure flexible and |
| 89 | automated ways in which capabilities are used and delivered |
| 90 | |
| 91 | 4. The architecture shall enable sourcing best-in-class components |
| 92 | |
| 93 | 5. Common capabilities are ‘developed’ once and ‘used’ many times |
| 94 | |
| 95 | 6. Core capabilities shall support many diverse services and infrastructures |
| 96 | |
| 97 | 7. The architecture shall support elastic scaling as needs grow or shrink |
| 98 | |
| 99 | Functional overview of ONAP |
| 100 | =========================== |
| 101 | |
| 102 | The following guidelines show the main ONAP activities in a chronological order, presenting ONAP's functional structure: |
| 103 | |
| 104 | 1. **Service design** - ONAP supports Service Design operations, using the TOSCA approach. |
| 105 | These service design activities are built up of the following subtasks: |
| 106 | a. Planning VNF onboarding – checking which VNFs will be necessary for the required environment and features |
| 107 | b. Creating resources, composing services |
| 108 | c. Distributing services - Distributing services constitutes of 2 subtasks: |
| 109 | * TOSCA C-SAR package is stored in the Catalog |
| 110 | * new service notification is published |
| 111 | |
| 112 | 2. **Service orchestration and deployment** |
| 113 | a. Defining which VNFs are necessary for the service |
| 114 | b. Defining orchestration steps |
| 115 | c. Selecting valid cloud region |
| 116 | d. Service orchestration calling cloud APIs to deploy VNFs |
| 117 | * The onboarding and instantiation of VNFs in ONAP is represented via |
| 118 | the example of onboarding and instantiating a virtual network function |
| 119 | (VNF), the virtual Firewall (vFirewall). Following the guidelines and |
| 120 | steps of this example, any other VNF can be similarly onboarded |
| 121 | and instantiated to ONAP. See :ref:`virtual Firewall Onboarding and |
| 122 | Instantiating <vfirewall_usecase>` examples. |
| 123 | e. Controllers applying configuration on VNFs |
| 124 | 3. **Service operations** |
| 125 | a. Closed Loop design and deployment |
| 126 | b. Collecting and evaluating event data |
| 127 | |
| 128 | Benefits of ONAP |
| 129 | ================ |
| 130 | |
| 131 | Open Network Automation Platform provides the following benefits: |
| 132 | |
| 133 | * common automation platform, which enables common management of services and |
| 134 | connectivity, while the applications run separately |
| 135 | * a unified operating framework for vendor-agnostic, policy-driven service |
| 136 | design, implementation, analytics and lifecycle management for |
| 137 | large-scale workloads and services |
| 138 | * orchestration for both virtual and physical network functions |
| 139 | * ONAP offers Service or VNF Configuration capability, in contrast to other |
| 140 | open-source orchestration platforms |
| 141 | * the model-driven approach enables ONAP to support services, that are using |
| 142 | different VNFs, as a common service block |
| 143 | * service modelling enables operators to use the same deployment and management |
| 144 | mechanisms, beside also using the same platform |
| 145 | |
| 146 | ONAP Release information |
| 147 | ======================== |
| 148 | |
| 149 | ONAP is enhanced with numerous features from release to release. Each release |
| 150 | is named after a city. |
| 151 | |
| 152 | +----------------------+----------------+----------------------+-----------------------------------------------------------+ |
| 153 | |Release Name |Release version |Release Date |Features delivered | |
| 154 | +======================+================+======================+===========================================================+ |
Noemi Wagner | 01fab8e | 2019-05-30 13:55:09 +0200 | [diff] [blame] | 155 | |Dublin |4.0.0 |2019 | :ref:`Dublin Release Notes <dublinrelease-notes>` | |
| 156 | +----------------------+----------------+----------------------+-----------------------------------------------------------+ |
| 157 | |Casablanca |* 3.0.2 |* 31 January 2019 | | |
Noemi Wagner | c729db8 | 2019-03-07 13:55:42 +0100 | [diff] [blame] | 158 | | |* 3.0.1 |* 30 November 2018 | | |
| 159 | | |* 3.0.0 |* 15 April 2019 | | |
| 160 | +----------------------+----------------+----------------------+-----------------------------------------------------------+ |
| 161 | |Beijing |2.0.0 |7 June 2018 | + |
| 162 | +----------------------+----------------+----------------------+-----------------------------------------------------------+ |
| 163 | |Amsterdam |1.0.0 |16 November 2017 | + |
| 164 | +----------------------+----------------+----------------------+-----------------------------------------------------------+ |
| 165 | |
| 166 | ONAP Blueprints and environments |
| 167 | ================================ |
| 168 | |
| 169 | ONAP is able to deploy and operate VNFs running OpenStack based Centralized Private Cloud Instances, as well as Mobile Edge Cloud instances. |
| 170 | ONAP has been tested in the following network environments: |
| 171 | |
| 172 | * Voice Over LTE (VoLTE) |
| 173 | * Customer Premise Equipment (CPE) |
| 174 | * 5G |
| 175 | * Cross Domain and Cross Layer VPN (CCVPN) |
| 176 | * Broadband Service (BBS) |
| 177 | |
| 178 | Licenses |
| 179 | ======== |
| 180 | |
| 181 | Open Network Automation Platform (ONAP) is an open source project hosted by the Linux Foundation. |
| 182 | |
| 183 | ONAP Source Code is licensed under the `Apache Version 2 License <http://www.apache.org/licenses/LICENSE-2.0>`_. |
| 184 | ONAP Documentation is licensed under the `Creative Commons Attribution 4.0 |
| 185 | International License <http://creativecommons.org/licenses/by/4.0>`_. |