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, . [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, August 2008, . [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, . [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, . [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, . [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, . [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, . 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]