Page Comparison

• Implemented new parent POM under org.onap.aai.aai-common.aai-parent for simplified management of 3rd party dependencies
• Upgrade to spring-boot 2 (partially complete)
• Model updates and edge rules changes in support of the following use cases:
  • CCVPN for SOTN NNI
  • 5G Network Slicing
  • Multi-Domain Optical Network Services
  • PNF enhancements
• Papyrus XMI UML files for run-time data model reverse engineering
• Integration with sonarcloud

• Integration of CMPv2 client and CA server

Features:

• Resource resolution via CDS
• ODL Neon SR1 update with  ONAP distribution
• vnfc/vf-module/v-server operations support for ansible LCMs
• New LCM commands implemented:
  • ActivateNESw
  • ConfigScaleIn
  • DownloadNESw
  • GetConfig   
  • LicenseManagement 
  • PostEvacuate 
  • PostMigrate  
  • PostRebuild  
  • PreConfigure  
  • PreEvacuate 
  • PreMigrate 
  • PreRebuild   
  • Provisioning  
  • StartTraffic  
  • StatusTraffic 
  • StopTraffic   
• Move northbound DMAAP adapter out from ODL OSGI Karaf base

Security:

• Removed hardcoded password for Maria DB
• Moved to non root processes for all APPC Pods
• Moved All connections to https
• Openstack password encrypted 
• Fixed SQL injection vulnerability

Quality:

• Test Coverage rate reaches 80%

• Improve model driven control implementation by:
  1. Implementing a new Control Loop creation flow: Self Serve Control Loop(partially done will be continued in next release).
  2. Adding Tosca policy-model support for Operational Policies definitions.
• Add integration to CDS for Actor/Action selection.
• Move from SearchGuard to OpenDistro for the ELK stack based Control Loop Dashboard.
• Improve security by:
  1. Removing even more vulnerabilities from the code at the point that there is none today!.
  2. Implementing all the SECCOM must have User Stories.

1. Move closer to a full model driven Control Loop end to end in ONAP (from SDC, to Policy, to CLAMP to DCAE).
2. Improve Security and Vulnarabilities.

For the Frankfurt Release, much of the work in CCSDK was focused on extending the Controller Design Studio (CDS) platform.  This work is described in more detail below (see 71833544 row below).

DCAE Platform Enhancement

• Introduction of Microservice and Onboarding Design (MOD) platform

MOD platform will eventually replace SDC_DCAE-DesignStudio. For Frankfurt, DCAE-MOD can be used to onboard DCAE components,compose flows (Service composition), generate and distribute dynamic blueprints into DCAE Platform/Runtime - enabling users to onboard and deploy MS on-demand

• Policy-Handler enhancement to support Policy update notification through DMaaP

DCAE Platform (Policy-Handler) enhancement enables automated policy based reconfiguration for DCAE MS in near real-time manner.

• Dynamic AAF certificate creation during component instantiation
• Helm chart optimization to control each platform component separate
• Dashboard Optimization
• Blueprint generator tool to simplify deployment artifact creation
• Deployment/bootstrap optimization

Following are new services components are delivered with Frankfurt. New DCAE service components delivered add into expanding ONAP/DCAE MS catalog; this enables new usecase support and data/analytics integration capabilties.  

• Event Processors
  • PM Subscription Handler
  • DataLake Handlers
• Analytics/RCA
  • TCA-GEN2
• Acumos Adapter (PoC)

Acumos Adapter provides mechanism to onboard Models from Acumos into ONAP and onboard (through MOD into DCAE). This enables designer to use this model for deploying  catalog for designers 

Security Improvements

• Python 3.x migration
• Java 11 migration (VES, HV_VES, BBS-EP, SDK)
• Resolved all outstanding OJSI
• Switched external interfaces to HTTPS (VES, Dashboard, HV_VES)

DMaaP DR
Dynamic cert distribution from OOM AAF
Implement boolean flag in OOM to disable HTTP ports
Added more test cases
Addressed SECCOM/OJSI must have stories
Disabled external facing HTTP ports

