idnits 2.17.1 draft-liu-alto-can-usecase-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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 17 characters in excess of 72. 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 (July 11, 2021) is 1020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.li-dyncast-architecture' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-dyncast-ps-usecases' is defined on line 418, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-li-dyncast-architecture-00 == Outdated reference: A later version (-04) exists of draft-liu-dyncast-ps-usecases-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application-Layer Traffic Optimization P. Liu 3 Internet-Draft Y. Fu 4 Intended status: Informational China Mobile 5 Expires: January 12, 2022 July 11, 2021 7 Computing-aware Networking Use case of ALTO 8 draft-liu-alto-can-usecase-00 10 Abstract 12 The ever-emerging new services are imposing more and more highly 13 demanding requirements on the network. In order to meet these 14 requirements, some new technology trends of network emerge as the 15 times require. On the one hand, for the selection of service node 16 and forwarding path, in addition to considering the network topology 17 and link state, more factors are also considered, such as the 18 computing properties of service node; On the other hand, network and 19 application present the trend of mutual perception, including 20 application to perceive the state of network path, or network to 21 perceive the demand of application. 23 This draft describes a new network scenario and architecture 24 considering computational properties, and assumes that Alto could be 25 used as an important node to realize the deployment of services, and 26 to assist in the selection of service nodes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 12, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Usage Scenarios of CAN . . . . . . . . . . . . . . . . . . . 4 69 2.1. AR/VR . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Internet of Vehicles . . . . . . . . . . . . . . . . . . 5 71 3. CAN Framework and ALTO . . . . . . . . . . . . . . . . . . . 5 72 4. Deployment of CAN with ALTO . . . . . . . . . . . . . . . . . 7 73 5. Scheduling of CAN with ALTO . . . . . . . . . . . . . . . . . 8 74 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 For new services with heavy computing tasks, such as AR/VR, video 84 recognition and so on, the computing time and network transmission 85 delay are almost the same order of magnitude. In this kind of 86 scenario, computing attributes become more important than traditional 87 services. 89 The generation of edge computing is to solve such problems. Edge 90 computing is to deploy service nodes close to the user side, which 91 shortens the distance of network transmission. Moreover, it can 92 deploy specific computing resources, such as CPU/GPU, to meet the 93 needs of different services. 95 It is predicted by Gartner that by 2025, more than 50% of the 96 computing data needs to be analyzed, processed, and stored at the 97 edge. Since the service providers begins to offer the edge computing 98 infrastructure to provide better response time and transfer rate. 99 There are also some challenges of edge computing itself, which are 100 pointed out in the work of dyncast [draft-liu-dyncast-ps-usecases- 101 01], [draft-li-dyncast-architecture-00] : 103 * Geographically Scattered Large Number of Edge Sites. The edge 104 sites are highly distributed and may not have proximate distances to 105 user. 107 * Resource Limitation. There are fewer servers of server per node. 109 * Heterogeneous Hardware, such as CPU, GPU, Memory, ASICs. 111 * Dynamic Load. The available resources may change quickly. 113 * Edge-cloud Coordination. Edge does not solve all requests. 115 * High Cost. On-site maintenance is expensive. 117 * Mission Critical. Users are counting on you for 100% reliability 118 of industry automation. 120 So how to collaboratively deploy and computing services based on the 121 computing resources in network to meet the diverse computing 122 requirements, and achieve the on-demand allocation and dispatch of 123 service request needs be studied. 125 Some existing works have begun to consider the computing attributes. 126 For example, coinrg initiated the consideration of computing and 127 storage resources. Dyncast proposed how to introduce the scheme of 128 computing metric at the routing level. Semantic routing[], which 129 also extends the semantics of routing in a broad sense. However, 130 today's routing system and technology has been relatively good, the 131 introduction of more metric in routing still need more theoretical 132 and experimental verification. In the work of ITU, it is more from 133 the perspective of architecture, such as ITU Y.CAN-reqts [Y.CAN- 134 reqts: "functional requirements of Computing-aware Networking"] 135 proposed a new network architecture-computing-aware networking (CAN), 136 CAN schedules service request to the optimal computing site along 137 optimal path to meet service requirements both on network and 138 computing. ITU.Y.CPN-arch [Y.CPN-arch: "Framework and architecture 139 of Computing power Network"]provides the framework and architecture 140 of Computing power Network, specifies its functional entities and 141 defines the functionalities of these functional entities. So the 142 convergence of network and computing brought by edge computing 143 includes the issue of service deployment and service request 144 scheduling. ALTO has done the work of collect the network 145 information for application, it may help to do some work in the two 146 important issues: 148 How to deploy service nodes based on computing resources. For this 149 point, [draft-contras-alto-service-edge-02] gives the corresponding 150 idea of using Alto to deploy edge computing nodes. Alto can better 151 interact with the upper application, fully understand the 152 requirements of the application, including computing requirements and 153 collect the information of infrastructure resources. 155 How to select the most suitable node for service request. Alto can 156 also help this kind of work to a certain extent. Centralized 157 selection of service nodes and paths is relatively easy to implement, 158 such as SDN. However, emerging service requests require high real- 159 time performance, and there may be some efficiency and complexity 160 problems, which have been analyzed in the work of dyncast. 162 2. Usage Scenarios of CAN 164 Any multi-point deployment service that requires high computing power 165 or low latency will involve the joint scheduling of network and 166 computing resources. 168 2.1. AR/VR 170 Take the AR/VR as an example. The upper bound latency for motion-to- 171 photon (MTP) is less than 20 milliseconds to avoid the motion 172 sickness. It consists of four parts, and the frame rendering 173 computing delay is 5.5 milliseconds, so the network delay demand can 174 be calculated as 5.1milliseconds. 176 +-----------------------+---------------------+ 177 | Total MTP delay | 50ms | 178 +-----------------------+---------------------+ 179 | sensor sampling delay | <1.5ms | 180 +-----------------------+---------------------+ 181 | display refresh delay | 5 ms | 182 +-----------------------+---------------------+ 183 | frame rendering delay | 5.5ms | 184 | computing with GPU | | 185 +-----------------------+---------------------+ 186 | network delay | 20-1.5-5.5-7.9=5.1ms| 187 +-----------------------+---------------------+ 189 Delay of MTP 191 So the budgets for computing delay and network delay are almost 192 equivalent. Considering another factor that the computing resources 193 have a big difference in different edges,it is necessary to apply 194 dynamically steer traffic to the 'best' edge. 196 2.2. Internet of Vehicles 198 Under the scenario of Internet of Vehicles, the services are divided 199 into auxiliary driving and on-board entertainment services . For the 200 auxiliary driving function, for road traffic conditions outside the 201 line of sight due to obstructions, blind areas, etc., the edge 202 computing node obtains comprehensive road traffic information around 203 the location of the vehicle, performs unified data processing, and 204 sends out warning signals for vehicles with potential safety hazards, 205 to assist the safe driving of vehicles. 207 Apparently, there are obviously differences between services 208 requirements of auxiliary driving services and entertainment 209 services, which needs to be processed by different edge nodes 211 3. CAN Framework and ALTO 213 In order to realize ubiquitous computing and service awareness, 214 interconnection and collaborative scheduling, the computing-aware 215 networking architecture can be divided into computing service layer, 216 computing resource layer, computing routing layer, network resource 217 layer, and computing and network management layer. Among them, the 218 computing routing layer contains the control plane and data plane 219 which is shown in Figure 2. Based on the ubiquitous computing 220 resources of the network, the computing resource layer abstracts and 221 models based on a unified measurement and modeling template, and 222 announces computing information to the computing routing layer. And 223 then the computing routing layer comprehensively considers user needs 224 and network resource status and computing resource status, to 225 schedule service requests to appropriate computing nodes. In 226 addition, the computing management layer completes the control and 227 management of computing resources. 229 Computing-aware Networking Framework 230 +---------------------------------------+ +------------------------+ 231 | Computing Service Layer |<->| Computing and Network | 232 +---------------------------------------+ | Management Layer | 233 | Computing Resource Layer |<->|+----------------------+| +---------+ 234 +---------------------------------------+ || Service Orchestration|<--------| | 235 | Computing-aware Routing Layer | |+----------------------+| | | 236 | +---------------+ +---------------+ |<->|| Computing OAM |<--------| | 237 | | Control Plane | | Data Plane | | |+----------------------+| | ALTO | 238 | +---------------+ +---------------+ |<->|| Routing Management |<--------| | 239 +---------------------------------------+ |+----------------------+| | | 240 | Network Resource Layer |<->|| Resource Management |<--------| | 241 +---------------------------------------+ |+----------------------+| +---------+ 243 CAN Framework and ALTO 245 * Computing service layer: computing service layer is computing 246 service provider, which deploys, operates and manages many kinds of 247 computing services and applications. In addition, it can realize the 248 functions of service decomposition and service scheduling through the 249 API gateway. 251 * Computing resource layer: it is based on the existing computing 252 infrastructure, and includes a combination of computing resources 253 from single-core CPU to multi-core CPU, CPU+GPU+FPGA, etc. And it 254 could supply computing modeling function, computing API function, 255 computing resource identification and other functions to meet the 256 diverse computing needs of different applications based on physical 257 computing resources. 259 * Computing-aware routing layer: It contains control plane and data 260 plane, performs computing-aware routing and generates service 261 scheduling policy in network layer. Based on the discovery of 262 abstracted computing and network resources, computing routing layer 263 generates new routing tables which include the information of 264 computing in network, considers the state of network and computing 265 comprehensively, and thus generates routing policy for different 266 service requests. Network resource layer: It utilizes the existing 267 network infrastructure, which includes access network, metropolitan 268 area network and backbone network, to provide ubiquitous network 269 connection. 271 * Computing and network management layer: It adds management 272 functions towards computing resources and computing services based on 273 the traditional network management function. Therefore, the 274 computing and network management layer performs service 275 orchestration, resource management, routing measurement and computing 276 OAM. In addition, the computing and network management layer could 277 be used to perform the pre-configuration function and management 278 function, which interacts with each functional layer. 280 * Network resource layer: using the existing network infrastructure 281 to provide network connection, network infrastructure includes access 282 network, metropolitan area network and backbone network. 284 Based on the five functional modules defined above, computing-aware 285 networking can realize the awareness, control and scheduling of 286 computing and network resources, and further perform dynamic and on- 287 demand service scheduling. The function of computing and network 288 management layer may be realized by Alto or by opening interface with 289 Alto server. 291 4. Deployment of CAN with ALTO 293 With the development of edge computing, there is multiple services 294 duplication deployed in different edge nodes. To improve the 295 effectiveness of service deployment, the problem of how to choose 296 optimal edge node to deploy services needs to be solved. More stable 297 static information should be considered in service deployment, such 298 as: 300 * Network topology: the overall consideration of network access, 301 connectivity, path protection or redundancy 303 * The topology of computing resources: including the location and 304 overall distribution of computing resources in network, and the 305 relative position towards network topology. 307 * Types of computing resources of edge nodes: such as CPU / GPU, etc 309 * Location: the number of users brought, the differentiation of 310 service types requested by users, etc 312 * Location of edge nodes: for edge nodes located in popular area, 313 which with large amount of users and service requests, the service 314 duplication can be deployed more than other areas. 316 * Capacity of multiple edge nodes: not only a single node, but also 317 the total number of requests that can be processed by the resource 318 pool composed of multiple nodes 320 * Service category: different types of services require different 321 computing resources. It's necessary to consider the e category of 322 computing resources required by the services to deploy services. For 323 example, whether the business is multi-user interaction, such as 324 video conferencing, games, or just resource acquisition, such as 325 short video viewing Alto can help to obtain one or more of the above 326 information, so as to provide suggestions or formulate principles and 327 strategies for service deployment. 329 For the collection of those information, second level or minute level 330 frequency is enough, while serious real-time processing isn't 331 necessary. For example, periodically collecting the total 332 consumption of computing resources, or the total number of sessions 333 accessed, to notify where to depoly more VMS or containers. Unlike 334 the scheduling of request, service deployment should still follow the 335 principle of proximity. The more local access, the more resources 336 should be deployed. If the resources are insufficient, the operator 337 can be informed to increase the hardware resources. Alto can be used 338 to transmit information. 340 5. Scheduling of CAN with ALTO 342 Compared to the deployment, scheduling needs to consider more dynamic 343 information to select and adjust the optimal (rather than the 344 shortest) path in real timesuch as: 346 * Mobility: CAN schedules service request to the optimal service node 347 among several service nodes near to users. So when user mobiles, the 348 nearby service nodes changes and new scheduling are needed to chooses 349 new path and new service node. 351 * Real time delay of network: network delay is always in the process 352 of dynamic change, and more and more services propose strict time 353 requirements, which is one of the most important factors affecting 354 user experience. 356 * Real time status of computing resources: computing resources change 357 frequently and the status of computing resources heavily affect the 358 completion time of service, which is also one of the most important 359 factors affecting user experience. 361 * Comprehensive status of network status and computing status: the 362 update frequency of computing status and network status is different, 363 it is necessary to generate a comprehensive value to reflect the 364 status of them. 366 * Various service requirements: different services propose different 367 service requirements on computing and network, including bandwidth, 368 latency, computing resources etc, and the latency includes both 369 transmission latency in network and processing latency in service 370 node, for transmission-intensive services, the transmission latency 371 accounts a lot , so the network latency of services are more 372 important. 374 Availability of network or computing resources: such as temporary 375 unavailability caused by network equipment or service node failure. 377 Alto can still help collect real-time network and service node 378 information： 380 * Providing the best choice of network and service nodes. Based on 381 the collected network information, computing information, and service 382 requirements on network and computing, Of course, there are still 383 some real-time and complexity problems. 385 * Providing data analysis and policy distribution, real-time node 386 selection still depends on distributed routing, such as dyncast. 388 6. Summary 390 The converge of network and computing, as well as the interaction 391 with applications has become one of the current technical development 392 directions. This draft analyzes the development status of the 393 current computing aware network and the functional modules in its 394 architecture that can interact with Alto. As a protocol to connect 395 networks and applications, Alto may play a more important role. 397 7. Security Considerations 399 TBD. 401 8. IANA Considerations 403 TBD. 405 9. Acknowledgements 407 Thanks to Yizhou Li, Qin Wu, Tianji Jiang for helpful suggestion. 408 Thanks go to Dirk Trossen, Luigi Iannone, and Carsten Bormann for 409 their inspiring Dyncast work. 411 10. Normative References 413 [I-D.li-dyncast-architecture] 414 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 415 Anycast Architecture", draft-li-dyncast-architecture-00 416 (work in progress), February 2021. 418 [I-D.liu-dyncast-ps-usecases] 419 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 420 (Dyncast) Use Cases & Problem Statement", draft-liu- 421 dyncast-ps-usecases-01 (work in progress), February 2021. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 Authors' Addresses 430 Peng Liu 431 China Mobile 432 Beijing 100053 433 China 435 Email: liupengyjy@chinamobile.com 437 Yuexia Fu 438 China Mobile 439 Beijing 100053 440 China 442 Email: fuyuexia@chinamobile.com