1 .. This work is licensed under a Creative Commons Attribution 4.0
2 International License. http://creativecommons.org/licenses/by/4.0
5 .. _onap-release-notes:
10 This page provides the release notes for the ONAP Istanbul release. This
11 includes details of software versions, known limitations, and outstanding
14 Release notes are cumulative for the release, meaning this release note will
15 have an entry for each Major, Minor, and Maintenance release, if applicable.
17 Each component within the ONAP solution maintains their own component level
18 release notes and links to those release notes are provided below.
19 Details on the specific items delivered in each release by each component is
20 maintained in the component specific release notes.
22 Istanbul Major Release 9.0.0
23 ============================
25 +--------------------------------------+--------------------------------------+
26 | **Project** | Open Network Automation Platform |
28 +--------------------------------------+--------------------------------------+
29 | **Release name** | Istanbul |
31 +--------------------------------------+--------------------------------------+
32 | **Release version** | 9.0.0 |
34 +--------------------------------------+--------------------------------------+
35 | **Release date** | November 15th 2021 |
37 +--------------------------------------+--------------------------------------+
41 ONAP Istanbul focusses on:
43 - Intent based networking (IBN) simplifies interaction and network
44 configuration by Control-Loop and Smart AI.
45 - Alignment with O-RAN Strategy to enable new RAN use cases
46 - Continued Cloud Native evolution with a rich feature set for CNF
47 orchestration capabilities
48 - Next level of functionality for 5G use cases including Network Slicing,
49 Performance management, SON, and CCVPN
50 - A second generation of control loop automation architecture
51 - New Network Function lifecycle management features based on real-life use
53 - New functionality for complex network configuration management
54 - Flexibility in resource onboarding with choice of modeling including SDC AID,
56 - Software quality and security improvements based on deployment experience
58 Functional Requirements
59 -----------------------
61 Increased Cloud Native Functionality
62 ....................................
63 Information about created CNF resources in k8s cluster are now available. This
64 information can be utilized later on i.e. in closed-loop context. CNF
65 Healthcheck Workflow in SO will let to monitor the status of CNF deployed into
66 k8s cluster and whether it is healthy or not. Further changes in k8splugin
67 related to Helm specification support allow for the better and more reliable
68 deployment of complex CNFs defined as a Helm package. ONAP now supports
69 Helm 3.5 package specification.
74 - Support for NSMF (Network Slice Management Function) based TN
75 (Transport Network) slices in which NSMF is responsible for TN-FH (FrontHaul)
76 and TN-MH (MidHaul) allocation
77 - RAN NSSMF (Network Slice Subnet Management Function) integration with CPS
78 (Configuration Persistence Service) and handled closed loop impacts
79 - POC on A1-interface for closed loop updates
80 - KPI Monitoring enhancements
82 Intent-based networking
83 .......................
84 The Intent Based Networking (IBN) use case includes the development of an
85 intent framework that contains intent modeling, intent translation, intent
86 execution and intent decision making. The intent UI is implemented in UUI
87 and the components of the intent framework interact with many components of
88 ONAP including SO, A&AI, Policy, DCAE, and CDS.
90 Control Loop evolutions
91 .......................
93 - CLAMP functionality is merged into Policy Framework project
94 - Control Loops can be defined and described in Metadata using TOSCA. Control
95 loops can run on the fly on any component that implements a *participant*
96 API. Control Loops can be commissioned into Policy/CLAMP, they can be
97 parameterized, initiated on arbitrary participants, activated and monitored
98 - Policy Handling Improvements: Support delta policies in PDPs
99 - CLAMP Client Policy and TOSCA Handling
100 - Policy Handling Improvements
101 - System Attribute Improvements
106 - Updates in fault management reporting and fault handling to be in line with
107 VES 7.2, 3GPP and smoother future alignment with O1 for OOF-SON
108 - Performance Management data collection control provides 5G network operators
109 with a dynamic and more efficient way to configure performance measurement
110 collection on a selected subset of PNFs/VNFs in the network and complements
111 the existing PM data collection and processing capabilities in ONAP/DCAE
112 - Simplified deployment for DCAE services via Helm
113 - Reduction on ONAP/DCAE footprint under transformation initiative by
114 deprecating Cloudify based platform components and Consul
115 - VES 7.2.1 integration for HV_VES enables ONAP, 3GPP, ORAN alignment
116 - Enhancements for Network Slicing, Bulk PM, OOF-SON usecases
118 Extended O-RAN Integration
119 ..........................
121 - Improvements for managing A1 Policies and terminating the A1 interface for
123 - A1 Adapter and A1 Policy Managements Enhancements
128 - SDN-C is based on OpenDaylight major release upgrade (Silicon)
129 - Enhancements to CCVPN, Network Slicing, and ONAP A1 Interface
134 - SDC can be used for onboarding resources and designing services with models
140 - Model updates as part of CCVPN Transport Slicing Feature
141 - Model updates as part of Smart Intent Guarantee based on IBN Feature
142 - Model updates as part of CNF Orchestration Feature
144 ONAP Operations Manager
145 .......................
147 - IPv4 / IPv6 dual stack support in ONAP: support for Kubernetes 1.20+
148 DualStack networking properties in ONAP K8S Service spec properties.
149 Upgraded EJBCA CMP v2 server to version 7.x
150 - CMPv2 enhancements: certificate update implemented using Key Update Request
151 (KUR) and Certificate Request (CR) CMPv2 messages
153 Non-Functional Requirements
154 ---------------------------
156 The following 'non-functional' requirements are followed in the
162 - ONAP shall use STDOUT for logs collection
163 - IPv4/IPv6 dual stack support in ONAP
164 - Containers must crash properly when a failure occurs
165 - Containers must have no more than one main process
166 - Application config should be fully prepared before starting the
167 application container
168 - No root (superuser) access to database from application container
173 - Each ONAP project shall improve its CII Badging score by improving input
174 validation and documenting it in their CII Badging site
175 - Each ONAP project shall define code coverage improvements and achieve at
176 least 55% code coverage
181 - Python language 3.8
183 - All containers must run as non-root user
184 - Continue hardcoded passwords removal
185 - Flow management must be activated for ONAP
186 - Each project will update the vulnerable direct dependencies in their code
192 - Interactive architecture map including short description and link to detailed
193 documentation for every architecture building block
194 - Changes in the Sphinx configuration for all contributing projects
195 - Guide to set up a documentation development environment with preview function
200 - New E2E tests: basic_cnf
201 - New tests: CPS healthcheck
202 - Stability tests: basic_vm and basic_onboard
205 Some non-functional requirements are not fully finalized. Please, check details
206 on the :ref:`Integration<onap-integration:release_non_functional_requirements>`
208 Project Specific Release Notes
209 ==============================
210 ONAP releases are specified by a list of project artifact versions in the
211 project repositories and docker container image versions listed in the OOM
214 Each project provides detailed :ref:`release notes<doc-releaserepos>`
215 and prepends to these if/when any updated versions the project team believes
216 are compatible with a major release are made available.
220 ONAP Istanbul Release provides a set selection of documents,
221 see :ref:`ONAP Documentation<master_index>`.
223 The `developer wiki <http://wiki.onap.org>`_ remains a good source of
224 information on meeting plans and notes from committees, project teams and
229 Details about discovered and mitigated vulnerabilities are in
230 :ref:`ONAP Security <onap-osa:onap-security>`
232 ONAP has adopted the `CII Best Practice Badge Program <https://bestpractices.coreinfrastructure.org/en>`_.
234 - `Badging Requirements <https://github.com/coreinfrastructure/best-practices-badge>`_
235 - `Badging Status for all ONAP projects <https://bestpractices.coreinfrastructure.org/en/projects?q=onap>`_
237 In the Istanbul release,
239 - 100% projects passed 90% of the CII badge
240 - 85% projects passed the CII badge
241 - 11% projects passed the CII Silver badge
243 Project specific details are in the :ref:`release notes<doc-releaserepos>` for
248 ONAP Maturity Testing Notes
249 ===========================
250 For the Istanbul release, ONAP continues to improve in multiple areas of
251 Scalability, Security, Stability and Performance (S3P) metrics.
253 In Istanbul the Integration team focussed in
255 - Automating ONAP Testing to improve the overall quality
256 - Adding security and E2E tests
258 More details in :ref:`ONAP Integration Project<onap-integration:master_index>`
260 Known Issues and Limitations
261 ============================
262 Known Issues and limitations are documented in each
263 :ref:`project Release Notes <doc-releaserepos>`.