Network Working Group P. Lei
Request for Comments: 5351 Cisco Systems, Inc.
Category: Informational L. Ong
Ciena Corporation
M. Tuexen
Muenster Univ. of Applied Sciences
T. Dreibholz
University of Duisburg-Essen
September 2008
An Overview of Reliable Server Pooling Protocols
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite.
（「RSerPool」と略す）信頼性の高いサーバプーリングの努力は、フォールトトレラントで可用性の高いクライアント/サーバアプリケーションを構築するためのサービスとプロトコルのアプリケーションに依存しないセットを提供します。この文書では、信頼できるサーバプーリングスイートのプロトコルとメカニズムの概要を説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Aggregate Server Access Protocol (ASAP) Overview ................6
2.1. Pool Initialization ........................................6
2.2. Pool Entity Registration ...................................6
2.3. Pool Entity Selection ......................................7
2.4. Endpoint Keep-Alive ........................................7
2.5. Failover Services ..........................................7
2.5.1. Cookie Mechanism ....................................7
2.5.2. Business Card Mechanism .............................8
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview ........8
3.1. Initialization .............................................8
3.2. Server Discovery and Home Server Selection .................8
3.3. Failure Detection, Handlespace Audit, and Synchronization ..9
3.4. Server Takeover ............................................9
4. Example Scenarios ...............................................9
4.1. Example Scenario Using RSerPool Resolution Service .........9
4.2. Example Scenario Using RSerPool Session Services ..........11
5. Reference Implementation .......................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. Acknowledgements ...............................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
The Reliable Server Pooling (RSerPool) protocol suite is designed to provide client applications ("pool users") with the ability to select a server (a "pool element") from among a group of servers providing equivalent service (a "pool"). The protocols are currently targeted for Experimental Track.
信頼性の高いサーバーのプーリング（RSerPool）プロトコルスイートは、同等のサービスを提供するサーバのグループ（「プール」）の中から、サーバ（「プール要素」）を選択する能力をクライアントアプリケーション（「プールユーザー」）を提供するように設計されて。プロトコルは現在、実験のトラックを対象としています。
The RSerPool architecture supports high availability and load balancing by enabling a pool user to identify the most appropriate server from the server pool at a given time. The architecture is defined to support a set of basic goals:
RSerPoolアーキテクチャは、ある時点でサーバプールから最も適切なサーバーを識別するために、プールのユーザーを有効にすることで、高可用性と負荷分散をサポートしています。アーキテクチャは、基本的な目標のセットをサポートするために定義されています。
o application-independent protocol mechanisms
Oアプリケーションに依存しないプロトコルメカニズム
o separation of server naming from IP addressing
Oサーバーの分離は、IPアドレス指定から命名します
o use of the end-to-end principle to avoid dependencies on intermediate equipment
O中間機器への依存を避けるために、エンド・ツー・エンド原理の使用
o separation of session availability/failover functionality from the application itself
アプリケーション自体からのセッション可用性/フェイルオーバー機能のO分離
o facilitation of different server selection policies
別のサーバー選択ポリシーのOの円滑化
o facilitation of a set of application-independent failover capabilities
アプリケーションに依存しないフェイルオーバー機能のセットのOの円滑化
o peer-to-peer structure
Oピア・ツー・ピア構造
The basic components of the RSerPool architecture are shown in Figure 1 below:
RSerPoolアーキテクチャの基本的な構成要素は、以下の図1に示されています。
.......................
______ ______ . +-------+ .
/ ENRP \ / ENRP \ . | | .
|Server| <----> |Server|<----------.----->| PE 1 | .
\______/ ENRP \______/ ASAP(1) . | | .
^ . +-------+ .
| . .
| ASAP(2) . Server Pool .
V . .
+-------+ . +-------+ .
| | . | | .
| PU |<---------->. | PE 2 | .
| | PU to PE . | | .
+-------+ . +-------+ .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
Figure 1
図1
A server pool is defined as a set of one or more servers providing the same application functionality. The servers are called Pool Elements (PEs). Multiple PEs in a server pool can be used to provide fault tolerance or load sharing, for example. The PEs register into and de-register out of the pool at an entity called the Endpoint haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate Server Access Protocol (ASAP) [RFC5352] (this association is labeled ASAP(1) in the figure).
サーバー・プールは、同じアプリケーション機能を提供する1台のまたは複数のサーバーのセットとして定義されます。サーバーは、プール要素（PES）と呼ばれています。サーバー・プール内の複数のPEは、例えば、フォールトトレランスや負荷分散を提供するために使用することができます。 PEは、図に集計サーバアクセスプロトコル（できるだけ早く）[RFC5352]（この関連付けは、1（ASAPは標識されている）を使用して、エンドポイントhaNdlespace冗長プロトコル（ENRP）サーバと呼ばに登録エンティティにプールからデレジスタ）。
Each server pool is identified by a unique byte string called the pool handle (PH). The pool handle allows a mapping from the pool to a specific PE located by its IP address (both IPv4 and IPv6 PE addresses are supported) and port number. The pool handle is what is specified by the Pool User (PU) when it attempts to access a server in the pool. To resolve the pool handle to the address necessary to access a PE, the PU consults an ENRP server using ASAP (this association is labeled ASAP(2) in the figure). The space of pool handles is assumed to be a flat space with limited operational scope (see RFC 3237 [RFC3237]). Administration of pool handles is not addressed by the RSerPool protocol documents at this time. The protocols used between the PU and PE are application-specific. It is assumed that the PU and PE are configured to support a common set of protocols for application layer communication, independent of the RSerPool mechanisms.
各サーバー・プールは、プール・ハンドル（PH）と呼ばれるユニークなバイト列によって識別されます。プール・ハンドルは、そのIPアドレス（IPv4とIPv6のPEの両方のアドレスがサポートされている）とポート番号によって位置特定PEにプールからのマッピングを可能にします。プール・ハンドルは、プール内のサーバーにアクセスしようとしたプールのユーザー（PU）で指定されたものです。 PEにアクセスするために必要なアドレスにプールハンドルを解決するために、PU（この関連付けは、図中（2）のASAP標識されている）、ASAP使用ENRPサーバを参照します。プールハンドルのスペースが限られた動作範囲（RFC 3237 [RFC3237]を参照）を有する平坦な空間であると仮定されます。プールハンドルの投与は、この時点でRSerPoolプロトコル文書によって対処されていません。 PUとPE間で使用されるプロトコルは、アプリケーション固有です。 PUとPEはRSerPool機構の独立したアプリケーション層の通信のためのプロトコルの共通セットをサポートするように構成されているものとします。
RSerPool provides a number of tools to aid client migration between servers on server failure: it allows the client to identify alternative servers, either on initial discovery or in real time; it also allows the original server to provide a state cookie to the client that can be forwarded to an alternative server to provide application-specific state information. This information is exchanged between the PE and PU directly, over the association labeled PU to PE in the figure.
RSerPoolは、サーバーの障害にサーバー間でクライアントの移行を支援するツールが多数用意されています。それは、最初の発見にまたはリアルタイムのいずれかで、クライアントは代替サーバーを識別することができます。それはまた、元のサーバーは、アプリケーション固有の状態情報を提供するために、代替サーバへ転送することができ、クライアントに状態クッキーを提供することができます。この情報は、関連付けは、図にPEにPU標識上に、直接PEとPUとの間で交換されます。
It is envisioned that ENRP servers provide a fully distributed and fault-tolerant registry service. They use ENRP [RFC5353] to maintain synchronization of data concerning the pool handle mapping space. For PUs and PEs, the ENRP servers are functionally equal. Due to the synchronization provided by ENRP, they can contact an arbitrary one for registration/de-registration (PE) or PH resolution (PU). An illustration containing 3 ENRP servers is provided in Figure 2 below:
ENRPサーバが完全分散とフォールトトレラントレジストリサービスを提供することが想定されます。彼らは、プール・ハンドルのマッピング空間に関するデータの同期を維持するためにENRP [RFC5353]を使用します。 PUとのPEの場合は、ENRPサーバは、機能的に同等です。起因ENRPによって提供される同期のために、彼らは、登録/登録解除（PE）又はPH解像度（PU）のための任意のものと接触することができます。 3台のENRPサーバを含む図は、以下の図2に提供されます。
______ _____
... / ENRP \ / ENRP \ ...
PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
... ASAP \______/ ENRP \______/ ASAP ...
^ ^
| |
| / ENRP \ |
+---->|Server|<----+
ENRP \______/ ENRP
^
| ASAP
v
...
PEs/PUs
...
Figure 2
図2
The requirements for the Reliable Server Pooling framework are defined in RFC 3237 [RFC3237]. It is worth noting that the requirements on RSerPool in the area of load balancing partially overlap with grid computing/high-performance computing. However, the scope of both areas is completely different: grid and high-performance computing also cover topics like managing different administrative domains, data locking and synchronization, inter-session communication, and resource accounting for powerful computation services, but the intention of RSerPool is simply a lightweight realization of load distribution and session management. In particular, these functionalities are intended to be used on systems with small memory and CPU resources only. Any further functionality is not in the scope of RSerPool and can -- if necessary -- be provided by the application itself.
信頼性の高いサーバプーリングフレームワークのための要件は、RFC 3237 [RFC3237]で定義されています。これは、ロードバランシングの領域でRSerPool上の要件は、部分的に、グリッド・コンピューティング/高性能コンピューティングと重複していることは注目に値します。グリッドとハイパフォーマンスコンピューティングはまた、異なる管理ドメイン、データのロックや同期、インターセッション通信、および強力な計算サービスの会計処理リソースを管理するようなトピックをカバーしますが、RSerPoolの意図は次のとおりです。ただし、両方の領域の範囲は完全に異なっています負荷分散とセッション管理の単純軽量を実現。具体的には、これらの機能は、わずかなメモリとCPUリソースを有するシステムで使用されることが意図されます。更なる機能は、RSerPoolの範囲内にないことができ、 - 必要ならば - アプリケーション自体によって提供されています。
This document provides an overview of the RSerPool protocol suite, specifically the Aggregate Server Access Protocol (ASAP) [RFC5352] and the Endpoint Handlespace Redundancy Protocol (ENRP) [RFC5353]. In addition to the protocol specifications, there is a common parameter format specification [RFC5354] for both protocols, a definition of server selection rules (pool policies) [RFC5356], as well as a security threat analysis [RFC5355].
このドキュメントはRSerPoolプロトコル群、具体的に集計サーバアクセスプロトコル（できるだけ早く）[RFC5352]とエンドポイントHandlespace冗長プロトコル（ENRP）[RFC5353]の概要を提供します。プロトコル仕様に加えて、両方のプロトコルのための共通パラメータ形式仕様[RFC5354]、サーバ選択規則（プールポリシー）[RFC5356]の定義、ならびにセキュリティ脅威分析[RFC5355]があります。
ASAP defines a straightforward set of mechanisms necessary to support the creation and maintenance of pools of redundant servers. These mechanisms include:
できるだけ早く冗長サーバのプールの作成とメンテナンスをサポートするために必要なメカニズムの簡単なセットを定義します。これらのメカニズムは、次のとおりです。
o registration of a new server into a server pool
サーバー・プールに新しいサーバーのO登録
o de-registration of an existing server from a pool
プールから既存のサーバーのOの登録解除
o resolution of a pool handle to a server or list of servers
サーバまたはサーバのリストにプール・ハンドルのO解像度
o liveness detection for servers in a pool
プール内のサーバーのOライブネス検出
o failover mechanisms for handling a server failure
サーバーの障害を処理するためのOのフェールオーバーメカニズム
Pools come into existence when a PE registers the first instance of the pool name with an ENRP server. They disappear when the last PE de-registers. In other words, the starting of the first PE on some machine causes the creation of the pool when the registration reaches the ENRP server.
PEはENRPサーバとプール名の最初のインスタンスを登録するときプールが存在するように来ます。とき、最後のPE登録解除彼らは消えます。換言すれば、いくつかのマシン上の最初のPEの開始は、登録がENRPサーバに到達プールの生成を引き起こします。
It is assumed that information needed for RSerPool, such as the address of an ENRP server to contact, is configured into the PE beforehand. Methods of automating this configuration process are not addressed at this time.
このような連絡するENRPサーバのアドレスとしてRSerPoolに必要な情報が、予めPEに構成されているものとします。この設定プロセスを自動化する方法は、現時点では対処されていません。
A new server joins an existing pool by sending a Registration message via ASAP to an ENRP server, indicating the pool handle of the pool that it wishes to join, a PE identifier for itself (chosen randomly), information about its lifetime in the pool, and what transport protocols and selection policy it supports. The ENRP server that it first contacts is called its Home ENRP server, and maintains a list of subscriptions by the PE as well as performs periodic audits to confirm that the PE is still responsive.
新しいサーバーが参加することを望むプールのプール・ハンドルを示す、ENRPサーバに、ASAPを介して登録メッセージを送信することにより、既存のプール、自体のPE識別子（ランダムに選択される）、プール内のその寿命に関する情報を、参加しますそしてどのようなトランスポートプロトコルと選択ポリシーはサポートしています。その最初の接点はそのホームENRPサーバと呼ばれ、PEがまだ応答することを確認するために、定期的な監査を行い、同様にPEによるサブスクリプションのリストを維持しているENRPサーバ。
Similar procedures are applied to de-register itself from the server pool (or, alternatively, the server may simply let the lifetime that it previously registered with expire, after which it is gracefully removed from the pool).
同様の手順は、サーバープールから自身を登録解除するために適用される（あるいは、サーバは、単にそれが正常プールから除去された後、それが以前に登録されていること寿命が満了させてもよいです）。
When an endpoint wishes to be connected to a server in the pool, it generates an ASAP Handle Resolution message and sends this to its Home ENRP server. The ENRP server resolves the handle based on its knowledge of pool servers and returns a Handle Resolution Response message via ASAP. The response contains a list of the IP addresses of one or more servers in the pool that can be contacted. The process by which the list of servers is created may involve a number of policies for server selection. The RSerPool protocol suite defines a few basic policies and allows the use of external server selection input for more complex policies.
エンドポイントは、プール内のサーバーに接続することを希望する場合は、できるだけ早くハンドル解決メッセージを生成し、そのホームENRPサーバに送信します。 ENRPサーバは、プールサーバのその知識に基づいてハンドルを解決し、できるだけ早く経由してハンドル解決応答メッセージを返します。応答は、接触させることができ、プール内の1台のまたは複数のサーバのIPアドレスのリストが含まれています。サーバのリストが作成されるプロセスは、サーバ選択のためのポリシーの数を含むことができます。 RSerPoolプロトコルスイートは、いくつかの基本的な方針を定義して、より複雑なポリシーのための外部サーバの選択入力を使用することができます。
ENRP servers monitor the status of pool elements using the ASAP Endpoint Keep-Alive message. A PE responds to the ASAP Keep-Alive message with an Endpoint Keep-Alive Ack response.
ENRPサーバは、できるだけ早くエンドポイントキープアライブメッセージを使用して、プール要素の状態を監視します。 PEは、エンドポイントキープアライブACK応答とできるだけ早くキープ・アライブ・メッセージに応答します。
In addition, a PU can notify its Home ENRP server that the PE it used has become unresponsive by sending an ASAP Endpoint Unreachable message to the ENRP server.
また、PUは、それが使用PEはENRPサーバにできるだけ早くエンドポイント到達不能メッセージを送信して応答しなくなってきたそのホームENRPサーバに通知することができます。
While maintaining application-independence, the RSerPool protocol suite provides some simple hooks for supporting failover of an individual session with a pool element. Generally, mechanisms for failover that rely on application state or transaction status cannot be defined without more specific knowledge of the application being supported. However, some simple mechanisms supported by RSerPool allow some level of failover that any application can use.
アプリケーションの独立性を維持しながら、RSerPoolプロトコルスイートは、プール要素と個々のセッションのフェイルオーバーをサポートするためのいくつかの単純なフックを提供します。一般的に、アプリケーションの状態やトランザクションの状態に依存しているフェイルオーバーのためのメカニズムがサポートされているアプリケーションのより具体的な知識がなくても定義することはできません。しかし、RSerPoolでサポートされているいくつかの簡単なメカニズムは、任意のアプリケーションを使用することができ、フェイルオーバーのいくつかのレベルを可能にします。
Cookies may optionally be generated by the ASAP layer and periodically sent from the PE to the PU. The PU only stores the last received cookie. In case of failover, the PU sends this last received cookie to the new PE. This method provides a simple way of state sharing between the PEs. Please note that the old PE should sign the cookie, and the receiving PE should verify that signature. For the PU, the cookie has no structure and is only stored and transmitted to the new PE.
クッキーは、必要に応じて、ASAP層によって生成され、定期的にPU PEから送信されてもよいです。 PUは最後に受信したクッキーを格納します。フェイルオーバーが発生した場合には、PUは、新しいPEには、この最後に受信したクッキーを送信します。この方法では、PE間の状態共有の簡単な方法を提供します。古いPEは、クッキーに署名しなければならない、と受信PEは、その署名を検証する必要があることに注意してください。 PUのために、クッキーはない構造を有していないとのみ記憶され、新たなPEに送信されます。
A PE can send a business card to its peer (PE or PU) containing its pool handle and guidance concerning which other PEs the peer should use for failover. This gives a PE a means of telling a PU what it identifies as the "next best" PE to use in case of failure, which may be based on pool considerations, such as load balancing, or user considerations, such as PEs that have the most up-to-date state information.
PEは、ピアは、フェイルオーバーのために使用すべき他のPEに関するそのプール・ハンドルとガイダンスを含むそのピア（PEまたはPU）に名刺を送信することができます。これは、PEにそれは、持っているのPEなどの負荷分散、またはユーザーの考慮事項として、プールの考慮、に基づくことができる障害が発生した場合に使用するための「次善」PE、として識別するものPUを伝えるための手段を提供します最新の状態情報。
A set of server pools, which is denoted as a handlespace, is managed by ENRP servers. Pools are not valid in the whole Internet but only in smaller domains, called the operational scope. The ENRP servers use the ENRP protocol in order to maintain a distributed, fault-tolerant, real-time registry service. ENRP servers communicate with each other for information exchange, such as pool membership changes, handlespace data synchronization, etc.
handlespaceと表記されたサーバー・プールのセットは、ENRPサーバによって管理されています。プールは、インターネット全体では有効ではありませんが、唯一の小さなドメインで、業務範囲と呼ばれます。 ENRPサーバは、分散、フォールトトレラント、リアルタイムレジストリサービスを維持するために、ENRPプロトコルを使用します。 ENRPサーバは等プールメンバシップの変更、handlespaceデータ同期などの情報交換のために相互に通信します
Each ENRP server initially generates a 32-bit server ID that it uses in subsequent messaging and remains unchanged over the lifetime of the server. It then attempts to learn all of the other ENRP servers within the scope of the server pool, either by using a pre-defined Mentor server or by sending out Presence messages on a well-known multicast channel in order to determine other ENRP servers from the responses and select one as Mentor. A Mentor can be any peer ENRP server. The most current handlespace data is requested by Handle Table Requests from the Mentor. The received answer in the form of Handle Table Response messages is unpacked into the local database. After that, the ENRP server is ready to provide ENRP services.
各ENRPサーバは、最初に、それがその後のメッセージングに使用し、サーバの寿命にわたって変化しないままで、32ビットのサーバIDを生成します。次にから他のENRPサーバを決定するために、サーバー・プールの範囲内で、いずれかの事前定義されたメンター・サーバを使用するか、順番によく知られているマルチキャストチャネル上プレゼンスメッセージを送信することによって他のENRPサーバの全てを学習することを試みますメンターとしての応答を選択1。メンター・グラフィックスは、任意のピアENRPサーバにすることができます。最新のhandlespaceデータは、メンターからハンドルテーブル要求によって要求されています。ハンドルテーブルの応答メッセージの形で受け取った答えは、ローカルデータベースにアンパックされます。その後、ENRPサーバはENRPサービスを提供する準備ができています。
PEs can now register their presence with the newly functioning ENRP server by using ASAP messages. They discover the new ENRP server after the server sends out an ASAP Server Announce message on the well-known ASAP multicast channel. PEs only have to register with one ENRP server, as other ENRP servers supporting the pool will synchronize their knowledge about pool elements using the ENRP protocol.
PEは今できるだけ早くメッセージを使用することにより、新たに機能してENRPサーバでその存在を登録することができます。サーバはできるだけ早くServerは、よく知られているできるだけ早くマルチキャストチャネル上でメッセージをアナウンス発送後彼らは、新しいENRPサーバを発見します。 PEはプールだけをサポートしている他のENRPサーバはENRPプロトコルを使用して、プール要素についての知識を同期するように、1台のENRPサーバに登録する必要があります。
The PE may have a configured list of ENRP servers to talk to, in the form of a list of IP addresses, in which case it will start to set up associations with some number of them and assign the first one that responds to it as its Home ENRP server.
PEは、IPアドレスのリストの形で、と話をした場合には、それはそれらのいくつかの数との関連付けを設定するために開始し、そのとしてそれに反応する最初のものを割り当てますENRPサーバの構成されたリストを持っていることホームENRPサーバ。
Alternatively, it can listen on the multicast channel for a set period, and when it hears an ENRP server, start an association. The first server it gets up can then become its Home ENRP server.
また、それは、設定された期間のためのマルチキャストチャネル上で聞くことができ、そしてそれはENRPサーバを聞いたときに、関連付けを開始します。それが立ち上がる最初のサーバがそのホームENRPサーバになることができます。
ENRP servers send ENRP Presence messages to all of their peers in order to show their liveness. These Presence messages also include a checksum computed over all PE identities for which the ENRP server is in the role of a Home ENRP server. Each ENRP server maintains an up-to-date list of its peers and can also compute the checksum expected from a certain peer, according to its local handlespace database. By comparing the expected sum and the sum reported by a peer (denoted as handlespace audit), an inconsistency can be detected. In such a case, the handlespace -- restricted to the PEs owned by that peer -- can be requested for synchronization, analogously to Section 3.2.
ENRPサーバは、彼らの生存性を示すために仲間の全員にENRPプレゼンスメッセージを送信します。これらのプレゼンスメッセージもENRPサーバは、ホームENRPサーバの役割であるため、すべてのPEのアイデンティティにわたって計算チェックサムを含んでいます。各ENRPサーバは、そのローカルhandlespaceデータベースによると、そのピアの最新のリストを維持し、また、特定のピアから期待されるチェックサムを計算することができます。予想和ピア（handlespace監査として示される）によって報告された和を比較することによって、矛盾を検出することができます。このような場合には、handlespace - そのピアが所有するPEに限定は - 類似セクション3.2に、同期のために要求することができます。
If the unresponsiveness of an ENRP server is detected, the remaining ENRP servers negotiate which other server takes over the Home ENRP role for the PEs of the failed peer. After reaching a consensus on the takeover, the ENRP server taking over these PEs sends a notification to its peers (via ENRP) as well as to the PEs taken over (via ASAP).
ENRPサーバの無応答が検出された場合、残りのENRPサーバは他のサーバに障害が発生したピアのPEのホームENRPの役割を引き継ぐ交渉します。買収について合意に達した後、これらのPEを引き継ぐENRPサーバは、ピア（ENRPを介して）、ならびに（ASAPを介して）引き継がPEに通知を送信します。
RSerPool can be used in a 'standalone' manner, where the application uses RSerPool to determine the address of a primary server in the pool, and then interacts directly with that server without further use of RSerPool services. If the initial server fails, the application uses RSerPool again to find the next server in the pool.
RSerPoolは、アプリケーションがプール内のプライマリ・サーバのアドレスを決定するRSerPoolを使用し、次いでRSerPoolサービスのさらなる使用せずに、そのサーバと直接対話する「スタンドアロン」方法で使用することができます。最初のサーバーに障害が発生した場合、アプリケーションは、プール内の次のサーバーを見つけるために、再びRSerPoolを使用しています。
For pool user ("client") applications, if an ASAP implementation is available on the client system, there are typically only three modifications required to the application source code:
ASAPの実装では、クライアントシステム上で利用可能である場合は、プールのユーザ（「クライアント」）アプリケーションのために、アプリケーションのソースコードに必要な3つだけの修飾は、典型的には存在します。
1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle.
代わりに第一、第二、第三のサーバなどのホスト名を指定するの1.、アプリケーションのユーザーは、プール・ハンドルを指定します。
2. Instead of using a DNS-based service (e.g., the Unix library function getaddrinfo()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive provisionally named GETPRIMARYSERVER that takes a pool handle as input, and returns the IP address of the primary server. The application then uses that IP address just as it would have used the IP address returned by the DNS in the previous scenario.
代わりに、IPアドレスにホスト名から変換するために、DNSベースのサービス（例えば、Unixのライブラリ関数はgetaddrinfo（））を使用しての2、アプリケーションは、入力としてプール・ハンドルを取りRSerPoolサービスプリミティブ暫定という名前GETPRIMARYSERVERを起動しますプライマリサーバのIPアドレスを返します。アプリケーションは、それは前のシナリオでDNSによって返されたIPアドレスを使用していたのと同じようにそのIPアドレスを使用しています。
3. Without the use of additional RSerPool services, failure detection and failover procedures must be designed into each application. However, when failure is detected on the primary server, instead of invoking DNS translation again on the hostname of a secondary server, the application invokes a service primitive provisionally named GETNEXTSERVER, which performs two functions in a single operation.
追加RSerPoolサービス、障害検出およびフェイルオーバー手順を使用しない3.各アプリケーションに設計する必要があります。障害がプライマリ・サーバ上で検出された場合しかし、代わりに、セカンダリ・サーバのホスト名に再度DNS変換を呼び出す、アプリケーションは、単一の操作で2つの機能を実行するサービスプリミティブ仮命名GETNEXTSERVERを呼び出します。
1. First, it indicates to the RSerPool layer the failure of the
server returned by a previous GETPRIMARYSERVER or
GETNEXTSERVER call.
2. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time (e.g., set of available pool elements, pool element policy in effect for the pool, etc.).
2.第二に、それは（現時点でRSerPool層に利用可能な最善の情報に基づいて、接触されるべき次のサーバのIPアドレスを提供し、例えば、プールの効果で利用可能なプール要素、プール要素ポリシーのセット、等。）。
Note: at the time of this document, a full API for use with RSerPool protocols has not yet been defined.
注意：この文書の時点で、RSerPoolプロトコルで使用するための完全なAPIはまだ定義されていません。
For pool element ("server") applications where an ASAP implementation is available, two changes are required to the application source code:
プール要素（「サーバ」）ASAPの実装が利用可能であるアプリケーションのために、2つの変更がアプリケーションのソースコードに必要とされます。
1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy (or policies).
1.サーバが適切なプール・ハンドルを使用してサーバー・プールに自分自身を追加するには、起動時にプリミティブREGISTERサービスを呼び出す必要があります。これはまた、アドレス（ES）プロトコルまたはマッピングID、ポート（マッピングすることにより必要な場合）が含まれ、およびポリシー（又はポリシー）をプールします。
2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down.
2.サーバーがシャットダウン時にサーバプールから自分自身を削除するプリミティブDEREGISTERサービスを呼び出す必要があります。
When using these RSerPool services, RSerPool provides benefits that are limited (as compared to utilizing all services), but nevertheless quite useful as compared to not using RSerPool at all. First, the client user need only supply a single string, i.e., the pool handle, rather than a list of servers. Second, the decision as to which server is to be used can be determined dynamically by the server selection mechanism (i.e., a "pool policy" performed by ASAP; see ASAP [RFC5352]). Finally, when failures occur, these are reported to the pool via signaling present in ASAP [RFC5352] and ENRP [RFC5353]; other clients will eventually know (once this failure is confirmed by other elements of the RSerPool architecture) that this server has failed.
これらRSerPoolサービスを使用する場合はRSerPoolを全く使用していないと比較して、RSerPoolは（全てのサービスを利用することに比較して）限定されている利点が、それにもかかわらず、非常に便利を提供します。まず、クライアントのユーザーにのみ、すなわち単一の文字列、プール・ハンドルではなく、サーバーのリストを提供する必要が。第二に、サーバが使用されるためにどのように決定がサーバ選択機構によって動的に決定することができる（即ち、できるだけ早くすることにより実行される「プールポリシー」は、できるだけ早く参照[RFC5352]）。障害が発生したときに最後に、これらは、ASAP [RFC5352]とENRP [RFC5353]に存在するシグナリングを介してプールに報告されます。 （この障害は、RSerPoolアーキテクチャの他の要素によって確認されれば）他のクライアントは最終的に、このサーバーに障害が発生したことを知っているだろう。
When the full suite of RSerPool services is used, all communication between the pool user and the pool element is mediated by the RSerPool framework, including session establishment and teardown, and the sending and receiving of data. Accordingly, it is necessary to modify the application to use the service primitives (i.e., the API) provided by RSerPool, rather than the transport layer primitives provided by TCP, Stream Control Transmission Protocol (SCTP), or whatever transport protocol is being used.
RSerPoolサービスの完全なスイートを使用した場合、プールのユーザとプール要素との間のすべての通信は、セッションの確立およびティアダウンを含む、RSerPoolフレームワークによって媒介され、データの送受信。したがって、どのようなトランスポートプロトコルを使用しているTCP、ストリーム制御伝送プロトコル（SCTP）、またはによって提供RSerPoolによって提供されるサービスプリミティブ（即ち、API）ではなくトランスポート層プリミティブを使用するようにアプリケーションを修正する必要があります。
As in the previous case, sessions (rather than connections or associations) are established, and the destination endpoint is specified as a pool handle rather than as a list of IP addresses with a port number. However, failover from one pool element to another is fully automatic, and can be transparent to the application (so long as the application has saved enough state in a state cookie):
前の場合と同様に、（むしろ接続または関連付けより）セッションが確立され、宛先エンドポイントは、プール・ハンドルとしてではなく、ポート番号とIPアドレスのリストとして指定されます。しかし、1つのプール要素から別のフェイルオーバーは完全に自動化され、そして（アプリケーション状態クッキーに十分な状態を保存している限り）アプリケーションに透明にすることができます。
The RSerPool framework control channel provides maintenance functions to keep pool element lists, policies, etc. current.
RSerPoolフレームワークの制御チャネルは、現在など、ポリシー、プール要素のリストを維持するためのメンテナンス機能を提供します。
Since the application data (e.g., data channel) is managed by the RSerPool framework, unsent data (data not yet submitted by RSerPool to the underlying transport protocol) is automatically redirected to the newly selected pool element upon failover. If the underlying transport layer supports retrieval of unsent data (as in SCTP), retrieved unsent data can also be automatically re-sent to the newly selected pool element.
アプリケーションデータ（例えば、データチャネル）RSerPoolフレームワーク、未送信データ（データがまだ基礎となるトランスポートプロトコルにRSerPoolによって提出されていない）によって管理されているので、自動的にフェイルオーバー時に、新たに選択されたプール要素にリダイレクトされます。基礎となるトランスポート層（SCTPのように）未送信データの検索をサポートしている場合、検索された未送信データも自動的に新たに選択されたプール要素に再送信することができます。
An application server (pool element) can provide a state cookie (described in Section 2.5.1) that is automatically passed on to another pool element (by the ASAP layer at the pool user) in the event of a failover. This state cookie can be used to assist the application at the new pool element in recreating whatever state is needed to continue a session or transaction that was interrupted by a failure in the communication between a pool user and the original pool element.
アプリケーション・サーバー（プール要素）が自動的にフェイルオーバーが発生した場合に（プールユーザにできるだけ早く層によって）別のプール要素に渡される（セクション2.5.1で説明した）状態クッキーを提供することができます。この状態クッキーは、プール利用者と、元のプール要素との間の通信に障害によって中断されたセッションまたはトランザクションを継続するために必要とされるどんな状態作り直すに新しいプール要素でアプリケーションを支援するために使用することができます。
The application client (pool user) can provide a callback function that is invoked on the pool user side in the case of a failover. This callback function can execute any application-specific failover code, such as generating a special message (or sequence of messages) that helps the new pool element construct any state needed to continue an in-process session.
アプリケーションクライアント（プールユーザ）は、フェイルオーバーの場合には、プールユーザ側で呼び出されるコールバック関数を提供することができます。このコールバック関数は、新しいプール要素がインプロセスセッションを継続するために必要な状態を構築するのに役立つ特別なメッセージ（またはメッセージのシーケンス）を生成するように、任意のアプリケーション固有のフェイルオーバー・コードを実行することができます。
Suppose in a particular peer-to-peer application, PU A is communicating with PE B, and it so happens that PU A is also a PE in pool X. PU A can pass a "business card" to PE B identifying it as a member of pool X. In the event of a failure at A, or a failure in the communication link between A and B, PE B can use the information in the business card to contact an equivalent PE to PU A from pool X.
特定のピア・ツー・ピア・アプリケーションに想定、PU AはPE Bと通信して、それがそうPU Aはまた、プールX. PU AにおけるPEであることが起こるように、それを識別PE Bに「名刺」を渡すことができAに障害が発生した場合プールXのメンバー、またはAとBとの間の通信リンクの障害、PE Bは、プールXからPU Aと同等のPEに接触するように名刺の情報を使用することができ
Additionally, if the application at PU A is aware of some particular PEs of pool X that would be preferred for B to contact in the event that A becomes unreachable from B, PU A can provide that list to the ASAP layer, and it will be included in A's business card (see Section 2.5.2).
PU Aにおけるアプリケーションは、AがBから到達不能になった場合に接触するようにBのために好ましいであろうプールXのいくつかの特定のPEを認識している場合に加えて、PU Aはできるだけ早く層にそのリストを提供することができ、それがあろうAの名刺に含まれ（第2.5.2項を参照してください）。
A reference implementation of RSerPool is available at [RSerPoolPage] and described in [Dre2006].
RSerPoolのリファレンス実装は、[RSerPoolPage]で利用可能と[Dre2006]に記載されています。
This document does not identify security requirements beyond those already documented in the ENRP and ASAP protocol specifications. A security threat analysis of RSerPool is provided in THREATS [RFC5355].
この文書では、これらのすでにできるだけ早くENRPに文書化され、プロトコル仕様を超えたセキュリティ要件を識別しません。 RSerPoolのセキュリティ脅威分析は、脅威[RFC5355]で提供されています。
This document does not require additional IANA actions beyond those already identified in the ENRP [RFC5353] and ASAP [RFC5352] protocol specifications.
この文書では、すでにENRPできるだけ早く[RFC5353]と[RFC5352]プロトコル仕様で同定されたもの以外の追加IANAのアクションを必要としません。
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall Stewart, Scott Bradner, and many others for their invaluable comments.
作者は彼らの貴重なコメントをモーリーンスティルマン、Qiaobing謝、ランドール・スチュワート、スコット・ブラッドナー、および多くの他に感謝したいです。
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002.
[RFC3237] Tuexen、M.、謝、Q.、スチュワート、R.、ショア、M.、オング、L.、Loughney、J.、およびM.スティルマン、 "信頼できるサーバプーリングのための要件"、RFC 3237年1月2002。
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5352]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（至急）"、RFC 5352、2008年9月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5353]謝、Q.、スチュワート、R.、スティルマン、M.、Tuexen、M.、およびA.シルバー、 "エンドポイントHandlespace冗長プロトコル（ENRP）"、RFC 5353、2008年9月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（ASAP）から印刷して、エンドポイントHandlespace冗長プロトコル（ENRP）パラメータ"、RFC 5354、2008年9月。
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.
[RFC5355]スティルマンが、M.編、ゴパル、R.、ガットマン、E.、ホールドレッジ、M.、およびS. Sengodanは、 "脅威脅威に応答して信頼できるサーバプーリング（RSerPool）とセキュリティ要件によって導入されました" 、RFC 5355、2008年9月。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
[RFC5356] Dreibholz、T.およびM. Tuexen、 "信頼できるサーバプーリング方針"、RFC 5356、2008年9月。
[RSerPoolPage] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", <http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>.
[RSerPoolPage] Dreibholz、T.、 "トーマス・DreibholzのRSerPoolページ"、<http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>。
[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture", Ph.D. Thesis University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, March 2007, <http://duepublico.uni-duisburg-essen.de/ servlets/DerivateServlet/Derivate-16326/ Dre2006-final.pdf>.
[Dre2006] Dreibholz、T.、「信頼できるサーバプーリング - 評価、最適化と新規IETFアーキテクチャの拡張」、博士デュイスブルク・エッセンの論文大学、経済学部、コンピュータ科学とビジネス情報システム、2007年3月のための研究所、<http://duepublico.uni-duisburg-essen.de/サーブレット/ DerivateServlet /誘導体-16326 / Dre2006決勝。 PDF>。
Authors' Addresses
著者のアドレス
Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US
ピーター・レイシスコシステムズ社955 Happfield博士アーリントンハイツ、イリノイ州60004米国
Phone: +1 773 695-8201 EMail: peterlei@cisco.com
電話：+1 773 695-8201 Eメール：peterlei@cisco.com
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 US
リンドン・オングCienaの株式会社私書箱308クパチーノ、CA 95015米国
EMail: Lyong@Ciena.com
メールアドレス：Lyong@Ciena.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルTuexenミュンスター大学。応用科学Stegerwaldstrの。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Thomas Dreibholz University of Duisburg-Essen, Institute for Experimental Mathematics Ellernstrasse 29 45326 Essen, Nordrhein-Westfalen Germany
デュイスブルク・エッセンのトーマスDreibholz大学、実験数学研究所Ellernstraße29 45326エッセン、ノルトラインヴェストファーレン州ドイツ
Phone: +49 201 183-7637 Fax: +49 201 183-7673 EMail: dreibh@iem.uni-due.de URI: http://www.iem.uni-due.de/~dreibh/
電話：+49 201 183-7637ファックス：+49 201 183-7673 Eメール：URIをdreibh@iem.uni-due.de：http://www.iem.uni-due.de/~dreibh/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。