Distributed architecture for microservice communication
draft-li-icnrg-damc-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xueting Li , Aijun Wang , Wei Wang | ||
| Last updated | 2023-07-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-icnrg-damc-00
ICNRG Working Group X. Li
Internet-Draft A. Wang
Intended status: Standards Track W. Wang
Expires: 11 January 2024 China Telecom
10 July 2023
Distributed architecture for microservice communication
draft-li-icnrg-damc-00
Abstract
This draft defines a new communication architecture, called
Distributed Architecture for Microservice Communication (DAMC). It
includes multiple aspects of microservice communication, such as
service registration, service discovery, service routing, service
scheduling, and more , Which to achieve all the essential
functionalities provided by current centralized service networks.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 11 January 2024 [Page 1]
Internet-Draft DAMC July 2023
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. The key process of thedistributed service mesh architecture for
microservice communication . . . . . . . . . . . . . . . 7
5. Key communication message types and functions . . . . . . . . 9
6. Operation process of the distributed architecture for
microservice communication (DAMC) . . . . . . . . . . . . 12
6.1. Control level process . . . . . . . . . . . . . . . . . . 13
6.2. Forwarding level process . . . . . . . . . . . . . . . . 14
6.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
In recent years, the rapid adoption of microservices architecture has
revolutionized the development and deployment of complex software
systems. However, as the number of microservices grows and the
communication between them becomes more intricate, traditional
centralized service-oriented network architectures face challenges in
meeting the demands of large-scale and distributed microservice
deployments. To address these challenges, the concept of
Information-Centric Networking (ICN)[RFC8763] has emerged as a
promising paradigm that focuses on the content itself rather than the
location of the services.
In current microservice communication scenario shown in Figure 1.
The essential functionalities for microservice communication,
including service registration, service discovery, service
scheduling, and service measurement, are typically implemented
through the deployment of proxies within a shared addressable unit
known as a Pod alongside microservices. The interconnection between
these proxies forms a new foundational communication infrastructure
known as a service mesh.
Li, et al. Expires 11 January 2024 [Page 2]
Internet-Draft DAMC July 2023
All communication between microservices at the forwarding level is
facilitated through these proxies.
1) Service registration
Microservices register with their corresponding proxies, which in
turn register with the centralized control center.
2) Service discovery
The centralized control center distributes relevant service
registration information to each proxy, enabling the synchronization
of microservice information.
3) Service measurement
Proxies proactively conduct quality probing towards target
microservices and report relevant information to the control center.
4) Service scheduling
The centralized control center distributes relevant service
scheduling policies to each proxy. Each proxy analyzes the received
microservice communication demands and performs scheduling based on
the policies and the communication requirements of the microservices.
Li, et al. Expires 11 January 2024 [Page 3]
Internet-Draft DAMC July 2023
+-------------------------------------------------------------------------+
| |
| +-------------------------------------------------------+ |
| | | |
| | +---------------+ +---------------+ | |
| | | +---------+ | | +---------+ | | |
| | Data | |Service A| | | |Service B| | | |
| | Plane| +---------+ | Mesh traffic| +---------+ | | |
| ---------> | | | |-----------> | | | |---------> |
|Ingress| | +---------+ | | +---------+ | | Egress |
|traffic| | | Proxy | | | | Proxy | | | traffic |
| | | +---------+ | | +---------+ | | |
| | +---------------+ +---------------+ | |
| | | Discovery | | |
| | | Configuration | | |
| | |_________Certificates_______| | |
| | | | |
| | | | |
| | Control Plane | | |
| | +----------------------------+ | |
| | | Controller | | |
| | +----------------------------+ | |
| | | |
| +-------------------------------------------------------+ |
| |
+-------------------------------------------------------------------------+
Figure 1 The architecture of current centralized service-based network
However, centralized service-oriented network architectures face
challenges in meeting the communication demands of large-scale and
complex microservice deployments. They encounter bottlenecks in
terms of performance, scalability, and reliability.
1) Performance bottlenecks
In centralized architectures, the central control point becomes a
potential performance bottleneck as it handles all communication
traffic. Routing traffic through a central controller introduces
increased latency, which can adversely affect the overall system
performance. As the number of microservices and communication volume
grow, the centralized control point may face challenges in
efficiently managing the increasing traffic load.
2) Poor scalability
Li, et al. Expires 11 January 2024 [Page 4]
Internet-Draft DAMC July 2023
Scaling a central control point becomes increasingly complex as the
system grows, as it requires substantial resources and careful
management. Consequently, the centralized approach may struggle to
handle the dynamic nature of microservices and their evolving
communication patterns.
3) Reliability issues
If the central control component experiences downtime or
malfunctions, it can disrupt the entire communication flow among
microservices. This vulnerability can result in service disruptions
and decreased availability of the system as a whole.
This draft defines a new distributed architecture, called Distributed
Architecture for Microservices Communication (DAMC). The overall
architecture of this distributed microservice communication shown in
Figure 2. It primarily consists of three types of devices shown in
Figure 2: Service Gateway (SG), Service Router (SR), and Service
Prefix Authentication (SPA) entities,along with a centrally deployed
Service Mesh Communication Scheduling Center (SCSC), organized by
domain. By incorporating the ICN concept [RFC7927] into the
architecture, the DAMC architecture aims to overcome the limitations
of the traditional Microservices centralized communication method.
It uses content-based addressing [RFC8793] and service prefix [NDN]
to uniquely identify and locate Microservices, so as to achieve
efficient and flexible communication. Service gateway (SG) plays a
vital role in service registration, discovery, routing and quality
control, while service router promotes the optimal forwarding of
communication traffic between Microservices. The service prefix
authentication (SPA) entity ensures the legitimacy and authorization
of the service prefix declared by the Microservices, and enhances the
security in the distributed Microservices environment. In addition,
the service mesh communication scheduling center (SCSC) provides
effective coordination and allocation of customized forwarding
policies between the service gateway and service router (SR) based on
the quality detection results reported by SG. This enables
intelligent routing decisions to ensure that communication traffic is
directed to the most capable and efficient Microservices node.
Li, et al. Expires 11 January 2024 [Page 5]
Internet-Draft DAMC July 2023
+-----------------------------------------------------------------------+
| +---------------+ |
| | SCSC | |
| +---------------+ |
| service | service |
| +----+ +----+ +----+ | +----+ +----+ +----+ |
| | A/1| | B/1| | ...| | |... | | ...| | ...| |
| +----+ +----+ +----+ | +----+ +----+ +----+ |
| \ | / | \ | / |
| +----+ +---------+ |_______ +---------+ +----+ |
| |SPA |-------| SG-1 |_______/|_ | SG-2 |-------|SPA | |
| +----+ +---------+ / | \ +---------+ +----+ |
| \ _______|________ / |
| \ | / \ | / |
| +--- +--- |
| / SR \ --------- / SR \ |
| ---+ ---+ |
| | \ +--- / | |
| | / SR \ | |
| | ---+ | |
| | / \ | |
| +----+ +---------+ +---------+ +----+ |
| |SPA |-------| SG-3 | | SG-4 |-------|SPA | |
| +----+ +---------+ +---------+ +----+ |
| / | \ / | \ |
| +----+ +----+ +----+ +----+ +----+ +----+ |
| |... | |... | | ...| | A/4| | B/4| | ...| |
| +----+ +----+ +----+ +----+ +----+ +----+ |
| service service |
+-----------------------------------------------------------------------+
Figure 2 The overall distributed architecture for microservice communication
In a word, the purpose of DAMC is to combine the ICN concept to
enhance the overall performance, scalability and reliability of
Microservices communication. The DAMC architecture provides a
powerful framework for managing the complex communication
requirements of distributed Microservices, ensuring integrity,
security and efficient resource utilization.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
Li, et al. Expires 11 January 2024 [Page 6]
Internet-Draft DAMC July 2023
3. Terminology
The following terms are defined in this draft:
* DAMC: a distributed architecture for microservice communication
defined in this draft.
* SG: Service Gateway, it is an important component in the DAMC
architecture. It is located between the Pod of Microservices and
the entire communication architecture, and is responsible for
handling the communication and coordination between Microservices.
* SPA: Service Prefixes Authentication, it is a key component in the
DAMC architecture, which is used to verify the validity and
validity of the service prefix declared by the Pod to which the
Microservices belongs.
* SR: Service Route, it is a network device or component that is
responsible for managing and processing the routing and forwarding
of communication traffic between Microservices.
* SCSC: Service Mesh Communication Scheduling Center，it is a
key component in the DAMC architecture responsible for
coordinating and managing the communication within the service
mesh.
* ICN: Information-Centric Networking, defined in [RFC7927]
* FIB: Forwarding Information Base, defined in [RFC9344]
* RIB: Routing Information Base, defined in [RFC9344]
* LSDB: the link state database to form a routing information base
and a forwarding information base.
4. The key process of thedistributed service mesh architecture for
microservice communication
The key process of the distributed service mesh architecture defined
in this draft is as follows:
1) A plurality of Microservices co address Pod send the first
signaling to the service gateway (SG), and the first signaling is
used to notify the service gateway linked to each of the pods of the
service identification information owned by the Pod. The service
identification information is the service prefix or namespace of the
pod.
Li, et al. Expires 11 January 2024 [Page 7]
Internet-Draft DAMC July 2023
2) The Service Gateway (SG) sends an authentication request to the
Service Prefix Authentication entity (SPA) through the third
signaling, which is used to authenticate whether the service
identification information requested by the Pod is legal. If
authentication fails, the service prefix authentication (SPA) entity
sends an authentication failure notification to the service gateway
(SG). If the authentication is passed, perform the operation of
sending the second signaling signal from the service gateway (SG) to
the service router (SR).
3)Acting as the default gateway for the Pod hosting the Service, the
Service Gateway (SG) absorbs and forwards all Service traffic emitted
from that Service Pod.
3) After the service prefix authentication (SPA) authentication is
passed, the service gateway sends the second signaling to the service
router, which is used to notify the topology link relationship and
service identification information under various interfaces of the
service gateway linked to the Pod to the service router.
4) The Service Gateway and Service Router (SR) exchange information
about the Service Prefixes they can reach and the interconnectivity
topology. Based on the preset algorithm and the topological link
relationship，each service gateway and each service router obtain a
forwarding information base (FIB) that based on the service
identification information, forwarding communication packets
according to the forwarding information base (FIB).
5) Each service gateway initiates a detection task to each target
Microservices, so that each target Microservices can detect according
to the detection task, and report the detection result to the
corresponding service gateway. Each service gateway receives the
detection results reported by the target Microservices, and reports
the detection results to the service mesh centralized scheduling
center. The Service Gateway and Service Router perform traffic
forwarding based on Service Prefixes and the service policies
distributed by the Service Mesh Scheduling Center.
DAMC, a distributed architecture for microservices communication,
addresses the intricate communication demands among microservices in
the future, while encompassing all the critical functionalities
offered by existing centralized service networks.
Li, et al. Expires 11 January 2024 [Page 8]
Internet-Draft DAMC July 2023
5. Key communication message types and functions
In this draft, we defines a new distributed architecture for
microservice communication. It encompasses all the critical
functionalities offered by existing centralized service networks. In
the distributed architecture for microservice communication (DAMC),
we also define multiple communication entities and clearly define
their control signaling message types and functions. These
communicating entities play a key role in the architecture, ensuring
efficient communication between microservices. The distributed
microservice communication architecture DAMC includes the following
communication entities:
* Pod/Service Gateway (SG)
* Service Gateway (SG)/Service Prefixes Authentication (SPA)
* Service Gateway (SG)/Service Route (SR)
* Service Gateway (SG)/SR and Service Mesh Communication Scheduling
Center (SCSC)
The types and functions of control signaling messages required for
communication between entities are shown in Figure 3.
+----------------------------------------------------------------------+
| |Communication |Control Signaling| Control Signaling |
|Num | Entities | Message Types | Function |
+----------------------------------------------------------------------+
| | |Service Prefixes | Microservices within each Pod |
| 1 | Pod/SG | (Name Space) | communicate their used Service |
| | | Announcement | Prefix (Namespace) to the SG. |
+----------------------------------------------------------------------+
| | SG/SPA | Service |The SG authenticates to the SPA |
| 2 | | Prefixes | requested by the Pod is legal. |
+----------------------------------------------------------------------+
| | |Service Prefixes | SG and SR advertise the Servic |
| 3 | SG/ SR | LSA | Prefix and topology link |
| | | | relationship they can reach. |
+----------------------------------------------------------------------+
| 4 |SG /SR |Service QoS |Communication quality |
| |and SCSC |Telemetry/Service| reporting policies |
| | | QoS Policy | between microservices. |
+----------------------------------------------------------------------+
Figure 4 Key communication message types and functions of DAMC
Li, et al. Expires 11 January 2024 [Page 9]
Internet-Draft DAMC July 2023
Based on this architecture, the key functions required for
communication between microservices are implemented as follows:
1) Service registration
Multiple Microservices co address Pods send the Service
identification information to the Service Gateway (SG).The service
identification information is the Service Prefix or Namespace owned
by the pod. The Service Gateway facilitates proxy registration by
utilizing Service Prefix Announcements. This approach allows the
Service Gateway to announce the Service Prefixes it can reach, along
with relevant information, enabling other components or services to
become aware of and register with the appropriate Service Prefix.
2) Service discovery
The Microservices information is authenticated to the service prefix
authentication (SPA) through the service gateway (SG). After the
successful authentication through the service prefix authentication
(SPA), the synchronous distribution of Microservices information is
realized between the Service Gateway (SG) and the service router (SR)
through the distributed protocol. In this process, the Service
Gateway (SG) acts as the central point of authentication to achieve
secure and reliable communication between Microservices. The service
router (SR) plays a crucial role in facilitating the distribution of
these verified Microservices information, so as to achieve efficient
routing and seamless interaction between Microservices. In this
architecture, Service Prefix Authentication (SPA), Service Gateway
(SG) and Service Router (SR) jointly establish a powerful and
synchronized ecosystem, complete the work of agents in the
traditional service mesh architecture, and ensure the integrity and
consistency of Microservices communication in the distributed service
mesh.
3) Service measurement
The service gateway (SG) detects the target Microservices regularly
and automatically according to the demand. The purpose of these
probes is to collect information and evaluate the health and
availability of the target Microservices. The service gateway (SG)
records the detection results and reports them to the Service Mesh
Communication Scheduling Center (SCSC). If the detection result does
not meet the preset conditions, the service mesh centralized
scheduling center generates forwarding policies based on the
detection result, and issues the forwarding policies to the service
gateway and service router corresponding to the paths of each target
Microservices. The detection results do not meet the preset
conditions, including at least one of the following:
Li, et al. Expires 11 January 2024 [Page 10]
Internet-Draft DAMC July 2023
* The bandwidth of the corresponding path of the target
Microservices is less than or equal to the preset bandwidth
threshold.
* The delay of the corresponding path of the target Microservices is
greater than or equal to the preset delay threshold.
* The jitter of the corresponding path of the target Microservices
is greater than or equal to the preset jitter threshold.
By actively and regularly detecting the target Microservices, the
service gateway (SG) ensures the latest and accurate assessment of
its status. This proactive approach can identify any potential
problems or exceptions, so that timely actions can be taken to ensure
the overall reliability and performance of Microservices.
4) Service scheduling
The Service Mesh Communication Scheduling Center (SCSC) utilizes the
quality detection results reported by various service gateways (SG)
to distribute customized forwarding policies to service gateways (SG)
and service routers (SR) on the communication path. These forwarding
policies aim to select the optimal service node from the
Microservices pool that provides the same function. By distributing
these customized forwarding policies throughout the entire service
mesh, the system can intelligently route traffic to the most capable
and efficient service node. This ensures that requests are directed
to Microservices that exhibit excellent performance, responsiveness,
and overall quality. The Service Mesh Communication Scheduling
Center (SCSC) plays a crucial role in coordinating the distribution
of these customized forwarding policies, ensuring effective
utilization of available resources by the network and optimizing
overall system performance. By making wise decisions based on the
quality detection results, the scheduling center enables the service
mesh to dynamically adjust and guide traffic to the most appropriate
Microservices, enhance the overall user experience, and maximize the
utilization of available resources.
In conclusion, the distributed architecture for microservice
communication defined in this draft depends on various components,
such as service gateway (SG), service router (SR) and Communication
Scheduling Center. It realizes efficient and reliable communication
between Microservices by using service prefix registration, service
prefix authentication, quality detection and customized forwarding
policies. This architecture overcomes the limitations of traditional
centralized methods and provides improved performance, scalability,
and reliability. By using these components and mechanisms, the
system can effectively manage the complex communication requirements
Li, et al. Expires 11 January 2024 [Page 11]
Internet-Draft DAMC July 2023
of large-scale Microservices deployment, and ensure the optimal
routing of traffic, thus enhancing the overall system performance and
user experience.
6. Operation process of the distributed architecture for microservice
communication (DAMC)
The distributed architecture for microservices communication consists
of the multiple Pods, multiple service gateways, multiple service
routers, one Pod linked to one service gateway. The communication
process of DAMC is jointly completed by the control plane and the
forwarding plane. In the control plane, each component is
responsible for managing and controlling the policy, routing and
security of Microservices communication, while the forwarding plane
is responsible for the actual packet forwarding and traffic
management.
The communication process starts from the control plane, where
various components such as service gateway, service prefix
authentication, and service router interact through defined signaling
types. For example, the service gateway can send an authentication
request to the service prefix authentication to verify whether the
Microservices has a legal service prefix. These signaling messages
are transmitted in the control plane to ensure Microservices
authentication, topology information collection and routing policy
distribution.
The communication process starts from the control plane, where
various components such as service gateway, service prefix
authentication, and service router interact through defined signaling
types. For example, the service gateway can send an authentication
request to the service prefix authentication to verify whether the
Microservices has a legal service prefix. These signaling messages
are transmitted in the control plane to ensure Microservices
authentication, topology information collection and routing policy
distribution. In the control plane, the service gateway and the
service router use the collected information to build a link state
database (LSDB) and run routing algorithms (such as Dijkstra
algorithm) to generate a routing information base (RIB) and a
Forwarding information base (FIB) based on the service prefix. These
information bases contain rules and policies on connection between
Microservices and packet forwarding.
Once the components in the control plane complete coordination and
decision-making, the forwarding plane begins to take effect. When a
packet arrives at the service gateway, it selects the best path and
the next hop according to the rules in the routing information base
(RIB) and the Forwarding information base (FIB) to forward the packet
Li, et al. Expires 11 January 2024 [Page 12]
Internet-Draft DAMC July 2023
to the target Microservices. In this way, the service gateway and
service router can work together to forward data packets along the
optimal path, ensuring efficient transmission and correct routing of
traffic.
6.1. Control level process
1) Service A located within Pod uses the defined class 1 signaling,
Service Prefixes (Name Space) Announcement, to notify the connected
Service Gateway (SG) of its service prefix or namespace. By adopting
this service prefix naming convention, each Microservice can
establish its unique identity.
2) When the Service Gateway (SG-1) receives a service prefix
notification, it initiates the verification process by sending an
authentication request to the Service Prefix Authentication (SPA)
unit using a defined signaling type (referred to as Class 2
signaling). The purpose of this authentication request is to verify
and confirm that Pod indeed has the specified service prefix. By
participating in this authentication process, the service gateway
ensures that only legitimate Pods with authorized service prefixes
are granted access to the network. This robust authentication
mechanism adds an additional layer of security and integrity to
communication in the service mesh environment.
3) When the service gateway (SG-1) completes the authentication of
the service prefix, it will use Class 3 signaling to communicate with
its connected service router (SR) to announce topology relationships
and service prefixes under each interface. By using this specific
signaling type, the Service Gateway (SG) transmits information about
the entire service mesh topology to the service router, including the
connection relationship between the service gateway and the service
router, as well as the service prefix associated with each interface.
This notification process ensures that various components in the
service mesh can accurately understand the topological relationships
between each other, providing an important foundation for subsequent
traffic forwarding and service routing. In this way, the service
gateway and service router can work together to achieve intelligent
traffic management and routing decisions, thus providing efficient
and reliable Microservices communication.
Li, et al. Expires 11 January 2024 [Page 13]
Internet-Draft DAMC July 2023
4) Other Microservices and service gateways will also adopt a similar
process for notification. They will communicate with the Service
Gateway (SG) and Service Router (SR) using the corresponding
signaling types to inform them of their service prefix information
and topology relationships. Through this notification process,
various components in the entire service grid can understand each
other's existence and functionality, and establish a consistent
communication foundation.
5) After the Service Gateway (SG) receives Service Prefix LSA from
other components, a Link State Database (LSDB) is generated between
the Service Gateway and the Service Router based on the service
identification information and the topological link relationship.
Then, the service gateway and service router will run Dijkstra
algorithm to process the data in the link state database （LSDB） to
form a routing information base (RIB) and a Forwarding information
base (FIB) based on the the service identification information. RIB
and FIB will be used to guide traffic forwarding and routing
decisions, ensuring that each service node can receive and forward
traffic according to the optimal path.
6.2. Forwarding level process
1) In the Microservices architecture, when the communication between
Microservices Service A/1 and Service B/4 needs to be realized,
Service A/1 usually sends the communication message actively. The
communication message will clearly specify the target service as
Service B/4 to ensure that the data packet can be accurately
delivered to the target Microservices. When Service A/1 sends a
communication message, it will package the relevant data and
information into a message based on the pre-defined communication
protocol and format. This message will contain the identification of
the target service, namely Service B/4, to ensure that the data can
be accurately routed to the target Microservices.
Li, et al. Expires 11 January 2024 [Page 14]
Internet-Draft DAMC July 2023
2) When the communication message is sent by Microservices Service
A/1, it will be sent to the default service gateway (SG-1). The
service gateway (SG-1) is a key component in the Microservices
architecture, which is responsible for managing and controlling
communication traffic. After receiving the communication message,
the service gateway (SG-1) will forward the message level by level
according to the Forwarding information base (FIB) table formed by
the interaction of the control layer. It will check the forwarding
rules and routing information in the FIB table to determine the next
destination. By searching the FIB table, the service gateway (SG-1)
can determine which next hop service gateway communication packets
should be forwarded to. It will forward the packet to the next
service gateway until it reaches the service gateway (SG-4) where the
destination service is located.
3) When the service gateway (SG-4) receives a communication message,
it will pass the message to the Podcast where the destination service
is located based on the Podcast information specified in the message.
When backhaul traffic is generated, a similar process is also used.
The service gateway (SG-4) forwards the backhaul traffic according to
the forwarding rules in the FIB table, through step-by-step
forwarding between service gateways, until it reaches the Podcast
where the source service is located.
6.3. Conclusion
Through the above communication process, the distributed architecture
for microservice communication realizes effective cooperation between
the control plane and the forwarding plane. The control plane is
responsible for managing and controlling the strategy and routing of
Microservices communication, while the forwarding plane is
responsible for actual packet forwarding and traffic management.
This layered architecture enables the system to flexibly adapt to
changing communication needs and provide reliable communication
services.
7. IANA Considerations
8. Acknowledgement
9. Normative References
[NDN] "Named Data Networking", September 2010.
Li, et al. Expires 11 January 2024 [Page 15]
Internet-Draft DAMC July 2023
[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>.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292,
August 2008, <https://www.rfc-editor.org/info/rfc5292>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April
2020, <https://www.rfc-editor.org/info/rfc8763>.
[RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
[RFC9236] Hong, J., You, T., and V. Kafle, "Architectural
Considerations of Information-Centric Networking (ICN)
Using a Name Resolution Service", RFC 9236,
DOI 10.17487/RFC9236, April 2022,
<https://www.rfc-editor.org/info/rfc9236>.
[RFC9344] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric
Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023,
<https://www.rfc-editor.org/info/rfc9344>.
Authors' Addresses
Xueting Li
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: lixt2@qq.com
Li, et al. Expires 11 January 2024 [Page 16]
Internet-Draft DAMC July 2023
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Wei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: weiwang94@foxmail.com
Li, et al. Expires 11 January 2024 [Page 17]