...
This page is used to collect VF-C requirements for Beijing Release. Welcome feedback.
1 Functionality Requirement
...
Functionality Requirement
...
Requirement Description
...
1.1 New Features Requirement
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) | | High |
Indirect Mode | - support Indirect mode related to VNF-related Resource Management
| High |
1.2 Function improvement
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 |
---|
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 |
---|
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)
- VF-C should authenticate itself to S-VNFM
- 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 |
---|
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 |
---|
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 |