ONAP Frankfurt Release Architecture Requirements





The Architecture Requirements are Summarized here: The full release requirements (including Architecture requirements) are captured here: Frankfurt Release Requirements;

  • Label with stories with the projects that are impacted and include a description of that impact

These are listed with EPIC, then the following stories.  The Epics are added manually, hence a complete list of Epics are included below.













To appear here, the JIRAs need the label ARC-REQ-FRANKFURT.  Mark the release as Frankfurt



EPIQs and stories here should be approved by ArchCom

The ones that are "agreed" in the architecture sub-committee are marked as:  This is still to be decided.



Summary / Status

Requirement/UseCase/...

Status

Requirement/UseCase/...

Status

Orchestration Scenarios

REQ-101: ETSI Alignment SupportDone

ArchCom approved ONAPARC-320: Orchestration scenarios ArchitectureIn Progress

 LCM API Evolution

REQ-92: LCM API EvolutionDone

 ArchCom approved

ONAPARC-234: Controller EvolutionOpen

  Edge Automation

Distributed Management Task Force - not ArchCom approved

  • Scope for Franfurt - "Extend Central K8S to register Edge Clouds"

    • Centrally manage k8s Edge Clouds (k8s-clusters)

    • Use Custom Resource Definition as Registry

    • Provide ability to extend CRD to contain metadata

      • -Location label 

      • -Edge type (ICN, AWS, Azure, etc.) 

      • -External IP 

      • -Namespaces, user for authorization

    • Edge Cloud Naming

      • Follow Cloud (AWS etc.) naming convention with additional operator name?

Questions: still to be answered:

  • how to determine the location

  • Is it OK to use different services for the applications centrally and distributed.  Which applications are taking these up. 

3rd Party Operational Domain Controller

 REQ-17: Third Party Operational Domain ManagerDone

 ArchCom approved for current direction.

Note: Not full functionality in Frankfurt.  One open issue to resolve as to whether the external service needs to be wrapped in an ONAP service to have consistent orchestation approach (or not).

ONAPARC-509: ONAP Thrid Party Operational Domain ManagerOpen

 Service Resolver

REQ-13: Service Resolving featureDone

 Not Yet Archcom approved

ONAPARC-509: ONAP Thrid Party Operational Domain ManagerOpen

 Model Driven ONAP

<< req >>

 Not Yet Archcom approved

ONAPARC-436: Model driven ONAPOpen

 Orchestration of Contain Based VNFs

<<>>

 Frankfurt Release ??

 Applications on ONAP

<<?? >>

 Not Yet Archcom approved

ONAPARC-500: ONAP Platform with network security as an applicationOpen

 API-GW

<<>>

 There will not be a proposal for Frankfurt.

ONAPARC-494: API Management / API GW proposalClosed

 Runtime DB

<< >>

 Status: need and concept OK by Archcom:ONAPARC-514: Run-time DB (was RT DB)In Progress

 5G / ORAN & 3GPP Standards Harmonization

REQ-38: 5G / ORAN & 3GPP Standards HarmonizationDone

 Status: Archcom approved

ONAPARC-516: 5G / ORAN & 3GPP Standards HarmonizationClosed

 ONAP CLI for VNF

<<??>>

 

Status: Note yet Archcom approved

ONAPARC-478: ONAP CLI and ArchitectureOpen

 Slicing Evolution

https://lf-onap.atlassian.net/browse/REQ-60

https://lf-onap.atlassian.net/browse/REQ-158

https://lf-onap.atlassian.net/browse/REQ-159

https://lf-onap.atlassian.net/browse/REQ-146

 Not Archcom Approved

 Multidomain optical service

https://lf-onap.atlassian.net/browse/REQ-37

 Archcom Approved https://lf-onap.atlassian.net/browse/ONAPARC-519

 Integrate Acumos with DCAE

https://lf-onap.atlassian.net/browse/REQ-166

Self Service Control Loop

https://lf-onap.atlassian.net/browse/REQ-9

 Archcom approved

xNF licencing with ONAP

Archcom approved (principles) (licening server outside ONAP) https://lf-onap.atlassian.net/browse/ONAPARC-520

ETSI catalogue as a common service

Archom approved.  Part of ETSI-ONAP alignment requirements

https://lf-onap.atlassian.net/browse/ONAPARC-523

CDS support of K8S

Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-522

Analytics (or VNF) at the edge using Akrono antaticis orchestrated by ONAP

Not Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-519







Orchestration Scenarios: ONAPARC-403

REQ-101: ETSI Alignment SupportDone

Status: Archcom approved: ONAPARC-320: Orchestration scenarios ArchitectureIn Progress

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh



Controller Evolution:

Controller Evolution towards combined GNFC: https://wiki.onap.org/download/attachments/53248195/Controller%20EvolutionElAlto04012019.pptx?version=2&modificationDate=1554220494764&api=v2

STATUS: The approach has been approved by ArchCom  ONAPARC-234: Controller EvolutionOpen

REQ-92: LCM API EvolutionDone

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh



https://lf-onap.atlassian.net/browse/INT-1131

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh





https://lf-onap.atlassian.net/browse/SO-2070



Edge Automation, (Ramki to inform)





ONAP 3rd Party Operational Domain Manager

Status: Architectureal Direction approved for current direction.  Note: Not full functionality in Frankfurt.  One open issue to resolve as to whether the external service needs to be wrapped in an ONAP service to have consistent orchestation approach (or not). ONAPARC-509: ONAP Thrid Party Operational Domain ManagerOpen

REQ-17: Third Party Operational Domain ManagerDone

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh



Service Resolver:

Status: Not Archcom Approved (https://lf-onap.atlassian.net/browse/ONAPARC-507)

REQ-13: Service Resolving featureDone

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh



Model Driven ONAP

Status: Not yet ArchCom approved (ONAPARC-436: Model driven ONAPOpen)



Orchestration of Container Based VNFs (Srini)

???

Applications on ONAP

Status: Not yet ArchCom approved (ONAPARC-500: ONAP Platform with network security as an applicationOpen)



API-GW

Status: Closed - there will not be a proposal for frankfurt timeframe

ONAPARC-494: API Management / API GW proposalClosed



RunTime DB

Status: direction approved, some more work to be done on project aspects (not an archcom issues) and flows:ONAPARC-514: Run-time DB (was RT DB)In Progress

CONFIGURATION PERSISTENCE SERVICE R6



 5G / ORAN & 3GPP Standards Harmonization

Status:ArchCom ApprovedONAPARC-516: 5G / ORAN & 3GPP Standards HarmonizationClosed

REQ-38: 5G / ORAN & 3GPP Standards HarmonizationDone

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh



ONAP CLI for VNF

Status: Note yet Archcom approved

ONAPARC-478: ONAP CLI and ArchitectureOpen



Slicing Evolution

https://lf-onap.atlassian.net/browse/REQ-60https://lf-onap.atlassian.net/browse/REQ-158https://lf-onap.atlassian.net/browse/REQ-159

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh

key summary type created updated due assignee reporter priority status resolution labels
Loading...
Refresh





Multidomain Optical Service

Status: Archcom approved https://lf-onap.atlassian.net/browse/ONAPARC-519

https://lf-onap.atlassian.net/browse/REQ-37

Integrate Acumos with DCAE

Status: not ArchCom approved

https://lf-onap.atlassian.net/browse/REQ-166



Self Service Control Loop

https://lf-onap.atlassian.net/browse/REQ-9



xNF licencing.

Status: principles archcom approved. https://lf-onap.atlassian.net/browse/ONAPARC-520



Misc:

  • Orchestration of container based VNFs (Srini)?

  • Service mesh (srini/mike)??

  • ONAP CLI For VNF (NB) and architecture (also make sure Dan Timony joins)

  • Service Resolver (Rene/Seshu)

  • DBaaS (what has been done, what we should do next) - (Yuri, Mike, Joanne)?? (session at subcommittee mtg).

    • Centalized DB technologies for the ONAP platform applications to use.  DB is responsible for their own schema.





Notes: to be removed at the end.

  • Assume that slicing is driven by the use case work as per in previous releases, and this will implicitly cover the needs for the alloted resource and hierarchal orchestration.



The full list of the Epics are included here. This is to identify if there is a missing Epic above.



Stories All stories and sub-tasks.