An Autonomic Mechanism for Resource-based Network Services Auto-deployment
draft-ietf-anima-network-service-auto-deployment-02

ANIMA                                                       J. Dang, Ed.
Internet-Draft                                                  S. Jiang
Intended status: Standards Track                                  Huawei
Expires: 9 January 2023                                            Z. Du
                                                            China Mobile
                                                            Z. Zhou, Ed.
                                                                  Huawei
                                                             8 July 2022

    An Autonomic Mechanism for Resource-based Network Services Auto-
                               deployment
          draft-ietf-anima-network-service-auto-deployment-02

Abstract

   This document specifies an autonomic mechanism for resource-based
   network services deployment through the Autonomic Control Plane (ACP)
   in a network.  This mechanism uses the GeneRic Autonomic Signaling
   Protocol (GRASP) in [RFC8990] to exchange the information among the
   autonomic nodes so that the resource along the service path can be
   coordinated.

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 9 January 2023.

Copyright Notice

   Copyright (c) 2022 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.

Dang, et al.             Expires 9 January 2023                 [Page 1]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology & Abbreviations . . . . . . . . . . . . . . . . .   4
   4.  Resource-based Network Services Auto-deployment Solution  . .   4
     4.1.  ResourceManager ASA Discovery . . . . . . . . . . . . . .   5
     4.2.  Resource Negotiation  . . . . . . . . . . . . . . . . . .   6
     4.3.  Behavior after Negotiation  . . . . . . . . . . . . . . .   7
   5.  Autonomic Resource Management Objectives  . . . . . . . . . .   7
   6.  Process of Network Service Auto-deployment  . . . . . . . . .   8
     6.1.  An example of End-to-End Service  . . . . . . . . . . . .   9
     6.2.  An example of multiple rounds . . . . . . . . . . . . . .  10
     6.3.  An example of multiple domain network . . . . . . . . . .  11
     6.4.  An example of changing resource requirements  . . . . . .  11
     6.5.  An example of releasing resource requirements . . . . . .  12
   7.  Compatibility with Other Technologies . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   With network development, a class of services with resource
   requirements (such as bandwidth, queue, and priority) are already
   emerging, such as video, VR, AR, and so on.  To ensure the proper
   operation of these services, the network needs to allocate sufficient
   resources for the services in advance.  An autonomous network SHOULD
   have an appropriate mechanism to negotiate the network resources.

   From the network perspective, this kind of service has a source IP
   address and a destination IP address.  Therefore, once the kind of
   service is delivered by a domain network, this service clearly has an
   access node and a departure node in the network.  In an autonomic
   resource negotiation mechanism, the resources are negotiated between
   the access node and departure node.

   The core goal of this document is to establish an automatic
   negotiation mechanism to achieve the negotiation and distribution of
   network resources in the domain network between the service client

Dang, et al.             Expires 9 January 2023                 [Page 2]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   and the network.  That is, the server client negotiates with the
   network how many resources can be provided for specific services in
   the domain network to support the transmission of network services.
   The benefits of doing so mainly include the following aspects:

   *  The resource-based network services auto-deployment satisfies the
      QoS requirements of the service.  If the service wants to ensure
      its own transmission quality, the most effective solution is to
      reserve enough transmission resources for the service before the
      service starts.

   *  The mechanism of supporting multiple rounds of negotiations
      enables the service client to change the resource requirements
      according to the state of the network.  For example, when the
      service is applying for resources, if the network is crowded,
      Video Conference services can reduce the quality of video to
      ensure the most basic connectivity.  In the traditional network
      resource reservation, the network will just inform the service
      that the resource is insufficient and the deployment fails.

   *  The mechanism can ensure that the resources in the network can be
      used more efficiently, provide different levels of network
      resources for different levels of services, and give priority to
      the network resource requirements of high importance services.

   The resource information negotiated in this document is more
   extensive.  Not only negotiation bandwidth resources but also
   includes and is not limited to queue, priority and other resources.
   On the one hand, in recent years, the requirements of services for
   the network have become more complex.  Services usually require the
   network to ensure not only the deterministic bandwidth but also the
   deterministic end-to-end delay and jitter, so as to deliver the data
   message to the destination "in time" and "on time".  For example, in
   the telemedicine scenario, in order to ensure that doctors do not
   feel obvious delay and jitter, it is required that the end-to-end
   delay should not exceed 20ms.  On the other hand, with the
   development of technology, the network has more refined the
   scheduling of transmission capacity, and also hopes to open its own
   capacity to the service clients.  The negotiation resources
   established in this document should support not only negotiating the
   existing supported resources but also to retain some scalability for
   the negotiation ability in the future.

   This document completes the resource-based self-adaptation among
   service and network nodes via GRASP.  This document defines an
   autonomic technical objective for resource-based network services
   auto-deployment.  It shows how the ANI can be applied to negotiate
   resource information for network service auto-deployment.  This

