1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
3 .. Copyright 2017 Huawei Technologies Co., Ltd.
5 Introducing the ONAP Architecture (Amsterdam Release)
6 =====================================================
11 The ONAP project was formed in March, 2017 in response to a rising need
12 for a common platform for telecommunication, cable, and cloud
13 operators—and their solution providers—to deliver differentiated network
14 services on demand, profitably and competitively, while leveraging
17 Prior to ONAP, operators of large networks have been challenged to keep
18 up with the scale and cost of manual changes required to implement new
19 service offerings, from installing new data center equipment to, in some
20 cases, upgrading on-premises customer equipment. Many are seeking to
21 exploit SDN and NFV to improve service velocity, simplify equipment
22 interoperability and integration, and reduce overall CapEx and OpEx
23 costs. In addition, the current, highly fragmented management landscape
24 makes it difficult to monitor and guarantee service-level agreements
27 ONAP is addressing these problems by developing global and massive scale
28 (multi-site and multi-VIM) orchestration capabilities for both physical
29 and virtual network elements. It facilitates service agility by
30 providing a common set of REST northbound APIs that are open and
31 interoperable, and by supporting YANG and TOSCA data models. ONAP’s
32 modular and layered nature improves interoperability and simplifies
33 integration, allowing it to support multiple VNF environments by
34 integrating with multiple VIMs, VNFMs, SDN Controllers, and even legacy
35 equipment. This approach allows network and cloud operators to optimize
36 their physical and virtual infrastructure for cost and performance; at
37 the same time, ONAP’s use of standard models reduces integration and
38 deployment costs of heterogeneous equipment, while minimizing management
41 The ONAP platform allows end customers and their network/cloud providers
42 to collaboratively instantiate network elements and services in a
43 dynamic, closed-loop process, with real-time response to actionable
44 events. In order to design, engineer, plan, bill and assure these
45 dynamic services, there are three (3) major requirements:
47 - A robust design framework that allows specification of the service in
48 all aspects – modeling the resources and relationships that make up
49 the service, specifying the policy rules that guide the service
50 behavior, specifying the applications, analytics and closed-loop
51 events needed for the elastic management of the service
53 - An orchestration and control framework (Service Orchestrator and
54 Controllers) that is recipe/policy driven to provide automated
55 instantiation of the service when needed and managing service demands
58 - An analytic framework that closely monitors the service behavior
59 during the service lifecycle based on the specified design, analytics
60 and policies to enable response as required from the control
61 framework, to deal with situations ranging from those that require
62 healing to those that require scaling of the resources to elastically
63 adjust to demand variations.
65 To achieve this, ONAP decouples the details of specific services and
66 technologies from the common information models, core orchestration
67 platform and generic management engines (for discovery, provisioning,
68 assurance etc). Furthermore, it marries the speed and style of a
69 DevOps/NetOps approach with the formal models and processes operators
70 require to introduce new services and technologies. This is in stark
71 contrast to the traditional OSS/Management software platform
72 architectures, which hardcoded service and technologies and required
73 lengthy software development and integration cycles to incorporate
76 The ONAP Platform enables product/service independent capabilities for
77 design, creation and lifecycle management, in accordance with the
78 following foundational principles:
80 - Ability to dynamically introduce full service life-cycle
81 orchestration (design, provisioning and operation) and service API
82 for new services & technologies without the need for new platform
83 software releases or without affecting operations for the existing
86 - Carrier-grade scalability including horizontal scaling (linear
87 scale-out) and distribution to support large number of services
90 - Metadata-driven and policy-driven architecture to ensure flexible
91 ways in which capabilities are used and delivered
93 - The architecture shall enable sourcing best-in-class components
95 - Common capabilities are ‘developed’ once and ‘used’ many times
97 - Core capabilities shall support many diverse services
99 - The architecture shall support elastic scaling as needs grow or
104 **Figure 1:** ONAP Platform
109 Figure 2 provides a high-level view of the ONAP architecture and
110 microservices-based platform components. The platform provides the
111 common functions (e.g., data collection, control loops, meta-data recipe
112 creation, policy/recipe distribution, etc.) necessary to construct
113 specific behaviors. To create a service or operational capability, it is
114 necessary to develop service/operations-specific collection, analytics,
115 and policies (including recipes for corrective/remedial action) using
116 the ONAP Design Framework Portal.
118 |image1|\ **Figure 2:** ONAP Platform components (Amsterdam Release)
123 ONAP delivers a single, consistent user experience to both design time
124 and run time environments, based on the user’s role; role changes to be
125 configured within the single ecosystem. This user experience is managed
126 by the ONAP Portal, which provides access to design, analytics and
127 operational control/administration functions via a shared, role-based
128 menu or dashboard. The portal architecture provides web-based
129 capabilities such as application onboarding and management, centralized
130 access management, and dashboards, as well as hosted application
133 The portal provides an SDK to enable multiple development teams to
134 adhere to consistent UI development requirements by taking advantage of
135 built-in capabilities (Services/ API/ UI controls), tools and
136 technologies. ONAP also provides a Command Line Interface (CLI) for
137 operators who require it (e.g., to integrate with their scripting
138 environment). ONAP SDKs enable operations/security, third parties (e.g.,
139 vendors and consultants), and other experts to continually define/refine
140 new collection, analytics, and policies (including recipes for
141 corrective/remedial action) using the ONAP Design Framework Portal.
143 Design time Framework
144 +++++++++++++++++++++
146 The design time framework is a comprehensive development environment
147 with tools, techniques, and repositories for defining/describing
148 resources, services, and products. The design time framework facilitates
149 re-use of models, further improving efficiency as more and more models
150 become available. Resources, services and products can all be modeled
151 using a common set of specifications and policies (e.g., rule sets) for
152 controlling behavior and process execution. Process specifications
153 automatically sequence instantiation, delivery and lifecycle management
154 for resources, services, products and the ONAP platform components
155 themselves. Certain process specifications (i.e., ‘recipes’) and
156 policies are geographically distributed to optimize performance and
157 maximize autonomous behavior in federated cloud environments.
159 Service Design and Creation (SDC) provides tools, techniques, and
160 repositories to define/simulate/certify system assets as well as their
161 associated processes and policies. Each asset is categorized into one of
162 four (4) asset groups: Resource, Services, Products, or Offers.
164 The SDC environment supports diverse users via common services and
165 utilities. Using the design studio, product and service designers
166 onboard/extend/retire resources, services and products. Operations,
167 Engineers, Customer Experience Managers, and Security Experts create
168 workflows, policies and methods to implement Closed Loop Automation and
169 manage elastic scalability.
171 To support and encourage a healthy VNF ecosystem, ONAP provides a set of
172 VNF packaging and validation tools in the VNF Supplier API and Software
173 Development Kit (VNF SDK) component. Vendors can integrate these tools
174 in their CI/CD environments to package VNFs and upload them to the
175 validation engine. Once tested, the VNFs can be onboarded through SDC.
176 In the future, ONAP plans to develop a VNF logo program to indicate to
177 users which VNFs have gone through formal ONAP validation testing.
179 The Policy Creation component deals with polices; these are conditions,
180 requirements, constraints, attributes, or needs that must be provided,
181 maintained, and/or enforced. At a lower level, Policy involves
182 machine-readable rules enabling actions to be taken based on triggers or
183 requests. Policies often consider specific conditions in effect (both in
184 terms of triggering specific policies when conditions are met, and in
185 selecting specific outcomes of the evaluated policies appropriate to the
186 conditions). Policy allows rapid updates through easily updating rules,
187 thus updating technical behaviors of components in which those policies
188 are used, without requiring rewrites of their software code. Policy
189 permits simpler management / control of complex mechanisms via
192 The Closed Loop Automation Management Platform (CLAMP) provides a
193 platform for designing and managing control loops. It is used to design
194 a closed loop, configure it with specific parameters for a particular
195 network service, then deploy and decommission it. Once deployed, a user
196 can also update the loop with new parameters during runtime, as well as
197 suspend and restart it.
202 The runtime execution framework executes the rules and policies
203 distributed by the design and creation environment. This allows us to
204 distribute policy enforcement and templates among various ONAP modules
205 such as the Service Orchestrator (SO), Controllers, Data Collection,
206 Analytics and Events (DCAE), Active and Available Inventory (A&AI), and
207 a Security Framework. These components use common services that support
208 logging, access control, and data management.
213 The Service Orchestrator (SO) component executes the
214 specified processes and automates sequences of activities, tasks, rules
215 and policies needed for on-demand creation, modification or removal of
216 network, application or infrastructure services and resources. The SO
217 provides orchestration at a very high level, with an end to end view of
218 the infrastructure, network, and applications.
223 Controllers are applications which are coupled with cloud and network
224 services and execute the configuration, real-time policies, and control
225 the state of distributed components and services. Rather than using a
226 single monolithic control layer, operators may choose to use multiple
227 distinct Controller types that manage resources in the execution
228 environment corresponding to their assigned controlled domain such as
229 cloud computing resources (network configuration (SDN-C) and application
230 (App-C). Also, the Virtual Function Controller (VF-C) provides an ETSI
231 NFV compliant NFV-O function, and is responsible for life cycle
232 management of virtual services and the associated physical COTS server
233 infrastructure. While it provides a generic VNFM, it also integrates
234 with external VNFMs and VIMs as part of a NFV MANO stack.
239 Active and Available Inventory (A&AI) provides real-time views of a
240 system’s resources, services, products and their relationships with each
241 other. The views provided by A&AI relate data managed by multiple ONAP
242 instances, Business Support Systems (BSS), Operation Support Systems
243 (OSS), and network applications to form a “top to bottom” view ranging
244 from the products end-users buy, to the resources that form the raw
245 material for creating the products. A&AI not only forms a registry of
246 products, services, and resources, it also maintains up-to-date views of
247 the relationships between these inventory items.
249 To deliver promised dynamism of SDN/NFV, A&AI is updated in real time by
250 the controllers as they make changes in the Domain 2 environment. A&AI
251 is metadata-driven, allowing new inventory types to be added dynamically
252 and quickly via SDC catalog definitions, eliminating the need for
253 lengthy development cycles.
255 Closed-Loop Automation
256 ----------------------
258 The following sections describe the ONAP frameworks designed to address
259 these major requirements. The key pattern that these frameworks help
262 ***Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
265 We refer to this automation pattern as “closed-loop automation” in that
266 it provides the necessary automation to proactively respond to network
267 and service conditions without human intervention. A high-level
268 schematic of the “closed-loop automation” and the various phases within
269 the service lifecycle using the automation is depicted in Figure 4.
271 Closed-loop control is provided by Data Collection, Analytics and Events
272 (DCAE) and other ONAP components. Collectively, they provide FCAPS
273 (Fault Configuration Accounting Performance Security) functionality.
274 DCAE collects performance, usage, and configuration data; provides
275 computation of analytics; aids in troubleshooting; and publishes events,
276 data and analytics (e.g., to policy, orchestration, and the data lake).
277 Another component, “Holmes”, connects to DCAE and provides alarm
278 correlation for ONAP.
280 Working with the Policy Framework and CLAMP, these components detect
281 problems in the network and identify the appropriate remediation. In
282 some cases, the action will be automatic, and they will notify Service
283 Orchestrator or one of the controllers to take action. In other cases,
284 as configured by the operator, they will raise an alarm but require
285 human intervention before executing the change.
289 \ **Figure 3:** ONAP Closed Loop Automation
294 ONAP provides common operational services for all ONAP components
295 including activity logging, reporting, common data layer, access
296 control, resiliency, and software lifecycle management. These services
297 provide access management and security enforcement, data backup,
298 restoration and recovery. They support standardized VNF interfaces and
301 Operating in a virtualized environment introduces new security challenges
302 and opportunities. ONAP provides increased security by embedding access controls
303 in each ONAP platform component, augmented by analytics and policy components
304 specifically designed for the detection and mitigation of security violations.
309 The ONAP project uses real-world use cases to help focus our releases.
310 For the first release of ONAP (“Amsterdam”), we introduce two use cases:
313 \ **Virtual CPE Use Case**
315 In this use case, many traditional network functions such as NAT,
316 firewall, and parental controls are implemented as virtual network
317 functions. These VNFs can either be deployed in the data center or at
318 the customer edge (or both). Also, some network traffic will be tunneled
319 (using MPLS VPN, VxLAN, etc.) to the data center, while other traffic
320 can flow directly to the Internet. A vCPE infrastructure allows service
321 providers to offer new value-added services to their customers with less
322 dependency on the underlying hardware.
324 In this use case, the customer has a physical CPE (pCPE) attached to a
325 traditional broadband network such as DSL (Figure 1). On top of this
326 service, a tunnel is established to a data center hosting various VNFs.
327 In addition, depending on the capabilities of the pCPE, some functions
328 can be deployed on the customer site.
330 This use case traditionally requires fairly complicated orchestration
331 and management, managing both the virtual environment and underlay
332 connectivity between the customer and the service provider. ONAP
333 supports such a use case with two key components – SDN-C, which manages
334 connectivity services, and APP-C, which manages virtualization services.
335 In this case, ONAP provides a common service orchestration layer for the
336 end-to-end service. It uses the SDN-C component to establish network
337 connectivity. Similarly, ONAP uses the APP-C component to manage the
338 virtualization infrastructure. Deploying ONAP in this fashion simplifies
339 and greatly accelerates the task of trialing and launching new
340 value-added services.
344 **Figure 4. ONAP vCPE Architecture**
346 Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
348 **Voice over LTE (VoLTE) Use Case**
350 The second use case developed with Amsterdam is Voice over LTE. This use
351 case demonstrates how a Mobile Service Provider (SP) could deploy VoLTE
352 services based on SDN/NFV. The SP is able to onboard the service via
353 ONAP. Specific sub-use cases are:
357 - Service configuration
359 - Service termination
361 - Auto-scaling based on fault and/or performance
363 - Fault detection & correlation, and auto-healing
365 - Data correlation and analytics to support all sub use cases
367 To connect the different data centers, ONAP will also have to interface
368 with legacy systems and physical function to establish VPN connectivity
369 in a brown field deployment.
371 The VoLTE use case, shown in Figure 6, demonstrates the use of the VF-C
372 component and TOSCA-based data models to manage the virtualization
377 **Figure 5. ONAP VoLTE Architecture**
379 Read the VoLTE Use Case with ONAP whitepaper to learn more.
384 The ONAP platform provides a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions that will enable software, network, IT and cloud providers and developers to rapidly automate new services and support complete lifecycle management.
386 By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a globally shared architecture and implementation for network automation–with an open standards focus–faster than any one product could on its own.
388 .. |image0| image:: media/ONAP-DTRT.png
391 .. |image1| image:: media/ONAP-toplevel.png
394 .. |image2| image:: media/ONAP-closedloop.png
397 .. |image3| image:: media/ONAP-vcpe.png
400 .. |image4| image:: media/ONAP-volte.png
Code Review / doc.git / blob