Internet-Draft IBN Network Management Automation October 2022
Jeong, et al. Expires 27 April 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-jeong-nmrg-ibn-network-management-automation-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Jeong, Ed.
Sungkyunkwan University
P. Lingga
Sungkyunkwan University
J. Kim
Sungkyunkwan University
Y. Kim
Soongsil University

Intent-Based Network Management Automation in 5G Core Networks

Abstract

This document describes Network Management Automation (NMA) of cellular network services in 5G core networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with closed-loop network control, network policy translation, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G core networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 April 2023.

▲

Table of Contents

1. Introduction

5G networks are evolutionary mobile networks over 4G networks in terms of high speed, wide bandwidth, high frequency bands, massive device connectivity, low energy consumption, and intelligence. Especially, the intelligence will be a key feature to understand the intents of users and automate network management fully. 5G networks are designed and implemented on the experience from 4G networks and new technologies which include Software-Defined Networking (SDN) [RFC7149] and Network Functions Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2] along with mmWave for low delivery delay, high data speed, and large network capacity [TS-23.501].

The support of network intelligence is one of the main goals of 5G core networks. The network intelligence can provide the 5G core networks with Network Management Automation (NMA) for a self-driving network that optimizes and adjusts itself by minimizing the interaction with humans (e.g., network administrators and users).

Intent-Based Networking (IBN) is a feasible approach that can provide the 5G core networks with the NMA services [RFC9315] [TS-28.312][TR-28.812]. The concept of IBN enables a closed-loop network control architecture that can adapt to the current status of a target network by collecting and analyzing monitoring data from Network Service Functions (NSFs). NSFs can be either Virtual Network Functions (VNFs) or Physical Network Functions (PNFs) in cloud and edge computing environments. In the 3rd Generation Partnership Project (3GPP), Network Data Analytics Function (NWDAF) is defined to collect and analyze monitoring data from multiple VNFs and PNFs in cellular networks [TS-23.288][TS-29.520].

For the intelligent NMA services, this document proposes an architectural framework that combines the IBN and NWDAF to the 5G core networks with Artificial Intelligence (AI) and Machine Learning (ML). The framework allows an intent from either a network operator or user to be translated into a high-level policy through a Natural Language Processing (NLP) technique such as Lumi [USENIX-ATC-Lumi]. The high-level policy is then translated into a low-level policy through a Policy Data Model Mapping and a Network Policy Translator (NPT) [I-D.yang-i2nsf-security-policy-translation]. This low-level policy is used to remotely configure a network policy into appropriate VNFs or PNFs in order to enforce the commanded intent in a target network (e.g., 5G core Networks). Also, it also collects and analyzes the monitoring data from VNFs and PNFs such that the policy can be verified and optimized to satisfy the requests for the intent.

Therefore, the NMA in this document deals with closed-loop network control, network policy translation, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. In addition, this framework can support the use cases of NMA in 5G core networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). Especially, this document shows a use case of IoT in 5G core networks such as the data collection and analysis of IoT devices.

2. Terminology

This document uses the terminology described in [RFC8329], [I-D.ietf-i2nsf-applicability], and [I-D.jeong-i2nsf-security-management-automation]. In addition, the following terms are defined below:

   +------------+
   |  IBN User  |
   +------------+
          ^
          | Consumer-Facing Interface
          v
+-------------------+     Registration     +-----------------------+
|   IBN Controller  |<-------------------->|  Vendor's Mgmt System |
+-------------------+      Interface       +-----------------------+
          ^      ^
          |      |
          |      |   Analytics Interface   +-----------------------+
          |      +------------------------>|  IBN Analyzer (NWDAF) |
          |                                +-----------------------+
          | NSF-Facing Interface              ^       ^       ^
          |                                   |       |       |
          |                                   |       |       |
          |    +------------------------------+       |       |
          |    |              +-----------------------+       |
          |    |              |   Monitoring Interface        |
          v    v              v                               v
   +---------------+  +---------------+        +---------------+
   |     NSF-1     |--|     NSF-2     |........|     NSF-n     |
   |(Policy Control|  | (Application  |        |  (IoT Device) |
   | Function, PCF)|  |  Function, AF)|        |               |
   +---------------+  +---------------+        +---------------+
Figure 1: Network Management Automation in IBN Framework for 5G Core Networks

3. Network Management Automation in IBN Framework for 5G Core Networks

This section describes an IBN framework for 5G core networks. Note that this IBN Framework is based on the Framework for Interface to Network Security Functions (I2NSF) [RFC8329][I-D.jeong-i2nsf-security-management-automation]. As shown in Figure 1, an IBN User can use network functions by delivering high-level network policies, which specify network requirements that the IBN User wants to enforce, to the IBN Controller via the Consumer-Facing Interface (CFI).

3.1. Components with IBN Framework for Network Management Automation

The following are the system components for the IBN framework for network management automation in 5G core networks.

  • IBN User: An entity that delivers a high-level network policy to Security Controller. It is assumed that an intent in a natural language (e.g., English) can be translated into a high-level network policy through a Natural Language Processing (called NLP) technique (e.g., Lumi [USENIX-ATC-Lumi]).
  • IBN Controller: An entity that controls and manages other system components in the IBN framework. It translates a high-level network policy into the corresponding low-level network policy and selects appropriate NSFs to execute the network rules of the low-level network policy.
  • Vendor's Management System (VMS): An entity that provides an image of of a virtualized NSF for a network service to the IBN framework, and registers the capability and access information of an NSF with IBN Controller.
  • Network Service Function (NSF): An entity that is a Virtual Network Function (called VNF), Physical Network Function (called PNF) and Container Network Function (CNF), which is also called Cloud-native Network Function, for a specific network service such as the data aggregation of IoT devices, network slicing, and the QoS provisioning in V2X communications.
  • IBN Analyzer: An entity that collects monitoring data from NSFs and analyzes such data for checking the activity and performance of the NSFs using machine learning techniques (e.g., Deep Learning [Deep-Learning]). IBN Analyzer can be a Network Data Analytics Function (NWDAF) in 5G networks [TS-23.288][TS-29.520]. If there is a suspicious network problem (e.g., traffic congestion and QoS degradation) for the target network or NSF, IBN Analyzer delivers a report of the augmentation or generation of network rules to IBN Controller.

For IBN-based network services with Feedback-Based Network Management (FNM), IBN Analyzer is a key IBN component for the IBN framework [RFC9315] to collect monitoring data from NSFs and analyzing the monitoring data. The actual implementation of the analysis of monitoring data is out of the scope of this document.

3.2. Interfaces for the IBN Framework

The following are the interfaces for the IBN framework. Note that the interfaces can be modeled with YANG [RFC6020] and network policies are delivered through either RESTCONF [RFC8040] or NETCONF [RFC6241]. In addition, according to 3GPP specifications, REST API [REST] can be supported for those interfaces.

  • Consumer-Facing Interface: An interface between IBN User and IBN Controller for the delivery of a high-level network policy [I-D.ietf-i2nsf-consumer-facing-interface-dm].
  • NSF-Facing Interface: An interface between IBN Controller and an NSF for the delivery of a low-level network policy [I-D.ietf-i2nsf-nsf-facing-interface-dm].
  • Registration Interface: An interface between a VMS and IBN Controller for the registration of an NSF's capability and access information with the IBN Controller or the query of an NSF for a required low-level network policy [I-D.ietf-i2nsf-registration-interface-dm].
  • Monitoring Interface: An interface between an NSF and IBN Analyzer for collecting monitoring data from an NSF to check the activity and performance of an NSF for a possible network problem [I-D.ietf-i2nsf-nsf-monitoring-data-model].
  • Analytics Interface: An interface between IBN Analyzer and IBN Controller for the delivery of an analytics report of the augmentation or generation of network rules to IBN Controller, which lets IBN Controller apply the report for network rules to its network policy management.

For IBN-based network services with FSM, Analytics Interface is a key interface in the IBN framework to deliver an analytics report of the augmentation or generation of network rules to IBN Controller through the analysis of the monitoring data from NSFs.

4. Network Policy Translation

To facilitate Network Policy Translation (NPT), IBN Controller needs to have a network policy translator that performs the translation of a high-level network policy into the corresponding low-level network policy. For the automatic NPT services, the IBN framework needs to bridge a high-level YANG data model and a low-level YANG data model in an automatic manner [I-D.yang-i2nsf-security-policy-translation]. Note that a high-level YANG data model is for the IBN Consumer-Facing Interface, and a low-level YANG data model is for the IBN NSF-Facing Interface.

Figure 2 shows automatic mapping of high-level and low-level data models for network policies. Automatic Data Model Mapper takes a high-level YANG data module for the Consumer-Facing Inteface and a low-level YANG data module for the NSF-Facing Interface. It then constructs a mapping table associating the data attributes (or variables) of the high-level YANG data module with the corresponding data attributes (or variables) of the low-level YANG data module. Also, it generates a set of production rules of the grammar for the construction of an XML file of low-level network policy rules.

Figure 3 shows the procedure of high-to-low network policy translation. A network policy translator is a component of IBN Controller. The translator consists of three components such as Policy Data Model Mapper, Policy Data Extractor, Policy Data Converter, and Policy Generator.


       High-level YANG Data Module   Low-level YANG Data Model
                   |                              |
                   V                              V
         +---------+------------------------------+---------+
         |             Policy Data Model Mapper             |
         +------------------------+-------------------------+
                                  |
               Mapping Model (Data Model Mapping Table)
                                  |
                                  V
         +--------------------------------------------------+
         |                  NSF Database                    |
         +--------------------------------------------------+
Figure 2: Automatic Mapping of High-level and Low-level Data Models 
  +-------------------------------------------------+
  |                                                 |
  |                     IBN User                    |
  |                                                 |
  +------------------------+------------------------+
                           | Consumer-Facing Interface
                           |
               High-level Network Policy
                           |
       IBN Controller      V
+--------------------------+-----------------------------------------------+
|         Network Policy   |                                               |
|         Translator       V                                               |
|  +-----------------------+--------------------------------------------+  |
|  |                       |                                            |  |
|  |                       V                                            |  |
|  |       +---------------+-------+      +--------------------------+  |  |
|  |       | Policy Data Extractor |      | Policy Data Model Mapper |  |  |
|  |       +---------------+-------+      +--------+-----------------+  |  |
|  |                       |                       | Mapping            |  |
|  |                       V                       V Model              |  |
|  |       +---------------+-------+      +--------------------+        |  |
|  |       | Policy Data Converter |<---->|    NSF Database    |        |  |
|  |       +---------------+-------+      +--------------------+        |  |
|  |                       |                                            |  |
|  |                       V                                            |  |
|  |       +---------------+-------+                                    |  |
|  |       |    Policy Generator   |                                    |  |
|  |       +---------------+-------+                                    |  |
|  |                       |                                            |  |
|  |                       V                                            |  |
|  +-----------------------+--------------------------------------------+  |
|                          |                                               |
|                          V                                               |
+--------------------------+-----------------------------------------------+
                           |  NSF-Facing Interface
                           |
                Low-level Network Policy
                           |
                           V
  +------------------------+-------------------------+
  |                                                  |
  |                      NSF(s)                      |
  |                                                  |
  +--------------------------------------------------+
Figure 3: High-to-Low Network Policy Translation

Policy Data Model Mapper maps the attributes and their values of a high-level network policy to the corresponding attributes and their values of a low-level network policy. Note that the values of a high-level network policy may involve a human language and must be converted to an appropriate value for a low-level network policy (e.g., employees -> 192.0.1.0/24).

Policy Data Extractor extracts the values of the attributes related to a network policy from a high-level network policy that was delivered by an IBN User to an IBN Controller through the Consumer-Facing Interface [I-D.ietf-i2nsf-consumer-facing-interface-dm].

Policy Data Converter converts the values of the high-level policy's attributes into the values of the corresponding low-level policy's attributes to generate the low-level network policy [I-D.ietf-i2nsf-nsf-facing-interface-dm].

Policy Generator generates the corresponding low-level network policy that is delivered by the IBN Controller to an appropriate NSF through NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm].

5. Network Audit System

The IBN framework is weak to both an insider attack and a supply chain attack since it trusts in NSFs provided by VMS and assumes that NSFs work for their network services appropriately [I-D.ietf-i2nsf-applicability].

To detect the malicious activity of either an insider attack by a malicious VMS or a supply chain attack by a compromised VMS, a network audit system is required by the IBN framework. This network audit system can facilitate the non-repudiation of configuration commands and monitoring data generated in the IBN framework.

A network audit system has the following four main objectives:

+-----------------------------+                   +----------------+
|           IBN User          |                   |  Vendor's Mgmt |
|                             +------------+      |     System     |
+--------------+--------------+            |      +--------+-------+
               | Consumer-Facing Interface |               |
               |                           |  Remote       |
   High-level Security Policy              |  Attestation  |
               |                           |  Interface    |
               |                           |               |
               V                           |               V
+--------------+--------------+            |     +---------+--------+
|                             |            V     |      Network     |
|        IBN Controller       +------------+---->|       Audit      |
|                             |            ^     |      System      |
+--------------+--------------+            |     +---------+--------+
               |  NSF-Facing Interface     |               ^
               |                           |  Remote       |
   Low-level Security Policy               |  Attestation  |
               |                           |  Interface    |
               V                           |               |
+--------------+--------------+            |      +--------+-------+
|            NSF(s)           +------------+      |  IBN Analyzer  |
|                             +------------------>|                |
+-----------------------------+    Monitoring     +----------------+
                                   Interface
Figure 4: Activity Auditing with Network Audit System

Figure 4 shows activity auditing with a network audit system in the IBN framework. All the components in the IBN framwork report its activities (such as configuration commands and monitoring data) to Network Audit System as transactions through Remote Attestation Interface [I-D.yang-i2nsf-remote-attestation-interface-dm]. The network audit system can analyze the reported activities from the IBN components to detect malicious activities such as an insider attack and a supply chain attack. Note that such a network audit system can be implemented by remote attestation [I-D.ietf-rats-architecture][I-D.yang-i2nsf-remote-attestation-interface-dm] or Blockchain [Bitcoin]. The details of the implementation of the network audit system are out of the scope of this document.

In order to determine a minimum set of controls required to reduce the risks from either an insider attack or a supply chain attack, the network audit system should analyze the activities of all the components in the IBN framework periodically, evaluate possible risks, and take an action to such risks since vulnerabilities and threats may change in different environments over time.

6. A Use Case of IoT Device Data Aggregation

This section describes a use case where a policy of IoT device data aggregation is set up in the IBN framework for 5G core networks.

