Network Working Group A. Bivens
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).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
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.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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.
システムのグループ全体に作業を配布する責任を負うエンティティは、伝統的に満足のいく方法で作業を完了するためにそれらのシステム上のアプリケーションの能力について多くを知りません。ワークロード管理システムは、伝統的なアプリケーションの健康について多くのことを知っているが、これらのアプリケーションは、仕事を受けている割合をほとんど制御を持っています。サーバ/アプリケーション状態プロトコル（SASP）はグループメンバーに既存のワークロードを分散するより良い方法を通信するロードバランサとワークロード管理システムのためのメカニズムを提供します。
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
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
サーバー/アプリケーション状態プロトコルは、ワークロードマネージャからのトラフィック量の推薦を受けるために（1）ロードバランサやスケジューラを有効にするために設計された（2）ロードバランシング/スケジューリンググループのワークロード・マネージャーのメンバーに登録すること、及び（3）ワークロードマネージャを有効にしますバランサやスケジューラをロードするための新しいロードバランシンググループメンバーを提案します
The figure below shows where the SASP entities are in typical load balancing topology.
SASPエンティティは、典型的な負荷分散トポロジのどこにいるか下の図を示します。
----------
| Group |
-------->|Member 1|<--|
| ---------- |
| |
--------- ---------- | ---------- |
|Request|<------>| Load |---| | Group | |
|Origins|<------>|Balancer|----------->|Member 2|<--|
--------- | |---| ---------- |
---------- | |
^ | ---------- |
| -------->| Group | |
SASP | |Member 3|<--|
------- ---------- |
| |
| -------------------- |
| | Group | SASP |
------>| Workload Manager |<----------
--------------------
Figure 1
図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.
SASPは、ワークロード・マネージャにロードバランサ/スケジューラからの通信を容易にするバイナリプロトコルです。グループワークロードマネージャ（GWM）とロードバランサ/スケジューラとの間の接続は、長時間実行されるTCPコネクションであることが予想されます。 SASP相互作用において、GWMは、他のSASPコンポーネントからの接続を受信するために待機しているSASPサーバとして機能します。サーバーのポート3860は、SASP通信のためにIANAに登録されています。すべてのSASPコンポーネントがこの接続を開発するGWMのDNS名で構成されていることを期待されています。 SASPのセキュリティは、セキュアソケットレイヤ/トランスポート層セキュリティ（SSL / TLS）の上にバイナリメッセージを輸送することによって処理されます。この文書は、接続とセキュリティ層以上のメッセージ形式とプロトコルの動作を説明しています。 SSLの認証と暗号化などの接続とセキュリティの側面は、実装固有のものになります。
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.
SASPは、「LB UID」と呼ばれるUTF-8文字列でロードバランサを識別します。サービスを提供する「同等」のサーバーのグループはLB UIDの文脈で解釈され、「グループ名」と呼ばれるUTF-8文字列によって識別されます。サーバは、そのIPアドレスおよび（オプション）ポート、およびプロトコル番号によって識別されます。 GWMは、ロード・バランサまたはグループメンバーからのTCP接続のもう一方の端のエンティティとして暗黙的に識別されます。これらの識別子はすべてローカルです。グローバル一意識別子が全くありません。コンポーネントは、管理者にとって意味のあるこれらのフィールドに値を割り当てることができるようにLB UIDとグループ名フィールドは、非構造化されています。例えば、多くの場合、ロードバランサは、管理者がSASP-指定したグループでグループ名としてサーバファームグループのために提供された名前を使用します。業界のロードバランサで命名オプションは、明示的な名前付けの制限を運ばないので、SASP命名オプションも一切の命名制限を運びません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
o Load Balancer - Entity responsible for distributing requests amongst the available members.
Oロードバランサ - 使用可能なメンバーの中でリクエストを配布するエンティティが担当しています。
o Member - Machine, process, or application used to service requests.
Oメンバー - サービス・リクエストの処理に使用される機械、プロセス、またはアプリケーション。
o Group Workload Manager (GWM) - Entity responsible for reporting or managing a group of members on multiple machines.
Oグループワークロードマネージャ（GWM） - 複数のマシン上でメンバーのグループを報告したり、管理するエンティティ責任を負います。
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.
グループワークロード・マネージャによって解釈任意の文字列は、UTF8を使用することが想定されます。 SASPを実装するコンポーネントは、UTF8（0x20-0x7E）の印刷可能なASCII subrepertoireをサポートしなければなりません。コンポーネントはまた、追加UTF8の文字エンコーディングのサポートを提供することを選択するかもしれません。 SASP対応製品をご利用のお客様は、同じ文字レパートリを使用する文字列を生成コンポーネント（ロードバランサとグループメンバー）を設定することをお勧めします。
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構造の多くは、マルチバイトの整数値の移転を伴います。マルチバイトの整数値が使用されているすべての場合において、それらはネットワークバイトオーダー（ビッグエンディアン）であると考えられています。
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).
SASPは、いくつかのメッセージコンポーネントで構成されています。拡張性と処理を容易にするために、各メッセージ・コンポーネントはTLV（タイプ、長さ、値）フォーマットで記述されています。 SASP構造の図は、以下の実施例に見出すことができます。最初のセクションは、メッセージコンポーネントタイプが続くヘッダです。上述したように、ヘッダ、メッセージ・コンポーネント、および他のすべてのコンポーネントは、TLVフォーマットを持ちます。各成分値が今後の構成要素を指すいくつかのフィールドの可変数を含み（コンポーネント記述は、今後のセクションにある説明）。 （メッセージタイプのフィールドに規定されるように）最初のメッセージコンポーネントの後に、追加の成分の任意の数が含まれていてもよいです。
-------------------------------------------------
| |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
図2
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.
TLVフォーマットの実例を以下に示します。タイプコンポーネントタイプのバイナリ値を含む2バイトのフィールドです。長さ（タイプと長さフィールドを含む）をバイト単位でTLVのサイズを含む2バイトのフィールドです。 Valueフィールドは、実際のコンポーネントのデータを含む可変長フィールドです。
< xxxx xxxx xxxx xxxx, xxxx xxxx xxxx xxxx, xxxx...........xxxx >
|-----------------| |-----------------| |-----------------|
Type(2 bytes) Length(2 bytes) Value(variable)
Figure 3
図3
The TLV structure requires a type value for each protocol component. All SASP types are listed in this section.
TLV構造は、各プロトコルコンポーネントのタイプの値を必要とします。すべてのSASPタイプは、このセクションに記載されています。
Reserved 0x0000-0x1000
予約0x0000-0x1000
Message Types
メッセージタイプ
Registration Request 0x1010
登録要求0x1010
Registration Reply 0x1015
登録応答0x1015
DeRegistration Request 0x1020
登録解除要求の0x1020
DeRegistration Reply 0x1025
登録解除は0x1025返信
Get Weights Request 0x1030
ウェイトは0x1030を請求します
Get Weights Reply 0x1035
ウェイトは0x1035返信ゲット
Send Weights 0x1040
送信ウェイト0x1040
Set Load Balancer State Request 0x1050
設定するロードバランサ状態要求0x1050
Set Load Balancer State Reply 0x1055
設定するロードバランサの状態0x1055返信
Set Member State Request 0x1060
加盟国の要求0x1060を設定します。
Set Member State Reply 0x1065
加盟国の返信0x1065を設定します。
Utility Component Types
ユーティリティコンポーネントタイプ
SASP Header 0x2010
SASPヘッダー0x2010
Singular Component Types
特異コンポーネントタイプ
Member Data 0x3010
メンバーデータ0x3010
Group Data 0x3011
グループデータ0x3011
Weight Entry Data 0x3012
重入力データ0x3012
Member State Instance 0x3013
加盟国のインスタンス0x3013
Group Component Types
グループコンポーネントタイプ
Group of Member Data 0x4010
メンバーデータ0x4010のグループ
Group of Weight Entry Data 0x4011
重入力データ0x4011のグループ
Group of Member State Data 0x4012
加盟国のデータ0x4012のグループ
Reserved 0xF000-0xFFFF
予約0xF000-0xFFFF
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.
SASPヘッダの例示を以下の表に見出されます。すべてのメッセージがSASPプロトコルヘッダ・コンポーネントで開始されることが期待されます。
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
図4
o Version: The version of the protocol used in this message.
Oバージョン：このメッセージに使用されるプロトコルのバージョン。
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メッセージ長：SASPメッセージの全長を示す4バイトの符号付き整数値。任意のJava実装を容易にするために、署名された4バイトの値（または符号なしの値を持たない任意の他の実装が）であると言われています。しかし、負の長さが有効ではありません。
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.
メッセージID（O）各リクエストメッセージは、単に応答のメッセージIDフィールドに返されるメッセージの発信により4バイトのメッセージIDが与えられます。このフィールドは、多くの要求が送られてきた適切な要求に応答を関連付けるに依頼者を支援するためのものです。送信ウェイトメッセージ（返事を持っていない唯一のメッセージトランザクション）では、このフィールドは何の目的を果たしていません。
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.
接続に関与するエンティティによって使用されるプロトコルのバージョンを交渉するために、GWMはロードバランサの提案バージョンとロードバランサ要求に含まれるバージョンを表示します。
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.
GWMはロードバランサによって提案されたバージョンをサポートしている場合、それはレスポンスヘッダ内の適切な応答コードとの接続およびロード・バランサの提案のバージョンに対応します。この提案されたバージョンでは、これに関連して、すべてのメッセージのために使用されるバージョンである必要があります。
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.
GWMはロードバランサによって提案されたバージョンをサポートしていない場合は、GWMは、「メッセージが理解されていない」レスポンスコードとレスポンスヘッダのバージョンフィールドでGWMの最高のサポートSASPバージョンで応答します。これは、GWMのSASPバージョンレベルに降りてくるために、ロードバランサの徴候です。
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.
彼らはメンバー、メンバー・リソース、部材の重量、またはグループの単一のインスタンスを記述するためSASP成分の最も基本的な、特異成分です。 SASPの部品のいくつかは、他のSASPの部品を再利用します。このケースである場合、ベースコンポーネントによって再利用される任意のコンポーネントは、単にベースコンポーネントの直後に説明します。この技術のいくつかの例を見て体重エントリと加盟国のインスタンスのコンポーネントで説明されています。
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
図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プロトコル：IPヘッダのプロトコルフィールドに使用されるIPトランスポートレイヤの割り当てられた番号。これらは、[RFC1700]で定義されています。しかし、現在のリストはhttp://www.iana.orgに維持されます。例：TCP = 0x06で、UDP = 0x11を、など
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ポート：メンバーへの通信に使用するポート番号。 *** 0の値は、システム・レベルのメンバーを意味するプロトコルおよびポートのために与えることができます。ただし、0はすなわち、ポート0とMemberDataコンポーネントを含む登録解除要求は、そのIPプロトコルの任意のポートをリッスンしているすべてのアプリケーションの登録を解除するという意味ではありません（ポートまたはプロトコルフィールドのいずれかのワイルドカードとして認識されるべきではありません）。
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.
O IPアドレス：現在のフォーマットは、IPv4アドレスは、「IPv4互換IPv6アドレス」[RFC4291]として表される次の16バイトで記述されます。次の例では、Xはゼロとは4ビット進値を表します。 Xは任意の進値を記述する。
IPv4 Address: 00 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx
IPv4アドレス：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
IPv6アドレス：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ラベルの長さ：長さ、バイト単位で、追随するラベル文字列の。
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.
Oラベル：メンバー登録時に設定することができるUTF8文字列。この文字列はGWMに不透明であり、単に会員データ成分を含む任意の対応に含まれています。このラベルのサイズは<= 255バイトであることに注意してください。 UTF8の文字エンコーディングは、6つのバイトまでである可能性があるので、注意がそれはGWMが実際<= 255バイトである送信してくださいUTF8文字列を作るために、ロードバランサやメンバーによって行使されなければなりません。
The group data component simply describes a group with which to associate other singular 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 Data Type (0x3011) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB UID Length | |
+-+-+-+-+-+-+-+-+ +
. .
. LB UID .
. .
+ +-+-+-+-+-+-+-+-+
| |Group Name Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Group Name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
o LB UID Length: Length of the LB UID to follow (in bytes).
O LB UID長さ（バイト単位）に追従するLB UIDの長さ。
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 LB UID：一意の識別子とグループ名（ロード・バランサまたは汎用一意識別子（UUID）のいくつかのタイプのMACアドレスの例えば、UTF8表現）のためのコンテキストとして使用されるUTF8文字列。この文字列は、アプリケーションの登録と登録解除を関連付けるために、正しいロードバランサと状態メッセージを設定するために、グループワークロード・マネージャーによって使用されます。このユニークな識別子は、任意の64バイトよりも長いすべきではありません。
o Group Name Len: Length of the Group Name field to follow (in bytes).
Oグループ名レン：（バイト単位）に追従するグループ名フィールドの長さ。
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.
Oグループ名：ロード・バランサは、このグループ名で登録されたメンバーは、機能に同等であることを、グループワークロード・マネージャーに伝えるために選ばれたUTF8文字列。ゲット重量と登録解除メッセージでは、グループ名（グループ名の長さ= 0）に関連するロードバランサからすべてのグループを示すために省略することができます。
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.
重エントリコンポーネントは、特定のメンバー（またはメンバーデータ）との重量を関連付けるために取得し、送信ウェイトメッセージで使用されています。また、不透明な部材の状態フィールドと部材（後述）に関する追加情報を示すために一般的なメンバーフラグフィールドを使用します。重エントリコンポーネントを使用した場合、会員データTLVは直ちに重エントリ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
図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.
状態フィールド○：このフィールドは、スケジューラに状態情報を通信するための部材で使用されます。このフィールドに配置された情報は、GWMに不透明であり、単に部材重み付きスケジューラに転送されます。このフィールドには定義された値はありません。
o Flags Field: This field has several flag values that describe several attributes of the member.
Oフラグフィールド：このフィールドは、メンバーのいくつかの属性を記述し、いくつかのフラグ値を持っています。
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.
（GWMで設定）A.コンタクト成功フラグ：メンバーが現在実行されているかどうかについて説明します。接触成功フラグがオフの場合、このメンバーは、ロードバランサによって避けるべきです。
+ xxxx xxx1 The GWM has located this running system or
application.
+ xxxx xxx0 The GWM has not located this running system or application.
+ XXXX XXX0 GWMは、この実行中のシステムやアプリケーションの場所に位置していません。
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.
（ロード・バランサまたはメンバーによって設定される）B.静止フラグ：管理者が一時的にグループから登録を解除重み計算からメンバーを削除ではなく、したいときに使用されます。静止したときに、部材が依然として重みに表示されますが、静止フラグが設定され、その量はゼロとなります。管理者がアクティブにこのメンバーを返す場合、静止フラグが0になり、重量が提供されます。静止フラグがオンの場合、このメンバーは、ロードバランサによって避けるべきです。
+ xxxx xx1x The member is quiesced.
+ XXXX xx1xメンバーが静止しています。
+ xxxx xx0x The member is active (not quiesced).
+ XXXXメンバーがアクティブであるxx0x（静止しません）。
C. Registration Flag (set by the GWM): stores how the member was registered.
（GWMで設定）C.登録フラグ：メンバーが登録されたかを保存します。
+ xxxx x1xx This member has been registered by the load
balancer/scheduler.
+ xxxx x0xx This member has registered itself.
+ XXXX x0xxこのメンバは、自分自身を登録しています。
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.).
D.（GWMで設定された）自信フラグ：GWMはこのメンバーの状態についての知識を持っているかどうかについて説明します。残りのメンバーは、有効な重みを持っている間、このフラグは、グループ内のメンバーの一部だけのためにオフになっている場合、ロードバランサは、自信を持ってフラグをオフにして、それらのメンバーに仕事を送るのを避ける必要があります。自信を持っフラグが有効なすべてのグループメンバーのためにオフになっている場合には自信を持っフラグには、少なくとも1人のメンバーのために戻ってくるまでは、ロードバランサはGWMから任意の勧告を無視してください。全て自信フラグがオフである。この場合に、ロードバランサは、他の手段によってワークの正しい分布（おそらく異なる顧問、以前に設定した静的重み、など）を決定しなければなりません。
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 1XXX GWMは、このメンバーの状態の知識を有する決定しました。
+ xxxx 0xxx GWM has no knowledge of the state of this member.
+ XXXX 0XXX GWMは、このメンバーの状態の知識を持ちません。
E. Leftmost four bits are reserved (0000 xxxx - 1111 xxxx).
E.左端の4ビットは予約されている（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.
O重量：このフィールドは、このメンバーに送信されなければならない作業の相対的な量のためのGWMの勧告を表しています。これは、重み値の広い範囲を受信するように準備されるべき0 65536にロードバランサの可能な範囲を有する16ビットのフィールドです。制限された最大の重み値を持つロードバランサはGWMによる管理の粒度を制限し、ひいては、最適なパフォーマンスよりも少ない可能性があります。多くの既存の実装は、0から100までの最小生量範囲をサポートしています。
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.
加盟国のインスタンスのコンポーネントは、言及したメンバーの送信者の認知状態を示すためにセット加盟国のメッセージで使用されています。この成分は、最終的にWeightEntry成分に終わるであろう値を設定するために使用されています。加盟国インスタンスコンポーネントは、メンバーデータTLV使用する場合には、直ちに加盟国インスタンス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
図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）このフィールドは、ロード・バランサまたはスケジューラに状態情報を通信するための部材で使用されます。このフィールドには定義された値はありません。
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.
Oフラグフィールド：このフィールドは、メンバーの属性について説明します。現在定義されている唯一のフラグ値は、静止フラグのことです。管理者が一時的にウエイト計算からメンバーを削除したいが、グループから登録を解除しないであろう場合に静止フラグが使用されています。静止したときに、部材が依然として重みに表示されますが、静止フラグが設定され、その量はゼロとなります。管理者がアクティブにこのメンバーを返す場合、静止フラグが0になり、重量が提供されます。
A. Quiesce Flag
A.静止旗
+ 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.
この状態を設定+ XXXX XXX0部材やロードバランサは、非静止状態で部材を配置しています。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
（ - 1111 111X 0000 000X）をB.左端7ビットは予約されています。
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.
グループプロトコルコンポーネントは、それぞれ関連する単数コンポーネントのコレクションが含まれています。特に、それらは、特定のグループのデータコンポーネントにメンバーデータ、体重入力、または加盟国のインスタンスのコンポーネントを関連付けます。これらの場合において、特定の「Xの基」成分がすぐにグループデータ構成要素が続きます。グループデータ成分は直ちにグループに含まれる単数形の構成要素の任意の数が続くであろう。この文書に記載されている図において、アスタリスク付きコンポーネントタイプは、数回繰り返される成分を示します。
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
図9
o Member Count: The number of Member Data Components immediately following the Group Data structure.
Oメンバー数：すぐにグループデータ構造以下のメンバーデータコンポーネントの数を。
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.
メンバーデータコンポーネントのOアレイ：メンバーCountが指定している限り多くのメンバーデータのTLVがあるでしょう。ロードバランサ/スケジューラは、このグループ名に関連付けるメンバーを識別するために、グループワークロード・マネージャーを可能にする情報を渡すために、これらのコンポーネントを使用します。メンバーデータコンポーネントは、セクション5.1で説明されました。登録解除メッセージでは、メンバーのカウントは、特定のグループのすべてのメンバーを示すために0に設定することができます。
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
図10
o Weight Entry Count: The number of Member Data / Weight Entry combinations to follow the Group Data TLV.
Oウェイトエントリ数：メンバーデータ/重入力の組み合わせの数は、グループデータ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.
重入力データのTLVのOアレイ：体重エントリカウントが指定した限り多くの[メンバーデータ/重入力]のTLVがあるでしょう。セクション5.3で説明したように各重みエントリコンポーネントは、対応するメンバデータ要素が先行します。このメンバーデータ/重入力データの組み合わせは重エントリが指定カウント限り多くの重入力項目を形成するために繰り返されます。
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
図11
o Member State Instance Count: The number of Member Data / Member State Instance combinations following the Group Data component.
O加盟国のインスタンスカウント：グループデータコンポーネント以下のメンバーデータ/加盟国のインスタンスの組み合わせの数。
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.
加盟国データコンポーネントのOアレイ：第5.4節で説明したように各加盟国インスタンス成分は直ちにその対応するメンバデータ要素が先行します。このメンバーデータ/加盟国のインスタンスの組み合わせは、加盟国のインスタンスと同じくらい多くの加盟国の項目を指定カウントを形成するために繰り返されます。
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.
SASPメッセージは、TLVの（タイプ、長さ、および値コンポーネント）の集まりです。ヘッダは、それが一部であるメッセージの種類についての情報を有していません。目的固有の情報は、メッセージコンポーネントです。この形式は、単一のメッセージに複数のメッセージコンポーネントを配置すること容易にすることができます。しかし、複数のメッセージコンポーネントのこの使用は、すべてのGWMでサポートされていないと不確定動作を作り出すことができます。メッセージコンポーネントが他のコンポーネントを含む必要がある他のプロトコルコンポーネントと同様に、追加の成分は即時メッセージ・コンポーネントに従います。
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.
GWMに送信されたすべてのSASP要求は応答で認められるでしょう。応答は、要求の成功を記述したシングルバイトの応答コードだけでなく、要求された情報が含まれています。 0x3Fに関わらず、応答メッセージ・タイプを用いてもよい - SASPは0×00の範囲のいくつかの一般的な応答コードを定義します。しかし、いくつかの要求タイプは、一般的な応答コードでカバーされていない特定のエラー状態が発生することがあります。 0x40の応答コード範囲 - 0xFFでは、これらのメッセージ固有の応答コードのために使用されます。任意の所与のSASP応答のみ（エラータイプに応じて）1つの応答コードを含むであろう。このセクションでは、特定のSASPメッセージの形式と目的を説明しています。
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 balancer/scheduler is set.
この交換は、ロードバランサ/スケジューラとグループワークロード・マネージャーの間だけでなく、グループワークロード・マネージャーとグループ名で指定されたグループにメンバーを登録するための部材との間に起こります。アプリケーションは、IPアドレス、プロトコル、およびポートで識別されています。システムは、唯一のIPアドレス（ポート= 0000およびプロトコル= 0x00の）で識別されています。グループ内のすべてのメンバーは、同等の機能を持っているので、グループワークロード・マネージャーは、グループ内の任意のメンバーに、ルータ、ロードバランサ、およびスケジューラを指示することができます。登録は、ロードバランサ/スケジューラ又は実際の部材のいずれかから来ることができるにもかかわらず、ロードバランサ/スケジューラの状態が設定されている間信頼フラグがセットされている場合、メンバーが開始登録のみを考えます。
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
図12
o Flag Field
Oフラグ・フィールド
A. Load Balancer Flag
A.ロードバランサ旗
+ xxxx xxx1 The entity sending this message is the load
balancer.
+ xxxx xxx0 The entity sending this message is an Application.
+ XXXX XXX0このメッセージを送信エンティティがアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
（ - 1111 111X 0000 000X）をB.左端7ビットは予約されています。
o Group of Member Data Count: The number of "Group of Member Data" components immediately following the Registration Request component.
Oメンバーデータのグループ数：「グループメンバーデータの」コンポーネントの数は、直ちに登録要求コンポーネントを以下に示します。
o 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 the 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.
グループメンバーのデータコンポーネントのOアレイは：（セクション6.1で説明したように）各「グループメンバのデータ」成分がすぐにグループデータコンポーネントと、その会員データ成分が続いています。これらの「グループメンバーのデータ」の構成要素のいくつかが存在してもよい場合には、成分秒「メンバーデータのグループは、」最初の「グループメンバデータの」コンポーネントによって参照される内部構成要素のすべてがされた後に表示されます記載されています。フォーマットは、メッセージ内のすべての後続の「グループメンバーデータの」コンポーネントのと同じです。
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
図13
o General SASP return codes (0x00 - 0x3F)
O一般SASPのリターンコード（$ 00 - は0x3F）
* 0x00 Successful
* 0x00の成功
* 0x10 Message not understood
* 0x10のメッセージが理解されていません
* 0x11 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.
* 0x11をGWMは、送信者からのメッセージを受け付けません。この理由は、次のものがあります。メッセージは、LBによって送信されていないし、信頼フラグがBオフです。 LBは、メッセージcで異なるLBのメンバーに対処しようとしました。このメッセージタイプのベンダー固有の基準が満たされませんでした。
o Message-Specific return codes (0x40 - 0xFF)
Oメッセージ固有の戻りコード（0x40の - 0xFFで）
* 0x40 Member already registered
* 0x40のメンバーはすでに登録されています
* 0x44 Duplicate Member in Request
リクエスト中* 0x44の重複メンバー
* 0x45 Invalid Group (determined by the GWM)
* 0x45無効なグループ（GWMで決定）
* 0x50 Invalid Group Name Size (size == 0)
* 0x50を無効なグループ名サイズ（サイズ== 0）
* 0x51 Invalid LB UID Size (size == 0 or > max)
* 0x51無効なLB UIDサイズ（サイズ== 0または> MAX）
* 0x61 Member is registering itself, but LB hasn't yet contacted the GWM. This registration will not be processed.
*の0x61メンバーは、自分自身を登録しているが、LBはまだGWMに連絡していません。この登録は処理されません。
**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.
**無効なグループエラー戻りコードは、LBまたはGWMが無効と考えるグループを形成しようとするメンバーをいいます。例えば、いくつかのGWMベンダーは、同じグループ内の両方のシステムおよびアプリケーションのメンバーの登録をサポートしない場合があります。 GWMは、このエラーコードを戻すことができるかを判断するには、ベンダーのマニュアルを参考にしなければなりません。
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 deregister members from a group specified by Group Name with the Group Workload Manager. Even though deregistrations can come from either the load balancer/scheduler or the actual member, member-initiated deregistrations will only be considered if the Trust flag is set with a Set LB State message.
この交換は、グループワークロード・マネージャーとグループ名で指定されたグループからメンバー登録を解除するために、ロードバランサ/スケジューラとグループワークロード・マネージャーの間だけでなく、グループワークロード・マネージャーとメンバーの間で起こります。登録解除は、ロードバランサ/スケジューラまたは実際のメンバーのいずれかから来ることができたとしても信頼フラグが設定LB状態メッセージで設定されている場合は、メンバー主導の登録解除にのみ考慮されます。
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
図14
o Flag Field
Oフラグ・フィールド
A. Load Balancer Flag
A.ロードバランサ旗
+ xxxx xxx1 The entity sending this message is the load
balancer.
+ xxxx xxx0 The entity sending this message is an Application.
+ XXXX XXX0このメッセージを送信エンティティがアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
（ - 1111 111X 0000 000X）をB.左端7ビットは予約されています。
o Reason: Byte describing the reason for deregistering the group or instance.
O理由：バイトはグループまたはインスタンスを登録解除する理由を説明します。
A. SASP-defined Reason Codes (0x00-0x7F)
A. SASP定義理由コード（0x00-0x7F）
+ 0x00 No reason given.
+ 0x00の理由はない与えられました。
+ 0x01 Learned and Purposeful, i.e., a human has deconfigured this member from the load balancer configuration.
+ 0x01の学習と意図的、すなわち、ヒトは、ロードバランサ構成からこのメンバーを構成解除しました。
+ 0x80-0xFF Open for vendor specific deregistration reason codes.
ベンダー固有の登録解除の理由コードのための+ 0x80-0xFFオープン。
o Group of Member Data Count: The number of "Group of Member Data" components immediately following the DeRegistration Request component.
Oメンバーデータのグループ数：「グループメンバーデータの」部品の数はすぐに登録解除要求コンポーネントを以下に示します。
o 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.
グループメンバーのデータコンポーネントのOアレイは：（セクション6.1で説明したように）各「グループメンバのデータ」成分がすぐにグループデータコンポーネントと、その会員データ成分が続いています。この場合、ここでこれらの「会員データ群」のいくつかの成分が存在してもよく、第二の「グループメンバーデータの」コンポーネントのみ最初の「グループメンバーデータの」コンポーネントによって参照される内部構成要素の全ての後に表示されます記載されています。フォーマットは、メッセージ内のすべての後続の「グループメンバーデータの」コンポーネントのと同じです。
** If Member Count equals zero in the Group of Member Data component, the Group Workload Manager will deregister the entire group.
**メンバーCountはグループメンバーのデータコンポーネントにゼロに等しい場合は、グループワークロード・マネージャーは、グループ全体の登録を解除します。
** 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.
**グループデータコンポーネントがユニークLB識別子フィールドとグループ名フィールドの両方が含まれていることを思い出してください。グループデータコンポーネントは、グループ名（のgroupdataのグループ名の長さ== 0）を持っていない場合は、グループワークロード・マネージャーは、このロードバランサに関連付けられているすべてのグループを登録解除します。
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
図15
o Return Code: A byte return code indicating the status of action taken.
Oリターンコード：実行されたアクションのステータスを示すバイトのリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPのリターンコード（$ 00 - は0x3F）
+ 0x00 Successful
+ 0x00の成功
+ 0x10 Message not understood
理解されていない+ 0x10のメッセージ
+ 0x11 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.
+ 0x11をGWMは、送信者からのメッセージを受け付けません。この理由は、次のものがあります。メッセージは、LBによって送信されていないし、信頼フラグがBオフです。 LBは、メッセージcで異なるLBのメンバーに対処しようとしました。このメッセージタイプのベンダー固有の基準が満たされませんでした。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の戻りコード（0x40の - 0xFFで）
+ 0x41 Application or System not registered
+ 0×41アプリケーションまたはシステムが登録されていません
+ 0x42 Unknown Group Name
+の0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43この未知のLB UID
+ 0x44 Duplicate Member in Request
リクエストで+ 0x44の重複メンバー
+ 0x46 Duplicate Group in Request (for remove all members/groups requests)
リクエストで+ 0x46の重複グループ（削除のためのすべてのメンバー/グループ要求）
+ 0x51 Invalid LB UID Size (size == 0 or > max)
+ 0x51無効なLB UIDサイズ（サイズ== 0または> MAX）
+ 0x61 Member is deregistering itself, but LB hasn't yet contacted the GWM. This deregistration will not be processed.
+の0x61メンバーは、自分自身を登録抹消されていますが、LBはまだGWMに連絡していません。この登録解除は処理されません。
This exchange happens between the load balancer/scheduler and the Group Workload Manager to get weights for the groups specified in the list of GroupData objects. In the case of 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,
この交換はのgroupdataオブジェクトのリストで指定されたグループの重みを取得するには、ロードバランサ/スケジューラとグループワークロード・マネージャーとの間で起こります。 （同じ機能を持つアプリケーション間のワークロードのバランスをとる）アプリケーションの負荷分散の場合には、ロードバランサは、重みと関連するメンバーの配列を取得するために、グループワークロード・マネージャーのすべての間隔（以下、グループワークロード・マネージャーによって返されるパラメータ）を呼び出します（たとえば、 、Application1の20、SecondCopyOfApplication 30、ThirdCopyOfApplication 5）。ロードバランサは、次に作業メンバーの各々に送信されるのファッションを決定するためにこれらの重みを使用します。例えば、重み付きラウンドロビンの場合には、ロードバランサ/スケジューラは、アプリケーション1、SecondCopyOfApplicationの隣にリクエストを送信し、そしてThirdCopyOfApplicationの隣にあります。 15の要求の後、ロードバランサ/スケジューラは唯一のアプリケーション1とSecondCopyOfApplicationに作業を送信します。さらに30のリクエストした後、ロードバランサ/スケジューラはSecondCopyofApplicationに要求を送信します。別の10個の要求後、ロードバランサ/スケジューラ製品は、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.
再び30、および5。秒の間隔数が経過している場合や、ロードバランサ/スケジューラは、重みの新しいセットになるだろう。
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
図16
o Group Data Count: The number of "Group Data" components immediately following the Get Weights Request TLV.
Oグループデータ数：すぐゲットウェイト以下「グループデータ」コンポーネントの数はTLVを要求します。
o Array of Group Data Components: This array of Group Data Components lists the groups for which the load balancer wants to get weights.
グループデータコンポーネントのOアレイ：グループデータコンポーネントのこの配列は、ロードバランサは重みを取得したい対象のグループが一覧表示されます。
** 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.
取得ウェイト要求のグループデータ構造にはグループ名が存在しない場合は**、ロードバランサは、ロードバランサのために登録されたすべてのグループの重みを要求しています。
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
図17
o Return Code: A byte return code indicating the status of action taken.
Oリターンコード：実行されたアクションのステータスを示すバイトのリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPのリターンコード（$ 00 - は0x3F）
+ 0x00 Successful
+ 0x00の成功
+ 0x10 Message not understood
理解されていない+ 0x10のメッセージ
+ 0x11 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.
+ 0x11をGWMは、送信者からのメッセージを受け付けません。この理由は、次のものがあります。 LBは、メッセージBで異なるLBのメンバーに対処しようとしました。このメッセージタイプのベンダー固有の基準が満たされませんでした。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の戻りコード（0x40の - 0xFFで）
+ 0x42 Unknown Group Name
+の0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43この未知のLB UID
+ 0x46 Duplicate Group in Request
+ 0x46の重複するグループの要求で
+ 0x51 Invalid LB uid Size (size == 0 or > max)
+ 0x51無効なLB UIDサイズ（サイズ== 0または> MAX）
o Interval: These two bytes indicate a recommended polling interval for the load balancer to use. The Group Workload Manager is stating that any polling interval smaller than the suggested interval would probably retrieve values before they have had a chance to change.
O間隔：これらの2つのバイトは、ロードバランサが使用するための推奨ポーリング間隔を示しています。グループワークロード・マネージャーは、彼らが変えるチャンスがあった前に示唆した間隔よりも小さい任意のポーリング間隔は、おそらく値を取得することを述べています。
o 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). In this case, where several "Group of Weight Data" components may be present, the second "Group of Weight Data" component only appears after all of the internal components that are referred to by the first "Group of Weight Data" component are listed. The format is the same for all subsequent "Group of Weight Data" components in the message.
重入力データ成分のOグループ：（セクション6.2で説明したように）各「重量データ群」成分がすぐにグループデータコンポーネントとその重量エントリデータ成分が続いています。この場合には、ここでいくつかの「重量データ群」の成分が存在していてもよい第一の「グループ重データの」コンポーネントによって参照される内部構成要素のすべてがリストされた後、第二の「グループ重データの」コンポーネントのみ表示します。フォーマットは、メッセージ内のすべての後続「グループ重みデータの」コンポーネントのと同じです。
This exchange happens between the Group Workload Manager and the load balancer/scheduler to send the new weights for the group specified in Group Name. This message is unique in that it is the only message exchange initiated by the Group Workload Manager and the only message that has no reply. In the case of application load balancing (balancing workloads between applications with the same functionality), the Group Workload Manager would message the load balancer at a possibly dynamic interval (chosen by the Group Workload Manager) to send 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 another 30 requests, the load balancer/scheduler would only send requests to SecondCopyofApplication. After an additional 10 requests, the load balancer/scheduler product would start over using the weights of 20, 30, and 5 again, if it has not yet received a new set of weights. The Group Workload Manager only sends this message if the Push flag has been enabled using a Set Load Balancer State message.
この交換はグループ名で指定されたグループの新しい重みを送信するために、グループワークロード・マネージャーとロードバランサ/スケジューラの間で起こります。このメッセージは、グループワークロード・マネージャーと返事を持っていない唯一のメッセージによって開始さだけメッセージ交換であるという点で独特です。アプリケーション負荷の場合バランシング（同じ機能を持つアプリケーション間でワークロードのバランスをとる）は、メッセージ（グループワークロードマネージャによって選択される）可能性の動的間隔でロード・バランサ希望グループワークロードマネージャは、重みと関連するメンバーの配列を（送信します例えば、アプリケーション1 20、SecondCopyOfApplication 30、ThirdCopyOfApplication 5）。ロードバランサは、次に作業メンバーの各々に送信されるのファッションを決定するためにこれらの重みを使用します。例えば、重み付きラウンドロビンの場合には、ロードバランサ/スケジューラは、アプリケーション1、SecondCopyOfApplicationの隣にリクエストを送信し、そしてThirdCopyOfApplicationの隣にあります。 15の要求の後、ロードバランサ/スケジューラは唯一のアプリケーション1とSecondCopyOfApplicationに作業を送信します。別の30個の要求の後、ロードバランサ/スケジューラはSecondCopyofApplicationに要求を送信します。それはまだ重みの新しいセットを受信していない場合、追加の10個の要求後、ロードバランサ/スケジューラ製品は、再び20、30、及び5の重みを使用して最初からやり直すことになります。プッシュフラグがセットロードバランサの状態メッセージを使用して有効になっている場合、グループワークロード・マネージャーは、このメッセージを送信します。
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
図18
o 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). In this case, where several "Group of Weight Data" components may be present, the second "Group of Weight Data" component only appears after all of the internal components that are referred to by the first "Group of Weight Data" component are listed. The format is the same for all subsequent "Group of Weight Data" components in the message.
重入力データ成分のOグループ：（セクション6.2で説明したように）各「重量データ群」成分がすぐにグループデータコンポーネントとその重量エントリデータ成分が続いています。この場合には、ここでいくつかの「重量データ群」の成分が存在していてもよい第一の「グループ重データの」コンポーネントによって参照される内部構成要素のすべてがリストされた後、第二の「グループ重データの」コンポーネントのみ表示します。フォーマットは、メッセージ内のすべての後続「グループ重みデータの」コンポーネントのと同じです。
This is a special exchange that can take place between the load balancer and the Group Workload Manager or between the Member and the Group Workload Manager to pass information about the state of the member including placing the member in quiesced or non-quiesced states. In particular, the load balancer/scheduler can use this message to quiesce a set of members. Members can also use this message to quiesce themselves as well as to pass certain state information to the load balancer/scheduler that is opaque to the Group Workload Manager. This opaque state information is passed to the load balancer/scheduler with the weights during get and send weight 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. 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
図19
o Flag Field
Oフラグ・フィールド
A. Load Balancer Flag
A.ロードバランサ旗
+ xxxx xxx1 The entity sending this message is the load
balancer.
+ xxxx xxx0 The entity sending this message is an Application.
+ XXXX XXX0このメッセージを送信エンティティがアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
（ - 1111 111X 0000 000X）をB.左端7ビットは予約されています。
o Group of Member State Data Count: The number of "Group of Member State Data" components immediately following the Set Member State Request TLV.
O加盟国のデータのグループ数：すぐに設定加盟国の要請TLV以下「グループメンバーの状態データ」コンポーネントの数を。
o 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). In the case where several "Group of Member State Data" components may be present, the second "Group of Member State Data" component only appears after all of the internal components that are referred to by the first "Group of Member State Data" component are listed. The format is the same for all subsequent "Group of Member State Data" components in the message.
グループメンバーのデータコンポーネントのOアレイ（セクション6.3で説明したように）各「グループメンバーの状態データ」成分がすぐにグループデータコンポーネントとその加盟国インスタンスコンポーネントが続きます。いくつかの「加盟国データ群」の成分が存在し得る場合には、コンポーネント第二「メンバー状態データのグループは、」最初の「グループメンバー状態データの」コンポーネントによって参照される内部構成要素の全ての後に表示されます記載されています。フォーマットは、メッセージ内のすべての後続「グループメンバーの状態データ」の部品についても同様です。
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
図20
o Return Code: A byte return code indicating the status of action taken.
Oリターンコード：実行されたアクションのステータスを示すバイトのリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPのリターンコード（$ 00 - は0x3F）
+ 0x00 Successful
+ 0x00の成功
+ 0x10 Message not understood
理解されていない+ 0x10のメッセージ
+ 0x11 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.
+ 0x11をGWMは、送信者からのメッセージを受け付けません。この理由は、次のものがあります。メッセージは、LBによって送信されていないし、信頼フラグがBオフです。 LBは、メッセージcで異なるLBのメンバーに対処しようとしました。このメッセージタイプのベンダー固有の基準が満たされませんでした。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の戻りコード（0x40の - 0xFFで）
+ 0x41 Application or System not registered
+ 0×41アプリケーションまたはシステムが登録されていません
+ 0x42 Unknown Group Name
+の0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43この未知のLB UID
+ 0x44 Duplicate Member in Request
リクエストで+ 0x44の重複メンバー
+ 0x46 Duplicate Group in Request
+ 0x46の重複するグループの要求で
+ 0x50 Invalid Group Name Size (size == 0)
+ 0x50を無効グループ名サイズ（サイズ== 0）
+ 0x51 Invalid LB UID Size (size == 0 or > than max)
+ 0x51無効なLB UIDサイズ（maxよりもサイズ== 0または>）
+ 0x61 Member is setting state for itself, but LB hasn't yet contacted the GWM. This request will not be processed.
+の0x61メンバーは、自身の状態を設定しているが、LBはまだGWMに連絡していません。この要求は処理されません。
This is an exchange that can take place between the load balancer and the Group Workload Manager to pass information about the state (and partial configuration) of the load balancer.
これは、ロードバランサの状態（および部分構成）に関する情報を渡すために、ロードバランサやグループワークロード・マネージャーとの間で行うことができる交換です。
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
図21
o LB UID Length: one-byte length field describing the size of the following LB UID.
O LB UID長さ：以下LB UIDのサイズを記述する1バイトの長さフィールド。
o LB UID: This should be the same unique identifier given when registering group members for this particular load balancer.
O LB UID：これは、この特定のロードバランサのためのグループメンバーを登録するときに与えられた同じ一意の識別子でなければなりません。
o LB Health: This field gives the load balancer a chance to pass in a metric describing its own health or state.
LB健康O：このフィールドは、ロードバランサに独自の健康や状態を記述するメトリックに合格する機会を与えてくれます。
0x00 - 0x7F Least Healthy - Most Healthy
0x00 - 0x7Fの最小健康 - 最も健康
0x80 - 0xFF Reserved
0x80 - 0xFFの予約
o LB Flags:
O LBフラグ：
A. Push Flag
A.プッシュ旗
+ xxxx xxx1 The load balancer should receive weights through
the Send Weights message (GWM pushes weights to load
balancer). Even if 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 get the new weights. This is the default behavior. (load balancer pulls weights from GWM).
+ XXXX XXX0ロードバランサは、新たな重みを取得するには、Getウェイトメッセージを送信します。これがデフォルトの動作です。 （ロードバランサはGWMからウェイトを引きます）。
B. Trust Flag
B.トラスト旗
+ xxxx xx1x Trust any member-initiated registration,
deregistration, or set state message. Immediately reflect
the registration, deregistration, or new state in the
weights sent.
+ xxxx xx0x Do not trust any member-initiated registration, deregistration, or set state message. Registration, Deregistration, and State Setting of members can only occur from the load balancer. Discard any member-initiated registration, deregistration, or set state message. This is the default behavior.
+ XXXX xx0x任意のメンバーが開始した登録、登録解除、または設定された状態メッセージを信用してはいけません。メンバーの登録、登録解除、および状態設定は、ロードバランサから発生する可能性があります。任意のメンバーが開始登録、登録解除、または設定された状態メッセージを破棄する。これがデフォルトの動作です。
C. No Change / No Send Flag
C.変更なし/いいえ送信旗
+ xxxx x1xx The GWM must not include members whose weights
and state (i.e., 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 the weights to this load balancer (including members whose weights and state have not changed). This is the default behavior.
（重みと状態変化していないメンバーを含む）は、このロードバランサにウェイトを送信するときに+ XXXX x0xx GWMは、すべてのグループメンバーの重みを含まなければなりません。これがデフォルトの動作です。
D. Leftmost five bits are reserved (0000 0xxx - 1111 1xxx).
D.左端5ビットは予約されて（0000 0XXX - 1111 1XXX）。
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
図22
o Return Code: A byte return code indicating the status of action taken.
Oリターンコード：実行されたアクションのステータスを示すバイトのリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPのリターンコード（$ 00 - は0x3F）
+ 0x00 Successful
+ 0x00の成功
+ 0x10 Message not understood
理解されていない+ 0x10のメッセージ
+ 0x11 GWM 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.
+ 0x11をGWMは、送信者からのメッセージを受け付けません。この理由は、次のものがあります。 LBは異なるLB bの状態に対処しようとしました。このメッセージタイプのベンダー固有の基準が満たされませんでした。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の戻りコード（0x40の - 0xFFで）
+ 0x51 Invalid LB UID Size (size == 0 or > max)
+ 0x51無効なLB UIDサイズ（サイズ== 0または> MAX）
This section provides an example of the actual SASP message encoding. For this example, we will look at a sample GetWeights Reply in which two webservers are registered to a serverfarm called FARM1. The IP addresses of the two webservers are 10.10.10.1 and 10.10.10.2. Currently the GWM has a weight of 40 for 10.10.10.1 and 20 for 10.10.10.2. The load balancer has a unique Identifier of "LB1" and the message example was sent by the GWM in response to a request (MessageID: 0x32000000) for FARM1's weights.
このセクションでは、実際のSASPメッセージ符号化の例を提供します。この例では、2つのウェブサーバがFARM1と呼ばれるサーバファームに登録されている返信サンプルGetWeightsを見ていきます。 2つのウェブサーバのIPアドレスが10.10.10.1と10.10.10.2です。現在、GWMは10.10.10.1のための40および10.10.10.2のための20の重量を有します。ロードバランサは、「LB1」の一意の識別子を有しており、メッセージの例は要求に応じてGWMによって送信された（メッセージID：0x32000000）FARM1の重みため。
The TLVs necessary for this message are shown in the following list.
このメッセージのために必要なの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
図23
------------------------------------
| | 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
図24
------------------------------------
| | 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
図25
------------------------------------
| | 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
図26
------------------------------------
| | 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
図27
------------------------------------
| | 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
図28
------------------------------------
| | 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
図29
------------------------------------
| | 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 30
図30
A hex stream representing this same message is below:
この同じメッセージを表す六角ストリームは以下のとおりです。
20 10 00 0D 01 00 00 00 6A 32 00 00 00 10 35 00 09 00 00 40
20 10 00 0D 01 00 00 00 IIIA 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
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
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
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
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
00 08 00 0D 00 14
(106 bytes)
（106バイト）
This section describes the expected general flow of the SASP messages.
このセクションでは、SASPメッセージの期待される一般的な流れを説明しています。
SASP first starts with a connection from an LB to the GWM. This is 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).
SASPは、最初にGWMにLBからの接続を開始します。これは、長時間実行接続であることが予想されており、多くのメッセージのために使用されます。接続を確立した後、LBは、いずれかのメンバーのグループを登録するか、メンバーが自分自身を登録することを可能にする信頼フラグをセットします。信頼フラグがセットLB状態要求（両方のメッセージ・フローを以下に示す）を用いて設定されています。
Registration from load balancer
ロードバランサから登録
------------ Registration Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Registration Reply | Manager |
| |<-----------------------| |
------------ ------------------
Set LB State from load balancer
ロードバランサからLB状態を設定
------------ Set LB State Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Set LB State Reply | Manager |
| |<-----------------------| |
------------ ------------------
Figure 31
図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.
ロードバランサは、常に接続が失われた後、すべての状態情報を削除し、GetWeightsメッセージを使用して、それを回復することができます。新しい接続の確立には、古いものが壊れていると仮定することGWMの原因となります。この場合、GWMは、検出された休憩の後、限られた時間のためのロード・バランサのすべての状態を維持します。限られた時間が経過した後、切断された接続のためのすべての状態は、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.
システムの負荷分散の場合には、部材の表現は、ポートとプロトコルの値として使用0のメンバーのIPアドレスです。アプリケーションの負荷分散の場合には、メンバーの表現は、メンバーのIPアドレスとアプリケーションのポートとプロトコルです。
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.
グループメンバーの登録解除はいつでも行うことができます。ロードバランサは、多くのメンバーの多くのグループにどこか一つのメンバーであるグループから登録を解除することができます。 LBはまた、グループ全体の登録を解除するか、一度にそのグループのすべての登録を解除することがあります。信頼フラグがセットされていると、それは適切なロードバランサ情報を知っている場合メンバーはまた、自身の登録を解除してもよいです。
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).
メンバーが登録されると、GWMはロードバランサに返送する重みを決定するために監視および重量演算処理を開始します。いつでもロードバランサはGetWeightsメッセージを発行することができるし、特定のグループ内のメンバーのための重みを求めます。 LBはまたGetWeightsメッセージを待たずに重みを送信するGWMを知らせるフラグを設定してもよいです。このフラグが設定されている場合、GWMは、（間隔がアルゴリズムに使用され、生成された重みの分散に応じて変えることができる）が適切であると感じる間隔で重みを送信します。
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.
いつでもLB又は特定の部材がSetMemberStateメッセージの使用を介して部材を休止してもよいです。この場合、メンバーの重量は常にゼロになり、静止フラグは、その重量を送信するときにオンになります。また、メンバーは重みを送信するときにも提示される不透明な状態値を送信するには、このメッセージを使用することができます。
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.
任意の時点で、ロードバランサはGWMにその相互作用を設定するためのSetLBState要求を送信することもできます。メッセージは、ロードバランサは、プッシュ、信頼、及びNoChange_NoSendフラグを設定することを可能にします。また、ロードバランサが表示されるようにGWMに健康値を渡すことができます。
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.
ケース：LBまたはアプリケーションは、GWMが完全に稼働している前にGWMに接続しようとします。
Behavior: The LB or application should wait at least 20 seconds to retry the connection.
行動：LBまたはアプリケーションが接続を再試行するには、少なくとも20秒間待つ必要があります。
Case: Members attempt to register or deregister themselves before the LB develops the connection with the GWM.
ケース：メンバーは、LBが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.
動作：この場合、メンバーはそのLB UIDと登録されたLBが存在しないことを意味するエラーコードで応答を受け取ることになります。
Case: Member registers or deregisters for an LB who has not set the Trust flag.
ケース：トラストフラグを設定していないLBのための会員登録や登録解除。
Behavior: GWM will send Member a reply containing an error code.
行動：GWMはメンバーのエラーコードを含む応答を送信します。
Case: LB asks for weights for a group that doesn't exist.
ケース：LBは存在しないグループの重みを要求します。
Behavior: GWM will send LB a reply containing an error code.
行動：GWMはLBエラーコードを含む応答を送信します。
Case: LB or Member attempts to register a member that is already registered in that group.
ケース：LBまたはメンバーは、すでにそのグループに登録されたメンバーを登録しようとします。
Behavior: GWM will send sender a reply containing an error code.
行動：GWMは送信者にエラーコードを含む応答を送信します。
Case: LB or Member attempts to deregister a member or group that doesn't exist.
ケース：LBまたはメンバーが存在しないメンバーまたはグループの登録を解除しようとします。
Behavior: GWM will send sender a reply containing an error code.
行動：GWMは送信者にエラーコードを含む応答を送信します。
Case: LB or Member tries to set state for a non-registered server.
ケース：LBかメンバー未登録のサーバーの状態を設定しようとします。
Behavior: GWM will send sender a reply containing an error code.
行動：GWMは送信者にエラーコードを含む応答を送信します。
Case: LB tries to Get Weights for an unregistered group.
ケース：LBは未登録グループの重みを取得しようとします。
Behavior: GWM will send LB a reply containing an error code.
行動：GWMはLBエラーコードを含む応答を送信します。
9.3. Example Flow 1: Load Balancer Registration, Getting Weights, and Application-Side Quiescing
9.3. 例の流れ1：ロードバランサの登録、取得ウェイト、およびアプリケーション側の静止
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
図32
1. The LB registers Members A, B, and C in a group named GRP1. The GWM replies with no error.
1. LBはGRP1という名前のグループにメンバーA、B、及びCを登録します。 GWMはエラーなしで応答します。
LB Health: 0x00 Flags: 0000 0010
LB健康：0x00のフラグ：0000 0010
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x00 0000 1101 5
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:
5.メンバーCは、以下のフラグで自身を休止する設定加盟国のメッセージを送信します。
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0001
6. The LB sends the Get Weights message for GRP1 and receives the following:
6. LBはGRP1のためのGetウェイトメッセージを送信し、次を受信します。
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:
7.メンバーCは、以下のフラグで（非休止自体）を再開するために設定する加盟国のメッセージを送信します。
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0000
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
9.4. 例フロー2：設定するロードバランサの状態、アプリケーション登録、およびロードバランサグループの登録抹消
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
図39
1. The LB sets its state with the Set LB State message and the following parameters.
1. LBは、Set LB州メッセージと次のパラメータを使用して、その状態を設定します。
Health: 0x7F Flags: 0000 0011
健康：0x7Fのフラグ：0000 0011
2. Member A registers itself for work in GRP1 using the Register message.
2.メンバーAがRegisterメッセージを使用して、GRP1での仕事のために自分自身を登録します。
3. Member B registers itself for work in GRP1 using the Register message.
3.メンバーBはRegisterメッセージを使用して、GRP1での仕事のために自分自身を登録します。
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.
5.メンバーCはRegisterメッセージを使用して、GRP1での仕事のために自分自身を登録します。
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
7. LB = 0をカウントメンバーデータと登録解除メッセージを使って、GRP1の登録を解除します
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、管理者は、彼または彼女の環境で複数のロードバランサを持つように選択することができます。 SASPは、ロードバランサ一意識別子（LBのUID）を使用して複数のロードバランサを追跡するために、GWMのために用意されています。
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.
oはGWMで、単一障害点を避けるか、いくつかの異なるGWMsの強みを利用して負荷分散戦略を強化するために、管理者は、彼または彼女の環境で複数のGWMsを持つように選択することができます。この場合、ロードバランサは複数GWMsに接続なり、対応する部材と同一のグループを登録します。ロードバランサは、それが選択した任意の方法によって各GWMの勧告を調整するために選択することができる（例えば、統計的組み合わせ平均など）。複数GWMsから重みの調整は、このプロトコルで対処特異的ではない製品です。
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:
SASPは、TCP接続を介して輸送されることが予想されるバイナリストリームです。このプロトコルを確保するためには、プロトコルの実装は、SSL / TLSなどのトランスポートのセキュアモードを使用することが期待されます。セキュリティ上の懸念の周りの議論は以下に記載されています：
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.
セキュリティの問題：新しい（潜在的に悪い）接続のための前の（おそらく有効な）接続を置き換えるためにLB UIDが別のシステムで知られているになった場合、安全でない環境では、他のシステムが接続を開始でき、GWMを引き起こしGWMにメッセージを送信します。
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.
ソリューション：ロードバランサとGWMは、ネットワークの保護された部分である場合、これが問題ではないかもしれません。管理者はこの脆弱性を懸念している場合、彼女は、接続のための認証を提供するために、SSLやTLSを使用する必要があります。接続を保護するためにSSLまたはTLSを使用する場合は、管理者がクライアントとサーバーの証明書を介してサーバとクライアント認証の両方を使用すべきです。 GWMは、信頼するように設定されています機関によって署名されたすべての証明書を信頼します。
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.
ソリューション：GWMとそのメンバーがネットワークの保護された部分である場合、これが問題ではないかもしれません。管理者はこの脆弱性を懸念している場合、彼女はメンバーの接続のための認証を提供するために、SSLやTLSを使用する必要があります。接続を認証するために、SSLやTLSを使用している場合、管理者は、各コンポーネントの信頼できる証明書を確立すると同時に、明示的に各コンポーネントに有効な証明書をインストールする必要があります。これはのみ、信頼できるコンポーネントはGWMへの接続を許可されることを確実にするでしょう。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
Appendix A. Acknowledgements
付録A.謝辞
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.
作者は感謝マークアルバート、デビッドMcCowan、ジョン・フェントン、デレクHuckaby、ダイアン・コリンズ、とステファノ・テスタの貢献を認めています。マーク・アルバート、デビッドMcCowan、ジョン・フェントン、デレクHuckaby、ダイアン・コリンズ、とステファノ・テスタは、シスコシステムズ社によりこの作業のためにサポートされていました
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.
著者はまた、この作品の創造と精製における彼らの努力のためにジョンArwe、デイブBostjancic、ブライアン・カーペンター、ドナDillenberger、GusのKassimis、およびトーマスNarten氏に感謝したいと思います。
Author's Address
著者のアドレス
Alan Bivens IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
アランBivens IBM T.J。ワトソン研究所19スカイラインドライブホーソーン、NY 10532米国
EMail: jbivens@us.ibm.com
メールアドレス：jbivens@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。