Versions Compared

Key

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

...

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

...