| Internet-Draft | Network Working Group | October 2024 |
| Yao, et al. | Expires 24 April 2025 | [Page] |
This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learning and general learning are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques.¶
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 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[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 injestion, intent translation, policy generation, and intent assurance, there is still a big gap between defining these high-level functionality and building realistic IBN systems. This document summarizes the methodologies, proposes several IBN use cases, 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 the methodologies to build an IBN system. These methodologies refer 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 methodologies are essential to build a real IBN system, beyond the definition in [RFC9315]. The methodologies to an IBN system are composed of several important parts, including the system awareness and data collection, the construction of an IBN system, integration and deployment, evaluation, optimization, and the reconfiguration of intents and policies.¶
System awareness requires the collection of various network status indicators, like network traffic and resources. Building a valuable dataset is essential for IBN systems. A comprehensive data collection depends on suitable methods and tools, appropriate sampling metrics, and reasonable granularity for data collection.¶
Methods and Tools¶
There are many existing ways to collect network data which can be primarily classified into two types, active measurement and passive measurement. Active measurement like In-band Network Telemetry (INT) can grab networking information by inserting timestamps into the programmable field of on-path packets. Passive measurement, on the other hand, uses some tools like Tcpdump or Wireshark to collect data at specific targets, like endpoint servers. IBN systems need both of the ways to collect data, depending on what scenarios they might be applied to.¶
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, IBN systems need to collect and process traffic and device related information.¶
Granularity¶
Network Traffic: Network traffic is usually collected in various forms, such as per-packet and per-flow [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. 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. Other collection methods are like per-cell and per-flowlet [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.¶
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 the 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 system. 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 trade-offs 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.¶
In the construction of an IBN system, intent translation module, policy generation and mapping module, and intent verification module play an important role. The different construction methods and different construction tools used in these modules may affect the advantages of realizing the intention. For different modules, we summarize 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.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 BERT [BERT], for intent translation is another possible approach. First, NLP is used to convert a user's intent in a human language (e.g., English) into a text intent in a computer programming language (e.g., XML and JSON), and then the key parameters of text intent are extracted to form the corresponding intent expression. The advantage of this method is high flexibility, users can directly express their intentions 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 users, and different intents expression paradigms will affect the generation of subsequent policies. Thus, it is necessary to formalize normative intent expression grammars.¶
On the basis of the above natural language-based approach, with the development of AI technologies such as deep learning in the field of text processing, key information in sentences can be extracted by an AI model-based detection scheme. Therefore, based on different AI models, the translation method of category detection and key information extraction of intent representation statements is another approach to intent translation. The advantage of this method is that the expression of the user's intention is more flexible, and the real intention of the user can be mined to a certain extent. The disadvantage is the deployment cost. Selecting an appropriate AI model to complete the model training is costly.¶
In addition, there are some preset expression languages for IBN networks, such as Nile and NEMO. In the design of these language expressions, most of them consider the flexibility of expression, which can be extended and adjusted according to the intention scenario of the business under consideration. However, these language designs have some disadvantages (e.g., the capability of intent expression). Most of the users are network practitioners, requiring users to have certain network knowledge background.¶
Policy Generation and Mapping¶
In the intent-based network, the generation of the corresponding network policy for a given input intent needs to consider both the intent and the network state, that is, the policy needs to satisfy the user's intent and ensure that the network 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 new 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. Similar to different ways of expressing an intent, there are different approaches for policy generation and mapping.¶
As opposed to the default template-based representation in the intent representation module, the simplest approach to policy generation is based on a default template or rule-based provisioning. After the user completes the corresponding intention expression through the graphical interface (e.g., a web-based graphical user interface (GUI)), the user can select the corresponding policy according to the preset template in the policy generation and matching a module or associate the corresponding rules in the 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 generation and mapping is inference-based generation, such as reasoning based on keywords in an intention 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 strategy generation methods have also emerged in recent years, such as machine learning technology, which selects corresponding strategies through model training according to keywords extracted from an intention expression. With the development of AI technology, in addition to selecting preset strategies, for example, based on Deep Reinforcement Learning [DRL], reasonable reward functions are set to generate strategies that consider user intentions and network status.¶
Intent Verification¶
Intent verification includes intent conflict detection and checking whether intents meet a specific user's requirements or not.¶
The intent conflict detection includes two types: the conflicts between different intents themselves and the conflicts between policies and network states of the target network to perform the requested intent. The conflict of intents 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 checking whether the intents can be deployed in practice, that is, you can choose to execute only the intents that can be executed according to the preset rules, and reject other intents. 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. If the generated policy cannot be executed, the policy needs to be re-generated. Otherwise, the policy generation of the intent should be reported to the intent user as a failure.¶
In terms of whether the user's intent 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 AI methods such as deep reinforcement learning [DRL] to determine whether the results meet the needs or not.¶
Intent Deployment¶
Intent Deployment is to deploy the policy translated from an intent into a target network and let the configurations or commands for the policy operate in the network.¶
The intent translator delivers a policy with detailed configurations or commands to an intent renderer which deploys the policy into target network entities (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator).¶
The intent 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.¶
Monitoring¶
Monitoring is to collect monitoring data from network entities (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator) for intent validation to judge whether the requested intent is enforced well or not in the target network.¶
Validation¶
Validation is to judge whether the requested intent is satisfied by network entities in a target network or not. The intent is translated into a policy with detailed configurations or commands by an intent translator. The policy may have goals in terms of performance (e.g., throughput and delay) and services (e.g., firewall, web filter, and DDoS-attak mitigator).¶
A validation entity (e.g., analyzer) uses the collected monitoring data for evaluation and check whether the required goals for each intent 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 entity (e.g., optimizer) which can augment the existing policy or generate a new policy for further improvement.¶
Optimization¶
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 and delay). 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 intent renderer so that the renderer can enforce the augmented or generated policy into the target network entities.¶
Thus, the steps from Intent Deployment to Optimization construct a closed-loop intent control to guarantee the goals of the requested intent in a target network. This is network service automation using the IBN technology.¶
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 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|
| +-----------+-------+ +-------------+ |
| | | | | | |
| | +--------v----+ | | | |
| | | Translation | | | | |
| | +-------------+ | | | |
| | | | Intelligent | |
| | +-------------+ | | | |
| | | Verification| | | Guarantee | |
| | +-------------+ | | | |
| |Intent Translation | | Module | |
| | Module | | | |
| +-------------------+ | | |
| | | |
| +-------------------+ | | |
| |Intelligent Policy | | | |
| | Mapping 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 cross-domain link-building requests (intent) 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."¶
The intent translation module outputs a conflict-free translation result (e.g., intent), which indicates that the external input and the translation platform have been communicated. The translation results are 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 results will be converted to a JavaScript Object Notation (JSON) request (e.g., policy) and transmitted to the intelligent policy mapping module.¶
The intelligent policy mapping module divides the JSON request into an SFC: 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.¶
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 two-dimensional space topology. Meanwhile, during the SFC construction process, the intent guarantee module monitors and manages network resource utilization as well as network failures in real time.¶
Overall, IBNM achieves the decoupling of service application and network, and cross-domain network orchestration, while reducing the complexity of network management.¶
For the automation of configuration and monitoring of Segment Routing version six (SRv6) routers, an IBN-based secure network management is proposed by [I-D.park-nmrg-ibn-network-management-srv6]. The proposed Intent-Based Network Management (IBNM) framework consists of system components and interfaces, as shown in Figure 2. 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 |<-------------------->| Vendor'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 routers is constructed by the IBN Consumer-Facing Interface YANG data model. On the other hand, a low-level network policy is constructed by the IBN NSF-Facing Interface YANG data model.¶
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]). 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].¶
The performance metrics for Service-Level Agreement (SLA) in a target network are packet loss, delay, 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, 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 warning value and 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 the 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 is collected to realize the most fine-grained measurement of the network, locate the root cause of the problem, and repair the network in time.¶
When the network delay exceeds warning value but is lower than 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 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) as well.¶
The 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 OAM tools, which inject test packets for measurements, the On-path Telemetry methods (AltMark and IOAM) allow to monitor real service packets and thereby allowing to directly measure network performance indicators from the live network.¶
Alternate-Marking Method RFC 9341 [RFC9341] (AltMark) and In-situ Operations, Administration, and Maintenance (IOAM) RFC 9197 [RFC9197] are the standard On-path Telemetry methods. AltMark is a technique used to perform packet loss, delay, and jitter measurements by marking in-flight packets according to the methodology described in RFC 9341 [RFC9341] and RFC 9342 [RFC9342]. IOAM is a method that allows to produce operational and telemetry information that may be exported using the in-band or out-of-band method. The data types and data formats for IOAM data records have been defined in RFC 9197 [RFC9197] RFC 9326 [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 example of a high-level IBN workflow for dynamic network control based on traffic monitoring with On-Path Telemetry Methods.¶
+-------------------------------------------+
| IBN On-Path Telemetry |
| Orchestration and Controller |
+-------------------------------------------+
| ^
| |
v |
+-----------------+ +---------------+
| Intent | | Compliance |
| Acquisition | | Assessment |
+--------+--------+ +---------------+
| ^
| |
v |
+-------------------+ +-----------------+
| Configuration and | | Data Collection |
| Optimization | | and Analytics |
+-------------------+ +-----------------+
| ^
| |
v |
+---------------------------------------------+
| Network |
+---------------------------------------------+
The Controller configures the monitoring of the network according to the specific performance measurement intent. AltMark or IOAM can be used. Then it collects data and analytics from the selected methodology (AltMArk or IOAM) in order to verify the compliance with the intent. Optimization actions can be eventually taken and can be related to network path modification or performance measurements variation.¶
The next section describes an example of the workflow for IBN based On-path Telemetry focusing on the use of RFC 9342 [RFC9342].¶
The Clustered Alternate-Marking framework RFC 9342 [RFC9342] adds flexibility to RFC 9341 [RFC9341] performance measurements, because it can reduce the order of magnitude of the packet counters. This allows the Orchestration and the Controller to supervise, control, and manage AltMark measurements in large networks.¶
RFC 9342 [RFC9342] introduces the concept of cluster partition of a network. The monitored network can be considered as a whole or split into clusters that are the smallest subnetworks (e.g., group-to-group segments), maintaining the packet loss property for each subnetwork. The clusters can be combined in new connected subnetworks at different levels, which can form new clusters, depending on the level of detail to achieve.¶
A clustered performance measurement intent represents the spatial accuracy, that is, the size of the subnetworks to consider for the monitoring. It is possible to start the monitoring without examining in depth and, in case of necessity, the "network zooming" approach can be used.¶
This approach is called "network zooming" and can be performed in two different ways:¶
change the traffic filter and select more detailed flows;¶
activate new measurement points by defining more specified clusters.¶
The network-zooming approach implies that some filters, rules or flow identifiers are changed. But these changes must be done in a way that do not affect the performance. Therefore there could be a transient time to wait once the new network configuration takes effect. Anyway, if the performance issue is relevant, it is likely to last for a time much longer than the transient time.¶
The concrete steps of the clustered performance measurement intent are as follows:¶
The performance measurement intent acquisition is initially recognized. For example, the intent can be a specific SLA for the network in terms of performance parameter values. Then, the performance measurement intent is analyzed and it is translated into specific configurations and measurement policy, such as network partition and the spatial accuracy needed for the monitoring.¶
The configuration and optimization step arranges and calibrates the measurement with the specific configuration according to the measurement policy in order to split the whole network into clusters at different levels. Note that, for the configuration, the YANG Data Model for the Alternate Marking Method [I-D.ydt-ippm-alt-mark-yang] can be used.¶
The data collection and analytics step gets the measurement data from the different clusters, and then verifies the performance for each cluster. Note that, 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.¶
The compliance assessment checks whether the initial intent is met or not, that is, for example, if a cluster is experiencing a packet loss or the delay is higher than the expected value. In this case, the Orchestration and Controller is notified of such an outage in order to modify the cluster partition of the network for further investigation. The network configuration can be immediately modified in order to perform a new partition of the network but only for the cluster with bad performance. In this way, the problem can be localized with successive approximation up to a flow detailed analysis. This is the so-called "closed-loop" performance management in the IBN.¶
A Cloud-Based Security Service Management is proposed in [I-D.jeong-i2nsf-security-management-automation]. It describes Security Management Automation (SMA) of cloud-based security services in 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.¶
+------------+
| 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 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) and delivers it to Security Controller. Security Controller translates the high-level security policy into the corresponding low-level security policy that is understandable to Network Security Functions (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 re-configuration 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 re-configuration 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 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 (NWDAF) |
| +-----------------------+
| NSF-Facing Interface (Policy) ^ ^ ^
| | | |
| | | |
| +------------------------------+ | |
| | +-----------------------+ |
| | | Monitoring Interface |
v v v v
+---------------+ +---------------+ +---------------+
| NSF-1 |--| NSF-2 |........| NSF-n |
|(Net 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.¶
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 an electrical vehicle with a software platform (e.g., AUTOSAR and Eclipse SDV) towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform having a cloud-native system (e.g., Kubernetes) and has its internal network (e.g., a giga-bit Ethernet). 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.¶
SDV User : Translation/ : Network Ops/
Space : IBS Space : App Space
Fulfill : :
+----------+ : +------------+ +------------+ : +-----------+
|Recognize/|---->| Translate/ |-->| Learn/ |-->| Configure/|
| Generate | : | Refine | | Plan/ | : | Provision |
| Intent |<----| | | Render | : | |
+----------+ : +------------+ +------------+ : +-----------+
^ : ^ : |
............|..................................|................|.....
| : +----------+ : v
| : | Validate | : +----------+
| : +----^-----+<----| Monitor/ |
Assure | : | : | Observe |
+--------+ : +----------+ +----------+<----| |
| Report |<-----| Abstract |<-----| Analyze/ | : +----------+
+--------+ : +----------+ | Aggregate| :
: +----------+ :
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 enforced for SDV management. The life cycle consists of three spaces, namely SDV User Space, Translation & IBS Space, and Network Operations (Ops) & Application (App) Space. These spaces are divided into two sections in the life cycle space, such as fulfillment and assurance. The fulfillment section (denoted as "Fuilfill") pipelines the steps for an intent enforcement, such as intent input, translation/refinement, learning/planning/rendering, and configuration/provisioning toward the final SFs (e.g., network functions (NFs) and applications in SDVs). On the other hand, the assurance section (denoted as "Assure") performs the steps for an intent validation and optimization by collecting final results of the intent fulfillment from the NFs and applications for SDVs. If an action for the found problem is needed, the life cycle inserts a reconfigured policy or feedback information into the fulfillment section or report a required action to SDV User.¶
<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 internal to the networks, or attached to them, enable new scenarios where those capabilities can be consumed through the advertisement or exposure of these execution environments (i.e., in terms of compute, storage and associated networking resources). In addition or complementary 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.¶
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 of
interconnection : protocols / APIs for : protocol sessions
intent type : coveying targeted resources : or API requests
- Specify targeted : - Parametrization of the : for configure or
resources (e.g., : protocols / APIs, e.g., : provision
routes, compute : leveraging data models : targeted resources
quotes, and service: :
functions) : :
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 (e.g.,
new intent (outer : fitted to the intent request: routes, compute,
closed-loop) : : 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.¶
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 the
- Trigger of actions : - Aggregation of data : slice (e.g.,
if needed, e.g., : producing an abstracted view: SLOs and SLEs
slice modification : fitted to the slice request : of connectivity
(outer closed-loop): : 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]. Note that SLO, SLE, and SDP stand for "Service Level Objective", "Service Level Expectation", and "Service Demarcation Point", respectively. 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].¶
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 IBN systems, incluing handling the dynamic and time variant nature of the network, the efficient management of cross-domain resources, and the reliability of automatic configuration, etc.¶
Let us take Service Function Chaining (called SFC) as an example to show these challenges.¶
1. 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.¶
2. 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).¶
3. 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.¶
Although there have been extensive research achievements from academic, industrial, and standardization fields, there are the following future research considerations.¶
1. 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.¶
2. Autonomous End-to-End Network Policy Generation:¶
Intent-based networks 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, intent-based networks 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, intent-based networks should provide an E2E optimization policies across multi-domain networking applications.¶
3. Intent Implementation with Large language Models (LLMs):¶
Large language models (LLMs) such as BERT [BERT] will play an important role in enhancing the accuracy of intent refinement, resulting from the powerful understanding capabilities of 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 networks’ stages, there still lack of generality and accuracy. Meanwhile, human interference is still in the full life-cycle of intent-based networks, and in the future the knowledge graph-assisted LLMs can further reduce the human intervention, and even make the human completely be out of the full life-cycle of the intent-based networks.¶
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 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.¶
(TBD)¶
(TBD)¶
This document has no requests to IANA.¶
The following changes are made from draft-kdj-nmrg-ibn-usecases-01:¶
This version updates each section for better clarity.¶
For Section 2.2, the construction of an IBN system is reorganized and clarifed according to the intent life cycle in [RFC9315].¶
For Section 3, IBN Use Cases are explained so that each use case can be clearly explained according to the intent life cycle in [RFC9315].¶
Figures in the document are polished up for better clarity.¶
This work of Jaehoon Paul Jeong is supported by 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 has been partially funded by the European Union under Horizon Europe project NEMO (NExt generation Meta Operating system) grant number 101070118.¶
The following people have substantially contributed to this document as co-authors:¶
Hongwei Yang China Mobile Email: yanghongwei@chinamobile.com Yiwen Shen Ajou University Email: chrisshen@ajou.ac.kr Pedro Martinez-Julia NICT Email: pedro@nict.go.jp Yoseop Ahn Sungkyunkwan University Email: ahnjs124@skku.edu Mose Gu Sungkyunkwan University Email: rna0415@skku.edu Younghan Kim Soongsil University Email: younghak@ssu.ac.kr Jung-Soo Park Electronics and Telecommunications Research Institute Email: pjs@etri.re.kr Yun-Chul Choi Electronics and Telecommunications Research Institute Email: cyc79@etri.re.kr¶