Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

YES means that (1) PTL INFORMED & COMMITTED - has agreed to support the changes needed for that Use Case, (2) DEVELOPMENT SUPPORT - there is development (company) support (3) JIRA TICKETS - and a Jira ticket exists. Please see the corresponding WIKI page for that Use Case to find out more details on impact, PTL support and Jira Ticket(s).

U/CSDCVIDPortSO

AAI

ESR

SDN-CAPP-C

SDNC/

CCSDK

APPCDCAEOOFPolicyCLAMP
DM

DMaaP

aaP

AAF

VNF

SDK

REQMODEL COM
OOMVIM

Pomba

Panda

CIACLIConsul
Bulk PM(star)N/AN/AN/AN/AN/AN/AYESN/AN/AN/AYESN/AN/AYESN/AN/AN/AN/AN/AN/AN/A
OnboardingYESN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AYESYESN/AN/AN/AN/AN/AN/AN/A
NetConfN/AN/AN/AYESN/AYESN/AN/AN/AN/AN/AN/A
(star)
N/A1N/AYESN/AN/AN/AN/AN/AN/AN/A
FM PM DictYESN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AYESN/AN/AN/AN/AN/AN/AN/A
OOF PCIN/AN/AN/AN/AN/AYESN/AYESYESYESN/AN/AN/AN/AYESN/AN/AN/AN/AN/AN/AN/A
PNF PnPN/AYESYESYESYESYESN/AYESN/AN/AN/AN/AYESN/AYESN/AN/AN/AN/AN/AN/AN/A
S/W Upg
N/AN/AN/AN/AN/AYESN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/A
SlicingYESN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AN/AYESN/AN/AN/AN/AN/AN/A

REQ = VNF Requirements Project. The VNF-RQTS project applies to both VNFs and PNFs. A "YES" here means that there are new requirements for the vendors. (Moved to Wed 10AM)

...

(star) Stretch Goal (N/A) but if extra resources are available some changes may be made.

Note ((star)1): YES This is still in discussion, solution depends on AAF. Will have to either the preferred option is to include AAF, but if the Jira is not implemented in time in R4, an alternate simplified solution will be adopted that excludes AAF from the U/C. (Feb 21) discussed in Security sub-committee, presented proposed scope for R4 wo/ AAF. AAF might provide functionality available (undocumented). Manual steps to setup certificates (wo/ AAF) workaround. With AAF could automate the TLS certificate setup.: Two options have been investigated for NETCONF/TLS client certificate generation: 1) manually outside of ONAP 2) by AAF. For Dublin option (1) will be supported. Option (2) is a possible extension for future release.

Note (3): Most of the PNF S/W Upgrade Use Case has been descope out of R4/Dublin and pushed to R5/El Alto release. In discussion with Change Management team, nothing major in R4 can be done, but may want to update the Playbooks distribute through SDC, distribute with roll-back API. Some discussion w/ 3GPP S/W mgmt API and what has been done in Change management U/C and how to bridge the gap. NetConf support in R4 and 5G API. See the Use Case Realization call for Wed Feb 20, 2019: USE CASE REALIZATION MEETING (Notes 2019-02-20)

...

USE CASEAPI Impacts
Bulk PM

DMaaP DR API Updates.

See the Wiki page for details on the Data Router Changes:

5G - Bulk PM (Casablanca carry-over items)

Next Steps: Confirming API details.

Configuration with NetConf

For communication between SO and the CDS Blueprint Processor, a new API has been defined by CDS.

This U/C will use that new API to request configuration as the last step of the extended PNF workflow.

The API request and response format is defined in the following file:

https://github.com/onap/ccsdk-apps/blob/master/ms/blueprintsprocessor/modules/commons/core/src/main/kotlin/org/onap/ccsdk/apps/blueprintsprocessor/core/api/data/BlueprintProcessorData.kt/BlueprintProcessorData.kt

The blueprint processor allows requests to be sent using either plain HTTP with JSON or gRPC over HTTP/2. The client in SO will use the gRPC option.

This API doesn't have pre-defined actions and payloads. Instead they will be defined as part of U/C. For initial configuration (both VNF and PNF), the following actions will be used: config-assign and config-deploy.

The blueprint processor allows requests to sent using either plain HTTP with JSON or gRPC over HTTP/2. The client in SO will use the gRPC option.

Next steps: The payload contents for config-assign and config-deploy actions are currently being finalizedPayload format and contents have now been proposed for both actions.

OOF / PCI

API changes are needed. Config DB API, SDN-R. APIs for individual nodes record updates in Config DB. Bulk APIs for updating. API associated with SDN-C project. SON MS & Policy & OOF. Keep in sync with the corresponding Yang Model. OOF API: micro-service calls (optimization and passes data).

Freeze on API changes.

Next Steps: JSON swagger document being produced. (in progress)

PNF S/W Upgrade

Roll-back API. From SO to SDN-C (Controller). South-bound changes (captured in the Ansible Playbooks), impacting the external controller rather than the ONAP platform. Data pushed from API so south-bound APIs will have right data (in the payload).

Reusing LCM API (between SO to SDN-C) which already has the rollback in there.

The Rollback action is already specified in SDN-C. In the yang model for LCM.Yang (in CCSDK repository) file. Mandatory/generic header fields need to make them optional so that we can use them as a generic API to pass specific 5G info in the Payload. Currently Rollback function was not implemented yet (so no one is currently using this API).

Next Steps: API definition details in progress. Changing field options, and defining the payload.

USE CASES WITH NO API IMPACT
PNF Plug and Play

New API for the Update Micro-service to SO (from the pnfUpdate event trigger) from Policy for the Reregistration Story. The "user" will be the BBS Micro-service U/C.

Next Steps: Ajay in DCAE has accepted this micro-service. Final details of the new service-update API is being defined in conjunction with SO project (Seshu).

PNF Pre-onboarding / OnboardingNo API Impacts.
5G FM Meta Data 5G PM DictionaryNo API changes
Network Slicing(Modeling only) - No API Changes

...