COIN                                                          D. Trossen
INTERNET-DRAFT                                                    Huawei
Intended Status: Informational                          C. Sarathchandra
Expires: April 25, 2021                                InterDigital Inc.
                                                             M. Boniface
                                               University of Southampton
                                                        October 23, 2020

          In-Network Computing for App-Centric Micro-Services


   The application-centric deployment of 'Internet' services has
   increased over the past ten years with many millions of applications
   providing user-centric services, executed on increasingly more
   powerful smartphones that are supported by Internet-based cloud
   services in distributed data centres, the latter mainly provided by
   large scale players such as Google, Amazon and alike. This draft
   outlines a vision for evolving those data centres towards executing
   app-centric micro-services; we dub this evolved data centre as an
   AppCentre. Complemented with the proliferation of such AppCentres at
   the edge of the network, they will allow for such micro-services to
   be distributed across many places of execution, including mobile
   terminals themselves, while specific micro-service chains equal
   today's applications in existing smartphones. We outline the key
   enabling technologies that needs to be provided for such evolution to
   be realized, including references to ongoing IETF work in some

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Trossen, et al.          Expires April 25, 2021                 [Page 1]

INTERNET DRAFT         App-Centric Micro-Services

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright and License Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1  Mobile Application Function Offloading  . . . . . . . . . .  5
     3.2  Interactive Real-time Applications  . . . . . . . . . . . .  7
     3.3  Distributed AI  . . . . . . . . . . . . . . . . . . . . . .  7
     3.4  Content Delivery Networks . . . . . . . . . . . . . . . . .  8
     3.5  Compute-Fabric-as-a-Service (CFaaS) . . . . . . . . . . . .  8
   4  Requirements Derived from Use Cases . . . . . . . . . . . . . .  9
   5  Enabling Technologies . . . . . . . . . . . . . . . . . . . . . 10
     5.1  Application Packaging . . . . . . . . . . . . . . . . . . . 10
     5.2  Service Deployment  . . . . . . . . . . . . . . . . . . . . 11
     5.3  Compute Inter-Connection at Layer 2 . . . . . . . . . . . . 12
     5.4  Service Routing . . . . . . . . . . . . . . . . . . . . . . 13
     5.5  Constraint-based Forwarding Decisions . . . . . . . . . . . 14
     5.6  Collective Communication  . . . . . . . . . . . . . . . . . 14
     5.7  State Synchronization . . . . . . . . . . . . . . . . . . . 15
     5.8  Dynamic Contracts . . . . . . . . . . . . . . . . . . . . . 15
   6  Security Considerations . . . . . . . . . . . . . . . . . . . . 15
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
   8  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 16

Trossen, et al.          Expires April 25, 2021                 [Page 2]

INTERNET DRAFT         App-Centric Micro-Services

     9.2  Informative References  . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Trossen, et al.          Expires April 25, 2021                 [Page 3]

INTERNET DRAFT         App-Centric Micro-Services

