| Internet-Draft | IBN Use Cases | October 2026 |
| Yao, et al. | Expires 30 April 2027 | [Page] |
This document proposes a methodology to construct an Intent-Based Networking (IBN) system. According to this methodogy, it decribes several use cases of IBN. The methodology for the IBN system includes data collection for system awareness in the IBN system and then the construction of the IBN system. This construction consists of intent translation, policy translation, policy verification, policy deployment, policy monitoring, policy validation, policy optimization, and intent report. In addition, practices are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. Finally, this document discusses three aspects for the deployment of the IBN system on the real world. They are Multi-Domain Dichotomy for IBN, the Integration of IBN and Network Digital Twin (NDT), and IBN with Artificial Intelligence (AI).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 30 April 2027.¶
Copyright (c) 2026 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.¶
[RFC9315] gives the concepts and definition of Intent-Based Networking (IBN), and [RFC9316] proposes a comprehensive taxonomy of the intent classifications. Although the intent life cycle has been defined, including all the core functional components like intent injection, intent translation, policy generation, and intent assurance, there is still a big gap between defining these high-level functionality and building a realistic IBN system.¶
This document proposes a methodology to construct an IBN system, proposes several use cases of IBN, and then practice learning and general learning when building an IBN system. Main objectives of this document is to instruct future research directions of IBN and other related network management technologies in the perspective of network operators and vendors as well as service providers.¶
This section summarizes a methodology to build an IBN system. This methodology refers to the modeling of an intent life cycle and its high-level core functional components, as well as the specific solutions to implement those components [RFC9315]. The methodology is essential to build a real IBN system, beyond the definition in [RFC9315]. The methodology to an IBN system is composed of two important parts: (i) data collection for system awareness and (ii) construction of an IBN system.¶
System awareness requires the data collection of various network status indicators like network traffic and resources. Building a valuable dataset is essential for an IBN system. A comprehensive data collection depends on suitable methods and tools, appropriate sampling metrics, and reasonable granularity for the data collection.¶
Methods and Tools¶
There are many existing ways to collect network data in transport networks in the Internet and core networks in mobile networks (e.g., 5G core networks [TS-23-501]). Those ways can be primarily classified into two types such as active measurement and passive measurement. Active measurement like In-band Network Telemetry (INT) [INT] can grab networking information by inserting timestamps into the programmable field of on-path packets. On the other hand, passive measurement uses some tools like Tcpdump or Wireshark to collect data at specific targets such as endpoint servers. An IBN system needs tools of both types to collect data, depending on what scenarios they might be applied to.¶
For a core network in mobile networks (e.g., 5G systems [TS-23-501]), an Event Exposure API is an interface with which Network Functions (NFs) to subscribe to network triggers (e.g., PDU session releases, IP address changes, and user-plane path changes), receive state changes, alerts and operational events in real time, and respond to them. For example, as Event Exposure APIs in 5G systems, there are Session Management Event Exposure Service [TS-29-508] and Policy Control Event Exposure Service [TS-29-523].¶
For a Radio Access Network (RAN) in mobile networks, Key Performance Measurement (KPM) in Open RAN (O-RAN) [E2SM-KPM] is a standard specification to collect performance measurement data from an RAN and control it. The O-RAN KPM collects performance measurement data like various performance metrics such as traffic throughput per cell or User Equipment (UE), wireless link status, and packet loss. The KPM collects the performance measurement data through Near-Real-Time Radio Intelligent Controller (RIC) for the RAN and E2 Service Model (E2SM).¶
Metrics¶
Metrics include traffic-related and network-related information. Traffic-related metrics include performance indicators, such as latency, throughput, and traffic congestion signals. Network-related information includes network device information, such as the number and health status of ports, and network topology information (e.g., link connectivity and structures). To meet a specific user intention, such as load balancing and congestion elimination on the entire network, an IBN system needs to collect and process traffic and device related information.¶
Logs and Traces¶
Logs and traces are important for root cause analysis and intent assurance. A log is a record about an event or alarm. It consists of a timestamp, a severity level, and a message to describe the event or alarm. A trace is a record to describe a path or procedure for processing a request in a target network. It consists of the flow of the request and a latency for each step in the whole path or procedure.¶
Granularity¶
Network Traffic: Network traffic is usually collected in various forms, such as per-packet [INT] and per-flow (or per-flowlet) [IntFlow], and these are two most typical types of data collection. Per-packet tracking lets each packet be tracked, which is very accurate, but it requires greater monitoring overhead and state maintenance overhead [INT]. In contrast, per-flow tracking does not need to maintain too many states, and it generally uses five-tuples (i.e., source IP address, destination IP address, source port number, destination port number, transport layer protocol) to identify each flow, which often brings good observation results [IntFlow]. Other collection methods are like per-cell and per-flow [IntFlow]. Per-cell tracking tracks each cell unit whose length remains unchangeable, which is more friendly to system management and control. This method is often applied to Artificial Intelligence (AI) data center network monitoring. Per-flowlet tracking cuts a flow into several small flows at a certain interval, which is more suitable for implementing refined load balancing scenarios. Thus, the IBN system should select an appropriate traffic collection granularity (e.g., packet, flow, flowlet, and cell).¶
Time Granularity: Time granularity means that the data acquisition needs to adopt the appropriate time interval for data sampling. In the extreme case, data is collected without interruption. For example, the status information of each data packet is reported to a monitoring module without interruption. This collection method often brings too much redundant information, which leads to a lot of storage and computing overhead to the monitoring module. However, the method of sampling without interruption or at a very low time interval can better observe micro-bursts of the networking system. A micro-burst occurs when a large amount of burst data is received in milliseconds. For some black-box network systems and some high-concurrency network systems, it is necessary to sacrifice a certain amount of storage and computing costs to collect data in a finer granularity time slot, so as to make better a trade-off between system overhead and data acquisition accuracy. By analyzing the historical behavior of IBN systems, a reasonable time interval can be selected for data acquisition.¶
Spatial Granularity: Spatial granularity indicates that it is necessary to select an appropriate physical scope of a network for data collection. In some cases, the information collection method based on the whole network and the whole domains may not be suitable for all situations, and sometimes the results obtained from the processing and analysis of the collected data may not be accurate (e.g., RTT-based congestion control in data center networking) or incur too much overhead (e.g., hop-by-hop performance monitoring over the Internet). The best way is to match the most appropriate spatial granularity for user intents. For example, in wide-area data transmission, users need to select an optimal path. In this case, sampling is not required for all paths from a source to a destination. Only partial sampling is required for certain path segments which share endpoints, to ensure the correctness of decision makings on path setup in a scenario of multi-path data transmission.¶
An IBN system consists of the following submodules: intent translation, policy translation, policy verification, policy deployment, policy monitoring, policy validation, policy optimization, and intent reporting. Each module in the IBN system can match with each module in the Intent Life Cycle in [RFC9315]. The different construction methods and different construction tools used in these modules may affect the advantages of realizing a user intent. For different modules, this document summarizes the methods and tools that have been used and may be used.¶
Intent Translation¶
Translating and refining intents require the system to explore and exploit the semantic relationships of different service intents [I-D.gu-nmrg-intent-translator][I-D.pedro-ite]. It is necessary to build a general model to extract the key semantic information from the service intents in different representation forms. In the intent translation module, several possible intent expressions and translation methods are as follows:¶
A limited range of templates are preset in advance, and users can only express corresponding intentions by filling in or selecting templates. The advantage of this method is that the requirements for users and translation are very low, and all users can use it without learning. The disadvantage is that there are many restrictions, which can only be achieved through a preset template, but the preset template is limited, and cannot really meet the flexible and diverse needs of users.¶
Using Natural Language Processing (NLP), such as Flan-T5 [Flan-T5] and GPT-3 [GPT-3], for intent translation is another possible approach. NLP is used to convert a user's intent in a human language (e.g., English) into a text intent in a data format (e.g., XML, JSON, and YAML) used to store, represent, and transfer data. This translation from a verbal intent in a natural language to a text intent in a computer programming language is performed by an intent translator [I-D.gu-nmrg-intent-translator]. The advantage of this method is high flexibility, users can directly express their intents in a natural language according to their own needs, without being limited by templates. The disadvantage is that it is difficult to implement and has high requirements for the intent translation module. This needs to be able to accurately identify the real intent of a user, and different intent expression paradigms will affect the generation of subsequent policies. Thus, it is necessary to formalize normative intent expression grammars.¶
In addition, there are some preset expression languages for IBN networks, such as Nile (Network Intent Language) [Nile] and NEMO (Network Modeling Language) [I-D.xia-sdnrg-nemo-language]. In the designs of these languages' expressions, most of them consider the flexibility of the expressions, which can be extended and adjusted according to the intent scenario of the business under consideration. However, these language designs have some disadvantages (e.g., the capabilities of intent expressions). Most of the users are network practitioners, requiring the users to have certain network knowledge background.¶
Policy Translation¶
In an Intent-Based Network, the translation from a user intent to the corresponding network policy is required. The generated network policy needs to be mapped to an appropriate network function or network device to execute the policy. Thus, both the policy translation and mapping are required for intent enforcement in the target intent-based network.¶
A given user intent needs to consider both the intent and the network state, that is, the policy needs to satisfy the user intent and ensure that a network operation can be executed to satisfy the requested intent. The policy generation module can be implemented by setting up a repository of “intent” and “policy”, and mapping relationship between the intent and policy should be stored and updated as knowledge in a knowledge datastore (e.g., knowledge graph [Knowledge-Graph]) according to various intents and dynamic network state telemetry.¶
There is a mapping submodule in the policy translation module. This mapping submodule can select an appropriate network function or network device to execute the requested policy. The selection of such a network function or network device can be done by a set-cover algorithm or decision tree algorithm. One of these selection algorithms searches for a network function or network device that can accommodate the keywords in the policy.¶
Similar to different ways of expressing an intent, there are different approaches for the policy generation.¶
As opposed to the default template-based representation in the intent translation module, the simplest approach to policy generation is based on a default template or rule-based provisioning. After the user completes the corresponding intent expression through the graphical interface (e.g., a web-based graphical user interface (GUI)), a user or an AI agent can select the corresponding policy according to the preset template in the policy generation or the rules in a constructed rule-based policy generator. Similar to the above analysis, this approach has the advantage of being very simple to implement, but the disadvantage is that it is too restrictive and only a limited number of preset strategies can be selected.¶
The second common method of policy translation is inference-based generation, such as reasoning based on keywords in an intent expression, associating keywords with policies, and using Circular Reasoning [Circular-Reasoning] to generate policies. This method is more flexible than the template class description method, but the precision of policy generation is more related to the keyword extraction, and there is some uncertainty. In addition, there are policy generation methods based on network service description, which are widely used in Service Function Chaining (SFC) [RFC7665], network slicing or Network Functions Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2]. In essence, this approach can also be seen as inference-based strategy generation.¶
In addition to the above methods, AI technology-based policy generation methods have also emerged in recent years, such as a machine learning technology, which selects the corresponding policies through an AI model according to keywords extracted from an intent expression. With the development of AI technology, in addition to selecting preset policies, for example, based on Deep Reinforcement Learning [DRL], reasonable reward functions are set to generate strategies that consider user intents and network status.¶
Policy Verification¶
Policy verification checks whether the policy meets a specific user's requirements or not. Also, it includes policy conflict detection and policy conflict resolution [AI-Intent-Network].¶
The policy conflict detection includes two types: the conflicts between different policies themselves and the conflicts between policies and network states of the target network to perform the requested policy.¶
First, the conflict of the policies may be due to the conflict between the network states that different users want to obtain. The simplest example is that both users A and B request to increase the bandwidth of 10Gbps, but the network bandwidth of the shared network for users A and B is less than 20Gbps. This conflict caused by different user requirements can be resolved by a policy conflict handler that checks whether the policies can be deployed in practice or not. For example, the policy conflict handler can choose to execute only the policies that can be executed according to the resolution strategies, and reject other conflicting policies. In another way, it may negotiate with the users of the conflicted policies and adjust their policies to satisfy all the users as much as possible.¶
Second, if the generated policy conflicts with the network state, the intent-based system must detect that the generated policy cannot be executed by the target network. Also, if the generated policy cannot be executed, the policy needs to be re-generated. Otherwise, the failed policy generation should be reported to the intent user as a failure.¶
In terms of whether the policy is satisfied or not, the first way is to feedback the result to the user, and the user judges whether it is satisfied or not. For this purpose, the execution result can be presented through a graphical user interface. The second way is to use an AI agent such as deep reinforcement learning [DRL] to determine whether the results meet the needs or not.¶
Policy Deployment¶
Policy deployment is to deploy the policy translated from an intent into a network function or network device in a target network and let the configurations or commands of the policy operate in the network.¶
The policy translator delivers a policy with detailed configurations or commands to a policy renderer which deploys the policy into target network functions or devices (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator), which are called target network entities.¶
The policy renderer delivers the policy to the target network entities with a policy delivery protocol such as NETCONF [RFC6241], RESTCONF [RFC8040], or REST API [REST].¶
The target network entities execute their own configuration for the requested network services which are specified by the policy.¶
Policy Monitoring¶
Policy monitoring is to collect monitoring data from network entities (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator) for policy validation to judge whether the requested policy is enforced well or not in the target network.¶
Policy Validation¶
Policy validation is to judge whether the requested policy is satisfied by network entities in a target network or not. The policy may have goals in terms of performance (e.g., throughput, delay, and loss rate) and services (e.g., firewall, web filter, and DDoS-attak mitigator).¶
A validation module (e.g., analyzer) uses the collected monitoring data for evaluation and check whether the required goals for each policy are met with specific metrics from the monitoring data or not. This checking can be performed by Artificial Intelligence (AI) and Machine Learning (ML) algorithms.¶
Evaluation results need to be delivered to an optimization module (e.g., optimizer) which can augment the existing policy or generate a new policy for further improvement.¶
Policy Optimization¶
Policy optimization is to augment the existing policy or generate a new policy to meet the goals of the requested intent. With the evaluation results, an optimization entity (e.g., optimizer) performs optimization for each registered intent.¶
There are two kinds of optimization, such as Quality of Service (QoS) and Service Provisioning. First, the optimizer for QoS deals with the improvement of performance metrics (e.g., throughput, delay, and loss rate). Second, the optimizer for service provisioning handles the service requirements (e.g., firewall filtering, web filtering, and DDoS-attack mitigation). For each optimization, the optimizer augments the existing policy or generates a new policy for further improvement. It delivers the policy to the policy renderer so that the renderer can enforce the augmented or generated policy into the target network entities.¶
Thus, the steps from Policy Deployment to Policy Optimization construct a closed-loop policy control to guarantee the goals of the requested intent in a target network. This is network service automation using the IBN technology.¶
Intent Reporting¶
Intent reporting is to abstract and report the operation results in a target network for a given intent to the intent user. An intent report can include explanations on what changed in the intent assurance closed-loop. The intent user can receive such a report in real time whenever a policy's update occurs.¶
The intent reporting consists of two submodules such as an abstraction submodule and a reporting submodule. The abstraction submodule abstracts results in the form of text, figures, and tables. The reporting submodule delivers the abstracted results to the user to let the user know the activity and performance of the network.¶
The abstraction submodule analyzes the activity and performance of target network entities in the target network. The analysis is expressed in the form of text, tables, and figures by various statistics, AI, ML, and graphics tools.¶
The reporting submodule delivers the analysis report to the user (e.g., network administrator and operator) so that (s)he may check the enforcement and quality of the requested network services for the given user intent in the target network with relevant network entities. The user can render another intent or modified intent to satisfy his (or her) user intent in the target network.¶
There is a mapping between the modules of an IBN System in Section 2.2 and the modules of the Intent Life Cycle in [RFC9315].¶
Intent Translation in the IBN System is mapped to (i) Intent Ingestion and Interaction with Users and (ii) Intent Translation in the Intent Life Cycle.¶
Policy Translation in the IBN System is mapped to Intent Orchestration in the Intent Life Cycle.¶
Policy Verification in the IBN System is mapped to Intent Orchestration in the Intent Life Cycle.¶
Policy Deployment in the IBN System is mapped to Intent Orchestration in the Intent Life Cycle.¶
Policy Monitoring in the IBN System is mapped to Monitoring in the Intent Life Cycle.¶
Policy Validation in the IBN System is mapped to Intent Compliance Assessment in the Intent Life Cycle.¶
Policy Optimization in the IBN System is mapped to Intent Compliance Actions in the Intent Life Cycle.¶
Intent Report in the IBN System is mapped to Abstraction, Aggregation, and Reporting in the Intent Life Cycle.¶
In this section, we will describe several scenarios where IBN can be applied. These use cases can reflect the aforementioned methodologies of IBN systems from different perspectives.¶
IBN can be applied in building network path and generating routing policies according to network administrators' requests.¶
An intent-based dynamic SFC is an example to solve the network management challenges (e.g., cross-domain orchestration and service functions are tightly coupled with the underlying equipment). An Intent-Based Network Management (IBNM) platform can be developed on top of the OpenStack [OpenStack]. The system architecture is shown as Figure 1, which includes the application layer, the intent-enabled layer and the infrastructure layer. The application layer collects intents from various intent users and applications, and provides a number of programmable network management services to the users. The intent-enabled layer consists of the intent translation module, intelligent policy mapping module, and intent guarantee module, whose functions are to build a bridge between the application layer and the infrastructure layer. Heterogeneous physical devices are deployed in the infrastructure layer. This layer can execute management instructions from the intent-enabled layer and upload underlying network situation information to the intent-enabled layer. Information interaction between different layers is done through different interfaces, such as the northbound and southbound interfaces.¶
+----------------------------------------+
| Application Layer |
+-------------+---------^----------------+
Intent Input | | Northbound Interface
+-------------+---------v----------------+
| | Intent-Enabled Layer|
| +-----------+-------+ +-------------+ |
| | | | | Intent | |
| | +--------v----+ | | Reporting | |
| | | Translation | | | Module | |
| | +-------------+ | +-------------+ |
| | | |
| | +-------------+ | +-------------+ |
| | | Verification| | | Intent | |
| | +-------------+ | | Guarantee | |
| |Intent Translation | | Module | |
| | Module | +-------------+ |
| +-------------------+ |
| +-------------+ |
| +-------------------+ | Intent | |
| | Intent Policy | | Monitoring | |
| | Mapping Module | | Module | |
| +-------------------+ +-------------+ |
| |
+--------------------^-------------------+
| Southbound Interface
+--------------------v-------------------+
| Infrastructure Layer |
+----------------------------------------+
The system demonstration implements the whole process from intent input to intent translation to intent policy generation for intent deployment, and the details are as follows.¶
The user inputs an intention that is cross-domain link-building requests in a natural language at a web page. An exemplary intent is "Transfer a common-level video service from user A in Beijing to user B in Nanjing while constraining the execution time of the intent."¶
With the intention in the natural language, the intent translation module outputs a conflict-free translation result (e.g., intent), which indicates that the external intent input (called intention) and the intent translation module have communicated with each other. The translation result is intent tuples, which are displayed on the front-end interface (e.g., web interface) in the form of name-value pairs. After the intent translation module, the translation result will be converted to a JavaScript Object Notation (JSON) request (e.g., intent) and transmitted to the intent policy mapping module.¶
The intent policy mapping module translates the JSON request as an intent into policies as an SFC with appropriate Service Functions (SFs): service function 1 (e.g., network address translation) and service function 2 (e.g., firewall). It then constructs the SFC request (having name, tenant_id, description, service requirements, etc.). Then it queries whether there is an atomic policy combination that satisfies the current intent requirements in the policy repository or not.¶
Following that, an SFC is constructed based on the SFC interface, which is extended by Neutron. OpenStack schedules network resources, constructs subnets and ports, and generates a two-dimensional space topology. Meanwhile, during the SFC operation, the intent monitoring module collects monitoring data from the SFs and analyzes the data. This module delivers the analysis information to the intent guarantee module for intent assurance. The intent guarantee module makes intent assurance by comparing the requested intent and the operation results of the SFs in the SFC. It reconfigures the policies to satisfy the requested intent. It can also manage network resources for optimal resource utilization and handle network failures in real time.¶
The intent reporting module summarizes the activities of the SFC for corresponding to the requested intent and makes a report for the intent user. It then delivers the report to the intent user in the Application Layer, as shown in Figure 1.¶
Overall, IBNM achieves the decoupling of service application and network, and cross-domain network orchestration, while reducing the complexity of network management.¶
Segment Routing over IPv6 (SRv6) is a network programming framework to enable a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header [RFC8986]. Each instruction specifies an action on one or several nodes on a source routing path in a target network. It is identified by an SRv6 Segment Identifier in the packet. An SRv6 router is a network forwarding element that uses native IPv6 addresses and IP routing principles for traffic engineering without using Multiprotocol Label Switching (MPLS) [RFC3031].¶
For the automation of configuration and monitoring of SRv6 routers, an IBN-based SRv6 network management is proposed by [I-D.park-nmrg-ibn-network-management-srv6]. The proposed IBNM framework for SRv6 consists of system components and interfaces, as shown in Figure 2. This figure shows an IBNM framework for 5G core networks using SRv6. This framework is built on the framework for Interface to Network Security Functions (I2NSF) [RFC8329].¶
+-------------+ +-----------------------------+
| IBN User | | Global Distributed Database |
+-------------+ +-----------------------------+
^ ^
| Consumer-Facing Software Update |
| Interface Interface (Up) |
v v
+-------------------+ Registration +-----------------------+
| IBN Controller |<-------------------->|Developer's Mgmt System|
+-------------------+ Interface +-----------------------+
^ ^ ^
| | Software Update Interface |
| | (Down) |
| | Analytics Interface +----------------+ |
| +------------------------>| IBN Analyzer | |
| +----------------+ |
| NSF-Facing Interface ^ |
| | |
| +---------------------+ |
| | Monitoring Interface |
| | |
+---------+------------------+--------------------------------+----+
| v v SRv6 Nodes v |
| +-----------------+ +---------------+ +---------------+ |
| | NSF-1 |--| NSF-2 | ....... | NSF-n | |
| |(Network Exposure| |(Policy Control| | (Application | |
| | Function, NEF) | | Function, PCF)| | Function, AF)| |
| +-----------------+ +---------------+ +---------------+ |
+------------------------------------------------------------------+
A high-level network policy for SRv6 nodes (e.g., NSFs) is constructed by a Consumer-Facing Interface YANG data model. On the other hand, a low-level network policy is constructed by an NSF-Facing Interface YANG data model. A high-level network policy is delivered to IBN Controller by IBN User via the Consumer-Facing Interface. On the other hand, a low-level network policy is delivered to a Network Service Function (NSF) by IBN Controller via the NSF-Facing Interface.¶
To automate Network Policy Translation (NPT), IBN Controller needs a network policy translator performing the translation of a high-level network policy into the corresponding low-level network policy (i.e., SRv6 policy [RFC9256]). As a prerequisite step for this automatic NPT service, the IBN framework needs to associate a high-level YANG data model and a low-level YANG data model in an automatic manner, like a data model mapper [I-D.ietf-spring-sr-policy-yang], [SPT].¶
For the policy assurance, NSFs send their monitoring data to IBN Analyzer on the basis of either periods or events via Monitoring Interface. IBN Analyzer analyzes the NSF monitoring data by AI and ML algorithms to check whether NSFs are working appropriately according to a network policy (called an intent). IBN Analyzer sends a report with either policy reconfiguration or feedback to IBN Controller for further actions for the policy assurance. Optionally, IBN Controller sends a report to IBN User to report the network status and events for the IBN User's high-level policy (called intent).¶
The performance metrics for Service-Level Agreement (SLA) in a target network are packet loss, delay, jitter, throughput, etc. An IBN-based approach can ensure that these performance parameters comply with well-defined SLAs.¶
If we consider the delay, the simple schematic diagram is shown in Figure 3. Different thresholds (e.g., warning values and alert values) should be set for network delay measurement in advance. When the delay value is below warning, the network is normal and the business is normal. When the delay is between a warning value and an alert value, the network fluctuation is abnormal, but the business is normal. When the delay exceeds the alert value, both the network and business are abnormal. For the delay in different thresholds, different measurement strategies should be adopted:¶
When the network delay exceeds an alert value, or when the historical data predicts that the delay will exceed the alert value, passive measurement requires 100% sampling of business data, and the transmission frequency of active measurement is adjusted to the maximum value. At the same time, the log and alarm data of the whole network equipment are collected to realize the most fine-grained measurement of the network, locate the root cause of the problem, and repair the network in time. For this root cause analysis, collecting traces at the control plane of the network equipment is useful.¶
When the network delay exceeds a warning value but is lower than an alert value, passive measurement samples 60% of business data, and the transmission message frequency of the active measurement is adjusted to the median value, and the running state data of some key devices in the network is collected synchronously.¶
When the network delay is less than a warning value, passive measurement data is sampled at 20%, and active measurement message frequency is adjusted to the lowest value, and the network equipment running state of key nodes can be collected as needed.¶
^
Delay |
[ms] |
| XX
| X X Sampling Rate 100%
| XX X
alert +--------------------------------------------------------+
| X X Sampling Rate 60%
| X XX
| X X XX
| XX X X XXX
| XXX X X X X
| XX X X X X XX
| X XX X X XX XX X XX
warning +-------------------------------------------------------+
| X XX X XX X XX X XX XX
| XX X X X X XX XX X X
| XX X X X X X XX XXX X
| X XX XXX X XX X
| X XX XX X
| X XX Sampling Rate 20%
|
+----------------------------------------------------------->
0 Time [sec]
The desired approach is to accurately measure the network state, especially when there are some issues affecting the service, but at the same time, reduce the resources to be employed to achieve the desired accuracy.¶
The example of network delay has been provided, but the same approach can be applied to other performance indicators (e.g., packet loss, jitter, throughput, and goodput) as well.¶
On-path Telemetry Methods refers to performance measurement techniques that can provide flow information on the entire forwarding path on a per-packet basis in real time. Differently from the traditional active tools for Operations, Administration, and Maintenance (OAM), which inject test packets for measurements, the On-path Telemetry Methods (e.g., AltMark [RFC9341] and IOAM [RFC9197]) allow to monitor real service packets and thereby allow to directly measure network performance indicators from the live networks. Note that Alternate-Marking Method [RFC9341] (AltMark) and In-situ Operations, Administration, and Maintenance (IOAM) [RFC9197] are the standard On-path Telemetry Methods.¶
First, AltMark is a method used to perform packet loss, delay, and jitter measurements by marking in-flight packets according to the methodology described in [RFC9341] and [RFC9342]. Second, IOAM is a method that allows to produce operational and telemetry information that may be exported using either an in-band or out-of-band method. The data types and data formats for IOAM data records have been defined in [RFC9197] and [RFC9326].¶
With AltMark and IOAM, the real-time traffic monitoring of the network can be used to optimize the network performance. Figure 4 shows an exemplary traffic monitoring system with a high-level IBN workflow for dynamic network control based on traffic monitoring with On-path Telemetry Methods.¶
+-------------------------------------------+
| Controller |
| for IBN On-Path Telemetry |
+-------------------------------------------+
| ^
| |
v |
+-----------------+ +---------------+
| Intent | | Compliance |
| Acquisition | | Assessment |
+--------+--------+ +---------------+
| ^
| |
v |
+-------------------+ +-----------------+
| Configuration and | | Data Collection |
| Optimization | | and Analytics |
+-------------------+ +-----------------+
| ^
| |
v |
+---------------------------------------------+
| Network |
+---------------------------------------------+
In Figure 4, the Controller for IBN On-Path Telemetry configures the monitoring of the network according to a specific performance measurement intent. For this monitoring, either AltMark or IOAM can be used. Then it collects data and analytics from the selected methodology (e.g., AltMArk and IOAM) in order to verify the compliance with the intent.¶
An Intent Acquisition Module acquires an intent as an SLA request from a network administrator. The intent is a specific SLA request for a target network in terms of performance parameter values. The Intent Acquisition Module gives the intent to a Configuration-and-Optimization Module.¶
The Configuration-and-Optimization Module translates the intent into a network configuration and a measurement policy, such as network partition and a spatial accuracy needed for network monitoring. Both the network configuration and the measurement policy are deployed into network clusters (i.e., subnetworks) in the target network, having forwarding elements (e.g., routers and switches). For the configuration, the YANG Data Model for the Alternate Marking Method [I-D.ydt-ippm-alt-mark-yang] can be used.¶
A Data-Collection-and-Analytics Module collects measurement data from the different network clusters in the target network, and then validates the actual performance for each cluster against the required performance according to the intent. For the collection of the measurement data, the On-path Telemetry YANG Data Model [I-D.fz-ippm-on-path-telemetry-yang] or the IPFIX Alternate-Marking Information [I-D.ietf-opsawg-ipfix-alt-mark] can be used.¶
A Compliance Assessment Module checks whether the initial intent is met or not. When there is an outage in the network, the module notifies the Controller of a report about such an outage. The Controller forwards the report to the Configuration-and-Optimization Module so that the module can modify the network configuration by further investigation.¶
The Configuration-and-Optimization Module takes optimization actions that may be related to either network path modification or performance measurement variation for better performance. The module delivers the modified configuration and measurement policy to the network clusters.¶
The whole process in the On-path Telemetry Method is called as Intent-Based Closed-Loop Performance Management for Service-Level Agreement (SLA) in a customer network. Through the closed-loop measurement and control, a network problem can be localized with successive approximations using flow detailed analysis.¶
A Cloud-Based Security System (CBSS) is proposed in [CBSS][I-D.jeong-i2nsf-security-management-automation]. CBSS supports the Security Management Automation (SMA) of Cloud-Based Security Services with the framework of Interface to Network Security Functions (I2NSF) [RFC8329]. The security management automation deals with closed-loop security control, security policy translation, and security audit. To support these three features in SMA, an augmented architecture of the I2NSF framework is proposed by introducing new system components and new interfaces. A Network Security Function (NSF) is a system component in the I2NSF framework that provides a security service such as firewall, web filter, and Distributed-Denial-of-Service (DDoS) attack mitigator.¶
+------------+
| I2NSF User |
+------------+
^
| Consumer-Facing Interface
v
+-------------------+ Registration +-----------------------+
|Security Controller|<-------------------->|Developer's Mgmt System|
+-------------------+ Interface +-----------------------+
^ ^
| |
| | Analytics Interface +-----------------------+
| +------------------------>| I2NSF Analyzer |
| +-----------------------+
| NSF-Facing Interface ^ ^ ^
| | | |
| | | |
| +------------------------------+ | |
| | +-----------------------+ |
| | | Monitoring Interface |
+--------+----+--------------+-------------------------------+-------+
| v v v Network Security Functions v |
| +----------------+ +---------------+ +-----------------------+ |
| | NSF-1 |-| NSF-2 |...| NSF-n | |
| | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| |
| +----------------+ +---------------+ +-----------------------+ |
+--------------------------------------------------------------------+
Figure 5 shows an IBN-driven I2NSF framework for Security Management Automation (called SMA) of cloud-based security service management. I2NSF User composes a high-level security policy (as an intent) according to the I2NSF Consumer-Facing Interface YANG Data Model in [I-D.ietf-i2nsf-consumer-facing-interface-dm]. Note that I2NSF User may use a natural language for an intent to express a security service through an Intent translator [I-D.gu-nmrg-intent-translator][I2NSF-Intent-Translator] using Large Language Models (LLMs) [Flan-T5][GPT-3]. I2NSF User delivers the high-level security policy to Security Controller. Security Controller translates the high-level security policy into the corresponding low-level security policy according to the I2NSF NSF-Facing Interface YANG Data Model in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. The low-level security policy is understandable to Network Security Functions (called NSFs) for actual security services. Security Controller has a Security Policy Translator (SPT) for this security policy translation [SPT].¶
As shown in Figure 5, for closed-loop security control, this I2NSF framework has Monitoring Interface and Analytics Interface along with I2NSF Analyzer. I2NSF Analyzer collects monitoring data from NSFs via Monitoring Interface. It analyzes the monitoring data using Artificial Intelligence (AI) and Machine Learning (ML). I2NSF Analyzers delivers a policy reconfiguration message (e.g., defense against a new security attack) or feedback information message (e.g., action for handling overloaded computing and communication resources) to Security Controller. Security Controller receives the message and takes an appropriate action for the message, such as translating the message into a security policy reconfiguration for target NSFs and taking a remedy action for the feedback information.¶
Therefore, with a security policy translator and a closed-loop security control, we can provide service customers with IBN-based security services according to the intent life cycle in [RFC9315].¶
A Network Management Automation (NMA) can be provided for cellular network services in 5G networks [I-D.jeong-nmrg-ibn-network-management-automation]. This NMA is feasible on top of an IBN-empowered framework. It deals with a closed-loop network control, network intent translator, 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 networks [TS-23-501] such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X).¶
+------------+
| IBN User |
+------------+
^
| Consumer-Facing Interface (Intent)
v
+-------------------+ Registration +-----------------------+
| IBN Controller |<-------------------->| Vendor's Mgmt System |
+-------------------+ Interface +-----------------------+
^ ^
| |
| | Analytics Interface +-----------------------+
| +------------------------>| IBN Analyzer |
| +-----------------------+
| NSF-Facing Interface (Policy) ^ ^ ^
| | | |
| | | |
| +-------------------------------+ | |
| | +-----------------------+ |
| | | Monitoring Interface |
+--------+----+---------------+-------------------------------+---+
| v v v Network Service Functions v |
| +-----------------+ +-----------------+ +-----------------+ |
| | NSF-1 |-| NSF-2 |...| NSF-n | |
| |(Network Exposure| |(Policy Control | | (IoT Device) | |
| | Function: NEF) | | Function: PCF) | | | |
| +-----------------+ +-----------------+ +-----------------+ |
+-----------------------------------------------------------------+
Figure 6 shows an IBN framework for Network Management Automation in 5G networks. This framework is based on the I2NSF framework for cloud-based security services [RFC8329][I-D.jeong-i2nsf-security-management-automation]. Like the framework for Security Management Automation (called SMA) of cloud-based security services, this framework supports an intent translation with a Network Intent Translator (NIT) and a closed-loop control mechanism, it realizes an IBN-based IoT device management in 5G networks [TS-23-501].¶
For the closed-loop control mechanism, the IBN framework includes an IBN Analyzer that collects monitoring data from Network Service Functions (called NSFs) and analyzes the data to reconfigure its policies or generate new policies to meet the requested intent from the IBN User. The IBN Analyzer includes a Network Data Analytics Function (NWDAF) [TS-23-288] that collects and analyzes the monitoring data from 5G network functions such as a Policy Control Function (PCF), Session Management Function (SMF), Access and Mobility Management Function (AMF), and User Plane Function (UPF). The IBN Analyzer also includes an IoT Device Analyzer that collects and analyzes the monitoring data from IoT devices connected to a 5G Radio Access Network (RAN) [TS-38-300].¶
An intent is expressed with YAML [YAML] according to an intent specification in [TS-28-312]. The delivery protocol of an intent and a tranlsated policy can be REST API [REST].¶
Software-Defined Vehicle (SDV) is a vehicle whose functions and services are continuously updated and managed through software. There are software platforms for the SDV, such as AUTOSAR [AUTOSAR], Eclipse SDV [Eclipse-SDV], and COVESA [COVESA] to enable autonomous vehicles in Intelligent Transportation Systems (ITS). The SDV is constructed and maintained by the software platform with an internal network (e.g., a giga-bit Ethernet) interconnecting various sensors and Electronic Control Units (ECUs). The software platform may be implemented as a cloud-native system such as Kubernetes [Kubernetes], which is the de facto standard in the container orchestration system.¶
For facilitating the easy and efficient configuration of networks, security, and applications in the SDV'S in-vehicle networks, an intent-based management is required. An intent-based management framework for SDVs is proposed by [I-D.jeong-opsawg-intent-based-sdv-framework]. This framework lets SDVs be configured and monitored by a vehicular cloud in terms of networks, security, and applications in SDVs. In this framework, SDVs can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in ITS.¶
User Space : Translation / : Network Ops
Fulfill : IBS Space : Space
(SDV User) : (Vehicular Cloud) : (SDV)
+----------+ : +------------+ +------------+ : +-----------+
|Recognize/|---->| Translate/ |-->| Learn/ |-->| Configure/|
| Generate | : | Refine | | Plan/ | : | Provision |
| Intent |<----| | | Render | : | |
+----------+ : +------------+ +------------+ : +-----------+
^ : ^ : |
............|..................................|................|.......
| : +----------+ : v
Assure | : | Validate | : +----------+
| : +----^-----+<----| Monitor/ |
| : | : | Observe |
+--------+ : +----------+ +----------+<----| |
| Report |<-----| Abstract |<-----| Analyze/ | : +----------+
+--------+ : +----------+ | Aggregate| :
: +----------+ :
According to the intent life cycle of an Intent-Based System (IBS) in [RFC9315], as shown in Figure 7, the intent life cycle of the IBS for SDVs can be explained for SDV management as follows. The life cycle consists of three spaces: SDV User Space (i.e., an SDV system administrator's dashboard), Translation & IBS Space (i.e., Vehicular Cloud), and Network Operations (Ops) & Application (App) Space (i.e., SDV software platform). These spaces are divided into two phases in the life cycle space, such as fulfillment and assurance.¶
The fulfillment phase (denoted as “Fulfill”) pipelines the following steps for an intent enforcement: the reception of an intent from the SDV User; the translation/refinement of an intent by an intent translator in the Vehicular Cloud; the learning/planning/rendering for the corresponding policy in the Vehicular Cloud; the configuration/provisioning of the policy into target Service Functions (SFs) in the SDV, such as Network Functions (NFs) and Application Functions (AFs).¶
On the other hand, the assurance phase (denoted as “Assure”) performs the following steps: the collection of monitoring data from the NFs and AFs in the SDV; the analysis and aggregation of the monitoring data in the Vehicular Cloud; the policy validation and optimization in the Vehicular Cloud for closed-loop control to satisfy the given intent; the abstraction of the analysis and feedback in the Vehicular Cloud; the reporting of the operation results for the intent to the SDV User.¶
Note that if the policy validation and optimization modules find a problem, and an action for the problem is needed, these modules generate a reconfigured policy and send it to the relevant SF(s) in the SDV. In this case, these modules may generate a report with feedback information about the operation results in the SDV and send it to the SDV User so that the SDV User can take action on the report.¶
<Vehicular Cloud (VC)>
+---------------------------------------------------------------------+
| +------------------+ +--------------------+ |
| | SDV User | +---------->| SDV 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 +--------------------+ | |
| | SDV Controller |<-------------------->| SDV Vendor's | | |
| +------------------+ Interface | Mgmt System | | |
| ^ ^ +--------------------+ | |
| | | | |
| | | | |
| | | Analytics Interface +--------------------+ | |
| | +------------------------>| SDV Analyzer |<-+ |
| | +--------------------+ |
| | SF-Facing Interface ^ |
| | (Low-level Policy) | |
| | | |
| | +--------------+----------------------+---+ |
| | | | Monitoring Interface | |
| v v v v |
| +---------------+ +---------------+ +---------------+ |
| | SF-1 | | SF-2 |........| SF-n | |
| | (Router) | | (Firewall) | | (Navigator) | |
| +---------------+ +---------------+ +---------------+ |
+---------------------------------------------------------------------+
<Software-Defined Vehicle (SDV)>
Figure 8 shows a framework of intent-based management for SDVs. The framework consists of a vehicular cloud and SDVs. The two parts of Vehicular Cloud and SDV borrow the components and interfaces of the I2NSF framework in [RFC8329][I-D.jeong-i2nsf-security-management-automation] and customize their components and interfaces for IBN-based SDV management.¶
For simplicy, Vehicular Cloud can be treated as SDV User (i.e., network administrator) like I2NSF User in [RFC8329]. In this case, the SDV framework in Figure 8 is similar to the I2NSF framework in [RFC8329].¶
New network capabilities based on programmability and virtualization are producing service situations where a connectivity-only approach is not sufficient. The increasing availability of computing capabilities, which are either internal to the networks or attached to them, enables new scenarios where those capabilities can be consumed through the advertisement or exposure of these execution environments (i.e., compute, storage, and associated networking resources). In addition to that, even services or network functions could be advertised in order to make them available for interconnection.¶
Figure 9 captures the intent procedure for the fulfillment phase of the Interconnection Intent. Note that SLO, SLE, and SDP stand for “Service Level Objective”, “Service Level Expectation”, and “Service Demarcation Point”, respectively.¶
User Space : Translation / IBS : Network Ops
: Space : Space
: :
+----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision |
|intent |<--- | refine | | render | : | |
+----------+ : +----------+ +-----------+ : +-----------+
: :
........................................................................
Provider A : Provider B
---------- : ----------
:
- Select : - Mapping of intent types to : - Establishment
interconnection : protocols / APIs for : of protocol
intent type : coveying targeted resources : sessions or
- Specify targeted : - Parametrization of the : API requests
resources (e.g., : protocols / APIs, e.g., : to configure
routes, compute : leveraging data models : or provision
quotes, and service: : targeted
functions) : : resources
Similarly, Figure 10 sketches the intent procedure for the assurance phase of the Interconnection Intent.¶
: +--------+ :
: |validate| : +----------+
: +----^---+ <----| monitor/ |
Assure +-------+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+
: +---------+ :
........................................................................
Provider A : Provider B
---------- : ----------
:
- Analysis of the : - Checking of monitored data : - Collection of
reported metrics : for inner closed-loop to : telemetry
against the intent : ensure committed SLOs : information
request : : related to
- Trigger of actions : - Aggregation of data to : allocated
if needed, e.g., : produce an abstracted view : resources
new intent (outer : fitted to the intent request: (e.g., routes,
closed-loop) : : compute,
: : quotes, and
: : service
: : functions)
In Figure 9 and Figure 10, both Fulfillment and Assurance phases are integral parts of the Interconnection Intent, respectively, according to the intent life cycle in [RFC9315]. For the more detailed discussion on an intent-based interconnection framework, refer to [I-D.contreras-nmrg-interconnection-intents].¶
Network slicing is emerging as a future model for service offering in telecom operator networks. Conceptually, network slicing provides a customer with an apparent dedicated network which is built on top of logical (i.e., virtual) and/or physical functions and resources supported by a shared infrastructure. This infrastructure is provided by one or more telecom operators. As part of an End-to-End (E2E) network slice, it is expected to have a number of network slices at a transport level (referred as IETF network slices) providing the necessary connectivity to the rest of components of the E2E slice, e.g., mobile packet core slice.¶
With this respect, the GSMA [GSMA] has been developing a universal blueprint that can be used by any vertical customer to request the deployment of a Network Slice Instance (NSI) based on a specific set of service requirements. Such a blueprint is a network slice descriptor called Generic Slice Template (GST). The GST contains multiple attributes that can be used to characterize a network slice. A particular template filled with values generates a specific Network Slice Type (NEST).¶
The previous slice templates provide a number of parameters that functionally characterizes the behavior of the network slice as expected by the slice customer. However, apart from the slice characteristics, further information is needed in order to request the realization of a slice towards the IETF Network Slice Controller (NSC), such as the identification of the slice endpoints and information about the virtual network topology expected to form the requested IETF Network Slice.¶
Figure 11 captures the intent procedure for the fulfillment phase of the IETF Network Slice Service Intent. Note that NBI and SBI stand for “Northbound Interface” and “Southbound Interface”, respectively.¶
User Space : Translation / IBS : Network Ops
: Space : Space
: :
+----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision |
|intent |<--- | refine | | render | : | |
+----------+ : +----------+ +-----------+ : +-----------+
: :
........................................................................
Slice Customer : Slice Provider
-------------- : --------------
:
- Customized Slice : - Identification of IETF : - Slice request
Templates : network slice endpoints : to IETF NSC
- Service SLOs as : and connectivity patterns : by using slice
understood by : - Derivation of network SLOs : NBI YANG model
Slice Customer : and SLEs from high-level :
: Customer Service SLOs :
Similarly, Figure 12 sketches the intent procedure for the assurance phase of the IETF Network Slice Service Intent.¶
: +--------+ :
: |validate| : +----------+
: +----^---+ <----| monitor/ |
Assure +-------+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+
: +---------+ :
.....................................................................
Slice Customer : Slice Provider
-------------- : --------------
:
- Analysis of the : - Checking of monitored data : - Collection of
reported metrics : for inner closed-loop : monitoring
against the slice : to ensure committed SLOs and: information
request : SLEs : related to
- Trigger of actions : - Aggregation of data : the slice
if needed, e.g., : producing an abstracted view: (e.g., SLOs
slice modification : fitted to the slice request : and SLEs of
(outer closed-loop): : connectivity
: : constructs
: : and SDP)
In Figure 11 and Figure 12, both Fulfillment and Assurance phases are integral parts of the IETF Network Slice Service Intent, respectively, according to the intent life cycle in [RFC9315]. For the more detailed discussion on an intent-based network slice service framework along with those terms, refer to [I-D.contreras-nmrg-transport-slice-intent].¶
With the increasing need for sustainability in network services, Intent-Based Networking can be applied to enable customers to express green service objectives as network intents [I-D.contreras-nmrg-green-intent]. These intents allow customers to specify constraints and preferences related to energy consumption, carbon emissions, and the use of renewable energy in the provisioning and management of network services in the aspect of green networking [RFC9845].¶
The green service intent includes attributes such as:¶
Energy Consumption: Specifies maximum thresholds for total energy used by a network service.¶
Energy Efficiency: Specifies minimum thresholds for energy efficiency metrics (e.g., bits per Joule).¶
Carbon Emissions: Specifies limits on carbon intensity (grams CO2 per kWh) associated with the network service.¶
Use of Renewable Energy: Specifies minimum ratios of renewable energy sources powering the network functions for the network service.¶
These attributes can be specified individually or combined in a green intent, allowing flexible expression of sustainability goals.¶
For example, as an intent-drivement management service for mobile networks (e.g., 5G networks) [TS-28-312], an intent of green service management in a 5G Vehicular-to-Everything (V2X) service can be specified as follows:¶
In a Collision Avoidance Navigation Service for autonomous vehicles in 5G networks [CNP], let vehicular edge servers for the safe driving of vehicles operate in an energy-efficient fashion.¶
This intent can be translated to a policy such that an Access and Mobility Management Function (AMF) in the 5G core network lets vehicular edge servers for the safe driving of vehicles in an energy-efficient fashion. When a vehicular edge server has no adjacent vehicles for computing possible collisions and suggesting maneuver changes to them, let the vehicular edge server transit to a sleep state to save energy consumption.¶
Figure 13 captures the intent procedure for the fulfillment phase of the Green Intents.¶
User Space : Translation / IBS : Network Ops
: Space : Space
: :
+----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision |
|intent |<--- | refine | | render | : | |
+----------+ : +----------+ +-----------+ : +-----------+
: :
.......................................................................
Customer : Provider
---------- : ----------
:
- Generate a green : - Translation of attributes as: - Configuration
intent using one : constraints to check against: of the network
or more of the : pre-defined policies : according to
attributes in the: : policies
document : :
The process begins when the customer generates a green intent that specifies the desired sustainability and energy-efficiency objectives for the network service. This intent is then interpreted by the intent translation module, which converts the high-level green objectives into concrete network policies and constraints. Next, the policy mapping module enforces these constraints by selecting appropriate network resources and configurations that align with the green goals, for instance, routing packets or traffic flows through energy-efficient paths, leveraging equipment with lower carbon footprints, or prioritizing data centers powered by renewable energy. Finally, the configuration and provisioning module deploys these configurations across the network infrastructure to realize the intended green service objectives.¶
Similarly, Figure 14 sketches the intent procedure for the assurance phase of the Green Service Intent.¶
: +--------+ :
: |validate| : +----------+
: +----^---+ <----| monitor/ |
Assure +-------+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+
: +---------+ :
.....................................................................
Customer : Provider
---------- : ----------
:
- Analysis of the : - Checking of monitored data : - Collection of
reported metrics : for internal closed loops : green
against the intent: to ensure committed SLOs : networking
request : (inner closed loop) : metrics (e.g.,
- Trigger of actions: - Exposure of green data by : power
if needed (outer : APIs, e.g., an API for an : consumption)
closed loop) : energy traffic ratio for a : suitable for
: given path [I-D.petra-green: the intent
: -api] : attributes [I-D
: : .cx-green-green
: : -metrics]
In the case of assurance, the monitoring module continuously collects green networking metrics from various network elements; note that the green networking metrics include power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it [I-D.cx-green-green-metrics]. The gathered information is then analyzed by the analytics module. The validation module then evaluates the network's performance and checks compliance with the established green intent objectives based on the green networking metrics. If any discrepancies or deviations from the intended goals are detected by the validation module, the optimization module intervenes by adjusting network policies or reallocating resources to better align with the green objectives. In some cases, this process may also trigger a renegotiation or feedback loop with the customer to refine the intent or update the service parameters accordingly.¶
The green intents build upon the following two parts. The first part is the existing green networking metrics, such as power consumption, energy efficiency, and carbon footprint, which are associated with a network, its equipment, and the services that are provided over it [I-D.cx-green-green-metrics]. The second part is the standardized APIs for energy and carbon reporting, such as an API to query a network regarding its Energy Traffic Ratio for a given path [I-D.petra-green-api]. Within this framework, the system must effectively manage trade-offs between traditional Quality of Service (QoS) objectives and green goals, maintaining service reliability and performance while optimizing energy efficiency and reduced emissions. If there are conflicts between the QoS objectives and green goals, this framework can introduce a priority to each service and for low-priority services, prioritize the green goals over performance goals of those services.¶
Finally, the intent framework should incorporate negotiation and validation mechanisms, recognizing that network providers may only be able to partially fulfill green intents, which depend on their current infrastructure capabilities and operational policies.¶
This section analyzes how the IBN methodology is applied to each IBN use case in Section 3. Figure 15 shows a table for the IBN methodology analysis for IBN use cases in Section 3. In the table, C1 through C8 represent the construction numbers of IBN the construction of an IBN system in Section 2.2. The "X" in the table refers to a construction number supported by each IBN use case, such as C1: Intent Translation, C2: Policy Translation, C3: Policy Verification, C4: Policy Deployment, C5: Policy Monitoring, C6: Policy Validation, C7: Policy Optimization, and C8: Intent Report.¶
+=======+=============+========================+=======================+ |Section|Use Case |Construction Number | |Number | |C1|C2|C3|C4|C5|C6|C7|C8| +=======+======================================+==+==+==+==+==+==+==+==+ |3.1.1 |IBN for Service Function Chaining |X |X |X |X |X |X | | | +=======+======================================+==+==+==+==+==+==+==+==+ |3.1.2 |IBN for SRv6 Networks | |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.2 |IBN for Guaranteeing SLA | |X |X |X |X |X |X | | +=======+======================================+==+==+==+==+==+==+==+==+ |3.3 |IBN for Cloud-Based Security System | |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.4 |IBN for IoT Device Management in 5G | |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.5 |IBN for Software-Defined Vehicle |X |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.6 |IBN for Interconnection |X |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.7 |IBN for IETF Network Slices |X |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+ |3.8 |IBN for Green Service Management |X |X |X |X |X |X |X |X | +=======+======================================+==+==+==+==+==+==+==+==+
This section analyzes how the intent taxonomy in [RFC9316] can be applied to each use case in Section 3. Figure 16 shows a diagram of Intent Taxonomy for the IBN Methodology Analysis for IBN use cases in Section 3. In this diagram, an Intent has seven intent components as follows:¶
A: Intent Solution¶
B: Intent User Type¶
C: Intent Type¶
D: Intent Scope¶
E: Network Scope¶
F: Abstraction¶
G: Life Cycle¶
+---------------------------------------+
+-->|1: Carrier 2: Enterprise 3: Data Center|
| +---------------------------------------+
| +---------------------------------+
+----------+ | |1: Customer/Subscriber/End User |
+>+A: Intent +--+ |2: Network or Service Operator |
| |Solution | |3: Application Developer |
| +----------+ +->|4: Enterprise Administrator |
| | |5: Cloud Administrator |
| +----------+ | |6: Underlay Network Administrator|
+>+B: Intent +---+ +---------------------------------+
| |User | +-----------------------------------+
| |Type | |1: Customer Service Intent |
| +----------+ |2: Strategy Intent |
| +----------+ |3: Network Service Intent |
+>+C: Intent +----->|4: Underlay Network Service Intent |
+------+ | |Type | |5: Network Intent |
|Intent+-+ +----------+ |6: Underlay Network Intent |
+------+ | |7: Operational Task Intent |
| +----------+ |8: Cloud Management Intent |
+>+D: Intent +---+ |9: Cloud Resource Management Intent|
| |Scope | | +-----------------------------------+
| +----------+ | +-----------------------------------------+
| +->|1: Connectivity 2: Application 3: QoS |
| +----------+ |4: Security/Privacy 5: Storage 6: Compute|
+>+E: Network+---+ +-----------------------------------------+
| |Scope | | +-----------------------------------+
| +----------+ | |1: Radio Access 2: Branch |
| +->|3: Transport Access 4: SD-WAN |
| +----------+ |5: Transport Aggr. 6: VNF 7: PNF|
+>+F: Abstra-+----+ |8: Transport Core 9: Physical|
| |ction | | |10: Cloud Edge 11: Logical |
| +----------+ | |12: Cloud Core 13: Campus |
| +----------+ | +-----------------------------------+
+>+G: Life | | +-------------------------------------+
|Cycle +--+ +>|1: Technical 2: Non-Technical|
+----------+ | +-------------------------------------+
| +-------------------------------------+
+-->|1: Persistent 2: Transient |
+-------------------------------------+
For the use cases in Section 3, Figure 17 shows a table for the Intent Taxonomy Analysis by [RFC9316]. The "Xi" in the table refers to a value "i" (defined in Figure 16) for an intent component "X" in [RFC9316]. For example, in Figure 17, "IBN for Service Function Chaining" in Section 3.1.1 has the following intent taxonomy:¶
A: Intent Solution => A1: Carrier¶
B: Intent User Type => B2: Network or Service Operator¶
C: Intent Type => C3: Network Service Intent¶
D: Intent Scope => D2: Application¶
E: Network Scope => E4: SD-WAN¶
F: Abstraction => F1: Technical¶
G: Life Cycle => G1: Persistent¶
For the other use cases in Figure 17, the intent taxonomy per use case can be interpreted in the same way with the above use case of "IBN for Service Function Chaining".¶
+=======+=============+========================+====================+ |Section|Use Case |Intent Taxonomy | |Number | |A |B |C |D |E |F |G | +=======+======================================+==+==+==+==+==+==+==+ |3.1.1 |IBN for Service Function Chaining |1 |2 |3 |2 |4 |1 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.1.2 |IBN for SRv6 Networks |1 |6 |6 |1 |8 |1 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.2 |IBN for Guaranteeing SLA |2 |4 |5 |3 |4 |1 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.3 |IBN for Cloud-Based Security System |2 |4 |3 |4 |10|2 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.4 |IBN for IoT Device Management in 5G |2 |1 |1 |2 |6 |2 |2 | +=======+======================================+==+==+==+==+==+==+==+ |3.5 |IBN for Software-Defined Vehicle |2 |3 |1 |2 |6 |2 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.6 |IBN for Interconnection |1 |2 |3 |2 |3 |1 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.7 |IBN for IETF Network Slices |1 |6 |6 |3 |4 |1 |1 | +=======+======================================+==+==+==+==+==+==+==+ |3.8 |IBN for Green Service Management |2 |1 |1 |2 |9 |2 |1 | +=======+======================================+==+==+==+==+==+==+==+
Some key learnings and takeaways can be extracted from the practices and implementation of IBN systems in different use cases. Commonly, there involve the following technical challenges in building an IBN system, including the handling of the dynamic and time variant nature of the network, the efficient management of cross-domain resources, and the reliability of automatic configuration.¶
First, Service Function Chaining (called SFC) in Section 3.1.1 showed the following three challenges:¶
Stability in Dynamic Network Environments: For instance, in the space-terrestrial networks where the network topology is with frequent changes, it is essential to design efficient service function chain reconstruction and service recovery mechanisms. But how to guarantee the effectiveness of the chaining rule in these scenarios is still a challenge.¶
Collaborative Management of Cross-Domain SFC: To ensure the network intents across multi-domain networks, intent-based networks should be designed with a cross-domain orchestration and management framework to ensure an E2E optimization of Quality of Service (called QoS).¶
Deployment under Resource-Constrained Conditions: It is important to consider how to effectively deploy and manage these service function chains within limited resources. Methods such as intent negotiation can be introduced to optimize resource allocation in the SFC.¶
Second, Cloud-Based Security System (called CBSS) in Section 3.3 showed the following three challenges:¶
Security Intent Translation: A natural-language security intent needs to be translated into a high-level security policy according to the I2NSF Consumer-Facing YANG Data Model [I-D.ietf-i2nsf-consumer-facing-interface-dm]. This intent translator should use the syntax of the YANG data model even where a train dataset with security policies is small [I-D.gu-nmrg-intent-translator]. To detect a hallucinated high-level security policy, the generated policy is double checked against the syntax of this YANG data model [I2NSF-Intent-Translator]. The intent can also be ambiguous or incomplete. In this case, the intent translator needs to detect this and prompt the user to clarify or complete the intent in a human-in-the-loop [HITL].¶
Security Policy Conflict Handling: A new security policy can conflict with an existing security policy, so the new security policy can be overlapped with the existing security policy or contradict with the existing security policy, which may invalidate the effect of the existing security policy. There are four kinds of security policy conflicts in [Security-Misconfiguration] such as Shadowing Conflict, Correlation Conflict, Redundancy Conflict, and Generalization Conflict. These conflicts should be resolved after an intent is translated into a high-level security policy.¶
Dynamic Security Policy Enforcement: It takes time to detect whether a traffic flow is related to a security attack or not. For a certain time period, a malicious traffic flow needs to be observed to see whether it has a negative impact on a target network. According to the severity of the impact of a traffic flow, the treatment of the traffic flow at network forwarding elements (e.g., router and switch) should be adapted dynamically and proactively by an adaptive decision-making (e.g., partial packet dropping and rerouting) in Security Controller in the I2NSF framework [ICSC].¶
Although there have been extensive research achievements from academic, industrial, and standardization fields, there are the following three future research considerations.¶
Generic Intent model for Full Life-Cycle Assurance: It is necessary to construct an intent model for the full life-cycle from both top-to-down and down-to-top perspectives, including the intent input state, the intent execution state, and the intent completion state, etc, merged in a generic logic model. It makes sense of ensuring the E2E guaranteed implementation of any network intent and verifying the intent state through consistent mathematical logic.¶
Autonomous End-to-End Network Policy Generation: An intent-based network should provide the network configuration policies to always well understand the requested network services in time, in particular towards various dynamic on-demand service requirements. Therefore, the intent-based network should make the network QoS satisfy the users’ Quality of Experience (QoE) from a vertical perspective of a network protocol or different intent holders. Meanwhile, the current network is based on domain-specific local policy optimization, and it is hard to ensure an E2E QoS guarantee, in particular a cross-domain global optimization. Therefore, the intent-based network should provide an E2E optimization policies across multi-domain networking applications.¶
Intent Implementation with LLMs: The LLMs such as Flan-T5 [Flan-T5] and GPT-3 [GPT-3] will play an important role in enhancing the accuracy of intent refinement, resulting from the powerful understanding capabilities of the LLMs and the entity relationships in knowledge graphs [Knowledge-Graph]. It is also beneficial to network policy generation according to the network status. Although we have involved different kinds of AI models at each intent-based network’ stage, there still exists the lack of generality and accuracy. Meanwhile, human interference is still in the full life-cycle of the intent-based network as a human-in-the-loop [HITL], and in the future the knowledge graph-assisted LLMs can further reduce such human intervention, and aims at making the human completely be out of the full life-cycle of the intent-based network. However, due to the probabilistic nature of the LLMs and the risk of hallucinations and other interpretation errors, ensuring trust in AI-driven network management remains a key challenge. Therefore, developing trustworthy LLMs with explainability as eXplainable AI (XAI) [XAI] is an important research direction.¶
This section discusses three aspects for the deployment of IBN systems on the real world. They are Multi-Domain Deployment, Network Digital Twin, and IBN with AI.¶
IBN shows two different aspects and relations with multi-domain concepts such as multi-domain intents and multi-domain intent resolution.¶
Some network intents involve multiple domains. They can be explicit, especially when being expressed in a natural language, or implicit. The resolution of the former is generally straightforward. Probably a mapping is required to let the intent resolution system, e.g., one following the specification in [I-D.pedro-ite], to know the real identity of the domain mentioned in the intent.¶
On the other hand, the resolution of the implicit domains in network intents requires a much larger and consistent structure and mapping functions. They must be able to determine the involvement of multiple domains, and the reason must be clearly stated in the structures. For instance, if the network intent is resolved into a network service that involves a security function and the security function is only available at a different domain to the domain that is resolving the intent, the involvement of multiple domains is justified. Similarly, other scenarios must provide justifications for involving multiple domains implicitly.¶
Regardless of a network intent being single-domain or multi-domain in Section 5.1.1, a network intent can be resolved by a standalone system, i.e., doing single-domain intent resolution, or by multiple interconnected systems, i.e., doing multi-domain intent resolution.¶
Involving multiple domains in the resolution of an intent has many benefits, such as using bigger knowledge bases and bigger network function structures. This is particularly beneficial for multi-domain intents. However, it also means that network management systems must consider additional security concerns and general domain information borders and policies for its transmission. This is being actively researched, but results are still early to say that a consistent multi-domain system can be built for network intent resolution.¶
As described in [I-D.irtf-nmrg-network-digital-twin-arch], the Network Digital Twin (NDT) can be an important enabler platform for implementing IBN systems and fostering their deployment. A user gives his (or her) intent to the network system with NDT. Through the closed-loop control with monitoring, validation, and adjustment in NDT, the IBN-based network management will be effectively performed with a minimum trial and error in the real networks. For more details on IBN interaction with Network Digital Twin, refer to Section 10 of [I-D.irtf-nmrg-network-digital-twin-arch].¶
This section proposes some discussions on IBN with AI. AI techniques have been integrated by IBN, but there is still much space in researching on topics related to IBN with AI, such as different learning patterns, AI agents, and agentic AI.¶
[I-D.cgfabk-nmrg-ibn-generative-ai] describes how transfer learning techniques can be adopted to design generative AI specialized models for IBN.¶
IBN represents a paradigm shift in network management, aiming to bridge the gap between business objectives and network configurations. IBN allows operators to specify high-level intents, which the system then automatically translates, enforces, and continuously validates. Generative AI, particularly Large Language Models (LLMs), can enhance IBN by automating intent parsing, policy generation, and network troubleshooting. LLMs can understand natural language intents, generate high-level policies, and adapt the policies in real time. Transfer learning enables pretrained models to adapt to specific tasks with significantly less data and computational resources. In the context of IBN, this approach offers a dual advantage: (i) enhancing the efficiency of model training and (ii) improving the reliability of intent recognition and execution.¶
In the future, IBN will be closely intertwined with AI Agents and Multi-Agent systems. Multi-Agent systems, equipped with capabilities of distributed perception, collaborative decision-making, and autonomous execution, will serve as the core technical engine for IBN to achieve full-process automation. For example, the Confucius framework in [Confucius] has proven that multi-agent collaboration can improve the accuracy of network management tasks by over 34%.¶
The core research issues in the integration of the IBN with AI focus on three dimensions as follows:¶
Accurate translation and decomposition of intents: This dimension considers the accuracy of intent translation. It needs to resolve the ambiguity of intents expressed in a natural language.¶
Collaboration and management of multi-agents: This dimension considers network scalability. As the network scale expands, the increase in the number of agents leads to issues such as decision consistency and resource competition. Additionally, it is necessary to handle the reasonable decomposition and dependency management of complex tasks among multiple agents.¶
System reliability and security: This dimension considers the stability and cybersecurity. This not only includes the logical verification of instructions generated by AI Agents (e.g., Domain-Specific Language (DSL) syntax compliance) but also involves issues such as data privacy protection, malicious behavior identification, and Byzantine fault tolerance in agent interactions. Note that the Byzantine fault tolerance allows the IBN systems to keep operating correctly or reach right consensus even if some components of the IBN systmes are malicious or faulty.¶
Potential research directions and technologies can be as follows:¶
Enhanced intent understanding: It optimizes intent parsing by combining domain knowledge graphs [Knowledge-Graph] and Retrieval-Augmented Generation (RAG) [RAG]. It can realize simulation verification and preview of intents (e.g., What-If analysis) through digital twins.¶
Efficient multi-agent collaborative architectures: It adopts a hierarchical agent design to reduce cross-layer communication overhead. Federated learning may enable dynamic task scheduling and parallel execution while protecting local data in each agent.¶
Trusted agent technologies: It includes a multi-layer verification mechanism of “agent pre-verification” and “manual approval” and also abnormal behavior detection algorithms based on traffic fingerprints.¶
Performance acceleration and resource optimization technologies: It matches the computing power needs of agents with network loads through dynamic resource scheduling algorithms to improve the operational efficiency of the IBN systems.¶
There are many considerations on security. First, the IBN systems should be strong and resilient against variable security attacks from outsider attacks (e.g., Distributed-Denial-of-Service (DDoS) attacks and virus) and to insider attacks (e.g., supply chain attacks).¶
A malicious intent can break down the whole IBN system if the analysis of each intent for the impact on the IBN system is not performed appropriately on time. Thus, the IBN defense system should execute both the security check for an intent during the Fulfillment Phase and the attack monitoring during the Assurance Phase. Such security check and attack monitoring need to be performed by the collaboration between AI agents and network administrators.¶
The security for SDVs is tightly associated with the safety of drivers and passengers in the SDVs. The SDVs compromised by a hacker may malfunction and lead to road accidents. Thus, the IBN for SDVs needs more robust defense against various cybersecurity attacks than the IBN for other domains. An SDV security defense system includes authentication and authorization of an intent issuer (e.g., SDV User), the validation of an intent prior to policy enforcement, and the prediction of the possible results by the policy enforcement. These security considerations for the SDVs can also be beneficial to the IBN systems for other domains.¶
For the safety of SDVs, the following are considered for the IBN for SDVs: rollback or recovery mechanisms for the events of operations drifting from a user's intent, failure-safe operations for a policy translated from an intent, and the handling of overloaded service functions. These safety considerations for the SDVs can also be applied to the IBN systems for other domains.¶
This document has no requests to IANA.¶
This document is a product of the NMRG including the RG Chairs (Jeferson Campos Nobre and Jerome Francois). This document benefitted from the review and comments from the following people: Abdelkader Mekrache, Byoungman Robert An, and Yong-Geun Hong. The authors sincerely appreciate their sincere efforts and kind help.¶
The work of Jaehoon Paul Jeong was supported by the Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea government, Ministry of Science and ICT (MSIT) (No. RS-2024-00398199 and No. RS-2022-II221015).¶
The work of Luis M. Contreras was supported in part by the European Union under Horizon Europe projects NEMO (NExt generation Meta Operating system) grant number 101070118, and SNS 6Green (Green Technologies For 5/6G Service-Based Architectures) grant agreement 101096925.¶
The following people have substantially contributed to this document as co-authors:¶
The following changes are made from draft-irtf-nmrg-ibn-usecases-03:¶
This version have addressed the main comments from external reviwers such as Abdelkader Mekrache, Yong-Geun Hong, and Byoungman Robert An.¶