Figure 5 shows the procedure of the enforcement for an IoT device data aggregation policy in the IBN Framework as follows:

  1. IBN User sends a High-level Policy Request to IBN Controller.
  2. IBN Controller translates the request with its Network Policy Translator (called NPT). The NPT identifies NSFs (i.e., IoT Devices) for the request after the steps of Policy Data Extraction and Policy Data Conversion.
  3. If the NSFs are available for the requested network policy, go to the step of Policy Generation in NPT. If the NSFs are unavailable for the requested network policy, go to the next step.
  4. IBN Controller sends an NSF Query Request to Vendor's Management System (called VMS) to find an appropriate NSF for the request network policy.
  5. If there is such an NSF registered with VMS, VMS sends an NSF Initializtion Request to Cloud (or Edge Server) to initialize the NSF.
  6. Cloud (or Edge Server) forwards the NSF Initializtion Request to the appropriate NSF to let it initialize itself.
  7. The NSF performs an initialization to perform a task for a network policy in 5G networks.
  8. The NSF sends an NSF Initialization Response to Cloud (or Edge Server) to tell Cloud (or Edge Server) its readiness to perform a task.
  9. Cloud (or Edge Server) forwards the NSF Initialization Response to VMS to tell an NSF's readiness to perform a task.
  10. VMS sends an NSF Query Response to IBN Controller to tell an NSF's readiness to perform a task along with the network access information for the NSF.
  11. IBN Controller performs the step of Policy Generation in its NPT along with the network access information of an appropriate NSF(s).
  12. IBN Controller sends a Low-level Policy Request to the appropriate NSF.
  13. The NSF performs the configration in the given Low-level Policy Request to perform the requested task (e.g., sensing and reporting).
  14. The NSF sends a Low-level Policy Response to IBN Controller to tell its readiness to perform the requested task. 
IBN             IBN             Vendor's           Cloud              NSF1
User         Controller       Mgmt System    (or Edge Server)    (IoT Device)
 |               |                 |                 |                 |
 |-High-level--->|                 |                 |                 |
 | Policy Request|                 |                 |                 |
 |               |                 |                 |                 |
 |          Translation:           |                 |                 |
 |        Data Extraction &        |                 |                 |
 |        Data Conversion          |                 |                 |
 |               |                 |                 |                 |
 |*** Case 1: NSFs available: Go to Policy Generation ***              |
 |               |                 |                 |                 |
 |*** Case 2: NSFs unavailable (START) ***           |                 |
 |               |                 |                 |                 |
 |               |-NSF Query------>|                 |                 |
 |               | Request         |-NSF Initiation->|                 |
 |               |                 | Request         |                 |
 |               |                 |                 |-NSF Initiation->|
 |               |                 |                 | Request         |
 |               |                 |                 |                 |
 |               |                 |                 |                NSF
 |               |                 |                 |         Initialization
 |               |                 |                 |                 |
 |               |                 |                 |<-NSF Initiation-|
 |               |                 |<-NSF Initiation-|  Response       |
 |               |<-NSF Query------|  Response       |                 |
 |               |  Response       |                 |                 |
 |               |                 |                 |                 |
 |*** Case 2: NSFs unavailable (END) ***             |                 |
 |               |                 |                 |                 |
 |          Translation:           |                 |                 |
 |       Policy Generation         |                 |                 |
 |               |                 |                 |                 |
 |               |--Low-level Policy Request-------------------------->|
 |               |                 |                 |                 |
 |               |                 |                 |                NSF
 |               |                 |                 |          Configuration
 |               |                 |                 |                 |
 |               |<-Low-level Policy Response--------------------------|
 |               |                 |                 |                 |
Figure 5: Procedure of an IoT Device Data Aggregation Policy Enforcement in the IBN Framework

Figure 6 shows the procedure of the reporting for IoT device data aggregation in the IBN Framework as follows:

  1. NSF1 (as an IoT Device) sends its Sensing Data to IBN Analyzer (as an NWDAF).
  2. NSF2 (as an IoT Device) sends its Sensing Data to IBN Analyzer (as an NWDAF).
  3. IBN Analyzer performs Sensing Data Aggregation and analyzes the aggregated sensing data through Machine Learning (ML) techniques. It then generates a Sensing Report for IBN Controller.
  4. IBN Analyzer sends a Sensing Report to IBN Controller.
  5. IBN Controller analyzes the Sensing Report for a further action. If a further action is needed, it updates the existing network policy or generates a new network policy.
  6. IBN Controller sends the report for the further action to IBN User optionally if the reporting is needed.
  7. For the further action, IBN Controller sends an Updated NSF Policy Request or a New NSF Policy Request to the appropriate NSF(s).
  8. The appropriate NSF(s) reconfigures the Updated NSF Policy or configures the new NSF Policy in its own system.
  9. The appropriate NSF(s) sends an Updated NSF Policy Response or a NEW NSF Policy Response to IBN Controller. 
