A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services
draft-ietf-anima-network-service-auto-deployment-06

ANIMA                                                      S. Jiang, Ed.
Internet-Draft                                                      BUPT
Intended status: Standards Track                                 J. Dang
Expires: 4 October 2024                                           Huawei
                                                                   Z. Du
                                                            China Mobile
                                                            2 April 2024

 A Generic Autonomic Deployment and Management Mechanism for Resource-
                         based Network Services
          draft-ietf-anima-network-service-auto-deployment-06

Abstract

   This document specifies an autonomic mechanism for resource-based
   network services deployment and management, using the GeneRic
   Autonomic Signaling Protocol (GRASP) to dynamically exchange the
   information among the autonomic nodes.  It supports the coordination
   and consistently operations within an autonomic network domain.  This
   mechanism is generic for most, if not all, of kinds of network
   resources, although this document only defines the process of quality
   transmission service deployment and management.  It can be easily
   extended to support network services deployment and management that
   is based on other types of network resources.

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 4 October 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jiang, et al.            Expires 4 October 2024                 [Page 1]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology & Abbreviations . . . . . . . . . . . . . . . . .   4
   4.  A Generic Auto-deployment Mechanism of Resource-based Network
           Services  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Discover RM ASA on Proper Service Responsers  . . . . . .   6
     4.2.  Authentication and Authorization  . . . . . . . . . . . .   6
     4.3.  Negotiate Resource with Service Responser . . . . . . . .   6
     4.4.  Change Reserved Resources . . . . . . . . . . . . . . . .   7
     4.5.  Releasing Resources during Service Ending . . . . . . . .   8
   5.  Autonomic Resource Management Objectives  . . . . . . . . . .   8
   6.  Process of the Quality Network Transmission Service
           Auto-deployment . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Quality Transmission Service Scenario & Service Type  . .  10
     6.2.  Negotiation between a Service Initiator and a Service
           Responser . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.3.  Coordination among Multiple Service Responsers  . . . . .  12
     6.4.  Service Ending  . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Service type  . . . . . . . . . . . . . . . . . . . . . .  13
     8.2.  Resource Type . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Traditionally, IP networks are based on the best-efforts model.  The
   IP layer does not reserve resources for upper-layer applications.
   However, more and more emerging applications that require quality
   services, such as video, VR, AR, and so on.  They need supports from
   steady network resources, such as bandwidth, queue, memory, priority,
   computational resources, etc.  On another side, from network side,
   more and more generic services, such as quality transmission

Jiang, et al.            Expires 4 October 2024                 [Page 2]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   services, in-network data cache services and computing services,
   etc., are starting to be deployed so that networks can serve these
   resource-consumption applications well.  These network services are
   strongly based on the availability and stability of network
   resources.

   To enable these resource-based applications and services, IETF have
   developed many resource reservation mechanisms, such as RSVP
   [RFC2205] that is mainly to reserve bandwidth only and path-oriented,
   etc.  However, most of them are mainly for reservation during the
   deployment only and are rigid for dynamic adjustment.  Furthermore,
   most of them are dedicated for a certain type of network resources.

   This document introduces an enhanced and extensible mechanism that
   supports dynamically dispatching of network resources, using the
   GeneRic Autonomic Signaling Protocol (GRASP) defined in [RFC8990] to
   dynamically exchange the information among the autonomic nodes.  Its
   dynamic adjust ability is mainly enabled by the negotiation ability
   defined by [RFC8990].

   This mechanism is generic for most, if not all, of kinds of network
   resources.  It can be easily extended to support network services
   deployment and management that is based on other network resources.
   It can be used, but no limited, in below network services scenarios:

   *  Quality transmission services.  The quality could means guaranteed
      bandwidth, or jitter, etc.  In order guarantee the quality of
      transmission services, the network should reserve transmission
      resource, particularly bandwidth or queues, on a selected path
      from the ingress to the egress node.  The dynamic resource
      dispatching mechanism should ensure the consistent of reserved
      resources on all the nodes in this path, particularly, when
      dynamic changes are operated on this path.

   *  Difference transmission services.  The network may provide
      different transmission services by putting the user packets into
      different processes that have different resources, such as
      bandwidth, queue length, priority, etc.  The results would be
      different user experience in delay and jitter, or even packet lose
      rate.

   *  In network cache/storage services.  The network may provide cache
      or storage service by memory in the network devices or attached
      devices.  The idle memory space is the resource that need to be
      request and managed.  The location or distance of the memory is
      also relevant to user experience.

Jiang, et al.            Expires 4 October 2024                 [Page 3]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   *  Computing services.  More and more spare computational resources
      are from network providers.  They may be idle computational cycles
      on the network devices or deployed computational servers.  The
      occupation of these computational resources are time-sensitive.
      Also, the location or distance of the computational resource is
      relevant to user experience.

   *  Information services.  In some scenarios, network may be the best
      information provider.  It may be the information are from or
      generated by network itself.  Or the network has the best location
      to provide the information.

   The Autonomic Control Plane (ACP) [RFC8994] and the Bootstrapping
   Remote Secure Key Infrastructure (BRSKI) [RFC8995] provide the secure
   precondition for this mechanism.

   This document defines an Autonomic Resource Management Objective in
   Section 5.  Three new corresponding registries are defined in
   Section 8.  This document defines the process of quality transmission
   service deployment and management in Section 6.

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] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology & Abbreviations

   This document uses terminology defined in [RFC7575].

   RM ASA: the Resource Manager ASA on an autonomic nodes.  It manages
   the local resources on the node, such as bandwidth, queue, memory,
   priority, computational resources, etc.  The RM ASA communicate with
   other counterpart RM ASAs in order to dynamically dispatch network
   resources within the autonomic network domain.  This document assumes
   all autonomic nodes have a RM ASA.

   Service Initiator: the autonomic node that initiates and manages a
   network service.  It requests and dynamically adjusts the resources
   of this network service through its RM ASA.  Normally, a network
   service SHALL have one service initiator within an autonomic network
   domain.  However, multiple Service Initiators model MAY also
   operational if there were good synchronous or coordinate mechanisms
   among them.

Jiang, et al.            Expires 4 October 2024                 [Page 4]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   Service Responser: the autonomic node that responses to the requests
   from the Service Initiator.  It receives the requests through its RM
   ASA, checks or operates on its local resources, and responds the
   results to the Service Initiator.  Typically, a network service MAY
   involve multiple Service Responser.  The consistency among them are
   the responsibility of the Service Initiator.

4.  A Generic Auto-deployment Mechanism of Resource-based Network
    Services

   This section describes the generic procedures of autonomic deployment
   and management of the resource-based network services, as Figure1
   shows.  The detailed implementation or internal algorithms of the
   Resource Manager ASAs are out of scope of this document.  This
   section does not cover the specific details that depend on certain
   network services or certain type of network resources.  The
   prepositive operation that indicates the Service Initiator to start
   the service deployment are out of scope.  The information or reasons
   that trigger the dynamic service changes are also out of scope.

                   |           Node Discovery           |
                   |- - - - - - - - - - - - - - - - - ->|
            +-----------------+               +-----------------+
            |      RM ASA     |               |      RM ASA     |
            |Service Initiator|               |Service Responser|
            +-----------------+ ASA Discovery +-----------------+
                   |----------------------------------->|
                   |  Authentication and Authorization  |
                   |----------------------------------->|
                   |            M_RESPONSE              |
                   |<-----------------------------------|
                   |                                    |
                   |     Multiple rounds Negotiation    |
                   |<---------------------------------->|
                   |      on Resource Availability      |
                   |                                    |
                   |               reserve the local resource
                   |                                    |
                  ...                                  ...
                   |   Coordination with other RM ASAs  |
                   |<---------------------------------->|
                  ...                                  ...
                   |           Service Ending           |
                   |<---------------------------------->|
                   |                       release resources

   Figure-1: generic procedures of autonomic deployment and management

Jiang, et al.            Expires 4 October 2024                 [Page 5]
Internet-Draft     Auto-Deployment of Network Services        April 2024

4.1.  Discover RM ASA on Proper Service Responsers

   The Service Initiator MAY first discover the relevant network nodes
   according to the service setup in order to reduce the node range of
   sending GRASP Discovery message.  It may be all the nodes on a giving
   path or nodes that have idle resource available for giving service
   condition, etc.  The node discover methods can be pre-configured,
   outbound discover, path detection, etc.

   The Service Initiator SHOULD send out a GRASP Discovery message that
   contains a Resource Manager Objective option defined in Section 5, in
   which the network service is described.  The Discovery message SHOULD
   send to the reduced range nodes, by abovementioned mechanism, or all
   nodes within the AN domain.

   A RM ASA that receives the Discovery message with the Resource
   Manager Objective option SHOULD check its satisfaction against the
   service description.  If meet, the node is a proper Service
   Responser.  It SHOULD respond a GRASP Response message back to the
   Service Initiator.

   Defined in the section 2.5.5.1 of [RFC8990], the Discovery message
   MAY combine with the below negotiation process, if the rapid
   negotiation function has been enabled network wide.  If the rapid
   negotiation function has been disabled, the process would fall back
   to the normal discovery-only process.

4.2.  Authentication and Authorization

   In principle, any operations on resources MUST be authorized.  The
   Service Responser SHOULD check the authentication of the Service
   Initiator and the authorization information for the operation it
   requests.  This document assumes all autonomic nodes within the AN
   domain have been authenticated and their requested operations are
   authorized, giving the Autonomic Control Plane (ACP) [RFC8994] and
   the Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
   has provided the secure environment for this mechanism.

4.3.  Negotiate Resource with Service Responser

   After the discovery step, the RM ASA on the Service Initiator sends a
   GRASP Request message with a Resource Manager Objective option, in
   which the value of the requested resource is indicated.

Jiang, et al.            Expires 4 October 2024                 [Page 6]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   When the RM ASA on a Service Responser 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 Resource Manager
   Objective option, which will indicate the resource type and value
   offered to the requesting RM ASA.

   During the negotiation, the RM ASA on the Service Responser will
   decide at each step how much resource can be offered.  That decision,
   and the decision to end the negotiation, are implementation choices.
   A resource shortage on the Service Responser may cause it to indicate
   the existing available value within a Resource Manager Objective
   option back to the Service Initiator.  The Service Initiator might
   decide whether to accept the request of the resource.  If not, the RM
   ASA on the Service Initiator MAY terminate the negotiation via
   Negotiation End messages.

   Upon completion of the negotiation, the Service Responser reserves
   its local resources.  The Service Initiator may use the negotiated
   resource after receiving synchronization message without further
   messages.

   Normally, a network service SHALL have one service initiator within
   an autonomic network domain.  It is the Service Initiator's
   responsibility to manage the service and coordinate among multiple
   Service Responsers to ensure the consistent of reserved resources.

4.4.  Change Reserved Resources

   After the process of automatic resource management mechanism, RM ASAs
   are allowed to change and negotiate the resource requirements.  In
   the lifetime of network services, there may be many reasons that the
   service has to be changed upon with its reserved resources.  Resource
   Manager ASA needs to be able to handle resource changes in a timely
   manner to meet service requirements.

   During the renegotiation process, RM ASA on the Service Initiator
   resends the service's resource requirements by using Resource Manager
   GRASP Objective.  RM ASA on the Service Responser receives the
   resource negotiation message and makes the determination.  If the
   resource requirements are lower than those allocated or/and less
   lifetime than previous, the Service Responser SHOULD directly confirm
   the information and release the excess resources.  If more resources
   or lifetime are required, RM ASA on the Service Responser SHOULD
   treat it as a brand-new request and make decision or further
   negotiation.  The bottom line is the Service Responser MUST allow the
   Service Initiator fall back to previous allocated resource, both on
   volume and lifetime.

Jiang, et al.            Expires 4 October 2024                 [Page 7]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   RM ASAs on the Service Responsers MUST NOT change existing resource
   allocation until the new negotiation on resource changes is complete.

4.5.  Releasing Resources during Service Ending

   After the service is completed or expired, the reserved network
   resources MUST be released so that network resources can be used more
   efficiently.  If the service lifetime expires, the Service Responser
   MUST release its local resources and MAY send a Synchronization
   message to the Service Initiator to notify the state change of its
   local resources.  If the Service Initiator wants to end the service
   before the service lifetime expires, the Service Initiator MUST send
   a negotiation message to the Service Responsers to request the
   network resource to be changed to zero.  Upon completion of the
   negotiation, the Service Responser releases the resources occupied by
   the service.

5.  Autonomic Resource Management Objectives

   This section defines the GRASP technical objective options that are
   used to support autonomic resource management.  Resource Manager
   GRASP Objective allows multiple types of resources to be requested
   simultaneously.

   The Resource Manager Objective option is a GRASP Objective option
   conforming to the GRASP specification [RFC8990].  Its name is
   "Resource Manager", 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 Resource
   Manager Objective option is described in the Concise Data Definition
   Language (CDDL) [RFC8610] as follows:

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

   objective-name = "Resource Manager"

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

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

Jiang, et al.            Expires 4 October 2024                 [Page 8]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   The 'objective-value' field expresses the actual value of a
   negotiation or synchronization objective.  So a new objective-value
   named autonomic-network-service-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 = autonomic-network-service-value; An autonomic-
   network-service-value is defined as Figure-2.

    autonomic-network-service-value =
        [
         [
          service-type,
          service-id,
          service-lifetime,
          service-tag
          ],[
          *resource-requirement-pair
         ]
        ]

   Figure-2: Format of autonomic-network-service-value-value

   service-type = 0..7

   service-id = uint

   service-lifetime = 0..4294967295 ; in milliseconds

   service-tag = [ *service-tag-info]

   The combination service-type and the service-id MUST uniquely
   represent a network service within the network.  The uniqueness of
   the combination service-type and the service-id SHOULD be guaranteed
   by an allocation mechanism that is out of scope of this document.

   The allocation of resources MUST specify the lifetime.  The service-
   lifetime represents the usage time of the resources required by the
   service.

   The service-tag contains other information that describes the
   service.  This information is not necessary, but will affect the
   policy for RM ASA resource reservation.

Jiang, et al.            Expires 4 October 2024                 [Page 9]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   The resource-requirement-pair describes the resource requirements and
   it is defined as Figure-3.  Resource requirements of different types
   can be described in an objective option.  The Resource Manager
   objective option supports multi-faceted resource requirements and
   negotiation.  These resource requirements are all in pairs, described
   by resource type and resource value.

   resource-requirement-pair =
        [
         resource-type,
         resource-value
        ]

   Figure-3: Format of resource-requirement-pair

   resource-type = 0..7

   resource-value = uint

6.  Process of the Quality Network Transmission Service Auto-deployment

6.1.  Quality Transmission Service Scenario & Service Type

   The quality transmission service scenario is the most important
   resource negotiation scenario.  In this scenario, RM ASAs negotiate
   the resource that will affect the transmission quality.  The basic
   resource is bandwidth and other types of resources such as queue can
   be required at the same time.

   The autonomic deployment and management of the quality transmission
   service includes the Service Initiator and the Service Responsers all
   have RM ASA.  The Service Initiator is the resource demander, which
   ensures the connection of services through negotiation resources with
   RM ASAs in the domain network.  Service Responsers are the nodes
   which packets are forwarded in the transmission scenario and Service
   Initiator asks resource from them.  These nodes can be discovered
   through RM ASA discovery process or path discovery methods.

                Negotiation Resource
    +-------------------------------------------------------------+
    |       Negotiation Resource                                  |
    | +--------------------------------------------+              |
    | |                                            |              |
 +--------+ Negotiation Resource +---------+   +---------+   +---------+
 | RM ASA |<-------------------->|  RM ASA |   |  RM ASA |   | RM ASA  |
 +--------+                      +---------+   +---------+   +---------+
 |  SI    | -------------------->| SR Node |-->| SR Node |-->| SR Node |
 +--------+   Transmit data      +---------+   +---------+   +---------+

Jiang, et al.            Expires 4 October 2024                [Page 10]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   Figure-3 shows how RM ASAs negotiate resources and how Service
   Initiator forwards packages.  The RM ASA on the Service Initiator
   negotiates resources with the RM ASAs on the Service Responsers one
   by one.

   Figure-3: Negotiation procedure of a transmission service

6.2.  Negotiation between a Service Initiator and a Service Responser

   In the process of negotiation, Service Initiator negotiates resources
   with Service Responsers and ensures resources enough.  RM ASAs are
   allowed to negotiate resources for multiple rounds.  It often happens
   that the network resources on one node cannot 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 RM ASAs on the Service Responsers feedback the maximum
   available resources using Resource Management Objectives in the
   response message.  The RM ASA on the Service Initiator changes the
   resource requirements according to the specific requirements of the
   received resources and services, to carry out the next round of
   service negotiation.

    +----------+                                   +---------+
    |  RM ASA  |                                   | RM ASA  |
    +----------+                                   +---------+
    |    SI    |                                   | SR Node |
    +----------+ [[0,36732,3600000,[]][[0,10]]]    +---------+
         |------------------------------------------->|
         |      [[0,36732,3600000,[]][[0,8]]]         |
         |<-------------------------------------------|
         |      [[0,36732,3600000,[]][[0,8]]]         |
         |------------------------------------------->|
         |          Negotiation End (ACCEPT)          |
         |<-------------------------------------------|

   Figure-4 shows an example of a negotiation process.  In the first
   negotiation round, RM ASA on the Service Initiator wants to get
   resource from RM ASA on the Service Responsers.  In this example, the
   service type is Transmission Service and service-id is 36732.  The
   service will last 3600 seconds and only ask for one kind of resource
   10 Mbit/s bandwidth.  So, the autonomic-network-service-value is
   [[0,36732,3600000,[]][[0,10]]].

   Figure-4: an example of a negotiation process

   When RM ASA on the Service Responser Node receives the message, if
   the RM ASA thinks the network can offer this required resource, it
   will response the ACCEPT.  But if it does not meet the request, it

Jiang, et al.            Expires 4 October 2024                [Page 11]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   will give how much resource it can offer.  In this example, the
   Service Responser can offer 8 Mbit/s.  The next step, RM ASA on the
   Service Initiator needs to decide whether to change its resource
   requirements according to the reply, and sends a next round
   negotiation.  Then, RM ASA on the Service Responser finds the new
   resource requirement, it can meet.  So, it will response ACCEPT.
   This is an example how ASAs negotiate resources.

6.3.  Coordination among Multiple Service Responsers

   The Service Initiator decides a coordinated value of resource and
   negotiates with multiple Service Responsers that need to reduce the
   locked resource.  The Service Responsers reserve resources for
   service according to the negotiation results.  If the operation is
   successful, the Service Responser reply success message to the
   Service Initiator.  If it fails, reply failure message to the Service
   Initiator.  And the Service Initiator will restart negotiation step.

   When the Service Initiator receives the success message from all the
   Service Responsers, the service can start to transmit the message.

6.4.  Service Ending

   When the service is ended, it is the responsibility of Service
   Initiator to release all reserved resources through the dialogue with
   the RM ASA on the Service Responser.  And if the service lifetime is
   exceeded, the Service Initiator SHOULD also release reserved resource
   although the Service Responsers may release the reserved resource by
   themselves.

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

8.  IANA Considerations

   This document defines a new GRASP Objective option names: "Resource
   Manager" which need to be added to the "GRASP Objective Names"
   registry defined by [RFC8990].  And this document defines a new
   registry tables "service-type" and "resource-type" under the
   "Resource Manager" GRASP Objective.  The following subsections
   describe the new parameters.

Jiang, et al.            Expires 4 October 2024                [Page 12]
Internet-Draft     Auto-Deployment of Network Services        April 2024

8.1.  Service type

   IANA has set up the "service-type" registry, which contains 4-bit
   value.  The service-type defines the type of service which is used to
   describe the type of resource requirements.

   *  0 : Transmission Service

   *  1 : Computing Service

8.2.  Resource Type

   IANA has set up the "resource-type" registry, which contains 4-bit
   value.

   *  0 : bandwidth

   *  1 : queue

   *  2 : memery

   *  3 : priority

   *  4 : cache

   *  5 : computing

9.  Acknowledgements

   Valuable comments were received from Michael Richardson and Brian
   Carpenter.  Contributions to early versions of this document was made
   by Yujing Zhou.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

Jiang, et al.            Expires 4 October 2024                [Page 13]
Internet-Draft     Auto-Deployment of Network Services        April 2024

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

10.2.  Informative References

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

Authors' Addresses

   Sheng Jiang (editor)
   Beijing University of Posts and Telecommunications
   No. 10 Xitucheng Road
   Beijing
   Haidian District, 100083
   China
   Email: shengjiang@bupt.edu.cn

Jiang, et al.            Expires 4 October 2024                [Page 14]
Internet-Draft     Auto-Deployment of Network Services        April 2024

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

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

Jiang, et al.            Expires 4 October 2024                [Page 15]