idnits 2.17.1 draft-sarathchandra-coin-appcentres-04.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 (January 26, 2021) is 1178 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'GRPC' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'FCDN' is defined on line 661, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: July 26, 2021 InterDigital Inc. 6 M. Boniface 7 University of Southampton 8 January 26, 2021 10 In-Network Computing for App-Centric Micro-Services 11 draft-sarathchandra-coin-appcentres-04 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. 29 We outline the key enabling technologies that needs to be provided 30 for such evolution to be realized, including references to ongoing 31 standardization efforts in key areas. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5 Enabling Technologies . . . . . . . . . . . . . . . . . . . . 5 75 5.1 Application Packaging . . . . . . . . . . . . . . . . . . . 5 76 5.2 Service Deployment . . . . . . . . . . . . . . . . . . . . 7 77 5.3 Compute Inter-Connection at Layer 2 . . . . . . . . . . . . 7 78 5.4 Service Routing . . . . . . . . . . . . . . . . . . . . . . 8 79 5.5 Constraint-based Forwarding Decisions . . . . . . . . . . . 9 80 5.6 Collective Communication . . . . . . . . . . . . . . . . . 10 81 5.7 State Synchronization . . . . . . . . . . . . . . . . . . . 11 82 5.8 Dynamic Contracts . . . . . . . . . . . . . . . . . . . . . 11 83 6 Overview of Relevant Standardization Efforts . . . . . . . . . 11 84 7 Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 89 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1 Introduction 94 With the increasing dominance of smartphones and application markets, 95 the end-user experiences today have been increasingly centered around 96 the applications and the ecosystems that smartphone platforms create. 97 The experience of the 'Internet' has changed from 'accessing a web 98 site through a web browser' to 'installing and running an application 99 on a smartphone'. This app-centric model has changed the way services 100 are being delivered not only for end-users, but also for business-to- 101 consumer (B2C) and business-to-business (B2B) relationships. 103 Designing and engineering applications is largely done statically at 104 design time, such that achieving significant performance improvements 105 thereafter has become a challenge (especially, at runtime in response 106 to changing demands and resources). Applications today come 107 prepackaged putting them at disadvantage for improving efficiency due 108 to the monolithic nature of the application packaging. Decomposing 109 application functions into micro-services [MSERVICE1] [MSERVICE2] 110 allows applications to be packaged dynamically at run-time taking 111 varying application requirements and constraints into consideration. 112 Interpreting an application as a chain of micro-services, allows the 113 application structure, functionality, and performance to be adapted 114 dynamically at runtime in consideration of tradeoffs between quality 115 of experience, quality of service and cost. 117 Interpreting any resource rich networked computing (and storage) 118 capability not just as a pico or micro-data centre, but as an 119 application-centric execution data centre (AppCentre), allows 120 distributed execution of micro-services. Here, the notion of an 121 'application' constitutes a set of objectives being realized in a 122 combined packaging of micro-services under the governance of the 123 'application provider'. These micro-services may then be deployed on 124 the most appropriate AppCentre (edge/fog/cloud resources) to satisfy 125 requirements under varying constraints. In addition, the high degree 126 of distribution of application and data partitions, and compute 127 resources offered by the execution environment decentralizes control 128 between multiple cooperating parties (multi-technology, multi-domain, 129 multi-ownership environments). Furthermore, compute resource 130 availability may be volatile, particularly when moving along the 131 spectrum from well-connected cloud resources over edge data centres 132 to user-provided compute resources, such as (mobile) terminals or 133 home-based resources such as NAS and IoT devices. 135 We believe that the emergence of AppCentreS will democratize 136 infrastructure and service provision to anyone with compute resources 137 with the notion of applications providing an element of governing the 138 execution of micro-services. This increased distribution will lead to 139 new forms of application interactions and user experiences based on 140 cooperative AppCentreS (pico-micro and large cloud data centres), in 141 which applications are being designed, dynamically composed and 142 executed. 144 2 Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 3 Use Cases 152 Although our motivation for the 'AppCentre' term stems from the 153 (mobile) application ecosystem, we foresee use cases that are not 154 limited to mobile applications only. Instead, we interpret 155 'applications' as a governing concept of executing a set of micro- 156 services where the 'application provider' can reach from those 157 realizing mobile applications over novel network applications to 158 emerging infrastructure offerings serving a wide range of 159 applications in a purpose- (and therefore application-)agnostic 160 manner. 162 Originally being described in more detail in this draft, use cases 163 are now gathered and described in more detail in [COIN-usecases], 164 following a common taxonomy for their description. Specifically, the 165 use cases for immersive devices and infrastructure services have 166 guided the following requirements and technology selection, although 167 this draft also applies to a number of industrial use cases as well. 168 For more detail on those use cases overall, we refer the reader to 169 [COIN-usecases]. 171 4 Requirements 173 The following requirements are derived from the use cases in Section 174 5 and 6 in [COIN-usecases], serving as a guidance for the following 175 discussions on enabling technologies in Section 5 of this document. 177 Req 1 - Service Routing: Any app-centric execution environment MUST 178 provide means for routing of service requests between 179 resources in the distributed environment. 181 Req 2 - Constraint-based Forwarding Decisions: Any app-centric 182 execution environment MUST provide means for dynamically 183 choosing the best possible micro-service sequence (i.e., 184 chaining of micro-services) for a given application 185 experience. Means for discovering suitable micro-service 186 SHOULD be provided. 188 Req 3 - Flow Affinity: Any app-centric execution environment MUST 189 provide means for pinning the excution of a specific micro- 190 service to a specific resource instance in the distributed 191 environment. 193 Req 4 - Deployment: Any app-centric execution environment SHOULD 194 provide means for packaging micro-services for deployments in 195 distributed networked computing environments. The packaging 196 SHOULD include any constraints regarding the deployment of 197 service instances in specific network locations or compute 198 resources. Such packaging SHOULD conform to existing 199 application deployment models, such as mobile application 200 packaging, TOSCA orchestration templates or tar balls or 201 combinations thereof. 203 Req 5 - Synchronization: Any app-centric execution environment MUST 204 provide means for real-time synchronization and consistency of 205 distributed application states. 207 Req 6 - Generic Invocation: Any app-centric execution environment 208 MUST provide support for app/micro-service specific invocation 209 protocols. 211 Req 7 - Collective Communication: Any app-centric execution 212 environment SHOULD utilize Layer 2 multicast transmission 213 capabilities for responses to concurrent service requests. 215 Req 8 - Orchestration: Any app-specific execution environment SHOULD 216 expose means to specify the requirements for the tenant- 217 specific compute fabric being utilized for the app execution. 218 Any app-specific execution environment SHOULD allow for 219 dynamic integration of compute resources into the compute 220 fabric being utilized for the app execution; those resources 221 include, but are not limited to, end user provided resources. 222 Any app-specific execution environment MUST provide means to 223 optimize the inter-connection of compute resources, including 224 those dynamically added and removed during the provisioning of 225 the tenant-specific compute fabric. Any app-specific execution 226 environment MUST provide means for ensuring availability and 227 usage of resources is accounted for. 229 5 Enabling Technologies 231 We now discuss a number of enabling technologies that address the 232 requirements set out in Section 4. 234 5.1 Application Packaging 235 Applications often consist of one or more sub-elements (e.g., audio, 236 visual, hepatic elements) which are 'packaged' together, resulting in 237 the final installable software artifact. Conventionally, application 238 developers perform the packaging process at design time, by packaging 239 a set of software components as a (often single) monolithic software 240 package, for satisfying a set of predefined application 241 requirements. 243 Decomposing micro-services of an application, and then executing them 244 on peer execution points in AppCentreS (e.g., on an app-centric 245 serverless runtime [SRVLESS]) can be done with design-time planning. 246 Micro-service decomposition process involves, defining clear 247 boundaries of the micro-service (e.g., using wrapper classes for 248 handling input/output requests), which could be done by the 249 application developer at design-time (e.g., through Android app 250 packaging by including, as part of the asset directory, a service 251 orchestration template [TOSCA] that describes the decomposed micro- 252 services). Likewise, the peer execution points could be 'known' to 253 the application (e.g., using well-known and fixed peer execution 254 points on AppCentreS) and incorporated with the micro-services by the 255 developer at design-time. 257 Existing programming frameworks address decomposition and execution 258 of applications centering around other aspects such as concurrency 259 [ERLANG]. For decomposing at runtime, application elements can be 260 profiled using various techniques such as dynamic program analysis or 261 dwarf application benchmarks. The local profiler information can be 262 combined with the profiler information of other devices in the 263 network for improved accuracy. The output of such a profiler process 264 can then be used to identify smaller constituting sub-components of 265 the application in forms of pico-services, their interdependencies 266 and data flow (e.g., using caller/callee information, instruction 267 usage). Due to the complex nature of resulting application structure 268 and therefore its increased overhead, in most cases, it may not be 269 optimal to decompose applications at the pico level. Therefore, one 270 may cluster pico-services into micro-services with common 271 characteristics, enabling a meaningful (e.g., clustering pico- 272 services with same resource dependency) and a performant 273 decomposition of applications. Characteristics of micro-services can 274 be defined as a set of concepts using an ontology language, which can 275 then be used for clustering similar pico-services into micro- 276 services. Micro-services may then be partitioned along their 277 identified borders. Moreover, mechanisms for governance, discovery 278 and offloading can be employed for 'unknown' peer execution points on 279 AppCentreS with distributed loci of control. 281 Therefore, with this app-centric model, application packaging can be 282 done at runtime by constructing micro-service chains for satisfying 283 requirements of experiences (e.g., interaction requirements), under 284 varying constraints (e.g., temporal consistency between multiple 285 players within a shared AR/VR world)[SCOMPOSE]. Such packaging 286 includes mechanisms for selecting the best possible micro-services 287 for a given experience at runtime in the multi-technology 288 environment. These run-time packaging operations may continuously 289 discover the 'unknown' and adapt towards an optimal experience. Such 290 decision mechanisms handle the variability, volatility and scarcity 291 within this multi-X framework. 293 5.2 Service Deployment 295 The service function chains, constituting each individual 296 application, will need deployment mechanisms in a true multi-X 297 (multi-user, multi-infrastructure, multi-domain) environment 298 [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and 299 orchestration processes are married into one, as a set of procedures 300 governed by device owners directly or with delegated authority. 301 However, apart from extending towards multi-X environments, the 302 process also needs to cater for changes in the environment, caused, 303 e.g., by movement of users, new pervasive sensors/actuators, and 304 changes to available infrastructure resources. Methods are needed to 305 deploy service functions as executable code into chosen service 306 execution points. Those methods need to support the various endpoint 307 (e.g., device stacks, COTS stacks, etc.) and service function 308 realizations, e.g., through utilizing existing and emerging 309 virtualization techniques. 311 A combination of application installation procedure and orchestrated 312 service deployment can be achieved by utilizing the application 313 packaging with integrated service deployment templates described in 314 Section 5.1 such that the application installation procedure on the 315 installing device is being extended to not only install the local 316 application package but also extract the service deployment template 317 for orchestrating with the localized infrastructure, using, for 318 instance, REST APIs for submitting the template to the orchestrator. 320 The concept of 'intent-based networking' [IB_CONC] has been the focus 321 of studies in the Network Management RG, allowing for declaratively 322 stating the goals that a network shall meet. In relation to service 323 deployment, intent-based concepts may be useful for the placement of 324 service endpoints in a distributed environment under given service- 325 specific constraints, e.g., on HW constraints for the execution of 326 service endpoints or similar. This could also link into conveying 327 service-specific constraints for the forwarding of information, as 328 discussed in the following Section 5.5. 330 5.3 Compute Inter-Connection at Layer 2 331 While Layer2 switching technologies have long proliferated in data 332 centre deployments, recent developments have advanced the 333 capabilities for interconnecting distributed computing resources over 334 Layer2 technologies. For instance, the efforts in 3GPP on so-called 335 '5G LAN' (or Vertical LAN) [SA2-5GLAN] allow for establishing a 336 Layer2 bearer between participating compute entities, using a 337 vertical-specific LAN identifier for packet forwarding between the 338 distributed Layer2 entities. Combined with Layer2 technology in data 339 centres as well as office and home networks alike, this enables the 340 deployment of services in vertical (Layer2) networks, interconnecting 341 with other Internet-based services through dedicated service 342 gateways. 344 Real deployments and realizations will have to show the scalability 345 of this approach but it points into a direction where application or 346 service-specific deployments could potentially 'live' entirely in 347 their own vertical network, interconnecting only based on need (which 348 for many services may not exist). From the application's or service's 349 perspective, the available compute resource pool will look no 350 different from that being realized in a single data centre albeit 351 with the possibility to being highly distributed now among many 352 (e.g., edge) data centres as well as mobile devices. 354 In such a deployment, it is interesting to study the realization of 355 suitable service routing capabilities, leading us to the next 356 technology area of interest. 358 5.4 Service Routing 360 Routing service requests is a key aspect within a combined compute 361 and network infrastructure in order to enable true end-to-end 362 experiences across distributed application execution points 363 provisioned on distant cloud, edge and device-centric resources. Once 364 the micro-services are packaged and deployed in such highly 365 distributed micro-data centres, the routing mechanisms must ensure 366 efficient information exchange between corresponding micro-services, 367 e.g., at the level of service requests, within the multi-technology 368 execution environment. 370 Routing here becomes a problem of routing micro-service requests, not 371 just packets, as done through IP. This calls for some form of 'flow 372 affinity' that allows for treating several packets as part of a 373 request semantic. This is important, e.g., for mobility (avoiding to 374 send some packets of a larger request to one entity, while other 375 packets are sent to another one, therefore creating incomplete 376 information at both entities as a result). Also, when applying 377 constraints to the forwarding of packets (discussed in more detail in 378 Section 5.6), it is important to apply the actions across the packets 379 of the request rather than individually. 381 Another key aspect is that of addressing services. Traditionally, the 382 combination of the Domain Naming Service (DNS) and IP routing has 383 been used for this purpose. However, the advent of virtualization 384 with use cases such as those outlined in Section 3 (such as those on 385 app-specific micro-services on mobile devices) have made it 386 challenging to further rely on the DNS. Apart from the initial delay 387 observed when resolving a service name into a locator for the first 388 time, the long delay in updating DNS entries to 'point' to the right 389 micro-service instances prohibits offloading to dynamically created 390 service instances. If one was to use the DNS, one would be updating 391 the DNS entries at a high rate, caused by the diversity of trigger, 392 e.g., through movement. DNS has not been designed for such frequent 393 update, rendering it useless for such highly dynamic applications. 394 With many edge scenarios in the VR/AR space demanding interactivity 395 and being latency-sensitive, efficient routing will be key to any 396 solution. 398 Various ongoing work on service request forwarding [RFC8677] with the 399 service function chaining [RFC7665] framework as well as name-based 400 routing [ICN5G][ICN4G][ICNIP] addresses some aspects described above 401 albeit with a focus on HTTP as the main invocation protocol. 402 Extensions will be required to support other invocation protocols, 403 such as GRPC or MPI (for distributed AI use cases). Proposals such as 404 those in [DYN-CAST] suggest extensions to the IP anycast scheme to 405 enable the flexible routing of service requests to one or more 406 service instances. Common to those proposals is the use of a semantic 407 identifier, often a service identifier akin to a URL, in the routing 408 decision within the network. 410 Efforts existed in the IRTF, in the form of the Routing RG [RRG], to 411 specifically study aspects of routing. The RRG concluded its work in 412 2014, but its possible revival has been suggested in ongoing 413 discussions on routing evolution [FIPE] as a forum to study semantic- 414 rich routing approaches. 416 5.5 Constraint-based Forwarding Decisions 418 Allocating the right resources to the right micro-services is a 419 fundamental task when executing micro-services across highly 420 distributed micro-data centres (e.g., resource management in cloud 421 [CLOUDFED]). This is particularly important in the light of volatile 422 resource availability as well as concurrent and highly dynamic 423 resource access. Once the specific set of micro-services for an 424 application has been identified, requirements (e.g., QoS) must be 425 ensured by the execution environment. Therefore, all micro-data 426 centres and the execution environment will need to realize mechanisms 427 for ensuring the utilization of specific resources within a pool of 428 resources for a specific set of micro-services belonging to one 429 application, while also ensuring integrity of the wider system. 430 Application-layer solution frameworks, such as those developed as 431 part of the Alto WG [ALTO], can be used for utilizing app/service- 432 specific constraints. 434 In relation to the service routing capability, realized below the 435 application layer and discussed in the previous sub-section, 436 constraints may need to be introduced into the forwarding decisions 437 for service requests. Such constraints will likely go beyond network 438 load and latency, as often applied in scenarios such as load 439 balancing in CDNs and as used in solutions such as [RFC7868]. 440 Instead, those constraints could be app/service-specific and will 441 need a suitable representation for the use within network nodes that 442 are forwarding service requests, as also outlined in [DYN-CAST]. 443 Moreover, individual router decisions (e.g., realized through 444 matching operations such as min/max/equal over a constraint 445 representation) may be coordinated to achieve a distribution of 446 service requests among many service instances, effectively realizing 447 a service scheduling capability in the network, optimized around 448 service-specific constraints, not unlike many existing data centre 449 service switching schemes. 451 As discussed already in Section 5.2, managing the constraints (for 452 controlling the forwarding behaviour) may be linked into the concepts 453 of intent-based networking [IB_CONC] to declaratively describe the 454 goals of the forwarding or steering of traffic, while specific 455 signaling protocols will need to be used to convey the actual 456 constraints as well as the operations performed on them in order to 457 fulfil the stated intent (or goals). 459 5.6 Collective Communication 461 Many micro-service scenarios may exhibit some form of collective 462 communication beyond 'just' unicast communication, therefore 463 requiring support for 1:M, M:1, and M:N communication. It is 464 important to consider here that such collective communication is 465 often extremely short-lived and can even take place at the level of a 466 single request, i.e., a following request may exhibit a different 467 communication pattern, even at least a different receiver group for 468 the same pattern, such as in the case of an interactive game. It is 469 therefore required that solutions for supporting such collective 470 communication must support the spontaneous formation of multicast 471 relations, as observed in those scenarios. 473 Solutions at Layer 2 have been discussed in [ICNIP], enabling the 474 delivery of service requests over a Layer2 forwarding solution. The 475 solution in [BIER-MC] utilizes the capabilities introduced by the 476 BIER multicast overlay [BIER] to form such spontaneous multicast 477 relations. Both approaches, however, are limited to the reachability 478 of the respective transport technology, i.e., the Layer 2 or BIER 479 overlay. Solutions over Layer 3 are currently limited to long-lived 480 IP multicast groups or will need to rely on application-level 481 solutions, mapping the group communication to replicated unicast 482 forwarding operations at the network layer, such as done in the 483 message passing interface [MPI], leading to significant 484 inefficiencies through high peak-to-average ratios for the required 485 transport network deployments. 487 5.7 State Synchronization 489 Given the highly distributed nature of app-centric micro-services, 490 their state exchange and synchronization is a very crucial aspect for 491 ensuring in-application and system wide consistency. Efforts such as 492 those in [GAIA-X] aim at developing solutions for application areas 493 such as distributed storage and data repositories. For this, 494 mechanisms that ensure consistency will ensure that data is 495 synchronized with different spatial, temporal and relational data 496 within a given time period. From the perspective of support through 497 in-network compute capabilities, such as provided through 498 technologies like P4, it is important to consider what system and 499 protocol support is required to utilize such in-network 500 capabilities. 502 5.8 Dynamic Contracts 504 NOTE: left for future revision 506 6 Overview of Relevant Standardization Efforts 508 +--------------+--------------------------------------------------+ 509 | Requirement | Standardization Efforts | 510 +==============+==================================================+ 511 | 1-Service | former Routing RG [RRG], possibly re-instated | 512 | Routing | Dyncast [DYN-CAST] | 513 | | APN BoF [APN] | 514 +--------------+--------------------------------------------------+ 515 | 2-Constraint | Dyncast [DYN-CAST] | 516 | based Fwd | EIGRP [RFC7868] | 517 | Decision | Alto WG [ALTO] | 518 | | Intent-based Networking [IB_CONC] | 519 +--------------+--------------------------------------------------+ 520 | 3-Flow | Dyncast [DYN-CAST] | 521 | Affinity | | 522 +--------------+--------------------------------------------------+ 523 | 4-Deployment | ETSI NFV MANO | 524 | | Intent-based Networking [IB_CONC} | 525 +--------------+--------------------------------------------------+ 526 | 5-Synchroni- | GAIA-X [GAIA-X] | 527 | zation | | 528 +--------------+--------------------------------------------------+ 529 | 6-Generic | Internet Services over ICN [ICNIP] | 530 | invocation | | 531 +--------------+--------------------------------------------------+ 532 | 7-Collective | BIER WG [BIER] | 533 | Communication| Internet Services over ICN (ICNIP] | 534 | | Multicast for HTTP over BIER [BIER-MC] | 535 +--------------+--------------------------------------------------+ 536 | 8-Orchestr. | 3GPP 5GLAN [SA2-5GLAN] and ETSI MANO | 537 +--------------+--------------------------------------------------+ 539 Figure 1: Mapping of Requirements to Standardization Efforts 541 7 Security Considerations 543 The use of semantic (or service) identifiers for routing decisions, 544 as mentioned in Section 5.4October 1, 2018April 4, 2019, requires 545 methods to ensure the privacy and security of the communication 546 through avoiding the exposure of service semantic (which is realized 547 at the application layer) to the network layer, therefore opening up 548 the opportunity for traffic inspection, among other things. The use 549 of cryptographic information, e.g., through self-certifying 550 identifiers, should be investigated to mitigate potential security 551 and privacy risks. 553 8 IANA Considerations 555 N/A 557 9 Conclusion 559 This draft positions the evolution of data centres as one of becoming 560 execution centres for the app-centric experiences provided today 561 mainly by smart phones directly. With the proliferation of data 562 centres closer to the end user in the form of edge-based micro data 563 centres, we believe that app-centric experiences will ultimately be 564 executed across those many, highly distributed execution points that 565 this increasingly rich edge environment will provide, such as smart 566 glasses and IoT devices. We have listed and discussed a number of 567 enabling key technologies that address some of the challenges for 568 realizing such AppCentre evolution. 570 Based on the requirements relevant to those key technologies, derived 571 from the COIN use cases, we have further provided an evaluation of 572 ongoing and related efforts in the relevant areas of study. We 573 believe that this analysis can be useful for positioning work 574 discussed and pursued in COIN against those ongoing efforts. 575 Furthermore, it may guide those interested in the respective key 576 technologies to create appropriate linkages to those ongoing efforts 577 elsewhere. 579 10 References 581 10.1 Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, DOI 585 10.17487/RFC2119, March 1997, https://www.rfc- 586 editor.org/info/rfc2119. 588 [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function 589 Chaining (SFC) Architecture", RFC 7665, DOI 590 10.17487/RFC7665, October 2015, https://www.rfc- 591 editor.org/info/rfc7665. 593 10.2 Informative References 595 [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, 596 M., Montesi, F., Mustafin, R., & Safina, L. (2017). 597 Microservices: yesterday,today, and tomorrow. In Present 598 and Ulterior Software Engineering (pp. 195-216). Springer, 599 Cham. 601 [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). 602 Microservices architecture enables devops: Migration to a 603 cloud-native architecture. IEEE Software, 33(3), 42-52. 605 [SRVLESS] C. Cicconetti, M. Conti and A. Passarella, "An 606 Architectural Framework for Serverless Edge Computing: 607 Design and Emulation Tools," 2018 IEEE International 608 Conference on Cloud Computing Technology and Science 609 (CloudCom), Nicosia, 2018, pp. 48-55. doi: 610 10.1109/CloudCom2018.2018.00024 612 [TOSCA] Topology and Orchestration Specification for Cloud 613 Applications Version 1.0. 25 November 2013. OASIS 614 Standard. http://docs.oasis- 615 open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html. 617 [ERLANG] Armstrong, Joe, et al. "Concurrent programming in ERLANG." 618 (1993). 620 [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm, 621 "A Catalog of Stream Processing Optimizations", ACM 622 Computing Surveys,46(4):1-34, Mar. 2014 624 [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M. 625 (2013, June). Pattern-based deployment service for next 626 generation clouds. In 2013 IEEE Ninth World Congress on 627 Services (pp. 464-471). IEEE. 629 [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E. 630 (2011, May). Pattern-based composite application 631 deployment. In 12th IFIP/IEEE International Symposium on 632 Integrated Network Management (IM 2011) and Workshops (pp. 633 217-224). IEEE. 635 [RFC8677] Trossen, D., Purkayastha, D., Rahman, A., "Name-Based 636 Service Function Forwarder (nSFF) Component within a 637 Service Function Chaining (SFC) Framework", RFC 8677, 638 November 2019. 640 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., White, 641 G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 642 https://www.ietf.org/archive/id/draft-irtf-icnrg-5gc-icn- 643 04, (work in progress), January 2021. 645 [ICN4G] Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R., 646 "Native Deployment of ICN in LTE, 4G Mobile Networks", 647 https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g- 648 08, (work in progress), January 2021. 650 [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M. 651 Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud 652 resource management: Review and discussion", Elsevier 653 Journal of Network and Computer Applications, 2017. 655 [GRPC] High performance open source universal RPC framework, 656 https://grpc.io/ 658 [MPI] A. Vishnu, C. Siegel, J. Daily, "Distributed TensorFlow 659 with MPI", https://arxiv.org/pdf/1603.02339.pdf 661 [FCDN] M. Al-Naday, M. J. Reed, J. Riihijarvi, D. Trossen, N. 662 Thomos, M. Al-Khalidi, "fCDN: A Flexible and Efficient CDN 663 Infrastructure without DNS Redirection of Content 664 Reflection", https://arxiv.org/pdf/1803.00876.pdf 666 [DYN-CAST] P. Liu, P. Willis, D. Trossen, "Dynamic-Anycast (Dyncast) 667 Use Cases and Problem Statement", 668 https://tools.ietf.org/html/draft-liu-rtgwg-dyncast-ps- 669 usecases-00, (work in progress), January 2021 671 [SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description, 672 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 673 LAN Services", 3GPP, 674 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-181120.zip 676 [COIN-usecases] I. Kunze, K. Wehrle, D. Trossen, "Use Cases for In- 677 Network Computing", https://tools.ietf.org/html/draft- 678 kunze-coin-industrial-use-cases-04, (work in progress), 679 January 2021. 681 [APN] Application-Aware Networking (APN), IETF BoF, 682 https://datatracker.ietf.org/group/apn/about/ (work in 683 progress), January 2021. 685 [RFC7868] D. Davage et al. , "Cisco's Enhanced Interior Gateway 686 Routing Protocol (EIGRP)", RFC 7868, May 2016, 687 https://tools.ietf.org/html/rfc7868 689 [ALTO] Application-Layer Traffic Optimization, IETF Working 690 Group, https://datatracker.ietf.org/wg/alto/about/, 691 January 2021 693 [GAIA-X] Gaia-X, "GAIA-X: A Federated Data Infrastructure for 694 Europe", accessed January 2021, https://www.data- 695 infrastructure.eu/GAIAX/Navigation/EN/Home/home.html, 696 January 2021 698 [ICNIP] D. Trossen, S. Robitzsch, M. Reed, M. Al-Naday, J. 699 Riihijarvi, "Internet Services over ICN in 5G LAN 700 Environments", https://tools.ietf.org/html/draft-trossen- 701 icnrg-internet-icn-5glan-04, (work in progress), January 702 2021 704 [BIER-MC] D. Trossen, A. Rahman, C. Wang, T. Eckert, "Applicability 705 of BIER Multicast Overlay for Adaptive Streaming 706 Services", https://tools.ietf.org/html/draft-ietf-bier- 707 multicast-http-response-05, (work in progress), January 708 2021 710 [BIER] Bit Indexed Explicit Replication, IETF Working Group, 711 https://datatracker.ietf.org/wg/bier/about/, January 2021 713 [RRG] Routing RG (concluded), IRTF Research Group, 714 https://trac.ietf.org/trac/irtf/wiki/RoutingResearchGroup, 715 accessed January 2021 717 [FIPE] Future Internet Protocol Evolution (FIPE) side meeting, 718 https://github.com/FIPE-Study/IETF109-Side-Meeting-FIPE, 719 November 2020 721 [IB_CONC] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, 722 "Intent-Based Networking - Concepts and Definitions", 723 https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn- 724 concepts-definitions/, (work in progress), September 2020 726 Authors' Addresses 728 Dirk Trossen 729 Huawei Technologies Duesseldorf GmbH 730 Riesstr. 25C 731 80992 Munich 732 Germany 734 Email: Dirk.Trossen@Huawei.com 736 Chathura Sarathchandra 737 InterDigital Europe, Ltd. 738 64 Great Eastern Street, 1st Floor 739 London EC2A 3QR 740 United Kingdom 742 Email: Chathura.Sarathchandra@InterDigital.com 744 Michael Boniface 745 University of Southampton 746 University Road 747 Southampton SO17 1BJ 748 United Kingdom 750 Email: mjb@it-innovation.soton.ac.uk