I2ICF
bofreq-jeong-i2icf-02

Document Type Declined BOF request
Title I2ICF
Last updated 2025-02-10
State Declined
Editors Jaehoon Paul Jeong , Luis M. Contreras , Haoyu Song , Yiwen (Chris) Shen , Kehan Yao
Responsible leadership Mahesh Jethanandani
Send notices to (None)
bofreq-jeong-i2icf-02

Name: Interface to In-Network Computing Functions (I2ICF)

Description

Many throughput-sensitive and compute-intensive applications have performance bottleneck issues under existing network technologies. Use cases related to these applications include:
* Metaverse, AI-enabled Content Delivery Network (CDN), Autonomous Vehicle Driving, Unmanned Aerial Vehicles (UAV), and Urban Air Mobility (UAM) which require the connectivity to the Internet having enterprise networks, campus networks, and edge networks.
* Distributed Artificial Intelligence (AI) model training, inference, and big data analysis (e.g., Spark) which are typically deployed in data center networks.

Common approaches just transmit a large volume of data to end servers for processing, which incur the following problems:
* Network capacity limitations,
* Heavy server load,
* High energy cost,
* The increase of Job Completion Time (JCT), and
* The reduction of overall service performance.

In-Network Computing (INC) or Computing in the Network (COIN) is a promising technology to help solve these problems. It could help reduce the data volume and improve the Quality of Service (QoS) by offloading some Application Functions (AFs) or Computing Functions (CFs) into In-Network Computing Functions (ICFs) such as Programmable Network Devices (PNDs). Also, Intent-Based Networking (IBN) can compose user services autonomously and construct a combination of ICFs into a target network for service provisioning and QoS assurance.

Existing approaches for Operation, Administration, and Maintenance (QAM) do not support the configuration and management of INC capabilities in an automatic manner. The most representative existing work is Interface to Network Security Functions (I2NSF) in terms of Network Security Functions (NSFs) for cloud-based security services. I2NSF has defined a set of software interfaces and YANG data models for the OAM aspects of the registration, control, and monitoring of virtualized NSFs. These interfaces enables users to specify their security policies.

However, the primary differences between I2NSF and I2ICF are:
* Use cases are very different.
* I2NSF cannot be directly extended to achieve in-network AFs or CFs configurations, in that:
- In-network AFs and CFs have not been clearly defined.
- INCs need coordination with end-hosts in job placement and memory management, which is not supported by I2NSF.
- I2NSF does not consider the composition of general AFs and CFs other than security services.
- I2NSF does not support Closed-Loop Control for intent assurance.

Therefore, some further operational interfaces should be defined to achieve the configuration and management of different in-network AFs and CFs as ICFs from different vendors.

The I2ICF group aims to define interfaces and protocols for provisioning In-Network Computing Functions (ICFs) like AFs and CFs for the requested services in the aforementioned use cases. The I2ICF interfaces include:
* The Northbound interface between an I2ICF User and a Network Controller having a job scheduler (service orchastrator) defines:
- High-level resource management (e.g., processors, memory, and network bandwidth) of ICFs.
- Exposure of topology information and in-network primitives to high-level in-network AFs (e.g., in-network aggregation).
- Job placement such as the attachment and dettachment of specific jobs with memories of ICFs.

  • The Southbound interface between the Network Controller and ICFs
  • Service provisioning with a low-level policy for the corresponding ICF(s).

  • Monitoring of ICFs for the task coordination between the Network Controller and ICFs.

  • Network Controller

  • Registration of the capabilities of ICFs through Vendor's Management Systems to provide the ICFs.
  • Intent translation from an intent (as a high-level policy) of an I2ICF User to a low-level policy for an ICF.
  • Intent assurance for the requirements of the intent through the closed-loop control.

This group also aims at standardizing YANG data models for the capabilities of ICFs and the I2ICF interfaces. An intent and a policy for the ICFs can be constructed by an XML file based on those YANG data models. The delivery of such an intent and a policy can be performed by either NETCONF or RESTCONF.

Required Details

Information for IAB/IESG

To allow evaluation of your proposal, please include the following items:
- Any protocols or practices that already exist in this space: NETCONF, RESTCONF
- Which (if any) modifications to existing protocols or practices are required: N/A
- Which (if any) entirely new protocols or practices are required: N/A
- Open source projects (if any) implementing this work: https://github.com/jaehoonpauljeong/I2INF

Agenda