1  Introduction

   With the increasing dominance of smartphones and application markets,
   the end-user experiences today have been increasingly centered around
   the applications and the ecosystems that smartphone platforms create.
   The experience of the 'Internet' has changed from 'accessing a web
   site through a web browser' to 'installing and running an application
   on a smartphone'. This app-centric model has changed the way services
   are being delivered not only for end-users, but also for business-to-
   consumer (B2C) and business-to-business (B2B) relationships.

   Designing and engineering applications is largely done statically at
   design time, such that achieving significant performance improvements
   thereafter has become a challenge (especially, at runtime in response
   to changing demands and resources). Applications today come
   prepackaged putting them at disadvantage for improving efficiency due
   to the monolithic nature of the application packaging. Decomposing
   application functions into micro-services [MSERVICE1] [MSERVICE2]
   allows applications to be packaged dynamically at run-time taking
   varying application requirements and constraints into consideration.
   Interpreting an application as a chain of micro-services, allows the
   application structure, functionality, and performance to be adapted
   dynamically at runtime in consideration of tradeoffs between quality
   of experience, quality of service and cost.

   Interpreting any resource rich networked computing (and storage)
   capability not just as a pico or micro-data centre, but as an
   application-centric execution data centre (AppCentre), allows
   distributed execution of micro-services. Here, the notion of an
   'application' constitutes a set of objectives being realized in a
   combined packaging of micro-services under the governance of the
   'application provider'. These micro-services may then be deployed on
   the most appropriate AppCentre (edge/fog/cloud resources) to satisfy
   requirements under varying constraints. In addition, the high degree
   of distribution of application and data partitions, and compute
   resources offered by the execution environment decentralizes control
   between multiple cooperating parties (multi-technology, multi-domain,
   multi-ownership environments). Furthermore, compute resource
   availability may be volatile, particularly when moving along the
   spectrum from well-connected cloud resources over edge data centres
   to user-provided compute resources, such as (mobile) terminals or
   home-based resources such as NAS and IoT devices.

   We believe that the emergence of AppCentreS will democratize
   infrastructure and service provision to anyone with compute resources
   with the notion of applications providing an element of governing the
   execution of micro-services. This increased distribution will lead to
   new forms of application interactions and user experiences based on

Trossen, et al.          Expires April 25, 2021                 [Page 4]

INTERNET DRAFT         App-Centric Micro-Services

   cooperative AppCentreS (pico-micro and large cloud data centres), in
   which applications are being designed, dynamically composed and

2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

3  Use Cases

   Although our motivation for the 'AppCentre' term stems from the
   (mobile) application ecosystem, the use cases in this section are not
   limited to mobile applications only. Instead, we interpret
   'applications' as a governing concept of executing a set of micro-
   services where the 'application provider' can reach from those
   realizing mobile applications over novel network applications to
   emerging infrastructure offerings serving a wide range of
   applications in a purpose- (and therefore application-)agnostic
   manner. The following use cases provide examples for said spectrum of

3.1  Mobile Application Function Offloading

   Partitioning an application into micro-services allows for denoting
   the application as a collection of functions for a flexible
   composition and a distributed execution, e.g., most functions of a
   mobile application can be categorized into any of three, "receiving",
   "processing" and "displaying" function groups.

   Any device may realize one or more of the micro-services of an
   application and expose them to the execution environment. When the
   micro-service sequence is executed on a single device, the outcome is
   what you see today as applications running on mobile devices.
   However, the execution of functions may be moved to other (e.g., more
   suitable) devices which have exposed the corresponding micro-services
   to the environment. The result of the latter is flexible mobile
   function offloading, for possible reduction of power consumption
   (e.g., offloading CPU intensive process functions to a remote server)
   or for improved end user experience (e.g., moving display functions
   to a nearby smart TV).

   The above scenario can be exemplified in an immersive gaming
   application, where a single user plays a game using a VR headset. The
   headset hosts functions that "display" frames to the user, as well as
   the functions for VR content processing and frame rendering combining
   with input data received from sensors in the VR headset. Once this

Trossen, et al.          Expires April 25, 2021                 [Page 5]

INTERNET DRAFT         App-Centric Micro-Services

   application is partitioned into micro-services and deployed in an
   app-centric execution environment, only the "display" micro-service
   is left in the headset, while the compute intensive real-time VR
   content processing micro-services can be offloaded to a nearby
   resource rich home PC, for a better execution (faster and possibly
   higher resolution generation).

   Figure 1 shows one realization of the above scenario, where a 'DPR
   app' is running on a mobile device (containing the partitioned
   Display(D), Process(P) and Receive(R) micro services) over an SDN
   network. The packaged applications are made available through a
   localized 'playstore server'. The application installation is
   realized as a 'service deployment' process (Section 5.2.), combining
   the local app installation with a distributed micro-service
   deployment (and orchestration) on most suitable AppCentreS
   ('processing server').

                                  +----------+ Processing Server
                Mobile            | +------+ |
             +---------+          | |  P   | |
             |   App   |          | +------+ |
             | +-----+ |          | +------+ |
             | |D|P|R| |          | |  SR  | |
             | +-----+ |          | +------+ |         Internet
             | +-----+ |          +----------+            /
             | |  SR | |              |                  /
             | +-----+ |            +----------+     +------+
             +---------+           /|SDN Switch|_____|Border|
                     \ +-------+ / +----------+     |  SR  |
                      \| 5GAN  |/       |           +------+
                        +-------+        |
           +---------+                   |
           |+-------+|               +----------+
           ||Display||              /|SDN Switch|
           |+-------+|   +-------+ / +----------+
           |+-------+|  /|WIFI AP|/     \
           ||   D   || / +-------+     +--+
           |+-------+|/                |SR|
           |+-------+|                /+--+
           ||  SR   ||            +---------+
           |+-------+|            |Playstore|
           +---------+            | Server  |
                TV                +---------+

          Figure 1: Application Function Offloading Example

   Such localized deployment could, for instance, be provided by a
   visiting site, such as a hotel or a theme park. Once the 'processing'

Trossen, et al.          Expires April 25, 2021                 [Page 6]

INTERNET DRAFT         App-Centric Micro-Services

   micro-service is terminated on the mobile device, the 'service
   routing' (SR) elements in the network (Section 5.4.) routes requests
   to the previously deployed 'processing' micro-service running on the
   'processing server' AppCentre over an existing SDN network. As an
   extension to the above scenarios, we can also envision that content
   from one processing micro-service may be distributed to more than one
   display micro-service, e.g., for multi/many-viewing scenarios.

3.2  Interactive Real-time Applications

   There has been a recent shift from applications that provide single-
   user experiences, such as the ones described in the previous section
   to collaborative/cooperative experiences that are highly interactive
   with strict real-time requirements, such as collaborative working,
   education, multi-user gaming, and mixed/virtual reality. This leads
   to increasing interaction where input (e.g., gesture, gaze, touch,
   movement) and output (e.g., visual display, sound, and actuation)
   needs to be processed within strict timing constraints and
   synchronized to ensure temporal and spatial consistency with local
   and distant users. App-centric design allows functions with high data
   and process coupling to be modularized, deployed and executed, such
   that the subset of micro-services is cooperatively executed towards
   optimizing the interactive experiences.

   The same example of the previous section can be envisaged in a multi-
   player gaming scenario. Here the micro-services that need to be
   executed cooperatively are executed in a localized and synchronized
   manner to ensure player coordination and synchronized state between
   collaborating players.

3.3  Distributed AI

   There is a growing range of use cases demanding for the realization
   of AI capabilities among distributed endpoints. Such demand may be
   driven by the need to increase overall computational power for large-
   scale problems. Other solutions may desire the localization of
   reasoning logic, e.g., for deriving attributes that better preserve
   privacy of the utilized raw input data. Examples for large-scale AI
   problems include biotechnology and astronomy related reasoning over
   massive amounts of observational input data. Examples for localizing
   input data for privacy reasons include radar-like application for the
   development of topological mapping data based on (distributed) radio
   measurements at base stations (and possibly end devices), while the
   processing within radio access networks (RAN) already constitute a
   distributed AI problem to a certain extent albeit with little
   flexibility in distributing the execution of the AI logic.

   Reasoning frameworks, such as TensorFlow, may be utilized for the

Trossen, et al.          Expires April 25, 2021                 [Page 7]

INTERNET DRAFT         App-Centric Micro-Services

   realization of the (distributed) AI logic, building on remote service
   invocation through protocols such as gRPC [GRPC] or MPI [MPI] with
   the intention of providing an on-chip NPU (neural processor unit)
   like abstraction to the AI framework.

3.4  Content Delivery Networks

   Delivery of content to end users often relies on Content Delivery
   Networks (CDNs) storing said content closer to end users for latency
   reduced delivery with DNS-based indirection being utilized to serve
   the request on behalf of the origin server. From the perspective of
   this draft, a CDN can be interpreted as a (network service level)
   application with distributed logic for distributing content from the
   origin server to the CDN ingress and further to the CDN replication
   points which ultimately serve the user-facing content requests.

   Studies such as those in [FCDN] have shown that content distribution
   at the level of named content, utilizing efficient (e.g., Layer 2)
   multicast for replication towards edge CDN nodes, can significantly
   increase the overall network and server efficiency. It also reduces
   indirection latency for content retrieval as well as reduces required
   edge storage capacity by benefiting from the increased network
   efficiency to renew edge content more quickly against changing

3.5  Compute-Fabric-as-a-Service (CFaaS)

   App-centric execution environments, consisting of Layer 2 connected
   AppcentreS, provide the opportunity for infrastructure providers to
   offer CFaaS type of offerings to application providers. Those app
   providers utilize the compute fabric exposed by this CFaaS offering
   for the purposes defined through their applications. In other words,
   the compute resources can be utilized to execute the desired micro-
   services of which the application is composed, while utilizing the
   inter-connection between those compute resources to do so in a
   distributed manner.

   We foresee those CFaaS offerings to be tenant-specific, a tenant here
   defined as the provider of at least one application. For this, we
   foresee an interaction between CFaaS provider and tenant to
   dynamically select the appropriate resources to define the demand
   side of the fabric. Conversely, we also foresee the supply side of
   the fabric to be highly dynamic with resources being offered to the
   fabric through, e.g., user-provided resources (whose supply might
   depend on highly context-specific supply policies) or infrastructure
   resources of intermittent availability such as those provided through
   road-side infrastructure in vehicular scenarios. The resulting
   dynamic demand-supply matching establishes a dynamic nature of the

Trossen, et al.          Expires April 25, 2021                 [Page 8]

INTERNET DRAFT         App-Centric Micro-Services

   compute fabric that in turn requires trust relationships to be built
   dynamically between the resource provider(s) and the CFaaS provider.
   This also requires the communication resources to be dynamically
   adjusted to interconnect all resources suitably into the (tenant-
   specific) fabric exposed as CFaaS.

4  Requirements Derived from Use Cases

   The following requirements are derived from the presented use cases
   in Section 3.1. to 3.5., numbered according to the use case numbers
   (as main item numbers) although those requirements apply in some
   cases across more than one of the presented use cases.

   Req 1.1: Any app-centric execution environment MUST provide means for
            routing of service requests between resources in the
            distributed environment.

   Req 1.2: Any app-centric execution environment MUST provide means for
            dynamically choosing the best possible micro-service
            sequence (i.e., chaining of micro-services) for a given
            application experience. Means for discovering suitable
            micro-service SHOULD be provided.

   Req 1.3: Any app-centric execution environment MUST provide means for
            pinning the excution of a specific micro-service to a
            specific resource instance in the distributed environment.

   Req 1.4: Any app-centric execution environment SHOULD provide means
            for packaging micro-services for deployments in distributed
            networked computing environments. The packaging MAY include
            any constraints regarding the deployment of service
            instances in specific network locations or compute
            resources. Such packaging SHOULD conform to existing
            application deployment models, such as mobile application
            packaging, TOSCA orchestration templates or tar balls or
            combinations thereof.

   Req 2.1: Any app-centric execution environment MUST provide means for
            real-time synchronization and consistency of distributed
            application states.

   Req 3.1: Any app-centric execution environment MUST provide means to
            specify the constraints for placing (AI) execution logic in
            certain logical execution points (and their associated
            physical locations).

   Req 3.2: Any app-centric execution environment MUST provide support
            for app/micro-service specific invocation protocols.

Trossen, et al.          Expires April 25, 2021                 [Page 9]

INTERNET DRAFT         App-Centric Micro-Services

   Req 4.1: Any app-centric execution environment SHOULD utilize Layer 2
            multicast transmission capabilities for responses to
            concurrent service requests.

   Req 5.1: Any app-specific execution environment SHOULD expose means
            to specify the requirements for the tenant-specific compute
            fabric being utilized for the app execution.

   Req 5.2: Any app-specific execution environment SHOULD allow for
            dynamic integration of compute resources into the compute
            fabric being utilized for the app execution; those resources
            include, but are not limited to, end user provided

   Req 5.3: Any app-specific execution environment MUST provide means to
            optimize the inter-connection of compute resources,
            including those dynamically added and removed during the
            provisioning of the tenant-specific compute fabric.

   Req 5.4: Any app-specific execution environment MUST provide means
            for ensuring availability and usage of resources is
            accounted for.

5  Enabling Technologies

   This section discusses a number of enabling technologies relevant for
   the realization of the app-centric micro-service vision laid out in
   this draft.

   EDITOR NOTE: Section 5 will be updated to include the addressing of
   specific requirements listed in Section 4.

5.1  Application Packaging

   Applications often consist of one or more sub-elements (e.g., audio,
   visual, hepatic elements) which are 'packaged' together, resulting in
   the final installable software artifact. Conventionally, application
   developers perform the packaging process at design time, by packaging
   a set of software components as a (often single) monolithic software
   package, for satisfying a set of predefined application

   Decomposing micro-services of an application, and then executing them
   on peer execution points in AppCentreS (e.g., on an app-centric
   serverless runtime [SRVLESS]) can be done with design-time planning.
   Micro-service decomposition process involves, defining clear
   boundaries of the micro-service (e.g., using wrapper classes for

Trossen, et al.          Expires April 25, 2021                [Page 10]

INTERNET DRAFT         App-Centric Micro-Services

   handling input/output requests), which could be done by the
   application developer at design-time (e.g., through Android app
   packaging by including, as part of the asset directory, a service
   orchestration template [TOSCA] that describes the decomposed micro-
   services). Likewise, the peer execution points could be 'known' to
   the application (e.g., using well-known and fixed peer execution
   points on AppCentreS) and incorporated with the micro-services by the
   developer at design-time.

   Existing programming frameworks address decomposition and execution
   of applications centering around other aspects such as concurrency
   [ERLANG]. For decomposing at runtime, application elements can be
   profiled using various techniques such as dynamic program analysis or
   dwarf application benchmarks. The local profiler information can be
   combined with the profiler information of other devices in the
   network for improved accuracy. The output of such a profiler process
   can then be used to identify smaller constituting sub-components of
   the application in forms of pico-services, their interdependencies
   and data flow (e.g., using caller/callee information, instruction
   usage). Due to the complex nature of resulting application structure
   and therefore its increased overhead, in most cases, it may not be
   optimal to decompose applications at the pico level. Therefore, one
   may cluster pico-services into micro-services with common
   characteristics, enabling a meaningful (e.g., clustering pico-
   services with same resource dependency) and a performant
   decomposition of applications. Characteristics of micro-services can
   be defined as a set of concepts using an ontology language, which can
   then be used for clustering similar pico-services into micro-
   services. Micro-services may then be partitioned along their
   identified borders. Moreover, mechanisms for governance, discovery
   and offloading can be employed for 'unknown' peer execution points on
   AppCentreS with distributed loci of control.

   Therefore, with this app-centric model, application packaging can be
   done at runtime by constructing micro-service chains for satisfying
   requirements of experiences (e.g., interaction requirements), under
   varying constraints (e.g., temporal consistency between multiple
   players within a shared AR/VR world)[SCOMPOSE]. Such packaging
   includes mechanisms for selecting the best possible micro-services
   for a given experience at runtime in the multi-technology
   environment. These run-time packaging operations may continuously
   discover the 'unknown' and adapt towards an optimal experience. Such
   decision mechanisms handle the variability, volatility and scarcity
   within this multi-X framework.

5.2  Service Deployment

   The service function chains, constituting each individual

Trossen, et al.          Expires April 25, 2021                [Page 11]

