RFC 5352
Aggregate Server Access Protocol (ASAP)
RFC 5352: Aggregate Server Access Protocol (ASAP) 💖
Part 1 of 12 🎀
- Network Working Group 🌸
- Authors: R. Stewart, Q. Xie (The Resource Group), M. Stillman (Nokia), and M. Tuexen (Muenster Univ. of Applied Sciences) 👑
- Category: Experimental 🧪
- Date: September 2008 📅
- Obsoletes / Updates: This title block has no Obsoletes or Updates line, so nothing is listed there 🙈
Status of This Memo ✨
Okay so this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind, and the authors are asking for discussion and suggestions for improvement 💬. Distribution of this memo is unlimited 🦋.
Abstract 🌈
Bestie, ASAP (that's RFC 5352 💅) teams up with ENRP (RFC 5353) to give you a high-availability data transfer mechanism over IP networks 🔥. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es). That means the binding between the endpoint and its physical IP address(es) is basically gone 🫶, and that binding is normally a single point of failure 💀.
ASAP also defines each logical communication destination as a pool 🏊♀️. That gives you full transparent support for server pooling and load sharing ✨. It's also dynamically scalable, so members of a server pool can be added or removed at any time without interrupting the service 💖. Iconic 😭.
ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol other than SCTP MUST have an accompanying transport mapping document 📄. Also, ngl, ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol 🫶. It should be noted that this is a strict rule 🔒.
The high-availability server pooling comes from combining two protocols, ASAP and ENRP 🧚. ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management 💅. Meanwhile, ENRP defines the high-availability Pool Handle translation service 👑. Teamwork makes the dream work 🌸.
Table of Contents 🍓
1. Introduction ....................................................4
1.1. Definitions ................................................4
1.2. Conventions ................................................5
1.3. Organization of This Document ..............................6
1.4. Scope of ASAP ..............................................6
1.4.1. Extent of the Handlespace ...........................6
2. Message Definitions .............................................6
2.1. ASAP Parameter Formats .....................................7
2.2. ASAP Messages ..............................................7
2.2.1. ASAP_REGISTRATION Message ...........................7
2.2.2. ASAP_DEREGISTRATION Message .........................8
2.2.3. ASAP_REGISTRATION_RESPONSE Message ..................9
2.2.4. ASAP_DEREGISTRATION_RESPONSE Message ...............10
2.2.5. ASAP_HANDLE_RESOLUTION Message .....................10
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message ............11
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message ...................13
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message ...............14
2.2.9. ASAP_ENDPOINT_UNREACHABLE Message ..................14
2.2.10. ASAP_SERVER_ANNOUNCE Message ......................15
2.2.11. ASAP_COOKIE Message ...............................16
2.2.12. ASAP_COOKIE_ECHO Message ..........................16
2.2.13. ASAP_BUSINESS_CARD Message ........................17
2.2.14. ASAP_ERROR Message ................................17
3. Procedures .....................................................18
3.1. Registration ..............................................18
3.2. De-Registration ...........................................21
3.3. Handle Resolution .........................................23
3.4. Endpoint Keep Alive .......................................25
3.5. Unreachable Endpoints .....................................26
3.6. ENRP Server Hunt Procedures ...............................27
3.7. Handling ASAP Endpoint to ENRP Server
Communication Failures ....................................28
3.7.1. SCTP Send Failure ..................................28
3.7.2. T1-ENRPrequest Timer Expiration ....................29
3.7.3. Registration Failure ...............................29
3.8. Cookie Handling Procedures ................................29
3.9. Business Card Handling Procedures .........................30
4. Roles of Endpoints .............................................31
5. SCTP Considerations ............................................31
6. The ASAP Interfaces ............................................31
6.1. Registration.Request Primitive ............................32
6.2. Deregistration.Request Primitive ..........................32
6.3. CachePopulateRequest Primitive ............................33
6.4. CachePurgeRequest Primitive ...............................33
6.5. DataSendRequest Primitive .................................33
6.5.1. Sending to a Pool Handle ...........................34
6.5.2. Pool Element Selection .............................35
6.5.2.1. Round-Robin Policy ........................35
6.5.3. Sending to a Pool Element Handle ...................35
6.5.4. Send by Transport Address ..........................37
6.5.5. Message Delivery Options ...........................37
6.6. Data.Received Notification ................................38
6.7. Error.Report Notification .................................39
6.8. Examples ..................................................39
6.8.1. Send to a New Pool .................................39
6.8.2. Send to a Cached Pool Handle .......................40
6.9. PE Send Failure ...........................................41
6.9.1. Translation.Request Primitive ......................41
6.9.2. Transport.Failure Primitive ........................42
7. Timers, Variables, and Thresholds ..............................42
7.1. Timers ....................................................42
7.2. Variables .................................................42
7.3. Thresholds ................................................43
8. IANA Considerations ............................................43
8.1. A New Table for ASAP Message Types ........................43
8.2. Port Numbers ..............................................44
8.3. SCTP Payload Protocol Identifier ..........................44
8.4. Multicast Addresses .......................................44
9. Security Considerations ........................................44
9.1. Summary of RSerPool Security Threats ......................45
9.2. Implementing Security Mechanisms ..........................46
9.3. Chain of Trust ............................................49
10. Acknowledgments ...............................................50
11. References ....................................................50
11.1. Normative References .....................................50
11.2. Informative References ...................................511. Introduction ✨
Okay, intro time 🎀. The Aggregate Server Access Protocol (ASAP), when used together with the Endpoint Name Resolution Protocol [RFC5353], gives you a high-availability data-transfer mechanism over IP networks 🌐. It uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es) 🦋. So the binding between the communication endpoint and its physical IP address(es) is effectively gone, and that binding would normally be a single point of failure 💀.
When multiple receiver instances exist under the same handle (aka a server pool) 🏊♀️, an ASAP Endpoint selects one Pool Element (PE). The selection follows the current load sharing policy indicated by the server pool 🎯. Then it delivers its message to the selected PE 💌.
While the message is being delivered, ASAP can monitor the reachability of the selected PE 👀. If that PE turns out to be unreachable, ASAP can automatically pick another PE under that pool (if one exists) and try delivering to it. It does this before notifying the message sender (an ASAP User) of the failure ✨. In other words, ASAP is capable of transparent failover amongst PE instances within a server pool 🔁💖.
ASAP depends on ENRP, which provides a high-availability Pool Handlespace 🧚. ASAP handles the abstraction of the underlying transport technologies, load distribution management, and fault management 🛠️. It also handles presentation to the upper layer (aka an ASAP User) through a unified primitive interface 💅.
When SCTP [RFC4960] is the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy that SCTP provides 🫶.
This document defines the ASAP portion of the high-availability server pool 👑. 🌈
1.1. Definitions
okay bestie, let's get into the vocab 📖💖 this doc uses the following terms:
- ASAP User: Either a PE or Pool User (PU) that uses ASAP. 🫶
- Business Card: When presented by a PU or PE, it specifies the pool the sender belongs to and provides a list of alternate PEs in case of failovers. 💼
- Operational Scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols. 👀
- Pool (or Server Pool): A collection of servers providing the same application functionality. 🌸
- Pool Handle: A logical pointer to a pool. Each server pool will be identifiable in the operational scope of the system by a unique Pool Handle. 🎀
- Pool Element: A server entity having registered to a pool. ✨
- Pool User: A server pool user. 💅
- Pool Element Handle (or Endpoint Handle): A logical pointer to a particular Pool Element in a pool, consisting of the Pool Handle and a destination transport address of the Pool Element. 🦋
- Handlespace: A cohesive structure of Pool Handles and relations that may be queried by an internal or external agent. 🧚
- Home ENRP Server: The ENRP server to which a PE or PU currently sends all namespace service requests. A PE must only have one Home ENRP server at any given time, and both the PE and its Home ENRP server MUST know and keep track of this relationship. A PU should select one of the available ENRP servers as its Home ENRP server, but the collective ENRP servers may change this by the sending of an
ASAP_ENDPOINT_KEEP_ALIVEmessage. 👑 - ENRP Client Channel: The communication channel through which an ASAP User sends all namespace service requests. The client channel is usually defined by the transport address of the Home ENRP server and a well-known port number. The channel MAY make use of multicast or a named list of ENRP servers. 📡
- Network Byte Order: Most significant byte first, aka Big Endian. 🌈
- Transport Address: A transport address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol). 🍓
1.2. Conventions
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]. 📜✨
1.3. Organization of This Document
Section 2 details the ASAP message formats. In Section 3, we provide detailed ASAP procedures for the ASAP implementer. Section 4 summarizes which messages need to be supported by which nodes, and Section 5 describes the usage of SCTP. In Section 6, details of the ASAP interface are given, focusing on the communication primitives between ASAP, the applications above ASAP, and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layers). Also included in this discussion are relevant timers and configurable parameters, as appropriate. Section 7 provides threshold and protocol variables. 🗺️
It should be noted that variables, timers, and constants are used in the text when necessary. The complete list can be found in Section 7. 💜
1.4. Scope of ASAP
The requirements for high availability and scalability do not imply requirements on shared state and data. ASAP does not provide transaction failover. If a host or application fails during the processing of a transaction, this transaction may be lost. Some services MAY provide a way to handle the failure, but this is not guaranteed. ASAP MAY provide hooks to assist an application in building a mechanism to share state but ASAP in itself does NOT share any state. 🙈
1.4.1. Extent of the Handlespace
The scope of ASAP/ENRP is NOT Internet-wide. The handlespace is neither hierarchical nor arbitrarily large like DNS. A flat peer-to-peer model is detailed. Pools of servers will exist in different administrative domains. For example, suppose the use of ASAP and ENRP is wanted. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact a server pool in Japan instead of North America. The PU would use DNS to get the list of IP addresses of the Japanese server pool; that is, the ENRP client channel in Japan. From there, the PU would query the Home ENRP server it established and then directly contact the PE(s) of interest. 🌏💖
2. Message Definitions ✨
All messages, as well as their fields described below, shall be in network byte order during transmission. For fields with a length bigger than 4 bytes, a number in a pair of parentheses may follow the field name to indicate the length of the field in number of bytes. 📏
2.1. ASAP Parameter Formats
The basic message format and all parameter formats can be found in [RFC5354]. Note also that all ASAP messages exchanged between an ENRP server and a PE MUST use SCTP as transport, while ASAP messages exchanged between an ENRP server and a PU MUST use either SCTP or TCP as transport. PE to PU data traffic MAY use any transport protocol specified by the PE during registration. 🚦
2.2. ASAP Messages
This section details the individual messages used by ASAP. These messages are composed of a standard message format found in Section 4 of [RFC5354]. The parameter descriptions can be found in [RFC5354]. 📬
The following ASAP message types are defined in this section:
Type Message Name
----- -------------------------
0x00 - (Reserved by IETF)
0x01 - ASAP_REGISTRATION
0x02 - ASAP_DEREGISTRATION
0x03 - ASAP_REGISTRATION_RESPONSE
0x04 - ASAP_DEREGISTRATION_RESPONSE
0x05 - ASAP_HANDLE_RESOLUTION
0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE
0x07 - ASAP_ENDPOINT_KEEP_ALIVE
0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK
0x09 - ASAP_ENDPOINT_UNREACHABLE
0x0a - ASAP_SERVER_ANNOUNCE
0x0b - ASAP_COOKIE
0x0c - ASAP_COOKIE_ECHO
0x0d - ASAP_BUSINESS_CARD
0x0e - ASAP_ERROR
others - (Reserved by IETF)Figure 1
2.2.1. ASAP_REGISTRATION Message
The ASAP_REGISTRATION message is sent by a PE to its Home ENRP server to either create a new pool or to add itself to an existing pool. The PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle parameter and the Pool Element parameter. The Pool Handle parameter specifies the name to be registered. The Pool Element parameter MUST be filled in by the registrant, as outlined in Section 3.1. Note that the PE sending the registration message MUST send the message using an SCTP association. Furthermore, the IP address(es) of the PE that is registered within the Pool Element parameter MUST be a subset of the IP address(es) used in the SCTP association, regardless of the registered transport protocol. 🧩
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 = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Pool Handle Parameter:
See [RFC5354].
Pool Element Parameter:
See [RFC5354].
2.2.2. ASAP_DEREGISTRATION Message
The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP server to remove itself from a pool to which it registered. 🚪
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 = 0x02 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++Pool Handle Parameter:
See [RFC5354].
PE Identifier Parameter:
See [RFC5354].
The PE sending the ASAP_DEREGISTRATION MUST fill in the Pool Handle and the PE identifier parameter in order to allow the ENRP server to verify the identity of the endpoint. Note that de-registration is NOT allowed by proxy; in other words, a PE may only de-register itself. 🔐
2.2.3. ASAP_REGISTRATION_RESPONSE Message
The ASAP_REGISTRATION_RESPONSE message is sent in response by the Home ENRP server to the PE that sent an ASAP_REGISTRATION message. 💌
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 = 0x03 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R (Reject) Flag:
When set to '1', this flag indicates that the ENRP server sending this message has rejected the registration. Otherwise, when this flag is set to '0', this indicates the registration has been granted. ✅❌
Pool Handle Parameter:
See [RFC5354].
PE Identifier Parameter:
See [RFC5354].
Operational Error Parameter (optional):
See [RFC5354].
This parameter is included if an error or some atypical events occurred during the registration process. When the R flag is set to '1', this parameter, if present, indicates the cause of the rejection. When the R flag is set to '0', this parameter, if present, serves as a warning to the registering PE, informing it that some of its registration values may have been modified by the ENRP server. If the registration was successful and there is no warning, this parameter is not included. ⚠️🩷
2.2.4. ASAP_DEREGISTRATION_RESPONSE Message ✨
okay so the ASAP_DEREGISTRATION_RESPONSE message is the reply the Home ENRP server sends back to a PE 💅 It shows up either because the PE sent an ASAP_DEREGISTRATION message, or because the PE's registration life in the pool ran out 🥺
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 = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Pool Handle Parameter: see [RFC5354] 🎀
PE Identifier Parameter: see [RFC5354] 🎀
Operational Error: see [RFC5354] 🎀
This parameter is included if an error or some atypical events occurred during the de-registration process. If the de-registration was successful, this parameter is not included 🫶
2.2.5. ASAP_HANDLE_RESOLUTION Message 🔍
the ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to its Home ENRP server 💜 Its whole job is to turn a Pool Handle into a list of the Pool Elements that belong to that pool. Iconic, honestly.
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 = 0x05 |0|0|0|0|0|0|0|S| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The 'S' bit:
so the 'S' bit, if set to '1', asks the Home ENRP server to keep sending updates for this Pool whenever the Pool changes 🔥 This lasts for the whole lifetime of the SCTP association. The updates come in as extra ASAP_HANDLE_RESOLUTION_RESPONSE messages, so the user doesn't have to send another ASAP_HANDLE_RESOLUTION each time 🙌
If the 'S' bit is set to '0', no Dynamic updates are requested. Bestie, that's the whole vibe 🌸
Heads up, this part is lowkey important 👀 If a new Home ENRP server gets adopted, any 'dynamic update request' has to be re-sent to the new Home ENPR server if the endpoint still wants updates. The ENRP servers do not share state about which of their PUs are asking for automatic updates. So when the Home ENRP server changes, the PU has to send an ASAP_HANDLE_RESOLUTION message again with the 'S' bit set to '1' 🥹 Also, the 'S' bit only causes Dynamic updates of a Pool when that Pool exists. If a negative response comes back, no further updates to the Pool (when it is created) will happen. Not me being dramatic about this, it's just how it works 💀
Pool Handle Parameter: see [RFC5354] 🎀
2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE Message 💌
the ASAP_HANDLE_RESOLUTION_RESPONSE message is the reply from the Home ENRP server of the PU or PE that sent an ASAP_HANDLE_RESOLUTION message ✨ It also gets sent periodically when the Pool changes, but only if the PU asked for Dynamic updates.
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 = 0x06 |0|0|0|0|0|0|0|A| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+'A' bit:
this bit is set to '1' if the ENRP server accepts the request to send automatic updates (aka the 'S' bit was set on the request) 🙆♀️ If it's set to '0', then one of three things happened: the ENRP server does not support automatic updates, it has resource issues and can't supply this feature, or the user never asked for it in the first place 🤷♀️
Pool Handle Parameter: see [RFC5354] 🎀
Overall PE Selection Policy (optional): see [RFC5354] 🎀
This parameter can be present when the response is positive. If it's there, it tells you the overall pool member selection policy of the pool. If it's not there, a Round-Robin overall pool member selection policy is assumed 🌈 This parameter is not present when the response is negative.
Note, any load policy parameter within a Pool Element parameter (if present) MUST be ignored, and MUST NOT be used to determine the overall pool member selection policy. Like, don't even look at it for this 🙅♀️
Pool Element Parameters (optional): see [RFC5354] 🎀
When the response is positive, an array of PE parameters is included, showing the current info about the PEs in the named pool 🧚 At least one PE parameter MUST be present. When the response is negative, no PE parameters are included.
Operational Error (optional): see [RFC5354] 🎀
the presence of this parameter means the response is negative, which is the ENRP server basically saying "nope" to the handle resolution request 💀 The cause code in this parameter (if present) tells you why it was rejected, like if the requested Pool Handle wasn't found. No Operational Error means the response is positive 💖
2.2.7. ASAP_ENDPOINT_KEEP_ALIVE Message 💓
the ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a PE 🫶 It checks that the PE is still reachable, and if the 'H' bit is set to '1', it also tells the PE to adopt the sending server as its new Home ENRP server 👑 No matter what the 'H' bit says, an ASAP Endpoint MUST respond with an ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages that arrive. Always reply, no ghosting 🥰
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 = 0x07 |0|0|0|0|0|0|0|H| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+H (Home ENRP server) Flag:
when set to '1', this means the ENRP server sending the message wants to be the Home ENRP server of whoever receives it 🏠
Server Identifier: 32 bits (unsigned integer) 🔢 This is the ID of the ENRP server, as discussed in [RFC5353].
Pool Handle Parameter: see [RFC5354] 🎀
2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK Message 🦋
the ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response to an ASAP_ENDPOINT_KEEP_ALIVE message from an ENRP server. Simple, clean, iconic ✨
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 = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Pool Handle Parameter: see [RFC5354] 🎀
PE Identifier Parameter: see [RFC5354] 🎀
2.2.9. ASAP_ENDPOINT_UNREACHABLE Message 🚨
the ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to its Home ENRP server to report a PE that can't be reached 😤
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 = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Pool Handle Parameter: see [RFC5354] 🎀
PE Identifier Parameter: see [RFC5354] 🎀
2.2.10. ASAP_SERVER_ANNOUNCE Message 📣
the ASAP_SERVER_ANNOUNCE message is sent by an ENRP server so that PUs and PEs know the transport info they need to connect to it 🌟
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 = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ..... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport Param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Server Identifier: 32 bits (unsigned integer) 🔢 This is the ID of the ENRP server, as discussed in [RFC5353].
Transport Parameters (optional): see [RFC5354] for the SCTP and TCP Transport parameters 🚚
Only SCTP and TCP Transport parameters are allowed for use within the SERVER_ANNOUNCE message. So no other transport types in this one, periodt 💅
2.2.11. ASAP_COOKIE Message 💌
Okay so the ASAP_COOKIE message is what a PE sends to a PU 💅 It's basically the PE's way of passing along info it wants to share, using a control channel 🎀
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 = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cookie Parameter: go check [RFC5354] for the full scoop on this one 📖✨
2.2.12. ASAP_COOKIE_ECHO Message 🦋
The ASAP_COOKIE_ECHO message is the comeback move 🔥 When a PU notices its current PE has failed, it sends this to a new PE to help with failover 🚨 The Cookie Parameter it sends is the latest one it got from the PE that just went down 💀
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 = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cookie Parameter: see [RFC5354] 💜
2.2.13. ASAP_BUSINESS_CARD Message 💼
The ASAP_BUSINESS_CARD message is the networking version of swapping contact info 🍓 It can be sent by a PU to a PE, or from a PE to a PU, over a control channel. Its whole job is to share the pool handle and a preferred failover ordering ✨
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 = 0x0d |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Pool Handle Parameter: see [RFC5354] 🎀
Pool Element Parameters: also see [RFC5354] 🫶
2.2.14. ASAP_ERROR Message 🚨
The ASAP_ERROR message is the "wait, that's not a thing I recognize" reply 🙈 An ASAP Endpoint sends it back to the sender when it gets an unknown message or an unknown parameter, so the problem gets reported 💅
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 = 0x0e |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Operational Error Parameter: see [RFC5354] ✨
When an ASAP Endpoint gets an ASAP message with an unknown message type, or a message of a known type that has an unknown parameter, it SHOULD handle the unknown message or the unknown parameter using the unrecognized message and parameter handling rules in Section 3 🧚
If an error report back to the sender is needed under those rules, the ASAP endpoint that spotted the error SHOULD send back an ASAP_ERROR message. That message includes an Operational Error parameter with the right cause code, cause length, and case-specific info 🔥
3. Procedures 🎬
This part is all about the methods and procedures an internal ASAP Endpoint uses 💖 Timers and recovery actions for failure detection and management get covered here too 🌈 Also, heads up: ASAP messages sent between a PE and a PU are identified by an SCTP Payload Protocol Identifier (PPID) 🦋
3.1. Registration ✨
okay bestie, so when a PE wants to start or join a server pool 🌸, it MUST use the steps in this section to register. Usually a user request primitive kicks this off (we cover that in Section 6.1 💅). The PE MUST register over an SCTP association between itself and its Home ENRP server. If it doesn't have a Home ENRP server yet, it MUST follow the procedures in Section 3.6 first 🫶.
Once the PE's ASAP Endpoint has established its Home ENRP server, these steps MUST be followed to register:
- R1) The PE's SCTP endpoint used to communicate with the Home ENRP server MUST be bound to all IP addresses that will be used by the PE (regardless of which transport protocol will be used to service user requests to the PE) 🦋.
- R2) The PE's ASAP Endpoint MUST formulate an
ASAP_REGISTRATIONmessage, as defined in Section 2.2.1 📝. While formulating it, the PE MUST:- R2.1) Fill in the
Pool Handleparameter to specify which server pool the ASAP Endpoint wants to join 🎀. - R2.2) Fill in the PE identifier using a good-quality randomly generated number ([RFC4086] provides some information on randomness guidelines) 🎲.
- R2.3) Fill in the
Registration Lifetimeparameter with the number of seconds this registration is valid for. Note that a PE that wishes to continue service MUST re-register before the registration expires ⏰. - R2.4) Fill in a
User Transportparameter to specify the type of transport and the data/control channel usage the PE is willing to support. Note, in joining an existing server pool, the PE MUST follow the overall transport type and overall data/control channel usage of the pool. Otherwise, the registration may be rejected by the ENRP server 🚫. - R2.5) Fill in the preferred
Pool Member Selection Policyparameter 🍓.
- R2.1) Fill in the
- R3) Send the
ASAP_REGISTRATIONmessage to the Home ENRP server using SCTP 🚀. - R4) Start a T2-registration timer ⏱️.
Note: the PE does not need to fill in the optional ASAP transport parameter. The ASAP transport parameter will be filled in and used by the Home ENRP server.
If the T2-registration timer expires before receiving an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the PE shall start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server, the PE SHOULD restart the registration procedure 🔄.
At the reception of the registration response, the PE MUST stop the T2-registration timer. If the response indicates success, the PE is registered and will be considered an available member of the server pool 🎉. If the registration response indicates a failure, the PE must either re-attempt registration after correcting the error or return a failure indication to the PE's upper layer. The PE MUST NOT re-attempt registration without correcting the error condition 🙅♀️.
At any time, a registered PE MAY wish to re-register to either update its member selection Policy Value or registration expiration time. When re-registering, the PE MUST use the same PE identifier 🪪.
After successful registration, the PE MUST start a T4-reregistration timer. At its expiration, a re-registration SHOULD be made starting at step R1, including (at completion) restarting the T4-reregistration timer 🔁.
Note that an implementation SHOULD keep a record of the number of registration (and re-registration) attempts it makes in a local variable that gets set to zero before the initial registration attempt to the Home ENRP server or after a successful re-registration. If repeated registration timeouts or failures occur and the local count exceeds the Threshold 'MAX-REG-ATTEMPT', the implementation SHOULD report the error to its upper layer and stop attempting registration 📊.
The ENRP server handles the ASAP_REGISTRATION message according to the following rules 👑:
- If the named pool does not exist in the handlespace, the ENRP server MUST create a new pool with that handle in the handlespace and add the PE to the pool as its first PE.
When a new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the first PE, the overall pool transport type MUST be set to the transport type indicated by the PE, and the overall pool data/control channel configuration MUST be set to what is indicated in the Transport Use field of the User Transport parameter by the registering PE.
- If the named pool already exists in the handlespace, but the requesting PE is not currently a member of the pool, the ENRP server will add the PE as a new member to the pool.
However, before adding the PE to the pool, the server MUST check if the policy type, transport type, and transport usage indicated by the registering PE is consistent with those of the pool. If different, the ENRP server MUST reject the registration 🚧.
- If the named pool already exists in the handlespace and the requesting PE is already a member of the pool, the ENRP server SHOULD consider this as a re-registration case. The ENRP server MUST perform the same tests on policy, transport type, and transport use, as described above. If the re-registration is accepted after the test, the ENRP server SHOULD replace the attributes of the existing PE with the information carried in the received
ASAP_REGISTRATIONmessage 🔧. - After accepting the registration, the ENRP server MUST assign itself the owner of this PE. If this is a re-registration, the ENRP server MUST take over ownership of this PE, regardless of whether the PE was previously owned by this server or by another server. The ENRP server MUST also record the SCTP transport address from which it received the
ASAP_REGISTRATIONin the ASAP Transport parameter TLV inside the PE parameter of this PE 📍. - The ENRP server may reject the registration due to other reasons such as invalid values, lack of resource, authentication failure, etc. 🙃
In all above cases, the ENRP server MUST reply to the requesting PE with an ASAP_REGISTRATION_RESPONSE message. If the registration is accepted, the ENRP server MUST set the R flag in the ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, the ENRP server MUST indicate the rejection by setting the R flag in the ASAP_REGISTRATION_RESPONSE to '1' 💌.
If the registration is rejected, the ENRP server SHOULD include the proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message 🧾.
If the registration is granted (either a new registration or a re-registration case), the ENRP server MUST assign itself to be the Home ENRP server of the PE, i.e., to "own" the PE 🏠.
Implementation note: For better performance, the ENRP server may find it both efficient and convenient to internally maintain two separate PE lists or tables -- one is for the PEs that are owned by the ENRP server and the other is for all the PEs owned by their peer(s). 🧠
Moreover, if the registration is granted, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. If the registration is denied, no message will be sent to its peers 📣.
3.2. De-Registration 👋
In the event a PE wishes to de-register from its server pool (normally, via an upper-layer request, see Section 6.2), it SHOULD use the following procedure. It should be noted that an alternate method of de-registration is to NOT re-register and to allow the registration life of the PE to expire. In this case, an ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP Endpoint to indicate the removal of the PE from the pool it registered 🌙.
When de-registering, the PE SHOULD use the SCTP association that was used for registration with its Home ENRP server. To de-register, the PE's ASAP Endpoint MUST take the following actions:
- D1) Fill in the
Pool Handleparameter of theASAP_DEREGISTRATIONmessage (Section 2.2.2) using the samePool Handleparameter sent during registration. - D2) Fill in the
PE Identifierparameter of theASAP_DEREGISTRATIONmessage. The identifier MUST be the same as used during registration. The use of the samePool HandleandPool Identifierparameters used in registration allows the identity of the PE ASAP Endpoint to be verified before de-registration can occur 🔍. - D3) Send the
ASAP_DEREGISTRATIONmessage to the Home ENRP server using the PE's SCTP association 📤. - D4) Start a T3-Deregistration timer ⏲️.
If the T3-Deregistration timer expires before receiving either an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification from the PE's SCTP endpoint, the PE's ASAP Endpoint shall start the ENRP Server Hunt procedure (see Section 3.6) in an attempt to get service from another ENRP server. After establishing a new Home ENRP server, the ASAP Endpoint SHOULD restart the de-registration procedure 🔁.
At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP endpoint MUST stop the T3-Deregistration timer 🛑.
It should be noted that after a successful de-registration, the PE MAY still receive requests for some period of time. The PE MAY wish to remain active and service these requests or to exit and ignore these requests 🫠.
Upon receiving the message, the ENRP server SHALL remove the PE from its handlespace. Moreover, if the PE is the last one of the named pool, the ENRP server will remove the pool from the handlespace as well 🧹.
If the ENRP server fails to find any record of the PE in its handlespace, it SHOULD consider the de-registration granted and completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the PE 🫥.
The ENRP server may reject the de-registration request for various reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send an ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-registration is rejected, the ENRP server MUST indicate the rejection by including the proper Operational Error parameter ❌.
It should be noted that de-registration does not stop the PE from sending or receiving application messages 💬.
Once the de-registration request is granted and the PE removed from its local copy of the handlespace, the ENRP server MUST take the handlespace update action to inform its peers about the change just made. Otherwise, the ENRP server MUST NOT inform its peers 🤐.
3.3. Handle Resolution
okay so at any time a PE or PU might wanna resolve a handle 💅 this usually happens when an ASAP Endpoint sends a Pool Handle (Section 6.5.1) to its Home ENRP server or asks for a cache population (Section 6.3). it can also happen for other reasons, like when the internal ASAP PE wants to know who its peers are so it can message all of them 🫶 when an ASAP Endpoint (PE or PU) wants to turn a pool handle into a list of accessible transport addresses for the member PEs of the pool, it MUST take the following actions:
- NR1) Fill in an
ASAP_HANDLE_RESOLUTIONmessage (Section 2.2.5) with the Pool Handle to be resolved. - NR2) If the endpoint does not have a Home ENRP server, start the ENRP Server Hunt procedures specified in Section 3.6 to get one 🔍 otherwise, skip ahead to step NR3.
- NR3) If it's a PE, send the
ASAP_HANDLE_RESOLUTIONmessage to the Home ENRP server using SCTP. if it's a PU, send it to the Home ENRP server using either TCP or SCTP. if the message comes from a PE, the SCTP association used for registration SHOULD be used. - NR4) Start a T1-ENRPrequest timer ⏰
if the T1-ENRPrequest timer runs out before a response message shows up, the ASAP Endpoint SHOULD take the steps described in Section 3.7.2 😬 if a SEND.FAILURE notification comes in from the SCTP or TCP layer, the ASAP Endpoint SHOULD start the Server Hunt procedure (see Section 3.6) to try and get service from a different ENRP server. once it has a new Home ENRP server, the ASAP Endpoint SHOULD restart the handle resolution procedure 🔄
when the ASAP_HANDLE_RESOLUTION_RESPONSE message arrives, the ASAP Endpoint MUST stop its T1-ENRPrequest timer ✋ after that, the ASAP Endpoint SHOULD process the message as appropriate (e.g., fill up a local cache, hand the response to the ASAP User, and/or use the response to send the ASAP User's message) ✨
ngl, some ASAP Endpoints MAY use a cache so they don't have to send as many handle resolutions 🧚 if a cache is used, it SHOULD:
- C1) Be consulted before sending a handle resolution.
- C2) Have a stale timeout timer associated with each cache entry. if the cache entry turns out to be stale when it gets a hit, a handle resolution message SHOULD be sent so the cache can be updated 🔁
- C3) In the case of a stale cache entry, the implementation may, in parallel, update the cache and answer the request, or it may block the user and wait for an updated cache before going ahead with the user's request ⏳
- C4) If the cache entry is NOT stale, the endpoint SHOULD NOT send a handle resolution request, and instead SHOULD use the entry from the cache 💖
it should be noted that whether a cache helps depends on the policy and the requirements of the application 🤷♀️ for some applications, using a cache can boost performance, and for others it can make things slower 🌸
an ENRP server SHOULD be ready to receive ASAP_HANDLE_RESOLUTION requests from PUs, either over an SCTP association on the well-known SCTP port, or over a TCP connection on the well-known TCP port 🎀
when the ASAP_HANDLE_RESOLUTION message comes in, the ENRP server MUST first look up the pool handle in its handlespace. if the pool exists, the Home ENRP server MUST compose and send back an ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU 💌
in that response, the ENRP server SHOULD list all the PEs currently registered in this pool, in a list of PE parameters. the ENRP server MUST also include a pool member selection policy parameter to show the overall member selection policy for the pool, but only if the current pool member selection policy is not Round-Robin 🎯
if the named pool isn't in the handlespace, the ENRP server MUST reject the handle resolution request by replying with an ASAP_HANDLE_RESOLUTION_RESPONSE message that carries an Unknown Pool Handle error 🙅♀️
3.4. Endpoint Keep Alive
the ASAP_ENDPOINT_KEEP_ALIVE message is how an ENRP server checks that a PE is still reachable 👀 if the transport level heartbeat mechanism isn't enough, this message can be used as a heartbeat at the ASAP level, with the goal of finding out the health of the ASAP level quickly and on time 💓 (the transport level heartbeat might not be enough because its timeouts or heartbeat interval are set too long, or because its coverage only reaches the transport level at the two ends.) the ASAP_ENDPOINT_KEEP_ALIVE message is also useful for fault detection reliability when the SCTP stack lives in the kernel 🧠 in that case, the SCTP-level heartbeat keeps an eye on end-to-end connectivity between the two SCTP stacks, while the ASAP-level heartbeat keeps an eye on the end-to-end liveliness of the ASAP layer sitting on top of it 🫧
the use of the ASAP_ENDPOINT_KEEP_ALIVE message (Section 2.2.7) and the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. when an ASAP_ENDPOINT_KEEP_ALIVE message comes in, the following actions MUST be taken:
- KA1) The PE must verify that the Pool Handle is correct and matches the Pool Handle sent in its earlier
ASAP_REGISTRATIONmessage. if the Pool Handle doesn't match, the PE MUST silently discard the message 🤫 - KA2) Send an
ASAP_ENDPOINT_KEEP_ALIVE_ACK(Section 2.2.8) like this:- KA2.1) Fill in the Pool Handle parameter with the PE's Pool Handle.
- KA2.2) Fill in the PE Identifier parameter using the PE identifier this PE used for registration.
- KA2.3) Send the
ASAP_ENDPOINT_KEEP_ALIVE_ACKmessage via the right SCTP association for the ENRP server that sent theASAP_ENDPOINT_KEEP_ALIVEmessage 📮 - KA2.4) If the H flag in the received
ASAP_ENDPOINT_KEEP_ALIVEmessage is set, and the Server Identifier in the message is NOT the identity of your Home ENRP server (or it isn't set, e.g., you have no Home ENRP server), adopt the sender of theASAP_ENDPOINT_KEEP_ALIVEmessage as the new Home ENRP server 👑
3.5. Unreachable Endpoints
every so often, an ASAP Endpoint might realize a PE is unreachable 😱 this can happen because of a specific SCTP error that the ASAP Endpoint notices, or because an ASAP User reports it through the Transport.Failure Primitive (Section 6.9.2). either way, the ASAP Endpoint SHOULD report that the PE is unavailable by sending an ASAP_ENDPOINT_UNREACHABLE message to any ENRP server 📣 before sending the ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in the Pool Handle parameter and the PE Identifier parameter of the unreachable endpoint 📝 if the sender is a PE, the message MUST be sent via SCTP. it should be noted that an ASAP Endpoint MUST report no more than once each time it runs into such an event 🙅♀️ also, when processing a Transport.Failure Primitive (Section 6.9.2), the ASAP Endpoint MUST NOT send an ASAP_ENDPOINT_UNREACHABLE message unless the user has previously asked to send data to the PE named in the primitive 💅
when an ENRP server receives an ASAP_ENDPOINT_UNREACHABLE message, it MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the H flag in the message SHOULD be set to '0' in this case) 🏃♀️ if this ASAP_ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP server MUST consider the PE truly unreachable and MUST remove the PE from its handlespace 💀
if the ASAP_ENDPOINT_KEEP_ALIVE message gets through to the PE successfully, the ENRP server MUST keep the PE in its handlespace 🫶 also, the server SHOULD keep a counter of how many ASAP_ENDPOINT_UNREACHABLE messages it has received that report a reachability problem for this PE. if the counter goes over the protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE from its handlespace 🚫
optionally, an ENRP server may also send point-to-point ASAP_ENDPOINT_KEEP_ALIVE messages (with the H flag set to '0') to each of the PEs it owns, to check their reachability status 🔍 if sending ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the PE unreachable and MUST remove the PE from its handlespace. note: if an ENRP server owns a huge number of PEs, the implementation should pay attention so it doesn't flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages 🌊 instead, the implementation MUST spread the ASAP_ENDPOINT_KEEP_ALIVE message traffic over a period of time. this can be done by randomly varying the time between two ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE by plus/minus 50 percent 🎲✨
3.6. ENRP Server Hunt Procedures 🔍✨
okay so each PU and PE keeps a little list of the transport addresses of every ENRP server it knows about 📋 think of it as their group chat contacts for the servers 💅
If multicast capabilities are used within the operational scope, an ENRP server MUST periodically send an ASAP_SERVER_ANNOUNCE message (Section 2.2.10) every (N+1)*T6-Serverannounce. That message includes all the transport addresses available for ASAP communication on the multicast ENRP client channel. Here, N is the number of ENRP servers the server has found by receiving ASAP_SERVER_ANNOUNCE messages. This should result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per T6-Serverannounce 🦋
If a PU or PE receives an ASAP_SERVER_ANNOUNCE message, it SHOULD insert all of the new included transport addresses into its list of ENRP server addresses and start a T7-ENRPoutdate timer for each address. For all the transport addresses it already knows about that are included, the T7-ENRPoutdate timer MUST be restarted for each address. If no transport parameters are included in the ASAP_SERVER_ANNOUNCE message, the SCTP transport protocol is assumed to be used, and the source IP address and the IANA-registered ASAP port number are used for communication with the ENRP server. If a T7-ENRPoutdate timer for a transport address expires, that address gets deleted from the managed list of transport addresses of the PU or PE 🗑️💀
If multicast capabilities are not used within the operational scope, each PU and PE MUST have a configured list of transport addresses of ENRP servers 🎀
At its startup, or when it fails to communicate with its Home ENRP server (i.e., it timed out on an ENRP request), a PE or PU MUST establish a new Home ENRP server (i.e., set up a TCP connection or SCTP association with a different ENRP server) 🔄
To establish a Home ENRP server, the following rules MUST be followed:
- SH1) The PE or PU SHOULD try to establish an association or connection with no more than three ENRP servers. An ASAP Endpoint MUST NOT establish more than three associations or connections. 🚫
- SH2) The ASAP Endpoint shall start a
T5-Serverhunttimer. ⏱️ - SH3) If the ASAP Endpoint establishes an association or connection, it MUST stop its
T5-Serverhunttimer. The ASAP Endpoint SHOULD also reset theT5-Serverhunttimer to its initial value and then proceed to step SH6. 🙌 - SH4) If an association or connection establishment fails, the ASAP Endpoint SHOULD try to establish an association or connection using a different transport address. 🔁
- SH5) If the
T5-Serverhunttimer expires, the following should be performed:- SH5.1) The ASAP Endpoint MUST double the value of the
T5-Serverhunttimer. Note that this doubling is capped at the valueRETRAN.max. 📈 - SH5.2) The ASAP Endpoint SHOULD stop the establishment of associations and connections with the transport addresses selected in step SH1.
- SH5.2) The ASAP Endpoint SHOULD repeat trying to establish an association or connection by proceeding to step SH1. It SHOULD attempt to select a different set of transport addresses to connect with. 🔄💅
- SH5.1) The ASAP Endpoint MUST double the value of the
- SH6) The PE or PU shall pick one of the ENRP servers it was able to establish an association or connection with, and send all subsequent ENRP request messages to this new Home ENRP server. 🎉👑
3.7. Handling ASAP Endpoint to ENRP Server Communication Failures 😭
Three types of failure may occur when the ASAP Endpoint at either the PE or PU tries to communicate with an ENRP server:
- A) SCTP send failure
- B)
T1-ENRPrequesttimer expiration - C) Registration failure
3.7.1. SCTP Send Failure 📭
This communication failure means the SCTP layer couldn't deliver a message sent to an ENRP server. In other words, the ENRP server is unreachable 💀
In that case, the ASAP Endpoint MUST NOT re-send the undeliverable message. Instead, it SHOULD discard the message and start the ENRP Server Hunt procedure described in Section 3.6. After finding a new Home ENRP server, the ASAP Endpoint should re-send the request.
Note that an ASAP Endpoint MAY also choose to NOT discard the message, but to queue it for retransmission after a new Home ENRP server is found. If an ASAP Endpoint does choose to discard the message, then after a new Home ENRP server is found, the ASAP Endpoint MUST be capable of reconstructing the original request 🧩
3.7.2. T1-ENRPrequest Timer Expiration ⏰
When the T1-ENRPrequest timer expires, the ASAP Endpoint should re-send the original request to the ENRP server and restart the T1-ENRPrequest timer. At the same time, the ASAP Endpoint should begin the ENRP server hunt procedures described in Section 3.6 🏃♀️💨
This should be repeated up to MAX-REQUEST-RETRANSMIT times. After that, an Error.Report notification should be generated to inform the ASAP User, and the ENRP request message associated with the T1-ENRPrequest timer should be discarded. It should be noted that if an alternate ENRP server responds, the ASAP Endpoint SHOULD adopt the responding ENRP server as its new Home ENRP server and re-send the request to the new Home ENRP server. 🫶
3.7.3. Registration Failure 📝
Registration failure is discussed in Section 3.1.
3.8. Cookie Handling Procedures 🍪
Whenever a PE wants, and a control channel exists, it can send an ASAP_COOKIE message to a PU over the control channel. The PU's ASAP endpoint stores the Cookie parameter and discards an older cookie if one was stored previously 🧁
Note: A control channel is a communication channel between a PU and PE that does not carry data passed to the user. With SCTP, this is done by using a PPID to separate the ASAP messages (Cookie and Business Card) from normal data messages. 🎀
If the PU's ASAP Endpoint detects a failure and starts a failover to a different PE, it SHOULD send the latest received cookie parameter in an ASAP_COOKIE_ECHO message to the new PE as the first message on the control channel. Upper layers may be involved in the failover procedure 🔀
The cookie handling procedure can be used for state sharing. So a cookie should be signed by the sending PE ASAP Endpoint, and the cookie should be verified by the receiving PE's ASAP Endpoint. The details of the verification procedure are out of scope for this document. What matters is that the PU always stores the last received Cookie parameter and sends that back unmodified in case of a PE failure 🔐💜
3.9. Business Card Handling Procedures 💳
When communication begins between a PU and a PE, either of which could be part of a PU/PE combination (i.e., a message is sent between the entities), a PE should always send an ASAP_BUSINESS_CARD message to a PU. A PU should send an ASAP_BUSINESS_CARD message to a PE only if it is part of a PU/PE combination. An ASAP_BUSINESS_CARD message MUST ONLY be sent if a control channel exists between a PU and PE. After communication has been established between a PE and PU, either entity may send a new ASAP_BUSINESS_CARD message at any time to update its failover order 🌸
The ASAP_BUSINESS_CARD message does two jobs. First, it lists the pool handle. For a PU that is part of a PU/PE combination and is contacting a PE, this is essential, so the PE learns the pool handle of the PU/PE combination requesting service. Second, the ASAP_BUSINESS_CARD message tells the receiving entity a failover order that is recommended to follow. This should facilitate rendezvous between entities that have been working together, and also help control the load redistribution when any PE fails ⚡
Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13), the receiving ASAP Endpoint SHOULD:
- BC1) Unpack the message. If the translation cache of the receiving ASAP Endpoint has no entry for the pool handle listed within the
ASAP_BUSINESS_CARDmessage, perform anASAP_HANDLE_RESOLUTIONfor that pool handle. If the translation cache does hold an entry for the pool handle, then it may be necessary to update the peer endpoint. 🔎 - BC2) Unpack the message and populate a preferred list for failover order. If the peer's PE should fail, this preferred list will be used to guide the ASAP Endpoint in selecting an alternate PE. 🧭
4. Roles of Endpoints 🎭
A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION and ASAP_HANDLE_RESOLUTION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ERROR messages. It MAY implement the handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. It MAY also implement the handling of ASAP_SERVER_ANNOUNCE messages. 💁♀️
A PE MUST implement the handling of ASAP_REGISTRATION, ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ENDPOINT_KEEP_ALIVE, ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ERROR messages. It SHOULD support the handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages. Furthermore, it MAY support the handling of ASAP_SERVER_ANNOUNCE messages. 👑
An ENRP server MUST implement the handling of ASAP_REGISTRATION, ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and ASAP_DEREGISTRATION_RESPONSE messages. Furthermore, it MUST support the handling of ASAP_ENDPOINT_KEEP_ALIVE, ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and ASAP_ERROR messages. Furthermore, it MAY support the handling of ASAP_SERVER_ANNOUNCE messages. 🌈
If a node acts as both a PU and a PE, it MUST fulfill both roles. 🫶
5. SCTP Considerations 🦋
Each ASAP message is treated as an SCTP user message. The PPID registered for ASAP SHOULD be used. The SCTP port used at the ENRP server might be preconfigured, or announced in the ASAP_SERVER_ANNOUNCE message, or it might be the well-known ASAP port 🔌
ASAP messages belonging to the control channel MUST be sent using the PPID registered for ASAP. Messages belonging to the data channel MUST NOT use the PPID registered for ASAP. So the channels stay separate, no drama 💅
6. The ASAP Interfaces 💖
This chapter will focus mainly on the primitives and notifications that form the interface between the ASAP User and ASAP, and the interface between ASAP and its lower-layer transport protocol (e.g., SCTP) 🧚
Note, the following primitive and notification descriptions are shown for illustrative purposes. We believe that including these descriptions in this document is important to understanding how many aspects of ASAP operate, but an ASAP implementation is not required to use the exact syntax described in this section 🙈
An ASAP User passes primitives to the ASAP sub-layer to request certain actions. Once those actions are complete, or when certain events are detected, the ASAP layer notifies the ASAP User ✨
6.1. Registration.Request Primitive ✨
okay bestie, this is the primitive for signing up 💖 Here's the format:
Format: registration.request(Pool Handle,
User Transport parameter(s))The Pool Handle is a NULL terminated ASCII string of fixed length 🎀 The optional User Transport parameter(s) tell you which transport parameters and types you want to register with. If you leave that off, the SCTP endpoint you use to talk to the ENRP server becomes the default User Transport parameter. Also, any IP address inside a User Transport parameter MUST be a bound IP address in that SCTP endpoint used to talk to the ENRP server. no exceptions 🙅♀️
The ASAP User calls this to add itself to the handlespace, so it becomes a Pool Element of a pool 🧚 The ASAP User must register itself with the ENRP server using this primitive before other ASAP Users in the handlespace can send messages to it, whether they use the Pool Handle or the PE handle (see Sections 6.5.1 and 6.5.3).
When you call the registration primitive, the ASAP Endpoint sends an ASAP_REGISTRATION message to the Home ENRP server (see Sections 2.2.1 and 3.1), and starts a T2-registration timer ⏰
6.2. Deregistration.Request Primitive 🦋
Format:
Format: deregistration.request(Pool Handle)The ASAP PE calls this to remove itself from the Server Pool 🌸 This should be used as part of the graceful shutdown process by the application, so you're leaving the party on your own terms 💅
The ASAP Endpoint then sends an ASAP_DEREGISTRATION message to the Home ENRP server (see Sections 2.2.2 and 3.2).
6.3. CachePopulateRequest Primitive 🌈
Format:
Format: cache_populate_request([Pool-Handle |
Pool-Element-Handle])If the address type is a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should start a mapping information query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle. Then it updates its local cache when the response comes back from the ENRP server 🔍
If you pass a Pool-Element-Handle, the Pool Handle gets unpacked from it, and the ASAP_HANDLE_RESOLUTION message is sent to the ENRP server for resolution. When the response comes back from the ENRP server, the local cache is updated 💜
Heads up: if the ASAP service does NOT support a local cache, this primitive performs NO action 🙈
6.4. CachePurgeRequest Primitive 🧹
Format:
Format: cache_purge_request([Pool-Handle | Pool-Element-Handle])If the user passes a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should remove the mapping information on that Pool Handle from its local cache. If the user passes a Pool-Element-Handle, the Pool Handle inside it is used for the cache_purge_request 🫶
Again, if the ASAP service does NOT support a local cache, this primitive performs NO action 💀
6.5. DataSendRequest Primitive 💌
Format:
Format: data_send_request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options);This primitive asks ASAP to send a message to a specified Pool or Pool Element within the current Operational scope 🎯
Depending on the address type used for the send request, the sender's ASAP Endpoint may do address translation and Pool Element selection before the message goes out. This MAY also call for creating a local transport endpoint so the required transport type is met ✨
The data_send_request primitive can take different forms of address types, and we'll go through them in the next sections 👑
6.5.1. Sending to a Pool Handle 🎀
In this case, the destinationAddress and typeOfAddress together indicate a pool handle.
This is the simplest form of send_data_request primitive. By default, it tells ASAP to send the message to one of the Pool Elements in the specified pool 🫧
Before sending the message to the pool, the sender's ASAP endpoint MUST first do a pool handle to address translation. It might also need to do Pool Element selection if multiple Pool Elements exist in the pool.
If the sender's ASAP implementation doesn't support a local cache of the mapping information, or if it doesn't have the mapping information on the pool in its local cache, it sends an ASAP_HANDLE_RESOLUTION message (see Sections 2.2.5 and 3.3) to the current Home ENRP server. It MUST hold the outbound message in queue while it waits for the response from the ENRP server. Any further send request to this pool before the ENRP server responds SHOULD also be queued 🥹
Once the necessary mapping information arrives from the ENRP server, the sender's ASAP will:
- A) map the pool handle into a list of transport addresses of the destination PE(s);
- B) if multiple PEs exist in the pool, choose one of them and transmit the message to it. In that case, the choice of the PE is made by the ASAP Endpoint of the sender based on the server pooling policy, as discussed in Section 6.5.2;
- C) optionally create any transport endpoint that may be needed to communicate with the PE selected;
- D) if no transport association or connection exists towards the destination PE, establish any needed transport state;
- E) send out the queued message(s) to the appropriate transport connection using the appropriate send mechanism (e.g., for SCTP, the SEND primitive in [RFC4960] would be used); and,
- F) if the local cache is implemented, append/update the local cache with the mapping information received in the ENRP server's response. Also, record the local transport information (e.g., the SCTP association id) if any new transport state was created.
For more on the ENRP server request procedures, see [RFC5353] 📚
Optionally, the ASAP Endpoint of the sender may return a Pool Element handle of the selected PE to the application after sending the message. That PE handle can then be used for future transmissions to that same PE (see Section 6.5.3) 🔁
Section 3.7 defines the failover procedures for cases where the selected PE is found unreachable 🛟
6.5.2. Pool Element Selection 🎲
Each time an ASAP User sends a message to a pool that contains more than one PE, the sender's ASAP Endpoint must select one of the PEs in the pool as the receiver of the current message. The selection is made according to the current server pooling policy of the pool the message is sent to 🫶
Note, no selection is needed if the ASAP_SEND_TOALL option is set (see Section 6.5.5) 🙌
Together with the server pooling policy, each PE can also specify a Policy Value for itself at registration time. What the Policy Value means depends on the current server pooling policy of the group. A PE can also change its Policy Value whenever it wants, by re-registering itself with the handlespace with a new Policy Value. Re-registration shall be done by simply sending another ASAP_REGISTRATION to its Home ENRP server (see Section 2.2.1) 🔄
One basic policy is defined in this document; others can be found in [RFC5356]
6.5.2.1. Round-Robin Policy 🎠
When an ASAP Endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP Endpoint of the sender selects the receiver for each outbound message by going round-robin through all the registered PEs in that Pool. The goal is an even distribution of outbound messages 🎡 Note that in a large server pool, the ENRP server might not send back all PEs to the ASAP client. In this case, the client or PU will be doing a Round-Robin policy on a subset of the entire Pool 🥰
6.5.3. Sending to a Pool Element Handle 🧸
In this case, the destinationAddress and typeOfAddress together indicate an ASAP Pool Element handle.
This requests that the ASAP Endpoint deliver the message to the PE identified by the Pool Element handle 📬
The Pool Element handle should contain the Pool Handle and a destination transport address of the destination PE, or the Pool Handle and the transport type. Other implementation dependent elements may also be cached in a Pool Element handle 🗂️
The ASAP Endpoint shall use the transport address and transport type to identify the endpoint it communicates with. If no communication state exists with the peer endpoint (and the transport protocol requires it), the ASAP Endpoint MAY set up the needed state and then invoke the SEND primitive for the particular transport protocol to send the message to the PE 🛠️
If a local translation cache is supported, the endpoint will also:
- A) send out the message to the transport address (or association id) designated by the PE handle.
- B) determine if the Pool Handle is in the local cache.
- i) If it is not, the endpoint will ask the Home ENRP server for handle resolution on the pool handle by sending an ASAP_HANDLE_RESOLUTION message (see Section 2.2.5), and
- ii) use the response to update the local cache.
- If the pool handle is in the cache, the endpoint will only update the pool handle if the cache is stale. A stale cache is indicated by it being older than the protocol parameter 'stale.cache.value' (see Section 7.2) ⏳
Sections 3.5 and 6.9 define the failover procedures for cases where the PE pointed to by the Pool Element handle is found to be unreachable 🦺
Optionally, the ASAP Endpoint may return the actual Pool Element handle the message was sent to. This may be different from the Pool Element handle specified when the primitive was invoked, because of the possibility of automatic failover 🪄
6.5.4. Send by Transport Address 🚀
In this case, the destinationAddress and typeOfAddress together indicate a transport address and transport type.
This directs the sender's ASAP Endpoint to send the message out to the specified transport address 📮
No endpoint failover is supported when this form of send request is used. This form of send request effectively bypasses the ASAP endpoint. 😭
6.5.5. Message Delivery Options 🎁
okay so the Options parameter in all those data_send_request versions is basically the "how should I handle this message, bestie?" setting 💅 the sender's ASAP endpoint reads it and does special stuff for delivery ✨
you make the Options value by bit-wise "OR"ing these pre-defined constants together 🧚
ASAP_USE_DEFAULT: 0x0000🌸 just use the default setting, no dramaASAP_SEND_FAILOVER: 0x0001🦋 this turns on PE failover for the message. if the first selected PE (or the PE the PE handle points to) is unreachable, the sender's ASAP Endpoint SHOULD re-select an alternate PE from the same pool, if one exists, and silently re-send the message to that new endpoint. iykyk 🫶
⚠️ BUT this is best-effort only, so messages can still get lost during failover, even when the transport can retrieve unacknowledged data (like SCTP). example: a message got acknowledged by the SCTP layer at a PE but the PE hadn't read it yet when it died 💀 and if the transport can't do retrieval (like TCP), any data ASAP already handed to the transport may be lost on failover. so apps need to know this, periodt 😭
ASAP_SEND_NO_FAILOVER: 0x0002🚫 this one stops the sender's ASAP Endpoint from re-sending to any alternate PE if the first selected PE (or the PE the handle points to) is unreachable. instead, the endpoint has to tell its upper layer about the unreachability with an Error.Report and return any unsent data. no second chances, bestie 💔ASAP_SEND_TO_LAST: 0x0004🔁 requests that the message go to the same PE in the pool that the previous message for this pool went to. main character loyalty energy 👑ASAP_SEND_TO_ALL: 0x0008📣 when sending by Pool Handle, this sends a copy of the message to all the PEs, except for the sender itself if the sender is a PE in that pool. everybody gets the tea ☕ASAP_SEND_TO_SELF: 0x0010🪞 this only works together with ASAP_SEND_TO_ALL. it lets the sender's ASAP Endpoint also deliver a copy to itself if it's a PE of the pool (aka loop-back). she's sending it to herself, and that's iconic 💜ASAP_SCTP_UNORDER: 0x1000🌈 requests that the transport layer send the current message with un-ordered delivery. heads up: the underlying transport has to support un-ordered delivery for this to actually work ✨
6.6. Data.Received Notification 📥
Format:
data.received(messageReceived, sizeOfMessage,
senderAddress, typeOfAddress)okay so when a new user message shows up, the receiver's ASAP Endpoint uses this notification to pass it up to its upper layer 💌
Along with the message, the receiver's ASAP Endpoint should also tell its upper layer who sent it. the sender's address can be an SCTP association id, a TCP transport address, a UDP transport address, or an ASAP Pool Element handle 🦋
A) if the handle translation local cache is implemented at the receiver's ASAP Endpoint, it should do a reverse mapping from the sender's IP address to the pool handle. if that works, the sender's ASAP Pool Element handle should be built and passed in the senderAddress field 🔍
B) if there's no local cache, or the reverse mapping doesn't work, the SCTP association id (or another transport-specific identifier if SCTP isn't being used) should be passed in the senderAddress field 🧩
6.7. Error.Report Notification 🚨
Format:
error.report(destinationAddress, typeOfAddress,
failedMessage, sizeOfMessage)an error.report should be generated to tell the ASAP User about failed message delivery and other abnormal stuff 😬
The destinationAddress and typeOfAddress together show who the message was originally sent to. the address type can be an ASAP Pool Element handle, an association id, or a transport address 📍
The original message (or just its first portion, if the message is too big) and its size get passed in the failedMessage and sizeOfMessage fields, respectively 📦
6.8. Examples 🎀
these examples assume an underlying SCTP transport between the PE and the PU. other transports are possible, but SCTP is used here just to illustrate things 🧚 also, all communication between the PU and the ENRP server, and between the PE and the ENRP servers, would be using SCTP 🦋
6.8.1. Send to a New Pool 🆕
this example shows the event sequence when a Pool User sends the message "hello" to a pool that isn't in the local translation cache (assuming local caching is supported) 💖
ENRP Server PU new-handle:PEx
| | |
| +---+ |
| | 1 | |
|2. ASAP_HANDLE_RESOLUTION +---+ |
|<-------------------------------| |
| +---+ |
| | 3 | |
|4. ASAP_HANDLE_RESOLUTION_RSP +---+ |
|------------------------------->| |
| +---+ |
| | 5 | |
| +---+ 6. "hello1" |
| |---------------->|
| | |- the user at PU invokes:
data_send_request("new-handle", handle-type, "hello1", 6, 0);the ASAP Endpoint looks up the pool "new-handle" in its local cache, but it can't find it 😵
- the ASAP Endpoint of the PU queues the message and sends an ASAP_HANDLE_RESOLUTION request to the ENRP server, asking for all the info about pool "new-handle" 📨
- a T1-ENRPrequest timer starts while the ASAP Endpoint waits for the response from the ENRP server ⏳
- the ENRP server responds to the query with an ASAP_HANDLE_RESOLUTION_RESPONSE message containing all the info about pool "new-handle" 🎉
- ASAP at PU cancels the T1-ENRPrequest timer and fills its local cache with info on pool "new-handle" 🗂️
- based on the server pooling policy of pool "new-handle", ASAP at PU picks the destination PE (PEx), sets up an SCTP association towards PEx if needed (explicitly or implicitly), and sends out the queued "hello1" user message 🚀
6.8.2. Send to a Cached Pool Handle 💨
this shows what happens when the ASAP User PU sends another message to pool "new-handle" after everything in Section 6.8.1 🌷
ENRP Server PU new-handle:PEx
| | |
| +---+ |
| | 1 | |
| +---+ 2. "hello2" |
| |---------------->|
| | |- the user at PU invokes:
data_send_request("new-handle", handle-type, "hello2", 6, 0);the ASAP Endpoint looks up pool "new-handle" in its local cache and finds the mapping info 🙌
- based on the server pooling policy of "new-handle", ASAP at PU selects the PE (assuming EPx gets picked again), and sends out the "hello2" message (assuming the SCTP association is already set up) 💅
6.9. PE Send Failure 💔
when the ASAP Endpoint in a PE or PU tries to send a message to a PE and it fails, the failed sender reports the event as described in Section 3.5 😤
there are also extra primitives defined in this section for user apps that don't want to use ASAP as the actual transport 🫶
6.9.1. Translation.Request Primitive 🔤
Format:
translation.request(Pool-Handle)if the address type is a Pool Handle and a local handle translation cache exists, the ASAP Endpoint should check its translation cache and return the currently known transport types, ports, and addresses to the caller 🗺️
if the Pool Handle isn't in the local handle cache, or there's no handle cache at all, the ASAP Endpoint will send an ASAP_HANDLE_RESOLUTION request using the Pool Handle 📡 once the handle resolution finishes, the ASAP Endpoint should fill the local handle cache (if one is supported) and return the transport types, ports, and addresses to the caller 🎀
6.9.2. Transport.Failure Primitive 🙅
Format:
transport.failure(Pool-Handle, Transport-address)if an external user runs into a failure sending to a PE and is not using ASAP, it can use this primitive to report the failure to the ASAP endpoint 🫣 ASAP will then send an ASAP_ENDPOINT_UNREACHABLE to the "Home" ENRP server in response to this primitive. note that ASAP SHOULD NOT send an ASAP_ENDPOINT_UNREACHABLE unless the user has actually made a previous request to send data to the PE 🚫
7. Timers, Variables, and Thresholds ⏰
okay so this section is basically the cheat sheet of all the timers, variables, and pre-set protocol constants used in ASAP 📋✨
7.1. Timers 🕰️
T1-ENRPrequest⏳ a timer started when ASAP sends a request to the ENRP server (while application info is queued). normally set to 15 seconds.T2-registration📝 a timer started when sending an ASAP_REGISTRATION request to the Home ENRP server. normally set to 30 seconds.T3-deregistration👋 a timer started when sending a de-registration request to the Home ENRP server. normally set to 30 seconds.T4-reregistration🔄 this one starts after a successful registration into the ENRP handlespace, and it's used to trigger a re-registration at a periodic interval. it's normally set to 10 minutes or 20 seconds less than the Lifetime parameter used in the registration request, whichever is less 🧮T5-Serverhunt🔎 used during the ENRP Server Hunt procedure. normally set to 10 seconds.T6-Serverannounce📢 gives the time between sending consecutive ASAP_SERVER_ANNOUNCE messages. normally set to 1 second.T7-ENRPoutdate🥀 gives the time a server announcement stays valid. normally set to 5 seconds.
7.2. Variables 🧪
stale_cache_value🕸️ a threshold variable that shows how long a cache entry is valid for.
7.3. Thresholds 🚧
MAX-REG-ATTEMPT🔁 the maximum number of registration attempts made before a server hunt is issued. the default value is 2.MAX-REQUEST-RETRANSMIT🔂 the maximum number of attempts made when requesting info from the local ENRP server before a server hunt is issued. the default value is 2.RETRAN-MAX📈 this value is the maximum time between registration attempts, and it puts a ceiling on how far the registration timer backs off. the default is normally set to 60 seconds.
8. IANA Considerations 🌍
this document (RFC 5352) is the reference for all the registrations described in this section 📚 all the registrations have been listed on the Reliable Server Pooling (RSerPool) Parameters page 💜
8.1. A New Table for ASAP Message Types ✨
okay so IANA keeps the list of ASAP Message Types, and they already handed out fourteen starter values 💅 here's the new table they made, called "ASAP Message Types":
Type Message Name Reference
----- ------------------------- ---------
0x00 (Reserved by IETF) RFC 5352
0x01 ASAP_REGISTRATION RFC 5352
0x02 ASAP_DEREGISTRATION RFC 5352
0x03 ASAP_REGISTRATION_RESPONSE RFC 5352
0x04 ASAP_DEREGISTRATION_RESPONSE RFC 5352
0x05 ASAP_HANDLE_RESOLUTION RFC 5352
0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFC 5352
0x07 ASAP_ENDPOINT_KEEP_ALIVE RFC 5352
0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFC 5352
0x09 ASAP_ENDPOINT_UNREACHABLE RFC 5352
0x0a ASAP_SERVER_ANNOUNCE RFC 5352
0x0b ASAP_COOKIE RFC 5352
0x0c ASAP_COOKIE_ECHO RFC 5352
0x0d ASAP_BUSINESS_CARD RFC 5352
0x0e ASAP_ERROR RFC 5352
0x0b-0xff (Available for Assignment) RFC 5352If you want to register a new ASAP Message Type in this table, you should send the request to IANA 🎀 the number has to be unique, and the "Specification Required" policy of [RFC5226] MUST be applied 🔥
8.2. Port Numbers 🌸
the references for these already-assigned port numbers have been updated to RFC 5352 💖
asap-tcp 3863/tcp
asap-udp 3863/udp
asap-sctp 3863/sctp
asap-tcp-tls 3864/tcp
asap-sctp-tls 3864/sctp8.3. SCTP Payload Protocol Identifier 🦋
the reference for the already-assigned ASAP payload protocol identifier 11 got updated to RFC 5352 too, so everything points to the same place now ✨
8.4. Multicast Addresses 🧚
IANA assigned an IPv4 multicast address (224.0.1.185) and an IPv6 multicast address (FF0X:0:0:0:0:0:0:133) 😭 the IPv4 one lives inside the Internetwork Control Block (224.0.1/24), so it's giving very organized energy.
9. Security Considerations 🔐
okay this section is the important one, bestie 🫶 we're going to go over the threats to the RSerPool architecture, the security requirements that answer them, and the security mechanisms (built on TLS) that implementations have to include. at the end there's a chain-of-trust argument that follows the critical data paths in RSerPool and shows how TLS protects them 👑
9.1. Summary of RSerPool Security Threats 💀
"Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats" [RFC5355] goes deep on the threats to the RSerPool architecture and lists the security requirements for each one 💜 here's the short version of the security services the RSerPool protocol needs, based on the threats in this document:
Threat 1) PE registration/de-registration flooding or spoofing. Security mechanism in response: the ENRP server authenticates the PE.
Threat 2) PE registers with a malicious ENRP server. Security mechanism in response: the PE authenticates the ENRP server.
Threats 1 and 2, taken together, end up giving you mutual authentication of the ENRP server and the PE 🤝
Threat 3) Malicious ENRP server joins the ENRP server pool. Security mechanism in response: ENRP servers mutually authenticate.
Threat 4) A PU communicates with a malicious ENRP server for handle resolution. Security mechanism in response: the PU authenticates the ENRP server.
Threat 5) Replay attack. Security mechanism in response: a security protocol that protects against replay attacks.
Threat 6) Corrupted data that causes a PU to have misinformation concerning a pool handle resolution. Security mechanism in response: a security protocol that supports integrity protection.
Threat 7) Eavesdropper snooping on handlespace information. Security mechanism in response: a security protocol that supports data confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to ENRP server. Security mechanism in response: ASAP must control the number of ASAP Endpoint unreachable messages transmitted from the PU to the ENRP server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from the ENRP server. Security mechanism in response: the ENRP server must control the number of ASAP_ENDPOINT_KEEP_ALIVE messages sent to the PE.
so to sum it up, threats 1-7 need security mechanisms that support authentication, integrity, data confidentiality, and protection from replay attacks 🔥
for RSerPool, these are the pairs that need authenticating:
PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP server (mutual authentication)9.2. Implementing Security Mechanisms 🔐
okay bestie, so we are NOT cooking up any new security mechanisms for threats 1-7 🙅♀️ instead we borrow an existing IETF security protocol, [RFC3237], to handle all the security services we need. TLS covers every single one of these requirements ✨ and it MUST be implemented 🔒 The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported, at a minimum, by implementers of TLS for RSerPool. For backwards compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other IETF-approved ciphersuites 🎀
ENRP servers, PEs, and PUs MUST implement TLS 💖 ENRP servers and PEs MUST support mutual authentication using PSK (pre-shared-key). ENRP servers MUST support mutual authentication among themselves using PSK. PUs MUST authenticate ENRP servers using certificates 🧚
TLS with PSK is mandatory to implement as the authentication mechanism for ENRP to ENRP authentication and PE to ENRP authentication. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. The justification for PSK is that we assume one administrative domain will control and manage the server pool. This allows PSK to be implemented and managed by a central security administrator 👑
TLS with certificates is mandatory to implement as the authentication mechanism for PUs to the ENRP server. PUs MUST authenticate ENRP servers using certificates. ENRP servers MUST possess a site certificate whose subject corresponds to their canonical hostname. PUs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All RSerPool Elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation. This entails possession of one or more root certificates issued by certificate authorities (preferably, well-known distributors of site certificates comparable to those that issue root certificates for web browsers) 🌸
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). The client's understanding of the server's identity (typically, the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped. However, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using DNS Security (DNSSEC), or using user- or admin-configured host-to-address/address-to-host lookup tables) 🔍
If the server identity check fails, user-oriented clients SHOULD either notify the user or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect, or both. Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination 🚨
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format, as specified in Section 4 of [RFC3490], before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of [RFC3490] as follows:
- in step 1, the domain name SHALL be considered a "stored string";
- in step 3, set the flag called "UseSTD3ASCIIRules";
- in step 4, process each label with the "ToASCII" operation; and
- in step 5, change all label separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality, according to the rules specified in Section 3 of RFC 3490. The * (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then, only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com 🧁
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation in [RFC0791] and [RFC2460]. For IP version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical 🌈
After a TLS layer is established in a session, both parties are to independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see RFC 4511)[RFC4511]. Implementations may re-evaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer 🙅♀️
Implementations MUST support TLS with SCTP, as described in [RFC3436] or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to a TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer, we also have to take into account the differences between TLS and SCTP 🦋
Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5) to the ENRP server.
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see [RFC5353]).
There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot consider the source address of such a message to be a trustworthy address of an ENRP server. A receiver must also be prepared to receive a large number of multicast announcements from attackers. 💀
9.3. Chain of Trust 🔗
Security is mandatory to implement in RSerPool and is based on TLS implementation in all three architecture components that comprise RSerPool, namely PU, PE, and ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server 👑
Here is a description of all possible data paths and a description of the security:
PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS)
PE <---> secured ENRP server (mutual authentication;
registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS)If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it 🌟
Summary of interaction between secured and unsecured components: If the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as an error due to security considerations, and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure, as the response can be tampered with in transit even if the ENRP database is secured 🫣
The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured, and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server 🍓
Summary:
RSerPool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for the RSerPool user 💜
10. Acknowledgments 🫶
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback. ✨
11. References 📚
11.1. Normative References 📚
These are the big foundational specs everything else leans on, bestie. Anything you need to implement the protocol properly lives here:
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002.
- [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
- [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
- [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
- [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
- [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.
11.2. Informative References 🧠
These are the extra-credit reads. Not required, but so worth your time:
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses 💌
Here's who made this whole thing happen, and how to reach them. Slide into their inboxes if you've got questions 🫶
Randall R. Stewart
The Resource Group
1700 Pennsylvania Ave NW
Suite 560
Washington, D.C., 20006
USA
EMail: randall@lakerest.net
Qiaobing Xie
The Resource Group
1700 Pennsylvania Ave NW
Suite 560
Washington, D.C., 20006
USA
Phone: +1 224-465-5954
EMail: Qiaobing.Xie@gmail.com
Maureen Stillman
Nokia
1167 Peachtree Ct.
Naperville, IL 60540
USA
EMail: maureen.stillman@nokia.com
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
EMail: tuexen@fh-muenster.deFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008). The legal stuff, but make it cute 🎀
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. No cap, that's a full "as is" vibe 💀
Intellectual Property 🔐
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid, or how far they reach, or whether any license for them is available. It also doesn't claim it has independently gone looking for those rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Spill the tea, it's the responsible thing to do ✨
📦 where this page comes from
- ietf: rfc5352 2008-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms