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

1 Functionality Requirement

1.1 New Features Requirement 

Feature NameFeature DescriptionPriority
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 NameFunction DescriptionPriority
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

AlignmentDescriptionPriority
R2 Model alignmentR2 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

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 TestFind 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
OOM IntegrationIntegration with OOM to deploy VF-CHigh
A&AI IntegrationImprove 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 grantingMedia


3 Non-functional Requirement

Reference  ONAP R2 proposals for Non-functional requirements

Non-functional Requirement

Requirement Description

Priority
Community S3P requirementsRequirements 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