VF-C Requirements Collection for Beijing Release



This page is used to collect VF-C requirements  for Beijing Release. Welcome feedback.

1 Functionality Requirement

1.1 New Features Requirement 

Feature Name

Feature Description

Priority

Feature Name

Feature Description

Priority

NS/VNF auto scaling(in/out)

  • NS/VNF auto scaling out/in based on policies

High

NS/VNF manual scaling(in/out)

  • NS/VNF manual scaling

High

Indirect Mode

  • support Indirect mode related to VNF-related Resource Management

High


1.2 Function improvement

Function Name

Function Description

Priority

Function Name

Function Description

Priority

VNF Image Management

  • support VNF Image storage and distribute to VIM

Note?Depend on the implementation of SDC and other related modules



Workflow function improvement

  • support workflow loading distributed by SDC

Note: Depend on the implementation of SDC




1.3 Alignment with models and specifications

Alignment

Description

Priority

Alignment

Description

Priority

R2 Model alignment

R2 Information Model and Data Model alignment base on the output of modeling subcommittee

High

Interface align with ETSI SOL003

Analyze the differences, try to align the relevant interface

Note: Interfaces with ETSI alignment, is the guiding principle to VF-C implementation

Interface Design alignment



1.4 Other Requirement Feedback ----------Used as a record and need to continue analysis

Functionality Requirement

Requirement Description

Functionality Requirement

Requirement Description

VNF scale to

  • On the VF-C LCN interface the LCN should support scale to as operation type

  • On the S-VNFM interface the scale to operation should be available

VNC Flavour Management

  • the flavour to be used for one particular VNFC should be passed on S-VNFM interface during grant response

VNF availability zone management

  • the availability zone to be used for one particular VNFC should be passed on S-VNFM interface during grant response

Multiple instantiation level support

  • it should be possible to define multiple instantiation levels in VNFD (without using vendor specific extensions)

  • the instantiation level to be used should be passed on S-VNFM interface during instantiation

Externally supplied addresses

  • it should be possible to pass external IP addresses, subnet ids ... for each external connection points

Affinity support

  • it should be possible to define affinity policies in the VNFD

  • VF-C should send the availability zones to be used in accordance to the VNF affinity requirements in VNFD

  • VF-C should take the affinity requirements (host and zone) when answering grant on S-VNFM interface

VNF attribute support

  • it should be possible to define VNF specific attributes in VNFD (without using vendor specific extensions)

  • the VNF attributes should be sent from VF-C S-VNFM during instantiation

Security issues

  • both KeyStone authentication domains should be visible on S-VNFM VIM query API

  • it should be possible to define multiple endpoints for a single ESR (S-VNFM)

  • S-VNFM should authenticate itself to VF-C (LCN & granting)

    • possibly OAUTH

  • VF-C should authenticate itself to S-VNFM

    • possibly OAUTH

  • SSL should be supported on VF-C APIs (LCM, catalog)

  • SSL should be supported on S-VNFM API

    • the VNFM query should provide the trusted CA certificates for VF-C interfaces

  • the human user that initiated the request via portal should be passed along each request from VF-C to S-VNFM

    • required for RBAC in S-VNFM

  • the KeyStone version to be used (v2/v3) should be available in VIM query interface

Granting support

  • the images, zones and flavours to be used should be sent in the grant response

  • VF-C should interpret the grant request & VNFD and make a decision based on resources being available on the cloud

LCN support

  • affected storages should be interpreted & defined on S-VNFM interface

    • A&AI should be updated according to storages

  • affected CP / ECP should be reportable via VF-C LCN API

  • floating IPs should be reportable in affected CP / ECP

Healing support

  • unique identifier should be sent in the heal request (ex. VNFC id) (the name of the VM is not unique)

  • it should be possible to send additional data during healing (same as instantiation)

Externally managed internal virtual link support

  • be able to define externally managed internal virtual links in VNFD

  • VF-C should pass the virtual links during instantiation

GVNFM usecase Test

Find GVNFM usecase and test

Interface align with ETSI SOL003

Existing interface aligns with ETSI SOL003

  • support VNF modify interface

  • on S-VNFM API the creation & instantiation should be separate API call


2 Integration with other projects(VF-C will consume the interfaces these projects provided ):

Functionality Requirement

Requirement Description

Priority

Functionality Requirement

Requirement Description

Priority

OOM Integration

Integration with OOM to deploy VF-C

High

A&AI Integration

Improve integration with A&AI(Virtual resource created by VF-C save to A&AI )

High

OF Integration 

Plan to integration with OF when do resource granting

Media


3 Non-functional Requirement

Reference  ONAP R2 proposals for Non-functional requirements

Non-functional Requirement

Requirement Description

Priority

Non-functional Requirement

Requirement Description

Priority

Community S3P requirements

Requirements abou S3P



Follow naming conventions on APIs

  • Document improvement

  • each API should use the same naming convention for names, types, constants, collections

    • ex. camel case vs all capital letters vs all small letters

    • ex. using dashes vs underscores for separation of types & constants & names

    • ex. use short vs long name of variables (ex. vnfId vs vnfInstanceId vf instId )

  • non supported features should not be visible on API

High