DMaaP MR
Enhance to protect all update operations in Kafka
Create Kafka image using Confluent 5.3.0
Create custom Zookeeper image using confluent 5.3.0
Disable the AAF authn/authz using a single flag
Securing the Kafka ZNodes using ACLs
Added Prometheus monitoring capability
Disabled external facing HTTP ports
Addressed SECCOM/OJSI must have stories

DMaaP BC
Upgrade to Java 11
Addressed SECCOM/OJSI must have stories
Disabled external facing HTTP ports

In addition the documentation project continuously work with improving processes and tools for documentation. Enabling the community to as easy as possible document all the aspects of the ONAP platform. During the Frankfurt release cycle we have started the work to clean up available content, both on the wiki and readthedocs (docs.onap.org) as well as moving the documentation away from submodules according to the LFN documentation strategy. 

Security:

Integration with AAF for automatic certitificate retrieval

Migration from http to https

Use common secret template to generate DB credentials

Migration from Java 8 to Java 11

removal of nbi root container

Use Cases:

5G E2E Slicing, new support for CST and serviceType in Service Ordering

Bug fixes:

Public HTTP port open

Improved security and integration with AAF, with automatic retrieval of Certificates using AAF Init on OOM install.

Daily and Gating chains, that were introduced in El Alto, have been improved especially from a security perspective.

Since January, we performed more than 6000 installations and performed more than, 25,000 tests on 2 infrastructure (Orange + Azure)

We integrated a security category addressing
- Infrastructure CIS, vulnerability tests
- Check of the public end points
- Chase rooted pods
- Exclude any open debug java port

The Frankfurt version will be much more secure than any version before (heavy work from OOM team - hardcoded password removing, templating, removing on certificates in pods). Moreover as we put in place these tests in CI, it is now possible to measure the progress in this area, which is key for production use.

This version was the first version when we delineated between an experimental orchestration solution (used for cutting edge demos) and production  grade features (requiring a better architecture, stability, security,..).

Testing remains an area of improvement though some projects have already refactored their healthcheck test suites.

Features:

• Registration of Frankfurt APIs to MSB

Security:

• Migration from HTTP to HTTPS
• Using none-root user to run processes inside containers
• Upgrading version of some third-party dependencies 

ETSI alignment support:

• Support the ONBOARDING_PACKAGE directory for the original vendor ETSI package extraction
• Enhance APIs for the SO SOL003/SOL005 Adapter
• Support VNF package Subscription and Notification

• Use common secret template to generate DB credentials
• SECCOM Password removal from OOM HELM charts
• Enable micro-service access via MSB HTTPS

Upgrade MultiCloud-StarlingX plugin to support onboarding and orchestration workload to StarlingX 3.0

Add containerized firewall as demo CNF to deploy over StarlingX 3.0

Decouple OpenStack HPA discovery logic from OpenStack Plugins

Enable the PoC of CNF orchestration to StarlingX 3.0

Flexibility to choose appropriate OpenStack HPA discovery logic during phase of deploying MultiCloud plugins

• Separate rest api from core api to improve adoptability for applications wishing to use music as a library.
• Improved configuration of Cassandra connection to allow more flexibility with connection.
• Thread safe locking to prevent multiple requests conflicting when creating a lock.
• Lock clean up daemon to improve performance when there are stale locks present
• Updating helm charts to spring boot version of music
• Added support for https in MUSIC through AAF certificates
• Benchmark the SQL-based plugin for MUSIC (mdbc) with TPC benchmarks that are widely used in the DB
• Improved MUSIC performance through enhanced locking semantics, policies

• No OOM related architecture changes in this release.
• Support for sub-chart packages (sub-chart can be deployed independently if required)
• Use of k8s Secrets to apply configured/generated passwords
• Platform infrastructure deployment with TOSCA
• Bug Fixes

Use cases: 

• Migration to new policy lifecycle APIs. Along with architectural enhancements, this enables catering to self-serving control loops. 
• 5G Network Slicing: Supports optimized Slice/Slice Subnet selection, which is a fundamental step in E2E slice orchestration. 
• CCVPN: Supports model-driven route optimization for OTN paths between two domains. 

Architectural enhancements: 

