DMSC Working Group C. Lin Internet Draft New H3C Technologies Intended status: Standards Track W. Wang Expires: August 21, 2025 X.Li China Telecom January 27, 2025 Architecture of Content-Based Service Router draft-lin-dmsc-content-based-service-router-00 Abstract This document first describes an architecture of Content-based Service Router (CSR), which is used to exchange service prefixes and topology information based on distributed routing protocol, and optimize routing based on service prefixes and topology, as one important component of Distributed Micro Service Communication (DMSC) architecture. 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 August 21, 2025. Copyright Notice 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 (http://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 Lin, et al. Expire August 21, 2025 [Page 1] Internet-Draft Content-Based Service Router January 2025 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 1.1. Requirements Language.....................................3 2. CSR Architecture Overview......................................4 3. Control Architecture for CSR...................................5 4. Data Architecture for CSR......................................6 5. Security Considerations........................................7 6. IANA Considerations............................................7 7. Summary........................................................7 8. References.....................................................7 8.1. Normative References......................................7 8.2. Informative References....................................8 Author's Address..................................................9 1. Introduction With the continuous emergence of various applications, Micro- services, as small and independent application segments, are becoming increasingly dense, making communication between Micro- services increasingly important. A Service Mesh serves as a dedicated infrastructure for handling communication between Micro-services, providing functions such as Traffic Management and Secure Communication. The Service Mesh has evolved from general communication middleware functions, starting from monolithic Micro-services, evolving into integrated middleware, and finally developing into a sidecar pattern. However, the service network presents some challenging issues, as follows: * Increased complexity: Implementing and deploying a Service Mesh requires adding additional components to the current application, significantly increasing the difficulty of mastering the Service Mesh. * The performance overhead increases: The sidecar pattern requires deployment within the same Pod as the Micro-service, resulting in a tightly coupled mode in terms of resource usage, which significantly affects tenant resource usage efficiency. * Maturity and acceptance are low: Although there have been several deployments of Service Mesh, it is still far from mature compared to traditional networks and related solutions. Lin, et al. Expires August 21, 2025 [Page 2] Internet-Draft Content-Based Service Router January 2025 To address the challenging issues of Service Meshes, a content- centric Micro-service communication architecture, called the Distributed Micro Service Communication (DMSC) architecture [I-D.li- dmsc-architecture], is proposed to enhance the efficiency and reliability of communication between Micro-services. DMSC has the following characteristics: * Content-centered: Focus on content and services, not on business location. * Decentralization: Registration, routing, and storage of content and services using distributed processing. * Dynamic Resource Allocation: Optimization of resource allocation to enhance network efficiency. * Scalability and flexibility: meets the needs of continuous network evolution and supports large-scale deployments comparable to current operator networks. The DMSC architecture consists of four key parts: the Service Gateway (SG), the Service Router (SR), the Service Prefix Authentication (SPA) system, and the Service Mesh Communication Scheduling Center (SCSC) system [I-D.li-dmsc-architecture]. The SG is used for flexible adaptation of communication between various existing Micro-services. SRs are used to optimize routing based on service prefixes and topology, and to exchange service prefix and topology information based on distributed routing protocols. The SPA system is used to authenticate distributed service prefixes. The SCSC system provides auxiliary centralized optimization scheduling for Micro-service routing. The SR holds a very important core position in the DMSC architecture. It serves as the main switching component for achieving routing reachability in distributed Micro-services, aiding in the large-scale deployment of Micro-service communication. Therefore, to implement the SR in the DMSC architecture, this document provides the first description of the structure of a Content-based Service Router (CSR). 1.1. 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. Lin, et al. Expires August 21, 2025 [Page 3] Internet-Draft Content-Based Service Router January 2025 2. CSR Architecture Overview The CSR architecture is similar to the traditional router architecture, with the only difference being that traditional routers use address prefixes as routing and forwarding information, while CSR use content (name) prefixes as routing and forwarding information. The address prefix is a fixed-length IPv4 or IPv6 address, while the name prefix is a variable-length character string [RFC8569]. As Micro-services continue to increase, service names may become longer, which also causes the name prefixes in a request message to lengthen, thus increasing the package load. To reduce the package load, name prefixes may need to be compacted or optimized, and the method of compaction or optimization is beyond the scope of this document. For the implementation of the CSR, the most significant challenge is how to efficiently match the compressed or optimized name prefixes in the request message with the forwarding information base (FIB) for transmission through the network to a system that can issue a response. How to compact or optimize name prefix also is beyond the scope of this document. The hierarchy of a name is used for routing via the longest matching prefix in a CSR of Content-Centric Networking. The longest matching prefix is computed name segment by name segment in the hierarchical name, where each name segment must be exactly equal to match. For traditional routers based on IP addresses, the longest match prefix is performed by applying a bitwise AND operation between the destination IP address and the subnet mask in the forwarding table. The result is then compared with the network address of the forwarding entry. If they match, it is a match; otherwise, it is not a match. So, if the name prefix is long, calculating the longest match for the name prefix will be more complex than for the address prefix. How to efficiently execute the longest match of name prefix also is beyond the scope of this document. Like traditional routers, The CSR architecture SHOULD be divided into the Control Plane and Data Plane, as shown in Figure 1. The Control Plane primarily exchanges Service Prefixes and topology information with Service Gateways (SG) or service routers (SR) through routing protocols, generates service routes, and delivers them to the Data Plane. The Data Plane mainly receives packets of interest and performs look-up forwarding based on the Service Prefix (Interest Name) carried in the data packet. The CSR may optionally include a Service Plane, which can be used to access online services and provide service response. The Service Plane also needs to send the service prefix to the Control Plane for publishing. The Service Lin, et al. Expires August 21, 2025 [Page 4] Internet-Draft Content-Based Service Router January 2025 Plane is not a necessary function component of CSR, and its architecture is not described in this document. +---------------------------------+ |CSR (Optional) | | +---------+ +---------+ | | | Service | | Control | | Online---+--->| Plane +-->+ Plane |<---+---->Service Prefix Services | +-----+---+ +---+-----+ | (Interest Name) | /\ /\ | | \ /Service | | \ / Route | | \/ \/ | | +------+-------+----+ | Interest--+----->| Data Plane |------+----->Interest Request | +-------------------+ | Request +---------------------------------+ Figure 1: The CSR architecture 3. Control Architecture for CSR This section describes the Control Plane architecture of CSR. The Control Plane primarily includes Routing Protocols and Route Management, as shown in Figure 2. Routing Protocols SHOULD be used for exchanging Service Prefixes and topology information, divided into Static Routing Protocol and Dynamic Routing Protocol. How to exchange Service Prefixes and topology information through routing protocols is beyond the scope of this document. Route Management SHOULD be used to collect, integrate, and optimize Service Routing Information from Routing Protocols and distribute effective Service Routing Information to the Data Plane. +------------------------------------+ | Control Plane | | +----------------------+ | | | Routing Protocol | | | | +--------+---------+ | | | | | | | | | | | | Static | Dynamic |<+------+---->Service Prefix | | +--------+---------+ | | (Interest Name) | +---------+------------+ | | | | | |Service Route | | | | Lin, et al. Expires August 21, 2025 [Page 5] Internet-Draft Content-Based Service Router January 2025 | \/ | | +---------+------------+ | | | Routing Management | | | +---------+------------+ | | | | | /To Data Plane | +---------------\/-------------------+ Figure 2: The Control Plane architecture 4. Data Architecture for CSR This section describes the Data Plane architecture of CSR, which mainly includes the Data Flow Table (DFT), Forwarding Strategy (FS), and Forwarding Information Base (FIB), as shown in Figure 3. The DFT SHOULD be used to maintain traffic stickiness, ensuring the output orientation remains consistent when the source and destination information are the same. The DFT also records and monitors the forwarding information of data packets, which is very useful for locating communication anomalies. The DFT SHOULD consist of the source service name, destination service name, and output interface information. The FS SHOULD be used to meet special forwarding needs, having higher precedence than the FIB. The FS can specify the forwarding of data packages based on the configured output orientation when matching the source service name or destination service name. The FIB SHOULD be used for regular guidance in forwarding data packages, mainly consisting of service names (prefixes) and output interfaces (next hops). /\ |Discarding +----------------+-------------------------+ | Data Plane |Not Match | | +---------+-----------+Match | | | FIB +---->+ | | +---------+-----------+ | | | /\ | | | |Not Match | | | +---------+-----------+Match| | | | Forwarding Strategy +---->+------>+-->Forwarding | +---------+-----------+ | | | /\ | | | |Not Match \/ | | +---------+-----------------+-+ | Lin, et al. Expires August 21, 2025 [Page 6] Internet-Draft Content-Based Service Router January 2025 | | |Match| Interest--|----->+ Data Flow Table +---->|-->Forwarding Request | | | | +------------------------------------------+ Figure 3: The Data Plane architecture Upon receiving an Interest Data Request, first check the DFT. If there's a match, forward directly. If not, send the data to check the FS. If it matches a FS, generate flow table information to DFT and forward. If there is no match with a FS, send the data to check the FIB. If it matches the FIB, generate flow table information to DFT, and forward. If there's no match in the FIB, discard it. 5. Security Considerations Security issues are not discussed in this document. 6. IANA Considerations TBD. 7. Summary The basic architecture of a content-based service router is described. The operation principles of the control plane and data plane of the service router are explained. Further investigation and discussion SHALL be necessary to execute the design of control protocols which MAY depend on the requirements by users. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Lin, et al. Expires August 21, 2025 [Page 7] Internet-Draft Content-Based Service Router January 2025 [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, . 8.2. Informative References [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, . Lin, et al. Expires August 21, 2025 [Page 8] Internet-Draft Content-Based Service Router January 2025 Author's Address Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Wei Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: weiwang94@foxmail.com Xueting Li China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: lixt2@foxmail.com Lin, et al. Expires August 21, 2025 [Page 9]