| Internet-Draft | DMSC Technical Considerations | January 2025 |
| Yuan, et al. | Expires 18 July 2025 | [Page] |
With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, updated framework and architecture would be required and designed, aiming to wisely allocate and schedule resources and services in order to provide consistent end-to-end service provisioning with Distributed Micro Service Communication (DMSC).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 18 July 2025.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In the context of cloud native, applications are often no longer provided in the form of monolithic services, but are decomposed into a series of cloud native services deployed in distributed clusters, with inter-connections and joint provision to the outer side. Relevant scenarios was discussed in [I-D.yuan-rtgwg-hfc-framework] with the introduction of a Hybrid Function Chain (HFC) framework. Technical considerations and brief designs in the previous work would also be applicable in a Distributed Micro Service Communication (DMSC) circumstance. Thus, similar perceptions mentioned are stated in this draft for further discussion and review.¶
Existing schemes, for which especially applied in cloud and cluster infrastructure, traffic lanes, for instance, have emerged to be a typical scenario for DMSC and been commonly used for environmental isolation and traffic control of the entire request chain of services for grayscale publishing scenarios, would be reckoned as a typical example for DMSC. In fact, assuming Istio and Kubernetes as the typical infrastructure for Cloud Native Services, the creation of traffic lanes is still executed by various existing network API configurations of the cluster. The service routes are always configured in the cluster and identified endpoints under a service name to implement various scheduling strategies and perform load balancing schemes among multiple optional instances.¶
With another aspect, edge computing, as a distributed computing paradigm, the core idea is to make computing, storage and service processing as close to the clients and customers as possible to reduce latency, improve response speed and enhance data security. When applications are further deconstructed into atomic services as analyzed previously, service inter-connections MAY not only exist in adjacent clusters deployed in a same edge, but also happen with network paths connecting remote edge data centers. Thus, incremental requirements would be raised correspondingly. Relevant use cases and requirements are discussed in [I-D.song-dmsc-promblem-and-requirements] and [I-D.huang-rtgwg-us-standalone-sid].¶
Therefore, requirements from development of IT/CT applications, infrastructure and patterns give rise to the promising furture of DMSC. Significant features of both distributed paradigm and application deconstruction also bring updated challenges and problems.¶
Correspondingly, this draft proposes technical considerations and primary designs about DDMSC. Compared to conventional schemes and patterns, Distributed Micro Service Communication, Collaboration and Association is granted with multiple features and connotations.¶
Step 1
----
( -- )
-----------> ( ( ) )
Request ( -- )
-------- \ +---+
\ ( )
\ Step 2 Step 3 +-- +
\ ---- ( )
\ ( -- ) ( -- -- )
V ( ( ) ) ( ( )( ) )
( -- )<--------->( -- -- ... )
/ -------- ( )
/ +------------+
/
Step 4 /
---- /
( -- ) /
<----------- ( ( ) )V
( -- )
--------
Edge Clusters/Clouds
Micro services would be deployed within various forms, providing functionality for different applications: Considering the deployment phase, services and application functions can be deployed in one or multiple clusters in the form of containers, or deployed based on virtual machines. Service instances can be deployed with multiple instances with dynamic implementation and released based on a Serverless framework. Based on the run-time state, micro services and atomic functions form a diverse set of external services, and correspondingly, often raise various requirements for the resources and network capabilities. Compared to conventional Service Function Chain (SFC), the service functions targeted and discussed in DMSC contains functions from both underlay network and application (L7) services.¶
Hybrid inter-connections and relations MAY exist between service instances of micro services: The inter-connection, interaction, and collaboration schemes between upstream and downstream micro services are always allocated and implemented within various forms. For instance, upstream functions MAY propose unidirectional notifications. Bidirectional requests and responses MAY also be observed between upstream function and single or multiple downstream functions. Multiple inter-connection forms MAY be implemented simultaneously in an overall DMSC process.¶
Techniques for hybrid areas and protocal stack layers are required for DMSC: For conventional SFC in which Firewalls and Accelerators MAY be included, service functions are not tended and deployed to terminate data packets. However, for micro services composing L7 applications in DMSC scenarios, packets and payloads are always terminated at endpoints and payloads would be reorganized and regenerated. The provisioning of micro services inter-connection requires collaboration among multiple techniques and extends across TCP/IP stacks.¶
Based on the considerations above, this draft further analyzes a possible and primary framework and deconstructs it into several planes with incremental functions and features based on conventional network and service mesh techniques.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Technical considerations for DMSC would generally includes administration plane, control plane and forwarding plane. Based on conventional framework of network and cloud native practices, several incremental functions and features are added and deployed.¶
-----------------------------------------------------------------------------
+----------+ +-----------+ +---------+
| AR/VR/XR | | Metaverse | | ....... |
+----------+ +-----------+ +---------+
Outer Application Composing DMSC
-----------------------------------------------------------------------------
Administration +------------------------------------+
Plane | Service Analysis & Operation |
+------------------------------------+
+------------------------------------+
| Service Evaluation & Modeling |
+------------------------------------+
+------------------------------------+
| Service Scheduling & Orchestration |
+------------------------------------+
-----------------------------------------------------------------------------
Control Plane
+---------------+ +---------------------------------------+ +---------------+
| | | Service Registration & Administration | | |
|K8S, | +---------------------------------------+ | |
|Service Mesh | +---------------------------------------+ | |
|(Istio) | | Service Discovery & Publication | | |
| | +---------------------------------------+ | |
|Galley, Pilot, | +---------------------------------------+ | |
|Mixer, Citadel | |Service Routes Calculation & Generation| | |
| | +---------------------------------------+ | |
| Cluster | +---------------------------------------+ | Network |
| Control Plane | |Service Inter-connection Configuration | | Control Plane |
+---------------+ +---------------------------------------+ +---------------+
-----------------------------------------------------------------------------
Forwarding +---------------------------------------+
Plane | Service Identification Administration |
+---------------------------------------+
+---------------------------------------+
| Service Aware Traffic Steering |
+---------------------------------------+
+---------------------------------------+
| Service Provisioning & Observability |
+---------------------------------------+
-----------------------------------------------------------------------------
Service Analysis and Operation: The increasingly complex and diverse applications and services would be granted with different characteristics and features for outer users. In terms of orchestration for distributed micro-services, Service Analysis and Operation interprets the external and internal forms of overall applications and services as corresponding deconstruction patterns.¶
Deep learning: The overall deep learning process would be decomposed into several successive or related phases and steps, data pre-processing, model training, prediction and estimation, model evaluation based on rewards functions, data storage and API interactions for instance.¶
Live Broadcast: Relevant micro-services MAY include user authentication, live stream administration, live recording, online payment and data migration.¶
The above deconstructed micro services have serial, parallel, unidirectional, and bidirectional relationships, and their interconnection and collaboration are comprehensively presented as user and outer oriented applications.¶
Service Evaluation and Modeling: There are different and various resource requirements raised by multiple services, including but not limited to:¶
Computing resources and network capabilities: Computing-related services MAY be sensitive to computing resources, related indicators include CPU cores, available memories, floating number calculation. On the other hand, large amount of data transmission MAY be implemented between upstream and downstream services. Thus, the network connecting them would have to reserve sufficient bandwidth and provide abilities of low packet loss rate.¶
Constraints for inter-connection patterns: the inter-connection patterns between upstream and downstream services and functions MAY be classified as unidirectional, bidirectional, one-to-one and one-to-many. Furthermore, due to security concerns for instance, relevant services MAY be deployed at adjacent endpoints or a same edge center geographically.¶
---- ----
( -- ) ( -- )
( ( ) )-------------->( ( ) )
( -- ) ( -- )
-------- --------
Notification
---- ----
( -- ) ( -- )
( ( ) )<------------->( ( ) )
( -- ) ( -- )
-------- --------
Request and Response
---- ----
( -- ) ( -- )
( ( ) )-------------> ( ( ) )
( -- ) \ ( -- )
-------- \ --------
\
\ ----
\ ( -- )
--->( ( ) )
( -- )
--------
One-to-Many
+---+
( )
+-- +
( )
( -- -- )
( ( )-->( )--)------->
( -- -- )
( )
+------------+
Successive Services at same Location
Service Orchestration and Scheduling: Service administration would customize strategies or specific algorithms depending on circumstances of infrastructure and required proposals. Providing low-latency experiences or achieving load balance among available instances and resources for instance, SHOULD be selected as specific inclinations for further scheduling.¶
Service Registration and Administration: Based on the results and conclusions analyzed by Service Analysis and Operation, the overall service and included micro services MAY be represented and administered by a series of corresponding identifications. Appropriate identifications would facilitate indicating the service traffic of the workflow in the process of DMSC.¶
----
( -- )
-----------> ( ( ) )
( -- ) Micro Service Chain with DMSC,
-------- \ Service 1(Pre)
Service 1 \ Service 2(Next)
\
\ ---- ----
\ ( -- ) ( -- )
v ( ( ) ) ( ( ) )
( -- )<--------->( -- )
/ -------- --------
/ Service 2 Service 3
/
/
---- / Same Micro Service Chain,
( -- ) / Service 2(Pre)
<----------- ( ( ) )v Service 4(Next)
( -- )
--------
Service 4
Service Discovery and Publication: Depending on existing and mature control plane protocols and interfaces, distributed services and capabilities of infrastructures SHOULD be able to be collected. Relevant schemes include extended protocols, IGP, BGP, BGP-LS, RESTful and Telemetry for instance. The information learned in the control plane MAY include:¶
Computing resources related to services of specific instances.¶
Deployment of service instances or possible and scheduled resources utilization.¶
Network topology information and corresponding TE capabilities.¶
Service Routes Calculation and Generation: Based on the information collected in Service Discovery and Publication, service routes would be calculated to determine appropriate instances and forwarding paths. Service Routes Calculation and Generation SHOULD follow the intentions identified in Service Orchestration and Scheduling. According to Service Registration and Administration, service routes could be distributed and indexed by appropriate service identifications.¶
Service Inter-connection Configuration: Within conventional schemes for services inter-connection, configurations would be disposed for each relevant endpoints distributed in multiple clusters. Istio, for instance, relys APIs including ServiceEntry, VirtualService and DestinationRules to describe inter-connections and relevant principles. Considering the framework discussed above, service routes would be translated into corresponding configurations issued to clusters for configuring and revising API files.¶
Service Identification Administration: Traffic would be able to be steered according to identifications distributed from the control plane. Also, the service identifications which indicate the target in DMSC would inherit and re-generate from the previous ones in the workflow. Proxies, sidecars or gateways SHOULD be able to administer the inheritance and renewal relationship. Suppose an application includes Service 1, 2 and 3, an identifier of {DMSC process and workflow, Service 2} implies that the successive function is expected to be Service 3. Correspondingly, the identifier would be modified as {the identical DMSC process and workflow, (Next) Service 3}.¶
Service Aware Forwarding: Service routes entries would be distributed from the control plane and involved entities and devices would perform traffic forwarding accordingly. Relevant entries include:¶
Service aware forwarding entries for edges routers in which forwarding paths are indexed by specific service and DMSC workflow and process.¶
Service identification administration entries for sidecars, proxies and gateways in which inheritance and correlations in specific DMSC workflows and processes would be specified.¶
Service provisioning and observability: By implementing and performing OAM or APM schemes, forwarding plane would monitor the circumstances and performance of traffic flows in DMSC workflows. With detections of failures and possible degradations, forwarding plane would be able to support recovering, enhancing and provisioning for traffic flows.¶
TBA.¶
TBA.¶
TBA.¶