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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
