Network Working Group Z. Luo, Ed. Internet-Draft H. Yan Intended status: Experimental CMCC Expires: 24 April 2027 21 October 2026 Available Session Recovery Protocol draft-cmcc-asrp-09 Abstract This document describes an experimental protocol, the Available Session Recovery Protocol (ASRP), for high-availability clusters that provide stateful network services - load balancing, Network Address Translation (NAT [RFC4787]), and other layer-4 stateful network functions, including their virtualized (NFV) forms. ASRP backs up the session state at the session's own endpoints, so that the cluster nodes hold no replicated state: no inter-node synchronization, no backup node, and no state warm-up for a newly added node. The document defines the procedures and message formats for session backup and recovery. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: theoretically unlimited elastic scaling capacity; support for rapid recovery from multi-point failures; reduction of resource redundancy through the elimination of centralized backup nodes; and significant simplification of cluster implementation complexity. The ASRP protocol provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters. 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/. Luo & Yan Expires 24 April 2027 [Page 1] Internet-Draft Available Session Recovery Protocol October 2026 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 24 April 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Comparison with Existing Approaches . . . . . . . . . . . 4 1.2. ASRP Elastic Stateful Cluster . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Two Operational Modes . . . . . . . . . . . . . . . . . . 8 3.1.1. PSV Mode . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. ACT Mode . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Two Routing Behaviors . . . . . . . . . . . . . . . . . . 9 3.2.1. Symmetric Routing . . . . . . . . . . . . . . . . . . 9 3.2.2. Asymmetric Routing . . . . . . . . . . . . . . . . . 9 3.3. Protocol Message . . . . . . . . . . . . . . . . . . . . 10 3.4. Transmission Modes . . . . . . . . . . . . . . . . . . . 11 3.4.1. Inline Message . . . . . . . . . . . . . . . . . . . 11 3.4.2. Standalone Message . . . . . . . . . . . . . . . . . 13 3.5. Session Creation/Recovery Scenarios . . . . . . . . . . . 13 3.5.1. PSV-Scenario-1 . . . . . . . . . . . . . . . . . . . 13 3.5.2. PSV-Scenario-2 . . . . . . . . . . . . . . . . . . . 14 3.5.3. PSV-Scenario-3 . . . . . . . . . . . . . . . . . . . 14 3.5.4. ACT-Scenario-1 . . . . . . . . . . . . . . . . . . . 16 3.5.5. ACT-Scenario-2 . . . . . . . . . . . . . . . . . . . 17 3.6. State Consistency . . . . . . . . . . . . . . . . . . . . 18 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Message Format . . . . . . . . . . . . . . . . . . . . . 18 4.1.1. Message Header . . . . . . . . . . . . . . . . . . . 19 Luo & Yan Expires 24 April 2027 [Page 2] Internet-Draft Available Session Recovery Protocol October 2026 4.1.2. Session Tuples . . . . . . . . . . . . . . . . . . . 20 4.1.3. NS Message . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. QS Message . . . . . . . . . . . . . . . . . . . . . 21 4.1.5. HS Message . . . . . . . . . . . . . . . . . . . . . 21 4.1.6. Other Messages . . . . . . . . . . . . . . . . . . . 22 4.2. ASRP Packets . . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Transport-Layer Transparency . . . . . . . . . . . . 22 4.3. Message Processing . . . . . . . . . . . . . . . . . . . 23 4.3.1. Message Validation . . . . . . . . . . . . . . . . . 23 4.3.2. Cookie Handling . . . . . . . . . . . . . . . . . . . 23 4.3.3. NS Message . . . . . . . . . . . . . . . . . . . . . 24 4.3.4. NA Message . . . . . . . . . . . . . . . . . . . . . 25 4.3.5. NC Message . . . . . . . . . . . . . . . . . . . . . 25 4.3.6. QS Message . . . . . . . . . . . . . . . . . . . . . 25 4.3.7. RS Message . . . . . . . . . . . . . . . . . . . . . 26 4.3.8. RX Message . . . . . . . . . . . . . . . . . . . . . 26 4.3.9. HS Message . . . . . . . . . . . . . . . . . . . . . 26 4.3.10. PS Message . . . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.1. TCP Option Kind . . . . . . . . . . . . . . . . . . . . . 28 7.2. UDP Option Kind . . . . . . . . . . . . . . . . . . . . . 28 7.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 29 7.4. Experimental Use . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Implementation Status . . . . . . . . . . . . . . . 31 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Many network functions are stateful: load balancers, NAT gateways, connection trackers, and other layer-4 network functions, in physical and virtualized (NFV) forms alike, each maintain per-session state for the traffic they forward, and are deployed at scale in every data center and enterprise edge. That state is the root cause of the complexity of operating these services at scale - it is what master/ backup replication, intra-cluster session synchronization, and failover machinery all exist to protect. This document takes a different starting point: the state of a session does not need to live in the cluster at all. The Available Session Recovery Protocol (ASRP) backs up the session state at the session's own endpoints - the client or the server - so that the cluster nodes hold no replicated state: no inter-node Luo & Yan Expires 24 April 2027 [Page 3] Internet-Draft Available Session Recovery Protocol October 2026 synchronization, no backup node, and no state warm-up for a newly added node; a node that receives a packet of a session it does not hold recovers the session from the endpoint on demand. The protocol is not specific to load balancing or NAT. Any network function that maintains per-session state can use ASRP to keep that state at the endpoints and gain the same properties: sessions survive node restarts, failovers, and elastic scaling without inter-node machinery. The availability boundary is the same as that of conventional high-availability designs - ASRP protects against failures of the network function itself; the failure of an endpoint takes down its sessions under any design. 1.1. Comparison with Existing Approaches High-availability mechanisms evolved together with the deployment model they serve. The industry's answer for elastically scaling deployments is the Elastic Stateful Cluster (ESC): a group of network nodes, all active, that simultaneously provide the same stateful network function, such as load balancing (SLB), Network Address Translation (NAT), and other layer-4 functions. In such a cluster the hard problem is session state: a design has to decide where the state lives, and how a node that receives a packet of a session it does not hold recovers that session. Master/backup HA (e.g., VRRP [RFC5798]) solved the failover problem of the master/backup era: it provides fast takeover of a shared address, with session continuity typically left to private synchronization between the active node and its backup (e.g., the LVS connection synchronization daemon, DPVS). The drawback is the single-active model: for a given service address, exactly one node forwards while the others stand by, so a service is capped at the capacity of one node, the standby nodes sit idle, and load cannot be met by adding nodes. The conventional Elastic Stateful Cluster keeps session state inside the cluster: its nodes communicate with each other to synchronize session state, and redundant backup nodes are kept within the cluster for failover. The architecture is typically layered - a Fast/Slow Path design that separates session management from packet forwarding: Luo & Yan Expires 24 April 2027 [Page 4] Internet-Draft Available Session Recovery Protocol October 2026 +--------------------------+ | +----------------------+ | | | ... | | | | ... | | | | +----------------+ | | | | | Slow Path Node | | | | | +----------------+ | | | | ... | | | | ... | | | +----------------------+ | | ^ | | | | V | | +----------------------+ | | | ... | | +----------+ | | ... | | +----------+ | | | | +----------------+ | | | | | Client | <--------> | Fast Path Node | <--------> | Server | | | | | +----------------+ | | | | +----------+ | | ... | | +----------+ | | ... | | | +----------------------+ | +--------------------------+ Figure 1: Fast/Slow Path Elastic Stateful Cluster The slow path nodes are responsible for session creation and synchronization, while the fast path nodes are responsible for rapid packet forwarding. The drawback is the weak elastic scaling capability of the slow path nodes: new sessions must be propagated to other nodes so that asymmetric traffic can be handled anywhere, the synchronization traffic grows with the session creation rate and the node count, and a newly added node starts without state. A typical implementation reference is the AWS Hyperplane NFV platform. Stateless scheduling (e.g., Maglev-style consistent hashing, ECMP [RFC2991] [RFC2992]) avoids session state on the nodes entirely by hashing each flow to a node. Node failure is handled by rehashing flows, which works only when the service can tolerate a flow landing on a node that holds no state for it; stateful services such as NAT cannot. Luo & Yan Expires 24 April 2027 [Page 5] Internet-Draft Available Session Recovery Protocol October 2026 These mechanisms are what make elastic clusters work in practice, but they are private. The contrast with the previous generation is telling: the master/backup architecture is served by a standard (VRRP), while the Elastic Stateful Cluster - the architecture that large deployments actually use today - has no standard protocol for its session-state layer. Routing, failure detection, and address takeover are individually standardized; session synchronization and recovery are not, and every production cluster ships its own. ASRP fills this gap by removing the session state from the cluster altogether: the backup of a session is stored at one of the session's own endpoints, nodes share no protocol state with each other, and recovery state is pulled on demand (QS/RS) only when a node actually needs a session it does not have. This structure - state held at an endpoint and recovered against an opaque token - mirrors the pattern proven at Internet scale by TLS session tickets [RFC8446] and QUIC address validation tokens [RFC9000]. This addresses the hardest problem of the elastic cluster and, as a side effect, simplifies the cluster itself: no inter-node protocol, no synchronization traffic, and no state warm-up for a newly added node. The tradeoff is that the client or server side must support the protocol. Within a single administrative domain - a data center for load balancing, an enterprise edge for SNAT - this is a deployment decision rather than a protocol limitation. Table 1 summarizes the comparison of master/backup HA with the two Elastic Stateful Cluster designs, conventional and ASRP: +==============+============+================+===================+ | Architecture | Elasticity | Implementation | Standard protocol | +==============+============+================+===================+ | Master/ | No | Pairwise sync | VRRP [RFC5798] | | backup HA | | | | +--------------+------------+----------------+-------------------+ | Conventional | Partial | Complex | None | | cluster | | | | +--------------+------------+----------------+-------------------+ | ASRP cluster | Yes | Simple | This document | +--------------+------------+----------------+-------------------+ Table 1: Comparison of HA Architectures 1.2. ASRP Elastic Stateful Cluster Luo & Yan Expires 24 April 2027 [Page 6] Internet-Draft Available Session Recovery Protocol October 2026 +----------------------+ | ... | +----------+ | ... | +----------+ | | | +----------------+ | | | | Client | <--------> | ASRP Node | <--------> | Server | | | | +----------------+ | | | +----------+ | ... | +----------+ | ... | +----------------------+ Figure 2: ASRP Elastic Stateful Cluster The Available Session Recovery Protocol (ASRP) provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters. Its core idea is to distribute session state information to the client or server. The lifecycle of the backup state is synchronized with the real session, eliminating the need for independent keepalive and timeout mechanisms. This design ensures the timeliness and availability of the backup information. ASRP defines corresponding session backup and recovery mechanisms. The protocol allows protocol messages to be transmitted together with the original service data packets, thereby reducing control overhead for state synchronization. In an Elastic Stateful Cluster built on ASRP, network nodes possess atomic and mutually independent properties. There is no need for communication between nodes, nor is session synchronization required within the cluster. This fundamental design provides theoretically unlimited scaling capability and supports rapid recovery from multi-point failures. 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. This document uses the following terms: Elastic Stateful Cluster (ESC): A group of network nodes, all active, that simultaneously provide the same stateful network function; any node may receive any flow of the service, and nodes can be added or removed at any time. In this document, "cluster" refers to an ESC. Luo & Yan Expires 24 April 2027 [Page 7] Internet-Draft Available Session Recovery Protocol October 2026 Network Node: A device that provides stateful network services (e.g., load balancing, NAT) and creates and maintains sessions for the traffic it forwards. Client / Server: The two endpoints of a session. Depending on the operational mode, the server (PSV mode) or the client (ACT mode) also holds the backup of the session. Backup Holder: The client or server that stores the backed-up state of a session. Session: The state a network node maintains for a flow, keyed by the flow's 5-tuple. Explicit First Packet: A packet whose characteristics explicitly indicate the start of a session, e.g., a TCP SYN or a DNS query. Inline Message: An ASRP message carried within a packet of the flow itself - at the head of the segment payload marked by the ASRP option, in the datagram's option area, or in a separate packet that copies the original packet header. ASRP option: The transport-layer option that marks the presence of an ASRP message. On TCP it carries no data (a Length of 2) and marks the message at the head of the segment payload; on UDP it carries the message as its option data, in the datagram's option area. Standalone Message: An ASRP message carried in an independent UDP packet whose destination port is ASRP-PORT. ASRP-PORT: The UDP destination port used for standalone ASRP messages. 3. Protocol Overview 3.1. Two Operational Modes For the ASRP protocol to function correctly, two prerequisites must be met. First, all network nodes within the cluster MUST run service software supporting the ASRP protocol. Second, the server or client responsible for backing up sessions MUST deploy a kernel module or an eBPF module that supports ASRP. Depending on whether this module is deployed on the server or the client, the protocol operates in one of two corresponding modes: Passive (PSV) Mode and Active (ACT) Mode. Luo & Yan Expires 24 April 2027 [Page 8] Internet-Draft Available Session Recovery Protocol October 2026 3.1.1. PSV Mode In PSV mode, the network node is typically deployed in the same network domain as the server (e.g., inside a data center). Load balancing is the typical example; any stateful function serving that domain can use the protocol. 3.1.2. ACT Mode In ACT mode, the network node is typically deployed in the same network domain as the client (e.g., an enterprise intranet). Source NAT is the typical example; any stateful function serving that domain can use the protocol. The operational mode (PSV or ACT) is determined by the deployment configuration of the network node and is not carried in ASRP messages. 3.2. Two Routing Behaviors 3.2.1. Symmetric Routing Elastic Stateful Cluster +------------------+ +----------+ | ... | +----------+ | | | +------------+ | | | | Client | <----------> | node X | <----------> | Server | | | | +------------+ | | | +----------+ | ... | +----------+ +------------------+ Figure 3: Symmetric Routing Symmetric routing refers to the path mode where bidirectional traffic of the same session between a client and a server is always routed to the same node within the cluster. 3.2.2. Asymmetric Routing Luo & Yan Expires 24 April 2027 [Page 9] Internet-Draft Available Session Recovery Protocol October 2026 Elastic Stateful Cluster +------------------+ | ... | +----------+ | +------------+ | +----------+ | | -----------> | node X | -----------> | | | | | +------------+ | | | | Client | | ... | | Server | | | | +------------+ | | | | | <----------- | node Y | <----------- | | +----------+ | +------------+ | +----------+ | ... | +------------------+ Figure 4: Asymmetric Routing Asymmetric routing refers to the scenario where bidirectional traffic of the same session may be routed (e.g., by mechanisms such as ECMP [RFC2991], [RFC2992]) to different nodes within a cluster. In cloud networking environments, asymmetric routing is a common phenomenon, which imposes higher demands on the implementation of elastic stateful clusters. 3.3. Protocol Message ASRP achieves distributed backup and recovery of session state information by exchanging specific protocol messages among the client, server, and network nodes (such as load balancers or NAT gateways). In a load-balancing scenario, session state is distributed and backed up to individual servers; in an SNAT scenario, session state is distributed and backed up to individual clients. ASRP defines the following messages: Luo & Yan Expires 24 April 2027 [Page 10] Internet-Draft Available Session Recovery Protocol October 2026 +=========+===================+=========================+ | Message | Generated by | Full name | +=========+===================+=========================+ | NS | Network node | New Session | +---------+-------------------+-------------------------+ | NA | Backup holder | New Session Acknowledge | +---------+-------------------+-------------------------+ | NC | Backup holder | New Session Conflict | +---------+-------------------+-------------------------+ | QS | Network node | Query Session | +---------+-------------------+-------------------------+ | RS | Backup holder | Recover Session | +---------+-------------------+-------------------------+ | RX | Backup holder | Recovery no-session | +---------+-------------------+-------------------------+ | HS | Client (ACT mode) | Hello Session | +---------+-------------------+-------------------------+ | PS | Server (PSV mode) | Push Session | +---------+-------------------+-------------------------+ Table 2 The network node sends an NS message to deliver the state of a newly created session to the backup holder - the server in PSV mode, or the client in ACT mode; the backup holder acknowledges it with an NA message, or reports a conflict with an existing local session with an NC message. When a received packet matches no local session and none can be created directly, the network node queries the backup holder with a QS message; the holder answers with an RS message carrying the state required to recover the session, or an RX message when the queried session is not found. In ACT mode, a client sends an HS message to announce its support of the protocol and trigger the network node to return an NS message; in PSV mode, a server sends a PS message to push session state to the network node, e.g. to create or update a session under asymmetric routing. 3.4. Transmission Modes ASRP messages can be transmitted in two modes: Inline Message and Standalone Message. 3.4.1. Inline Message The Inline Message is transmitted with the same 5-tuples as the flow. The carriage differs by transport. Luo & Yan Expires 24 April 2027 [Page 11] Internet-Draft Available Session Recovery Protocol October 2026 For TCP flows, the ASRP option is a TCP option with Kind TBD and a Length of 2; it carries no data and marks the presence of the message. The message occupies the leading octets of the segment payload. When the total packet length does not exceed the MTU, NS, HS, and PS messages SHOULD be inserted into the original packet; otherwise, they are carried in a separate packet that copies the original packet header, including the ASRP option, without the original packet data. For UDP flows, the ASRP message is carried as the option data of the ASRP option, a UDP option [RFC9868] placed in the datagram's option area. The datagram's own payload is untouched. When the datagram leaves no room for the option within the MTU, the message is carried in a separate packet that copies the original datagram header. HS messages are sent after forwarded packets, and PS messages are sent before forwarded packets. Traveling with the flow's 5-tuple is a structural requirement for HS and PS: both are sent from an endpoint towards the cluster, and under asymmetric routing the sender cannot predict which network node handles the corresponding direction of the flow. Since per-flow scheduling (e.g., ECMP hashing) maps one 5-tuple to one node, a message carried with the flow's 5-tuple - whether inserted into a packet of the flow or in a separate packet copying its header - is delivered to the same node as the flow itself, which is the node that holds (for HS) or needs (for PS) the session. NS, by contrast, is sent from a network node to a known endpoint (the selected server in PSV mode, or the client in ACT mode) and can also be transmitted as a Standalone Message; carrying it inline is a performance optimization that piggybacks on a packet about to be forwarded. Inserting a message into the payload of the first packet of a TCP session makes that packet carry data (e.g., a TCP SYN with a non- empty payload). Some middleboxes drop such packets; this behavior has been observed in the deployment of TCP Fast Open [RFC7413]. Where such interference is known or detected on a path, the implementation SHOULD use the separate-packet form instead of inserting into the original packet, since the separate packet carries the message without altering the characteristics of the session's own packets. The UDP form is not affected: an option in the datagram's option area does not change the datagram's payload or its UDP length. Luo & Yan Expires 24 April 2027 [Page 12] Internet-Draft Available Session Recovery Protocol October 2026 3.4.2. Standalone Message The Standalone Message is transmitted in an independent packet with its own 5-tuples. It is encapsulated using IP/UDP [RFC0768], with IP addresses configured to ensure mutual reachability and a fixed destination port ASRP-PORT (e.g., 51200). QS, RS, RX, NA and NC messages typically use this transmission mode. 3.5. Session Creation/Recovery Scenarios This section elaborates on, through a series of typical scenarios, how the ASRP protocol achieves session backup and recovery via message interaction in the event of network node failures under different operational modes. Each scenario details the involved protocol message flows and the processing steps of each entity. 3.5.1. PSV-Scenario-1 ASRP Cluster +----------+ +--------------+ +----------+ | | ---1:PKT--> | | -----2:NS----> | | | | | | <----3:NC----- | | | client | | ASRP Nodes | | server | | | | | | | | | <--5:PKT--- | | <----4:PS----- | | +----------+ +--------------+ +----------+ Figure 5: Direct Session Creation in PSV Mode This scenario describes that, in PSV mode, a network node receives an explicit first packet (i.e., a packet whose characteristics explicitly indicate the start of a session) and directly creates a session flow. Common examples of explicit first packets include TCP SYN [RFC9293] and DNS [RFC1034] [RFC1035] query, among others. The processing flow is as follows: 1. Session Creation: Upon receiving a packet from the client (e.g., TCP SYN), the network node first creates a new session and then sends an NS message to the selected server. 2. Server Response: Upon receiving the NS message, the server stores the session state information and associates it with its local session. If a conflict occurs, it sends an NC message. In the case of asymmetric routing, when sending its first response packet, the server sends a PS message to the network node. Luo & Yan Expires 24 April 2027 [Page 13] Internet-Draft Available Session Recovery Protocol October 2026 3. Session Recovery: Upon receiving the PS message, the network node restores the session and forwards packets accordingly. The session state information backed up by the server is released upon local session termination, without requiring any additional teardown message. 3.5.2. PSV-Scenario-2 ASRP Cluster +----------+ +--------------+ +----------+ | | | | <----1:PKT---- | | | | | | | | | client | <--4:PKT--- | ASRP Nodes | -----2:QS----> | server | | | | | | | | | | | <---3:RS/RX--- | | +----------+ +--------------+ +----------+ Figure 6: Session Recovery for Server in PSV Mode This scenario describes the session recovery flow triggered by a server packet. The processing flow is as follows: 1. Session Query: Upon receiving a packet from the server, the network node searches its local session table. If no matching session is found, the node SHOULD first buffer the packet for forwarding, then sends a QS message back to the server. 2. Server Response: After receiving the QS message, the server looks up the backed-up session state information and sends an RS/RX message. 3. Session Recovery: Upon receiving an RS message, the network node creates a new local session and forwards packets accordingly. Upon receiving an RX message, the node SHOULD discard the pending packets. 3.5.3. PSV-Scenario-3 Luo & Yan Expires 24 April 2027 [Page 14] Internet-Draft Available Session Recovery Protocol October 2026 ASRP Cluster +----------+ +------------+ +------------+ | | | | ----2:QS-----> | ... | | | ---1:PKT--> | | <---3:RS/RX--- | +--------+ | | | | | ... | | server | | | | | | ... | +--------+ | | client | | ASRP Nodes | ---4:PKT/NS--> | ... | | | | | | +--------+ | | | | | | | server | | | | <--7:PKT--- | | <--5:NA/NC---- | +--------+ | | | | | <----6:PS----- | ... | +----------+ +------------+ +------------+ Figure 7: Session Creation/Recovery for Client in PSV Mode This scenario describes the session creation/recovery flow triggered by a client packet. The processing flow is as follows: 1. Query Local Session: Upon receiving a packet from the client, if no matching session is found, the network node first obtains a list of candidate servers (possibly multiple) for querying. 2. Query Backup Session: The network node sends QS messages to each candidate server. Each server replies with an RS or RX message. 3. Process Query Results: If a session is found, the network node restores the session and forwards the packet. Otherwise, for TCP packets: drop the packet. For UDP packets: create a new local session and send an NS message to the selected server. 4. Server Creates New Session: Upon receiving an NS message, the server stores the session state information and associates it with its local session. If a conflict occurs, it sends an NC message; otherwise, if the F-NA flag is set, it immediately replies with an NA packet. 5. Session Recovery: In an asymmetric routing environment, when sending its first response packet, the server sends a PS message to restore the session at the network node. In this scenario, obtaining the list of candidate servers is a key challenge. Two solutions are proposed: Luo & Yan Expires 24 April 2027 [Page 15] Internet-Draft Available Session Recovery Protocol October 2026 1. The network node derives an ordered list of candidate servers from the packet's 5-tuple using a deterministic server-selection algorithm, such as consistent hashing or history-aware consistent hashing, and sends QS messages to the candidates in order. 2. Enhance the client so that client packets carry backend server information, allowing the network node to directly extract the target server from the client packet. One such enhancement is specified in [I-D.draft-cmcc-tcp-sro], which carries the selected backend identity in a transport-layer option. ASRP works with either solution and does not depend on the SR option. For the first solution, the specific algorithm is a local implementation choice; what the protocol relies on are three properties of it: Determinism: The mapping from a session's 5-tuple to its candidate list MUST be identical on every node of the cluster, so that any node receiving a packet of a session it does not hold computes the same candidates to query. History awareness: When the backend pool changes (e.g., a server is added), the algorithm SHOULD keep the servers that previously served the affected hash region in the candidate list, so that sessions created before the change can still locate their backup holder. A removed server simply fails to answer; the recovery attempt moves on to the next candidate or is abandoned. Bounded querying: The number of candidates queried for one recovery MAY be limited to a small constant, bounding the QS traffic and the recovery latency. When the limit is reached without an RS response, the node stops querying and falls back to its local handling of packets without a session (Section 3.6). 3.5.4. ACT-Scenario-1 ASRP Cluster +----------+ +--------------+ +----------+ | | -----1:HS----> | | | | | | <----2:NS----- | | ---3:PKT--> | | | client | | ASRP Nodes | | server | | | <----5:QS----- | | <--4:PKT--- | | | | ---6:RS/RX---> | | | | +----------+ +--------------+ +----------+ Figure 8: Session Creation/Recovery in ACT Mode Luo & Yan Expires 24 April 2027 [Page 16] Internet-Draft Available Session Recovery Protocol October 2026 This scenario describes session creation at a network node and server-initiated session restoration. The processing flow is as follows: 1. Session Backup: When sending a packet without receiving an NS message, the client sends an HS message to the network node to request session backup (the client MAY rate-limit the HS messages it generates). Upon receiving the HS message, the node replies with an NS message. 2. Session Lookup: For packets from a server with no matching session, the network node identifies the target client and sends it a QS message. 3. Session Recovery: Upon receiving QS, the client sends an RS/RX message to the network node to restore the session. In step 2, identifying the target client is challenging. Two solutions are proposed: 1. Use static mapping (e.g., map destination port to client). For SNAT, client IP addresses can be statically mapped to distinct port ranges. 2. Enhance the server to embed client information in its packets, allowing the network node to extract the client address directly. 3.5.5. ACT-Scenario-2 ASRP Cluster +----------+ +--------------+ +----------+ | | ----1:PKT----> | | | | | | | | | | | client | <----2:QS----- | ASRP Nodes | ---4:PKT--> | server | | | | | | | | | ---3:RS/RX---> | | | | +----------+ +--------------+ +----------+ Figure 9: Session Recovery for Client in ACT Mode This scenario describes the client-packet-triggered session recovery. The processing flow is as follows: 1. Session Query: Upon receiving a packet from a client with no local session and without an HS message, the network node sends a QS message to the client. Luo & Yan Expires 24 April 2027 [Page 17] Internet-Draft Available Session Recovery Protocol October 2026 2. Session Recovery: The client responds with an RS/RX message; the RS message enables session restoration. 3.6. State Consistency ASRP does not need a distributed consistency protocol, because the session state has a single writer at any time and the backup is a read-only copy. The backup of a session is created by the NS message at session creation and is never modified afterwards; it is released when the local session terminates. It therefore reflects the session state at creation time. For the state that ASRP targets - the flow-defining state of a session, keyed by its 5-tuple - this snapshot remains valid for the lifetime of the session, since the key does not change. Implementations that maintain additional mutable state (e.g., timeouts or counters) recover a usable approximation of it. Recovery is a local action of one network node: the node rebuilds the session from the backup delivered in an RS message and thereafter owns the session. If, under asymmetric routing, two nodes receive packets of the same session and each recovers it independently, both hold the session locally and each forwards the packets that reach it - which is exactly how the cluster treats any session it holds. No node writes to another node's session state, so there is no split- brain condition to resolve. In this sense, a node's session table is a cache rather than a source of truth. A session that a node does not hold locally can always be rebuilt from the endpoint backup - including the complete address- and-port mapping that a full-NAT load balancer maintains - so nothing is lost when a table is dropped, a node restarts, or traffic shifts to a new node. If recovery fails (an RX response, or no response before the recovery attempt is abandoned), the network node falls back to its local handling of packets without a session, e.g., discarding them or creating a new session. 4. Protocol Details 4.1. Message Format An ASRP message consists of a fixed 12-octet header followed by a variable-length body. The header comprises the first eight fields below; the body comprises the Session-Tuple and Session-Data fields and, for the NS message, the Node-Local-IP field. The fields are defined as follows: Luo & Yan Expires 24 April 2027 [Page 18] Internet-Draft Available Session Recovery Protocol October 2026 1. Version: 1 octet. This document defines version 0 (Ver0). 2. MsgType: 1 octet, the message type: NS=0, NA=1, QS=2, RS=3, RX=4, HS=5, PS=6, NC=7. 3. STType: 1 octet, the Session-Tuple layout carried in the message body: NULL=0 (no Session-Tuple), ST44=1, ST66=2, ST46=3, ST64=4, ST4=5, ST6=6. 4. Flags: 1 octet. Bits are allocated from the least significant bit: - F-LIP6 (0x1): the Node-Local-IP carried by the NS message is an IPv6 address. - F-CC (0x2): client-side session conflict (NC message). - F-NA (0x4): NA acknowledgment requested (NS message). Unassigned bits MUST be sent as zero and ignored on receipt. 5. Length: 2 octets, the total length of the ASRP message in octets, from the first octet of the Version field through the last octet of the message body. 6. Reserved: 1 octet, reserved for future use. It MUST be sent as zero and ignored on receipt. 7. Protocol: 1 octet, transport-layer protocol (e.g., TCP, UDP). 8. Cookie: 4 octets, an opaque value used for message validation. The sender of a request message SHOULD fill this field with a value that identifies the request; the responder MUST echo it unchanged, and a backup holder MUST echo the stored NS Cookie in its PS messages. See "Cookie Handling" and the Security Considerations. 9. Session-Tuple (ST): source and destination addresses and ports. The IP address type is IPv4/IPv6. There are 6 types of ST, as follows: - ST4: IPv4-only tuple; - ST6: IPv6-only tuple; - ST44/ST66: Pairs of ST4 or ST6; - ST46/ST64: Mixed IPv4/IPv6 tuples. 10. Session-Data (SD): opaque session state information. Rules for validating these fields on receipt are specified in "Message Validation". 4.1.1. Message Header Every ASRP message begins with the following 12-octet header: Luo & Yan Expires 24 April 2027 [Page 19] Internet-Draft Available Session Recovery Protocol October 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | MsgType | STType | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: ASRP Message Header 4.1.2. Session Tuples ST4 (length 12) Format: 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 IP (IPv4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP (IPv4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: IPv4 Session Tuple Format ST6(length 36) Format: Same structure as ST4, but with IPv6 ST44(length 24) Format: ST4 pair ST66(length 72) Format: ST6 pair ST46(length 48) Format: Mixed ST pair(ST4->ST6 sequence) ST64(length 48) Format: Mixed ST pair(ST6->ST4 sequence) For messages carrying two Session-Tuples (NS, NA, NC, RS, and PS), the first Session-Tuple (ST1) MUST be the client-side tuple, and the second Session-Tuple (ST2) MUST be the server-side tuple. For messages carrying a single Session-Tuple (QS and RX), the Session- Tuple MUST be the 5-tuple of the triggering packet. 4.1.3. NS Message The NS message contains a Node-Local-IP field and two Session-Tuples. Luo & Yan Expires 24 April 2027 [Page 20] Internet-Draft Available Session Recovery Protocol October 2026 The Node-Local-IP field is located at the end of the NS message and carries the local IP address of the network node that sends the NS message. Its length is 16 octets when the F-LIP6 flag is set, and 4 octets otherwise. The client or server uses this address as the destination IP to send the NA message back to the network node. The body of the NS message follows the header: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Session-Tuples: ST44/ST66/ST46/ST64 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Session-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Node-Local-IP (IPv4 or IPv6) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ASRP NS Message Body The two Session-Tuples represent the network node's connections with the client and the server, respectively. 4.1.4. QS Message The body of the QS message follows the header: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Session-Tuple: ST4 or ST6 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Session-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: ASRP QS Message Body 4.1.5. HS Message The HS message consists of the message header followed by a 4-octet Reserved field. Luo & Yan Expires 24 April 2027 [Page 21] Internet-Draft Available Session Recovery Protocol October 2026 4.1.6. Other Messages The NA message has the same structure as the NS message, except that the Node-Local-IP field is not present. The NC, RS, and PS messages have the structure of the NA message. In the NC message, the client- side Session-Tuple remains unchanged, while the server-side Session- Tuple may be modified to reflect the conflicting session; the F-CC flag indicates whether the conflict is on the client side or the server side. The RX message has the structure of the QS message. 4.2. ASRP Packets A packet that carries a single ASRP message is referred to as an ASRP packet. An inline-ASRP packet is a packet of the flow itself: how the message is placed in it - at the head of the segment payload marked by the ASRP option, or in the datagram's option area - is specified in Section 3.4. A standalone-ASRP packet is an independent packet with its own 5-tuples, encapsulated using IP/UDP [RFC0768] with the destination port ASRP-PORT; its payload is the message. 4.2.1. Transport-Layer Transparency An inline ASRP message exists only on the wire between the sending side's ASRP module (which inserts it) and the receiving side's ASRP module (which removes or reads it). Neither the application nor either transport stack observes it. On a TCP flow, an inline message is never part of either endpoint's TCP sequence space: the sender's transport stack generated the segment without it, and the receiver's transport stack processes the segment without it. The receiving ASRP module removes the message from the head of the payload and the ASRP option from the header before the segment is handed to the transport stack. Implementations MUST NOT modify TCP sequence or acknowledgment numbers when inserting or removing an inline message; the fields requiring adjustment are the IP total length, the TCP data offset, and the transport checksums, which MUST be recomputed. After removal, the byte stream each endpoint's transport stack observes is identical to that of a session that never carried ASRP messages. On a UDP flow, no such machinery is required. The ASRP Option is carried in the datagram's option area, beyond the length indicated by the UDP header: a receiving stack that does not process UDP options ignores it by definition, and the receiving ASRP module reads the option without modifying the datagram. The datagram delivered to the application is the one the sender's application wrote. Luo & Yan Expires 24 April 2027 [Page 22] Internet-Draft Available Session Recovery Protocol October 2026 A separate packet that copies the original packet header carries no data of the flow: the receiving ASRP module processes the message and discards the packet, on both TCP and UDP flows. 4.3. Message Processing Standalone-ASRP packets are identified by the UDP destination port, while Inline-ASRP packets are identified by the ASRP option. Once an ASRP packet is identified, the ASRP message within it is then parsed and processed. 4.3.1. Message Validation Before processing any ASRP message, a receiver MUST perform the following checks and silently discard the message if any of them fails: 1. The Version field is a version the receiver implements. 2. The Length field matches the number of ASRP message octets actually present in the packet. 3. The STType field matches the MsgType: QS and RX carry a single Session-Tuple (ST4 or ST6); NS, NA, NC, RS, and PS carry a Session-Tuple pair (ST44, ST66, ST46, or ST64); HS carries no Session-Tuple (NULL). 4. The Reserved field and any unassigned flag bits are ignored. A message that passes these checks is processed according to its MsgType as described in the following subsections. 4.3.2. Cookie Handling Every ASRP message carries the 4-octet Cookie field defined in Section 4.1. The cookie associates a response with the request that triggered it. The sender of a request message (QS, NS, or HS) SHOULD fill the Cookie field with a value that identifies the request; a per-request random value is a typical choice. A responder (the sender of RS/RX, NA/NC, or the NS replying to HS) MUST copy the Cookie field of the request into the Cookie field of its response, unchanged. The Cookie is opaque on the wire and echoed verbatim, so interoperability does not depend on how it is generated; the security properties of different generation methods are discussed in the Security Considerations. Luo & Yan Expires 24 April 2027 [Page 23] Internet-Draft Available Session Recovery Protocol October 2026 A node that receives a response SHOULD verify that the Cookie field matches the outstanding request it is applying the response to, and discard the response otherwise. A backup holder MUST store the Cookie of the NS message that created the backup, and MUST echo that Cookie in every PS message it sends for that session. A network node that receives a PS message SHOULD verify the echoed Cookie when it can - e.g., by matching its local record for the session, or by recomputing a Cookie whose derivation it is configured with - and silently discard the PS message if verification fails. A PS message whose Cookie the node cannot verify is processed according to the node's local policy; see the Security Considerations. An implementation that does not use cookie validation MAY set the Cookie field of its requests to zero and skip the verification above; see the Security Considerations for how this affects message validation. Stronger message authentication, e.g., based on a message authentication code, can be introduced as a future extension carried in the variable-length Session-Data field, without any change to the message format. 4.3.3. NS Message When a client or server receives an NS message, it MUST first check for session conflicts on the client side and then on the server side. A client-side conflict occurs when the client-side tuple matches an existing backed-up session on either side. If a conflict is found, it MUST clear the F-NA flag and send an NC message, with the F-CC flag set to indicate a client-side conflict. If no conflict is found, it MUST back up the session state information together with the Cookie of the NS message, and hand the embedded packet (if present) over to the system. If the F-NA flag is set, it MUST send an NA message. The F-NA flag SHOULD be set when the session is created from a non- explicit first packet; explicit first packets (e.g., TCP SYN or DNS query) do not require it. If an NS message is lost, in PSV mode a TCP SYN retransmission or subsequent packets regenerate NS messages until an NA message is received; in ACT mode, subsequent packets generate HS messages, prompting the network node to retransmit the NS message. Luo & Yan Expires 24 April 2027 [Page 24] Internet-Draft Available Session Recovery Protocol October 2026 NS messages may be generated in both PSV and ACT modes. The handling procedures are described in Figure 5, Figure 7, and Figure 8. 4.3.4. NA Message The destination IP of the NA packet MUST be set to the Node-Local-IP field carried in the received NS message, and the destination port MUST be set to ASRP-PORT. Upon receiving an NA message, the network node considers that the corresponding NS message has been processed by the responder, and MUST NOT send any further NS messages for this session. 4.3.5. NC Message The destination IP of the NC packet MUST be set to the Node-Local-IP field carried in the received NS message, and the destination port MUST be set to ASRP-PORT. Upon receiving an NC message, the network node considers that the session conflicts with an existing local session on the responder. If the F-CC flag is set, the conflict is on the client side; otherwise, it is on the server side. The network node SHOULD handle the conflict according to its local policy. 4.3.6. QS Message The source IP of the QS packet MUST be set to the network node's local IP (obtainable from configuration), and the destination IP MUST be set to the client's or server's IP (obtainable from the forwarded packet as described in Figure 6 and Figure 9, or derived via algorithmic mapping to the client or server as described in Figure 7 and Figure 8). The source port MUST be randomly generated, and the destination port MUST be set to ASRP-PORT. The backup holder MUST index the backed-up session by both the client-side and the server-side 5-tuples. When a client or server receives a QS packet, it MUST look up the backed-up session whose client-side or server-side 5-tuple matches the Session-Tuple in the QS message. If a match is found, it MUST return an RS message; otherwise, it MUST return an RX message. If a QS message is lost, subsequent packets will trigger the generation of new QS packets, continuing the attempt to recover the session. QS messages may be generated in both PSV and ACT modes. The handling procedures are described in Figure 6, Figure 7, and Figure 9. Luo & Yan Expires 24 April 2027 [Page 25] Internet-Draft Available Session Recovery Protocol October 2026 4.3.7. RS Message The RS packet MUST reuse the protocol header of the QS packet, with the source and destination IP addresses swapped. When a network node receives an RS packet, it MUST recover the session and forward packets according to the session. If an RS message is lost, subsequent QS messages will continue the attempt to recover the session, thereby triggering retransmission of the RS message. RS messages may be generated in both PSV and ACT modes. The handling procedures are described in Figure 5, Figure 6, Figure 7, Figure 8, and Figure 9. 4.3.8. RX Message Upon receiving an RX message, the network node MUST follow the processing procedures described in the respective scenarios under PSV/ACT mode. 4.3.9. HS Message The network node identifies the session by the 5-tuple of the packet carrying the HS message. If a local session is found, it MUST return an NS message for that session to the client, addressed to the source IP of that packet; otherwise, no NS message is returned. HS messages are only generated in ACT mode. The handling procedure is described in Figure 8. 4.3.10. PS Message The source IP, destination IP, and source port of the PS packet MUST be copied from the packet sent by the server. When a network node receives a PS message, it SHOULD verify the echoed Cookie as described in "Cookie Handling" before recovering the session; it extracts the forwarded packet (if present) and forwards it according to the session. PS messages are only generated in PSV mode. The handling procedure is described in Figure 5 Figure 7. Luo & Yan Expires 24 April 2027 [Page 26] Internet-Draft Available Session Recovery Protocol October 2026 5. Security Considerations ASRP messages may be subject to forgery, replay, or flooding by attackers who are able to inject traffic into the network that carries them. ASRP deployments can counter this with two layers of message validation. Both draw only on information available to the validating node - including, where deployed, a cluster-wide key, which is deployment configuration rather than protocol state - so no protocol-level trust relationship between nodes is required. Cookie-based validation: Every ASRP message carries a 4-octet Cookie field. For a request/response pair (QS and RS/RX, NS and NA/NC, HS and the NS replying to it), a node that sends a request fills the Cookie and verifies that the response echoes it; this binds the response to an outstanding request of the receiving node, so that a forged response that guesses the Cookie, or a replayed response from an earlier request, can be recognized and discarded. A backup holder likewise echoes in its PS messages the Cookie of the NS message that created the backup, and a network node verifies the echoed Cookie before recovering a session; this binds a PS message to a session the cluster actually created. This document specifies the echo and verification framework and intentionally leaves Cookie generation to the implementation and deployment, since the Cookie is opaque and echoed verbatim: a per-request random value resists guessing and replay, and a value derived with a key shared across the cluster additionally lets any node verify a PS message, which matters under asymmetric routing, where the node receiving a PS message need not be the node that created the session. Session-legitimacy validation: Nodes SHOULD validate the session referenced by a message against application-level policies, such as verifying that the session points to a known and healthy server in a load-balancing deployment, or that the address translation complies with configured rules in a NAT deployment. Nodes that perform this validation MUST discard messages that fail it and MUST NOT create a new session for them. Implementations MAY apply rate limiting to ASRP messages as appropriate, e.g., to contain QS floods [RFC4987]. ASRP responses are comparable in size to the requests that trigger them, so the protocol itself provides no amplification. Luo & Yan Expires 24 April 2027 [Page 27] Internet-Draft Available Session Recovery Protocol October 2026 6. Privacy Considerations ASRP messages carry the 5-tuple of the session they describe. This is the same information that is visible in the session's own packets; observing ASRP traffic reveals the existence of a session between two endpoints and their addresses, but nothing beyond what the carried traffic already exposes. The Node-Local-IP field of an NS message discloses the address of the network node that created the session to the backup holder. This is information the backup holder requires in order to return NA/NC messages, and the network node address is in any case observable in the forwarded traffic of the session. ASRP introduces no new identifiers that persist across sessions and no tracking mechanism. Operators who wish to limit the visibility of session metadata can apply the usual operational measures to ASRP traffic, e.g., restricting routing of the ASRP-PORT destination to the serving domain. 7. IANA Considerations This document defines an application-layer protocol (ASRP). All values of the MsgType, STType, and Flags fields used by this version of the protocol are defined in this specification. New values MUST be defined via an update to this document or a successor specification; a future standards-track version of ASRP SHOULD request the creation of IANA registries for these fields. The implementation of this protocol requires the allocation of a TCP option Kind, a UDP option Kind, and a UDP destination port: 7.1. TCP Option Kind The ASRP option (see Section 3.4) requires the allocation of a TCP option Kind number from the TCP option kind registry: +======+========+=========+===============+ | Kind | Length | Meaning | Reference | +======+========+=========+===============+ | TBD | 2 | ASRP | This document | +------+--------+---------+---------------+ Table 3 7.2. UDP Option Kind The ASRP option requires the allocation of a UDP option Kind number from the "UDP Option Kind Numbers" registry [RFC9868]: Luo & Yan Expires 24 April 2027 [Page 28] Internet-Draft Available Session Recovery Protocol October 2026 +======+==========+=========+===============+ | Kind | Length | Meaning | Reference | +======+==========+=========+===============+ | TBD | variable | ASRP | This document | +------+----------+---------+---------------+ Table 4 7.3. UDP Destination Port QS/RS/RX/NA/NC messages are encapsulated within UDP datagrams for transmission. A fixed UDP destination port number is required so that the receiving end can identify and process such encapsulated packets. Service Name: asrp Port Number: 51200 (proposed value for current experimentation) Transport Protocol: udp Description: Used for receiving UDP-encapsulated ASRP protocol messages. For experimental implementations and interoperability testing prior to IANA assignment, UDP port 51200 MAY be used as a temporary default. This port falls within the dynamic/private port range (49152-65535) reserved for local or temporary use and documentation examples [RFC6335]. IANA is requested to assign a permanent port number in the "User Ports" range (1024-49151) for the "asrp" service in the "Service Name and Transport Protocol Port Number Registry", with a reference to this document. 7.4. Experimental Use Prior to IANA assignment of permanent option Kind values, implementations deployed for experimentation or interoperability testing SHOULD use the option Kind values reserved for experimental use, together with an Experiment Identifier (ExID), as described in [RFC6994] for TCP and [RFC9868] for UDP. 8. References 8.1. Normative References Luo & Yan Expires 24 April 2027 [Page 29] Internet-Draft Available Session Recovery Protocol October 2026 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP", RFC 9868, DOI 10.17487/RFC9868, October 2025, . 8.2. Informative References [I-D.draft-cmcc-tcp-sro] Luo, Z. and H. Yan, "The Session Recovery (SR) Option for TCP", Work in Progress, Internet-Draft, draft-cmcc-tcp- sro-02, 14 September 2026, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, . [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, . [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . Luo & Yan Expires 24 April 2027 [Page 30] Internet-Draft Available Session Recovery Protocol October 2026 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . Appendix A. Implementation Status Note to the RFC Editor: Please remove this section before publication. ASRP has been implemented twice, through two independent technology stacks, and the implementations are interoperable: Luo & Yan Expires 24 April 2027 [Page 31] Internet-Draft Available Session Recovery Protocol October 2026 * A Linux kernel module extending IPVS, implementing the network- node role in PSV mode: session creation with inline NS insertion, QS/RS exchange for session recovery, NA/NC handling, cookie verification of responses, and the ASRP-PORT UDP listener. * An eBPF implementation based on traffic-control programs, implementing the backup-holder role on the endpoints: NS backup from session first packets, session reconstruction from PS messages, and response generation with cookie echoing. The two stacks were interoperability tested on a three-node testbed (client, load-balancing node, backend server), covering direct session creation, recovery after cluster session-table loss simulating node failure, and the fallback when no backed-up session exists. Recovery is driven by the retransmission behavior of the recovered session, as described in the scenarios. The small footprint of both implementations - a kernel module and a set of eBPF programs - indicates that endpoint support for ASRP is a modest engineering effort. Appendix B. Acknowledgments The authors would like to thank all individuals who have provided valuable feedback and contributions during the development of this document. Authors' Addresses Zhaoyu Luo (editor) CMCC No. 58 Kunlunshan Road Suzhou 215000 China Email: lluozy@yeah.net Haishuang Yan CMCC No. 58 Kunlunshan Road Suzhou 215000 China Email: yanhaishuang_yewu@cmss.chinamobile.com Luo & Yan Expires 24 April 2027 [Page 32]