expected to be a long-running connection and will be used for many
messages. After establishing the connection, the LB either registers
a group of members or sets a Trust flag to allow the members to
register themselves. The Trust flag is set using a Set LB State
Request (both message 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 31
The connection can start with other requests, but any other request
would likely result in an error (unless this connection is a
reconnection that has happened a short period of time after the
original connection). For example, if the load balancer issues a
deregistration request as its first message, it will receive an error
because it has not registered any groups.
The load balancer always drops all state information after a loss of
connection and can recover it using a GetWeights message. The
establishment of a new connection causes the GWM to assume that the
old one is broken. In this case, the GWM will keep all state for the
load balancer for a limited time after a detected break. After the
limited time has expired, all state for the broken connection will be
discarded by the GWM.
Registration of group members may be done at any time. A load
balancer can register anywhere from one group with one member to many
groups of many members. The member may also register itself if the
Trust flag has been set and it knows the appropriate load balancer
information. Registrations will add to groups that already exist,
but return errors if any of the registered members already exist.
In the case of system load balancing, the representation of a member
is only the member’s IP address with a 0 used as the value for the
port and protocol. In the case of application load balancing, the
representation of a member is the member’s IP address and the
Application’s port and protocol.
Deregistration of group members may be done at any time. A load
balancer can deregister anywhere from one group with one member to
many groups of many members. The LB may also deregister entire
groups or deregister all of its groups at once. The member may also
deregister itself if the Trust flag has been set and it knows the
appropriate load balancer information.
Once members are registered, the GWM will start the monitoring and
weight computation processes to determine weights to be sent back to
the load balancer. At any time the load balancer may issue a
GetWeights message and ask for the weights for members in a
particular group. The LB may also set a flag telling the GWM to send
the weights without waiting for the GetWeights message. If this flag
is set, the GWM will send the weights at an interval it feels is
appropriate (the interval could change depending on the algorithm
used and variance of the weights generated).
At any time the LB or a particular member may quiesce the member
through the use of a SetMemberState message. In this case, the
member’s weight will always be zero, and the quiesce flag will be
turned on when sending its weight. Members may also use this message
to send an opaque state value that will also be presented when
sending weights.
At any time, the load balancer may choose to send the GWM a
SetLBState request to configure its interaction. The message allows
the load balancer to set the Push, Trust, and NoChange_NoSend flags.
It also allows the load balancer to pass a health value to the GWM to
be displayed.
9.2. Behavior in Error Cases
While behaviors in many error conditions will be product specific,
the following error cases should have the following expected
behavior.
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
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
1. The LB registers Members A, B, and C in a group named GRP1. The
GWM replies with no error.
2. The LB turns its trust flag on by issuing a Set LB State message:
LB Health: 0x00 Flags: 0000 0010
3. The LB sends a Get Weights message for GRP1 and gets the reply:
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x00 0000 1101 5
4. Member A sends a Set Member State message with flags:
Members Opaque State Flags
-------- ------------ ---------
Member A 0x32 0000 0000
5. Member C sends a Set Member State message to quiesce itself with
the following flags:
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0001
6. The LB sends the Get Weights message for GRP1 and receives 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
7. Member C sends a Set Member State message to resume (un-quiesce
itself) with the following flags:
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0000
8. The LB sends a Get Weights message for GRP1 and gets the reply:
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x32 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x0A 0000 1101 5
9.4. Example Flow 2: Set Load Balancer State, Application
Registration, and Load Balancer Group DeRegistration
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
1. The LB sets its state with the Set LB State message and the
following parameters.
Health: 0x7F Flags: 0000 0011
2. Member A registers itself for work in GRP1 using the Register
message.
3. Member B registers itself for work in GRP1 using the Register
message.
4. The GWM issues a Send Weights message to the LB.
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40
5. Member C registers itself for work in GRP1 using the Register
message.
6. The GWM issues a Send Weights message to the LB.
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40
Member C 0x00 0000 1001 5
7. LB deregisters GRP1 by using the DeRegister message with the
Member Data Count = 0
9.5. Avoiding Single Points of Failure
o 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 provides for the GWM to keep track of
multiple load balancers through the use of load balancer unique
identifiers (LB UIDs).
o To avoid having a single point of failure at the GWM or enhance
the load balancing strategy by utilizing 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.
10. Security Considerations
SASP is a binary stream expected to be transported over a TCP
connection. To secure this protocol, it is expected that
implementers of the protocol use a secure mode of transport such as
SSL/TLS. Discussions around security concerns have been listed
below:
Security Issue: In insecure environments, if the LB UID becomes
known by another system, the other system could initiate a
connection and send messages to the GWM causing the GWM to replace
the previous (possibly valid) connection for the new (potentially
bad) connection.
Solution: This may not be a concern if the load balancer and GWM are
in protected parts of the network. If the administrator is
concerned about this vulnerability, she should use SSL or TLS to
provide authentication for the connection. When using SSL or TLS
to secure the connection, the administrator SHOULD use both server
and client authentication through client and server certificates.
The GWM will trust any certificate that is signed by an authority
it’s been configured to trust.
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 be included in the serverfarm to receive
work. A person with bad intentions and the correct information
could exploit this feature and register his own application to
receive work. His counterfeit application could capture valuable
data from unsuspecting clients as their transactions are sent to
his system.
Solution: This may not be a concern if the GWM and its members are
in protected parts of the network. If the administrator is
concerned about this vulnerability, she should use SSL or TLS to
provide authentication for the member connections. When using SSL
or TLS to authenticate the connection, the administrator would
need to explicitly install valid certificates on each component
while at the same time establishing the trusted certificates of
each component. This would make certain that only those trusted
components would be permitted 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.com
Full 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