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