Dang, et al.             Expires 9 January 2023                 [Page 3]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   document reduces the difficulty of manual operation, avoids the
   problems of specification limitation and slow response speed in the
   centralized system, improves the efficiency of service deployment and
   makes more rational use of network resources.  The GeneRic Autonomic
   Signaling Protocol (GRASP) is specified by [RFC8990] and can make use
   of the technical objective to provide a solution for resource-based
   network services auto-deployment.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] .

3.  Terminology & Abbreviations

   This document uses terminology defined in [RFC7575].

   RRM ASA: Requester ResourceManager ASA.  A kind of ResourceManager
   ASA which starts to request resource in the network.

   PRM ASA: Provider ResourceManager ASA.  A kind of ResourceManager ASA
   which provides resource in the network.

   APE: Access Provider Edge is the first access provider edge where the
   service initiator connects to the network or where the path-dependent
   and resource-based network service starts.

   DPE: Departure PE is the last provider edge where the path-dependent
   and resource-based network service ends.

   Transmit node: A transmit node in the domain network.

   ASBR: AS Border Router is an edge node of the domain in the cross-
   domain scenario.  It may also be a PE node.

4.  Resource-based Network Services Auto-deployment Solution

   This section describes the internal architecture of resource-based
   network services auto-deployment.  As noted in Section 1, this is not
   a complete description of a solution, which will depend on the
   detailed design of the relevant Autonomic Service Agents (ASAs).  It
   uses the generic discovery and negotiation protocol defined by
   [RFC8990] and the relevant GRASP objectives are defined in Section 5.

Dang, et al.             Expires 9 January 2023                 [Page 4]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   Figure1 shows the process of the auto deployment mechanism.  And the
   procedures described below are carried out by an ASA in each device
   that participates in the solution.  We will refer to this as the
   ResourceManager ASA.  If a device containing a ResourceManager ASA
   needs reserve resources for specific, it can request more resources
   according to its requirements.  It should decide the type and value
   of the requested resource and request it via the mechanism described
   in Section 6.

                +----------+                          +---------+
                | RRM ASA  |                          | PRM ASA |
                +----------+        Discovery         +---------+
    Discovery         |----------------------------------->|
                      |            M_RESPONSE              |
                      |<-----------------------------------|
    Negotiation       |                                    |
             +----------------+                    +----------------+
             | Decide each    |   Multiple rounds  |  responses how |
             |round how large |<------------------>| large resource |
             | response need  |    Negotiation     |   can offer    |
             +----------------+                    +----------------+
                     |                                     |
      After          |             +---------------------------------+
    Negotiation      |             | Removes the acceptable resource |
                     |             | from its resource pool          |
                     |             +---------------------------------+
                     |      synchronize to other ASAs      |
                     |<------------------------------------|
             +----------------+                            |
             | Send packets   |                            |
             +----------------+                            |
                     |                                     |

   Figure-1: Auto-deployment Process

4.1.  ResourceManager ASA Discovery

   A ResourceManager ASA that needs additional resources should first
   discover peers that may be able to provide extra resources.  The ASA
   should send out a GRASP Discovery message that contains a
   ResourceManager Objective option to discover peers also supporting
   that option.

Dang, et al.             Expires 9 January 2023                 [Page 5]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   A GRASP device that receives a Discovery message with a
   ResourceManager Objective option should respond with a GRASP Response
   message if it contains a ResourceManager ASA.  If it does not contain
   a ResourceManager ASA, the device ignores this message.  Further
   details of the discovery process are described in Section 2.5.4 of
   [RFC8990].

4.2.  Resource Negotiation

   After the discovery step, the RRM ASA (Requesting ResourceManager
   ASA) will act as a GRASP negotiation initiator by sending a GRASP
   Request message with a ResourceManager Objective option.  The RRM ASA
   indicates in this option the value of the requested resource.
   ResourceManager GRASP Objective allows multiple types of resources to
   be requested simultaneously.

   When the PRM ASA (Provider ResourceManager ASA) receives a subsequent
   Request message, it should conduct a GRASP negotiation sequence,
   using Negotiate, Confirm Waiting, and Negotiation End messages as
   appropriate.  The Negotiate messages carry a ResourceManager
   Objective option, which will indicate the resource type and value
   offered to the requesting ASA.

   During the negotiation, the RRM ASA will decide at each step how
   large a resource needs to offer.  That decision, and the decision to
   end the negotiation, are implementation choices.  As to the PRM ASA
   responses how large resources they can offer and reserve enough
   resources during this negotiation step.  A resource shortage may
   cause a device to indicate the existing available value within a
   ResourceManager Objective option to the RRM ASA.  The RRM ASA
   compares whether the resource data received is the same locally.  If
   they are not the same, the RRM ASA might decide whether to accept the
   request of the resource.  If not, the RRM ASA might terminate the
   negotiation via Negotiation End messages with an error code string.

   As described in Section 2.8.8 of [RFC8990], negotiation will continue
   until either end stops it with a Negotiation End message.  If the
   negotiation succeeds, the ASA that provides the resource will remove
   the negotiated resource from its pool, and the requesting ASA will
   add it.  If the negotiation fails, the party sending the Negotiation
   End message may include an error code string.

Dang, et al.             Expires 9 January 2023                 [Page 6]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

4.3.  Behavior after Negotiation

   Upon receiving a GRASP Negotiation End message that indicates that
   the acceptable resource is available.  The resource-providing device
   removes the acceptable resource from its resource pool and
   synchronizes to other RRM ASAs and PRM ASAs.  The requesting device
   may use the negotiated resource after receiving synchronization
   message without further messages.

5.  Autonomic Resource Management Objectives

   This section defines the GRASP technical objective options that are
   used to support autonomic resource management.

   The ResourceManager Objective option is a GRASP Objective option
   conforming to the GRASP specification [RFC8990].  Its name is
   "ResourceManager", and it carries the following data items as its
   value: the resource value.  Since GRASP is based on CBOR (Concise
   Binary Object Representation) [RFC8949], the format of the
   ResourceManager Objective option is described in the Concise Data
   Definition Language (CDDL) [RFC8610] as follows:

   objective = ["ResourceManager", objective-flags, loop-count,
   ?objective-value]

   objective-name = "ResourceManager"

   objective-flags = uint .bits objective-flag ; as in the GRASP
   specification

   loop-count = 0..255 ; as in the GRASP specification

   The 'objective-value' field expresses the actual value of a
   negotiation or synchronization objective.  So a new objective-value
   named n-s-deployment-value is defined for Network Service Auto-
   deployment as follows.  The autonomic node can know that it is
   serving Network Service Auto-deployment according to the objective-
   value after receiving the GRASP message.  The 'objective value'
   contains two parts, one represents the information of the service
   itself, and the other represents the requirements of resources.

   objective-value = n-s-deployment-value ; An n-s-deployment-value is
   defined as Figure-2.

Dang, et al.             Expires 9 January 2023                 [Page 7]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

    n-s-deployment-value
        + service-information
            + source-ip-address
            + destination-ip-address
            + service-tag
        + resource-information
            + resource-requirement-pair
                + resource-type
                + resource-value

   Figure-2: Format of n-s-deployment-value

   service-information = [ source-ip-address, destination-ip-address,
   service-tag ]

   The source-ip-address and the destination-ip-address represent the
   source address and destination address.  IPv4 and IPv6 addresses are
   allowed.

   resource-information = [ resource-requirement-pair 1, resource-
   requirement-pair 2, ... , resource-requirement-pair n ]

   Resource requirements of different types can be described in an
   objective option.  The ResourceManager objective option supports
   multi-faceted resource requirements and negotiation.

   resource-requirement-pair = [ resourcetype, resval ]

   resourcetype /= 0...16; requested or offered resource type, such as
   bandwidth, queue, and priority.

   resval /= 1...1000000; If the restype is bandwidth, the value ranges
   in Mbit/s; If the restype is latency, the value ranges in
   microsecond; If the restype is jitter, the value ranges in
   microsecond.

6.  Process of Network Service Auto-deployment

   The network service auto-deployment system includes Service
   Initiator(SI), Service Terminator(ST), RRM ASA, PRM ASA and even
   ASBR.

   The service initiator is the resource demander, which ensures the
   connection of services through negotiation resources with
   ResourceManager ASA in the domain network.  Service Terminator is the
   end of service.  APE represents the first access provider edge where
   the service initiator connects to the network or where the path-
   dependent and resource-based network service starts.  There may be

Dang, et al.             Expires 9 January 2023                 [Page 8]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   multiple Transmit nodes between APE and Service Terminator in the
   network or even cross multiple network domains through ASBRs.  RRM
   ASA starts a negotiation process to get enough resources in the
   network.  After RRM ASA gets the result about the resource, it sends
   a response message to the Service Initiator.  And PRM ASA manages
   resources from APE to ST hop-by-hop.

6.1.  An example of End-to-End Service

   In an End-to-End service, Service Initiator is a kind of access
   terminal of the network.  And the End-to-End service initiator uses
   ResourceManager ASA to negotiate resources with the ResourceManager
   ASA in the APE.  Figure 3 shows the architecture of the End-to-End
   service.  In the figure, the RRM ASA in SI will act as a GRASP
   negotiation initiator by sending a GRASP Request message with a
   ResourceManager Objective option.  The RRM ASA indicates in this
   option the value of the requested resource.  When this RRM ASA
   receives a subsequent Request message, it should conduct a GRASP
   negotiation sequence, using Negotiate, Confirm Waiting, and
   Negotiation End messages as appropriate.  The Negotiate messages
   carry a ResourceManager Objective option with the resource value
   offered to the PRM ASA.

   +---------+ Negotiation Resource  +---------+
   | RRM ASA |<--------------------->| PRM ASA |
   +---------+                       +---------+    +------+    +------+
   |   SI    | --------------------->|   APE   |--->| Node |--->|  ST  |
   +---------+   Transmit data       +---------+    +------+    +------+

   Figure-3: An example of End-to-End Service

   PRM ASA processes receive resource requests and ensure the nodes
   resource it can manage.  When the RRM ASA receives a Negotiation
   response message, it should check whether the resource value in the
   Negotiate message is the same as the resource value requested.  If it
   is the same, the RRM ASA should send GRASP Negotiation End messages
   indicating that the negotiation was successful.  If it is not the
   same, the RRM ASA should communicate with the Service Initiator about
   the result and decide whether to accept this negotiation.  If
   accepting this negotiation, RRM ASA should send GRASP Negotiation End
   messages indicating that the negotiation was successful.  If not
   accepting this negotiation, it should send GRASP Negotiation End
   messages indicating that the negotiation fails.

Dang, et al.             Expires 9 January 2023                 [Page 9]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

    +----------+                                   +---------+
    | RRM ASA  |                                   | PRM ASA |
    +----------+ [[IP_A,IP_B,Service_tag][[0,10]]] +---------+
         |------------------------------------------->|
         |      [[IP_A,IP_B,Service_tag][[0,8]]]      |
         |<-------------------------------------------|
         |      [[IP_A,IP_B,Service_tag][[0,8]]]      |
         |------------------------------------------->|
         |          Negotiation End (ACCEPT)          |
         |<-------------------------------------------|

   Figure 4 shows an example of negotiation process.  In the first
   negotiation round, RRM ASA want to get 10 Mbit/s bandwidth from IP_A
   to IP_B, so the resource value is [0,10].  Zero means the resource
   type is bandwidth and ten is the value.  The message also include
   source and target IP and some service information.  PRM ASA can use
   service_tag to decide whether to provide these resources to services
   in the case of resource constraints.  When PRM ASA receives the
   message, if the PRM ASA think the network can offer this message to
   RRM ASA, it will response the ACCEPT.  But if it not response, it
   will give the RRM ASA request about how much resource it can offer.
   In this example, PRM ASA can offer 8 Mbit/s to RRM ASA.  The next
   step, RRM ASA needs to decide whether to change its resource
   requirements according to the reply.  And sends a next round
   negotiation.  And then PRM ASA deal the new resource requirement, it
   then the requirement it can offer.  So it will response ACCEPT.  This
   is an example about how ASAs negotiation resource.  And after
   negotiation, PRM ASA will build a hop-by-hop resource path for
   service.  And Service send data packet through this path.

   Figure-4: Example of Negotiation Process

6.2.  An example of multiple rounds

   In the process of automatic resource management mechanism, RRM ASA
   and PRM ASA are allowed to negotiate resources for multiple rounds.
   A very common situation is that the network resources can not meet
   the resources required by the service, but the service is willing to
   reduce its resource requirements to ensure the successful deployment
   of the service.  The PRM ASA using Resource Management Objectives
   contains the resources that the network can provide to the service
   present in the response message.  The RRM ASA changes the resource
   requirements according to the specific requirements of the received
   resources and services, to carry out the next round of service
   negotiation.

Dang, et al.             Expires 9 January 2023                [Page 10]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

6.3.  An example of multiple domain network

   In a multiple network, PRM ASA doesn't have the resource status of
   other domains.  So PRM ASA should negotiate with ASBR PRM ASA before
   response RRM ASA.  The PRM ASA should send a Confirm Waiting message
   to the RRM ASA, to extend its timeout.  When the new resource becomes
   available confirmed by ASBR, the PRM ASA responds with a GRASP
   Negotiate message with a resource value offered.  The process shows
   in Figure 5.  The Confirm Waiting message is described in
   Section 2.8.9 of [RFC8990].

    +----------+           +---------+
    | RRM ASA  |<--------->| PRM ASA |
    +----------+           +---------+        +--------------+
         |                 | RRM ASA |<------>| ASBR PRM ASA |
         |                 +---------+        +--------------+
         |Request Negotiation Message                 |
         |---------------------->|                    |
         |Waiting message        |                    |
         |<----------------------|                    |
         |                       | Request Negotiation Message
         |                       |------------------->|
         |                       | Negotiation message|
         |                       |<------------------ |
         | Negotiation message   |
         |<----------------------|

   Other processes between APE and ASBR are the same as between Service
   Initiator and APE.

   Figure-5: An example of a path-based resource negotiation

