Network Working Group D. Yuan
Internet-Draft D. Huang
Intended status: Standards Track C. Miao
Expires: 9 August 2025 ZTE Corporation
5 February 2025
Technical Considerations for Distributed Micro Services Communication
draft-yuan-dmsc-technical-considerations-01
Abstract
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).
Status of This Memo
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 9 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yuan, et al. Expires 9 August 2025 [Page 1]
Internet-Draft DMSC Technical Considerations February 2025
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.
Table of Contents
1. Micro Service Connection, Communication and Collaboration . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Distributed Micro Service Communication Technical
Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Administration Plane . . . . . . . . . . . . . . . . . . 8
4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Micro Service Connection, Communication and Collaboration
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.
Yuan, et al. Expires 9 August 2025 [Page 2]
Internet-Draft DMSC Technical Considerations February 2025
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 DMSC. Compared to conventional schemes and
patterns, Distributed Micro Service Communication, Collaboration and
Association is granted with multiple features and connotations.
Yuan, et al. Expires 9 August 2025 [Page 3]
Internet-Draft DMSC Technical Considerations February 2025
Ultimate Service or Application
with decomposed distributed micro services or functions
^
| |
| |
+--|--+ +--|--+
+ | + + | +
( | ) ( | )
( v ) ( | )
( +-----+ ) ( +-----+ )
( |Pod 1|-----+ +---->|Pod 4| ) Hyper Edge
( +-----+ ) \ / ( +-----+ ) Clouds
+------------+ \ / +------------+
Cloud/Cluster 1 \ / Cloud/Cluster 3
\ +-----+ /
\ ++-----+) /
->|Pod 2|-+
( +-----+ )
( | ^ )
( v | )
( +-----+ ) Edge
( |Pod 3| ) Clouds
( +-----+ )
+------------+
Cloud/Cluster 2
+-------+
( )
( )
( +----+ ) Central
( |Pods| ) Clouds
( +----+ )
( +----+ +----+ )
( |Pods| |Pods| )
( +----+ +----+ )
+--------------+
Yuan, et al. Expires 9 August 2025 [Page 4]
Internet-Draft DMSC Technical Considerations February 2025
Figure 1: Distributed Micro Service Connection and Communication
across Multi- edges
* 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.
Yuan, et al. Expires 9 August 2025 [Page 5]
Internet-Draft DMSC Technical Considerations February 2025
2. Requirements Language
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.
3. Terminology
* DMSC: Distributed Micro Service Communication.
* SFC: Service Function Chain.
* QoE: Quality of Experience.
* SLA: Service Level Agreement.
* OAM: Operation, Administration and Maintenance.
* APM: Application Performance Management.
4. Distributed Micro Service Communication Technical Considerations
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.
Yuan, et al. Expires 9 August 2025 [Page 6]
Internet-Draft DMSC Technical Considerations February 2025
-----------------------------------------------------------------------------
+----------+ +-----------+ +---------+
| 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 |
+---------------------------------------+
-----------------------------------------------------------------------------
Figure 2: DMSC Technical Considerations within Hierarchical Patterns
Yuan, et al. Expires 9 August 2025 [Page 7]
Internet-Draft DMSC Technical Considerations February 2025
4.1. Administration Plane
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.
Yuan, et al. Expires 9 August 2025 [Page 8]
Internet-Draft DMSC Technical Considerations February 2025
1. Unidirectional Notification
Or
Bidirectional Request and Response
---- ---- ---- ----
( -- ) ( -- ) ( -- ) ( -- )
( ( ) )-------------->( ( ) ) ( ( ) )<------------->( ( ) )
( -- ) ( -- ) ( -- ) ( -- )
-------- -------- -------- --------
2. One-to-one
Or
One-to-many
---- ---- ---- ----
( -- ) ( -- ) ( -- ) ( -- )
( ( ) )-------------->( ( ) ) ( ( ) )-------------> ( ( ) )
( -- ) ( -- ) ( -- ) \ ( -- )
-------- -------- -------- \ --------
\
\ ----
\ ( -- )
--->( ( ) )
( -- )
--------
3. Successive services MUST be deployed adjacently
Or
could be deployed distributedly in multiple clouds/clusters
+---+
( )
+-- +
( )
( -- -- )
( ( )-->( ) )
( -- -- )
( )
+------------+
---- ----
( -- ) ( -- )
( ( ) )-------------->( ( ) )
( -- ) ( -- )
-------- --------
Yuan, et al. Expires 9 August 2025 [Page 9]
Internet-Draft DMSC Technical Considerations February 2025
Figure 3: Inter-Connection Patterns between Services and Functions
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.
4.2. Control Plane
It would be observed in Figure 2 that the components and facilities
would reuse and enhance the current Service Mesh (Istio for instance)
and network infrastructures. It is also relevantly described in
[I-D.li-dmsc-architecture], specific devices would possibly include
existing Kubernetes and Istio APIs, network controllers and enhanced
distributed Service Gateways and Routers. The control plane would be
deployed in distributed, centralized or hybrid patterns.
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.
Yuan, et al. Expires 9 August 2025 [Page 10]
Internet-Draft DMSC Technical Considerations February 2025
Ultimate Service or Application
with decomposed distributed micro services
(Micro Service Chain: Service 1-->Service 2<->Service 3-->Service 4)
(Micro Service Chain with Chain id x)
----
( -- )
-----------> ( ( ) )
( -- ) Micro Service Chain with id x,
-------- \ Service 1(Pre)
Service 1 \ Service 2(Next)
\
\ ---- ----
\ ( -- ) ( -- )
v ( ( ) ) ( ( ) )
( -- )<--------->( -- )
/ -------- --------
/ Service 2 Service 3
/
/
---- / Same Micro Service Chain with id x,
( -- ) / Service 2(Pre)
<----------- ( ( ) )v Service 4(Next)
( -- )
--------
Service 4
Figure 4: Service Administration by Identification
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.
Yuan, et al. Expires 9 August 2025 [Page 11]
Internet-Draft DMSC Technical Considerations February 2025
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.
4.3. Forwarding Plane
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.
Yuan, et al. Expires 9 August 2025 [Page 12]
Internet-Draft DMSC Technical Considerations February 2025
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.
5. Security Considerations
TBA.
6. Acknowledgements
TBA.
7. IANA Considerations
TBA.
8. Normative References
[I-D.huang-rtgwg-us-standalone-sid]
Huang, D., Liang, J., Yang, F., Zhang, Y., and D. Yang,
"Use Cases-Standalone Service ID in Routing Network", Work
in Progress, Internet-Draft, draft-huang-rtgwg-us-
standalone-sid-01, 1 July 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-rtgwg-
us-standalone-sid-01>.
[I-D.li-dmsc-architecture]
Li, X., Wang, A., Wang, W., and D. KUTSCHER, "Distributed
Micro Service Communication architecture based on Content
Semantic", Work in Progress, Internet-Draft, draft-li-
dmsc-architecture-00, 2 January 2025,
<https://datatracker.ietf.org/doc/html/draft-li-dmsc-
architecture-00>.
[I-D.song-dmsc-promblem-and-requirements]
Song, E., Song, Y., Zhang, S., Li, X., and J. Zhao,
"Problem Statements of Service Mesh Infrastructure and
Requirements of DMSC", Work in Progress, Internet-Draft,
draft-song-dmsc-promblem-and-requirements-00, 6 January
2025, <https://datatracker.ietf.org/doc/html/draft-song-
dmsc-promblem-and-requirements-00>.
[I-D.yuan-rtgwg-hfc-framework]
Yuan, D., Zhang, Y., Huang, D., and C. Miao, "Hybrid-
Function-Chain (HFC) Framework", Work in Progress,
Yuan, et al. Expires 9 August 2025 [Page 13]
Internet-Draft DMSC Technical Considerations February 2025
Internet-Draft, draft-yuan-rtgwg-hfc-framework-00, 29
September 2024, <https://datatracker.ietf.org/doc/html/
draft-yuan-rtgwg-hfc-framework-00>.
[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-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Dongyu Yuan
ZTE Corporation
Nanjing
China
Phone: +86 13776623784
Email: yuan.dongyu@zte.com.cn
Daniel Huang
ZTE Corporation
Nanjing
China
Phone: +86 13770311052
Email: huang.guangping@zte.com.cn
Chuanyang Miao
ZTE Corporation
Nanjing
China
Email: miao.chuanyang@zte.com.cn
Yuan, et al. Expires 9 August 2025 [Page 14]