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

'Toerless Eckert' <tte@cs.fau.de> Tue, 21 May 2024 15:19 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 227ADC14F6A7; Tue, 21 May 2024 08:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, 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 u52Q6vXz2hgB; Tue, 21 May 2024 08:19:46 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 F2B02C14F680; Tue, 21 May 2024 08:19:42 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.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 4VkJ546bwVznkTC; Tue, 21 May 2024 17:19:36 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4VkJ545cC4zknkD; Tue, 21 May 2024 17:19:36 +0200 (CEST)
Date: Tue, 21 May 2024 17:19:36 +0200
From: 'Toerless Eckert' <tte@cs.fau.de>
To: Sheng JIANG <shengjiang@bupt.edu.cn>
Message-ID: <Zky7iGWFFFRi30fB@faui48e.informatik.uni-erlangen.de>
References: <ZjOvZkSM9YMRkdDr@faui48e.informatik.uni-erlangen.de> <C0CC45892178526D+050101da9dba$6444cf80$2cce6e80$@bupt.edu.cn> <ZkOLloBmWLumxVtY@faui48e.informatik.uni-erlangen.de> <60FB9E66597B2CB6+011d01daa75e$6dc51d50$494f57f0$@bupt.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <60FB9E66597B2CB6+011d01daa75e$6dc51d50$494f57f0$@bupt.edu.cn>
Message-ID-Hash: MA56ARIY5IQ33NNQ5B25YFPMB4BKM4AO
X-Message-ID-Hash: MA56ARIY5IQ33NNQ5B25YFPMB4BKM4AO
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-anima-network-service-auto-deployment@ietf.org, anima-chairs@ietf.org, anima@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: draft-ietf-anima-network-service-auto-deployment-06 comments
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wh1_HbGYeSeg639944YVxEtZhJ4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

On Thu, May 16, 2024 at 02:58:15PM +0800, Sheng JIANG wrote:
> Hi, Toerless,
> 
> Thanks for your further suggestion. It is fair to have a specific resource
> deployment as a proof example alongside the framework document. Storage
> could be one. Actually, I am thinking computing resource may be even more
> straight forward as the newly merged resource have not been explored a lot.
> I will talk around to my friends in carriers and vendors to find some people
> who are interested to work on this with me. Meanwhile, I will try to
> modified the current document towards an informational framework/guidance
> document. By the way, I guess our prefix management could also be an example
> if we take prefix availability as a type of network resource.

Thanks, Sheng

There is also CATS WG which may be an adjacency and/or place to position this GRASP 
work in relationship to compute.

Then again, it is a lot more likely that the members of that WG have already their own
solution and protocol framework in mind. Alas i forgot all the technical details
since i last looked into CATS effort before the WG was formed...

Cheers
    Toerless

> Cheers,
> 
> Sheng
> 
> > -----Original Message-----
> > From: forwardingalgorithm@ietf.org <forwardingalgorithm@ietf.org> On
> > Behalf Of 'Toerless Eckert'
> > Sent: Wednesday, May 15, 2024 12:05 AM
> > To: Sheng JIANG <shengjiang@bupt.edu.cn>
> > Cc: draft-ietf-anima-network-service-auto-deployment@ietf.org;
> > anima-chairs@ietf.org; anima@ietf.org
> > Subject: Re: [Anima] draft-ietf-anima-network-service-auto-deployment-06
> > comments
> > 
> > Sheng,
> > 
> > I think it would be good to create a well received proof point for one
> type of
> > resource first - for example RAM or storage. These two are also services
> where
> > we might approach COINRG and/or NFSv4 WG to get feedback,
> > e.g.: ask for a slot to ask what they think.
> > 
> > Ultimetely, in the IETF, the hard job is always to find the lowest hanging
> > practical fruit that someone actually would want to implement. Finding,
> > selecting and aquiring/releasing some resources like this might be one
> such low
> > hanging fruit - but we will only know if/when we talk to folks who are
> closer to
> > those use-cases than i think we are right now.
> > 
> > The path based stuff would IMHO require for someone with a lot more TEAS
> > involvement to help/be-interested. Otherwise i fear we'd be faced with the
> > challenge of explaining how the work relates to TEAS, and we likely
> wouldn't
> > have a good answer withou doing such an engagement.
> > 
> > Cheers
> >     Toerless
> > 
> > On Sat, May 04, 2024 at 08:31:20AM +0800, Sheng JIANG wrote:
> > > Hi, Toerless,
> > >
> > > Thanks so much for this great comments. It is very valuable and
> > > constructive. This draft was initiated by end-to-end deterministic
> > > forwarding service. I was too ambitious to make it generic, even I
> > > knew generic was very difficult. Later, we got lost between the
> > > specific use case and a generic mechanism. We got further lost when it
> came
> > to path-oriented.
> > > It is a lot more complicated using node-by-node negotiation mechanism
> > > to make up a multiple-node path-oriented mechanism than a single-round
> > > path-through mechanism.
> > >
> > > Actually, like we mentioned, there is a lot network resources that can
> > > make up various services. Therefore, these seems to be worth a series
> > > of documents. And beyond the potential documents each focuses on a
> > > specific solution, there should be an informational framework
> > > document. It could be the direction to modify this document, if
> > > agreed. This would be feasible with minimum modification in an
> > > acceptable timeline, I think. Another specific-resource document,
> > > which had better not be path-oriented, should be also started as an use
> case
> > of such framework.
> > >
> > > How do you think?
> > >
> > > Best regards,
> > >
> > > Sheng
> > >
> > > > -----Original Message-----
> > > > From: Anima <anima-bounces@ietf.org> On Behalf Of Toerless Eckert
> > > > Sent: Thursday, May 2, 2024 11:21 PM
> > > > To: draft-ietf-anima-network-service-auto-deployment@ietf.org;
> > > > anima-chairs@ietf.org
> > > > Cc: anima@ietf.org
> > > > Subject: [Anima] draft-ietf-anima-network-service-auto-deployment-06
> > > > comments
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Anima mailing list
> > > > Anima@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/anima
> > >
> > 
> > --
> > ---
> > tte@cs.fau.de
> 
> 

-- 
---
tte@cs.fau.de