A Framework for the Interface to In-Network Functions (I2INF)
Department of Computer Science & Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Department of Computer Science & Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106chrisshen@skku.eduhttps://chrisshen.github.io
Department of Computer Science & Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106ahnjs124@skku.eduhttp://iotlab.skku.edu/people-Ahn-Yoseop.php
School of Electronic Engineering
Soongsil University369, Sangdo-ro, Dongjak-guSeoul06978Republic of Koreayounghak@ssu.ac.kr
Department of Informatics
Federal University of ParanaBrazilelias@inf.ufpr.br
China Mobile
Beijing100053Chinayaokehan@chinamobile.com
Operations and Management Area
Operations and Management Area Working GroupInternet-Draft
This document specifies a framework to define Interface to In-Network
Functions (I2INF) for user services both on the network-level and
application-level. In-Network Functions (INF) include In-Network
Computing Functions (INCF), defined in the context of Network Functions
Virtualization (NFV) and Software-Defined Networking (SDN). INF also
includes In-Network Application Functions (INAF) which appear in the
context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles
(SDV), and Unmanned Aerial Vehicles (UAV). This document describes an
I2INF framework, which includes components and interfaces to configure
and monitor the INFs that implement applications and services.
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 ). The multiple
technologies behind network softwarization include Network Functions
Virtualization (NFV) and Software-Defined Networking (SDN) . Furthermore, there is also an integration with
Intent-BasedNetworking (IBN), which can be used to define and deploy
intelligent network services as well as intelligent application services.
In the context of Computing in the Network (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 be exposed so that they can learn
about each other's capabilities and properly interact with each other.
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 with 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 a 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) . 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 a framework for the definition of the Interface to
In-Network Functions (I2INF) for In-Network Functions (INFs), assuming
arbitrary functionalities, features and capabilities. The INFs consist of
Network Functions (NFs) including PNDs and Application Functions (AFs) and
are used to compose user services. First of all, INFs include In-Network
Computing Functions (INCF) which are NFs defined within the context of NFV
and SDN . Secondly, they also
include In-Network Application Functions (INAF) which are AFs employed by
Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV)
, 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.
This document uses the terminology described in ,
,
,
,
, , and . 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 .
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)
. In this document, the intent can be
translated into a corresponding high-level policy by an intent
translator . The
high-level policy can also be translated into the corresponding
low-level policy by a policy translator
. 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) , and Unmanned
Aerial Vehicle (UAV). An MO is a Programmable Network Device (PND) that can be reconfigured
for different network requirements inside the MO.
In-Network Computing Functions (INCF): the service functions that work
for computing in the network infrastructure. They are a group of COIN
programs 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
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.
This section specifies a framework for defining the Interface to In-Network
Functions (I2INF), including its components and the interfaces among those
components.
shows Wireless and Wired Networks of a Central Cloud. The I2INF framework
includes network entities and Mobile Objects (MO). shows a
VNF-Consensus Architecture that allows the I2INF framework to synchronize
flow table information of all the replicated SDN Controllers in the same Edge
Cloud .
| 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 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
]]>
An intent-based management strategy is required between the central cloud
and MOs to allow the automatic configuration of MOs . shows an instance of the I2INF
framework as an IBS for an MO. The framework in this case includes a Central
Cloud and an MO. shows an
I2INF framework as an IBS for an Edge Cloud. The framework in this case
consists of a Central Cloud and an Edge Cloud.
+---------------------------------------------------------------------+
| +------------------+ +--------------------+ |
| | I2INF User | +---------->| I2INF Database | |
| +------------------+ | +--------------------+ |
| ^ | ^ |
| | | Database | Database |
| | | Interface | Interface |
| | Consumer-Facing | V |
| | Interface (Intent) | +--------------------+ |
| | | +-------->| Cloud Analyzer |<-+ |
| | | | +--------------------+ | |
| V | |Analytics | |
| +------------------+<---------+ |Interface | |
| | Cloud Controller |<-----------+ +--------------------+ | |
| +------------------+<-------------------->|Vendor's Mgmt System| | |
| ^ Registration Interface +--------------------+ | |
| | ^ | |
+----------|------------------------------------------|-------------|-+
| Controller-Facing Interface VMS-Facing | Analyzer- |
| (High-level Policy) Interface | Facing |
| | Interface |
+----------|------------------------------------------|-------------|-+
| | | | |
| v v | |
| +------------------+ Registration +--------------------+ | |
| | MO Controller |<-------------------->| MO Vendor's | | |
| +------------------+ Interface | Mgmt System | | |
| ^ ^ +--------------------+ | |
| | | | |
| | | | |
| | | Analytics Interface +--------------------+ | |
| | +------------------------>| MO Analyzer |<-+ |
| | +--------------------+ |
| | SF-Facing Interface ^ |
| | (Low-level Policy) | |
| | | |
| | +--------------+----------------------+---+ |
| | | | Monitoring Interface | |
| v v v v |
| +---------------+ +---------------+ +---------------+ |
| | SF-1 | | SF-2 |........| SF-n | |
| | (Router) | | (Firewall) | | (Navigator) | |
| +---------------+ +---------------+ +---------------+ |
+---------------------------------------------------------------------+
]]>
+---------------------------------------------------------------------+
| +------------------+ +--------------------+ |
| | I2INF User | +---------->| I2INF Database | |
| +------------------+ | +--------------------+ |
| ^ | ^ |
| | | Database | Database |
| | | Interface | Interface |
| | Consumer-Facing | V |
| | Interface (Intent) | +--------------------+ |
| | | +-------->| Cloud Analyzer |<-+ |
| | | | +--------------------+ | |
| V | |Analytics | |
| +------------------+<---------+ |Interface | |
| | Cloud Controller |<-----------+ +--------------------+ | |
| +------------------+<-------------------->|Vendor's Mgmt System| | |
| ^ Registration Interface +--------------------+ | |
| | ^ | |
+----------|------------------------------------------|-------------|-+
| Controller-Facing Interface VMS-Facing | Analyzer- |
| (High-level Policy) Interface | Facing |
| | Interface |
+----------|------------------------------------------|-------------|-+
| | | | |
| v v | |
| +------------------+ Registration +--------------------+ | |
| | Edge Controller |<-------------------->| Edge Vendor's | | |
| +------------------+ Interface | Mgmt System | | |
| ^ ^ +--------------------+ | |
| | | | |
| | | | |
| | | Analytics Interface +--------------------+ | |
| | +------------------------>| Edge Analyzer |<-+ |
| | +--------------------+ |
| | SF-Facing Interface ^ |
| | (Low-level Policy) | |
| | | |
| | +--------------+----------------------+---+ |
| | | | Monitoring Interface | |
| v v v v |
| +---------------+ +----------------------+ +---------------+ |
| | SF-1 | | SF-2 |...| SF-n | |
| |(VNF-Consensus)| |(NFV-Failure-Detector)| | (NFV-RBCast) | |
| +---------------+ +----------------------+ +---------------+ |
+---------------------------------------------------------------------+
]]>
A Central Cloud (CC) consists of an I2INF User (as network administrator), a
Cloud Controller (which acts as an orchestrator for the central cloud), an
I2INF Database (which is the main repository for INF management and
monitoring information), and a Cloud Analyzer (as a monitoring data analyzer
for MOs and ECs) such as Network Data Analytics Function (NWDAF) in 5G
networks . These and
other components are defined next:
I2INF User: the software (e.g., web-browser-based user
interface) that is used by I2INF administrators to deliver network intents to MO
controllers and edge controllers. In the 3GPP intent-driven management
service document, it is assumed that a network intent is configured by an
intent data model .
Cloud Controller: the main component that is responsible for the management
and control of other system components of the central cloud, including
security. From a security point of view, a security service policy can be
transmitted to the service function (SF) by converting the I2INF User's
security service intent into the corresponding security service policy and
selecting an SF that provides an appropriate security service.
Cloud Vendor's Management System: the component that provides images of
virtualized SFs for cloud services and registers the SFs and access
information with the Cloud Controller.
Cloud Analyzer: the component that gathers and evaluates monitoring data from MO Analyzers
and Edge Analyzers to ensure the functionality and performance of SFs, e.g.,
the network data analytics function (NWDAF) in 5G networks.
I2INF Database: the database that manages the information of MOs and ECs,
including network and security configuration and status of MOs and ECs. For
example, for MOs it maintains the current locations and navigation paths
(e.g., SDVs). For ECs, it maintains network configuration information,
including for instance the status of AFs and NFs within the edge cloud.
An IBS in an MO (or EC) is composed of an MO Controller (or Edge Controller)
which acts as a manager for the MO (or EC), an MO Analyzer (or Edge
Analyzer) which acts as a monitoring data analyzer for an MO (or EC)) , it can also
include a Vendor's Management System (as a vendor system to provide
cloud-native containers) , and Service Functions
(SFs). SFs for the MO require NFs such as routers, DNS servers, and
firewalls ), and AFs
include safe driver devices and navigators. SFs for the EC include NFs such
as VNF-Consensus, NFV-Failure-Detector, and NFV-RBCast (i.e., NFV
Reliable-Ordered Broadcast) ). Those components are
further described next:
MO Controller: the component that controls and manages other components of the
MO framework (or the EC framework). It translates the high-level policies
received from the Cloud Controller into a low-level policies that the SF can
understand. Any SF can be selected to execute any low-level service. Yet
another task is the transmission of the policy to the SF.
MO Vendor Management System (or Edge Vendor Management System): the component
that provides an image of a virtualized SF for MO services (or EC services)
to the MO framework (or the EC framework). Also responsible for registering
functions and SF access control information on MO Controller (or the Edge
Controller).
Service Function (SF): the component that can be either a virtual network
function (VNF), cloud native network function (CNF), or physical network
function (PNF) of a specific service. In the context of security, SFs
provide security services such as firewalls, web filters, DDoS attack
mitigators, and anti-viruses. In addition, networks and application services
can also operate as SFs.
MO Analyzer (or Edge Analyzer): the component that collects monitoring data
from SFs of MOs (or ECs) and analyzes the collected data to monitor the
activity and performance of SFs. The MO Analyzer (or Edge Analyzer) acts as
NWDAF of a 5G network. If there are problems (e.g., security attacks,
traffic congestion, QoS degradation) in the MO network (or EC network), the
MO Analyzer (or Edge Analyzer) requests either policy reconfigurations or
feedback information to MO Controller (or Edge Controller) to restore
security or troubleshoot the network.
Together with the I2INF framework, interfaces are also defined between pairs
of system components in the central cloud and MO (or EC), respectively.
These interfaces are shown in and and include the following:
Consumer-Facing Interface: the interface between I2INF User Internet and the
Cloud Controller. This interface is used for communicating intents.
Controller-Facing Interface: the interface between the Cloud Controller and
the MO Controller (or Edge Controller) for the transmission of high-level
policies corresponding to translated intents.
SF-Facing Interface: the interface between the MO Controller (or Edge
Controller) and SF for the transmission of translated lower-level policies.
Registration Interface: the interface used to transfer information about SF
capabilities and access control for the registration of the SF with either the
Cloud Controller or MO Controller (or Edge Controller). This interface is
also used to deliver SF queries issued for searching for a requested SF. For
an MO, this can be the interface between the Cloud Controller and the Cloud
Vendor Management System (Cloud VMS), or between MO Controller and MO Vendor
Management System (MO VMS). Also, for an EC, this can be the interface
between the Cloud Controller and the Cloud Vendor Management System (Cloud
VMS), or between Edge Controller and Edge Vendor Management System (Edge
VMS).
Monitoring Interface: the interface between the SF and the MO Analyzer (or
Edge Analyzer) used to collect the SF monitoring data and is employed to
identify security, system, and network issues related to the SF.
Analytics Interface: the interface for the transmission of policy
reconfigurations or feedback produced as a result of analyzing the SF
monitoring data. For an MO, this is an interface between the MO Analyzer
and MO Controller, or between the Cloud Analyzer and Cloud Controller.
Also, for an EC, this is an interface between the Edge Analyzer and the
Edge Controller, or between the Cloud Analyzer and the Cloud Controller.
Analyzer-Facing Interface: the interface between the MO Analyzer (or Edge
Analyzer) and the Cloud Analyzer for the exchange of security, network, and
system-related analysis of SFs.
VMS-Facing Interface: the interface between the Cloud VMS and the MO VMS (or
Edge VMS) used to exchange SF feature information, such as SF container
images.
Database Interface: the interface for exchanging data of an I2INF database.
This is an interface between the I2INF Database and the Cloud Controller, or
between the I2INF Database and the Cloud Analyzer.
The intents, high-level policies, and low-level policies can be either XML
documents or YAML
documents . They can be delivered to the destination
components using NETCONF , RESTCONF , or REST API .
As shown in and , the I2INF Framework receives an
intent from the I2INF User, entered by a user (who can be an
administrator) into a target system such as an MO (e.g., SDV) or an Edge
Cloud. The intent from the I2INF User can be translated into the
corresponding high-level policy by an intent translator in the Cloud
Controller of the Central Cloud . The high-level
policy can also be translated into the corresponding low-level policy by a
policy translator in the MO Controller of the MO or the Edge Controller of
the Edge Cloud .
For the MO, as shown in , the
low-level policy is dispatched from the MO Controller to the appropriate
Service Functions (SFs) in the MO, examples of which include a Router or a
Firewall. Also, in the context of the EC, as shown in , the low-level policy is
dispatched from the Edge Controller to appropriate Service Functions (SFs)
in the EC, such as VNF-Consensus, NFV-Failure-Detector, and NFV-RBCast.
Through the monitoring of the SFs, the activity and performance of the SFs
in the MO (or EC) is monitored and analyzed by the MO Analyzer (or Edge
Analyzer) in the MO (or EC). If needed, the rules of the high-level or
low-level network policy can be augmented by the MO Analyzer (or Edge
Analyzer). Also, new rules can be automatically generated and configured to
appropriate SFs by the MO Analyzer (or Edge Analyzer).
In conclusion, this document proposed an I2INF framework as an IBS for both
MOs and ECs. Through this IBS, the SFs (i.e., NFs and AFs) in the MOs and
ECs can be configured and managed. Based on the proposed framework, both
virtualized NFs and AFs can be efficiently orchestrated, also allowing agile
resource reconfigurations and flexible updates.
This document does not require any IANA actions.
The same security considerations for the Interface to Network Security
Functions (I2NSF) Framework are applicable to the
Intent-Based System this document.
Yet Another Markup Language (YAML) 1.0System Architecture for the 5G System (5GS)Intent Driven Management Services for Mobile NetworksStudy on Scenarios for Intent Driven Management Services for Mobile NetworksArchitecture Enhancements for 5G System (5GS) to Support Network Data Analytics ServicesNetwork Data Analytics ServicesNetwork Functions Virtualisation (NFV); Architectural FrameworkNetwork Functions Virtualisation (NFV) Release 2;
Management and Orchestration; Architectural Framework SpecificationNFV-COIN: Unleashing The Power of In-Network Computing with Virtualization TechnologiesPrincipled Design of the Modern Web ArchitectureHey, Lumi! Using Natural Language for Intent-Based Network ManagementBERT: Pre-training of Deep Bidirectional Transformers for Language UnderstandingDeep LearningAUTOSAR Adaptive PlatformEclipse Software Defined Vehicle Working Group CharterConnected Vehicle Systems Alliance Kubernetes: Cloud Native Computing PlatformA Survey on Intent-Based NetworkingClickINC: In-network Computing as a Service in Heterogeneous Programmable Data-center Networks
The following changes are made from draft-jeong-opsawg-i2inf-framework-01:
The conents have been updated for further clarification.
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).
This document is made by the group effort of OPWAWG, greatly benefiting
from inputs and texts by (Futurewei),
(Daejeon University), and
(Dong-Eui University).
The authors sincerely appreciate their contributions.
The following are coauthors of this document:
Department of Computer Science & EngineeringSungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106rna0415@skku.eduhttp://iotlab.skku.edu/people-Moses-Gu.phpDepartment of Computer Science & EngineeringSungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106hongju2024@skku.eduhttp://iotlab.skku.edu/people-Joo-Won-Hong.phpDepartment of InformaticsFederal University of ParanaBrazilgiovanni@inf.ufpr.br