• Re-architect Optimization Design Framework platform as independent optimization run-times and compile time libraries.
• Allows easier on-boarding new (and custom) optimizers with limited impact on existing optimizers.
• Enables run-time insertion of optimization models for the generic solvers. 

Security:

• Non root processes for all OOF Pods
• All connections move to https
• Implemented SECCOM password retrieval recommendations

1. 5G network GUI （Support the whole flow of creating 5G network slicing service）:
   • Provide CSMF portal for the network slicing customers
   • Provide NSMF portal for the network slicing operators
   • Enhance the Monitor Module for monitoring 5G network slicing
2. CCVPN GUI :
   • Support CCVPN-E-LINE over OTN Inter Domain Links
   • Support Multi-domain multi-layer Optical Service Orchestration
3. Https: Update the frontend and backend service to https

New Features:

• Policy Update Notifications - When versions of policies are deployed/undeployed, an update notification is sent on Dmaap topic so that clients (DCAE in particular) can make Decision API call to get the latest policy that they should be enforcing.
• Native Policy Support for each PDP was implemented. Now users can use the APIs to create policies specific to a PDP such as Drools Rules, XACML XML policies and Apex policies.
• Consolidated the health check of all the components into the PAP. Previously each component had to be queried for health status, now a single call to the PAP can retrieve the health of all the components. NOTE: This does not include legacy components
• Configurable Pre-loading and pre-deployment of policies. When ONAP is brought up, the user can configure a set of default policies that can be created and deployed.
• Enhancements to Lifecycle APIs
  • Added a new simplified API to create one or more policies in a single API call.
• Enhancements to PAP Deployment API's
  • Fetch policy deployment status: Clients will be able to poll the PAP API to find out when policies have been successfully or unsuccessfully deployed to the PDP's.
  • A new API available for Create and Update PDP Groups
  • A new API is introduced to deploy policies on specific PDPGroups
• Statistics for XACML and Apex PDP components enhanced.
• Policy Distribution now uses the Lifecycle API and PAP deployment API to auto create and deploy policies upon service distribution. The legacy API's support were removed.
• XACML PDP New Features:
  • Decision API for monitoring policies was enhanced to support an abbreviated list of policies.
  • Decision API now supports naming policies for CCSDK project.
  • Decision API now supports a closest match algorithm for optimization policies and enhancements were made to better support policies with "matchable" properties.
• Drools PDP New Features
  • Support for offline mode which allows users to run drools in a locked environment.
  • Parameterize mvn repo urls and proxy settings which allows the users to build the docker images for drools-pdp and drools-application using their own CI pipelines.
  • New Controller TOSCA Policy Type support so users can configure controllers during Design Time.
  • Telemetry API enhanced to support Native and Controller TOSCA Policy Types.
• Apex PDP New Features
  • Multiple Policy Deployment now supported
  • Apex now sends the Statistics data in every heartbeat sent to PAP
• CDS as an actor in Control Loops is now fully supported. Introduced in Dublin, the new actor is now available to be used in Operational policies.

Maintenance and Security

• All components were upgraded to JDK 11
• Many dependencies were upgraded to clear known security issues and/or to keep up with improvements in 3rd party libraries. For a full listing, see release notes.
• Hard coded passwords were removed from the components. Now readable from environment variables allowing OOM charts to use secrets for setting passwords.

Feature Improvements

• Treatment of PASSIVE state for PDPs: If a PDP fails to deploy one or more policies specified in a PDP-UPDATE message, PAP will undeploy those policies that failed to deploy to the PDP.  This entails removing the policies from the Pdp Group(s), issuing new PDP-UPDATE requests, and updating the notification tracking data.
• Improvements in validation of Policy Types and Policies
• Fixes for Policy Versioning
• When retrieving a Policy Type, inherited policy types are now included in the API call along with referenced Data Types.
• Control Loop Operational and Guard TOSCA Policy Types were defined and implemented. The legacy yaml is still supported, but will be deprecated in the next release.
• Deployed API removed from API and now is supported in the PAP
• Control Loop actor code was re-designed and cleaned up enabled faster integration of new actors and operations for control loops.
• Control Loop Events were enhanced to support rate limiting of ONSET events to control the flooding of events from DCAE analytics.
• Drools PDP Improvements
  • The Drools Rules were simplified for ease of debugging.
