Request for Comments: 4678 IBM Research
Category: Informational September 2006
Server/Application State Protocol v1
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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.
Abstract
Entities responsible for distributing work across a group of systems
traditionally do not know a great deal about the ability of the
applications on those systems to complete the work in a satisfactory
fashion. Workload management systems traditionally know a great deal
about the health of applications, but have little control over the
rate in which these applications receive work. The
Server/Application State Protocol (SASP) provides a mechanism for
load balancers and workload management systems to communicate better
ways of distributing the existing workload to the group members.
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 ......................................47
1. Introduction
1.1. Overview
The Server/Application State Protocol is designed to enable load
balancers or schedulers (1) to receive traffic weight recommendations
from Workload Managers, (2) to register with Workload Managers
members of load balancing/scheduling groups, and (3) to enable
Workload Managers to suggest new load balancing group members to load
balancers and schedulers
The figure below shows where the SASP entities are in typical load
balancing topology.
----------
| Group |
-------->|Member 1|<--|
| ---------- |
| |
--------- ---------- | ---------- |
|Request|<------>| Load |---| | Group | |
|Origins|<------>|Balancer|----------->|Member 2|<--|
--------- | |---| ---------- |
---------- | |
^ | ---------- |
| -------->| Group | |
SASP | |Member 3|<--|
------- ---------- |
| |
| -------------------- |
| | Group | SASP |
------>| Workload Manager |<----------
--------------------
Figure 1
SASP is a binary protocol that facilitates 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 to receive connections from the
other SASP components. Server port 3860 has been registered with the
IANA for SASP communications. It is expected that all SASP
components are configured with the DNS name of the GWM to develop
this connection. Security in SASP is handled by transporting 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. Connection and security
aspects including SSL’s authentication and encryption will be
implementation specific.
1.2. Identities
SASP identifies a load balancer by a UTF-8 string called a "LB UID".
A group of "equivalent" servers providing a service is identified by
a UTF-8 string called a "Group Name", which is interpreted in the
context of the LB UID. A server is identified by its IP address and
(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;
there are no globally unique identifiers. The LB UID and GroupName
fields are unstructured so that components could assign values to
these fields that are meaningful to an administrator. For example,
in many cases, a load balancer would use the name an administrator
provided for the serverfarm group as the groupname in a SASP-
specified group. Since the naming options in industry load balancers
do not carry explicit naming restrictions, SASP naming options also
carry no naming restrictions.
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
o Load Balancer - Entity responsible for distributing requests
amongst the available members.
o Member - Machine, process, or application used to service
requests.
o Group Workload Manager (GWM) - Entity responsible for reporting or
managing a group of members on multiple machines.
4. General Message Structure
Any string interpreted by the group workload manager is assumed to
use UTF8. Components implementing SASP MUST support the printable
ASCII subrepertoire of UTF8 (0x20-0x7E). Components MAY also choose
to provide support for additional UTF8 character encodings. It is
recommended that customers using SASP-enabled products configure the
string-generating components (load balancers and group members) to
use the same character repertoire.
Many of the SASP structures involve the transfer of multi-byte
integer values. In all cases where multi-byte integer values are
used, they are considered to be in network-byte order (big-endian).
SASP is organized into several message components. For extendibility
and ease of processing, each message component is described in a TLV
(Type, Length, Value) format. An illustration of the SASP structure
can be found in the example below. The first section is the header
followed by the message component type. As mentioned, the header,
message component, and all other components have a TLV format. Each
component value contains a variable number of fields, some of which
refer to upcoming components (explained component descriptions are in
upcoming sections). After the first message component, any number of
additional components may be included (as stipulated in the fields of
the message type).
-------------------------------------------------
| |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
An illustration of the TLV format is shown below. The Type is a
two-byte field containing a binary value for the component type. The
Length is a two-byte field containing the size of the TLV in bytes
(including the Type and Length fields). The Value field is a
variable-length field that actually contains the 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
The TLV structure requires a type value for each protocol component.
All SASP types are listed in this section.
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-0xFFFF
4.3. SASP Protocol Header
An illustration of the SASP Header is found in the table below. It
is expected that every message will start with the SASP Protocol
Header component.
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
o Version: The version of the protocol used in this message.
o Message Length: A 4-byte signed integer value representing the
total length of the SASP message. It is said to be a signed
4-byte value to make any Java implementations easier (or any other
implementations without unsigned values); however, no negative
lengths are valid.
o Message ID: Each request message is given a 4-byte Message ID by
the message originator, which is simply returned in the Message ID
field of the reply. This field is meant to assist the requester
in correlating replies to the appropriate request when many
requests have been sent. In the Send Weights message (the only
message transaction that has no reply), this field serves no
purpose.
4.4. Version Negotiation
To negotiate the version of the protocol used by the entities
involved in the connection, the GWM views the version included in the
load balancer request as the load balancer’s proposed version.
If the GWM supports the version proposed by the load balancer, it
will respond to the connection with the appropriate response code and
the load balancer’s proposed version in the response header. This
proposed version should be the version used for all messages in this
connection.
If the GWM does not support the version proposed by the load
balancer, the GWM will respond with a "message not understood"
response code and the GWM’s highest supported SASP version in the
version field of the response header. This is an indication for the
load balancer to come down to GWM’s SASP version level.
5. Singular Protocol Components
The most basic of SASP components are singular components because
they describe a single instance of a member, member resource, member
weight, or group. Some of the SASP components reuse other SASP
components. When this is the case, any component being reused by a
base component will simply be given immediately following the base
component. Some examples of this technique are seen and explained in
the Weight Entry and Member State Instance components.
5.1. Member Data Component
The member data component describes a particular member and is
referred to by other 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ IP Address of Member +
| |
+ +-+-+-+-+-+-+-+-+
| | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Label .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
o Protocol: The assigned number of the IP transport layer used in
the Protocol Field of the IP header. These are defined in
[RFC1700]; however, a current list is maintained at
http://www.iana.org.
for example: TCP = 0x06, UDP = 0x11, etc.
o Port: The port number used for communication to the member.
*** A value of 0 can be given for the Protocol and Port to signify
a system level member. However, 0 shouldn’t be perceived as a
wildcard for either Port or Protocol fields (i.e., a
deregistration request that includes a MemberData component with a
0 for the port doesn’t mean deregister all applications listening
on any port of that IP and protocol).
o IP Address: The current format is described by the following 16
bytes, where IPv4 addresses are represented as "IPv4-compatible
IPv6 addresses" [RFC4291]. In the following example, the x’s and
zeros represent 4-bit hex values. The x’s describe arbitrary hex
values.
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
o Label length: The length, in bytes, of the label string to follow.
o Label: A UTF8 string that may be set while registering a member.
This string is opaque to the GWM and is simply included with any
correspondence containing the member data component. Note that
the size of this label is <= 255 bytes. Because UTF8 character
encodings may be up to 6 bytes, care must be exercised by the load
balancer or member to make sure the UTF8 string it sends the GWM
is in fact <= 255 bytes.
5.2. Group Data Component
The group data component simply describes a group with which to
associate other singular components.
0 1 2 3