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 2017-2018 Huawei Technologies Co., Ltd.
9 The ONAP project addresses a rising need for a common platform for
10 telecommunication, cable, and cloud operators—and their solution
11 providers—to deliver differentiated network services on demand,
12 profitably and competitively, while leveraging existing investments.
14 Prior to ONAP, operators of large networks have been challenged to keep
15 up with the scale and cost of manual changes required to implement new
16 service offerings, from installing new data center equipment to, in some
17 cases, upgrading on-premises customer equipment. Many are seeking to
18 exploit SDN and NFV to improve service velocity, simplify equipment
19 interoperability and integration, and reduce overall CapEx and OpEx
20 costs. In addition, the current, highly fragmented management landscape
21 makes it difficult to monitor and guarantee service-level agreements
24 ONAP is addressing these problems by developing global and massive scale
25 (multi-site and multi-VIM) orchestration capabilities for both physical
26 and virtual network elements. It facilitates service agility by
27 providing a common set of Northbound REST APIs that are open and
28 interoperable, and by supporting YANG and TOSCA data models. ONAP’s
29 modular and layered nature improves interoperability and simplifies
30 integration, allowing it to support multiple VNF environments by
31 integrating with multiple VIMs, VNFMs, SDN Controllers, and even legacy
32 equipment. This approach allows network and cloud operators to optimize
33 their physical and virtual infrastructure for cost and performance; at
34 the same time, ONAP’s use of standard models reduces integration and
35 deployment costs of heterogeneous equipment, while minimizing management
36 fragmentation. ONAP exists to instantiate and operate VNFs. Typical
37 operator networks are expected to support multiple instances of hundreds
38 of different types of VNFs. ONAP’s consolidated VNF requirements
39 publication is a significant deliverable to enable commercial
40 development of ONAP-compliant VNFs.
42 The ONAP platform allows end user organizations and their network/cloud
43 providers to collaboratively instantiate network elements and services
44 in a dynamic, closed-loop process, with real-time response to actionable
45 events. In order to design, engineer, plan, bill and assure these
46 dynamic services, there are three major requirements:
48 - A robust design framework that allows specification of the service in
49 all aspects – modeling the resources and relationships that make up
50 the service, specifying the policy rules that guide the service
51 behavior, specifying the applications, analytics and closed-loop
52 events needed for the elastic management of the service.
54 - An orchestration and control framework (Service Orchestrator and
55 Controllers) that is recipe/policy-driven to provide automated
56 instantiation of the service when needed and managing service demands
59 - An analytic framework that closely monitors the service behavior
60 during the service lifecycle based on the specified design, analytics
61 and policies to enable response as required from the control framework,
62 to deal with situations ranging from those that require healing to those
63 that require scaling of the resources to elastically adjust to demand
66 To achieve this, ONAP decouples the details of specific services and
67 technologies from the common information models, core orchestration
68 platform and generic management engines (for discovery, provisioning,
69 assurance etc). Furthermore, it marries the speed and style of a
70 DevOps/NetOps approach with the formal models and processes operators
71 require to introduce new services and technologies. It leverages
72 cloud-native technologies including Kubernetes to manage and rapidly
73 deploy the ONAP platform and related components. This is in stark
74 contrast to traditional OSS/Management software platform architectures,
75 which hardcoded services and technologies, and required lengthy software
76 development and integration cycles to incorporate changes.
78 The ONAP Platform enables product/service independent capabilities for
79 design, creation and lifecycle management, in accordance with the
80 following foundational principles:
82 - Ability to dynamically introduce full service lifecycle orchestration
83 (design, provisioning and operation) and service API for new services
84 & technologies without the need for new platform software releases or
85 without affecting operations for the existing services.
87 - Carrier-grade scalability including horizontal scaling (linear
88 scale-out) and distribution to support large number of services and
91 - Metadata-driven and policy-driven architecture to ensure flexible and
92 automated ways in which capabilities are used and delivered.
94 - The architecture shall enable sourcing best-in-class components.
96 - Common capabilities are ‘developed’ once and ‘used’ many times.
98 - Core capabilities shall support many diverse services and
101 - The architecture shall support elastic scaling as needs grow or
104 **Figure 1: ONAP Platform**
111 The platform provides the common functions (e.g., data collection,
112 control loops, metadata recipe creation, policy/recipe distribution,
113 etc.) necessary to construct specific behaviors. To create a service or
114 operational capability, it is necessary to develop
115 service/operations-specific service definitions, data collection,
116 analytics, and policies (including recipes for corrective/remedial
117 action) using the ONAP Design Framework Portal. Figure 2 provides a
118 high-level view of the ONAP architecture and microservices-based
119 platform components, including all ONAP projects.
121 **Figure 2: ONAP Platform components with projects (Beijing Release)**
125 In Figure 3 below, we provide a functional view of the architecture,
126 which highlights the role of key new components:
128 1. The Beijing release standardizes and improves northbound
129 interoperability for the ONAP Platform using the **External API**
132 2. **OOM** provides the ability to manage cloud-native installation and
133 deployments to Kubernetes-managed cloud environments.
135 3. ONAP Common Services now manage more complex and optimized
136 topologies. **MUSIC** allows ONAP to scale to multi-site
137 environments to support global scale infrastructure requirements. The
138 ONAP Optimization Framework (OOF) provides a declarative,
139 policy-driven approach for creating and running optimization
140 applications like Homing/Placement, and Change Management Scheduling
143 4. **Information Model and framework utilities** have evolved to
144 harmonize the topology, workflow, and policy models from a number of
145 SDOs including ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA,
148 |image2| Figure 3. Functional view of the ONAP architecture
150 3. Microservices Support
151 ========================
153 As a cloud-native application that consists of numerous services, ONAP
154 requires sophisticated initial deployment as well as post-deployment
155 management. It needs to be highly reliable, scalable, secure and easy to
156 manage. Also, the ONAP deployment needs to be flexible to suit the
157 different scenarios and purposes for various operator environments.
158 Users may also want to select part of the ONAP components to integrate
159 into their own systems. To achieve all these goals, ONAP is designed as
160 a microservices based system, with all components released as Docker
163 The ONAP Operations Manager
164 (`OOM <https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project>`__)
165 is responsible for orchestrating the end-to-end lifecycle management and
166 monitoring of ONAP components. OOM uses Kubernetes to provide CPU
167 efficiency and platform deployment. In addition, OOM helps enhance ONAP
168 platform maturity by providing scalability and resiliency enhancements
169 to the components it manages.
173 OOM is the lifecycle manager of the ONAP platform and uses the
174 Kubernetes container management system and Consul to provide the
175 following functionality:
177 1. **Deployment** - with built-in component dependency management
178 (including multiple clusters, federated deployments across sites, and
181 2. **Configuration** - unified configuration across all ONAP
184 3. **Monitoring** - real-time health monitoring feeding to a Consul GUI
187 4. **Restart** - failed ONAP components are restarted automatically
189 5. **Clustering and Scaling** - cluster ONAP services to enable seamless
192 6. **Upgrade** - change-out containers or configuration with little or
195 7. **Deletion** - cleanup individual containers or entire deployments
197 OOM supports a wide variety of cloud infrastructures to suit your
198 individual requirements.
200 The Microservices Bus (MSB) component project provides some fundamental
201 microservices support such as service registration/discovery, external
202 API gateway, internal API gateway, client software development kit
203 (SDK), and Swagger SDK to help ONAP projects evolve towards the
204 microservice direction. MSB is integrated with OOM to provide
205 transparent service registration for ONAP microservices, it also
206 supports OpenStack(Heat) and bare metal deployment.
211 ONAP delivers a single, consistent user experience to both design-time
212 and run-time environments, based on the user’s role. Role changes are
213 are configured within a single ONAP instance instance.
215 This user experience is managed by the ONAP Portal, which provides
216 access to design, analytics and operational control/administration
217 functions via a shared, role-based menu or dashboard. The portal
218 architecture provides web-based capabilities such as application
219 onboarding and management, centralized access management, and
220 dashboards, as well as hosted application widgets.
222 The portal provides an SDK to enable multiple development teams to
223 adhere to consistent UI development requirements by taking advantage of
224 built-in capabilities (Services/API/UI controls), tools and
225 technologies. ONAP also provides a Command Line Interface (CLI) for
226 operators who require it (e.g., to integrate with their scripting
227 environment). ONAP SDKs enable operations/security, third parties (e.g.,
228 vendors and consultants), and other experts to continually
229 define/redefine new collection, analytics, and policies (including
230 recipes for corrective/remedial action) using the ONAP Design Framework
233 5. Design-time Framework
234 ========================
236 The design-time framework is a comprehensive development environment
237 with tools, techniques, and repositories for defining/ describing
238 resources, services, and products.
240 The design time framework facilitates reuse of models, further improving
241 efficiency as more and more models become available. Resources,
242 services, products, and their management and control functions can all
243 be modeled using a common set of specifications and policies (e.g., rule
244 sets) for controlling behavior and process execution. Process
245 specifications automatically sequence instantiation, delivery and
246 lifecycle management for resources, services, products and the ONAP
247 platform components themselves. Certain process specifications (i.e.,
248 ‘recipes’) and policies are geographically distributed to optimize
249 performance and maximize autonomous behavior in federated cloud
252 Service Design and Creation (SDC) provides tools, techniques, and
253 repositories to define/simulate/certify system assets as well as their
254 associated processes and policies. Each asset is categorized into one of
255 four asset groups: Resource, Services, Products, or Offers.
257 The SDC environment supports diverse users via common services and
258 utilities. Using the design studio, product and service designers
259 onboard/extend/retire resources, services and products. Operations,
260 Engineers, Customer Experience Managers, and Security Experts create
261 workflows, policies and methods to implement Closed Loop
262 Automation/Control and manage elastic scalability.
264 To support and encourage a healthy VNF ecosystem, ONAP provides a set of
265 VNF packaging and validation tools in the VNF Supplier API and Software
266 Development Kit (VNF SDK) and VNF Validation Program (VVP) components.
267 Vendors can integrate these tools in their CI/CD environments to package
268 VNFs and upload them to the validation engine. Once tested, the VNFs can
269 be onboarded through SDC.
271 The Policy Creation component deals with polices; these are rules,
272 conditions, requirements, constraints, attributes, or needs that must be
273 provided, maintained, and/or enforced. At a lower level, Policy involves
274 machine-readable rules enabling actions to be taken based on triggers or
275 requests. Policies often consider specific conditions in effect (both in
276 terms of triggering specific policies when conditions are met, and in
277 selecting specific outcomes of the evaluated policies appropriate to the
278 conditions). Policy allows rapid modification through easily updating
279 rules, thus updating technical behaviors of components in which those
280 policies are used, without requiring rewrites of their software code.
281 Policy permits simpler management / control of complex mechanisms via
284 The Closed Loop Automation Management Platform (CLAMP) provides a
285 platform for designing and managing control loops. CLAMP is used to
286 design a closed loop, configure it with specific parameters for a
287 particular network service, then deploy and decommission it. Once
288 deployed, a user can also update the loop with new parameters during
289 runtime, as well as suspend and restart it.
294 The runtime execution framework executes the rules and policies
295 distributed by the design and creation environment.
297 This allows for the distribution of policy enforcement and templates
298 among various ONAP modules such as the Service Orchestrator (SO),
299 Controllers, Data Collection, Analytics and Events (DCAE), Active and
300 Available Inventory (A&AI), and a Security Framework. These components
301 use common services that support logging, access control, and data
302 management. A new component, Multi-Site State Coordination (MUSIC),
303 allows the platform to register and manage state across multi-site
304 deployments. The External API provides access for third-party frameworks
305 such as MEF, TM Forum and potentially others, to facilitate interactions
306 between operator BSS and relevant ONAP components.
311 The Service Orchestrator (SO) component executes the specified processes
312 by automating sequences of activities, tasks, rules and policies needed
313 for on-demand creation, modification or removal of network, application
314 or infrastructure services and resources. The SO provides orchestration
315 at a very high level, with an end-to-end view of the infrastructure,
316 network, and applications.
318 The External API Northbound Interface component provides a
319 standards-based interface between the BSS and and various ONAP
320 components, including Service Orchestrator, A&AI and SDC, providing an
321 abstracted view of the platform. This type of abstraction allows service
322 providers to use their existing BSS/OSS environment and minimize
323 lengthy, high-cost integration with underlying infrastructure. The
324 Beijing release is the first of a series of enhancements in support of
325 SDO collaborations, which are expected to support inter-operator
326 exchanges and other use cases defined by associated standards bodies
327 such as MEF, TM Forum and others.
329 Policy-driven Workload Optimization
330 -----------------------------------
332 In the Beijing Release, ONAP Optimization Framework (OOF) provides a
333 policy-driven and model-driven framework for creating optimization
334 applications for a broad range of use cases. OOF-HAS is a policy-driven
335 workload optimization service that enables optimized placement of
336 services across multiple sites and multiple clouds, based on a wide
337 variety of policy constraints including capacity, location, platform
338 capabilities, and other service specific constraints.
340 In the Beijing Release, ONAP Multi-VIM/Cloud (MC) and several other ONAP
341 components such as Policy, SO, A&AI etc. play an important role in
342 enabling “Policy-driven Performance/Security-aware Adaptive Workload
343 Placement/Scheduling” across cloud sites through OOF-HAS. OOF-HAS uses
344 Hardware Platform Awareness (HPA) and real-time Capacity Checks provided
345 by ONAP MC to determine the optimal VIM/Cloud instances, which can
346 deliver the required performance SLAs, for workload (VNF etc.) placement
347 and scheduling (Homing). The key operator benefit is realizing the true
348 value of virtualization through fine grained optimization of cloud
349 resources while delivering the performance/security SLAs. For the
350 Beijing release, this feature is available for the vCPE use case.
355 Controllers are applications which are coupled with cloud and network
356 services and execute the configuration, real-time policies, and control
357 the state of distributed components and services. Rather than using a
358 single monolithic control layer, operators may choose to use multiple
359 distinct Controller types that manage resources in the execution
360 environment corresponding to their assigned controlled domain such as
361 cloud computing resources (network configuration (SDN-C) and application
362 (App-C). Also, the Virtual Function Controller (VF-C) provides an ETSI
363 NFV compliant NFV-O function, that is responsible for lifecycle
364 management of virtual services and the associated physical COTS server
365 infrastructure. VF-C provides a generic VNFM capability but also
366 integrates with external VNFMs and VIMs as part of a NFV MANO stack.
368 In the Beijing release, the new Multisite State Coordination (MUSIC)
369 project records and manages state of the Portal and ONAP Optimization
370 Framework to ensure consistency, redundancy and high availability across
371 geographically distributed ONAP deployments.
376 Active and Available Inventory (A&AI) provides real-time views of a
377 system’s resources, services, products and their relationships with each
378 other. The views provided by A&AI relate data managed by multiple ONAP
379 instances, Business Support Systems (BSS), Operation Support Systems
380 (OSS), and network applications to form a “top to bottom” view ranging
381 from the products end-users buy, to the resources that form the raw
382 material for creating the products. A&AI not only forms a registry of
383 products, services, and resources, it also maintains up-to-date views of
384 the relationships between these inventory items.
386 To deliver the promised dynamism of SDN/NFV, A&AI is updated in real
387 time by the controllers as they make changes in the network environment.
388 A&AI is metadata-driven, allowing new inventory types to be added
389 dynamically and quickly via SDC catalog definitions, eliminating the
390 need for lengthy development cycles.
392 7. Closed-Loop Automation
393 =========================
395 The following sections describe the ONAP frameworks designed to address
396 major operator requirements. The key pattern that these frameworks help
399 **Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
402 We refer to this automation pattern as “closed-loop automation” in that
403 it provides the necessary automation to proactively respond to network
404 and service conditions without human intervention. A high-level
405 schematic of the “closed-loop automation” and the various phases within
406 the service lifecycle using the automation is depicted in Figure 3.
408 Closed-loop control is provided by Data Collection, Analytics and Events
409 (DCAE) and one or more of the other ONAP runtime components.
410 Collectively, they provide FCAPS (Fault Configuration Accounting
411 Performance Security) functionality. DCAE collects performance, usage,
412 and configuration data; provides computation of analytics; aids in
413 troubleshooting; and publishes events, data and analytics (e.g., to
414 policy, orchestration, and the data lake). Another component, “Holmes”,
415 connects to DCAE and provides alarm correlation for ONAP, which depicts
416 the topological relation between different alarms raising either from
417 different layers of VNFs or from different VNF entities that are
418 distributed all over the network.
420 Working with the Policy Framework and CLAMP, these components detect
421 problems in the network and identify the appropriate remediation. In
422 some cases, the action will be automatic, and they will notify Service
423 Orchestrator or one of the controllers to take action. In other cases,
424 as configured by the operator, they will raise an alarm but require
425 human intervention before executing the change.
427 **Figure 5: ONAP Closed Loop Automation**
434 ONAP provides common operational services for all ONAP components
435 including activity logging, reporting, common data layer, access
436 control, secret and credential management, resiliency, and software
437 lifecycle management.
439 These services provide access management and security enforcement, data
440 backup, restoration and recovery. They support standardized VNF
441 interfaces and guidelines.
443 Operating in a virtualized environment introduces new security
444 challenges and opportunities. ONAP provides increased security by
445 embedding access controls in each ONAP platform component, augmented by
446 analytics and policy components specifically designed for the detection
447 and mitigation of security violations.
452 Adopting the model-driven approach, ONAP provides models to assist the
453 service design, development of various ONAP components and improve the
454 interoperability of ONAP.
456 Models are essential part for the design time and run time framework
457 development. The ONAP modeling project leverages the experience of
458 member companies, standard organizations and other open source projects
459 to produce models which are simple, extensible, and reusable. The goal
460 is to fulfill the requirements of various use cases, guide the
461 development and bring consistency among ONAP components and explore a
462 common model to improve the interoperability of ONAP.
464 In the Bejing Release, ONAP supports the following Models:
466 - A VNF Information Model based on ETSI NFV IFA011 v.2.4.1 with
467 appropriate modifications aligned with ONAP requirements;
469 - A VNF Descriptor Model based on TOSCA implementation based on the IM
470 and follow the same model definitions in ETSI NFV SOL001 v 0.6.0.
472 - VNF Package format based on ETSI NFV SOL004 specification.
474 These models enable ONAP to interoperate with implementations based on
475 standard, and improve the industry collaboration. Service models,
476 multi-VIM models and other models will be explored and defined in the
477 Casablanca and future releases.
482 The ONAP project tests blueprints for real-world use cases to enable
483 rapid adoption of the platform. With the first release of ONAP
484 (“Amsterdam”), we introduced two blueprints: vCPE and VoLTE. Subsequent
485 releases test additional functionality and/or new blueprints.
490 In this use case, many traditional network functions such as NAT,
491 firewall, and parental controls are implemented as virtual network
492 functions. These VNFs can either be deployed in the data center or at
493 the customer edge (or both). Also, some network traffic will be tunneled
494 (using MPLS VPN, VxLAN, etc.) to the data center, while other traffic
495 can flow directly to the Internet. A vCPE infrastructure allows service
496 providers to offer new value-added services to their customers with less
497 dependency on the underlying hardware.
499 In this use case, the customer has a physical CPE (pCPE) attached to a
500 traditional broadband network such as DSL (Figure 1). On top of this
501 service, a tunnel is established to a data center hosting various VNFs.
502 In addition, depending on the capabilities of the pCPE, some functions
503 can be deployed on the customer site.
505 This use case traditionally requires fairly complicated orchestration
506 and management, managing both the virtual environment and underlay
507 connectivity between the customer and the service provider. ONAP
508 supports such a use case with two key components – SDN-C, which manages
509 connectivity services, and APP-C, which manages virtualization services.
510 In this case, ONAP provides a common service orchestration layer for the
511 end-to-end service. It uses the SDN-C component to establish network
512 connectivity. Similarly, ONAP uses the APP-C component to manage the VNF
513 lifecycle. Deploying ONAP in this fashion simplifies and greatly
514 accelerates the task of trialing and launching new value-added services.
516 In the Beijing Release, the vCPE use case supports Policy-driven
517 Workload Optimization, which is supported by OOF, Multi-VIM/Cloud,
518 Policy, SO, A&AI and other ONAP components.
520 **Figure 6. ONAP vCPE Architecture**
524 Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
526 Voice over LTE (VoLTE) Use Case
527 -------------------------------
529 The second blueprint developed for ONAP is Voice over LTE. This
530 blueprint demonstrates how a Mobile Service Provider (SP) could deploy
531 VoLTE services based on SDN/NFV. This blueprint incorporates commercial
532 VNFs to create and manage the underlying vEPC and vIMS services by
533 interworking with vendor-specific components, including VNFMs, EMSs,
534 VIMs and SDN controllers, across Edge Data Centers and a Core Date
537 **Figure 7. ONAP VoLTE Architecture**
541 ONAP supports the VoLTE use case with several key components: SO, VF-C,
542 SDN-C, and Multi-VIM/ Cloud. In this use case, SO is responsible for
543 VoLTE end-to-end service orchestration. It collaborates with VF-C and
544 SDN-C to deploy the VoLTE service. ONAP uses the SDN-C component to
545 establish network connectivity, then the VF-C component completes the
546 Network Services and VNF lifecycle management (including service
547 initiation, termination and manual scaling which is composed of VNFs
548 based on the unified VNFD model) and FCAPS (fault, configuration,
549 accounting, performance, security) management. VF-C can also integrate
550 with commercial VIMs in the Edge and Core datacenters via abstract
551 interfaces provided by Multi-VIM/Cloud.
553 Using ONAP to manage the complete lifecycle of the VoLTE use case brings
554 increased agility, CAPEX and OPEX reductions, and increased
555 infrastructure efficiency to Communication Service Providers (CSPs). In
556 addition, the usage of commercial software in this blueprint offers CSPs
557 an efficient path to rapid production.
559 Read the VoLTE Use Case with ONAP whitepaper to learn more.
561 .. include:: blueprint-enr.rst
566 The ONAP platform provides a comprehensive platform for real-time,
567 policy-driven orchestration and automation of physical and virtual
568 network functions that will enable software, network, IT and cloud
569 providers and developers to rapidly automate new services and support
570 complete lifecycle management.
572 By unifying member resources, ONAP will accelerate the development of a
573 vibrant ecosystem of VNFs around a globally shared architecture and
574 implementation for network automation–with an open standards focus–
575 faster than any one product could on its own.
578 .. |image0| image:: media/ONAP-DTRT.png
581 .. |image1| image:: media/ONAP-toplevel.png
584 .. |image2| image:: media/ONAP-fncview.png
587 .. |image3| image:: media/ONAP-oom.png
590 .. |image4| image:: media/ONAP-closedloop.jpeg
593 .. |image5| image:: media/ONAP-vcpe.png
596 .. |image6| image:: media/ONAP-volte.png