...
- This project will deliver a unified set of VNF Guidelines and Requirements.
- The VNF Guidelines and Requirements must be versioned to enable evolution based on operational experience
- The VNF Guidelines and Requirements will support the ONAP Architecture Principles.
- Identify a list of features and functionality will be developed.
- The VNF Guidelines and Requirements will support the Release 1 Use Cases.
- Use cases focused on VNF Requirements may be developed in this project, and they will need to be aligned with the ETE Platform use cases.
- It will be incorporating and integrating the source material on VNF Guidelines and Requirements from OPEN-O and ECOMP in Release 1
- VNF Guidelines and Requirements are to be refined beyond prototype text (e.g. through EPIC statements, use cases) to deliver test cases and test procedures for us in VNF onboarding & validation. VNF Requirement level use cases to be aligned with ETE platform use cases
- Identify what is in or out of scope. During the development phase, it helps reduce discussion.
- VNF Guidelines may be forward looking, or include best practices in VNF design and VNF lifecycle processes.
- VNF Requirements from ONAP APIs should be linked to the ONAP Release
- VNF Requirements may include:
- expected operational characteristics ( e.g. security, resilience, upgradeability)
- conditional requirements (e.g. When configured for deployment on High Availability Network Cloud Infrastructure, the VNF Shall …)
...
TSC Use Case | VNFs identified in TSC Use case |
---|---|
(obselete)Use Case: VoLTE (vIMS + vEPC) | N/A |
Use Case: Residential Broadband vCPE (Approved) | vBNG, vG_MUX, vG, vAAA, vDHCP, vDNS |
Use Case: vFW/vDNS (Approved) | vFW, vPacketGenerator, vDataSink, vDNS, vLoadBalancer, all VPP based. |
Use Case: VoLTE(approved) | vSBC, vPCSCF, vSPGW, vPCRF, VI/SCSCF, vTAS, VHSS, vMME |
...
- a VNF Provider (developer) using VNF Requirements in designing, testing, and certifying a VNF for use on ONAP
- a Service Provider using VNF Requirements as prototype text for RFPs to acquire VNFs to run in an ONAP context see VNFRQTS-16
- VNF Validation Project uses VNF Test Descriptions developed by this project to implement VNF testing for validation purposes.
...
- A set of Integrated VNF Requirements for use as prototype RFP text.
- VNF Test Descriptions for use by VNF Validation project
Functionalities
List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.
...
Sub-components are repositories are consolidate in a single centralized place. Edit the Release Components name for your project in the centralized page.
...
Other ONAP projects that this VNF Requirements project depends on?
- SDN-C (for API requirements on VNFs)
- APPC (for VNF configuration requirements)
- VF-C (for VNF life cycle managment and configuration)
- Service Design & Creation (for VNF onboarding)
- DCAE (for VNF reporting requirements)
- Authentication and authorization Framework (for VNF Security Requirements)
- Modeling (for Tosca Data Modeling for VNF)
- Multi-VIM/ MultiCloud (for network cloud infrastructure requirements)
...
The VNF Requirements project (as a non-code project) does not directly interface with APIs, however, it is expected that VNF Requirements may reference APIs that VNFs may be required to support.
Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.
Prior to the delivery date, it is a good practice to organize an API review with the API consumers.
API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
---|---|---|---|---|
To fill out | High level description of the API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
SDN-C | API requirements on VNFs | M2 | M3 | |
APPC | VNF configuration requirements | M2 | M3 | |
VF-C | VNF life cycle management and configuration | M2 | M3 | |
Service Design & Creation | VNF onboarding | M2 | M3 | |
DCAE | VNF reporting requirements | M2 | M3 | |
Authentication and authorization Framework | VNF Security Requirements | M2 | M3 | |
Modeling | Tosca Data Modeling for VNF | N/A | ||
Multi-VIM/ MultiCloud | network cloud infrastructure requirements | N/A |
...
Project Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
---|---|---|---|---|
To fill out | High level description of the API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
VNF SDK | VNF tooling should support the development and packaging of VNFs that are conformant to the VNF Requirements | N/A | ||
VNF Validation program (ICE) | VNF Validation should be traceable against the VNF Requirements | N/A see the VNFRQTS <> VNF Validation project Workflow wiki page | ||
Documentation | References to deliverables produced by this project may be included in various ONAP release documents maintained through the documentation project | N/A see the VNFRQTS <> Documentation Project Workflows wiki page | ||
Reference VNFs (now Integration Project) | Reference VNFs should be VNF Requirement compliant. The Integration Project maintaining those Reference VNFS would be dependent on the VNF Requirements for validating compliance. | N/A see the VNFRQTS <> Integration Project Workflow wiki page |
Third Party Products Dependencies
...
This VNF Requirements project does not generate code to be integrated by the Integration project.
However, the Integration project may be integrating VNFs, and those VNFs should have documented their degree of compliance against the published VNF Requirements.
refer to the VNFRQTS <> Integration Project Workflow wiki page.
Gaps
This section is used to document a limitation on a functionality or platform support. We are currently aware of this limitation and it will be delivered in a future Release.
List identified release gaps (if any), and its impact.
...
Risk identified | Mitigation Plan | Contingency Plan |
---|---|---|
documentaton tool chain | prioritize tasks to resolve tool chain | defer to Beijing release |
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.
...
Date | Project | Deliverable |
---|---|---|
July 21 | VNF Requirements | seed contributions in proper formats and repos |
July 28 | VNF Requirements | documentation tool chain generating:
|
August 1 | VNF Requirements | Sprint 1 defined |
August 3 | VNF Requirements | M2: Test Cases Defined |
August 15 | VNF Requirements | Sprint 1 complete, Sprint 2 Defined |
August 24 | VNF Requirements | M3: |
August 29 | VNF Requirements | Sprint 2 complete, Sprint 3 Defined |
September 12 | VNF Requirements | Sprint 3 complete, Sprint 4 Defined |
September 14 | VNF Requirements | M4:(postponsed by TSC) |
September 26 | VNF Requirements | Sprint 4 complete, Sprint 5 Defined |
September 28 | VNF Requirements | RC0M4 |
October 10 | VNF Requirements | Sprint 5 complete, Sprint 6 Defined |
October 12 | VNF Requirements | RC1RC0 |
October 24 | VNF Requirements | Sprint 6 complete. |
October 26 | VNF Requirements | RC2RC1 |
November 216 | VNF Requirements | RC2 / Signoff |
Documentation, Training
...
Refer to the wiki page on VNFRQTS <> Documentation Project Workflows
Other Information
Vendor Neutral
...