Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Introduction
After researching on NFs from different vendors, no matter NFs are PNF, VNF or CNF, they are designed as distributed applications, which usually contains functional modules including interface module, data storage module, operation and management module, NF logic processing modules.
Image RemovedImage Removed
Functional modules' description are as follows. Different NFs from different vendors may have difference on design and implementation, but they almost follow this similar design paradigm.
- Interface Module: module in charge of South-North communication between different NFs, which is usually implemented as load balancer.
- NF logic processing modules: modules processing NF service logics. For example AMF contains functions of access management, security management, session management etc., and these functions can be implemented as different NF logic processing modules.
- Data storage module: module stores NF states, user data and service processing context. Cloud native NF requires network logic processing module is stateless and supports scaling in/out horizontally, which usually results in that the NF data are stored in independent DB.
- OAM(operation and management) module: module in charge of NF management, configuration, monitoring, etc.
- Internal communication module: module support internal communication between differrent modules within a NF.
Among all these functional modules, OAM module is one of the most commonly used module within different NFs, which makes it possible to be shared among NFs as a PaaS service. Providing OAM module as a platform capability can relief the developers from spending too much effort on non-NF logic design and development. So in XGVela release 1, cloud native OAM for NF is planned to be delivered.
Draft High-level architecture
Image RemovedImage Added
Figure 1: Draft High-level Architecture of cloud native OAM module
Cloud native OAM is a group of operation and management functionalities, which is treated as a group of tightly related PaaS capabilities running as containers. This module can provide local O&M functionalities for cloud native NFs on edge as well as O&M data service capablity.
Cloud native OAM is planned to be designed as three logical layers: agent layer, processing layer and data sharing layer.
- Agent layer connects with network functions southbound. It will be in charge of the collection of NF's O&M data and operation delivery. Cloud native network functions can use the methods defined by Agent layer to get connected with and use functions of cloud native OAM. Functionalities of this layer is usually deployed in the same environment together with NFs.
- Processing layer is the moddile and core processing layer of cloud native OAM. It will processing the data collected by Agent layer, the processing operation includes but not limited to data storage, data processing, policy checking, etc. This layer will also transfer data and instructions among Agent layer and Data sharing layer. Functionalities in this layer can be deployed together with Agent layer as well as in different container environment.
- Data sharing layer is a group of northbound interfaces, which provide O&M data subscription and NF management interfaces. The management systems like OSS or 3rd party management systems could manage the NF and get datas through these interfaces.
Relationship clarification
Cloud native OAM module planned to be designed as a Telco PaaS capability. Newly developed code and existing software integration will both exist.
Potential software integration will include Prometheus as performance metrics management backend, EFK as log management backend, Kafka as message queue, MySQL as NF data storage backend. XGVela TMaaS will also be integrated to provide NF topology.
Image Modified
Documentation & TrainingRelease Planning & Release Notes
Code delivery project.
Functional featuresContents to be delivered
:in Release 12.2023
Cloud native OAM Design Doc update: the current layered functional architecture figure for cloud native oam is independent from xgvela architecture. Functional type (Telco PaaS, General PaaS, Adaptation layer) and its relationship with xgvela should be reflected.Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-35
Complete a doc for cloud native oam southbound interface: interfaces or interaction methods between cloud native oam and sounthbound NFs should be defined.Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-36
---------------------------------------------------------------------------------------
Functional features to be delivered in Release 11.2022:
Topology management (Mavenir code): A function that providesJira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-34
- NF register (new): A function that supports NF to register to cloud native OAM after being successfully deployed. As functions of cloud native OAM are PaaS capabilities, which can be deployed independently with NFs, this function provides a method for NF to register itself to cloud native OAM. This function will collect and store NF data including NF ID, NF name, NF service IP and port, etc., and will also provide a northbound API to inform management systems about new NF onborading.
- NF management trigger (new + existing TMaaS integration): A function that allows management systems to manage NF after registering to cloud native OAM. For each telco operator or third-party customers, there would exist a central management system for their entire network system, which could be OSS or virtical industry management system. This function will support those management systems to establish unified connection with NF, get NF lists, get NF data, and manage NF configurations. In this function,
the topology of NF, NF microservices and related deployment
would also be provided to management systems.NF heartbeat management (new): A function that monitors the heartbeat and manages the status of NF. This function will collect NF heartbeat, check the NF running status according to heartbeat based on pre-defined policies given by management systems, and generate alert if heartbeat is wrong..
NF configuration management (new): A function that manages that configuration of NFs. It supports getting configuration files, version management of configuration, configuration file storage, and configuring NFs. The northbound API provided supports northbound management ystems to get historical configuration list, get in-use configuration of target NF, and make configuration update.Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-14
existing
NF performance management (Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-23 Prometheus integration): A function that manages the performace data of NFs. It supports collecting performance data from NFs, provide data subscription functionality through northbound API. As promrtheus is commonly used for perfomance metrics data management, it will be integrated to implement this function.
NF alarm management (new): A function that collects and store alarm of NFs, and report them to management systems. This function will also processing the alarm data by alarm data supplement, duplicate alarm remove, etc.Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-27
existing
NF log management (Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-31 EFK integration): A function that collects and store logs of NFs. EFK integratoin prefered.
Development Language:
Other supporting functions and tasks are:
Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-12 Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-21 Jira server LFNetworking Jira serverId 3c1fbbb1-22c4-3d7c-9507-06bfb67a1be2 key XGVELA-22
NOTE:Green blocks in Figure 1 are OAM functions plans to be delivered in Release 11.2022. Pink blocks are necessary for other OAM functions to operate propoerly but whose source code will not be open sources. Gray blocks are within OAM scope which will be delivered in future release.
Link to features in Project candidate list: No 10, 11, 12, 13
Development Language: Go, Java
Test plan:
Unit test to check the function and API of listed featuresJira | ||||||
---|---|---|---|---|---|---|
|
Documents to be delivered:
User guide, installing guide, test cases, design doc of functions and interfacesJira | ||||||
---|---|---|---|---|---|---|
|
Planned milestones:
Action | Planned time |
---|---|
Project proposal and detailed plans | June / July |
Functional & Interface Design | June / July |
Development plan and start coding | July/August |
Code delivery | Late September/ early October |
Test | Middle October |
Document delivery | Late October/ Early November |
Project Facts
Project Creation Date: 2022-05-31
Project status: Approved. 2022-07-12 TSC Minutes
Primary Contact: zhaoqihui@chinamobile.com
Project Lead: Qihui Zhao
(Temparary)Committers:
- chenpengxiang@chinamobile.com
- Xinzhouhe@163wuzhe02@inspur.com
- zhao_oa@126zhaoqihui@chinamobile.com
- To be addedhe.xz@inspur.com
Mailing List:
xgvela-tsc@lists.xgvela.org
Meetings:
Plan to have meeting every two weeks. Specific weekday hasn't been set yet.Irregular meeting based on working progress. Please check with PTL for every week's meeting arrangement.
Repository:
Github Repo:
Jenkins:
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Repository:
Jenkins:Open Bugs:
Project Working Documents
Children Display |
---|
Task Report
Task report | ||
---|---|---|
|
Project Files
Attachments | ||
---|---|---|
|