RFC5353 日本語訳
5353 Endpoint Handlespace Redundancy Protocol (ENRP). Q. Xie, R.Stewart, M. Stillman, M. Tuexen, A. Silverton. September 2008. (Format: TXT=83657 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Q. Xie
Request for Comments: 5353 R. Stewart
Category: Experimental The Resource Group
M. Stillman
Nokia
M. Tuexen
Muenster Univ. of Applied Sciences
A. Silverton
Sun Microsystems, Inc.
September 2008
コメントを求めるワーキンググループQ.シェ要求をネットワークでつないでください: 5353年のR.スチュワートカテゴリ: 実験的である、応用科学A.シルヴァートンサン・マイクロシステムズ・インク2008年9月の資源グループM.蒸留装置操作係ノキアM.Tuexen Muenster大学
Endpoint Handlespace Redundancy Protocol (ENRP)
終点Handlespace冗長プロトコル(ENRP)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.
Endpoint Handlespace Redundancyプロトコル(ENRP)は、(できるだけ早く)Reliable Server Pooling(RSerPool)要件とアーキテクチャの機能性を達成するためにAggregate Server Accessプロトコルに関連して働くように設計されています。 RSerPoolの操作上の範囲の中では、ENRPは保存のための分配されたフォールトトレラント登録サービスの手順とメッセージ・フォーマットを定義します、簿記、プール操作と会員資格情報を検索して、広げて。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Conventions ................................................4
2. ENRP Message Definitions ........................................4
2.1. ENRP_PRESENCE Message ......................................5
2.2. ENRP_HANDLE_TABLE_REQUEST Message ..........................6
2.3. ENRP_HANDLE_TABLE_RESPONSE Message .........................7
2.4. ENRP_HANDLE_UPDATE Message .................................9
2.5. ENRP_LIST_REQUEST Message .................................10
2.6. ENRP_LIST_RESPONSE Message ................................11
2.7. ENRP_INIT_TAKEOVER Message ................................12
2.8. ENRP_INIT_TAKEOVER_ACK Message ............................13
2.9. ENRP_TAKEOVER_SERVER Message ..............................14
2.10. ENRP_ERROR Message .......................................15
1. 序論…3 1.1. 定義…3 1.2. コンベンション…4 2. ENRPメッセージ定義…4 2.1. ENRP_存在メッセージ…5 2.2. ENRP_ハンドル_は_要求メッセージを見送ります…6 2.3. ENRP_ハンドル_は_応答メッセージを見送ります…7 2.4. ENRP_ハンドル_はメッセージをアップデートします…9 2.5. ENRP_リスト_はメッセージを要求します…10 2.6. ENRP_リスト_応答メッセージ…11 2.7. ENRP_イニット_接収メッセージ…12 2.8. ENRP_イニット_接収_ACKメッセージ…13 2.9. ENRP_接収_サーバメッセージ…14 2.10. ENRP_エラーメッセージ…15
Xie, et al. Experimental [Page 1] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [1ページ]実験的なRFC5353終点Handlespace冗長2008年9月
3. ENRP Operation Procedures ......................................15
3.1. Methods for Communicating amongst ENRP Servers ............16
3.2. ENRP Server Initialization ................................16
3.2.1. Generate a Server Identifier .......................16
3.2.2. Acquire Peer Server List ...........................17
3.2.2.1. Finding the Mentor Server .................17
3.2.2.2. Request Complete Server List from
Mentor Peer ...............................17
3.2.3. Download ENRP Handlespace Data from Mentor Peer ....18
3.3. Server Handlespace Update .................................20
3.3.1. Announcing Additions or Updates of PE ..............20
3.3.2. Announcing Removal of PE ...........................21
3.4. Maintaining Peer List and Monitoring Peer Status ..........22
3.4.1. Discovering New Peer ...............................22
3.4.2. Server Sending Heartbeat ...........................22
3.4.3. Detecting Peer Server Failure ......................23
3.5. Taking Over a Failed Peer Server ..........................23
3.5.1. Initiating Server Take-over Arbitration ............23
3.5.2. Takeover Target Peer Server ........................24
3.6. Handlespace Data Auditing and Re-synchronization ..........25
3.6.1. Auditing Procedures ................................25
3.6.2. PE Checksum Calculation Algorithm ..................26
3.6.3. Re-Synchronization Procedures ......................27
3.7. Handling Unrecognized Messages or Unrecognized
Parameters ................................................28
4. Variables and Thresholds .......................................28
4.1. Variables .................................................28
4.2. Thresholds ................................................28
5. IANA Considerations ............................................28
5.1. A New Table for ENRP Message Types ........................29
5.2. A New Table for Update Action Types .......................29
5.3. Port Numbers ..............................................30
5.4. SCTP Payload Protocol Identifier ..........................30
6. Security Considerations ........................................30
6.1. Summary of RSerPool Security Threats ......................30
6.2. Implementing Security Mechanisms ..........................32
6.3. Chain of Trust ............................................34
7. Acknowledgments ................................................35
8. References .....................................................36
8.1. Normative References ......................................36
8.2. Informative References ....................................37
3. ENRP運転手順…15 3.1. ENRPサーバの中で交信するためのメソッド…16 3.2. ENRPサーバ初期設定…16 3.2.1. サーバ識別子を生成してください…16 3.2.2. 同輩サーバリストを取得してください…17 3.2.2.1. 師サーバを見つけます…17 3.2.2.2. 師の同輩から完全なサーバリストを要求してください…17 3.2.3. 師の同輩からENRP Handlespaceデータをダウンロードしてください…18 3.3. サーバHandlespaceアップデート…20 3.3.1. PEの追加かアップデートを発表します…20 3.3.2. PEの解任を発表します…21 3.4. 同輩リストを維持して、同輩状態をモニターします…22 3.4.1. 新しい同輩を発見します…22 3.4.2. サーバの発信している鼓動…22 3.4.3. 同輩サーバ失敗を検出します…23 3.5. 失敗した同輩サーバを引き継ぎます…23 3.5.1. サーバ接収仲裁を開始します…23 3.5.2. 接収目標同輩サーバ…24 3.6. Handlespaceデータ監査と再同期…25 3.6.1. 手順を監査します…25 3.6.2. PEチェックサム計算アルゴリズム…26 3.6.3. 再同期手順…27 3.7. 認識されていないメッセージか認識されていないパラメタを扱います…28 4. 変数と敷居…28 4.1. 変数…28 4.2. 敷居…28 5. IANA問題…28 5.1. ENRPメッセージのための新しいテーブルはタイプされます…29 5.2. アップデート動作のための新しいテーブルはタイプされます…29 5.3. 数を移植してください…30 5.4. SCTP有効搭載量プロトコル識別子…30 6. セキュリティ問題…30 6.1. RSerPool軍事的脅威の概要…30 6.2. セキュリティがメカニズムであると実装します…32 6.3. 信頼のチェーン…34 7. 承認…35 8. 参照…36 8.1. 標準の参照…36 8.2. 有益な参照…37
Xie, et al. Experimental [Page 2] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [2ページ]実験的なRFC5353終点Handlespace冗長2008年9月
1. Introduction
1. 序論
ENRP is designed to work in conjunction with ASAP [RFC5352] to accomplish the functionality of RSerPool as defined by its requirements [RFC3237].
に関連してENRPが働くように設計されている、できるだけ早さ、[RFC5352] 要件[RFC3237]によって定義されるようにRSerPoolの機能性を達成するために。
Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.
RSerPoolの操作上の範囲の中では、ENRPは保存のための分配されたフォールトトレラント登録サービスの手順とメッセージ・フォーマットを定義します、簿記、プール操作と会員資格情報を検索して、広げて。
Whenever appropriate, in the rest of this document, we will refer to this RSerPool registry service as ENRP handlespace, or simply handlespace, because it manages all pool handles.
このドキュメントの残りで適切であるときはいつも、私たちはこのRSerPool登録サービスをENRP handlespace、または単にhandlespaceと呼ぶつもりです、すべてのプールハンドルを管理するので。
1.1. Definitions
1.1. 定義
This document uses the following terms:
このドキュメントは次の用語を使用します:
Operational 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: A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a unique
pool handle.
ハンドルをプールしてください: プールへの論理的な指針。 それぞれのサーバプールはシステムの操作上の範囲でユニークなプールハンドルで身元保証可能になるでしょう。
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 pool handle
and a destination transport address of the pool element.
要素ハンドル(または、終点ハンドル)をプールしてください: プールの中の特定のプール要素への論理的な指針、プールハンドルと目的地から成るのはプール要素のアドレスを輸送します。
Handle space: A cohesive structure of pool handles and relations
that may be queried by an internal or external agent.
スペースを扱ってください: 内部の、または、外部のエージェントによって質問されるかもしれないプールハンドルと関係の粘着性がある構造。
ENRP client channel: The communication channel through which an ASAP
User (either a Pool Element (PE) or Pool User (PU)) requests ENRP
handlespace service. The client channel is usually defined by the
transport address of the Home ENRP server and a well-known port
number.
ENRPクライアントチャンネル: 通信チャネル、通じて、どれ、できるだけ早く、User(Pool Element(PE)かPool User(PU)のどちらか)はENRP handlespaceサービスを要求するか。 通常、クライアントチャンネルはホームENRPサーバとウェルノウン・ポート番号の輸送アドレスによって定義されます。
Xie, et al. Experimental [Page 3] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [3ページ]実験的なRFC5353終点Handlespace冗長2008年9月
ENRP server channel: Defined by a list of IP addresses (one for each
ENRP server in an operational scope) and a well-known port number.
All ENRP servers in an operational scope can send "group-cast"
messages to other servers through this channel. In a "group-
cast", the sending server sends multiple copies of the message,
one to each of its peer servers, over a set of point-to-point
Stream Control Transmission Protocol (SCTP) associations between
the sending server and the peers. The "group-cast" may be
conveniently implemented with the use of the "SCTP_SENDALL" option
on a one-to-many style SCTP socket.
ENRPサーバチャンネル: IPアドレス(操作上の範囲のそれぞれのENRPサーバあたり1つ)のリストとウェルノウン・ポート番号で、定義されます。 操作上の範囲のすべてのENRPサーバがこのチャンネルで他のサーバへの「グループキャスト」メッセージを送ることができます。 「グループキャスト」では、送付サーバで、メッセージ、複本の1つは送付サーバと同輩との1セットの二地点間Stream Control Transmissionプロトコル(SCTP)仲間の上にそれぞれの同輩サーバに行きます。 多くへのA OneスタイルSCTPソケットの上に「SCTP_SENDALL」オプションの使用がある状態で、「グループキャスト」は便利に実装されるかもしれません。
Home ENRP server: The ENRP server to which a PE or PU currently
belongs. A PE MUST only have one Home ENRP server at any given
time, and both the PE and its Home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its Home ENRP server.
ホームENRPサーバ: PEかPUが現在属するENRPサーバ。 PE MUSTには、その時々で、1つのホームENRPサーバしかありません、そして、PEとそのホームENRPサーバの両方がそれらの間のこのマスター/奴隷関係の動向をおさえなければなりません。 ホームENRPサーバとしての利用可能なENRPサーバのPU SHOULD選んだもの。
1.2. Conventions
1.2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. ENRP Message Definitions
2. ENRPメッセージ定義
In this section, we define the format of all ENRP messages. These are messages sent and received amongst ENRP servers in an operational scope. Messages sent and received between a PE/PU and an ENRP server are part of ASAP and are defined in [RFC5352]. A common format, that is defined in [RFC5354], is used for all ENRP and ASAP messages.
このセクションで、私たちはすべてのENRPメッセージの書式を定義します。 これらは操作上の範囲のENRPサーバの中に送られて、受け取られたメッセージです。 PE/PUとENRPサーバの間に送られて、受け取られたメッセージは、できるだけ早さの一部であり、[RFC5352]で定義されます。 一般的な形式、すなわち、定義されたコネ[RFC5354]は、すべてのENRPに使用されて、できるだけ早く、通信します。
Most ENRP messages contain a combination of fixed fields and TLV (Type-Length-Value) parameters. The TLV parameters are also defined in [RFC5354]. If a nested TLV parameter is not ended on a 32-bit word boundary, it will be padded with all '0' octets to the next 32- bit word boundary.
ほとんどのENRPメッセージが固定分野とTLV(長さの値をタイプする)パラメタの組み合わせを含んでいます。 また、TLVパラメタは[RFC5354]で定義されます。 入れ子にされたTLVパラメタが32ビットの語境界で終わらないと、それはすべての'0'八重奏で次の32の噛み付いている語境界に水増しされるでしょう。
All messages, as well as their fields/parameters described below, MUST be transmitted in network byte order (aka Big Endian, meaning the most significant byte is transmitted first).
ネットワークバイトオーダーですべてのメッセージ、および以下で説明されたそれらの分野/パラメタを送らなければなりません(通称Big Endian、意味している最も重要なバイトは最初に、伝えられます)。
Xie, et al. Experimental [Page 4] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [4ページ]実験的なRFC5353終点Handlespace冗長2008年9月
For ENRP, the following message types are defined in this section:
ENRPに関しては、以下のメッセージタイプはこのセクションで定義されます:
Type Message Name
----- -------------------------
0x00 - (Reserved by IETF)
0x01 - ENRP_PRESENCE
0x02 - ENRP_HANDLE_TABLE_REQUEST
0x03 - ENRP_HANDLE_TABLE_RESPONSE
0x04 - ENRP_HANDLE_UPDATE
0x05 - ENRP_LIST_REQUEST
0x06 - ENRP_LIST_RESPONSE
0x07 - ENRP_INIT_TAKEOVER
0x08 - ENRP_INIT_TAKEOVER_ACK
0x09 - ENRP_TAKEOVER_SERVER
0x0a - ENRP_ERROR
0x0b-0xff - (Reserved by IETF)
タイプメッセージ名----- ------------------------- 0x00 - (Reserved by IETF) 0x01 - ENRP_PRESENCE 0x02 - ENRP_HANDLE_TABLE_REQUEST 0x03 - ENRP_HANDLE_TABLE_RESPONSE 0x04 - ENRP_HANDLE_UPDATE 0x05 - ENRP_LIST_REQUEST 0x06 - ENRP_LIST_RESPONSE 0x07 - ENRP_INIT_TAKEOVER 0x08 - ENRP_INIT_TAKEOVER_ACK 0x09 - ENRP_TAKEOVER_SERVER 0x0a - ENRP_ERROR 0x0b-0xff - (IETFによって予約されます)
Figure 1
図1
2.1. ENRP_PRESENCE Message
2.1. ENRP_存在メッセージ
This ENRP message is used to announce (periodically) the presence of an ENRP server, or to probe the status of a peer ENRP server. This message is either sent on the ENRP server channel or sent point-to- point to another ENRP server.
(定期的に)ENRPサーバの存在を示すか、または同輩ENRPサーバの状態を調べるのにこのENRPメッセージを使用します。このメッセージは、ENRPサーバチャンネルで送るか、または別のENRPサーバにポイントからポイントを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x01をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PEチェックサムParam: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : サーバ情報Param(任意の): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID: 32 bits (unsigned integer)
送付サーバのID: 32ビット(符号のない整数)
This is the ID of the ENRP server that sent this message.
これはこのメッセージを送ったENRPサーバのIDです。
Xie, et al. Experimental [Page 5] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [5ページ]実験的なRFC5353終点Handlespace冗長2008年9月
Receiving Server's ID: 32 bits (unsigned integer)
受信サーバのID: 32ビット(符号のない整数)
This is the ID of the ENRP server to which this message is
intended. If the message is not intended for an individual
server (e.g., the message is group-casted to a group of
servers), this field MUST be sent with all 0s. If the message
is sent point-to-point, this field MAY be sent with all 0s.
これはこのメッセージが意図するENRPサーバのIDです。 個々のサーバのためにメッセージを意図しないなら(例えば、メッセージはグループによってサーバのグループにcastedされています)、すべての0と共にこの野原を送らなければなりません。 ポイントツーポイントをメッセージに送るなら、すべての0と共にこの野原を送るかもしれません。
PE Checksum Parameter:
PEチェックサムパラメタ:
This is a TLV that contains the latest PE checksum of the ENRP
server that sends the ENRP_PRESENCE. This parameter SHOULD be
included for handlespace consistency auditing. See
Section 3.6.1 for details.
これはENRP_PRESENCEを送るENRPサーバの最新のPEチェックサムを含むTLVです。 このパラメタSHOULD、handlespace一貫性監査には、含められてください。 詳細に関してセクション3.6.1を見てください。
Server Information Parameter:
サーバ情報パラメタ:
If this parameter is present, it contains the server
information of the sender of this message (the Server
Information Parameter is defined in [RFC5354]). This parameter
is optional. However, if this message is sent in response to a
received "reply required" ENRP_PRESENCE from a peer, the sender
then MUST include its server information.
このパラメタが存在しているなら、それはこのメッセージの送付者のサーバ情報を含んでいます(Server情報Parameterは[RFC5354]で定義されます)。 このパラメタは任意です。 しかしながら、同輩からの容認された「回答が必要であり」ENRP_PRESENCEに対応してこのメッセージを送るなら、そして、送付者はサーバ情報を入れなければなりません。
Note, at startup, an ENRP server MUST pick a randomly generated, non- zero 32-bit unsigned integer as its ID and MUST use this same ID until the ENRP server is rebooted.
そして、始動でENRPサーバが32ビットで手当たりしだいに発生している非ゼロを選ばなければならないことに注意してください、IDとしての符号のない整数、ENRPサーバがリブートされるまで、この同じIDを使用しなければなりません。
2.2. ENRP_HANDLE_TABLE_REQUEST Message
2.2. ENRP_ハンドル_テーブル_要求メッセージ
An ENRP server sends this message to one of its peers to request a copy of the handlespace data. This message is normally used during server initialization or handlespace re-synchronization.
ENRPサーバは、handlespaceデータのコピーを要求するためにこのメッセージを同輩のひとりに送ります。 通常、このメッセージはサーバ初期化かhandlespace再同期の間、使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x02をタイプしてください。|0|0|0|0|0|0|0|W| メッセージ長は0xCと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xie, et al. Experimental [Page 6] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [6ページ]実験的なRFC5353終点Handlespace冗長2008年9月
W (oWn-children-only) Flag: 1 bit
W(自己の子供専用)旗: 1ビット
Set to '1' if the sender of this message is only requesting
information about the PEs owned by the message receiver.
Otherwise, set to '0'.
このメッセージの送付者がメッセージ受信機によって所有されていたPEsの情報を要求しているだけであるなら、'1'にセットしてください。さもなければ、'0'にセットしてください。
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
2.3. ENRP_HANDLE_TABLE_RESPONSE Message
2.3. ENRP_ハンドル_テーブル_応答メッセージ
The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in response to a received PEER_NAME_TABLE_REQUEST message to assist peer-server initialization or handlespace synchronization.
ENRPサーバは同輩サーバ初期化かhandlespace同期を促進する受信されたPEER_NAME_TABLE_REQUESTメッセージに対応してPEER_NAME_TABLE_RESPONSEメッセージを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 |0|0|0|0|0|0|M|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Entry #1 (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Entry #n (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x03をタイプしてください。|0|0|0|0|0|0|M|R| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : プールエントリー#1(任意の): : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : エントリー#(任意の)nをプールしてください: : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M (More_to_send) Flag: 1 bit
M(_への、より多くの_が発信する)旗: 1ビット
Set to '1' if the sender of this message has more pool entries
to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages.
Otherwise, set to '0'.
このメッセージの送付者が以上にその後のENRP_HANDLE_TABLE_RESPONSEメッセージを送るためにエントリーをプールさせるなら、'1'にセットしてください。 さもなければ、'0'にセットしてください。
Xie, et al. Experimental [Page 7] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [7ページ]実験的なRFC5353終点Handlespace冗長2008年9月
R (Reject) Flag: 1 bit
R(拒絶する)旗: 1ビット
MUST be set to '1' if the sender of this message is rejecting a
handlespace request. In this case, pool entries MUST NOT be
included. This might happen if the sender of this message is
in the middle of initializing its database or is under high
load.
このメッセージの送付者がhandlespace要求を拒絶しているなら、'1'に設定しなければなりません。 この場合、プールエントリーを含んではいけません。 このメッセージの送付者はデータベースを初期化する中央にいるか、または高い負荷の下にいるなら、これが起こるかもしれません。
Message Length: 16 bits (unsigned integer)
メッセージ長: 16ビット(符号のない整数)
Indicates the entire length of the message, including the
header, in number of octets.
八重奏の数でヘッダーを含むメッセージの全長を示します。
Note, the value in the Message Length field will NOT cover any
padding at the end of this message.
注意、Message Length分野の値はこのメッセージの終わりの少しの詰め物もカバーしないでしょう。
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Pool Entry #1-#n:
プールエントリー#1#n:
If the R flag is set to '0', at least one pool entry SHOULD be
present in this message. Each pool entry MUST start with a
Pool Handle parameter, as defined in Section 3.9 of [RFC5354],
and is followed by one or more Pool Element parameters in TLV
format, as shown below:
R旗が設定されるなら、'0'、少なくとも1つに、現在のコネがこのメッセージであったならエントリーSHOULDをプールしてください。 それぞれのプールエントリーから[RFC5354]のセクション3.9で定義されるようにPool Handleパラメタから始まらなければならなくて、TLV形式における1つ以上のPool Elementパラメタがあとに続いています、以下に示すように:
+---------------------------+
: Pool Handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
+---------------------------+ : ハンドルをプールしてください: +---------------------------+ : PE#1: +---------------------------+ : PE#2: +---------------------------+ : ... : +---------------------------+ : PE#n: +---------------------------+
Xie, et al. Experimental [Page 8] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [8ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.4. ENRP_HANDLE_UPDATE Message
2.4. ENRP_ハンドル_アップデートメッセージ
The PEER_NAME_UPDATE message is sent by the Home ENRP server of a PE to all peer servers to announce registration, re-registration, or de- registration of the PE in the handlespace.
PEのホームENRPサーバでPEER_NAME_UPDATEメッセージをすべての同輩サーバに送って、handlespaceでのPEの登録、再登録、または反-登録を発表します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Action | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x04をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アップデート動作| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ハンドルパラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 要素パラメタをプールしてください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length: 16 bits (unsigned integer)
メッセージ長: 16ビット(符号のない整数)
Indicates the entire length of the message, including the
header, in number of octets.
八重奏の数でヘッダーを含むメッセージの全長を示します。
Note, the value in the Message Length field will NOT cover any
padding at the end of this message.
注意、Message Length分野の値はこのメッセージの終わりの少しの詰め物もカバーしないでしょう。
Update Action: 16 bits (unsigned integer)
動作をアップデートしてください: 16ビット(符号のない整数)
This field indicates the requested action of the specified PE.
The field MUST be set to one of the following values:
この分野は指定されたPEの要求された機能を示します。 以下の値の1つに分野を設定しなければなりません:
0x0000 - ADD_PE: Add or update the specified PE in the ENRP
handlespace.
0×0000--_PEを加えてください: ENRP handlespaceで指定されたPEを加えるか、またはアップデートしてください。
0x0001 - DEL_PE: Delete the specified PE from the ENRP
handlespace.
0×0001--DEL_PE: ENRP handlespaceから指定されたPEを削除してください。
0x0002 - 0xFFFF: Reserved by IETF.
0×0002 --0xFFFF、: IETFによって予約されます。
Other values are reserved by IETF and MUST NOT be used.
他の値を、IETFが予約して、使用してはいけません。
Xie, et al. Experimental [Page 9] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [9ページ]実験的なRFC5353終点Handlespace冗長2008年9月
Reserved: 16 bits
予約される: 16ビット
This field MUST be set to all 0s by the sender and ignored by
the receiver.
この分野を送付者によってすべての0に設定されて、受信機で無視しなければなりません。
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Pool Handle:
ハンドルをプールしてください:
Specifies to which the PE belongs.
指定、PEが属する。
Pool Element:
要素をプールしてください:
Specifies the PE.
PEを指定します。
2.5. ENRP_LIST_REQUEST Message
2.5. ENRP_リスト_要求メッセージ
The PEER_LIST_REQUEST message is sent to request a current copy of the ENRP server list. This message is normally sent from a newly activated ENRP server to an established ENRP server as part of the initialization process.
ENRPサーバリストの現在のコピーを要求するためにPEER_LIST_REQUESTメッセージを送ります。 通常、初期化プロセスの一部として新たに動かされたENRPサーバから確立したENRPサーバにこのメッセージを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x05をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長は0xCと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Xie, et al. Experimental [Page 10] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [10ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.6. ENRP_LIST_RESPONSE Message
2.6. ENRP_リスト_応答メッセージ
The PEER_LIST_RESPONSE message is sent in response from an ENRP server that receives a PEER_LIST_REQUEST message to return information about known ENRP servers.
PEER_LIST_RESPONSEメッセージは知られているENRPサーバの情報を返すPEER_LIST_REQUESTメッセージを受け取るENRPサーバからの送られた応答です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x06をタイプしてください。|0|0|0|0|0|0|0|R| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 同輩#1のサーバ情報パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 同輩#nのサーバ情報パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) Flag: 1 bit
R(拒絶する)旗: 1ビット
This flag MUST be set to '1' if the sender of this message is
rejecting a PEER_LIST_REQUEST message. If this case occurs,
the message MUST NOT include any Server Information Parameters.
このメッセージの送付者がPEER_LIST_REQUESTメッセージを拒絶しているなら、'1'にこの旗を設定しなければなりません。 本件が現れるなら、メッセージは少しのServer情報Parametersも含んではいけません。
Message Length: 16 bits (unsigned integer)
メッセージ長: 16ビット(符号のない整数)
Indicates the entire length of the message in number of octets.
八重奏の数における、メッセージの全長を示します。
Note, the value in the Message Length field will NOT cover any
padding at the end of this message.
注意、Message Length分野の値はこのメッセージの終わりの少しの詰め物もカバーしないでしょう。
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Server Information Parameter of Peer #1-#n:
同輩#1#のnサーバ情報パラメタ:
Each contains a Server Information Parameter of a peer known to
the sender. The Server Information Parameter is defined in
[RFC5354].
それぞれが送付者にとって知られている同輩のServer情報Parameterを含んでいます。 Server情報Parameterは[RFC5354]で定義されます。
Xie, et al. Experimental [Page 11] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [11ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.7. ENRP_INIT_TAKEOVER Message
2.7. ENRP_イニット_接収メッセージ
The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the takeover initiator) to announce its intention of taking over a specific peer ENRP server. It is sent to all its peers.
ENRPサーバ(接収創始者)でENRP_INIT_TAKEOVERメッセージを送ります。特定の同輩ENRPサーバを引き継ぐという意志を発表して、すべての同輩にそれを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x07をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを狙います。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Targeting Server's ID: 32 bits (unsigned integer)
狙いサーバのID: 32ビット(符号のない整数)
This is the ID of the peer ENRP that is the target of this
takeover attempt.
これはこの接収試みの目標である同輩ENRPのIDです。
Xie, et al. Experimental [Page 12] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [12ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.8. ENRP_INIT_TAKEOVER_ACK Message
2.8. ENRP_イニット_接収_ACKメッセージ
The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover initiator to acknowledge the reception of the PEER_INIT_TAKEOVER message and that it does not object to the takeover.
PEER_INIT_TAKEOVERメッセージのレセプションと、それが接収に反対しないと認めるために接収創始者に対応してPEER_INIT_TAKEOVER_ACKメッセージを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x08をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを狙います。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Targeting Server's ID:
狙いサーバのID:
This is the ID of the peer ENRP that is the target of this
takeover attempt.
これはこの接収試みの目標である同輩ENRPのIDです。
Xie, et al. Experimental [Page 13] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [13ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.9. ENRP_TAKEOVER_SERVER Message
2.9. ENRP_接収_サーバメッセージ
The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator to declare the enforcement of a takeover to all active peer ENRP servers.
PEER_TAKEOVER_REGISTRARメッセージは、すべてのアクティブな同輩ENRPサーバに接収の実施を宣言するために接収創始者によって送られます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x09をタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを狙います。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Targeting Server's ID:
狙いサーバのID:
This is the ID of the peer ENRP that is the target of this
takeover operation.
これはこの接収操作の目標である同輩ENRPのIDです。
Xie, et al. Experimental [Page 14] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [14ページ]実験的なRFC5353終点Handlespace冗長2008年9月
2.10. ENRP_ERROR Message
2.10. ENRP_エラーメッセージ
The ENRP_ERROR message is sent by a registrar to report an operational error to a peer ENRP server.
ENRP_ERRORメッセージは、同輩ENRPサーバに誤操作を報告するために記録係によって送られます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0aをタイプしてください。|0|0|0|0|0|0|0|0| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付サーバのID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバのIDを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 誤操作パラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
送付サーバのID:
See Section 2.1.
セクション2.1を見てください。
Receiving Server's ID:
受信サーバのID:
See Section 2.1.
セクション2.1を見てください。
Operational Error Parameter:
誤操作パラメタ:
This parameter, defined in [RFC5354], indicates the type of
error(s) being reported.
[RFC5354]で定義されたこのパラメタは報告される誤りのタイプを示します。
3. ENRP Operation Procedures
3. ENRP運転手順
In this section, we discuss the operation procedures defined by ENRP. An ENRP server MUST follow these procedures when sending, receiving, or processing ENRP messages.
このセクションで、私たちはENRPによって定義された運転手順について議論します。 ENRPメッセージを送るか、受け取るか、または処理するとき、ENRPサーバはこれらの手順に従わなければなりません。
Many of the RSerPool events call for both server-to-server and PU/ PE-to-server message exchanges. Only the message exchanges and activities between an ENRP server and its peer(s) are considered within the ENRP scope and are defined in this document.
RSerPoolイベントの多くがサーバからサーバとPU/ PEからサーバへの両方の交換処理を求めます。 ENRPサーバとその同輩の間の交換処理と活動だけが、ENRP範囲の中で考えられて、本書では定義されます。
Procedures for exchanging messages between a PE/PU and ENRP servers are defined in [RFC5352].
PE/PUとENRPサーバの間でメッセージを交換するための手順は[RFC5352]で定義されます。
Xie, et al. Experimental [Page 15] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [15ページ]実験的なRFC5353終点Handlespace冗長2008年9月
3.1. Methods for Communicating amongst ENRP Servers
3.1. ENRPサーバの中で交信するためのメソッド
Within an RSerPool operational scope, ENRP servers need to communicate with each other in order to exchange information, such as the pool membership changes, handlespace data synchronization, etc.
RSerPoolの操作上の範囲の中では、ENRPサーバは、情報交換するために互いにコミュニケートする必要があります、プール会員資格変化、handlespaceデータ同期などのように
Two types of communications are used amongst ENRP servers:
2つのタイプに関するコミュニケーションはENRPサーバの中で使用されます:
o point-to-point message exchanges from one ENPR server to a
specific peer server, and
o そして二地点間1つのENPRサーバから特定の同輩サーバまでの交換処理。
o announcements from one server to all its peer servers in the
operational scope.
o 操作上の範囲での1つのサーバからすべての同輩サーバまでの発表。
Point-to-point communication is always carried out over an SCTP association between the sending server and the receiving server. Announcements are sent out via "group-casts" over the ENRP server channel.
送付サーバと受信サーバの間でいつもSCTP協会の上に二地点間コミュニケーションを行います。ENRPサーバチャンネルの上の「グループキャスト」を通して発表を出します。
3.2. ENRP Server Initialization
3.2. ENRPサーバ初期設定
This section describes the steps a new ENRP server needs to take in order to join the other existing ENRP servers, or to initiate the handlespace service if it is the first ENRP server started in the operational scope.
このセクションは新しいENRPサーバがそれが操作上の範囲で始められた最初のENRPサーバであるなら他の既存のENRPサーバを接合するために取るか、またはhandlespaceサービスを開始するために必要とするステップについて説明します。
3.2.1. Generate a Server Identifier
3.2.1. サーバ識別子を生成してください。
A new ENRP server MUST generate a non-zero, 32-bit server ID that is as unique as possible among all the ENRP servers in the operational scope, and this server ID MUST remain unchanged for the lifetime of the server. Normally, a good 32-bit random number will be good enough, as the server ID [RFC4086] provides some information on randomness guidelines.
新しいENRPサーバは、操作上の範囲のすべてのENRPサーバの中で非ゼロの、そして、32ビットのサーバができるだけユニークなIDであると生成しなければなりません、そして、このサーバIDはサーバの生涯変わりがあってはいけません。通常、良い32ビットの乱数は十分良くなるでしょう、サーバID[RFC4086]が偶発性ガイドラインの何らかの情報を提供するとき。
Note, there is a very remote chance (about 1 in about 4 billion) that two ENRP servers in an operational scope will generate the same server ID and hence cause a server ID conflict in the pool. However, no severe consequence of such a conflict has been identified.
注意、プールの中に操作上の範囲の2つのENRPサーバが同じサーバがIDであると生成して、したがって、サーバID闘争を引き起こすという非常にリモートな可能性(40億に関するおよそ1つのコネ)があります。 しかしながら、そのような闘争のどんな厳しい結果も特定されていません。
Note, the ENRP server ID space is separate from the PE Id space defined in [RFC5352].
注意、ENRPサーバIDスペースは[RFC5352]で定義されたPE Idスペースから別々です。
Xie, et al. Experimental [Page 16] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [16ページ]実験的なRFC5353終点Handlespace冗長2008年9月
3.2.2. Acquire Peer Server List
3.2.2. 同輩サーバリストを取得してください。
At startup, the ENRP server (the initiating server) will first attempt to learn of all existing peer ENRP servers in the same operational scope, or to determine that it is alone in the scope.
始動では、ENRPサーバ(開始サーバ)は、最初に、同じ操作上の範囲のすべての既存の同輩ENRPサーバを知るか、またはそれが範囲で単独であることを決定するのを試みるでしょう。
The initiating server uses an existing peer server to bootstrap itself into service. We call this peer server the mentor server.
開始サーバは、サービスにそれ自体を独力で進むのに既存の同輩サーバを使用します。 私たちは、この同輩サーバを師サーバと呼びます。
3.2.2.1. Finding the Mentor Server
3.2.2.1. 師サーバを見つけます。
If the initiating server is told about one existing peer server through some administrative means (such as DNS query, configuration database, startup scripts, etc.), the initiating server MUST then use this peer server as its mentor server.
いくつかの管理手段(DNS質問、構成データベース、始動スクリプトなどの)でおよそ1つの既存の同輩サーバが開始サーバに言われるなら、開始サーバは師サーバとしてこの同輩サーバを使用しなければなりません。
If multiple existing peer servers are specified, the initiating server MUST pick one of them as its mentor server and keep the others as its backup mentor servers.
複数の既存の同輩サーバが指定されるなら、開始サーバは、師サーバとしてそれらの1つを選んで、バックアップ師サーバとして他のものを保たなければなりません。
If no existing peer server is specified, the initiating server MUST assume that it is alone in the operational scope, and MUST skip the procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its initialization completed and start offering ENRP services.
どんな既存の同輩サーバも指定されないなら、開始サーバは、操作上の範囲で単独であり、セクション3.2.2の.2とセクション3.2.3で手順をスキップしなければならなくて、初期化が完成していると考えなければならないと仮定して、サービスをENRPに提供し始めなければなりません。
3.2.2.2. Request Complete Server List from Mentor Peer
3.2.2.2. 師の同輩から完全なサーバリストを要求してください。
Once the initiating server finds its mentor peer server (by either discovery or administrative means), the initiating server MUST send an ENRP_LIST_REQUEST message to the mentor peer server to request a copy of the complete server list maintained by the mentor peer (see Section 3.4 for maintaining a server list).
開始サーバがいったん、師同輩サーバ(発見か管理手段のどちらかによる)を見つけると、開始サーバは、師の同輩によって維持された完全なサーバリストのコピーを要求するためにENRP_LIST_REQUESTメッセージを師同輩サーバに送らなければなりません(サーバリストを維持するためにセクション3.4を見てください)。
The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every time it finishes sending an ENRP_LIST_REQUEST message. If the timer expires before receiving a response from the mentor peer, the initiating server SHOULD abandon the interaction with the current mentor server and send a new server list request to a backup mentor peer, if one is available.
開始サーバSHOULDがaを始める、マックスタイム誌NO RESPONSE、ENRP_LIST_REQUESTを送り終えるときはいつも、タイマは通信します。 師の同輩から応答を受ける前にタイマが期限が切れるなら、開始サーバSHOULDは現在の師サーバで相互作用を捨てて、新しいサーバリスト要求をバックアップ師の同輩に送ります、1つが利用可能であるなら。
Upon the reception of this request, the mentor peer server SHOULD reply with an ENRP_LIST_RESPONSE message and include in the message body all existing ENRP servers known by the mentor peer.
この要求のレセプションでは、師同輩サーバSHOULDはENRP_LIST_RESPONSEメッセージで返答して、メッセージ本体に師の同輩によって知られていたすべての既存のENRPサーバを含んでいます。
Upon the reception of the ENRP_LIST_RESPONSE message from the mentor peer, the initiating server MUST use the server information carried in the message to initialize its own peer list.
師の同輩からのENRP_LIST_RESPONSEメッセージのレセプションでは、開始サーバはそれ自身の同輩リストを初期化するメッセージで運ばれたサーバ情報を使用しなければなりません。
Xie, et al. Experimental [Page 17] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [17ページ]実験的なRFC5353終点Handlespace冗長2008年9月
However, if the mentor itself is in the process of startup and not ready to provide a peer server list (for example, the mentor peer is waiting for a response to its own ENRP_LIST_REQUEST to another server), it MUST reject the request by the initiating server and respond with an ENRP_LIST_RESPONSE message with the R flag set to '1', and with no server information included in the response.
しかしながら、師自身が始動の途中にいて、同輩サーバリストを提供する準備ができていないなら(例えば、師の同輩はそれ自身のENRP_LIST_REQUESTへの応答を別のサーバに待っています)、それは、開始サーバで要求を拒絶して、サーバ情報が全くR旗が'1'に設定されていて応答に含まれていなく、ENRP_LIST_RESPONSEメッセージで応じなければなりません。
In the case where its ENRP_LIST_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the ENRP_LIST_REQUEST to the new mentor server.
ENRP_LIST_REQUESTが師の同輩によって拒絶されて、開始サーバSHOULDが数秒間、待っていて、ENRP_を再送する場合では、師サーバかそれとも手があいているバックアップ師の同輩がいるかどうかへのLIST_REQUESTは新しい師サーバに別の師同輩サーバを選択して、ENRP_LIST_REQUESTを送ります。
3.2.3. Download ENRP Handlespace Data from Mentor Peer
3.2.3. 師の同輩からENRP Handlespaceデータをダウンロードしてください。
After a peer list download is completed, the initiating server MUST request a copy of the current handlespace data from its mentor peer server, by taking the following steps:
同輩リストダウンロードが終了した後に、開始サーバは師同輩サーバから現在のhandlespaceデータのコピーを要求しなければなりません、以下の方法を取ることによって:
1. The initiating server MUST first send an
ENRP_HANDLE_TABLE_REQUEST message to the mentor peer, with the W
flag set to '0', indicating that the entire handlespace is
requested.
1. 開始サーバは最初にENRP_HANDLE_TABLE_REQUESTメッセージを師の同輩に送らなければなりません、'0'に設定されたW旗で、全体のhandlespaceが要求されているのを示して。
2. Upon the reception of this message, the mentor peer MUST start a
download session in which a copy of the current handlespace data
maintained by the mentor peer is sent to the initiating server in
one or more ENRP_HANDLE_TABLE_RESPONSE messages. (Note, the
mentor server may find it particularly desirable to use multiple
ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when
the handlespace is large, especially when forming and sending out
a single response containing a large handlespace may interrupt
its other services.)
2. このメッセージのレセプションに、師の同輩は師の同輩によって保守された現在のhandlespaceデータのコピーが1つ以上のENRP_HANDLE_TABLE_RESPONSEメッセージの開始サーバに送られるダウンロードセッションを始めなければなりません。 (注意、特に形成するとき、handlespaceが大きく、大きいhandlespaceを含むただ一つの応答を出すのが他のサービスを中断するかもしれないなら、師サーバはhandlespaceを送る複数のENRP_HANDLE_TABLE_RESPONSEメッセージを使用するのが特に望ましいのがわかるかもしれません。)
If more than one ENRP_HANDLE_TABLE_RESPONSE message is used
during the download, the mentor peer MUST use the M flag in each
ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this
message is the last one for the download session. In particular,
the mentor peer MUST set the M flag to '1' in the outbound
ENRP_HANDLE_TABLE_RESPONSE if there is more data to be
transferred and MUST keep track of the progress of the current
download session. The mentor peer MUST set the M flag to '0' in
the last ENRP_HANDLE_TABLE_RESPONSE for the download session and
close the download session (i.e., removing any internal record of
the session) after sending out the last message.
1つ以上のENRP_HANDLE_TABLE_RESPONSEメッセージがダウンロードの間、使用されるなら、師の同輩はダウンロードセッションのためにこのメッセージが最後のものであるかどうかを示すそれぞれのENRP_HANDLE_TABLE_RESPONSEメッセージでM旗を使用しなければなりません。 特に、師の同輩はMが移すために、より多くのデータがあれば外国行きの_ENRP_HANDLE TABLE_RESPONSEの'1'まで旗を揚げて、動向をおさえなければならない現在のダウンロードセッションの進歩のセットがそうしなければなりません。 師の同輩は、ダウンロードセッションのために最後のENRP_HANDLE_TABLE_RESPONSEの'0'にM旗を設定して、最後のメッセージを出した後に、ダウンロードセッション(すなわち、セッションのどんな内部の記録も取り除く)を終えなければなりません。
Xie, et al. Experimental [Page 18] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [18ページ]実験的なRFC5353終点Handlespace冗長2008年9月
3. During the downloading, every time the initiating server receives
an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data
entries carried in the message into its local handlespace
database, and then check whether or not this message is the last
one for the download session.
3. ダウンロードの間、開始サーバがENRP_HANDLE_TABLE_RESPONSEメッセージを受け取るときはいつも、それは、メッセージで運ばれたデータエントリーをローカルのhandlespaceデータベースに移して、次に、ダウンロードセッションのためにこのメッセージが最後のものであるかどうかチェックしなければなりません。
If the M flag is set to '1' in the just processed
ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST
send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer
to request for the next ENRP_HANDLE_TABLE_RESPONSE message.
M旗がただ処理されているところの'1'に設定されるなら、ENRP_HANDLE_TABLE_RESPONSEは通信して、開始サーバは次のENRP_HANDLE_TABLE_RESPONSEメッセージのために要求する師の同輩に別のENRP_HANDLE_TABLE_REQUESTメッセージを送らなければなりません。
4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE
message into its local handlespace database, the initiating
server MUST handle each pool entry carried in the message using
the following rules:
4. ENRP_HANDLE_TABLE_RESPONSEメッセージからローカルのhandlespaceデータベースにデータエントリーをアンパックするとき、開始サーバはメッセージで以下の規則を使用することで運ばれたそれぞれのプールエントリーを扱わなければなりません:
A. If the pool does not exist in the local handlespace, the
initiating server MUST create the pool in the local
handlespace and add the PE(s) in the pool entry to the pool.
A. プールが地方のhandlespaceに存在していないなら、開始サーバは、地方のhandlespaceでプールを作成して、プールエントリーでプールにPE(s)を加えなければなりません。
When creating the pool, the initiation server MUST set the
overall member selection policy type of the pool to the
policy type indicated in the first PE.
プールを作成するとき、開始サーバはプールの総合的なメンバー選択方針タイプを最初のPEで示された方針タイプに設定しなければなりません。
B. If the pool already exists in the local handlespace, but the
PE(s) in the pool entry is not currently a member of the
pool, the initiating server MUST add the PE(s) to the pool.
B. プールが地方のhandlespaceに既に存在していますが、現在プールエントリーにおけるPE(s)がプールの部材でないなら、開始サーバはプールにPE(s)を加えなければなりません。
C. If the pool already exists in the local handlespace AND the
PE(s) in the pool entry is already a member of the pool, the
initiating server SHOULD replace the attributes of the
existing PE(s) with the new information. ENRP will make sure
that the information stays up to date.
C. プールが地方のhandlespaceに既に存在していて、プールエントリーにおけるPE(s)が既にプールの部材であるなら、開始サーバSHOULDは既存のPE(s)の属性を新情報に取り替えます。 ENRPは、情報が最新の状態で残っているのを確実にするでしょう。
5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from
the mentor peer and unpacked into the local handlespace, the
initialization process is completed and the initiating server
SHOULD start to provide ENRP services.
5. 最後のENRP_HANDLE_TABLE_RESPONSEメッセージが師の同輩から受け取られて、地方のhandlespaceにアンパックされるとき、初期化の過程は完了しています、そして、開始サーバSHOULDはサービスをENRPに供給し始めます。
Under certain circumstances, the mentor peer itself may not be able to provide a handlespace download to the initiating server. For example, the mentor peer is in the middle of initializing its own handlespace database, or it currently has too many download sessions open to other servers.
ある状況で、師の同輩自身はhandlespaceダウンロードを開始サーバに提供できないかもしれません。例えば、師の同輩がそれ自身のhandlespaceデータベースを初期化する中央にいるか、または多く過ぎるのが現在、それで他のサーバに開かれているセッションをダウンロードします。
Xie, et al. Experimental [Page 19] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [19ページ]実験的なRFC5353終点Handlespace冗長2008年9月
In such a case, the mentor peer MUST reject the request by the initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE message with the R flag set to '1', and with no pool entries included in the response.
このような場合には、師の同輩は、開始サーバで要求を拒絶して、プールエントリーが全くR旗が'1'に設定されていて応答に含まれていなく、ENRP_HANDLE_TABLE_RESPONSEメッセージで応じなければなりません。
In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new mentor server.
ENRP_HANDLE_TABLE_REQUESTが師の同輩によって拒絶されて、開始サーバSHOULDが数秒間、待っていて、ENRP_HANDLE_を再送する場合では、師サーバかそれとも手があいているバックアップ師の同輩がいるかどうかへのTABLE_REQUESTは新しい師サーバに別の師同輩サーバを選択して、ENRP_HANDLE_TABLE_REQUESTを送ります。
A handlespace download session that has been started may get interrupted for some reason. To cope with this, the initiating server SHOULD start a timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires without receiving a response from the mentor peer, the initiating server SHOULD abort the current download session and re-start a new handlespace download with a backup mentor peer, if one is available.
始められたhandlespaceダウンロードセッションはある理由で中断されるかもしれません。 これに対処するために、ENRP_HANDLE_TABLE_REQUESTを師の同輩に送り終えるときはいつも、開始サーバSHOULDはタイマを始動します。 このタイマが師の同輩から応答を受けないで期限が切れるなら、開始サーバSHOULDは現在のダウンロードセッションを中止して、バックアップ師の同輩と共に新しいhandlespaceダウンロードを再開します、1つが利用可能であるなら。
Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the mentor peer setting the M-bit to '1' to indicate that it has more data to send, it SHOULD start a session timer. If this timer expires without receiving another request from the initiating server, the mentor peer SHOULD abort the session, cleaning out any resource and record of the session.
ENRP_HANDLE_TABLE_RESPONSEを出して、'1'にM-ビットを設定する師の同輩の後に、それには送るより多くのデータがあって、SHOULDであることを示すために、同様に、セッションタイマを始動してください。 このタイマが開始サーバから別の要求を受け取らないで期限が切れるなら、師同輩SHOULDはセッションを中止します、セッションに関するどんなリソースと記録も一掃して。
3.3. Server Handlespace Update
3.3. サーバHandlespaceアップデート
This includes a set of update operations used by an ENRP server to inform its peers when its local handlespace is modified, e.g., addition of a new PE, removal of an existing PE, change of pool or PE properties.
これはENRPサーバによって使用される、地方のhandlespaceがいつ変更されているかを同輩に知らせる1セットのアップデート操作を含んでいます、例えば、新しいPEの追加、既存のPEの解任、プールかPEの特性の変化。
3.3.1. Announcing Additions or Updates of PE
3.3.1. PEの追加かアップデートを発表します。
When a new PE is granted registration to the handlespace or an existing PE is granted a re-registration, the Home ENRP server uses this procedure to inform all its peers.
新しいPEは登録をhandlespaceに承諾されるか、または再登録が既存のPEに承諾されるとき、ホームENRPサーバが、すべての同輩に知らせるのにこの手順を用います。
This is an ENRP announcement and is sent to all the peer of the Home ENRP server. See Section 3.1 on how announcements are sent.
これをENRP発表であり、ホームENRPサーバのすべての同輩に送ります。どう発表を送るかのセクション3.1を見てください。
An ENRP server MUST announce this update to all its peers in a ENRP_HANDLE_UPDATE message with the Update Action field set to 'ADD_PE', indicating the addition of a new PE or the modification of
ENRPサーバはUpdate Action分野があるENRP_HANDLE_UPDATEメッセージの同輩が'ADD_PE'、新しいPEの追加を示すか、または変更にセットしたすべてにこのアップデートを発表しなければなりません。
Xie, et al. Experimental [Page 20] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [20ページ]実験的なRFC5353終点Handlespace冗長2008年9月
an existing PE. The complete new information of the PE and the pool it belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively.
既存のPE。 メッセージでPEパラメタとPool Handleパラメタでそれぞれそれが属すPEとプールの完全な新情報を示さなければなりません。
The Home ENRP server SHOULD fill in its server ID in the Sending Server's ID field and leave the Receiving Server's ID blank (i.e., all 0s).
ホームENRPサーバSHOULDはSending ServerのID分野にサーバIDに記入して、Receiving ServerのIDを空白の状態で(すなわちすべての0)おきます。
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take the following actions:
同輩がこのENRP_HANDLE_UPDATEメッセージを受け取るとき、以下の行動を取らなければなりません:
1. If the named pool indicated by the pool handle does not exist in
its local copy of the handlespace, the peer MUST create the named
pool in its local handlespace and add the PE to the pool as the
first PE. It MUST then copy in all other attributes of the PE
carried in the message.
1. プールハンドルによって示された命名されたプールがhandlespaceの地方のコピーに存在していないなら、同輩は、地方のhandlespaceで命名されたプールを作成して、最初のPEとしてプールにPEを加えなければなりません。 そして、それはメッセージで運ばれたPEの他のすべての属性でコピーされなければなりません。
When the new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the PE.
新しいプールが作成されるとき、プールの総合的なメンバー選択方針をPEによって示された方針タイプに設定しなければなりません。
2. If the named pool already exists in the peer's local copy of the
handlespace *and* the PE does not exist, the peer MUST add the PE
to the pool as a new PE and copy in all attributes of the PE
carried in the message.
2. *命名されたプールが同輩のhandlespace*の地方のコピーに既に存在していて、PEが存在していないなら、PEのすべての属性における新しいPEとコピーがメッセージで運ばれたので、同輩はプールにPEを加えなければなりません。
3. If the named pool exists *and* the PE is already a member of the
pool, the peer MUST replace the attributes of the PE with the new
information carried in the message.
3. そして、命名されたプールが存在している、*、*PEが既にプールの部材である、同輩はPEの属性をメッセージで運ばれる新情報に取り替えなければなりません。
3.3.2. Announcing Removal of PE
3.3.2. PEの解任を発表します。
When an existing PE is granted de-registration or is removed from its handlespace for some other reasons (e.g., purging an unreachable PE, see Section 3.5 in [RFC5352]), the ENRP server MUST use this procedure to inform all its peers about the change just made.
既存のPEが反-登録が承諾されるか、またはある他の理由でhandlespaceから取り外されるとき(例えば、手の届かないPEを掃除して、[RFC5352]でセクション3.5を見てください)、ENRPサーバは、ただ行われた変更に関してすべての同輩に知らせるのにこの手順を用いなければなりません。
This is an ENRP announcement and is sent to all the peers of the Home ENRP server. See Section 3.1 on how announcements are sent.
これをENRP発表であり、ホームENRPサーバのすべての同輩に送ります。どう発表を送るかのセクション3.1を見てください。
An ENRP server MUST announce the PE removal to all its peers in an ENRP_HANDLE_UPDATE message with the Update Action field set to DEL_PE, indicating the removal of an existing PE. The complete information of the PE and the pool it belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively.
ENRPサーバは、Update Action分野があるENRP_HANDLE_UPDATEメッセージのすべての同輩へのPE取り外しがDEL_PEにセットしたと発表しなければなりません、既存のPEの解任を示して。 メッセージでPEパラメタとPool Handleパラメタでそれぞれそれが属すPEとプールの完全な情報を示さなければなりません。
Xie, et al. Experimental [Page 21] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [21ページ]実験的なRFC5353終点Handlespace冗長2008年9月
The sending server MUST fill in its server ID in the Sending Server's ID field and leave the Receiving Server's ID blank (i.e., set to all 0s).
送付サーバは、Sending ServerのID分野にサーバIDに記入して、Receiving ServerのIDを空白の状態でおかなければなりません(すなわち、すべての0にセットしてください)。
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first find the pool and the PE in its own handlespace, and then remove the PE from its local handlespace. If the removed PE is the last one in the pool, the peer MUST also delete the pool from its local handlespace.
同輩がこのENRP_HANDLE_UPDATEメッセージを受け取ると、それは、最初にそれ自身のhandlespaceでプールとPEを見つけて、地方のhandlespaceからPEを取り外さなければなりません。 また、取り外されたPEがプールで最後のものであるなら、同輩は地方のhandlespaceからプールを削除しなければなりません。
If the peer fails to find the PE or the pool in its handlespace, it SHOULD take no further actions.
同輩が中でPEかプールを見つけないなら、それはhandlespaceで、SHOULDです。これ以上行動を取らないでください。
3.4. Maintaining Peer List and Monitoring Peer Status
3.4. 同輩リストを維持して、同輩状態をモニターします。
An ENRP server MUST keep an internal record on the status of each of its known peers. This record is referred to as the server's "peer list".
ENRPサーバは知られている同輩各人の状態に関する内部の記録をつけなければなりません。 この記録はサーバの「同輩リスト」と呼ばれます。
3.4.1. Discovering New Peer
3.4.1. 新しい同輩を発見します。
If a message of any type is received from a previously unknown peer, the ENRP server MUST consider this peer a new peer in the operational scope and add it to the peer list.
以前に未知の同輩からどんなタイプに関するメッセージも受け取るなら、ENRPサーバは、操作上の範囲でこの同輩が新しい同輩であると考えて、同輩リストにそれを追加しなければなりません。
The ENRP server MUST send an ENRP_PRESENCE message with the Reply- required flag set to '1' to the source address found in the arrived message. This will force the new peer to reply with its own ENRP_PRESENCE containing its full server information (see Section 2.1).
ENRPサーバは'1'に設定されたReplyの必要な旗でENRP_PRESENCEメッセージを到着したメッセージで見つけられたソースアドレスに送らなければなりません。 これによって、それ自身のENRP_PRESENCEが完全なサーバ情報を含んでいて、新しい同輩はやむを得ず返答するでしょう(セクション2.1を見てください)。
3.4.2. Server Sending Heartbeat
3.4.2. サーバ送付鼓動
Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its continued presence to all its peer with a ENRP_PRESENCE message. In the ENRP_PRESENCE message, the ENRP server MUST set the 'Replay_required' flag to '0', indicating that no response is required.
秒、サーバがそうしなければならないENRPが、ENRP_PRESENCEをもっているすべての同輩への継続的な存在が通信すると発表するあらゆるPEER-HEARTBEAT-CYCLE。 ENRP_PRESENCEメッセージでは、応答は全く必要でないことを示して、ENRPサーバが'再生_が必要である'という旗を'0'に設定しなければなりません。
The arrival of this periodic ENRP_PRESENCE message will cause all its peers to update their internal variable "peer_last_heard" for the sending server (see Section 3.4.3 for more details).
この周期的なENRP_PRESENCEメッセージの到着で、すべての同輩が送付サーバのために彼らの内部の可変「最後の_が聞いた同輩_」をアップデートするでしょう(その他の詳細に関してセクション3.4.3を見てください)。
Xie, et al. Experimental [Page 22] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [22ページ]実験的なRFC5353終点Handlespace冗長2008年9月
3.4.3. Detecting Peer Server Failure
3.4.3. 同輩サーバ失敗を検出します。
An ENRP server MUST keep an internal variable "peer_last_heard" for each of its known peers and the value of this variable MUST be updated to the current local time every time a message of any type (point-to-point or announcement) is received from the corresponding peer.
ENRPサーバは知られている同輩各人のために内部の可変「最後の_が聞いた同輩_」を保たなければなりません、そして、対応する同輩からどんなタイプ(ポイントツーポイントか発表)に関するメッセージも受け取るときはいつも、この変数の値を現地時間の電流にアップデートしなければなりません。
If a peer has not been heard for more than MAX-TIME-LAST-HEARD seconds, the ENRP server MUST immediately send a point-to-point ENRP_PRESENCE with the Reply_request flag set to '1' to that peer.
同輩の声がマックスタイム誌LAST-HEARD秒以上で聞かれていないなら、ENRPサーバはすぐに、'1'に設定されたReply_要求旗で二地点間ENRP_PRESENCEをその同輩に送らなければなりません。
If the send fails or the peer does not reply after MAX-TIME-NO- RESPONSE seconds, the ENRP server MUST consider the peer server dead and SHOULD initiate the takeover procedure defined in Section 3.5.
やり損ないを送ってください。さもないと、マックス-タイム誌RESPONSEがない秒、ENRPサーバが同輩サーバが死んでいると考えなければならなくて、SHOULDがセクション3.5で定義された接収手順に着手した後に同輩は返答しません。
3.5. Taking Over a Failed Peer Server
3.5. 失敗した同輩サーバを引き継ぎます。
In the following descriptions, we call the ENRP server that detects the failed peer server and initiates the takeover the "initiating server" and the failed peer server the "target server". This allows the PE to continue to operate in case of a failure of their Home ENRP server.
以下の記述では、私たちは、失敗した同輩サーバを検出して、接収を開始するENRPサーバを「開始サーバ」と呼びます、そして、失敗した同輩サーバは「目標サーバ」を呼びます。 これで、PEは、それらのホームENRPサーバの失敗の場合に作動し続けることができます。
3.5.1. Initiating Server Take-over Arbitration
3.5.1. サーバ接収仲裁を開始します。
The initiating server SHOULD first start the takeover arbitration process by sending an ENRP_INIT_TAKEOVER message to all its peer servers. See Section 3.1 on how announcements are sent. In the message, the initiating server MUST fill in the Sending Server's ID and Targeting Server's ID. The goal is that only one ENRP server takes over the PE from the target.
開始サーバSHOULDは、最初に、ENRP_INIT_TAKEOVERメッセージをすべての同輩サーバに送ることによって、接収仲裁プロセスを始めます。 どう発表を送るかのセクション3.1を見てください。 メッセージでは、開始サーバはSending ServerのIDとTargeting ServerのIDに記入しなければなりません。 目標は1つのENRPサーバだけが目標からPEを持って行くということです。
After announcing the ENRP_INIT_TAKEOVER message ("group-casting" to
all known peers, including the target server), the initiating server
SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its
known peers, except that of the target server.
ENRP_INIT_TAKEOVERメッセージ(目標サーバを含むすべての知られている同輩への「グループキャスティング」)を発表した後に、開始サーバSHOULDは知られている同輩各人からのENRP_INIT_TAKEOVER_ACKメッセージを待ちます、目標サーバのものを除いて。
Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating server MUST take the following actions:
開始サーバからENRP_INIT_TAKEOVERメッセージを受け取る各同輩は以下の行動を取らなければなりません:
1. If the peer server determines that it (itself) is the target
server indicated in the ENRP_INIT_TAKEOVER message, it MUST
immediately announce an ENRP_PRESENCE message to all its peer
ENRP servers in an attempt to stop this takeover process. This
1. 同輩サーバが、それ(それ自体)がENRP_INIT_TAKEOVERメッセージで示された目標サーバであることを決定するなら、それはすぐに、この接収プロセスを止める試みにおけるすべての同輩ENRPサーバにENRP_PRESENCEメッセージを発表しなければなりません。 これ
Xie, et al. Experimental [Page 23] RFC 5353 Endpoint Handlespace Redundancy September 2008
シェ、他 [23ページ]実験的なRFC5353終点Handlespace冗長2008年9月
一覧
スポンサーリンク
