diff options
author | Andreas Geissler <andreas-geissler@telekom.de> | 2020-12-07 08:30:45 +0000 |
---|---|---|
committer | Gerrit Code Review <gerrit@onap.org> | 2020-12-07 08:30:45 +0000 |
commit | b450cf3ec8d89c5a8e21afaf8fe9af4a57f482e7 (patch) | |
tree | ec43235f66d9c2c77ea03a9d50598e8a18ed9ca8 | |
parent | b7ac9e9889e9819b3b6fca99c1f18484433b1093 (diff) | |
parent | ae97753f82eb63f7d8d701247febc40298fed8c0 (diff) |
Merge "Update architecture section"
-rw-r--r-- | .vscode/settings.json | 3 | ||||
-rw-r--r-- | docs/guides/onap-developer/architecture/media/ONAP-architecture.png | bin | 131064 -> 130630 bytes | |||
-rw-r--r-- | docs/guides/onap-developer/architecture/onap-architecture.rst | 407 |
3 files changed, 208 insertions, 202 deletions
diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 000000000..12ff2fdb0 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "restructuredtext.confPath": "${workspaceFolder}/docs" +}
\ No newline at end of file diff --git a/docs/guides/onap-developer/architecture/media/ONAP-architecture.png b/docs/guides/onap-developer/architecture/media/ONAP-architecture.png Binary files differindex 0e7c69548..a390fae79 100644 --- a/docs/guides/onap-developer/architecture/media/ONAP-architecture.png +++ b/docs/guides/onap-developer/architecture/media/ONAP-architecture.png diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst index 92db75887..d94e42890 100644 --- a/docs/guides/onap-developer/architecture/onap-architecture.rst +++ b/docs/guides/onap-developer/architecture/onap-architecture.rst @@ -8,6 +8,12 @@ Introduction ============ +ONAP is a comprehensive platform for orchestration, management, and automation +of network and edge computing services for network operators, cloud providers, +and enterprises. Real-time, policy-driven orchestration and automation of +physical, virtual, and cloud native network functions enables rapid automation +of new services and complete lifecycle management critical for 5G and +next-generation networks. The ONAP project addresses the rising need for a common automation platform for telecommunication, cable, and cloud service providers—and their solution @@ -21,22 +27,22 @@ in some cases, upgrading on-premises customer equipment. Many are seeking to exploit SDN and NFV to improve service velocity, simplify equipment interoperability and integration, and to reduce overall CapEx and OpEx costs. In addition, the current, highly fragmented management landscape makes it -difficult to monitor and guarantee service-level agreements (SLAs). These -challenges are still very real now as ONAP creates its fourth release. +difficult to monitor and guarantee service-level agreements (SLAs). ONAP is addressing these challenges by developing global and massive scale -(multi-site and multi-VIM) automation capabilities for both physical and -virtual network elements. It facilitates service agility by supporting data -models for rapid service and resource deployment and providing a common set of -northbound REST APIs that are open and interoperable, and by supporting +(multi-site and multi-VIM) automation capabilities for physical, virtual, and +cloud native network elements. It facilitates service agility by supporting +data models for rapid service and resource deployment and providing a common +set of northbound REST APIs that are open and interoperable, and by supporting model-driven interfaces to the networks. ONAP’s modular and layered nature improves interoperability and simplifies integration, allowing it to support -multiple VNF environments by integrating with multiple VIMs, VNFMs, -SDN Controllers, as well as legacy equipment (PNF). ONAP’s consolidated xNF -requirements publication enables commercial development of ONAP-compliant xNFs. -This approach allows network and cloud operators to optimize their physical -and virtual infrastructure for cost and performance; at the same time, ONAP’s -use of standard models reduces integration and deployment costs of +multiple VNF environments by integrating with multiple VIMs, VNFMs, SDN +Controllers, as well as legacy equipment (PNF). The Service Design & Creation +(SDC) project also offers seamless orchestration of CNFs. ONAP’s consolidated +xNF requirements publication enables commercial development of ONAP-compliant +xNFs. This approach allows network and cloud operators to optimize their +physical and virtual infrastructure for cost and performance; at the same time, +ONAP’s use of standard models reduces integration and deployment costs of heterogeneous equipment. All this is achieved while minimizing management fragmentation. @@ -47,16 +53,14 @@ that supports real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three major requirements: -- A robust design framework that allows the specification of the service in - all aspects – modeling the resources and relationships that make up the - service, specifying the policy rules that guide the service behavior, - specifying the applications, analytics and closed control loop events needed - for the elastic management of the service - -- An orchestration and control framework (Service Orchestrator and Controllers - ) that is recipe/ policy-driven to provide an automated instantiation of the +- A robust design framework that allows the specification of the service in all + aspects – modeling the resources and relationships that make up the service, + specifying the policy rules that guide the service behavior, specifying the + applications, analytics and closed control loop events needed for the elastic + management of the service +- An orchestration and control framework (Service Orchestrator and Controllers) + that is recipe/ policy-driven to provide an automated instantiation of the service when needed and managing service demands in an elastic manner - - An analytic framework that closely monitors the service behavior during the service lifecycle based on the specified design, analytics and policies to enable response as required from the control framework, to deal with @@ -66,24 +70,25 @@ requirements: To achieve this, ONAP decouples the details of specific services and supporting technologies from the common information models, core orchestration platform, and generic management engines (for discovery, provisioning, assurance etc.). + Furthermore, it marries the speed and style of a DevOps/NetOps approach with -the formal models and processes operators require to introduce new services -and technologies. It leverages cloud-native technologies including Kubernetes -to manage and rapidly deploy the ONAP platform and related components. This is -in stark contrast to traditional OSS/Management software platform -architectures, which hardcoded services and technologies, and required lengthy -software development and integration cycles to incorporate changes. +the formal models and processes operators require to introduce new services and +technologies. It leverages cloud-native technologies including Kubernetes to +manage and rapidly deploy the ONAP platform and related components. This is in +stark contrast to traditional OSS/Management software platform architectures, +which hardcoded services and technologies, and required lengthy software +development and integration cycles to incorporate changes. The ONAP Platform enables service/resource independent capabilities for design, creation and lifecycle management, in accordance with the following foundational principles: - Ability to dynamically introduce full service lifecycle orchestration (design - ,provisioning and operation) and service API for new services and + , provisioning and operation) and service API for new services and technologies without the need for new platform software releases or without affecting operations for the existing services -- Carrier-grade scalability including horizontal scaling (linear scale-out) and - distribution to support a large number of services and large networks +- Scalability and distribution to support a large number of services and large + networks - Metadata-driven and policy-driven architecture to ensure flexible and automated ways in which capabilities are used and delivered - The architecture shall enable sourcing best-in-class components @@ -113,20 +118,18 @@ which highlights the role of a few key components: designing required services. #. External API provides northbound interoperability for the ONAP Platform and Multi-VIM/Cloud provides cloud interoperability for the ONAP workloads. -#. OOM provides the ability to manage cloud-native installation and - deployments to Kubernetes-managed cloud environments. -#. ONAP Shared Services provides shared capabilities for ONAP modules. MUSIC - allows ONAP to scale to multi-site environments to support global scale - infrastructure requirements. The ONAP Optimization Framework (OOF) provides - a declarative, policy-driven approach for creating and running optimization - applications like Homing/Placement, and Change Management Scheduling - Optimization. Logging provides centralized logging capabilities, Audit - (POMBA) provides capabilities to understand orchestration actions. +#. OOM provides the ability to manage cloud-native installation and deployments + to Kubernetes-managed cloud environments. +#. ONAP Shared Services provides shared capabilities for ONAP modules. The ONAP + Optimization Framework (OOF) provides a declarative, policy-driven approach + for creating and running optimization applications like Homing/Placement, + and Change Management Scheduling Optimization. #. ONAP shared utilities provide utilities for the support of the ONAP components. #. Information Model and framework utilities continue to evolve to harmonize the topology, workflow, and policy models from a number of SDOs including - ETSI NFV MANO, TM Forum SID, ONF Core, OASIS TOSCA, IETF, and MEF. + ETSI NFV MANO, ETSI/3GPP, O-RAN, TM Forum SID, ONF Core, OASIS TOSCA, IETF, + and MEF. |image2| @@ -140,11 +143,11 @@ sophisticated initial deployment as well as post- deployment management. The ONAP deployment methodology needs to be flexible enough to suit the different scenarios and purposes for various operator environments. Users may also want to select a portion of the ONAP components to integrate into their -own systems. And the platform needs to be highly reliable, scalable, secure and -easy to manage. To achieve all these goals, ONAP is designed as a +own systems. And the platform needs to be highly reliable, scalable, secure +and easy to manage. To achieve all these goals, ONAP is designed as a microservices-based system, with all components released as Docker containers following best practice building rules to optimize their image size. To reduce -the ONAP footprint, a first effort to use shared data base have been initiated +the ONAP footprint, a first effort to use a shared database has been initiated with a Cassandra and mariadb-galera clusters. The ONAP Operations Manager (OOM) is responsible for orchestrating the @@ -171,15 +174,15 @@ container management system and Consul to provide the following functionality: OOM supports a wide variety of cloud infrastructures to suit your individual requirements. -Microservices Bus (MSB) provides fundamental microservices supports including +Microservices Bus (MSB) provides fundamental microservices support including service registration/ discovery, external API gateway, internal API gateway, client software development kit (SDK), and Swagger SDK. When integrating with OOM, MSB has a Kube2MSB registrar which can grasp services information from k8s metafile and automatically register the services for ONAP components. In the spirit of leveraging the microservice capabilities, further steps -towards increased modularity have been taken. Service -Orchestrator (SO) and the controllers have increased its level of modularity. +towards increased modularity have been taken. Service Orchestrator (SO) and the +controllers have increased its level of modularity. Portal ====== @@ -187,46 +190,48 @@ ONAP delivers a single, consistent user experience to both design time and runtime environments, based on the user’s role. Role changes are configured within a single ONAP instance. -This user experience is managed by the ONAP Portal, which provides access to -design, analytics and operational control/administration functions via a -shared, role-based menu or dashboard. The portal architecture provides -web-based capabilities such as application onboarding and management, -centralized access management through the Authentication and Authorization -Framework (AAF), and dashboards, as well as hosted application widgets. +This user experience is managed by the ONAP +Portal, which provides access to design, analytics and operational control/ +administration functions via a shared, role-based menu or dashboard. The portal +architecture provides web-based capabilities such as application onboarding and +management, centralized access management through the Authentication and +Authorization Framework (AAF), and dashboards, as well as hosted application +widgets. The portal provides an SDK to enable multiple development teams to adhere to consistent UI development requirements by taking advantage of built-in capabilities (Services/ API/ UI controls), tools and technologies. ONAP also provides a Command Line Interface (CLI) for operators who require it (e.g., to -integrate with their scripting environment). ONAP SDKs enable -operations/security, third parties (e.g., vendors and consultants), and other -experts to continually define/redefine new collection, analytics, and policies -(including recipes for corrective/remedial action) using the ONAP Design -Framework Portal. +integrate with their scripting environment). ONAP SDKs enable operations/ +security, third parties (e.g., vendors and consultants), and other experts to +continually define/redefine new collection, analytics, and policies (including +recipes for corrective/remedial action) using the ONAP Design Framework Portal. Design Time Framework ===================== -The design time framework is a comprehensive development environment with -tools, techniques, and repositories for defining/ describing resources, -services, and products. +The design time framework is a comprehensive development environment with tools +, techniques, and repositories for defining/ describing resources, services, +and products. The design time framework facilitates reuse of models, further improving efficiency as more and more models become available. Resources, services, -products, and their management and control functions can all be modeled using -a common set of specifications and policies (e.g., rule sets) for controlling +products, and their management and control functions can all be modeled using a +common set of specifications and policies (e.g., rule sets) for controlling behavior and process execution. Process specifications automatically sequence instantiation, delivery and lifecycle management for resources, services, products and the ONAP platform components themselves. Certain process -specifications (i.e., ‘recipes’) and policies are geographically distributed -to optimize performance and maximize autonomous behavior in federated cloud +specifications (i.e., ‘recipes’) and policies are geographically distributed to +optimize performance and maximize autonomous behavior in federated cloud environments. Service Design and Creation (SDC) provides tools, techniques, and repositories to define/simulate/certify system assets as well as their associated processes -and policies. Each asset is categorized into one of four asset groups: -Resource, Services, Products, or Offers. SDC also supports TOSCA1.3 List type -definition which provides the ability to design complicated -service descriptor. +and policies. Each asset is categorized into one of four asset groups: Resource +, Services, Products, or Offers. SDC supports the onboarding of Network +Services packages (ETSI SOL 0007 ), CNF packages (Helm), VNF packages (Heat or +ETSI SOL004) and PNF packages (ETSI SOL004). SDC also includes some +capabilities to model 5G network slicing using the standard properties (Slice +Profile, Service Template). The SDC environment supports diverse users via common services and utilities. Using the design studio, product and service designers onboard/extend/retire @@ -240,9 +245,9 @@ packaging and validation tools in the VNF Supplier API and Software Development Kit (VNF SDK) and VNF Validation Program (VVP) components. Vendors can integrate these tools in their CI/CD environments to package VNFs and upload them to the validation engine. Once tested, the VNFs can be onboarded through -SDC. In addition, the testing capability of VNFSDK is being utilized at the -LFN Compliance Verification Program to work towards ensuring a highly -consistent approach to VNF verification. +SDC. In addition, the testing capability of VNFSDK is being utilized at the LFN +Compliance Verification Program to work towards ensuring a highly consistent +approach to VNF verification. The Policy Creation component deals with policies; these are rules, conditions, requirements, constraints, attributes, or needs that must be provided, @@ -254,20 +259,18 @@ of the evaluated policies appropriate to the conditions). Policy allows rapid modification through easily updating rules, thus updating technical behaviors of components in which those policies are used, without -requiring rewrites of their software code. Policy permits simpler management -/ control of complex mechanisms via abstraction. +requiring rewrites of their software code. Policy permits simpler +management / control of complex mechanisms via abstraction. Runtime Framework ================= The runtime execution framework executes the rules and policies and other models distributed by the design and creation environment. -This allows for the distribution of models and policy among -various ONAP modules such as the Service Orchestrator (SO), Controllers, -Data Collection, Analytics and Events (DCAE), Active and Available Inventory -(A&AI). These components use common services that -support logging, access control, Multi-Site State Coordination (MUSIC), which -allow the platform to register and manage state across multi-site deployments. +This allows for the distribution of models and policy among various ONAP +modules such as the Service Orchestrator (SO), Controllers, Data Collection, +Analytics and Events (DCAE), Active and Available Inventory (A&AI). These +components use common services that support access control. Orchestration ------------- @@ -275,11 +278,9 @@ The Service Orchestrator (SO) component executes the specified processes by automating sequences of activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services and resources, this includes VNFs, CNFs and PNFs. -The SO provides orchestration at a very high level, with an end-to-end view of -the infrastructure, network, and applications. - -One is BroadBand Service (BBS), the second one is Cross Domain and Cross Layer -VPN (CCVPN). +The SO provides orchestration at a very high level, with an end-to-end view +of the infrastructure, network, and applications. Examples of this include +BroadBand Service (BBS) and Cross Domain and Cross Layer VPN (CCVPN). Virtual Infrastructure Deployment (VID) --------------------------------------- @@ -299,15 +300,14 @@ constraints including capacity, location, platform capabilities, and other service specific constraints. ONAP Multi-VIM/Cloud (MC) and several other ONAP components such as Policy, SO, -A&AI etc. play an important role in enabling “Policy-driven -Performance/Security-Aware Adaptive Workload Placement/ Scheduling” across -cloud sites through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA), -cloud agnostic Intent capabilities, and real-time capacity checks provided by -ONAP MC to determine the optimal VIM/Cloud instances, which can deliver the -required performance SLAs, for workload (VNF etc.) placement and scheduling -(Homing). Operators now realize the true value of virtualization through fine -grained optimization of cloud resources while delivering performance and -security SLAs. +A&AI etc. play an important role in enabling “Policy-driven Performance/ +Security-Aware Adaptive Workload Placement/ Scheduling” across cloud sites +through OOF-HAS. OOF-HAS uses Hardware Platform Awareness (HPA), cloud agnostic +Intent capabilities, and real-time capacity checks provided by ONAP MC to +determine the optimal VIM/Cloud instances, which can deliver the required +performance SLAs, for workload (VNF etc.) placement and scheduling (Homing). +Operators now realize the true value of virtualization through fine grained +optimization of cloud resources while delivering performance and security SLAs. Controllers ----------- @@ -324,6 +324,19 @@ the associated physical COTS server infrastructure. VF-C provides a generic VNFM capability but also integrates with external VNFMs and VIMs as part of an NFV MANO stack. +The Controller Design Studio (CDS) community in ONAP has contributed a +framework to automate the resolution of resources for instantiation and any +config provisioning operation, such as day0, day1 or day2 configuration. The +essential function of CDS is to create and populate a controller blueprint, +create a configuration file from this Controller blueprint, and associate at +design time this configuration file (configlet) to a PNF/VNF/CNF during the +design phase. CDS removes dependence on code releases and the delays they cause +and puts the control of services into the hands of the service providers. Users +can change a model and its parameters with great flexibility to fetch data from +external systems (e.g. IPAM) that is required in real deployments. This makes +service providers more responsive to their customers and able to deliver +products that more closely match the needs of those customers. + Inventory --------- Active and Available Inventory (A&AI) provides real-time views of a system’s @@ -351,25 +364,28 @@ design capabilities in SDC, simplifying the design process. Multi Cloud Adaptation ---------------------- Multi-VIM/Cloud provides and infrastructure adaptation layer for VIMs/Clouds -in exposing advanced hardware platform awareness and cloud agnostic intent -capabilities, besides standard capabilities, which are used by OOF and other -components for enhanced cloud selection and SO/VF-C for cloud agnostic workload -deployment. +and K8s clusters in exposing advanced hardware platform awareness and cloud +agnostic intent capabilities, besides standard capabilities, which are used by +OOF and other components for enhanced cloud selection and SO/VF-C for cloud +agnostic workload deployment. The K8s plugin is in charge to deploy the CNF on +the Kubernetes clusters using Kubernetes API. Closed Control Loop Automation ============================== Closed loop control is provided by cooperation among a number of design-time and run-time elements. The Runtime loop starts with data collectors from Data -Collection, Analytics and Events (DCAE). ONAP includes the following -collectors: VES for events, HV-VES for high-volume events, SNMP for SNMP traps, -File Collector to receive files, and Restconf Collector to collect the -notifications. After data collection/verification phase, data are moved through -the loop of micro-services like Homes for event detection, Policy for -determining actions, and finally, controllers and orchestrators to implement -actions CLAMP is used to monitor the loops themselves. DCAE also supports -(Platform for Network Data Analytics) PNDA analytics capabilities. CLAMP, -Policy and DCAE all have design time aspects to support the creation of the -loops. +Collection, Analytics and Events (DCAE). ONAP includes the following collectors +: VES (VNF Event Streaming) for events, HV-VES for high-volume events, SNMP +for SNMP traps, File Collector to receive files, and RESTCONF Collector to +collect the notifications. After data collection/verification phase, data are +moved through the loop of micro-services like Homes for event detection, Policy +for determining actions, and finally, controllers and orchestrators to +implement actions CLAMP is used to monitor the loops themselves. DCAE also +includes a number of specialized micro-services to support some use-cases such +as the Slice Analysis or SON-Handler. Some dedicated event processor modules +transform collected data (SNMP, 3GPP XML, RESTCONF) to VES format and push the +various data onto data lake. CLAMP, Policy and DCAE all have design time +aspects to support the creation of the loops. We refer to this automation pattern as “closed control loop automation” in that it provides the necessary automation to proactively respond to network and @@ -383,10 +399,6 @@ Collectively, they provide FCAPS (Fault Configuration Accounting Performance Security) functionality. DCAE collects performance, usage, and configuration data; provides computation of analytics; aids in troubleshooting; and publishes events, data and analytics (e.g., to policy, orchestration, and the data lake). -Another component, “Holmes”, connects to DCAE and provides alarm correlation -for ONAP, new data collection capabilities with High Volume VES, and bulk -performance management support. - Working with the Policy Framework and CLAMP, these components detect problems in the network and identify the appropriate remediation. In some cases, the action will be automatic, and they will notify Service Orchestrator or one of @@ -418,7 +430,6 @@ ONAP Modeling ============= ONAP provides models to assist with service design, the development of ONAP service components, and with the improvement of standards interoperability. - Models are an essential part for the design time and runtime framework development. The ONAP modeling project leverages the experience of member companies, standard organizations and other open source projects to produce @@ -434,7 +445,6 @@ The modeling project includes the ETSI catalog component, which provides the parser functionalities, as well as additional package management functionalities. - Industry Alignment ================== ONAP support and collaboration with other standards and open source communities @@ -447,20 +457,16 @@ is evident in the architecture. - Further collaboration includes 5G/ORAN & 3GPP Harmonization, Acumos DCAE Integration, and CNCF Telecom User Group (TUG). -Read this whitepaper for more information: The Progress of ONAP: Harmonizing -Open Source and Standards. +Read this whitepaper for more information: +`The Progress of ONAP: Harmonizing Open Source and Standards <https://www.onap.org/wp-content/uploads/sites/20/2019/04/ONAP_HarmonizingOpenSourceStandards_032719.pdf>`_ ONAP Blueprints =============== ONAP can support an unlimited number of use cases, within reason. However, to provide concrete examples of how to use ONAP to solve real-world problems, the -community has created a set of blueprints. In addition to helping users -rapidly adopt the ONAP platform through end-to-end solutions, these blueprints -also help the community prioritize their work. With the ONAP Frankfurt release, -we introduced a new blueprint in the area of optical transport networking -called Multi-Domain Optical Network Service (MDONS). Prior blueprints were -vCPE, VoLTE, vFW/vDNS, 5G, and CCVPN. 5G and CCVPN underwent feature -enhancements during the Frankfurt release. +community has created a set of blueprints. In addition to helping users rapidly +adopt the ONAP platform through end-to-end solutions, these blueprints also +help the community prioritize their work. 5G Blueprint ------------ @@ -493,11 +499,11 @@ case. Virtual CPE (vCPE) .................. -Currently, services offered to a subscriber are restricted to what is -designed into the broadband residential gateway. In the blueprint, the customer -has a slimmed down physical CPE (pCPE) attached to a traditional broadband -network such as DSL, DOCSIS, or PON (Figure 5). A tunnel is established to a -data center hosting various VNFs providing a much larger set of services to the +Currently, services offered to a subscriber are restricted to what is designed +into the broadband residential gateway. In the blueprint, the customer has a +slimmed down physical CPE (pCPE) attached to a traditional broadband network +such as DSL, DOCSIS, or PON (Figure 5). A tunnel is established to a data +center hosting various VNFs providing a much larger set of services to the subscriber at a significantly lower cost to the operator. In this blueprint, ONAP supports complex orchestration and management of open source VNFs and both virtual and underlay connectivity. @@ -511,15 +517,14 @@ to learn more. Broadband Service (BBS) ....................... -This blueprint provides multi-gigabit residential -internet connectivity services based on PON (Passive Optical Network) access -technology. A key element of this blueprint is to show automatic -re-registration of an ONT (Optical Network Terminal) once the subscriber moves -(nomadic ONT) as well as service subscription plan changes. This blueprint uses -ONAP for the design, deployment, lifecycle management, and service assurance of -broadband services. It further shows how ONAP can orchestrate services across -different locations (e.g. Central Office, Core) and technology domains (e.g. -Access, Edge). +This blueprint provides multi-gigabit residential internet connectivity +services based on PON (Passive Optical Network) access technology. A key +element of this blueprint is to show automatic re-registration of an ONT +(Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as +service subscription plan changes. This blueprint uses ONAP for the design, +deployment, lifecycle management, and service assurance of broadband services. +It further shows how ONAP can orchestrate services across different locations +(e.g. Central Office, Core) and technology domains (e.g. Access, Edge). |image6| @@ -531,17 +536,18 @@ to learn more. Voice over LTE (VoLTE) Blueprint -------------------------------- This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE -blueprint incorporates commercial VNFs to create and manage the underlying vEPC -and vIMS services by interworking with vendor-specific components, including -VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and a Core Data -Center. ONAP supports the VoLTE use case with several key components: SO, VF-C, -SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is responsible for VoLTE -end-to-end service orchestration working in collaboration with VF-C and SDN-C. -SDN-C establishes network connectivity, then the VF-C component completes the -Network Services and VNF lifecycle management (including service initiation, -termination and manual scaling) and FCAPS (fault, configuration, accounting, -performance, security) management. This blueprint also shows advanced -functionality such as scaling and change management. +blueprint incorporates commercial VNFs to create and manage the underlying +vEPC and vIMS services by interworking with vendor-specific components, +including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and +a Core Data Center. ONAP supports the VoLTE use case with several key +components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is +responsible for VoLTE end-to-end service orchestration working in collaboration +with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C +component completes the Network Services and VNF lifecycle management +(including service initiation, termination and manual scaling) and FCAPS +(fault, configuration, accounting, performance, security) management. This +blueprint also shows advanced functionality such as scaling and change +management. |image7| @@ -550,14 +556,13 @@ functionality such as scaling and change management. Read the `VoLTE Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf>`_ to learn more. - Optical Transport Networking (OTN) ---------------------------------- Two ONAP blueprints (CCVPN and MDONS) address the OTN use case. CCVPN addresses Layers 2 and 3, while MDONS addresses Layers 0 and 1. CCVPN (Cross Domain and Cross Layer VPN) Blueprint --------------------------------------------------- +.................................................. CSPs, such as CMCC and Vodafone, see a strong demand for high-bandwidth, flat, high-speed OTN (Optical Transport Networks) across carrier networks. They also want to provide a high-speed, flexible and intelligent service for high-value @@ -578,17 +583,15 @@ completes the Network Services and VNF lifecycle management. ONAP peering across CSPs uses an east-west API which is being aligned with the MEF Interlude API. The key innovations in this use case are physical network discovery and modeling, cross-domain orchestration across multiple physical networks, cross -operator end-to-end service provisioning, close-loop reroute for -cross-domain service, dynamic changes (branch sites, VNFs) and intelligent -service optimization (including AI/ML). The Frankfurt release adds support for -end-to-end E-LINE services over optical transport network (OTN) -network-to-network interface (NNI). +operator end-to-end service provisioning, close-loop reroute for cross-domain +service, dynamic changes (branch sites, VNFs) and intelligent service +optimization (including AI/ML). Read the `CCVPN Blueprint <https://www.onap.org/wp-content/uploads/sites/20/2019/07/ONAP_CaseSolution_CCVPN_062519.pdf>`_ to learn more. MDONS (Multi-Domain Optical Network Service) Blueprint ------------------------------------------------------- +...................................................... While CCVPN addresses the automation of networking layers 2 and 3, it does not address layers 0 and 1. Automating these layers is equally important because providing an end-to-end service to their customers often requires a manual and @@ -613,64 +616,64 @@ vLoadBalancer. The blueprint exercises most aspects of ONAP, showing VNF onboarding, network service creation, service deployment and closed-loop automation. The key components involved are SDC, CLAMP, SO, APP-C, DCAE and Policy. In the recent releases, the vFW blueprint has been demonstrated by -using a mix of a CNF and VNF and entirely using CNFs. +using a mix of a CNF and VNF and entirely using CNFs. Verified end to end tests ========================= Use cases --------- -Various use cases have been tested for the Release. Detailed information can -be found in :ref:`Verified Use Cases<onap-integration:docs_usecases>`. - -- vFirewall with closed loop -- vFirewall/vDNS with HPA -- vFirewall In-Place Software Upgrade with Traffic Distribution -- vFirewall CNF With CDS -- Scale Out -- CCVPN-E LINE over OTN NNI -- CCVPN - MDONS -- BBS (Broadband Service) -- vFirewall CNF with multicloud k8s plugin -- EdgeXFoundry CNF with multicloud k8s plugin -- vCPE with Tosca -- E2E Automation vLB with CDS +Various use cases have been tested for the Release. Use case examples are +listed below. See detailed information on use cases, functional requirements, +and automated use cases can be found here: +:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`. + +- E2E Network Slicing +- 5G OOF (ONAP Optimization Framework) SON (Self-Organized Network) +- CCVPN-Transport Slicing +- MDONS (Multi-Domain Optical Network Service) Functional requirements ----------------------- -Various functional requirements have been tested for the Release. Detailed -information can be found in -:ref:`Verified Use Cases<onap-integration:docs_usecases>`. - -- PNF Software Upgrade using direct Netconf Yang interface with PNF -- PNF Software Upgrade with EM with Ansible -- PNF Software Upgrade with EM with Netconf -- VSP Compliance and Validation Check within SDC -- Enable PNF software version at onboarding -- xNF communication security enhancements -- ETSI Alignment SO plugin to support SOL003 to connect to an external VNFM -- Integration of CDS as an Actor -- 3rd Party Operational Domain Manager -- Configuration & persistency -- 5G functional requirements - - - 5G Realtime PM and High Volume Stream Data Collection - - 5G PNF Plug and Play - - 5G Bulk PM - - 5G OOF and PCI - - 5G NRM Network Resource Model (Configuration management) - - 5G NETCONF configuration - - 5G PNF Pre-Onboarding & Onboarding - - 5G OOF SON - - 5G E2E Network Slicing - - 5G ORAN A1 Adapter (SDNR) +Various functional requirements have been tested for the Release. Detailed +information can be found in the +:ref:`Verified Use Cases<onap-integration:docs_usecases_release>`. + +- xNF Integration + + - ONAP CNF orchestration - Enhancements + - PNF PreOnboarding + - PNF Plug & Play + +- Lifecycle Management + + - Policy Based Filtering + - Bulk PM / PM Data Control Extension + - Support xNF Software Upgrade in association to schema updates + - Configuration & Persistency Service + +- Security + + - CMPv2 Enhancements + +- Standard alignment + + - ETSI-Alignment for Guilin + - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES + - Extend ORAN A1 Adapter and add A1 Policy Management + +- NFV testing Automatic Platform + + - Support for Test Result Auto Analysis & Certification + - Support for Test Task Auto Execution + - Support for Test Environment Auto Deploy + - Support for Test Topology Auto Design Conclusion ========== -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. +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. By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a globally shared architecture and implementation for network |