Internet-Draft I2INF Problem Statement July 2024
Jeong, et al. Expires 23 January 2025 [Page]
Workgroup:
Operations and Management Area Working Group
Internet-Draft:
draft-jeong-opsawg-i2inf-problem-statement-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Jeong, Ed.
Sungkyunkwan University
Y. Shen
Sungkyunkwan University
Y. Ahn
Sungkyunkwan University
Y. Kim
Soongsil University
E. Duarte Jr.
Federal University of Parana

Interface to In-Network Functions (I2INF): Problem Statement

Abstract

This document specifies the problem statement for Interface to In-Network Functions (I2INF) for a user's services involved in both networks and applications. In-Network Functions (INF) include In-Network Computing Functions (INCF) in Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). They also include In-Network Application Functions (INAF) in Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to realize the user's services consisting of a combination of INFs in a target network. This document analyzes the gap for an IBN-based system to perform the user's service and specifies the requirements for the I2INF for intelligent service provisioning.

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 23 January 2025.

▲

Table of Contents

1. Introduction

Network softwarization is widely used for network services in network infrastructure (e.g., 5G mobile networks [TS-23.501]), clouding computing, and edge computing. This network softwarization is enabled by the technologies of Network Functions Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2] and Software-Defined Networking (SDN) [RFC7149]. In addition, Intent-Based Networking (IBN) [RFC9315][Survey-IBN-CST-2023] has been intensively researched and realized for the last five yearly. Many end-user devices such as smartphones and smart watches are connected to various Internet-of-Things (IoT) devices for customer-tailored services. Recently Software-Defined Vehicles (SDVs) [AUTOSAR-SDV][Eclipse-SDV][COVESA] have been spotlighted as the next-generation user devices after the smartphones. SDVs are intended to use the network softwarization technologies such as NFV and SDN. System components and applications in the SDVs are working in the form of containers in a cloud native environment (e.g., Kubernetes [Kubernetes]).

In this trend, the network automation and management has become more important to realize intelligent services for both end users and network operators [I-D.jeong-nmrg-ibn-network-management-automation]. For this network automation and management, an intent of a user (e.g., end user and network operator) in the form of either text or voice needs to be understood and processed by the service systems. Note that an intent is a declarative request for a specific goal rather than an imperative request having a series of configuration or commands for specific operations. This intent needs to be translated into a network policy and an application policy for the satisfaction of the user's service request. First, the network policy contains rules to execute the service's network demands in terms of Quality of Service (QoS) such as throughput and delay. Second, the application policy contains rules to execute the service's application demands in terms of functionality and timing. These translated network and application polices need to be delivered to appropriate Network Functions (NF) in network infrastructure, edge computing, and cloud computing. Thus, an intent of a user's service needs to be translated into both a network policy for a network infrastructure for a network service and an application policy for a client and a server for an application service.

For example, services for user applications (e.g., video conference) need to be accurately configured to and efficiently processed by not only Application Functions (AF) like a client (e.g., a video conference client) and a server (e.g., a video conference server), but also Network Functions (NF) (e.g., video broadcast coordinator) in Computing in the Network (COIN) [I-D.irtf-coinrg-use-cases][NFV-COIN].

As per definitions of Computing in the Network (COIN), a Programmable Network Device (PND) in an In-Network Computing (INC) environment can have multiple kinds of capabilities (i.e., features) [I-D.irtf-coinrg-coin-terminology] to work with other PNDs. PNDs from different product lines or vendors can have different capabilities for INC functions. When working togther for a COIN system, the PDNs may be unaware of capabilities of others. Therefore, it is necessary to define a standard interface for PNDs to exchange their capabilities.

