Versions Compared

Old Version 3

changes.mady.by.user Alex Vul

Saved on

compared with

New Version Current

changes.mady.by.user Tina Tsou (Deactivated)

Saved on

Key

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

...

Gliffy
size1200
nameEnd-To-End Flow


1VNF
Developers
developers use
VNF SDK
the VNFSDK tools to create VNF descriptors based on the TOSCA YAML templates.
If a given
VNF
has
hardware platform capability
dependencies
requirements, if any,
they
are
included
captured in the VNF descriptor.
2VNF
Developers use V.NF SDK
developers use the VNFSDK tools to create VNF packages and upload them to the VNF marketplace.
VNF marketplace validates uploaded VNFs and makes them available for download
Uploaded packaged are validated and made available for use by ONAP operator(s).
3
The SDC downloads
VNF packages are downloaded from the VNF marketplace using SDC tools and on-
boards them
boarded into the SDC catalog for use by
Service Designers
ONAP service designers.
4

Service

Designers

designers use SDC design tools to

create

build and maintain network services

and make them available

. Network services are stored in the

catalog for use by Service Consumers

SDC catalog and made available to service consumers.

5Service
Consumers
consumers browse the SDC catalog and choose
a service
services for instantiation.
6

Requests for instantiation are passed to the SO. The SO

downloads appropriate

obtains NSD and VNFD

definitions

information from the SDC.

If hardware

Hardware platform capability requirements

were present, they

are downloaded as

well

part of the VNFD data.

7
The SO decomposes the service and calls OOF to optimize its homing and placement.

SO at present has 2 possible options to take over from here

  1. Modify the existing flows (used by VCPE in amsterdam) to do service decomposition and call the OOF APIs to perform the optimize service/VNF homing and placement.
  2. Introduce new flows that would invoke the TOSCA DO inside SO to perform the decomposition and OOF interactions

Hardware platform capability requirements are passed to the OOF

as well

.


8The OOF
consults
uses the resource information stored in the AAI inventory database to obtain resource topology and
capability information
capabilities data. It them makes use of placement policies to determine optimal homing and placement of a given network service.
9Infrastructure
Providers
providers register VIMs with the Multi-VIM layer, as part of the resource on-boarding process.
10
As part of
During the VIM registration process, resource topology
information
and
hardware platform
capabilities
are
data is discovered and persisted in the AAI inventory database
for subsequent use by the OOF.
. From the HPA perspective, the AAI acts as the system of record for all HPA related information.
11Any "day 2" operations that require VNF (re)instantiation, are performed by calling the SO and OOF components. Therefore, no changes to the "day 2" controllers is required in support of HPA.


General Assumptions


This proposal does not require changes to the ONAP architecture and makes use of the existing ONAP management components. The following diagram identifies the ONAP components affected by this project:

...