Questions and answers
This page will be used for asking a questions and providing an answers between Architecture and Usecase subcommittees
Questions from Architecture subcommittee to Usecase subcommittee and Usecase subcommittee answers
Would the use case(s) require multi-site support?
Would the use case(s) require multi-region/multi-domain/federation support?
Would the use case(s) require Multi-national support?
Do we need to consider enhanced networking features (e.g., underlays)?
For the Enterprise vCPE use case, we already consider the enhanced networking features both underlays and overlays. For the overlay layer, we support three alternatives ways to set up connection between vCPE/CPE and the firewall on the edge of TIC-core, including VxLAN, IPSec and MPLS. For the underlay layer, we proposed two new components including PCE (Path Calculation Element) and NAI (Network Artificial Intelligence) which support new features of network management including traffic scheduling, QoS support and traffic prediction. After the discussion of harmonization and simplification, we will take the underlay function as stretch goal of this case.
Can individual use cases be built from same components? (common APIs/models)
For the Enterprise vCPE use case, we can reuse the adjusted components from the Residential vCPE use case including multi-vim component, some of the VNFs and some parts of the infrastructure. In the E-vCPE use case, we may adapt different VNFs and also introduce some PNF.
What are the challenges from the first set of use cases?
What technical debt have you identified?
Right now the SDN-C may not fully support the PNFs which may have different versions and adapt different models apart from YANG. So, we may have the needs to introduce 3rd-party controllers to configure the PNFs mentioned above.
Clarify business drivers and capabilities of the use cases
For the Enterprise vCPE use case, Enterprise customers would benefit from cloud services and automation either on-premises or in the cloud depending on their branch configurations. This will free the enterprise users from the installation, local configuration and administration of LAN/NAT/WAN/VPN networking.
SPs would benefit from a more flexible platform to provide more kinds of virtual services. To implement the configuration remotely will help SPs reduce complexity of the service deployment and cut down the OPEX.
The centralized traffic scheduling and optimization of backbone network is the embodiment of SDN concept in backbone network, it will help operators enhance the management ability of operation and maintenance and improve the efficiency of resource utilization.
What are the functional commonalities between the use cases? Are there generic elements where we should focus?
For the Enterprise vCPE use case, it can reuse some VNFs from other use cases such as vDHCP, vFW, vAAA, which requires similar functional capability about VNF configuration and management. Besides, E-vCPE and SD-WAN provide the Site2Site service and introduce the CPE into the system, which require the PNF configuration from SDNC.
Clarification of requirements. For instance, you call out PNFs. What level of PNF support do you need for R2? Also, what are the requirements driving the need for PCE and NAI components? Could those be satisfied by existing components? If not, please clarify why not so that we can discuss how those components fit with the existing components and the rest of the architecture.
For the Enterprise vCPE, we take the advices from others, after the usecase meeting about harmonization and simplification proposal. So we will take the underlay network management including the PCE and NAI components as a stretch goal.
In this release, we will focus on the overlay connection establishment between site to site/DC/Internet including alternative ways and the management of VNFs. If we take traffic scheduling function as a stretch goal , the configuration of ThinCPE/CPE on the custom site are the remaining function which the ONAP need to support in this release.
Discuss key features for R2. From what we can tell, multitenancy/slicing, WAN/connection types, and PNF support seem to be required. Are there others?
Answers to architecture questions from 5G Use Case team:
No | Question | Answer | Additional Info |
1 | Would the use case(s) require multi-site support? | Yes | Site = Node (PNF or ≥1 VNFs) e.g., Radio Unit e.g., Radio Control Function |
2 | Would the use case(s) require multi-region/multi-domain/federation support? |
| |
3 | Would the use case(s) require Multi-national support? | Maybe – minimal impact from this use case to support multi-nations deployment If Operator using ONAP instance across national boundaries, Yes. | e.g., multiple Operating Companies? No No, if multiple ONAP Instances? |
4 | Do we need to consider enhanced networking features (e.g., underlays)? | Not applicable | |
5 | Can individual use cases be built from same components? (common APIs/models) | Yes? |
|
6 | What are the new challenges from the first set of use cases? |
| not part of R1 use cases (ref: Use Case: VoLTE(approved)) |
7 | What technical debt have you identified? | See above | |
8 | Clarify business drivers and capabilities of the use cases | 5G and network slicing are emerging technologies that are complex and distributed. Multiple service providers are getting ready to deploy. his will help 5G technology vendors to understand ONAP requirements and deliver PNF / VNF capabilities that can be managed using ONAP. This use case is expected to: Release 2 Goals:
Future Releases ....?? | |
9 | What are the functional commonalities between the use cases? Are there generic elements where we should focus? | See answer to question 6 above | which (other?) use cases?
|
10 | Clarification of requirements. For instance, you call out PNFs. What level of PNF support do you need for R2? Also, what are the requirements driving the need for PCE and NAI components? Could those be satisfied by existing components? If not, please clarify why not so that we can discuss how those components fit with the existing components and the rest of the architecture | N/A - Seems targeted for the Enterprise vCPE case | |
11 | Discuss key features for R2. From what we can tell, multitenancy/slicing, WAN/connection types, and PNF support seem to be required. Are there others? | See R2 functional requirements candidates (extracted from R2 use cases' proposals) |
Questions from Usecase subcommittee to Architecture subcommittee and Architecture subcommittee answers
Controllers (VF-C/APPC foreseen R2 evolution path
External orchestrator/controllers usage in R2