<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-chen-nmrg-ibn-management-01"
     ipr="trust200902">
  <front>
    <title abbrev="Network Working Group">Network Management Intent -One of
    IBN Use Cases</title>

    <author fullname="Danyang Chen" initials="D." surname="Chen">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>chendanyang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Kehan Yao" initials="K." surname="Yao">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>yaokehan@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Chungang Yang" initials="C." surname="Yang">
      <organization>Xidian University</organization>

      <address>
        <postal>
          <street/>

          <city>Xi'an</city>

          <code>710071</code>

          <country>China</country>
        </postal>

        <email>cgyang@xidian.edu.cn</email>
      </address>
    </author>

    <author fullname="Xinru Mi" initials="X." surname="Mi">
      <organization>Xidian University</organization>

      <address>
        <postal>
          <street/>

          <city>Xi'an</city>

          <code>710071</code>

          <country>China</country>
        </postal>

        <email>xinrum@163.com</email>
      </address>
    </author>

    <author fullname="Ying Ouyang" initials="Y." surname="Ouyang">
      <organization>Xidian University</organization>

      <address>
        <postal>
          <street/>

          <city>Xi'an</city>

          <code>710071</code>

          <country>China</country>
        </postal>

        <email>yingouyang224@163.com</email>
      </address>
    </author>

    <!---->

    <date day="4" month="March" year="2024"/>

    <area>Networking</area>

    <workgroup>Internet Research Task Force</workgroup>

    <keyword>Intent based network, network management</keyword>

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>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:</t>

      <t><list>
          <t>Tight coupling of network and service applications: Traditional
          network management methods cannot solve the diverse cross-domain
          service requirements in future communication networks</t>
        </list><list>
          <t>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</t>
        </list><list>
          <t>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.</t>
        </list><list>
          <t>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.</t>
        </list></t>

      <t>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 <xref target="RFC9315">RFC 9315</xref>, 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.</t>
    </section>

    <section title="Definitions and Acronyms">
      <t>IBN: Intent based network</t>

      <t>IBNM: Intent based network management</t>

      <t>DQN: Deep Q network</t>
    </section>

    <section title="Overview">
      <t>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.</t>

      <t>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.<figure
          title="The Architecture of IBNM">
          <artwork>  +----------------------------------------+
  |          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           |
  +----------------------------------------+</artwork>
        </figure></t>

      <t>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.</t>

      <t>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.<list>
          <t>Intent Translation Module</t>

          <t>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&rsquo;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.</t>
        </list><list>
          <t>Intelligent Policy Mapping Module</t>

          <t>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.</t>
        </list><list>
          <t>Intent Guarantee Module</t>

          <t>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.</t>
        </list></t>
    </section>

    <section title="levels of Intent-based Network Management">
      <t>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<xref
      target="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:<list>
          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>
    </section>

    <section title="Advantages">
      <t>The advantages of the intent based network management include:<list>
          <t>A specific intent based network management architecture is
          proposed for sensing diversified service intents with various
          scenarios, objectives, and preferences.</t>

          <t>The proposed framework can achieve zero touch management within a
          time bound, which can handle the complex services in a fully
          automatic manner.</t>

          <t>The performance benefits are in terms of adaptivity and
          scalability, which rewards various network environments and avoids
          network reconstructions.</t>
        </list></t>
    </section>

    <section title="Concrete Example: Intent based Dynamic Service Function Chain">
      <t>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.</t>

      <t>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 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.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no requests to IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.9315"?>

      <reference anchor="Autonomous-Networks">
        <front>
          <title>Autonomous Networks: Empowering Digital Transformation for
          Telecoms Industry. TM Forum, Parsippany, New Jersey, White Paper,
          2019.</title>

          <author fullname="A. Richard" initials="A. Richard"
                  surname="Richard">
            <organization/>
          </author>

          <date month="April" year="2019"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
