idnits 2.17.1 draft-li-rtgwg-cfn-framework-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1628 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8174' is mentioned on line 127, but not defined -- No information found for draft-geng-rtgwg-CFN-req - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Y. Li 3 INTERNET-DRAFT J. He 4 Intended Status: Informational Huawei Technologies 5 Expires: May 7, 2020 L. Geng 6 P. Liu 7 China Mobile 8 Y. Cui 9 Tsinghua University 10 November 4, 2019 12 Framework of Compute First Networking (CFN) 13 draft-li-rtgwg-cfn-framework-00 15 Abstract 17 Compute First Networking (CFN) leverages both computing and 18 networking status to help determine the optimal edge among multiple 19 edge sites with different geographic locations to serve a specific 20 edge computing request. Requests for the same service can be 21 determined and dispatched to different edges based on service 22 requirements, network and computing resource conditions and other 23 factors to achieve better load balancing and system efficiency. The 24 request needs to be dispatched to the selected edge in real time and 25 the subsequent packets from the same flow should be served by the 26 same edge for flow affinity. This document describes a framework of 27 CFN to achieve the desired features. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2019 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. CFN Framework . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1 CFN Service Overview . . . . . . . . . . . . . . . . . . . . 5 70 2.2 Generic Workflow . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Control Plane and Data Plane . . . . . . . . . . . . . . . . . 7 72 3.1 Control plane . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2 Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 80 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Compute First Networking (CFN) scenarios and requirements document 86 [CFN-req] shows the usage scenarios that require an edge to be 87 dynamically selected from multiple edge sites with different 88 geographic locations to serve an edge computing request based on 89 computing resource consumption and network status in real time. For 90 instance, edge site in residential area receives low request volume 91 during working hours and high request volume during non-working 92 hours. And the request volume received by the edge site in industrial 93 park is the opposite. Such a pattern causes a big difference of 94 computing load on different edge sites. Traditional static or hashing 95 based service dispatch can not adapt to the unbalanced nature of 96 computing load or rapid change of it on different edge sites. One 97 edge such as the closest one to the client may have been overloaded 98 and at the same time the other edges may still have plenty of 99 computing resources to serve the requests. To efficiently leveraging 100 the computing resources hosted on all edges, service requests should 101 be dispatched and handled dynamically to make the computing and 102 network resources consumed in a balanced way. 104 CFN assumes there are multiple service equivalent edges to serve a 105 single service. A single edge has limited computing resources and 106 different edges may have different resources available for serving a 107 specific service at a specific time. In concept, multiple edges are 108 interconnected and collaborated with each other to balance the 109 service load in CFN. Computing resource available to serve a request 110 is the top metric to be considered when dispatching a request. At the 111 same time, the quality of the network path to an edge varies over 112 time. CFN is a network based approach so that the request is 113 dispatched to the optimal edge in terms of both computing resources 114 available and network status on the fly. 116 This document presents a CFN framework which can support service 117 equivalency and dynamics in edge computing to achieve better load 118 balancing with no application dependency. 120 1.1 Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 CFN: Computing First Networking 130 2. CFN Framework 132 Edge computing is expanding from a single edge site to networked and 133 collaborated multiple edge sites to solve the issues of low 134 efficiency and and low resource reuse. CFN enables large scale edge 135 interconnection and collaboration, providing optimal service access 136 and load balancing to adapt to service dynamics. Based on the real- 137 time computing capacity available and the network conditions, CFN 138 dynamically schedules computing request to appropriate service node, 139 thus the resource utilization and user experience is improved. 141 Figure 1 shows the network topology of CFN. CFN node is the basic 142 function entity in CFN network to provide the capability to exchange 143 the information about the computing resource consumption information 144 of service nodes attached to it and/or provide the CFN service access 145 to the clients. Edge site (edge for short) is normally the site where 146 the edge computing is hosted. CFN node can be a network virtual 147 function (NFV) co-located with service node in a server. CFN node's 148 function can also be provided by physical equipment like access 149 router in access ring or metro network. 151 edge site 1 edge site 2 edge site 3 153 +------------+ 154 +------------+ +------------+ | 155 +-+----------+ | +-+----------+ |-+ 156 |service node|-+ |service node|-+ 157 +------------+ +------------+ 158 | | 159 | | 160 +----------+ +----------+ +----------+ 161 |CFN node 1| ------ |CFN node 2| ------- |CFN node 3| CFN 162 +----------+ +----------+ +----------+ layer 163 | | 164 | | 165 | | 166 +-----+ +-----+ 167 +------+| +-----+| 168 |client|+ +-----+|+ 169 +------+ +------+|+ 170 |client|+ 171 +------+ 173 Figure 1. CFN Network Topology 175 2.1 CFN Service Overview 177 CFN uses Service ID (SID) to identify a particular service provided 178 by service nodes on multiple edges. The end devices always use SID to 179 initiate an access to a service. SID in current system is an anycast 180 address. Request to a single SID can potentially be served by 181 different edge sites. The end device does not know in advance which 182 edge to serve the request. The procedures to make such determination 183 is called the service dispatch. During service dispatch, the most 184 appropriate edge site (i.e. CFN egress) is selected and it is the 185 edge to which the service node that handles this specific request is 186 attached to. A binding IP (BIP) address to the requested SID is known 187 by CFN egress. BIP is a unicast IP address accessible to a particular 188 service node providing service SID. 190 As shown in figure 2, service with SID 2 can be served by either CFN 191 node 2 with binding IP BIP22 or CFN node 3 with BIP32. When the 192 service request from the end device to SID2 reaches the ingress CFN 193 (which is CFN node 1 in this case), the ingress CFN node should 194 determine on the fly which egress CFN this request should be sent to. 195 Then, the de facto service node is determined, and all the subsequent 196 data packets from the same flow to access this service should always 197 be sent to the binding IP of the selected service node. 199 edge 1 edge 2 edge 3 200 ----- 201 +-----------------+ +-----------------+ /|\ 202 +----------------+ |+-----+ +-----+ | |+-----+ +-----+ | | 203 |+-----+ +-----+| ||BIP21|--|SID1 | | ||BIP32|--|SID2 | | | 204 ||BIP13|--|SID3 || |+-----+ +-----+ | |+-----+ +-----+ | | 205 |+-----+ +-----+| |+-----+ +-----+ | |+-----+ +-----+ | | 206 +--------+-------+ ||BIP22|--|SID2 | | ||BIP33|--|SID3 | | | 207 | |+-----+ +-----+ | |+-----+ +-----+ | | 208 | +-------+---------+ +-------+---------+ CFN 209 | | | 210 +----+-----+ +----+-----+ +----+-----+ | 211 |CFN node 1|------ |CFN node 2| ---------|CFN node 3| | 212 +----+-----+ +----------+ +----------+ | 213 | | 214 | | 215 +-----------+ | 216 |CFN adaptor| \|/ 217 +-----------+ ------------ 218 | /|\ 219 | | 220 +----------+ client side 221 |end device| | 222 +----------+ \|/ 223 ----------- 225 Figure 2. CFN System Overview 227 CFN adaptor shown in figure 2 is an entity to help the end device 228 working with CFN in a way of keeping the binding information, 229 identifying the initial request packet, and so on. It can be 230 implemented as a part of CFN node (internal mode) or on a separate 231 equipment (external mode). Figure 2 shows an external mode of CFN 232 adaptor which can be deployed at the client side, on a virtual 233 gateway connecting multi user equipments (UEs), as a user Plane 234 Function (UPF) in the mobile network, or on Broadband Remote Access 235 Server (BRAS) in the fixed network. The reason to have such an 236 external mode is that CFN adaptor can be put closer to the clients, 237 and then CFN node is put at some aggregated point with multiple CFN 238 adaptors attached to it. Compared to the internal mode, external CFN 239 adaptor keeps less binding information of the clients. It results in 240 less memory requirements on CFN node. CFN adaptor has no control 241 plane. 243 2.2 Generic Workflow 245 The following procedures describe how CFN works in general. 247 1) CFN adaptor identifies a new service request from the end device, 248 possibly by the special anycast address range for a SID. 250 2) CFN adaptor sends the request to its attaching CFN node which is 251 CFN ingress. 253 3) CFN ingress determines the most appropriate CFN egress based on 254 the computing resource consumption of the service nodes, the network 255 status to the egress nodes and other information. CFN ingress 256 forwards the request to the selected CFN egress. CFN ingress can 257 select itself to serve the request. In this case, it is both ingress 258 and egress in concept. 260 4) CFN egress receives the request from the CFN ingress and 261 explicitly uses the binding IP BIP as destination address to access 262 the required service. 264 5) CFN adaptor of ingress keeps the binding information on (SID, CFN 265 egress) for the flow. 267 6) CFN ingress sends the subsequent packets for the same service from 268 the same flow to the bound CFN egress to ensure the flow affinity. 270 7) CFN nodes distribute the service nodes status like available 271 computing resources for specific services to each other on a regular 272 base. 274 3. Control Plane and Data Plane 276 3.1 Control plane 278 CFN node needs to notify each other about service IDs (SIDs) 279 attaching to it and the computing load information available 280 corresponding to each service ID. This is used for service discovery 281 and dispatch when a request to access a SID is received. Such 282 information can be carried in current BGP [RFC4760] /IGP routing 283 protocol extension. The network cost to a CFN node can be distributed 284 in the same way. A sample service status information to be stored on 285 a CFN edge is shown in figure 2. 287 +---------------+---------------+----------------+----------------+ 288 | | Computing | | | 289 |Destination | Load | Network Cost | Next Hop | 290 +---------------+---------------+----------------+----------------+ 291 | | | | CFN Egress | 292 |SID 1 | 3 | 5 | node 1 | 293 +---------------+---------------+----------------+----------------+ 294 Figure 2. Example of service status information in CFN 296 Computing load can be calculated from different weighted dimensions, 297 e.g. CPU used, number of session being served, query per second, 298 computation delay and so on. Such information needs to be refreshed 299 regularly. In order to avoid fluctuation, it is distributed only when 300 the metrics variation exceeds a threshold or the updating timer is 301 expired. At the same time, the most appropriate egress node selected 302 by the CFN ingress does not necessarily mean the one with the lowest 303 load. Request can be sent to one selected from those egresses with 304 relatively low computing load to avoid fluctuation. 306 Since SID is an anycast address, CFN ingress determines which CFN 307 egress to forward the request to a specific SID to based on a 308 combination of computing load and network cost. 310 Figure 3 shows how CFN control plane works in general. It depicts 311 that CFN node 3 distributes computing information for service SID2. 312 CFN node 2 should distribute service SID 2 information in the similar 313 way as shown in figure 3. Definition and operations to extend control 314 plane routing protocol to support CFN information distribution, and 315 schemes/criteria to select CFN egress with anycast address from those 316 information are to be added. 318 CFN CFN CFN Edge Platform 319 Node 1 Node 2 Node 3 Manager 321 | | | | 322 | | | | 323 | | |<------------------| 324 | | | 1.Service info | 325 | | | registration/ | 326 | | | update/withdraw | 327 | | | (SID2, BIP32) | 328 | | | | 329 | | | | 330 | | |<------------------| 331 | | | 2.Computing load | 332 | | | update triggering | 333 | | | (SID2,computing | 334 | | | load information) | 335 | | | | 336 | | | | 337 | |<---------------------| | 338 | | | | 339 |<------------------------------| | 340 | | 3.BGP update for | | 341 | | computing load | | 342 | | (SID2, CFN node 3, | | 343 | | computing load info)| | 344 | | | | 346 Figure 3. CFN control plane 348 3.2 Data plane 350 The traditional anycast is normally used for single request single 351 response style communication as different requests may be sent to 352 different places when the network status changes. CFN used in edge 353 computing may require multiple request multiple response style 354 communication between the end device and the service node. Therefore 355 the data plane must maintain flow affinity to ensure that the 356 requests from the same flow are always processed by the same edge and 357 that edge is determined at the time when the first anycast request is 358 received by CFN ingress. The service access to the same SID from 359 different end hosts attaching to the same CFN ingress may be 360 dispatched to different CFN egresses. We call such a feature dynamic 361 anycast or Dyncast in this document. 363 Dyncast puts some requirements on the data plane. The flow affinity 364 table needs to be maintained by CFN ingress. On the other hand, large 365 number of end hosts may attach to a CFN node. Therefore CFN ingress 366 may require large memory space, such as tens of thousands of entries, 367 to maintain such a big table of (flow, service ID, egress CFN). It is 368 preferable to place such a binding table on an external CFN adaptor 369 as CFN adaptor only needs to maintain a much smaller table, usually 370 less than a hundred. 372 Figure 4 shows how CFN data plane works in general. 374 CFN node 1 CFN node 3 Service 375 client (CFN ingress) (CFN egress) Node for S 377 | | | | 378 |1.service req | | | 379 |------------->| | | 380 |dst=SID2 | | | 381 |src=client_IP | | | 382 | | | | 383 | +----------------+ | | 384 | |2.Select CFN | | | 385 | |egress & save it| | | 386 | +----------------+ | | 387 | | | | 388 | |3. encap & forward | | 389 | |---------------------> | | 390 | |outer: dst=CFN_Node_3 | | 391 | | src=CFN_Node_1 | | 392 | |inner: dst=SID2 | | 393 | | src=client_IP | | 394 | | +----------------+ | 395 | | |4.decap & map | | 396 | | |SID2 to BIP32 | | 397 | | +----------------+ | 398 | | |5. forward pkt | 399 | | |------------------>| 400 | | |dst=BIP32 | 401 | | | | 402 | | | 6. service rsp | 403 | | |<----------------- | 404 | | |src=BIP32 | 405 | | | | 406 | | +----------------+ | 407 | | |7.map BIP32 back| | 408 | | |to SID2 | | 409 | | +----------------+ | 410 | | | | 411 | |8. encap and forward | | 412 | |<--------------------- | | 413 | |outer: dst=CFN_Node_1 | | 414 | | src=CFN_Node_3 | | 415 | |inner: dst=client_IP | | 416 | | src=SID2 | | 417 | 9. decap | | | 418 | &forward | | | 419 |<-------------| 421 Figure 4. CFN data plane for the first request of a flow 423 The data plane supports the following functions. 425 - CFN ingress forwards the first service access request packet of a 426 flow to the selected CFN egress by encapsulation, source routing or 427 segment routing. Figure 4 shows the example of forwarding by 428 encapsulation. 430 - CFN ingress can inform the external CFN adaptor (if there is) about 431 the binding information on (flow, service ID, egress CFN). 433 - CFN adaptor (internal or external to CFN ingress) maintains the 434 binding information table for all end hosts attaching to it and 435 forwards the subsequent packets based on the binding information if 436 any. 438 4. Summary 440 This draft introduces a CFN framework that enables the service 441 request to be sent to an optimal edge to improve the overall system 442 load balancing. It can dynamically adapt to the computing resources 443 consumption and network status on edges and avoid overloading a 444 single load. CFN is a network based solution that supports a large 445 number of edges and is independent of the applications or services 446 hosted on the edge. 448 This present document is a strawman for defining CFN framework. A 449 routing protocol (BGP [RFC4760]/IGP based) extension to distribute 450 computing resource information and a late binding based dynamic 451 anycast are to be defined on control plane and data plane 452 respectively. 454 5. Security Considerations 456 The computing resource information changes over time very fast with 457 the creation and termination of service instance handlers. When such 458 information is carried in routing protocol, too many updates can make 459 the network fluctuate. Section 3.1 gives a brief idea on avoiding 460 sending too much updates. 462 6. IANA Considerations 464 No IANA action is required so far. 466 7. Acknowledgements 467 8. References 469 8.1 Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 8.2 Informative References 476 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 477 "Multiprotocol Extensions for BGP-4", RFC 4760, January 478 2007. 480 [CFN-req] Geng, L., et al, "Compute First Networking (CFN) Scenarios 481 and Requirements", draft-geng-rtgwg-CFN-req-00, November 482 2019. 484 Authors' Addresses 486 Yizhou Li 487 Huawei Technologies 489 Email: liyizhou@huawei.com 491 Jeffrey He 492 Huawei Technologies 494 Email: jeffrey.he@huawei.com 496 Liang Geng 497 China Mobile 498 Email: gengliang@chinamobile.com 500 Peng Liu 501 China Mobile 502 Email: liupengyjy@chinamobile.com 504 Yong Cui 505 Tsinghua University 507 Email: cuiyong@tsinghua.edu.cn