TCPM Working Group W. Wang Internet-Draft A. Wang Intended status: Standards Track China Telecom Expires: 18 September 2024 17 March 2024 Service Affinity Solution for TCP based Application draft-wang-tcpm-tcp-service-affinity-option-05 Abstract This draft proposes a service affinity solution between client and server based on the newly defined TCP Options. This solution can avoid the waste of resources caused by saving a large amount of customer status data in the network equipment, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing-aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources. 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 18 September 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Wang & Wang Expires 18 September 2024 [Page 1] Internet-Draft tcp-service-affinity-option March 2024 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 . . . . . . . . . . . . . . 5 3. Procedures of the proposed solution . . . . . . . . . . . . . 5 4. Encoding of TCP Option for service affinity . . . . . . . . . 6 4.1. IPv4 Service Affinity option . . . . . . . . . . . . . . 7 4.2. IPv6 Service Affinity option . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The rapidly increasing number of customers and service requirements require more flexible, fast-response network. The increasing of the number of edge cloud pools makes a service can be deployed in many different resource pools, which needs the network to provide the capability to steer customer traffic to the optimal service node. Computing-Aware Traffic Steering(CATS) Working Group is proposed to make the network edge steer traffic between clients of a service and sites offering the service more quickly, flexibly and smoothly. [I-D.ietf-cats-usecases-requirements] describes the problem statement, use-cases and requirements of CATS. Due to the computing resource is deployed in edge clouds/sites, a service can be provided by different service nodes that use the same anycast IP address. The anycast IP address and the status of computing resource in each service node should be broadcast to the whole network. At the beginning, a customer establishes a TCP session with a service node. When the network status changes, the service node may no longer be able to ensure customer experience. It is necessary to disconnect the TCP session between the customer and the service node, and establish a TCP session between the customer and another service node that can provide the best customer experience. Wang & Wang Expires 18 September 2024 [Page 2] Internet-Draft tcp-service-affinity-option March 2024 A simplified CATS scenario is shown in Figure 1. Customer A and customer B want to access the same service. For customer A, the packet will firstly be transmitted to the corresponding anycast IP address. The ingress will determine the optimal service node for customer A based on the access cost, computing resources of each service node, and the scheduled computing resource scheduling algorithm. Similar processing will be performed when customer B accesses the same service. +-----------------------------------------------------------------+ | Anycast IP/IP4 | | +------------+ | | |Service node| | | +-----+------+ | | | | | +----+-----+ | | | R4 | | | +-------------+ Egress +------------+ | | | +----------+ | | | | | Anycast IP/IP3 | +----+-----+ +----+-----+ +------------+ | A -+ R1 | | R3 +--+Service node| | B -+ Ingress +--------------------------+ Egress | +------------+ | +----+-----+ +----+-----+ | | | | | | | +----------+ | | | +--------------+ R2 +-----------+ | | | Egress | | | +----+-----+ | | | | | +-----+------+ | | |Service node| | | +------------+ | | Anycast IP/IP2 | +-----------------------------------------------------------------+ Figure 1: The Computing-Aware Traffic Steering (CATS) scenario As the network status and computing resources are constantly changing, different customers may be scheduled to different service nodes when accessing the same service. For customers who have established connections, the service node providing services must remain unchanged. Otherwise, a large number of state synchronization between service nodes are required to maintain the consistency of application data in the process of two-way connection communication. The traditional solutions have two main methods: Wang & Wang Expires 18 September 2024 [Page 3] Internet-Draft tcp-service-affinity-option March 2024 * Maintain the customer-based connection status table in each router along the path. This table will not change dynamically with the change of network status and computing resources, so that the subsequent packets will be transmitted along the same path. * Maintain the customer-based connection status table in ingress and egress routers. The packets need to be forwarded through tunnels on the intermediate routers. The above solutions based on the connection status table are lack of flexibility and extensibility. The network devices should keep large amounts of status table to keep the service affinity for every customer flow. For large-scale service deployment, if the network status changes, it is easy to affect the customer experience. Besides, in the load balance scenario, a load balancer is usually put in front of all the physical servers so that all the packets sent and received by the physical servers should pass through the load balancer. This deployment may lead to the load balancer become the bottleneck when the traffic increases. Direct traffic redirection and traffic scheduling between the client and server can avoid the bottleneck of load balancer. MPTCP enables hosts to send packets belonging to one connection over different paths, but it is confined to the MPTCP framework. We want to find one solution that can meet such requirements in more general manner for TCP based application. HTTP redirection enables automatic page jumps by having the browser automatically send a new request based on the specific response status code and the value of the Location field returned by the server. It mainly involve the communication between client and server. Both client and server do not perceive changes in network status and cannot achieve comprehensive optimization based on network status and computing resource status. DNS redirection can redirect customer requests from one domain name to another by modifying DNS resolution records, or change the resolution result of a domain name to point to a different server IP address. However, due to the caching time of DNS records, it takes some time for the modification to take effect, which may result in customers still accessing servers that have been taken offline, thereby affecting customer experience. We propose a solution for the service affinity between client and server based on one newly defined TCP Option, which can realize the comprehensive scheduling based on real-time status of network and computing resources. This solution eliminates the need to maintain Wang & Wang Expires 18 September 2024 [Page 4] Internet-Draft tcp-service-affinity-option March 2024 customer-based connection status tables for network devices, and improves the feasibility and extensibility of large-scale deployment of computing-aware traffic steering network. 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] . 3. Procedures of the proposed solution The scenario is shown as Figure 1, and the transmission process of packets is shown in Figure 2. A new Flag (“SAF”) is requested for identify the sender supports TCP Service Affinity Option. When customer A accesses to the service, it will send its request packet to the ingress (R1). In this packet, SYN and SAF flag will be set and the destination address of this packet is set to the anycast IP address of this service (IPs). R1 schedules the customer A's service connection request according to the real-time status of the network and computing resources, and determine that the service node behind R4 will provide services to customer A. If the service node supports this TCP option, it returns its IP address and port information through the newly defined Option in TCP FIN packet in the connection response message. Customer A re-establishes the connection to the specific service node address and keeps it until the two-way communication ends. Wang & Wang Expires 18 September 2024 [Page 5] Internet-Draft tcp-service-affinity-option March 2024 +----------+ +----------+ +----------+ |Customer A| | R1 | | R4 | +-----+----+ +-----+----+ +-----+----+ | | | | | | | 1.Customer A access to | 2.R1 schedule the request and | | the service | determines service node behind | |------------------------>| R4 will provide service | | TCP(SYN+SAF/Anycast IP) |--------------------------------->| | | TCP(SYN+SAF/Anycast IP) | | | | | | | 3.Service node returns its IP address and port information | |<-----------------------------------------------------------| | TCP FIN(Server Affinity Option = IP4, FIN) | | | | | | 4.Customer A re-establishes the connect to service node | |----------------------------------------------------------->| | TCP(SYN/IP4) | Figure 2: Procedures for the service affinity solution In the whole process, devices in the network only need to broadcast the information of the computing network and Specific Address of service node, and perform optimized scheduling of computing network resources according to this information. 4. Encoding of TCP Option for service affinity After the customer selects the service node that actually provides services, it needs to maintain the connection to the server. The connection cannot change with the network status or server performance indicators. The changes of network status or server performance indicators can only affect subsequent new connections. TCP is a reliable transport layer protocol, which can provide high- quality data transmission and ensure customer experience. The TCP Header is shown as Figure 2 (defined in [RFC9293]). Wang & Wang Expires 18 September 2024 [Page 6] Internet-Draft tcp-service-affinity-option March 2024 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |S|C|E|U|A|P|R|S|F| | | Offset| Rsrv|A|W|C|R|C|S|S|Y|I| Window | | | |F|R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Options] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : : Data : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: TCP Header Format The newly defined flag "SAF" is used to identify whether the packet sender supports the Service Affinity Option. When the sender supports it, the flag should be set to 1. Options can carry differentiated requirements for the network. The list of all currently defined options is managed by IANA, but none of them can meet the demand of service affinity. So, we defined 2 new TCP Options: IPv4 Service Affinity option and IPv6 Service Affinity option. 4.1. IPv4 Service Affinity option The encoding of IPv4 Service Affinity option is shown in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (IPv4 Address, Port) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IPv4 Service Affinity option Wang & Wang Expires 18 September 2024 [Page 7] Internet-Draft tcp-service-affinity-option March 2024 where: * Type (1 octet): identifies the newly defined TCP Option, which is allocated by IANA. * Length (1 octet): identifies the length of the TCP Option. * (IPv4 Address, Port) (6 octets): identifies the IPv4 address and port owned by the service node that provides the service. This TCP Option has the capability to transmit the IPv4 address and TCP port of service node to be redirected. This Option is carried in the TCP FIN packet sending by the service node, and the address carried must be the address owned by the service node. After receiving the TCP FIN packet, if this TCP Option is included in the packet, the customer will establish the connection to the IPv4 address specified in this Option. 4.2. IPv6 Service Affinity option The encoding of IPv6 Service Affinity option is shown in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : (IPv6 Address, Port) : : | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPv6 Service Affinity option where: * Type (1 octet): identifies the newly defined TCP Option, which is allocated by IANA. * Length (1 octet): identifies the length of the TCP Option. * (IPv6 Address, Port) (18 octets): identifies the IPv6 address and port owned by the service node that provides the service. Wang & Wang Expires 18 September 2024 [Page 8] Internet-Draft tcp-service-affinity-option March 2024 This TCP Option has the capability to transmit the IPv6 address and TCP port of service node to be redirected. This Option is carried in the TCP FIN packet sending by the service node, and the address carried must be the address owned by the service node. After receiving the TCP FIN packet, if this TCP Option is included in the packet, the customer will establish the connection to the IPv6 address specified in this Option. 5. Security Considerations In Service affinity scenarios, traffic hijacking and DDoS attacks may occur. The attack source may send TCP packets with SAF to a service node to obtain the unicast IP address of the service node, thereby illegally obtaining information on the server, or launching DDoS attacks on the service node. To avoid DDoS attacks, traffic accessing service nodes can first pass through the firewall, which filters the traffic before sending it to the service node. To avoid information theft on the server, users and sites accessing the network can be authenticated and verified. CATS solutions for various network attacks were mentioned in [I-D.li-cats-attack-detection]. Among them, service instances have a low-rate attack computation aware security module (LCSM), an application computation aware security model (ACSM), a botnet computation aware security detection module (BCSM), a network attack computation aware security module (NCSM), a DDDoS computation aware security module (DCSM), and a firewall. Capable of defending against various common network attacks. 6. IANA Considerations This document defines 2 new types of TCP Option. If this work is standardized, IANA is requested to officially assign Type value for IPv4 Service Affinity option and IPv6 Service Affinity option as follows: +-----+-------+----------------------------+ |Type |Length |Meaning | +-----+-------+----------------------------+ | 79 | 8 |IPv4 Service Affinity option| +-----+-------+----------------------------+ | 80 | 20 |IPv6 Service Affinity option| +-----+-------+----------------------------+ 7. Normative References Wang & Wang Expires 18 September 2024 [Page 9] Internet-Draft tcp-service-affinity-option March 2024 [I-D.ietf-cats-usecases-requirements] Yao, K., Trossen, D., Boucadair, M., Contreras, L. M., Shi, H., Li, Y., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft- ietf-cats-usecases-requirements-02, 1 January 2024, . [I-D.li-cats-attack-detection] Li, M., Zhou, H., Deng, S., and W. Wang, "Computing-aware Traffic Steering for attack detection", Work in Progress, Internet-Draft, draft-li-cats-attack-detection-00, 13 October 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . Authors' Addresses Wei Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: weiwang94@foxmail.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: wangaj3@chinatelecom.cn Wang & Wang Expires 18 September 2024 [Page 10]