idnits 2.17.1 draft-sarathchandra-coin-appcentres-02.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 date (February 28, 2020) is 1513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COIN C. Sarathchandra 3 INTERNET-DRAFT InterDigital Inc. 4 Intended Status: Informational D. Trossen 5 Expires: August 28, 2020 Huawei 6 M. Boniface 7 University of Southampton 8 February 28, 2020 10 In-Network Computing for App-Centric Micro-Services 11 draft-sarathchandra-coin-appcentres-02 13 Abstract 15 The application-centric deployment of 'Internet' services has 16 increased over the past ten years with many million 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 of 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 Collaborative Gaming . . . . . . . . . . . . . . . . . . . 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 3.6. Requirements Derived from Use Cases . . . . . . . . . . . . 9 78 4 Enabling Technologies . . . . . . . . . . . . . . . . . . . . . 10 79 4.1 Application Packaging . . . . . . . . . . . . . . . . . . . 10 80 4.2 Service Deployment . . . . . . . . . . . . . . . . . . . . 11 81 4.3. Compute Inter-Connection . . . . . . . . . . . . . . . . . 12 82 4.4. Dynamic Contracts . . . . . . . . . . . . . . . . . . . . . 12 83 4.5 Service Routing . . . . . . . . . . . . . . . . . . . . . . 12 84 4.6 Service Pinning . . . . . . . . . . . . . . . . . . . . . . 13 85 4.7. Opportunistic Multicast . . . . . . . . . . . . . . . . . . 13 86 4.8 State Synchronization . . . . . . . . . . . . . . . . . . . 13 87 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 88 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 89 7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.1 Normative References . . . . . . . . . . . . . . . . . . . 14 92 8.2 Informative References . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 where 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, if any of the three functions are terminated on the device, 179 the execution of the rest of the functions may be moved to other 180 (e.g., more suitable) devices which have exposed the corresponding 181 micro-services to the environment. The result of the latter is 182 flexible mobile function offloading, for possible reduction of power 183 consumption (e.g., offloading CPU intensive process functions to a 184 remote server) or for improved end user experience (e.g., moving 185 display functions to a nearby smart TV). 187 The above scenario can be exemplified in an immersive gaming 188 application, where a single user plays a game using a VR headset. The 189 headset hosts functions that "display" frames to the user, as well as 190 the functions for VR content processing and frame rendering combining 191 with input data received from sensors in the VR headset. Once this 192 application is partitioned into micro-services and deployed in an 193 app-centric execution environment, only the "display" micro-service 194 is left in the headset, while the compute intensive real-time VR 195 content processing micro-services can be offloaded to a nearby 196 resource rich home PC, for a better execution (faster and possibly 197 higher resolution generation). 199 Figure 1 shows one realization of the above scenario, where a 'DPR 200 app' running on a mobile device (containing the partitioned 201 Display(D), Process(P) and Receive(R) micro services) over an SDN 202 network. The packaged applications are made available through a 203 localized 'playstore server'. The application installation is 204 realized as a 'service deployment' process (Section 4.2.), combining 205 the local app installation with a distributed micro-service 206 deployment (and orchestration) on most suitable AppCentreS 207 ('processing server'). 209 +----------+ 210 Mobile |Processing| 211 +---------+ | Server | 212 | App | +----------+ 213 | +-----+ | | 214 | |D|P|R| | +--+ 215 | +-----+ | |SR| Internet 216 | +-----+ | +--+ / 217 | | SR | | | / 218 | +-----+ | +----------+ +------+ 219 +---------+ /|SDN Switch|_____|Border| 220 \ +-------+ / +----------+ | SR | 221 \| 5GAN |/ | +------+ 222 +-------+ | 223 | 224 +----------+ 225 +---------+ /|SDN Switch| 226 | +-----+ | +-------+ / +----------+ 227 | | SR | | /|WIFI AP|/ \ 228 | +-----+ | / +-------+ +--+ 229 |+-------+|/ |SR| 230 ||Display|| /+--+ 231 || || +---------+ 232 |+-------+| |Playstore| 233 +---------+ | Server | 234 TV +---------+ 236 Figure 1: Application Function Offloading Example 238 Such localized deployment could, for instance, be provided by a 239 visiting site, such as a hotel or a theme park. Once the 'processing' 240 micro-service is terminated on the mobile device, the 'service 241 routing' (SR) elements in the network (Section 4.3.) route requests 242 to the previously deployed 'processing' micro-service running on the 243 'processing server' AppCentre over an existing SDN network. 245 3.2 Collaborative Gaming 247 There has been a recent shift from applications that provide single- 248 user experiences, such as the ones described in the previous section 249 to collaborative/cooperative experiences such as multi-user gaming 250 and mixed/virtual reality. The latter leads to increasing amounts of 251 interaction where input (e.g., gesture, gaze, touch, movement) and 252 output (e.g., visual display, sound, and actuation) needs to be 253 processed within strict timing constraints and synchronized to ensure 254 temporal and spatial consistency with local and distant users. App- 255 centric design allows functions with high data and process coupling 256 to be modularized, deployed and executed, such that the subset of 257 micro-services is cooperatively executed towards optimizing multi- 258 user experiences. 260 The same example in previous section can be envisaged from a multi- 261 player gaming scenario. Here the micro-services that need to be 262 executed cooperatively are executed in a localized and synchronized 263 manner for player coordination and synchronizing interaction and 264 state between collaborating players. 266 3.3. Distributed AI 268 There is a growing range of use cases demanding for the realization 269 of AI capabilities among distributed endpoints. Such demand may be 270 driven by the need to increase overall computational power for large- 271 scale problems. Other solutions may desire the localization of 272 reasoning logic, e.g., for deriving attributes that better preserve 273 privacy of the utilized raw input data. Examples for large-scale AI 274 problems include biotechnology and astronomy related reasoning over 275 massive amounts of observational input data. Examples for localizing 276 input data for privacy reasons include radar-like application for the 277 development of topological mapping data based on (distributed) radio 278 measurements at base stations (and possibly end devices), while the 279 processing within radio access networks (RAN) already constitute a 280 distributed AI problem to a certain extent albeit with little 281 flexibility in distributing the execution of the AI logic. 283 Reasoning frameworks, such as TensorFlow, may be utilized for the 284 realization of the (distributed) AI logic, building on remote service 285 invocation through protocols such as gRPC [GRPC] or MPI [MPI] with 286 the intention of providing an on-chip NPU (neural processor unit) 287 like abstraction to the AI framework. 289 3.4. Content Delivery Networks 291 Delivery of content to end user often relies on Content Delivery 292 Networks (CDNs) storing said content closer to end users for latency 293 reduced delivery with DNS-based indirection being utilized to serve 294 the request on behalf of the origin server. From the perspective of 295 this draft, a CDN can be interpreted as a (network service level) 296 application with distributed logic for distributing content from 297 origin server to CDN ingress and further to the CDN replication 298 points which ultimately serve the user-facing content requests. 299 Studies such as those in [FCDN] have shown that content distribution 300 at the level of named content, utilizing efficiency Layer 2 multicast 301 for replication towards edge CDN nodes, can significantly increase 302 the overall network and server efficiency, while reducing indirection 303 latency for content retrieval but also reducing required edge storage 304 capacity by benefiting from the increased network efficiency to renew 305 edge content more quickly against changing demand. 307 3.5. Compute-Fabric-as-a-Service (CFaaS) 309 App-centric execution environments, consisting of Layer 2 connected 310 appcentres in the sense outlined in this draft, provide the 311 opportunity for infrastructure providers to offer CFaaS type of 312 offerings to application providers for them to utilize the compute 313 fabric exposed by this CFaaS offering for the purposes defined 314 through their applications. In other words, the compute resources can 315 be utilized to execute the desired micro-services of which the 316 application is composed, while utilizing the inter-connection between 317 those compute resources to do so in a distributed manner. We foresee 318 those CFaaS offerings to be tenant-specific, a tenant here defined as 319 the provider of at least one application. For this, we foresee an 320 interaction between CFaaS provider and tenant to dynamically select 321 the appropriate resources to define the demand side of the fabric. 322 Conversely, we also foresee the supply side of the fabric to be 323 highly dynamic with resources being offered to the fabric through, 324 e.g., user-provided resources (whose supply might depend on highly 325 context-specific supply policies) or infrastructure resources of 326 intermittent availability such as those provided through road-side 327 infrastructure in vehicular scenarios. The resulting dynamic demand- 328 supply matching establishes a dynamic nature of the compute fabric 329 that in turn requires trust relationships to be built dynamically 330 between the resource provider(s) and the CFaaS provider. This also 331 requires the communication resources to be dynamically adjusted to 332 interconnect all resources suitably into the (tenant-specific) fabric 333 exposed as CFaaS. 335 3.6. Requirements Derived from Use Cases 337 The following requirements are derived from the presented use cases 338 in Section 3.1. to 3.5., numbered according to the section numbers 339 although those requirements apply in some cases across more than one 340 of the presented use cases. 342 Req 1.1: Any app-centric execution environment MUST provide means for 343 routing of service requests between resources in the distributed 344 environment. 346 Req 1.2: Any app-centric execution environment MUST provide means for 347 dynamically choosing the best possible micro-service sequence (i.e., 348 chaining of micro-services) for a given application experience. 350 Req 1.3: Any app-centric execution environment MUST provide means for 351 pinning the execution of a specific micro-service to a specific 352 resource instance in the distributed environment. 354 Req 1.4: Any app-centric execution environment SHOULD provide means 355 for packaging micro-services for deployments in distributed networked 356 computing environments, including any constraints regarding the 357 deployment of service instances in specific network locations or 358 compute resources. Such packaging SHOULD conform to existing 359 application deployment models, such as mobile application packaging, 360 TOSCA orchestration templates or tar balls or combinations thereof. 362 Req 2.1: Any app-centric execution environment MUST provide means for 363 real-time synchronization and consistency of distributed application 364 states. 366 Req 3.1: Any app-centric execution environment MUST provide means to 367 specify the constraints for placing (AI) execution logic in certain 368 logical execution points (and their associated physical locations). 370 Req 3.2: Any app-centric execution environment MUST provide support 371 for app/micro-service specific invocation protocols. 373 Req 4.1: Any app-centric execution environment SHOULD utilize Layer 2 374 multicast transmission capabilities for responses to concurrent 375 service requests. 377 Req 5.1: Any app-specific execution environment SHOULD expose means 378 to specify the requirements for the tenant-specific compute fabric 379 being utilized for the app execution. 381 Req 5.2: Any app-specific execution environment SHOULD allow for 382 dynamic integration of compute resources into the compute fabric 383 being utilized for the app execution; those resources include, but 384 are not limited to, end user provided resources. 386 Req 5.3: Any app-specific execution environment MUST provide means to 387 optimize the inter-connection of compute resources, including those 388 dynamically added and removed during the provisioning of the tenant- 389 specific compute fabric. 391 Req 5.4: Any app-specific execution environment MUST provide means 392 for ensuring availability and usage of resources is accounted for. 394 4 Enabling Technologies 396 EDITOR NOTE: Section 4 will be updated and extended in the next 397 version of the draft, including the addressing of specific 398 requirements listed in Section 3.6. 400 4.1 Application Packaging 402 Applications often consist of one or more sub-elements (e.g., audio, 403 visual, hepatic elements) which are 'packaged' together, resulting in 404 the final installable software artifact. Conventionally, application 405 developers perform the packaging process at design time, by packaging 406 a set of software components as a (often single) monolithic software 407 package, for satisfying a set of predefined application 408 requirements. 410 Decomposing micro-services of an application, and then executing them 411 on peer execution points in AppCentreS (e.g., on an app-centric 412 serverless runtime [SRVLESS]) can be done with design-time planning. 413 Micro-service decomposition process involves, defining clear 414 boundaries of the micro-service (e.g., using wrapper classes for 415 handling input/output requests), which could be done by the 416 application developer at design-time (e.g., through Android app 417 packaging by including, as part of the asset directory, a service 418 orchestration template [TOSCA] that describes the decomposed micro- 419 services). Likewise, the peer execution points could be 'known' to 420 the application (e.g., using well-known and fixed peer execution 421 points on AppCentreS) and incorporated with the micro-services by the 422 developer at design-time. 424 Existing programming frameworks address decomposition and execution 425 of applications centering around other aspects such as concurrency 426 [ERLANG]. For decomposing at runtime, application elements can be 427 profiled using various techniques such as dynamic program analysis or 428 dwarf application benchmarks. The local profiler information can be 429 combined with the profiler information of other devices in the 430 network for improved accuracy. The output of such a profiler process 431 can then be used to identify smaller constituting sub-components of 432 the application in forms of pico-services, their interdependencies 433 and data flow (e.g., using caller/callee information, instruction 434 usage). Due to the complex nature of resulting application structure 435 and therefore its increased overhead, in most cases, it may not be 436 optimal to decompose applications at the pico level. Therefore, one 437 may cluster pico-services into micro-services with common 438 characteristics, enabling a meaningful (e.g., clustering pico- 439 services with same resource dependency) and a performant 440 decomposition of applications. Characteristics of micro-services can 441 be defined as a set of concepts using an ontology language, which can 442 then be used for clustering similar pico-services into micro- 443 services. Micro-services may then be partitioned along their 444 identified borders. Moreover, mechanisms for governance, discovery 445 and offloading can be employed for 'unknown' peer execution points on 446 AppCentreS with distributed loci of control. 448 Therefore, with this app-centric model, application packaging can be 449 done at runtime by constructing micro-service chains for satisfying 450 requirements of experiences (e.g., interaction requirements), under 451 varying constraints (e.g., temporal consistency between multiple 452 players within a shared AR/VR world)[SCOMPOSE]. Such packaging 453 includes mechanisms for selecting the best possible micro-services 454 for a given experience at runtime in the multi-X environment. These 455 run-time packaging operations may continuously discover the 'unknown' 456 and adapt towards an optimal experience. Such decision mechanisms 457 handle the variability, volatility and scarcity within this multi-X 458 framework. 460 4.2 Service Deployment 462 The service function chains, constituting each individual 463 application, will need deployment mechanisms in a true multi-X 464 (multi-user, multi-infrastructure, multi-domain) environment 465 [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and 466 orchestration processes are married into one, as a set of procedures 467 governed by device owners directly or with delegated authority. 468 However, apart from extending towards multi-X environments, the 469 process also needs to cater for changes in the environment, caused, 470 e.g., by movement of users, new pervasive sensors/actuators, and 471 changes to available infrastructure resources. Methods to deploy 472 service functions as executable code into chosen service execution 473 points, supporting the various endpoint realizations (e.g., device 474 stacks, COTS stacks, etc.), and service function endpoint realization 475 through utilizing existing and emerging virtualization techniques. 477 A combination of application installation procedure and orchestrated 478 service deployment can be achieved by utilizing the application 479 packaging with integrated service deployment templates described in 480 Section 4.1 such that the application installation procedure on the 481 installing device is being extended to not only install the local 482 application package but also extract the service deployment template 483 for orchestrating with the localized infrastructure, using, for 484 instance, REST APIs for submitting the template to the orchestrator. 486 4.3. Compute Inter-Connection 488 NOTE: left for future revision 490 4.4. Dynamic Contracts 492 NOTE: left for future revision 494 4.5 Service Routing 496 Service routing within a combined compute and network infrastructure 497 that will enable true end-to-end experiences across distributed 498 application execution points provisioned on distant cloud, edge and 499 device-centric resources (e.g., using ICN/name-based routing 500 methods), is a key aspect of app-centric micro-service execution. 501 Once the micro-services are packaged and deployed in such highly 502 distributed micro-data centres, the routing mechanisms will ensure 503 efficient information exchange (e.g., for satisfying application 504 requirements) between corresponding micro-services within the multi-X 505 execution environment. 507 Routing becomes a problem of routing the micro-service requests, not 508 just packets, as done through IP. Traditionally, the combination of 509 the Domain Naming Service (DNS) and IP routing has been used for this 510 purpose. However, the advent of virtualization with use cases such as 511 those outlined above have made it challenging to further rely on the 512 DNS. This is mainly down to the long delay in updating DNS entries to 513 'point' to the right micro-service instances. If one was to use the 514 DNS, one would be updating the DNS entries at a high rate, caused by 515 the diversity of trigger, e.g., through movement. DNS has not been 516 designed for such frequent update, rendering it useless for such 517 highly dynamic applications. With many edge scenarios in the VR/AR 518 space demanding interactivity and being latency-sensitive, efficient 519 routing will be key to any solution. 521 Various ongoing work on service request forwarding [nSFF] with the 522 service function chaining [RFC7665] framework as well as name-based 523 routing [ICN5G][ICN4G] addressing some aspects described above albeit 524 with a focus on HTTP as the main invocation protocol. Extensions will 525 be required to support other invocation protocols, such as GRPC or 526 MPI (for distributed AI use cases, as outlined in Section 3.3.). 528 4.6 Service Pinning 530 Allocating the right resources to the right micro-services is a 531 fundamental task when executing micro-services on such highly 532 distributed app-centric micro-data centres (e.g., resource management 533 in cloud [CLOUDFED]), particularly in the light of volatile resource 534 availability as well as concurrent and highly dynamic resource 535 access. Once the specific set of micro-services of an application has 536 been identified, during the lifetime of the application, requirements 537 (e.g., QoS) must be ensured by the execution environment. Therefore, 538 all micro-data centres and the execution environment will realize 539 mechanisms for ensuring the utilization of specific resources within 540 a pool of resources (i.e., resources in all app-centric micro-data 541 centres), for a specific set of micro-services belonging to one 542 application, while also ensuring integrity in the wider system. 544 4.7. Opportunistic Multicast 546 NOTE: left for future revision 548 4.8 State Synchronization 550 Given the highly distributed nature of app-centric micro-services, 551 their state exchange and synchronization is a very crucial aspect for 552 ensuring in-application and system wide consistency. Mechanisms that 553 ensure consistency will ensure that data is synchronized with 554 different spatial, temporal and relational data within a given time 555 period. 557 5 Security Considerations 559 N/A 561 6 IANA Considerations 563 N/A 565 7 Conclusion 567 This draft positions the evolution of data centres as one of becoming 568 execution centres for the app-centric experiences provided today 569 mainly by smart phones directly. With the proliferation of data 570 centres closer to the end user in the form of edge-based micro data 571 centres, we believe that app-centric experiences will ultimately be 572 executed across those many, highly distributed execution points that 573 this increasingly rich edge environment will provide, such as smart 574 glasses and IoT devices. Although a number of activities are 575 currently underway to address some of the challenges for realizing 576 such AppCentre evolution, we believe that the proposed COIN research 577 group will provide a suitable forum to drive forward the remaining 578 research and its dissemination into working systems and the necessary 579 standardization of key aspects and protocols. 581 8 References 583 8.1 Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, DOI 587 10.17487/RFC2119, March 1997, . 590 [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function 591 Chaining (SFC) Architecture", RFC 7665, DOI 592 10.17487/RFC7665, October 2015, . 595 8.2 Informative References 597 [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, 598 M., Montesi, F., Mustafin, R., & Safina, L. (2017). 599 Microservices: yesterday,today, and tomorrow. In Present 600 and Ulterior Software Engineering (pp. 195-216). Springer, 601 Cham. 603 [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). 604 Microservices architecture enables devops: Migration to a 605 cloud-native architecture. IEEE Software, 33(3), 42-52. 607 [SRVLESS] C. Cicconetti, M. Conti and A. Passarella, "An 608 Architectural Framework for Serverless Edge Computing: 609 Design and Emulation Tools," 2018 IEEE International 610 Conference on Cloud Computing Technology and Science 611 (CloudCom), Nicosia, 2018, pp. 48-55. doi: 612 10.1109/CloudCom2018.2018.00024 614 [TOSCA] Topology and Orchestration Specification for Cloud 615 Applications Version 1.0. 25 November 2013. OASIS 616 Standard. . 619 [ERLANG] Armstrong, Joe, et al. "Concurrent programming in ERLANG." 620 (1993). 622 [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm, 623 "A Catalog of Stream Processing Optimizations", ACM 624 Computing Surveys,46(4):1-34, Mar. 2014 626 [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M. 627 (2013, June). Pattern-based deployment service for next 628 generation clouds. In 2013 IEEE Ninth World Congress on 629 Services (pp. 464-471). IEEE. 631 [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E. 632 (2011, May). Pattern-based composite application 633 deployment. In 12th IFIP/IEEE International Symposium on 634 Integrated Network Management (IM 2011) and Workshops (pp. 635 217-224). IEEE. 637 [nSFF] Trossen, D., Purkayastha, D., Rahman, A., "Name-Based 638 Service Function Forwarder (nSFF) component within SFC 639 framework", (work in progress), April 641 2019. 643 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., White, 644 G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 645 646 (work in progress), March 2019. 648 [ICN4G] Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R., 649 "Native Deployment of ICN in LTE, 4G Mobile Networks", 650 (work in progress), March 2019. 653 [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M. 654 Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud 655 resource management: Review and discussion", Elsevier 656 Journal of Network and Computer Applications, 2017. 658 [GRPC] High performance open source universal RPC framework, 659 https://grpc.io/ 661 [MPI] A. Vishnu, C. Siegel, J. Daily, "Distributed TensorFlow with 662 MPI", https://arxiv.org/pdf/1603.02339.pdf 664 [FCDN] M. Al-Naday, M. J. Reed, J. Riihijarvi, D. Trossen, N. Thomos, 665 M. Al-Khalidi, "fCDN: A Flexible and Efficient CDN 666 Infrastructure without DNS Redirection of Content 667 Reflection", https://arxiv.org/pdf/1803.00876.pdf 669 Authors' Addresses 670 Chathura Sarathchandra 671 InterDigital Europe, Ltd. 672 64 Great Eastern Street, 1st Floor 673 London EC2A 3QR 674 United Kingdom 676 Email: Chathura.Sarathchandra@InterDigital.com 678 Dirk Trossen 679 Huawei Technologies Duesseldorf GmbH 680 Riesstr. 25C 681 80992 Munich 682 Germany 684 Email: Dirk.Trossen@Huawei.com 686 Michael Boniface 687 University of Southampton 688 University Road 689 Southampton SO17 1BJ 690 United Kingdom 692 Email: mjb@it-innovation.soton.ac.uk