idnits 2.17.1 draft-liu-coin-differential-reservation-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 332 has weird spacing: '...esource tbd...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 10, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5440' is defined on line 365, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Computing in Network Research Group P. Liu 3 Internet-Draft H. Yao 4 Intended status: Informational L. Geng 5 Expires: January 11, 2021 China Mobile 6 July 10, 2020 8 Differential Computing Resource Reservation 9 draft-liu-coin-differential-reservation-00 11 Abstract 13 Computing in the network may require the embedded computing 14 capability in the network device, such as gateway, switch, etc, and 15 there might be so much distributed computing task in the network. 16 Some new applications like AR/VR, motion control put forward higher 17 demand of network than before, and AI is also considered to be used 18 in the app and network. 20 In order to satisfy their demands, network may not only need to 21 reserve bandwidth resource, but also reserve computing resource. 22 This document analyzes the requirements of Serial distributed 23 computing model and give some reference solutions. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 11, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Existing Protocol . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Resource Reservation Protocol . . . . . . . . . . . . . . 3 68 2.2. Path Computation Element Protocol . . . . . . . . . . . . 3 69 3. Problems of Resource Reservation . . . . . . . . . . . . . . 4 70 4. Reference Method . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Distributed Resource Reservation . . . . . . . . . . . . 5 72 4.2. Centralized Resource Reservation . . . . . . . . . . . . 6 73 4.2.1. PCEP . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2.2. Netconf/Yang . . . . . . . . . . . . . . . . . . . . 7 75 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Overview 83 From cloud computing to edge computing, computing power is 84 distributed to the customer side. In the future network and 85 computing convergence system, computing power will be distributed as 86 ubiquitous endogenous resources in each node of the network. The 87 user's request can be satisfied by calling the nearest node resource, 88 which is no longer limited to a specific node. 90 Resource reservation is usually used to guarantee the QoS of specific 91 application traffic. The reservation of network resources is same in 92 an end-to-end path, which means the reserved bandwidth resources will 93 not change from the client to the server, but computing is different. 94 Distributed computing will bring different computing power, and 95 different resources need to be reserved for different nodes. For 96 example, AI algorithm now has a model of step-by-step iteration at 97 multiple nodes. The previous iteration will affect the next 98 calculation results, and the computing resources required for each 99 iteration are not the same. From the perspective of network 100 standard, we hope to regard computing resources as the dimensions to 101 measure network performance, such as the same bandwidth, path, etc., 102 while the traditional technologies of resource reservation have not 103 considered the reservation of computing resources, and have not 104 considered the differentiated resource reservation model. 106 2. Existing Protocol 108 Existing resource reservation protocols, such as Resource ReSerVation 109 Protocol(RSVP) and Path Computation Element Protocol (PCEP) , can be 110 used to reserve bandwidth resources. RSVP is a traditional protocol, 111 which only focuses on how to initiate the reservation of resources, 112 not the establishment of path. Later, RSVP-TE protocol was developed 113 for MPLS. PCEP was designed to separate the path calculation and 114 path establishment functions of RSVP-TE firstly, which means that the 115 path calculation part before resource reservation can be realized. 116 Therefore, RSVP and PCEP can be used together or separately. 118 2.1. Resource Reservation Protocol 120 Resource reservation is currently regarded as the key technology 121 configuration scheme to guarantee network QoS. In order to solve the 122 problem of bandwidth competition caused by the simultaneous arrival 123 of specific data flow and common data flow on the network node, the 124 bandwidth reservation management of data from the source node to the 125 destination node end-to-end is realized, so as to ensure the real- 126 time data flow QoS and delay requirements. The general process is as 127 follows: 129 The sender client initiates the request of resource reservation by 130 the path message. After determining the path, the sender sends the 131 request along the path, carrying the network requirements (latency, 132 etc.) to the receiver. 134 The receiver calculates the bandwidth and other resources that need 135 to be reserved for the network according to the request of the 136 sender. Then it returns according to the original path, and informs 137 the equipment to reserve resources one by one. 139 2.2. Path Computation Element Protocol 141 Path Computation Element Protocol (PCEP) is a centralized 142 configuration technology, which is usually used in software defined 143 network (SDN) as the South interface calculation and configuration 144 path information. PCE can improve the agility of the network. Any 145 change in network can be programmed using PCECC to learn the change 146 and react to it quickly and efficiently. 148 PEC can initiate resource reservation application to each device in 149 the path by the PCLRResv message. This message is sent by Path 150 Computation Element (PCE) to Path Computation Client (PCC) to sent 151 reserved label range for the network. The objects supported in this 152 message are stateful PCE request parameters objects, setting the 153 unique identifier for mapping request/response between PCEP and PCC. 155 3. Problems of Resource Reservation 157 In the model of computing in the network, the computing resource may 158 be distributed in multiple nodes. A task may be divided into several 159 parts to be executed by multiple nodes, including serial distribution 160 and parallel distribution. Parallel distribution can reserve 161 resources separately. However, in the serial computing model, the 162 calculation process of serial distribution algorithm is sequential, 163 and the results of the previous calculation need to be used in the 164 later calculation, so it will bring the following two problems: 166 Different computing nodes on the same path need different reserved 167 computing resources. 169 The bandwidth resources to be reserved maybe different after the 170 previous calculations in the same path. 172 A typical example is the artificial intelligence algorithm, which 173 involves the multi-layer convolution iterative process and can be 174 completed by multiple computing device in serial. As shown in the 175 figure, 20%, 30% and 50% tasks are calculated on network device 1, 3 176 and server respectively, and the calculation results of device 1 will 177 affect the subsequent calculation of device 3 and server. Then, 179 Network device 1, 3 and server need to reserve corresponding 180 computing resources respectively. 182 Since devices 1 and 3 calculated, the traffic will change after 183 passing through devices 1 and 3, so the bandwidth resources to be 184 reserved are different. 186 Traditional RSVP and other protocols do not consider the calculation 187 attribute, so the reserved value of bandwidth resource along the path 188 is unchanged, and the calculation resource cannot be reserved. PCEP 189 also dosen't consider about the comuputing resource. 191 +------+ +--------+ 192 |Client| ->| Server | 193 +------+ \ +--------+ +--------+ +--------+ / +--------+ 194 \->|network | |network | |network |->/ 50% of 195 |device 1|-->|device 2|-->|device 3| computing 196 +--------+ +--------+ +--------+ tasks 197 20% of 30% of 198 computing computing 199 tasks tasks 201 Serial distributed computing model 203 4. Reference Method 205 This scheme provides distributed and centralized resource reservation 206 reference scheme. It should be noted that for serial distributed 207 computing, we assume that the application side implements the 208 following functions: 210 The number of steps are involved in the calculation. 212 The computing proportion of calculation required at each node. 214 For bandwidth changes after each step of calculation, if this item 215 cannot be implemented, the same bandwidth resources will be reserved 216 by default. 218 4.1. Distributed Resource Reservation 220 Distributed resource reservation can be implemented by extending RSVP 221 or RSVP-TE protocol. The server receives the client's service 222 request, calculating the resource reservation strategy and return it. 223 The process is as follows: 225 1. The client sends the service request, carrying the service 226 requirements and the collected resource status of each node on the 227 path. They will be collected and added to the information that 228 carried by the service request. 230 2. The server receives the client's service request, then generates 231 the resource reservation strategy for target nodes on the path based 232 on the the service requirements and the resource status of each node, 233 and return the resource reservation strategy to each target node 234 along the path to reserve the resource. 236 The resource status at least includes the computing resource status 237 such as the catergery of chip, algorithm, etc. It can also includes 238 the network resource status such as bandwidth, delay, etc. 240 The resource reservation strategy at least includes the computing 241 resource reservation information of target nodes, which is as 242 follows: 244 1. Determine the serial distributed computing subtasks and computing 245 resources required by each computing subtask based on the service 246 request. 248 2. Select the target nodes for each computing subtask and generate 249 the computing resources reservation information to inform each target 250 node to reserve resource based on the computing resource status of 251 each node and the computing resources required by each computing 252 subtask. 254 Moreover, if the bandwidth change after each subtask can be 255 calculated, the resource reservation strategy can also carrying the 256 bandwidth resources reservation information. 258 It can be realized by defining new object of RSVP or RSVP-TE to 259 reserve different resources in each target nodes. The object can be 260 customized and extended with variable length. For example, 261 redefining a new class num as 30, carries the following message body: 263 [L = 0, IPv4, 64, IP address1, bandwidth 1, computing resource 1] 265 [L = 0, IPv4, 64, IP address2, bandwidth 2, computing resource 2] 267 [L = 0, IPv4, 64, IP address3, bandwidth 3, computing resource 3] 269 [L = 0, IPv4, 64, IP address4, bandwidth 4, computing resource 4] 271 ...... 273 It should be noted that the extended object can not only carry the 274 collected resources status of each node in the PATH message, but also 275 return the resource reservation strategy in the RESV message. 277 4.2. Centralized Resource Reservation 279 Centralized resource reservation can be realized by the network 280 manager. The manager receives the service request, calculates the 281 network and computing resources needed, and initiates resource 282 reservation configuration for the target nodes along the path.The 283 process is as follows: 285 The client sends a service request to the network manager. 287 Network manager selects the path according to the service request and 288 get the resource status of each node on the path. 290 Network manager generates the resource reservation strategy based on 291 the client's service request and resource status of each node. 293 Network manager sends resource reservation strategy to target nodes 294 to reserve the resource. 296 The resource status at least includes the computing resource status. 297 The resource reservation strategy at least includes the computing 298 resource reservation information of each target node. Which are the 299 same with chapter 4.1. 301 If at least one node in the selected path does not meet the resource 302 reservation requirements, it is necessary to re-select at least one 303 node in the path and get the resource status of the re-selected node 304 until the path meets the requirements of the resource reservation 305 strategy. 307 4.2.1. PCEP 309 By adding calculation force resource reservation field to resource 310 reservation object in PECP message, each calculation force flow has a 311 dynamic resource range based on the minimum reserved resource. 313 +---------+---------+-----------+----------+--------+ 314 | Object | Label | Reserverd |Interface | In/ | 315 | Type | ID | Bandwidth |IP Address| Out | 316 +---------+---------+-----------+----------+--------+ 318 PCEP extension 320 4.2.2. Netconf/Yang 322 It can also send resource reservation configuration to the target 323 nodes by netconf and defining the Yang structure. The reference Yang 324 module is as follows. 326 module: rs-computing-network 327 +--rw rs-computing-network 328 +--rw added-device[id] 329 | +--rw service id string 330 | +--rw user id string 331 | +--rw bandwitdh mbps 332 | +--rw computing resource tbd 333 +--rw deleted-device[id] 335 Yang Module 337 5. Conclusion 339 The draft proposes a method of differential reservation of computing 340 power and bandwidth resources. Because the traditional network does 341 not include computing power, the reservation of network resources is 342 the same on the path. This scheme can accurately reserve computing 343 power and network resources for the serial distributed computing 344 services. It also present the reference methods to realize different 345 resource reservation.Of course, there may be more and more 346 appropriate methods to achieve serial distributed computing power and 347 network resource reservation, which may require more analysis and 348 discussion. 350 6. Security Considerations 352 TBD. 354 7. IANA Considerations 356 TBD. 358 8. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 366 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 367 DOI 10.17487/RFC5440, March 2009, 368 . 370 Authors' Addresses 372 Peng Liu 373 China Mobile 374 Beijing 100053 375 China 377 Email: liupengyjy@chinamobile.com 379 Huijuan Yao 380 China Mobile 381 Beijing 100053 382 China 384 Email: yaohuijuan@chinamobile.com 386 Liang Geng 387 China Mobile 388 Beijing 100053 389 China 391 Email: gengliang@chinamobile.com