INTERNET DRAFT         App-Centric Micro-Services

   application, will need deployment mechanisms in a true multi-X
   (multi-user, multi-infrastructure, multi-domain) environment
   [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and
   orchestration processes are married into one, as a set of procedures
   governed by device owners directly or with delegated authority.
   However, apart from extending towards multi-X environments, the
   process also needs to cater for changes in the environment, caused,
   e.g., by movement of users, new pervasive sensors/actuators, and
   changes to available infrastructure resources. Methods are needed to
   deploy service functions as executable code into chosen service
   execution points. Those methods need to support the various endpoint
   (e.g., device stacks, COTS stacks, etc.) and service function
   realizations, e.g., through utilizing existing and emerging
   virtualization techniques.

   A combination of application installation procedure and orchestrated
   service deployment can be achieved by utilizing the application
   packaging with integrated service deployment templates described in
   Section 5.1 such that the application installation procedure on the
   installing device is being extended to not only install the local
   application package but also extract the service deployment template
   for orchestrating with the localized infrastructure, using, for
   instance, REST APIs for submitting the template to the orchestrator.

5.3  Compute Inter-Connection at Layer 2

   While Layer2 switching technologies have long proliferated in data
   centre deployments, recent developments have advanced the
   capabilities for interconnecting distributed computing resources over
   Layer2 technologies. For instance, the efforts in 3GPP on so-called
   '5G LAN' (or Vertical LAN) [SA2-5GLAN] allow for establishing a
   Layer2 bearer between participating compute entities, using a
   vertical-specific LAN identifier for packet forwarding between the
   distributed Layer2 entities. Combined with Layer2 technology in data
   centres as well as office and home networks alike, this enables the
   deployment of services in vertical (Layer2) networks, interconnecting
   with other Internet-based services through dedicated service

   Real deployments and realizations will have to show the scalability
   of this approach but it points into a direction where application or
   service-specific deployments could potentially 'live' entirely in
   their own vertical network, interconnecting only based on need (which
   for many services may not exist). From the application's or service's
   perspective, the available compute resource pool will look no
   different from that being realized in a single data centre albeit
   with the possibility to being highly distributed now among many
   (e.g., edge) data centres as well as mobile devices.

Trossen, et al.          Expires April 25, 2021                [Page 12]

INTERNET DRAFT         App-Centric Micro-Services

   In such a deployment, it is interesting to study the realization of
   suitable service routing capabilities, leading us to the next
   technology area of interest.

5.4  Service Routing

   Routing service requests is a key aspect within a combined compute
   and network infrastructure in order to enable true end-to-end
   experiences across distributed application execution points
   provisioned on distant cloud, edge and device-centric resources. Once
   the micro-services are packaged and deployed in such highly
   distributed micro-data centres, the routing mechanisms must ensure
   efficient information exchange between corresponding micro-services,
   e.g., at the level of service requests, within the multi-technology
   execution environment.

   Routing here becomes a problem of routing micro-service requests, not
   just packets, as done through IP. This calls for some form of 'flow
   affinity' that allows for treating several packets as part of a
   request semantic. This is important, e.g., for mobility (avoiding to
   send some packets of a larger request to one entity, while other
   packets are sent to another one, therefore creating incomplete
   information at both entities as a result). Also, when applying
   constraints to the forwarding of packets (discussed in more detail in
   Section 5.6), it is important to apply the actions across the packets
   of the request rather than individually.

   Another key aspect is that of addressing services. Traditionally, the
   combination of the Domain Naming Service (DNS) and IP routing has
   been used for this purpose. However, the advent of virtualization
   with use cases such as those outlined in Section 3 (such as those on
   app-specific micro-services on mobile devices) have made it
   challenging to further rely on the DNS. Apart from the initial delay
   observed when resolving a service name into a locator for the first
   time, the long delay in updating DNS entries to 'point' to the right
   micro-service instances prohibits offloading to dynamically created
   service instances. If one was to use the DNS, one would be updating
   the DNS entries at a high rate, caused by the diversity of trigger,
   e.g., through movement. DNS has not been designed for such frequent
   update, rendering it useless for such highly dynamic applications.
   With many edge scenarios in the VR/AR space demanding interactivity
   and being latency-sensitive, efficient routing will be key to any

   Various ongoing work on service request forwarding [RFC8677] with the
   service function chaining [RFC7665] framework as well as name-based
   routing [ICN5G][ICN4G] addresses some aspects described above albeit
   with a focus on HTTP as the main invocation protocol. Extensions will

Trossen, et al.          Expires April 25, 2021                [Page 13]

INTERNET DRAFT         App-Centric Micro-Services

   be required to support other invocation protocols, such as GRPC or
   MPI (for distributed AI use cases, as outlined in Section 3.3.).
   Proposals such as those in [DYN-CAST] suggest extensions to the IP
   anycast scheme to enable the flexible routing of service requests to
   one or more service instances. Common to those proposals is the use
   of a semantic identifier, often a service identifier akin to a URL,
   in the routing decision within the network.

5.5  Constraint-based Forwarding Decisions

   Allocating the right resources to the right micro-services is a
   fundamental task when executing micro-services across highly
   distributed micro-data centres (e.g., resource management in cloud
   [CLOUDFED]). This is particularly important in the light of volatile
   resource availability as well as concurrent and highly dynamic
   resource access. Once the specific set of micro-services for an
   application has been identified, requirements (e.g., QoS) must be
   ensured by the execution environment. Therefore, all micro-data
   centres and the execution environment will need to realize mechanisms
   for ensuring the utilization of specific resources within a pool of
   resources for a specific set of micro-services belonging to one
   application, while also ensuring integrity of the wider system.

   In relation to the service routing capability discussed in the
   previous sub-section, constraints may need to be introduced into the
   forwarding decisions for service requests. Such constraints will
   likely go beyond network load and latency, as often applied in
   scenarios such as load balancing in CDNs. Instead, those constraints
   are generally app/service-specific and will need a suitable
   representation for the use within network nodes, i.e., the routers
   that are forwarding service requests. Moreover, individual router
   decisions (e.g., realized through matching operations such as
   min/max/equal over a constraint representation) may be coordinated to
   achieve a distribution of service requests among many service
   instances, effectively realizing a service scheduling capability in
   the network, optimized around service-specific constraints, not
   unlike many existing data centre service switching schemes.

5.6  Collective Communication

   Many micro-service scenarios may exhibit some form of collective
   communication beyond 'just' unicast communication, therefore
   requiring support for 1:M, M:1, and M:N communication. It is
   important to consider here that such collective communication is
   often extremely short-lived and can even take place at the level of a
   single request, i.e., a following request may exhibit a different
   communication pattern, even at least a different receiver group for
   the same pattern, such as in the case of an interactive game. It is

Trossen, et al.          Expires April 25, 2021                [Page 14]

INTERNET DRAFT         App-Centric Micro-Services

   therefore required that solutions for supporting such collective
   communication must support the spontaneous formation of multicast
   relations, as observed in those scenarios.

5.7  State Synchronization

   Given the highly distributed nature of app-centric micro-services,
   their state exchange and synchronization is a very crucial aspect for
   ensuring in-application and system wide consistency. Mechanisms that
   ensure consistency will ensure that data is synchronized with
   different spatial, temporal and relational data within a given time
   period. From the perspective of support through in-network compute
   capabilities, such as provided through technologies like P4, it is
   important to consider what system and protocol support is required to
   utilize such in-network capabilities.

5.8  Dynamic Contracts

   NOTE: left for future revision

6  Security Considerations

   The use of semantic (or service) identifiers for routing decisions,
   as mentioned in Section 5.4October 1, 2018April 4, 2019, requires
   methods to ensure the privacy and security of the communication
   through avoiding the exposure of service semantic (which is realized
   at the application layer) to the network layer, therefore opening up
   the opportunity for traffic inspection, among other things. The use
   of cryptographic information, e.g., through self-certifying
   identifiers, should be investigated to mitigate potential security
   and privacy risks.

7  IANA Considerations


8  Conclusion

   This draft positions the evolution of data centres as one of becoming
   execution centres for the app-centric experiences provided today
   mainly by smart phones directly. With the proliferation of data
   centres closer to the end user in the form of edge-based micro data
   centres, we believe that app-centric experiences will ultimately be
   executed across those many, highly distributed execution points that
   this increasingly rich edge environment will provide, such as smart
   glasses and IoT devices. Although a number of activities are
   currently underway to address some of the challenges for realizing
   such AppCentre evolution, we believe that the proposed COIN research

Trossen, et al.          Expires April 25, 2021                [Page 15]

INTERNET DRAFT         App-Centric Micro-Services

   group will provide a suitable forum to drive forward the remaining
   research and its dissemination into working systems and the necessary
   standardization of key aspects and protocols.

9  References

9.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <https://www.rfc-

   [RFC7665]  Halpern, J., Ed., and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665, DOI
              10.17487/RFC7665, October 2015, <https://www.rfc-

9.2  Informative References

   [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara,
              M., Montesi, F., Mustafin, R., & Safina, L. (2017).
              Microservices: yesterday,today, and tomorrow. In Present
              and Ulterior Software Engineering (pp. 195-216). Springer,

   [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016).
              Microservices architecture enables devops: Migration to a
              cloud-native architecture. IEEE Software, 33(3), 42-52.

   [SRVLESS]  C. Cicconetti, M. Conti and A. Passarella, "An
              Architectural Framework for Serverless Edge Computing:
              Design and Emulation Tools," 2018 IEEE International
              Conference on Cloud Computing Technology and Science
              (CloudCom), Nicosia, 2018, pp. 48-55. doi:

   [TOSCA]    Topology and Orchestration Specification for Cloud
              Applications Version 1.0. 25 November 2013. OASIS
              Standard. <http://docs.oasis-

   [ERLANG]   Armstrong, Joe, et al. "Concurrent programming in ERLANG."

   [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm,
              "A Catalog of Stream Processing Optimizations", ACM
              Computing Surveys,46(4):1-34, Mar. 2014

Trossen, et al.          Expires April 25, 2021                [Page 16]

INTERNET DRAFT         App-Centric Micro-Services

   [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M.
              (2013, June). Pattern-based deployment service for next
              generation clouds. In 2013 IEEE Ninth World Congress on
              Services (pp. 464-471). IEEE.

   [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E.
              (2011, May). Pattern-based composite application
              deployment. In 12th IFIP/IEEE International Symposium on
              Integrated Network Management (IM 2011) and Workshops (pp.
              217-224). IEEE.

   [RFC8677]     Trossen, D., Purkayastha, D., Rahman, A., "Name-Based
              Service Function Forwarder (nSFF) Component within a
              Service Function Chaining (SFC) Framework", RFC 8677,
              November 2019.

   [ICN5G]    Ravindran, R., Suthar, P., Trossen, D., Wang, C., White,
              G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture",
              (work in progress), March 2019.

   [ICN4G]    Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R.,
              "Native Deployment of ICN in LTE, 4G Mobile Networks",
              03> (work in progress), March 2019.

   [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M.
              Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud
              resource management: Review and discussion", Elsevier
              Journal of Network and Computer Applications, 2017.

   [GRPC] High performance open source universal RPC framework,

   [MPI] A. Vishnu, C. Siegel, J. Daily, "Distributed TensorFlow with

   [FCDN] M. Al-Naday, M. J. Reed, J. Riihijarvi, D. Trossen, N. Thomos,
              M. Al-Khalidi, "fCDN: A Flexible and Efficient CDN
              Infrastructure without DNS Redirection of Content

   [DYN-CAST] Y. Li, J. He, L. Geng, P. Liu, Y. Cui, "Framework of
              Compute First Networking (CFN)",
              00> (work in progress), November 2019

   [SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description,

Trossen, et al.          Expires April 25, 2021                [Page 17]

INTERNET DRAFT         App-Centric Micro-Services

              Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and
              LAN Services", 3GPP,
Authors' Addresses

   Dirk Trossen
   Huawei Technologies Duesseldorf GmbH
   Riesstr. 25C
   80992 Munich


   Chathura Sarathchandra
   InterDigital Europe, Ltd.
   64 Great Eastern Street, 1st Floor
   London EC2A 3QR
   United Kingdom


   Michael Boniface
   University of Southampton
   University Road
   Southampton SO17 1BJ
   United Kingdom


Trossen, et al.          Expires April 25, 2021                [Page 18]