| Info | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Some material:
Meeting Minutes - 3/3/2021
...
- Trudy Morgan : Present first ONAP/OPS-5G use cases
- 5 year effort - all work being done in the LF. Work will be up-stream w/o forking code
- NIWC: Naval Information Warfare Center
- Research project - all work is unclassified.
- Deck presented today: OPS 5G Use Case.pdf
...
#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
...
#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
...
- Review of the integration with Magma Controller/GWs
- Code updated for AWS environments and is how available.
- Up and running with 2 deployments
- fully containerized GW planned for v1.6 ( ~4 weeks out)
- discussion this week and next should have sufficient content for the DTF
- standard SDC/SO/Multicloud model should be able to be used.
- potential for SDNC or CDS might be able to be used later - TBD
- Possibility of plug-n-play model to be used for AGW - something to look at
- Installing the access GW automatically would be valuable
- existing Magma baremetal upgrade model installs as a new package or collection of packages
- For ONAP assumption of initial deployments are PNF and time permitting then on CNF
- https://github.com/magma/magma/tree/master/experimental/cloudstrapper
- Suggestion to have a meeting next week at the same time with a smaller group. (TAC conflict noted)
- Same bi-weekly bridge to be used- David McBride will host, Kenny Paul will set up invite
- Information about Magma Security requirements @Arun Thulasi
- public certs are used for connects between internal components and HTTPS
- Magma provides the certificate to client
- https://docs.magmacore.org/docs/orc8r/architecture_modularity
- https://docs.magmacore.org/docs/orc8r/architecture_security
- https://docs.magmacore.org/docs/orc8r/architecture_overview
- The three above links should address some of the questions that we discussed in better detail
- DTF Event in June - 2021-06-DD - ONAP TSC Task Force: ONAP For Enterprise Business
- Is the slot OK i.e. Tue Jun 8 2021, 16:30 - 17:30 CET/10.30am-11.30am EST?
- Shall we meet on June 2nd, 2021 to finalize the DDF presentation?
- ONAP For Enterprise call will be canceled on June 9th due to DDF event.
...
- Magma/ONAP Integration - latest updates
- Prabhjot Singh Sethi
- #1 enabling 5G as part of the Access GW will be part of the next Magma release (v1.6) but roadmap not yet finalised
- No major in the Configuration API discussed on 7/7
- Network slicing and complex features will be part of later Magma releases (but not v1.6)
- Prabhjot Singh Sethi
- LF Edge - Ike Alisson
- Discussion about Network Slicing
- Information sent offline by Ike
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?
Agenda - 8/4/2021 @7.30 am PST
...