For the configuration and monitoring of Application Functions (AFs) for applications and Network Functions (NFs) for network services for a given user's service, a standard framework with interfaces is required. There is no standard data model to describe the capabilities of AFs and NFs for a user-demanded service. Also, there is no standard data model for a registration interface that is used to register the capabilities of those AFs and NFs with a controller for the requested service. In addition, there are no standard interfaces to configure and monitor those AFs and NFs according to a user's intent. In the past, Interface to Network Security Functions (I2NSF) was standardized for the control and management of Network Security Services with Network Security Functions (NSFs) [RFC8329] [I-D.ietf-i2nsf-applicability]. This document takes advantage of the work of I2NSF for a more general control and management framework for intelligent services consisting of AFs and NFs.

This document specifies the problem statement and use cases for Interface to In-Network Functions (I2INF) for In-Network Functions (INFs) having different capabilities. The INFs consist of Network Functions (NFs) including PNDs and Application Functions (AFs) in order to compose a user's services. First of all, INFs include In-Network Computing Functions (INCF) as NFs within NFV and SDN [I-D.irtf-coinrg-use-cases]. Secondly, they also include In-Network Application Functions (INAF) as AFs within Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Finally, Intent-Based Networking (IBN) can be realized with the network services consisting of a combination of INFs in a target network.

2. Terminology

This document uses the terminology described in [RFC9315], [RFC8329], [I-D.irtf-coinrg-coin-terminology], [I-D.irtf-coinrg-use-cases], [I-D.jeong-i2nsf-security-management-automation], [I-D.jeong-nmrg-ibn-network-management-automation], and [I-D.yang-i2nsf-security-policy-translation]. In addition, the following terms are defined below:

3. Problem Statement for Interface to In-Network Functions

This section specifies the Gap Analysis, Intent-Based Networking (IBN), and Problem Statement for Interface to In-Network Functions (I2INF). First, Figure 1 shows Wireless and Wired Networks in a Central Cloud for the I2INF framework having network entities and Mobile Objects (MO) to run network functions and application functions for a user's service, respectively. Second, Figure 2 shows a VNF-Consensus Architecture in an Edge Cloud in the I2INF framework to synchonize the SDN Controllers for flow table information in the same Edge Cloud [NFV-COIN]. These networks are assumed for the problem space for the I2INF.

                                  Central Cloud
                   *******************************************
                 *                                             *
                *              +------------------+             *
               *               | Cloud Controller |              *
               *               +------------------+              *
               *                         ^                       *
                *                        |                      *
                 *                       v                     *
                   *******************************************
                    ^                   ^                    ^
                    |                   |                    |
                    V                   V                    V
              +-----------+       +-----------+        +-----------+
              |Edge-Cloud1|       |Edge-Cloud2|        |Edge-Cloud3|
              +-----------+       +-----------+        +-----------+
                    ^                   ^                    ^
                    |                   |                    |
                    V                   V                    V
               +---------+         +---------+         +---------+
               | IP-RSU1 |<------->| IP-RSU2 |<------->| IP-RSU3 |
               +---------+         +---------+         +---------+
                    ^                   ^                    ^
                    :                   :                    :
           +-----------------+ +-----------------+   +-----------------+
           |        : V2I    | |        : V2I    |   |       : V2I     |
           |        v        | |        v        |   |       v         |
+--------+ |   +--------+    | |   +--------+    |   |   +--------+    |
|   MO1  |===> |   MO2  |===>| |   |   MO3  |===>|   |   |   MO4  |===>|
+--------+<...>+--------+<........>+--------+    |   |   +--------+    |
           V2V     ^         V2V        ^        |   |        ^        |
           |       : V2V     | |        : V2V    |   |        : V2V    |
           |       v         | |        v        |   |        v        |
           |  +--------+     | |   +--------+    |   |    +--------+   |
           |  |   MO5  |===> | |   |   MO6  |===>|   |    |   MO7  |==>|
           |  +--------+     | |   +--------+    |   |    +--------+   |
           +-----------------+ +-----------------+   +-----------------+
                 Subnet1              Subnet2              Subnet3
                (Prefix1)            (Prefix2)            (Prefix3)

        <----> Wired Link   <....> Wireless Link   ===> Moving Direction
