Versions Compared

Old Version 17

changes.mady.by.user luman wang

Saved on

compared with

New Version Current

changes.mady.by.user Vimal Begwani

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Would the use case(s) require multi-site support?
  2. Would the use case(s) require multi-region/multi-domain/federation support?
  3. Would the use case(s) require Multi-national support?
  4. Do we need to consider enhanced networking features (e.g., underlays)?
    1. 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.
  5. Can individual use cases be built from same components? (common APIs/models)
    1. 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.
  6. What are the challenges from the first set of use cases?
  7. What technical debt have you identified?
    1. 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. 
  8. Clarify business drivers and capabilities of the use cases
    1. 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.
  9. What are the functional commonalities between the use cases? Are there generic elements where we should focus?
    1. 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.
  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.
    1. 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.
  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?


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?

  1.   Multi-region (= multiple ONAP instances?): No
  2.   Multi-domain:   Yes
  3.   lifecycle   of ≥1 RAN domains
  4.   lifecycle   of ≥1 slice instances                                                                      
  5.   lifecycle   of RAN+WAN+EPC domains
  6.   .....any   other?
  7.   federation   (=multiple operators): No

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?

  1.   what   "same <onap?> components"?
  2.   what   existing APIs/Models?, e.g., generic VNF model?

6

What are the new   challenges from the first set of use cases?

  1.   Support   a hybrid network consisting of PNF & VNF across RAN, WAN and EPCore
  2.   Support   CRUD on Network Slice(s)
  3.   Design   studio (SDC) enhancement
  4.   Component   models: e.g., RAN VNFs, Core VNFs, PNFs, etc..
  5.   E2E   model(s): e.g.,service chain (tosca) topology
  6.   policy   model(s)
  7.   ...other?
  8.   AAI   enhancements to capture topology & inventory. 
  9.   SO   / App-C / DCAE / Policy enhancements to support for PNF and slice   lifecycle management, slice deployment and management.
  10.   DCAE   / Policy enhancements to support open framework for near-real time network   optimization, conflict resolution during design time as well as run time   across multiple microservices.
  11.   OOF   enhancements to support multi-cloud and 5G network optimizations.

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:

  1.   Enhance   ONAP platform capabilities for supporting hybrid network consisting of PNFs   & VNFs in a multi-domain (RAN vs WAN vs EPC) scenario
  2.   demonstrate   use of ONAP platform to realize following:
  3.   (simple?)   A planned list of 5G Nodes are on-boarded into ONAP, and ONAP configures the   Nodes to the level they are ready to handle traffic. ONAP begins to actively   monitor and manage the nodes.  
  4.   CRUD   operations on RAN-only slice(s) and RAN-to-EPC slice(s)
  5.   Optimizations

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

...