On Thu, May 16, 2024 at 02:58:15PM +0800, Sheng JIANG wrote:
> Hi, Toerless,
>
> Thanks for your further suggestion. It is fair to have a specific resource
> deployment as a proof example alongside the framework document. Storage
> could be one. Actually, I am thinking computing resource may be even more
> straight forward as the newly merged resource have not been explored a lot.
> I will talk around to my friends in carriers and vendors to find some people
> who are interested to work on this with me. Meanwhile, I will try to
> modified the current document towards an informational framework/guidance
> document. By the way, I guess our prefix management could also be an example
> if we take prefix availability as a type of network resource.
Thanks, Sheng
There is also CATS WG which may be an adjacency and/or place to position this
GRASP
work in relationship to compute.
Then again, it is a lot more likely that the members of that WG have already
their own
solution and protocol framework in mind. Alas i forgot all the technical details
since i last looked into CATS effort before the WG was formed...
Cheers
Toerless
> Cheers,
>
> Sheng
>
> > -----Original Message-----
> > From: [email protected] <[email protected]> On
> > Behalf Of 'Toerless Eckert'
> > Sent: Wednesday, May 15, 2024 12:05 AM
> > To: Sheng JIANG <[email protected]>
> > Cc: [email protected];
> > [email protected]; [email protected]
> > 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 <[email protected]> On Behalf Of Toerless Eckert
> > > > Sent: Thursday, May 2, 2024 11:21 PM
> > > > To: [email protected];
> > > > [email protected]
> > > > Cc: [email protected]
> > > > 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: [email protected]
> > > > 658 Joanna Dang
> > > > 659 Huawei
> > > > 660 No.156 Beiqing Road
> > > > 661 Beijing
> > > > 662 P.R. China, 100095
> > > > 663 China
> > > > 664 Email: [email protected]
> > > >
> > > > 666 Zongpeng Du
> > > > 667 China Mobile
> > > > 668 32 Xuanwumen West Street
> > > > 669 Beijing
> > > > 670 P.R. China, 100053
> > > > 671 China
> > > > 672 Email: [email protected]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Anima mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/anima
> > >
> >
> > --
> > ---
> > [email protected]
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
