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

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 7 May 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Network softwarization has been widely adopted in multiple environments, such as in cloud and edge computing, as well as in the network infrastructure itself, facilitating the deployment of network services (e.g., 5G mobile networks [TS-23.501]). The multiple technologies behind network softwarization include Network Functions Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2] and Software-Defined Networking (SDN) [RFC7149]. Furthermore, there is also an integration with Intent-Based Networking (IBN) [RFC9315][Survey-IBN-CST-2023], which can be used to define and deploy intelligent network services as well as intelligent application services. End-user devices such as smartphones and smartwatches are connected to various Internet-of-Things (IoT) devices for customer-tailored services. Recently, Software-Defined Vehicles (SDVs) [AUTOSAR-SDV][Eclipse-SDV][COVESA] have the potential to become as popular as smartphones. SDVs are intended to use network softwarization technologies such as NFV and SDN. System components and applications in the context of SDVs are usually executed on containers in a cloud native environment and can be orchestrated for instance with Kubernetes [Kubernetes].¶

There is an undeniable trend towards using Artificial Intelligence (AI) to improve multiple complex network operations. AI can, for instance, enable the creation of dynamic, adaptable security policies, which are particularly important in the cloud-edge-core-continuum, which is by definition a heterogeneous environment to which different parts can bring advantages, challenges and threats. AI has been successfully used in the context of intrusion detection, but it also improves troubleshooting, being able to predict problems before they occur. AI can learn from telemetry data collected from multiple networks and reach conclusions that can be applied globally or to individual networks. In all these cases, there are tremendous benefits to running AI processes within the network itself.¶

In this context, network automation and management have become critical. It is important to facilitate the construction of intelligent services and applications for both network operators and end users [I-D.jeong-nmrg-ibn-network-management-automation]. A user intent (who can be an end user or network operator) in the form of either text or voice needs to be understood and processed by the system. 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. Thus, an intent needs to be translated into a network policy or an application policy that satisfies the user request. A network policy consists of rules to execute a user intent, which can be for instance defined in terms of Quality of Service (QoS) requirements, defining targets for metrics such as throughput and delay. An application policy consists of rules to execute the service's application demands, for example in terms of functionality and timing. After network and application polices are translated, there is a need to invoke the appropriate Network Functions (NF) in the network infrastructure, edge, or cloud.¶

Thus, a user intent has to be translated either into a network policy executed as a network service on the network infrastructure or an application policy for an application service. For example, services for user applications (e.g., video conference) need to be accurately configured and efficiently processed by not only Application Functions (AF) such as 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) defined in the context of Computing in the Network (COIN) [I-D.irtf-coinrg-use-cases][NFV-COIN].¶

In the context of Computing in the Network (COIN) terminology [I-D.irtf-coinrg-coin-terminology], a Programmable Network Device (PND) in an In-Network Computing (INC) environment can have multiple kinds of features and capabilities. A PND can also interact with other PNDs. PNDs from different product lines or vendors can provide different functionalities for INC functions. In order to compose a COIN system consisting of multiple PDNs that interact among themselves, it is necessary to define a standard interface for PNDs to expose so that they can learn about each other's capabilities and properly interact.¶

A standard framework to define the interfaces of Application Functions (AFs) and Network Functions (NFs) is required to allow the configuration and monitoring of applications and network services consisting of those functions. There is currently no standard data model to describe the capabilities of AFs and NFs. Furthermore, there is no standard data model defining an interface to register the capabilities of AFs and NFs on a controller-like device that would process service requests for those functions. In addition, there are no standard interfaces to configure and monitor those AFs and NFs according to user's intent. The 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]. The present document is defined taking into account the I2NSF document, but the purpose is beyond the scope of Security Functions, defining 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 the Interface to In-Network Functions (I2INF) considering arbitrary In-Network Functions (INFs) presenting arbitrary features and 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) which are NFs defined within the context of NFV and SDN [I-D.irtf-coinrg-use-cases]. Secondly, they also include In-Network Application Functions (INAF) which are AFs employed by Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV) [AUTOSAR-SDV][Eclipse-SDV][COVESA], and Unmanned Aerial Vehicles (UAV). Finally, this document shows how Intent-Based Networking (IBN) can be realized with the proposed I2INF framework and its interfaces for user services that consist of a combination of INFs in a target network.¶

