Internet DRAFT - draft-chen-nmrg-ibn-management
draft-chen-nmrg-ibn-management
Internet Research Task Force D. Chen
Internet-Draft K. Yao
Intended status: Informational China Mobile
Expires: 5 September 2024 C. Yang
X. Mi
Y. Ouyang
Xidian University
4 March 2024
Network Management Intent -One of IBN Use Cases
draft-chen-nmrg-ibn-management-01
Abstract
Full life cycle network management will be a key feature of the
future communication networks. Meanwhile, the complexity of the
network management should be reduced and the network expects to be
managed in a fully automated manner with humans out of the loop. In
this document, we propose an use case of intent based network
management to achieve more flexible , convenient, and efficient
network management. In this use case, we propose an architecture and
attempt to illustrate the five levels of achieving full autonomous
network management.
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/.
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 5 September 2024.
Chen, et al. Expires 5 September 2024 [Page 1]
Internet-Draft Network Working Group March 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. levels of Intent-based Network Management . . . . . . . . . . 7
5. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Concrete Example: Intent based Dynamic Service Function
Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
With the rapid evolution of networks, such as the emergence of the
sixth generation (6G), we have entered a new digital era that is
ubiquitously connected by highly heterogeneous and dynamic network
infrastructure. And various network applications are predicted to
appear more in future communication networks. With these complex
network scenarios, services, and uncountable degrees of freedom in
future communication networks, the complexity of network management
will increase drastically. Traditional network management methods
are insufficient to keep up with the growing requirements. Firstly,
there exists high complexity and difficulty to manage a large amount
of infrastructures due to high labor cost, high error probability,
low management efficiency. Secondly, traditional network management
lacks closed-loop control, which can not find and repair faults in
time. To overcome these challenges, some novel network models have
been proposed, such as NFV and SDN. However, it still faces many
novel challenges:
Chen, et al. Expires 5 September 2024 [Page 2]
Internet-Draft Network Working Group March 2024
Tight coupling of network and service applications: Traditional
network management methods cannot solve the diverse cross-domain
service requirements in future communication networks
High configuration complexity and scaling cost: Future
communication networks will have a huge network scale, different
kinds of network resources, and constantly changing topology.
This will result in a high network configuration complexity and
cannot be configured in a timely and efficient manner. A smart
and simple network management architecture is required for rapid
deployment of network service requirements
Fragile performance provision and policy robustness: In future
communication networks, it need to continuously improve the
network system model based on the experienced knowledge of
administrators. And real-time verification and feedback
mechanisms are required for network runtime.
Lack of full life cycle verification of policy resilience: Manual
management has several shortcomings, such as high error
probability, long fault location time, and expensive labor costs.
Fortunately, full life cycle verification can reduce the failure
recovery time, monitor network operation, and maintain the whole
process while enhancing the accuracy of policy configuration and
the robustness of policy implementation.
At the same time, with the exponential growth of network devices,
network administrators need to put in tremendous effort to manage the
policies that affect the services of these devices. While in recent
years the network management methods have been gradually automated,
there are still many procedures that must be accomplished under the
strict supervision of administrators, resulting in high error
probability. Moreover, current network management is at a level too
low to entirely eliminate the requirements to customize each solution
for a specific device or protocol in use. The emergence of the IBN,
as defined in RFC 9315 [RFC9315], has the potential to compensate for
the limitations of the current network management methods. The
intent is a high-level abstraction of policy, and the IBN is a way to
manage the network through intent-driven rather than a low-level
configuration. When the user specifies a high-level goal (intent),
the network automatically converts that goal into policies and
automatically deploys these policies throughout the network.
2. Definitions and Acronyms
IBN: Intent based network
IBNM: Intent based network management
Chen, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Network Working Group March 2024
DQN: Deep Q network
3. Overview
Driven by the above requirements and challenges, the intent based
network management (IBNM) is proposed. IBNM aims to transition from
a fully static manual network management to a fully dynamic
autonomous intent based network management. In IBNM, users express
their service requirements or goals in a declarative manner without
paying attention to how the network achieves them.
The architecture is shown as Fig 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. 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.
Chen, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Network Working Group March 2024
+----------------------------------------+
| Application Layer |
+-------------+---------^----------------+
Intent Ingestion| | 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 IBNM
Among these layers, the intent-enabled layer is the core of this
network management architecture. First, the intent translation
module translates declarative intent (expressed in the form of
natural language) into the network intent that can be recognized by
the system (specific ). There may be an intent conflict problem when
multiple intents are input simultaneously. Thus, the intent
translation module executes intent verification and intent conflict
resolution before the intent is issued (measurable). Second, the
intelligent policy mapping module provides customized policies
(achievable) for specific intents according to various requirements
and evaluates the current policy by rewarding values. After that, in
order to complete the policy configuration within the time-bound, the
intent guarantee module is needed to execute feature extraction and
location on the collected alarm information. Then the fault
information is fed back to the intelligent policy mapping module.
Chen, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Network Working Group March 2024
Based on the above design, on one hand, this architecture can achieve
full lifecycle automated network management with humans out of the
loop. On the other hand, it converts service requirements (intent)
into network policies and provides self-adapted customized service
with a full lifecycle verification. The functions of each module in
intent-enabled layer are described below.
Intent Translation Module
Intent is expressed in the form of natural language, which is
ambiguous and does not follow specific forms. Thus, the intent
translation module translates the intent expressed in a natural
language through bidirectional long short-term memory (Bi-LSTM)
and morphological rules, and outputs the network’s understandable
and regularized intent. Meanwhile, the intent translation module
analyzes the accuracy and completeness of the translated intent
through intent verification and conflict resolution, and
continuously monitors whether there are conflicts. The intent
translation module is the first step to realizing intent. In
short, the translation module provides a bridge between the users
and the network and is responsible for ensuring the integrity and
realizability of the input intent. In addition, the result of the
intent translation module is a critical foundation for the
intelligent policy mapping module.
Intelligent Policy Mapping Module
The intelligent policy mapping module is the process of intent
realization, in can consist of policy repository, fuzzy decision
tree, and deep Q network (DQN). A large number of atomic policies
can be stored in the policy repository, which can be established
by the historical policy and administrator operation and
maintenance experience. In particular, atomic policy refers to
the smallest policy unit that can be executed but cannot be split
again, such as some functional node configuration policies
(routing selection, service provider node selection, etc.). The
function of the fuzzy decision tree is to generate new atomic
policies for the policy repository or to adjust the existing
atomic policies. DQN is a combination of neural network and
reinforcement learning, which are used to reorganize the atomic
policies into a new policy that satisfies the current intent
requirements. The function of the neural network is to calculate
the configuration scores for state-action pairs and outputs all
actions. Then the action with the highest configuration score is
selected as the configuration action according to the Q-learning
principle.
Intent Guarantee Module
Chen, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Network Working Group March 2024
The function of the intent guarantee module is to monitor the
network in real time, collect and analyze the data of the faults
that have occurred, and predict the faults that have not occurred
in order to ensure the normal operation of the network. First, a
fault information table, including fault type, location, quantity,
and occurrence time, is established based on the collected network
abnormal information. Second, a deep neural evolutionary network
is used to repair faults and feed back the repair results to the
intent translation module in real time. A deep neural evolution
network can not only repair faults, but also ensure the
implementation of intents when network faults occur.
4. levels of Intent-based Network Management
The complexity of the future communication network dictates that
achieving IBNM is a long-term goal, which needs to be completed step
by step. Based on the autonomous network levels[Autonomous-Networks]
, we gives the definition of the levels of IBNM as five levels:
manual network management (Level 0), intent assistance network
management (Level 1), partial autonomous IBNM (Level 2), high
autonomous IBNM (Level 3), and full autonomous IBNM (Level 4). IBNM
transforms the traditional fully static network into a fully dynamic
network, and details are as follows:
Manual network management: This is a fully static phase, and the
full life cycle of network management is done by the network
administrator. The network is unable to provide differentiated
services for users.
Intent assistance network management: Intent is first introduced
in this phase. Manual network management is still there; however,
the IBN has been involved to handle partial tasks. Meanwhile,
this level always requires administrators to configure parameters
and correct for errors in implementation results.
Partial autonomous IBNM: This level achieves a leap from static to
dynamic. Most scenarios can achieve automatic configuration and
timing verification for partial scenarios, which lessens the role
of the administrator. In addition, the network can provide
partial differentiated services for users at this micro-dynamic
level.
High autonomous IBNM: This level is semi-dynamic. The IBN can
recognize multi- form (graph, text, and voice) intent input and
realize autonomous intent translation. In addition, the IBN
adopts real-time data collection and analysis methods, which
improve the performance of network management in terms of
intelligence, real time, and accuracy.
Chen, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Network Working Group March 2024
Full autonomous IBNM: Full dynamicity is the objective of the IBN.
The unique characteristics of a network management are intelligent
intent insight, intelligent translation, intelligent configuration
and error correction as well as real-time verification. All the
tasks are done by the network. The IBN can provide users with
differentiated services in full scenarios.
5. Advantages
The advantages of the intent based network management include:
A specific intent based network management architecture is
proposed for sensing diversified service intents with various
scenarios, objectives, and preferences.
The proposed framework can achieve zero touch management within a
time bound, which can handle the complex services in a fully
automatic manner.
The performance benefits are in terms of adaptivity and
scalability, which rewards various network environments and avoids
network reconstructions.
6. Concrete Example: Intent based Dynamic Service Function Chain
In order to evaluate the performance of the proposed IBNM
architecture, we use the intent-based dynamic service function chain
(SFC) as an example to solve the network management challenges (e.g.,
cross-domain orchestration and service functions are tightly coupled
with the underlying equipment). At the same time, we developed an
Openstack-based IBNM platform. The system demonstration implements
the whole process from intent input to intent translation to intent
policy generation to intent deployment, and the details are as
follows.
The user input cross-domain link-building requests (intent) in
natural language at the web-page: 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, 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 in the form of name-value
pairs. After the intent translation module, the translation results
will be converted to JavaScript Object Notation (JSON) and
transmitted to the intelligent policy mapping module. The
intelligent policy mapping module divides the JSON request into an
SFC: service function 1 (network address translation) service
Chen, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Network Working Group March 2024
function 2 (firewall), and constructs the SFC request (name,
tenant_id, description, service requirements, etc.). Then query
whether there is an atomic policy combination that satisfies the
current intent requirements in the policy repository. Following
that, SFC is constructed based on the SFC interface, which is
extended by Neutron. OpenStack schedules network resources,
constructs sub-nets 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.
7. Security Considerations
TBD
8. IANA Considerations
This document has no requests to IANA.
9. Normative References
[Autonomous-Networks]
Richard, A. Richard., "Autonomous Networks: Empowering
Digital Transformation for Telecoms Industry. TM Forum,
Parsippany, New Jersey, White Paper, 2019.", April 2019.
[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>.
[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>.
Authors' Addresses
Danyang Chen
China Mobile
Beijing
100053
China
Email: chendanyang@chinamobile.com
Chen, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Network Working Group March 2024
Kehan Yao
China Mobile
Beijing
100053
China
Email: yaokehan@chinamobile.com
Chungang Yang
Xidian University
Xi'an
710071
China
Email: cgyang@xidian.edu.cn
Xinru Mi
Xidian University
Xi'an
710071
China
Email: xinrum@163.com
Ying Ouyang
Xidian University
Xi'an
710071
China
Email: yingouyang224@163.com
Chen, et al. Expires 5 September 2024 [Page 10]