Figure 1: Wireless and Wired Networks in Central Cloud for I2INF Framework 
                        Edge Cloud                      Central Cloud
        ******************************************        **********
       *                                          *     *            *
      *                                            *   * +----------+ *
      *  +---------------+   +-----------------+   *   * |  Cloud   | *
      *  | VNF-Consensus |<->| Edge Controller |<->*<->* |Controller| *
      *  +-------^-------+   +--------^--------+   *   * +----------+ *
      *          |                    |            *   *              *
       *         v                    V           *     *            *
        ******************************************        **********
        ^                    ^                    ^
        |                    |                    |
        V                    V                    V
+---------------+    +---------------+    +---------------+
|SDN-Controller1|    |SDN-Controller2|    |SDN-Controller3|
+---------------+    +---------------+    +---------------+
        ^                    ^                    ^
        |                    |                    |
        V                    V                    V
+---------------+    +---------------+    +---------------+
|   +-----+     |    |   +-----+     |    |   +-----+     |
|   | SW1 |     |    |   | SW3 |     |    |   | SW5 |     |
|   +---^-+     |    |   +---^-+     |    |   +---^-+     |
|       |       |    |       |       |    |       |       |
|     +-V---+   |    |     +-V---+   |    |     +-V---+   |
|     | SW2 |   |    |     | SW4 |   |    |     | SW6 |   |
|     +-----+   |    |     +-----+   |    |     +-----+   |
+---------------+    +---------------+    +---------------+
   SDN-Network1         SDN-Network2         SDN-Network3
     (Subnet1)            (Prefix2)            (Prefix3)

<----> Wired Link
Figure 2: VNF-Consensus Architecture in Edge Cloud for I2INF Framework

3.1. Gap Analysis

In-Network Computing Functions (INCF) are proposed for various computing services in the area of COIN on top of network softwarization environments of NFV and SDN [I-D.irtf-coinrg-use-cases][NFV-COIN].

The COIN Use Cases Document in [I-D.irtf-coinrg-use-cases] proposes four kinds of use cases for In-Network Computing. Its use cases are (i) Providing New COIN Experiences, (ii) Supporting New COIN Systems, (iii) Improving Existing COIN Capabilities, and (iv) Enabling New COIN Capabilities.

  1. For Providing New COIN Experiences, the document describes mobile application offloading and Extended Reality (XR) and immersive media.

  2. For Supporting New COIN Systems, the document describes In-Network Control, Time-Sensitive Application, Large Volume Applications, and Industrial Safety.

  3. For Improving Existing COIN Capabilities, the document describes Content Delivery Networks (CDN), Compute-Fabric-as-a-Service (CFaaS), and Virtual Networks Programming (e.g., P4 programs and OpenFlow rules).

  4. For Enabling New COIN Capabilities, the document describes Distributed AI Training among distributed endpoints for large-scale problems.

The NFV-COIN Paper in [NFV-COIN] proposes three kinds of use cases for In-Network Computing. Its use cases are (i) NFV Failure Detection, (ii) Virtual Network Function (VNF) Consensus, and (iii) NFV Reliable Broadcast.

  1. NFV Failure Detection is that an NFV-based failure detector gets monitoring data from SDN Switches via SDN Controller and detects the failure of communication links. This failure detector can work within the SDN Controller by sacrificing the performance (e.g., CPU usage) of the SDN Controller.

  2. VNF Consensus is that a VNF-Consensus service performs the sychronization of the control planes of multiple SDN Controllers. This consensus service does not require any modification of both the data plane at SDN switches and SDN control plane (e.g., OpenFlow). Through the consensus service, if a new rule is configured by an SDN Controller, this rule is distributed to all the other SDN Controllers through the VNF-Consensus.

  3. NFV Reliable Broadcast is that an NFV-based broadcast (NFV-RBCast) performs reliable and in-order delivery of broadcasted data packets. This reliable and in-order broadcast for applications is provisioned by NFV-RBCast using a VNF-Sequencer. A flow using the NFV-RBCast service lets a forwarding rule be installed at SDN Switches through an SDN Controller. All the packets of the flow are forwarded to the VNF-Sequencer via the SDN Controller. The VNF-Sequencer inserts a sequence number into each of those forwarded packets, and sends them to the destination hosts running an RBCast application.