IBN             IBN               IBN               NSF1              NSF2
User         Controller         Analyzer       (IoT Device)      (IoT Device)
 |               |                 |                 |                 |
 |               |                 |<----Sensing-----|                 |
 |               |                 |     Data        |                 |
 |               |                 |                 |                 |
 |               |                 |<----Sending-----------------------|
 |               |                 |     Data        |                 |
 |               |                 |                 |                 |
 |               |              Sensing              |                 |
 |               |               Data                |                 |
 |               |            Aggregation            |                 |
 |               |                 |                 |                 |
 |               |<---Sensing------|                 |                 |
 |               |    Report       |                 |                 |
 |               |                 |                 |                 |
 |             Policy              |                 |                 |
 |             Update              |                 |                 |
 |        (or Generation)          |                 |                 |
 |               |                 |                 |                 |
 |<---Report-----|                 |                 |                 |
 |               |--Updated/New Low-level Policy Request-------------->|
 |               |                 |                 |                 |
 |               |                 |                 |                NSF
 |               |                 |                 |      (Re)Configuration
 |               |                 |                 |                 |
 |               |<-Updated/New Low-level Policy Response--------------|
 |               |                 |                 |                 |
Figure 6: Procedure of IoT Device Data Aggregation Reporting in the IBN Framework

7. IANA Considerations

This document does not require any IANA actions.

8. Security Considerations

The same security considerations for the IBN framework [RFC8329] are applicable to this document.

The development and introduction of IBN Analyzer and Network Audit System in the IBN Framework may create new security concerns that have to be anticipated at the design and specification time. The usage of machine learning to analyze monitoring data of malicious NSFs may add a risk to its model to be attacked (e.g., adversarial attack) and can result in a bad security policy that is deployed into the IBN system.

9. References

9.1. Normative References

[RFC6020]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8329]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, , <https://www.rfc-editor.org/info/rfc8329>.
[RFC9315]
Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, , <https://www.rfc-editor.org/info/rfc9315>.

9.2. Informative References

