idnits 2.17.1 draft-dang-anima-network-service-auto-deployment-00.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 date (July 7, 2021) is 1017 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) == Unused Reference: 'RFC2119' is defined on line 439, 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 (~~), 2 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: January 8, 2022 Z. Du 6 China Mobile 7 July 7, 2021 9 An Auto-deployment Mechanism for Resource-based Network Services 10 draft-dang-anima-network-service-auto-deployment-00 12 Abstract 14 This document specifies an auto-deployment mechanism that deploys 15 resource-based network services through the Autonomic Control Plane 16 (ACP) in an Autonomic Network. This mechanism uses the GRASP in 17 [RFC8990] to exchange the information among the autonomic nodes so 18 that the resource among the service path can be coordinated. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 8, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3 57 4. Architecture and components . . . . . . . . . . . . . . . . . 3 58 5. GRASP Option for Network Service Auto-deployment . . . . . . 4 59 6. Processes of Network Service Auto-deployment . . . . . . . . 7 60 6.1. Path-based Resource Negotiation . . . . . . . . . . . . . 7 61 7. Compatibility with Other Technologies . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 A network service is a service carried by a network. A system of 71 network service development includes a service initiator, a network 72 and a service terminator. And a network is between a service 73 initiator and a service terminator. From network perspective, this 74 network service clearly has a source IP address and a destination IP 75 address. Therefore, once a network service is delivered by a 76 network, this network service clearly has an access node and a 77 departure node in the network. Here, this access node is called UPE, 78 and the departure node is called PE. Actually there may be multiple 79 P nodes between UPE and PE in a single domain, and even cross 80 multiple domains connections through ASBRs. And there may be one or 81 more paths between UPE and PE for this network service. 83 With the development of the network services, a class of services 84 with resource requirements (such as bandwidth, latency, and jitter) 85 are already emerging, such as video, LR, VR and so on. To collect 86 resource information of network nodes along a path, the network 87 managers must analyse whether there are available resources to 88 allocate on the path. This is very demanding for network managers. 89 Along with the increasing scale of the network and the increasing 90 types of network services, the manual way have become increasingly 91 difficult to operate. There are two directions to solve this 92 problem. One is that network nodes perform the resource-based 93 negotiation and calculation along the path, and the other is that the 94 centralized control system perform network resource-based 95 calculations for the path. The former is faster and is not limited 96 by the number of nodes; the latter has better global calculation 97 results. Based on the principle that the two methods can complement 98 each other, the former is focused on in this document. 100 This document specifies an auto-deployment mechanism for resource- 101 based network services on the autonomic nodes in [RFC8993] to reduce 102 human operation difficulty and avoid the problem of specification 103 limitation and slow response in centralized systems, for the purpose 104 of improving service deployment efficiency. 106 The following chapters describe the architecture and functional 107 components, the definition of GRASP options and processes. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119. 115 3. Terminology & Abbreviations 117 Service Initiator: It may be an end user, a Customer Edge (CE), or a 118 controller that initiates a path-dependent and resource-based network 119 service. 121 SPE: A first hop network node where the service initiator connects to 122 the network or where the path-dependent and resource-based network 123 service starts. 125 PE: Provider Edge node where the network service starts or ends. 127 P: A transmit node between SPE and PE. 129 ASBR: AS Border Router which is an edge node of the domain in the 130 cross-domain scenario. It may also be a PE node. 132 4. Architecture and components 134 This section describes the internal architecture of an auto- 135 deployment mechanism for resource-based network services. 137 As Figure 1 shows, a functional system of network service auto- 138 development includes Autonomic Network Service (ANS) Request, ANS 139 Deployment Function and ANS Response. 141 1. First, the network resource initiator sends an ANS Request to a 142 UPE on the edge of network. 144 2. Then, the UPE starts to establish a resource-based path to the 145 network service according to the network service requirements. A 146 resource-based path is an LSP within 147 [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls]. If the 148 path is successfully established, UPE will automatically 149 configure the LSP. The specific configuration command lines are 150 not in the scope of this document. 152 3. Finally, UPE sends back an ANS Response with the deployment 153 result to the network service initiator. 155 Network Service Network Service 156 Initiator Terminator 157 +--------+ +--------+ 158 | | | | 159 +--------+ +--------+ 160 | +--------+ +--------+ +--------+ | 161 +-------| SPE |--------| P |--...--| PE |+------+ 162 +--------+ +--------+ +--------+ 163 Network Network Network 164 Node1 Node2 NodeN 165 1.ANS Request 166 ------------> 167 2.ANS Deployment Function 168 <-------------------------------------------> 169 3. ANS Response 170 <------------ 172 Figure-1: Architecture and Components 174 These messages including ANS Request, ANS Deployment Function and ANS 175 Response are exchanged between or in autonomic nodes through GRASP. 176 The chapter 5 defines the optional fields of GRASP for this function, 177 and the chapter 6 introduces the process. 179 5. GRASP Option for Network Service Auto-deployment 181 The GRASP enables autonomic nodes to dynamically discover peers, to 182 synchronize state with each other, and to negotiate parameter 183 settings with each other. So an objective option is used to identify 184 objectives for the purposes of discovery, negotiation, or 185 synchronization. So a new objective option is defined for Network 186 Service Auto-deployment as follows. 188 objective-name = EX10 190 All objectives MUST be in the following format, described in 191 fragmentary CDDL. 193 objective = [objective-name, objective-flags, loop-count, ?objective- 194 value] 196 The 'objective-value' field expresses the actual value of a 197 negotiation or synchronization objective. So a new objective-value 198 named n-s-deployment-value is defined for Network Service Auto- 199 deployment as follows. The autonomic node can know that it is 200 serving Network Service Auto-deployment according to the objective- 201 value after receiving the GRASP message. 203 objective-value = n-s-deployment-value 205 loop-count = 0..255 207 An n-s-deployment-value is defined as Figure-2. 209 n-s-deployment-value 210 + service-identification 211 + service-identification-type 212 + service-identification-value 213 + resource-information 214 + resource-type 215 + resource-value 216 + n-s-deployment-type 217 + status 219 Figure-2: Format of n-s-deployment-value 221 n-s-deployment-value = [ service-identification 1, service- 222 identification 2, ..., service-identification n ] 224 More than one auto-deployed network services can share a GRASP 225 channel. 227 service-identification = [ service-identification-type, service- 228 identification-value, ?path-identification-type, ?path- 229 identification-value, resource-information, n-s-deployment-type, 230 ?n-s-status ] 232 resource-information = [ resource-type, resource-value ] 234 The detailed fields of n-s-deployment-value are defined as follows. 236 service-identification-type: 3 bits, which is used to identify 237 different services within a Request Negotiation message or a 238 Negotiation message. 240 o 1 = MAC 241 o 2 = VLAN 243 o 3 = IP address 245 o 4 = Label 247 o 5~6 is reserved 249 service-identification-value: TBD, which is used to identify 250 different network services within a Request Negotiation message or a 251 Negotiation message. 253 path-identification-type: 3 bits, which is related to the network. 255 o 1 = LSP 257 o 2~6 is reserved 259 path-identification-value: TBD 261 path-identification-value, 3 bits 263 o MAC 265 o Or VLAN 267 o Or 5 tuple 269 o Or label 271 resource-type: 2 bits, one service may have a type of resource 272 information or more than one type of resource information. 274 o 1 = bandwidth 276 o 2 = latency 278 o 3 = jitter 280 n-s-deployment-type: 2 bits 282 o 1 = network service establishment 284 o 2 = network service withdrawal 286 o 3 = network service update including resource information update 288 n-s-status: 2 bits only in a Negotiation message 289 o 0, default 291 o 1, which indicates that the negotiation was successful. 293 o 2, which indicates that the negotiation failed 295 6. Processes of Network Service Auto-deployment 297 The GRASP within objective-name for network service auto-deployment 298 enables autonomic nodes which are a service initiator, a network and 299 a service terminator. 301 During the negotiation process, the service initiator first sends a 302 Request Negotiation message with a service-identification to the SPE. 303 After receiving the Request Negotiation message, the SPE records the 304 service-identification and creates the related data block. Next, the 305 SPE starts to establish a resource-based path based on the resource 306 information within service-identification. 308 6.1. Path-based Resource Negotiation 310 If the s-deployment-type within the Request Negotiation message is 1 311 which indicates network service establishment, the resource-based 312 path establishment is started. 314 If s-deployment-type is 3 which indicates network service update, the 315 process directly skips to the processes of the path-based resource 316 negotiation. 318 The UPE must check whether the network path is reachable based on 319 addressing information from service-identification. The addressing 320 information may be destination MAC address in layer 2 networks, or 321 destination IP address in layer 3 networks, or label in MPLS or SR 322 networks , and so on. A path is an LSP within 323 [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls]. 325 o If a reachable path is found out from the existing free path, the 326 SPE will initiate path resource negotiation. 328 o If a reachable path isn't found out from the existing free path, 329 the SPE will start path-based auto-configuration before resource 330 negotiation. If the path configuration still fails, the SPE will 331 send back a Negotiation Message that the service deployment failed 332 to the service initiator. 334 After finding out a network reachable path, the SPE initiates a path- 335 based resource negotiation based on its resource information as 336 figure-3. 338 +-----+ +----+ +----+ +-----+ 339 | SPE |------| P |------| P |------| PE + 340 +-----+ +----+ +----+ +-----+ 341 Request Negotiation Message 342 ------------> 343 Request Negotiation Message 344 ------------> 345 Request Negotiation Message 346 ------------> 347 Negotiation message 348 <------------ 349 Negotiation message 350 <------------ 351 Negotiation message 352 <------------ 354 Figure-3: An example of a path-based resource negotiation 356 o Every autonomic network node along the path need to calculate the 357 available resources. If receiving the path Request Negotiation 358 message, it obtains resource information from the Request 359 Negotiation message, and calculate whether its own resources 360 related to this path meet the requirements. 362 o 364 * If they do, network autonomic node needs to send a path Request 365 Negotiation message to the downstream node before related 366 resources is occupies by this path. If the negotiation message 367 reaches the last node of the path and resources are available, 368 the autonomic node will send a Negotiation message with 369 successful negotiation back to the upstream node. If the SPE 370 receives a path Negotiation message indicating that the path 371 resource negotiation is successful, it will send back to a 372 service Negotiation message to the service initiator. 374 * If they do not, it will terminate this message and response a 375 Negotiation message with failed resource negotiation to its 376 upstream node. If receiving it, the upstream node also 377 response a path Negotiation message with failed resource 378 negotiation to its upstream node. The SPE will send back to 379 the service Negotiation message failed resource negotiation to 380 the service initiator after receiving this path Negotiation 381 message. 383 If s-deployment-type within the Request Negotiation message is 3 384 which indicates network service update, the path update based on its 385 resource requirement is started. It should be emphasized that the 386 nodes occupy the sum of the existing and updated resources before the 387 nodes along the path have successfully completed the path 388 negotiation. If the update is successful, the existing resource 389 along the path will be released. If the update fails, the existing 390 resource along the path will be kept. 392 If s-deployment-type within the Request Negotiation message is 2 393 which indicates network service withdrawal, the nodes along the path 394 will release the relevant configuration and resources before 395 receiving this message. 397 7. Compatibility with Other Technologies 399 It is worth emphasizing that the resource allocation and calculation 400 methods of network nodes are different on the type of different 401 resource requirements. 403 Now it is explained in terms of bandwidth. If in the MPLS network, 404 the RSVP protocol system has the complete signaling mechanism and 405 bandwidth resource calculation functions. The bandwidth negotiation 406 of the network-side path can be completed by RSVP. 408 For latency and jitter, the GRASP mechanism is needed to complete. 409 For example, the network node collects links, forwarding and queue 410 scheduling delays, and performs delay or calculations. If the 411 calculated delay meets the service requirements, the other node is 412 notified through the GRASP protocol. The same principle applies to 413 jitter. 415 8. Security Considerations 417 It complies with GRASP security consideration. 419 9. IANA Considerations 421 A new GRASP Objective Name is especially for network service 422 deployment. The Objective-name of n-s-deployment-value need to be 423 defined. 425 10. Acknowledgements 427 TBD 429 11. Normative References 431 [I-D.ietf-mpls] 432 "Multiprotocol Label Switching Architecture", 433 . 435 [I-D.ietf-spring-segment-routing] 436 "Segment Routing Architecture", 437 . 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC8990] "GeneRic Autonomic Signaling Protocol (GRASP)", 445 . 447 [RFC8993] "A Reference Model for Autonomic Networking", 448 . 450 Authors' Addresses 452 Joanna Dang (editor) 453 Huawei 454 No.156 Beiqing Road 455 Beijing, P.R. China 100095 456 China 458 Email: dangjuanna@huawei.com 460 Sheng Jiang 461 Huawei 462 No.156 Beiqing Road 463 Beijing, P.R. China 100095 464 China 466 Email: jiangsheng@huawei.com 468 Zongpeng Du 469 China Mobile 470 32 Xuanwumen West St 471 Beijing, P.R. China 100053 472 China 474 Email: duzongpeng@chinamobile.com