#1 What does ONAP offer to an enterprise customer (IoT, Financial, Healthcare, Gaming, etc) that we can't get from existing cloud offers or outside the Cloud.
#2 What does ONAP offer on top of that outside of the telco space?
Different Scenarios
1) 3rd party vendors using ONAP to serve their enterprise customers (operating model - managed services)
2) Operators offering solutions to Enterprises (based on 5G Techno - Network Slicing, Virtual Edge, etc) supported by 3rd party vendors
Feedback from Carriers:
Fernando Oliveira- Investment in Gaming, Edge Computing - possibility to re-use ONAP as a key orchestrator
Catherine Lefevre - Edge Computing is the area where AT&T have invested (i.e. Akraino) in conjunction with ONAP possibilities; We have a Gaming division inherited from TimeWarner but not yet explored added-value of ONAP in this space
3) Enterprise customers running ONAP themselves (on their premises), supported/trained by 3rd party vendors
Additional thought(s)
#1 Investigate what Openstack is offering to Enterprise Business?
to rebrand ONAP and its components outside the "Network" domain
to be able using ONAP components independently
to demonstrate with some real cases ONAP components with other systems/applications (not CNF, PNF, VNF)
to use ONAP (or a subset of ONAP) as a black box
Survey- key items (in progress)
Comments: Need to re-adjust the survey and also ONAP message based on "Enterprise" Terminology
What are your goals about Cloud migration?
Are you already hosting your IT applications in public cloud or private cloud managed by a 3rd party vendors? If not - Where are you in your virtualization journey?
What are the different major steps being part of your migration?
Which OSS/BSS systems/IT applications will not be part of your virtualisation journey? Hybrid model (Private on prem/Cloud & Public Cloud)
(After introducing ONAP) which consumption model do you think you would like to adopt? Or will you adopt another one not listed below? Need to re-adjust the consumption model for Enterprise Business
Have you any regulatory requirement to be considered?
Any particular device/standard to be supported and connected to your IT application(s) ?
Size of production deployment (small/medium/large)? Define "size' for Enterprise Business
What would you consider "as a service" for your Enterprise Business (which application, what type of IT support, etc?)
Goal is to use as much OSS as possible, but may need commercial solutions initially in areas that are less OSS mature like RAN i.e. 5UE, Commercial gNB
From a testing perspective, the goal is to us Nationwide network to enhance DoD ability to test 5G Core security (Multisite OPS 5G Joint Independent Testing Option) but it will also dependent on Magma deployment model.
ONAP capabilities to support this program:
Orchestrate/Instantiate and Magma Orchestrator (instead of SO)
ONAP Network Slicing functionalities
LCM
Control Loop mechanisms (including ONAP/Acumos)
Akraino/ONAP Blueprint
Believe that we need to be proactive on this
Would like Aarna to provide a regular update on progress to this team. Set aside the first 5-10 mins of every meeting for that purpose.
Need to make sure that standard process workflow is followed for feeding requirements into the community
ONAP Enterprise Task Force will be the first entry point for OPS 5G program supported by the Requirements, Architecture and Security subcommittee representatives.
ONAP/Magma discussions on April 8th - Deep Dive about ONAP
Current understanding is that we could use REST API (northbound ITF) or Mesh
OPS 5G meeting on April 9th - focus on E2E Network Slicing
Welcome and IntroductionNeil Hoff, NIWC PAC
Super Blueprint and 2021 Roadmap, including slicing Amar Kapadia, Linux Foundation
OPS-5G Technical Area 3 (SABRES) – Secure SlicingDr. Erik Kline, USC/ISI
MAGMA - Target release for network slicing and timeline for requirements developmentAmar Padmanabhan, Facebook
ONAP - How network slicing will be orchestrated by ONAP Swaminathan Seetharaman, Wipro
OUSD(R&E) comments / discussion
Key take away: Align people on "what it is a Slice" terminology
How could ONAP interact with Magma GW/Magma Controller?
Some additional info about Magma
First deployment of 5G-FWA in June 2021 (Brazil)
Can be deployed on ARM/ESXI
Horizontal scaling
NB ITF= REST (to be connected with ONAP) or Mesh
3 options:
#1 Create a dedicated controller via SDNC and handle Magma GW like any other device
#2 Have an adapter for the magma in ONAP Service Orchestrator and use it as a resource orchestrator for the specific jobs. Disadvantage: create something specific
#3 5G PNF Plug & Play and consider Magma GW as a PNF?
Current proposal: Avoid to create something specific but re-use what it is already developed in ONAP (SO/SDNC/SDNR) and orchestrate directly the Magma GW via gRPC
Need to understand what it is behing the Magma GW and explore if there is a possibility to interact directly with the devices? Maybe not acceptable
Feedback from Swaminathan Seetharaman about future scope/functionalities/roadmap supported by CSMF (Communication Service Management Function)
With ref. to the roadmap for CSMF, there is nothing planned for Istanbul release. Anything beyond it will depend on the interest from use case contributors and/or community.
A few points which came up in our earlier discussions include the following. However, none of them have progressed further since then.
#1 Control Loop actions at Communication Service (e.g., eMBB) level (service assurance) which will be driven by CSMF. This could result in slice-level reconfigurations, or even re-mapping of the service to a different slice instance.
#2 Having different service priorities, e.g., resulting in pre-emption (when needed) during service fulfilment and during operation, for services having a higher priority
Magma GW = to be considered as CNF (by June 2021); currently available as PNF/VNF
Magma Controller= CNF
#2 Currently the goal is to interact with the Magma Controller as a first step directly.
As part of the roadmap, we should also investigate if there is a way to interact directly with the Magma GW (reduce 1 overhead layer between Magma/ONAP)
Additional information are required about Magma Controller to finalize the right architecture.
#3 Currently the scaling of GW is manual and triggered by the user.
Magma Controller is also manual so both (Controller/Magma) can be orchestrated via ONAP
Opportunity for ONAP to automate the scaling of Magma GW (Control Loop)
#4 Can we conclude Magma is an EMS (Element Management System)? YES
#5 5G Blueprint based on Guilin/Honolulu? Magma release is scheduled by June 2021 therefore let's consider ONAP Honolulu release
#6 Is there any Security Magma requirement? based on HTTPS, Mesh? Not yet available.
Currently used DockerCompose, next step will be used Helm v3.0.
#7 Any information about Magma packaging, modeling requirement?
Recommendations: TOSCA descriptor pointing to HELM (in alignment with ETSI specs
Byung-Woo Jun - Next on ONAP CNF Task Force - every Thursday at 1pm UTC
Initial analysis about Magma integration on April 29th, 2021
Review of the integration with Magma Controller/GWs
Byung-Woo Junshared the latest Magma architecture proposal
Amar Kapadia explained that there are two interactions expected with ONAP: Deployment/Onboarding & Instantiation
Arun Thulasi (from Magma's team) provided additional information about how Magma Controller & GWs are deployed. Magma Controller is today deployable on AWS K8s. Goal is to have GWs fully containerized by June 2021. Magma controller (orc8R) is managing all GWs. Additional information: Configure AGW · Magma Documentation
Chaker Al-Hakim sees Magma components as services orchestrated by the ONAP Platform. ONAP will onboard Magma via SDC, instantiate Magma Controller via SDNC and then collect KPIS/Telemetry data to trigger any Control Loop action (if required) + Network Slicing capabilities (NSMF through NBI)
Prabhjot Singh Sethi shared the HL Integration Plan
Upstreaming - each project will host the source code and provide artefacts/containers to be used for 5G Super Blueprint
Feel free to review offline and add any component
How do we plan to communicate with the other open source communities about 5G Super Blueprint (Akraino, Anuket, LF Edge) to discusse dependencies and requirements?
<Catherine> Bring this item to the next 5G Super Blueprint call.
Functionalities (3GPP TS 23 501 Rel 17 June 2021) related to "Session Service Continuity" (deliberately not including details on SSC Mode 1-3 related to UPF/PSA selection/re-selection) and "Local Traffic Routing" functions/capabilities for "inter-" and "intra-" Platforms/Systems communiction (HPLMN and VPLMN) with regard to %G NFs Cloud Native factors adoption in CSP Service Solution Frameworks.
Related to that, there is also the issue of Authentication, Authorisation and Accounting (also as part of the Security) (SUPI; SUCI; GUTI) for both, Applications/Service commissioning/instantiation and Users and related to them UEs.
As it is recently stated in some reports on that issue (adoption of Cloud Native capabilites and Cloudification in CSP/Cellular/Wireless Networks), it becomes apparent that VNFs implementing NFs such as Firewalling, IP Address assignment or Switching & Routing might not be able to comply entirely with the Cloud Native paradigm.
E.g aiming at 3GPP Service Communication Proxy (SCP/SeCoP), as a CNF, a Component performing Proxy-like Routing Tasks can be certainly decomposed into Micro Services based on their Workload type (e.g. Long-Running Tasks versus Short Logical Operation to determine an outcome). However, by De-composing a NF into Microservices the newly created CNFs need to be addressable among each other based on Stateless Protocols like HTTP. The result is a typical “Chicken and the Egg” Problem, as the CNFs were supposed to implement Service Routing, but relies on a Service Routing among them.
Other Factors such as Port Binding and Dev/Prod Parity simply do not apply to Functions that sit below the Transport Layer where Ports are exposed.
Furthermore, for Networking related Tasks (Routing, Firewalling, etc.) Packets from senders such as the UE that are supposed to be handled must be encapsulated in a Stateless Protocol to reach the next Microservice that forms the Networking Application. Thus, not all VNFs can be ported to CNFs to enable an economy at scale. However, even though not all Cloud Native factors can be fulfilled for some VNF types, VNFs can be Cloudified aiming at a high adoption of the Cloud Native Factors without the notion of decomposing a VNF into Microservices (CNFs) that form the Application.
Questions about Magma: Is there any performance metrics about Magma? How many users per GW etc without any additional infrastructure? Prabhjot Singh Sethi said that Magma team said that currently put high physical devices as an Access GW, you will get a better number.
Magma Containerization is delayed, not date/commitment yet, phasing approach but the requirements have been created in Github.
Chaker Al-Hakim discussed the LF Open Source Component Projects for 5G under LF Edge umbrella. Chaker invited people to attend the LFN 5G Super Blueprint meeting.
Prabhjot Singh Sethigave some information about Akraino Blue print part of LF Open Source Component Projects for 5G. Magma GW has a monolithic architecture and not yet foreseen for Edge blue print.
Chaker Al-Hakimwill join Akraino TSC meeting to provide some awareness about LF Open Source Component Projects for 5G.
Meeting Minutes - 8/4/2021 @7.30 am PST
SABRES (Secure, Adaptive, roBust, Resilient, and Efficient Slices) presented by Dr Erik Kline
Gervais-Martial Ngueko : Proposal of SABRES Integration into ONAP E2E Network Slicing call flows
CNF TOSCA package being onboarded through ONAP SDC - information shared by Sebastien Determe (SDC Committer) - in progress in preparation to onboard Magma CNF
Seshu Kumar Mudiganti, Byung-Woo Jun provided additional information about ONAP CNFO/SO – CNF distribution/orchestration - further discussions will be organised offline as soon as Lukasz Rajewskiwill be back (re-use the ONAP Enterprise slot?)
=> Catherine to open the bridge on Wednesday (8/25) at xxx- team to let us know
Feedback from Amar Kapadia - Onboarding of standalone EMCO done but integration with ONAP still under discussion a.k.a. EMCO v2 (additional development/integration work will be required)
Magma CNF date not yet available - current path: Magma VNF (1.6?). Nevertheless let's complete our current path so we can learn from our initital integration (not only from a service delivery perspective but also from service assurance, security, resiliency, etc perspectives
ONAP/SABRES Integration - current status: SABRES constructor/validator under prototype/development; ONAP/SABRES - Design level, no implementation/integration yet
Follow-up on Michael August's questions - In order to document a test plan about how to evaluate the network slicing security research being done by Dr. Kline's team. Can the ONAP Community provide information about:
1) Is there an API within ONAP's VNF Manager component or Element Management that enables assignment/allocationto specific pieces of hardware within the NFVI/cloud infrastructure?
Some information are currently available in the AAI component (Active Available Inventory)
Our model can also easily be adapted to store any information needed if our current model does not support it. APIs for inventory operations are auto generated once added to the model.
Can you please review our current model/relationships to see if it supports what you are looking for
Associations between virtual and physical resources is currently done in A&AI.
Question: What level of granularity do we need to consider (pod, container, etc)? Michael to confirm
VNF Manager in the context of ONAP:
#1 external VNFM adaptor provided by SO (ETSI compliant)
#2 VNF (CNF) LCM is provided by SDNC/CCSDK (Heat compliant)
2) If the underlying VIM provides APIs for placement of virtual resources on specific pieces of physical hardware, then does ONAP provide corresponding APIs that the VNFs can use to leverage these VIM placement APIs to perform precise placements of the virtual resources they use onto specific nodes within the physical infrastructure? It also depends on what the VNF/CNF/PNF provide as information.
If the VIM is based on k8S then the new EMCO version (developed by Openness) will support a way to define the platform requirements on per workload basis as intents.
At the time of deployment, it can do match making between requirements and capabilities it discovered early on to select the right K8s cluster.
3) Are there APIs between the Network Slice Instance layer and the Resource layer (resource management functions) that enable a network slice instance to gain information about the current mapping of network slice instances to physical resources? Likewise, are there APIs that enable the network slice instances to leverage specific resources available within the resource layer?
The current Network Slicing functionality (till Istanbul release) hasn't considered VNF placement, resource occupancy levels of a cloud instance, occupancy levels of a VNF, etc. due to a number of reasons (first focus on the basic functionality and key lifecycle phases, limited interest/contributions from community for core slicing (where VNF/CNF will be most relevant), etc.). Some of the aspects were being discussed for future releases beyond Istanbul.
In addition, , there is work done on VNF/VF module placement optimization done in OOF. The HAS functionality in OOF could be leveraged, a couple of references are given
There was also another functionality FGPS (Fine-Grained Placement Service) in OOF which I think is no longer maintained
Seshu Kumar Mudigantiwill provide additional further information about SO NSSMF adaptor, compliant with 3GPP
CSMF and NSMF are implemented using SO BPMN workflows to support 5G network slicing use case. CSMF workflow will process the user input (service request) that comes from CSMF portal (UUI) and save the order information into a communication service instance in AAI. Then CSMF will send network slice request to NSMF workflow, and NSMF will then create service profile, NSI and NSSI. Service profile is a logical concept which exists only in AAI - it contains two AAI instances, one is a profile instance that will hold the slice parameters, and the other is a service instance which will be used to organize the NSI. NSI is also a service instance in AAI which will be used to organize NSSI. NSSI is the actual entity which will be created by NSSMF and an AAI service instance will also be created to represent NSSI in ONAP context. NSI and NSSI can both be shared.
SO queries OOF for slice template selection and then slice instance selection. In response to slice instance selection query, OOF may return an existing slice instance or may recommend SO to create a new slice instance. A new process called Orchestration Task is created to manage recalibration of NSI&NSSI selection with manual intervention from the portal. A new SO adapter is created to be the adapter of NSSMF which will interact with external NSSMF for NSSI management. See theSO Impacts and Interfaces wiki pagefor details.
Amar Kapadia Will check how long Magma 1.5 support will be available? Will VNF Magma GW still available with Magma 1.6? What's the process to raise a bug? How long it will take to fix it?Check if Magma 1.6 API backward compatible (supporting both LTE/5G) to Magma 1.5 ; Amar Kapadia I have followed up with the Magma community on these questions. For now I can confirm that Magma GW is available as a VNF in Magma 1.6.
Amar Kapadiato follow up with Louis (LF) to setup a repository for Helm Charts (Magma special packaging); Amar Kapadia : I have followed up with LJ Illuzzi, LJ Illuzzi any udpate?
(Catherine) To follow up with Swaminathan Seetharaman about scope/functionalities/roadmap supported by CSMF
Kenny): Setup onboarding process for DARPA Program
(Veronica): Provide the Orange Invite to be shared with the ONAP community
(Kenny) Collect any EUAG Use Cases
(Kenny) add an item to TSC call - 3/25 about EUAG for Enterprise
(Kenny) add an item to TSC call - 3/4 - new schedule for Task Force - Enterprises + introduce agenda (3/31) - Alla Goldner, Timo Perala (requirement subcommittee) and Chaker Al-Hakim(architecture subcommittee) to attend
(David): Follow-up with Amar Kapadiaabout TSC presentation about current status regarding OPS-5G & LFN Activities
Chaker Al-Hakim Invite LF Edge to our ONAP for Enterprise Task Force on July 21st
Catherine Lefevre Discuss with Arpit about the new name a.k.a "5G Open Source Stack" - can be confusing with OpenStack initiative from RedHat; preference is to use "Open 5G Stack"
Rework our ONAP Added Values Message in alignment with Vertical Industry & Enterprise Business - presented during the DDF Event in June 2021
Contact Enterprise Business Units within our own company
Prepare the Survey (Discontinued)
Catherine Lefevre "How do we plan to communicate with the other open source communities " - Bring this item to the next 5G Super Blueprint call.
Chaker Al-Hakim Invite LF Edge to our ONAP for Enterprise Task Force on July 21st
and triggered by the user.
