RFC 5354
Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters 🌈
okay bestie, this is RFC 5354 💖, and the title block has all the tea:
- Stream: Network Working Group 🎀
- Category: Experimental 🧪
- Date: September 2008 📅
- Authors: R. Stewart and Q. Xie (The Resource Group), M. Stillman (Nokia), and M. Tuexen (Muenster Univ. of Applied Sciences) 👑
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨
Status of This Memo ✨
This memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind. The authors want discussion and suggestions for improvement, and distribution of this memo is unlimited 🦋.
Abstract 💜
This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture 🌸.
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Conventions ................................................3
2. Parameters in General ...........................................3
3. ENRP-ASAP Common Parameters .....................................3
3.1. IPv4 Address Parameter .....................................6
3.2. IPv6 Address Parameter .....................................6
3.3. DCCP Transport Parameter ...................................7
3.4. SCTP Transport Parameter ...................................8
3.5. TCP Transport Parameter ....................................9
3.6. UDP Transport Parameter ....................................9
3.7. UDP-Lite Transport Parameter ..............................10
3.8. Pool Member Selection Policy Parameter ....................11
3.9. Pool Handle Parameter .....................................12
3.10. Pool Element Parameter ...................................12
3.11. Server Information Parameter .............................13
3.12. Operation Error Parameter ................................14
3.12.1. Unspecified Error .................................15
3.12.2. Unrecognized Parameter Error ......................15
3.12.3. Unrecognized Message Error ........................15
3.12.4. Invalid Values Error ..............................16
3.12.5. Non-Unique PE Identifier Error ....................16
3.12.6. Inconsistent Pool Policy Error ....................16
3.12.7. Lack of Resources Error ...........................16
3.12.8. Inconsistent Transport Type Error .................16
3.12.9. Inconsistent Data/Control Configuration Error .....16
3.12.10. Rejected Due to Security Considerations ..........16
3.12.11. Unknown Pool Handle Error ........................17
3.13. Cookie Parameter .........................................17
3.14. PE Identifier Parameter ..................................17
3.15. PE Checksum Parameter ....................................18
3.16. Opaque Transport Parameter ...............................18
4. Common Message Formats .........................................18
5. IANA Considerations ............................................20
5.1. A New Table for RSerPool Parameter Types ..................20
5.2. A New Table for RSerPool Error Causes .....................21
6. Security Considerations ........................................21
7. Normative References ...........................................211. Introduction 💖
ASAP [RFC5352] and ENRP [RFC5353] team up to give you a high-availability, data-transfer mechanism over IP networks 🚀.
Both protocols work together, so they share a bunch of common parameters in their message formats 🫶. This document covers those shared message parameters. It only gives the parameter formats. If you want the procedures and how messages get composed, go check [RFC5352] and [RFC5353] 📚.
1.1. 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] 💅.
2. Parameters in General ✨
Every parameter below MUST be in network byte order (aka Big Endian, i.e., the most significant byte first) during transmission 🔥.
Messages in both ENRP and ASAP are often built from multiple parameters, and those parameters can be nested 🧚. When that happens, a nested parameter includes the length of the padding between the nested parameters, but not the last padding 🙈.
3. ENRP-ASAP Common Parameters 🌸
Parameters use a Type-Length-Value (TLV) format, and it looks like this 🦋:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Parameter Value :
: +-------------------------------:
: | Padding :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Parameter Type is a 16-bit unsigned integer that identifies the kind of parameter 🎀. Valid values run from 0 to 65534. The value 65535 is reserved for IETF-defined extensions. Any value that isn't defined in a specific ENRP parameter description is reserved by the IETF, and extra types can be defined later through the usual IETF/IANA procedures 💜.
The top two bits of the type decide what happens when the receiving endpoint doesn't recognize the type. It's giving "choose your own adventure" 😭:
00: stop processing this ENRP or ASAP message and throw it away, and don't process any more parameters inside it 💀.01: stop processing and throw it away, same as00, but also report the unrecognized parameter in an 'Unrecognized Parameter' error (see Section 3.12) 🚨.10: skip this parameter and keep going 🦋.11: skip this parameter and keep going, but also report the unrecognized parameter in an 'Unrecognized Parameter' error (see Section 3.12) ✨.
Here's the table of parameter type values 🍓:
+-----------------+------------------------------+
| Value | Parameter Type |
+-----------------+------------------------------+
| 0x0 | (Reserved by IETF) |
| 0x1 | IPv4 Address |
| 0x2 | IPv6 Address |
| 0x3 | DCCP Transport |
| 0x4 | SCTP Transport |
| 0x5 | TCP Transport |
| 0x6 | UDP Transport |
| 0x7 | UDP-Lite |
| 0x8 | Pool Member Selection Policy |
| 0x9 | Pool Handle |
| 0xa | Pool Element |
| 0xb | Server Information |
| 0xc | Operation Error |
| 0xd | Cookie |
| 0xe | PE Identifier |
| 0xf | PE Checksum |
| 0x10 | Opaque Transport |
| 0x11-0xfffffffe | (Available for assignment) |
| 0xffffffff | IETF-defined extensions |
+-----------------+------------------------------+Table 1 🌈
Parameter Length is a 16-bit unsigned integer, and it counts the bytes in the whole parameter, so the Type, Length, and Value fields all count 🧮. A parameter with an empty Value field has a Length of 4 💖. The whole parameter (Type, Length, and Value together) has to end up a multiple of 4 bytes. If it doesn't, the sender adds all-zero padding bytes at the end, after the Value field 🫶. That padding isn't counted in the Parameter Length field. Padding is capped at 3 bytes, so a sender MUST NOT pad with more than 3 bytes, and the receiver MUST ignore the padding bytes 🙅♀️. The total length MUST be a multiple of 4 bytes, and the sender MUST pad when it's not, so no skipping that step 💅.
Parameter Value is variable length and holds the actual info the parameter carries 🌸.
Parameter Padding is variable length, and it's the padding we just talked about 🦋.
3.1. IPv4 Address Parameter 🌐
This parameter is a TLV that carries an IPv4 address 💜.
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 = 0x1 | Length = 0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 Address is 32 bits (unsigned integer) holding an IPv4 address, stored in binary form 🫶.
3.2. IPv6 Address Parameter 🌌
This parameter is a TLV that carries an IPv6 address ✨.
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 = 0x2 | Length = 0x14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6 Address is 128 bits (unsigned integer) holding an IPv6 address, stored in binary form 💅.
part 1 is done 🎀 part 2 is coming next, bestie 🦋
3.3. DCCP Transport Parameter ✨
okay so this parameter is a TLV 🎀 that describes a user transport running over Datagram Congestion Control Protocol (DCCP) 💅
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 = 0x3 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCCP Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCCP Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 🌸 This is the entire length of the parameter in number of octets, counting the Type, Length, DCCP port, reserved fields, and IP Address Parameter.
DCCP Port: 16 bits (unsigned integer) 🦋 This is the DCCP port number signed to this DCCP user transport.
DCCP Service Code: 32 bits (unsigned integer) 🧚 This is the DCCP service code signed to this DCCP user transport.
IPv4 or IPv6 Address 💜 This is an IPv4 or IPv6 address parameter (as defined above in Section 3.1 and Section 3.2) assigned to this DCCP user transport. Unlike in an SCTP Transport parameter, only one IP address parameter can be present in a DCCP Transport parameter. 🙈
Note: The DCCP Port MUST NOT be used for control information. For this reason, no Transport Use field is provided. DCCP MUST always be treated as a "Data Only" type transport use. 😭
3.4. SCTP Transport Parameter 🦋
this parameter defines a TLV that describes a user transport using Stream Control Transport Protocol (SCTP) ✨
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 = 0x4 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Port | Transport Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 🌈 This is the entire length of the parameter in number of octets, counting the Type, Length, SCTP port, reserved fields, and all IP Address Parameters present.
SCTP Port: 16 bits (unsigned integer) 💖 This is the SCTP port number signed to this SCTP user transport.
Transport Use: 16 bits (unsigned integer) 👑 This field shows how the pool element intends this transport address to be used. The field MUST be populated with one of the following values:
+-------------------+--------+
| Type | Value |
+-------------------+--------+
| DATA ONLY | 0x0000 |
| DATA plus CONTROL | 0x0001 |
+-------------------+--------+IPv4 or IPv6 Address #1 - #n 🫶 Each one is an IPv4 or IPv6 address parameter (as defined above in Section 3.1 and Section 3.2) assigned to this SCTP user transport. An SCTP Transport parameter may have a mixed list of IPv4 and IPv6 addresses, and at least one IP address parameter MUST be present in an SCTP Transport parameter. 🔥
3.5. TCP Transport Parameter 🌸
this parameter defines a TLV that describes a user transport using TCP 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 = 0x5 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 🎀 This is the entire length of the parameter in number of octets, counting the Type, Length, TCP port, reserved fields, and IP Address Parameter.
TCP Port: 16 bits (unsigned integer) 💅 This is the TCP port number signed to this TCP user transport.
IPv4 or IPv6 Address 🧚 This is an IPv4 or IPv6 address parameter (as defined above in Section 3.1 and Section 3.2) assigned to this TCP user transport. Unlike in an SCTP Transport parameter, only one IP Address parameter can be present in a TCP Transport parameter. 💜
Note: The TCP Port MUST NOT be used for control information. For this reason, no Transport Use field is provided. TCP MUST always be treated as a "Data Only" type transport use. 💀
3.6. UDP Transport Parameter 🦋
this parameter defines a TLV that describes a user transport using UDP 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 = 0x6 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 🌈 This is the entire length of the parameter in number of octets, counting the Type, Length, UDP port, reserved fields, and IP Address Parameter.
UDP Port: 16 bits (unsigned integer) ⭐ This is the UDP port number signed to this UDP user transport.
IPv4 or IPv6 Address 🍓 This is an IPv4 or IPv6 address parameter (as defined above in Section 3.1 and Section 3.2) assigned to this UDP user transport. Unlike in an SCTP Transport parameter, only one IP Address parameter can be present in a UDP Transport parameter. 🙈
Note: The UDP Port MUST NOT be used for control information. For this reason, no Transport Use field is provided. UDP MUST always be treated as a "Data Only" type transport use. 😭
3.7. UDP-Lite Transport Parameter 💖
this parameter defines a TLV that describes a user transport using UDP-Lite 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 = 0x7 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP-Lite Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 👑 This is the entire length of the parameter in number of octets, counting the Type, Length, UDP-Lite port, reserved fields, and IP Address Parameter.
UDP Port: 16 bits (unsigned integer) 🔥 This is the UDP-Lite port number signed to this UDP-Lite user transport.
IPv4 or IPv6 Address 🌸 This is an IPv4 or IPv6 address parameter (as defined above in Section 3.1 and Section 3.2) assigned to this UDP-Lite user transport. Unlike in an SCTP Transport parameter, only one IP address parameter can be present in a UDP-Lite transport parameter. ✨
Note: The UDP-Lite Port MUST NOT be used for control information. For this reason, no Transport Use field is provided. UDP-Lite MUST always be treated as a "Data Only" type transport use. 💅
3.8. Pool Member Selection Policy Parameter 🧚
this parameter defines a pool member selection policy. RSerPool supports multiple pool member selection policies and also allows the definition of new selection policies in the future. 🦋
The enforcement rules and handling procedures of all the policies are defined in [RFC5352].
All pool member selection policies, both present and future, MUST use the following general parameter format: 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy-specific Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 💜 This is the entire length of the parameter in number of octets, counting the Type, Length, Policy Type, and the Policy-specific Data fields. Note, the Length field value will NOT include any padding at the end of the parameter.
Policy Type: 32 bits (unsigned integer) 💖 This specifies the type of selection policy. The values are defined in [RFC5356].
Policy-specific Data: 🌈 The structure and fields for each presently defined policy type are described in detail in [RFC5356].
3.9. Pool Handle Parameter 🍓
this parameter holds a pool handle 🫶
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 = 0x9 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Handle :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 🔥 This is the entire length of the parameter in number of octets, counting the Type, Length, and Pool Handle string. Note, the value in the Length field will NOT cover any padding at the end of the parameter.
Pool Handle 👑 Defined as a sequence of (Length - 4) bytes.
3.10. Pool Element Parameter 🧚
okay so this parameter is the main character of ENRP messages 💅 It shows up in a bunch of them to represent an ASAP endpoint (aka a Pool Element, or PE, in a pool) plus all its deets: its transport address, its selection policy, and other operational or status info. literally the whole PE profile in one TLV 🎀
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 = 0xa | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home ENRP Server Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Life |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: User Transport param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Member Selection Policy param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ASAP Transport param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 📏 Tells you the whole length of the parameter in octets 🫶 It counts the Type, Length, PE Identifier, Registration Life, User Transport, and Member Selection Policy parameters. heads up: the Length value will NOT cover any padding at the end of this Pool Element parameter, so don't go counting the padding 🙈
PE Identifier: 32 bits (unsigned integer) 🆔 Uniquely identifies the PE in the pool. the PE picks its own identifier when it starts up, so it's giving main character origin story ✨
Home ENRP Server Identifier: 32 bits (unsigned integer) 🏠 Shows the current Home ENRP server of this PE. if the PE's Home ENRP server is undetermined, set it to all 0s 🫠
Registration Life: 32 bits (signed integer) ⏳ The lifetime of the registration, in seconds. a value of -1 means infinite lifetime, aka forever bestie 💜
User Transport 📡 This can be a DCCP, SCTP, TCP, UDP, UDP-Lite, or Opaque Transport parameter (see Section 3.3, Section 3.4, Section 3.5, Section 3.6, Section 3.7, and Section 3.16). the rule here is that a PE MUST have one and only one User Transport. no more, no less, periodt 💅
Member Selection Policy 🎯 Contains one of the defined member selection policy parameters (see Section 3.8).
ASAP Transport 🚪 This is the ASAP transport address of the PE. it MUST be an SCTP type transport parameter (see Section 3.4). no vibes-based choices here 😤
3.11. Server Information Parameter 🖥️
this one passes around the basic info of an ENRP server. think of it as the server's little dating profile 💖
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 = 0xb | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Transport :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 📏 The entire length of the parameter in bytes. the Length value will NOT cover any padding at the end of the parameter, so skip the padding in your math 🙈
Server ID: 32 bits (unsigned integer) 🪪 This is the ID of the ENRP server, as defined in [RFC5353]. the server's main character ID 👑
Server Transport: 🛣️ This is an SCTP Transport Parameter, as defined in Section 3.4, that holds the network access address(es), SCTP port number, etc. of the ENRP server. basically everything you need to slide into its DMs 📬
3.12. Operation Error Parameter 🚨
this one is used in both ENRP and ASAP so a message sender can report error(s) to a message receiver. bestie, when something goes wrong, the drama gets documented 📝
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 = 0xc | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: one or more Error Causes :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 📏 The entire length of the parameter in bytes. the Length value will NOT cover any padding at the end of the parameter 🫶
Error causes are variable-length parameters, and they use this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Cause-Specific Information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cause Code: 16 bits (unsigned integer) 🔖 Defines the type of error condition being reported. here's the full menu of codes 👇
+------------------+-----------------------------------------+
| Cause Code Value | Cause Code |
+------------------+-----------------------------------------+
| 0x0 | Unspecified Error |
| 0x1 | Unrecognized Parameter |
| 0x2 | Unrecognized Message |
| 0x3 | Invalid Values |
| 0x4 | Non-unique PE Identifier |
| 0x5 | Inconsistent Pooling Policy |
| 0x6 | Lack of Resources |
| 0x7 | Inconsistent Transport Type |
| 0x8 | Inconsistent Data/Control Configuration |
| 0x9 | Unknown Pool Handle |
| 0xa | Rejected due to security considerations |
| 0xb -0xffff | (Available for assignment) |
+------------------+-----------------------------------------+
Table 2Cause Length: 16 bits (unsigned integer) 📐 Set to the size of the parameter in bytes, counting the Cause Code, Cause Length, and Cause-Specific Information fields. it does not include any padding at the end of this error cause TLV 🙈
Cause-specific Information: variable length 🧩 This field carries the details of the error condition. the tea goes here ☕
The following subsections (Section 3.12.1 - Section 3.12.9) define specific error causes. 💅
3.12.1. Unspecified Error 🤷♀️
this one is for reporting an unspecified error by the sender. no cause-specific info, we don't know what happened and that's the vibe 🌫️
3.12.2. Unrecognized Parameter Error 🫥
this one reports an unrecognized parameter. the complete, unrecognized parameter TLV gets included as the cause-specific information. if a message has multiple unrecognized parameters, you use multiple error causes, one per parameter 📋
3.12.3. Unrecognized Message Error 📭
this one reports an unrecognized message. the unrecognized message TLV goes in as the cause-specific information 💌
3.12.4. Invalid Values Error ❌
this one reports one or more invalid values found in a received parameter. the offending TLV holding the invalid value(s) is included as cause-specific information. caught red-handed 🙃
3.12.5. Non-Unique PE Identifier Error 👯
an ENRP server uses this to tell a registering PE that the PE Identifier it picked has already been taken by another PE in the pool. oop, name's taken, bestie 💔 there's no cause-specific information.
3.12.6. Inconsistent Pool Policy Error 📜
an ENRP server uses this to tell a registering PE that the pool policy it picked doesn't match the overall policy of the pool. a Pool Member Selection Policy TLV (see Section 3.8) that shows the overall pool policy is included as cause-specific information. so it can see the vibe check it failed 🎯
3.12.7. Lack of Resources Error 🪫
this one is used to say the sender doesn't have certain resources to perform a requested function. no cause-specific information. running on empty, no shade 😮💨
3.12.8. Inconsistent Transport Type Error 🚫
an ENRP server uses this to tell a registering PE that the User Transport it picked doesn't match the overall user transport of the pool. a Transport TLV that shows the overall pool user transport type is included as cause-specific information. you gotta match the group, sis 👯♀️
3.12.9. Inconsistent Data/Control Configuration Error 🎛️
an ENRP server uses this to tell a registering PE that the Transport Use field in the User Transport it sent in its registration doesn't line up with the pool's overall data/control channel configuration. no cause-specific information. the configs are not vibing 🫤
3.12.10. Rejected Due to Security Considerations 🛡️🔐
any endpoint can use this one to say a request got rejected because of a failure in security credentials or authorizations. security said absolutely not, and it's not negotiable 🚷 this is the serious one, so take it seriously!
3.12.11. Unknown Pool Handle Error 🫥🏊
an ENRP server uses this to tell a PE or PU that the requested pool is unknown to the server. there's no cause-specific information. this pool? never heard of her 🤨
3.13. Cookie Parameter 🍪
this one defines a TLV that carries a Cookie. yes it's an actual cookie, and yes I'm excited 🥹
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 = 0xd | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Cookie :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 📏 The entire length of the parameter in bytes, counting the Type, Length, and Cookie 🧮
Cookie: variable length 🍪 The Cookie is an arbitrary byte string of (Length - 4) bytes. a surprise bag of bytes 🎁
3.14. PE Identifier Parameter 🆔✨
this one defines a TLV that carries a PE Identifier. it's the PE's name tag, basically 🏷️
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 = 0xe | Length=0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PE Identifier: 32 bits (unsigned integer) 🪪 Uniquely identifies the PE in the pool. the PE picks its identifier when it starts up. for tips on generating PE identifiers, check out [RFC5352] 📚 it's giving research before commitment 💜
3.15. PE Checksum Parameter ✨
okay so this one is a TLV that carries a PE Checksum 🧮 it's giving tidy bookkeeping energy
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 = 0xf | Length=0x6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Checksum | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PE Checksum: 16 bits (unsigned integer) 🔢 An overall checksum of all PEs in the current handlespace owned by an ENRP server, which is normally the sender of this TLV. The definition and calculation of this checksum is defined in [RFC5353]. 💖
3.16. Opaque Transport Parameter 🦋
this parameter is a TLV that carries opaque transport information. bestie, "opaque" just means the contents are an arbitrary byte string and the format is not spelled out here 🫶
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 = 0x10 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Opaque Transport Data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: 16 bits (unsigned integer) 📏 Indicates the entire length of the parameter in number of bytes, including the Type, Length, and Opaque Transport Data.
Opaque Transport Data: variable length 🌈 The Opaque Transport Data is an arbitrary byte string of (Length - 4) bytes.
4. Common Message Formats 💅
okay this is the common format for every single ASAP and ENRP message 💌 each one gets a Message Type field, a message-specific Flag field, a Message Length field, and a Value field. iconic layout, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Msg Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Message Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message Type: 8 bits (unsigned integer) 🎀 This field identifies the type of information contained in the Message Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field. Message Types are encoded such that the two bits of the highest order specify the action that must be taken if the message receiver does not recognize the Message Type. 👑
00Stop processing this message and discard it.01Stop processing this message and discard it, and report the unrecognized message in an 'Unrecognized Message' error (see Section 3.12.3). 🚨10Reserved.11Reserved.
Message Flags: 8 bits 🚩 The usage of these bits depends on the message type, as given by the Message Type. Unless otherwise specified, they are set to zero on transmit and ignored on receipt.
Message Length: 16 bits (unsigned integer) 🍓 This value represents the size of the message in bytes, including the Message Type, Message Flags, Message Length, and Message Value fields. Therefore, if the Message Value field is zero length, the Length field will be set to 4. Note, the value in the Message Length field will NOT cover any padding at the end of this message. 🙈
Message Value: variable length 🧚 The Message Value field contains the actual information to be transferred in the message. The usage and format of this field is dependent on the Message Type. The total length of a message (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the message is not a multiple of 4 bytes, the sender MUST pad the message with all zero bytes and this padding is not included in the Message Length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes. ✨
5. IANA Considerations 🗂️
this document (RFC 5354) is the reference for all the registrations described in this section. all of them have been listed on the RSerPool Parameters page 📋
5.1. A New Table for RSerPool Parameter Types 🦋
RSerPool Parameter Types are maintained by IANA. Thirteen initial values have been assigned by IANA, as described in Table 1. IANA created a new table, "RSerPool Parameter Types":
+------------+------------------------------+
| Value | Parameter Type |
+------------+------------------------------+
| 0x0 | (Reserved by IETF) |
| 0x1 | IPv4 Address |
| 0x2 | IPv6 Address |
| 0x3 | DCCP Transport |
| 0x4 | SCTP Transport |
| 0x5 | TCP Transport |
| 0x6 | UDP Transport |
| 0x7 | UDP-Lite |
| 0x8 | Pool Member Selection Policy |
| 0x9 | Pool Handle |
| 0xa | Pool Element |
| 0xb | Server Information |
| 0xc | Operation Error |
| 0xd | Cookie |
| 0xe | PE Identifier |
| 0xf | PE Checksum |
| 0x10 | Opaque Transport |
| 0xffffffff | IETF-defined extensions |
| others | (Reserved by IETF) |
+------------+------------------------------+Requests to register an RSerPool Parameter Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied. 💌
5.2. A New Table for RSerPool Error Causes 🚫
RSerPool Error Causes are maintained by IANA. Eleven initial values have been assigned by IANA, as described in Table 2. IANA created a new table, "RSerPool Error Causes":
+------------------+-----------------------------------------+
| Cause Code Value | Cause Code |
+------------------+-----------------------------------------+
| 0x0 | Unspecified Error |
| 0x1 | Unrecognized Parameter |
| 0x2 | Unrecognized Message |
| 0x3 | Invalid Values |
| 0x4 | Non-Unique PE Identifier |
| 0x5 | Inconsistent Pooling Policy |
| 0x6 | Lack of Resources |
| 0x7 | Inconsistent Transport Type |
| 0x8 | Inconsistent Data/Control Configuration |
| 0x9 | Unknown Pool Handle |
| 0xa | Rejected Due to Security Considerations |
| others | (Reserved by IETF) |
+------------------+-----------------------------------------+Requests to register an RSerPool Error Cause in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied. 🔥
6. Security Considerations 🔐
⚠️ bestie, read this part properly. 💀
this document only contains common parameter formats. as such, it specifies no new security constraints on either ENRP or ASAP. the details on ENRP and ASAP security constraints live in [RFC5353] and [RFC5352] 🛡️
7. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
Authors' Addresses 🎀
Randall R. Stewart, The Resource Group, 1700 Pennsylvania Ave NW, Suite 560, Washington, DC 20006, USA. Phone: EMail: randall.stewart@trgworld.com 💖
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.de 🧚
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
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.
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶
📦 where this page comes from
- ietf: rfc5354 2008-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms