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]