Versions Compared

Key

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

...

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

Epic #6: CDS integration with SDC (VF/PNF Resource artifact upload screens) (Best effort)
PROJECTPTLUser Story / EpicRequirement
A&AI


AAF

Epic #4 Secure PnP

(just a dependency) Functionality will be developed in separate release requirement

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyREQ-140

Epic #4:

  1. CMPv2 Client implementation so that ONAP platform components can get operator certificates.
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyAAF-994
  2. Ensure AAF provides interface allowing DCAE to deploy extra client certificate for external communication
APPC


CLAMP

CC-SDK Epic#1: Controller to PNF exchange (Epic) STEP 37

Epic #1:

  1. Support NetConf, uses CDS component. W/F in SO. Extended with optional configuration step in SO uses CDS API. wi/ CDS to create blueprint ansible/netconf. CDS south-bound can use different protocols.
  2. Support ONAP communication back to the PNF (via Ansible/Netconf) see Step 37 on the PnP Wiki.
  3. (Might be all fully working - might no new development)
DCAEDCAE

Epic #4#1: Secure PnP

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-1794

____________________________

Epic #2: Adjust VES collector to SECCOM requirements

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-1775

Epic #1:

  1. CMPv2 for operator certificate enrollment for VES Collector to correctly handle pnfRegistration event.

_________

#5: Refactor Tests for DCAE-SDK DMaaP-Client

____________________________

Epic #7#2: Adjust

  1. Secure VES collector - make sure client certificate authentication (together with Basic authentication) is default authentication method (according to SECCOM requirements)
jira
DMaaP
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-1775

Epic #4:

  1. CMPv2 for operator certificate enrollment for VES Collector to correctly handle pnfRegistration event.

________________________________

Epic #5: Refactor Tests for DCAE-SDK DMaaP-Client

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-1773

_________________________________

Epic #7:

  1. Secure VES collector - make sure client certificate authentication (together with Basic authentication) is default authentication method (according to SECCOM requirements)
DMaaPExternal API
MODELINGEpic #2: Geolocation parameters

Epic #2:

  1. Geolocation information and standards alignment
  2. ETSI SOL001 Alignment
  3. A&AI Schema alignment
  4. Complex object updates


External API

MODELINGEpic #2: Geolocation parameters

Epic #2:

  1. Geolocation information and standards alignment
  2. ETSI SOL001 Alignment
  3. A&AI Schema alignment
  4. Complex object updates

Multi-VIM /

Cloud



OOFShankaranarayanan Puzhavakath Narayanan

POLICY



PORTAL

SDN-C

SDCEpic #6: CDS Integration with SDC (Low priority)

Epic #6: CDS integration with SDC (VF/PNF Resource artifact upload screens) (Best effort)

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySDC-2575

SO

Multi-VIM /

Cloud

OOFShankaranarayanan Puzhavakath NarayananPOLICYPORTALSDN-CSDCSOEpic #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.

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySO-2556

Need to sync on the VID implementation of 5G VID Instantiation/orchestration.
VCPE also wants to use these building blocks.

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySO-2339

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySO-1838

VIDEpic #3: SO Building BlocksNeed 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-SDKCDSYuriy MalakovEpic #6: CDS Integration with SDC (Low priority)

List of PTLs: Approved Projects

EPIC / REQ

The Plug and Play Epic for R6 Frankfurt:

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
key

...

REQ-

...

List of PTLs:Approved Projects

EPIC / REQ

...

134

DCAE

Frankfurt Work ItemDESCRIPTION

DCAE1: Secure PnP



CMPv2 for operator certificate enrollment for VES Collector to correctly handle pnfRegistration event.

Jira
serverONAP JIRA

...

serverId425b2b0a-557c-3c0c-b515-579789cceedb
key

...

DCAEGEN2-

...

1794

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

DCAE1: Secure PnP

CMPv2 for operator certificate enrollment for VES Collector to correctly handle pnfRegistration event.1794
Frankfurt Work ItemDESCRIPTION

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-

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)

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyDCAEGEN2-1775

AAF

1775



AAF

Frankfurt Work ItemDESCRIPTION
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 ItemDESCRIPTION
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

Associating a xNF to a Service. Seen in the VID UI, after instantiation waiting for registration see only a Service instance, and beyond that a PNF resource instance associated with it. 

DEVELOPMENT STATUS:

[SO] Support of SO for an already existing PNF (active) A&AI Entry

(use case with a deleted & recreated service or instantiating 2nd service using the same PNF)
Within ONAP/Beijing - In Step #19B SO would exit and service creation would continue

DEVELOPMENT STATUS:

In ONAP/Casablanca this was updated, and irrespective of AAI entry existence for a PNF instance, the workflow execution always waits to receive a PNF registration event797This is not planned to be changed in ONAP/Dublin release.

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

.

Jira
serverONAP JIRA
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keySO-

2556

Need to sync on the VID implementation of 5G VID Instantiation/orchestration.
VCPE also wants to use these building blocks, but a fully generic solution is desired and targted.

 SO2: Service & NF Instance Association

Associating a xNF to a Service.
Seen in the VID UI, after instantiation waiting for registration see only a Service instance, and beyond that a PNF resource instance associated with it. 

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 ITEMDESCRIPTION
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:

  1. Service Model contains a PNF resource type.Service type = vCPE

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.
We`d have to check, what capabilities and conditions could be applied to display and process this “PNF Correlation ID parameter”.

Can the same BBs could be re-used in “standard” vCPE use-case.
We`re looking at a generic solution, and we`d probably display this additional field, when we figure out, that there is a PNF resource used in a Service Model.

...

PresentationFile
Presentation for Epic #4:

View file
name2019-09-24 ONAP_Secure_Communication_PNF_PnP_R6.pptx
height250

Slides for SO work
(Generic SO BBs for PNFs)

View file
namePNF PnP as Building Blocks-v24-20191203_115837.pdf
height250



...