RFC5351 日本語訳
5351 An Overview of Reliable Server Pooling Protocols. P. Lei, L. Ong,M. Tuexen, T. Dreibholz. September 2008. (Format: TXT=33062 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループP.レイ要求をネットワークでつないでください: 5351年のシスコシステムズInc.カテゴリ: デュースブルク-エッセン2008年9月の応用科学T.Dreibholz大学の情報のL.のオングCiena社のM.Tuexen Muenster大学
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.
Reliable Server Pooling取り組み("RSerPool"を簡略化する)はビルフォールトトレラントと非常に利用可能なクライアント/サーバアプリケーションにアプリケーションから独立しているセットのサービスとプロトコルを提供します。 このドキュメントはプロトコルとメカニズムの概要をReliable Server Poolingスイートに供給します。
Lei, et al. Informational [Page 1] RFC 5351 RSerPool Overview September 2008
レイ、他 [1ページ]情報のRFC5351RSerPool概要2008年9月
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
1. 序論…3 2. サーバアクセス・プロトコル(できるだけ早い)概要に集めてください…6 2.1. 初期設定をプールしてください…6 2.2. 実体登録をプールしてください…6 2.3. エンティティの選択をプールしてください…7 2.4. 終点は…を生かします…7 2.5. フェイルオーバーサービス…7 2.5.1. クッキーメカニズム…7 2.5.2. 名刺メカニズム…8 3. 終点Handlespace冗長プロトコル(ENRP)概要…8 3.1. 初期設定…8 3.2. サーバ発見とホームサーバ選択…8 3.3. 失敗検出、Handlespace監査、および同期。9 3.4. サーバの接収…9 4. 例のシナリオ…9 4.1. RSerPool解決サービスを使用する例のシナリオ…9 4.2. RSerPoolセッション・サービスを使用する例のシナリオ…11 5. リファレンスインプリメンテーション…12 6. セキュリティ問題…12 7. IANA問題…12 8. 承認…12 9. 参照…13 9.1. 標準の参照…13 9.2. 有益な参照…13
Lei, et al. Informational [Page 2] RFC 5351 RSerPool Overview September 2008
レイ、他 [2ページ]情報のRFC5351RSerPool概要2008年9月
1. Introduction
1. 序論
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.
Reliable Server Pooling(RSerPool)プロトコル群は、サーバ(「プール要素」)を選択する能力と共に同等なサービス(「プール」)を提供しながら(「プールユーザ」)をサーバのグループからクライアントアプリケーションに提供するように設計されています。 プロトコルは現在、Experimental Trackのために狙います。
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アーキテクチャは高い有用性とロードバランシングをサポートします。 アーキテクチャは1セットの基本的な目標をサポートするために定義されます:
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 1セットのアプリケーションから独立しているフェイルオーバー能力の簡易化
o peer-to-peer structure
o ピアツーピア構造
The basic components of the RSerPool architecture are shown in Figure 1 below:
RSerPoolアーキテクチャの基本的な成分は以下の図1に示されます:
Lei, et al. Informational [Page 3] RFC 5351 RSerPool Overview September 2008
レイ、他 [3ページ]情報のRFC5351RSerPool概要2008年9月
.......................
______ ______ . +-------+ .
/ ENRP \ / ENRP \ . | | .
|Server| <----> |Server|<----------.----->| PE 1 | .
\______/ ENRP \______/ ASAP(1) . | | .
^ . +-------+ .
| . .
| ASAP(2) . Server Pool .
V . .
+-------+ . +-------+ .
| | . | | .
| PU |<---------->. | PE 2 | .
| | PU to PE . | | .
+-------+ . +-------+ .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
....................... ______ ______ . +-------+ . /ENRP\/ENRP\。| | . |サーバ| <、-、-、-->| サーバ| <、-、-、-、-、-、-、-、-、--.----->| PE1| . \______/ENRP\______/、できるだけ早さ、(1)。| | . ^ . +-------+ . | . . | できるだけ早く、(2) サーバは. V+をプールします。-------+ . +-------+ . | | . | | . | Pu| <、-、-、-、-、-、-、-、-、-->。 | PE2| . | | PEへのPu。| | . +-------+ . +-------+ . . . . +-------+ . . | | . . | PE3| . . | | . . +-------+ . .......................
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つ以上のサーバのセットと定義されます。 サーバはPool Elements(PEs)と呼ばれます。 耐障害性か例えば負荷分割法を提供するのにサーバプールの中の複数のPEsを使用できます。 PEsはプールからEndpoint haNdlespace Redundancyプロトコル(ENRP)サーバと呼ばれる実体で、登録して、反-登録します、(できるだけ早い)[RFC5352]Aggregate Server Accessプロトコルを使用して(この協会ができるだけ早く(1) 中にラベルされる、図)
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.
それぞれのサーバプールはプールハンドル(ペーハー)と呼ばれるユニークなバイトストリングによって特定されます。 プールハンドルはプールから特定のそのIPアドレス(IPv4とIPv6 PEアドレスの両方がサポートされる)とポートナンバーによって見つけられたPEまでのマッピングを許容します。 プールハンドルはプールの中でサーバにアクセスするのを試みるとPool User(PU)によって指定されることです。 PEにアクセスするのに必要なアドレスにプールハンドルを決議するために、できるだけ早く使用することでPUがENRPサーバに相談する、(この協会ができるだけ早く(2) 中にラベルされる、図) プールハンドルのスペースは限られた操作上の範囲がある平坦なスペースであると思われます(RFC3237[RFC3237]を見てください)。 プールハンドルの政権はこのとき、RSerPoolプロトコルドキュメントによって演説されません。 PUとPEの間で使用されるプロトコルはアプリケーション特有です。 PUとPEが応用層コミュニケーションのために一般的なセットのプロトコルをサポートするために構成されると思われます、RSerPoolメカニズムの如何にかかわらず。
Lei, et al. Informational [Page 4] RFC 5351 RSerPool Overview September 2008
レイ、他 [4ページ]情報のRFC5351RSerPool概要2008年9月
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]を使用します。 PUsとPEsに関しては、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
...
______ _____ ... /ENRP\/ENRP\… PEs/うみの<。---->|サーバ| <、-、-、-->| サーバ| <、-、-、-->PEs/うみ… できるだけ早さ、\______/ENRP\______/、できるだけ早い… ^ ^ | | | /ENRP\| +---->|サーバ| <、-、-、--+ ENRP\______/ENRP^| できるだけ早く…に対して PEs/うみ…
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
Reliable Server Poolingフレームワークのための要件はRFC3237[RFC3237]で定義されます。 ロードバランシングの領域のRSerPoolに関する要件がグリッド・コンピューティング/高性能コンピューティングに部分的に重なることに注意する価値があります。 しかしながら、両方の領域の範囲は完全に異なっています: また、グリッドと高性能コンピューティングは異なった管理ドメイン、データロック、同期、相互セッションコミュニケーション、および強力な計算サービスのための資源の使用に対する課金を管理するような話題をカバーしていますが、RSerPoolの意志は単に負荷分配とセッション管理の軽量の実現です。 これらの機能性は、使用されるために特に、意図しています。
Lei, et al. Informational [Page 5] RFC 5351 RSerPool Overview September 2008
レイ、他 [5ページ]情報のRFC5351RSerPool概要2008年9月
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.
小さいメモリと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プロトコル群の概要、明確にAggregate Server Accessプロトコル(できるだけ早い)[RFC5352]、およびEndpoint Handlespace Redundancyプロトコル(ENRP)[RFC5353]を提供します。 プロトコル仕様に加えて、両方のプロトコルのための一般的なパラメタ書式仕様[RFC5354]があります、サーバ選択規則(プール方針)[RFC5356]の定義、軍事的脅威分析[RFC5355]と同様に。
2. Aggregate Server Access Protocol (ASAP) Overview
2. 集合サーバアクセス・プロトコル(できるだけ早い)概要
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 サーバ失敗を扱うためのフェイルオーバーメカニズム
2.1. Pool Initialization
2.1. プール初期設定
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が反-登録するとき、それらは見えなくなります。 言い換えれば、登録がENRPサーバに達すると、あるマシンの最初のPEの始動はプールの作成を引き起こします。
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に構成されると思われます。 このコンフィギュレーションプロセスを自動化するメソッドはこのとき、扱われません。
2.2. Pool Entity Registration
2.2. プール実体登録
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
を通して新しいサーバがRegistrationメッセージを送ることによって既存のプールを接合する、できるだけ早さ、それが接合したがっているプールのプールハンドル、それ自体(手当たりしだいに選ばれている)のためのPE識別子、プールの生涯の情報を示すENRPサーバと何という輸送
Lei, et al. Informational [Page 6] RFC 5351 RSerPool Overview September 2008
レイ、他 [6ページ]情報のRFC5351RSerPool概要2008年9月
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サーバは、ホームENRPサーバと呼ばれて、PEによる購読のリストを維持して、PEがまだ敏感であると確認するために期末監査を実行します。
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).
同様の手順は、反-サーバプールからそれ自体を登録するために適用されます(あるいはまた、サーバはどれになったかの後に、単に、プールから優雅に取り除いた状態でそれが以前にともに記名した生涯の期限が切れるかもしれません)。
2.3. Pool Entity Selection
2.3. プールエンティティの選択
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.
を通して終点がそうしたがっているとき、プールの中のサーバに接続されてください、それ、生成する、できるだけ早くHandle Resolutionが通信する、サーバハンドルがプールサーバに関する知識に基礎づけたENRPサーバ決心をホームENRPへのこれに送って、Handle Resolution Responseメッセージをリターンに送る、できるだけ早く。 応答は連絡できるプールに1つ以上のサーバのIPアドレスのリストを含んでいます。 サーバのリストが作成されるプロセスはサーバ選択のための多くの方針にかかわるかもしれません。 RSerPoolプロトコル群は、いくつかの基本方針を定義して、より複雑な方針のために入力された外部のサーバ選択の使用を許します。
2.4. Endpoint Keep-Alive
2.4. 生きている終点生活費
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サーバが使用することでプール要素の状態をモニターする、できるだけ早く、生きているEndpoint Keepは通信します。 PEが応じる、できるだけ早く生きているKeepが通信する、生きているEndpoint Keep 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サーバに通知できる、できるだけ早くEndpoint Unreachableが通信する、ENRPサーバに。
2.5. Failover Services
2.5. フェイルオーバーサービス
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によってサポートされたいくつかの簡単なメカニズムがどんなアプリケーションも使用できる何らかのレベルのフェイルオーバーを許容します。
2.5.1. Cookie Mechanism
2.5.1. クッキーメカニズム
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
クッキーはできるだけ早く、層にして、定期的にPEからPUに送ることによって任意に生成されるかもしれません。 PUは最後の容認されたクッキーを保存するだけです。 フェイルオーバーの場合には、PUは最後にこれを送ります。
Lei, et al. Informational [Page 7] RFC 5351 RSerPool Overview September 2008
レイ、他 [7ページ]情報のRFC5351RSerPool概要2008年9月
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.
新しいPEへの容認されたクッキー。 このメソッドは州がPEsを平等に割り当てる簡単な方法を提供します。 古いPEはクッキーに署名するはずです、そして、受信PEはその署名について確かめるはずです。 PUに関しては、クッキーは、新しいPEに骨格がなくて、保存されるだけであり、伝えられます。
2.5.2. Business Card Mechanism
2.5.2. 名刺メカニズム
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は同輩がフェイルオーバーに使用するべきであるどの他のPEsに関してそのプールハンドルと指導を含む同輩(PEかPU)に名刺を送ることができます。これはそれが、ロードバランシングなどのプール問題に基づくかもしれない失敗の場合の使用かユーザ問題への「次の最善」PEであると何を認識するかをPUに言う手段をPEに与えます、最も最新の州の情報を持っているPEsなどのように。
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview
3. 終点Handlespace冗長プロトコル(ENRP)概要
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.
1セットのサーバプール(handlespaceとして指示される)はENRPサーバによって管理されます。 プールは全体のインターネット、しかし、単に操作上の範囲と呼ばれるより小さいドメインで有効ではありません。 ENRPサーバは、分配されて、欠点許容性があって、リアルタイムの登録サービスを維持するのにENRPプロトコルを使用します。 ENRPサーバは会員資格が変えるプール、handlespaceデータ同期などの情報交換のために互いにコミュニケートします。
3.1. Initialization
3.1. 初期設定
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を選定するためによく知られるマルチキャストチャンネルでPresenceメッセージを出すことによって、試みます。 メントールはどんな同輩ENRPサーバであるかもしれません。最も現在のhandlespaceデータはHandle Table Requestsによってメントールから要求されます。 Handle Table Responseメッセージの形における容認された答えはローカルのデータベースにアンパックされます。 その後に、ENRPサーバはサービスをENRPに供給する準備ができています。
3.2. Server Discovery and Home Server Selection
3.2. サーバ発見とホームサーバ選択
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
PEsは、現在、できるだけ早くメッセージを使用することによって、新たに機能しているENRPサーバに彼らの存在を示すことができます。 サーバが出された後に彼らが新しいENRPサーバを発見する、できるだけ早くServer Announceが通信する、よく知られるところでは、できるだけ早く、マルチキャストは精神を集中します。 PEsはともに記名するだけでよいです。
Lei, et al. Informational [Page 8] RFC 5351 RSerPool Overview September 2008
レイ、他 [8ページ]情報のRFC5351RSerPool概要2008年9月
one ENRP server, as other ENRP servers supporting the pool will synchronize their knowledge about pool elements using the ENRP protocol.
プールを支える1つのENRPサーバの、そして、他のENRPサーバが、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サーバになることができます。
3.3. Failure Detection, Handlespace Audit, and Synchronization
3.3. 失敗検出、Handlespace監査、および同期
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 Presenceに送ります。 また、これらのPresenceメッセージはホームENRPサーバの役割にはENRPサーバがあるすべてのPEのアイデンティティに関して計算されたチェックサムを含んでいます。それぞれのENRPサーバは、同輩の日付までのリストを維持して、また、確信している同輩から予想されたチェックサムを計算できます、ローカルのhandlespaceデータベースによると。 同輩(handlespace監査として、指示される)によって報告された予想された合計と合計を比較することによって、矛盾を検出できます。 このような場合には、同期のために、類似して、handlespace(その同輩によって所有されていたPEsに制限される)をセクション3.2に要求できます。
3.4. Server Takeover
3.4. サーバの接収
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サーバは他のサーバがホームENRPの役割の上で失敗した同輩のPEsに取るものを交渉します。 を通して接収に関するコンセンサスに達した後にこれらのPEsを持って行くENRPサーバが持って行かれたPEsに関してまた、同輩(ENRPを通した)に通知書を送る、(できるだけ早い)
4. Example Scenarios
4. 例のシナリオ
4.1. Example Scenario Using RSerPool Resolution Service
4.1. RSerPool解決サービスを使用する例のシナリオ
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:
プールユーザ(「クライアント」)アプリケーションのためにできるだけ早さ、実装、クライアントシステムの上で利用可能です、アプリケーションソースコードに必要である3つの変更しか通常ないということです:
Lei, et al. Informational [Page 9] RFC 5351 RSerPool Overview September 2008
レイ、他 [9ページ]情報のRFC5351RSerPool概要2008年9月
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.
2. ホスト名からIPアドレス、アプリケーションまで翻訳する例えば、Unixライブラリ関数getaddrinfo())は入力されるようにプールハンドルを取るGETPRIMARYSERVERと臨時に命名されて、原始的にRSerPoolサービスを呼び出して、プライマリサーバのIPアドレスを返します。(次に、DNSベースのサービスを利用することの代わりに、ちょうど前のシナリオの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.
3. 追加RSerPoolサービスの使用がなければ、失敗検出とフェイルオーバー手順を各アプリケーションに設計しなければなりません。 しかしながら、失敗がプライマリサーバに検出されるとき、再びセカンダリサーバに関するホスト名にDNS翻訳を呼び出すことの代わりに、GETNEXTSERVER(ただ一つの操作における2つの機能を実行する)と臨時に命名されて、アプリケーションは原始的にサービスを呼び出します。
1. First, it indicates to the RSerPool layer the failure of the
server returned by a previous GETPRIMARYSERVER or
GETNEXTSERVER call.
1. まず最初に、前のGETPRIMARYSERVERによって返されたサーバの失敗をRSerPool層に示すか、またはGETNEXTSERVERは呼びます。
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. 2番目に、連絡されるべきである次のサーバのIPアドレスを提供します、現時点(例えば、有効なプール要素をセットして、事実上、要素方針をプールにプールしますなど)にRSerPool層に利用可能な最も良い情報によると。
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:
プール要素(「サーバ」)アプリケーション、どこ、できるだけ早さ、実装、利用可能であることで、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)プロトコルかイド、ポート(必要ならマッピングによる)、およびプーリング方針(または、方針)を写像するのを含んでいます。
2. The server should invoke the DEREGISTER service primitive to
remove itself from the server pool when shutting down.
2. サーバは停止するとき、サーバプールから立ち退くためには原始のDEREGISTERサービスを呼び出すべきです。
Lei, et al. Informational [Page 10] RFC 5351 RSerPool Overview September 2008
レイ、他 [10ページ]情報のRFC5351RSerPool概要2008年9月
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は制限されましたが(すべてのサービスを利用すると比べて)、それにもかかわらずかなり役に立つ利益を提供します。 まず最初に、クライアントユーザは一連、すなわち、サーバのリストよりむしろプールハンドルを供給するだけでよいです。 2番目に、使用されているかに関するどのサーバがことである決定はサーバ選択メカニズムでダイナミックに決定できます(すなわち、「プール方針」はできるだけ早さまでに働きました; できるだけ早く、[RFC5352]を見てください)。 失敗が起こるとき、最終的に、これらはできるだけ早さの現在のシグナリング[RFC5352]とENRP[RFC5353]を通してプールに報告されます。 他のクライアントは、結局、このサーバが失敗したのを知るでしょう(この失敗がRSerPoolアーキテクチャの他の原理によっていったん確認されると)。
4.2. Example Scenario Using RSerPool Session Services
4.2. 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によって提供されたトランスポート層基関数、Stream Control Transmissionプロトコル(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フレームワークによって管理されるので、自動的に、unsentデータ(RSerPoolによってまだ基本的なトランスポート・プロトコルに提出されていなかったデータ)をフェイルオーバーの新たに選択されたプール要素に向け直します。また、基本的なトランスポート層がunsentデータの検索をサポートするなら(SCTPのように)、自動的に新たに選択されたプール要素に検索されたunsentデータを再送できます。
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
アプリケーション・サーバー(プール要素)が自動的に別のプール要素に取られる州のクッキー(セクション2.5.1では、説明される)を提供できる、(できるだけ早く層にしてください、プールユーザ) . この州のクッキーでは、フェイルオーバーの場合、それがセッションかトランザクションであったのを続けるのが必要であるどんな状態も休養させるのを新しいプール要素でのアプリケーションを促進するのに使用できます。
Lei, et al. Informational [Page 11] RFC 5351 RSerPool Overview September 2008
レイ、他 [11ページ]情報のRFC5351RSerPool概要2008年9月
interrupted by a failure in the communication between a pool user
and the original pool element.
プールユーザと元のプール要素とのコミュニケーションでの失敗で、中断されます。
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のPEです。AはプールXよりAでの失敗、またはAとB、PE Bの間の通信リンクにおける失敗のイベントが名刺の情報を使用できるプールX.Inのメンバーとしてそれを特定するPE Bへの「名刺」接触に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のアプリケーションがプールXのいくつかの特定のPEsを意識しているなら、それは接触へのAがBから手が届かなくなる場合Bのために好まれるでしょう、とPU Aがそのリストを前提とすることができる、できるだけ早く層にしてください、それがAの名刺に含まれるでしょう(セクション2.5.2を見てください)。
5. Reference Implementation
5. リファレンスインプリメンテーション
A reference implementation of RSerPool is available at [RSerPoolPage] and described in [Dre2006].
RSerPoolの参照実装は、[RSerPoolPage]で利用可能で[Dre2006]で説明されています。
6. Security Considerations
6. セキュリティ問題
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に記録されたものを超えてセキュリティ要件を特定して、できるだけ早く、仕様を議定書の中で述べません。 THREATS[RFC5355]にRSerPoolの軍事的脅威分析を提供します。
7. IANA Considerations
7. IANA問題
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動作を必要としません。
8. Acknowledgements
8. 承認
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall Stewart, Scott Bradner, and many others for their invaluable comments.
作者は彼らの非常に貴重なコメントについてモーリーン・スティルマン、Qiaobingシェ、ランドル・スチュワート、スコット・ブラドナー、および多くの他のものに感謝したがっています。
Lei, et al. Informational [Page 12] RFC 5351 RSerPool Overview September 2008
レイ、他 [12ページ]情報のRFC5351RSerPool概要2008年9月
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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.スティルマン、「信頼できるサーバプーリングのための要件」RFC3237(2002年1月)。
[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、「集合サーバアクセス・プロトコル(できるだけ早い)」、RFC5352、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)」、RFC5353 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は「サーバアクセス・プロトコル(できるだけ早い)と終点Handlespace冗長プロトコル(ENRP)パラメタに集めます」、RFC5354、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.、Guttman、E.、Holdrege、M.、およびS.Sengodan、「セキュリティのために信頼できるサーバプーリング(RSerPool)と要件によって脅威に対応して導入された脅威」RFC5355(2008年9月)。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling
Policies", RFC 5356, September 2008.
[RFC5356] DreibholzとT.とM.Tuexen、「信頼できるサーバプーリング方針」、RFC5356、2008年9月。
9.2. Informative References
9.2. 有益な参照
[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/Derivate-16326/Dre2006-final.pdf>)を設けます。
Lei, et al. Informational [Page 13] RFC 5351 RSerPool Overview September 2008
レイ、他 [13ページ]情報のRFC5351RSerPool概要2008年9月
Authors' Addresses
作者のアドレス
Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US
ピーターレイシスコシステムズInc.955Happfieldアーリントンハイツ博士、IL60004米国
Phone: +1 773 695-8201 EMail: peterlei@cisco.com
以下に電話をしてください。 +1 773 695-8201 メールしてください: peterlei@cisco.com
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 US
カルパチーノ、リンドンオングCiena社のPO Box308カリフォルニア95015米国
EMail: Lyong@Ciena.com
メール: Lyong@Ciena.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexen Muenster大学。 39 48565Steinfurtドイツ
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大学、実験的な数学Ellernstrasse29 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-7637Fax: +49 201 183-7673 メールしてください: dreibh@iem.uni-due.de ユリ: http://www.iem.uni-due.de/~dreibh/
Lei, et al. Informational [Page 14] RFC 5351 RSerPool Overview September 2008
レイ、他 [14ページ]情報のRFC5351RSerPool概要2008年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Lei, et al. Informational [Page 15]
レイ、他 情報[15ページ]
一覧
スポンサーリンク
