Beijing Functional Requirements

Summary of the Teams commitments to support Beijing functional Requirement.

This is summary of outcome of Use case Sub-Committee and effort from:

  1. HPA (main contact @Alex Vul)

  2. Change Management (Main contact @Ajay Mahimkar)

  3. Scaling  (main contact @Scott Blandford)

  4. 5G/PNF support (main contact @Vimal Begwani)

Legend

Yes: Committed by PTLs to Beijing Release

No: Not committed to Beijing Release

NA: Project not impacted by functional requirement, requirement not defined enough to make formal decision.




Project Name

Functional Requirements

Comments



HPA

ChangeMngt

Scaling Auto

Scaling Manual

PNF

Network Slicing

Data Collection

Path Selection





M1 Commitment

M4 result

M1 Commitment

M4 result

M1 Commitment

M4 result

M1 Commitment

M4 result

M1 Commitment

M4 result









A&AI

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

NA

NA

NA

Change Mngt, Scaling: Functionality already exist in Amsterdam. New way to exercice the API. No schema change required.



Application Authorization Framework

N/A

N/A

N/A

Yes, AAF is now ONAP Only

N/A

Yes

N/A

Yes

N/A

N/A

N/A

N/A

N/A

AAF was not managed in ONAP for Beijing. Instead, we used this time to take the major features desired from AT&T production, including Certman, OAuth2 and other elements. AAF project is now ONAP First. This means that starting with Casablanca, requirements and results now come from the community, will have M1 Commitments, etc.

APPC

NA

NA

Yes

Yes

No

No

Yes

Yes



NA

NA

NA

NA

NA

Change Mngt: not impacted for Beijing because Use case being focuses on an L3 VNF. APPC is impacted for this change management functional requirement for L4 to L7 VNFs. APPC will support In Place software upgrade in Beijing.

Scaling Auto: Lack of detailed requirements and resources.

CLAMP

NA

NA

NA

NA

No

No

NA

NA

NA

NA

NA

NA

NA

Scaling: Dependency on Policy who has no resource to deliver in Beijing

Common Controller SDK

NA

NA

Yes

Yes

Yes

Yes

Yes

Yes

NA



NA

NA

NA

Change Mngt: Ansible server support

DCAE

NA

NA

NA

NA

NA

NA

NA

NA

Event for PNF discovery to be added (validate whether prov only or need dev). If dev needed and not committed then can deliver the solution without DCAE for Beijing

WIP as of 03/28

(the PNF Registration Handler, aka prh, work is in the process of being contributed.

Code coverage 63%, but currently encountering problems in CLM scan reporting "CLM server error", LF helpdesk ticket #54190)

NA

NA

NA

HPA: Not priority

DMaaP

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

Documentation

NA



NA



NA



NA















External API Framework

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

Initial code release

Holmes

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA



Integration

Yes



Yes



NA



NA



Yes











Logging Enhancements Project

NA



NA



NA



NA







NA

NA

NA

Scaling is possible via standard k8s config - but not yet tested for elasticsearch and logstash containers

Network slicing has not been prototyped (independent of any k8s component - not specific to the elk stack)

Data collection is possible via PVs exposed on /dockerdata-nfs share - via standard k8s volumes - but not tested

Patch selection is not applicable - but needs to be verified

Microservices Bus

NA



NA



NA



NA



NA



NA

NA

NA

No modification is needed in MSB project specifically to support all these functionalities so far. If you think there are any new requirements needed, please let us know.

Modeling

Yes



NA



NA



NA



NA



NA

NA

NA

modeling project is responsible for a tool: Parser, modeling committee is responsible for modeling spec, HPA will be related parser.

Multi VIM/Cloud

Yes

Yes

NA



NA



NA



NA



NA

NA

NA



MUSIC

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA



ONAP CLI

NA



NA



Yes

Note1

Yes

Note1

NA

YES

Note2

NA

NA

NA

Mostly HPA will be captured as part of Templates (TOSCA/HEAT). so CLI won't get oppourtunity to operate on HPA. But if Services provides API to handle the HPA, those can be incorporated. So after M2/M3, things will be very clear. so CLI marked HPA as NA.

Note1: SO does not expose the REST API for scaling yet. so CLI is not in postiion to support this feature.

Note2: PNF support was not initially planned during M1, but as part of M3, it got identified to support and is enabled now.

ONAP Operations Manager

NA



NA



NA



NA















ONAP Optimization Framework

Yes

Yes

Yes

N/A

Note 1

Yes

No

Note 2

Yes

No

Note 2

NA



NA

NA

NA

  • Note1: OOF was not required in R2 flows. Use Case proposal: ONAP Change Management 

  • Note 2: OOF dependencies had this as stretch goal. Communicated the same with use case owners, and the plan is to support in R3.



ONAP Usecase UI Project Proposal

NA



NA



N/A



Yes















Policy Framework Project Proposal

Yes

Yes

NA



No



NA



NA



NA

NA

NA

Scaling: Resources found for vDNS, but APPC is unable to commit fully. Policy will do as much as possible in conjunction with APPC's ability.

Portal Platform Project Proposal

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA

NA



SDN-C

NA

NA

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

NA

NA

NA

Change Mngt: In-place software upgrade execution using Ansible

Service Design & Creation

Yes (based on INTEL contribution)

WIP

NA



NA



Yes

YES

Yes (based on NOKIA contribution)

YES

No

No

No



Scaling Manual: no resource

Service Orchestrator

Yes

Yes

Defects Fixing

Yes

Yes



Yes

NA

Dropped of the scope

Yes

WIP

Yes

Yes (VCPE), needs to be stabilised.

Volte - WIP

NA

NA

NA

Change Mngt: Change workflow design and execution for in-place software upgrade

Note: The current commitment is based on the discussions and promises of availablity of coding resources for the respective function implementation.

VFC

Yes

WIP

NA

NA

Yes

(but the auto scaling process is not very clear now)

Yes

Yes

Yes

NA

NA

NA

NA

NA

scaling Auto: VF-C will provide the scaling API, but the auto-scaling process is not very clear now.

For other requirements did not reach out to VF-C



VID

NA



Yes

Yes

NA



Yes

WIP

Yes

Yes

NA

NA

NA

Change Mngt: User interface for invoking software upgrade workflow

Scaling Manual: no resource

VNF SDK

Yes

No

NA



NA



NA



NA



NA

NA

NA

M4: Model not published.

VNF Requirements

Yes



Yes



Yes



Yes



Yes



Still investigating

Still investigating

NA

Auto scaling and Manual Scaling covered by scaling use case component planned for Beijing.

Scope of PNF work dependent on definition of PNF, VNFRQTS-160

VNF Validation (VVP)

NA



NA



NA



NA