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

[Brian E Carpenter <[e-mail]>]

On 16-May-24 18:58, 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.

Yes. If you remember, I wrote a demo application of prefix management, and if integrated with DHCPv6-PD it should work. I haven't touched the code for several years, but it is still at https://github.com/becarpenter/graspy/blob/master/ASA-examples/pfxm4.py

If you need a good project for a student, it is right there, to add support for PD, as described in RFC 8992.

There is even some partly obsolete documentation at https://github.com/becarpenter/graspy/blob/master/documentation/pfxm3.pdf.

It doesn't strictly conform to RFC 8992, since it was written before the RFC was finalized. Also, of course, although the algorithm is distributed it needs a single source, called the Origin ASA, presumably in the NOC, that provides valid prefixes.

    Brian


> 
> 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]
> 
> 
> _______________________________________________
> Anima mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]