• XACML PDP Improvements
  • Support for PASSIVE Mode
  • Now returns error when a policy cannot be loaded
• Apex PDP Improvements
  • Changed JavaScript executor from Nashorn to Rhino as part of Java 11 upgrade.
  • Passing parameters from ApexConfig to policy logic.
  • Added support for interaction with CDS over gRPC

Experimental

• New PDP Monitoring GUI is available for experimental use to view PDP groups and the PDPs in those groups. Users can visualize the heartbeat, statistics, and health of the PDPs in each group.
• Drools PDP a new server pool implemented was contributed. 

•  Angular Upgrade from 1.X to 7.0 - Portal and SDK (Backward Compatible)
• Close HTTP Ports (Portal, SDK)
• OParent 2.0 Migration & Self Release Jobs
• Address Security Vulnerabilities from Nexus-IQ (Jars and Javascript libraries)
• UI/TypeScript Test Coverage - (Portal Coverage 60% and SDK Coverage 63%)
• Spring Boot Migration (Portal only/ Partially Completed)
• Containers to run as Non-Root user
  • portal, portal-sdk, portal-widget

Enhanced rich UI, improved backend performance, added reporting features and matured security.

• SDN-R Release Frankfurt

• Third-party Operational Domain Manager
• PNF software

• version onboarding
• VSP Compliance and Validation Check within SDC (Frankfurt) - Phase 2
• Consolidation of SDC user roles into a single designer role

• ETSI alignment improvements - Ericcson, Huawei, Samsung, Verizon
  • SOL005 adaptation
  • SOL003 adaptation
  • SOL002 adaptation
  • SOL004 - Using the ETSI catalog manager for the SDC models.
• LCM evolution with API decision tree - Ericcson, Nokia, Bell Canada
• PNF orchestration Enhancements - Ericcson, Huawei, Nokia
  • PNF sotware upgrade  upgrade Using direct Netconf/Yang interface with PNF
  • PNF sotware upgrade Using Ansible protocol with EM
  • PNF sotware upgrade using Netconf/Yang interface with EM 
  • PNF PNP enhancement  
• CCVPN Enhancement
  • MDONS support -  Fujitsu
  • Eline support - Bell, Huawei, CMCC
• 5G Slicing - ATT, Amdocs, CMCC, Huawei, Wipro
  • NSSMF Adapter implementation 
  • Support of Allocate, Deallocate, Activate and deactivate of the Core NSSMF.

• Migrate VF-C catalog to Modeing etsicatalog to  provide common ETSI catalog service
• Support TOSCA based VNF validation for OVP&CVC 
• Add VF-C CLI command to  improve the VF-C usability
• Use common secret template to generate DB credentials
• SECCOM Password removal from OOM HELM charts
• Enable micro-service access via msb https

For an end-user VID is easier to use.

For a system admin, VID is easier to deploy and manage.

• Updated Virtual-Function Event Streaming (VES) Event Listener specification to version 7.1.1
• Significant updates to VNF security requirements

• access via msb https

Security

Adherence to ONAP Logging Spec v1.2
Update to Portal SDK v2.6
Use common secret template to generate DB credentials
Java 11 migration from JDK 8
And more...

Bug fixes

Refresh after Add VF Module fails
Generates different VF module name during scale out
And many more...

For an end-user VID is easier to use.

For a system admin, VID is easier to deploy and manage.

Security:

HTTPS is enabled for VTP and Marketplace REST Services

Non-Root user is enabled for container

Direct Vulnerability issues are resolved 

Features:

VTP REST API is contributed into TMF Test API specification 704-710 / 913 v19.5

VTP Portal is incubated.

Along with CLI, enabled VNF lifecycle testing.

• Updated Virtual-Function Event Streaming (VES) Event Listener specification to version 7.1.1
• Significant updates to VNF security requirements

OVP testsuite

• Migrated OVP VNF Life-cycle validation testsuite to VVP test-engine repo from integration repo.

Preload Plugin Capability

• Enhanced VVP validation script for a pluggable preload template creation. Users can write their own plugin to generate preload templates when executing the vvp validation scripts.

