RFC 4678
Server/Application State Protocol v1
Server/Application State Protocol v1 🎀
- Network Working Group 🌸 this one is from the Network Working Group
- RFC: 4678 💖
- Author: A. Bivens, from IBM Research 🧚
- Category: Informational 📚
- Date: September 2006 🍓
- Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates, so it doesn't change anything else 🦋
Status of This Memo ✨
okay so this memo is for information only, so the internet community can read it. It is not an Internet standard of any kind 🙈. Distribution is unlimited, so share it with everyone 💅.
Copyright Notice 🌈
Copyright (C) The Internet Society (2006).
IESG Note 💀
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
ngl this one is serious 😭. It isn't a candidate for any level of Internet Standard. The IETF isn't claiming it knows whether this RFC is fit for any purpose, and the decision to publish wasn't based on IETF review of things like security, congestion control, or bad interactions with protocols already out there. The RFC Editor picked it to publish at their own discretion. So if you're thinking about implementing or deploying this, be careful and check it properly first 🫶. See RFC 3932 for more.
Abstract 🔥
okay so entities that spread work across a group of systems usually don't know much about how well the apps on those systems can handle the work 👀. Workload management systems know all the tea about how healthy the apps are, but they have basically no control over how fast those apps get work 💅. That's where SASP comes in! The Server/Application State Protocol gives load balancers and workload management systems a way to communicate, so they can distribute the existing workload to the group members in better ways ✨.
Table of Contents 📖
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Identities .................................................4
2. Requirements Notation ...........................................4
3. Conventions Used in This Document ...............................4
4. General Message Structure .......................................4
4.1. TLV Structure ..............................................6
4.2. Component Types ............................................6
4.3. SASP Protocol Header .......................................7
4.4. Version Negotiation ........................................8
5. Singular Protocol Components ....................................9
5.1. Member Data Component ......................................9
5.2. Group Data Component ......................................11
5.3. Weight Entry Data Component ...............................12
5.4. Member State Instance Component ...........................14
6. Group Protocol Components ......................................15
6.1. Group of Member Data Component ............................15
6.2. Group of Weight Data Component ............................16
6.3. Group of Member State Data Components .....................17
7. Protocol Messages ..............................................17
7.1. Registration Request and Reply ............................18
7.1.1. Registration Request ...............................18
7.1.2. Registration Reply .................................19
7.2. DeRegistration Request and Reply ..........................20
7.2.1. DeRegistration Request .............................21
7.2.2. DeRegistration Reply ...............................22
7.3. Get Weights Request and Reply .............................23
7.3.1. Get Weights Request ................................24
7.3.2. Get Weights Reply ..................................25
7.4. Send Weights ..............................................26
7.5. Set Member State Request and Reply ........................27
7.5.1. Set Member State Request ...........................28
7.5.2. Set Member State Reply .............................29
7.6. Set Load Balancer State Request and Reply .................30
7.6.1. Set LB State Request ...............................30
7.6.2. Set LB State Reply .................................32
8. Example of SASP Message Encoding ...............................32
9. Protocol Flow ..................................................37
9.1. Normal Protocol Flow ......................................37
9.2. Behavior in Error Cases ...................................39
9.3. Example Flow 1: Load Balancer Registration,
Getting Weights, and Application-Side Quiescing ...........41
9.4. Example Flow 2: Set Load Balancer State, Application
Registration, and Load Balancer Group DeRegistration ......43
9.5. Avoiding Single Points of Failure .........................44
10. Security Considerations .......................................45
11. Normative References ..........................................46
Appendix A. Acknowledgements ......................................471. Introduction 🦋
1.1. Overview 🌟
okay so SASP is designed to help load balancers or schedulers do three things 💖. They can (1) get traffic weight recommendations from Workload Managers, (2) register with Workload Managers the members of their load balancing/scheduling groups, and (3) let Workload Managers suggest new load balancing group members to load balancers and schedulers 🧚.
The figure below shows where the SASP entities sit in a typical load balancing topology 👀.
----------
| Group |
-------->|Member 1|<--|
| ---------- |
| |
--------- ---------- | ---------- |
|Request|<------>| Load |---| | Group | |
|Origins|<------>|Balancer|----------->|Member 2|<--|
--------- | |---| ---------- |
---------- | |
^ | ---------- |
| -------->| Group | |
SASP | |Member 3|<--|
------- ---------- |
| |
| -------------------- |
| | Group | SASP |
------>| Workload Manager |<----------
--------------------
Figure 1So SASP is a binary protocol 🤖, and it handles the communication from load balancers/schedulers to Workload Managers 💅. The connection between the Group Workload Manager (GWM) and the load balancer/scheduler is expected to be a long-running TCP connection 🔥. In SASP interactions, the GWM acts as a SASP server, waiting around to receive connections from the other SASP components 🫶. Server port 3860 has been registered with the IANA for SASP communications 🎀. All SASP components are expected to be configured with the DNS name of the GWM so they can set up this connection 🌸.
Security in SASP is handled by transporting the binary messages over Secure Socket Layer/Transport Layer Security (SSL/TLS) 🔐. This document only describes the message format and protocol behavior above the connection and security layers ✨. The connection and security aspects, including SSL's authentication and encryption, are going to be implementation specific, so those choices are up to you 🧚.
1.2. Identities 🪪
SASP identifies a load balancer by a UTF-8 string called a "LB UID" 💖. A group of "equivalent" servers that provide a service is identified by a UTF-8 string called a "Group Name", and that name gets interpreted in the context of the LB UID 🌈. A server is identified by its IP address and its (optional) port and protocol numbers 🍓. A GWM is only identified implicitly, as the entity on the other end of the TCP connection from a load balancer or group member 👀.
All of these identifiers are local, so there are no globally unique identifiers 🙈. The LB UID and GroupName fields are unstructured on purpose, so that components can assign values that mean something to an administrator 💅. For example, in lots of cases a load balancer would use the name an administrator gave the serverfarm group as the groupname in a SASP-specified group 🫶. And since the naming options in industry load balancers don't come with explicit naming restrictions, SASP's naming options don't have any restrictions either ✨.
2. Requirements Notation 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.
3. Conventions Used in This Document 🎀
okay so here are the main players 🧚:
- Load Balancer: the entity responsible for distributing requests amongst the available members 🌸.
- Member: a machine, process, or application used to service requests 💖.
- Group Workload Manager (GWM): the entity responsible for reporting on or managing a group of members across multiple machines 🔥.
Part 1 of 9 done ✨ Next up: Section 4, General Message Structure 💅
4. General Message Structure ✨
okay so bestie, first up: every string the group workload manager reads is assumed to be UTF8 🌸 Components implementing SASP MUST support the printable ASCII subrepertoire of UTF8 (0x20-0x7E). That's the non-negotiable baseline 🫶 Components MAY also choose to support other UTF8 character encodings, which is totally optional. It's recommended that customers using SASP-enabled products set up their string-generating components (load balancers and group members) to use the same character repertoire. Keeping everyone on the same page is so important ngl 💅
Lots of SASP structures move multi-byte integer values around. Whenever they do, those integers are in network-byte order (big-endian) 🔥
SASP is built from several message components, and for extendibility and easy processing, each one is described in a TLV (Type, Length, Value) format 🎀 The example below shows the whole vibe. The first thing you'll see is the header, followed by the message type component. The header, the message component, and every other component all use TLV. Each component value holds a variable number of fields, and some of those fields point at upcoming components (those component descriptions get their own sections, coming up next 👀). After the first message component, you can add any number of extra components, as long as the fields of the message type allow it ✨
-------------------------------------------------
| |T| Type (SASP Header Type) |
| SASP |----------------------------------|
| Header |L| Length of SASP header TLV |
| |----------------------------------|
| |V| Header fields |
|-----------------------------------------------|
| |T| Type (Message Type) |
| Message |----------------------------------|
| Type |L| Length of this Message Type TLV|
| Component |----------------------------------|
| |V| Component fields |
|-----------------------------------------------|
| |T| Type (Component Type) |
| |----------------------------------|
|Component-1 |L| Length of this TLV |
| |----------------------------------|
| |V| Component fields |
|-----------------------------------------------|
| ... |
|-----------------------------------------------|
| |T| Type (Component Type) |
| |----------------------------------|
|Component-n |L| Length of this TLV |
| |----------------------------------|
| |V| Component fields |
-------------------------------------------------Figure 2
4.1. TLV Structure 🦋
Here's the TLV format. The Type is a two-byte field holding a binary value for the component type. The Length is a two-byte field with the size of the TLV in bytes (Type and Length fields included, so it counts itself too 🙈). The Value field is variable-length and holds the actual data of the component.
< xxxx xxxx xxxx xxxx, xxxx xxxx xxxx xxxx, xxxx...........xxxx >
|-----------------| |-----------------| |-----------------|
Type(2 bytes) Length(2 bytes) Value(variable)Figure 3
4.2. Component Types 🧚
Every protocol component needs a type value in the TLV structure. Here's the full list of SASP types, and yes, it's giving registry energy 💜
Reserved 0x0000-0x1000
Message Types
Registration Request 0x1010
Registration Reply 0x1015
DeRegistration Request 0x1020
DeRegistration Reply 0x1025
Get Weights Request 0x1030
Get Weights Reply 0x1035
Send Weights 0x1040
Set Load Balancer State Request 0x1050
Set Load Balancer State Reply 0x1055
Set Member State Request 0x1060
Set Member State Reply 0x1065
Utility Component Types
SASP Header 0x2010
Singular Component Types
Member Data 0x3010
Group Data 0x3011
Weight Entry Data 0x3012
Member State Instance 0x3013
Group Component Types
Group of Member Data 0x4010
Group of Weight Entry Data 0x4011
Group of Member State Data 0x4012
Reserved 0xF000-0xFFFF4.3. SASP Protocol Header 🌈
Here's the SASP Header, drawn out for you 🫶 Every message is expected to start with the SASP Protocol Header component, no exceptions bestie.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SASP header type (0x2010) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+Figure 4
- Version: the protocol version used in this message 💖
- Message Length: a 4-byte signed integer for the total length of the SASP message. It's signed 4-byte so Java implementations (or any other implementations without unsigned values) have an easier time 🙈 Negative lengths are not valid tho, so don't try it 💀
- Message ID: every request message gets a 4-byte Message ID from its originator, and that same ID comes back in the Message ID field of the reply. It's there so the requester can match up replies to the right request when a bunch of requests are flying around 🦋 In the Send Weights message (the only message transaction with no reply), this field doesn't do anything at all.
4.4. Version Negotiation 👑
Okay, so how do the entities in a connection agree on a version? The GWM treats the version in the load balancer's request as the load balancer's proposed version 🎀
If the GWM supports the proposed version, it responds with the right response code and the load balancer's proposed version in the response header. That proposed version is then the one used for every message in that connection ✨
If the GWM doesn't support the proposed version, it replies with a "message not understood" response code and its own highest supported SASP version in the version field of the response header. That's the signal for the load balancer to drop down to the GWM's SASP version level 🥺
5. Singular Protocol Components 💅
The most basic SASP components are the singular ones, since each describes a single instance of a member, member resource, member weight, or group 🌸 Some components reuse other components. When that happens, the reused component just shows up right after the base component. You'll see this trick in the Weight Entry and Member State Instance components 👀
5.1. Member Data Component 💜
The member data component describes a particular member, and other components refer back 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ IP Address of Member +
| |
+ +-+-+-+-+-+-+-+-+
| | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Label .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5
- Protocol: the assigned number of the IP transport layer used in the Protocol Field of the IP header. These are defined in [RFC1700], but a current list is kept at
http://www.iana.org.for example: TCP = 0x06, UDP = 0x11, etc. - Port: the port number used to talk to the member.
A value of 0 can be given for Protocol and Port to mean a system level member. But 0 shouldn't be read as a wildcard for either Port or Protocol (so a deregistration request with a MemberData component that has 0 for the port does NOT mean "deregister every app listening on any port of that IP and protocol" 🙅♀️).
- IP Address: the current format is 16 bytes, and IPv4 addresses are written as "IPv4-compatible IPv6 addresses" [RFC4291]. In the examples below, the x's are arbitrary hex values, and the zeros are the fixed bits.
IPv4 Address: 00 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx
IPv6 Address: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx- Label length: how many bytes long the label string that follows is 🍓
- Label: a UTF8 string that can be set while registering a member. The GWM doesn't interpret it, it just includes it with any correspondence containing the member data component 🎀 The label has to be <= 255 bytes. UTF8 characters can be up to 6 bytes each, so the load balancer or member needs to check that the UTF8 string it sends to the GWM really is <= 255 bytes. Don't let your label get too chunky bestie 😭
5.2. Group Data Component 🫶
Okay bestie, the group data component is basically the "this is my squad" card 🎀. It describes a group, and then other singular components get linked to it so the system knows who's in which crew 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Data Type (0x3011) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB UID Length | |
+-+-+-+-+-+-+-+-+ +
. .
. LB UID .
. .
+ +-+-+-+-+-+-+-+-+
| |Group Name Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Group Name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6
- LB UID Length: the length of the LB UID that comes next, in bytes. 📏
- LB UID: a UTF8 string that works as a unique ID and as context for the Group Name 🆔. For example, it can be a UTF8 representation of the MAC address of the load balancer, or some kind of Universally Unique Identifier (UUID). The Group Workload Manager uses it to link application registration and deregistration, and to send state messages to the correct load balancer 🎯. This unique identifier should not be any longer than 64 bytes.
- Group Name Len: the length of the Group Name field that comes next, in bytes.
- Group Name: a UTF8 string that the load balancer picks to tell the Group Workload Manager that members registered under this Group Name are equivalent in function 🧚. In Get Weight and DeRegistration messages, the Group Name may be omitted (Group Name Length = 0) to mean all groups from the associated load balancer 🌈.
5.3. Weight Entry Data Component 💜
The Weight Entry Component is what the get and send weight messages use to attach a weight to a particular member (or Member Data) ⚖️. It also carries an opaque member state field and a general member flags field, which tell you extra stuff about the member (more on that below). When you use the Weight Entry component, the Member Data TLV it refers to goes first, and the Weight Entry TLV comes right after 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this Member Data TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Member Data Fields .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight Entry Type (0x3012) | Size of this Weight Entry TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State Field | Flags Field | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7
- State Field: the member uses this to pass state info to the scheduler 🧠. The GWM treats it as opaque, so it just gets forwarded to the scheduler along with the member weights. There are no defined values for this field.
- Flags Field: this one has several flag values that describe different attributes of the member 🚩.
- A. Contact Success Flag (set by the GWM): tells you whether the member is currently running 🏃. If the contact success flag is off, the load balancer should avoid this member.
xxxx xxx1The GWM has located this running system or application ✅.xxxx xxx0The GWM has not located this running system or application ❌.
- B. Quiesce Flag (set by the load balancer or Member): used when an admin wants to temporarily take a member out of the weight calculation, without deregistering it from the group 😴. While quiesced, the member still shows up in the weights, but the quiesce flag is set and its weight is zero. When the admin brings the member back to active, the quiesce flag becomes 0 and a weight gets provided. If the quiesce flag is on, the load balancer should avoid this member.
xxxx xx1xThe member is quiesced.xxxx xx0xThe member is active (not quiesced).
- C. Registration Flag (set by the GWM): stores how the member got registered 📝.
xxxx x1xxThis member has been registered by the load balancer/scheduler.xxxx x0xxThis member has registered itself.
- D. Confident Flag (set by the GWM): tells you whether the GWM actually knows this member's state 🔮. If this flag is off for only some of the members in the group while the rest have valid weights, the load balancer should avoid sending work to the members with the confident flag off. If the confident flag is off for all valid group members, the load balancer should ignore any recommendation from the GWM until the confident flag comes back on for at least one member. In that all-off case, the load balancer should figure out the right distribution of work some other way (maybe a different advisor, previously configured static weights, etc.) 🛠️.
- A. Contact Success Flag (set by the GWM): tells you whether the member is currently running 🏃. If the contact success flag is off, the load balancer should avoid this member.
The whole point of the confident flag is to tell the load balancer that it should look to other sources for distribution recommendations when the GWM can't give recommendations for any of the valid group members 💅. If some members have the confident flag on but the contact flag off or the quiesced flag on (meaning they should always be avoided), while the rest of the group has their confident flag off, the load balancer should work out the right distribution for the confident-off members some other way 🫠.
xxxx 1xxxGWM has determined it has knowledge of the state of this member.xxxx 0xxxGWM has no knowledge of the state of this member.
- E. Leftmost four bits are reserved (0000 xxxx - 1111 xxxx) 🔒.
- Weight: this is the GWM's recommendation for the relative amount of work that should be sent to this member 🍰. It's a 16-bit field with a possible range of 0 to 65536. Load balancers should be ready to receive a wide range of weight values 🌊. Load balancers with a limited maximum weight value might restrict how finely the GWM can manage things, which can make performance less than optimal 😬. Plenty of existing implementations have supported a minimum raw weight range from 0 to 100 💯.
5.4. Member State Instance Component 🦋
The Member State Instance Component is what the set member state message uses to show the sender's view of the state of the member mentioned 👀. This component is for setting values that will eventually end up in the WeightEntry component. When you use the Member State Instance component, the Member Data TLV it refers to goes first, and then the Member State Instance TLV follows right after 🍓.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this Member Data TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Member Data Fields .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member State Instance(0x3013) | Size of Member State Inst TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State Field | Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8
- State Field: the member uses this to pass state info to the load balancer or scheduler 📡. There are no defined values for this field.
- Flags Field: this describes attributes of the member 🎀. Right now, the only flag value defined is the quiesce flag 😴. The quiesce flag is for when an admin wants to temporarily take a member out of the weight calculation, without deregistering it from the group. While quiesced, the member still shows up in the weights, but the quiesce flag is set and its weight is zero. When the admin brings the member back to active, the quiesce flag becomes 0 and a weight gets provided.
- A. Quiesce Flag
xxxx xxx1The member or load balancer setting this state is quiescing this member.xxxx xxx0The member or load balancer setting this state is placing the member in a non-quiesced state.
- B. Leftmost seven bits are reserved (0000 000x - 1111 111x) 🔒.
- A. Quiesce Flag
6. Group Protocol Components 🧚♀️
Group protocol components each hold a collection of related singular components 🫧. Specifically, they link Member Data, Weight Entry, or Member State Instance components to a particular Group Data component. In these cases, the specific "Group of x" component is immediately followed by the Group Data component, and the Group Data component is immediately followed by any number of singular components that belong to the group 💖. In the figures in this document, a component type with an asterisk means that component gets repeated a number of times ⭐.
6.1. Group of Member Data Component ✨
okay so the "group of member data" component is how you describe one particular group of members, and it shows up in the registration message components 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group of Member Data (0x4010) | Size of GroupOfMemberData TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9- Member Count: this is the number of Member Data Components sitting right after the Group Data structure 💅
- Array of Member Data Components: there will be as many Member Data TLVs as Member Count has specified 🌸 A load balancer/scheduler uses these components to pass along info that lets the Group Workload Manager figure out which members to associate with this Group Name 🧚 The Member Data Component was described in Section 5.1. In DeRegistration messages, the Member Count may be set to 0 to indicate all members of a particular group ✨
6.2. Group of Weight Data Component 🦋
the "Group of Weight Data" Component is used by the get and send weight messages to make a list of Weight Entry Components for one particular group 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Group Weight Entry Type(0x4011)| Size of GroupOfWeightEntry TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight Entry Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10- Weight Entry Count: the number of Member Data / Weight Entry combinations that follow the Group Data TLV 🍓
- Array of Weight Entry Data TLVs: there will be as many [Member Data / Weight Entry] TLVs as Weight Entry Count has specified 💅 Each Weight Entry component is preceded by its matching Member Data component, as explained in Section 5.3 🫶 This Member Data / Weight Entry pairing repeats until you have as many Weight Entry items as the Weight Entry Count says ✨
6.3. Group of Member State Data Components 🌈
the "group of member state data" component describes a particular set of members and their state fields, which get used in the Set Member State messages 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Group Weight Entry Type(0x4011)| Size of GroupOfWeightEntry TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member State Instance Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Member State Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11- Member State Instance Count: the number of Member Data / Member State Instance combinations that follow the Group Data component 🦋
- Array of Member State Data Components: each Member State Instance component is immediately preceded by its matching Member Data component, as explained in Section 5.4 💜 This Member Data / Member State Instance combination repeats to form as many Member State items as the Member State Instance Count specifies 🔥
7. Protocol Messages 💖
SASP messages are a collection of TLVs (Type, Length, and Value components), so they're giving very structured 🧚 The header has no info about what type of message it belongs to. The purpose-specific info lives in the message component instead 🫶 This format could let you put more than one message component in a single message, but this isn't supported in every GWM and could produce indeterminate behavior 😭 Just like the other protocol components, when a message component needs to involve other components, the additional components immediately follow the message component 🌸
All SASP requests sent to the GWM get acknowledged with a reply 💅 The reply has the info you asked for plus a single-byte response code that tells you how the request went ✨ SASP defines some general response codes in the range 0x00 - 0x3F that can be used no matter what the response message type is 🎀 Some request types can cause specific error conditions that the general codes don't cover, though, and that's where the 0x40 - 0xFF range comes in, reserved for these message-specific response codes 👑 Any given SASP response only contains one response code, depending on the error type 🙈 This section explains the format and purpose of specific SASP messages 🦋
7.1. Registration Request and Reply 💜
this exchange happens between the load balancer/scheduler and the Group Workload Manager, and also between the Group Workload Manager and the member. Its job is to register the members in a group specified by Group Name 🌈 Applications are identified with an IP address, Protocol, and Port. Systems are identified only with an IP Address (Port = 0x0000 and Protocol = 0x00) 🧚 All members in a group have equivalent functionality, so the Group Workload Manager can direct routers, load balancers, and schedulers to any member in the group 🫶 Registrations can come from either the load balancer/scheduler or the actual member, but member-initiated registrations will only be considered if the Trust flag is set while the state of the load balancer/scheduler is set 👑
7.1.1. Registration Request 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Req. Type(0x1010)| Size of Registration Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Group of Member Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group of Member Data Components as "Group of
Member Data Count" has specified.
Figure 12- Flag Field
- A. Load Balancer Flag
xxxx xxx1the entity sending this message is the load balancer 🎀xxxx xxx0the entity sending this message is an Application 💅
- B. Leftmost seven bits are reserved (
0000 000x - 1111 111x) 🙈
- A. Load Balancer Flag
- Group of Member Data Count: the number of "Group of Member Data" components immediately following the Registration Request component 🌸
- Array of Group of Member Data Components: each "Group of Member Data" component is immediately followed by Group Data Components and its Member Data components (as described in Section 6.1) 🫶 If several of these "Group of Member Data" components are present, the second one only shows up after all of the internal components referred to by the first "Group of Member Data" component are listed 😭 The format is the same for all subsequent "Group of Member Data" components in the message ✨
7.1.2. Registration Reply ✨
Okay bestie, this is the reply the GWM sends back after a registration attempt, and it's giving "did you get in or not?" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Registration Reply Type(0x1015)| Size of Registration Reply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+Figure 13 🎀
- General SASP return codes (
0x00 - 0x3F) 🌸0x00Successful0x10Message not understood0x11GWM will not accept this message from the sender. Reasons for this include the following:- a. The message was not sent by a LB and trust flag is off
- b. LB attempted to address members of a different LB in the message
- c. Vendor specific criteria for this message type were not met.
- Message-Specific return codes (
0x40 - 0xFF) 🦋0x40Member already registered0x44Duplicate Member in Request0x45Invalid Group (determined by the GWM)0x50Invalid Group Name Size (size == 0)0x51Invalid LB UID Size (size == 0 or > max)0x61Member is registering itself, but LB hasn't yet contacted the GWM. This registration will not be processed.
The Invalid Group error return code refers to the LB or member attempting to form a group that the GWM considers invalid. For example, some GWM vendors may not support the registration of both System and Application members in the same group. To determine what can cause a GWM to return this error code, the vendor's documentation must be consulted. 🙈 So if you're getting 0x45 and wondering why, go read the vendor docs, no shortcuts!
7.2. DeRegistration Request and Reply 🦋
Okay so this is the breakup exchange 💀 It happens between the load balancer/scheduler and the Group Workload Manager, and also between the Group Workload Manager and the Member, to deregister members from a group specified by Group Name with the Group Workload Manager. Deregistrations can come from either the load balancer/scheduler or the actual member, but member-initiated deregistrations will only be considered if the Trust flag is set with a Set LB State message. The main character here is the Trust flag, periodt ✨
7.2.1. DeRegistration Request 💌
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DeRegistration Req.Type(0x1020)|Size of DeRegistration Req. TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Reason | Group of Member Data Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Group of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+There will be as many Group of Member Data Components as "Group of Member Data Count" has specified.
Figure 14 🎀
- Flag Field 🌈
- A. Load Balancer Flag
xxxx xxx1The entity sending this message is the load balancer.xxxx xxx0The entity sending this message is an Application.
- B. Leftmost seven bits are reserved (
0000 000x - 1111 111x).
- A. Load Balancer Flag
- Reason: Byte describing the reason for deregistering the group or instance. 💅
- A. SASP-defined Reason Codes (
0x00-0x7F)0x00No reason given.0x01Learned and Purposeful, i.e., a human has deconfigured this member from the load balancer configuration.0x80-0xFFOpen for vendor specific deregistration reason codes.
- A. SASP-defined Reason Codes (
- Group of Member Data Count: The number of "Group of Member Data" components immediately following the DeRegistration Request component. 🍓
- Array of Group of Member Data Components: Each "Group of Member Data" component is immediately followed by Group Data Components and its Member Data components (as described in Section 6.1). In this case, where several of these "Group of Member Data" components may be present, the second "Group of Member Data" component only appears after all of the internal components that are referred to by the first "Group of Member Data" component are listed. The format is the same for all subsequent "Group of Member Data" components in the message. 🧚
If Member Count equals zero in the Group of Member Data component, the Group Workload Manager will deregister the entire group. 💀 Big yeet energy, so be careful!
Recall that the Group Data Component contains both a Unique LB Identifier field and a Group Name field. If the Group Data component has no Group Name (GroupData's Group Name Length==0), the Group Workload Manager will deregister all groups associated with this load balancer. 😭 That's the nuke option, iykyk.
7.2.2. DeRegistration Reply 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DeReg. Reply Type(0x1025) | Size of DeReg. Reply TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+Figure 15 🎀
- Return Code: A byte return code indicating the status of action taken. 🌸
- A. General SASP return codes (
0x00 - 0x3F)0x00Successful0x10Message not understood0x11GWM will not accept this message from the sender. Reasons for this include the following:- a. The message was not sent by a LB and trust flag is off
- b. LB attempted to address members of a different LB in the message
- c. Vendor specific criteria for this message type were not met.
- B. Message-Specific return codes (
0x40 - 0xFF)0x41Application or System not registered0x42Unknown Group Name0x43Unknown LB UID0x44Duplicate Member in Request0x46Duplicate Group in Request (for remove all members/groups requests)0x51Invalid LB UID Size (size == 0 or > max)0x61Member is deregistering itself, but LB hasn't yet contacted the GWM. This deregistration will not be processed.
- A. General SASP return codes (
7.3. Get Weights Request and Reply ⚖️
This is the weights check-in 🍭 It happens between the load balancer/scheduler and the Group Workload Manager, to get weights for the groups specified in the list of GroupData objects. For application load balancing (balancing workloads between applications with the same functionality), the load balancer would call the Group Workload Manager every Interval (parameter returned by the Group Workload Manager below) to get an array of weights and associated members (e.g., Application1 20, SecondCopyOfApplication 30, ThirdCopyOfApplication 5). The load balancer then uses these weights to determine the fashion in which work will be sent to each of the members.
For example, in the case of weighted round robin, the load balancer/scheduler would then send a request to Application1, the next to SecondCopyOfApplication, and the next to ThirdCopyOfApplication. After 15 requests, the load balancer/scheduler would only send work to Application1 and SecondCopyOfApplication. After an additional 30 requests, the load balancer/scheduler would only send requests to SecondCopyofApplication. After another 10 requests, the load balancer/scheduler product would start over using the weights of 20, 30, and 5 again; or if the Interval number of seconds have passed, the load balancer/scheduler would get a new set of weights. The rotation is so cute, I'm obsessed 🦋✨
7.3.1. Get Weights Request 🧁
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Get Weights Req. Type(0x1030) | Size of Get Weights Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+There will be as many Group Data Components as "Group Data Count" has specified.
Figure 16 🎀
- Group Data Count: The number of "Group Data" components immediately following the Get Weights Request TLV. 🍓
- Array of Group Data Components: This array of Group Data Components lists the groups for which the load balancer wants to get weights. 🌷
If there is no group name in the Group Data structure of the Get Weights Request, the load balancer is requesting weights for all groups registered for the load balancer. ✨ No name means "give me everything," bestie 👑
Onward we go, the next bit is coming in the next part! 🌈
7.3.2. Get Weights Reply ✨
Here's the reply to a Get Weights Request. 💌 Every packet opens with the SASP Header TLV, then the Get Weights Reply TLV, then the weight groups. 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Get Weights Reply Type(0x1035)| Size of Get Weights Reply TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Interval | Group of Weight
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Entry Data Count| |
+-+-+-+-+-+-+-+-+ +
. .
. *Group of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* There will be as many Group of Weight Entry Data Components as
"Group of Weight Entry Data Count" has specified.
Figure 17- Return Code: a byte return code that tells you how the action went. 💅
- A. General SASP return codes (0x00 - 0x3F)
0x00 Successful0x10 Message not understood0x11 GWM will not accept this message from the sender.Reasons for this include the following:- a. LB attempted to address members of a different LB in the message
- b. Vendor specific criteria for this message type were not met.
- B. Message-Specific return codes (0x40 - 0xFF)
0x42 Unknown Group Name0x43 Unknown LB UID0x46 Duplicate Group in Request0x51 Invalid LB uid Size (size == 0 or > max)
- A. General SASP return codes (0x00 - 0x3F)
- Interval: these two bytes hold a recommended polling interval for the load balancer to use. 🦋 The Group Workload Manager is basically saying that polling any faster than the suggested interval would probably grab values before they've had a chance to change. 🙈
- Group of Weight Entry Data Components: each "Group of Weight Data" component is immediately followed by Group Data Components and its Weight Entry Data components (as described in Section 6.2). 🧚 When several "Group of Weight Data" components are in one message, the second one only shows up after all of the internal components referred to by the first one are listed. Every later "Group of Weight Data" component follows the same format. 🌈
7.4. Send Weights 💜
Okay, this is the one exchange where the Group Workload Manager starts the conversation. 📣 It sends fresh weights for the group named in Group Name, and it's the only message with no reply. 🙃
Picture application load balancing (spreading work across apps that do the same job). The Group Workload Manager messages the load balancer at an interval that might be dynamic, and that interval is the Group Workload Manager's call. 🍓 The message carries an array of weights and their members, like Application1 20, SecondCopyOfApplication 30, ThirdCopyOfApplication 5. The load balancer then uses those weights to decide how work gets handed out. ✨
With weighted round robin, for example, the load balancer sends a request to Application1, the next one to SecondCopyOfApplication, and the next to ThirdCopyOfApplication. After 15 requests, it only sends work to Application1 and SecondCopyOfApplication. After another 30 requests, it only sends requests to SecondCopyofApplication. After an additional 10 requests, the load balancer/scheduler product starts over and uses the weights of 20, 30, and 5 again, as long as it hasn't received a new set of weights yet. 🔁
One more thing, bestie: the Group Workload Manager only sends this message if the Push flag has been enabled using a Set Load Balancer State 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send Weights Type(0x1040) | Size of Send Weights TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group of Weight Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Group of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* There will be as many Group of Weight Entry Data Components as
"Group of Weight Data Count" has specified.
Figure 18- Group of Weight Entry Data Components: each "Group of Weight Data" component is immediately followed by Group Data Components and its Weight Entry Data components (as described in Section 6.2). 🌸 When several "Group of Weight Data" components are in one message, the second one only shows up after all of the internal components referred to by the first one are listed. Every later "Group of Weight Data" component follows the same format. 💖
7.5. Set Member State Request and Reply 🎀
This is a special exchange that can happen between the load balancer and the Group Workload Manager, or between a Member and the Group Workload Manager. 🧁 Its job is passing along the state of a member, including putting that member into a quiesced or non-quiesced state. 🌙 The load balancer/scheduler can use it to quiesce a whole set of members. Members can also use it to quiesce themselves, and to pass along certain state information that is opaque to the Group Workload Manager. 🔒 That opaque state info then gets handed to the load balancer/scheduler along with the weights during get and send weight messages. 📦
7.5.1. Set Member State Request ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SetMemberState Req.Type(0x1060)|Size of SetMemberState Req. TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Group of MemberStateData Count| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group of Member State Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group of Member State Data Components as
"Group of Member State Data Count" has specified.
Figure 19- Flag Field 🚩
- A. Load Balancer Flag
xxxx xxx1The entity sending this message is the load balancer.xxxx xxx0The entity sending this message is an Application.
- B. Leftmost seven bits are reserved (
0000 000x - 1111 111x).
- A. Load Balancer Flag
- Group of Member State Data Count: the number of "Group of Member State Data" components immediately following the Set Member State Request TLV. 🔢
- Array of Group of Member Data Components: each "Group of Member State Data" component is immediately followed by Group Data Components and its Member State Instance components (as described in Section 6.3). 🌷 When several "Group of Member State Data" components are present, the second one only appears after all of the internal components referred to by the first one are listed. Every later "Group of Member State Data" component follows the same format. 💜
7.5.2. Set Member State Reply 💌
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set Member State Reply(0x1025)|Size of SetMemberStateReply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 20- Return Code: a byte return code that tells you how the action went. 🎯
- A. General SASP return codes (0x00 - 0x3F)
0x00 Successful0x10 Message not understood0x11 GWM will not accept this message from the sender.Reasons for this include the following:- a. The message was not sent by a LB and trust flag is off
- b. LB attempted to address members of a different LB in the message
- c. Vendor specific criteria for this message type were not met.
- B. Message-Specific return codes (0x40 - 0xFF)
0x41 Application or System not registered0x42 Unknown Group Name0x43 Unknown LB UID0x44 Duplicate Member in Request0x46 Duplicate Group in Request0x50 Invalid Group Name Size (size == 0)0x51 Invalid LB UID Size (size == 0 or > than max)0x61 Member is setting state for itself, but LB hasn't yet contacted the GWM. This request will not be processed.
- A. General SASP return codes (0x00 - 0x3F)
7.6. Set Load Balancer State Request and Reply 🌈
This is an exchange that can happen between the load balancer and the Group Workload Manager. 🍭 It's how the load balancer passes along its state, plus some of its partial configuration. 🧚♀️
7.6.1. Set LB State Request ✨
Okay bestie, this one is all about setting a load balancer's state 💅 Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Set LB State Req. Type (0x1050)| Size of Set LB State Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB UID Length | |
+-+-+-+-+-+-+-+-+ +
. .
. LB UID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Health | LB Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21- LB UID Length: a one-byte length field that tells you how big the LB UID after it is.
- LB UID: this should be the same unique identifier that was given when group members were registered for this particular load balancer.
- LB Health: this gives the load balancer a chance to send along a metric about its own health or state.
0x00 - 0x7F Least Healthy - Most Healthy
0x80 - 0xFF Reserved- LB Flags: a bit field with three flags, plus some reserved space. 🔥
- A. Push Flag
xxxx xxx1: the load balancer should receive weights through the Send Weights message, so the GWM pushes weights to the load balancer. Even when this flag is set, the GWM must still respond accordingly to any Get Weights messages from the load balancer.xxxx xxx0: the load balancer will send a Get Weights message to fetch the new weights. This is the default behavior (the load balancer pulls weights from the GWM).
- B. Trust Flag
xxxx xx1x: trust any member-initiated registration, deregistration, or set state message. Reflect the registration, deregistration, or new state right away in the weights that get sent.xxxx xx0x: do not trust any member-initiated registration, deregistration, or set state message. Registration, deregistration, and state setting of members can only happen from the load balancer. Discard any member-initiated registration, deregistration, or set state message. This is the default behavior.
- C. No Change / No Send Flag
xxxx x1xx: the GWM must not include members whose weights and state (that is, contact and quiesce flags) have not changed since they were last sent.xxxx x0xx: the GWM must include the weights of all group members when sending weights to this load balancer, including members whose weights and state have not changed. This is the default behavior.
- D. Leftmost five bits are reserved (
0000 0xxxthrough1111 1xxx).
- A. Push Flag
7.6.2. Set LB State Reply 🦋
Here's the reply, the response that comes back after a Set LB State Request:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set LB State Reply (0x1025) | Size of Set LB State Reply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 22- Return Code: a byte return code that tells you the status of the action taken.
- A. General SASP return codes (
0x00-0x3F)0x00Successful0x10Message not understood0x11GWM will not accept this message from the sender. Reasons for this include the following:- a. LB attempted to address the state of a different LB
- b. Vendor specific criteria for this message type were not met.
- B. Message-Specific return codes (
0x40-0xFF)0x51Invalid LB UID Size (size == 0 or > max)
- A. General SASP return codes (
8. Example of SASP Message Encoding 🧁
This section is the fun part, a real worked example of what a SASP message looks like on the wire. We're following a sample Get Weights Reply where two webservers are registered to a serverfarm called FARM1. The IP addresses are 10.10.10.1 and 10.10.10.2. Right now the GWM has a weight of 40 for 10.10.10.1 and 20 for 10.10.10.2. The load balancer's unique identifier is "LB1", and the GWM sent this message in response to a request (MessageID: 0x32000000) for FARM1's weights.
The TLVs needed for this message are below, in order.
- SASP Header TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x2010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x000D |
|-----------|---------|------------|
| | Version | 1 byte | 0x01 |
| |---------|---------|------------|
|V| Mesg Len| 4 bytes | 0x0000 006A|
| |---------|---------|------------|
| | Mesg ID | 4 bytes | 0x3200 0000|
------------------------------------
Figure 23- Get Weights Reply TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x1035 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0009 |
|-----------|---------|------------|
| | RetCode | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Interval| 2 bytes | 0x0040 |
| |---------|---------|------------|
| |GWD Count| 2 bytes | 0x0001 |
------------------------------------
*GWD Count = Group of Weight Data Count
Figure 24- Group of Weight Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x4011 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0006 |
|-----------|---------|------------|
|V| WE Count| 2 bytes | 0x0002 |
------------------------------------
*WE Count = Weight Entry Count
Figure 25- Group Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3011 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x000E |
|-----------|---------|------------|
| |LBUID len| 1 byte | 0x03 |
| |---------|---------|------------|
| | LBUID | 3 bytes | "LB1" or |
| | | | 0x4C 42 31 |
|V|---------|---------|------------|
| |GroupName| 1 byte | 0x05 |
| | Length | | |
| |---------|---------|------------|
| | Group | | "FARM1" or |
| | Name | 5 bytes | 0x46 41 52 |
| | | | 4D 31 |
------------------------------------
Figure 26- Member Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0018 |
|-----------|---------|------------|
| | Protocol| 1 byte | 0x06 |
| |---------|---------|------------|
| | Port | 2 bytes | 0x0050 |
| |---------|---------|------------|
|V| IP |16 bytes | 0x0000 0000|
| | Address | | 0000 0000|
| | | | 0000 0000|
| | | | 0A0A 0A01|
| |---------|---------|------------|
| |Label Len| 1 byte | 0x00 |
| |---------|---------|------------|
| | Label | 0 bytes | |
------------------------------------
Figure 27- Weight Entry Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3012 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0008 |
|-----------|---------|------------|
| | State | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Flags | 1 byte | 0x0D |
| |---------|---------|------------|
| | Weight | 2 bytes | 0x0028 |
------------------------------------
Figure 28- Member Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0018 |
|-----------|---------|------------|
| | Protocol| 1 byte | 0x06 |
| |---------|---------|------------|
| | Port | 2 bytes | 0x0050 |
| |---------|---------|------------|
|V| IP |16 bytes | 0x0000 0000|
| | Address | | 0000 0000|
| | | | 0000 0000|
| | | | 0A0A 0A02|
| |---------|---------|------------|
| |Label Len| 1 byte | 0x00 |
| |---------|---------|------------|
| | Label | 0 bytes | |
------------------------------------
Figure 29- Weight Entry Data TLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3012 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0008 |
|-----------|---------|------------|
| | State | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Flags | 1 byte | 0x0D |
| |---------|---------|------------|
| | Weight | 2 bytes | 0x0014 |
------------------------------------
Figure 30And here's the whole thing as a hex stream, so you can see the exact bytes. It's 106 bytes total 🤯
20 10 00 0D 01 00 00 00 6A 32 00 00 00 10 35 00 09 00 00 40
00 01 40 11 00 06 00 02 30 11 00 0E 03 4C 42 31 05 46 41 52
4D 31 30 10 00 18 06 00 50 00 00 00 00 00 00 00 00 00 00 00
00 0A 0A 0A 01 00 30 12 00 08 00 0D 00 28 30 10 00 18 06 00
50 00 00 00 00 00 00 00 00 00 00 00 00 0A 0A 0A 02 00 30 12
00 08 00 0D 00 14
(106 bytes)9. Protocol Flow 🌈
This section is where we zoom out and talk about how SASP messages expect to flow in general 🦋
9.1. Normal Protocol Flow ✨
okay so SASP starts with a connection from an LB to the GWM 🫶 this is meant to be a long-running connection that carries lots of messages. once the connection is up, the LB either registers a group of members or flips the Trust flag on so the members can register themselves. the Trust flag gets set with a Set LB State Request (both flows are shown below) 💖
Registration from load balancer
------------ Registration Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Registration Reply | Manager |
| |<-----------------------| |
------------ ------------------
Set LB State from load balancer
------------ Set LB State Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Set LB State Reply | Manager |
| |<-----------------------| |
------------ ------------------
Figure 31the connection can open with other requests too, but any other request would likely get an error 🙈 (unless this connection is a reconnection that happens a short time after the original one). for example, if the LB sends a deregistration request as its very first message, it gets an error because it hasn't registered any groups yet 💀
the LB always drops all of its state after a connection is lost, and it can get that state back using a GetWeights message 🔄 setting up a new connection makes the GWM assume the old one is broken. in that case the GWM keeps the LB's state for a limited time after the break was detected. once that limited time is up, the GWM throws away all the state for the broken connection 🗑️
registering group members can happen at any time ⭐ an LB can register anywhere from one group with one member all the way up to many groups with many members each. a member can also register itself, but only if the Trust flag is set and it knows the right load balancer info 🎀 registrations get added to groups that already exist, but if any of the members being registered already exist, you get an error back 🚫
for system load balancing, a member is only represented by its IP address, with a 0 used as the value for both the port and the protocol 🧚 for application load balancing, a member is represented by its IP address plus the Application's port and protocol 🌸
deregistering group members can also happen at any time 🦋 an LB can deregister anywhere from one group with one member to many groups with many members. the LB can also deregister an entire group, or deregister all of its groups at once 👑 a member can deregister itself too, as long as the Trust flag is set and it knows the right load balancer info ✨
once members are registered, the GWM starts the monitoring and weight computation processes so it can work out the weights it sends back to the LB 💅 the LB can issue a GetWeights message at any time to ask for the weights of the members in a particular group. the LB can also set a flag telling the GWM to send weights without waiting to be asked. when that flag is set, the GWM sends the weights at an interval it thinks is appropriate (that interval could change depending on the algorithm being used and how much the generated weights vary) 🍓
at any time, the LB or a particular member can quiesce that member using a SetMemberState message 😭 when that happens, the member's weight is always zero, and the quiesce flag gets turned on when its weight is sent. members can also use this message to send an opaque state value, which also gets presented when weights are sent 🔥
at any time, the LB can send the GWM a SetLBState request to configure how they interact 🫧 this message lets the LB set the Push, Trust, and NoChange_NoSend flags. it also lets the LB pass a health value to the GWM so it can be displayed 💜
9.2. Behavior in Error Cases 🚨
so behaviours in lots of error conditions are going to be product specific, but the following error cases should have the following expected behaviour 💖
- Case: The protocol is violated in an unrecoverable manner by either end of the connection.
- Behavior: Either end of the connection may choose to disconnect to avoid future message synchronization problems. The state kept when disconnected is vendor specific. 🔌
- Case: LB or application attempts to connect to the GWM before the GWM is fully up and running.
- Behavior: The LB or application should wait at least 20 seconds to retry the connection. ⏳
- Case: Members attempt to register or deregister themselves before the LB develops the connection with the GWM.
- Behavior: In this case, the members would receive a reply with an error code signifying that there is no LB registered with that LB UID. 🙅♀️
- Case: Member registers or deregisters for an LB who has not set the Trust flag.
- Behavior: GWM will send Member a reply containing an error code. 🚫
- Case: LB asks for weights for a group that doesn't exist.
- Behavior: GWM will send LB a reply containing an error code. 🥲
- Case: LB or Member attempts to register a member that is already registered in that group.
- Behavior: GWM will send sender a reply containing an error code. 💀
- Case: LB or Member attempts to deregister a member or group that doesn't exist.
- Behavior: GWM will send sender a reply containing an error code. 🙈
- Case: LB or Member tries to set state for a non-registered server.
- Behavior: GWM will send sender a reply containing an error code. 🫠
- Case: LB tries to Get Weights for an unregistered group.
- Behavior: GWM will send LB a reply containing an error code. 🌈
9.3. Example Flow 1: Load Balancer Registration, Getting Weights, and Application-Side Quiescing 🎬
this example walks through a whole session from start to finish, so you can see the messages in order 🦋
Load Group Workload
Balancer Manager
| |
| 1) Registration Request |
|------------------------>|
|<------------------------|
| Registration Reply |
| |
| 2) Set LB State Request |
|------------------------>|
|<------------------------|
| Set LB State Reply |
| |
| 3) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| | 4) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| A |
| | Set Member State Reply --------
| |
| | 5) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Set Member State Reply --------
| |
| 6) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| |
| | 7) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Set Member State Reply --------
| |
| 8) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| |
Figure 32- the LB registers Members A, B, and C in a group named GRP1. the GWM replies with no error 🎀
- the LB turns its trust flag on by sending a Set LB State message:
LB Health: 0x00 Flags: 0000 0010- the LB sends a Get Weights message for GRP1 and gets this reply 👀
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x00 0000 1101 5- Member A sends a Set Member State message with these flags 💅
Members Opaque State Flags
-------- ------------ ---------
Member A 0x32 0000 0000- Member C sends a Set Member State message to quiesce itself, with these flags 🫠
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0001- the LB sends the Get Weights message for GRP1 and gets back the following 📊
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x32 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x0A 0000 1111 5- Member C sends a Set Member State message to resume (un-quiesce itself), with these flags ✨
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0000- the LB sends a Get Weights message for GRP1 and gets this reply 🌸
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x32 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x0A 0000 1101 59.4. Example Flow 2: Set Load Balancer State, Application Registration, and Load Balancer Group DeRegistration ✨
okay bestie, this one is a whole story 🎀 the LB sets its state first, then members show up to work, then weights get sent, then the LB bails on the group 😭
Load Group Workload
Balancer Manager
| |
| 1) Set LB State Request |
|------------------------>|
|<------------------------|
| Set LB State Reply |
| |
| | 2) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| A |
| | Registration Reply --------
| |
| | 3) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| B |
| | Registration Reply --------
| |
| 4) Send Weights Mesg |
|<------------------------|
| |
| | 5) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Registration Reply --------
| |
| 6) Send Weights Mesg |
|<------------------------|
| |
|7) Deregistration Request|
|------------------------>|
|<------------------------|
| Deregistration Reply |
| |
Figure 39- The LB sets its state with the Set LB State message and these params:
Health: 0x7F Flags: 0000 0011✨ the LB is basically introducing itself, no cap 💅 - Member A registers itself for work in GRP1 using the Register message. 🦋
- Member B registers itself for work in GRP1 using the Register message. 🌸
- The GWM issues a Send Weights message to the LB. the table below is the vibe check 💜
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40- Member C registers itself for work in GRP1 using the Register message. new girl just arrived 🧚
- The GWM issues a Send Weights message to the LB again, and now the table has Member C in it too 🔥
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40
Member C 0x00 0000 1001 5- LB deregisters GRP1 by using the DeRegister message with the Member Data Count = 0 💀 bye bye group, it's not you it's me 🫶
9.5. Avoiding Single Points of Failure 🛡️
okay so nobody wants a single point of failure, that's giving chaos energy 😭 SASP has a couple of ways to dodge it:
- To avoid having a single point of failure at the load balancer, an administrator may choose to have multiple load balancers in his or her environment. SASP lets the GWM keep track of multiple load balancers through load balancer unique identifiers (LB UIDs) 👑
- To avoid having a single point of failure at the GWM, or to level up the load balancing strategy by using the strengths of several different GWMs, an administrator may choose to have multiple GWMs in his or her environment. In this case, the load balancer would connect to multiple GWMs and register the same groups with corresponding members. The load balancer may choose to coordinate the recommendations of each GWM by any method it chooses (e.g., statistical combination such as averaging). The coordination of weights from multiple GWMs is product specific and not addressed in this protocol. 🌈 that part is up to the product, not the protocol, so don't ask me 🙈
10. Security Considerations 🔐
okay the security section is where we get real, bestie 😭 SASP is a binary stream that's expected to ride over a TCP connection. so to lock it down, implementers are expected to use a secure transport such as SSL/TLS. here are the drama points 🎭
Security Issue: In insecure environments, if the LB UID becomes known by another system, the other system could open a connection and send messages to the GWM. that would make the GWM swap out the previous (possibly valid) connection for the new (potentially bad) one. ⚠️
Solution: this might not be a concern if the load balancer and GWM live in protected parts of the network 🏰 but if the administrator is worried about it, she should use SSL or TLS to authenticate the connection. when SSL or TLS is securing the connection, the administrator SHOULD use both server and client authentication through client and server certificates. the GWM will trust any certificate that's signed by an authority it's been configured to trust. 💖
the point is: trust only the certs you actually configured, bestie. 🔒
Security Issue: In insecure environments, if the load balancer turns the Trust Flag on, any member or other system can send a Registration Message and get included in the serverfarm to receive work. a person with bad intentions and the right info could exploit this and register their own application to receive work. that counterfeit app could capture valuable data from unsuspecting clients as their transactions get sent to it. 😱
Solution: this might not be a concern if the GWM and its members are in protected parts of the network 🛡️ but if the administrator is concerned, she should use SSL or TLS to authenticate the member connections. with SSL or TLS, the administrator would need to explicitly install valid certificates on each component, while also establishing the trusted certificates of each component. that makes sure only those trusted components are allowed to connect to the GWM. 🫶
11. Normative References 📚
- [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. 🎀
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🦋
Appendix A. Acknowledgements 💜
The author gratefully acknowledges contributions by Mark Albert, David McCowan, John Fenton, Derek Huckaby, Dyan Collins, and Stefano Testa. Mark Albert, David McCowan, John Fenton, Derek Huckaby, Dyan Collins, and Stefano Testa were supported for this work by Cisco Systems Inc. 🙌
The author would also like to thank John Arwe, Dave Bostjancic, Brian Carpenter, Donna Dillenberger, Gus Kassimis, and Thomas Narten for their efforts in the creation and refining of this work. 🌟
Author's Address 📮
Alan Bivens
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
US
EMail: jbivens@us.ibm.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 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.
Acknowledgement 🌈
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💖
📦 where this page comes from
- ietf: rfc4678 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms