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

[Sheng JIANG <[e-mail]>]

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

Yes, CATS is working on computing relevant. They are working on "how the
network edge can steer traffic between clients and network computing service."

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

I believe our problem here is much narrower than CATS or different. We are mostly
care about only availability of computing resources on the service side while CATS 
are considering more complicated situation including network metrics and 
transport of traffics. I also believe CATS solution could benefit from our efforts if we
made it.

I know people who initiated CATS well. I will talk with them.

Regards,

Sheng

> 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: [e-mail] <[e-mail]> On
> > > Behalf Of 'Toerless Eckert'
> > > Sent: Wednesday, May 15, 2024 12:05 AM
> > > To: Sheng JIANG <[e-mail]>
> > > Cc: [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 <[e-mail]> On Behalf Of Toerless Eckert
> > > > > Sent: Thursday, May 2, 2024 11:21 PM
> > > > > To: [e-mail];
> > > > > [e-mail]
> > > > > Cc: [e-mail]
> > > > > 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: [e-mail]
> > > > > 658	   Joanna Dang
> > > > > 659	   Huawei
> > > > > 660	   No.156 Beiqing Road
> > > > > 661	   Beijing
> > > > > 662	   P.R. China, 100095
> > > > > 663	   China
> > > > > 664	   Email: [e-mail]
> > > > >
> > > > > 666	   Zongpeng Du
> > > > > 667	   China Mobile
> > > > > 668	   32 Xuanwumen West Street
> > > > > 669	   Beijing
> > > > > 670	   P.R. China, 100053
> > > > > 671	   China
> > > > > 672	   Email: [e-mail]
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Anima mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/anima
> > > >
> > >
> > > --
> > > ---
> > > [e-mail]
> >
> >
> 
> --
> ---
> [e-mail]
> 
> _______________________________________________
> Anima mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]