[I-D.ietf-i2nsf-consumer-facing-interface-dm]
Jeong, J. P., Chung, C., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-consumer-facing-interface-dm-23, , <https://www.ietf.org/archive/id/draft-ietf-i2nsf-consumer-facing-interface-dm-23.txt>.
[I-D.ietf-i2nsf-nsf-facing-interface-dm]
Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-nsf-facing-interface-dm-29, , <https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt>.
[I-D.ietf-i2nsf-registration-interface-dm]
Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model for NSF Capability Registration", Work in Progress, Internet-Draft, draft-ietf-i2nsf-registration-interface-dm-21, , <https://www.ietf.org/archive/id/draft-ietf-i2nsf-registration-interface-dm-21.txt>.
[I-D.ietf-i2nsf-nsf-monitoring-data-model]
Jeong, J. P., Lingga, P., Hares, S., Xia, L. F., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-nsf-monitoring-data-model-20, , <https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt>.
[I-D.ietf-i2nsf-applicability]
Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and R. Diego Lopez, "Applicability of Interfaces to Network Security Functions to Network-Based Security Services", Work in Progress, Internet-Draft, draft-ietf-i2nsf-applicability-18, , <https://www.ietf.org/archive/id/draft-ietf-i2nsf-applicability-18.txt>.
[I-D.jeong-i2nsf-security-management-automation]
Jeong, J. P., Lingga, P., Park, J., Diego Lopez, R., and S. Hares, "Security Management Automation of Cloud-Based Security Services in I2NSF Framework", Work in Progress, Internet-Draft, draft-jeong-i2nsf-security-management-automation-04, , <https://www.ietf.org/archive/id/draft-jeong-i2nsf-security-management-automation-04.txt>.
[I-D.yang-i2nsf-security-policy-translation]
Jeong, J. P., Lingga, P., Yang, J., and J. Kim, "Guidelines for Security Policy Translation in Interface to Network Security Functions", Work in Progress, Internet-Draft, draft-yang-i2nsf-security-policy-translation-12, , <https://datatracker.ietf.org/api/v1/doc/document/draft-yang-i2nsf-security-policy-translation/>.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture-22, , <https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.txt>.
[I-D.yang-i2nsf-remote-attestation-interface-dm]
Yang, P., Chen, M., Su, L., Lopiz, D., Jeong, J. P., and L. Dunbar, "I2NSF Remote Attestation Interface YANG Data Model", Work in Progress, Internet-Draft, draft-yang-i2nsf-remote-attestation-interface-dm-01, , <https://www.ietf.org/archive/id/draft-yang-i2nsf-remote-attestation-interface-dm-01.txt>.
[TS-23.501]
"System Architecture for the 5G System (5GS)", Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144, .
[TS-28.312]
"Intent Driven Management Services for Mobile Networks", Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3554, .
[TR-28.812]
"Study on Scenarios for Intent Driven Management Services for Mobile Networks", Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3553, .
[TS-23.288]
"Architecture Enhancements for 5G System (5GS) to Support Network Data Analytics Services", Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3579, .
[TS-29.520]
"Network Data Analytics Services", Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3355, .
[RFC7149]
Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, , <https://www.rfc-editor.org/rfc/rfc7149>.
[ETSI-NFV]
"Network Functions Virtualisation (NFV); Architectural Framework", Available: https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf, .
[ETSI-NFV-Release-2]
"Network Functions Virtualisation (NFV) Release 2; Management and Orchestration; Architectural Framework Specification", Available: https://www.etsi.org/deliver/etsi_gs/nfv/001_099/006/02.01.01_60/gs_nfv006v020101p.pdf, .
[Bitcoin]
Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", Available: https://bitcoin.org/bitcoin.pdf, .
[USENIX-ATC-Lumi]
Jacobs, A., Pfitscher, R., Ribeiro, R., Ferreira, R., Granville, L., Willinger, W., and S. Rao, "Hey, Lumi! Using Natural Language for Intent-Based Network Management", USENIX Annual Technical Conference, Available: https://www.usenix.org/conference/atc21/presentation/jacobs, .
[REST]
Fielding, R. and R. Taylor, "Principled Design of the Modern Web Architecture", ACM Transactions on Internet Technology, Vol. 2, Issue 2,, Available: https://dl.acm.org/doi/10.1145/514183.514185, .
[Deep-Learning]
Goodfellow, I., Bengio, Y., and A. Courville, "Deep Learning", Publisher: The MIT Press, URL: https://www.deeplearningbook.org/, .

Appendix A. Acknowledgments

This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT)(No. 2022-0-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).

This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. 2022-0-01199, Regional strategic industry convergence security core talent training business).

Appendix B. Contributors

This document is made by the group effort of NMRG. Many people actively contributed to this document, such as Linda Dunbar, Yoav Nir, Susan Hares, and Qin Wu. The authors sincerely appreciate their contributions.

The following are co-authors of this document:

Jiyong Uhm - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-Ro Jangan-Gu, Suwon, Gyeonggi-do 16419, Republic of Korea. EMail: jiyong423@skku.edu

Jung-Soo Park - Electronics and Telecommunications Research Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of Korea. EMail: pjs@etri.re.kr

Yunchul Choi - Electronics and Telecommunications Research Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of Korea. EMail: cyc79@etri.re.kr

Authors' Addresses

Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Patrick Lingga
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Jeonghyeon Kim
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Younghan Kim
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
06978
Republic of Korea
Phone: +82 10 2691 0904