TCPM Working Group W. Wang
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: 20 April 2023 17 October 2022
Service Affinity Solution for TCP based Application in Anycast Situation
draft-wang-tcpm-tcp-service-affinity-option-00
Abstract
This draft proposes a service affinity solution between client and
server based on the newly defined TCP Option. 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 power resources in the distributed computing power network
scenario, so as to realize the reasonable operation of cloud network
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 20 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang & Wang Expires 20 April 2023 [Page 1]
Internet-Draft tcp-service-affinity-option October 2022
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 . . . . . . . . . . . . . . 4
3. Procedures of the proposed solution . . . . . . . . . . . . . 4
4. Encoding of TCP Option for service affinity . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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 Power Network (CPN) is proposed to make the cloud and
network interact more quickly, flexibly and smoothly. At the
beginning, all service nodes that provide the same service function
use the same anycast IP address. The anycast IP address and the
status of computing power resource in each service node should be
broadcast to the whole network.
The CPN 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 of the CPN will determine the optimal service node for
customer A based on the access cost, computing power resources of
each service node, and the scheduled computing power resource
scheduling algorithm. Similar processing will be performed when
customer B accesses the same service.
Wang & Wang Expires 20 April 2023 [Page 2]
Internet-Draft tcp-service-affinity-option October 2022
+-----------------------------------------------------------------+
| IPs/IP4 |
| +------------+ |
| |Service node| |
| +-----+------+ |
| | |
| +----+-----+ |
| | R4 | |
| +-------------+ Egress +------------+ |
| | +----------+ | |
| | | IPs/IP3 |
+----+-----+ +----+-----+ +------------+ |
A -+ R1 | | R3 +--+Service node| |
B -+ Ingress +--------------------------+ Egress | +------------+ |
+----+-----+ +----+-----+ |
| | | |
| | +----------+ | |
| +--------------+ R2 +-----------+ |
| | Egress | |
| +----+-----+ |
| | |
| +-----+------+ |
| |Service node| |
| +------------+ |
| IPs/IP2 Computing Power Network |
+-----------------------------------------------------------------+
Figure 1: The Computing Power Network (CPN) scenario
As the network status and computing power 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:
* 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 power 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.
Wang & Wang Expires 20 April 2023 [Page 3]
Internet-Draft tcp-service-affinity-option October 2022
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.
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 power resources. This solution eliminates the need to
maintain customer-based connection status tables for network devices,
and improves the feasibility and extensibility of large-scale
deployment of computing power 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 Figure1, and the transmission process of
packets is shown in Figure 2. When customer A accesses to the
service, it will send its request packet to the ingress (R1). 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 power resources, and determine that the service node
behind R4 will provide services to customer A. The service node to
be dispatched returns its specific service address (IP4) and port
information through the newly defined TCP Option in the connection
response message. Customer A reestablishes the connection to the
specific service node address and keeps it until the two-way
communication ends.
Wang & Wang Expires 20 April 2023 [Page 4]
Internet-Draft tcp-service-affinity-option October 2022
+----------+ +----------+ +----------+
|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/IPs) |--------------------------------->|
| | TCP(SYN/IPs) |
| | |
| |
| 3.Service node returns its IP address and port information |
|<-----------------------------------------------------------|
| TCP FIN(Server Address Option = IP4, FIN) |
| |
| |
| 4.Customer A reestablishes 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 <Anycast Address, Service
node Status> 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 20 April 2023 [Page 5]
Internet-Draft tcp-service-affinity-option October 2022
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 | |C|E|U|A|P|R|S|F| |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window |
| | |R|E|G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Options] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
: Data :
: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TCP Header Format
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 a new
TCP Option, the encoding is shown as Figure 3.
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) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| :
: (IPv6 Address, Port) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The encoding of new TCP Option
where:
* Type (1 octet): identifies the newly defined TCP Option, which is
allocated by IANA.
Wang & Wang Expires 20 April 2023 [Page 6]
Internet-Draft tcp-service-affinity-option October 2022
* 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.
* (IPv6 Address, Port) (18 octets): identifies the IPv6 address and
port owned by the service node that provides the service.
This TCP Option has the capability to transmit the IP 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 address specified in
this Option.
5. Security Considerations
TBD
6. IANA Considerations
This document defines a new type of TCP Option. If this work is
standardized, IANA is requested to officially assign Type value for
this TCP Option, it is recommended to be 79.
7. 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>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
Authors' Addresses
Wei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: weiwang94@foxmail.com
Wang & Wang Expires 20 April 2023 [Page 7]
Internet-Draft tcp-service-affinity-option October 2022
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Wang & Wang Expires 20 April 2023 [Page 8]