[Anima] draft-ietf-anima-network-service-auto-deployment-06 comments

Toerless Eckert <tte@cs.fau.de> Thu, 02 May 2024 15:21 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B19C14F6BE; Thu, 2 May 2024 08:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjODqacMNL8b; Thu, 2 May 2024 08:21:23 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328B8C1516F3; Thu, 2 May 2024 08:21:15 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4VVd1f5mHBznkRs; Thu, 2 May 2024 17:21:10 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4VVd1f4W1HzknYH; Thu, 2 May 2024 17:21:10 +0200 (CEST)
Date: Thu, 02 May 2024 17:21:10 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: draft-ietf-anima-network-service-auto-deployment@ietf.org, anima-chairs@ietf.org
Cc: anima@ietf.org
Message-ID: <ZjOvZkSM9YMRkdDr@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uCAYc7UWdmxNegVuLBBluxlZXeo>
Subject: [Anima] draft-ietf-anima-network-service-auto-deployment-06 comments
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2024 15:21:27 -0000

Dear Authors

Thank you for this work. The document sounds and currently intends to target
a full standard specification for arbitrary services management via GRASP. I
think this is an unattainable goal. What i think is attainable is to outline
how to build such GRASP based signaling specifications, and for that the document
has good starting text, but it does not really well focus on that in comparison 
to e.g.: pre-existing methods.

If the resource is located on a single GRASP speaking node, such as maybe
storage, compute or memory, this is easy to imagine:

- One needs to figure out what the type of resource and the specific
  resource attributes are.

- One needs to figure out how to define objectives to find server nodes
  that meet those resource attirbute needs - aka: memory of a certain minimum
  size, and for example minimum speed, with or without persistance, etc. pp

- One then needs to define the GRASP objectives to request/negotiate and
  re-negotiate such a service consumption request.

- Finally, one has to define the GRASP objectives to consume such a resource,
  e.g. read/write actual memory. I guess this part is not necessarily part
  of the intended scope of this draft, but could use other pre-existing
  protocols, but it would help a lot of listing all thise bullet points and
  pointing this out explicitly.

The draft has some of these aspects covered, but it seems very incomplete and
in parts confusing. Primarily also because it simply enumerates a long list of
possible resources in section 8.2, but does not provide enough specification
to actually implement in GRASP any single such resource management solution,
because there are no mentioning of relevant attributes to show where GRASP
could be better than existing mechanisms.

More problematic though is the implication that this draft can support
resource management like RSVP, aka: services for path properties. But then it does
not explain how the resource management would work when like for a path, it
requires allocation of resources from multiple nodes together. Is there some
on-path signaling like in RSVP, NSIS ? Is there a central controller ? Does
it require some fixed path ? What happens when the path changes ? etc. pp.

And unlike compute, storage, memory resources, path resource management 
has a tremendous number of RFCs specifying thousands of details - around TE,
RSVP, RSVP-TE, PCE, Netconf/YANG and so on. And there is no comparison or
even specific claims of why this GRASP approach would be beneficial for any
scenario in which these existing solutions work or where it is understood that
they could be adopted to.

So, i think it would be very useful to discuss primarily the intended scope
of the document before going into further details of the text.

For example, i think it would be very helpful to constrain the scope single-node
resource management and discuss the path resource issues/complexities only
in an appendix like section, pointing to the variety of existing protocols from
IETF and suggesting if any, some of the benefits the GRASP approach could have.

If this makes sense, then i would also suggest to select some example service
and on each step of the document discuss example details of that service.

Ideally, the service in question would already have one or more existing
consumption protocols and the GRASP solution could be presented as a
unifying single protocol to do discovery, negotiation, selection. Specifically
highlighting, that GRASP has network-based discovery, so it can operate without
the need of prior discovery servers (e.g.; no need to set up a DNS-SD server or
CORE-SD server for example)

I am not sure what the lowest-hanging fruit for such a service would be, e.g.:
the type of service for which this management aspect is least well supported today.
I do not know a lot of details of remote memory access, but i can well imagine
how this mechanism could be nice for storage. On the other hand, for storage,
i can easily imagine a serious long list of service parameters ranging
from the consumption protocol (NFSv3, NFSv4, SMBv1, SMBv2, SMBv3, WebDAV, and a lot more),
connection parameters (TCP, UDP, credentials), resilience of storage, performance
parameters, maximum size, cost, number of files, maximum file size, etc. pp). And storage
of course would have the nice aspect that it would easily allow negotiation of several
of those parameters (such as maximum storage allowed, maximum through given to client, 
session credentials, sharing of the storage across multiple clients.

Aka: I think that as soon as we think of any specific service, it becomes clear
that this document can not be normative for even a small part of relevant spec
details, but can only point out how "easy" it is to use GRASP to define them. Aka:
include text about formal specification of the data model via CDDL, and easy
extensibility, etc. pp.

In the end it would be good to evolve this document into one that has enough
details of one service so that a minium interoperable implementation could be
built from it. Not because this should be seen as a complete specification, but only
to have a prac tical enough explanation that coders can make sense of it. And then
highlight the benefits of GRASP, e.g.: why not use other protocols:

- lightweight, binary encoded, appropriate for LLN up to SP core networks.
- In-network discovery - no need to have third-party (services server) dependencies
- Ability to find "closest" resource (network distance).
- separated security and transport substrate - can deploy GRASP on various such substrates
- CDDL formal specifications of data model
- easily extensible service properties (as compared to DNS-SD TXT record limits).
- negotation of consumption (not in DNS-SD, CORE-LF/CORE-SD).
...

And with this scope it would make a lot more sense to make this draft target informational.
If this makes sense then i can provide further detail feednback after you've tried to
come up with a version that attempts to re-scope the document this way.

If you want to keep the path-properties a core goal of the document than i'd
have to provide more feedback for that, but i think it would be a lot more work, and
much less likely to get through IETF.

Cheers
    Toerless



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

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

14	Abstract

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

27	Status of This Memo

29	   This Internet-Draft is submitted in full conformance with the
30	   provisions of BCP 78 and BCP 79.

32	   Internet-Drafts are working documents of the Internet Engineering
33	   Task Force (IETF).  Note that other groups may also distribute
34	   working documents as Internet-Drafts.  The list of current Internet-
35	   Drafts is at https://datatracker.ietf.org/drafts/current/.

37	   Internet-Drafts are draft documents valid for a maximum of six months
38	   and may be updated, replaced, or obsoleted by other documents at any
39	   time.  It is inappropriate to use Internet-Drafts as reference
40	   material or to cite them other than as "work in progress."

42	   This Internet-Draft will expire on 4 October 2024.

44	Copyright Notice

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

49	   This document is subject to BCP 78 and the IETF Trust's Legal
50	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
51	   license-info) in effect on the date of publication of this document.
52	   Please review these documents carefully, as they describe your rights
53	   and restrictions with respect to this document.  Code Components
54	   extracted from this document must include Revised BSD License text as
55	   described in Section 4.e of the Trust Legal Provisions and are
56	   provided without warranty as described in the Revised BSD License.

58	Table of Contents

60	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
61	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
62	   3.  Terminology & Abbreviations . . . . . . . . . . . . . . . . .   4
63	   4.  A Generic Auto-deployment Mechanism of Resource-based Network
64	           Services  . . . . . . . . . . . . . . . . . . . . . . . .   5
65	     4.1.  Discover RM ASA on Proper Service Responsers  . . . . . .   6
66	     4.2.  Authentication and Authorization  . . . . . . . . . . . .   6
67	     4.3.  Negotiate Resource with Service Responser . . . . . . . .   6
68	     4.4.  Change Reserved Resources . . . . . . . . . . . . . . . .   7
69	     4.5.  Releasing Resources during Service Ending . . . . . . . .   8
70	   5.  Autonomic Resource Management Objectives  . . . . . . . . . .   8
71	   6.  Process of the Quality Network Transmission Service
72	           Auto-deployment . . . . . . . . . . . . . . . . . . . . .  10
73	     6.1.  Quality Transmission Service Scenario & Service Type  . .  10
74	     6.2.  Negotiation between a Service Initiator and a Service
75	           Responser . . . . . . . . . . . . . . . . . . . . . . . .  11
76	     6.3.  Coordination among Multiple Service Responsers  . . . . .  12
77	     6.4.  Service Ending  . . . . . . . . . . . . . . . . . . . . .  12
78	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
79	   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
80	     8.1.  Service type  . . . . . . . . . . . . . . . . . . . . . .  13
81	     8.2.  Resource Type . . . . . . . . . . . . . . . . . . . . . .  13
82	   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
83	   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
84	     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
85	     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
86	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

88	1.  Introduction

90	   Traditionally, IP networks are based on the best-efforts model.  The
91	   IP layer does not reserve resources for upper-layer applications.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

nit: 
s/IP layer/IP protocols/

92	   However, more and more emerging applications that require quality
93	   services, such as video, VR, AR, and so on.  They need supports from
94	   steady network resources, such as bandwidth, queue, memory, priority,
95	   computational resources, etc.  On another side, from network side,
96	   more and more generic services, such as quality transmission
97	   services, in-network data cache services and computing services,
98	   etc., are starting to be deployed so that networks can serve these
99	   resource-consumption applications well.  These network services are

nit: 
Please provide references for "quality transmission services", "in-nework data cache services", etc..

100	   strongly based on the availability and stability of network
101	   resources.

103	   To enable these resource-based applications and services, IETF have
104	   developed many resource reservation mechanisms, such as RSVP
105	   [RFC2205] that is mainly to reserve bandwidth only and path-oriented,

nit:
When you say many, please cite at least one more example, ideally one most different
from RSVP.


106	   etc.  However, most of them are mainly for reservation during the
107	   deployment only and are rigid for dynamic adjustment.  Furthermore,

nit:
It is unclear what other than "during the deployment only" means. Please explain in text.

108	   most of them are dedicated for a certain type of network resources.

110	   This document introduces an enhanced and extensible mechanism that
111	   supports dynamically dispatching of network resources, using the
112	   GeneRic Autonomic Signaling Protocol (GRASP) defined in [RFC8990] to
113	   dynamically exchange the information among the autonomic nodes.  Its

nit:
Please explain what "enhanced" means - readers assume enhanced compared to RSVP,
or any other prior mentioned example, but how ?

114	   dynamic adjust ability is mainly enabled by the negotiation ability
115	   defined by [RFC8990].

117	   This mechanism is generic for most, if not all, of kinds of network

nit:
Generic itself is not very specific, but generic or not generic wrt. to a specific
network resource is even less clear. Please explain.

118	   resources.  It can be easily extended to support network services
119	   deployment and management that is based on other network resources.

nit: 
Other "network resources" than what network resource ? Please explain in text.

120	   It can be used, but no limited, in below network services scenarios:

122	   *  Quality transmission services.  The quality could means guaranteed

nit:
Please provide a reference or explain what "quality transmission services" means.

123	      bandwidth, or jitter, etc.  In order guarantee the quality of
124	      transmission services, the network should reserve transmission
125	      resource, particularly bandwidth or queues, on a selected path
126	      from the ingress to the egress node.  The dynamic resource
127	      dispatching mechanism should ensure the consistent of reserved
128	      resources on all the nodes in this path, particularly, when
129	      dynamic changes are operated on this path.

131	   *  Difference transmission services.  The network may provide

nit:
This probably should say "Differentiated Services" ?? If so, then please add
reference for DiffServ arch RFC, else explain or provide other reference for
what "Difference ... services" means.

132	      different transmission services by putting the user packets into
133	      different processes that have different resources, such as
134	      bandwidth, queue length, priority, etc.  The results would be
135	      different user experience in delay and jitter, or even packet lose
136	      rate.

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

nit:
Please provide a reference for any such network cache/storage service and any
existing means to manage their resources. I can imagine such a thing, but i am
not aware of anything in the IETF context (CDNI for example does not seem to
be about managing resources, but rather content). Likewise "idle memory" space.
It is unclear to me what even a simple example of network based memory
resource (idle or not) would be.

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

nit:
Same question about providing example reference.

If there are no useful referrences, then it would help to provide a simple
explanation of a use-case exemplifying such a service. E.g.: for memory
one could think of an application that needs more memory, so it tries to get
it from a "memory server" and consumes it via e.g.: proprietary protocols like
RoCEv2 (https://www.infinibandta.org/ibta-announces-new-roce-specification/)

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

nit:
reference and/or scenario.

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

nit:
We should always try to emphasize how the components provided by ANIMA can support
each other but can also be used independently, e.g.:

s/provide ..."/may provide the secure precodnitions for this mechanism/.
Nevertheless, the meachanism as presented is not dependent on them but can equally
be combined with other security mechanisms that support mutual authentication
between devices employing the mechanism proposed here.

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

165	2.  Requirements Language

167	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
168	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
169	   "OPTIONAL" in this document are to be interpreted as described in BCP
170	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
171	   capitals, as shown here.

173	3.  Terminology & Abbreviations

175	   This document uses terminology defined in [RFC7575].

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

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

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

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

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

212	                   |           Node Discovery           |
213	                   |- - - - - - - - - - - - - - - - - ->|
214	            +-----------------+               +-----------------+
215	            |      RM ASA     |               |      RM ASA     |
216	            |Service Initiator|               |Service Responser|
217	            +-----------------+ ASA Discovery +-----------------+
218	                   |----------------------------------->|
219	                   |  Authentication and Authorization  |
220	                   |----------------------------------->|
221	                   |            M_RESPONSE              |
222	                   |<-----------------------------------|
223	                   |                                    |
224	                   |     Multiple rounds Negotiation    |
225	                   |<---------------------------------->|
226	                   |      on Resource Availability      |
227	                   |                                    |
228	                   |               reserve the local resource
229	                   |                                    |
230	                  ...                                  ...
231	                   |   Coordination with other RM ASAs  |
232	                   |<---------------------------------->|
233	                  ...                                  ...
234	                   |           Service Ending           |
235	                   |<---------------------------------->|
236	                   |                       release resources

238	   Figure-1: generic procedures of autonomic deployment and management

240	4.1.  Discover RM ASA on Proper Service Responsers

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

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

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

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

267	4.2.  Authentication and Authorization

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

278	4.3.  Negotiate Resource with Service Responser

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

284	   When the RM ASA on a Service Responser receives a subsequent Request
285	   message, it SHOULD conduct a GRASP negotiation sequence, using
286	   Negotiate, Confirm Waiting, and Negotiation End messages as
287	   appropriate.  The Negotiate messages carry a Resource Manager
288	   Objective option, which will indicate the resource type and value
289	   offered to the requesting RM ASA.

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

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

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

311	4.4.  Change Reserved Resources

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

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

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

336	4.5.  Releasing Resources during Service Ending

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

350	5.  Autonomic Resource Management Objectives

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

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

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

368	   objective-name = "Resource Manager"

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

373	   loop-count = 0..255 ; as in the GRASP specification
374	   The 'objective-value' field expresses the actual value of a
375	   negotiation or synchronization objective.  So a new objective-value
376	   named autonomic-network-service-value is defined for Network Service
377	   Auto-deployment as follows.  The autonomic node can know that it is
378	   serving Network Service Auto-deployment according to the objective-
379	   value after receiving the GRASP message.  The 'objective value'
380	   contains two parts, one represents the information of the service
381	   itself, and the other represents the requirements of resources.

383	   objective-value = autonomic-network-service-value; An autonomic-
384	   network-service-value is defined as Figure-2.

386	    autonomic-network-service-value =
387	        [
388	         [
389	          service-type,
390	          service-id,
391	          service-lifetime,
392	          service-tag
393	          ],[
394	          *resource-requirement-pair
395	         ]
396	        ]

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

400	   service-type = 0..7

402	   service-id = uint

404	   service-lifetime = 0..4294967295 ; in milliseconds

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

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

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

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

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

428	   resource-requirement-pair =
429	        [
430	         resource-type,
431	         resource-value
432	        ]

434	   Figure-3: Format of resource-requirement-pair

436	   resource-type = 0..7

438	   resource-value = uint

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

442	6.1.  Quality Transmission Service Scenario & Service Type

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

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

459	                Negotiation Resource
460	    +-------------------------------------------------------------+
461	    |       Negotiation Resource                                  |
462	    | +--------------------------------------------+              |
463	    | |                                            |              |
464	 +--------+ Negotiation Resource +---------+   +---------+   +---------+
465	 | RM ASA |<-------------------->|  RM ASA |   |  RM ASA |   | RM ASA  |
466	 +--------+                      +---------+   +---------+   +---------+
467	 |  SI    | -------------------->| SR Node |-->| SR Node |-->| SR Node |
468	 +--------+   Transmit data      +---------+   +---------+   +---------+
469	   Figure-3 shows how RM ASAs negotiate resources and how Service
470	   Initiator forwards packages.  The RM ASA on the Service Initiator
471	   negotiates resources with the RM ASAs on the Service Responsers one
472	   by one.

474	   Figure-3: Negotiation procedure of a transmission service

476	6.2.  Negotiation between a Service Initiator and a Service Responser

478	   In the process of negotiation, Service Initiator negotiates resources
479	   with Service Responsers and ensures resources enough.  RM ASAs are
480	   allowed to negotiate resources for multiple rounds.  It often happens
481	   that the network resources on one node cannot meet the resources
482	   required by the service, but the service is willing to reduce its
483	   resource requirements to ensure the successful deployment of the
484	   service.  The RM ASAs on the Service Responsers feedback the maximum
485	   available resources using Resource Management Objectives in the
486	   response message.  The RM ASA on the Service Initiator changes the
487	   resource requirements according to the specific requirements of the
488	   received resources and services, to carry out the next round of
489	   service negotiation.

491	    +----------+                                   +---------+
492	    |  RM ASA  |                                   | RM ASA  |
493	    +----------+                                   +---------+
494	    |    SI    |                                   | SR Node |
495	    +----------+ [[0,36732,3600000,[]][[0,10]]]    +---------+
496	         |------------------------------------------->|
497	         |      [[0,36732,3600000,[]][[0,8]]]         |
498	         |<-------------------------------------------|
499	         |      [[0,36732,3600000,[]][[0,8]]]         |
500	         |------------------------------------------->|
501	         |          Negotiation End (ACCEPT)          |
502	         |<-------------------------------------------|

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

512	   Figure-4: an example of a negotiation process

514	   When RM ASA on the Service Responser Node receives the message, if
515	   the RM ASA thinks the network can offer this required resource, it
516	   will response the ACCEPT.  But if it does not meet the request, it
517	   will give how much resource it can offer.  In this example, the
518	   Service Responser can offer 8 Mbit/s.  The next step, RM ASA on the
519	   Service Initiator needs to decide whether to change its resource
520	   requirements according to the reply, and sends a next round
521	   negotiation.  Then, RM ASA on the Service Responser finds the new
522	   resource requirement, it can meet.  So, it will response ACCEPT.
523	   This is an example how ASAs negotiate resources.

525	6.3.  Coordination among Multiple Service Responsers

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

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

538	6.4.  Service Ending

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

547	7.  Security Considerations

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

555	8.  IANA Considerations

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

564	8.1.  Service type

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

570	   *  0 : Transmission Service

572	   *  1 : Computing Service

574	8.2.  Resource Type

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

579	   *  0 : bandwidth

581	   *  1 : queue

583	   *  2 : memery

585	   *  3 : priority

587	   *  4 : cache

589	   *  5 : computing

591	9.  Acknowledgements

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

597	10.  References

599	10.1.  Normative References

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

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

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

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

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

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

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

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

641	10.2.  Informative References

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

649	Authors' Addresses

651	   Sheng Jiang (editor)
652	   Beijing University of Posts and Telecommunications
653	   No. 10 Xitucheng Road
654	   Beijing
655	   Haidian District, 100083
656	   China
657	   Email: shengjiang@bupt.edu.cn
658	   Joanna Dang
659	   Huawei
660	   No.156 Beiqing Road
661	   Beijing
662	   P.R. China, 100095
663	   China
664	   Email: dangjuanna@huawei.com

666	   Zongpeng Du
667	   China Mobile
668	   32 Xuanwumen West Street
669	   Beijing
670	   P.R. China, 100053
671	   China
672	   Email: duzongpeng@chinamobile.com