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, <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>.







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, <https://datatracker.ietf.org/doc/html/draft-li-
             dmsc-architecture-00>.

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, <https://www.rfc-
             editor.org/info/rfc8569>.



































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]