...
Wiki to the "Base" PNF Plug and Play Page: 5G - PNF Plug and Play
PRH update handling of Logical Links (move to SO) - introduced in R4 Dublin for BBS/Re-registration Epic
DEVELOPMENT IMPACTS
PROJECT | PTL | User Story / Epic | Requirement | |||||||||||||||||||||||||||||||||||||||||
A&AI | ||||||||||||||||||||||||||||||||||||||||||||
AAF | Epic #4 Secure PnP (just a dependency) Functionality will be developed in separate release requirement
| Epic #4:
| ||||||||||||||||||||||||||||||||||||||||||
APPC | ||||||||||||||||||||||||||||||||||||||||||||
CLAMP | ||||||||||||||||||||||||||||||||||||||||||||
CC-SDK | Epic#1: Controller to PNF exchange (Epic) STEP 37 | Epic #1:
| ||||||||||||||||||||||||||||||||||||||||||
DCAE | DCAE | Epic #4#1: Secure PnP
____________________________ Epic #2: Adjust VES collector to SECCOM requirements
| Epic #1:
_________ #5: Refactor Tests for DCAE-SDK DMaaP-Client____________________________ Epic #7#2: Adjust
| |||||||||||||||||||||||||||||||||||||||||
DMaaP | ||||||||||||||||||||||||||||||||||||||||||||
| Epic #4:
________________________________ Epic #5: Refactor Tests for DCAE-SDK DMaaP-Client
_________________________________ Epic #7:
| DMaaP | External API | |||||||||||||||||||||||||||||||||||||||||
MODELING | Epic #2: Geolocation parameters | Epic #2:
| ||||||||||||||||||||||||||||||||||||||||||
External API | ||||||||||||||||||||||||||||||||||||||||||||
MODELING | Epic #2: Geolocation parameters | Epic #2:
| ||||||||||||||||||||||||||||||||||||||||||
Multi-VIM / Cloud | ||||||||||||||||||||||||||||||||||||||||||||
OOF | Shankaranarayanan Puzhavakath Narayanan | |||||||||||||||||||||||||||||||||||||||||||
POLICY | ||||||||||||||||||||||||||||||||||||||||||||
PORTAL | ||||||||||||||||||||||||||||||||||||||||||||
SDN-C | ||||||||||||||||||||||||||||||||||||||||||||
SDC | Epic #6: CDS Integration with SDC (Low priority) | Epic #6: CDS integration with SDC (VF/PNF Resource artifact upload screens) (Best effort)
| ||||||||||||||||||||||||||||||||||||||||||
SO | Multi-VIM / Cloud | OOF | Shankaranarayanan Puzhavakath Narayanan | POLICY | PORTAL | SDN-C | SDC | SO | Epic #3: SO Building Blocks. | E#3a: Change to the onboarding (definition) of the BPMN workflow. To bring war file with the workflow. E#3b: Migrate existing workflows to existing building blocks.
Need to sync on the VID implementation of 5G VID Instantiation/orchestration.
| ||||||||||||||||||||||||||||||||||
VID | Epic #3: SO Building Blocks | Need to sync on the VID implementation of 5G VID Instantiation/orchestrationOrchestration. VCPE also wants to use these building blocks, a fully generic solution is desired here. | ||||||||||||||||||||||||||||||||||||||||||
VNFRQTS | ||||||||||||||||||||||||||||||||||||||||||||
VNF-SDK | CDS | Yuriy Malakov | Epic #6: CDS Integration with SDC (Low priority) | Epic #6: CDS integration with SDC (VF/PNF Resource artifact upload screens) (Best effort)
List of PTLs: Approved Projects
EPIC / REQ
The Plug and Play Epic for R6 Frankfurt:
Jira | |||||||
---|---|---|---|---|---|---|---|
|
...
|
...
List of PTLs:Approved Projects
EPIC / REQ
...
|
DCAE
Frankfurt Work Item | DESCRIPTION | ||||
---|---|---|---|---|---|
DCAE1: Secure PnP | CMPv2 for operator certificate enrollment for VES Collector to correctly handle pnfRegistration event.
|
...
|
...
|
...
| ||
DCAE2: Adjust VES collector to SECCOM requirements | Secure VES collector - make sure client certificate authentication (together with Basic authentication) is default authentication method (according to SECCOM requirements) |
DCAE
Frankfurt Work Item | DESCRIPTION | ||||||||
---|---|---|---|---|---|---|---|---|---|
| 1794|||||||||
DCAE2: Refactor Tests for DCAE-SDK DMaaP-Client | Refactor Tests for DCAE-SDK DMaaP-Client | ||||||||
DCAE3: Adjust VES collector to SECCOM requirements | Secure VES collector - make sure client certificate authentication (together with Basic authentication) is default authentication method (according to SECCOM requirements)
|
AAF
| ||
AAF
Frankfurt Work Item | DESCRIPTION |
---|---|
Secure pnfRegistration | Introduction of Secure Communications with CMPv2. 3GPP PnP operator certificate (to DCAE) before it sends pnfRegistration event. Not on DCAE-side. Setup ONAP system have to have root CA, CA chain from the CAs that issue NF certificates. you get DCAE component Certificate signed by local AAF/CA. DCAE doesn't use AAF directly, DCAE |
Frankfurt Work Item | DESCRIPTION |
Secure pnfRegistration | Introduction of Secure Communications with CMPv2. 3GPP PnP operator certificate (to DCAE) before it sends pnfRegistration event. Not on DCAE-side. Setup ONAP system have to have root CA, CA chain from the CAs that issue NF certificates. you get DCAE component Certificate signed by local AAF/CA. DCAE doesn't use AAF directly, DCAE component uses its own init container to get certs. NetConf over TLS will use CMPv2. External border components (DCAE, Controllers) need real certificates, which they don't have right now. This will be developed in R6. ONAP platform Containers / Prepare system to upload certificates manually. Need automatic way to get operator certificates through CMPv2 client. Plug-in to AAF to get certificates, how are these distributed to other ONAP components. Need trust chain. Can't do this manually with 100s of instances. Don't have a factory certificate w/ inherent identifier. PNFs scope. DCAE components need to get operator certificates. COMPONENTS: DCAE, AAF. |
SO IMPACTS
with 100s of instances. Don't have a factory certificate w/ inherent identifier. PNFs scope. DCAE components need to get operator certificates. COMPONENTS: DCAE, AAF. | |
SO IMPACTS
PNF PnP FRANKFURT WORK ITEM | DESCRIPTION | ||||||||||||
SO1: Building Blocks | Refactor BPMN workflow. Clean up work previously done in R4. Migrate existing workflows to existing building blocks | ||||||||||||
PnP DUBLIN WORK ITEM | DESCRIPTION | ||||||||||||
SO1: Building Blocks | Refactor PBMN workflow. Clean up work previously done in R4. Migrate existing workflows to existing building blocks. Need to sync on the VID implementation of 5G VID Instantiation/orchestration. VCPE also wants to use these building blocks. | ||||||||||||
SO2: Service & NF Instance Association | SO3: SO support for already existing PNF A&AI entries | .
| 797This is not planned to be changed in ONAP/Dublin release.
Need to sync on the VID implementation of 5G VID Instantiation/orchestration. | ||||||||||
SO2: Service & NF Instance Association | Associating a xNF to a Service. DEVELOPMENT STATUS: Stretch goal in Frankfurt release SO-future: Controller to NF Association [SDC/SO] The PNF controller caused quite a stir in Casablanca, the tension between Design/Platform Model vs Run-Time/Deployment Model. As a result the SO controller design was sub-optimal and should be addressed in Dublin. |
AssignPnfBB
- Responsibility: Creates PNF entry in A&AI
- Makes a link in AAI between service entry and PNF entry
- currently implemented in CreateAndActivatePnfResource.bpmn
...
R6 ITEM | DESCRIPTION |
---|---|
VID1 Migration of Sub-worksflows | Migration of existing PNF PnP sub-workflows to a new BB approach (probably we will be creating 4-5 new BBs). VID Impact: Within “old” VID macro orchestration pages, a special field to provide a pnf-id parameter (shall be actually called “correlationID” or “PNF correlationID”) has been displayed under the following conditions:
When we migrate to BB approach, we`d keep the possibility to provide this parameter (PNF correlationID) to the SO API call as input. How this will change with SO/BB approach, and with new VID GUI targeted at macro (GR) flows – we`d see exactly, after we execute some tests with new VID UI, and updated SO PNF BB code. |
...
Presentation | File | ||||||
---|---|---|---|---|---|---|---|
Presentation for Epic #4: |
| ||||||
Slides for SO work (Generic SO BBs for PNFs) |
| ||||||
...