ONAP client

• Created python client to interact with various onap applications. Currently used by OVP VNF testsuite to model and instantiate a VNF for lifecycle badging.

5G use case covers a few independent use cases which improves the ONAP capabilities on PNF management.  

Key use cases which are supported in ONAP Frankfurt release:

• PNF software version onboarding
• PNF sotware upgrade Using direct Netconf/Yang interface with PNF
• PNF sotware upgrade Using Ansible protocol with EM
• PNF sotware upgrade using Netconf/Yang interface with EM 
• PNF PNP enhancement 
• E2E Network Slicing
• O-RAN Harmonization
• PNF Plug & Play with Netconf execution

E2E Network Slicing

(a new E2E use case for Frankfurt, we'd also like to apply to publish a separate Blueprint White Paper for E2E Network Slicing use case, same as the community did for other use cases in every release)

5G Network Slicing is one of the key features of 5G. The essence of Network Slicing is in sharing network resources (PNFs, VNFs, CNFs) while satisfying widely varying and sometimes seemingly contradictory requirements to different customers in an optimal manner. Same network is expected to provide different Quality of Experience to different consumers, use case categories and industry verticals including factory automation, connected home, autonomous vehicles, smart cities, remote healthcare, in-stadium experience and rural broadband. An End-to-End Network Slice consists of RAN, Transport and Core network slice sub-nets. This Use Case intends to demonstrate the modeling, orchestration and assurance of a simple network slice (e.g. eMBB). While 3GPP standards are evolving and 5G RAN and core are being realized, this Use Case will start with realizing an E2E Network Slice with a simple example of a 5G RAN, Core and Transport Network Slice sub-nets. It will also align with relevant standard bodies (e.g., 3GPP, ETSI, TM Forum) as well as other open initiatives such as O-RAN where relevant, with respect to both interfaces as well as the functional aspects.

Key features in Frankfurt:

• Tenants and network operators can order slice-based services
• Enables network slice creation as well as reuse
• Supports many of the slice lifecycle management operations

Key capabilities added for ONAP Frankfurt release:

• ONAP Frankfurt provides basic capabilities for Network Slice Orchestration
• Supports Network Slice lifecycle operations of E2E Slice Design and Creation, Activation, Deactivation and Termination
• Provides CSMF and NSMF functionality implemented within ONAP
• Supports E2E Slice design including design of Communication Service, Service Profile and Network Slice Template
• Supports selection of suitable NST and suitable NSI, covering the scenario of new NSI creation by providing suitable slice profile
• Interacts with an external Core NSSMF

This use case is a multi release effort and we will continue to provide more enhancements and features based on what we've implemented in Frankfurt in the subsequent releases.

1. The ONAP based E2E Network Slicing solution allows a service provider to manage the slices and its constituents by leveraging ONAP existing capabilities.
2. enables the slice-consumer to request for and activate a network slice on-demand without being concerned about network internals, which is very essential for industry-vertical
3. An operation guidance will be provided on ONAP wiki in which explicit instructions are provided to help any interested parties to experience ONAP based E2E Network slicing management.

PNF software updates are routine for network upgrades to support new features, improve efficiency or increase capacity on the field, and to eliminate bugs. This use case positions ONAP as a vantage point in orchestrating and managing PNF software upgrades inline with the business and service objectives.  

Deployment and orchestration of new network services over both VNFs and PNFs in a model and software driven way simplifies the network management. As 5G networks will host a large number of PNFs from multiple vendors, streamlining service upgrades that involve PNF software changes through ONAP will reduce the OPEX substantially. 

The following upgrade scenarios are supported in ONAP Frankfurt release: 

• PNF sotware upgrade Using direct Netconf/Yang interface with PNF
• PNF sotware upgrade Using Ansible protocol with EM
• PNF sotware upgrade using Netconf/Yang interface with EM 

PNF software version onboarding

PNF software version onboarding is a key feature to onboard the vendor provide PNF software version into the ONAP internal PNF descriptor. This PNF software version information will be used by ONAP Run Time components for the purpose of PNF life cycle management. 

Adding two extension functions / sub use cases for Frankfurt.

PNF support

Significant progress in supporting

• Distributed Applications and Distributed network functions.
• Multi-tenancy 
• Multi party K8s Clusters 
• Provider networks and Multiple Virtual networks on per Cluster
• Complex applications
• Various deployment intents (Generic Placement intent, Network workload intent)
• Logical Clouds for  network slices with soft-isolation.

1. End-to-end E-LINE services across the domains over OTN NNI handover. The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator and provide VPN service provision in OTN and ETH networkan operator and provide VPN service provision in OTN and ETH network. Use case specific developments have been realized in SO, OOF, A&AI, SDN-C and U-UI components
2. Multi-Domain Optical Network Service(MDONS). The MDONS sub use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP.Use case specific developments have been realized in SDC, SO, OOF, A&AI, SDN-C and U-UI components
3. Multi-Domain Optical Network Service(MDONS). The MDONS sub use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP.Use case specific developments have been realized in SDC, SO, A&AI, SDN-C and U-UI components

1. E-LINE over OTN NNI extends upon the CCVPN use case by incorporating support for L1/L2 network management capabilities leveraging open standards& common data models such as the IETF ACTN-based transport YANG models.
2. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 end customer services that span service provider domains, with a plan to support inter-carrier optical services.
3. MDONS defines a unified optical service model based upon OpenROADM, T-API, MEF 63, and MEF 64 models, and allows integration of optical domain controllers using either the Open ROADM or TAPI service models.

1. Establishment of a subscriber's HSIA (High Speed Internet Access) service from an ONT to the Internet drain

2. Support the change of location for ONT devices (Nomadic ONT devices)

2.1 PNF (Re-)Registration for an ONT
2.2 Service location modification that is detected by ONAP's analytic and enforced by APEX policy engine

1. -UI components

1. E-LINE over OTN NNI extends upon the CCVPN use case by incorporating support for L1/L2 network management capabilities leveraging open standards& common data models such as the IETF ACTN-based transport YANG models.
2. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 end customer services that span service provider domains, with a plan to support inter-carrier optical services.
3. MDONS defines a unified optical service model based upon OpenROADM, T-API, MEF 63, and MEF 64 models, and allows integration of optical domain controllers using either the Open ROADM or TAPI service models.

1. Establishment of a subscriber's HSIA (High Speed Internet Access) service from an ONT to the Internet drain

2. Support the change of location for ONT devices (Nomadic ONT devices)

2.1 PNF (Re-)Registration for an ONT
2.2 Service location modification that is detected by ONAP's analytic and enforced by APEX policy engine

PNF support

• vFW Traffic Distribution Use Case changed into vFW In-Place Upgrade with Traffic Distribution with possibility to run only vFW Traffic Distribution
  
  • Enhanced workflows that demonstrate different LCM operations of APPC
  • Workflow utilizes new mechanisms in APPC for Ansible LCM operations: running LCM commands on v-server, vf-module or vnfc level without the need to specify NodeList parameter - it is auto enerated from information in AAI and LCM request identifiers.
• PNF software upgrade without schema update

Significant progress in supporting

• Distributed Applications and Distributed network functions.
• Multi-tenancy 
• Multi party K8s Clusters 
• Provider networks and Multiple Virtual networks on per Cluster
• Complex applications
• Various deployment intents (Generic Placement intent, Network workload intent)
• Logical Clouds for  network slices with soft-isolation.

Integration with Macro instantiation flow and with CDS for vFW Use Case

• New Use Case - vFW CNF CDS. Use case demonstrates E2E Automation for instantiation via SO building, MultiCloud & CDS for CNF. 
• Improvements and bug fixes to support Macro flow instantiation of helm package
• Override parameters can be specified in Instantiation API - profile is not required for the same purpose
• Default profile created - does not have to be created before instantiation
• SDC helm package distribution is improved - many helm packages allowed in one CSAR package - decoupling of CNF into separate vf-modules (helm packages)
• Integration with CDS allows to generate instantiation time parameters for helm package like names, IP addresses etc. and it allows to automatically upload to Multicloud profile for helm package - when required.

• Now supports Ansible Playbooks in addition to Netconf for controller configuration of VNF
• Now supports dynamic configuration of VNF through CDS