Use Cases and Practices for Intent-Based Networking
draft-kdj-nmrg-ibn-usecases-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (nmrg RG) | |
|---|---|---|---|
| Authors | Kehan Yao , Danyang Chen , Jaehoon Paul Jeong , Qin Wu , Chungang Yang , Luis M. Contreras , Giuseppe Fioccola | ||
| Last updated | 2024-11-13 (Latest revision 2024-10-21) | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | Candidate RG Document | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Jéferson Campos Nobre | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | jcnobre@inf.ufrgs.br |
draft-kdj-nmrg-ibn-usecases-02
Internet Research Task Force K. Yao, Ed.
Internet-Draft D. Chen, Ed.
Intended status: Informational China Mobile
Expires: 24 April 2025 J. Jeong, Ed.
Sungkyunkwan University
Q. Wu
Huawei
C. Yang
Xidian University
L. Contreras
Telefonica
G. Fioccola
Huawei
21 October 2024
Use Cases and Practices for Intent-Based Networking
draft-kdj-nmrg-ibn-usecases-02
Abstract
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.
Requirements Language
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Yao, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Network Working Group October 2024
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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Methodologies for Building IBN Systems . . . . . . . . . . . 3
2.1. System Awareness and Data Collection . . . . . . . . . . 3
2.2. The Construction of an IBN System . . . . . . . . . . . . 5
3. IBN Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IBN for Routing and Path Selection . . . . . . . . . . . 11
3.1.1. IBN for Service Function Chaining . . . . . . . . . . 11
3.1.2. IBN for SRv6 Networks . . . . . . . . . . . . . . . . 13
3.2. IBN for Guaranteeing Service-Level Agreement . . . . . . 15
3.2.1. On-Path Telemetry Methods . . . . . . . . . . . . . . 16
3.3. IBN for Cloud-Based Security Service Management . . . . . 19
3.4. IBN for IoT Device Management . . . . . . . . . . . . . . 21
3.5. IBN for Sofware-Defined Vehicle Management . . . . . . . 23
3.6. IBN for Interconnection . . . . . . . . . . . . . . . . . 26
3.7. IBN for IETF Network Slices . . . . . . . . . . . . . . . 28
4. Practice Learnings . . . . . . . . . . . . . . . . . . . . . 30
4.1. Difficulties and Challenges . . . . . . . . . . . . . . . 30
4.2. Future Research Directions . . . . . . . . . . . . . . . 31
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 32
5.1. Multi-Domain Dichotomy for IBN . . . . . . . . . . . . . 32
5.1.1. Multi-Domain Intents . . . . . . . . . . . . . . . . 32
5.1.2. Multi-Domain Intent Resolution . . . . . . . . . . . 33
5.2. The Integration of IBN and Network Digital Twin . . . . . 33
5.3. The Integration of IBN, AI and Green Networking . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
Yao, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Network Working Group October 2024
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Changes from draft-kdj-nmrg-ibn-usecases-01 . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
[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.
2. Methodologies for Building IBN Systems
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.
2.1. System Awareness and Data Collection
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.
1. Methods and Tools
Yao, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Network Working Group October 2024
* 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.
2. 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.
3. 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.
Yao, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Network Working Group October 2024
* 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.
2.2. The Construction of an IBN System
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.
1. Intent Translation
Yao, et al. Expires 24 April 2025 [Page 5]
Internet-Draft Network Working Group October 2024
* 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.
Yao, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Network Working Group October 2024
- 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.
2. 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
Yao, et al. Expires 24 April 2025 [Page 7]
Internet-Draft Network Working Group October 2024
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.
3. 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
Yao, et al. Expires 24 April 2025 [Page 8]
Internet-Draft Network Working Group October 2024
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.
4. 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.
5. 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.
Yao, et al. Expires 24 April 2025 [Page 9]
Internet-Draft Network Working Group October 2024
- Network entities send their monitoring data to a validation
entity (e.g., analyzer) as a delivery protocol NETCONF
[RFC6241], RESTCONF [RFC8040], or REST API [REST].
- The validation entity stores the monitoring data into its
local repository for further analysis and investigation.
6. 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.
7. 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.
Yao, et al. Expires 24 April 2025 [Page 10]
Internet-Draft Network Working Group October 2024
- 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.
3. IBN Use Cases
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.
3.1. IBN for Routing and Path Selection
IBN can be applied in building network path and generating routing
policies according to network administrators' requests.
3.1.1. IBN for Service Function Chaining
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.
Yao, et al. Expires 24 April 2025 [Page 11]
Internet-Draft Network Working Group October 2024
+----------------------------------------+
| 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 |
+----------------------------------------+
Figure 1: The Architecture of an IBNM System
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."
Yao, et al. Expires 24 April 2025 [Page 12]
Internet-Draft Network Working Group October 2024
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.
3.1.2. IBN for SRv6 Networks
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].
Yao, et al. Expires 24 April 2025 [Page 13]
Internet-Draft Network Working Group October 2024
+-------------+ +-----------------------------+
| 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)| |
| +-----------------+ +---------------+ +---------------+ |
+------------------------------------------------------------------+
Figure 2: Intent-Based Network Management in SRv6 Networks
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].
Yao, et al. Expires 24 April 2025 [Page 14]
Internet-Draft Network Working Group October 2024
3.2. IBN for Guaranteeing Service-Level Agreement
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.
Yao, et al. Expires 24 April 2025 [Page 15]
Internet-Draft Network Working Group October 2024
^
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]
Figure 3: Network SLA Performance Metrics
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.
3.2.1. On-Path Telemetry Methods
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.
Yao, et al. Expires 24 April 2025 [Page 16]
Internet-Draft Network Working Group October 2024
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 |
+---------------------------------------------+
Figure 4: Workflow for IBN-Based On-Path Telemetry
Yao, et al. Expires 24 April 2025 [Page 17]
Internet-Draft Network Working Group October 2024
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].
3.2.1.1. Clustered Alternate-Marking Methodology
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:
1. change the traffic filter and select more detailed flows;
2. 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.
Yao, et al. Expires 24 April 2025 [Page 18]
Internet-Draft Network Working Group October 2024
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.
3.3. IBN for Cloud-Based Security Service Management
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.
Yao, et al. Expires 24 April 2025 [Page 19]
Internet-Draft Network Working Group October 2024
+------------+
| 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: Security Management Automation in I2NSF Framework
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].
Yao, et al. Expires 24 April 2025 [Page 20]
Internet-Draft Network Working Group October 2024
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].
3.4. IBN for IoT Device Management
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).
Yao, et al. Expires 24 April 2025 [Page 21]
Internet-Draft Network Working Group October 2024
+------------+
| 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: Network Management Automation in IBN Framework for 5G
Networks
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].
Yao, et al. Expires 24 April 2025 [Page 22]
Internet-Draft Network Working Group October 2024
3.5. IBN for Sofware-Defined Vehicle Management
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| :
: +----------+ :
Figure 7: The Intent Life Cycle of IBS for SDV Management
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
Yao, et al. Expires 24 April 2025 [Page 23]
Internet-Draft Network Working Group October 2024
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.
Yao, et al. Expires 24 April 2025 [Page 24]
Internet-Draft Network Working Group October 2024
<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)>
Yao, et al. Expires 24 April 2025 [Page 25]
Internet-Draft Network Working Group October 2024
Figure 8: Intent-Based Management Framework for Software-Defined
Vehicles
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].
3.6. IBN for Interconnection
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.
Yao, et al. Expires 24 April 2025 [Page 26]
Internet-Draft Network Working Group October 2024
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) : :
Figure 9: Fulfillment Phase of Interconnection Intent
Similarly, Figure 10 sketches the intent procedure for the assurance
phase of the Interconnection Intent.
Yao, et al. Expires 24 April 2025 [Page 27]
Internet-Draft Network Working Group October 2024
: +--------+ :
: |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)
Figure 10: Assurance Phase of Interconnection Intent
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].
3.7. IBN for IETF Network Slices
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
Yao, et al. Expires 24 April 2025 [Page 28]
Internet-Draft Network Working Group October 2024
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 :
Figure 11: Fulfillment Phase of IETF Network Slice Service Intent
Similarly, Figure 12 sketches the intent procedure for the assurance
phase of the IETF Network Slice Service Intent.
Yao, et al. Expires 24 April 2025 [Page 29]
Internet-Draft Network Working Group October 2024
: +--------+ :
: |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)
Figure 12: Assurance Phase of IETF Network Slice Service Intent
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].
4. Practice Learnings
4.1. Difficulties and Challenges
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:
Yao, et al. Expires 24 April 2025 [Page 30]
Internet-Draft Network Working Group October 2024
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.
4.2. Future Research Directions
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:
Yao, et al. Expires 24 April 2025 [Page 31]
Internet-Draft Network Working Group October 2024
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.
5. Other Considerations
5.1. Multi-Domain Dichotomy for IBN
IBN shows two different aspects and relations with multi-domain
concepts such as multi-domain intents and multi-domain intent
resolution.
5.1.1. Multi-Domain Intents
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
Yao, et al. Expires 24 April 2025 [Page 32]
Internet-Draft Network Working Group October 2024
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.
5.1.2. Multi-Domain Intent Resolution
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.
5.2. The Integration of IBN and Network Digital Twin
(TBD)
5.3. The Integration of IBN, AI and Green Networking
(TBD)
6. Security Considerations
TBD.
7. IANA Considerations
This document has no requests to IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Yao, et al. Expires 24 April 2025 [Page 33]
Internet-Draft Network Working Group October 2024
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/info/rfc9315>.
[RFC9316] Li, C., Havel, O., Olariu, A., Martinez-Julia, P., Nobre,
J., and D. Lopez, "Intent Classification", RFC 9316,
DOI 10.17487/RFC9316, October 2022,
<https://www.rfc-editor.org/info/rfc9316>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
Yao, et al. Expires 24 April 2025 [Page 34]
Internet-Draft Network Working Group October 2024
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
8.2. Informative References
[BERT] Devlin, J., Chang, M., Lee, K., and K. Toutanova, "BERT:
Pre-training of Deep Bidirectional Transformers for
Language Understanding", Proceedings of Conference of the
North American Chapter of the Association of Computational
Linguistics - Human Language Technology (NAACL-HLT),
Available: https://arxiv.org/abs/1810.04805, June 2019.
[Circular-Reasoning]
Rips, L., "Circular Reasoning", Wiley Cognitive Science,
Volume 26, Issue 6,
Available: https://doi.org/10.1016/S0364-0213(02)00085-X,
November 2002.
[DRL] Luong, N., Hoang, D., Gong, S., Niyato, D., Wang, P., and
Y. Liang, "Applications of Deep Reinforcement Learning in
Communications and Networking: A Survey",
IEEE Communications Surveys & Tutorials, Volume 21, Issue
4,
Available: https://ieeexplore.ieee.org/document/8714026,
October 2019.
[ETSI-NFV] ETSI GS NFV 002 V1.2.1, "Network Functions Virtualisation
(NFV); Architectural Framework", Available:
https://www.etsi.org/deliver/etsi_gs/
nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
December 2014.
[ETSI-NFV-Release-2]
ETSI GS NFV 006 V2.1.1, "Network Functions Virtualisation
(NFV) Release 2; Management and Orchestration;
Architectural Framework Specification", Available:
https://www.etsi.org/deliver/etsi_gs/
nfv/001_099/006/02.01.01_60/gs_nfv006v020101p.pdf, January
2021.
Yao, et al. Expires 24 April 2025 [Page 35]
Internet-Draft Network Working Group October 2024
[GSMA] "GSMA: Global System for Mobile Communications
Association", Available: https://www.gsma.com.
[I-D.contreras-nmrg-interconnection-intents]
Contreras, L. M., Lucente, P., and T. H. Velivassaki,
"Interconnection Intents", Work in Progress, Internet-
Draft, draft-contreras-nmrg-interconnection-intents-05, 8
July 2024, <https://datatracker.ietf.org/doc/html/draft-
contreras-nmrg-interconnection-intents-05>.
[I-D.contreras-nmrg-transport-slice-intent]
Contreras, L. M., Demestichas, P., and J. Tantsura, "IETF
Network Slice Intent", Work in Progress, Internet-Draft,
draft-contreras-nmrg-transport-slice-intent-07, 8 July
2024, <https://datatracker.ietf.org/doc/html/draft-
contreras-nmrg-transport-slice-intent-07>.
[I-D.fz-ippm-on-path-telemetry-yang]
Fioccola, G. and T. Zhou, "On-path Telemetry YANG Data
Model", Work in Progress, Internet-Draft, draft-fz-ippm-
on-path-telemetry-yang-00, 19 June 2024,
<https://datatracker.ietf.org/doc/html/draft-fz-ippm-on-
path-telemetry-yang-00>.
[I-D.ietf-opsawg-ipfix-alt-mark]
Graf, T., Fioccola, G., Zhou, T., Milan, F., and M. Nilo,
"IPFIX Alternate-Marking Information", Work in Progress,
Internet-Draft, draft-ietf-opsawg-ipfix-alt-mark-00, 8
July 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-opsawg-ipfix-alt-mark-00>.
[I-D.ietf-spring-sr-policy-yang]
Raza, S. K., Saleh, T., Shunwan, Z., Voyer, D., Durrani,
M., Matsushima, S., and V. P. Beeram, "YANG Data Model for
Segment Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-03, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-03>.
[I-D.jeong-i2nsf-security-management-automation]
Jeong, J. P., Lingga, P., Jung-Soo, J., Lopez, D., and S.
Hares, "An I2NSF Framework for Security Management
Automation in Cloud-Based Security Systems", Work in
Progress, Internet-Draft, draft-jeong-i2nsf-security-
management-automation-08, 26 July 2024,
<https://datatracker.ietf.org/doc/html/draft-jeong-i2nsf-
security-management-automation-08>.
Yao, et al. Expires 24 April 2025 [Page 36]
Internet-Draft Network Working Group October 2024
[I-D.jeong-nmrg-ibn-network-management-automation]
Jeong, J. P., Ahn, Y., Kim, Y., and J. Jung-Soo, "Intent-
Based Network Management Automation in 5G Networks", Work
in Progress, Internet-Draft, draft-jeong-nmrg-ibn-network-
management-automation-04, 22 April 2024,
<https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-
ibn-network-management-automation-04>.
[I-D.jeong-opsawg-intent-based-sdv-framework]
Jeong, J. P. and Y. Shen, "An Intent-Based Management
Framework for Software-Defined Vehicles in Intelligent
Transportation Systems", Work in Progress, Internet-Draft,
draft-jeong-opsawg-intent-based-sdv-framework-02, 24 June
2024, <https://datatracker.ietf.org/doc/html/draft-jeong-
opsawg-intent-based-sdv-framework-02>.
[I-D.park-nmrg-ibn-network-management-srv6]
Jung-Soo, J., Choi, Y., and J. P. Jeong, "Intent-Based
Network Management in SRv6 Networks", Work in Progress,
Internet-Draft, draft-park-nmrg-ibn-network-management-
srv6-02, 24 June 2024,
<https://datatracker.ietf.org/doc/html/draft-park-nmrg-
ibn-network-management-srv6-02>.
[I-D.pedro-ite]
Martinez-Julia, P. and J. P. Jeong, "Intent Translation
Engine for Intent-Based Networking", Work in Progress,
Internet-Draft, draft-pedro-ite-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-pedro-ite-
01>.
[I-D.ydt-ippm-alt-mark-yang]
Graf, T., Wang, M., Fioccola, G., Zhou, T., and X. Min, "A
YANG Data Model for the Alternate Marking Method", Work in
Progress, Internet-Draft, draft-ydt-ippm-alt-mark-yang-03,
2 September 2024, <https://datatracker.ietf.org/doc/html/
draft-ydt-ippm-alt-mark-yang-03>.
[IntFlow] Shi, Q., Wang, F., and D. Feng, "IntFlow: Integrating Per-
Packet and Per-Flowlet Switching Strategy for Load
Balancing in Datacenter Networks", IEEE Transactions on
Network and Service Management, Volume 17, Issue 3,
Available: https://ieeexplore.ieee.org/document/9079931,
September 2020.
[Knowledge-Graph]
Ji, S., Pan, S., Cambria, E., Marttinen, P., and P. Yu, "A
Survey on Knowledge Graphs: Representation, Acquisition,
Yao, et al. Expires 24 April 2025 [Page 37]
Internet-Draft Network Working Group October 2024
and Applications", IEEE Transactions on Neural Networks
and Learning Systems, Volume 33, Issue 2,
Available: https://ieeexplore.ieee.org/document/9416312,
February 2022.
[OpenStack]
"OpenStack: Open Source Cloud Computing Infrastructure",
Available: https://www.openstack.org.
[REST] Fielding, R. and R. Taylor, "Principled Design of the
Modern Web Architecture", ACM Transactions on Internet
Technology, Volume 2, Issue 2,
Available: https://dl.acm.org/doi/10.1145/514183.514185,
May 2002.
[SPT] Lingga, P., Jeong, J., Yang, J., and J. Kim, "SPT:
Security Policy Translator for Network Security Functions
in Cloud-Based Security Services", IEEE Transactions on
Dependable and Secure Computing,
Available: https://ieeexplore.ieee.org/document/9416312,
February 2024.
[TS-28-312]
3GPP TS 28.312 V18.5.0, "Intent Driven Management Services
for Mobile Networks", Available:
https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3554, September
2024.
[YAML] YAML Language Development Team, "Yet Another Markup
Language (YAML) version 1.2",
Available: https://yaml.org/spec/1.2.2/, October 2021.
Appendix A. Changes from draft-kdj-nmrg-ibn-usecases-01
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.
Yao, et al. Expires 24 April 2025 [Page 38]
Internet-Draft Network Working Group October 2024
Acknowledgments
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.
Contributors
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
Yao, et al. Expires 24 April 2025 [Page 39]
Internet-Draft Network Working Group October 2024
Authors' Addresses
Kehan Yao (editor)
China Mobile
Beijing
100053
China
Email: yaokehan@chinamobile.com
Danyang Chen (editor)
China Mobile
Beijing
100053
China
Email: chendanyang@chinamobile.com
Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Qin Wu
Huawei
Email: bill.wu@huawei.com
Chungang Yang
Xidian University
Email: cgyang@xidian.edu.cn
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Giuseppe Fioccola
Huawei
Yao, et al. Expires 24 April 2025 [Page 40]
Internet-Draft Network Working Group October 2024
Email: giuseppe.fioccola@huawei.com
Yao, et al. Expires 24 April 2025 [Page 41]