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
o LB UID Length: Length of the LB UID to follow (in bytes).
o LB UID: A UTF8 string used as a unique identifier and a context
for the Group Name (e.g., a UTF8 representation of the MAC address
of the load balancer or some type of Universally Unique Identifier
(UUID)). This string is used by the Group Workload Manager to
associate application registration and deregistration, and to set
state messages with the correct load balancer. This unique
identifier should not be any longer than 64 bytes.
o Group Name Len: Length of the Group Name field to follow (in
bytes).
o Group Name: A UTF8 string the load balancer has chosen to tell the
Group Workload Manager that members being registered with this
Group Name are equivalent in function. In Get Weight and
DeRegistration messages, the Group Name may be omitted (Group Name
Length = 0) to indicate all groups from the associated load
balancer.
5.3. Weight Entry Data Component
The Weight Entry Component is used by the get and send weight
messages to associate a weight with a particular member (or Member
Data). It also uses an opaque member state field and a general
member flags field to denote extra information about a member
(described below). When the Weight Entry component is used, the
Member Data TLV it refers to is listed first, immediately followed by
the Weight Entry TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
o State Field: This field is used by the member to communicate state
information to the scheduler. The information placed in this
field is opaque to the GWM and will simply be forwarded to the
scheduler with the member weights. There are no defined values
for this field.
o Flags Field: This field has several flag values that describe
several attributes of the member.
A. Contact Success Flag (set by the GWM): describes whether the
member is currently running. If the contact success flag is
off, this member should be avoided by the load balancer.
+ xxxx xxx1 The GWM has located this running system or
application.
+ xxxx xxx0 The GWM has not located this running system or
application.
B. Quiesce Flag (set by the load balancer or Member): used when
an administrator would like to temporarily remove a member
from the weight calculation, but not deregister it from the
group. When quiesced, the member will still show up in the
weights, but the quiesce flag will be set, and its weight will
be zero. When the administrator returns this member to
active, the quiesce flag will be 0, and a weight will be
provided. If the quiesce flag is on, this member should be
avoided by the load balancer.
+ xxxx xx1x The member is quiesced.
+ xxxx xx0x The member is active (not quiesced).
C. Registration Flag (set by the GWM): stores how the member was
registered.
+ xxxx x1xx This member has been registered by the load
balancer/scheduler.
+ xxxx x0xx This member has registered itself.
D. Confident Flag (set by the GWM): describes whether the GWM has
knowledge of this member’s state. If this flag is off for
only some of the members in the group while the remaining
members have valid weights, the load balancer should avoid
sending work to those members with the confident flag off. If
the confident flag is off for all valid group members, the
load balancer should disregard any recommendation from the GWM
until the confident flag comes back on for at least one
member. In this case where all confident flags are off, the
load balancer should determine the correct distribution of
work by other means (perhaps a different advisor, previously
configured static weights, etc.).
The goal of the confident flag is to convey to the load
balancer that it should look to other methods of distribution
recommendations if the GWM cannot give recommendations for any
of the valid group members. If some members of the group have
the confident flag on but the contact flag off or the quiesced
flag on (meaning these members should always be avoided) while
the remaining members of the group have their confident flag
off, the load balancer should determine the appropriate
distribution of work for those members with the confident flag
off by other means.
+ xxxx 1xxx GWM has determined it has knowledge of the state
of this member.
+ xxxx 0xxx GWM has no knowledge of the state of this member.
E. Leftmost four bits are reserved (0000 xxxx - 1111 xxxx).
o Weight: This field represents the GWM’s recommendation for the
relative amount of work that should be sent to this member. This
is a 16-bit field with a possible range of 0 to 65536. Load
balancers should be prepared to receive a wide range of weight
values. Load balancers with limited maximum weight values may
restrict the granularity of management by the GWM and in turn
cause less than optimal performance. Many 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 used by the set member state
message to indicate the sender’s perceived state of the member
mentioned. This component is used to set values that will ultimately
end up in the WeightEntry component. When the Member State Instance
component is used, the Member Data TLV it refers to is listed first,
immediately followed by the Member State Instance TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
o State Field: This field is used by the member to communicate state
information to the load balancer or scheduler. There are no
defined values for this field.
o Flags Field: This field describes attributes of the member.
Currently the only flag value defined is that of the quiesce flag.
The quiesce flag is used when an administrator would like to
temporarily remove a member from the weight calculation, but not
deregister it from the group. When quiesced, the member will
still show up in the weights, but the quiesce flag will be set,
and its weight will be zero. When the administrator returns this
member to active, the quiesce flag will be 0, and a weight will be
provided.
A. Quiesce Flag
+ xxxx xxx1 The member or load balancer setting this state is
quiescing this member.
+ xxxx xxx0 The 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).
6. Group Protocol Components
Group protocol components each contain a collection of related
singular components. In particular, they associate Member Data,
Weight Entry, or Member State Instance components to a particular
Group Data component. In these cases, the particular "Group of x"
component will be immediately followed by the Group Data component.
The Group Data component will be immediately followed by any number
of singular components the group contains. In figures listed in this
document, a component type with an asterisk denotes a component that
is repeated a number of times.
6.1. Group of Member Data Component
The "group of member data" component describes a particular group of
members and is used 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
o Member Count: The number of Member Data Components immediately
following the Group Data structure.
o Array of Member Data Components: There will be as many Member Data
TLVs as Member Count has specified. A load balancer/scheduler
would use these components to pass information that would enable
the Group Workload Manager to identify the 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 create a list of Weight Entry Components for a
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
o Weight Entry Count: The number of Member Data / Weight Entry
combinations to follow the Group Data TLV.
o 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 corresponding
Member Data component as explained in Section 5.3. This Member
Data / Weight Entry data combination will repeat to form as many
Weight Entry items as the Weight Entry Count specifies.
6.3. Group of Member State Data Components
The "group of member state data" component describes a particular set
of members and their corresponding state fields 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
o Member State Instance Count: The number of Member Data / Member
State Instance combinations following the Group Data component.
o Array of Member State Data Components: Each Member State Instance
component is immediately preceded by its corresponding Member Data
component as explained in Section 5.4. This Member Data / Member
State Instance combination will repeat 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). The header has no information as to what type of
message it is part of; the purpose-specific information is in the
message component. This format could facilitate placing more than
one message component in a single message; however, this use of
multiple message components is not supported in every GWM and could
produce indeterminate behavior. Similar to 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 will be acknowledged with a reply.
The reply contains information requested as well as a single-byte
response code describing the success of the request. SASP defines
some general response codes in the range of 0x00 - 0x3F that may be
used regardless of the response message type. However, some request
types may cause specific error conditions not covered by the general
response codes. The response code range of 0x40 - 0xFF is used for
these message-specific response codes. Any given SASP response will
only contain 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 as well as between the Group Workload Manager
and the member 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. Even though
registrations can come from either the load balancer/scheduler or the
actual member, member-initiated registrations will only be considered
if the Trust flag is set while the state of the load