idnits 2.17.1 draft-sarathchandra-coin-appcentres-03.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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2020) is 1279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COIN D. Trossen 3 INTERNET-DRAFT Huawei 4 Intended Status: Informational C. Sarathchandra 5 Expires: April 25, 2021 InterDigital Inc. 6 M. Boniface 7 University of Southampton 8 October 23, 2020 10 In-Network Computing for App-Centric Micro-Services 11 draft-sarathchandra-coin-appcentres-03 13 Abstract 15 The application-centric deployment of 'Internet' services has 16 increased over the past ten years with many millions of applications 17 providing user-centric services, executed on increasingly more 18 powerful smartphones that are supported by Internet-based cloud 19 services in distributed data centres, the latter mainly provided by 20 large scale players such as Google, Amazon and alike. This draft 21 outlines a vision for evolving those data centres towards executing 22 app-centric micro-services; we dub this evolved data centre as an 23 AppCentre. Complemented with the proliferation of such AppCentres at 24 the edge of the network, they will allow for such micro-services to 25 be distributed across many places of execution, including mobile 26 terminals themselves, while specific micro-service chains equal 27 today's applications in existing smartphones. We outline the key 28 enabling technologies that needs to be provided for such evolution to 29 be realized, including references to ongoing IETF work in some 30 areas. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1 Mobile Application Function Offloading . . . . . . . . . . 5 73 3.2 Interactive Real-time Applications . . . . . . . . . . . . 7 74 3.3 Distributed AI . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4 Content Delivery Networks . . . . . . . . . . . . . . . . . 8 76 3.5 Compute-Fabric-as-a-Service (CFaaS) . . . . . . . . . . . . 8 77 4 Requirements Derived from Use Cases . . . . . . . . . . . . . . 9 78 5 Enabling Technologies . . . . . . . . . . . . . . . . . . . . . 10 79 5.1 Application Packaging . . . . . . . . . . . . . . . . . . . 10 80 5.2 Service Deployment . . . . . . . . . . . . . . . . . . . . 11 81 5.3 Compute Inter-Connection at Layer 2 . . . . . . . . . . . . 12 82 5.4 Service Routing . . . . . . . . . . . . . . . . . . . . . . 13 83 5.5 Constraint-based Forwarding Decisions . . . . . . . . . . . 14 84 5.6 Collective Communication . . . . . . . . . . . . . . . . . 14 85 5.7 State Synchronization . . . . . . . . . . . . . . . . . . . 15 86 5.8 Dynamic Contracts . . . . . . . . . . . . . . . . . . . . . 15 87 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 88 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 89 8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 92 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1 Introduction 97 With the increasing dominance of smartphones and application markets, 98 the end-user experiences today have been increasingly centered around 99 the applications and the ecosystems that smartphone platforms create. 100 The experience of the 'Internet' has changed from 'accessing a web 101 site through a web browser' to 'installing and running an application 102 on a smartphone'. This app-centric model has changed the way services 103 are being delivered not only for end-users, but also for business-to- 104 consumer (B2C) and business-to-business (B2B) relationships. 106 Designing and engineering applications is largely done statically at 107 design time, such that achieving significant performance improvements 108 thereafter has become a challenge (especially, at runtime in response 109 to changing demands and resources). Applications today come 110 prepackaged putting them at disadvantage for improving efficiency due 111 to the monolithic nature of the application packaging. Decomposing 112 application functions into micro-services [MSERVICE1] [MSERVICE2] 113 allows applications to be packaged dynamically at run-time taking 114 varying application requirements and constraints into consideration. 115 Interpreting an application as a chain of micro-services, allows the 116 application structure, functionality, and performance to be adapted 117 dynamically at runtime in consideration of tradeoffs between quality 118 of experience, quality of service and cost. 120 Interpreting any resource rich networked computing (and storage) 121 capability not just as a pico or micro-data centre, but as an 122 application-centric execution data centre (AppCentre), allows 123 distributed execution of micro-services. Here, the notion of an 124 'application' constitutes a set of objectives being realized in a 125 combined packaging of micro-services under the governance of the 126 'application provider'. These micro-services may then be deployed on 127 the most appropriate AppCentre (edge/fog/cloud resources) to satisfy 128 requirements under varying constraints. In addition, the high degree 129 of distribution of application and data partitions, and compute 130 resources offered by the execution environment decentralizes control 131 between multiple cooperating parties (multi-technology, multi-domain, 132 multi-ownership environments). Furthermore, compute resource 133 availability may be volatile, particularly when moving along the 134 spectrum from well-connected cloud resources over edge data centres 135 to user-provided compute resources, such as (mobile) terminals or 136 home-based resources such as NAS and IoT devices. 138 We believe that the emergence of AppCentreS will democratize 139 infrastructure and service provision to anyone with compute resources 140 with the notion of applications providing an element of governing the 141 execution of micro-services. This increased distribution will lead to 142 new forms of application interactions and user experiences based on 143 cooperative AppCentreS (pico-micro and large cloud data centres), in 144 which applications are being designed, dynamically composed and 145 executed. 147 2 Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3 Use Cases 155 Although our motivation for the 'AppCentre' term stems from the 156 (mobile) application ecosystem, the use cases in this section are not 157 limited to mobile applications only. Instead, we interpret 158 'applications' as a governing concept of executing a set of micro- 159 services where the 'application provider' can reach from those 160 realizing mobile applications over novel network applications to 161 emerging infrastructure offerings serving a wide range of 162 applications in a purpose- (and therefore application-)agnostic 163 manner. The following use cases provide examples for said spectrum of 164 applications. 166 3.1 Mobile Application Function Offloading 168 Partitioning an application into micro-services allows for denoting 169 the application as a collection of functions for a flexible 170 composition and a distributed execution, e.g., most functions of a 171 mobile application can be categorized into any of three, "receiving", 172 "processing" and "displaying" function groups. 174 Any device may realize one or more of the micro-services of an 175 application and expose them to the execution environment. When the 176 micro-service sequence is executed on a single device, the outcome is 177 what you see today as applications running on mobile devices. 178 However, the execution of functions may be moved to other (e.g., more 179 suitable) devices which have exposed the corresponding micro-services 180 to the environment. The result of the latter is flexible mobile 181 function offloading, for possible reduction of power consumption 182 (e.g., offloading CPU intensive process functions to a remote server) 183 or for improved end user experience (e.g., moving display functions 184 to a nearby smart TV). 186 The above scenario can be exemplified in an immersive gaming 187 application, where a single user plays a game using a VR headset. The 188 headset hosts functions that "display" frames to the user, as well as 189 the functions for VR content processing and frame rendering combining 190 with input data received from sensors in the VR headset. Once this 191 application is partitioned into micro-services and deployed in an 192 app-centric execution environment, only the "display" micro-service 193 is left in the headset, while the compute intensive real-time VR 194 content processing micro-services can be offloaded to a nearby 195 resource rich home PC, for a better execution (faster and possibly 196 higher resolution generation). 198 Figure 1 shows one realization of the above scenario, where a 'DPR 199 app' is running on a mobile device (containing the partitioned 200 Display(D), Process(P) and Receive(R) micro services) over an SDN 201 network. The packaged applications are made available through a 202 localized 'playstore server'. The application installation is 203 realized as a 'service deployment' process (Section 5.2.), combining 204 the local app installation with a distributed micro-service 205 deployment (and orchestration) on most suitable AppCentreS 206 ('processing server'). 208 +----------+ Processing Server 209 Mobile | +------+ | 210 +---------+ | | P | | 211 | App | | +------+ | 212 | +-----+ | | +------+ | 213 | |D|P|R| | | | SR | | 214 | +-----+ | | +------+ | Internet 215 | +-----+ | +----------+ / 216 | | SR | | | / 217 | +-----+ | +----------+ +------+ 218 +---------+ /|SDN Switch|_____|Border| 219 \ +-------+ / +----------+ | SR | 220 \| 5GAN |/ | +------+ 221 +-------+ | 222 +---------+ | 223 |+-------+| +----------+ 224 ||Display|| /|SDN Switch| 225 |+-------+| +-------+ / +----------+ 226 |+-------+| /|WIFI AP|/ \ 227 || D || / +-------+ +--+ 228 |+-------+|/ |SR| 229 |+-------+| /+--+ 230 || SR || +---------+ 231 |+-------+| |Playstore| 232 +---------+ | Server | 233 TV +---------+ 235 Figure 1: Application Function Offloading Example 237 Such localized deployment could, for instance, be provided by a 238 visiting site, such as a hotel or a theme park. Once the 'processing' 239 micro-service is terminated on the mobile device, the 'service 240 routing' (SR) elements in the network (Section 5.4.) routes requests 241 to the previously deployed 'processing' micro-service running on the 242 'processing server' AppCentre over an existing SDN network. As an 243 extension to the above scenarios, we can also envision that content 244 from one processing micro-service may be distributed to more than one 245 display micro-service, e.g., for multi/many-viewing scenarios. 247 3.2 Interactive Real-time Applications 249 There has been a recent shift from applications that provide single- 250 user experiences, such as the ones described in the previous section 251 to collaborative/cooperative experiences that are highly interactive 252 with strict real-time requirements, such as collaborative working, 253 education, multi-user gaming, and mixed/virtual reality. This leads 254 to increasing interaction where input (e.g., gesture, gaze, touch, 255 movement) and output (e.g., visual display, sound, and actuation) 256 needs to be processed within strict timing constraints and 257 synchronized to ensure temporal and spatial consistency with local 258 and distant users. App-centric design allows functions with high data 259 and process coupling to be modularized, deployed and executed, such 260 that the subset of micro-services is cooperatively executed towards 261 optimizing the interactive experiences. 263 The same example of the previous section can be envisaged in a multi- 264 player gaming scenario. Here the micro-services that need to be 265 executed cooperatively are executed in a localized and synchronized 266 manner to ensure player coordination and synchronized state between 267 collaborating players. 269 3.3 Distributed AI 271 There is a growing range of use cases demanding for the realization 272 of AI capabilities among distributed endpoints. Such demand may be 273 driven by the need to increase overall computational power for large- 274 scale problems. Other solutions may desire the localization of 275 reasoning logic, e.g., for deriving attributes that better preserve 276 privacy of the utilized raw input data. Examples for large-scale AI 277 problems include biotechnology and astronomy related reasoning over 278 massive amounts of observational input data. Examples for localizing 279 input data for privacy reasons include radar-like application for the 280 development of topological mapping data based on (distributed) radio 281 measurements at base stations (and possibly end devices), while the 282 processing within radio access networks (RAN) already constitute a 283 distributed AI problem to a certain extent albeit with little 284 flexibility in distributing the execution of the AI logic. 286 Reasoning frameworks, such as TensorFlow, may be utilized for the 287 realization of the (distributed) AI logic, building on remote service 288 invocation through protocols such as gRPC [GRPC] or MPI [MPI] with 289 the intention of providing an on-chip NPU (neural processor unit) 290 like abstraction to the AI framework. 292 3.4 Content Delivery Networks 294 Delivery of content to end users often relies on Content Delivery 295 Networks (CDNs) storing said content closer to end users for latency 296 reduced delivery with DNS-based indirection being utilized to serve 297 the request on behalf of the origin server. From the perspective of 298 this draft, a CDN can be interpreted as a (network service level) 299 application with distributed logic for distributing content from the 300 origin server to the CDN ingress and further to the CDN replication 301 points which ultimately serve the user-facing content requests. 303 Studies such as those in [FCDN] have shown that content distribution 304 at the level of named content, utilizing efficient (e.g., Layer 2) 305 multicast for replication towards edge CDN nodes, can significantly 306 increase the overall network and server efficiency. It also reduces 307 indirection latency for content retrieval as well as reduces required 308 edge storage capacity by benefiting from the increased network 309 efficiency to renew edge content more quickly against changing 310 demand. 312 3.5 Compute-Fabric-as-a-Service (CFaaS) 314 App-centric execution environments, consisting of Layer 2 connected 315 AppcentreS, provide the opportunity for infrastructure providers to 316 offer CFaaS type of offerings to application providers. Those app 317 providers utilize the compute fabric exposed by this CFaaS offering 318 for the purposes defined through their applications. In other words, 319 the compute resources can be utilized to execute the desired micro- 320 services of which the application is composed, while utilizing the 321 inter-connection between those compute resources to do so in a 322 distributed manner. 324 We foresee those CFaaS offerings to be tenant-specific, a tenant here 325 defined as the provider of at least one application. For this, we 326 foresee an interaction between CFaaS provider and tenant to 327 dynamically select the appropriate resources to define the demand 328 side of the fabric. Conversely, we also foresee the supply side of 329 the fabric to be highly dynamic with resources being offered to the 330 fabric through, e.g., user-provided resources (whose supply might 331 depend on highly context-specific supply policies) or infrastructure 332 resources of intermittent availability such as those provided through 333 road-side infrastructure in vehicular scenarios. The resulting 334 dynamic demand-supply matching establishes a dynamic nature of the 335 compute fabric that in turn requires trust relationships to be built 336 dynamically between the resource provider(s) and the CFaaS provider. 337 This also requires the communication resources to be dynamically 338 adjusted to interconnect all resources suitably into the (tenant- 339 specific) fabric exposed as CFaaS. 341 4 Requirements Derived from Use Cases 343 The following requirements are derived from the presented use cases 344 in Section 3.1. to 3.5., numbered according to the use case numbers 345 (as main item numbers) although those requirements apply in some 346 cases across more than one of the presented use cases. 348 Req 1.1: Any app-centric execution environment MUST provide means for 349 routing of service requests between resources in the 350 distributed environment. 352 Req 1.2: Any app-centric execution environment MUST provide means for 353 dynamically choosing the best possible micro-service 354 sequence (i.e., chaining of micro-services) for a given 355 application experience. Means for discovering suitable 356 micro-service SHOULD be provided. 358 Req 1.3: Any app-centric execution environment MUST provide means for 359 pinning the excution of a specific micro-service to a 360 specific resource instance in the distributed environment. 362 Req 1.4: Any app-centric execution environment SHOULD provide means 363 for packaging micro-services for deployments in distributed 364 networked computing environments. The packaging MAY include 365 any constraints regarding the deployment of service 366 instances in specific network locations or compute 367 resources. Such packaging SHOULD conform to existing 368 application deployment models, such as mobile application 369 packaging, TOSCA orchestration templates or tar balls or 370 combinations thereof. 372 Req 2.1: Any app-centric execution environment MUST provide means for 373 real-time synchronization and consistency of distributed 374 application states. 376 Req 3.1: Any app-centric execution environment MUST provide means to 377 specify the constraints for placing (AI) execution logic in 378 certain logical execution points (and their associated 379 physical locations). 381 Req 3.2: Any app-centric execution environment MUST provide support 382 for app/micro-service specific invocation protocols. 384 Req 4.1: Any app-centric execution environment SHOULD utilize Layer 2 385 multicast transmission capabilities for responses to 386 concurrent service requests. 388 Req 5.1: Any app-specific execution environment SHOULD expose means 389 to specify the requirements for the tenant-specific compute 390 fabric being utilized for the app execution. 392 Req 5.2: Any app-specific execution environment SHOULD allow for 393 dynamic integration of compute resources into the compute 394 fabric being utilized for the app execution; those resources 395 include, but are not limited to, end user provided 396 resources. 398 Req 5.3: Any app-specific execution environment MUST provide means to 399 optimize the inter-connection of compute resources, 400 including those dynamically added and removed during the 401 provisioning of the tenant-specific compute fabric. 403 Req 5.4: Any app-specific execution environment MUST provide means 404 for ensuring availability and usage of resources is 405 accounted for. 407 5 Enabling Technologies 409 This section discusses a number of enabling technologies relevant for 410 the realization of the app-centric micro-service vision laid out in 411 this draft. 413 EDITOR NOTE: Section 5 will be updated to include the addressing of 414 specific requirements listed in Section 4. 416 5.1 Application Packaging 418 Applications often consist of one or more sub-elements (e.g., audio, 419 visual, hepatic elements) which are 'packaged' together, resulting in 420 the final installable software artifact. Conventionally, application 421 developers perform the packaging process at design time, by packaging 422 a set of software components as a (often single) monolithic software 423 package, for satisfying a set of predefined application 424 requirements. 426 Decomposing micro-services of an application, and then executing them 427 on peer execution points in AppCentreS (e.g., on an app-centric 428 serverless runtime [SRVLESS]) can be done with design-time planning. 429 Micro-service decomposition process involves, defining clear 430 boundaries of the micro-service (e.g., using wrapper classes for 431 handling input/output requests), which could be done by the 432 application developer at design-time (e.g., through Android app 433 packaging by including, as part of the asset directory, a service 434 orchestration template [TOSCA] that describes the decomposed micro- 435 services). Likewise, the peer execution points could be 'known' to 436 the application (e.g., using well-known and fixed peer execution 437 points on AppCentreS) and incorporated with the micro-services by the 438 developer at design-time. 440 Existing programming frameworks address decomposition and execution 441 of applications centering around other aspects such as concurrency 442 [ERLANG]. For decomposing at runtime, application elements can be 443 profiled using various techniques such as dynamic program analysis or 444 dwarf application benchmarks. The local profiler information can be 445 combined with the profiler information of other devices in the 446 network for improved accuracy. The output of such a profiler process 447 can then be used to identify smaller constituting sub-components of 448 the application in forms of pico-services, their interdependencies 449 and data flow (e.g., using caller/callee information, instruction 450 usage). Due to the complex nature of resulting application structure 451 and therefore its increased overhead, in most cases, it may not be 452 optimal to decompose applications at the pico level. Therefore, one 453 may cluster pico-services into micro-services with common 454 characteristics, enabling a meaningful (e.g., clustering pico- 455 services with same resource dependency) and a performant 456 decomposition of applications. Characteristics of micro-services can 457 be defined as a set of concepts using an ontology language, which can 458 then be used for clustering similar pico-services into micro- 459 services. Micro-services may then be partitioned along their 460 identified borders. Moreover, mechanisms for governance, discovery 461 and offloading can be employed for 'unknown' peer execution points on 462 AppCentreS with distributed loci of control. 464 Therefore, with this app-centric model, application packaging can be 465 done at runtime by constructing micro-service chains for satisfying 466 requirements of experiences (e.g., interaction requirements), under 467 varying constraints (e.g., temporal consistency between multiple 468 players within a shared AR/VR world)[SCOMPOSE]. Such packaging 469 includes mechanisms for selecting the best possible micro-services 470 for a given experience at runtime in the multi-technology 471 environment. These run-time packaging operations may continuously 472 discover the 'unknown' and adapt towards an optimal experience. Such 473 decision mechanisms handle the variability, volatility and scarcity 474 within this multi-X framework. 476 5.2 Service Deployment 478 The service function chains, constituting each individual 479 application, will need deployment mechanisms in a true multi-X 480 (multi-user, multi-infrastructure, multi-domain) environment 481 [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and 482 orchestration processes are married into one, as a set of procedures 483 governed by device owners directly or with delegated authority. 484 However, apart from extending towards multi-X environments, the 485 process also needs to cater for changes in the environment, caused, 486 e.g., by movement of users, new pervasive sensors/actuators, and 487 changes to available infrastructure resources. Methods are needed to 488 deploy service functions as executable code into chosen service 489 execution points. Those methods need to support the various endpoint 490 (e.g., device stacks, COTS stacks, etc.) and service function 491 realizations, e.g., through utilizing existing and emerging 492 virtualization techniques. 494 A combination of application installation procedure and orchestrated 495 service deployment can be achieved by utilizing the application 496 packaging with integrated service deployment templates described in 497 Section 5.1 such that the application installation procedure on the 498 installing device is being extended to not only install the local 499 application package but also extract the service deployment template 500 for orchestrating with the localized infrastructure, using, for 501 instance, REST APIs for submitting the template to the orchestrator. 503 5.3 Compute Inter-Connection at Layer 2 505 While Layer2 switching technologies have long proliferated in data 506 centre deployments, recent developments have advanced the 507 capabilities for interconnecting distributed computing resources over 508 Layer2 technologies. For instance, the efforts in 3GPP on so-called 509 '5G LAN' (or Vertical LAN) [SA2-5GLAN] allow for establishing a 510 Layer2 bearer between participating compute entities, using a 511 vertical-specific LAN identifier for packet forwarding between the 512 distributed Layer2 entities. Combined with Layer2 technology in data 513 centres as well as office and home networks alike, this enables the 514 deployment of services in vertical (Layer2) networks, interconnecting 515 with other Internet-based services through dedicated service 516 gateways. 518 Real deployments and realizations will have to show the scalability 519 of this approach but it points into a direction where application or 520 service-specific deployments could potentially 'live' entirely in 521 their own vertical network, interconnecting only based on need (which 522 for many services may not exist). From the application's or service's 523 perspective, the available compute resource pool will look no 524 different from that being realized in a single data centre albeit 525 with the possibility to being highly distributed now among many 526 (e.g., edge) data centres as well as mobile devices. 528 In such a deployment, it is interesting to study the realization of 529 suitable service routing capabilities, leading us to the next 530 technology area of interest. 532 5.4 Service Routing 534 Routing service requests is a key aspect within a combined compute 535 and network infrastructure in order to enable true end-to-end 536 experiences across distributed application execution points 537 provisioned on distant cloud, edge and device-centric resources. Once 538 the micro-services are packaged and deployed in such highly 539 distributed micro-data centres, the routing mechanisms must ensure 540 efficient information exchange between corresponding micro-services, 541 e.g., at the level of service requests, within the multi-technology 542 execution environment. 544 Routing here becomes a problem of routing micro-service requests, not 545 just packets, as done through IP. This calls for some form of 'flow 546 affinity' that allows for treating several packets as part of a 547 request semantic. This is important, e.g., for mobility (avoiding to 548 send some packets of a larger request to one entity, while other 549 packets are sent to another one, therefore creating incomplete 550 information at both entities as a result). Also, when applying 551 constraints to the forwarding of packets (discussed in more detail in 552 Section 5.6), it is important to apply the actions across the packets 553 of the request rather than individually. 555 Another key aspect is that of addressing services. Traditionally, the 556 combination of the Domain Naming Service (DNS) and IP routing has 557 been used for this purpose. However, the advent of virtualization 558 with use cases such as those outlined in Section 3 (such as those on 559 app-specific micro-services on mobile devices) have made it 560 challenging to further rely on the DNS. Apart from the initial delay 561 observed when resolving a service name into a locator for the first 562 time, the long delay in updating DNS entries to 'point' to the right 563 micro-service instances prohibits offloading to dynamically created 564 service instances. If one was to use the DNS, one would be updating 565 the DNS entries at a high rate, caused by the diversity of trigger, 566 e.g., through movement. DNS has not been designed for such frequent 567 update, rendering it useless for such highly dynamic applications. 568 With many edge scenarios in the VR/AR space demanding interactivity 569 and being latency-sensitive, efficient routing will be key to any 570 solution. 572 Various ongoing work on service request forwarding [RFC8677] with the 573 service function chaining [RFC7665] framework as well as name-based 574 routing [ICN5G][ICN4G] addresses some aspects described above albeit 575 with a focus on HTTP as the main invocation protocol. Extensions will 576 be required to support other invocation protocols, such as GRPC or 577 MPI (for distributed AI use cases, as outlined in Section 3.3.). 578 Proposals such as those in [DYN-CAST] suggest extensions to the IP 579 anycast scheme to enable the flexible routing of service requests to 580 one or more service instances. Common to those proposals is the use 581 of a semantic identifier, often a service identifier akin to a URL, 582 in the routing decision within the network. 584 5.5 Constraint-based Forwarding Decisions 586 Allocating the right resources to the right micro-services is a 587 fundamental task when executing micro-services across highly 588 distributed micro-data centres (e.g., resource management in cloud 589 [CLOUDFED]). This is particularly important in the light of volatile 590 resource availability as well as concurrent and highly dynamic 591 resource access. Once the specific set of micro-services for an 592 application has been identified, requirements (e.g., QoS) must be 593 ensured by the execution environment. Therefore, all micro-data 594 centres and the execution environment will need to realize mechanisms 595 for ensuring the utilization of specific resources within a pool of 596 resources for a specific set of micro-services belonging to one 597 application, while also ensuring integrity of the wider system. 599 In relation to the service routing capability discussed in the 600 previous sub-section, constraints may need to be introduced into the 601 forwarding decisions for service requests. Such constraints will 602 likely go beyond network load and latency, as often applied in 603 scenarios such as load balancing in CDNs. Instead, those constraints 604 are generally app/service-specific and will need a suitable 605 representation for the use within network nodes, i.e., the routers 606 that are forwarding service requests. Moreover, individual router 607 decisions (e.g., realized through matching operations such as 608 min/max/equal over a constraint representation) may be coordinated to 609 achieve a distribution of service requests among many service 610 instances, effectively realizing a service scheduling capability in 611 the network, optimized around service-specific constraints, not 612 unlike many existing data centre service switching schemes. 614 5.6 Collective Communication 616 Many micro-service scenarios may exhibit some form of collective 617 communication beyond 'just' unicast communication, therefore 618 requiring support for 1:M, M:1, and M:N communication. It is 619 important to consider here that such collective communication is 620 often extremely short-lived and can even take place at the level of a 621 single request, i.e., a following request may exhibit a different 622 communication pattern, even at least a different receiver group for 623 the same pattern, such as in the case of an interactive game. It is 624 therefore required that solutions for supporting such collective 625 communication must support the spontaneous formation of multicast 626 relations, as observed in those scenarios. 628 5.7 State Synchronization 630 Given the highly distributed nature of app-centric micro-services, 631 their state exchange and synchronization is a very crucial aspect for 632 ensuring in-application and system wide consistency. Mechanisms that 633 ensure consistency will ensure that data is synchronized with 634 different spatial, temporal and relational data within a given time 635 period. From the perspective of support through in-network compute 636 capabilities, such as provided through technologies like P4, it is 637 important to consider what system and protocol support is required to 638 utilize such in-network capabilities. 640 5.8 Dynamic Contracts 642 NOTE: left for future revision 644 6 Security Considerations 646 The use of semantic (or service) identifiers for routing decisions, 647 as mentioned in Section 5.4October 1, 2018April 4, 2019, requires 648 methods to ensure the privacy and security of the communication 649 through avoiding the exposure of service semantic (which is realized 650 at the application layer) to the network layer, therefore opening up 651 the opportunity for traffic inspection, among other things. The use 652 of cryptographic information, e.g., through self-certifying 653 identifiers, should be investigated to mitigate potential security 654 and privacy risks. 656 7 IANA Considerations 658 N/A 660 8 Conclusion 662 This draft positions the evolution of data centres as one of becoming 663 execution centres for the app-centric experiences provided today 664 mainly by smart phones directly. With the proliferation of data 665 centres closer to the end user in the form of edge-based micro data 666 centres, we believe that app-centric experiences will ultimately be 667 executed across those many, highly distributed execution points that 668 this increasingly rich edge environment will provide, such as smart 669 glasses and IoT devices. Although a number of activities are 670 currently underway to address some of the challenges for realizing 671 such AppCentre evolution, we believe that the proposed COIN research 672 group will provide a suitable forum to drive forward the remaining 673 research and its dissemination into working systems and the necessary 674 standardization of key aspects and protocols. 676 9 References 678 9.1 Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, DOI 682 10.17487/RFC2119, March 1997, . 685 [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function 686 Chaining (SFC) Architecture", RFC 7665, DOI 687 10.17487/RFC7665, October 2015, . 690 9.2 Informative References 692 [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, 693 M., Montesi, F., Mustafin, R., & Safina, L. (2017). 694 Microservices: yesterday,today, and tomorrow. In Present 695 and Ulterior Software Engineering (pp. 195-216). Springer, 696 Cham. 698 [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). 699 Microservices architecture enables devops: Migration to a 700 cloud-native architecture. IEEE Software, 33(3), 42-52. 702 [SRVLESS] C. Cicconetti, M. Conti and A. Passarella, "An 703 Architectural Framework for Serverless Edge Computing: 704 Design and Emulation Tools," 2018 IEEE International 705 Conference on Cloud Computing Technology and Science 706 (CloudCom), Nicosia, 2018, pp. 48-55. doi: 707 10.1109/CloudCom2018.2018.00024 709 [TOSCA] Topology and Orchestration Specification for Cloud 710 Applications Version 1.0. 25 November 2013. OASIS 711 Standard. . 714 [ERLANG] Armstrong, Joe, et al. "Concurrent programming in ERLANG." 715 (1993). 717 [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm, 718 "A Catalog of Stream Processing Optimizations", ACM 719 Computing Surveys,46(4):1-34, Mar. 2014 721 [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M. 722 (2013, June). Pattern-based deployment service for next 723 generation clouds. In 2013 IEEE Ninth World Congress on 724 Services (pp. 464-471). IEEE. 726 [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E. 727 (2011, May). Pattern-based composite application 728 deployment. In 12th IFIP/IEEE International Symposium on 729 Integrated Network Management (IM 2011) and Workshops (pp. 730 217-224). IEEE. 732 [RFC8677] Trossen, D., Purkayastha, D., Rahman, A., "Name-Based 733 Service Function Forwarder (nSFF) Component within a 734 Service Function Chaining (SFC) Framework", RFC 8677, 735 November 2019. 737 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., White, 738 G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 739 740 (work in progress), March 2019. 742 [ICN4G] Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R., 743 "Native Deployment of ICN in LTE, 4G Mobile Networks", 744 (work in progress), March 2019. 747 [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M. 748 Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud 749 resource management: Review and discussion", Elsevier 750 Journal of Network and Computer Applications, 2017. 752 [GRPC] High performance open source universal RPC framework, 753 https://grpc.io/ 755 [MPI] A. Vishnu, C. Siegel, J. Daily, "Distributed TensorFlow with 756 MPI", https://arxiv.org/pdf/1603.02339.pdf 758 [FCDN] M. Al-Naday, M. J. Reed, J. Riihijarvi, D. Trossen, N. Thomos, 759 M. Al-Khalidi, "fCDN: A Flexible and Efficient CDN 760 Infrastructure without DNS Redirection of Content 761 Reflection", https://arxiv.org/pdf/1803.00876.pdf 763 [DYN-CAST] Y. Li, J. He, L. Geng, P. Liu, Y. Cui, "Framework of 764 Compute First Networking (CFN)", 765 (work in progress), November 2019 768 [SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description, 769 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 770 LAN Services", 3GPP, 771 772 Authors' Addresses 774 Dirk Trossen 775 Huawei Technologies Duesseldorf GmbH 776 Riesstr. 25C 777 80992 Munich 778 Germany 780 Email: Dirk.Trossen@Huawei.com 782 Chathura Sarathchandra 783 InterDigital Europe, Ltd. 784 64 Great Eastern Street, 1st Floor 785 London EC2A 3QR 786 United Kingdom 788 Email: Chathura.Sarathchandra@InterDigital.com 790 Michael Boniface 791 University of Southampton 792 University Road 793 Southampton SO17 1BJ 794 United Kingdom 796 Email: mjb@it-innovation.soton.ac.uk