idnits 2.17.00 (12 Aug 2021) /tmp/idnits6895/draft-ietf-anima-network-service-auto-deployment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8990]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (4 March 2022) is 71 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8174' is mentioned on line 157, but not defined == Missing Reference: 'RFC7575' is mentioned on line 160, but not defined == Missing Reference: 'RFC8949' is mentioned on line 266, but not defined == Missing Reference: 'RFC8610' is mentioned on line 268, but not defined == Missing Reference: 'RFC8995' is mentioned on line 484, but not defined == Unused Reference: 'I-D.ietf-mpls' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC8993' is defined on line 516, but no explicit reference was found in the text -- No information found for draft-ietf-mpls - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-mpls' == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 ** Downref: Normative reference to an Informational RFC: RFC 8993 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA J. Dang, Ed. 3 Internet-Draft S. Jiang 4 Intended status: Standards Track Huawei 5 Expires: 5 September 2022 Z. Du 6 China Mobile 7 Z. Zhou, Ed. 8 Huawei 9 4 March 2022 11 An Autonomic Mechanism for Resource-based Network Services Auto- 12 deployment 13 draft-ietf-anima-network-service-auto-deployment-01 15 Abstract 17 This document specifies an autonomic mechanism for resource-based 18 network services deployment through the Autonomic Control Plane (ACP) 19 in a network. This mechanism uses the GeneRic Autonomic Signaling 20 Protocol (GRASP) in [RFC8990] to exchange the information among the 21 autonomic nodes so that the resource along the service path can be 22 coordinated. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 5 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 4 60 4. Resource-based Network Services Auto-deployment Solution . . 4 61 4.1. ResourceManager ASA Discovery . . . . . . . . . . . . . . 5 62 4.2. Resource Negotiation . . . . . . . . . . . . . . . . . . 5 63 4.3. Behavior after Negotiation . . . . . . . . . . . . . . . 6 64 5. Autonomic Resource Management Objectives . . . . . . . . . . 6 65 5.1. ResourceManager Objective option . . . . . . . . . . . . 6 66 6. Process of Network Service Auto-deployment . . . . . . . . . 8 67 6.1. An example of End-to-End Service . . . . . . . . . . . . 8 68 6.2. An example of multiple rounds . . . . . . . . . . . . . . 9 69 6.3. An example of multiple domain network . . . . . . . . . . 9 70 6.4. An example of changing resource requirements . . . . . . 10 71 6.5. An example of releasing resource requirements . . . . . . 11 72 7. Compatibility with Other Technologies . . . . . . . . . . . . 11 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 With the network development, a class of services with resource 82 requirements (such as bandwidth, queue, and priority) are already 83 emerging, such as video, LR, VR, and so on. To ensure the normal 84 operation of these services, the network needs to allocate sufficient 85 resources for the services in advance. An autonomous network must 86 have an appropriate mechanism to negotiate the network resource. 88 From the network perspective, this kind of service has a source IP 89 address and a destination IP address. Therefore, once the kind of 90 service is delivered by a domain network, this service clearly has an 91 access node and a departure node in the network. In an autonomic 92 resources negotiation mechanism, the resources are being negotiated 93 between the access node and departure node. 95 The core goal of this paper is to establish a set of automatic 96 negotiation mechanism to achieve the negotiation and distribution of 97 network resources in the domain network between the service client 98 and the network. That is, the server client negotiates with the 99 network how many resources can be provided for specific services in 100 the domain network to support the transmission of network services. 101 The benefits of doing so mainly include the following aspects: 103 * The resource-based network services auto-deployment satisfys the 104 QoS requirements of the service. If the service wants to ensure 105 its own transmission quality, the most effective solution is to 106 reserve enough transmission resources for the service before the 107 service starts. 109 * The mechanism of supporting multiple rounds of negotiations 110 enables the service client to change the resource requirements 111 according to the state of the network. For example, when the 112 network is congested, Video Conference services can reduce the 113 quality of video to ensure the most basic connectivity. 115 * The mechanism can ensure that the resources in the network can be 116 used more efficiently, provide different levels of network 117 resources for different levels of services, and give priority to 118 the network resource requirements of services of high importance. 120 The resource information negotiated in this document is more 121 extensive. Not only negotiation bandwidth resources but also 122 includes and is not limited to queue, priority and other resources. 123 On the one hand, in recent years, the requirements of services for 124 the network have become more complex. Services usually require the 125 network to ensure not only the deterministic bandwidth but also the 126 deterministic end-to-end delay and jitter, so as to deliver the data 127 message to the destination "in time" and "on time". For example, in 128 the telemedicine scenario, in order to ensure that doctors do not 129 feel obvious delay and jitter, it is required that the end-to-end 130 delay should not exceed 20ms and the jitter should be less than 200 131 μs. On the other hand, with the development of technology, the 132 network has more refined the scheduling of transmission capacity, and 133 also hopes to open its own capacity to the service clients. The 134 negotiation resources established in this document should support not 135 only to negotiate the existing supported resources but also to retain 136 some scalability for the negotiation ability in the future. 138 This document complete the resource-based self-adaptation among 139 service and network nodes via GRASP. This document defines an 140 autonomic technical objective for resource-based network services 141 auto-deployment. It shows how the ANI can be applied to negotiate 142 resource information for network service auto-deployment. This 143 document reduces the difficulty of manual operation, avoids the 144 problems of specification limitation and slow response speed in the 145 centralized system, improves the efficiency of service deployment and 146 makes more rational use of network resources. The GeneRic Autonomic 147 Signaling Protocol (GRASP) is specified by [RFC8990] and can make use 148 of the technical objective to provide a solution for resource-based 149 network services auto-deployment. 151 2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119][RFC8174] . 158 3. Terminology & Abbreviations 160 This document uses terminology defined in [RFC7575]. 162 RRM ASA: Requester ResourceManager ASA. A kind of ResourceManager 163 ASA which start to request resource in the network. 165 PRM ASA: Provider ResourceManager ASA. A kind of ResourceManager ASA 166 which provid resource in the network. 168 APE: Access Provider Edge is the first access provider edge where the 169 service initiator connects to the network or where the path-dependent 170 and resource-based network service starts. 172 DPE: Departure PE is the last provider edge where the path-dependent 173 and resource-based network service ends. 175 Transmit node: A transmit node in the domain network. 177 ASBR: AS Border Router is an edge node of the domain in the cross- 178 domain scenario. It may also be a PE node. 180 4. Resource-based Network Services Auto-deployment Solution 182 This section describes the internal architecture of resource-based 183 network services auto-deployment. As noted in Section 1, this is not 184 a complete description of a solution, which will depend on the 185 detailed design of the relevant Autonomic Service Agents (ASAs). It 186 uses the generic discovery and negotiation protocol defined by 187 [RFC8990] and the relevant GRASP objectives are defined in Section 5. 189 The procedures described below are carried out by an ASA in each 190 device that participates in the solution. We will refer to this as 191 the ResourceManager ASA. If a device containing a ResourceManager 192 ASA is used up its resource, it can request more resources according 193 to its requirements. It should decide the type and value of the 194 requested resource and request it via the mechanism described in 195 Section 6. 197 4.1. ResourceManager ASA Discovery 199 A ResourceManager ASA that needs additional resources should firstly 200 discover peers that may be able to provide extra resources. The ASA 201 should send out a GRASP Discovery message that contains a 202 ResourceManager Objective option to discover peers also supporting 203 that option. 205 A GRASP device that receives a Discovery message with a 206 ResourceManager Objective option should respond with a GRASP Response 207 message if it contains a ResourceManager ASA. If it does not contain 208 ResourceManager ASA, the device ignores this message. Further 209 details of the discovery process are described in Section 2.5.4 of 210 [RFC8990]. 212 4.2. Resource Negotiation 214 After the discovery step, the RRM ASA (Requesting ResourceManager 215 ASA) will act as a GRASP negotiation initiator by sending a GRASP 216 Request message with a ResourceManager Objective option. The RRM ASA 217 indicates in this option the value of the requested resource. And 218 ResourceManager GRASP Objective allows multiple types of resources to 219 be requested simultaneously. 221 When the PRM ASA (Provider ResourceManager ASA) receives a subsequent 222 Request message, it should conduct a GRASP negotiation sequence, 223 using Negotiate, Confirm Waiting, and Negotiation End messages as 224 appropriate. The Negotiate messages carry a ResourceManager 225 Objective option, which will indicate the resource type and value 226 offered to the requesting ASA. 228 During the negotiation, the RRM ASA will decide at each step how 229 large a resource needs to offer. That decision, and the decision to 230 end the negotiation, are implementation choices. As to the PRM ASA 231 responses how large resources they can offer and reserve enough 232 resources during this negotiation step. A resource shortage may 233 cause a device to indicate the existing available value within a 234 ResourceManager Objective option to the RRM ASA. The RRM ASA 235 compares whether the resource data received is the same locally. If 236 they are not the same, the RRM ASA might decide whether to accept the 237 request of the resource. If not, the RRM ASA might terminate the 238 negotiation via Negotiation End messages with an error code string. 240 As described in Section 2.8.8 of [RFC8990], negotiation will continue 241 until either end stops it with a Negotiation End message. If the 242 negotiation succeeds, the ASA that provides the resource will remove 243 the negotiated resource from its pool, and the requesting ASA will 244 add it. If the negotiation fails, the party sending the Negotiation 245 End message may include an error code string. 247 4.3. Behavior after Negotiation 249 Upon receiving a GRASP Negotiation End message that indicates that 250 the acceptable resource is available. The resource-providing device 251 removes the acceptable resource from its resource pool and the 252 requesting device may use the negotiated resource without further 253 messages. 255 5. Autonomic Resource Management Objectives 257 This section defines the GRASP technical objective options that are 258 used to support autonomic resource management. 260 5.1. ResourceManager Objective option 262 The ResourceManager Objective option is a GRASP Objective option 263 conforming to the GRASP specification [RFC8990]. Its name is 264 "ResourceManager", and it carries the following data items as its 265 value: the resource value. Since GRASP is based on CBOR (Concise 266 Binary Object Representation) [RFC8949], the format of the 267 ResourceManager Objective option is described in the Concise Data 268 Definition Language (CDDL) [RFC8610] as follows: 270 objective = ["ResourceManager", objective-flags, loop-count, 271 ?objective-value] 273 objective-name = "ResourceManager" 274 objective-flags = uint .bits objective-flag ; as in the GRASP 275 specification 277 loop-count = 0..255 ; as in the GRASP specification 279 The 'objective-value' field expresses the actual value of a 280 negotiation or synchronization objective. So a new objective-value 281 named n-s-deployment-value is defined for Network Service Auto- 282 deployment as follows. The autonomic node can know that it is 283 serving Network Service Auto-deployment according to the objective- 284 value after receiving the GRASP message. The 'objective value' 285 contains two parts, one represents the information of the service 286 itself, and the other represents the requirements of resources. 288 objective-value = n-s-deployment-value ; An n-s-deployment-value is 289 defined as Figure-1. 291 n-s-deployment-value 292 + service-information 293 + source-ip-address 294 + destination-ip-address 295 + service-tag 296 + resource-information 297 + resource-requirement-pair 298 + resource-type 299 + resource-value 301 Figure-1: Format of n-s-deployment-value 303 service-information = [ source-ip-address, destination-ip-address, 304 service-tag ] 306 The source-ip-address and the destination-ip-address represent the 307 source address and destination address. IPv4 and IPv6 addresses are 308 allowed. 310 resource-information = [ resource-requirement-pair 1, resource- 311 requirement-pair 2, ... , resource-requirement-pair n ] 313 Resource requirements of different types can be described in an 314 objective option. The ResourceManager objective option supports 315 multi-faceted resource requirements and negotiation. 317 resource-requirement-pair = [ resourcetype, resval ] 319 resourcetype /= 0...4; requested or offered resource type, such as 320 bandwidth, queue, and priority. 322 resval /= 1...1000000; If the restype is bandwidth, the value ranges 323 in Mbit/s; If the restype is latency, the value ranges in 324 microsecond; If the restype is jitter, the value ranges in 325 microsecond. 327 6. Process of Network Service Auto-deployment 329 The network service auto-deployment system includes Service 330 Initiator(SI), Service Terminator(ST), RRM ASA, PRM ASA and even 331 ASBR. 333 The service initiator is the resource demander, which ensures the 334 connection of services through negotiation resources with 335 ResourceManager ASA in the domain network. Service Terminator is the 336 end of service. APE represents the first access provider edge where 337 the service initiator connects to the network or where the path- 338 dependent and resource-based network service starts. There may be 339 multiple Transmit nodes between APE and Service Terminator in the 340 network or even cross multiple network domains through ASBRs. RRM 341 ASA starts a negotiation process to get enough resources in the 342 network. After RRM ASA gets the result about the resource, it sends 343 a response message to Service Initiator. And PRM ASA manages 344 resources from APE to ST hop-by-hop. 346 6.1. An example of End-to-End Service 348 In an End-to-End service, Service Initiator is a kind of access 349 terminal of the network. And the End-to-End service initiator uses 350 ResourceManager ASA to negotiate resources with the ResourceManager 351 ASA in the APE. Figure 2 shows the architecture of the End-to-End 352 service. In the figure, the RRM ASA in SI will act as a GRASP 353 negotiation initiator by sending a GRASP Request message with a 354 ResourceManager Objective option. The RRM ASA indicates in this 355 option the value of the requested resource. When this RRM ASA 356 receives a subsequent Request message, it should conduct a GRASP 357 negotiation sequence, using Negotiate, Confirm Waiting, and 358 Negotiation End messages as appropriate. The Negotiate messages 359 carry a ResourceManager Objective option with the resource value 360 offered to the PRM ASA. 362 +---------+ Negotiation Resource +---------+ 363 | RRM ASA |<--------------------->| PRM ASA | 364 +---------+ +---------+ +------+ +------+ 365 | SI | --------------------->| APE |--->| Node |--->| ST | 366 +---------+ Transmit data +---------+ +------+ +------+ 368 Figure-2: An example of End-to-End Service 369 PRM ASA processes receive resource requests and ensure the nodes 370 resource it can manage. If PRM ASA can't manage all nodes in the 371 data transport root or can't have enough resources, PRM ASA should 372 act as a GRASP negotiation initiator to negotiate resources with 373 other ASA in the network. 375 When the RRM ASA receives a Negotiation response message, it should 376 check whether the resource value within the Negotiate message is the 377 same as the resource value requested. If it is the same, the RRM ASA 378 should send GRASP Negotiation End messages indicating that the 379 negotiation was successful. If it is not the same, the RRM ASA 380 should communicate with Service Initiator about the result and decide 381 whether to accept this negotiation. If accepting this negotiation, 382 RRM ASA should send GRASP Negotiation End messages indicating that 383 the negotiation was successful. If not accepting this negotiation, 384 it should send GRASP Negotiation End messages indicating that the 385 negotiation fails. 387 6.2. An example of multiple rounds 389 In the process of automatic resource management mechanism, RRM ASA 390 and PRM ASA are allowed to negotiate resources for multiple rounds. 391 A very common situation is that the network resources can not meet 392 the resources required by the service, but the service is willing to 393 reduce its resource requirements to ensure the successful deployment 394 of the service. The PRM ASA using Resource Management Objectives 395 contains the resources that the network can provide to the service at 396 present in the response message. The RRM ASA changes the resource 397 requirements according to the specific requirements of the received 398 resources and services, to carry out the next round of service 399 negotiation. 401 6.3. An example of multiple domain network 403 In a multiple network, PRM ASA doesn't have the resource status of 404 other domains. So PRM ASA should negotiate with ASBR PRM ASA before 405 response RRM ASA. The PRM ASA should send a Confirm Waiting message 406 to the RRM ASA, to extend its timeout. When the new resource becomes 407 available confirmed by ASBR, the PRM ASA responds with a GRASP 408 Negotiate message with a resource value offered. The process as 409 Figure 3 shows. The Confirm Waiting message is described in 410 Section 2.8.9 of [RFC8990]. 412 +----------+ +---------+ 413 | RRM ASA |<---->| PRM ASA | 414 +----------+ +---------+ +--------------+ 415 | RRM ASA |<------>| ASBR PRM ASA | 416 +---------+ +--------------+ 417 Request Negotiation Message 418 ----------------------> 419 Waiting message 420 <---------------------- 421 Request Negotiation Message 422 -------------------> 423 Negotiation message 424 <------------------ 425 Negotiation message 426 <---------------------- 428 Other processes between APE and ASBR are the same as between Service 429 Initiator and APE. 431 Figure-3: An example of a path-based resource negotiation 433 6.4. An example of changing resource requirements 435 r the process of automatic resource management mechanism, RRM ASA and 436 PRM ASA are allowed to change and negotiate the resource 437 requirements. In the course of using network services, there will be 438 service requirement change which will lead to the problem of network 439 resource requirement change. ResourceManager ASA needs to be able to 440 handle resource changes in a timely manner to meet service 441 requirements. 443 During the renegotiation process, RRM ASA resent the service's 444 resource requirements by using ResourceManager GRASP Objective. And 445 the resource renegotiation process does not require the use of the 446 same PRM ASA as at the last negotiation on the mission. PRM ASA 447 received the resource negotiation message and made the determination. 448 If the resource requirements are lower than those allocated, the 449 response confirms the information and releases the excess resources. 450 If more resources are required than have been allocated, the resource 451 negotiation process follows Section 6.1. 453 PRM ASA does not change existing resource allocation until 454 negotiation on resource changes is complete. After negotiation, PRM 455 ASA makes changes to the resource pool by using response to the 456 negotiated resource requirements and synchronizes them with other ASA 457 nodes. 459 6.5. An example of releasing resource requirements 461 After the service is completed, a mechanism is needed to release 462 network resources so that network resources can be used more 463 efficiently. This process can be seen as a change in resource 464 requirements negotiation, where the resource requirements of the 465 service to the network become zero. A negotiation with PRM ASA was 466 initiated by RRM ASA in SI to reduce the resource footprint of the 467 service. Upon completion of the negotiation, PRM ASA released the 468 resources occupied by the service. 470 7. Compatibility with Other Technologies 472 A gateway device is used between the GRASP network and the MPLS 473 network. As is known, the RSVP belongs to the distribution mechanism 474 for resource reservation, but it is only coupled with MPLS. Then 475 this device uses the GRASP protocol in the GRASP network, and the 476 MPLS protocol in the MPLS network, so that resource information can 477 be shared. 479 8. Security Considerations 481 It complies with GRASP security considerations. Relevant security 482 issues are discussed in [RFC8990]. The preferred security model is 483 that devices are trusted following the secure bootstrap procedure 484 [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994] 485 is in place. 487 9. IANA Considerations 489 This document defines a new GRASP Objective option names: 490 "ResourceManager" which is need to be added to the "GRASP Objective 491 Names" registry. 493 10. Acknowledgements 495 Valuable comments were received from Michael Richardson and Brian 496 Carpenter. 498 11. Normative References 500 [I-D.ietf-mpls] 501 "Multiprotocol Label Switching Architecture", 502 . 504 [I-D.ietf-spring-segment-routing] 505 "Segment Routing Architecture", 506 . 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC8990] "GeneRic Autonomic Signaling Protocol (GRASP)", 514 . 516 [RFC8993] "A Reference Model for Autonomic Networking", 517 . 519 [RFC8994] "GeneRic Autonomic Signaling Protocol (GRASP)", 520 . 522 Authors' Addresses 524 Joanna Dang (editor) 525 Huawei 526 No.156 Beiqing Road 527 Beijing 528 P.R. China, 100095 529 China 530 Email: dangjuanna@huawei.com 532 Sheng Jiang 533 Huawei 534 No.156 Beiqing Road 535 Beijing 536 P.R. China, 100095 537 China 538 Email: jiangsheng@huawei.com 540 Zongpeng Du 541 China Mobile 542 32 Xuanwumen West St 543 Beijing 544 P.R. China, 100053 545 China 546 Email: duzongpeng@chinamobile.com 547 Yujing (editor) 548 Huawei 549 No.156 Beiqing Road 550 Beijing 551 P.R. China, 100095 552 China 553 Email: zhouyujing3@huawei.com