Versions Compared

Key

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

...

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

1 Functionality Requirement

...

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
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
    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
    the image to be used for one particular VNFC should be passed on S-VNFM interface during grant response

    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)
    Separation of creation from instantiation
    • on S-VNFM API the creation & instantiation should be separate API call
    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
    Workflow function improvementsupport workflow loading distributed by SDC
    R2 Model alignment
    R2 Information Model and Data Model alignment
    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