6.4.  An example of changing resource requirements

   After the process of automatic resource management mechanism, RRM ASA
   and PRM ASA are allowed to change and negotiate the resource
   requirements.  In the course of using network services, there will be
   service requirement change which will lead to the problem of network
   resource requirement change.  ResourceManager ASA needs to be able to
   handle resource changes in a timely manner to meet service
   requirements.

   During the renegotiation process, RRM ASA resends the service's
   resource requirements by using ResourceManager GRASP Objective.  And
   the resource renegotiation process does not require the use of the
   same PRM ASA as at the last negotiation on the mission.  PRM ASA
   receives the resource negotiation message and makes the
   determination.  If the resource requirements are lower than those

Dang, et al.             Expires 9 January 2023                [Page 11]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   allocated, the response confirms the information and releases the
   excess resources.  If more resources are required than have been
   allocated, the resource negotiation process follows Section 6.1.

   PRM ASA does not change existing resource allocation until
   negotiation on resource changes is complete.  After negotiation, PRM
   ASA makes changes to the resource pool by using response to the
   negotiated resource requirements and synchronizes them with other ASA
   nodes.

6.5.  An example of releasing resource requirements

   After the service is completed, a mechanism is needed to release
   network resources so that network resources can be used more
   efficiently.  This process can be seen as a change in resource
   requirements negotiation, where the resource requirements of the
   service to the network become zero.  A negotiation with PRM ASA was
   initiated by RRM ASA in SI to reduce the resource footprint of the
   service.  Upon completion of the negotiation, PRM ASA released the
   resources occupied by the service.

7.  Compatibility with Other Technologies

   This auto deployment mechanism support multi-round negotiation
   mechanim which improves the deployment success rate.  This mechanism
   is not available in other protocols

   A gateway device is used between the GRASP network and the MPLS
   network.  As is known, the RSVP belongs to the distribution mechanism
   for resource reservation, but it is only coupled with MPLS.  Then
   this device uses the GRASP protocol in the GRASP network, and the
   MPLS protocol in the MPLS network, so that resource information can
   be shared.

8.  Security Considerations

   It complies with GRASP security considerations.  Relevant security
   issues are discussed in [RFC8990].  The preferred security model is
   that devices are trusted following the secure bootstrap procedure
   [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994]
   is in place.

9.  IANA Considerations

   This document defines a new GRASP Objective option names:
   "ResourceManager" which is need to be added to the "GRASP Objective
   Names" registry.

Dang, et al.             Expires 9 January 2023                [Page 12]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

10.  Acknowledgements

   Valuable comments were received from Michael Richardson and Brian
   Carpenter.

11.  Normative References

   [I-D.ietf-mpls]
              "Multiprotocol Label Switching Architecture",
              <https://www.rfc-editor.org/info/rfc3031>.

   [I-D.ietf-spring-segment-routing]
              "Segment Routing Architecture",
              <https://www.rfc-editor.org/info/rfc8402>.

   [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>.

   [RFC8990]  "GeneRic Autonomic Signaling Protocol (GRASP)",
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8993]  "A Reference Model for Autonomic Networking",
              <https://www.rfc-editor.org/info/rfc8993>.

   [RFC8994]  "GeneRic Autonomic Signaling Protocol (GRASP)",
              <https://www.rfc-editor.org/info/rfc8994>.

Authors' Addresses

   Joanna Dang (editor)
   Huawei
   No.156 Beiqing Road
   Beijing
   P.R. China, 100095
   China
   Email: dangjuanna@huawei.com

   Sheng Jiang
   Huawei
   No.156 Beiqing Road
   Beijing
   P.R. China, 100095
   China
   Email: jiangsheng@huawei.com

Dang, et al.             Expires 9 January 2023                [Page 13]
Internet-Draft  An Autonomic Mechanism for Resource-base       July 2022

   Zongpeng Du
   China Mobile
   32 Xuanwumen West Street
   Beijing
   P.R. China, 100053
   China
   Email: duzongpeng@chinamobile.com

   Yujing (editor)
   Huawei
   No.156 Beiqing Road
   Beijing
   P.R. China, 100095
   China
   Email: zhouyujing3@huawei.com

Dang, et al.             Expires 9 January 2023                [Page 14]