Network Working Group M. Tuexen
Request for Comments: 3237 Siemens AG
Category: Informational Q. Xie
Motorola
R. Stewart
M. Shore
Cisco
L. Ong
Ciena
J. Loughney
M. Stillman
Nokia
January 2002
Requirements for Reliable Server Pooling
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document defines a basic set of requirements for reliable server pooling.
この文書では、信頼性の高いサーバー・プーリングの要件の基本セットを定義します。
The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.
プーリング信頼性の高いサーバ（RSerPool）の目標は、サーバー・プールに信頼性の高いアプリケーションをサポートするサーバー・プールの管理・運営のための、およびクライアントアクセスメカニズムのためのアーキテクチャとプロトコルを開発することです。
The Internet is always on. Many users expect services to be always available; many businesses depend upon connectivity 24 hours a day, 7 days a week, 365 days a year. In order to fulfill this level of performance, many proprietary solutions and operating system dependent solutions have been developed to provide highly reliable and highly available servers.
インターネットは常にオンです。多くのユーザーは、サービスが常に利用可能であることを期待します。多くの企業は、接続時に1日24時間、週7日、1年365日を依存しています。このレベルの性能を満たすために、多くの独自のソリューションとオペレーティングシステムに依存するソリューションは、高い信頼性と可用性の高いサーバを提供するために開発されました。
This document defines requirements for an architecture and protocols enabling pooling of servers to support high reliability and availability for applications.
この文書では、アーキテクチャの要件とアプリケーションのための高い信頼性と可用性をサポートするために、サーバのプーリングを可能にするプロトコルを定義します。
The range of applications that can benefit from reliable server pooling includes both mobile and real-time applications. Reliable server pooling mechanisms will be designed to support functionality for flexible pooling such as registration and deregistration, and load balancing of traffic across the server pool. Mechanisms will need to balance the needs of scalability, overhead traffic and response time to changes in pool status, as discussed below.
信頼できるサーバプーリングの恩恵を受けることができるアプリケーションの範囲は、モバイルおよびリアルタイム・アプリケーションの両方を含んでいます。信頼性の高いサーバー・プーリング・メカニズムは、そのような登録および登録解除、およびサーバー・プール間でトラフィックのロードバランシングなどの柔軟なプーリングの機能をサポートするように設計されます。メカニズムは、以下に説明するように、プールの状態の変化にスケーラビリティ、オーバーヘッドトラフィックと応答時間のニーズのバランスを取る必要があります。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
Operation scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols.
動作範囲：信頼できるサーバプーリングプロトコルの特定のインスタンスによってプールユーザーに表示ネットワークの一部。
Pool (or server pool): A collection of servers providing the same application functionality.
プール（またはサーバプール）：同じアプリケーション機能を提供するサーバの集合。
Pool handle (or pool name): A logical pointer to a pool. Each server pool will be identifiable in the operation scope of the system by a unique pool handle or "name".
プールハンドル（またはプール名）：プールへの論理ポインタ。各サーバー・プールには、独自のプール・ハンドルまたは「名前」によってシステムの動作範囲内に識別されます。
Pool element: A server entity having registered to a pool.
プール要素：プールに登録されたサーバエンティティ。
Pool user: A server pool user.
プールのユーザー：サーバー・プールのユーザー。
Pool element handle (or endpoint handle): A logical pointer to a particular pool element in a pool, consisting of the name of the pool and one or more destination transport addresses for the pool element.
プール要素ハンドル（またはエンドポイントハンドル）：プール内の特定のプール要素への論理ポインタ、プール素子用プールおよび1つ以上の宛先トランスポートアドレス名からなります。
Name space: A cohesive structure of pool names and relations that may be queried by an internal or external agent.
名前空間：内部または外部エージェントによって照会することができるプール名と関係の凝集構造。
Name server: Entity which is responsible for managing and maintaining the name space within the RSerPool operation scope.
サーバーの名前：エンティティRSerPoolの操作範囲内で名前空間を管理し、維持する責任があります。
RSerPool: The architecture and protocols for reliable server pooling.
RSerPool：信頼性の高いサーバー・プーリングのためのアーキテクチャとプロトコル。
PE: Pool element
以下の場合：プール要素
PU: Pool user
PU：プールユーザー
SCTP: Stream Control Transmission Protocol
SCTP：ストリーム制御伝送プロトコル
TCP: Transmission Control Protocol
TCP：伝送制御プロトコル
The solution must allow itself to be implemented and deployed in such a way that there is no single point of failure in the system.
溶液は、それ自体が実装され、システムの故障の単一点が存在しないような方法で展開することを可能にしなければなりません。
The RSerPool architecture must be able to detect failure of pool elements and name servers supporting the pool, and support failover to available alternate resources.
RSerPoolアーキテクチャは、プール要素とプールをサポートするネームサーバの障害を検出し、利用可能な代替リソースへのフェイルオーバーをサポートすることができなければなりません。
The general architecture should support flexibility of the communication model between pool users and pool elements, especially allowing for a peer-to-peer relationship to support some applications.
一般的なアーキテクチャは、特に、いくつかのアプリケーションをサポートするピア・ツー・ピア関係を可能にする、プールユーザーおよびプール要素との間の通信モデルの柔軟性をサポートしなければなりません。
It should be possible to use the protocol stack in small devices, like handheld wireless devices. The solution must scale to devices with a differing range of processing power.
ハンドヘルドの無線機器と同様に、小型デバイスでプロトコルスタックを使用することが可能でなければなりません。解決策は、処理能力の異なる範囲を持つデバイスに拡張しなければなりません。
The protocols used for the pool handling should not cause network congestion. This means that it should not generate heavy traffic, even in case of failures, and has to use flow control and congestion avoidance algorithms which are interoperable with currently deployed techniques, especially the flow control of TCP [RFC793] and SCTP [RFC2960] and must be compliant with [RFC2914].
プールの処理のために使用されるプロトコルは、ネットワークの輻輳が発生することはありません。これは、それも障害が発生した場合には、大量のトラフィックを生成してはならないことを意味し、現在展開技術との相互運用が可能ですフロー制御と輻輳回避アルゴリズム、TCP [RFC793]とSCTP [RFC2960]の、特にフロー制御を使用していなければならず、 [RFC2914]に準拠します。
The architecture should not rely on multicast capabilities of the underlying layer. Nevertheless, it can make use of it if multicast capabilities are available.
アーキテクチャは、下地層のマルチキャスト機能に頼るべきではありません。マルチキャスト機能が利用可能な場合にもかかわらず、それを利用することができます。
Network failures have to be handled and concealed from the application layer as much as possible by the transport protocol. This means that the underlying transport protocol must provide a strong network failure handling capability on top of an acknowledged error-free non-duplicated data delivery service. The failure of a network element must be handled by the transport protocol in such a way that the timing requirements are still fulfilled.
ネットワーク障害は、処理され、トランスポートプロトコルによって可能な限り、アプリケーション層から隠蔽されなければなりません。これは、基礎となるトランスポートプロトコルが承認されたエラーのない非重複データ配信サービスの上に強力なネットワーク障害処理能力を提供しなければならないことを意味します。ネットワーク構成要素の故障は、タイミング要件がまだ満たされるように、トランスポートプロトコルによって処理されなければなりません。
The architecture should allow for ease of interaction between pools and non-RSerPool-aware clients. However, it is assumed that only RSerPool-aware participants will receive maximum timing and notification benefits the architecture offers.
アーキテクチャは、プールと非RSerPool対応クライアントの間の相互作用を容易にするために許可する必要があります。しかし、それだけでRSerPool対応の参加者が最大のタイミングを受けることが想定されると通知がアーキテクチャの提供に利益をもたらします。
Another important requirement is that servers should be able to register to (become PEs) and deregister from a server pool transparently without an interruption in service. This means that after a PE has deregistered, it will continue to serve PUs which started their connection before the deregistration of the PE. New connections will be directed towards an alternative PE.
もう一つの重要な要件は、サーバが透過的にサービスを中断せずに（PESになる）に登録し、サーバプールから登録解除することができるはずということです。これは、PEが登録解除された後、それはPEの登録解除前に、接続を開始したのPUにサービスを提供し続けることを意味します。新しい接続は、代替PEの方に指示されます。
Servers should be able to register in multiple server pools which may belong to different namespaces.
サーバーは、異なる名前空間に属していてもよい複数のサーバー・プールに登録することができるはずです。
Server pools are identified by pool handles. These pool handles are only valid inside the operation scope. Interoperability between different namespaces has to be provided by other mechanisms.
サーバー・プールはプールハンドルによって識別されます。これらのプールハンドルが操作範囲の内側にのみ有効です。異なる名前空間の間での相互運用性は、他のメカニズムによって提供されなければなりません。
The name resolution should not result in a pool element which is not operational. This might be important for fulfilling the timing requirements described below.
名前解決が動作していないプール要素になるべきではありません。これは、後述のタイミング要件を満たすために重要であるかもしれません。
The RSerPool mechanisms must be able to support different server selection mechanisms. These are called server pool policies.
RSerPoolメカニズムは異なるサーバ選択メカニズムをサポートすることができなければなりません。これらは、サーバプールポリシーと呼ばれています。
Examples of server pool policies are:
サーバプールポリシーの例は以下のとおりです。
- Round Robin
- ラウンドロビン
- Least used
- 最小使用
- Most used
- 最も使用
The set of supported policies must be extensible in the sense that new policies can be added as required. Non-stochastic and stochastic policies can be supported.
サポートされるポリシーのセットは、必要に応じて新しいポリシーを追加することができるという意味で拡張可能でなければなりません。非確率論的および確率的政策をサポートすることができます。
There must be a way for the client to provide operational status feedback to the name server about the pool elements.
クライアントがプールの要素についてのネームサーバへの動作状態のフィードバックを提供するための方法があるに違いありません。
The name server protocols must be extensible to allow more refined server selection mechanisms to be implemented as they are developed in the future.
ネームサーバプロトコルは、それらが将来開発されているように、より洗練されたサーバ選択メカニズムを実装することができるように拡張可能でなければなりません。
For some applications it is important that a client repeatedly connects to the same server in a pool if it is possible, i.e., if that server is still alive. This feature should be supported through the use of pool element handles.
一部のアプリケーションでは可能である場合、そのサーバーがまだ生きている場合、クライアントは繰り返し、すなわち、プール内の同じサーバーに接続することが重要です。この機能は、プール要素ハンドルを使用してサポートする必要があります。
Handling of name resolution must be fast to support real-time applications. Moreover, the name space should reflect pool membership changes to the client application as rapidly as possible, i.e., not waiting until the client application next reconnects.
名前解決の取り扱いは、リアルタイム・アプリケーションをサポートするために、高速でなければなりません。また、名前空間は、すなわち、クライアントアプリケーションの次の再接続するまで待機していない、可能な限り迅速にクライアント・アプリケーションにプールメンバーシップの変更を反映する必要があります。
The architecture should support control of timing parameters based on specific needs, e.g., of an application or implementation.
アーキテクチャは、アプリケーションまたは実装の特定のニーズ、例えば、に基づいてタイミング・パラメータの制御をサポートしなければなりません。
In order to support more rapid and accurate response, the requirements on scalability of the mechanism are limited to server pools consisting of a suitably large but not Internet-wide number of elements, as necessary to support bounded delay in handling real-time name resolution.
より迅速かつ正確な応答をサポートするために、メカニズムのスケーラビリティの要件は、リアルタイムの名前解決を処理する際の有界遅延をサポートするために、必要に応じて要素の適切な大きさではなく、インターネット全体の数からなるサーバー・プールに制限されています。
Also, there is no requirement to support hierarchical organization of name servers for scalability. Instead, it is envisioned that the set of name servers supporting a particular pool is organized as a flat space of equivalent servers. Accordingly, the impact of relatively frequent updates to ensure accurate reflection of the status of pool elements is limited to the set of name servers supporting a specific pool.
また、スケーラビリティのためのネームサーバの階層的な組織をサポートする必要はありません。代わりに、特定のプールをサポートしているネームサーバーのセットが同等のサーバーのフラットなスペースとして編成されていることが想定されます。したがって、プール要素のステータスを正確に反映を確保するため、比較的頻繁な更新の影響は、特定のプールをサポートしているネームサーバのセットに制限されています。
The RSerPool architecture should not require a limitation on the number of server pools or on the number of pool users, although the size of an individual pool may be limited by timing requirements as defined above.
上記で定義され、個々のプールのサイズは、タイミング要件によって制限されてもよいRSerPoolアーキテクチャは、サーバー・プールの数にまたはプールユーザの数に制限を必要とすべきではありません。
- The scaling characteristics of the security architecture should be compatible with those given previously.
- セキュリティアーキテクチャのスケーリング特性は以前に与えられたものと互換性があるべきです。
- The security architecture should support hosts having a wide range of processing powers.
- セキュリティアーキテクチャは、処理能力の広い範囲を有するホストをサポートしなければなりません。
- It must not be possible for an attacker to falsely register as a pool element with the name server either by masquerading as another pool element or by registering in violation of local authorization policy.
- 攻撃者は別のプール要素としてマスカレードするか、またはローカル承認ポリシーに違反して登録することにより、いずれかのネームサーバとプールの要素として登録偽っすることが可能であってはなりません。
- It must not be possible for an attacker to deregister a server which has successfully registered with the name server.
- 攻撃者がネームサーバに登録されているサーバーの登録を解除することが可能であってはなりません。
- It must not be possible for an attacker to spoof the response to a query to the name server
- 攻撃者がネームサーバへのクエリに対する応答を偽装することが可能であってはなりません
- It must be possible to protect the privacy of queries to the name server and responses to those queries from the name server.
- ネームサーバからこれらのクエリにネームサーバへのクエリと応答のプライバシーを保護することが可能でなければなりません。
- Communication among name servers must be afforded the same protections as communication between clients and name servers.
- ネームサーバ間の通信は、クライアントとネームサーバ間の通信と同様の保護を与えなければなりません。
The security context of an application is a subset of the overall context, and context or state sharing is explicitly out-of-scope for RSerPool. Because RSerPool does introduce new security vulnerabilities to existing applications application designers employing RSerPool should be aware of problems inherent in failing over secured connections. Security services necessarily retain some state and this state may have to be moved or re-established. Examples of this state include authentication or retained ciphertext for ciphers operating in cipher block chaining (CBC) or cipher feedback (CFB) mode. These problems must be addressed by the application or by future work on RSerPool.
アプリケーションのセキュリティコンテキストは、全体的な文脈のサブセットであり、コンテキストまたは状態の共有は、アウト範囲RSerPoolのために明示的です。 RSerPoolはRSerPoolを採用し、既存のアプリケーションのアプリケーションの設計者に、新たなセキュリティの脆弱性を導入しないため安全な接続を介して失敗に固有の問題に注意する必要があります。セキュリティサービスは、必ずしもいくつかの状態を保持し、この状態では移動または再確立する必要があります。この状態の例には、認証や暗号ブロック連鎖（CBC）または暗号フィードバック（CFB）モードで動作する暗号の保持暗号文を含みます。これらの問題は、アプリケーションまたはRSerPoolの今後の作業によって対処されなければなりません。
Security issues are discussed in section 2.13.
セキュリティ問題はセクション2.13で説明されています。
The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot Lear, Christopher Ross, Werner Vogels and many others for their invaluable comments and suggestions.
作者は彼らの貴重なコメントと提案のためにバーナードAboba、マット・ホールドレッジ、エリオット・リア、クリストファー・ロス、ワーナー・ボーゲルズおよび多くの他に感謝したいと思います。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル（FTP）"、STD 9、RFC 959、1985年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[RFC2719]オング、L.、Rytina、I.、ガルシア、M.、Schwarzbauer、H.、Coene、L.、リン、H.、ユハス、I.、ホールドレッジ、M.とC.シャープ、「フレームワークのアーキテクチャシグナリング交通」、RFC 2719、1999年10月のため。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, November 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年11月。
Michael Tuexen Siemens AG ICN WN CS SE 51 D-81359 Munich Germany
マイケルTuexenシーメンスAG ICN WN CS SE 51 D-81359ミュンヘン、ドイツ
Phone: +49 89 722 47210 EMail: Michael.Tuexen@icn.siemens.de
電話：+49 89 722 47210 Eメール：Michael.Tuexen@icn.siemens.de
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, Il 60004 USA
私はIEモトローラ社1501 W.シュウ再ドライブをXオリンピックアイスQ、＃2309アーリントンハイツ、IL 60004 USA
Phone: +1 847 632 3028 EMail: qxie1@email.mot.com
電話：+1 847 632 3028 Eメール：qxie1@email.mot.com
Randall Stewart Cisco Systems, Inc. 24 Burning Bush Trail Crystal Lake, Il 60012 USA
ランドール・スチュワートシスコシステムズ社24燃える柴トレイルクリスタルレイク、イル60012 USA
Phone: +1 815 477 2127 EMail: rrs@cisco.com
電話：+1 815 477 2127 Eメール：rrs@cisco.com
Melinda Shore Cisco Systems, Inc. 809 Hayts Rd Ithaca, NY 14850 USA
メリンダ・ショアシスコシステムズ社809 Hayts Rdのイサカ、NY 14850 USA
Phone: +1 607 272 7512 EMail: mshore@cisco.com
電話：+1 607 272 7512 Eメール：mshore@cisco.com
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
リンドン・オングシエナ10480 Ridgeview裁判所クパチーノ、CA 95014 USA
Phone: +1 408 366 3358 EMail: lyong@ciena.com
電話：+1 408 366 3358 Eメール：lyong@ciena.com
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
ジョンLoughneyノキア・リサーチセンター私書箱407 FIN-00045 Nokiaのグループフィンランド
Phone: +358 50 483 6242 EMail: john.loughney@nokia.com
電話番号：+358 50 483 6242 Eメール：john.loughney@nokia.com
Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 USA
モーリーンスティルマンノキア127 W.ステート・ストリートイサカ、NY 14850 USA
Phone: +1 607 273 0724 62 EMail: maureen.stillman@nokia.com
電話：+1 607 273 0724 62電子メール：maureen.stillman@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。