The Session Recovery Option (SRO) for TCP
draft-cmcc-tcp-sro-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Zhaoyu Luo | ||
| Last updated | 2026-08-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cmcc-tcp-sro-01
Network Working Group Z. Luo, Ed.
Internet-Draft CMCC
Intended status: Experimental 13 August 2026
Expires: 14 February 2027
The Session Recovery Option (SRO) for TCP
draft-cmcc-tcp-sro-01
Abstract
This document defines the Session Recovery Option (SRO) for TCP. SRO
improves the reliability of Source Network Address Translation (SNAT)
and load balancing (LB) services and simplifies the implementation of
elastically scaling SNAT/LB clusters. SRO enables a client and a
server to exchange their identifiers during connection establishment.
When a session needs to be recovered, an endpoint conveys the
identifier of the peer to the network node, which uses it to locate
the endpoint holding the session backup and recover the session. SRO
is optional: endpoints that do not support it behave as if the option
did not exist.
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 14 February 2027.
Copyright Notice
Copyright (c) 2026 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
Luo Expires 14 February 2027 [Page 1]
Internet-Draft TCP SRO August 2026
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The SRO Option . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Option Formats . . . . . . . . . . . . . . . . . . . . . 4
3.2. Option Semantics . . . . . . . . . . . . . . . . . . . . 4
4. SRO Operation . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Connection Establishment . . . . . . . . . . . . . . . . 5
4.2. Session Recovery . . . . . . . . . . . . . . . . . . . . 5
4.3. Per-Segment Mode . . . . . . . . . . . . . . . . . . . . 7
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9
Appendix B. Changes since draft-cmcc-tcp-sro-00 . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
SNAT [RFC2663] and LB are stateful services: session state resides on
the serving node, and a single node cannot recover its sessions after
a failure. To provide reliable service, operators deploy high-
availability (HA) pairs or clusters. Existing elastically scaling
SNAT/LB cluster designs are complex to implement, and the most
complex part is session recovery and session migration. Moreover,
these services are unfriendly to long-lived connections: an idle
connection is typically cleaned up by the serving node after a
timeout [RFC5382], breaking the connection.
Luo Expires 14 February 2027 [Page 2]
Internet-Draft TCP SRO August 2026
A novel approach to reliable service is to back up the session state
to the client or server side, so that even a single serving node can
recover a session after a failure. This approach is embodied in the
Available Session Recovery Protocol (ASRP) [draft-cmcc-asrp], to
which readers may refer for the details of session backup and
recovery. A key challenge of this approach is locating the endpoint
that holds the session backup. Other mechanisms exist, but the
Session Recovery Option (SRO) defined in this document addresses this
challenge in the most direct way: it locates the backup endpoint in a
single step. Moreover, SRO is not limited to session recovery: any
mechanism that needs to locate a client or a server can use it.
SRO is a TCP option [RFC9293]. During the TCP handshake, the client
and the server exchange their identifiers; when a session needs to be
recovered, an endpoint carries the identifier of the peer, and the
network node uses it to locate the endpoint holding the session
backup. SRO is lightweight: it is carried only in the SYN, the SYN-
ACK, and segments sent on timeout retransmission, adding no overhead
to normal data segments. Despite this small cost, SRO is important
for the reliability of SNAT and LB services: it simplifies session
recovery and session migration in elastically scaling SNAT/LB
clusters, and makes them friendly to long-lived connections. With
SRO, a session that has been cleaned up after an idle timeout is
recovered as soon as a segment carrying the identifier arrives.
2. Terminology
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.
"SRO" refers to the Session Recovery Option defined in this document.
"Client" refers to TCP's active open side, and "server" refers to
TCP's passive open side. "Network node" refers to a device (e.g., a
load balancer or a NAT gateway) that forwards packets and
participates in session backup and recovery. "Client identifier"
refers to a value, carried in the SRO option in a SYN segment, that
identifies a client within a cluster. Its length is configurable and
defaults to 4 octets. "Server identifier" refers to a value, carried
in the SRO option in a SYN-ACK segment, that identifies a server
within a cluster. Its length is configurable and defaults to 4
octets. "Session backup" refers to session state information stored
on an endpoint for the purpose of session recovery.
Luo Expires 14 February 2027 [Page 3]
Internet-Draft TCP SRO August 2026
3. The SRO Option
SRO is negotiated during the TCP handshake, similar to other TCP
options, e.g., the Window Scale option [RFC7323] and TCP Fast Open
[RFC7413]. During the handshake, each endpoint carries its own
identifier in the SRO option: a client includes the SRO option in the
SYN segment, and a server that supports SRO includes it in the SYN-
ACK segment. SRO is only in effect if both segments carry the
option. After the handshake, an endpoint carries the identifier of
the peer in the SRO option, which it stored during the handshake: a
client carries the server identifier, and a server carries the client
identifier.
3.1. Option Formats
The SRO option carries an identifier. During the handshake, it
carries the identifier of its sender: the client identifier in a SYN
segment, and the server identifier in a SYN-ACK segment; on session
recovery, it carries the identifier of the peer. The identifier
length is configurable, from 2 to 8 octets, with a default of 4
octets. The option is 2 + N octets long: 1 octet for the Kind, 1
octet for the Length (Length = N + 2), and N octets for the
identifier.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identifier (N octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRO Option
3.2. Option Semantics
A client MAY include the SRO option in a SYN segment; the client
decides whether to use SRO.
A server that supports SRO and receives a SYN segment with the SRO
option SHOULD include the SRO option in the SYN-ACK segment.
A server that does not support SRO MUST NOT include the SRO option in
the SYN-ACK segment.
Luo Expires 14 February 2027 [Page 4]
Internet-Draft TCP SRO August 2026
The length of an identifier is configurable, from 2 to 8 octets, with
a default of 4 octets; each endpoint determines the length of its own
identifier. The Length field MUST equal the identifier length plus
2.
A client that receives the SRO option in a SYN-ACK segment SHOULD
store the server identifier for the lifetime of the connection.
A server that receives the SRO option in a SYN segment SHOULD store
the client identifier for the lifetime of the connection.
4. SRO Operation
4.1. Connection Establishment
During the TCP handshake, the client and the server exchange the SRO
option according to the rules in Section 3.2. After the handshake,
each endpoint has stored the identifier of the peer and conveys it
for session recovery as described in Section 4.2.
4.2. Session Recovery
By default, an endpoint conveys the identifier on timeout
retransmission.
In a load-balancing cluster, where the session state is backed up to
the server, a client conveys the server identifier on timeout
retransmission. The network node uses the identifier to locate the
server holding the backup and recover the session.
Luo Expires 14 February 2027 [Page 5]
Internet-Draft TCP SRO August 2026
load-balancing
client network node server
| | |
| ------ SYN + Client-ID -----> | ----- SYN + Client-ID ------> |
| <---- SYN-ACK + Server-ID --- | <--- SYN-ACK + Server-ID ---- |
| | |
| <---------- data -----------> | <---------- data -----------> |
| | |
| - - - (session lost) - - - x|x - - - (session lost) - - - |
| | |
| | |
| retransmission | |
| ------------ + -------------> | |
| Server-ID | |
| | |
| | ------ recovery query ------> |
| | <----- session state -------- |
| | (session recovered) |
| | |
| <---------- data -----------> | <---------- data -----------> |
Figure 2: Session recovery in a load-balancing cluster
Figure 2 shows the recovery flow in a load-balancing cluster, where
the client conveys the server identifier. The flow in a SNAT cluster
is symmetric: the server conveys the client identifier, and the
network node locates the client holding the backup. The detailed
recovery procedures are described in the Available Session Recovery
Protocol (ASRP) [draft-cmcc-asrp].
In a SNAT cluster, where the session state is backed up to the
client, a server conveys the client identifier on timeout
retransmission. The network node uses the identifier to locate the
client holding the backup and recover the session.
How the network node recovers a session is out of the scope of this
document. It is suggested that the node use the Available Session
Recovery Protocol (ASRP) [draft-cmcc-asrp] to recover the session;
however, SRO does not depend on ASRP.
The endpoint includes the identifier of the peer stored during the
handshake in the retransmitted segment.
Luo Expires 14 February 2027 [Page 6]
Internet-Draft TCP SRO August 2026
4.3. Per-Segment Mode
In the per-segment mode, an endpoint MAY be configured to include the
identifier of the peer in every segment of a connection, instead of
only on timeout retransmission. The network node can then recover
the session at any time, without depending on retransmission timing.
This mode is intended only for services with extremely high
requirements on both reliability and recovery speed; for most
deployments, the default mode is sufficient and the per-segment mode
is not needed. It is disabled by default, as it adds 2 + N octets to
every segment.
5. Compatibility
Clients that do not support SRO do not include the SRO option in the
SYN segment, and servers that do not support SRO do not include it in
the SYN-ACK segment. Such connections behave exactly as connections
without SRO, and session recovery falls back to the mechanisms
implemented by the network node. Similarly, if the SRO option is
removed by an intermediate device, the endpoints operate without
identifiers. SRO is designed for the common deployment where a
single tier of SNAT or LB nodes sits between the client and the
server; in multi-tier deployments, only the tier closest to the
client or the server can use SRO.
6. Security Considerations
A forged identifier cannot recover a non-existent session, because
recovery succeeds only if the session backup actually exists on the
identified endpoint. A segment carrying an identifier triggers at
most one recovery query, which is no more than the number of queries
triggered by other recovery mechanisms.
How a network node maps an identifier to an endpoint address is an
implementation matter. A node SHOULD ignore an identifier that it
cannot map to a known endpoint, and SHOULD rate-limit recovery
queries (e.g., per session or per source) to mitigate flooding.
An identifier SHOULD be randomly assigned or derived with a secret
key, rather than being derived directly from the endpoint IP address,
so that internal addressing information is not exposed to third
parties.
7. IANA Considerations
IANA is requested to allocate one TCP option Kind number from the TCP
option kind registry for the Session Recovery Option:
Luo Expires 14 February 2027 [Page 7]
Internet-Draft TCP SRO August 2026
+======+==========+=========+===============+
| Kind | Length | Meaning | Reference |
+======+==========+=========+===============+
| TBD | variable | SRO | This document |
+------+----------+---------+---------------+
Table 1
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>.
[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>.
8.2. Informative References
[draft-cmcc-asrp]
Luo, Z. and H. Yan, "Available Session Recovery Protocol",
Work in Progress, Internet-Draft, draft-cmcc-asrp, 2026,
<https://datatracker.ietf.org/doc/html/draft-cmcc-asrp>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
Luo Expires 14 February 2027 [Page 8]
Internet-Draft TCP SRO August 2026
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
Appendix A. Acknowledgments
The authors would like to thank all individuals who have provided
valuable feedback and contributions during the development of this
document, especially Mike Heard and Michael Tuexen for their detailed
review comments.
Appendix B. Changes since draft-cmcc-tcp-sro-00
* Expanded SNAT and LB on first use and added an informative
reference to RFC 2663.
* Consolidated the two option kinds into a single kind.
* Removed the MTU consideration in Section 4.2.
Author's Address
Zhaoyu Luo (editor)
CMCC
No. 58 Kunlunshan Road
Suzhou
215000
China
Email: lluozy@yeah.net
Luo Expires 14 February 2027 [Page 9]