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