| Internet-Draft | CATS Service Announcement Methods | November 2024 |
| Gao, et al. | Expires 7 May 2025 | [Page] |
This document introduces network-layer service announcement solutions based on architecture defined in [I-D.ldbc-cats-framework]. In particular, the scheme describes how to disseminate computing service information to clients and the control plane through service announcement messages. This draft also proposes to classify the attributes used to describe computing services and analyzes several service querying mechanisms.¶
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 7 May 2025.¶
Copyright (c) 2024 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 (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.¶
As described in [draft-ietf-cats-framework-02], steering in CATS aims to select the suitable service contact instance(s) from a set of candidates. Particularly, the CATS architecture gives the exemplifications of the service announcement workflow for distributed design. However, the CATS framework does not provide the detailed description of the specific process of service announcement. Additionally, the application-layer DNS solutions for name resolution in CATS face challenges in adapting to high-frequency dynamic resolution and result in significant signaling overhead.¶
This document proposes network-layer service announcement solutions for CATS based on identifier resolution and mapping, and classifies the attributes used to describe computing services. Several service querying mechanisms are further analyzed based on the proposed solutions.¶
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.¶
This document makes use of the terms defined in [draft-ietf-cats-framework-04]. In addition, the following terms are defined below:¶
Computing service Attributes (CSA): Attributes that multi-dimensionally describe the computing service.¶
Computing service Demand Attributes (CSDA): Attributes that describe the computing resources and network resources requirements of the computing service.¶
Computing service Information Attributes (CSIA): Attributes that detail the nature of the computing service and the methods of its provision.¶
The service announcement using the DNS mechanism involves the following two phases:¶
Phase 1: When a computing service is instantiated at the service site, it sends a registration message to the domain name server, which includes the computing service's CS-ID and the network identifier of the service site.¶
Phase 2: When a user requests a computing service, the CS-ID is sent to the domain name server for hierarchical querying to obtain the network identifier of the service site for communication.¶
However, using the DNS mechanism for service announcements faces several challenges:¶
The DNS mechanism is not designed for high-frequency resolution. When the client first requests a computing service with CS-ID, the mapping result is typically recorded and is used for subsequent requests until the cache expires. Due to the dynamic nature of computing resources at service sites, if the client continues to request the same site based on a cached copy, the site or its connecting links may be occupied, making it suboptimal for providing the CS-ID specified computing service.¶
DNS service is normally at the application layer (Layer 7), and the signaling flow between the service site and the DNS server would introduce additional overhead. In CATS, a service site can provide multiple computing services and a single computing service could be accessed through multiple service sites. The resources occupied by one computing service at the service site may also affect the availability of other computing services. Thus, multiple edge sites need to frequently announce the services they provide and their availability to the DNS server, leading to network resource consumption.¶
The resources of DNS servers are limited. Besides responding to client mapping requests, frequent interactions with service sites will consume a considerable amount of resources. Moreover, updating and checking the information database at a high refresh rate can potentially overload the servers.¶
As illustrated in Figure 1, a computing service is identified by a unique CS-ID and instantiated through multiple edge service sites to enable client access. CATS functional components are deployed at the ingress CATS-Forwarder and egress CATS-Forwarder, where the C-SMA is tasked with gathering the status of the service sites and service instances, and interfacing with the control plane. The control plane utilizes this information to perform service scheduling. When a user node connects to the network, to protect the privacy of users, the scheme employs a hashing algorithm to generate unique anonymous identity identifiers for each user during the registration process.¶
+---------+ |
| Client | |
+----+----+ |
| |
| |
+--------+--------+ |
| CATS-Forwarder 1| |
|--------+--------| |
| C-NMA | |
+--------+--------+ |
| | +---------+
+--+----------+--------------+--+ | | Control |
| Underlay | | | Plane |
| Infrastructure | | +---------+
+--+-------------+-----------+--+ |
| | |
+--------+--------+ +--------+--------+ |
| CATS-Forwarder 2| | CATS-Forwarder 3| |
|--------+--------| |--------+--------| |
| C-SMA | | C-SMA | |
+--------+--------+ +--------+--------+ |
| | |
| | |
+------+-----+ +----+------+ |
+------------+ | +------------+ | |
| Service | | | Service | | |
| Contact | | | Contact | | |
| Instance |-+ | Instance |-+ |
+------------+ +------------+ |
Service site 1 Service site 2
The service announcement process is established between the ingress forwarder, the egress forwarder, and the control plane. After a computing service is instantiated on a specific service site, the brief service information and the service deployment status need to be reported. The Service Contact Instance then updates it to the connected egress CATS-Forwarders ("CATS-Forwarder 2/3"). And the status is collected by C-SMAs and uploaded to the controllers. When receiving the information of a new type of computing service, the control plane is responsible for generating the CS-ID and sending it to the egress CATS-Forwarder, which subsequently disseminates it to other forwarders.¶
In particular, for any computing service deployed in the CATS for the first time, the control plane could request the service instance to upload service demands and service attributes, which are associated with the CS-ID. The information may then be relayed to the C-PS in order to orchestrate the network and computing resources for computing service requests, thereby ensuring the quality of service.¶
When querying the computing service, the clients do not need to memorize the specific CS-ID, but describe their intentions by the service attributes and map them to the CS-ID by the controllers (in centralized model) or themselves (in distributed model). A service request carrying CS-ID as the destination address is successively routed to the ingress CATS-Forwarder, and is forwarded to the egress CATS-Forwarder through the path computed by the C-PS component. At egress CATS-Forwarder, the requests are forwarded to the corresponding service contact instance which selects the instance that can provide the service.¶
To enable the control plane to understand the characteristics of different computing services and schedule network and computing resources based on clients' demands, this document propose to classify the computing service attributes and upload to the control plane during the workflow of service announcement. Computing service attributes could be categorized into two types: Computing service Demand Attributes and Computing service Information Attributes. CSDA describes the computing resources and network resources requirements of the service, and CSIA details the nature of the computing service and the methods of its provision.¶
Computing service demand attributes can be categorized into computing resource demand and network resource demand.¶
Computing resource demand includes but not limited to the following items.¶
Computing capability type: describes the computation type required to run computing services, which could be categorized into logical computing capability, parallel computing capability, neural network computing capability and so on;¶
Computing performance: specifies the required computational performance to ensure the quality of computing services, typically measured in operations per second, such as FLOPS;¶
Memory capacity: describes the memory size required by computing services;¶
Disk capacity: describes the required disk size to ensure the quality of computing service.¶
Network resource demands define the network performance metrics to guarantee the service experience, including latency, RTT, bandwidth, jitter, and packet loss rate.¶
Computing service information attributes include but not limited to service model, service type, service provider, service name, and service attribution domain.¶
Service model: Differentiate the methods how service sites provide computing services, such as infrastructure services, platform services, and software services.¶
Service type: Specify the types of computing services, such as video rendering, scientific computing, cloud AR/VR, etc.¶
Service provider: Identify who provide the computing service.¶
Service name: Specifies the name of the computing service.¶
Service domain: Describe the area where the computing service is provided.¶
The service announcement processing and handling procedures could be divided into two parts: service registration and service update.¶
For a new computing service that has not been registered in CATS domain, the service contact instance is first notified of the service information attributes after the computing service is instantiated at the service site. It looks up the cache that stores the service deployment information, and announce it to C-SMA through the network layer service registration message if this is a new computing service.¶
Subsequently, if C-SMA also detects that the computing service has not been registered, the service information attributes would be sent to the control plane encapsulated in the registration packet. When the registration packet is received by the control plane, it generates a CS-ID for this new computing service and replies it to the C-SMA. At C-SMA, CS-ID is encapsulated in service registration response message and diffused to other CATS-Forwarders.¶
Additionally, the controller plane could request computing service demand attributes from the service site that registered the new CS-ID. This request is forwarded from the control plane to the service site via the C-SMA. When the service site receives the request, it returns the requested computing service demand attributes to the control plane.¶
To ensure integrated management of computing services, the control plane needs to maintain a database of CS-IDs and related service attributes. The information database includes an expiration time for the mapping relationship, which encompasses the CS-ID and its bound CIS-ID, as well as the CS-ID and its computing service attributes.¶
When the controller detects the expiration of the former mapping, it sends an update request message to the service contact instance and obtains the response information. If there is an update to the mapping relationship, the control plane sends an update message to the CATS-Forwarder, which then disseminates the update message; when a CS-ID is no longer bound to any CIS-ID, the latter mapping enters the expiration state and the control plane should decide whether to clear the binding relationship based on remain cache size.¶
Additionally, when a service contact instance detects a change in the state of a service instance, such as the addition of a new instance of an available computing service or the removal of a service by the service site, it should send a service update message to the C-SMA. At C-SMA, two steps would be taken: 1. send a service update message to the control plane announcing the change in the mapping relationship between the CS-ID and the CIS-ID; 2. send a service update message to the other CATS-Forwarders to announce the service update.¶
The client does not need to memorize the CS-ID, but describe intentions by computing service information attributes. Before service request, a service querying packet carrying the clients' address and the computing service information attributes is constructed and sent to the control plane via CATS-Forwarder. When the controller receives the packet, it interprets and parses the computing service information attributes in the packet. The attributes are typically mapped to a CS-ID or a set of alternative CS-IDs, and the mapping result is subsequently returned to clients.¶
In the distributed model, the CS-ID may contain semantics such as service type, service name and other service information attributes. The client could construct the CS-ID according to computing service intents and encapsulates it into the service request packet, which is then routed to the ingress CATS-Forwarder. At ingress CATS-Forwarder, The request is matched by the C-PS component to select the service instance as well as the network path that satisfy the computing service demand attributes.¶