idnits 2.17.1 draft-dang-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (9 October 2021) is 929 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: 'RFC8949' is mentioned on line 234, but not defined == Missing Reference: 'RFC8610' is mentioned on line 236, but not defined == Missing Reference: 'RFC8995' is mentioned on line 339, but not defined == Missing Reference: 'RFC8994' is mentioned on line 339, but not defined == Unused Reference: 'I-D.ietf-mpls' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 363, 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' ** Downref: Normative reference to an Informational RFC: RFC 8993 Summary: 2 errors (**), 0 flaws (~~), 9 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: 12 April 2022 Z. Du 6 China Mobile 7 Z. Zhou, Ed. 8 Huawei 9 9 October 2021 11 An Autonomic Mechanism for Resource-based Network Services Auto- 12 deployment 13 draft-dang-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 an Autonomic Network. This mechanism uses the GRASP in [RFC8990] 20 to exchange the information among the autonomic nodes so that the 21 resource among the service path can be coordinated. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 12 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3 59 4. Resource-based Network Services Auto-deployment Solution . . 4 60 4.1. ResourceManager ASA Discovery . . . . . . . . . . . . . . 4 61 4.2. Resource Negotiation . . . . . . . . . . . . . . . . . . 4 62 4.3. Behavior after Negotiation . . . . . . . . . . . . . . . 5 63 5. Autonomic Resource Management Objectives . . . . . . . . . . 5 64 6. Process of Network Service Auto-deployment . . . . . . . . . 6 65 6.1. Process between Service Initiator and APE . . . . . . . . 6 66 6.2. Process between APE and ASBR . . . . . . . . . . . . . . 7 67 7. Compatibility with Other Technologies . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 With the network development, a class of services with resource 77 requirements (such as bandwidth, latency, and jitter) are already 78 emerging, such as video, LR, VR and so on. From network perspective, 79 this kind of service clearly has a source IP address and a 80 destination IP address. Therefore, once the kind of service is 81 delivered by a network, this network service clearly has an access 82 node and a departure node in the network. Here, the access node is 83 called APE, and the departure node is called DPE. Actually there may 84 be multiple Transmit nodes between APE and DPE in a network domain, 85 and even cross multiple network domains through ASBRs. Then, the 86 deployment of network services needs to negotiate network resources. 88 As is surveyed, the resource in campus network are more uneven than 89 in the operator's network, such as wireless connections. Ideally, as 90 a centralized system, the controller can automatically perform 91 resource discovery and overall allocation. Actually, all devices in 92 the campus network cannot be conveniently, availably communicated 93 with one controller, such as, some sensors with complex installation 94 environment, the network devices from different vendors. Therefore, 95 a new distributed mechanism in network is required to negotiate the 96 resource information for network service auto-deployment. 98 The original purpose of this document was to validate the design of 99 the Autonomic Networking Infrastructure (ANI) for a realistic use 100 case. It shows how the ANI can be applied to negotiate the resource 101 information for network service auto-deployment. 103 This document defines an autonomic technical objectives for Resource- 104 based Network Services Auto-deployment. The GeneRic Autonomic 105 Signaling Protocol (GRASP) is specified by [RFC8990] and can make use 106 of the technical objective to provide a solution for Resource-based 107 Network Services Auto-deployment. An important purpose of the 108 present document is to use it for validation of the design of GRASP 109 and other components of the ANI as described in [RFC8993]. 111 The goal of this document is to complete the resource-based self- 112 adaptation among service and network nodes via GRASP. And this 113 document is not a complete functional specification of an autonomic 114 system of Resource-based Network Services Auto-deployment, and it 115 does not describe all detailed aspects of the GRASP objective 116 parameters and Autonomic Service Agent (ASA) procedures necessary to 117 build a complete system. Instead, it describes the architectural 118 framework utilizing the components of the ANI, outlines the different 119 deployment options and aspects, and defines GRASP objectives for use 120 in building the system. It also provides some basic parameter 121 examples. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119. 129 3. Terminology & Abbreviations 131 Service Initiator(SI): It may be an end user, a Customer Edge (CE), 132 or a controller that initiates a path-dependent and resource-based 133 network service. 135 Provider Edge (PE): Provider Edge node where the network service 136 starts or ends. 138 Access PE (APE): A first provider edge where the service initiator 139 connects to the network or where the path-dependent and resource- 140 based network service starts. 142 Departure PE (DPE): A last provider edge where the path-dependent and 143 resource-based network service ends. 145 Transmit node: A transmit node between APE and DPE. 147 AS Border Router (ASBR): AS Border Router which is an edge node of 148 the domain in the cross-domain scenario. It may also be a PE node. 150 4. Resource-based Network Services Auto-deployment Solution 152 This section describes the internal architecture of resource-based 153 network services auto-deployment. As noted in Section 1, this is not 154 a complete description of a solution, which will depend on the 155 detailed design of the relevant Autonomic Service Agents (ASAs). It 156 uses the generic discovery and negotiation protocol defined by 157 [RFC8990] and the relevant GRASP objectives are defined in Section 5. 159 The procedures described below are carried out by an ASA in each 160 device that participates in the solution. We will refer to this as 161 the ResourceManager ASA. If a device containing a ResourceManager 162 ASA which is used up its resource, it can request more resource 163 according to its requirements. It should decide the type and value 164 of the requested resource and request it via the mechanism described 165 in Section 6. 167 4.1. ResourceManager ASA Discovery 169 A ResourceManager ASA that needs additional resource should firstly 170 discover peers that may be able to provide extra resource. The ASA 171 should send out a GRASP Discovery message that contains a 172 ResourceManager Objective option in order to discover peers also 173 supporting that option. Then, it should choose one such peer, most 174 likely the first to respond. 176 A device that receives a Discovery message with a ResourceManager 177 Objective option should respond with a GRASP Response message if it 178 contains a ResourceManager ASA. If it does not contain 179 ResourceManager ASA, the device ignore this message. Further details 180 of the discovery process are described in [RFC8990]. 182 4.2. Resource Negotiation 184 After discover step, the requesting ResourceManager ASA will act as a 185 GRASP negotiation initiator by sending a GRASP Request message with a 186 ResourceManager Objective option. The requesting ResourceManager ASA 187 indicates in this option the value of the requested resource. This 188 starts a GRASP negotiation process. 190 When the provider ResourceManager ASA receives a subsequent Request 191 message, it should conduct a GRASP negotiation sequence, using 192 Negotiate, Confirm Waiting, and Negotiation End messages as 193 appropriate. The Negotiate messages carry a ResourceManager 194 Objective option, which will indicate the resource type and value 195 offered to the requesting ASA. 197 During the negotiation, the requesting ResourceManager ASA will 198 decide at each step how large resource need to offer. That decision, 199 and the decision to end the negotiation, are implementation choices. 200 As to the provider ResourceManager ASA responses how large resource 201 they can offer and reserve enough resource during this negotiation 202 step. A resource shortage may cause a device to indicate the 203 existing available value within a ResourceManager Objective option to 204 the requesting ASA. The requesting ASA compares whether the resource 205 data received is the same locally. If they are not the same, the 206 requesting ASA might decide whether to accept the resource. If not, 207 the requesting ASA might terminate the negotiation via Negotiation 208 End messages with an error code string. 210 As described in [RFC8990], negotiation will continue until either end 211 stops it with a Negotiation End message. If the negotiation 212 succeeds, the ASA that provides the resource will remove the 213 negotiated resource from its pool, and the requesting ASA will add 214 it. If the negotiation fails, the party sending the Negotiation End 215 message may include an error code string. 217 4.3. Behavior after Negotiation 219 Upon receiving a GRASP Negotiation End message that indicates that 220 the acceptable resource is available. The resource providing device 221 remove the acceptable resource from its resource pool and the 222 requesting device may use the negotiated resource without further 223 messages. 225 5. Autonomic Resource Management Objectives 227 This section defines the GRASP technical objective options that are 228 used to support autonomic resource management. 230 The ResourceManager Objective option is a GRASP Objective option 231 conforming to the GRASP specification [RFC8990]. Its name is 232 "ResourceManager", and it carries the following data items as its 233 value: the resource value. Since GRASP is based on CBOR (Concise 234 Binary Object Representation) [RFC8949], the format of the 235 ResourceManager Objective option is described in the Concise Data 236 Definition Language (CDDL) [RFC8610] as follows: 238 objective = ["ResourceManager", objective-flags, loop-count, 239 [restype, resval]] 241 loop-count = 0..255 ; as in the GRASP specification 243 objective-flags /= ; as in the GRASP 245 resourcetype /= 0...4; requested or offered resource type, such as 246 bandwidth, latency or jitter. 248 resval /= 1...1000000; If the restype is bandwidth, the value ranges 249 in Mbit/s; If the restype is latency, the value ranges in 250 microsecond; If the restype is jitter, the value ranges in 251 microsecond. 253 6. Process of Network Service Auto-deployment 255 The network service auto-deployment system includes Service 256 Initiator, APE, DPE, and even ASBR. 258 The network service clearly has a APE and a DPE in the network. 259 Actually there may be multiple Transmit nodes between APE and DPE in 260 a single network domain, or even cross multiple network domains 261 through ASBRs. In a single network domain, APE holds all resource 262 information to DPE. In multiple domain network domains, APE holds 263 all resource information to ASBR, and ASBR holds all resource 264 information to DPE. 266 The Service Initiator initiates resource negotiation for a certain 267 network service to APE. If in one single domain, APE should respond 268 to the message with the resource valued offered. If in multiple 269 domain network domains, APE should initiates resource negotiation to 270 ASBR, and respond to the message with the resource valued offered 271 until receiving ASBR's response. 273 6.1. Process between Service Initiator and APE 275 The Service Initiator containing a ResourceManager ASA should send 276 out a GRASP Discovery message that contains a ResourceManager 277 Objective option in order to discover APE also supporting that 278 option. The APE that receives a Discovery message with a 279 ResourceManager Objective option should respond with a GRASP Response 280 message if it contains a ResourceManager ASA. 282 The ASA in the Service Initiator will act as a GRASP negotiation 283 initiator by sending a GRASP Request message with a ResourceManager 284 Objective option. The ASA indicates in this option the value of the 285 requested resource. 287 When this ASA in the APE receives a subsequent Request message, it 288 should conduct a GRASP negotiation sequence, using Negotiate, Confirm 289 Waiting, and Negotiation End messages as appropriate. The Negotiate 290 messages carry a ResourceManager Objective option with the resource 291 value offered to the requesting ASA. 293 If in a single network domain, this ASA in the APE check whether the 294 local resource data meets the requirements of the request. If it 295 meets the requested requirement, the APE should respond with a GRASP 296 Negotiate messages with the resource type and the resource value 297 requested. If it doesn't meet the requested requirement, the APE 298 should respond with a GRASP Negotiate messages with the resource 299 value offered. 301 If in the multiple network domain, this ASA in the APE should act a 302 GRASP negotiation initiator described in Section 6.2. 304 When the ASA in the Service Initiator receives a Negotiate message, 305 it should check whether the resource value within the Negotiate 306 message is the same as the resource value requested. If it is same, 307 the Service Initiator should send GRASP Negotiation End messages 308 indicating that the negotiation was successful. If it is not same, 309 the Service Initiator should decide whether to accept this 310 negotiation. If accepting this negotiation, it send should send 311 GRASP Negotiation End messages indicating that the negotiation was 312 successful. If not accepting this negotiation, it should send GRASP 313 Negotiation End messages indicating that the negotiation fails. 315 6.2. Process between APE and ASBR 317 The ASA in the APE should send a Confirm Waiting message to the 318 Service Initiator, to extend its timeout. When the new resource 319 becomes available confirmed by ASBR, the APE responds with a GRASP 320 Negotiate message with a resource value offered. 322 Other processes between APE and ASBR are the same as between Service 323 Initiator and APE. 325 7. Compatibility with Other Technologies 327 A gateway device gateway device is adopted between the GRASP network 328 and the MPLS network. As is known, the RSVP belong to the 329 distributed mechanism for resource reservation, but it is only 330 coupled with MPLS. Then this device uses the GRASP protocol in the 331 GRASP network, and the MPLS protocol in the MPLS network, so that 332 resource information can be shared. 334 8. Security Considerations 336 It complies with GRASP security considerations. Relevant security 337 issues are discussed in [RFC8990]. The preferred security model is 338 that devices are trusted following the secure bootstrap procedure 339 [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994] 340 is in place. 342 9. IANA Considerations 344 This document defines a new GRASP Objective option names: 345 "ResourceManager" which is need to be added to the "GRASP Objective 346 Names" registry. 348 10. Acknowledgements 350 Valuable comments were received from Michael Richardson and Brian 351 Carpenter. 353 11. Normative References 355 [I-D.ietf-mpls] 356 "Multiprotocol Label Switching Architecture", 357 . 359 [I-D.ietf-spring-segment-routing] 360 "Segment Routing Architecture", 361 . 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC8990] "GeneRic Autonomic Signaling Protocol (GRASP)", 369 . 371 [RFC8993] "A Reference Model for Autonomic Networking", 372 . 374 Authors' Addresses 375 Joanna Dang (editor) 376 Huawei 377 No.156 Beiqing Road 378 Beijing 379 P.R. China, 100095 380 China 382 Email: dangjuanna@huawei.com 384 Sheng Jiang 385 Huawei 386 No.156 Beiqing Road 387 Beijing 388 P.R. China, 100095 389 China 391 Email: jiangsheng@huawei.com 393 Zongpeng Du 394 China Mobile 395 32 Xuanwumen West St 396 Beijing 397 P.R. China, 100053 398 China 400 Email: duzongpeng@chinamobile.com 402 Yujing (editor) 403 Huawei 404 No.156 Beiqing Road 405 Beijing 406 P.R. China, 100095 407 China 409 Email: zhouyujing3@huawei.com