...
Release first proposed | TSC Use Case | VNFs identified/impacted in TSC Use case |
|---|---|---|
| Amsterdam | Use Case: Residential Broadband vCPE (Approved) | vBNG, vG_MUX, vG, vAAA, vDHCP, vDNS |
| Amsterdam | Use Case: vFW/vDNS (Approved) | vFW, vPacketGenerator, vDataSink, vDNS, vLoadBalancer, all VPP based. |
| Amsterdam | Use Case: VoLTE(approved) | vSBC, vPCSCF, vSPGW, vPCRF, VI/SCSCF, vTAS, VHSS, vMME |
| Beijing | 5G- RAN deployment, Slicing, SON | |
| Beijing | Enterprise vCPE --potential R1 use cases’ extension | vCPE, vAAA, vDHCP |
| Beijing | ONAP Change Management | |
| Beijing | SD-WAN | vBG |
| Beijing | Scale Out | VOLTE, vDNS |
| Beijing | Centralised Parser Distribution | |
| Casablanca |
PNF onboarding & Packaging PNF Registration, VES Event domain | |
| Casablanca | CCVPN(Cross Domain and Cross Layer VPN) USE CASE |
|
| Casablanca | Centralized Representation and Consistent Identification of Cloud Regions In ONAP | |
| Casablanca | Change Management Extensions |
|
| Casablanca | Edge Automation through ONAP | Access Management will leverage the PNF management |
| Casablanca | OpenSource Access Manager | Access Management will leverage the PNF management |
| Casablanca | Scaling Use Case Extension | In Beijing the operator had to manually select the controller type (SDNC or APPC) within VID. The controller type should be part of the VNF model and not a run time option. |
| Casablanca | HPA Casablanca Plans (ONAP).pdf |
|
...
Sub-components are repositories and are consolidated in a single centralized place. Edit the Release Components name for your project in the centralized page.
| Deliverable | repo | Files Structure of repo |
| VNF Guidelines: | vnfrqts/guidelines | File per chapter |
| VNF Requirements: | vnfrqts/requirements | File per chapter |
| VNF Use Cases: | vnfrqts/usecases | File per Use Case |
| VNF Test Descriptions: | vnfrqts/testcases | File Per Test Case DscriptionDescription |
| VNF EPICs: | vnfrqts/epics | not used in Casablanca Release |
...
| Risk identified | Mitigation Plan | Contingency Plan |
|---|---|---|
| ONAP supporting multiple onboarding formats | work with VNF SDK, VVP and SDC to minimize the risk. | Document the desired direction in the forward looking VNF Guidelines |
| Inconsistency between published VNF Requirements and ONAP Platform |
| document discrepancy in release notes |
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.
| Milestone | Deliverable | Date |
|---|---|---|
| M0 | Intent to Participate | June 14, 2018 |
| M1 | Release Plan M1 Checklist | June 28, 2018 |
| M2 | M2 Checklist | July 26, 2018 |
| M3 M3 | M3 Checklist | August 23, 2018 |
| M4 M4Checklist | M4 Checklist | September 20, 2018 |
| RC0 RC0 | RC0 Checklist | October 11, 2018 |
| RC1 | RC1ChecklistRC1Checklist | October 25, 2018 |
| RC2 RC2 | RC2 Checklist | November 8, 2018 |
| Signoff Signoff | Signoff Checklist | November 15, 2018 |
...
Documentation, Training
- The VNF Requirements is documentation built using the LF toolchain from .rst files into html. This tooclhain is administered by the documentation project. The toolchain provides for syntax checks of the documentation within Sphinx, doc8 etc.
- The VNFRQTS Project publishes a VNF Provider User Guide:
- VNF Guidelines
- Component lead - Wenyao Guan (China Mobile)
- VNF Requirements
- Component Lead - Hagop Bozawglanian (AT&T)
- VNF Provider Use Cases
- Component Lead - Scott Blandford (AT&T)
- VNF Test Descriptions
- Component Lead - Steven Wright (AT&T)
- Release Notes
- VNF Guidelines
Other Information
...