Functionalities of each service needs to be decomposed into AFs and NFs in edge computing. The generation and configuration of those AFs and NFs are needed by a service coordinator for COIN-based network services. However, a framework and interfaces are missing and not standardized for the life cycle management for the COIN-based network services.

3.2. Intent-Based Networking

According to the life cycle design of IBN [RFC9315], Figure 3 shows the life cycle of an Intent-Based System (IBS) for the intent management for network entities and MOs. It divides the life cycle into three spaces, namely MO User Space, Translation & IBS Space, and Network Operations (Ops) & Application (App) Space. Each space is further divided into two sections, fulfillment and assurance. The fulfillment section pipelines the steps (i.e., intent input, translation/refinement, learning/planning/rendering, and configuration/provisioning) toward the final SFs such as Network Functions (NFs) and Application Functions (AFs) in MOs. The assurance section monitors final results of the intent fulfillment to validate and analyze the resulted NFs and applications for MOs.

        IBS User     :            Translation/          : Network Ops/
          Space      :             IBS Space            :  App Space
Fulfill              :                                  :
       +----------+  :  +------------+   +------------+ : +-----------+
       |Recognize/|---->| Translate/ |-->|   Learn/   |-->| Configure/|
       | Generate |  :  |   Refine   |   |   Plan/    | : | Provision |
       | Intent   |<----|            |   |   Render   | : |           |
       +----------+  :  +------------+   +------------+ : +-----------+
            ^        :                         ^        :       |
............|..................................|................|.....
            |        :                    +----------+  :       v
            |        :                    | Validate |  :  +----------+
            |        :                    +----^-----+<----| Monitor/ |
Assure      |        :                         |        :  | Observe  |
        +--------+   :  +----------+      +----------+<----|          |
        | Report |<-----| Abstract |<-----| Analyze/ |  :  +----------+
        +--------+   :  +----------+      | Aggregate|  :
                     :                    +----------+  :
Figure 3: The Life Cycle of IBS for Intent Management

The life cycle in Figure 3 is so conceptual for the implementation of an IBS. It needs to be concretized in the form of a framework with interfaces among components in the framework. The data models of an intent, a network policy, and an application policy should be specified by either YANG [RFC6020][RFC7950] or YAML [YAML] to make messages that will be delivered to target components via a message delivery protocol, such as NETCONF [RFC6241], RESTCONF [RFC8040], and REST API [REST].

3.3. Problem Statemet

The goal of an Intent-Based System (IBS) is to enforce the service corresponding to a user's intent with an appropriate application in a target network in terms of functionality and quality [RFC9315][RFC8329] [I-D.jeong-i2nsf-security-management-automation] [I-D.jeong-nmrg-ibn-network-management-automation]. To achieve this goal, first of all, an intent needs to be translated into both a network policy and an application policy by an intent translator [I-D.jeong-nmrg-ibn-network-management-automation] [I-D.yang-i2nsf-security-policy-translation]. Then these network policy and application policy needs to delivered to a network controller and an application controller, respectively. The network controller further translates the network policy into the network rules to be sent to the network entities (i.e., NFs). In the same way, the application controller further translates the application policy into the application rules to be sent to the application entities (i.e., AFs).

For the translation of either an intent or a policy, the capabilities of NFs and AFs should be registered with databases (e.g., NF database and AF database). Thus, a capability data model for such NFs and AFs should be specified in advance [I-D.ietf-i2nsf-capability-data-model]. Also, a registration interface is required for a vendor for either an NF or an AF to register its NF or AF with the corresponding database such as the NF database and the AF database, respectively [I-D.ietf-i2nsf-registration-interface-dm]. Therefore, a data model for this registration interface should be specified to make a registration message for the Vendor's Management System (VMS) [RFC8329].

An IBS user needs an interface to deliver its intent to an IBS controller (e.g.., Cloud Controller in Figure 1) having an intent translator, which translates the intent into a network policy and an application policy, and a dispatcher, which dispatches the policies to appropriate destinations (e.g, NF controller and AF controller). This interface is called a Customer-Facing Interface (CFI) for the IBS user [I-D.ietf-i2nsf-consumer-facing-interface-dm]. A data model for the Customer-Facing Interface should be specified.

Both an NF controller and an AF controller need an interface to deliver the network rules and the application rules to the appropriate NFs and the appropriate AFs, respectively. This interface is called a Service Function-Facing Interface (SFI) for both the NF controller and the AF controller [I-D.ietf-i2nsf-nsf-facing-interface-dm].

For the assurance of the intent in the target network and application, the collection and analysis of monitoring data from the NFs and AFs is required. A Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] is an interface to collect monitoring data from either an NF or an AF to a data collector (e.g., IBS analyzer [I-D.lingga-i2nsf-analytics-interface-dm] [TS-23.288][TS-29.520]). For the further actions, the analysis results of the NF and the AF should be reported to the NF controller and the AF controller, respectively. An Analytics Interface is an interface to deliver analysis results to either an NF controller or an AF controller [I-D.lingga-i2nsf-analytics-interface-dm].

The data models for capability and interfaces can be contructed by either YANG [RFC6020][RFC7950] or YAML [YAML]. The message delivery protocol for the interfaces can be one among NETCONF [RFC6241], RESTCONF [RFC8040], and REST API [REST].

4. IANA Considerations

This document does not require any IANA actions.

5. Security Considerations

The same security considerations for the Interface to Network Security Functions (I2NSF) Framework [RFC8329] are applicable to the Intent-Based System this document.

6. References

6.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>.
[RFC7149]
Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, , <https://www.rfc-editor.org/info/rfc7149>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC9365]
Jeong, J., Ed., "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", RFC 9365, DOI 10.17487/RFC9365, , <https://www.rfc-editor.org/info/rfc9365>.

6.2. Informative References

[I-D.jeong-nmrg-ibn-network-management-automation]
Jeong, J. P., Ahn, Y., Kim, Y., and J. Jung-Soo, "Intent-Based Network Management Automation in 5G Networks", Work in Progress, Internet-Draft, draft-jeong-nmrg-ibn-network-management-automation-04, , <https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-ibn-network-management-automation-04>.
[I-D.irtf-coinrg-coin-terminology]
Hong, J., Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy, X., Griffin, D., and M. Rio, "Terminology for Computing in the Network", Work in Progress, Internet-Draft, draft-irtf-coinrg-coin-terminology-01, , <https://datatracker.ietf.org/doc/html/draft-irtf-coinrg-coin-terminology-01>.
[I-D.irtf-coinrg-use-cases]
Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy, X., Griffin, D., and M. Rio, "Use Cases for In-Network Computing", Work in Progress, Internet-Draft, draft-irtf-coinrg-use-cases-05, , <https://datatracker.ietf.org/doc/html/draft-irtf-coinrg-use-cases-05>.
[I-D.ietf-i2nsf-applicability]
Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. Lopez, "Applicability of Interfaces to Network Security Functions to Network-Based Security Services", Work in Progress, Internet-Draft, draft-ietf-i2nsf-applicability-18, , <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-applicability-18>.
[I-D.ietf-i2nsf-capability-data-model]
Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. Lin, "I2NSF Capability YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-capability-data-model-32, , <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-32>.
[I-D.ietf-i2nsf-registration-interface-dm]
Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Jung-Soo, "I2NSF Registration Interface YANG Data Model for NSF Capability Registration", Work in Progress, Internet-Draft, draft-ietf-i2nsf-registration-interface-dm-26, , <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-26>.
[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-31, , <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-31>.
[I-D.ietf-i2nsf-nsf-facing-interface-dm]
Kim, J. T., Jeong, J. P., Jung-Soo, 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://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-29>.
[I-D.ietf-i2nsf-nsf-monitoring-data-model]
Jeong, J. P., Lingga, P., Hares, S., Xia, L., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-nsf-monitoring-data-model-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-20>.
[I-D.lingga-i2nsf-analytics-interface-dm]
Lingga, P., Jeong, J. P., and Y. Choi, "I2NSF Analytics Interface YANG Data Model", Work in Progress, Internet-Draft, draft-lingga-i2nsf-analytics-interface-dm-03, , <https://datatracker.ietf.org/doc/html/draft-lingga-i2nsf-analytics-interface-dm-03>.
[I-D.jeong-i2nsf-security-management-automation]
Jeong, J. P., Lingga, P., Jung-Soo, J., Lopez, D., 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-07, , <https://datatracker.ietf.org/doc/html/draft-jeong-i2nsf-security-management-automation-07>.
[I-D.yang-i2nsf-security-policy-translation]
Jeong, J. P., Lingga, P., and J. Yang, "Guidelines for Security Policy Translation in Interface to Network Security Functions", Work in Progress, Internet-Draft, draft-yang-i2nsf-security-policy-translation-16, , <https://datatracker.ietf.org/doc/html/draft-yang-i2nsf-security-policy-translation-16>.
[YAML]
Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another Markup Language (YAML) 1.0", Available: https://yaml.org/spec/history/2001-05-26.html, .
[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, .
[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, .
[NFV-COIN]
Venancio, G., Turchetti, R., and E. Duarte Jr., "NFV-COIN: Unleashing The Power of In-Network Computing with Virtualization Technologies", SBC Journal of Internet Services and Applications, Available: https://journals-sol.sbc.org.br/index.php/jisa/article/view/2342, .
[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, .
[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, .
[BERT]
Devlin, J., Chang, M., Lee, K., and K. Toutanova, "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding", NAACL-HLT Conference, Available: https://aclanthology.org/N19-1423.pdf, .
[Deep-Learning]
Goodfellow, I., Bengio, Y., and A. Courville, "Deep Learning", Publisher: The MIT Press, Available: https://www.deeplearningbook.org/, .
[AUTOSAR-SDV]
"AUTOSAR Adaptive Platform", Available: https://www.autosar.org/standards/adaptive-platform, .
[Eclipse-SDV]
"Eclipse Software Defined Vehicle Working Group Charter", Available: https://www.eclipse.org/org/workinggroups/sdv-charter.php, .
[COVESA]
"Connected Vehicle Systems Alliance", Available: https://covesa.global/, .
[Kubernetes]
"Kubernetes: Cloud Native Computing Platform", Available: https://kubernetes.io/, .
[Survey-IBN-CST-2023]
Leivadeas, A. and M. Falkner, "A Survey on Intent-Based Networking", Available: https://ieeexplore.ieee.org/document/9925251, .

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. RS-2024-00398199).

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-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).

Appendix B. Contributors

This document is made by the group effort of OPWAWG, greatly benefiting from inputs and texts by Linda Dunbar (Futurewei), Yong-Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui University). The authors sincerely appreciate their contributions.

The following are coauthors of this document:

Mose Gu
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
URI: http://iotlab.skku.edu/people-Moses-Gu.php
Juwon Hong
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
URI: http://iotlab.skku.edu/people-Joo-Won-Hong.php

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
Yiwen Shen
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
URI: https://chrisshen.github.io
Yoseop Ahn
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
URI: http://iotlab.skku.edu/people-Ahn-Yoseop.php
Younghan Kim
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
06978
Republic of Korea
Elias P. Duarte Jr.
Department of Computer Science and Engineering
Federal University of Parana
Brazil