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 (Beijing 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.
120 **Figure 2:** ONAP Platform components (Beijing Release)
125 ONAP delivers a single, consistent user experience to both design time
126 and run time environments, based on the user’s role; role changes to be
127 configured within the single ecosystem. This user experience is managed
128 by the ONAP Portal, which provides access to design, analytics and
129 operational control/administration functions via a shared, role-based
130 menu or dashboard. The portal architecture provides web-based
131 capabilities such as application onboarding and management, centralized
132 access management, and dashboards, as well as hosted application
135 The portal provides an SDK to enable multiple development teams to
136 adhere to consistent UI development requirements by taking advantage of
137 built-in capabilities (Services/ API/ UI controls), tools and
138 technologies. ONAP also provides a Command Line Interface (CLI) for
139 operators who require it (e.g., to integrate with their scripting
140 environment). ONAP SDKs enable operations/security, third parties (e.g.,
141 vendors and consultants), and other experts to continually define/refine
142 new collection, analytics, and policies (including recipes for
143 corrective/remedial action) using the ONAP Design Framework Portal.
145 Design time Framework
146 +++++++++++++++++++++
148 The design time framework is a comprehensive development environment
149 with tools, techniques, and repositories for defining/describing
150 resources, services, and products. The design time framework facilitates
151 re-use of models, further improving efficiency as more and more models
152 become available. Resources, services and products can all be modeled
153 using a common set of specifications and policies (e.g., rule sets) for
154 controlling behavior and process execution. Process specifications
155 automatically sequence instantiation, delivery and lifecycle management
156 for resources, services, products and the ONAP platform components
157 themselves. Certain process specifications (i.e., ‘recipes’) and
158 policies are geographically distributed to optimize performance and
159 maximize autonomous behavior in federated cloud environments.
161 Service Design and Creation (SDC) provides tools, techniques, and
162 repositories to define/simulate/certify system assets as well as their
163 associated processes and policies. Each asset is categorized into one of
164 four (4) asset groups: Resource, Services, Products, or Offers.
166 The SDC environment supports diverse users via common services and
167 utilities. Using the design studio, product and service designers
168 onboard/extend/retire resources, services and products. Operations,
169 Engineers, Customer Experience Managers, and Security Experts create
170 workflows, policies and methods to implement Closed Loop Automation and
171 manage elastic scalability.
173 To support and encourage a healthy VNF ecosystem, ONAP provides a set of
174 VNF packaging and validation tools in the VNF Supplier API and Software
175 Development Kit (VNF SDK) component. Vendors can integrate these tools
176 in their CI/CD environments to package VNFs and upload them to the
177 validation engine. Once tested, the VNFs can be onboarded through SDC.
178 In the future, ONAP plans to develop a VNF logo program to indicate to
179 users which VNFs have gone through formal ONAP validation testing.
181 The Policy Creation component deals with polices; these are conditions,
182 requirements, constraints, attributes, or needs that must be provided,
183 maintained, and/or enforced. At a lower level, Policy involves
184 machine-readable rules enabling actions to be taken based on triggers or
185 requests. Policies often consider specific conditions in effect (both in
186 terms of triggering specific policies when conditions are met, and in
187 selecting specific outcomes of the evaluated policies appropriate to the
188 conditions). Policy allows rapid updates through easily updating rules,
189 thus updating technical behaviors of components in which those policies
190 are used, without requiring rewrites of their software code. Policy
191 permits simpler management / control of complex mechanisms via
194 The Closed Loop Automation Management Platform (CLAMP) provides a
195 platform for designing and managing control loops. It is used to design
196 a closed loop, configure it with specific parameters for a particular
197 network service, then deploy and decommission it. Once deployed, a user
198 can also update the loop with new parameters during runtime, as well as
199 suspend and restart it.
204 The runtime execution framework executes the rules and policies
205 distributed by the design and creation environment. This allows us to
206 distribute policy enforcement and templates among various ONAP modules
207 such as the Service Orchestrator (SO), Controllers, Data Collection,
208 Analytics and Events (DCAE), Active and Available Inventory (A&AI), and
209 a Security Framework. These components use common services that support
210 logging, access control, and data management.
215 The Service Orchestrator (SO) component executes the
216 specified processes and automates sequences of activities, tasks, rules
217 and policies needed for on-demand creation, modification or removal of
218 network, application or infrastructure services and resources. The SO
219 provides orchestration at a very high level, with an end to end view of
220 the infrastructure, network, and applications.
225 Controllers are applications which are coupled with cloud and network
226 services and execute the configuration, real-time policies, and control
227 the state of distributed components and services. Rather than using a
228 single monolithic control layer, operators may choose to use multiple
229 distinct Controller types that manage resources in the execution
230 environment corresponding to their assigned controlled domain such as
231 cloud computing resources (network configuration (SDN-C) and application
232 (App-C). Also, the Virtual Function Controller (VF-C) provides an ETSI
233 NFV compliant NFV-O function, and is responsible for life cycle
234 management of virtual services and the associated physical COTS server
235 infrastructure. While it provides a generic VNFM, it also integrates
236 with external VNFMs and VIMs as part of a NFV MANO stack.
241 Active and Available Inventory (A&AI) provides real-time views of a
242 system’s resources, services, products and their relationships with each
243 other. The views provided by A&AI relate data managed by multiple ONAP
244 instances, Business Support Systems (BSS), Operation Support Systems
245 (OSS), and network applications to form a “top to bottom” view ranging
246 from the products end-users buy, to the resources that form the raw
247 material for creating the products. A&AI not only forms a registry of
248 products, services, and resources, it also maintains up-to-date views of
249 the relationships between these inventory items.
251 To deliver promised dynamism of SDN/NFV, A&AI is updated in real time by
252 the controllers as they make changes in the Domain 2 environment. A&AI
253 is metadata-driven, allowing new inventory types to be added dynamically
254 and quickly via SDC catalog definitions, eliminating the need for
255 lengthy development cycles.
257 Closed-Loop Automation
258 ----------------------
260 The following sections describe the ONAP frameworks designed to address
261 these major requirements. The key pattern that these frameworks help
264 **Design -> Create -> Collect -> Analyze -> Detect -> Publish ->
267 We refer to this automation pattern as “closed-loop automation” in that
268 it provides the necessary automation to proactively respond to network
269 and service conditions without human intervention. A high-level
270 schematic of the “closed-loop automation” and the various phases within
271 the service lifecycle using the automation is depicted in Figure 3.
273 Closed-loop control is provided by Data Collection, Analytics and Events
274 (DCAE) and other ONAP components. Collectively, they provide FCAPS
275 (Fault Configuration Accounting Performance Security) functionality.
276 DCAE collects performance, usage, and configuration data; provides
277 computation of analytics; aids in troubleshooting; and publishes events,
278 data and analytics (e.g., to policy, orchestration, and the data lake).
279 Another component, “Holmes”, connects to DCAE and provides alarm
280 correlation for ONAP.
282 Working with the Policy Framework and CLAMP, these components detect
283 problems in the network and identify the appropriate remediation. In
284 some cases, the action will be automatic, and they will notify Service
285 Orchestrator or one of the controllers to take action. In other cases,
286 as configured by the operator, they will raise an alarm but require
287 human intervention before executing the change.
291 \ **Figure 3:** ONAP Closed Loop Automation
296 ONAP provides common operational services for all ONAP components
297 including activity logging, reporting, common data layer, access
298 control, resiliency, and software lifecycle management. These services
299 provide access management and security enforcement, data backup,
300 restoration and recovery. They support standardized VNF interfaces and
303 Operating in a virtualized environment introduces new security challenges
304 and opportunities. ONAP provides increased security by embedding access controls
305 in each ONAP platform component, augmented by analytics and policy components
306 specifically designed for the detection and mitigation of security violations.
311 The ONAP project uses real-world use cases to help focus our releases.
312 For the first release of ONAP (“Beijing”), we introduce two use cases:
315 \ **Virtual CPE Use Case**
317 In this use case, many traditional network functions such as NAT,
318 firewall, and parental controls are implemented as virtual network
319 functions. These VNFs can either be deployed in the data center or at
320 the customer edge (or both). Also, some network traffic will be tunneled
321 (using MPLS VPN, VxLAN, etc.) to the data center, while other traffic
322 can flow directly to the Internet. A vCPE infrastructure allows service
323 providers to offer new value-added services to their customers with less
324 dependency on the underlying hardware.
326 In this use case, the customer has a physical CPE (pCPE) attached to a
327 traditional broadband network such as DSL (Figure 4). On top of this
328 service, a tunnel is established to a data center hosting various VNFs.
329 In addition, depending on the capabilities of the pCPE, some functions
330 can be deployed on the customer site.
332 This use case traditionally requires fairly complicated orchestration
333 and management, managing both the virtual environment and underlay
334 connectivity between the customer and the service provider. ONAP
335 supports such a use case with two key components – SDN-C, which manages
336 connectivity services, and APP-C, which manages virtualization services.
337 In this case, ONAP provides a common service orchestration layer for the
338 end-to-end service. It uses the SDN-C component to establish network
339 connectivity. Similarly, ONAP uses the APP-C component to manage the
340 virtualization infrastructure. Deploying ONAP in this fashion simplifies
341 and greatly accelerates the task of trialing and launching new
342 value-added services.
346 **Figure 4. ONAP vCPE Architecture**
348 Read the Residential vCPE Use Case with ONAP whitepaper to learn more.
350 **Voice over LTE (VoLTE) Use Case**
352 The second use case developed with Beijing is Voice over LTE. This use
353 case demonstrates how a Mobile Service Provider (SP) could deploy VoLTE
354 services based on SDN/NFV. The SP is able to onboard the service via
355 ONAP. Specific sub-use cases are:
359 - Service configuration
361 - Service termination
363 - Auto-scaling based on fault and/or performance
365 - Fault detection & correlation, and auto-healing
367 - Data correlation and analytics to support all sub use cases
369 To connect the different data centers, ONAP will also have to interface
370 with legacy systems and physical function to establish VPN connectivity
371 in a brown field deployment.
373 The VoLTE use case, shown in Figure 5, demonstrates the use of the VF-C
374 component and TOSCA-based data models to manage the virtualization
379 **Figure 5. ONAP VoLTE Architecture**
381 Read the VoLTE Use Case with ONAP whitepaper to learn more.
386 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.
388 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.
390 .. |image0| image:: media/ONAP-DTRT.png
393 .. |image1| image:: media/ONAP-toplevel.png
396 .. |image2| image:: media/ONAP-closedloop.png
399 .. |image3| image:: media/ONAP-vcpe.png
402 .. |image4| image:: media/ONAP-volte.png
Code Review / doc.git / blob