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