Note that a standard framework for In-Network Functions is the only way to provide the interoperability of diverse autonomous systems and networks on the service-level. The proposed I2INF allows the integration of existing and new services implemented with different technologies, at different locations (e.g., cloud or edge) each with different requirements and functionalities. It can also have an impact on innovation, as it provides a new level of integration for various INFs. The standard interfaces for the INFs can also allow global-level decisions to be enforced, such as those related to elasticity and scalability.¶

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:¶

• Intent: the set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how they are achieved or should be implemented [RFC9315].¶

• Intent-Based System (IBS): the system that enforces an intent from a user (or administrator) into a target system (e.g., SDV). An intent can be expressed in Natural Language (e.g., English) and can be translated into a policy (i.e., network policy and application policy) using Natural Language Processing (NLP) [USENIX-ATC-Lumi] [BERT] [Deep-Learning]. In this document, the intent can be translated into a corresponding high-level policy by an intent translator [I-D.jeong-i2nsf-security-management-automation]. The high-level policy can also be translated into the corresponding low-level policy by a policy translator [I-D.yang-i2nsf-security-policy-translation]. The low-level policy is dispatched to appropriate Service Functions (SFs). Through the monitoring of the SFs, the activity and performance of the SFs is monitored and analyzed. If needed, the rules of the high-level or low-level network policy are augmented or new rules are generated and configured to appropriate SFs.¶

• Mobile Object (MO): the object that is capable of moving with its own power source and wireless communication capability, e.g., in the context of 5G Vehicle-to-Everything (e.g., 5G V2X). An MO can be an Internet-of-Things (IoT) device, Software-Defined Vehicle (SDV) [AUTOSAR-SDV][Eclipse-SDV][COVESA], and Unmanned Aerial Vehicle (UAV). An MO is a Programmable Network Device (PND) [I-D.irtf-coinrg-coin-terminology] that can be reconfigured for different network requirements inside the MO.¶

• In-Network Computing Functions (INCF): the service functions that do the computing in the network infrastructure. They are a group of COIN programs [I-D.irtf-coinrg-coin-terminology] to provide required computing tasks and functions.¶

• In-Network Application Functions (INAF): the service functions that work for applications in Mobile Objects. They are a group of COIN programs [I-D.irtf-coinrg-coin-terminology] to provide the required application tasks and functions.¶

• Interface to In-Network Functions (I2INF): the interfaces that are used between a pair of INFs for the interaction, configuration and monitoring.¶

• A Framework for the Interface to In-Network Functions (I2INF): the framework that consists of components and interfaces to configure and monitor INFs that can be employed by applications and services in the network infrastructure and MOs.¶

3. Problem Statement for Interface to In-Network Functions

This section starts with a description and examples of In-Network Computing Functions. Next, an overview of Intent-Based Networking (IBN) is presented, and finally the Problem Statement for the Interface to In-Network Functions (I2INF). Figure 1 shows Wireless and Wired Networks of a Central Cloud. The I2INF framework includes network entities and Mobile Objects (MO). Figure 2 shows a VNF-Consensus Architecture that allows the I2INF framework to synchronize flow table information of replicated SDN Controllers all in the same Edge Cloud [NFV-COIN]. These are example networks within the I2INF problem space.¶

                                  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

                        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
     (Prefix1)            (Prefix2)            (Prefix3)

<----> Wired Link

        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|  :
                     :                    +----------+  :

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.¶

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 and RS-2022-II221015).¶

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:¶

Authors' Addresses