VF-C Requirements Collection for Beijing Release

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

• NS/VNF manual scaling

• support Indirect mode related to VNF-related Resource Management

• support VNF Image storage and distribute to VIM

• support workflow loading distributed by SDC

Note: Depend on the implementation of SDC

Analyze the differences, try to align the relevant interface

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

• 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

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

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

• 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

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

• 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

• 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

• 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

• 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

• 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

• 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)

• be able to define externally managed internal virtual links in VNFD
• VF-C should pass the virtual links during instantiation

Existing interface aligns with ETSI SOL003

• support VNF modify interface
• on S-VNFM API the creation & instantiation should be separate API call

• 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